يساعد الربط المفيد بين شوبيفاي وأودو المتجر الإلكتروني والمستودع وفريق المالية على العمل بسجلات متّسقة. ابدأ بتحديد النظام المرجعي لكل حقل، ثم اختبر انتقال المعلومات عندما يتغيّر الطلب. ربط الحسابين هو بداية العمل.
تتناول هذه القائمة استخدام موصّل من طرف ثالث أو بناء تكامل مخصّص. ولا تفترض أن موصّلًا معيّنًا يدعم كل إصدار من أودو أو كل إعداد في شوبيفاي أو جميع إجراءات العمل. تخصّ مراجع واجهة أودو البرمجية الإصدار 19؛ تحقّق من متطلبات البيئة التي ستستخدمها فعليًا.
1. حدّد أول مسار عمل وحدوده
اكتب جملة تصف المرحلة الأولى، مثل: «استيراد طلبات شوبيفاي المعتمدة إلى أودو، وحجز المخزون، وإعادة بيانات الشحن إلى شوبيفاي». حدّد متى يصبح الطلب مؤهّلًا للاستيراد، والمتجر والمستودع المشمولَين، والحالات التي تحتاج إلى تدخّل شخص.
افصل هذا المسار عن الخطوات اللاحقة، مثل نشر كتالوج المنتجات أو تسويق العملاء أو تعدد العملات أو مخزون الأسواق الإلكترونية. خصّص لكل إضافة معايير قبول. فقد ينجح الربط مع الطلبات الاعتيادية، ويتعثر مع حزم المنتجات أو الاشتراكات أو الطلبات المعدّلة.
تحقّق من إمكانية الوصول قبل اختيار الموصّل. تنصّ وثائق واجهة أودو البرمجية للإصدار 19 على إتاحة الواجهة الخارجية ضمن خطط Custom، وعدم إتاحتها ضمن One App Free أو Standard. أكّد الخطة المختارة ونوع الاستضافة ومتطلبات الموصّل مع الجهة المسؤولة.
2. عيّن مصدرًا مرجعيًا لكل حقل
وجود السجل في النظامين لا يعني السماح لكليهما بتعديل كل حقوله. جهّز جدول ربط يحدّد الحقل والنظام المرجعي واتجاه النقل والحدث الذي يبدأه وقاعدة حل التعارض. الجدول التالي نقطة بداية توضيحية، وليس تصميمًا إلزاميًا.
| البيانات | مصدر مرجعي مقترح | القرار المطلوب توثيقه |
|---|---|---|
| هوية المنتج | سجل المنتجات الأساسي في أودو | ربط ثابت للمنتجات ومتغيّراتها، ومعالجة رموز SKU المفقودة أو المتكررة |
| أوصاف واجهة المتجر | شوبيفاي | هل يُسمح لتحديثات الكتالوج باستبدال النصوص التسويقية؟ |
| المخزون المتاح للبيع | طريقة حساب متّفق عليها لمستودع أودو | المواقع المشمولة والحجوزات والكمية الاحتياطية والبضاعة التالفة |
| طلب المتجر الإلكتروني | شوبيفاي عند الشراء | توقيت الاستيراد وكيفية معالجة التعديل أو الإلغاء لاحقًا |
| تأكيد الشحن | عملية تجهيز الطلب وشحنه | النظام الذي يسجّل الكميات المشحونة وبيانات التتبّع |
| حالة ردّ المبلغ | دليل معاملة الدفع | مطابقة المبالغ والبضاعة المرتجعة والسجلات الدائنة |
استخدم معرّفات السجلات الخارجية إلى جانب رموز الأصناف SKU. فقد يتغيّر اسم المنتج، ويجب أن يؤدي غياب الرمز إلى حالة ربط غير محلولة ظاهرة للفريق، لا إلى مطابقة عرضية. وضّح قواعد مطابقة العملاء أيضًا؛ فالبريد الإلكتروني وحده قد لا يميّز بين جهات الاتصال أو عناوين التسليم المختلفة للشركة نفسها.
3. راجع قدرات الموصّل بأمثلة واقعية
اطلب من المورّد عرضًا يستخدم الإصدار والاستضافة ومتغيّرات المنتجات وتنظيم المستودعات ومسار الدفع التي تقصد استخدامها. واطلب قائمة مكتوبة بالعمليات المدعومة والاستثناءات المعروفة وسياسة التحديث والمسؤول عن حل الأعطال. قارن عبء صيانة الموصّل بالمسؤوليات التي ستتحملها عند بناء تكامل مخصّص.
لا تختزل الشحن في علامة واحدة تقول «تم الشحن». يشرح توثيق FulfillmentOrder في شوبيفاي تخصيص الأصناف لموقع تنفيذ، وإمكانية وجود عدة أوامر تنفيذ للطلب الواحد. اختبر الشحن الجزئي وتغيير الموقع بحسب السلوك الفعلي للموصّل.
كذلك، افصل وجود سجل استرداد عن نجاح ردّ المال. يوضّح مرجع Refund أن حالة معاملة الدفع تحدّد ما إذا أُعيدت الأموال فعلًا. وقرّر بصورة منفصلة ما إذا كانت البضاعة المرتجعة قابلة للبيع أو تالفة أو بانتظار الفحص.
4. خطّط للتحديثات المكررة والمتأخرة والمفقودة
يوضّح شوبيفاي أن ترتيب وصول إشعارات Webhook غير مضمون، ويوصي بالمطابقة الدورية لاستعادة التحديثات التي فاتت. يجب ألّا يستبدل إشعار وصل متأخرًا معلومات أحدث دون تحقّق. اسأل كيف يفحص التكامل الحالة الحالية ويسجّل الفروق غير المحلولة. راجع إرشادات سلوك إشعارات شوبيفاي.
عند استقبال إشعارات Webhook عبر HTTPS، تحقّق من التوقيع قبل قبول المحتوى. ويجب ألّا يؤدّي تكرار وصول الإشعار إلى إنشاء طلب ثانٍ أو تكرار حركة مخزون. تتناول إرشادات التحقّق من الإشعارات فحص التوقيع ومعالجة التكرار. وتحتاج العمليات نفسها إلى معرّفات ثابتة تتيح استئناف المحاولة بأمان بعد الانقطاع.
وفّر لفريق العمليات قائمة بالحالات المتعطّلة، تشمل الطلب المتأثر والخطوة التي فشلت وآخر محاولة والمسؤول. حدّد الأعطال التي يمكن إعادة محاولتها تلقائيًا وتلك التي تحتاج إلى تحقيق. يجب أن تقارن المطابقة السجلات والكميات والإجماليات الفعلية بالمتوقعة؛ فمؤشر اتصال أخضر لا يثبت اتّساقها.
5. نفّذ اختبارات القبول قبل التوسّع
| الاختبار | الدليل المطلوب |
|---|---|
| وصول بيانات الطلب نفسه مرتين | طلب تجاري واحد وأثر واحد مقصود على المخزون |
| متغيّر منتج غير معروف | حالة استثنائية ظاهرة دون اختيار منتج بديل تلقائيًا |
| شحن جزئي | تطابق الكميات المشحونة والمتبقية في النظامين |
| إلغاء بعد حجز المخزون | توافق الحجز وحالة الطلب مع قاعدة الإلغاء المعتمدة |
| ردّ جزء من المبلغ | صحة مبالغ البنود وحالة الدفع، مع قرار منفصل لمعالجة المخزون |
| انقطاع الاتصال | استعادة التغييرات المفقودة دون تكرار العمليات المكتملة |
مثال افتراضي: مصباحان ومرتجع واحد
لنفترض أن متجرًا يبيع مصباحين في طلب واحد. يُشحن الأول اليوم، ويُلغى الثاني قبل الشحن. ثم يعود المصباح المشحون تالفًا. هذه حالة اختبار افتراضية وليست تجربة لعميل لدى لافا.
على الفريق تتبّع معرّف الطلب والكميات المحجوزة والشحنة والبند الملغى ومعاملة ردّ المبلغ في النظامين. يجب أن يتبع المرتجع التالف إجراء الفحص المتّفق عليه، بدلًا من زيادة المخزون القابل للبيع تلقائيًا. وعند إعادة تشغيل التحديث نفسه، يجب أن تبقى الكميات النهائية والسجلات المالية متّسقة.
جهّز مواصفات ربط قابلة للمراجعة
اجمع جدول ربط البيانات وطلبات تمثّل عملك وقواعد الاستثناءات ونتائج القبول لمناقشتها مع فريق التطبيق. حدّد من يراقب الأعطال ومن يملك صلاحية إيقاف المزامنة مؤقتًا. احتفظ بإجراء للاستعادة، وطابق نتائج التجربة قبل إضافة منتجات أو مواقع أخرى.
راجع الفرق بين إعداد أودو وتخصيصه أو تعرّف إلى خدمات أودو لدى لافا. تواصل معنا مع وصف الأنظمة الحالية وأول مسار تريد ربطه. ولتنظيم المتابعة حول الطلب، اقرأ دليل إدارة عملاء المتجر الإلكتروني.