فهم الفوترة

كجزء من بنود برنامج Last Mile Fleet Solution (LMFS) في "منصة خرائط Google"، تتمّ المعاملة القابلة للفوترة عند إتمام المهام المرتبطة بالشحنة بنجاح.

كائن المهمة هو نوع عنصر أساسي يلعب دورًا رئيسيًا في تتبُّع المعاملات القابلة للفوترة وإعداد التقارير عنها في LMFS Deliveries API. تتطلّب بنودنا منك وضع نماذج لمهام السائق بشكل صحيح وتسجيل السمة TaskOutcome بشكل مناسب. يضمن ذلك تسجيل جميع المعاملات القابلة للفوترة بشكل صحيح. بالنسبة إلى العملاء المتعاقدين، راجع متطلبات إعداد التقارير السارية لمنتجك:

• متطلبات إعداد تقارير الحلول التي توفّرها شركة Last Mile Fleet
• متطلبات إعداد التقارير بشأن خدمات التنقّل

ما المهمة القابلة للفوترة؟

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

يقدم الجدول التالي بعض السيناريوهات الواقعية للمهام القابلة للفوترة وغير القابلة للفوترة.

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

كيف تتم الفوترة داخل واجهة برمجة تطبيقات Deliveries API؟

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

• تم ضبط نوع المهمة على delivery. لا تؤدي مهام الاستلام إلى بدء الفوترة، ولا تؤدي الفواصل أو المحطات المجدوَلة إلى بدء الفوترة. يجب أن تحتوي كل معاملة قابلة للفوترة على مهمة تسليم مرتبطة بها. يمكن أن يتم تصميم مهمة الاستلام لعمليات الاستلام من الميل الأول التي يتم تسليمها إلى المستودع في موقع الاستلام ومهمة التوصيل في المستودع.

• تكون قيمة السمة TaskOutcome هي SUCCEEDED.

تُنشئ واجهة برمجة التطبيقات Last Mile Fleet Solution Deliveries API حدثًا قابلاً للفوترة في المرة الأولى التي يتم فيها تعديل TaskOutcome بقيمة SUCCEEDED. عندما يحدث هذا، فإنه يزيد مقياس الفوترة لرمز التخزين التعريفي هذا. لن تؤثر أي تعديلات لاحقة يتم إجراؤها على هذه المهمة في مقياس الفوترة هذا، والذي لا يمكن زيادته أو تقليله بعد تحديد النتيجة لأول مرة.

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

كيف يجب أن تضع نموذجًا لمهامك؟

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

ملاحظة: يجب الرجوع إلى العقد ومتطلبات إعداد التقارير للاطّلاع على التفاصيل الكاملة.

• حدِّد الحقول المناسبة لمهام الشحن. اضبط نوع المهمة على delivery وعيّن معرّف مهمة فريدًا، ثم حدِّد الموقع الجغرافي الصحيح لإكمال كل مهمة. التأكد من أن كل شحنة لها مهمة تسليم.
• أنشِئ مهام منفصلة لكل مجموعة من مستلِمي الشحن ومستلِميها. على سبيل المثال، استخدم مهمتين لمتلقي واحد من عدة جهات شحن. أو، بالنسبة لموقع التسليم الواحد الذي يتم فيه تسليم حزم متعددة إلى عدة مستلمين، قم بإنشاء مهام متعددة.
• حدِّد المهام المتعلّقة بعدم الشحن بشكل صحيح. بالنسبة إلى المحطات المجدولة، اضبط المهمة Type على SCHEDULED_STOP. بالنسبة إلى أوقات فواصل السائق، اضبط السمة Type على UNAVAILABLE.
• يجب ضبط الحقل TaskOutcome بشكل مناسب. عند اكتمال المهمة، تأكَّد من أنّ عملية التنفيذ تضبط السمة TaskOutcome على السمة SUCCEEDED أو السمة FAILED. مجرّد تعديل مهمة مكتملة إلى حالة CLOSED لا يتوافق مع أحكامنا. يمكنك تحديد نتيجة المهمة باستخدام حزمة Driver SDK أو gRPC أو REST.

لمزيد من المعلومات، راجع موضوعات دليل مستخدم Fleet Engine التالية:

• تعديل مهمة
• إغلاق مهمة
• تحديد نتيجة المهمة وموقع النتيجة