مسار البيع الأساسي: يبدأ الطلب طلبًا غير قابل للدفع، ولا يصير قابلًا للدفع إلا بعد أن يؤكّد المورّد التوفّر، ثم يتبع ذلك الدفع ودفع الطلب إلى نظام تخطيط الموارد.

1. 1يُنشئ العميل سلّة ويقدّم طلبًا، فتُلتقط أسعار البنود ويُنشأ طلب غير قابل للدفع
2. 2يُسنِد الفريق عروض المورّدين لكل بند ويُصدر طلبات تأكيد التوفّر، لكلٍّ منها اتفاقية مستوى خدمة مدّتها 24 ساعة
3. 3يستجيب المورّدون لكل بند عبر البوّابة، ومهمّة Celery beat تتعقّب التأكيدات المتأخّرة
4. 4تُقدّم evaluate_order_after_confirmation آلة الحالات فيصبح الطلب قابلًا للدفع
5. 5تُصدر create_payment_for_order رابط دفع عبر Moyasar/Tap/Stripe وتُشعر العميل
6. 6يُعلّم webhook بوّابة الدفع الطلب بحالة PAID، فتنطلق الإشعارات ويُدفع الطلب إلى Odoo

يحوّل رقم VIN أو اختيار مركبة إلى مجموعة دقيقة من القطع مُرشَّحة بحسب الملاءمة، مضبوطة للعلامات الصينية والكورية.

1. 1يُدخل العميل رقم VIN أو يختار العلامة والطراز والجيل والمحرّك
2. 2يفكّ النظام الخلفي ترميز VIN عبر NHTSA vPIC، ويعود إلى 17vin للعلامات الصينية، ثم يُخزّن النتيجة مؤقتًا
3. 3تُترجَم المواصفات المفكوكة إلى سجل VehicleModel، وتُرشّح سجلات PartFitment الكتالوج إلى القطع التي تلائم المركبة فعلًا

مساعد قابل لتبديل المزوّد يستدعي الأدوات ويجيب عن أسئلة القطع اعتمادًا على حقائق الكتالوج وحدها، مدعومًا باسترجاع قائم على التضمينات.

1. 1يدخل سؤال العميل في حلقة استدعاء أدوات مع النموذج اللغوي المُهيّأ
2. 2يبحث الوكيل في الكتالوج ويفكّ ترميز أرقام VIN ويتحقّق من الملاءمة عبر أدوات لا تُرجع سوى حقائق الكتالوج
3. 3يسترجع RAG القطع المرشّحة بتشابه جيب التمام على التضمينات المخزّنة، ويردّ المساعد بلغة العميل مع قطع مقترحة

تُبقي التوفّر متزامنًا مع نظام تخطيط الموارد بوصفه المصدر المرجعي، مع دعم المورّدين الذين لا يملكون نظام تخطيط موارد.

1. 1يحتفظ Odoo بالكميات المتاحة المرجعية لمورّد المستودع الداخلي
2. 2يقرأ أمر إداري مستويات الكميات المتاحة عبر XML-RPC ويعكسها في عروض ذلك المورّد
3. 3أمّا المورّدون الذين لا يستخدمون Odoo فيُحدّثون التوفّر مباشرة عبر البوّابة أو باستيراد جماعي من Excel