Leonix: منصة تجارة إلكترونية وموردين لبيع قطع غيار الشاحنات الثقيلة

Leonix موزّع يبيع قطع غيار الشاحنات الثقيلة (الشاحنات والرؤوس الجرارة) في السوق الأمريكي. تأتي القطع من مصنّعين في تركيا ومن موردين لديهم مستودعات في الولايات المتحدة، وقد تنتج عدة علامات تجارية رقم OEM نفسه. ويبحث المشترون غالبًا عن القطعة برقم OEM ويريدون رؤية السعر وحالة التوفر قبل إضافتها إلى السلة.

وخلف الواجهة كان هناك سير عمل يتجاوز نطاق متجر إلكتروني تقليدي. فعلى الموردين أن يرفعوا مئات الأصناف من ملف Excel، ولا يجوز طرح أي منتج للبيع دون موافقة Leonix، ويجب تحديد سعر البيع مع مراعاة سعر الشراء وهامش الربح وأسعار السوق وتكلفة الاستيراد، ولا يُقبل الدفع الإلكتروني إلا للمخزون الموجود في المستودعات الأمريكية. وكان لا بد من تتبّع كل خطوة، من خروج المنتج من المورّد حتى وصوله إلى المشتري، من مكان واحد.

وكان لا بد أيضًا من فصل الصلاحيات: يرى كل مورّد منتجاته ومخزونه وشحناته فقط، بينما يدير فريق Leonix العملية كلها من شاشة واحدة. لذلك لم يكن ممكنًا أن يكون المتجر ولوحة المورّد ولوحة الإدارة أدوات منفصلة، بل صُمّمت كنظام واحد يعمل على نموذج بيانات مشترك.

طوّرت Detartech منصة Leonix من الصفر: المتجر ولوحة المورّد ولوحة الإدارة تعمل جميعها على واجهة API واحدة.

بنية من ثلاثة أجزاء

نواة المنصة هي واجهة API تعمل على ASP.NET Core وتعتمد على PostgreSQL قاعدةً للبيانات. أما لوحتا المورّد والإدارة فهما تطبيق Next.js واحد: يدخل الجميع من شاشة واحدة، ودور المستخدم هو الذي يحدد اللوحة التي تُفتح. والمتجر تطبيق Next.js منفصل يقرأ البيانات ويكتبها عبر الـAPI فقط. وتشكّل المهام المجدولة والخلفية والتفويض حسب الأدوار وسجل تدقيق التغييرات جزءًا من هذه النواة.

كتالوج قائم على OEM وعدة موردين

تُدمج القطعة نفسها في بطاقة منتج واحدة بعد توحيد أرقام OEM من حيث المسافات والشرطات والنقاط. يحتفظ كل مورّد بعرضه وسعر شرائه ومخزونه، بينما يرى المشتري سعر بيع واحدًا. ويُجمع المخزون من العروض المعتمدة ويُخصم عند وصول الطلب بترتيب التكلفة.

رفع جماعي من Excel وسير عمل الموافقة

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

المستودعات والشحنات وشفافية المخزون

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

واجهة API خاصة بالمتجر والدفع عبر Stripe

المتجر غير مرتبط بمنصة تجارة إلكترونية جاهزة. إنه موقع المبيعات الخاص بـ Leonix، ويعمل على واجهة API للمتجر طوّرناها نحن، ويتم تحصيل الدفع عبر Stripe من خلال المتجر نفسه. أثناء إتمام الطلب يُحجز المخزون لفترة قصيرة، ويُعرض على المشتري السعر الحالي إذا تغيّر، ولا يُنشأ الطلب إلا بعد إشعار موثّق من Stripe، وإذا وصل الدفع بعد نفاد المخزون يُرد المبلغ تلقائيًا. وتؤكد الاختبارات أن الطلبات المتزامنة لا يمكن أن تتجاوز المخزون المتاح.

الأمان والنشر

لا يصل الموردون إلا إلى سجلاتهم، وعند طلب سجل مورّد آخر يأتي الرد نفسه الذي يأتي عند طلب سجل غير موجود. وتُطبَّق حدود لعدد الطلبات وقفل الحساب عند تكرار الإخفاق في الدخول، وقواعد صارمة لكلمات المرور وسجل تدقيق. وتُبنى التطبيقات وتُنشر تلقائيًا عبر Jenkins دون تدخل يدوي.

تبيع Leonix مباشرة عبر leonixusa.com وتعمل منصةً واحدة مع لوحتي المورّد والإدارة.

• منصة واحدة من البداية إلى النهاية: تُدار العملية كلها، من رفع المنتج إلى الموافقة والتسعير والمخزون والطلبات والدفع، من نظام واحد.
• نشر خاضع للرقابة: لا يُطرح أي منتج للبيع دون موافقة Leonix، وتُحدد الأسعار مع مراعاة التكلفة ومعلومات السوق.
• إدخال جماعي للمنتجات: يستطيع الموردون رفع مئات الأصناف في ملف Excel واحد مع الإبلاغ عن الأخطاء صفًا صفًا.
• بيع على بنية تحتية خاصة: يعمل المتجر على واجهة API خاصة به ودفع عبر Stripe، وتُدار الطلبات والمخزون من مكان واحد.
• تجربة شراء شفافة: يجد المشتري القطعة برقم OEM، ويظهر السعر وحالة التوفر قبل الإضافة إلى السلة.