ماذا يعني فعلاً أن الكاشير «يعمل بدون إنترنت»
ادّعاء العمل دون إنترنت سهل، وبناؤه صعب. إليك ما يجب أن يستمر الصندوق في فعله بلا اتصال، وما لا يستطيع فعله، وكيف يلحق الطابور بأمان بعد عودة الشبكة.
كل نظام كاشير سحابي يقول إنه يعمل بدون إنترنت. وقليل جداً منها يشرح ما الذي تغطيه هذه الجملة، والفجوة بين الادّعاء والسلوك لا تُكتشف إلا في أسوأ ليلة في السنة.
العمل دون إنترنت مسألة طابور، لا مسألة شاشة
أي تطبيق يستطيع تخزين القائمة وعرض شاشة بلا اتصال. هذا هو النصف السهل. النصف الصعب هو ما يحدث للعشرين طلباً وأربعة المرتجعات والوردية المُقفلة التي أُنشئت أثناء انقطاع الخط.
هذه ليست شاشات. هذه وقائع تعتمد عليها أرقام أشخاص آخرين — المخزون، والمطبخ، والدفاتر، ودرج الكاشير. وإعادتها بالترتيب الصحيح، مرة واحدة بالضبط، هي المشكلة الهندسية كلها.
ما يجب أن يستمر الصندوق في فعله
بلا إنترنت، على نقطة البيع أن تظل قادرة على:
- فتح وردية وتسجيل رصيد افتتاحي.
- عرض القائمة كاملة بأسعارها وإضافاتها وأحجامها ووجباتها المجمّعة.
- استقبال الطلبات وتعليقها وتقسيم الفواتير وتطبيق الخصومات وأكواد العروض.
- تحصيل الدفع النقدي وطباعة الإيصال على طابعة موصولة محلياً.
- الإلغاء والمرتجع بالقواعد والاعتمادات نفسها.
- الاستمرار في حساب الدرج حتى يوازن الإقفال.
هذا مطعم يعمل. ولا شيء في هذه القائمة يحتاج خادماً ليكون صحيحاً.
وما لا يستطيع العمل فعلاً
الصراحة هنا ميزة لا ضعف:
- الدفع بالبطاقات والدفع الإلكتروني. اعتماد البوابة يحتاج البوابة. فإمّا نقداً، وإمّا بالبطاقة بعد عودة الخط.
- العرض اللحظي عبر الفروع. مخزون فرع آخر واقعة تعيش على الخادم.
- أي شيء يجب أن يراه جهاز ثانٍ فوراً. شاشة مطبخ على الشبكة المحلية نفسها يمكن أن تُخدَم، أما هاتف على بيانات الجوال فلن يُخبره صندوق بلا اتصال بتذكرة جديدة.
النظام الذي يدّعي أن كل ذلك يعمل دون إنترنت إمّا مخطئ وإمّا يعيد تعريف كلمة «دون إنترنت».
كيف تُجعل عملية اللحاق آمنة
عند عودة الاتصال، لا يعيد الجهاز الإرسال ببساطة. كل إجراء كُتب محلياً كسجل غير قابل للتعديل لحظة حدوثه، ويحمل:
| الحقل | لماذا يوجد |
|---|---|
clientActionId | معرّف فريد يُولَّد على الجهاز — هوية الإجراء |
deviceId | أي صندوق أنشأه |
actionType | إنشاء طلب، تحصيل دفعة، إقفال وردية… |
payloadJson | الإجراء كاملاً، مجمَّداً بحالته وقت حدوثه |
localCreatedAt | لإعادة تشغيل الإجراءات بالترتيب الذي وقعت به فعلاً |
يخزّن الخادم هذه السجلات بمفتاح فريد على (deviceId, clientActionId). فإذا وصل الإجراء نفسه مرتين — واي فاي متقطع، أو إعادة تشغيل التطبيق، أو محاولة متعجّلة — يُتعرَّف على الثاني ويُعاد نتيجة الأول بدل إنشاء طلب ثانٍ. والمدفوعات تحمل مفتاح تكرار للسبب نفسه: إعادة المحاولة لا يمكن أن تخصم مرتين.
وتتباعد المحاولات تدريجياً بدل إرهاق الاتصال، وما يفشل بعد الحد الأقصى للمحاولات يُوضع في قائمة معلّقة يراها المدير ويعالجها، بدل أن يختفي بصمت.
حين يختلف صندوقان
هذا هو السؤال الذي يستحق أن تطرحه على أي مورّد. صندوقان ينقطعان. كلاهما يبيع آخر خمس حصص من طبق اليوم. ثم يعودان معاً.
لا توجد إجابة سحرية — الحصص غير موجودة. المهم أن يكون سلوك النظام محدَّداً وواضحاً وأن يُخبرك:
- المخزون الذي سيصبح سالباً يُرفض برسالة قابلة للتنفيذ، لا يُقبل بصمت.
- حالة الطلب لا تتحرّك إلا عبر انتقالات صحيحة، فلا تُعاد تذكرة «قُدِّمت» بسبب وصول متأخر.
- الدفعة الأكبر من إجمالي الطلب تُرفض.
- حالة الطاولة تأخذ نسخة الخادم المرجعية، لأن شخصين لا يجلسان على الطاولة ٦.
ستضطر لتعويض طبق. لكنك ستعرف لحظة وصول التعارض، بدل اكتشاف سطر مخزون سالب بعد ثلاثة أسابيع.
اختبار الدقيقة الواحدة
قبل التعاقد مع أي جهة، افعل هذا في العرض التوضيحي: ضع التابلت في وضع الطيران، وسجّل أربعة طلبات، وارتجع واحداً، وأقفل الوردية، ثم أعد الاتصال. بعدها راجع ثلاث شاشات — المخزون، وسجلّ المطبخ، ومبيعات اليوم — وتأكد أن الطلبات الأربعة موجودة، مرة واحدة لكل منها، بالترتيب الصحيح، والمرتجع منعكس.
هذا الاختبار يستغرق دقيقة، ويخبرك أكثر من أي قائمة مزايا.
شغّل كل هذا من نظام واحد
كاشير ومطبخ ومخزون وتكلفة أطباق وموظفون ومحاسبة — مترابطة، والبداية مجانية.
أنشئ حسابك المجاني