المشكلة
كان Ristorante Gina، وهو مطعم للمأكولات البحرية، يدير خدمته على الورق: يكتب النُّدُل الطلبات بخط اليد، ويقرأ المطبخ والبار القسائم نفسها، وتُجمع الفاتورة عند الصندوق. أراد المالكون نظامًا واحدًا لصالة الطعام والمطبخ والمدير، مبنيًا بحيث يخدم لاحقًا أكثر من مطعم.
ما الذي بنيته
بنيت RistoFlow، وهو تطبيق ويب لإدارة المطاعم، وأعددته مع Gina بوصفه المطعم الأول.
- مخطط الصالة — طاولات مجمّعة حسب القاعة، بحالات مباشرة (شاغرة، مشغولة، طلبات قيد التنفيذ، طلبات جاهزة) وعدد الأشخاص الذي يُحدد عند فتح الطاولة.
- الطلبات من الهاتف — يُعدّ النُّدُل الطلب حسب الفئة، مع ملاحظات لكل طبق. وعند الإرسال يُقسم تلقائيًا بين المطبخ والبار، فلا يرى كل قسم إلا عمله.
- شاشة المطبخ — شاشة تتحدث كل 5 ثوانٍ، وتنقل كل طلب من «مُرسل» إلى «قيد التحضير» ثم «جاهز» ثم «مُقدَّم»، وتُبرز التأخيرات، وتطبع إيصالًا بعرض 72 مم، تلقائيًا عند الحاجة.
- الفواتير — إجمالي الطاولة مع رسم الخدمة، وفاتورة مبدئية قابلة للطباعة، والإغلاق. منذ الإصدار 1.5.0 لا تظهر الأسعار إلا للمدير الذي يغلق الفاتورة، لا للنُّدُل ولا لطاقم المطبخ.
- محرر القائمة والتقارير — الفئات والأسعار (وأيضًا لكل 100 غ)، ووسم الأطباق بأنها نفدت فورًا، والإيرادات اليومية وعدد الزبائن والأطباق الأكثر مبيعًا.
- أربعة أدوار ومطاعم كثيرة — مسؤول المنصة والمدير والنادل والمطبخ. لكل مطعم مستخدموه وبياناته، محفوظة بشكل منفصل.
- حزمة الخادم المحلي — مثبّت يضع التطبيق مع قائمة Gina وطاولاته الحقيقية على حاسوب داخل المطعم، مع سكربت للنسخ الاحتياطي اليومي.
التقنيات المستخدمة
PHP 8 وMySQL مع PDO، وJavaScript خالصة دون مكتبات خارجية. نقطة نهاية API واحدة تتولى كل الاستدعاءات. جلسات مع رموز CSRF وكلمات مرور مُجزّأة (hashed). حُمّلت قائمة Gina وقائمة النبيذ في 9 فئات.
لماذا بهذه الطريقة
أبقيت التطبيق خاليًا من الاعتماديات واستخدمت الاستطلاع الدوري البسيط (polling) بدلًا من websockets، ليعمل على استضافة مشتركة عادية. وسهّل الاختيار نفسه نقله إلى خادم محلي: تستمر الطلبات والفواتير في العمل عبر شبكة Wi-Fi في المطعم حتى عند انقطاع الإنترنت.
