الدور والنطاق
تدير Cookinglife (متجر إلكتروني لأدوات المطبخ، إلى جانب متاجر فعلية) عملية المستودع بكاملها على نظام بنيتُه وما زلت أطوّره منذ ذلك الحين: استقبال الطلبات، والتجهيز (فردي ودفعي وبعربة ومتعدد المستويات)، وإدارة المخزون ومواقع التخزين، والتغليف، وملصقات الشحن، والمزامنة مع NetSuite بوصفه نظام ERP. وإلى جانب الصيانة المستمرة، تجري حاليًا هجرة منصة PHP القائمة إلى Laravel وحدةً تلو الأخرى ودون توقف الخدمة.
- من استقبال الطلب حتى الشحن: نظام واحد لعملية التنفيذ كاملة، موصول بـ NetSuite بوصفه مصدر الحقيقة للطلبات والمخزون.
- طرق تجهيز متعددة (فردي، دفعي، بعربة، متعدد المستويات) ومسح الباركود داخل المستودع عبر OnScan.js.
- ملصقات شحن متعددة الناقلين عبر Sendcloud، مع مهمة مسح خاصة تجلب الملصقات فور إنشائها في NetSuite بعد حالة "packed".
- تكاملات مع Shopify وMagento، إضافة إلى توحيد صيغ العناوين وأرقام الهواتف عبر Alumio.
- هجرة إلى Laravel دون توقف للخدمة: وحدةً تلو الأخرى (الطلبات، التجهيز، المخزون، الشحن، NetSuite، الإدارة) عبر توجيه nginx، مع إمكانية التراجع الفوري لكل وحدة على حدة.
الأثر
- نظام واحد لعملية التنفيذ بأكملها بدلًا من أدوات منفصلة للتجهيز والمخزون والشحن.
- عولج خطأ بنيوي في NetSuite يظهر مع طلبات الأطقم (منتجات مكوّنة من عدة قطع)، وذلك بتخصيص المخزون تلقائيًا عبر مواقع تخزين متعددة بدل اشتراط وجود كل القطع في موقع واحد.
- أُزيل تعارض توقيت بين إنشاء ملصقات الشحن وجلبها عبر مهمة مزامنة دورية، فلم تعد الملصقات تضيع بين الحين والآخر.
- مسار شحن احتياطي لحالات تعطّل النظام خارج ساعات العمل، مع منطق مطابقة يمنع ظهور الطلبات مرتين في طابور التجهيز.
- قرابة عامين من التشغيل المتواصل (848 التزامًا برمجيًا منذ أغسطس 2024) — ليس مشروعًا من الصفر يُسلَّم مرة واحدة، بل نظام ينمو مع الشركة.
البنية التقنية
ثلاث طبقات: نواة مشتركة، ووحدة TailorFitWMS نفسها، وتخصيصات لكل عميل (Overwrites) — حتى لا تتسرب التعديلات الخاصة بشركة بعينها إلى النواة. بُنيت الوظائف على هيئة وحدات إضافية يمكن تفعيلها أو تعطيلها لكل شركة، مع نقاط توسعة مبنية على الأحداث. تُخزَّن البيانات في MySQL (البيانات المعاملاتية) وMongoDB (المستندات) وRedis (التخزين المؤقت والجلسات)؛ أما العمل في الخلفية (مزامنة الملصقات ومهام NetSuite) فيجري عبر Laravel Horizon بمعدل 100 إلى 500 مهمة في الساعة. وتتم هجرة منصة PHP القائمة إلى Laravel وحدةً تلو الأخرى عبر كتل location في nginx، بحيث يمكن نشر كل جزء والتراجع عنه على حدة دون المساس بالبقية.
اختيار النموذج
لا وجود للذكاء الاصطناعي أو نماذج اللغة في صميم هذه المنصة — فمنطق التنفيذ (المخزون والتجهيز والشحن ومزامنة ERP) يتطلب القابلية للتنبؤ والتتبع، لا مرونة نموذج لغوي. "اختيار النموذج" الأهم هنا معماري لا متعلق بالذكاء الاصطناعي: الانتقال من إطار PHP الخاص القائم إلى Laravel للحصول على منظومة أدوات أوسع وقابلية صيانة أفضل، لكن بالتدريج ووحدةً تلو الأخرى بدل إعادة كتابة دفعة واحدة، للحد من المخاطرة في نظام يدير مستودعًا على مدار الساعة.
التكلفة وزمن الاستجابة
- تعمل بيئة الإنتاج على 5 خدمات Docker، لكل منها 8 معالجات و8 غيغابايت — وهو تحجيم يناسب نظامًا يعالج حركة الطلبات وNetSuite باستمرار، لا في أوقات الذروة وحدها.
- ملصقات الشحن غير متزامنة عن قصد: إذ لا ينشئ NetSuite الملصق إلا بعد حالة "packed"، فلا حاجة لأن ينتظر النظام — تجمع مهمة مسح الملصقات كل 3 دقائق بدل الاستعلام عن كل طلب على حدة.
- تكامل NetSuite (OAuth1 TBA وSOAP وRESTlet وREST) هو الحلقة الأبطأ في السلسلة؛ أما العمليات المحلية في المستودع مثل المسح والتجهيز فتظل تعمل بمعزل عنه.
الدروس المستفادة
كانت طلبات الأطقم (منتجات مكوّنة من عدة قطع) تتعثر عند خطأ VALID_LINE_ITEM_REQD في NetSuite، لأن مخزون المكوّنات كان موزعًا على مواقع تخزين متعددة بينما يتوقع NetSuite موقعًا واحدًا لكل سطر. حُلّت المشكلة بإعادة كتابة تكامل RESTlet بحيث يُخصَّص المخزون تلقائيًا عبر عدة مواقع. كما تبيّن أن ملصقات الشحن تضيع أحيانًا بسبب تعارض توقيت بين لحظة إنشاء NetSuite للملصق ولحظة جلب النظام له؛ وقد عالجت مهمة مسح دورية كل 3 دقائق ذلك بنيويًا بدل ترقيع مؤقت. أما في الأمسيات وعطلات نهاية الأسبوع حين يتعطل النظام نفسه، فهناك مسار طوارئ خارجي يتيح مواصلة الشحن — مع منطق مطابقة يمنع ظهور الطلبات ذاتها مرتين في طابور التجهيز فور عودة النظام للعمل.