ما الفرق بين بوابة الموزعين وموقع التجارة الإلكترونية؟

الفرق الأساسي في آلية السعر والدفع. ففي التجارة الإلكترونية يكون السعر واحدًا للجميع ويُؤخذ الدفع لحظة الطلب. أمّا في B2B فيتغيّر السعر بحسب العميل والقناة والكمّية؛ ويرتبط الدفع بأجل عادةً، ويجب أن يمرّ الطلب بضبط حدّ الائتمان. ولذلك فإنّ بوابة الموزعين ليست كتالوجًا، بل سطح عمليات مفتوح من ERP إلى الخارج.

اكتبوا نموذج التسعير أولًا

يتكوّن السعر عمليًا بتطبيق الطبقات الآتية بالترتيب:

  • سعر القائمة
  • خصم مجموعة العملاء أو القناة
  • سعر اتفاقي خاصّ بالعميل
  • درجة الكمّية (هل ينتقل بين الدرجات لحظة الطلب أم بإجمالي الفترة؟)
  • الحملة والتخفيض الموسمي
  • فرق الأجل أو خصم الدفع النقدي

والسؤال الحرج هو: هل تُطبَّق هذه الطبقات بالضرب أم بالتتابع؟ فمجموعة الخصومات نفسها قد تعطي نتيجتين مختلفتين. وإن لم تكن القاعدة مكتوبة، أنتجت البوابة وERP سعرين مختلفين ونشأ اعتراض على الفاتورة بينكم وبين الموزّع. وأقلّ البنى احتكاكًا هي إجراء حساب السعر في مكان واحد (في ERP يفضَّل) وعرض البوابة له.

حدّ الائتمان وضبط المخاطر

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

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

جانب ERP في مسار الطلب

عند نقل طلب البوابة إلى ERP تُعالَج ثلاث حالات على حدة:

  • نجح النقل: يجب إعادة كتابة رقم الطلب في ERP إلى البوابة وعرضه للموزّع.
  • فشل النقل بخطأ مؤقّت: يبقى الطلب في حالة «قيد النقل» وتُعاد المحاولة؛ ولا يُترك غامضًا في شاشة الموزّع.
  • رُفض النقل بخطأ دائم: يجب عرض سبب الرفض بلغة يفهمها الموزّع، وألّا يضيع السجلّ.

ويُستخدم مفتاح العملية كي لا يُنتج النقل المعاد طلبًا ثانيًا؛ انظروا دليل تكامل واجهات API.

الشاشات التي يستخدمها الموزّع فعلًا

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

قرار إظهار المخزون

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

الأسئلة الشائعة

أيُحسب السعر في البوابة أم في ERP؟

في ERP. فالبوابة تعرض السعر المحسوب وتتحقّق منه من جديد لحظة الطلب. أمّا محرّكا حساب منفصلان فينتجان عاجلًا أو آجلًا نتيجتين مختلفتين.

كيف ينبغي تصميم صلاحيات مستخدمي الموزّع؟

يلزم دوران على الأقلّ داخل الموزّع: مستخدم يستطيع تقديم الطلبات، ومستخدم يستطيع رؤية المعلومات المالية (كشف الحساب، والحدّ، والسعر). أمّا تصميم الدور الواحد فيحدّ من استخدام البوابة لأنّ الموزّع لا يستطيع منح صلاحيات لموظفيه.

هل يلزم تطبيق هاتف للبوابة؟

يلزم إذا كان الفريق الميداني يُدخل الطلبات، ويُنتظَر أن يعمل دون اتصال؛ ويُتناول هذا السيناريو في دليل تطبيقات الهواتف. أمّا في بوابة تُستخدَم من المكتب فقط، فتكفي واجهة ويب متوافقة مع الهواتف.