Korat
ميزة

كاشير المطعم وشاشة المطبخ والطلب من الطاولة

نظام طلب الطعام يبدأ من الطاولة: الزبون يمسح رمز QR فيصير داخل القائمة. والمتجر يحصل على شاشة مطبخ وفاتورة مفصّلة يوافق عليها الصندوق وطابور توصيل — من دون أن يُوثَق بسعر واحد أرسله الهاتف. مجانًا وبلا اشتراك شهري.

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

رمز الطاولة رمز أمان لمرة واحدة، لا رقم طاولة

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

الزبون الواقف أمام الطاولة ليس عضوًا في المتجر ولا مضيف جلسة لم تبدأ بعد، فهو تحت الأمان على مستوى الصف لا يستطيع قراءة جدول dining_sessions إطلاقًا، لا صفّه ولا أي صفّ. فالأمان على مستوى الصف يحكم بمن يتّصل، ولا يحكم بأن الطلب يحمل رمزًا صحيحًا. لذلك يمرّ المسح عبر join_session_by_token، وهي دالة من نوع SECURITY DEFINER تطابق الرمز على الخادم، وتجعل أول ماسح هو المضيف، وتعيد لا شيء حين لا يطابق — من دون أن تقول لماذا. فرسالة خطأ تميّز بين «رمز خاطئ» و«رمز منتهٍ» هي أداة تخمين جاهزة.

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

الطلب: خيارات وملاحظات وقائمة تعرف أنها تُغلق

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

ساعات العمل ومهلة آخر طلب وفحص السنّ للكحول

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

طابور التأكيد: لا شيء يصل إلى المطبخ قبل أن يوافق إنسان

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

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

الفاتورة الحيّة المفصّلة وتقسيمها برمز PromptPay

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

تقسيم الفاتورة: كم على كل واحد

وشاشة التقسيم تجيب عن السؤال الذي يتجادل فيه الناس فعلًا: كم عليّ أنا. يرى كل شخص مجموع أصنافه الخاصة إضافة إلى حصة متساوية من أي باقة بوفيه على الطاولة. ويمكن توليد رمز PromptPay للمبلغ، بصيغة رمز QR التايلاندية القياسية مع مجموع التحقّق CRC-16 الخاص بها.

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

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

البوفيه: باقات للفرد ومؤقّتات ورسوم الطعام المتروك

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

التوصيل والطلب الخارجي وحجوزات الطاولات

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

كل سعر يُحسب على الخادم

القاعدة التي تجعل بقية ذلك آمنًا: العميل لا يحدّد سعرًا أبدًا. تقرأ place_dining_order وplace_shop_order أسعار الأصناف وفروق الخيارات ورسم التوصيل من قاعدة البيانات وتتجاهل ما أرسله الهاتف. فحقل قادم من العميل ويُوثَق به هو خصم يمنحه العميل لنفسه. والمبدأ نفسه يغطّي التقييمات: لا يكتب تقييمًا إلا زبون تستطيع قاعدة البيانات أن تثبت أنه أكل أو طلب توصيلًا، ومتوسط النجوم يعيد حسابه مُشغِّل في قاعدة البيانات ولا يُكتب يدويًا.

إن كنت تفضّل ألا يجلس الزبون منتظرًا وأن يأخذ رقمًا فقط، فانظر الطابور. وما يُباع خارج المطبخ — سفري، منتجات، وجبات معدّة — يمرّ عبر المتجر الإلكتروني على المخزون نفسه.

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

الأسئلة الشائعة

هل يستطيع الزبون الطلب من دون مسح رمز الطاولة؟

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

أما التوصيل والطلب الخارجي فبالعكس: يُطلبان من صفحة المتجر بلا طاولة أصلًا.

ما الذي يمنع أحدهم من تصوير رمز طاولتنا والطلب لاحقًا؟

الرمز داخل QR ذو استخدام واحد ومرتبط بالجلسة التي فتحها الموظفون. وبانتهاء تلك الجلسة يتوقّف الرمز عن المطابقة ولا يقود المسح إلى شيء. ويجري الفحص داخل دالة SECURITY DEFINER في قاعدة البيانات لا في التطبيق، فلا يمكن تجاوزه بمخاطبة الواجهة البرمجية مباشرةً.

هل تذهب الطلبات إلى المطبخ مباشرةً؟

لا. كل طلب يهبط أولًا في طابور انتظار التأكيد على شاشة المطبخ، ويؤكّده الموظفون أو يرفضونه. وخطوة التأكيد تلك هي الموضع الذي تُلتقط فيه الأخطاء وسوء الاستعمال قبل أن يكلّفا طعامًا.

هل يستطيع كل شخص على الطاولة دفع حصته ببطاقته؟

لا. تحسب شاشة التقسيم ما على كل شخص — أصنافه إضافة إلى حصة متساوية من أي بوفيه — وتُسوَّى الدفعة مع المتجر. ولا يعالج Korat دفعات بطاقات منفصلة لكل شخص.

ماذا يحدث إذا طلب زبون في لحظة إغلاقنا؟

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

افتح طاولة وشاهد الحلقة كاملة

جانب الزبون وجانب لوحة التحكم هما التطبيق نفسه. ثبّته، وأنشئ نشاطًا تجاريًا، وامسح رمزك بنفسك.