تفاصيل المشروع

Deli منصة SaaS متعددة المطاعم، مبنية بـ Laravel كـ REST API بإصدارات، بواجهات منفصلة لإدارة المنصة، وأصحاب المطاعم وموظفيها، والكاشير، والعملاء. تُعزل بيانات كل مطعم تلقائيًا عبر Global Scope، ويُدار الوصول بالأدوار والصلاحيات مع مصادقة مبنية على Passport. يدير المطعم قائمته بالتصنيفات والأصناف والأحجام والإضافات والأصناف متغيرة السعر (Market Price)، إلى جانب العروض والكوبونات والضرائب والبانرات والطاولات ومناطق التوصيل وأسباب الإلغاء. ويستقبل الكاشير طلبات الصالة والتوصيل والاستلام، بينما يسجّل العميل دخوله برمز تحقق (OTP) عبر SMS، ويتصفح القائمة، ويحفظ أصنافه المفضلة، ويطلب، ويقيّم الأصناف والمطاعم. قلب النظام هو سير العمل في المطبخ: يُقسَّم كل طلب تلقائيًا إلى طلبات فرعية حسب قسم المطبخ، كالشرقي والغربي والآسيوي والبار، فيصل كل قسم إلى أصنافه فقط، مع شاشة رئيسية تتابع الطلب كاملًا. وتصل الطلبات إلى شاشات المطبخ والطابعات لحظيًا عبر أحداث Pusher، كما توفّر المنصة تقارير صافي الربح والأداء التشغيلي وسجلًا كاملًا للنشاط (Activity Log).

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

بنيت إنشاء الطلبات وتعديلها كـ Pipelines في Laravel: التحقق، ثم إنشاء الطلبات الفرعية لكل قسم، ثم حساب الإجمالي، ثم طلبات الطباعة؛ فتبقى كل خطوة مستقلة وقابلة لإعادة الاستخدام والاختبار. وعند تعديل الطلب، تقارن خدمة مخصصة الطلب قبل التعديل وبعده، وترسل لكل قسم الأصناف المعدّلة والملغاة فقط. أما الطباعة، فيرسل الـ Back-End أحداث Pusher إلى Dile Printing، تطبيق سطح المكتب الذي يدير طابعات المطعم، ويحوّل الإيصالات إلى صور مناسبة للطابعات الحرارية، مع Queued Jobs لطباعة الطلبات الفرعية. ويعمل إرسال الرسائل النصية عبر واجهة موحدة لمزوّدي الخدمة (SMS Misr وTwilio)، فيمكن تبديل المزوّد دون المساس بمنطق العمل.