أول تكامل ERP بين SofTech وطلبات في مصر: مزامنة مباشرة للمخزون والأسعار

أهم النقاط

• تؤكد مراسلات من Delivery Hero تلقتها CompuScope أن هذا هو أول تكامل متكامل من نوعه بين ERP وواجهة Talabat Partner API في مصر ضمن النطاق المحدد.
• تزامن النسخة المتاحة الأصناف المختارة والأسعار والمخزون الحالي حسب الفرع من دون الاعتماد على ملفات كتالوج دورية عبر SFTP.
• يمكن ربط فروع طلبات الافتراضية بفرع فعلي، واختيار مصدر المخزون، وضبط حد وقائي لإظهار الكمية بصفر.
• نشر العروض تلقائيًا واستقبال طلبات Talabat داخل نقطة البيع إمكانيتان قادمتان وليستا متاحتين حاليًا.
• القيمة الحقيقية تأتي من حوكمة بيانات القناة ومراقبة الاستثناءات وتحديد المسؤولية على مستوى كل فرع.

ماذا حقق تكامل SofTech مع طلبات؟

أطلقت SofTech وCompuScope تكاملًا ناجحًا ومتكاملًا مع واجهة Talabat Partner API في مصر. واستنادًا إلى مراسلات من Delivery Hero تلقتها CompuScope، يمثل هذا أول تكامل ERP مع واجهة طلبات بهذا النطاق في السوق المصرية. ترسل النسخة الحالية الأصناف المختارة وأسعار البيع المعتمدة والمخزون المتاح لكل فرع مرتبط مباشرة من SofTech، بدلًا من تبادل ملفات كتالوج مجدولة.

تكمن الأهمية في أن الإتاحة على المنصة ليست قائمة تسويقية منفصلة، بل وعد تشغيلي للعميل. يجب أن يطابق السعر الظاهر على طلبات السعر المعتمد، وأن يكون الصنف المعروض من فرع ما متاحًا بالفعل للتجهيز. وتؤكد وثائق Partner API الرسمية أن واجهة الكتالوج مصممة لمزامنة توافر المنتجات والمخزون والأسعار وبيانات الكتالوج عبر اتصال مباشر.

يجب أن تظل صياغة الأسبقية دقيقة. فهي لا تعني أن SofTech شريك التقنية الوحيد لطلبات، ولا تنفي وجود تكاملات نقاط بيع أخرى. المقصود هو نطاق التكامل المتكامل بين ERP وPartner API الذي أكدته Delivery Hero لـCompuScope. وعلى فريق النشر الاحتفاظ برسالة التأكيد ومطابقة أي عنوان أو حملة مع حدودها المكتوبة.

ما الوظائف المتاحة في الإصدار الحالي؟

بُني التكامل على التحكم حسب الفرع، وليس على تصدير غير منضبط لكل دليل الأصناف. وبذلك يستطيع فريق التشغيل الإجابة عن خمسة أسئلة واضحة: ما الصنف الذي سيباع عبر الإنترنت؟ وبأي سعر؟ ومن أي رصيد مخزون؟ ولأي فرع افتراضي على طلبات؟ وعند أي كمية يجب إيقاف الإتاحة؟

• مزامنة السعر: يرسل SofTech سعر البيع المعتمد المرتبط بإعدادات الفرع والتشكيلة الإلكترونية.
• المخزون الحالي حسب الفرع: تُرسل الكمية المتاحة من مصدر المخزون المختار بدلًا من التعامل مع رصيد الشبكة كله كرقم واحد.
• ربط الفروع الافتراضية: يمكن ربط أكثر من فرع افتراضي على طلبات بفرع فعلي واحد داخل SofTech وفق نموذج التشغيل.
• حد صفري قابل للضبط: يمكن الاحتفاظ بمخزون أمان يجعل الصنف غير متاح قبل نفاد الرصيد الفعلي بالكامل.
• اختيار المخزون: تحدد الشركة المخزون أو الموقع الذي يشارك في المزامنة بدلًا من كشف كل المخازن تلقائيًا.

تدعم مواصفات Partner API هذا النموذج؛ إذ تعتمد حالة المنتج على علامة التفعيل والكمية المرسلة وهامش المبيعات المضبوط. يقلل الهامش خطر قبول طلب على رصيد غير كافٍ، لكنه ليس ضمانًا مطلقًا. لذلك تظل مراقبة الحجوزات والمرتجعات غير المرحلة والتحديثات المتأخرة وأخطاء الاتصال ضرورية.

لماذا يختلف الاتصال المباشر عبر API عن ملفات SFTP؟

تستطيع الواجهة البرمجية والملف نقل بيانات الكتالوج، لكن لكل منهما إيقاع تشغيلي مختلف. تقدم طلبات Partner API بوصفها مسارًا للتحديثات المباشرة المؤتمتة، بينما تقدم SFTP كمسار يعتمد على الملفات ويلائم الإعدادات الأبسط. وتشير بوابة المطورين إلى أن الواجهة تقلل التدخل اليدوي، في حين تحتاج الملفات القياسية إلى تنسيق يدوي أكبر. ومع ذلك، تعتمد سرعة التحديث الفعلية على جدول SofTech وجودة الشبكة واستجابة الواجهة وسياسة إعادة المحاولة.

لا تكمن الفائدة الأساسية في الاختصار التقني، بل في تقصير المسافة بين تغيير معتمد داخل ERP وظهوره على القناة الإلكترونية. يمكن للفريق اكتشاف التحديث المرفوض وإعادة إرساله وحفظ سجل تدقيق ومقارنة القيمة المرسلة بالنتيجة المقبولة. قد يظل الملف المجدول مناسبًا لكتالوج صغير ومستقر، أما التشكيلة سريعة التغير عبر فروع كثيرة فتحتاج عادة إلى ضبط ومراقبة أقوى.

الاتصال المباشر لا يعني غياب الرقابة. يجب حوكمة بيانات الدخول وربط الفروع ودورية التحديث وقواعد إعادة المحاولة والسجلات ومسؤولية المطابقة قبل التوسع.

كيف يحقق نموذج الفروع قيمة عملية؟

يفيد ربط الفروع الافتراضية عندما يخدم موقع فعلي واحد أكثر من نطاق توصيل أو تشكيلة أو وقت تشغيل على طلبات. بدل إنشاء مواقع مخزون وهمية لمجرد مطابقة عرض المنصة، يمكن ربط المنافذ الافتراضية المعتمدة بالفرع الذي يتولى التجهيز فعليًا. ويحتاج كل ربط إلى مسؤول محدد، وتشكيلة واضحة، ومصدر مخزون، وقواعد خدمة، واستجابة مختبرة للإلغاء أو الإغلاق المؤقت.

لا تقتصر هذه البنية على الصيدليات. يستطيع تجار التجزئة ضبط تشكيلة كل فرع، ويمكن للموزعين إتاحة نقاط تجهيز مختارة، كما تستطيع المصانع التي تبيع مباشرة للمستهلك فصل مخزون المنتجات النهائية القابل للبيع عن مخزون الإنتاج. ويمكن لشركات الخدمات التي تبيع باقات أو منتجات معيارية ضبط أسعار القناة. تستفيد الإدارة المالية من وضوح ملكية السعر، بينما تستفيد فرق المخازن وسلسلة الإمداد من ربط الوعد الإلكتروني برصيد محدد بدل الاعتماد على إجمالي متفائل لكل الشبكة.

للموارد البشرية والامتثال دور أيضًا. يجب تحديد من يعتمد تغييرات الأسعار، ومن يدير بيانات الدخول، ومن يراجع العمليات الفاشلة، ومن يتعامل مع استثناءات الفروع خارج ساعات العمل. يساعد فصل المسؤوليات على منع تحول الاتصال التقني إلى عملية بلا مالك. وعند التوسع إلى فروع جديدة، تكون الحوكمة القابلة للتكرار أهم من سرعة إضافة منافذ لا تتطابق فيها الأسعار والمخزون والمسؤوليات.

ما الذي سيأتي قريبًا، وما الذي لم يُطرح بعد؟

تتضمن خارطة الطريق مرحلتين منفصلتين. قريبًا، يُخطط لنشر عروض SofTech مباشرة إلى طلبات. توثق طلبات بالفعل واجهات لإنشاء العروض وتعديلها وإيقافها والتحقق من حالتها. وتدعم حالات استخدام العروض الرسمية الاتجاه التقني، لكن وظيفة SofTech يجب أن تكمل التطوير والاختبار والاعتماد قبل تقديمها كخدمة متاحة.

قريبًا، يُخطط لاستقبال طلبات Talabat آليًا داخل نقطة البيع في SofTech. تشرح وثائق واجهة الطلبات الإشعارات الفورية وإمكانية الربط بنظام التجهيز لدى الشريك. والقيمة المخططة داخل SofTech هي إنشاء مسار مضبوط للمعاملة داخل نقطة البيع بدل إعادة إدخال الطلب يدويًا. وحتى اكتمال الإصدار والاختبار والاعتماد، تظل هذه وظيفة قادمة فقط.

تضيف المرحلتان ضوابط جديدة. تحتاج العروض إلى تواريخ سريان وأصناف مؤهلة ونطاق فروع واعتماد للخصم ومراجعة بعد النشر. وتحتاج الطلبات الواردة إلى منع التكرار وربط الضرائب ووسيلة الدفع وحجز المخزون وقواعد الاستبدال والإلغاء والإيصال ومطابقة التسويات. الأتمتة تنقل العمل ولا تلغي المسؤولية.

قائمة عملية قبل التشغيل

1. اعتماد مصدر الحقيقة. حدد قائمة أسعار SofTech وموقع المخزون ومعادلة الكمية المتاحة ومعرفات الأصناف المستخدمة لكل منفذ.
2. التحقق من مطابقة الأصناف. اختبر SKU أو GTIN ووحدات القياس والأسماء والضرائب وأحجام العبوات والأصناف الموقوفة والتكرارات.
3. ضبط هامش منطقي. حدد الحد الصفري وفق سرعة الطلب وتأخر المعاملات والحجوزات وتكلفة الإلغاء، وليس بالتخمين.
4. اختبار ربط كل فرع. تأكد من أن كل منفذ افتراضي يسحب من الفرع الفعلي المقصود، وأن تغير المخزون يؤثر في المنفذ الصحيح فقط.
5. تحديد مسؤولية الاستثناءات. عيّن من يراجع فشل المصادقة ورفض العمليات واختلاف الأسعار والمخزون السالب والتحديثات القديمة.
6. إجراء المطابقة بعد الإطلاق. قارن قيم ERP بنتائج طلبات يوميًا في البداية، ثم استخدم دورية مبنية على المخاطر ومدعومة بالتنبيهات.
7. فصل بوابات المرحلة القادمة. تحتاج العروض والطلبات إلى اختبارات قبول وضوابط مالية ومراجعة لنقطة البيع وتدريب وخطة تراجع مستقلة.

ماذا يعني ذلك للنمو في مصر وأسواق MENA؟

يقدم التكامل نمطًا قابلًا للتكرار للشركات المصرية التي تريد النمو عبر منصات البيع من دون بناء نظام تشغيلي ثانٍ ومنفصل. تظل حوكمة المنتج والسعر والمخزون داخل ERP، بينما تتلقى القناة الجزء المعتمد الذي تحتاج إليه. ويمكن تطبيق هذا النمط في التجزئة والتوزيع والتصنيع الاستهلاكي ونماذج الفروع الأخرى، مع مراجعة قواعد الضرائب والتراخيص والمنتجات والتجهيز لكل قطاع.

كما يوفر نقطة بداية أفضل للشركات التي تدرس التوسع إلى عُمان أو الخليج: فصل إعدادات كل دولة عن منطق التكامل المشترك. لا ينبغي نسخ الأسعار أو الضرائب أو الوحدات أو قواعد المنافذ أو سياسات المخزون المصرية إلى سوق آخر. ما يمكن إعادة استخدامه هو المنهج المنضبط: ملكية البيانات الرئيسية، وربط المنافذ، وهوامش الأمان، والمراقبة، والمطابقة، ثم تكييف الإعدادات التجارية والامتثال بمراجعة محلية.