غالبًا ما توصف نسخة Community من Odoo بأنها غير مناسبة لـ RFID لأنها تفتقر إلى صندوق IoT وإلى تطبيق الباركود في نسخة Enterprise. في الواقع صندوق IoT راحة لا قدرة: يغلّف مجموعة من مشغلات الأجهزة في حاوية مدفوعة. والبوابة التي تتحدث MQTT أو HTTP أصلًا لا تحتاجه.
ما تتطلبه Community حقًا هو الانضباط. الإغراء هو تعديل وحدة المخزون مباشرة، وهذا الإغراء هو سبب عجز كثير من مشاريع Odoo عن الترقية. وحدة منفصلة من بضع مئات الأسطر تعيش ثلاث هجرات؛ والتعديل الجذري لا يعيش واحدة.
لماذا نسخة Community كافية
الفجوات أضيق مما تبدو، ولكل منها مخرج نظيف.
- القوة الأساسية موجودة: stock.quant وstock.move ونموذج تعديل المخزون في النسخة المجانية.
- واجهة Odoo العامة وORM يمنحان وصولًا كاملًا للنماذج، فتستطيع وحدة مخصصة الكتابة كما يفعل تطبيق Enterprise.
- تسمح وحدات التحكم بتعريض نقطة دخول صغيرة دون تثبيت أي شيء إضافي.
- مجدول المهام موجود، وهو كل ما يحتاجه كاتب دفعي.
- ما تخسره هو مشغلات أجهزة جاهزة وعقد دعمها، وكلاهما يعوّضه بوابتك.
هيكل الوحدة: ما مكانه أين
الهيكل المتوقع أثمن من الكود الذكي، لأن المطوّر التالي سيقرأه أولًا.
- جذر الوحدة يحوي المانيفست الذي يعلن الاعتماد على stock، وعلى طابور المهام إن استُخدم.
- يحتوي models ثلاثة ملفات: سجل القارئات، وحدث القراءة الخام، وخريطة EPC إلى المنتج.
- يحتوي views قوائم وأشكال وبحث وتعريفات القوائم، ولا شيء غيرها.
- يحتوي security تعريفات المجموعات وملف حقوق الوصول وقواعد السجلات.
- يحتوي controllers نقطة الدخول؛ وdata تعريف المهمة المجدولة؛ وtests اختبارات العمليات.
نماذج البيانات: قارئ وحدث وخريطة
ثلاثة نماذج تكفي لنسخة أولى، وإضافة رابع يجب أن تطلب حجة.
- القارئ: المعرّف، الموقع، المنطقة، البروتوكول، الحالة، آخر نبضة، وإعداد الهوائيات.
- حدث القراءة: القارئ، الهوائي، EPC، شدة الإشارة، زمن الجهاز، زمن الاستقبال، التسلسل، والحالة.
- الخريطة: نمط EPC، المنتج، اللوت، الكمية، وإصدار القاعدة المستخدمة في الحل.
- حالة الحدث تعداد صغير — مستلم، محلول، مطبّق، مرفوض — وهي عمود فقري لأثر التدقيق.
- أبقِ الحدث الخام غير قابل للتغيير بعد وصوله إلى حالة نهائية؛ والتصحيحات تنتمي إلى حدث جديد لا إلى تعديل.
الواجهات والقوائم دون المساس بالنواة
الوراثة للإضافة لا لإعادة الكتابة، وهذا التمييز يحدد إن كانت الترقيات ستؤلم.
- ضع القائمة تحت المخزون، لا كتطبيق رئيسي جديد، إلا إذا كانت الوحدة تخدم عدة وحدات فعلًا.
- استخدم الواجهات الموروثة لإضافة زر ذكي في شكل المنتج يفتح تاريخ بطاقاته.
- أعطِ قائمة الأحداث مرشحًا افتراضيًا لليوم وتجميعًا حسب المنطقة، فهكذا ينظر المشغّلون فعلًا.
- أظهر إصدار قاعدة الربط في شكل الحدث؛ فعند ظهور تباين يكون أول حقل يفحصه أي شخص.
- لا تتجاوز بنية واجهة أساسية بالكامل أبدًا؛ أضف العقدة المحددة التي تحتاجها عبر xpath.
الأمان: ACL وقواعد السجلات ومستخدم التكامل
الأمان هو الجزء الذي يُتخطى في النموذج الأولي ويُدقّق في الإنتاج.
- مجموعتان تكفيان عادة: مشغّل يقرأ الأحداث ويؤكد الخرائط، ومدير يغيّر القارئات والقواعد.
- لا تمنح صلاحية كتابة على نماذج المخزون تتجاوز ما تملكه مجموعات المخزون القياسية.
- استخدم مستخدم تكامل مخصصًا بصلاحيات ضيقة، وأعطِ البوابة مفتاح API خاصًا بها لا تسجيل دخول بشريًا.
- أضف قاعدة سجل بحيث لا يرى مستخدم في شركة قارئات وأحداث شركة أخرى.
- سجّل من غيّر قاعدة ربط، لأن قاعدة خاطئة تلوّث أسابيع من المخزون بصمت.
تكامل stock.quant دون تعديل stock
مسار الكتابة هو الجزء الوحيد الخطر فعلًا في الوحدة.
- استدعِ دالة ORM القائمة التي تحدّث الكمية المتاحة ذريًا، ولا تُسند حقل الكمية مباشرة أبدًا.
- ضع التطبيق في عملية واحدة لكل موقع، ليرجع الفشل وحدة متماسكة لا نصف ممر.
- سجّل سبب التعديل ومعرّف الحدث المصدر في حقل المرجع، ليصل أثر التدقيق إلى الراديو.
- لا تنشئ حركات مخزون لتصحيح جرد؛ استخدم نموذج تعديل المخزون الذي وُجد لهذا بالضبط.
- أبقِ إزالة التكرار والتجميع خارج Odoo؛ فالوحدة يجب أن تستقبل فروقًا لا تيار قراءات خام.
نقطة الدخول: وحدة تحكم ومهمة مجدولة ودفعات
يجب أن تكون النقطة مملة: تحقق من الهوية، تحقق من الصحة، ضع في الطابور، أعِد الرد.
- اقبل جسم JSON يحمل دفعة فروق ومفتاح عدم تكرار، وارفض كل ما يفشل في تحقق المخطط بخطأ محدد.
- اكتب الفرق في جدول الأحداث ثم ارجع فورًا؛ ولا تنفّذ تطبيق Odoo داخل طلب HTTP أبدًا.
- دع المهمة المجدولة تفرّغ الطابور كل دقيقة، أو كل بضع ثوانٍ في طابور المهام، بكاتب واحد.
- اجعل التطبيق غير متكرر الأثر على مفتاح عدم التكرار، فلا تضاعف إعادة محاولة الشبكة الكمية.
- حدّد حجم الدفعة وحجم الجسم، فنقطة بلا حدود دعوة.
الاختبار وانضباط الترقية
ستُرقّى الوحدة، والاختبارات هي ما يحوّل ذلك إلى روتين لا مشروع.
- اكتب اختبارات عمليات تنشئ قارئًا وتُدخل حدثًا وتطبّقه وتتحقق من quant ثم ترجع.
- اختبر حالة التكرار صراحة: أرسل المفتاح نفسه مرتين وتحقّق من تطبيق واحد.
- اختبر مسار الرفض: EPC مجهول يجب أن يذهب إلى الحجر لا إلى أثر استثناء.
- أبقِ سكربت هجرة لكل إصدار يمسّ البيانات، واختبره على نسخة من الإنتاج.
- ثبّت اعتماديات الوحدة وتجنّب نداءات API الخاصة، لأنها ما ينكسر في الإصدار الرئيسي التالي.
