تصميم نظام إدارة مطعم متكامل لمنطقة MENA: من نقطة البيع إلى التقارير

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

هذه البنية تقف خلف RTYLR، منصة commerce التابعة لـ Voxire للمطاعم وشركات التجزئة. RTYLR يعمل في مواقع تتراوح من مقاهٍ ذات فرع واحد في بيروت إلى سلاسل متعددة الفروع عبر الخليج.

المكونات الأساسية

نظام إدارة مطاعم متكامل يتضمن مكونات أكثر مما تقدر معظم الفرق الهندسية في البداية:

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

نظام عرض المطبخ (KDS): يعرض الطلبات لموظفي المطبخ في قائمة التحضير. الطلب يظهر على KDS لحظة تقديمه.

نظام المخزون: يتتبع مستويات المخزون في الوقت الفعلي. كل عنصر مُباع يُنقص المكونات ذات الصلة.

إدارة الطاولات: لعمليات تناول الطعام داخل المطعم، تتتبع حالة الطاولة وحجم المجموعة ومدة الطلب.

لوحة تحكم المالك: واجهة ويب للمشغلين لعرض المبيعات الحية وإدارة القوائم وتكوين النظام.

أين تصبح قرارات البنية صعبة

ثلاث خصائص تخلق أكبر توتر في التصميم: التشغيل دون اتصال، والتنسيق في الوقت الفعلي، واتساق المواقع المتعددة.

التشغيل دون اتصال يعني أن طرفية نقطة البيع يجب أن تقبل الطلبات وتعالج مدفوعات نقدية وتطبع إيصالات بدون اتصال بالشبكة. هذا يتطلب قاعدة بيانات SQLite محلية على كل طرفية بالقائمة الكاملة والإعدادات.

التنسيق في الوقت الفعلي يعني أن KDS يجب أن يرى الطلب في غضون ثوانٍ من تقديمه. هذا يتطلب اتصالات WebSocket من KDS إلى الخلفية.

aتساق المواقع المتعددة يعني أن مالك السلسلة يمكنه رؤية مستويات مخزون دقيقة وأرقام مبيعات عبر جميع الفروع من لوحة تحكم واحدة.

بنية المزامنة

أهم قرار تصميمي في النظام بأكمله هو كيفية مزامنة حالة الطرفية مع الخلفية.

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

type SyncRequest struct {
    TerminalID    uuid.UUID `json:"terminal_id"`
    LocalSeq      int64     `json:"local_seq"`
    LastServerSeq int64     `json:"last_server_seq"`
    PendingEvents []Event   `json:"pending_events"`
}

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

تتبع المخزون

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

CREATE TABLE inventory_items (
  id          UUID PRIMARY KEY,
  location_id UUID NOT NULL,
  name        TEXT NOT NULL,
  unit        TEXT NOT NULL,
  quantity    NUMERIC(10,3) NOT NULL,
  low_stock_threshold NUMERIC(10,3)
);

CREATE TABLE menu_item_recipes (
  menu_item_id      UUID NOT NULL,
  inventory_item_id UUID NOT NULL,
  quantity_used     NUMERIC(10,4) NOT NULL,
  PRIMARY KEY (menu_item_id, inventory_item_id)
);

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

نظام عرض المطبخ

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

إذا انفصل WebSocket، يستمر KDS في عرض آخر حالة معروفة ويُظهر تحذير اتصال لموظفي المطبخ. عند إعادة الاتصال، يطلب قائمة الانتظار الحالية الكاملة ويُعيد المزامنة.

التقارير التي تُستخدم فعلاً

تقارير نهاية اليوم والمقارنات بين الفترات هي الميزات الأكثر استخداماً من مشغلي المطاعم في لبنان والخليج. أكثر التقارير فائدة في RTYLR:

توزيع المبيعات بالساعة: يُظهر ساعات الذروة وما دونها. يُستخدم لقرارات التوظيف.

أداء العناصر: الإيرادات والكميات لكل عنصر في القائمة. يُستخدم لتحسين القائمة.

معدل دوران الطاولات: متوسط الوقت لكل طاولة لعمليات تناول الطعام داخل المطعم.

تحليل الإلغاء والاسترداد: معدلات الإلغاء غير العادية تشير إلى مشاكل في تدريب الموظفين أو مشاكل في النظام.

دروس من عمليات RTYLR

أربعة دروس شكَّلت البنية بعد عام من التشغيل الإنتاجي:

أولاً، معدل التعارض في المزامنة أقل مما توقعنا لكن عواقب التعارضات الفائتة أكبر مما توقعنا. سعر قائمة مطبَّق في الوقت الخطأ بسبب تعارض مزامنة يُنتج فاتورة خاطئة.

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

ثالثاً، كل مطعم يريد تقارير مخصصة. بناء طبقة استعلام تقارير مرنة يمكن للمشغلين تكوينها يستحق الاستثمار.

رابعاً، وضع عدم الاتصال ليس بديلاً، إنه وضع التشغيل الأساسي لكثير من المطاعم. صمِّم أولاً لحالة عدم الاتصال، وأضف الاتصال كتحسين.