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

نظرة عامة

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

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

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

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

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

تعريف موافقة

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

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

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

البدء

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

انتقل إلى: إدارة النظام ← تخصيص شكل النظام ← تعريف موافقه (Administration → Display Customization → Approval Definition)

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

المعلومات الأساسية
- الكود (Code): معرّف فريد لتعريف الموافقة
- الاسم (Name): اسم وصفي (مثل "موافقة الفاتورة فوق 10,000")
- نوع الملف/المستند (Approval Entity): اختر نوع الكيان الذي يتطلب موافقة
شروط الموافقة
- Use With Insert: تطبيق عند إنشاء سجلات جديدة
- Use With Update: تطبيق عند تعديل السجلات الموجودة
- Use With Delete: تطبيق عند حذف السجلات
- Use With Budget Exceeded: تطبيق عند تجاوز المعاملات حدود الميزانية
- Apply When Query: استعلام SQL لتحديد متى تكون الموافقة مطلوبة
تعريف خطوات الموافقة
- إضافة خطوات موافقة متسلسلة
- تعيين موظفين أو أدوار مسؤولة
- تهيئة خيارات القرار (موافقة، رفض، إرجاع، إلخ)

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

تطلب التنفيذ (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
المحتوى الديناميكي: دعم مراجع الحقول من العنصر المعتمَد (مثل {money.netValue} و{code} و{department})
خيار المستخدم: يمكن للمستخدمين النقر على "تأكيد" للمتابعة أو "إلغاء" لإيقاف عملية الموافقة
دعم اللغات: يعرض الرسالة المناسبة بناءً على تفضيل لغة المستخدم

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

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

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

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

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

حقول الكيان (Entity Fields): أي حقل من السجل المراد اعتماده، باسم الحقل البرمجي (مثل {money.netValue} لصافي الفاتورة أو الأمر، و{customer.name1}). وتجد أسماء حقول كل شاشة في dm.namasoft.com
حقول النظام (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 (لكل خطوة): يدعم النظام ثلاث سياسات مختلفة للتحكم في التعديلات أثناء الموافقة:

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

Allow For Authorized Users (الافتراضي)
- يمكن للمستخدمين الذين لديهم صلاحية EditUnderApproval تعديل السجل
- يتطلب إذن أمان محدداً
- الخيار الأكثر مرونة للموظفين المخوَّلين
Allow For Authorized And Can Approve
- يجب أن يمتلك المستخدمون صلاحية EditUnderApproval وأن يكونوا مؤهلين للموافقة على الخطوة الحالية
- أكثر تقييداً - يمكن فقط لمعتمِدي الخطوة الحالية إجراء التعديلات
- يضمن إجراء التعديلات من قِبل المسؤولين عن الموافقة
Prevent Modify
- لا يُسمح بأي تعديلات بغض النظر عن أذونات المستخدم
- أعلى مستوى أمان لخطوات الموافقة الحرجة
- يتجاوز خيار Allow Modify While Under Approval في التعريف

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

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

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

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 لإنشاء مشغلات موافقة متطورة:

sql

-- مثال على تعريف موافقة لأمر الشراء: اعتماد الأوامر التي تتجاوز 50,000
SELECT CASE WHEN {money.netValue} > 50000 THEN 1 ELSE 0 END

الأسماء بين الأقواس هي أسماء حقول السجل المراد اعتماده، وتجدها لكل شاشة في dm.namasoft.com. وصافي الفاتورة أو الأمر هو money.netValue. وإذا كتبت اسمًا ليس من حقول السجل أعاد الاستعلام 0، فلا تبدأ الموافقة أبدًا.

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

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

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

تقييم القاعدة: عند حفظ مستند، تُقيَّم القواعد المرفقة
فحص التطبيق: تحدد كل قاعدة ما إذا كانت تنطبق على المعاملة الحالية
اكتشاف السطر: يمكن للقواعد تحديد الأسطر المحددة التي أدت إلى الموافقة
تشغيل الموافقة: إذا انطبقت أي قاعدة، تبدأ عملية الموافقة
معلومات السياق: تُخزَّن الأسطر المشغِّلة في $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)

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

ما يحدث عند التجاوز يُقرَّر لكل حساب على حدة، بحقل عندما يتم تجاوز الموازانة في الحساب (راجع «ضبط الموازنة على الحساب» في صفحة الحسابات): منع الحفظ يرفض المستند صراحةً، وطلب موافقة يرسله إلى الموافقة، وسماح يتركه يمر.

لكي يعمل طلب موافقة:

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

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

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

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

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

لإسناد خطوة إلى دور أو إلى «مدير فرع المستند» بدلاً من شخص بعينه، انظر المسئوليات والمسئول المخصص والتفويض.

مثال عملي: توجيه التحويل المخزني إلى المخزن المستلم

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

أنشئ تعريف موافقة لـسند التحويل (StockTransfer).
أضف خطوة واحدة واجعل نوع المسئول فيها من حقل.
في حقل الخطوة اكتب أصحاب الموافقة في جهة الاستلام، مفصولين بفاصلة:

toWarehouse.warehouseKeeper,toWarehouse.warehouseKeeper.directSupervisor

يذهب الطلب الآن إلى أمين المخزن المستلم وإلى مديره المباشر، فيتبع كل تحويل التسلسل الإداري للمخزن الذي يصل إليه.

ملف JSON للاستيراد المباشر

json

{
  "approvalEntity": "StockTransfer",
  "steps": [
    {
      "stepSeq": 1,
      "name1": "موافقة أمين المخزن",
      "responsible": {
        "responsibleType": "Field",
        "fieldId": "toWarehouse.warehouseKeeper,toWarehouse.warehouseKeeper.directSupervisor"
      }
    }
  ]
}

افتح تعريف موافقة جديدًا، ثم المزيد ← Import Into Current Record والصق الملف — راجع الاستيراد إلى السجل الحالي.

نوع المسئول = استعلام: قائمة ثابتة من استعلام

اجعل نوع المسئول في الخطوة استعلام عندما يكون أسهل وصف للمعتمِدين أنه شرط على الموظفين، مثل كل موظفي إدارة معينة. ويأخذ حقل الاستعلام في الخطوة استعلام HQL يختار سجلات الموظفين (Employee):

select e from Employee e where e.department.code = '01'

كل موظف يُرجعه الاستعلام يصبح مرشحاً للخطوة، ويُضاف إليهم بدلاء التعريف. ويكتب HQL أسماء الكيانات وحقولها (Employee وe.department.code) لا أسماء الجداول والأعمدة (department_id). ولا يستقبل الاستعلام علامات {fieldId}، فيُرجع الأشخاص أنفسهم لكل سجل؛ أما لاختيار المعتمِدين من بيانات السجل نفسه فاستخدم من حقل كما في المثال السابق.

المعتمِدون البدلاء (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"

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

إعداد المصدر: في تعريف الموافقة، اختر الحقول المصدر من الكيان المعتمَد
التعبئة التلقائية: عند إنشاء حالة الموافقة، تُنسخ القيم من الحقول المصدر
التصفية: استخدام approvalRef1 وapprovalRef2 لتصفية حالات الموافقة في القوائم
إعداد التقارير: تضمين المراجع في تقارير وملخصات الموافقة
معلومات السياق: الوصول إلى البيانات ذات الصلة دون التنقل إلى السجل المعتمَد
يدعم صيغة 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 لجميع قرارات الموافقة
الموافقة للسطور (Approve Lines)	طلب الموافقة على السطور التي تستوفي شروط التعريف بدلًا من السجل كله، ويبتّ المعتمِدون في هذه السطور
عند رفض سطر يتم حذفه (Reject Line Delete It)	حين تنتهي الحالة بالموافقة تُحذف من السجل السطور التي رفضها أحد المعتمِدين. ولا يقبله إلا نوع سجل يدعم الموافقة على مستوى السطر
السماح بالتعديل بعد الاستخدام (Allow Edit After Usage)	يسمح بتعديل هذا التعريف ما دامت هناك سجلات مبنية عليه تنتظر الموافقة، وبدونه يُرفض هذا الحفظ
طلب ملاحظة في روابط الموافقة (Request Comment In Approval Links)	يُطلب من المعتمِد الذي يبتّ من روابط بريد الموافقة أن يكتب ملاحظة
تجاهل صلاحيات الاستخدام عند الموافقة (Ignore Usage Capability When Approving)	حين يحفظ قرارُ المعتمِد السجلَّ لا تُفحص صلاحيات الاستخدام لدى المعتمِد على السجلات التي يشير إليها
حذف باقي مسئولين الموافقة عند التصعيد (Remove Other Employees From approval When Escalate)	حين يصعّد المعتمِد الخطوة إلى موظف بعينه يُستبعد باقي المرشحين على الخطوة، فلا يبتّ فيها إلا الموظف المُصعَّد إليه
WhatsApp Message والمرسل المفضل لواتساب وTelegram Message	إرسال الطلب إلى كل معتمِد أيضًا عبر واتساب أو تيليجرام
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، 2، 3، إلخ
- اسم الخطوة: "موافقة مدير القسم"
- الحالة المطلوبة: يجب على جميع المرشحين الموافقة
تعيين المسؤوليات
- التعيين المباشر: موظف محدد
- القائم على الدور: المسمى الوظيفي أو دور القسم
- الديناميكي: بناءً على بيانات المعاملة
تعيين خيارات القرار
- Approve: الانتقال إلى الخطوة التالية
- Reject: إيقاف العملية والرفض
- Return: إعادة الإرسال للتعديلات
- تصعيد إلى المدير الأعلي (Escalate to Supervisor): تسليم الخطوة إلى المدير الأعلي للمعتمِد
- تصعيد إلى المشرف المباشر (Escalate to Direct Supervisor): تسليم الخطوة إلى المشرف المباشر للمعتمِد
- تصعيد الي موظف بعينه (Escalate to Specific Employee): تسليم الخطوة إلى شخص يختاره المعتمِد

الخطوات المشروطة (الاختيارية)

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

يمكن أن تحمل كل خطوة موافقة شرطها الخاص عبر حقلين:

معايير الخطوة (Step Criteria): تعريف المعايير محفوظ يُبنى عبر باني المعايير المرئي.
استعلام تطبيق الخطوة (Step Apply When Query): استعلام SQL يُرجع ما إذا كانت الخطوة تنطبق على السجل.

القاعدة بسيطة:

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

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

sql

-- مثال على خطوة: اطلب هذه الخطوة فقط عندما يتجاوز الإجمالي 100,000
SELECT CASE WHEN {money.netValue} > 100000 THEN 1 ELSE 0 END

يُعتبر المستند محفوظاً عندما لا تنطبق آخر خطوة اختيارية

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

يجب أن تنطبق خطوة واحدة على الأقل

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

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

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

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

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

جميع هذه الخيارات مفعَّلة افتراضياً — فالنظام الجديد يتيح كل القرارات إلى أن تقوم بتعطيل ما لا تريده.

طريقتان للتصعيد إلى أعلى

التصعيد يعني تسليم خطوتك إلى شخص آخر بدلاً من البت فيها بنفسك، ويوفر النظام مسارين هرميين لأن سجل الموظف يحتوي على مديرَين منفصلين:

القرار	يقرأ حقل الموظف	المعنى المعتاد
تصعيد إلى المدير الأعلي (Escalate to Supervisor)	المدير الأعلي (Supervisor)	المدير الأعلى في التسلسل التنظيمي — الشخص الذي يعلو المسؤول المباشر عن المعتمِد
تصعيد إلى المشرف المباشر (Escalate to Direct Supervisor)	المشرف المباشر (Direct Supervisor)	المسؤول المباشر الذي يتبعه المعتمِد في عمله اليومي

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

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

يجب أن يكون الحقل المستهدف معبَّأ

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

الأسباب والملحوظات تغطي القرارين معاً

أسباب الموافقة المعلَّم عليها تستخدم مع التصعيد (Used With Escalation) تظهر مع قرارات التصعيد الثلاثة جميعاً، كما أن إعدادَي الخطوة يجب إدخال ملحوظة مع التصعيد ويجب إدخال السبب مع التصعيد يسريان على التصعيد إلى المدير الأعلي وإلى المشرف المباشر على حد سواء. فلا حاجة إلى قائمة أسباب منفصلة لكل مسار تصعيد.

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

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

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

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

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

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

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

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

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

تُضبط الرسائل المرسلة إلى معتمِدي كل خطوة في تبويب متقدم:

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

ولإرسال نسخة من بريد الموافقة في خطوة ما إلى عناوين من خارج قائمة المعتمِدين، املأ ارسال الايميلات الي العناوين في سطر تلك الخطوة من جدول الخطوات.

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

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

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

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

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

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

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

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

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

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

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

للمعتمِدين

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

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

الإجراء	الوصف	الخطوة التالية
Approve	قبول الطلب	الانتقال إلى خطوة الموافقة التالية
Reject	رفض الطلب	إيقاف سير العمل وإخطار مُنشئه
Return	إعادة للتعديلات	السماح بالتعديلات وإعادة تشغيل الموافقة
تصعيد إلى المدير الأعلي (Escalate to Supervisor)	إحالة إلى المدير الأعلي للمعتمِد	يصبح ذلك المدير مرشحاً على نفس الخطوة
تصعيد إلى المشرف المباشر (Escalate to Direct Supervisor)	إحالة إلى المشرف المباشر للمعتمِد	يصبح ذلك المشرف مرشحاً على نفس الخطوة
تصعيد الي موظف بعينه (Escalate to Specific Employee)	إحالة إلى شخص محدد	يوافق الموظف المحدد
إرجاع للخطوة السابقة (Return To Previous Step)	إعادة الحالة خطوة إلى الوراء	يقرر معتمِد الخطوة السابقة من جديد
إرجاع لخطوة محددة (Return To A Specific Step)	إعادة الحالة إلى خطوة تسمّيها	يقرر معتمِد تلك الخطوة من جديد

الإجراءات في هذه الشاشات

القرارات السابقة هي ما يختاره المعتمِد. وهذه هي الأزرار التي توصله إليها، وهي على شاشات السجلات العادية لا على شاشة تعريف الموافقة نفسها.

الموافقة على السجلات المختارة (Approve Selected Lines) — القرار المجمَّع، ويُعرض في شاشة قائمة أي كيان خاضع للموافقة. أشّر على السطور المعلَّقة واضغطه، فتحسمها نافذة واحدة. املأ ما يحتاجه القرار — تصعيد إلى (موظف أو صلاحية أو مجموعة موظفين) والرقم السري المؤقت حيث تطلبه الخطوة وملاحظات للتسبيب وسبب الموافقة — ثم اضغط القرار نفسه: في النافذة زر موافقة وزر رفض وزر إرجاع. وبقية القرارات خلف زر قرار آخر، الذي يفتح نافذة ثانية فيها زر لكل قرار. ويرفض العمل إن لم تؤشّر على شيء. والقرارات المتاحة هنا ستة من الثمانية: موافقة، ورفض، وإرجاع، وتصعيد إلى المدير الأعلي، وإرجاع للخطوة السابقة، وتصعيد الي موظف بعينه — أما إرجاع لخطوة محددة وتصعيد إلى المشرف المباشر فلا يتاحان إلا على سجل واحد في كل مرة، لأن كليهما يقتضي النظر في قائمة خطوات الحالة نفسها أولًا.
إلغاء طلب الموافقة (Revoke Approval Request) — يلغي طلب الموافقة المعلَّق ويخرج السجل من دورة الموافقات. ويعمل على السجل الذي أنت فيه، أو على كل سطر أشّرت عليه في القائمة.
نقل الموافقات إلى الموظف المفوض (Move Approvals To Delegated Employee) — في شاشة التفويض. احفظ التفويض وأشّر على السطور، فتنتقل حالات الموافقة المعلَّقة الخاصة بالموظف المفوِّض إلى المفوَّض إليه. وهذا هو الزر الذي يجعل التفويض بأثر رجعي؛ فبدونه لا يلتقط التفويض الجديد إلا الحالات التي تنشأ بعده.

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

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

إشعارات البريد الإلكتروني
- روابط موافقة مدمجة
- دعم المرفقات
رسائل SMS
الإشعارات داخل التطبيق
الإشعارات الفورية (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> {money.netValue}</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: {money.netValue}
OTP: {$notificationInfo.otp}

{approvelink}
{rejectlink}

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

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

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

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

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

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

الوصول المباشر للحقل: {code} و{money.netValue} و{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} - رابط/زر للتصعيد إلى المدير الأعلي
{escalatetodirectsupervisorlink} - رابط/زر للتصعيد إلى المشرف المباشر

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

في قوالب الإشعارات (البريد الإلكتروني، الرسائل القصيرة، الإشعارات داخل التطبيق، إلخ)، يمكنك الوصول إلى معلومات حالة الموافقة التفصيلية باستخدام بادئة 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> {money.netValue}</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 → Budget Exceeded Behavior = 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

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

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

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

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

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

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

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

خيار في الإعدادات العامة: إضافة خطوات الموافقة في سجل التعديل

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

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

سجلات الخطوات الفردية: إدخال مراجعة منفصل لكل قرار موافقة
أنواع القرارات المتتبعة:
- Approve - عند اعتماد خطوة
- Reject - عند رفض خطوة
- Return - عند الإرجاع للتعديلات
- Return To Previous Step - عند الإرجاع خطوة واحدة للخلف
- Return To A Specific Step - عند الإرجاع إلى خطوة بعينها
- Escalate To Supervisor - عند التصعيد إلى المدير الأعلي للمعتمِد
- Escalate To Direct Supervisor - عند التصعيد إلى المشرف المباشر للمعتمِد
- Escalate To Specific Employee - عند التصعيد إلى موظف محدد
سجل الاكتمال النهائي: لا يزال يُنشئ سجل Approval القياسي عند اكتمال سير العمل
سياق المستخدم: يلتقط من اتخذ كل قرار ومتى

أخطاء إعداد شائعة

موافقة «مع التعديل» على مستند لا تُحفظ

تفعيل مع التعديل في تعريف موافقة لمستند — سند تحويل أو فاتورة — يُرفض عند حفظ التعريف بالرسالة:

«لا يمكن استعمال "مع التعديل" مع المستندات - تستعمل مع الملفات فقط»

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

value.info.allowApprovalsOnDocumentsUpdate

قفل السجلات المعتمَدة بدلًا من ذلك

إن كان ما تريده فعلًا هو منع تغيير المستند بعد اعتماده، فلا تحتاج إلى موافقة «مع التعديل» أصلًا: فعّل منع التعديل بعد الموافقة (وللحذف منع الحذف بعد الموافقة) في سطور ملف الصلاحيات أو في إعدادات المستخدم.

فاتورة المشتريات تطلب موافقة من جديد عند حفظ سند استلام

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

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

sql

select case when {$systemIsCommiting} = 1 then 0 else 1 end

تظل الموافقة تعمل حين يعدّل المستخدم الفاتورة مباشرة، ولا تعمل حين يحدّثها سند استلام.

رسائل قد تظهر لك

رسائل ترفض العمل على سجل داخل دورة موافقة:

الرسالة	لماذا	ما تفعله
«لا يمكن التعديل أثناء الموافقات» · «لا يمكن التعديل أثناء انتظار الموافقة للخطوة {0}»	للسجل دورة موافقة مفتوحة، وأنت لا تملك قدرة التعديل أثناء الموافقة، أو سياسة الخطوة تمنعه.	أنهِ الموافقة أو ألغِها، أو استعمل السماح بالتعديل أثناء الموافقة مع السياسة المناسبة للخطوة ومع القدرة.
«الموظف {0} لا يمكنه الموافقة على الخطوة {1} في السجل {2} لذلك لا يمكنه التعديل أثناء انتظار الموافقة»	سياسة الخطوة هي السماح للمصرح لهم ومن يمكنهم الموافقة، وهذا الشخص ليس من معتمدي الخطوة المنتظرة حالياً.	دع أحد معتمدي تلك الخطوة يجري التعديل، أو خفّف السياسة إلى السماح للمصرح لهم.
«السجل بانتظار موافقة. لا يمكن حفظ أي تعديلات إلى أن يتم انهاء الموافقات»	جرت محاولة اعتماد على سجل موافقته ما زالت مفتوحة. والصيغة المنتهية بـ«و لكن يمكنك حفظه كمسودة» تعني أن طريق المسودة ما زال متاحاً.	انتظر القرار، أو احفظ كمسودة حيث تعرض الرسالة ذلك.
«السجل بانتظار موافقة. لا يمكن الحذف إلى أن يتم انهاء الموافقات»	حذف سجل له دورة موافقة مفتوحة.	أنهِ الموافقة أو ألغِها أولاً.
«السجل {0} خاضع لموافقة حاليا»	جرت محاولة مراجعة أو عملية مشابهة أثناء الدورة.	انتظر انتهاء الموافقة.
«لا يمكن للمستخدم الحالي حذف {0} بعد الموافقة»	السجل معتمَد، وملف الصلاحيات لا يسمح لك بحذف السجلات بعد الموافقة.	اطلب ذلك ممن يسمح له ملفه، أو ألغِ السجل بدل حذفه.
«يمكن استعمال الرفض مع المستندات و الطلبات فقط - في الملفات قم باستعمال قرار الإرجاع»	ضُغط رفض على ملف أساسي.	استعمل إرجاع — فالملفات الأساسية تُرجَع ولا تُرفض.

رسائل ترفض حفظ تعريف الموافقة نفسه:

الرسالة	لماذا	ما تفعله
«تعريف سير العمل يجب أن يحتوي على خطوة واحدة على الأقل»	جدول الخطوات فارغ.	أضف خطوة.
«يجب تحديد حالة علي الأقل يتم استخدام سير العمل معها (عند الانشاء أو الحذف ... إلخ)»	لم يؤشَّر أي من حالات الاستعمال، فلن يعمل التعريف أبداً.	أشّر واحدة على الأقل: الإنشاء أو التعديل أو الحذف أو غيرها.
«مسلسل خطوة مكرر : {0}»	خطوتان تحملان المسلسل نفسه.	غيّر مسلسل إحداهما.
«لا يمكن استعمال "مع التعديل" مع المستندات - تستعمل مع الملفات فقط»	خيار مع التعديل مفعّل في تعريف موافقة لمستند.	راجع موافقة «مع التعديل» على مستند لا تُحفظ.
«أولوية تعريف سير العمل مكررة مسبقا في تعريف آخر {0}»	تعريف آخر للكيان نفسه يستعمل الأولوية ذاتها، فيصير الترتيب بينهما غير محدد.	امنح هذا التعريف أولوية مختلفة.
«سياسة التعديل أثناء الموافقة يجب أن تكون {0} أو فارغة لأن اوبشن التعديل أثناء الموافقة غير مفعل»	اختيرت سياسة تعديل للخطوة بينما الخيار العام السماح بالتعديل أثناء الموافقة مغلق.	فعّل الخيار العام، أو أفرغ سياسة الخطوة.
«يتوجب عليك تفعيل الأوبشن {0} في إعدادات الحسابات حتي تتمكن من استعمال الأوبشن {1}»	علامة يستعمل مع تخطي الموازنات موضوعة بينما تفعيل الموافقة عند تجازو الموازنات غير مفعَّل في إعدادات الحسابات.	فعِّل الخيار في إعدادات الحسابات، أو أزل علامة يستعمل مع تخطي الموازنات.
«لا يمكنك التعليم علي الحقل {0} و أي من الحقول {1},{2},{3} في نفس الوقت. يرجي ازالة العلامة من تلك الحقول»	علامة يستعمل مع تخطي الموازنات موضوعة مع الإنشاء أو الحذف أو التعديل.	اجعل موافقة الموازنة في تعريف مستقل.
The entity type {0} can not be used with budget approval because it does not generate an accounting request. (تظهر بالإنجليزية — لا نص عربي لها في النظام)	التعريف، أو قائمة الأنواع الإضافية فيه، يذكر نوعًا لا يُنتج أثرًا محاسبيًا أبدًا، فلا يمكن أن يتجاوز موازنة.	احذف هذا النوع من تعريف الموازنة.

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

نظرة عامة ​

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

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

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

البدء ​

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مثال عملي: توجيه التحويل المخزني إلى المخزن المستلم ​

نوع المسئول = استعلام: قائمة ثابتة من استعلام ​

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

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

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

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

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

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

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

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

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

الخطوات المشروطة (الاختيارية) ​

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

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

طريقتان للتصعيد إلى أعلى ​

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

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

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

الحقول الحرجة (Critical Fields) ​

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

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

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

للمعتمِدين ​

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

الإجراءات في هذه الشاشات ​

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

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

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

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

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

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

حقول ApprovalCaseStep ​

حقول ApprovalCaseStepCandidate ​

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

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

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

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

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

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

أخطاء إعداد شائعة ​

موافقة «مع التعديل» على مستند لا تُحفظ ​

فاتورة المشتريات تطلب موافقة من جديد عند حفظ سند استلام ​

رسائل قد تظهر لك ​

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

نظرة عامة

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

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

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

البدء

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مثال عملي: توجيه التحويل المخزني إلى المخزن المستلم

نوع المسئول = استعلام: قائمة ثابتة من استعلام

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

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

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

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

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

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

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

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

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

الخطوات المشروطة (الاختيارية)

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

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

طريقتان للتصعيد إلى أعلى

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

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

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

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

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

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

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

للمعتمِدين

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

الإجراءات في هذه الشاشات

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

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

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

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

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

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

حقول ApprovalCaseStep

حقول ApprovalCaseStepCandidate

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

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

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

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

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

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

أخطاء إعداد شائعة

موافقة «مع التعديل» على مستند لا تُحفظ

فاتورة المشتريات تطلب موافقة من جديد عند حفظ سند استلام

رسائل قد تظهر لك