إجراءات أتمتة KayanOS

​

ما الذي يفعله الإجراء؟

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

1. قراءة البيانات ذات الصلة أو إيجادها.
2. التحقق من شرط القرار.
3. تنفيذ كتابة أو استجابة مضبوطة واحدة.
4. إشعار الشخص أو الفريق المسؤول.
5. تسجيل ما يكفي لكي يستطيع المراجع العثور على النتيجة.

​

قبل ربط أي إجراء

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

​

كتالوج الإجراءات الحالي

تحافظ الجداول على أسماء إجراءات KayanOS وحقول الإدخال المطلوبة الظاهرة حالياً في الكتالوج. قد يعرض المحرر حقولاً اختيارية إضافية؛ استخدمها لتضييق النطاق وجعل النتيجة أسهل تدقيقاً.

​

إجراءات السجلات

​

إجراءات المهام والعمل المجمّع

​

إجراءات النماذج وإجراءات الكيانات

​

سلوك اعتماد الساعات المرنة

إنشاء سجل Attendance Schedule Adjustments بإجراء Create Record الحالي هو قرار جدول دوام وليس مطالبة بوقت. لا ينشئ أبداً إدخال وقت عمل. تبقى البصمات الفعلية المغلقة المصدر الوحيد لدقائق العمل؛ ويمكن لبصمة دخول مفتوحة تثبيت وقت الوصول، لكنها لا تضيف دقائق عمل قبل وجود خروج صالح. لا يحتوي السجل على حقل قرار أو حالة موافقة. يعامل كل تعديل مرسل على أنه معتمد. Note هو حقل النص الاختياري الوحيد. يدير النظام تلقائياً المراجعة ومصدر الاعتماد والمنصب والوردية ولقطة الجدول وحالة الأثر الرجعي، ولا تدخل هذه القيم في Create Record. يكون Source Submission اختيارياً لأن الخادم يستخدم معرّف تشغيل التدفق عند تركه فارغاً. استخدم مرجعاً ثابتاً عندما يجب أن يحدّث تشغيل لاحق التعديل نفسه؛ وتزيد السجلات رقم المراجعة الداخلي تلقائياً. يعرض Create Record تفاصيل الجدول كحقول محددة النوع بدلاً من كائن JSON. يتحكم نوع التعديل في ظهور الحقول:

• Fixed Times: وقت البداية ووقت النهاية.
• Shift Offset: دقائق الإزاحة (القيمة الموجبة تؤخر الجدول والسالبة تقدمه).
• Flex Window: وقت بداية النافذة الاختياري ووقت نهاية النافذة المطلوب.

يتولى النظام وحده قيم التدقيق، ومنها JSON الموحّد للتعديل، والوضع المشتق، ولقطة الوردية، ومراجعة القرار الافتراضية، وصاحب الإجراء، ومهمة إعادة الاحتساب، ومؤشر الأثر الرجعي؛ ولا يمكن تعديلها كحقول في سجل الدفتر. يلتقط الخادم Shift Snapshot تلقائياً من وردية التعيين المحدد ولا يُدخل يدوياً. أما Retroactive فيُشتق أيضاً في الخادم: تكون قيمته true عندما توجد قسيمة راتب معتمدة للتواريخ المتأثرة. يتطلب هذا التغيير صلاحية تصحيح الفترة المقفلة؛ ويحافظ على الحضور والرواتب المقفلة ويستخدم مسار التسوية الحالي في الفترة التالية.

• يقبل الوقت الثابت زوج بداية ونهاية صريحاً فقط إذا حافظ على مدة الوردية الأساسية. ويقدم إزاحة الوردية النتيجة نفسها بعدد دقائق موجب أو سالب. تنتقل كل فترات العمل والاستراحات المضبوطة بالإزاحة نفسها.
• تقيد النافذة المرنة أول دخول بحدود النافذة المعتمدة: الوصول قبلها يثبت عند بدايتها، وداخلها يستخدم وقت الوصول الفعلي، وبعد سقفها يثبت عند السقف ويُحسب الفرق كتأخير.
• عند عدم وجود دخول يبقى الجدول الأساسي فعالاً ولا تُمنح أي دقائق. يمكن لخروج مفقود أن يحدد التأخير، لكنه لا ينتج دقائق عمل أو وقت خروج أو مغادرة مبكرة أو عملاً إضافياً قبل تصحيحه.
• لا تتغير مدة العمل المطلوبة ولا سماح الاستراحة. تُقاس المغادرة المبكرة مقابل النهاية المعدلة، ويبدأ العمل الإضافي من دقائق البصمة المنتجة بعد النهاية المعدلة، وليس من الوصول المبكر أو عدم أخذ الاستراحة.
• مثال: دوام أساسي 08:00–16:00 ونافذة 08:00–10:00 ودخول 09:17 ينتج 09:17–17:17. أما دخول 10:20 فيثبت عند 10:00 ويُحسب 20 دقيقة تأخير.
• يقتصر النطاق على 366 يوماً، ويسمح بتعديل معتمد واحد لكل عضو ويوم. تستبدل المراجعة الأعلى التعديل نفسه وتعيد حساب نطاقه المتأثر. لا تُعاد كتابة أيام الحضور المقفلة، بل يطبق سلوك تسوية الرواتب القائم.

​

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

​

الحوكمة والإشعار الداخلي

​

كيف تربط الإجراءات بلا مفاجآت

​

1. اقرأ قبل الإنشاء

عندما يمكن إعادة تشغيل المسار، ابدأ بـ Get Record أو Find Records. في مثال الترخيص، ابحث عن سجل مفتوح في Inspection Cases يرتبط معرّف طلبه بطلب الترخيص. إذا وجدته، فحدّثه أو أبلغه. وإذا لم تجد نتيجة وكان شرط القرار متحققاً، فأنشئ حالة واحدة فقط.

​

2. احتفظ بقيم الربط

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

​

3. افصل عمل النظام عن القرار البشري

استخدم الإجراء لتجهيز البيانات أو إنشاء مهمة أو انتظار إجراء نموذج. لا تستخدم Execute Task Action أو Execute Epic Action أو Execute Form Action أو Execute Entity Action لتجاوز قرار تسنده السياسة إلى شخص أو دور.

​

4. اجعل إجراءات الاستجابة مقترنة ومحدودة

ينتمي Return Form Response إلى On Form Call، وينتمي Return Dashboard Widget Response إلى On Dashboard Widget Call. عرّف حقول JSON المتوقعة قبل البناء، وأعد هذا المخطط فقط، واختبر حالات المدخل الناقص وعدم وجود نتيجة والخطأ بصورة منفصلة.

​

أنماط مسارات مفصلة

​

نمط: من الإدخال إلى المعاينة بلا تكرار

1. ابدأ بـ Record Changes على Permit Applications.
2. تحقق من أن الحالة أصبحت Ready for inspection وأن الطلب يتضمن المنطقة والعنوان المطلوبين.
3. استخدم Find Records للبحث عن حالة معاينة مفتوحة ترتبط بالطلب.
4. إذا لم توجد، فاستخدم Create Record لإنشاء سجل واحد في Inspection Cases بعلاقة الطلب المصدر والمنطقة والحالة والوحدة المسؤولة.
5. استخدم Create Task لفريق المعاينة الميدانية وSend Notification لمنسقهم المقيد بالنطاق.
6. احتفظ بمعرّف الحالة المنشأة أو أظهره بحيث يستطيع المراجع تتبع النتيجة من طلب الترخيص.

​

نمط: انتظار قرار بشري ثم إعداد مستند

1. ابدأ بـ On Form Action عندما يُرسل ملف الحالة لاتخاذ قرار.
2. استخدم Wait For Form Signature أو Wait For Form Action لنقطة القرار المعتمدة فعلياً.
3. تحقق من القرار المقبول ومسار التوقيع المطلوب.
4. استخدم Word Template بالحقول المعتمدة فقط.
5. استخدم Word to PDF عند الحاجة، ثم حدّث سجل الحالة بمرجع الناتج.
6. أبلغ مالك الخدمة المسؤول داخل KayanOS.

​

نمط: خدمة استجابة لوحة معلومات

1. ابدأ بـ On Dashboard Widget Call.
2. تحقق من الوضع والمدخل مقابل نطاق الخدمة المسموح للمستخدم به.
3. استخدم Find Records لاسترجاع التجميعات أو السجلات اللازمة فقط.
4. شكّل النتيجة حسب مخطط JSON الموثق.
5. اختم بـ Return Dashboard Widget Response.

​

اختبر كل إجراء بالترتيب الصحيح

استخدم سجلاً غير إنتاجي معتمداً واحداً ونفذ الفحوص التالية:

1. اختبار المشغّل: تحقق من حدث المصدر والبيانات المتوقعة.
2. اختبار القراءة: تحقق من أن إجراءات البحث تجد مجموعة السجلات المقصودة.
3. اختبار الكتابة: أنشئ أو حدّث هدفاً غير إنتاجي معرفاً بوضوح.
4. اختبار الانتظار/التنفيذ: تأكد من ربط المهمة أو العمل المجمّع أو جلسة النموذج أو إجراء الكيان الصحيحين.
5. اختبار الإشعار/الاستجابة: تحقق من المستلم أو الحمولة المعادة دون استخدام مواطن حقيقي أو مستلم خارجي أو نطاق دور إنتاجي.
6. المراجعة: حدد النتيجة داخل KayanOS وسجل معرّفها ومالكها ونتيجتها.

​

متابعة البناء

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