التخصيص بلا كود وبالكود في ERPNext

كل ما سبق كان استعمال النظام كما هو. هذه المحطة تسأل: ماذا تفعل حين لا يكفي؟

والجواب الذي يفاجئ كثيرين: في أغلب الطلبات، لا تكتب شيئاً. أكبر مهارة في هذه المحطة ليست الكتابة؛ هي رفض الكتابة حين لا تلزم.

لماذا هذا النظام مختلف هنا

عد إلى الفكرة التي بدأ بها هذا المسار كلّه: كل شيء نوع مستند، والنوع نفسه بيانات في قاعدة البيانات لا كود في ملفّ.

الحقول والشاشات وسير العمل والتقارير والصلاحيات كلها صفوف في جداول. وأثر ذلك عملي لا نظري: ما تعدّله من داخل الواجهة يبقى بعد الترقية، لأن الترقية تحدّث الكود ولا تمسح بياناتك.

فالسؤال «هل سينجو تخصيصي؟» له جواب واضح هنا: ينجو إذا كان بيانات، ويحتاج صيانة إذا كان كوداً. وهذا وحده يفسّر لماذا تُصنَّع أنظمة كاملة فوق هذا الإطار بلا تفريعه، وهو أقوى ما يُحسب لهذا المنتج في دليل ERPNext.

سلّم التخصيص — خمس درجات، تُجرَّب بالترتيب

القاعدة الحاكمة للمحطة كلها: لا تنزل درجة قبل أن تثبت أن التي فوقها لا تكفي.

الدرجة	الأداة	كود؟	تنجو من الترقية	متى تُستعمل
‎1	حقل مخصّص وتعديل خصائص حقل قائم	لا	نعم	معلومة ناقصة أو حقل يجب أن يصير إلزامياً
‎2	تخطيط الشاشة وتخصيص القوائم والتقارير	لا	نعم	«الشاشة مزدحمة» أو «التقرير ينقصه عمود»
‎3	سير عمل واعتمادات وصلاحيات	لا	نعم	«هذا المستند يحتاج موافقة مدير»
‎4	قواعد آلية وقوالب طباعة وتنبيهات	لا	نعم	«حين يحدث كذا افعل كذا»
‎5	تطبيق مستقلّ فوق الإطار	نعم	بشرط الالتزام بالواجهات	منطق حسابي حقيقي أو تكامل خارجي

ولاحظ ما ليس في الجدول أصلاً: التعديل داخل ملفّات ERPNext نفسها. هذه ليست درجة على السلّم؛ هي خروج منه. من يعدّل الأصل يشتري ألماً في كل ترقية إلى الأبد، ويخسر أهمّ ميزة في مشروع مفتوح المصدر: أن غيره يصونه له.

الدرجات الأربع الأولى — ماذا تنفّذ فعلاً

الحقل المخصّص. أضف حقلاً واحداً إلى أمر البيع، واجعله إلزامياً، ثم أنشئ أمراً بلا ملئه واقرأ الاعتراض. ثم أظهره في العرض الجدولي. هذه أربع طلبات من كل عشرة تصل إلى فرق التطوير، وكلها هنا بلا سطر واحد.

تخطيط الشاشة. أخفِ الحقول التي لا يستعملها فريقك، وأعد ترتيب الأقسام. ولا تستخفّ بهذا: شاشة فيها أربعون حقلاً يستعمل الفريق منها ثمانية هي أشهر سبب لرفض المستخدمين نظاماً سليماً. التبنّي مسألة تصميم شاشة قبل أن يكون مسألة تدريب.

سير العمل. عرّف حالات ومراحل موافقة على مستند واحد — أمر شراء يتجاوز حدّاً معيّناً مثلاً. ثم جرّبه بحسابين مختلفين. الفرق بين نظام يُصدَّق وآخر يُتحايَل عليه هو وجود اعتماد حقيقي أو غيابه.

القاعدة الآلية. اربط حدثاً بإجراء: عند اعتماد مستند، أرسل تنبيهاً أو حدّث حقلاً. ثم اقرأ سجلّ التنفيذ. وقاعدة الانضباط هنا: كل أتمتة تكتب سجلاً، والأتمتة التي لا يظهر أثرها في مكان يُقرأ هي عطل ينتظر.

الدرجة الخامسة — التطبيق المستقلّ

حين يلزم كود فعلاً، لا يُكتب داخل ERPNext؛ يُكتب في تطبيق مستقلّ يُثبَّت بجانبه. هذه هي البنية التي شرحتها في المحطة الثانية: الإطار، والتطبيق، والموقع، والبيئة التي تجمعها.

وأثر ذلك على المشروع كبير: كودك في مستودعك أنت، وله إصداره، ويمكن نزعه. والتطبيق الذي لا يُنزع بلا كسر الموقع تطبيق مكتوب خطأً.

وثلاث قواعد تحكم هذه الدرجة:

الأولى: امتدّ ولا تعدّل. أضف نوع مستند جديداً أو اربط منطقك بأحداث المستندات القائمة، ولا تغيّر سلوك الأصل من داخله.

الثانية: كل منطق مالي يترك أثراً. ما يمسّ القيود يجب أن يكون مقروءاً في تقرير، لأن ما لا يُقرأ لا يُراجَع، وما لا يُراجَع يُكتشف في التدقيق.

الثالثة: لا تكتب ما يكتبه النظام. أكثر الكود الذي رأيته في مشاريع حقيقية يعيد بناء تقرير موجود، أو حقل محسوب متاح من الواجهة، أو صلاحية تُضبط بضغطتين.

السؤال الذي تسأله قبل كل طلب

قبل أن تنفّذ أي طلب تخصيص، اسأل بالترتيب:

1. هل هذا نقص في النظام أم نقص في الإجراء؟ كثير من الطلبات وصفها الصحيح «فريقنا يعمل بطريقة غريبة»، وعلاجها إجراء لا حقل.
2. من المستفيد، وماذا يقرّر بهذه المعلومة؟ طلب لا يغيّر قراراً هو طلب يُؤجَّل.
3. ما الدرجة الأدنى على السلّم التي تحقّقه؟
4. من يصونه بعد سنتين؟

والسؤال الرابع هو الذي يميّز الاستشاري عن المنفّذ. كل تخصيص دَين، وفائدته تُدفع في كل ترقية. ومن يعدّ التخصيصات ميزة مجّانية يبني نظاماً لا يستطيع أحد ترقيته بعد ثلاث سنوات.

القاعدة العملية التي تنهي نصف الطلبات

عد إلى ما فعلته في المحطة السابعة: بنيت ثلاثة تقارير من الواجهة بلا كود.

هذه هي الإجابة عن أكثر ما يصل إلى المطوّرين تحت اسم «نحتاج تقريراً جديداً». وقياسها بسيط: جرّب بناءه في الواجهة أولاً؛ إن نجحت في عشر دقائق فقد وفّرت على المشروع أسبوعاً، وإن فشلت فقد عرفت لماذا يحتاج كوداً — وهذه معرفة تكتبها في الطلب.

أشهر ثلاثة أخطاء

الأول: التخصيص قبل الاستعمال. فريق يطلب تعديلات قبل أن يشغّل شهراً كاملاً. والقاعدة: لا تخصيص قبل ثلاثة أشهر تشغيل حقيقي، لأن نصف الطلبات تسقط وحدها حين يتعوّد الناس.

الثاني: تخصيص بلا توثيق. حقل أضافه أحدهم قبل سنة ولا أحد يعرف لماذا، فيبقى إلى الأبد لأن حذفه مخيف. اكتب لكل تخصيص سطراً: من طلبه، ولماذا، ومتى يُراجَع.

الثالث: نسخ التخصيص يدوياً من بيئة الاختبار إلى الإنتاج. يعمل مرة، ثم تفترق البيئتان بصمت، ويصير كل اختبار كذبة. ما يُخصَّص يُنقل كوحدة واحدة، لا بإعادة الضغط على نفس الأزرار.

اختبار القبول لهذه المحطة

1. أضف حقلاً مخصّصاً إلزامياً إلى مستند، واقرأ اعتراض النظام حين تتركه فارغاً.
2. أعد تخطيط شاشة بإخفاء ما لا يُستعمل، وقِس عدد الحقول قبل وبعد.
3. ابنِ سير عمل باعتماد واحد وجرّبه بحسابين مختلفين.
4. أنشئ قاعدة آلية تُطلق تنبيهاً عند حدث، وتحقّق من سجلّها.
5. خذ ثلاثة طلبات تخصيص حقيقية — من عملك أو من منتديات المستخدمين — وضع كلاً منها في درجته على السلّم مع سبب مكتوب. هذا الجدول قطعة في محفظتك، وهو أقرب ما تُظهره لمقابلة عمل استشارية.

ماذا بعد

تعرف النظام، وتعرف حدوده، وتعرف كيف تتجاوزها بانضباط. المحطة الأخيرة تحوّل هذا كلّه إلى شيء يراه غيرك: شهادة رسمية بتفاصيلها المعلَنة، ومحفظة أعمال مبنية من مخرجات المحطات التسع، وطريق أول عمل.