نظام إدارة المخزون بالأحداث: كيف تبنيه بـ Go للمطاعم والمتاجر في لبنان والمنطقة

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

لماذا إدارة المخزون أصعب مما تبدو؟

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

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

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

التقارير في الوقت الفعلي مع الدقة التاريخية. مديرو العمليات يحتاجون مستويات المخزون الحالية الآن. المحاسبون يحتاجون معرفة مستويات المخزون في نهاية الشهر الماضي.

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

سجل الأحداث كمصدر الحقيقة

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

• PURCHASE_RECEIVED: مخزون مضاف من توصيل مورد
• ORDER_DEDUCTION: مخزون مستهلك بطلب عميل
• TRANSFER_OUT: مخزون مرسل لموقع آخر
• TRANSFER_IN: مخزون مستلم من موقع آخر
• WASTE_RECORDED: مخزون تالف أو مُهدر
• ADJUSTMENT: تصحيح يدوي من مدير
• STOCKTAKE: جرد مادي يتجاوز الرصيد المحسوب

مستوى المخزون الحالي لأي صنف في أي موقع هو مجموع جميع الأحداث لذلك الصنف والموقع. المستويات التاريخية في أي وقت هي نفس الاستعلام مع إضافة WHERE event_time <= $3.

لماذا الإلحاق فقط أفضل من التحديثات المباشرة؟

البديل هو جدول current_stock بعمود كمية رقمية. كل حدث يحدث هذا العمود.

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

سجل الأحداث للإلحاق فقط يتجنب التنافس على مستوى الصف. كل حدث هو INSERT، لا UPDATE. INSERTs على نفس الجدول لا تتنافس مع بعضها في PostgreSQL.

تنفيذ طبقة الإسقاط في Go

طبقة الإسقاط تحافظ على جدول stock_projections بمستويات مخزون حالية محسوبة مسبقاً. خدمة Go تشترك في أحداث المخزون وتحدث الإسقاطات عند وصول الأحداث.

تحديث الإسقاط يعمل ضمن نفس معاملة قاعدة البيانات كإدراج الحدث - هذا يضمن أن الحدث وإسقاطه دائماً متسقان.

معالجة أحداث الجرد بشكل صحيح

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

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

التوسع عبر مواقع متعددة في لبنان

لمجموعات المطاعم بفروع متعددة في لبنان، النظام يحتاج التعامل مع النقل بين المواقع ومنح المكتب الرئيسي رؤية عبر جميع الفروع.

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

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

دروس من الإنتاج

نموذج سجل الأحداث أكثر تعقيداً في البناء الأولي لكنه أكثر صحة وقابلية للصيانة بكثير من تحديثات الكمية المباشرة.

جداول الإسقاط ضرورية لأداء القراءة. جمع 50,000 حدث لكل استعلام صنف وموقع بطيء جداً للاستخدام الفوري في لوحة المعلومات.

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