الإجابة المختصرة: ربط المطعم بتطبيقات التوصيل والطلب الإلكتروني يتم عادة عبر واجهات برمجة التطبيقات (API): تنتقل الطلبات من المنصة إلى نظام المطعم تلقائيًا، وتعود حالة الطلب وتوفر الأصناف من النظام إلى المنصة، ثم تُسوّى المبالغ والعمولات محاسبيًا. الربط الجيد يلغي إعادة إدخال الطلبات يدويًا، ويخصم المخزون حسب الوصفة، ويُظهر ربحية قناة التوصيل منفصلة عن الصالة.
لماذا أصبح الربط مع قنوات الطلب أولوية؟
التوصيل لم يعد قناة جانبية في السوق السعودي. فبحسب بيانات الهيئة العامة للنقل، تجاوز عدد طلبات التوصيل 118 مليون طلب في الربع الأول من 2026 بنمو 49% عن الفترة نفسها من العام السابق، ثم تجاوز 132 مليون طلب في الربع الثاني من 2026 بنمو 30.5%. واستحوذت منطقة الرياض على نحو 44% من الطلبات، تلتها منطقة مكة المكرمة بنحو 22%، ثم المنطقة الشرقية بنحو 16%.
مع هذا الحجم، يعمل كثير من المطاعم بشاشة أو جهاز لوحي منفصل لكل منصة، ويعيد الموظف كتابة كل طلب في الكاشير. النتيجة: أخطاء في الطلبات، وتأخير في المطبخ، ومخزون لا يعكس الحقيقة، وتقارير لا تفرق بين ربح الصالة وربح التوصيل.
والمشكلة لا تتوقف عند المطبخ؛ فعندما تُسجَّل طلبات التوصيل يدويًا أو بشكل مجمّع في نهاية اليوم، يصعب على المحاسب مطابقة كشوف التسوية الواردة من المنصات مع المبالغ المحولة إلى الحساب البنكي، وتختلط مبيعات القنوات المختلفة في رقم واحد. ومع تعدد الفروع، تتضاعف هذه الفروقات، ويصبح السؤال «هل التوصيل مربح فعلًا؟» بلا إجابة دقيقة. الربط الآلي هو ما يحوّل هذه البيانات المتفرقة إلى تقارير يمكن الاعتماد عليها في قرارات التسعير والتوسع.
كيف يعمل الربط عبر API ببساطة؟
واجهة برمجة التطبيقات (API) هي «لغة متفق عليها» بين نظامين. المنصة تنشر توثيقًا يحدد شكل البيانات وطريقة إرسالها، ونظام المطعم يتحدث بهذه اللغة. وغالبًا تُستخدم آلية الإشعارات الفورية (Webhooks)، بحيث ترسل المنصة الطلب إلى نظامك لحظة إنشائه بدلًا من أن يسأل نظامك عنه كل دقيقة.
أنماط الربط الشائعة
| النمط | كيف يعمل | مناسب لـ |
|---|---|---|
| إدخال يدوي | جهاز المنصة في المطعم، والموظف يعيد إدخال الطلب في الكاشير | بداية النشاط وحجم طلبات صغير |
| ربط مباشر عبر API | نظام المطعم يتصل بواجهة المنصة مباشرة | المطاعم ذات الحجم المرتفع على منصة أو منصتين |
| طبقة وسيطة | خدمة وسيطة تجمع الطلبات من عدة منصات وترسلها لنظام واحد | السلاسل التي تعمل على منصات متعددة |
| متجر طلب خاص | موقع أو تطبيق باسم المطعم يرسل الطلبات للنظام | المطاعم التي تريد قناة مباشرة مع عملائها |
ما البيانات التي تنتقل في الاتجاهين؟
من المنصة إلى نظام المطعم
- رقم الطلب ووقته والفرع المستهدف.
- الأصناف والكميات والإضافات والملاحظات الخاصة.
- الأسعار والخصومات والعروض المطبقة.
- طريقة الدفع (مدفوع مسبقًا أو عند الاستلام).
- بيانات التسوية الدورية: إجمالي المبيعات والعمولات والرسوم والمبالغ المحولة.
من نظام المطعم إلى المنصة
- قبول الطلب أو رفضه، والوقت المتوقع للتحضير.
- تحديث حالة الطلب: قيد التحضير، جاهز للاستلام.
- توفر الأصناف: إيقاف صنف نفد مخزونه بشكل مؤقت.
- قائمة الطعام والأسعار، إن كانت المنصة تسمح بمزامنتها من النظام.
داخل نظام المطعم بعد استلام الطلب
- إرسال الطلب إلى شاشة أو طابعة المطبخ.
- خصم المواد الخام من المخزون حسب الوصفة.
- تسجيل المبيعات تحت قناة «توصيل» ومركز تكلفة الفرع.
- تسجيل عمولة المنصة كمصروف عند استلام كشف التسوية، ومطابقة المبلغ المحوّل مع البنك.
احسب هامش التوصيل قبل أن تتوسع فيه
المثال التالي توضيحي بافتراض نسبة عمولة 25% من السعر قبل الضريبة؛ استخدم النسبة الواردة في عقدك الفعلي:
| البند | الصالة (ريال) | التوصيل (ريال) |
|---|---|---|
| سعر الوجبة قبل الضريبة | 33.91 | 33.91 |
| تكلفة المكونات والتغليف | 12.06 | 12.06 |
| عمولة المنصة (افتراضية 25%) | 0.00 | 8.48 |
| الهامش الإجمالي للطبق | 21.85 | 13.37 |
الطبق نفسه قد يفقد قرابة 40% من هامشه في قناة التوصيل. لذلك يعتمد كثير من المطاعم أسعارًا مختلفة للتوصيل، أو قائمة مختصرة لأصناف أعلى ربحية، وهذا القرار يحتاج بيانات دقيقة من نظام مرتبط لا تقديرات.
أسئلة يجب أن تطرحها على مزود النظام والمنصة
- هل لدى المنصة واجهة API متاحة للمطاعم أو لمزودي الأنظمة؟ وما شروط الحصول على مفاتيح الوصول وبيئة الاختبار؟
- هل الربط يدعم استقبال الطلبات فقط أم يشمل تحديث الحالة والتوفر والقائمة؟
- كيف تُطابق الأصناف؟ كل صنف في المنصة يجب أن يقابله صنف ووصفة في نظامك، بما فيها الإضافات.
- ماذا يحدث عند انقطاع الاتصال؟ هل تُعاد محاولة إرسال الطلب؟ وكيف يُنبه الموظف؟
- كيف تصل بيانات التسوية والعمولات؟ عبر API أم ملفات دورية؟ وهل يمكن استيرادها محاسبيًا؟
- من يصدر الفاتورة الضريبية للعميل النهائي في نموذج عملك؟ ارجع إلى عقد المنصة ومستشارك الضريبي، وتأكد أن النظام يسجلها بما يتوافق مع الفوترة الإلكترونية.
- ما البيانات الشخصية التي تصلك عن العميل؟ وكيف تُحفظ وتُحمى وفق الأنظمة المعمول بها؟
- من يتحمل صيانة الربط عند تحديث المنصة لواجهتها؟
خطوات تنفيذ مشروع الربط
- حصر القنوات: اكتب قائمة بكل منصة تعمل عليها، وعدد الطلبات الشهرية من كل منها، والفروع المشاركة.
- توحيد قائمة الأصناف: اعتمد اسمًا ورمزًا واحدًا لكل صنف وإضافة في النظام، ثم اربطه بما يقابله في كل منصة.
- توثيق الوصفات: بدونها لن يخصم الربط المخزون بدقة مهما كانت التقنية متقدمة.
- الحصول على التوثيق الفني: اطلب من المنصة توثيق الـ API وبيئة الاختبار وشروط الاعتماد.
- التطوير والاختبار: جرّب سيناريوهات الطلب العادي والمعدل والملغى والمرتجع، وانقطاع الاتصال، قبل التشغيل الفعلي.
- التشغيل التجريبي في فرع واحد: راقب الطلبات أسبوعًا أو أسبوعين، ثم عمّم على بقية الفروع.
- المتابعة الشهرية: طابق تقارير المنصة مع النظام والبنك، وراجع ربحية كل قناة، وعدّل الأسعار أو القائمة بناءً على النتائج.
أخطاء شائعة يجب تجنبها
- ربط الطلبات دون ربط الإضافات: فيظهر الطلب في المطبخ ناقصًا، ولا يُخصم مخزون الإضافات.
- تسجيل المبيعات بالصافي بعد العمولة: فتختفي العمولة من التقارير ولا تعرف تكلفة القناة الحقيقية.
- إهمال الطلبات الملغاة والمرتجعة: وهي من أكثر أسباب الفروقات بين تقارير المنصة وحساباتك.
- الاعتماد على شخص واحد يعرف طريقة الربط: وثّق الإعدادات والصلاحيات ليستمر العمل عند غيابه.
ما الذي يعنيه هذا لأصحاب المطاعم والمقاهي في السعودية؟
- نمو الطلبات بعشرات الملايين كل ربع يعني أن إعادة الإدخال اليدوي ستصبح عنق زجاجة في ساعات الذروة.
- تركّز الطلبات في الرياض ومكة المكرمة والشرقية يجعل السلاسل في هذه المناطق أكثر حاجة للربط الآلي.
- الربط لا يتعلق بالسرعة فقط، بل بدقة المخزون وفصل ربحية كل قناة.
- ابدأ بتنظيف بياناتك: قائمة أصناف موحدة ووصفات موثقة، فهذا شرط أي ربط ناجح.
كيف يمكن أن يساعدك Riv-ERP؟
يضم Riv-ERP نقاط البيع والمخزون متعدد المستودعات والمحاسبة ومراكز التكلفة في نظام واحد، وهي الأساس الذي يحتاجه أي ربط مع قنوات الطلب: أصناف موحدة، ووصفات، وحسابات منفصلة لكل قناة وفرع. ولدى Riv-ERP تكامل حصري مع متاجر سلة وزد للتجارة الإلكترونية. وفي توصيل الطعام، Riv-ERP مربوط مع هنقرستيشن وجاهز وكيتا ومرسول: تصل الطلبات إلى النظام تلقائياً، ويُخصم المخزون حسب الوصفات، فلا حاجة لإعادة إدخال الطلبات يدوياً. ولأي منصة أخرى يمكن للفريق دراسة الربط عبر API وبناء حلول مخصصة بخبرة في .NET وC# وSQL Server. اطلب عرض سعر وشغّل الربط مع تطبيقات التوصيل.
لأصحاب المطاعم: تعرّف على برنامج Riv-ERP للمطاعم والكافيهات المربوط مع هنقرستيشن وجاهز وكيتا ومرسول.
مقالات ذات صلة
الأسئلة الشائعة
ما المقصود بربط المطعم بتطبيقات التوصيل عبر API؟
هو اتصال برمجي بين نظام المطعم والمنصة، تصل من خلاله الطلبات تلقائيًا إلى الكاشير والمطبخ، وتعود منه حالة الطلب وتوفر الأصناف إلى المنصة، دون إعادة إدخال يدوي.
هل كل تطبيقات التوصيل تتيح الربط المباشر؟
لا تتيح كل المنصات واجهاتها للجميع، وبعضها يشترط اعتماد مزود النظام أو حجم طلبات معين، لذلك يجب السؤال عن شروط الوصول وبيئة الاختبار قبل أي التزام.
كيف تُسجل عمولة المنصة في المحاسبة؟
تُسجل المبيعات بقيمتها، ثم تُسجل العمولة والرسوم كمصروف عند استلام كشف التسوية، ويطابق صافي المبلغ المحول مع كشف البنك، مع مراعاة ضريبة القيمة المضافة على فاتورة العمولة.
هل يخصم الربط المخزون تلقائيًا؟
يحدث ذلك عندما يكون كل صنف في المنصة مطابقًا لصنف ووصفة في النظام؛ عندها يخصم كل طلب توصيل المواد الخام كما يحدث في طلبات الصالة.
هل يمكن لـ Riv-ERP الربط مع منصة التوصيل التي أستخدمها؟
نعم، Riv-ERP مربوط مع هنقرستيشن وجاهز وكيتا ومرسول، وتتزامن الطلبات والمخزون تلقائياً. وإن كنت تستخدم منصة أخرى، يدرس فريق Riv-ERP الربط معها عبر API بحسب ما تتيحه من توثيق وصلاحيات.
المصادر: الاقتصادية – 132 مليون طلب توصيل في الربع الثاني 2026، المدينة – 118 مليون طلب توصيل في الربع الأول 2026.
