كيف تعمل جلسة Punchout خطوة بخطوة

تبدو جلسة Punchout للمستخدم تدفقًا واحدًا، لكن عدة أنظمة تشارك فيها. إليك ما يحدث مع وجود طبقة وسيطة بين المشتري ومتجرك.

Buyer's ERP / procurement system
        |  1. punchout request
        v
   Middleware  ---- 2. request + session ID --->  Your shop
        ^                                            |
        |  4. mapped basket (cXML / OCI)             | 3. user shops
        +--------------- basket <--------------------+
        |
        v
Buyer's system: approval -> purchase order -> you

1. يبدأ المشتري الجلسة

يختار موظف كتالوجك من نظام المشتريات لديه. يرسل النظام طلب Punchout إلى عنوان سجّلته لدى المشتري، وهذا العنوان يشير إلى الطبقة الوسيطة.

2. تحوّل الطبقة الوسيطة الطلب مع معرّف جلسة

تتحقق الطبقة الوسيطة من هوية الطالب، وتنشئ معرّف جلسة (session ID)، وتحوّل الطلب إلى متجرك. وتتذكر أي مشترٍ وأي عنوان عودة وأي صيغة تخص هذه الجلسة.

3. يتسوّق المستخدم في متجرك

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

4. تقوم الطبقة الوسيطة بربط السلة

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

5. يعتمد المشتري ويطلب

تصل السلة إلى نظام المشتري كسلة تسوّق، وتمر بمسار الاعتماد المعتاد، ثم تتحول إلى أمر شراء يصلك كطلب دون أن يعيد أحد كتابته.

لماذا يهم معرّف الجلسة

قد يكون كثير من المستخدمين داخل متجرك في اللحظة نفسها، لمشترين مختلفين. معرّف الجلسة هو ما يطابق السلة العائدة مع المشتري الصحيح وعنوان العودة الصحيح والربط الصحيح.