كريم يبيع ملابس الأطفال. عنده متجر ووكومرس، وصفحة إنستغرام تصلها طلباتها الخاصة، ومنذ فترة قصيرة واجهة على سوق إلكترونية. ثلاث قنوات بيع، ورفّ واحد في مستودعه ببئر خادم. كلّ مساء يقارن ثلاث قوائم طلبات بما تبقّى عنده، ومرّةً في الأسبوع يبيع فستاناً لم يعد لديه. الزبون ينتظر، يغضب، الطرد يعود، وكريم يعيد ثمن توصيلٍ دفعه هو.
المشكلة ليست في وجود ثلاثة مواقع، بل في وجود ثلاثة مخزونات. إليك كيف تربط موقعين أو ثلاثة بمخزون واحد، مخزون المـوارد، حتى تختفي الكمية المباعة في مكانٍ ما من كلّ الأماكن.
المبدأ: حقيقة واحدة، والمواقع تقرأها
في المـوارد، لكلّ منتج مرجع (SKU) وكمية في المخزون. هذه الكمية وحدها هي المعتمدة. مواقع البيع لا تمسك حساباً خاصاً بها: تستقبل الكمية من المـوارد وترسل إليها كلّ طلب. حين يصل طلب من موقع، ينقص المخزون في المـوارد، وتستقبل المواقع الأخرى الكمية الجديدة.
مفتاح كلّ شيء هو المرجع. يجب أن يحمل المنتج نفسه رمز SKU نفسه في كلّ موقع وفي المـوارد. «ROBE-ROSE-6A» في ووكومرس، و«ROBE-ROSE-6A» في السوق الإلكترونية، و«ROBE-ROSE-6A» في المخزون. ساعة واحدة لتوحيد المراجع توفّر شهوراً من التصحيح اليدوي.
الموقع الأول: ووكومرس، بدون سطر برمجة واحد
بالنسبة لووكومرس، كلّ شيء جاهز في وحدة التجارة الإلكترونية بالمـوارد:
- في ووكومرس: الإعدادات، متقدّم، REST API، «إنشاء مفتاح» بصلاحيات القراءة والكتابة.
- في المـوارد، صفحة التجارة الإلكترونية: الصق عنوان المتجر والمفتاح والسرّ، ثم «اختبار الاتصال».
- «استيراد المنتجات»: المطابقة تتمّ عبر SKU. المنتجات المعروفة تُربط، والمجهولة يُشار إليها.
- فعّل «دفع مخزوني إلى المتجر»: بمجرّد تغيّر كمية في المـوارد، يستقبل الموقع القيمة الجديدة.
- فعّل «استيراد الطلبات فورياً»: ووكومرس يستدعي المـوارد عند كلّ طلب، فيظهر الطلب في قائمة التأكيد ويُخصم المخزون.
سجلّ المزامنات، في الصفحة نفسها، يعرض كلّ تبادل. إن كان منتج في الموقع بلا مقابل، تراه هناك مع رمز SKU الخاص به.
الموقعان الثاني والثالث: عبر الواجهة البرمجية (API)
لسوق إلكترونية، أو موقع مصمّم خصيصاً، أو بريستاشوب، أو متجر ثانٍ، توفّر المـوارد واجهة برمجية برمز وصول. تجد الرمز في القائمة، مدخل «API والرمز»، ويُرسل في ترويسة كلّ طلب:
Authorization: Token رمزكنداءان يكفيان لإدارة مخزون مشترك.
قراءة الكميات
GET https://almawarid.app/api/stock/products/?active=1الردّ يسرد كلّ منتج بمعرّفه ورمز SKU والباركود وسعر البيع والكمية الحالية. موقعك الثاني يستدعي هذا العنوان كلّ خمس أو عشر دقائق، يجد كلّ مادة عبر SKU ويحدّث كمياته. المادة التي بلغت الصفر تصبح «غير متوفّرة» في الموقع قبل أن يطلبها زبون.
التصريح ببيع
POST https://almawarid.app/api/stock/move/
{"product_id": 128, "delta": -2, "reason": "طلب السوق الإلكترونية رقم 4471"}حين يصل طلب إلى الموقع الثاني، يرسل سكريبتك خروجاً من المخزون لكلّ سطر: فرق سالب، وسبب يسمح لك لاحقاً بالعثور على الطلب. إن كان الخروج سيجعل المخزون سالباً، ترفضه المـوارد: هذه إشارة إلى أنّ زبوناً اشترى القطعة الأخيرة في مكان آخر قبل ثوانٍ، وأنّ عليك إخبار زبونك قبل الشحن.
دخول بضاعة، أو إرجاع من زبون، أو جرد، يُصرَّح بها بالطريقة نفسها بفرق موجب.
من يكتب هذا السكريبت؟
مطوّر يقضي فيه نصف يوم: مهمّة مجدولة تقرأ الكميات وتحدّث الموقع، ونقطة استقبال تتلقّى طلبات الموقع وتصرّح بالخروج. منصّات الأتمتة التي تستطيع استدعاء عنوان ويب بترويسة تفي بالغرض أيضاً للأحجام المتوسطة. وحدة «API والويب هوك» في المـوارد تقدّم أمثلة النداءات، ويمكنك التجربة برمز وصول قبل ربط أيّ شيء في الإنتاج.
ما الذي يتغيّر عند كريم
- لم يعد ينظر إلا إلى رقم واحد: الكمية في المـوارد. وهي صالحة للقنوات الثلاث.
- قطعة بيعت على إنستغرام، أُدخلت في عشر ثوانٍ عبر الإدخال السريع، تختفي من موقع ووكومرس ومن السوق الإلكترونية في الدقائق التالية.
- طلبات القنوات الثلاث تصل إلى قائمة التأكيد نفسها: مكالمة، رسالة واتساب، وينطلق الطرد بتعريفة التوصيل الصحيحة حسب الولاية.
- نسبة الإرجاع تنخفض، لأنّه لم يعد يرسل أبداً طرداً لمادة لم تعد عنده.
وحدة التجارة الإلكترونية متاحة عند الطلب، مع رابط ووكومرس مضمّناً؛ والوصول إلى الواجهة البرمجية جزء من وحدة «API والويب هوك». افتح حساباً، اربط موقعك الأول، واطلب منّا الموقعين الآخرين.