درس تعلمناه: كيف أوقفنا المخزون السالب نهائيًا

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

المشكلة: البيع أسرع من تحديث المخزون

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

ليه المخزون السالب مشكلة حقيقية مش مجرد رقم غريب

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

الحل: بوابة تحقق قبل تأكيد أي بيع

فريق تكة بنى بوابة تحقق من إمكانية البيع (sellability gate) بتشتغل قبل ما أي عملية بيع تتأكد نهائيًا، بغض النظر عن القناة (كاشير أو تطبيق عميل):

1. النظام بيتأكد من الرصيد الفعلي في المخزون لحظة محاولة البيع.
2. لو الرصيد مش كافي، العملية بترفض فورًا بدل ما تتأكد وتسبب رصيد سالب.
3. لو المنتج وصل لصفر، بيتحط عليه علامة "غير متاح مؤقتًا" تلقائيًا في كل القنوات.
4. في حالة البيع أوفلاين، نفس التحقق بيحصل لحظة المزامنة مع السيرفر.

قائمة "إيقاف" كأداة إضافية

جنب بوابة التحقق، فريق تكة أضاف "قائمة إيقاف" (stop list) تسمح لصاحب المحل يوقف بيع منتج يدويًا حتى لو رصيده موجود، لحالات زي منتج فيه مشكلة جودة أو منتج محجوز لمناسبة معينة.

الدرس المستفاد

الدرس هنا إن أي نظام بيتعامل مع أكتر من قناة بيع في نفس الوقت لازم يتعامل مع المخزون كـ"مصدر حقيقة واحد" (single source of truth) بيتحقق منه لحظيًا، مش كرقم بيتحدث بعدين. الفرق ده بسيط في الكلام لكنه مهم جدًا في التنفيذ.

لو عايز تعرف أكتر عن إدارة المخزون في تكة

اقرأ قصة مخبز بيدير مخزونه بدقة، وشوف إزاي خزنة الفرع بتكمّل دقة الأرقام دي على مستوى الكاش مش بس المخزون.