عبارة «يجب أن يوافق المدير على هذا قبل أن يخرج» من أكثر طلبات التخصيص تكراراً في أي مشروع Odoo. تبدو بسيطة: زر جديد وحالة جديدة وينتهي الأمر. لكن الزر في الواقع هو الجزء السهل، أما الصعب فهو القاعدة التي تقف خلفه: أي المستندات، وفوق أي مبلغ، ومن يوافق، وماذا يحدث حين يكون هذا الشخص في إجازة. الفرق التي تحسم هذه الأسئلة أولاً تحصل على تغيير صغير يمكن الاعتماد عليه، والفرق التي تتجاوزها تحصل على مسار إما يعطّل كل شيء وإما لا يحمي شيئاً.
ابدأ بما يوفره Odoo أصلاً
قبل أن تطلب أي تخصيص، راجع خطوات الموافقة المدمجة في التطبيقات التي تستخدمها، فبعضها لا يحتاج إلا إلى تفعيل إعداد:
- المشتريات. إعداد الموافقة على أوامر الشراء يطلب موافقة المدير على الأوامر التي تتجاوز حداً أدنى تحدده أنت.
- المصروفات. تُرفع تقارير المصروفات إلى المدير ليوافق عليها أو يرفضها قبل ترحيلها.
- الإجازات. يمكن ضبط كل نوع إجازة بحيث لا يحتاج إلى اعتماد، أو يعتمده مسؤول الإجازات، أو المسؤول المباشر عن الموظف، أو الاثنان معاً.
- تطبيق الموافقات. في إصدار Odoo Enterprise يتيح تطبيق Approvals تعريف أنواع من الطلبات، مثل طلب شراء أو رحلة عمل، مع تحديد الموافقين عليها بالاسم.
إن كان أحد هذه الخيارات يلبي الحاجة، فاضبطه ودرّب فريقك عليه. فخطوة الموافقة القياسية يتولى Odoo صيانتها عبر ترقيات الإصدارات، أما الخطوة المخصصة فصيانتها مسؤوليتك أنت.
متى يكون المسار المخصص مبرراً
تستحق الموافقات المخصصة مكانها حين تتوقف الخيارات القياسية عن مطابقة الطريقة التي تتخذ بها شركتك قراراتها فعلاً. ومن العلامات المعتادة:
- تحتاج إلى أكثر من مستوى، كرئيس القسم حتى مبلغ معين ثم المدير المالي لما فوقه.
- يتحدد الموافق حسب بيانات السجل نفسه: مركز التكلفة، أو الفرع، أو فئة المنتج، أو المشروع.
- المستند الذي تريد ضبطه لا توجد له خطوة موافقة في إعداداتك الحالية، مثل عرض سعر بخصم كبير على غير العادة، أو فاتورة مورد لا تطابق أمر الشراء الخاص بها.
- يشترط المدققون أو سياستك الداخلية سجلاً واضحاً لمن وافق على ماذا، ومتى.
اكتب القاعدة قبل أن تطلب المسار
طلب الموافقة الجيد يُقرأ كأنه سياسة، لا كأنه ميزة برمجية. ويجب أن يجيب عن الآتي:
- أي مستند، وفي أي مرحلة. عبارة «أوامر الشراء قبل تأكيدها» دقيقة، أما «المشتريات» فليست كذلك.
- ما الذي يستدعي الموافقة. مبلغ، أو نسبة، أو قيمة حقل معين، أو كل السجلات. وحدّد هل المبلغ شامل الضريبة، وأي عملة تُعتمد حين يكون المستند بعملة أخرى.
- من يوافق. دور أو مجموعة، لا شخص بعينه، حتى تصمد القاعدة أمام تغيّر الموظفين.
- الغياب والتفويض. من يوافق حين يكون الموافق غائباً؟ إن كانت الإجابة «لا أحد»، فستتراكم المستندات في أول أسبوع يسافر فيه أحدهم.
- الرفض. هل يعود المستند المرفوض إلى المسودة، أم يُلغى، أم يبقى مفتوحاً للتعديل؟ وهل ذكر السبب إلزامي؟
- التعديل بعد الموافقة. إن غيّر أحدهم المبلغ بعد الموافقة، فهل يحتاج المستند إلى موافقة جديدة؟ غالباً يجب ذلك، وهذه الحالة هي الأكثر نسياناً.
- وصول الموافقين إلى ما ينتظرهم. كيف يعرف الموافق ما ينتظر قراره: عبر الأنشطة، أو قائمة مصفّاة، أو البريد الإلكتروني.
التنبيه ليس بوابة
بعض الاحتياجات يمكن تلبيتها دون كتابة كود. فقواعد الأتمتة تستطيع إسناد نشاط مراجعة إلى المدير عند تغيّر حقل معين، وهذا يكفي غالباً حين يكون الهدف مجرد الإحاطة. لكن النشاط لا يوقف شيئاً، إذ يمكن تأكيد المستند بينما المراجعة لم تُقرأ بعد. فإن كان المطلوب ألا يتقدم المستند دون موافقة فاذكر ذلك صراحةً، لأن هذه بوابة، ويجب أن تُبنى وتُختبر على هذا الأساس.
كيف يجري ذلك على Plemo
على Plemo يبدأ طلب الموافقة بمحادثة، يطرح فيها الذكاء الاصطناعي أسئلة توضيحية، وهنا تُحسم بنود القائمة السابقة. كما يضيّق الطلبات الواسعة التي يصعب بناؤها جيداً دفعة واحدة، فتتحول عبارة «أضف موافقات على المشتريات والمبيعات» إلى مستند واحد وقاعدة واحدة يمكنك التحقق منهما أولاً. بعد ذلك توافق على مواصفات مكتوبة قبل أن يبدأ التطوير، فتكون السياسة موثقة، بما فيها سلوك الرفض وإعادة الموافقة.
يصل التغيير إلى بيئة تجريبية قبل أن يصل أي شيء إلى بيئة الإنتاج. اختبره بأدوار المستخدمين الحقيقية لا بحساب المسؤول وحده، لأن مسؤول النظام ينتمي عادةً إلى كل مجموعات الموافقة، فلا يرى ما يراه المستخدم العادي. ثم مرّ على كل المسارات: مبلغ تحت الحد، وآخر فوقه بقليل، وحالة رفض، وتعديل بعد الموافقة، ومستند بعملة ثانية. ولأن استخدام الذكاء الاصطناعي قائم على الأرصدة، فإن القاعدة محددة النطاق هي أيضاً الأقل تكلفة في البناء، وفي التعديل بعد أن يبدأ الفريق في استخدامها.
أخطاء شائعة
- اشتراط الموافقة على كل شيء. حين يحتاج كل مستند إلى توقيع، يبدأ الموافقون بالضغط دون قراءة، وتتحول الرقابة إلى إجراء شكلي.
- تسمية شخص بدلاً من دور. يتعطل المسار في اليوم الذي يغادر فيه ذلك الشخص أو يتغير منصبه.
- غياب مسار للحالات العاجلة. حدّد مسبقاً من يحق له الموافقة حين يتعذر الوصول إلى الموافق المعتاد.
- الاختبار بحساب المسؤول فقط. يبدو المسار سليماً حتى يصطدم به أول مستخدم حقيقي.
تقع قواعد الموافقة في نقطة التقاء تصميم الإجراءات مع التطوير، وأحياناً يكون الحل الصحيح تعديلاً في السياسة لا كوداً جديداً. ويمكن لفريق التطوير المخصص لدينا مساعدتك في تحديد الضوابط التي تنتمي إلى Odoo وتلك التي تنتمي إلى إجراءاتك الداخلية.