نقل ضيوف المطعم إلى طاولة أخرى: ماذا يحدث لطلبهم المفتوح؟

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

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

افصلوا هوية الطلب عن رقم الطاولة

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

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

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

هل اختيار الطاولة للاطلاع أم لتأكيد إشغالها؟

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

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

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

نبهوا قبل أن يتحول النقل إلى دمج

توثق Odoo نتيجتين لإجراء Transfer/Merge: اختيار طاولة متاحة ينقل الضيوف وطلباتهم، بينما اختيار طاولة مشغولة يدمج الضيوف وطلباتهم. لذلك فإن اختيار وجهة خاطئة أثناء ازدحام الخدمة قد يغير أكثر من المكان.

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

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

افصلوا تغيير المكان عن الدفع وتحضير الطعام

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

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

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

اختبروا قصة الخدمة لا رسم الصالة وحده

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

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

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