النسخة الأولى من كل تكامل بين RFID وOdoo تبدو متطابقة. يُضبط القارئ ليرسل كل قراءة إلى وحدة تحكم، وتكتب وحدة التحكم مباشرة في stock.quant، وفي غضون أسبوع تبدأ قاعدة البيانات بالانحباس، وتشبع عمّال Odoo، ويصبح المخزون خاطئًا بطريقة لا يستطيع أحد إعادة إنتاجها.
الخطأ معماري لا تقني. القارئ مستشعر وليس مصدر عملية. بين مستشعر يبلّغ آلاف المرات في الثانية ونظام ERP يتوقع حدثًا تجاريًا مدروسًا، لا بد أن يوجد شيء يفكر. ذلك الشيء هو البوابة، وفي نشر ناجح تكون هي الجزء الذي تصونه وتصدّره وتراقبه — المنتج لا الغراء.
لماذا توصيل القارئات مباشرة بـ Odoo نمط مضاد
الأرقام تثبت ذلك قبل كتابة أي سطر كود.
- قارئ ثابت واحد عند باب يصدر عدة مئات من أحداث TagRead في الثانية أثناء مرور بالتة.
- تُرى كل بطاقة عادة بين خمس وعشرين مرة داخل الثانية الواحدة، بشدة إشارة مختلفة.
- يحسب ORM في Odoo ويكتب صف quant واحد لكل منتج وموقع ولوت، مع أقفال صفوف وإبطال ذاكرة عند كل كتابة.
- تتسلسل الكتابات المتزامنة على quant نفسه في انتظار الأقفال، وتنتج تحديثات الصفوف المتعددة بترتيب خاطئ حالات جمود.
- ثم يعيد انقطاع القارئ تشغيل دفعة، تصل في اللحظة التي يكون فيها ERP أقل قدرة على استيعابها.
مهام البوابة الثلاث: التحليل وإزالة التكرار والتجميع
بوابة تُتقن هذه الثلاث يمكن أن تكون مئتي سطر. وأخرى تُسيئها ستُعاد كتابتها مرتين.
- التحليل: تحويل EPC الخام إلى منتج ولوت ورقم تسلسلي دون استعلام قاعدة بيانات على المسار الساخن.
- إزالة التكرار: الاحتفاظ بمشاهدة واحدة لكل بطاقة في نافذة زمنية، لا عشرين، مع أقوى إشارة.
- التجميع: تحويل المشاهدات إلى فروق موقّعة لكل موقع ومنتج — وهي الكمية الوحيدة التي ينبغي أن يراها Odoo.
- التخزين المؤقت: إبقاء الفروق في طابور متين بحيث لا يضيع شيء عند إعادة التشغيل وتكون إعادة المحاولة آمنة.
- التطبيق: الكتابة في Odoo على دفعات بمفتاح عدم تكرار يجعل التطبيق المكرر بلا أثر.
من EPC إلى المنتج: ربط حتمي
تحليل EPC هو حيث تنكسر التكاملات بهدوء، لأنه يُنفّذ بمعالجة نصوص بدل مخطط.
- يرمّز SGTIN ذو 96 بتة بادئة الشركة ومرجع الصنف والرقم التسلسلي؛ ونقطة الفصل تعتمد على طول البادئة لا على النص.
- فكّك الترويسة أولًا ثم القسم ثم الحقول؛ وتخمين عروض الحقول يعمل حتى يتوقف عن العمل.
- احتفظ بخريطة مخزّنة من مرجع الصنف إلى المنتج واللوت؛ وحدّثها بمؤقت لا عند كل قراءة.
- عامل EPC غير المعروفة كطابور صريح لا كقيم فارغة؛ فالبطاقة المجهولة عيب في التعليم يستحق أن يُرى.
- صدّر قواعد الربط بإصدارات، لأن تغيير المورّد لترميزه لا ينبغي أن يفرض نشر كود.
الكتابة في stock.quant دون جمود
مسار الكتابة هو حيث تخسر معظم المشاريع عطلة أسبوع. القواعد بسيطة وتتعلق بالترتيب غالبًا.
- عملية كتابة واحدة لكل قاعدة بيانات؛ فالتزامن هنا يشتري إنتاجية لا تحتاجها وجمادًا تحتاجه.
- فضّل طريقة ORM التي تنفّذ تحديثًا ذريًا للكمية بالقفل الصحيح، ولا تفعل قراءة-تعديل-كتابة في بايثون أبدًا.
- إذا اضطررت إلى SQL، فأقفل الصفوف بترتيب حتمي — المنتج ثم الموقع ثم اللوت — حتى لا تتقاطع عمليتان.
- اجمع حسب الموقع لا حسب البطاقة: خمسون فرقًا في ممر واحد تنتمي إلى عملية واحدة لا خمسين.
- سجّل السبب التجاري في كل تعديل، لأن تغير كمية بلا تفسير لا يمكن تمييزه عن خطأ في التدقيق.
حل التعارض حين تتعارض حقيقتان
سيختلف القارئ وERP، والسؤال التصميمي هو من يُسمح له بالفوز ومتى.
- القراءة دليل على الحاضر، وسجل ERP ادعاء عن الماضي. وليستا من جنس واحد.
- لا تدع قراءة واحدة تكتب فوق كمية؛ طبّق الفرق فقط عندما تكون المشاهدة كاملة والمنطقة مغلقة.
- استخدم زمن الحدث من القارئ لا زمن الوصول إلى البوابة، حتى لا تبدو دفعة متأخرة حركة جديدة.
- «آخر كاتب يفوز» غير آمن مع الأحداث المكررة؛ الأفضل تسلسل رتيب لكل قارئ ورفض ما هو أقدم من آخر تطبيق.
- حين يكون الخلاف بنيويًا — منطقة كاملة منحرفة عشرة بالمئة — أطلق استثناءً بدل التصحيح الصامت.
هندسة الإنتاجية عند 100 ألف حدث يوميًا
مئة ألف حدث تعني واحدًا في الثانية في المتوسط ومئتين في الثانية عند الرصيف، لذا فالمتوسطات عديمة الفائدة.
- صمّم للذروة ثم تحقق من المتوسط؛ فالذروة تكسر النظام والمتوسط يجعله يبدو جيدًا في عرض.
- اجمع في نافذة من نصف ثانية إلى ثانيتين؛ أقل من ذلك تدفع كلفة عملية، وأكثر تدفع تأخيرًا.
- أبقِ المسار الساخن خاليًا من حقول ORM المحسوبة ومنطق onchange وخيوط البريد؛ لا شيء منها ينتمي لكتابة مخزون.
- شغّل عامل التطبيق في طابور المهام على قناة مخصصة، حتى لا يوقف ERP البطيء جانب القارئ.
- قِس نسبة إزالة التكرار؛ فإن كانت أقل من عشرة إلى واحد فالنافذة قصيرة وOdoo يقوم بعمل غير ضروري.
القابلية للمراقبة: ماذا نسجّل وماذا نُنبّه
خط أنابيب مخزون لا يمكن مراقبته سيُثق به حتى أول تدقيق، ثم لا.
- سجّل كل حدث خام لعينة، وكل فرق مطبّق لكل الأحداث، مع مفتاح عدم التكرار.
- تتبّع القراءات لكل هوائي، حتى يظهر الهوائي الميت كسقوط في سلسلة لا كأسبوع هادئ.
- نبّه على زمن تطبيق يتجاوز حدًا، وعلى نمو عمق الطابور، وعلى ارتفاع معدل الأحداث المرفوضة.
- طابق يوميًا: قارن فروق البوابة بتغيرات كمية Odoo وفسّر كل فرق يتجاوز حدًا.
- احتفظ بأرشيف أحداث قابل لإعادة التشغيل، لأن الحادث الأكثر شيوعًا ليس انهيارًا بل قاعدة خاطئة عملت ثلاثة أيام.
تسلسل النشر والتراجع
الطريقة الآمنة لإدخال مسار كتابة إلى ERP هي أن تجعله يستحق حق الكتابة.
- المرحلة الأولى: الوضع الظلي. احسب الفروق، سجّلها، لا تكتب شيئًا، وقارن بالنتائج المتوقعة لأسبوعين.
- المرحلة الثانية: الكتابة إلى قاعدة اختبار بحركة إنتاج، وتشغيل تقرير المطابقة عليها.
- المرحلة الثالثة: تفعيل الكتابة لمنطقة واحدة بمفتاح ميزة، وإبقاء العملية القديمة تعمل بالتوازي.
- المرحلة الرابعة: التوسع منطقة بمنطقة، مع مراقبة معدل الاستثناءات لا معدل النجاح.
- التراجع ليس استعادة قاعدة بيانات: أوقف الكاتب، وأعد تشغيل الطابور بالقاعدة المصححة، وطبّق مرة أخرى بلا تكرار.
