Skip to main content
اعتمادات المشتريات في أودو 20: متى تكفي قواعد Studio ومتى تحتاج إلى وحدة مخصصة
قراءة 11 دقيقة
أودو

اعتمادات المشتريات في أودو 20: متى تكفي قواعد Studio ومتى تحتاج إلى وحدة مخصصة

متى تكفي قواعد الاعتماد في أودو 20 Studio لاعتماد المشتريات، ومتى تحتاج إلى وحدة مخصصة تفرض السياسة عبر API والتكاملات، مع مصفوفة اختبار قبول عملية.

لبناء سير عمل لاعتماد المشتريات في أودو 20، ابدأ بآلية الاعتماد المتاحة أصلًا في قاعدة بياناتك، واستخدم Studio عندما يحتاج زرٌّ ما إلى موافقة مشروطة، ولا تلجأ إلى وحدة مخصصة إلا عندما يجب فرض قاعدة الأعمال عبر عدة نقاط دخول أو عندما تتطلب دورة حياة جديدة للاعتماد.

قد يبدو أن فريق مشتريات يطلب "اعتمادين لما يتجاوز 50,000 درهم" بحاجة إلى مشروع تطوير، وقد لا يكون الأمر كذلك. أما الفريق الذي يطلب "اعتماد المالية للمورّد الجديد، واعتماد صاحب الميزانية للمشروع، وألّا يُصدَر أي أمر شراء عبر API دون القرارين معًا" فلديه مشكلة مختلفة. فقاعدة مرتبطة بزر وسياسة أعمال قابلة للفرض ليستا أمرًا واحدًا يمكن تبديل أحدهما بالآخر.

وسؤال البداية المفيد ليس كم زرّ اعتماد نحتاج؟ بل ما الإجراء التجاري الذي يجب أن يظل مستحيلًا إلى أن تتحقق أي شروط؟

ثلاث طبقات مختلفة للاعتماد

لنأخذ شركة لديها مشترون ومديرو مشتريات ورؤساء أقسام ومراقب مالي. يمكن أن يتحول طلب عرض السعر (RFQ) إلى أمر شراء، وقد تترتب على ذلك آثار تشغيلية مثل الاستلامات والفواتير المستقبلية. والشركة تريد ضبط الأمر قبل أن يقع هذا الالتزام.

وهناك ثلاث طبقات محتملة:

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

تتضمن شيفرة تقارير المشتريات في أودو 20 حالة "بانتظار الاعتماد" (To Approve)، لكن ينبغي فحص الإعدادات والسلوك الفعليين لتطبيق المشتريات المثبّت في قاعدة بيانات أودو 20 الخاصة بك قبل تحديد حلٍّ يقتصر على الإعدادات. راجع شيفرة تقرير المشتريات الرسمية في الإصدار 20.0. فوجود حالةٍ ما ليس دليلًا على أن كل قاعدة اعتماد متعددة المستويات مقترحة مدعومة أصلًا.

ما الذي تفعله قواعد الاعتماد في أودو 20 Studio فعلًا

تصف وثائق قواعد الاعتماد في أودو 20 Studio قواعدَ مرتبطة بزر إجراء. إذ يستطيع المستخدم تعريف خطوة اعتماد على ذلك الزر، وإسنادها إلى معتمِد محدد أو أكثر أو إلى مجموعة معتمِدين، وتحديد الحالات التي تنطبق فيها الخطوة اختياريًا.

وهذا يجعل Studio مفيدًا لمتطلب واضح مثل:

قبل أن يؤكد المشتري عملية شراء عالية القيمة، يجب أن يعتمد مدير مشتريات محدد بالاسم إجراء التأكيد.

وللحالات الأكثر تعقيدًا، توثّق Studio خطوات إضافية وخيار ترتيب الاعتماد (Approval Order) الذي يسمح بترتيب الخطوات تسلسليًا. كما توثّق خيار الاعتماد الحصري (Exclusive Approval) الذي يهدف إلى منع المستخدم نفسه من اعتماد خطوة أخرى على السجل ذاته. وينبّه أودو إلى تفصيل مهم: يستطيع المستخدم المسؤول عن خطوة أعلى أن يعتمد خطوة سابقة أو يرفضها ما لم يُفعَّل الاعتماد الحصري. وهذا بالضبط نوع التفاصيل التي ينبغي لاختبار الفصل بين المهام أن يتحقق منها بدلًا من افتراضها.

قد يتلقى المعتمِدون أنشطة، ويمكنهم الاعتماد أو الرفض، كما يمكنهم ضمن القواعد الموثّقة تفويض صلاحيات الاعتماد. وتُتتبَّع القرارات في سجل المحادثة (chatter) الخاص بالسجل وعبر سجلات اعتماد Studio (Studio Approval Entries)، وفقًا للوثائق نفسها الخاصة بهذا الإصدار.

ولذلك فإن Studio يقدّم أكثر من مجرد زر مخفي أو إشعار: فهو يضيف تفاعل اعتماد موثّقًا وأثرًا ظاهرًا للقرارات.

مثال عملي

لنفترض أن شركة اتفقت على السياسة المقترحة التالية:

  • المشتريات حتى 10,000 درهم تتبع الإجراء المعتاد للمشتري.
  • من 10,000.01 درهم إلى 50,000 درهم، يعتمدها مدير المشتريات.
  • ما يتجاوز 50,000 درهم يعتمده كلٌّ من مدير المشتريات والمراقب المالي.
  • لا يجوز أن يتخذ الشخص نفسه القرارين المطلوبين معًا.

هذه قواعد توضيحية خاصة بالشركة، وليست إعدادات افتراضية في أودو.

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

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

نشاط الاعتماد ليس هو نفسه الفرض

يوثّق أودو أيضًا قواعد الأتمتة في الإصدار 20.0. فيمكن لقاعدة أتمتة مثلًا أن تُنشئ نشاطًا بعد تغيّر قيمة حقل ما. وقد يفيد ذلك في التذكيرات وتوجيه العمل.

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

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

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

متى تصبح الوحدة المخصصة في أودو الخيار الأكثر أمانًا

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

1. المعتمِدون يعتمدون على عدة أبعاد حية

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

وقد تنص مواصفات السياسة على ما يلي:

text
IF purchase crosses a configured company threshold
AND supplier is new or bank details were changed
THEN require purchasing + finance approvals
AND forbid self-approval
BEFORE purchase commitment can occur.

هذا مثال تصميمي فقط، وليس شيفرة أودو قابلة للتنفيذ ولا قاعدة مدمجة في أودو 20.

2. قد تنتهي صلاحية الاعتماد أو يصبح متقادمًا

تخيّل أن مديرًا اعتمد 30,000 درهم، ثم غيّر المشتري المورّد أو رفع المبلغ إلى 85,000 درهم. هل ينبغي أن يظل الاعتماد الأصلي ساريًا؟

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

ومن الحقول المفيدة في تصميم مخصص مقترح: المبلغ المعتمَد، والمورّد، والعملة، والمستخدم المعتمِد، ووقت القرار، ومرجع إلى القيم أو النسخة التي اعتُمدت. وينبغي أن يتبع تصميم البيانات النهائي أعراف أودو وأن يُراجَع على الإصدار المستهدف.

3. يمكن للأنظمة الخارجية إنشاء السجل أو تأكيده

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

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

4. الاعتماد يتطلب أكثر من قرار بنعم أو لا

ومن الأمثلة: حالات الرفض لإعادة العمل، والمعتمِدون البدلاء، والتصعيد عند تجاوز المهلة، وحجز الميزانية، والتحقق من اكتمال المرفقات، وإجراء واضح للاستثناءات في المشتريات العاجلة.

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

الاختيار بين Studio والشيفرة قرار استضافة واشتراك أيضًا

تُدرج صفحة الأسعار الحالية في أودو أودو Studio (Odoo Studio) ضمن خطة Custom وتميّزها عن خطة Standard. تأكد من الخطة الفعلية والترتيب التعاقدي قبل افتراض أن Studio متاح أو إضافته إلى قاعدة بيانات الإنتاج.

ويؤثر نموذج النشر في التخصيص أيضًا. فOdoo Online (Odoo Online) وOdoo.sh والتثبيتات المستضافة ذاتيًا لا تقدّم مسارات توسيع متطابقة. وتتطلب الإضافة المخصصة المكتوبة بـ Python عمومًا مسار استضافة يدعم الوحدات المخصصة، بينما يوفر Studio نهجه الخاص للإعداد داخل التطبيق.

وهذا لا يعني أن كل قاعدة بيانات على خطة Custom ينبغي أن تستخدم الشيفرة. ففي سياسة اعتماد بسيطة ومستقرة، يكون تقليل الشيفرة غالبًا قرار الصيانة الأفضل. لكنه لا يعني أيضًا أن Studio يلغي الحاجة إلى الاختبار أو المراجعة الأمنية.

صمّم السياسة قبل الضغط على أي إعداد

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

السؤالمثال على القرار الذي يجب توثيقه
ما الذي يُصرَّح به؟تحويل طلب عرض السعر (RFQ) إلى أمر شراء ملزِم
ما الذي يستدعي اعتمادًا إضافيًا؟تجاوز الإجمالي حدًّا معينًا، أو كون المورّد مضافًا حديثًا
أي مبلغ؟المبلغ الشامل للضريبة بعملة الشركة
من المخوَّل؟مدير المشتريات أولًا، ثم المراقب المالي
هل يمكن للشخص نفسه الاعتماد مرتين؟لا
من يمكنه طلب تغييرات؟المشتري أو المعتمِد
ما الذي يُلغي الاعتماد السابق؟تغيّر المورّد أو العملة أو المبلغ أو البنود الحرجة
ماذا يحدث للاستثناءات العاجلة؟مسار طوارئ منفصل معتمَد صراحةً
ما الواجهات المشمولة؟واجهة الويب، وAPI، والمهام المجدولة، وبوابة الجوال
ما الدليل؟القرار، والمنفّذ، ووقت القرار، والسياق، ونسخة السجل

السياسة المفيدة هي التي يستطيع فريق المالية قراءتها، ويستطيع فريق المشتريات اتباعها، ويستطيع فريق الهندسة تحويلها إلى اختبارات حتمية.

حالات الحدود في العتبات ليست اختيارية

كثيرًا ما تفشل القواعد المبنية على العتبات عند الحدود. فإذا استطاع المشتري تجاوز مراجعة المالية بتغيير المبلغ من 50,000.01 إلى 50,000.00، فهل هذا صحيح؟ وكيف يُتعامَل مع تحويلات العملات في أوامر الشراء بالعملات الأجنبية؟ وماذا لو تغيّر الإجمالي بسبب إعادة احتساب ضريبة أو خصم؟ وماذا يحدث إذا قُسِّمت عملية الشراء إلى عدة أوامر أصغر؟

لا ينبغي حل كل خطر داخل زر اعتماد واحد. فبعض المخاطر يتطلب سياسة للميزانية، أو تحليلًا للمشتريات، أو إجراء استثناءات لمنع التجزئة. وينبغي أن يعكس النظام سياسة أعمال محددة بدلًا من أن يخترع سياسة.

مصفوفة واقعية لاختبارات قبول الاعتماد

اختبر هذه الحالات في قاعدة بيانات ضمن بيئة الاختبار المرحلية تحاكي الأدوار والشركات المقصودة. ولا تُجرِ اختبار الضوابط بصفة مسؤول النظام فقط.

حالة الاختبارالنتيجة المتوقعة
طلب عرض سعر دون العتبة من مشترٍ مخوَّليتبع الإجراء المعتاد الموثّق
عند العتبة بالضبطيتبع الحد المتفق عليه شاملًا/غير شامل
طلب عرض سعر فوق العتبة دون اعتمادلا يمكنه إكمال الانتقال المحمي
اعتمد المعتمِد الأول ولم يعتمد الثاني بعديظل محظورًا حتى تكتمل القرارات المطلوبة
المستخدم نفسه يحاول تنفيذ الخطوتين الحصريتينيُرفَض وفقًا للسياسة
المعتمِد المطلوب يرفضلا يتقدم؛ مع مسار واضح لإعادة التقديم
المشتري يغيّر الإجمالي/المورّد بعد الاعتماديُحتفَظ بالاعتماد السابق أو يُعاد ضبطه كما هو محدد تمامًا
المدير يفوّض الاعتمادتعمل الصلاحيات المفوَّضة ضمن النطاق والمدة المعتمَدين فقط
المستخدم يدخل إلى شركة ثانيةينطبق المعتمِد والعتبة الصحيحان الخاصان بالشركة
API أو تكامل يستدعي العملية المحميةتنطبق الضوابط الإلزامية نفسها، أو يُستثنى المسار عمدًا ويُوثَّق
أتمتة مجدولة تعمل أثناء اعتماد معلّقلا تُصدِر عملية شراء غير مصرّح بها
اعتمادات متزامنة أو إعادة محاولاتلا انتقالات حالة مكررة ولا اعتمادات مفقودة
قاعدة بيانات مرقّاة / وحدة معدّلةيظل سير العمل يعمل بعد اختبارات الانحدار

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

أخطاء شائعة في التنفيذ

إعداد المعتمِد متابعًا فقط. فمتابعة المستند أو تلقي نشاط لا يمنح صلاحية إصدار عملية الشراء.

بناء الشرط على المبلغ الخطأ. فمقارنة عتبات بعملة الشركة بقيم بعملة المستند قد توجّه الأوامر توجيهًا خاطئًا. حدّد الأساس قبل إعداد القاعدة.

بقاء الاعتماد ساريًا بعد تعديل جوهري. قد تظن الشركة أن المراقب المالي اعتمد أمر الشراء الجديد، بينما لم يعتمد إلا نسخة سابقة.

قدرة المعتمِدين في المستويات الأعلى على إكمال الخطوات الأدنى أيضًا. تنص وثائق Studio في أودو 20 صراحةً على هذا السلوك ما لم يُطبَّق الاعتماد الحصري. تحقّق من الفصل بين المهام في إعداداتك الخاصة. المصدر.

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

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

أي نهج ينبغي أن تختار؟

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

يوفر أودو 20 لبنات مفيدة للاعتماد. والقرار الهندسي هو معرفة أين تنتهي هذه اللبنات وأين تبدأ سياسة الضبط الفعلية لدى الشركة.

لسير عمل المشتريات الذي يشمل عدة شركات أو تطبيقات جوال مخصصة أو عمليات تكامل خارجية، يمكن أن تساعد خدمات تخصيص أودو وتكامله من Octivex في تحويل سياسة الاعتماد إلى نطاق تنفيذ قابل للاختبار قبل أن يغيّر أحدٌ إعدادات بيئة الإنتاج.