كيف تدير المخزون بين متجرك والمنصات: المشكلة ليست في العدد
البائع الذي يبيع في متجره على سلة أو زد ويبيع في الوقت نفسه على نون أو أمازون السعودية يصل إلى الحالة نفسها دائماً: طلب يُقبل على المنصة لمنتج نفد فعلياً، ثم إلغاء، ثم أثر على تقييم البائع. والتشخيص المتداول أن «الأرقام غير محدّثة»، وهذا تشخيص مريح لأنه يقترح حلاً واحداً: أداة مزامنة.
لكن معظم حالات البيع الزائد التي نراها ليست مشكلة تحديث. هي مشكلة تعريف. كل قناة لديها تعريفها الخاص لما يُعتبر «متاحاً للبيع»، والرقم الذي ترسله من نظام إلى آخر يحمل معنى واحداً في المصدر ومعنى آخر في الوجهة.
وهذا المقال مبني على ما توثقه المنصات نفسها عن هذه النقطة، لا على ممارسات شائعة. والمفردات الموثقة أهم من الأداة، لأنها هي ما يحدد الإعداد الصحيح للأداة.
حالات المخزون الموثقة، ولماذا تهمك
أوضح توثيق منشور لهذه المسألة هو توثيق شوبيفاي لحالات الكميات. وهو يستحق القراءة حتى لو كان متجرك على سلة أو زد، لأن المشكلة التي يصفها واحدة في كل المنصات والفرق في التسمية فقط.
تنص صفحة شوبيفاي عن إدارة حالات الكميات، وهي بالإنجليزية، على أن حالة on_hand تمثل إجمالي عدد الوحدات الموجودة فعلياً في الموقع. ثم تقول إنها تساوي مجموع الكميات في الحالات التالية:
| الحالة | ما تعنيه بحسب التوثيق |
|---|---|
| available | القابل للبيع فعلاً، وهو ما تفصله الصفحة عن الحالات غير المتاحة |
| committed | مخصص لطلبات قائمة، والصفحة تقول إن شوبيفاي تديره ولا يستطيع التطبيق تعديله أو نقله |
| reserved | وحدات موجودة جُنّبت مؤقتاً |
| damaged | وحدات أُخرجت من العدّ بسبب التلف |
| safety_stock | وحدات موجودة جُنّبت للحماية من البيع الزائد |
| quality_control | وحدات غير قابلة للبيع لأنها تحت الفحص |
وتذكر الصفحة أن حالة incoming ليست ضمن هذا المجموع، وهي تفصيلة عملية: الكمية التي في الطريق إليك ليست جزءاً من الموجود.
النتيجة المباشرة: إذا أرسلت رقم on_hand إلى قناة أخرى على أنه المتاح للبيع فأنت تعرض للبيع وحدات مخصصة لطلب قائم، أو تالفة، أو تحت الفحص. وهذا بيع زائد سببه تعريف، لا تأخير في المزامنة.
تريد تحديد أي حالة من حالات مخزونك تُعتبر «متاحاً للبيع» في كل قناة؟
اطلب تشخيصاً مجانياًأنماط التحديث الثلاثة، وما توصي به سلة نفسها
هنا تصبح المسألة سعودية على وجه التحديد، لأن توثيق سلة للمطورين يعالجها بصراحة أكثر من معظم ما يُكتب عنها.
تصف صفحة سلة لتحديث الكميات بالجملة، وهي بالإنجليزية، ثلاثة أنماط لتحديث الكمية، وتوصي بأحدها وتحذّر من آخر:
| النمط | الاستخدام بحسب التوثيق |
|---|---|
| increment | إضافة مخزون: استلام كمية جديدة، إرجاع مرتجع، تصحيح عدّ ناقص |
| decrement | خصم مخزون: بيع، تلف، تسويات جرد |
| overwrite | الإعداد الأولي فقط: تحديد الكميات لأول مرة، إعادة تعيين كاملة، والمزامنة مع أنظمة خارجية «مع الحذر» |
والصفحة تذكر توصية صريحة باستخدام الإضافة والخصم بدلاً من الاستبدال، لإدارة أفضل للمخزون وسلامة البيانات. وتشرح السبب بمثال واضح: خصم خمس وحدات يخصم خمساً بغض النظر عن أي عملية متزامنة، أما استبدال الرقم بـ95 فقد يمحو تغييرات أجرتها عمليات أخرى. وتسمي هذا أمان التزامن ومنع حالات التسابق.
اقرأ هذا جيداً، لأن أغلب أدوات المزامنة الرخيصة تعمل بالاستبدال. هي تقرأ الرقم من مكان وتكتبه في مكان آخر كل خمس عشرة دقيقة. وفي الموسم، حين تأتي ثلاث عمليات شراء في الدقيقة الواحدة من ثلاث قنوات، فإن أي كتابة بالاستبدال تمحو ما سجّلته القناتان الأخريان. والمنصة التي تبيع عليها تقول لك هذا في صفحة توثيقها، لا في بريد دعم.
مخزون الأمان: قرار مقصود لا خطأ في العدّ
أغلب البائعين يصلون إلى مخزون الأمان بعد أول كارثة، ويعتبرونه حلاً مرقّعاً. التوثيق يصنّفه حالة قائمة بذاتها: صفحة شوبيفاي تصف سبب حالة safety_stock بأنه تخصيص وحدات موجودة فعلياً للحماية من البيع الزائد.
وهذا يغيّر طريقة الحديث عنه داخل المنشأة. ليس «نترك وحدتين احتياطاً لأن النظام غير دقيق»، بل «نحتجز وحدتين لأن زمن انتشار التحديث بين قنواتنا ليس صفراً». والفرق أن الصيغة الثانية قابلة للقياس والمراجعة.
والمقدار لا يوجد له رقم منشور، ولن نخترع واحداً. ما يحدده عاملان: كم دقيقة يأخذ التحديث للوصول إلى أبطأ قناة لديك، وكم وحدة تبيع من هذا المنتج في تلك المدة في أعلى يوم. المنتج الذي يبيع وحدة في الأسبوع لا يحتاج احتياطاً، والمنتج الذي يبيع عشرين وحدة في يوم جمعة بيضاء يحتاج أكثر مما تظن.
من هو مصدر الحقيقة، ولماذا السؤال غير قابل للتأجيل
قبل أي أداة، قرار واحد: أي نظام يملك الرقم. والاحتمالات ثلاثة فقط، ولكل منها ثمن صريح.
- متجرك هو المصدر. مناسب إذا كان أغلب بيعك من متجرك. الثمن أن كل قناة أخرى تتبع متجرك بتأخير، فتحتاج مخزون أمان أعلى على القنوات.
- نظام مستقل للمخزون هو المصدر. الأنسب تشغيلياً عند ثلاث قنوات أو أكثر، وأغلى، ويضيف نظاماً جديداً يجب أن يعمل دائماً.
- كل قناة تملك حصتها. تقسيم الكمية الفعلية بين القنوات بحيث لا تتنافس. يُهدر مخزوناً لكنه يمنع البيع الزائد تماماً، وهو الخيار الصحيح للمنتج الواحد النادر لا للكتالوج كله.
الخطأ الشائع ليس اختيار الخيار الخطأ، بل عدم الاختيار: نظامان يكتبان على بعضهما، ولا أحد يعرف أي رقم هو الصحيح. وأثر هذا على التدفق النقدي وعلى صحة الحساب لدى المنصة تناولناه ضمن مشاكل البائعين على المنصات وحلولها.
وإذا كان القرار الأكبر لديك ما زال هل تضيف قناة أصلاً، فالحسبة التي تحسم ذلك في حساب الربحية الحقيقية بعد عمولات المنصة، ومتطلبات التسجيل على نون في كيف تبيع على نون السعودية كبائع.
ما لا يصل إليك إشعار به
التفصيلة التي تكلّف أكثر من غيرها هي أن ليس كل تغيير في المخزون يُطلق إشعاراً. ووثائق سلة تذكر حدثاً باسم product.quantity.low يُطلق عند انخفاض كمية المنتج، وهذا نافع لكنه ليس تغطية كاملة لكل حالة.
النتيجة العملية أن الاعتماد على الإشعارات وحدها يترك فجوات، وأن المراجعة الدورية ليست ترفاً. ولهذا فإن وجود نقطة نهاية لأسباب تغيير الكمية وأخرى لتدقيق التغييرات في توثيق سلة ليس تفصيلاً تقنياً: هو الأداة التي تجيب على سؤال «من غيّر هذا الرقم ولماذا» بعد وقوع المشكلة.
والنظير البرمجي لهذه المسألة، أي كيف يُبنى نظام مخزون يحكم فروعاً متعددة دون مشروع تخطيط موارد كامل، كتب عنه فريق Rivl قراءة مفصلة في نظام مخزون لسلسلة متاجر، مبني على دقة الرصيد، وهي بالإنجليزية. وهي مفيدة تحديداً إذا وصلت إلى حد أن الأدوات الجاهزة لم تعد تكفي.
قائمة تحقق قبل أول مزامنة
سبعة بنود، بالترتيب. البنود الأربعة الأولى لا تكلّف شيئاً وتمنع أغلب ما يحدث بعدها.
- اكتب تعريفك لـ«المتاح للبيع» في جملة واحدة، وحدد أي الحالات أعلاه داخله وأيها خارجه.
- حدد مصدر الحقيقة بالاسم، ونظاماً واحداً فقط.
- تأكد أن أداتك تكتب بالإضافة والخصم لا بالاستبدال. إن لم تكن تعرف، فهي تكتب بالاستبدال.
- حدد مخزون أمان لكل قناة لا رقماً واحداً للكل، واكتب سبب كل رقم.
- اختبر بمنتج واحد سريع الحركة لأسبوع قبل تشغيل الكتالوج كله.
- سجّل ثلاث حالات بيع زائد بتوقيتها وقناتها، واقرأ سبب كل واحدة من سجل التدقيق لا من الذاكرة.
- راجع المرتجعات تحديداً: الوحدة المرتجعة تعود إلى المخزون في لحظة قد لا تكون قابلة للبيع فيها، وهذه الحالة بالذات هي ما تصفه حالتا damaged وquality_control.
وبعد أن يستقر العدّ، يصبح الظهور على المنصة سؤالاً له معنى. إعدادات سلة وزد الموثقة لهذا الجانب في خدمات السيو للمتاجر السعودية على سلة وزد، والمقارنة بين المنصات نفسها في مقارنة سلة وزد وشوبيفاي للسوق السعودي.
تريد مراجعة إعداد المزامنة الحالي لديك قبل موسم الذروة؟
اطلب تشخيصاً مجانياًحدود يجب أن تُقال
ثلاثة.
الأول: ما ورد أعلاه من منصتين لا من كل المنصات. حالات المخزون مقتبسة من توثيق شوبيفاي، وأنماط التحديث من توثيق سلة، وقرأناهما أثناء كتابة هذا المقال. لم نتحقق من توثيق زد ولا نون ولا أمازون السعودية لهذه النقطة تحديداً، فلا تفترض أن المفردات نفسها أو الأنماط نفسها موجودة هناك. راجع صفحة المطورين للمنصة التي تبيع عليها فعلاً.
الثاني: لا رقم واحد لمخزون الأمان في هذا المقال. وهذا مقصود. الرقم الذي يصلح لمتجر يبيع عشر وحدات في اليوم ليس الرقم الذي يصلح لمتجر يبيع ثلاثمائة، وأي رقم ننشره سيُقتبس كقاعدة. المعادلة أعلاه أكثر نفعاً من رقم.
الثالث، وهو الأهم: المزامنة لا تحل مشكلة مخزون غير مضبوط أصلاً. إذا كان الجرد الفعلي في مستودعك لا يطابق أي نظام، فالمزامنة ستوزع الخطأ على كل القنوات بسرعة أكبر. ابدأ بجرد فعلي لأعلى عشرين منتجاً عندك، ثم تحدث عن الأدوات.