نظام الموافقات - الدليل الشامل لتعريف الموافقة

نظرة عامة

يوفر نظام موافقات Nama ERP حلاً شاملاً لإدارة سير العمل يتيح للمؤسسات تعريف عمليات الموافقة لمختلف العمليات التجارية. يضمن هذا النظام التفويض الملائم والرقابة على المعاملات التجارية الحيوية قبل إتمامها.

المزايا الرئيسية

• تصميم مرن لسير العمل: إنشاء سير عمل موافقات مخصصة لأي نوع كيان
• موافقات متعددة المراحل: دعم لعمليات الموافقة المتعددة والمعقدة
• منطق قائم على القواعد: تطبيق قواعد الموافقة بناءً على شروط عمل محددة
• إشعارات فورية: إشعارات تلقائية عبر البريد الإلكتروني والرسائل القصيرة والرسائل داخل التطبيق
• سجل مراجعة: تتبع كامل لقرارات الموافقة والتعليقات

المفاهيم الأساسية

تعريف الموافقة (Approval Definition)

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

• الكيان المستهدف (Target Entity): نوع السجل الذي يتطلب موافقة (فواتير، أوامر شراء، إلخ)
• خطوات الموافقة (Approval Steps): مراحل الموافقة المتسلسلة أو المتوازية
• الأطراف المسؤولة (Responsible Parties): من يمكنه الموافقة في كل خطوة
• الشروط (Conditions): متى يجب تفعيل الموافقة
• قوالب الإشعارات (Notification Templates): كيفية إخطار المعتمِدين

حالة الموافقة (Approval Case)

عندما تستوفي معاملة ما معايير الموافقة، تُنشأ حالة موافقة تلقائياً. تمثل هذه الحالة طلب موافقة نشطاً يتتبع:

• الحالة الراهنة (Current Status): قيد التنفيذ، مقبولة، مرفوضة، أو مُعادة
• خطوات الموافقة (Approval Steps): سجل القرارات التي اتخذها كل معتمِد
• المرشحون التاليون (Next Candidates): من يحتاج إلى التصرف بعد ذلك
• المعلومات الملخصة (Summary Information): تفاصيل رئيسية حول المعاملة التي تتطلب موافقة

البدء

الوصول إلى تعريفات الموافقة

انتقل إلى: الأساسيات > الإعدادات > تعريف موافقه (Basic > Settings > Approval Definition)

إنشاء تعريف الموافقة الأول

1. المعلومات الأساسية

   • الكود (Code): معرّف فريد لتعريف الموافقة
   • الاسم (Name): اسم وصفي (مثل "موافقة الفاتورة فوق 10,000")
   • الكيان المستهدف (Target Entity): اختر نوع الكيان الذي يتطلب موافقة

2. شروط الموافقة

   • Use With Insert: تطبيق عند إنشاء سجلات جديدة
   • Use With Update: تطبيق عند تعديل السجلات الموجودة
   • Use With Delete: تطبيق عند حذف السجلات
   • Use With Budget Exceeded: تطبيق عند تجاوز المعاملات حدود الميزانية
   • Apply When Query: استعلام SQL لتحديد متى تكون الموافقة مطلوبة

3. تعريف خطوات الموافقة

   • إضافة خطوات موافقة متسلسلة
   • تعيين موظفين أو أدوار مسؤولة
   • ضبط فترات التصعيد الزمنية
   • تهيئة خيارات القرار (موافقة، رفض، إرجاع، إلخ)

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

تطلب التنفيذ (Require Execution)

عند تفعيل Require Execution، يضيف النظام تلقائياً خطوة تنفيذ نهائية بعد اكتمال جميع خطوات الموافقة. تتطلب هذه الخطوة من مُنشئ الموافقة (Approval Initiator) الأصلي (الشخص الذي أنشأ/عدّل السجل) تأكيد التنفيذ النهائي.

سلوك خطوة التنفيذ

• الإضافة التلقائية: يضيف النظام خطوة التنفيذ برقم تسلسلي بعد آخر خطوة موافقة
• الطرف المسؤول: يُعيَّن دائماً لمُنشئ الموافقة (مقدم الطلب الأصلي)
• الغرض: يضمن أن الشخص الذي طلب الموافقة يؤكد التنفيذ النهائي
• حالة الاستخدام: شائعة في السيناريوهات التي تتطلب فيها المعاملات المعتمدة تأكيداً نهائياً قبل المعالجة

مثال لمسار العمل مع Require Execution:

1. User creates Invoice → Approval triggered
2. Manager approves → Next step
3. Finance Director approves → All approvals complete
4. System creates "Execution Step" → Assigns back to original user
5. Original user confirms execution → Document is committed

التأكيد قبل البدء (Confirm Before Starting)

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

ميزات مربع حوار التأكيد

• لغة Tempo: استخدام حقلَي arabicConfirmation وenglishConfirmation مع صيغة قوالب Tempo
• المحتوى الديناميكي: دعم مراجع الحقول من العنصر المعتمَد (مثل {totalAmount} و{code} و{department})
• خيار المستخدم: يمكن للمستخدمين النقر على "تأكيد" للمتابعة أو "إلغاء" لإيقاف عملية الموافقة
• دعم اللغات: يعرض الرسالة المناسبة بناءً على تفضيل لغة المستخدم

أمثلة رسائل التأكيد مع المحتوى الديناميكي:

Arabic Confirmation:
"تأكيد: هل أنت متأكد من طلب الموافقة على {entityType} رقم {code} بمبلغ {totalAmount} للقسم {department.name1}؟"

English Confirmation:
"Confirmation: Are you sure you want to request approval for {entityType} #{code} with amount {totalAmount} for department {department.name2}?"

Static Example:
Arabic: "تأكيد: هذا المبلغ كبير، هل تريد المتابعة؟"
English: "Confirmation: This is a large amount, do you want to proceed?"

الحقول الديناميكية المتاحة:

• حقول الكيان (Entity Fields): أي حقل من السجل المراد اعتماده (مثل {totalAmount} و{customerName})
• حقول النظام (System Fields): حقول مدمجة مثل {code} و{entityType} و{creationDate}
• حقول الكيان المرتبط (Related Entity Fields): حقول الكيان المرجعي باستخدام الترميز النقطي (مثل {department.name1} و{customer.creditLimit})
• القيم المحسوبة (Calculated Values): حسابات مخصصة أو قيم منسقة

المراجعة عند الاكتمال (Revise On Completion)

عند تفعيل Revise On Completion، يضع النظام تلقائياً علامة "مراجَع" على السجل بعد اكتمال عملية الموافقة بنجاح. يوفر هذا طبقة إضافية من سلامة البيانات ورقابة المراجعة.

التعديل أثناء الموافقة (Modify While Under Approval)

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

خيارات الإعداد:

Allow Modify While Under Approval (إعداد عام):

• عند التعطيل (الافتراضي): لا يمكن تعديل السجلات أثناء عملية الموافقة
• عند التفعيل: يمكن تعديل السجلات بناءً على إعدادات السياسة أدناه

Modify While Under Approval Policy (لكل خطوة): يدعم النظام ثلاث سياسات مختلفة للتحكم في التعديلات أثناء الموافقة:

سياسات التعديل

1. Allow For Authorized Users (الافتراضي)

   • يمكن للمستخدمين الذين لديهم صلاحية EditUnderApproval تعديل السجل
   • يتطلب إذن أمان محدداً
   • الخيار الأكثر مرونة للموظفين المخوَّلين

2. Allow For Authorized And Can Approve

   • يجب أن يمتلك المستخدمون صلاحية EditUnderApproval وأن يكونوا مؤهلين للموافقة على الخطوة الحالية
   • أكثر تقييداً - يمكن فقط لمعتمِدي الخطوة الحالية إجراء التعديلات
   • يضمن إجراء التعديلات من قِبل المسؤولين عن الموافقة

3. Prevent Modify

   • لا يُسمح بأي تعديلات بغض النظر عن أذونات المستخدم
   • أعلى مستوى أمان لخطوات الموافقة الحرجة
   • يتجاوز الإعداد العام allowModifyWhileUnderApproval

التحكم في التعديل على مستوى الحقل (Field-Level Editing Control)

بالإضافة إلى الإعداد العام allowModifyWhileUnderApproval، يوفر النظام تحكماً دقيقاً على مستوى الحقل في ما يمكن تعديله أثناء الموافقة. يتيح هذا للمؤسسات السماح بتعديل حقول معينة مع إبقاء حقول أخرى مقفلة.

خيارات الإعداد:

Allow Editing Fields (لكل خطوة):

• اسم الحقل: allowEditingFields
• الصيغة: قائمة مفصولة بفواصل من معرّفات الحقول
• النطاق: ينطبق على خطوة الموافقة المحددة
• سلوك الواجهة: تبقى الحقول المدرجة فقط قابلة للتعديل؛ تُعطَّل جميع الحقول الأخرى

كيف يعمل التحكم على مستوى الحقل:

منطق تعديل الحقل

User attempts to edit field during approval:
1. Check if approval is pending
2. Check if current step has allowEditingFields configured
3. If configured:
   - Listed fields → Remain editable
   - Unlisted fields → Become disabled
4. If not configured:
   - Fall back to modifyWhileUnderApprovalPolicy
5. Apply security validation for authorized users

أمان OTP (كلمة مرور لمرة واحدة)

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

خيارات الإعداد:

Require OTP For All Steps (إعداد عام):

• عند التفعيل: تتطلب جميع خطوات الموافقة التحقق عبر OTP
• ينطبق على كل خطوة في تعريف الموافقة
• يتجاوز إعدادات الخطوة الفردية

Require OTP (إعداد لكل خطوة):

• عند التفعيل: تتطلب خطوة الموافقة المحددة التحقق عبر OTP
• يسمح بمتطلب OTP انتقائي للخطوات الحساسة

تطلب موافقة الجميع (Require All Approvers)

عند تعيين مسؤوليات الموافقة لعدة موظفين في وقت واحد (إما عبر مجموعات الموظفين أو المسؤوليات الخاصة أو مرشحين متعددين)، يتحكم إعداد Require All Approvers في ما إذا كان يجب على جميع الموظفين المعيَّنين الموافقة قبل اعتبار الخطوة مكتملة.

خيارات الإعداد:

Require All Approvers (إعداد لكل خطوة):

• اسم الحقل: requireAllApprovers (يتطلب موافقة الجميع)
• النوع: Boolean (نعم/لا)
• الافتراضي: معطَّل (يمكن لأي معتمِد منفرد إتمام الخطوة)

كيف يعمل:

السلوك الافتراضي (Require All Approvers = معطَّل)

عند التعطيل (السلوك الافتراضي):

• يعيّن النظام خطوة الموافقة لمرشحين متعددين
• يمكن لأي واحد من المرشحين الموافقة
• بمجرد أن يوافق أحد المرشحين، تُعتبر الخطوة مكتملة
• ينتقل سير عمل الموافقة فوراً إلى الخطوة التالية
• لا يُطلب من المرشحين الآخرين التصرف بعد الآن

Require All Approvers = مفعَّل

عند التفعيل:

• يعيّن النظام خطوة الموافقة لمرشحين متعددين
• يجب على جميع المرشحين الموافقة قبل اكتمال الخطوة
• يوافق كل مرشح بشكل مستقل
• بعد كل موافقة، يزيل النظام ذلك المرشح من القائمة
• تبقى الخطوة قيد التنفيذ حتى يوافق جميع المرشحين
• فقط بعد استلام جميع الموافقات ينتقل سير العمل إلى الخطوة التالية

الإعداد المتقدم

الموافقات الشرطية

استخدم Criteria Definition وApply When Query لإنشاء مشغلات موافقة متطورة:

-- Example: Approve invoices above 50,000 SAR
SELECT case when {totalAmount} > 50000 then 1 else 0 end

قواعد الموافقة (Approval Rules)

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

كيف تعمل قواعد الموافقة

1. تقييم القاعدة: عند حفظ مستند، تُقيَّم القواعد المرفقة
2. فحص التطبيق: تحدد كل قاعدة ما إذا كانت تنطبق على المعاملة الحالية
3. اكتشاف السطر: يمكن للقواعد تحديد الأسطر المحددة التي أدت إلى الموافقة
4. تشغيل الموافقة: إذا انطبقت أي قاعدة، تبدأ عملية الموافقة
5. معلومات السياق: تُخزَّن الأسطر المشغِّلة في $map.approvalRuleLines للاستخدام في القوالب

القواعد المدمجة المتاحة

قواعد الموافقة الشائعة

يتضمن النظام عدة قواعد جاهزة لسيناريوهات المبيعات والمشتريات:

قواعد أسعار المبيعات:

• BelowMinSalesPriceApprovalRule: يُشغَّل عند البيع بأقل من الحد الأدنى المسموح به للسعر
• BelowDefaultSalesPriceApprovalRule: يُشغَّل عند البيع بأقل من السعر القياسي
• AboveMaxSalesPriceApprovalRule: يُشغَّل عند تجاوز السعر الحد الأقصى
• MaxUserDiscountPercentageApprovalRule: يُشغَّل عند تجاوز الخصم النسبة المسموح بها للمستخدم

قواعد أسعار المشتريات:

• AboveLastPricePurchasesApprovalRule: يُشغَّل عند تجاوز سعر الشراء آخر سعر شراء

تهيئة قواعد الموافقة

الخطوة 1: إضافة القواعد إلى تعريف الموافقة في تعريف الموافقة، أضف القواعد في قسم "القواعد":

• الاختيار من القواعد المتاحة لنوع كيانك
• تُقيَّم القواعد بالتسلسل
• يجب أن تجتاز جميع القواعد حتى يُتجاوز الاعتماد

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

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

{if($map.approvalRuleLines)}
<h3>Lines Requiring Approval:</h3>
<table>
  <tr><th>Item</th><th>Price</th><th>Reason</th></tr>
  {loop($map.approvalRuleLines)}
    <tr>
      <td>{link($map.approvalRuleLines.item.item)}</td>
      <td>{$map.approvalRuleLines.price.unitPrice}</td>
      <td>Price below minimum threshold</td>
    </tr>
  {endloop}
</table>
{endif}

موافقات تجاوز الميزانية (Budget Exceeded Approvals)

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

كيف تعمل موافقات الميزانية

1. التحقق من الميزانية: عند حفظ مستند، يتحقق النظام مما إذا كان يولّد قيوداً محاسبية تتجاوز حدود الميزانية
2. الإعداد على مستوى الحساب: يمكن إعداد كل حساب بسلوك تجاوز الميزانية:
   • Prevent Saving: حظر المعاملة كلياً
   • Request Approval: السماح بالحفظ مع اشتراط الموافقة قبل الإلزام
3. الفحص الديناميكي: يأخذ التحقق من الميزانية في الاعتبار أبعاداً متعددة (القسم، الفرع، الفترة المالية، إلخ)

متطلبات الإعداد

المتطلبات الأساسية

لكي تعمل موافقات الميزانية، تأكد من إعداد ما يلي:

1. تفعيل موافقات الميزانية: تعيين Enable Approvals For Budgets إلى true في الإعدادات العامة
2. تعريفات الميزانية: إنشاء سجلات ميزانية في النظام للحسابات ذات الصلة
3. إعداد الحساب: تعيين budgetExceededBehavior على الحسابات إلى "Request Approval"
4. تعريف الموافقة: إنشاء تعريف موافقة مع useWithBudgetExceeded = true

عملية التحقق من الميزانية

يجري النظام هذه الفحوصات عند حفظ المستندات:

منطق التحقق من الميزانية

1. توليد قيود محاسبية مؤقتة للمستند
2. المقارنة مع تخصيصات الميزانية الموجودة
3. التحقق مما إذا كانت المعاملة ستتجاوز حدود الميزانية
4. مراعاة إعداد budgetExceededBehavior للحساب
5. إذا كان "Request Approval" ← تشغيل سير عمل الموافقة
6. إذا كان "Prevent Saving" ← حظر المعاملة مع إظهار خطأ

أبعاد الميزانية المعتبرة

يمكن للتحقق من الميزانية مراعاة أبعاد تنظيمية متعددة:

• شركة (Legal Entity): ميزانيات على مستوى الشركة
• السنة/الفترة المالية (Fiscal Year/Period): تخصيص الميزانية على أساس زمني
• القسم (Department): حدود الإنفاق الإدارية
• الفرع (Branch): ميزانيات على أساس الموقع
• القطاع (Sector): ضوابط على مستوى الأقسام
• مجموعة التحليل (Analysis Set): تجميعات تحليلية مخصصة
• فروع الحسابات (Account Subsidiaries): ميزانيات على مستوى الحساب الفرعي

الأطراف المسؤولة الديناميكية

تهيئة توجيه الموافقة بناءً على:

• التسلسل الهرمي التنظيمي: سلاسل موافقة المشرف
• القائم على القسم: التوجيه إلى مديري الأقسام
• القائم على الحقل: استخدام حقول الموظفين من المعاملة
• المحددات المخصصة: منطق متقدم لاختيار المعتمِد

المعتمِدون البدلاء (Alternate Approvers)

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

أنواع البدلاء

1. المعتمِد البديل (Alternate) - موظف منفرد

• الإعداد: تحديد موظف واحد بوصفه بديلاً عاماً
• النطاق: يمكنه الموافقة على أي خطوة في عملية الموافقة
• حالة الاستخدام: تعيين نائب أو معتمِد احتياطي لسير العمل بأكمله

2. بدلاء آخرون (Other Alternates) - قائمة ديناميكية

• الإعداد: استخدام محددات SpecialResponsible لتحديد البدلاء ديناميكياً
• النطاق: يمكنهم الموافقة على أي خطوة بناءً على معايير ديناميكية
• الخيارات:
  • Initiator: الشخص الذي أنشأ/عدّل المستند
  • Supervisor: المشرف المباشر لمُنشئ الطلب
  • Field-based: الموظفون المشار إليهم في حقول المستند
  • Custom Logic: الاختيار الديناميكي بناءً على قواعد الأعمال

الفرق عن الاحتياطي (Fallback)

تمييز مهم

• Fallback: يُستخدم فقط عندما لا يستطيع النظام تحديد المعتمِد المعتاد (معالجة الأخطاء)
• Alternate: متاح دائماً للموافقة جنباً إلى جنب مع المعتمِدين المعتادين (مرونة الأعمال)
• Other Alternates: بدلاء محددون ديناميكياً بناءً على السياق

حقول مرجع الموافقة (Approval Reference Fields)

يوفر نظام الموافقات حقلَي مرجع اختياريَّين يمكن استخدامهما لتخزين معلومات سياقية إضافية حول السجلات المعتمدة. تساعد هذه المراجع في التصفية وإعداد التقارير والحصول على معلومات إضافية حول حالة الموافقة.

الإعداد:

Approval Reference 1 Source (approvalRef1Source) وApproval Reference 2 Source (approvalRef2Source):

• نوع الحقل: FieldID (محدد الحقل)
• المصدر: اختيار أي حقل مرجع أو مرجع عام من الكيان المعتمَد
• الغرض: تعبئة approvalRef1 وapprovalRef2 تلقائياً في حالة الموافقة
• التوافر: يراعي السياق بناءً على كيان الموافقة وإعدادات "Apply Also To"

كيف تعمل حقول المرجع

1. إعداد المصدر: في تعريف الموافقة، اختر الحقول المصدر من الكيان المعتمَد
2. التعبئة التلقائية: عند إنشاء حالة الموافقة، تُنسخ القيم من الحقول المصدر
3. التصفية: استخدام approvalRef1 وapprovalRef2 لتصفية حالات الموافقة في القوائم
4. إعداد التقارير: تضمين المراجع في تقارير وملخصات الموافقة
5. معلومات السياق: الوصول إلى البيانات ذات الصلة دون التنقل إلى السجل المعتمَد
6. يدعم صيغة Field Values Calculator مثلاً sql(select entityType,id from Table where x= {y})

أمثلة حالات الاستخدام:

• موافقات العملاء: تخزين مرجع العميل لتصفية الموافقات الخاصة بالعملاء
• تتبع القسم: ربط الموافقات بالأقسام لإعداد التقارير الإدارية
• ارتباط المشروع: تتبع الموافقات حسب المشروع لإدارة المشاريع
• القائم على الموقع: تصفية الموافقات حسب الفرع أو المخزن
• التجميع حسب الفئة: تجميع الموافقات حسب فئة المنتج أو نوع الخدمة

اعتبار تاريخ الطلب كتاريخ الإنشاء (Consider Request Date As Creation Date)

بشكل افتراضي، يعيّن النظام creationDate للسجل عند اكتمال خطوة الموافقة النهائية وإلزام السجل. ومع ذلك، يغيّر خيار considerRequestDateAsCreationDate هذا السلوك ليستخدم تاريخ طلب الموافقة بدلاً من ذلك.

إعداد ملخص الموافقة (Approval Summary Configuration)

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

خيارات توليد الملخص:

1. ملخص الكيان الافتراضي

• إذا لم يُعدَّ ملخص مخصص، يستخدم النظام الطريقة المدمجة summaryForApproval() للكيان
• يوفر معلومات أساسية حول السجل
• صيغة قياسية عبر جميع كيانات من نفس النوع

2. قالب ملخص مخصص

• summaryTemplate: يستخدم لغة Tempo لإنشاء ملخصات منسقة
• الوصول إلى جميع حقول الكيان والبيانات ذات الصلة
• تنسيق مرن مع دعم HTML
• محتوى ديناميكي بناءً على بيانات السجل

3. ملخص قائم على الاستعلام

• summaryQuery: استعلام SQL لجمع بيانات محددة للملخص
• summaryTemplate: قالب يعالج نتائج الاستعلام
• قوي للملخصات المعقدة التي تتطلب بيانات محسوبة أو تجميعات

4. مسح قبل الملخص (Flush Before Summary)

• flushBeforeSummary: يفرض إلزام قاعدة البيانات قبل توليد الملخص
• يضمن حفظ جميع التغييرات قبل حساب الملخص
• مطلوب عندما يعتمد الملخص على بيانات قد لا تكون محفوظة بعد
• استخدم فقط مع summaryQuery

دليل الإعداد خطوة بخطوة

الخطوة 1: تعريف الإعدادات الأساسية

الحقل	الوصف
Approval Entity	نوع السجل المراد اعتماده
Priority	ترتيب المعالجة عند تطابق تعريفات متعددة
Use With Insert	التشغيل عند السجلات الجديدة
Use With Update	التشغيل عند التعديلات
Comment Required	إلزام المعتمِدين بإضافة تعليقات
Require Execution	إضافة خطوة تنفيذ نهائية لمُنشئ الطلب
Confirm Before Starting	عرض مربع حوار تأكيد قبل بدء الموافقة
Revise On Completion	تمييز السجل كمراجَع بعد الموافقة (يقفل التعديل/الحذف)
Allow Modify While Under Approval	السماح بتعديل السجلات أثناء عملية الموافقة
Require OTP For All Steps	اشتراط التحقق عبر OTP لجميع قرارات الموافقة
Fallback	الموظف للتعامل مع أخطاء النظام (مطلوب)
Alternate	الموظف الذي يمكنه الموافقة على أي خطوة
Other Alternates	بدلاء ديناميكيون (المشرف، القائم على الحقل، إلخ)
Approval Reference 1 Source	الحقل المصدر لمرجع الموافقة الأول (approvalRef1Source)
Approval Reference 2 Source	الحقل المصدر لمرجع الموافقة الثاني (approvalRef2Source)
Consider Request Date As Creation Date	استخدام تاريخ طلب الموافقة كتاريخ إنشاء السجل
Summary Template	قالب Tempo لملخصات الموافقة المخصصة
Summary Query	استعلام SQL لجمع بيانات توليد الملخص
Flush Before Summary	إلزام التغييرات في قاعدة البيانات قبل توليد الملخص

الخطوة 2: إعداد خطوات الموافقة

1. إضافة خطوات الموافقة

   • تسلسل الخطوة: 1، 2، 3، إلخ
   • اسم الخطوة: "موافقة مدير القسم"
   • الحالة المطلوبة: يجب على جميع المرشحين الموافقة

2. تعيين المسؤوليات

   • التعيين المباشر: موظف محدد
   • القائم على الدور: المسمى الوظيفي أو دور القسم
   • الديناميكي: بناءً على بيانات المعاملة

3. تعيين خيارات القرار

   • Approve: الانتقال إلى الخطوة التالية
   • Reject: إيقاف العملية والرفض
   • Return: إعادة الإرسال للتعديلات
   • Escalate: إحالة إلى المشرف

إعداد قرار الموافقة العام (Global Approval Decision Configuration)

يوفر النظام خيارات إعداد عامة للتحكم في قرارات الموافقة المتاحة في سير عمل الموافقات. تُعدَّل هذه الإعدادات في الإعدادات العامة (Global Configuration) وتؤثر على جميع عمليات الموافقة على مستوى النظام.

خيارات إعداد القرارات المتاحة

خيار الإعداد	الاسم بالعربية	الاسم بالإنجليزية	الوصف
useRejectDecision	استعمال قرار الرفض	Use Reject Decision	يتحكم في توافر خيار قرار "Reject" (رفض)
useReturnDecision	استعمال قرار الارجاع	Use Return Decision	يتحكم في توافر خيار قرار "Return" (إرجاع)
useEscalateToSupervisor	استخدام قرار تصعيد الي المدير المباشر	Use Escalate To Supervisor	يتحكم في توافر خيار "Escalate to Supervisor" (تصعيد الي المدير المباشر)
useEscalateToSpecificEmployee	استخدام قرار تصعيد الي موظف بعينه	Use Escalate To Specific Employee	يتحكم في توافر خيار "Escalate to Specific Employee" (تصعيد الي موظف بعينه)
useReturnToPreviousStep	استخدام قرار إرجاع إلي الخطوة السابقة	Use Return To Previous Step	يتحكم في توافر خيار "Return to Previous Step" (إرجاع للخطوة السابقة)

تأثير الإعداد

عند تعطيل خيارات القرار:

• لن يظهر القرار المقابل في القائمة المنسدلة للموافقة
• لا يمكن للمعتمِدين اختيار ذلك النوع من القرار
• تعريفات الموافقة الحالية التي تعتمد على القرارات المعطَّلة قد تكون محدودة الوظائف
• سيعرض النظام فقط خيارات القرار المفعَّلة

سيناريوهات مثالية:

1. عملية موافقة مبسطة: تعطيل خياري "Return" و"Escalate" للسماح فقط بـ"Approve" أو"Reject"
2. سياسة عدم الرفض: تعطيل "Reject" لإجبار المعتمِدين على استخدام "Return" للتعديلات
3. هرمي فقط: تعطيل "Escalate to Specific Employee" لفرض تصعيد صارم عبر المشرف

اعتبارات الإعداد

• تعطيل خيارات القرار يؤثر على جميع عمليات الموافقة على مستوى النظام
• تأكد من توافق تعريفات الموافقة مع مجموعة القرارات المفعَّلة
• ضع في الاعتبار تأثير التغييرات على سير عمل الموافقة الموجودة قبل تطبيقها
• قد تتطلب بعض عمليات الموافقة أنواعاً محددة من القرارات لتعمل بشكل صحيح

الخطوة 3: إعداد الإشعارات

قوالب البريد الإلكتروني

إعداد إشعارات البريد الإلكتروني التلقائية مع:

• Email Template: قالب HTML لطلبات الموافقة
• Email Subject: سطر موضوع ديناميكي
• Additional Recipients: إرسال نسخة لأصحاب المصلحة الآخرين

إشعارات الرسائل القصيرة

• SMS Template: صيغة الرسالة النصية
• Mobile Number Source: معلومات الاتصال بالموظف

الإشعارات داخل التطبيق

• Notification Template: صيغة الرسالة داخل النظام
• FCM Templates: الإشعارات الفورية لتطبيقات الجوال

الخطوة 4: الميزات المتقدمة

مراقبة الحقول الحرجة (Critical Fields Monitoring)

تتبع تغييرات حقول محددة تستلزم إعادة الموافقة:

• تغييرات المبالغ تجاوزاً للحد المسموح
• تعديلات التواريخ الرئيسية
• تحديثات حقل الحالة

التصعيد التلقائي (Auto-escalation)

تعيين حدود زمنية لخطوات الموافقة:

• Auto Escalate After: الفترة الزمنية (ساعات/أيام)
• Escalation Target: المشرف أو موظف محدد

مطلوب جدول مهام (Task Schedule)

لكي يعمل التصعيد التلقائي، يجب إنشاء Task Schedule بالإعداد التالي:

• Schedule Type: Action
• Class Name: اختيار أحد الخيارين:
  • EAAutoEscalateApprovalToSupervisor - يصعّد إلى المشرف المباشر للمعتمِد
  • EAAutoEscalateApprovalToFallBackEmployee - يصعّد إلى الموظف الاحتياطي المحدد في تعريف الموافقة
• Schedule Frequency: يوصى بالتشغيل كل 15-30 دقيقة للتحقق من الموافقات المتأخرة

سير عمل المستخدم

لمُنشئي المعاملات

1. إنشاء/تعديل السجل: إدخال بيانات المعاملة بصورة عادية
2. حفظ السجل: يتحقق النظام من متطلبات الموافقة
3. تشغيل الموافقة: إذا تحققت المعايير، تُنشأ حالة موافقة
4. إرسال الإشعار: يتلقى المعتمِدون الإشعارات
5. تتبع الحالة: مراقبة تقدم الموافقة في المعاملة

للمعتمِدين

1. استلام الإشعار: تنبيه عبر البريد الإلكتروني أو الرسائل القصيرة أو داخل التطبيق
2. مراجعة الطلب: الوصول إلى تفاصيل الموافقة وملخص المعاملة
3. اتخاذ القرار: موافقة، رفض، إرجاع، أو تصعيد
4. إضافة تعليقات: تقديم مبرر للقرار
5. الإرسال: يُسجَّل القرار ويستمر سير العمل

إجراءات الموافقة المتاحة

الإجراء	الوصف	الخطوة التالية
Approve	قبول الطلب	الانتقال إلى خطوة الموافقة التالية
Reject	رفض الطلب	إيقاف سير العمل وإخطار مُنشئه
Return	إعادة للتعديلات	السماح بالتعديلات وإعادة تشغيل الموافقة
Escalate to Supervisor	إحالة إلى المدير	يصبح المدير المعتمِد التالي
Escalate to Specific Employee	إحالة إلى شخص محدد	يوافق الموظف المحدد

نظام الإشعارات

أنواع الإشعارات

1. إشعارات البريد الإلكتروني
   • روابط موافقة مدمجة
   • دعم المرفقات
2. رسائل SMS
3. الإشعارات داخل التطبيق
4. الإشعارات الفورية (Push)
   • تنبيهات تطبيق الجوال

قوالب الإشعارات

تستخدم القوالب لغة Tempo لعرض المحتوى الديناميكي. تتمتع القوالب بالوصول إلى الكائن $notificationInfo الذي يحتوي على:

• $notificationInfo.employee - الموظف الذي يجب أن يوافق
• $notificationInfo.approvalCase - تفاصيل حالة الموافقة الكاملة
• $notificationInfo.otp - رمز OTP للموافقة (إذا تم إعداده)

مثال قالب البريد الإلكتروني:

<h2>Approval Required: {entityType} #{code}</h2>
<p>Dear {$notificationInfo.employee.name2},</p>

<p>Please review and approve the following {entityType}:</p>
<ul>
    <li><strong>Document:</strong> {link(this)} (#{code})</li>
    <li><strong>Amount:</strong> {totalAmount}</li>
    <li><strong>Department:</strong> {department.name2}</li>
    <li><strong>Date:</strong> {$creationDate}</li>
    <li><strong>Current Step:</strong> {$notificationInfo.approvalCase.nextStepName2}</li>
</ul>

{if($notificationInfo.otp)}
<p><strong>Security Code (OTP):</strong> {$notificationInfo.otp}</p>
{endif}

<h3>Summary:</h3>
<p>{$notificationInfo.approvalCase.summary}</p>

<h3>Actions:</h3>
<table>
    <tr>
        <td>{approvelink}</td>
        <td>{rejectlink}</td>
        <td>{returnlink}</td>
    </tr>
</table>

مثال قالب الرسائل القصيرة:

{$notificationInfo.employee.name2}: Approval needed for {entityType} #{code}
Amount: {totalAmount}
OTP: {$notificationInfo.otp}

{approvelink}
{rejectlink}

قالب الإشعار داخل التطبيق:

<strong>Approval Request</strong>{enter}
{entityType} #{code} requires your approval{enter}
Amount: {totalAmount}{enter}
Department: {department.name1}{enter}
{enter}
{titledlink("View Details", this)}

متغيرات Tempo المتاحة لقوالب الموافقة

متغيرات السياق

تتمتع جميع قوالب الإشعارات بالوصول إلى كائنات السياق والمتغيرات التالية:

حقول المستند:

• الوصول المباشر للحقل: {code} و{totalAmount} و{creationDate} إلخ
• حقول الكيان المرتبط: {customer.name1} و{department.code} إلخ
• حقول النظام: {entityType} و{firstAuthor} و{currentVersion}

كائن NotificationInfo ($notificationInfo):

• $notificationInfo.employee - الموظف الذي يجب أن يوافق
• $notificationInfo.approvalCase - كائن حالة الموافقة الكامل
• $notificationInfo.approvalCase.summary - ملخص الموافقة
• $notificationInfo.approvalCase.requestedBy - من طلب الموافقة
• $notificationInfo.approvalCase.nextStepName1 - اسم الخطوة الحالية بالعربية
• $notificationInfo.approvalCase.nextStepName2 - اسم الخطوة الحالية بالإنجليزية
• $notificationInfo.otp - رمز OTP (إذا تم إعداده)
• $notificationInfo.concernedLines - الأسطر التي تتطلب موافقة

روابط إجراءات الموافقة:

• {approvelink} - رابط/زر للموافقة
• {rejectlink} - رابط/زر للرفض
• {returnlink} - رابط/زر للإرجاع للتعديلات
• {escalatelink} - رابط/زر للتصعيد

الوصول إلى بيانات حالة الموافقة في قوالب الإشعارات

في قوالب الإشعارات (البريد الإلكتروني، الرسائل القصيرة، الإشعارات داخل التطبيق، إلخ)، يمكنك الوصول إلى معلومات حالة الموافقة التفصيلية باستخدام بادئة currentApprovalCase. يتيح هذا عرض سجل الموافقة والقرارات السابقة ومعلومات المرشح ورموز OTP في إشعاراتك.

حقول ApprovalCase المتاحة

الوصول إلى معلومات حالة الموافقة باستخدام {currentApprovalCase.<field>}:

معلومات الخطوة:

• {currentApprovalCase.$lastStep} - آخر خطوة موافقة
• {currentApprovalCase.$firstStep} - أول خطوة موافقة
• {currentApprovalCase.nextStepSequence} - الرقم التسلسلي للخطوة الحالية
• {currentApprovalCase.nextStepName1} - اسم الخطوة الحالية بالعربية
• {currentApprovalCase.nextStepName2} - اسم الخطوة الحالية بالإنجليزية

معلومات المرشح:

• {currentApprovalCase.$firstCandidate} - المرشح الأول في الخطوة الحالية
• {currentApprovalCase.$secondCandidate} - المرشح الثاني
• {currentApprovalCase.$thirdCandidate} - المرشح الثالث
• {currentApprovalCase.$fourthCandidate} - المرشح الرابع
• {currentApprovalCase.$fifthCandidate} - المرشح الخامس

حالة الموافقة:

• {currentApprovalCase.state} - حالة الموافقة الحالية (InProgress, Approved, Rejected, Returned)
• {currentApprovalCase.requestedBy} - الموظف الذي بدأ الموافقة
• {currentApprovalCase.requestDate} - وقت طلب الموافقة
• {currentApprovalCase.completionDate} - وقت اكتمال الموافقة
• {currentApprovalCase.summary} - نص ملخص الموافقة
• {currentApprovalCase.approvalRef1} - مرجع الموافقة الأول (إذا تم إعداده)
• {currentApprovalCase.approvalRef2} - مرجع الموافقة الثاني (إذا تم إعداده)

حقول ApprovalCaseStep

الوصول إلى تفاصيل الخطوة من $lastStep أو $firstStep أو مراجع خطوات أخرى:

• {currentApprovalCase.$lastStep.decision} - القرار المتخذ (Approve, Reject, Return, إلخ)
• {currentApprovalCase.$lastStep.actualResponsible} - الموظف الذي اتخذ القرار
• {currentApprovalCase.$lastStep.approvalDate} - وقت اتخاذ القرار
• {currentApprovalCase.$lastStep.comment} - التعليق المقدم مع القرار
• {currentApprovalCase.$lastStep.approvalStepName1} - اسم الخطوة بالعربية
• {currentApprovalCase.$lastStep.approvalStepName2} - اسم الخطوة بالإنجليزية
• {currentApprovalCase.$lastStep.approvalReason} - سبب الموافقة (إذا تم تقديمه)
• {currentApprovalCase.$lastStep.escalated} - ما إذا كانت الخطوة قد صُعِّدت
• {currentApprovalCase.$lastStep.escalatedFrom} - من صعَّدها
• {currentApprovalCase.$lastStep.escalateTo} - من صُعِّدت إليه

حقول ApprovalCaseStepCandidate

الوصول إلى تفاصيل المرشح من $firstCandidate أو $secondCandidate إلخ:

• {currentApprovalCase.$firstCandidate.candidate} - الموظف المرشح
• {currentApprovalCase.$firstCandidate.concernedLines} - الأسطر المعيَّنة لهذا المرشح
• {currentApprovalCase.$firstCandidate.otp} - رمز OTP لهذا المرشح (إذا فُعِّل OTP)
• {currentApprovalCase.$firstCandidate.requestedOn} - وقت تعيين المرشح
• {currentApprovalCase.$firstCandidate.escalated} - ما إذا كان قد صُعِّد إلى هذا المرشح
• {currentApprovalCase.$firstCandidate.escalatedFrom} - المعتمِد الأصلي الذي صعَّد
• {currentApprovalCase.$firstCandidate.source} - مصدر تعيين المسؤولية
• {currentApprovalCase.$firstCandidate.responsibility} - نوع المسؤولية

أمثلة عملية لقوالب الإشعارات

مثال 1: عرض رمز OTP

{if(currentApprovalCase.$firstCandidate.otp)}
<p>Your Security Code (OTP): <strong>{currentApprovalCase.$firstCandidate.otp}</strong></p>
{endif}

مثال 2: عرض قرار المعتمِد السابق وتعليقه

{if(currentApprovalCase.$lastStep)}
<h3>Previous Approval Step:</h3>
<p><strong>Approved By:</strong> {currentApprovalCase.$lastStep.actualResponsible.name2}</p>
<p><strong>Decision:</strong> {currentApprovalCase.$lastStep.decision}</p>
<p><strong>Date:</strong> {currentApprovalCase.$lastStep.approvalDate}</p>
{if(currentApprovalCase.$lastStep.comment)}
<p><strong>Comment:</strong> {currentApprovalCase.$lastStep.comment}</p>
{endif}
{endif}

مثال 3: عرض معلومات التصعيد

{if(currentApprovalCase.$firstCandidate.escalated)}
<p style="color: orange;">
    <strong>Note:</strong> This approval was escalated from {currentApprovalCase.$firstCandidate.escalatedFrom.name2}
</p>
{endif}

مثال 4: عرض جميع المرشحين الحاليين

<h3>Awaiting Approval From:</h3>
<ul>
{if(currentApprovalCase.$firstCandidate)}
    <li>{currentApprovalCase.$firstCandidate.candidate.name2}</li>
{endif}
{if(currentApprovalCase.$secondCandidate)}
    <li>{currentApprovalCase.$secondCandidate.candidate.name2}</li>
{endif}
{if(currentApprovalCase.$thirdCandidate)}
    <li>{currentApprovalCase.$thirdCandidate.candidate.name2}</li>
{endif}
</ul>

مثال 5: قالب بريد إلكتروني كامل مع سجل الموافقة

<h2>Approval Request: {entityType} #{code}</h2>
<p>Dear {$notificationInfo.employee.name2},</p>

<h3>Document Details:</h3>
<ul>
    <li><strong>Document:</strong> {link(this)}</li>
    <li><strong>Amount:</strong> {totalAmount}</li>
    <li><strong>Requested By:</strong> {currentApprovalCase.requestedBy.name2}</li>
    <li><strong>Request Date:</strong> {currentApprovalCase.requestDate}</li>
</ul>

{if(currentApprovalCase.$lastStep)}
<h3>Previous Approval:</h3>
<p>{currentApprovalCase.$lastStep.actualResponsible.name2} - {currentApprovalCase.$lastStep.decision} on {currentApprovalCase.$lastStep.approvalDate}</p>
{if(currentApprovalCase.$lastStep.comment)}
<p><em>"{currentApprovalCase.$lastStep.comment}"</em></p>
{endif}
{endif}

{if(currentApprovalCase.$firstCandidate.otp)}
<h3>Security Code (OTP):</h3>
<p style="font-size: 24px; font-weight: bold; color: #2196F3;">{currentApprovalCase.$firstCandidate.otp}</p>
{endif}

<h3>Summary:</h3>
<p>{currentApprovalCase.summary}</p>

<p>{approvelink} {rejectlink} {returnlink}</p>

حالات استخدام currentApprovalCase

• عرض OTP: عرض كلمات المرور لمرة واحدة للمرشحين في الإشعارات
• سجل الموافقة: عرض قرارات الموافقة السابقة والتعليقات
• تنبيهات التصعيد: الإشارة إلى وقت التصعيد ومن قام به
• إشعارات المرشحين المتعددين: عرض جميع المرشحين الذين ينتظرون الموافقة
• سجل المراجعة: تضمين سلسلة الموافقة الكاملة في إشعارات البريد الإلكتروني
• معلومات السياق: عرض أسماء الخطوات والتواريخ والأطراف المسؤولة

الموافقات القائمة على الميزانية

Account Setup:
- Expense Accounts → budgetExceededBehavior = "Request Approval"
- Budget Limits → Department/Branch level allocation
- Approval Flow → Department Head → Finance Manager

Process:
Document Creation → Budget Check → Approval (if exceeded) → Commitment

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

IF (Amount > 50,000 OR Customer = "High Risk" OR Payment Terms > 60 days)
THEN Require: Credit Manager + Finance Director approval

نصائح الأداء

• تحسين الاستعلامات: تأكد من أداء Apply When Query بكفاءة
• المعالجة الدفعية: تجميع الموافقات المتشابهة لتحقيق الكفاءة
• أرشفة الحالات القديمة: الحفاظ على أداء النظام بسياسات الاحتفاظ بالبيانات
• مراقبة نقاط الاختناق: تحديد وحل تأخيرات الموافقة

استكشاف الأخطاء وإصلاحها

المشكلات الشائعة

المشكلة	السبب	الحل
لم يُشغَّل الاعتماد	المعايير غير محققة	مراجعة Apply When Query والشروط
تعيين معتمِد خاطئ	إعداد طرف مسؤول غير صحيح	التحقق من إعداد مسؤوليات الخطوة
الإشعارات لم تُرسَل	مشكلة في القالب أو معلومات الاتصال	التحقق من قوالب البريد الإلكتروني وبيانات الموظفين
الموافقة عالقة	معتمِد مفقود أو خطأ في النظام	التحقق من حالة حالة الموافقة وقواعد التصعيد
موافقة الميزانية لا تعمل	إعداد مفقود	التحقق من إعدادات الميزانية وإعداد الحساب والإعدادات العامة

إدارة النظام

مراقبة الموافقات

• مراجعة منتظمة لحالات الموافقة المعلقة
• مراقبة أداء استعلامات الموافقة
• تحليل سجل المراجعة للامتثال
• تحليل الميزانية مقابل الإنفاق الفعلي

مهام الصيانة

• أرشفة حالات الموافقة المكتملة
• تحديث مسؤوليات الموظفين
• تحديث ذاكرة التخزين المؤقت لتعريف الموافقة
• مراجعة وتحسين قوالب الإشعارات
• تحديث تخصيصات الميزانية دورياً

نقاط التكامل

الأنظمة الخارجية

يمكن لنظام الموافقات التكامل مع:

• خوادم البريد الإلكتروني: إعداد SMTP للإشعارات
• بوابات الرسائل القصيرة: مزودو خدمة SMS من جهات خارجية
• تطبيقات الجوال: خدمات الإشعارات الفورية
• أنظمة BI: مقاييس الموافقة وإعداد التقارير
• أنظمة الميزانية: تتبع استهلاك الميزانية في الوقت الفعلي

وصول API

الوصول البرمجي لـ:

• إنشاء حالات الموافقة
• الاستعلام عن حالة الموافقة
• تقديم قرارات الموافقة
• توليد تقارير الموافقة
• فحوصات التحقق من الميزانية

سجل الإجراءات وسجل المراجعة

يُنشئ النظام تلقائياً سجلات مراجعة تفصيلية لجميع أنشطة الموافقة من خلال نظام سجل الإجراءات. يوفر هذا تتبعاً شاملاً لقرارات الموافقة وتقدم سير العمل.

السلوك الافتراضي لسجل الإجراءات

بشكل افتراضي، يُنشئ النظام سجل إجراءات واحداً عند اكتمال عملية الموافقة بأكملها:

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

التتبع المحسّن خطوة بخطوة

للمؤسسات التي تتطلب سجلات مراجعة تفصيلية، يدعم النظام التتبع الدقيق لكل خطوة موافقة من خلال خيار الإعداد العام:

خيار الإعداد: addApprovalStepsToActionHistory (إضافة خطوات الموافقة إلى سجل الإجراءات)

عند التفعيل، يُنشئ هذا الخيار سجل إجراءات لـكل خطوة موافقة فردية:

ميزات التتبع المحسّن

• سجلات الخطوات الفردية: إدخال مراجعة منفصل لكل قرار موافقة
• أنواع القرارات المتتبعة:
  • Approve - عند اعتماد خطوة
  • Reject - عند رفض خطوة
  • Return - عند الإرجاع للتعديلات
  • Escalate - عند التصعيد إلى مشرف/موظف محدد
• سجل الاكتمال النهائي: لا يزال يُنشئ سجل Approval القياسي عند اكتمال سير العمل
• سياق المستخدم: يلتقط من اتخذ كل قرار ومتى

اعتبارات الأمان

التحكم في الوصول

• الأذونات القائمة على الأدوار: التحكم في من يمكنه إنشاء/تعديل تعريفات الموافقة
• التحقق من المعتمِد: التحقق من تفويض المعتمِد لكل خطوة
• تسجيل المراجعة: تتبع جميع أنشطة الموافقة من خلال سجل الإجراءات
• فصل البيانات: احترام الحدود التنظيمية
• الوصول إلى الميزانية: التحكم في رؤية معلومات الميزانية

ميزات الامتثال

• التوقيعات الرقمية: دعم تكامل التوقيع الإلكتروني
• سياسات الاحتفاظ: الحفاظ على سجلات الموافقة وفق المتطلبات التنظيمية
• تقارير المراجعة: توليد وثائق الامتثال
• التحكم في الإصدار: تتبع التغييرات في تعريفات الموافقة
• فصل المهام: ضمان الفصل المناسب للضوابط المالية

الخاتمة

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

يضمن التكامل مع إدارة الميزانية الانضباط المالي مع توفير المرونة للتعامل مع الظروف الاستثنائية من خلال عملية الموافقة.

الخطوات التالية

1. ابدأ بتعريفات موافقة بسيطة للمعاملات عالية التأثير
2. إعداد موافقات الميزانية لحسابات المصروفات الحيوية
3. تدريب المستخدمين الرئيسيين على عمليات الموافقة القياسية وموافقات الميزانية
4. مراقبة أداء النظام وملاحظات المستخدمين
5. التوسع تدريجياً لتشمل عمليات أعمال إضافية
6. مراجعة وتحسين منتظمان لسير عمل الموافقة وتخصيصات الميزانية

للدعم الإضافي أو أسئلة الإعداد المتقدم، استشر مدير النظام أو تواصل مع دعم Nama ERP.