القارئات تعمل. والوسوم تُقرأ بنسبة 98%. وبعد ثلاثة أشهر من التشغيل يقف فريق المالية أمام تسويات مخزون لا يستطيع أحد تفسيرها. وكل فشل في RFID لا يعود إلى مشكلة فيزيائية هو في الغالب فشل في التكامل: أحداث تصل بترتيب خاطئ، أو تُحتسب المنصة نفسها مرتين، أو يكتب الوسيط كمية في ERP لا يمكن تدقيقها أبدًا.
يتناول هذا المقال الطبقة الواقعة بين القارئ ونظام الأعمال، وكيف ينبغي تصميمها لتظل أرقام Odoo أو SAP أو يوني قابلة للدفاع عند إقفال الشهر.
ما الذي تتولاه طبقة التكامل وما الذي يبقى داخل ERP؟
وزّع المسؤوليات صراحة، واكتب هذا التوزيع في نطاق العقد. الغموض هنا ينتج نظامين يعتقد كل منهما أن الآخر هو المرجع.
- طبقة الحافة: اتصال القارئات، ضبط الهوائيات، تصفية القراءات، منع التكرار، تحويل الوسم إلى رمز صنف، الطوابع الزمنية ومعرّف الحدث.
- الوسيط: الترتيب، إعادة المحاولة، معالجة الرسائل الفاشلة، إثراء السياق (بوابة، مشغّل، أمر عمل)، والتحويل إلى مستند أعمال.
- ERP: التقييم، التخصيص، حساب المتاح، الترحيل المالي، وأثر التدقيق.
القاعدة التي تُنقذ معظم المشاريع: لا يكتب الوسيط أبدًا في stock.quant مباشرة. بل يقدّم مستندًا — استلام أو تحويل أو تسوية جرد — ويترك لمنطق ERP نفسه أن يقرر ماذا يصبح المخزون. الكتابة المباشرة تتجاوز أثر التدقيق وطبقة التقييم، وتنكسر في يوم الترقية.
أي نمط يناسب حجمك: ملف أم API أم تدفق أحداث؟
اختر بأرقام مقاسة لا بتفضيل المورّد. الأنماط الثلاثة تتعايش بلا مشكلة.
- أقل من 5,000 حدث في الوردية: يكفي تبادل ملفات كل ساعة أو كل ليلة، وهو الأسهل في المطابقة. ملف واحد لكل موقع، تسمية محددة، وبصمة تحقق في القائمة.
- من 5,000 إلى 50,000 حدث في الساعة: نداءات REST متزامنة في دفعات من 100 إلى 500، يحمل كل منها مفتاح عدم تكرار.
- فوق ذلك، أو حين تحدد الكمون نتيجة العمل (بوابة يجب أن تؤكد في ثوانٍ): تدفق أحداث — MQTT من القارئ إلى الحافة، وKafka أو RabbitMQ من الحافة إلى ERP.
الكمون أهم من الإنتاجية. تأكيد استلام يصل متأخرًا عشرين دقيقة مشكلة عمل لا مشكلة تقنية. قِس المئين 95 عند البوابة، لا المتوسط في المختبر.
Odoo: كيف تستقبل الأحداث دون إفساد stock.quant
يتيح Odoo كتابة أي شيء تقريبًا، ولهذا تحديدًا يحتاج التكامل إلى انضباط.
- نوع عملية مخصص لكل مسار: استلام RFID، تحويل داخلي RFID، جرد RFID. التقارير والصلاحيات تتبع نوع العملية.
- في الجرد استخدم معالج تسوية المخزون: اكتب inventory_quantity على سطر الكوانت ثم استدعِ action_apply_inventory. لا تكتب الحقل quantity مباشرة؛ المعالج هو الذي يولّد حركة قابلة للتدقيق.
- امنح كل حدث معرّفًا خارجيًا ثابتًا في حقل مخصص بفهرس فريد، حتى لا تولّد إعادة المحاولة سطر حركة ثانيًا.
- عالج من 200 إلى 500 سطر حركة في المعاملة الواحدة. الدفعات الأكبر تحتفظ بأقفال صفوف على الأصناف وتعطّل مستخدمين آخرين بلا فائدة.
- ضع حقول RFID (rfid_epc، rfid_event_id، rfid_reader) في نموذج منفصل أو كحقول محسوبة غير مخزّنة. جدول stock.quant يُقرأ باستمرار، وتضخيمه يكلّف الأداء في كل مكان.
SAP: IDoc وOData ومسألة الوسيط
SAP يريد مستندات مواد لا قراءات وسوم. هناك ثلاثة مسارات واقعية ولكل منها حالة استخدام جيدة.
- IDoc (WMMBID02، MBGMCR، DESADV): ناضج وموجّه للدفعات، وهو الخيار الأقل إزعاجًا إذا كنت تشغّل PI/PO بالفعل.
- OData وواجهات REST على S/4HANA: أفضل للترحيل شبه الفوري وأبسط بكثير في إدارة الإصدارات من توسيعات IDoc المخصصة.
- طبقة MII أو EWM مخصصة: لا تُبرَّر إلا فوق عدة ملايين من أحداث الوسم يوميًا، أو حين يكون EWM أصلًا النظام المرجعي للمستودع.
الخطأ المتكرر هو اختيار نوع الحركة للراحة بدل المعنى المحاسبي. 261 و262 للاستهلاك، 101 و102 للاستلام، 311 و312 للتحويل — ولكل منها تبعات في حساب التكلفة وعند إقفال الفترة. اجعل مراقب الحسابات يوقّع جدول التحويل قبل كتابة أول سطر من كود التكامل.
يوني وKingdee وأنظمة ERP الصينية: OpenAPI أولًا
أنظمة ERP الصينية — يوني U8+، ويوني BIP وNC Cloud، وKingdee K/3 وCloud — توفر OpenAPI من نوع REST وناقل رسائل. استخدمها، واستخدمها بشكل غير متزامن.
- اسحب لقطة مخزون يومية وطابقها مع جردك الخاص، وادفع المعاملات كمستندات أعمال مكتملة.
- الكتابة المباشرة في قاعدة بيانات U8 ممارسة شائعة في السوق المحلي وهي أغلى اختصار متاح. تتجاوز أثر التدقيق، وتنكسر عند ترقيات التحديثات، وتحوّل مطابقة الإقفال إلى مفاوضة سياسية.
- تحقق من حدود معدل الواجهة ومن تحويل حقول المستودع والدفعة والرقم التسلسلي قبل الوعد بالزمن الحقيقي. كثير من التركيبات المحلية شبه فورية فعليًا، والوعد بغير ذلك هو كيف يفقد المشروع مصداقيته في الأسبوع الثاني.
ما ينكسر في الإنتاج وكيف نصمم له
ستة أنماط فشل تفسر معظم الحوادث، ولكل منها إجابة تصميمية.
- انحراف الساعة بين القارئات: سجّل occurred_at من القارئ وreceived_at من الخادم، ولا ترتّب على الأول وحده.
- تكرار EPC: وسمان مبرمجان بالمعرّف نفسه يولّدان حركات متناقضة. اكتشف ذلك عند الحافة وارفضه قبل أن يصل إلى ERP.
- تراكم القراءات أثناء الانقطاع: قارئ يعود للاتصال بعد ساعتين لا يجوز أن يعيد بث 40,000 قراءة قديمة كأحداث حالية. حدّد نافذة للتراكم وعلّم الأحداث المتأخرة صراحة.
- التسليم خارج الترتيب: لا يمكن لصنف أن يغادر موقعًا قبل أن يصل إليه. ارفض أو اعزل، ولا تقبل بصمت أبدًا.
- المنطقة الزمنية: خزّن بالتوقيت العالمي، واعرض المحلي، واختبر حد التوقيت الصيفي قبل الإطلاق.
- الفشل الجزئي الصامت: دفعة من 500 يفشل فيها 3 أسطر يجب أن تبلّغ عن 497 ناجحًا و3 معلّقًا، لا عن خطأ عام واحد.
قائمة تحقق قبل توقيع عقد التكامل
- من يولّد معرّف الحدث، وهل هو فريد عالميًا بين المواقع والسنوات؟
- أي نظام يملك صلاحية تحويل قراءة إلى حركة؟
- هل كل كتابة غير قابلة للتكرار مزدوج، وهل اختُبرت برسالة مكررة عن قصد؟
- ما كمون المئين 95 مقاسًا عند البوابة؟
- كيف تظهر الاستثناءات، ومن يغلقها وفي أي مهلة؟
- هل يمكنك إعادة تشغيل يوم كامل من الأحداث دون مضاعفة المخزون؟
- هل وقّعت المالية أو مراقبة التكاليف على تحويل أنواع الحركة وأنواع العمليات؟
إذا كان أي جواب اسم شخص لا مستندًا، فالتكامل لم يُحدَّد بعد، وستُدفع تكلفة هذا الغموض في صورة تسويات مخزون.
