برنامج فودكس للمطاعم: كيف تجهز تكامل الطلبات مع نقاط البيع؟

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

ما دور فودكس في رحلة طلب المطعم؟

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

إليك أهم وظائف فودكس خلال رحلة الطلب:

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

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

لذلك، لا يعني استخدام فودكس أن جميع تطبيقات توصيل المطاعم ترتبط به تلقائيًا؛ إذ يجب التأكد من توفر التكامل المطلوب وتفعيله واختباره.

البيانات المطلوبة قبل تكامل POS

للمقارنة بين مسؤوليات نقطة البيع وإدارة الطلبات قبل تحديد واجهات الربط، راجع الفرق بين إدارة الطلبات ونقطة البيع التقليدية.

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

1. عناصر التنفيذ والمعايير العملية

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

2. تفعيل استقبال طلبات API على فودكس

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

وتشمل خطوات التجهيز:

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

3. مراجعة صلاحيات الربط وحماية البيانات

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

مطابقة الفروع والمنيو والإضافات

إذا كان المطعم يغيّر الأسعار آليًا، فراجع خطوات دمج نظام تسعير ذكي مع نقطة البيع الحالية لتقييم مصدر السعر واتجاه تحديثاته قبل ربط قنوات الطلب.

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

1. مطابقة معرفات الفروع بين Foodics وتطبيقات التوصيل

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

2. مطابقة المنتجات والأقسام في منيو Foodics

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

3. مطابقة مجموعات الإضافات والخيارات

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

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

4. اختبار مزامنة المنيو والأسعار حسب الفرع

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

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

5. اختبار مطابقة إضافات المنيو والخيارات الإلزامية

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

الإضافات أو Modifiers قد تكون مدفوعة، مثل إضافة جبن، أو مجانية، مثل اختيار طريقة التحضير. وهي تختلف عن الملاحظات النصية الحرة؛ إذ يمكن أن تحتوي على معرّفات وخيارات وقواعد كمية وأسعار. وتوضح وثائق Foodics الخاصة بإعداد خيارات الإضافات وجود حقول للحد الأدنى والأقصى والخيارات المجانية والافتراضية والمستبعدة وتقييد تكرار الخيار. لا يعني وجود هذه الحقول أن كل تطبيق توصيل أو موصل يدعمها بالطريقة نفسها.

نموذج جدول Mapping لمطابقة المجموعة والخيار

أعدّ سجل مطابقة لكل صنف وفرع وقناة قبل تفعيل المنيو. لا تعتمد على اسم «صوص إضافي» وحده، فقد تستخدم قناتان الاسم نفسه لمعرّفين مختلفين. يوضح الجدول حقول التحقق العملية، ولا يمثل شاشة أو وظيفة مؤكدة في أي منتج بعينه.

مصفوفة QA للإضافات قبل تشغيل المنيو

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

تشخيص فقد الخيار بعد استلام الطلب

1. ابدأ من الأصل: احفظ رقم الطلب لدى تطبيق التوصيل والصنف والخيارات المختارة دون مشاركة بيانات عميل حساسة.
2. قارن المعرّفات: راجع خيار الإضافة في إعدادات Foodics وسجل طبقة الربط ونتيجة إنشاء الطلب، إذا أتاحها المزود.
3. حدد موضع الخطأ: هل غاب الخيار من بيانات الإرسال، أم رُفضت العملية داخل POS، أم وصلت البيانات كاملة ولم تظهر على تذكرة المطبخ؟
4. صحح السبب الأصلي: أصلح معرّفًا أو قاعدة Min/Max أو إعداد استقبال ثم حدّث المنيو بالطريقة التي يوثقها المورد؛ لا تنشئ خيارًا افتراضيًا قد يغيّر اختيار العميل.
5. أعد الاختبار بأمان: تحقق من عدم وجود طلب سابق قبل إعادة الإرسال، ثم نفّذ طلبًا تجريبيًا وراجع الكاشير والمطبخ والفروقات المالية.

تشرح إرشادات Foodics الرسمية لتشخيص الطلبات غير الظاهرة أمثلة لأخطاء «خيار غير صالح» و«خيار إلزامي مفقود»، وتوصي بمراجعة الاستجابة ومزامنة المنيو. هذه الأمثلة تخص المسار الموثق في Foodics Online؛ لا يجوز افتراض رمز HTTP محدد أو السلوك نفسه في كل تكامل خارجي.

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

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

إرسال الطلبات وتحديث حالاتها

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

1. نقل طلبات التوصيل إلى كاشير فودكس

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

2. تحديث حالة طلب Foodics خلال التنفيذ

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

لا تدعم جميع التكاملات الحالات نفسها أو مزامنتها في الاتجاهين، لذلك يجب الاتفاق على قائمة الحالات المدعومة قبل اعتماد التشغيل.

3. التحقق من المدفوعات والضرائب والخصومات

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

قد يفرض كل مزود ربط متطلبات مختلفة لتمثيل الأسعار والضرائب والرسوم. قارن نموذج الأسعار الشاملة وغير الشاملة للضريبة، ونوع الطلب المدفوع مسبقًا، ثم طابق الإجمالي مع Foodics قبل اعتماد التشغيل.

حالات الإلغاء وإعادة المحاولة

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

1. التعامل مع إلغاء الطلب بعد وصوله إلى فودكس

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

2. معالجة فشل إرسال الطلبات عبر API

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

3. منع تكرار طلبات التوصيل أثناء إعادة المحاولة

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

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

عند عدم ظهور الطلب في الكاشير، تنصح تعليمات استكشاف أعطال طلبات API في فودكس بمراجعة الطلبات المعلقة Pending في لوحة التحكم، ثم التحقق من جهاز الاستقبال ومزامنة البيانات لتحديد ما إذا كان الطلب وصل إلى Foodics لكنه لم يظهر على الكاشير.

جدول اختبارات تكامل جاهز

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

الجدول نموذج اختبار عام، ويجب تعديل الحالات بحسب الوظائف التي يدعمها مزود التكامل وحساب المطعم.

كيف تعتمد نتائج اختبار Foodics Integration؟

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

إليك معايير قبول التكامل:

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

ولا ينصح باعتماد نسبة نجاح أو زمن مزامنة ثابت لجميع المطاعم؛ إذ تختلف المعايير المقبولة بحسب حجم الطلبات وطبيعة القنوات واتفاقيات الخدمة.

متى تحتاج وسيط تكامل متعدد القنوات؟

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

إليك الحالات التي قد تجعل وسيط التكامل مناسبًا:

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

تقدم تطبيقات مختلفة ضمن منظومة Foodics طرقًا متعددة لتجميع طلبات التوصيل وربطها بنقاط البيع. قارن نطاق التوافق الفعلي مع حسابات الفروع، ودعم الإضافات وتحديث الحالات، ومسؤولية المراقبة والدعم، قبل إضافة وسيط جديد.

كيف تقيّم LYNNC ضمن خيارات ربط الطلبات؟

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

تقدم (منصة LYNNC لتشغيل المطاعم) خدمات لإدارة طلبات التطبيقات وتنظيم بيانات الأصناف ومتابعة التشغيل، وتعمل باعتبارها منصة SaaS تتكامل مع أنظمة نقاط البيع وليست بديلًا مستقلًا لنظام الكاشير.

وعند تقييم ربط Foodics عبر LYNNC، من المهم مراجعة العناصر التالية:

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

يمكن مراجعة تكاملات نقاط البيع لدى LYNNC لفهم الخدمات العامة المتاحة والتواصل مع الفريق للتأكد من توفر ربط Foodics وتطبيقات التوصيل المناسبة لحساب المطعم. وجود معلومات عامة عن التكاملات لا يُعد تأكيدًا بأن الربط المحدد متاح لكل عميل.

إذا كنت تقارن حلول إدارة الطلبات متعددة القنوات، ابدأ بمراجعة منصة LYNNC لتشغيل المطاعم، ثم تواصل مع فريق LYNNC للتحقق من توافق Foodics قبل أي التزام تعاقدي.

الأسئلة الشائعة عن برنامج فودكس للمطاعم وتكامل الطلبات

1. هل يجب توحيد معرفات الأصناف بين الأنظمة؟

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

2. كيف أختبر تفاصيل الإضافات في Foodics؟

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

3. كيف يتم التحقق من توافق نسخة Foodics؟

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

4. هل يشترط وجود API لربط تطبيقات التوصيل؟

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

5. هل يمكن ربط فودكس مع جاهز وهنقرستيشن؟

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

6. لماذا لا تظهر طلبات التوصيل في كاشير Foodics؟

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

7. هل تتزامن أسعار المنيو تلقائيًا بعد ربط Foodics؟

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

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