المحطة 9 من 10
التخصيص والتحديث في Dynamics 365 F&O
ما تخرج به من هذه المحطة
معرفة أين يقف الإعداد وأين يبدأ الكود، وبناء قائمة اختبار انحدار تُشغَّل مرتين في السنة على الأقلّ.
في المحطة السابقة وقفت عند حدّ المنتج أمام الدولة. هذه عن حدّه أمامك.
وابدأ من الرقم الذي يحكم كل شيء بعده. مايكروسوفت تنشر سياستها صراحةً: أربع خدمات تحديث سنوياً، تحديثاً آلياً في فبراير وأبريل ويوليو وأكتوبر. والعميل يستطيع أخذ أربعة، ومُلزَم بأخذ اثنين على الأقلّ، ولا يستطيع تأجيل أكثر من واحد في المرة. وبعد انتهاء مهلة التأجيل تطبّق مايكروسوفت أحدث تحديث آلياً. وبيئة الاختبار تُحدَّث قبل الإنتاج بسبعة أيام.
فالسؤال في هذا المنتج ليس «هل أستطيع أن أفعل هذا؟» بل «ماذا يحدث لما فعلته مرتين في السنة على الأقلّ؟»
القاعدة البنيوية: توسعة لا تغليف
هذه أهمّ جملة معمارية في المنتج: لا يُعدَّل كود مايكروسوفت.
فالأجيال القديمة من هذا المنتج كانت تسمح بتغليف الشيفرة الأصلية وتعديلها في الموضع، وكان ثمن ذلك أن كل ترقية مشروع بالغ الكلفة. والجيل السحابي أغلق الباب: التخصيص يُكتب توسعةً تُعلَّق على نقاط ممتدّة يعلنها المنتج، ولا تمسّ أصله.
وهذا يُقرأ قيداً وهو حماية. فما يُبنى توسعةً ينجو من التحديث في الغالب الأعمّ؛ وما كان يُبنى تغليفاً كان يُكسَر في كل ترقية. ومن يقاوم النموذج اليوم يعيد اختراع مشكلة حُلّت.
سلّم الدرجات الأربع
| الدرجة | ما فيها | أثر التحديث |
|---|---|---|
| 1. الإعداد | مجموعات الترحيل، الأبعاد، سياسات المطابقة، الضريبة، تسلسل الأرقام | ينجو دائماً |
| 2. أدوات المنصة | التقارير الإلكترونية، سير العمل، مساحات العمل، الاستيراد والتصدير | ينجو، ويُختبَر |
| 3. طبقة باور بلاتفورم | تطبيقات وتدفّقات فوق البيانات، بلا لمس المنتج | ينجو، ويُختبَر |
| 4. توسعات X++ والتكاملات | كود ونقاط تكامل خارجية | مسؤوليتك، ويُختبَر كل مرة |
والدرجة الأولى أوسع بكثير ممّا يظنّ القادم من أنظمة أصغر. فأكثر ما يُطلب في مشروع خليجي نمطي — حساب مختلف لحالة، ومستوى اعتماد إضافي، وحقل على الفاتورة، ومعالجة ضريبية خاصة — يقع في الدرجتين الأولى والثانية.
والجملة التي تختصر المحطة: أكثر ما يُطلب ككود هو إعداد لم يعرفه أحد.
والتقارير الإلكترونية تحديداً — التي رأيتها في المحطة الثامنة — محرّك تنسيق كامل بلا كود. ومن أتقنها يُخرج مستنداً بأي تنسيق تفرضه جهة، بلا أن يفتح بيئة تطوير.
وأثر هذه السياسة على ميزانية التشغيل مفصَّل في دليل Dynamics 365 Finance & Operations.
أداة اختبار الانحدار — ما يفصل الفريق الناضج
مايكروسوفت تنشر أداة مجانية لأتمتة اختبار الانحدار، تسجّل سيناريو يُنفَّذ على الشاشة ثم تعيد تشغيله على أي بيئة بعد أي تحديث.
وقيمتها لا تظهر في السنة الأولى بل في العاشرة.
فأربعة تحديثات سنوياً، على منتج عمره عشر سنوات عند العميل، تساوي أربعين دورة اختبار. ومن بنى الاختبار آلياً في السنة الأولى دفع مرة؛ ومن أبقاه يدوياً دفع أربعين مرة، ثم اختصره تحت الضغط، ثم اكتشف عطلاً في الإنتاج.
والحدّ الأدنى الذي يستحقّ الأتمتة: دورة شراء كاملة، ودورة بيع كاملة، وإقفال مصغّر، وفاتورة ضريبية إلكترونية، وكل تكامل قائم.
الطبقة التي تُنسى: باور بلاتفورم
بين الإعداد والكود طبقة كاملة يتجاهلها أكثر المشاريع، وهي غالباً الجواب الصحيح.
وثلاث حالات تُحلّ فيها بلا لمس المنتج:
- شاشة إدخال مبسّطة لدور واحد. مندوب يحتاج حقلين لا أربعين: تطبيق صغير فوق البيانات أبسط من تخصيص شاشة المنتج، وينجو من التحديث لأنه خارجه.
- تنبيه أو موافقة خارج النظام. إشعار على الهاتف عند تجاوز حدّ، أو اعتماد من بريد المدير.
- دمج مع نظام ثالث بلا كود. تدفّق جاهز بدل تكامل يُبنى ويُصان.
والفرق الذي يجعل هذه الطبقة آمنة: هي تقرأ وتكتب عبر واجهات معلنة، ولا تعدّل المنتج. فتحديث المنتج لا يكسرها، وما يكسرها هو تغيّر الواجهة نفسها — وهو أندر بكثير.
والقيد الذي يجب أن يُعرَف مسبقاً: هذه الطبقة مرخّصة على حدة في حالات، ويُسأل عنها في عرض السعر قبل أن يُبنى عليها تصميم. فحلّ ممتاز بترخيص غير مشترى ليس حلاً.
عادة التحديث
ثلاث خطوات، وهي ما يجعل التحديث حدثاً عادياً:
الأولى: تُقرأ خطة الإصدار قبل وصوله. مايكروسوفت تنشر خطة كل موجة بتواريخ المعاينة والإتاحة العامة. ومن يقرأها قبل الوصول يخطّط؛ ومن يقرأها بعده يشرح.
الثانية: تُختبر بيئة الاختبار في نافذتها. وهي سبعة أيام، لا أكثر، لأن الإنتاج يُحدَّث بعدها آلياً. ومن لا يملك اختباراً آلياً لا يستطيع أن يستعمل سبعة أيام استعمالاً جادّاً.
الثالثة: يُوثَّق ما تغيّر وما يحتاج تدريباً. فأكثر شكاوى المستخدمين بعد تحديث ليست أعطالاً، بل شاشة تبدّلت ولم يُخبَر أحد.
ما تفعله عملياً في هذه المحطة
- خذ خمسة طلبات تغيير واقعية وصنّفها على الدرجات الأربع. وأربعة منها ستقع في الأولى والثانية.
- أنشئ تنسيق تقرير إلكتروني بسيطاً بلا كود، وأخرِج به مستنداً.
- اكتب قائمة اختبار الانحدار لدوراتك بخطوات ونتائج متوقّعة.
- اقرأ خطة الإصدار الحالية واكتب في نصف صفحة ما يخصّ عميلاً خليجياً.
- احسب: كم دورة اختبار يحتاجها عميل على مدى عشر سنوات، بواقع اثنتين سنوياً على الأقلّ؟ الرقم هو حجّتك أمام أي إدارة ترفض الأتمتة.
أشهر ثلاثة أخطاء
الأول: القفز إلى X++. يُكتب كود لحلّ ما كان إعداداً، فتُضاف صيانة دائمة ودورة اختبار أبدية.
الثاني: اختبار يدوي في نافذة سبعة أيام. يُختصر تحت الضغط، ويُكتشف العطل في الإنتاج.
الثالث: تجاهل خطة الإصدار. فيُعرَف التغيير من شكوى مستخدم، وهو أغلى طريق لمعرفة شيء منشور مجاناً قبل شهور.
اختبار القبول لهذه المحطة
- اذكر سياسة التحديث بأرقامها: كم في السنة، وكم الحدّ الأدنى، وكم يمكن تأجيله.
- اشرح الفرق بين التوسعة والتغليف ولماذا أُغلق الثاني.
- صنّف خمسة طلبات تغيير على الدرجات الأربع.
- اعرض قائمة اختبار الانحدار التي كتبتها.
- اشرح لماذا تكون نافذة السبعة أيام بلا أتمتة نافذة نظرية.
ماذا بعد
أتقنت المنتج وحدوده. المحطة الأخيرة تحوّله إلى دخل: الشهادة وأول وظيفة — امتحان MB-310 بمدّته وثمنه ولغاته وتجديده السنوي، وما يُسأل في المقابلة فعلاً.
