يصدر Odoo نسخة رئيسية جديدة كل عام، ولا يبقى مدعوماً سوى أحدث الإصدارات. هذا الإيقاع يضع كل شركة تعمل على Odoo أمام السؤال نفسه في مرحلة ما: هل تنتقل الآن، أم تنتظر دورة أخرى وتقفز قفزة أكبر لاحقاً؟ لا توجد إجابة صحيحة تلقائياً، لكن الخطأ الذي يتكرر واحد: التعامل مع الترقية بوصفها عملية على قاعدة البيانات، بينما هي في الحقيقة مشروع كامل يشمل الاختبار والتحول والتدريب.
فيما يلي ما يحدد فعلياً مدى صعوبة ترقيتك، وما ينبغي التحقق منه قبل تثبيت أي تاريخ.
قاعدة البيانات هي الجزء السهل
يوفّر Odoo خدمة ترقية رسمية تنقل قاعدة بياناتك من إصدار إلى آخر. إذا كنت تعمل بالتطبيقات القياسية مع إعدادات فقط، فإن هذه الخدمة تنجز معظم العمل، ويتبقى لك التحقق. في هذه الحالة الترقية مشروع قصير.
الصعوبة تتصاعد مع كل ما بُني فوق التطبيقات القياسية: الوحدات المخصصة، والتطبيقات الخارجية من متجر Odoo Apps، وتخصيصات Studio، والتقارير المخصصة، والأنظمة التي تتحدث مع Odoo من الخارج. لا شيء من هذا يُرحَّل نيابة عنك. الكود المخصص يحتاج إلى مراجعة مقابل واجهات الإصدار الجديد، والتطبيقات الخارجية يجب أن تكون متوفرة أصلاً للإصدار المستهدف قبل أن تتمكن من التحرك من مكانك.
ابدأ بالجرد، لا بالتاريخ
قبل أن يحجز أحد عطلة نهاية أسبوع للتحول، اكتب قائمة بكل ما هو غير قياسي في النظام:
- الوحدات المخصصة، ومن يتولى صيانة كل واحدة منها اليوم
- التطبيقات الخارجية، وهل صدرت نسخة منها للإصدار المستهدف
- تخصيصات Studio، وهي الأسهل نسياناً لأنها أُنشئت من الواجهة لا من الكود
- التقارير المخصصة وقوالب البريد وأي تنسيق يعتمد عليه فريق المالية أو المبيعات
- التكاملات: بوابات الدفع، والفوترة الإلكترونية، والكشوف البنكية، والمتجر الإلكتروني، وأجهزة نقاط البيع، وكل ما يقرأ من Odoo عبر XML-RPC أو webhooks
- الإجراءات التلقائية وإجراءات الخادم المكتوبة كأكواد Python قصيرة
عنصران من هذه القائمة يتسببان في معظم التأخير. التطبيقات الخارجية هي السبب المعتاد لتوقف الترقية، لأنك تنتظر جدول إصدار يخص طرفاً آخر ولا تملك وسيلة لتسريعه. اكتشف ذلك مبكراً، وليكن لديك قرار جاهز لكل تطبيق: الانتظار، أو الاستبدال، أو إعادة بناء الجزء الذي تستخدمه فعلاً، أو الاستغناء عنه. أما تخصيصات Studio فهي السبب المعتاد للمفاجآت، لأن أحداً لم يوثّقها، ولا تظهر إلا حين يختفي حقل بهدوء من إحدى الشاشات.
اختبر على نسخة من بياناتك الحقيقية
قاعدة بيانات تجريبية لا تثبت شيئاً عن ترقيتك. خذ نسخة مرقّاة من قاعدة بيانات الإنتاج ومرّر عليها عملاً حقيقياً: أنشئ أمر بيع، وأكّد تسليماً، وسجّل فاتورة، ونفّذ دفعة، وأقفل فترة، واطبع التقارير التي يستخدمها محاسبوك بالفعل.
أقوى اختبار على الإطلاق هو المطابقة. اطلب من فريق المالية إقفال فترة سبق إقفالها على النظام المباشر، ثم قارن الأرقام سطراً بسطر. إذا تحرك رقم واحد فأنت تريد معرفة السبب الآن، لا في أول إقفال شهري على الإصدار الجديد. خصّص للاختبار وقتاً أكبر مما يبدو ضرورياً، لأن الأعطال التي تستحق الاصطياد هي الأعطال المملة: تقرير فقد عموداً، أو تسلسل ترقيم بدأ من جديد، أو ضريبة توقفت عن الانطباق على فئة منتجات واحدة.
التوطين يسير بجدوله الخاص
الامتثال المحلي في Odoo يأتي من وحدات التوطين الرسمية التي يتولى Odoo صيانتها لا شريكك. الفوترة الإلكترونية لـ ZATCA في السعودية، ومنظومة ETA في مصر، وإقرارات ضريبة القيمة المضافة لدى FTA في الإمارات، وملفات WPS للرواتب، كلها تعيش هناك. قبل الترقية تأكد أن توطين بلدك متاح للإصدار المستهدف، وتعامل مع مخرجات الامتثال بوصفها اختباراً من الدرجة الأولى: أصدر فاتورة حقيقية، وأرسلها في بيئة اختبارية، واقرأ الرد بدل افتراض أن الأمر نجح.
توقّع الأعطال الصغيرة
بين الإصدارات الرئيسية تُعاد تسمية وحدات أو تُدمج داخل النواة، وتتغير خصائص العروض، وقد تختفي حقول يقرأها كودك المخصص. كل واحدة من هذه على حدة إصلاح بسيط. مجتمعةً هي معظم العمل، وهي السبب في أن النظام كثير التخصيص ينبغي أن يرقّيه من يقرأ الكود لا من يقرأ الشاشات فقط.
خطّط للتحول قبل أن تحتاجه
تدرّب على التسلسل كاملاً مرة واحدة على الأقل من البداية إلى النهاية، حتى يكون التحول الحقيقي تكراراً لا محاولة أولى. حدّد نافذة تجميد لا يسجّل فيها أحد أي حركة، واحتفظ بالنسخة الاحتياطية السابقة للترقية واعرف بالضبط كيف ستعود إليها، وأخبر المستخدمين مسبقاً بما سيبدو مختلفاً صباح الاثنين. تغيّرات الواجهة بين الإصدارات حقيقية، والفريق الذي رأى الشاشات الجديدة مرة واحدة يختلف كثيراً في حجم الدعم الذي يطلبه عن فريق يواجهها بلا تمهيد.
إذاً متى تنتقل؟
المقايضة بصراحة: الترقية مع كل إصدار تقريباً تُبقي كل قفزة صغيرة وتُبقي كودك المخصص قريباً من الحاضر، مقابل تنفيذ مشروع بوتيرة أعلى. وتخطّي الإصدارات يؤجل هذا الجهد لكنه يراكمه، وينتهي بك إلى إصدار غير مدعوم تشحّ فيه التحديثات الأمنية ودعم الشركاء معاً.
إذا كان Odoo لديك قياسياً في معظمه، فانتظار دورة واحدة خيار سليم عادة. أما إذا كنت تحمل كوداً مخصصاً كثيراً، فالترقيات الأصغر والأكثر تكراراً أرخص إجمالاً في الغالب، لأن مطوريك يتعاملون مع تغييرات سنة واحدة بدل ثلاث سنوات دفعة واحدة. في الحالتين، ليكن القرار مقصوداً. أسوأ إصدار يمكن أن تكون عليه هو الإصدار الذي وصلت إليه لأنك لم تختر.
Plementus شريك Odoo Gold منذ 2017، ولديها فرق في دبي والرياض والقاهرة، وترقية الإصدارات من أكثر ما تنفّذه. إذا أردت رأياً ثانياً في ما تتطلبه ترقيتك فعلاً، فإن خدمة ترقية الإصدارات لدينا تبدأ بتقييم يغطي الجرد الموصوف أعلاه بالضبط.