تخيل أن متجرًا سعوديًا بدأ عروض الجمعة البيضاء، وكانت لديه آخر عشر قطع من منتج مطلوب. خلال دقائق، اشترى عملاء من الموقع خمس قطع، بينما باع أحد الفروع أربع قطع أخرى. لكن نظام المخزون لم يحدث الأرقام بالسرعة المطلوبة، فاستمر المتجر في استقبال طلبات جديدة. النتيجة مبيعات لا يمكن تنفيذها، وعمليات استرجاع، وعملاء ينتظرون منتجات غير متوفرة.
تظهر هنا أهمية ربط المتجر مع ERP، خصوصًا خلال التخفيضات التي ترتفع فيها الطلبات وتتغير الأسعار بسرعة. يساعد الربط الصحيح على توحيد بيانات المنتجات والمخزون والطلبات بين المتجر ونظام إدارة الموارد. لكنه يحتاج أكثر من مجرد توصيل واجهتين برمجيتين؛ إذ يجب تحديد مصدر البيانات المعتمد وكيفية التعامل مع الحجوزات والأخطاء والتحديثات المتأخرة.
في هذا الدليل نوضح طريقة مزامنة المخزون والأسعار باستخدام API وWebhooks، وكيفية الحد من البيع الزائد في WooCommerce وسلة وزد، مع خطة عملية لاختبار التكامل قبل الجمعة البيضاء 2026.
لماذا يصبح ربط المتجر مع ERP ضروريًا أثناء التخفيضات؟
قد يعمل المتجر الصغير بصورة مقبولة عندما يحدث صاحبه المخزون يدويًا مرة يوميًا. لكن هذه الطريقة تصبح خطرة مع ارتفاع المبيعات أو وجود أكثر من قناة بيع. فقد يسجل نظام نقاط البيع عملية في المعرض، بينما يظل الموقع يعرض الكمية السابقة حتى موعد المزامنة التالية.
يتيح نظام ERP جمع بيانات الشراء والتكلفة والمستودعات والطلبات في منظومة واحدة. وعندما يرتبط بالمتجر بصورة صحيحة، يمكن أن تنعكس تغييرات المخزون والأسعار دون إعادة إدخالها يدويًا. لكن جودة النتيجة تعتمد على دقة قواعد الربط، وليس على اسم نظام ERP المستخدم.
للتعرف على الصورة الأوسع، يمكنك قراءة دليل الصقر لإدارة المخزون متعدد القنوات للمتاجر السعودية. أما هذه المقالة فتركز على منع التعارض أثناء الذروة وتزامن السعر والكمية مع الطلب الفعلي.
حدد مصدر الحقيقة قبل إنشاء أي اتصال برمجي
أول قرار تقني هو تحديد النظام الذي يملك الحق في اعتماد المخزون. قد يكون ERP نفسه أو نظامًا متخصصًا لإدارة المستودعات، بحسب بنية النشاط. ويجب كذلك تحديد الجهة التي تعتمد السعر الأساسي والتخفيض الموسمي.
المشكلة تبدأ عندما يستطيع المتجر وERP تعديل الكمية بصورة مستقلة، ثم يرسل كل منهما القيمة النهائية للآخر. فإذا سجل المتجر سبع قطع وأرسل ERP عشر قطع من نسخة قديمة، فقد يعود المخزون إلى عشرة رغم حدوث مبيعات جديدة.
الحل هو وضع قواعد لملكية البيانات واتجاه التحديث. يمكن أن يستقبل ERP طلبات البيع من المتجر، بينما يظل مسؤولًا عن الرصيد المعتمد. ويجب أن تكون هناك آلية لمعرفة أي العمليات عولجت بالفعل حتى لا يؤدي تكرار الرسائل إلى خصم القطعة مرتين.
ما الفرق بين المخزون الفعلي والمخزون المتاح للبيع؟
لا يساوي عدد القطع الموجودة في المستودع بالضرورة عدد القطع التي يمكن عرضها للعملاء. فقد توجد طلبات محجوزة لم يكتمل دفعها أو وحدات مخصصة لفرع آخر أو كمية احتياطية لمعالجة فروق الجرد.
يمكن حساب الكمية المتاحة للبيع وفق قاعدة مبسطة:
المخزون المتاح = المخزون القابل للبيع فعليًا − الكميات المحجوزة − مخزون الأمان
لنفترض وجود 35 قطعة قابلة للبيع، منها خمس قطع محجوزة لطلبات قيد المعالجة، وثلاث قطع مخصصة كهامش أمان. تصبح الكمية المعروضة للبيع 27 قطعة. هذا نموذج توضيحي، ويجب التأكد من أن تعريف المخزون الفعلي في نظامك لا يخصم الحجوزات مسبقًا، حتى لا تُطرح مرتين.
| البيان | الكمية الافتراضية |
|---|---|
| المخزون القابل للبيع | 35 قطعة |
| الطلبات المحجوزة | 5 قطع |
| مخزون الأمان | 3 قطع |
| المتاح للعملاء | 27 قطعة |
يساعد هذا الفصل على عدم عرض كل الوحدات للبيع في وقت واحد. لكنه لا يمنع التعارض بمفرده؛ فعمليات الحجز تحتاج إلى تنفيذ آمن عند تزامن الطلبات.
كيف تعمل مزامنة المخزون عبر API وWebhooks؟
تسمح واجهات برمجة التطبيقات API للأنظمة بقراءة البيانات وتحديثها بطريقة منظمة. ويمكن للمتجر الاستعلام عن كمية منتج أو إرسال تفاصيل طلب، وفق الصلاحيات التي يوفرها النظام.
أما Webhooks فهي إشعارات تصل عند وقوع حدث معين، مثل إنشاء طلب أو تحديث منتج. بدل أن يسأل ERP المتجر كل دقيقة عما تغير، يمكن أن يتلقى إشعارًا ويبدأ معالجة الحدث.
لكن وصول Webhook لا يثبت وحده نجاح المزامنة. فقد تتأخر الرسالة أو تتكرر أو يفشل النظام المستقبل في معالجتها. لهذا يفضل استخدام طابور مهام يحفظ الأحداث ويتيح إعادة المحاولة ومتابعة الأخطاء، مع إجراء مطابقة دورية للأرصدة.
مثال على دورة تحديث الطلب
عندما يبدأ العميل الشراء، يتحقق النظام المسؤول من توفر الكمية ويحجزها وفق السياسة المعتمدة. بعد نجاح الدفع، تتحول العملية إلى طلب مؤكد، ثم تُحدث الأنظمة المتصلة حالة الطلب والمخزون. وإذا أُلغي طلب مؤهل لتحرير الحجز، تعاد الكمية مرة واحدة فقط.
يجب أن يميز التكامل بين إنشاء الطلب وتأكيد الدفع وشحنه وإرجاعه. لا يصح خصم المخزون مرة عند إنشاء الطلب ومرة ثانية عند الدفع، إلا إذا كانت العمليتان تمثلان مرحلتين محاسبيتين مختلفتين صُممتا دون ازدواج.
منع البيع الزائد عند وصول طلبات متزامنة
قد يصل طلبان في اللحظة نفسها لشراء آخر قطعة. إذا قرأ كل طلب أن الكمية المتاحة واحدة، ثم وافق النظام على كليهما دون حجز متزامن آمن، سيحدث البيع الزائد رغم وجود API سريع.
تحتاج هذه الحالة إلى عملية حجز ذرية أو آلية تحكم بالتزامن في النظام المسؤول عن المخزون. يجب أن ينجح أحد الطلبين فقط عندما لا تكفي الكمية لهما معًا، وأن يرى الآخر رسالة واضحة بعدم التوفر.
لا تجعل إضافة المنتج إلى السلة تعني حجزه تلقائيًا ما لم تكن هذه سياسة المتجر فعلًا. فقد يترك بعض الزوار المنتجات داخل السلة دون شراء، مما يؤدي إلى تعطيل مخزون كان يمكن بيعه لعملاء آخرين.
كيف تتعامل مع الطلبات غير المدفوعة؟
حدد مدة مناسبة للاحتفاظ بالمخزون للطلبات المعلقة، مع مراعاة طبيعة وسائل الدفع. وإذا انتهت المهلة دون تأكيد الدفع، يجب تحرير الحجز بصورة آمنة.
يوفر WooCommerce إعداد Hold Stock للطلبات غير المدفوعة، ويمكن ضبط مدته من إعدادات المخزون. لكن يجب اختبار كيفية تفاعله مع ERP وبوابات الدفع، خصوصًا عند وصول تأكيد الدفع متأخرًا.
لماذا تحتاج المزامنة إلى معرفات وأرقام إصدار؟
لا يكفي إرسال كلمة تحديث مخزون مع رقم جديد. يجب أن يعرف النظام المنتج المقصود ومصدر التحديث ووقت إنشائه وما إذا كان قد عولج مسبقًا.
استخدم SKU ثابتًا، ومعرفًا فريدًا للحدث، ورقم إصدار أو ترتيبًا منطقيًا للتغييرات عندما تسمح البنية بذلك. فإذا وصل تحديث قديم بعد تحديث أحدث، يجب ألا يستبدل الحالة الصحيحة دون تحقق.
كذلك ينبغي أن تكون معالجة الحدث قابلة للتكرار بأمان، وهو ما يعرف بمبدأ Idempotency. إذا أعادت المنصة إرسال إشعار الطلب نفسه، يتعرف عليه النظام ولا يكرر خصم المخزون أو إنشاء طلب ERP جديد.
هذه الضوابط تنفذ عادة في طبقة التكامل أو النظام المسؤول عن الأرصدة، ولا توفرها كل واجهات المنتجات تلقائيًا بمجرد استخدامها.
مزامنة الأسعار لحظيًا دون اختلاف بين المنتج والدفع
خلال الجمعة البيضاء قد يتغير السعر الأساسي أو يبدأ خصم مؤقت أو ينتهي كوبون. يجب أن يعرف فريق العمل النظام المسؤول عن اعتماد كل نوع من هذه التغييرات.
قد يكون ERP مصدر السعر التجاري، بينما تنفذ منصة المتجر قواعد التخفيضات الشرطية. في هذه الحالة لا ينبغي أن يرسل ERP السعر الأساسي ويستبدل السعر النهائي في السلة دون مراعاة قواعد الخصم المحلية.
فرق مهم بين السعر الأساسي والسعر المخفض
في WooCommerce توجد حقول مثل regular_price وsale_price مع مواعيد جدولة التخفيض. يمكن تحديث هذه البيانات عبر REST API، لكن يجب اختبار توافقها مع الكوبونات وإضافات Dynamic Pricing.
لنفترض أن السعر الأساسي لمنتج هو 300 ريال، والسعر الترويجي المعتمد 240 ريالًا. يجب أن تعرض صفحة المنتج والسلة والدفع القيمة الصحيحة وفق شروط العرض والضريبة. وإذا انتهى التخفيض أثناء وجود العميل في السلة، ينبغي إعادة حساب المبلغ وإبلاغه بوضوح قبل تأكيد الطلب.
لا تغيّر أسعار الطلبات المكتملة تلقائيًا بعد صدورها لمجرد تحديث السعر في ERP. فبيانات المعاملة السابقة يجب أن تبقى قابلة للمراجعة وفق قواعد المحاسبة والفوترة.
للتوسع في حماية الربحية، راجع دليل التسعير المرن للمتاجر السعودية الذي يوضح الفرق بين السعر الأساسي والتخفيض والهامش.
ربط WooCommerce مع نظام ERP
يوفر WooCommerce واجهات REST API للتعامل مع المنتجات والطلبات والمتغيرات، ومنها حقول manage_stock وstock_quantity وbackorders. ويجب ضبط إدارة المخزون للمنتج أو المتغير المناسب حتى تعمل الكميات كما هو متوقع.
يمكن استخدام Webhooks لإبلاغ النظام الخارجي بإنشاء الطلبات وتعديلها. وتوضح وثائق WooCommerce الرسمية كيفية إنشاء الإشعارات ومراجعة سجلات وصولها. ومن المهم مراقبتها؛ إذ قد يعطل WooCommerce الإشعار بعد عدة محاولات تسليم فاشلة متتالية.
إذا كان المتجر يستخدم ألوانًا ومقاسات متعددة، فلا تحدث كمية المنتج الأب وحدها دون مراجعة طريقة إدارة مخزون المتغيرات. فقد يؤدي ذلك إلى إظهار مقاس متوفر بينما الرصيد الفعلي لهذا المقاس نفد.
ربط متاجر سلة وزد بأنظمة ERP
توفر سلة واجهات لقراءة بيانات المنتجات والكميات، بالإضافة إلى إشعارات Webhooks لأحداث الطلبات والمنتجات بحسب الإمكانات المتاحة للتطبيق. ويمكن مراجعة توثيق Webhooks في سلة لتحديد الأحداث المناسبة وصلاحيات الوصول.
وتوفر زد Merchant API للتعامل مع المنتجات والمخزون والطلبات، وتدعم Webhooks للأحداث المعلنة في وثائقها. ويمكن الاطلاع على توثيق Webhooks في زد قبل بناء التكامل.
لا تفترض أن جميع إمكانات WooCommerce متاحة داخل سلة وزد، أو أن حدود الطلبات البرمجية متطابقة. يجب مراجعة صلاحيات التطبيق والحدود التشغيلية ونوع الحدث المدعوم في إصدار الواجهة المستخدم.
ماذا يحدث عندما تتوقف المزامنة أثناء الجمعة البيضاء؟
يحتاج التكامل إلى خطة واضحة للفشل. إذا توقف ERP أو فقد الاتصال بالمتجر، يجب أن يعرف النظام متى يستمر في قبول الطلبات ومتى يوقف بيع المنتجات الحساسة للمخزون.
يمكن استخدام قواعد احتياطية تختلف حسب نوع المنتج. فالسلعة ذات المخزون الكبير قد تتحمل تأخيرًا قصيرًا ضمن حدود محسوبة، بينما قد يحتاج منتج بقيت منه قطعتان إلى إيقاف البيع مؤقتًا حتى تأكيد الرصيد.
لا تعالج الانقطاع بإعادة إرسال جميع التحديثات عشوائيًا. احفظ الأحداث غير المعالجة داخل طابور، ثم أعد تنفيذها بترتيب مناسب مع التحقق من الإصدار والحالة الحالية. وبعد استعادة الاتصال، نفذ مطابقة للأرصدة لكشف أي اختلافات متبقية.
ما المؤشرات التي تكشف ضعف ربط المتجر مع ERP؟
ابدأ بقياس الزمن بين وقوع الحدث واعتماد التحديث في النظام الآخر. راقب متوسط التأخير وقيم P95 وP99، لأن المتوسط قد يخفي حالات تتأخر فيها بعض المنتجات بصورة كبيرة.
راقب أيضًا عدد الأحداث المعلقة ومعدل الإخفاق وعدد عمليات إعادة المحاولة والاختلافات بين الأرصدة. ويمكن إضافة مؤشر لنسبة الطلبات الملغاة بسبب عدم توفر المنتج، وآخر للمنتجات التي يظهر سعرها مختلفًا بين المتجر وERP.
| المؤشر | لماذا تراقبه؟ |
|---|---|
| زمن المزامنة | معرفة تأخر وصول تغييرات المخزون والأسعار |
| الأحداث المعلقة | كشف تراكم العمليات غير المعالجة |
| اختلاف الرصيد | تحديد المنتجات التي تحتاج إلى مطابقة |
| إلغاءات نفاد المخزون | قياس أثر المشكلة على العملاء |
| اختلاف الأسعار | تجنب التضارب بين الإعلان والصفحة والدفع |
لا توجد مدة واحدة تسمى مزامنة لحظية وتناسب جميع الأنظمة. ضع مستوى خدمة مستهدفًا وفق قدرة البنية ومخاطر المنتج، ثم اختبر الالتزام به في أوقات الضغط.
اختبارات ضرورية قبل إطلاق تخفيضات نوفمبر
جهز بيئة اختبار تمثل طريقة عمل المتجر والمستودعات دون استخدام مدفوعات حقيقية أو بيانات عملاء حساسة. ابدأ ببيع منتج من الموقع، ثم بيعه من نقطة بيع أخرى، وتحقق من وصول الرصيد الصحيح إلى جميع الأنظمة.
بعد ذلك اختبر شراء آخر قطعة بواسطة طلبين متزامنين، وإلغاء طلب معلق، وتأخر إشعار الدفع، وتكرار Webhook، ووصول تحديث مخزون قديم. اختبر كذلك تغيير سعر منتج خلال فترة التخفيض، ثم راجع السعر في صفحة المنتج والسلة والفاتورة.
إذا كان المتجر يبيع عبر عدة مستودعات، فتحقق من أن الطلب لا يخصم مخزون الفرع الخطأ. ولا تعتبر نجاح عملية واحدة دليلًا على جاهزية التكامل؛ إذ ينبغي اختبار الحالات التي تسبب التعارض عادة.
خطة تنفيذ قبل الجمعة البيضاء 2026
من 3 إلى 10 نوفمبر: توحيد البيانات والمسؤوليات
راجع معرفات SKU وتطابقها بين المتجر وERP والمستودعات. حدد مصدر الحقيقة للمخزون والسعر، ومن يملك صلاحية تعديل قواعد التخفيض. ثم سجل حالات الطلب التي تؤثر في الحجز والخصم والاسترجاع.
من 11 إلى 19 نوفمبر: تنفيذ الربط واختبار التعارض
اضبط واجهات API والإشعارات وطوابير المعالجة وسجل الأخطاء. اختبر الطلبات المتزامنة وإعادة إرسال الأحداث والمزامنة بعد الانقطاع. صحح أي اختلاف قبل تفعيل الربط على جميع المنتجات.
من 20 إلى 26 نوفمبر: تثبيت الأسعار وخطة الطوارئ
اعتمد الأسعار الترويجية ومواعيد بدايتها ونهايتها بتوقيت السعودية. راجع المخزون الاحتياطي، وجهز تنبيهات عند تأخر المزامنة. وحدد مسؤولًا يستطيع إيقاف بيع منتج عند تعذر تأكيد رصيده.
من 27 نوفمبر: المراقبة أثناء العروض
توافق الجمعة البيضاء عام 2026 يوم 27 نوفمبر. راقب الأحداث المعلقة والفروقات والمنتجات الأكثر طلبًا، ونسق مع خدمة العملاء عند ظهور مشكلة. تجنب إجراء تغييرات جوهرية في التكامل أثناء ذروة الشراء دون اختبار وخطة رجوع.
أخطاء شائعة عند ربط المتجر مع ERP
من أبرز الأخطاء الاعتماد على تحديث شامل للمخزون كل عدة ساعات مع توقع عدم حدوث بيع زائد. ويظهر خطأ آخر عند السماح للنظامين بتعديل الرصيد المطلق دون معرفة ترتيب العمليات.
كذلك قد يؤدي تجاهل المقاسات والألوان إلى اختلاف المخزون الفعلي عن المعروض. ومن الأخطاء الاعتماد على نجاح استجابة API دون التأكد من معالجة الحدث، أو إرسال تحديثات سعر قديمة بعد بدء عرض جديد.
يجب أيضًا حماية مفاتيح الوصول والتحقق من توقيع أو هوية الإشعارات وفق توثيق المنصة، ومنح التطبيقات أقل الصلاحيات اللازمة. ولا تعرض مفاتيح API في واجهة المتجر أو ملفات عامة.
أسئلة شائعة عن ربط المتجر مع ERP
هل يمنع ربط المتجر مع ERP البيع الزائد نهائيًا؟
ليس بمجرد إنشاء الاتصال. يتطلب منع التعارض إدارة حجوزات متزامنة ومصدر مخزون موثوقًا وآلية للتعامل مع الأحداث المتأخرة. وكلما تحسنت هذه الضوابط انخفض احتمال البيع الزائد، دون ضمان مطلق ضد جميع الأعطال.
هل يمكن ربط WooCommerce مع ERP دون برمجة مخصصة؟
قد توفر بعض أنظمة ERP إضافات جاهزة للربط. لكن يجب اختبار توافقها مع المنتجات المتغيرة وحالات الدفع والمخزون متعدد المستودعات قبل الاعتماد عليها في موسم مزدحم.
هل يمكن تحديث الأسعار والمخزون في سلة وزد عبر API؟
توفر المنصتان واجهات برمجية لإدارة بيانات المنتجات والمخزون وفق الصلاحيات والإمكانات المدعومة. وتختلف خطوات الربط والحدود التشغيلية بحسب المنصة والتطبيق، لذلك يجب الرجوع إلى التوثيق الرسمي قبل التنفيذ.
هل يمكن استخدام الربط نفسه مع Google Merchant Center؟
يمكن إنشاء مسار إضافي لتحديث بيانات المنتجات المستخدمة في Google Shopping. لكن توافر السعر الجديد داخل المتجر لا يعني ظهوره فورًا في جميع خدمات Google. يجب مراقبة معالجة خلاصة المنتجات وتطابق البيانات مع صفحة البيع.
الخلاصة: مزامنة المخزون قرار تشغيلي قبل أن تكون تكاملًا برمجيًا
يعتمد نجاح ربط المتجر مع ERP على وضوح مسؤولية كل نظام عن بيانات المنتجات والمخزون والأسعار. تساعد API وWebhooks على تبادل التحديثات، لكن إدارة الحجوزات ومنع التكرار ومعالجة الأخطاء هي ما يجعل التكامل مناسبًا لأوقات الضغط.
قبل الجمعة البيضاء، اختبر آخر قطعة في المخزون، والطلب الملغى، والسعر الذي يتغير أثناء الدفع. ثم راقب النتائج الفعلية بدل الاكتفاء بظهور حالة اتصال ناجح. ويمكن الاستفادة من دليل الصقر للتسويق متعدد القنوات لفهم ارتباط المبيعات بالمستودعات والفروع، أو التواصل مع فريق الصقر لتصميم وتطوير المتاجر الإلكترونية لمراجعة احتياجات المتجر الفنية وخطة تكامله مع الأنظمة الخارجية.
