تعريفات التنبيهات
تعريف التنبيه سجل واحد يجيب عن أربعة أسئلة عن رسالة واحدة: ماذا حدث، وعلى أي السجلات، ومن يعلم به، وماذا يقرأ. تحفظه مرة واحدة فيغذّي كل قناة كتبتَ لها قالباً — جرس التنبيهات داخل النظام، والبريد الإلكتروني، والرسائل النصية، وواتساب، وتطبيقات الجوال. فليس هناك «قاعدة للبريد» و«قاعدة للرسائل»، وإنما تعريف واحد لكل قناة فيه قالبها.
وما يلي هو شاشة التعريف بالترتيب الذي تعرضه به. أما جانب المزودين في الرسائل النصية وواتساب — الحسابات والرموز والمرسلون — ففي ضبط SMS وواتساب، ووصفات القوالب للحالات الملتبسة في أسئلة التنبيهات الشائعة.
ما الذي يُطلقه
نوع الملف/المستند (notificationEntity) يسمي نوع السجل المراقَب — فاتورة المبيعات، أو العميل، أو الموظف. وبدلاً منه يوسّع مطبق على الشبكة دون تسمية نوع بعينه:
| مطبق على | الإنجليزية | يشمل |
|---|---|---|
| كل الشاشات | All Screens | كل أنواع السجلات في النظام |
| الملفات | Master Files | كل الملفات (العملاء، الأصناف، الموظفون…) |
| المستندات | Documents | كل المستندات (الفواتير، الإيصالات، الأوامر…) |
وتطبق ايضا علي يمدّ التعريف الواحد إلى قائمة أنواع إضافية، فتغطي قاعدة واحدة فاتورة المبيعات ومردودها دون أن تُكتب مرتين.
ثم تُعلِّم الأحداث. فالتعريف يعمل مع ما تُعلِّمه لا غير:
| الحدث | English | الحدث | English |
|---|---|---|---|
| مع الإدخال | Use With Insert | مع التعديل | Use With Update |
| مع الحذف | Use With Delete | مع المسودة | Use With Draft |
| مع طلب الموافقة | Use With Approval Request | مع الرفض | Use With Reject |
| مع الارجاع | Use With Return | مع المراجعة | Use With Revise |
| مع إلغاء المراجعة | Use With Unrevise | مع الإلغاء | Use With Cancel |
| مع إلغاء الإلغاء | Use With Uncancel | مع الطباعة | Use With Print |
| مع المناقشة | Use With Discussion | مع فشل التكرار | Use With Replication Failure |
| مع فشل المعالجه | Use With Processing Failure | يدوياً | Manually |
قاعدتان تفرضهما الشاشة عند الحفظ
التعريف الذي لم يُعلَّم فيه حدث واحد مرفوض — ويردّ النظام بأنه «يجب اختيار مع الإدخال أو التعديل أو الحذف… إلخ». والتعريف الذي لم يُذكر فيه نوع الملف/المستند ولا تطبق ايضا علي ولا مطبق على مرفوض كذلك: فليس لديه ما يراقبه.
وحدثان من هذه هما طريق مدير النظام إلى معرفة المشكلات لا الأعمال: فـمع فشل المعالجه يعمل حين يفشل طلب أعمال لمستند، ومع فشل التكرار يعمل حين يعجز سجل عن الوصول إلى موقع آخر. وجِّههما إلى مدير النظام يكن أول من يعلم بالأستاذ المتوقف هو من يستطيع إصلاحه.

تضييق النطاق
تعليم مع التعديل على فاتورة المبيعات يعني أن كل تعديل في كل فاتورة يرسل رسالة، وهكذا يصير التنبيه ضجيجاً لا يقرؤه أحد. وأربعة فلاتر تضيّقه، وهي مجتمعة بـ«و» — فلا يعمل التعريف إلا إذا وافقت كلها:
- المعايير — محرر المعايير المعتاد: شروط على حقول السجل.
- تطبيق عند التوافق مع الاستعلام — استعلام لا بد أن يُرجع السجل.
- سيناريو — سيناريو يقرر.
- عندما تتغير الحقول الاتية — جدول حقول يخص التعديل وحده: فلا يعمل التنبيه إلا إذا تغيّر أحد الحقول المذكورة فيه. واتركه فارغاً يصلح كل تعديل.
وعدم إرسال التنبيه في حالة تغيير الحقول الحرجة فقط يعكس الأخير: فلا تُرسل الرسالة إلا إذا تغيّر شيء غير تلك الحقول. وهو خيار «أخبرني بأي تعديل إلا الملاحظة».
وخمسة خيارات للمحددات — القطاع والشركة والفرع والإدارة ومجموعة التحليل: يجب أن تطابق السجل — تقصر التعريف على السجلات التي تطابق محدداتُها محدداتِ التعريف، وبها تحتفظ كل شركة برسائلها في قاعدة بيانات واحدة تخدم عدة شركات.
وأخيراً يمنع عدم الإرسال مع إعادة الحفظ عملَ التعريف حين يعيد النظام حفظ السجل من تلقاء نفسه، فيوفّر على المستخدم نسخة ثانية من رسالة عنده منها نسخة.
الأولوية ليست ترتيباً، بل هي «بدلاً من»
لكل تعريف أولوية، ويمرّ المحرك على التعريفات المطابقة بترتيب الأولوية. والذي يفاجئ الناس ما يحدث بعدها: فحين يجمع تعريفات أول مستوى أولوية طابق، يتوقف — فلا تعمل تعريفات المستويات التالية أبداً، طابقت أو لم تطابق.
فالأولوية إذن ليست رقم تسلسل لترتيب الرسائل، وإنما هي سُلّم أسبقية: التعريفات التي تشترك في أولوية واحدة تعمل جميعاً، والتعريف الأدنى لا يعمل إلا إذا لم يطابق شيء فوقه. فإذا وجب خروج تنبيهين مختلفين على الحدث نفسه، فأعطهما الأولوية نفسها.
من يستقبله
جدول المستهدفين يقبل في كل سطر أحد أمرين:
- الحقل — حقل في السجل المراقَب يشير إلى شخص: مندوب المبيعات في الفاتورة، أو الموظف في طلب الإجازة. ويُقرأ الحقل عند الإرسال، فتتبع الرسالةُ من هو مذكور في السجل.
- المستهدف — مستقبِل محدد بعينه. ويقبل المرجع: موظفاً أو مستخدماً أو منصباً تنظيمياً أو وظيفة أو إدارة موظفين أو مجموعة موظفين أو مجموعة رئيسية أو ملف تأمين (Security Profile) أو مسؤولية — فتصير «كل من له مسؤولية متابعة الائتمان» سطراً واحداً لا قائمة تتقادم.
واستعلام المستهدفين يغطي الباقي: المستقبِلون الذين يجب البحث عنهم لا تسميتهم.
شرط الاستعلام
لا بد أن يُرجع الاستعلام العمودين entityType وid بهذا الترتيب. وأي أعمدة بعدهما تُهمَل. فلتنبيه كل الشركات التابعة للشركة التي دفعت مثلاً:
select entityType, id from Customer where parent_id = {relatedSubsidiary.id}حين لا يعرض المرجع نوع السجل الذي تريده
المراجع التي تختار المستقبِل لا تعرض إلا أنواع السجلات التي سمح بها مدير النظام مستقبِلين للبريد. فإذا غاب النوع الذي تحتاجه — طرف آخر، أو جهة اتصال، أو سائق — فأضفه في إعدادات الحقول والكيانات ليصير قابلاً للاختيار في كل موضع يُختار فيه المستقبِلون.
وعدم تنبيه محرر السجل يُسقط من القائمة من تسبب في الحدث — فأكثر الناس لا يحتاجون إلى إخبارهم بما فعلوه للتو.
ولا يُراسَل كل من في القائمة بالضرورة. فالنظام يُسقط في صمت الموظفين الذين تركوا العمل والمستخدمين الممنوعين من الدخول. انظر القسم «لماذا لم يصل التنبيه» أدناه.
التفويض: الوصول إلى من ينوب
التنبيه الذي يصل إلى صندوق شخص في إجازة أسبوعين تنبيهٌ لا يتصرف فيه أحد. فإذا كان للموظف مستند تفويض ساري — وهو المستند نفسه الذي تُسلَّم به الموافقات المعلقة إلى نائب — مدّ النظام التنبيهات إليه بالطريقة نفسها.
فما دامت فترة التفويض جارية، يُرفع كلُّ تنبيه موجَّه إلى المفوِّض للمفوَّض إليه كذلك. وتحمل نسخة النائب حقل مفوض من يسمي المستقبِل الأصلي، فيرى من أول نظرة أن الرسالة تخص عمل غيره. ولا يُنتزع شيء من المستقبِل الأصلي — فتبقى نسخته عنده، ولا يضيع شيء إن هو اطّلع من إجازته.
والمفوَّض إليه ينضم إلى قائمة المستهدفين نفسها، أي أنه يُبلَّغ بكل القنوات التي يستعملها التعريف — تنبيه داخل النظام أو بريد أو رسالة نصية أو واتساب — لا بجرس التنبيهات وحده. وهذا مقصود لتغطية الإجازات، لكن من الجدير معرفته قبل أن تفوّض من هو على قائمة تنبيهات كثيفة.
ويحكم السلوكَ خياران:
- عدم تطبيق التفويض في تعريف التنبيه يوقف التفويض لهذا التعريف وحده. استعمله للرسائل التي لا يجوز أن تغادر صاحبها: تغييرات الرواتب، والمسائل التأديبية، وكل ما لا يرضى الموظف أن يقرأه زميل.
- عدم إرسال التنبيهات للموظف المفوض في الإعدادات العامة يوقف السلوك في التركيب كله.
والتنبيهات التي ترفعها المهام المجدولة تتبع القاعدة نفسها. فليس للمهمة المجدولة خيار على مستوى السجل، ولذلك لا ينطبق عليها إلا الخيار العام.
التنبيهات التي كانت منتظرة من قبل
التفويض يغطي ما يُرفع من تنبيهات أثناء سريان الفترة، ولا يمتد إلى ما تراكم قبل إنشائه. ولتلك افتح مستند التفويض واستعمل المزيد ← نقل التنبيهات للموظف المفوض. فيُنقل إلى النائب كل تنبيه غير مقروء للمفوِّض يقع تاريخه داخل فترة التفويض، ويُختم بـمفوض من.
ولاحظ الفرق: هذا نقل حقيقي — فالتنبيهات تغادر قائمة المفوِّض — بينما التفويض الجاري ينسخها. وهو أداة «المدير في إجازة بالفعل وصندوقه ممتلئ»، لا أداة التغطية الاعتيادية. ولا بد أن يكون المستند محفوظاً ومعتمداً قبل أن يعمل الإجراء.
ماذا يقرؤون
تحمل مجموعة القوالب قالباً لكل قناة، وكلها بلغة Tempo:
| الحقل | English | يغذّي |
|---|---|---|
| قالب التنبيهات | Notification Template | الرسالة داخل النظام |
| قالب الإيميل | Email Template | متن البريد، ويقبل HTML |
| قالب الرسائل النصية | SMS Template | الرسالة النصية |
| رسالة واتساب | WhatsApp Message | رسالة واتساب |
| قالب عنوان التنبيه / قالب محتوى التنبيه | Notification Title / Body Template | تنبيه تطبيقات الجوال |
وعنوان الرسالة هو اسم التعريف نفسه — فسمِّ التعريفات بما تحب أن يقرأه المستخدم في قائمة تنبيهاته، لا بـNOTIF-017.
وكتابة النص نفسه ثلاث مرات يمكن تجنبها: فـنسخ التنبيهات من ونسخ الايميل من ونسخ الرسائل من يأخذ كل منها إحدى القيم Email أو SMS أو Notification فيعيد استعمال قالب تلك القناة.
وحقول أخرى تشكّل ما يصل:
- تقرير التنبيه / تقرير الايميل / تقرير الرسائل ترفق تقريراً مطبوعاً للسجل، ويختار تنسيق الملف المرفق صيغة الإخراج، ويسمّي قالب اسم المرفق الملفَ — وهو قالب Tempo، فيصل العميلَ ملف
Invoice-SI-2024-001.pdfلاreport.pdf. - مرسل الايميل المفضل ومرسل الرسائل المفضل يحددان المرسل المضبوط الذي تخرج منه الرسالة؛ والمرسل المفضل لواتساب يفعل ذلك في واتساب ويمكن أن يُحسب لكل موظف — انظر الإرسال من أرقام الموظفين.
- السماح بأكثر من رسالة نصية بنفس المحتوي لنفس الرقم من هذا التنبيه مغلق افتراضياً، فيمنع تكرار الرسالة نفسها إلى الرقم نفسه. وعلِّمه حين يكون التكرار هو المقصود، كتذكير يومي بنص واحد.
- لا ترسل تنبيهات لتطبيقات الجوال يُبقي التعريف بعيداً عن الهواتف.
- مصدر مرجع 1 / مرجع 2 للتنبيه يختمان التنبيه الناتج بمرجع مأخوذ من حقل في السجل، وبه تُفلتَر قائمة التنبيهات بالعميل الذي تخصه مثلاً.
قوالب تقرأ السجل
قوالب Tempo تصل إلى أي حقل في السجل وفي السجلات التي يشير إليها:
عزيزنا {customer.name1}،
فاتورتكم {code} بتاريخ {valueDate} وقيمتها {money.total}
قد تم {translate(status)}.
يمكنكم الاطلاع على تفاصيلها هنا: {link($this)}وإن كانت روابط كهذه تفتح السجل في الواجهة القديمة، فأضف {useNewGUIForLinks} في أي موضع من القالب لتفتح في الواجهة الجديدة، من البريد الإلكتروني ومن داخل النظام على السواء — انظر فتح الروابط في الواجهة الجديدة.
وأربعة حقول جاهزة تضع سجل تغييرات التعديل في متن الرسالة — {$changesAsHtmlAr} و{$changesAsHtmlEn} و{$changesAsTextAr} و{$changesAsTextEn}. استعمل زوج HTML في البريد وزوج النص في الرسائل النصية؛ فكلٌّ منها يسرد حقول الرأس التي تغيرت بقيمتها القديمة والجديدة، ومعها السطور المضافة والمحذوفة والمعدّلة. وفي Tempo بقية الصياغة، ومنها الدوران على السطور وكتل {openmsg}…{closemsg} التي تجعل تعريفاً واحداً يرسل رسالة مختلفة لكل مستقبِل.
متى يُرسَل
التنبيهات داخل النظام تظهر بمجرد اعتماد الحدث. أما البريد والرسائل النصية وواتساب وتنبيهات الجوال فلا تخرج في حينها — إنما يصير كل منها مهمة معلقة يلتقطها معالج في الخلفية، ولهذا لا يبطئ خادمُ بريد بطيء حفظَ المستند.
وجدول السماح بأرسال الرسائل والبريد الإلكتروني في الأوقات التاليه هو موضع قول التعريف متى يجوز لتلك الرسائل أن تغادر:
| العمود | English | المعنى |
|---|---|---|
| من وقت / إلى وقت | From-Time / To-Time | النافذة المسموح فيها بالإرسال |
| اليوم 1 … اليوم 7 | Day 1 … Day 7 | تقييد النافذة بأيام بعينها اختياري؛ واتركها فارغة تنطبق النافذة كل يوم |
والرسالة التي تُرفع خارج كل النوافذ لا تُهمَل — بل تنتظر وتخرج في أقرب وقت مسموح. واترك الجدول فارغاً تُرسَل الرسائل متى نشأت. ولاحظ أن هذا من خصائص التعريف لا المستقبِل: فليس في نما إعداد «ساعات هدوء» لكل مستخدم.
وحقلان آخران يخصان التوقيت:
- الحفظ قبل التنبيه (Flush Before Notification) يكتب التغييرات المعلقة في قاعدة البيانات قبل تجهيز القوالب. فإن كان التعريف يستعمل استعلاماً فاحتَجْ إليه، وإلا فقد لا يرى الاستعلامُ السجلَ الذي أطلق الرسالة نفسه. والشاشة تنبهك إلى ذلك تحديداً حين تحفظ تعريفاً فيه استعلام والخيار مغلق.
- التنبيه في يقصر التعريف على مواقع تكرار بعينها، فلا تعمل قاعدة المركز الرئيسي مرة أخرى في كل فرع.
لماذا لم يصل التنبيه
«التعريف مضبوط، لكنها لم يصلها شيء» هو أكثر بلاغات التنبيهات شيوعاً. راجع القائمة بالترتيب، فهي تبدأ بالتعريف ثم المستقبِل ثم الخادم.
1. التعريف لم يعمل أصلاً. تأكد أن غير نشط غير معلَّم، وأن الحدث معلَّم، وأن كل فلتر ملأته يوافق السجل. ثم تأكد أن تعريفاً في أولوية أعلى لم يطابق قبله (انظر تنبيه الأولوية أعلاه). والتعريف المعلَّم يدوياً لا يعمل من تلقاء نفسه، وقد يقصر التنبيه في التعريفَ على موقع آخر.
2. النظام أسقط المستقبِل. قبل إنشاء أي رسالة يُسقط النظام في صمت هؤلاء:
- المستخدم المعلَّم عليه منع الدخول؛
- الموظف الذي حالة الموظف عنده: مستقيل، أو تم فصله، أو على المعاش، أو موقوف، والمستخدم المرتبط بموظف كهذا؛
- الموظف الذي عُلِّم منع الدخول على كل مستخدميه.
ولا ينطبق هذا الفحص إلا على المستخدمين والموظفين؛ فالعميل والمورد والعنوان المكتوب يدوياً لا يُسقَط أبداً. وخيار تجاهل حالة الموظف عند إرسال التنبيهات في تبويب الإشعارات والمراسلات من الإعدادات العامة يعطّل قاعدة حالة الموظف للتركيب كله، وتبقى قاعدة منع الدخول سارية. ولا يترك المستقبِل المُسقَط أثراً في السجل ولا في المهام المعلقة؛ أثره الوحيد سطر في سجل الخادم نصه Notification … was not sent to … because …. وكذلك يُسقط عدم تنبيه محرر السجل من تسبب في الحدث، والمستخدم المذكور مع موظفه يصله تنبيه واحد لا اثنان.
3. ليس للمستقبِل عنوان على تلك القناة. لا يُوضع بريد في الطابور إلا لمستقبِل له بريد إلكتروني مسجَّل، ولا رسالة نصية إلا لمن له رقم جوال. فإن غاب العنوان لم يُوضع شيء ولم يظهر خطأ. أما التنبيه داخل النظام فيصل، ولهذا فإن «رآه في الجرس ولم يصله بريد» يعني في الغالب أن حقل البريد فارغ.
4. السجل وصل بالتكرار (Replication). لا يُنشأ بريد ولا رسالة نصية لسجل يُحفَظ بالتكرار القادم من موقع آخر؛ فالموقع الذي أُدخل فيه السجل هو الذي يرسلها.
5. الرسالة في الطابور لكنها لم تغادر. افتح المهام المعلقة. الحالة مؤجلة (Postponed) تعني أن جدول أوقات الإرسال في التعريف يحبس الرسالة. وتأتي إعادة المحاولة (Retry) وBlocked مع عمود رسالة الخطأ الذي يسمي السبب. فإن كانت كل المهام متوقفة، فافحص ارسال البريد و الرسائل من الخوادم (CSV) في الإعدادات العامة. فالبريد والرسائل النصية وواتساب وتيليجرام وتنبيهات الجوال لا تغادر إلا خادماً معرّفه في تلك القائمة. وإذا كانت القائمة فارغة تفشل كل مهمة بالرسالة:
Server ID is not defined
وإذا لم يكن معرّف هذا الخادم في القائمة تفشل كل مهمة بالرسالة:
Ignoring send email and sms because allowed servers is {0} and server id is {1}
وليس لأي من الرسالتين ترجمة عربية، فتظهران بالإنجليزية على الشاشات العربية. والعكس يحدث أيضاً: خادم اختبار منسوخ عن الإنتاج ما زال يحمل معرّف خادم الإنتاج يرسل رسائل حقيقية، وهذا هو السبب المعتاد لـ«وصلت العميلَ نسختان».
إطلاقه يدوياً
علِّم يدوياً فيتوقف التعريف عن الاستجابة للأحداث؛ وينتظر أن يُشغَّل على سجل عند الطلب. وله طريقان:
- إجراء كيان — Run Manual Notification — يأخذ كود التعريف مدخلاً له، فيرسله زرٌّ أو خطوة في مسار للسجل الذي بين يديك.
- والرسالة المجمعة (Bulk Message) مستند تُكتب في سطوره أسماء المستلمين باليد — عملاء أو موردون أو موظفون أو جهات اتصال. وزرّ إرسال فيها يشغّل مرة واحدة تعريفاً يدوياً مُعدّاً للرسالة المجمعة، فتصل الرسالة إلى كل من في السطور. وهي أداة «أرسل هذا لهؤلاء الأربعين عميلاً».
طريقة إعداد الرسالة المجمعة وإرسالها في الرسائل المجمعة ورسائل واتساب والمحادثات الداخلية.
ولأن التعريف اليدوي لا يعمل من تلقاء نفسه، فهو أيضاً الطريق الآمن لبناء قالب واختباره على نظام عامل.
صيانة القوائم من الشاشة
تحمل شاشة التعريف أربعة إجراءات للتنبيهات التي أنتجها بالفعل: حذف كل التنبيهات، وحذف تنبيهات المستخدم الحالي المقروءة، وحذف تنبيهات كل المستخدمين المقروءة، وحذف التنبيهات حتى تاريخ. وهي تفرّغ قوائم التنبيهات داخل النظام، وهي في التركيب المزدحم تنمو أسرع مما يقرؤها أحد.
تعديل التعريف يسري فوراً
التعريفات محفوظة في ذاكرة مؤقتة، لكن هذه الذاكرة تُسقَط لحظة حفظ أي تعريف — فلا إعادة تشغيل ولا انتظار. فإذا بدا أن تعريفاً معدَّلاً لم يسرِ، فالسبب في فلاتره هو، أو في مستوى أولويته، أو في مستقبِل أسقطه المحرك — لا في ذاكرة قديمة.