كيف توقف بيع صنف ناقص: مزامنة المخزون بين موقعك ونظامك

قرّر مين المصدر الرسمي للرقم

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

خزّن الكمية على صف المنتج

الكمية والسعر وحالة التوفّر تعيش بصف المنتج بقاعدة بيانات الموقع. الصف يتحمّل حتى 32 كيلوبايت، فهو للأرقام والنصوص لا للملفات — صور المنتجات ترفع للتخزين ويُحفظ رابطها على الصف. حدود التخزين: 10 ميغابايت للملف الواحد، و250 ميغابايت و2000 ملف للمشروع، والصيغ المقبولة PNG وJPG وWEBP وGIF وPDF بفحص للبايتات لا للامتداد.

افتح طريق التحديث

لو نظامك يرسل ويبهوك: الملف لازم يكون باسم ينتهي بـ -webhook.js، لأن هذي الملفات فقط هي المتاحة على رابط عام وباقي دوالك تبقى خاصة. ولو الموقع هو اللي يسأل: تسجّل المهمة بملف functions/_jobs.json بجدولة every_15m أو hourly بتوقيتك أنت. المهام لها حدود صريحة: أقصى 10 مهام للموقع، و200 تشغيلة باليوم للمهمة، والمهمة تتعطّل تلقائياً بعد 10 إخفاقات متتالية. والمشغّل يحجز المهمة قبل ما يشغّلها فما تنفّذ مرتين.

اقفل البيع على الصفر بدل ما تخفي المنتج

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

شغّل مهمة تسوية وراقبها

حتى مع الويبهوك، خلّ عندك مهمة تسوية تقارن أرقام الموقع بأرقام نظامك مرة بالساعة أو باليوم وترسل لك ملخّص الفروقات بالإيميل. الويبهوك يضيع أحياناً وما حدا يلاحظ، والتسوية هي شبكة الأمان. جوّا التشغيلة المجدولة هوية المستخدم فارغة، فالمهمة تشتغل بصلاحية صاحب الموقع.

تكسب

• توقف بيع الناقص، وهذا أرخص من كل اعتذار واسترجاع بعده.
• الرقم يتحدّث بدون ما يفتح أحد الموقع — الويبهوك والمهام تشتغل على الخادم.
• تشغيل المهمة محجوز قبل التنفيذ فما تشتغل مرتين على نفس الصنف.
• منتجات متجر شوبيفاي القائم تُقرأ كما هي عبر cloud.commerce بلا نقل يدوي.
• زر «نبّهني لما يتوفر» يحوّل نفاد المخزون من خسارة زائر إلى قائمة انتظار.

تدفع

• ebnii.db.list داخل الدالة يوقف عند 200 صف بلا offset، وlistAll مو موجودة على الخادم — كتالوج أكبر لازم يتقسّم على مهام مؤجلة.
• 8 نداءات خارجية بالتشغيلة الواحدة، ترتفع بحد أقصى 24 لتشغيلة صاحب الموقع — يعني ما تسحب خمسين صفحة من واجهة المورّد مرة وحدة.
• المهام المجدولة ما تشتغل إلا على موقع منشور، وأقصاها 10 مهام للموقع و200 تشغيلة باليوم للمهمة.
• ما في مكتبات npm: لا SDK للكاشير ولا مكتبة إكسل — الصندوق QuickJS بدون require ولا Node.
• الصف الواحد أقصاه 32 كيلوبايت، فالمخزون أرقام ونصوص لا ملفات.
• ebnii.jobs.enqueue تعطي حداً أدنى للتأخير لا موعداً مضموناً — لا تبني عليها توقيتاً دقيقاً.

تخفي المنتج بدل ما تقفل الشراء

الصفحة تختفي، والزائر اللي جا يدوّرها يطلع بلا نتيجة. الأصح إن الصفحة تبقى وتتحوّل لحالة «نفد المخزون» مع زر تنبيه.

تنسى تنشر الموقع

المهام المجدولة ما تشتغل على موقع غير منشور نهائياً، والشغل المؤجل لموقع غير منشور تنتهي صلاحيته بعد ثلاثة أيام. تنشر أول، وبعدين تعتمد على الجدولة.

تخلي الموقع مصدر الرقم وأنت تبيع بالمحل

لو الكاشير يبيع وما يخبر الموقع، أرقام الموقع تصير خيالاً خلال يوم. حدّد مصدراً رسمياً واحداً واجعل الثاني ينسخ منه.

تسحب الكتالوج كامل كل ربع ساعة

هذا يصطدم بسقف 200 صف داخل الدالة وبسقف 8 نداءات خارجية بالتشغيلة. الأصح إنك تسحب المتغيّر فقط، أو تستقبل ويبهوك لكل حركة.

تحط رقم المخزون بصفّ يقدر أي زائر يعدّله

cloud.db فيه أربعة مستويات وصول لسبب. صفوف المنتجات تُقرأ من الجميع وتُكتب من صاحب الموقع أو من دالة سحابة فقط، لا من كود الصفحة بيد الزائر.