التسليم على دفعات في تطبيق الطلبات: كيف يبقى الجزء المتبقي واضحاً؟
لا ينبغي اعتبار الطلب مكتملاً لمجرد خروج الطرد الأول من المستودع. إذا كان فريقكم يرسل البضاعة على دفعات، فحددوا الكميات وسجلات الشحن لكل بند في الطلب، وأظهروا ما بقي مطلوباً. واتفقوا على ما إذا كانت حالات «شُحن» و«تم التسليم» و«أُغلق الطلب» تعني أشياء مختلفة في عملكم.
يساعد هذا الدليل في إعداد متطلبات تطبيق مخصص لإدارة الطلبات أو العمليات. موضوعه تنفيذ طلب واحد على عدة دفعات، وليس تعديل مجموعة طلبات دفعة واحدة أو تحديد وقت حجز المخزون. المقترحات التالية متطلبات للمشروع، وليست تأكيداً بأن منصة بعينها توفرها تلقائياً.
ابدؤوا بما التزمتم بتوفيره، لا بالطرد وحده
أبقوا الطلب الأصلي ظاهراً إلى جانب ما نُفذ منه. يحتاج الموظف إلى التمييز بين الكمية المطلوبة والكمية الملغاة والكمية التي ما زالت مستحقة. وينبغي أن يحدد سجل الشحنة البنود والكميات التي تشملها، بدلاً من الاكتفاء برقم تتبع مرتبط بالطلب كله.
في مثال افتراضي لمورّد معدات، قد تصل الآلة إلى العميل أولاً ثم تُرسل إحدى ملحقاتها لاحقاً. يجب ألا يختفي الملحق من قائمة العمل المتبقي بعد شحن الآلة. وفي الوقت نفسه، ينبغي ألا توحي القائمة بأن الآلة تحتاج إلى الشحن مرة أخرى.
تقدم وثائق Shopify الرسمية الخاصة بكائن FulfillmentOrder مثالاً مفيداً على الفصل بين العمل المخطط والعمل المنفذ. فهي تصف أوامر التنفيذ بأنها العمل المزمع إجراؤه للطلب، بينما يمثل كائن Fulfillment عمل التنفيذ الجاري أو المكتمل. وتوضح أيضاً تجميع البنود بحسب الموقع المتوقع تنفيذها منه. هذا وصف لنموذج Shopify، وليس إلزاماً بنسخ واجهته البرمجية في تطبيقكم.
حددوا الحدث الذي تتغير عنده الكمية
اطلبوا من الفريق وصف التسليم الفعلي للبضاعة. هل تُعد الكمية مشحونة عند طباعة الملصق، أم عند تأكيد التعبئة، أم عند تسليمها إلى شركة النقل؟ هذه أحداث مختلفة. اختاروا الحدث المعتمد بوضوح، واستخدموا أسماء صادقة للحالات الوسيطة.
إذا كان تأكيد وصول البضاعة مهماً، فسجلوه بصورة مستقلة عن الشحن. رقم التتبع مرجع لشحنة، وليس تعريفاً تلقائياً لاستلام العميل وفق قواعد عملكم. حددوا من يحق له تأكيد كل حدث، أو أي تكامل موثوق يقبله النظام، وما الذي يظهر للموظفين إذا لم يصل التأكيد بعد.
وللتصحيح معنى يجب الاتفاق عليه. إلغاء ملصق قبل خروج البضاعة يختلف عن اكتشاف أن بضاعة خرجت بالفعل سُجلت على بند خاطئ. اطلبوا مسار تصحيح يحتفظ بتفسير التغيير، من دون الإيحاء بأن حركة البضاعة الفعلية قد أُلغيت.
اجعلوا للجزء المتبقي مسؤولاً ونهاية واضحة
لا تكفي كمية صغيرة في صفحة تفاصيل الطلب لإدارة المتابعة. حددوا أين يجد الموظفون البنود المتبقية، ومن يتابعها، وما الإجراء التالي المطلوب. وافصلوا بين موعد شحن مستهدف وموعد مؤكد التزمتم به أمام العميل، حتى لا يتحول التخمين إلى وعد.
هل يمكن إلغاء الباقي، أو استبداله، أو إرساله من موقع آخر؟ عند الاستبدال، يجب أن يظل واضحاً ما وافق العميل على استلامه فعلياً، لا أن يُغيَّر اسم الصنف الأصلي بصمت. وإذا سمحتم بإغلاق طلب لم تُورد جميع بنوده، فاطلبوا سبباً واضحاً وإظهار الكمية المتبقية الملغاة.
لا تدمجوا افتراضات الدفع والفوترة في هذه الميزة. السماح بإصدار فاتورة بعد تسليم جزئي، أو أثره على استرداد مبلغ، أو اعتباره وفاءً بعقد، مسائل منفصلة تحتاج إلى قواعد عمل واستشارة مختصة عند اللزوم. لا ينبغي لشاشة الشحن أن تخترع تلك القواعد.
أخبروا العميل عن الدفعة المحددة
حددوا ما تتضمنه رسالة التحديث: الأصناف التي خرجت، والأصناف المتبقية، والشحنة التي يخصها رابط التتبع. عند وجود عدة طرود، قد يكون زر واحد بعنوان «تتبّع طلبك» غامضاً. اطلبوا صياغة تعرّف الشحنة المقصودة ولا توحي بأن جميع البضائع أصبحت في الطريق.
واتفقوا على إمكانية إعادة إرسال الإشعار من دون إنشاء سجل شحن جديد. تسجيل تقدم البضاعة وإرسال رسالة عنه عمليتان منفصلتان. إذا فشلت الرسالة، يحتاج الفريق إلى حالة واضحة للتواصل، لا إلى تكرار تسجيل الشحنة لمحاولة الإرسال مجدداً.
اختبروا طلباً مقسماً قبل قبول الميزة
استخدموا أصنافاً وعناوين وهمية في اختبارات القبول. اطلبوا عرض شحنة أولى مع بقاء جزء مفتوح، ثم شحنة لاحقة، وحالة أخرى يُلغى فيها الباقي.
اتفقوا أيضاً على النتائج التالية:
- لا تستهلك الشحنة كمية أكبر من المسموح بشحنه حالياً، إلا عند وجود استثناء معتمد صراحة.
- لا تؤدي محاولتان متزامنتان من موظفين إلى تسجيل البضاعة المتبقية مرتين من دون تنبيه أو منع مناسب.
- تبقى الشحنات السابقة ظاهرة بعد إلغاء الباقي.
- تُصحح البيانات الخاطئة وفق سياسة السجل وحركة البضاعة المتفق عليها.
- يحدد كل إشعار للعميل الأصناف والشحنة المعنية.
- لا تنشئ إعادة محاولة الإشعار عملاً إضافياً لتنفيذ الطلب.
- لا يُغلق الطلب إلا وفق قاعدة الإكمال أو الإلغاء المتفق عليها.
هذه متطلبات قبول، وليست تصميماً تقنياً كاملاً لمعالجة التزامن والتكاملات. على المطور إثبات التزام جميع الواجهات التي تعدل المخزون أو تسجل الشحن بهذه القواعد.
عند مناقشة تطبيق لإدارة الطلبات والعمليات، أحضروا وصفاً منزوع الهوية لتسليم فعلي جرى على دفعات، من دون بيانات العملاء. السؤال الأهم هو ما يحدث للالتزام الذي لم يُنفذ بعد خروج الطرد الأول.
المصدر وحدود الاستناد إليه
Shopify، مرجع FulfillmentOrder: https://shopify.dev/docs/api/admin-graphql/latest/objects/FulfillmentOrder
يدعم المرجع التمييز بين عمل التنفيذ المخطط والعمل الجاري أو المكتمل، بما في ذلك تجميع البنود حسب الموقع. أما أحداث الشحن ومسؤولية متابعة الباقي والتصحيحات والرسائل وقواعد القبول الواردة هنا، فهي متطلبات مقترحة تحتاج إلى تنفيذ واختبار منفصلين. وليست مزايا موثقة بالكامل في Shopify أو مشورة قانونية.