الطلبات والتنفيذ والقبول

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

إنشاء الطلب وتأكيده

افتح /operations/orders/new أو ابدأ من بطاقة العميل. أضف سطراً واحداً أو عدة أسطر للطلب، من 1 إلى 40. لكل سطر مقترحه الخاص من الكتالوج وكميته ووحدته وشروط سعر مجمدة؛ ولا يمكن حذف السطر الأخير. لا تخلط العملات في طلب واحد، لأن ذلك يمنع الإرسال. إذا كان الدليل أو الشروط غير متاحين فلا تستبدلهما بصفر ولا تنشئ الطلب عشوائياً؛ يظهر خطأ الشروط في السطر المعني وتُتاح إعادة المحاولة لذلك السطر فقط. \nبعد اختيار العميل وأول عرض/سعر، تقترح البوابة اسماً بصيغة «العرض — العميل». ما لم تعدّل الاسم يدوياً، يتحدث الاقتراح عند تغيير الاختيار؛ وبعد التعديل اليدوي تحتفظ البوابة بنصك. يمكن أن يبقى الطلب بلا اسم ويستخدم اسماً محايداً في القائمة، فلا تخترع بيانات لإكمال النموذج.

دورة الحياة هي draft → submitted → confirmed → provisioned. احفظ المسودة وأرسلها مع أساس أو مرجع ثم أكد الإصدار الحالي. يحول التأكيد الطلب إلى التزام، وينشئ provision خطة التنفيذ. إذا لم يُقبل الإجراء، فتحقق من الصلاحيات والحقول المطلوبة وحدّث البطاقة قبل المحاولة مرة أخرى.

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

في /operations/orders تقبل الفلاتر draft وsubmitted وconfirmation_pending وconfirmed وon_hold وcompleted. قد تحمل الصفوف حالات provisioned أو fulfilled أو cancelled أو closed وتظهر عند فتح الطلب. تتوفر الجداول والبطاقات والإجماليات والصفحات وإعادة المحاولة والحالات الفارغة.

عند توفر الصف لك، افتح بطاقة الطلب عبر /operations/orders/:orderId لمراجعة البنود والأطراف والحالة والخطوة التالية المتاحة. يمكن فتح الرابط مباشرة ومشاركته مع الزملاء، لكن الوصول يظل خاضعاً للصلاحيات.

في الطلب المؤكد تعرض البطاقة أيضاً تقدم كل بند في خطة التنفيذ: planned وin_progress وhanded_over وaccepted أو cancelled. عندما تصل الكمية المسلّمة إلى الكمية المطلوبة، يُعرض البند على أنه مُسلَّم بالكامل حتى لو لم تتزامن حالة الخطة الرئيسية بعد. لتنفيذ الخطوة التالية افتح /operations/fulfillment وأعد قراءة البند الحالي؛ لا تستنتج واقعة التسليم من حالة الطلب الرئيسي وحدها.

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

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

إعداد التنفيذ

في /operations/fulfillment راجع الخطة وبنودها. يمكن نقل planning أو blocked إلى ready، وبدء ready أو partially_completed. يتطلب كل انتقال تأكيداً أو مرجعاً غير فارغ وإصداراً حالياً. لا يعني تأكيد الطلب وحده أن الخطة جاهزة؛ تحقق من الكمية والوحدة والمسؤول والكيان القانوني. قد تكون حزمة العمل غير منشأة أو مرتبطة في قسم حزم العمل.

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

يشمل سجل التسليمات جميع العملاء افتراضياً؛ ويعمل مرشح العميل على هذه الشاشة فقط ولا يُحفظ. لا يُحمّل قسم الخطط «الموعودة ولم تُسلَّم بعد» إلا بعد اختيار عميل؛ امسح المرشح للعودة إلى جميع التسليمات. فراغ قسم الخطط من دون اختيار عميل لا يثبت غياب البيانات.

كل تسليم ظاهر في بطاقة العميل يقود الآن إلى هذا السجل مع تضمين العميل مسبقاً في مرشح عنوان URL، كما يفتح الصف بطاقة تفاصيل منفصلة للتسليم عبر المسار /operations/fulfillment/deliveries/:deliveryId. تُستخدم البطاقة لعرض تفاصيل التسليم وحالته؛ وتظل إجراءات الصف فتح الاستلام والإرجاع والتصحيح والإبلاغ عن مشكلة والإلغاء تبدأ من هذا السجل. يستخدم الصف اسم التسليم البشري الظاهر عند توفره، ولا يعود إلى طريقة التسليم إلا في السجلات القديمة.

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

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

قد تكون خلية «أمر العمل» الفارغة طبيعية أيضاً: إذا لم تُستخدم executionContainerPolicy=work_order يُتابَع العمل على البند، لكن ذلك لا يثبت أن مهمة أُنشئت أو عُيّنت أو اكتملت. إذا كانت السياسة تتطلبه، تعني عبارة «لم يُنشأ بعد» فقط أن الحزمة لم تُنشأ بعد، وليست خطأ في الوصول. في البوابة الحالية لا يوفّر مسار حياة أمر العمل وحزمته طريقاً لإنشاء مكوّن مهمة أو إرساله، ولا يثبتان أن المنفذ تلقى العمل أو أتمه. قبل التسليم أو مراجعة الإكمال، تحقق من النتيجة الفعلية في سياق المهمة والمنفذ المتفق عليه؛ وإذا لم يكن متاحاً، فتوقف واسأل مالك البوابة، ولا تتجاوز ذلك عبر استدعاء API مباشر.

تسليم بند

يتاح التسليم فقط عندما تكون الخطة in_progress وللكمية التي لم تُسلّم أو تُقبل. أضف الدليل والطريقة: السلعة المادية تستخدم shipment، والأنواع الأخرى تستخدم طريقة الخدمة. عند النتيجة الجزئية حدّث الخطة والسجل قبل إعادة المحاولة لتجنب التكرار. البند المسلّم والإصدار القديم والتعارض نتائج مختلفة. يتطلب إلغاء التسليم سبباً غير فارغ.

تقدم قائمة الصف التصحيح والإرجاع بعد تسليم شيء ما؛ ويتطلب كلاهما وصفاً إلزامياً ولا يعملان إلا لتسليم ذي بند واحد. يتطلب الإرجاع أيضاً إصدار التسليم الحالي ولا يتاح بعد اتخاذ قرار القبول؛ ويحفظ التصحيح بجانب السجل الأصلي. إذا لم توجد بنود أو وُجد أكثر من بند تشرح القائمة القيد. الحالات ready_for_handoff وreceived وaccepted وreturned وexception تصف حالة السجل ولا تثبت وحدها حركة مخزون.

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

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

إذا عرض الإصدار الحالي Report a problem (قد تعرض الواجهة المعرّبة بالكامل الإبلاغ عن مشكلة)، فهذا يسجل حادثة ولا ينفذ إجراءً على البضاعة. قد يتاح في حالات planned وready_for_handoff وpartially_handed_over وhanded_over؛ اشرحوا ما حدث. تُعلَّم عملية التسليم كمشكلة، لكن لا يبدأ إرجاع أو قبول أو حركة مخزون. إذا تغيرت الحالة أو إصدار البطاقة، أعيدوا تحميل السجل وتحققوا مرة أخرى.

في بطاقة الاستلام يصبح عنوان الطلب المصدر رابطاً إلى /operations/orders/:orderId عندما يمكن فتح الطلب. وإذا كان العنوان غير متاح أو قيد التحميل، تستخدم البوابة تسمية محايدة ولا تعرض معرفاً تقنياً.

مراجعة القبول

تعرض /operations/acceptance وبطاقة القبول الطلب الأصلي والكميات المقبولة والمرفوضة والحالة وتحذير إعادة العمل والتواريخ والمستندات والسجل. يمكن فتح بطاقة قبول محددة مباشرة عبر /operations/acceptance/:acceptanceCaseId. قد تكون الواجهة للقراءة فقط؛ القبول وإعادة العمل والرفض تتطلب صلاحية منفصلة وفصل الواجبات. لا تعد بإجراء لا يظهر في البطاقة.

في القائمة المشتركة، يُسمّى كل صف قبول بعنوان طلب البيع المصدر؛ وإذا لم يُحمّل العنوان بعد يُستخدم البديل المحايد القبول. تظهر الحالات بصيغ draft (مسودة)، وcollecting_evidence (جمع الأدلة)، وready_for_submission (جاهز للإرسال)، وsubmitted (أُرسل إلى العميل)، وpending (في انتظار القرار)، وunder_review (قيد المراجعة)، وpartially_accepted (مقبول جزئياً)، وaccepted، وrejected، وcancelled (مُلغى). وفي حالة ready_for_submission تعرض البوابة زر إرسال إلى العميل؛ ويبدأ الإرسال مسار موافقة منفصلاً وقد يتطلب تأكيد موظف ثانٍ وفق فصل المهام.

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

في بطاقة القبول، اختر أولاً إرفاق الدليل: ينقل ذلك الحالة من draft إلى collecting_evidence. يمكن للموظف إلغاء الحالة من draft فقط، مع سبب غير فارغ وإصدار الحالة الحالي. يظهر جاهز للإرسال من حالة collecting_evidence فقط ويتطلب علامة دليل غير فارغة وغير قابلة للتغيير. في حالة ready_for_submission ينشئ زر إرسال إلى العميل طلب الموافقة أو يعيد استخدامه؛ ولا يُعرض مرجع القرار التقني في نص المستخدم. قرار العميل (decide) مسار منفصل للطرف الآخر وليس إجراءً للموظف. ويتطلب القبول وإعادة العمل والرفض الصلاحية المناسبة وفصل الواجبات.

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

بعد قرار accepted أو partially_accepted تعرض بطاقة القبول إجراءً واحداً لضمان إنشاء قيد الرسوم وتوفر رابطاً إلى سجل الرسوم (المسار /operations/billing?view=charges). لا يُدخل مبلغ القيد يدوياً: يستخرجه الخادم من الكمية المقبولة والشروط والسياسة المجمّدة وسعر الوحدة والدقة المسموح بها. التكرار idempotent: تميّز البطاقة بين «تم إنشاء القيد» و«القيد موجود مسبقاً» ولا تنشئ نسخة مكررة. يتطلب الإجراء الصلاحية المناسبة وفصل المهام؛ وتُعرض بصورة منفصلة أخطاء تعطيل مشغّل الفوترة، وعدم صلاحية السعر/الشروط/الدقة، وعدم صلاحية حالة القبول أو مصدره، وعدم العثور على السجل، وتعارض الإصدار (عند التعارض أعد قراءة البطاقة). اعرض المبلغ بعملة اللغة المحلية والكيان القانوني المختارين؛ استخدم بيانات اصطناعية فقط، من دون فواتير أو بيانات مصرفية أو بيانات عميل حقيقية.

الأدلة والمال والخصوصية

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

صفحات ذات صلة

• العمليات
• المستندات
• المهام
• CRM