إذا كنت تستخدم Odoo وتريد البيع عبر الإنترنت في هذه المنطقة، فأمامك خياران صادقان: أن تشتري موصّلًا جاهزًا لمنصة مثل Salla أو Zid أو Shopify أو WooCommerce، أو أن تبني التكامل بنفسك مع متجر تتحكّم فيه.
معظم ما يُكتب عن هذا الموضوع على الإنترنت إما صفحة عرض لوحدة برمجية أو صفحة مبيعات. ولا يخبرك أيّ منهما بما يجب أن تختاره. هذه هي النسخة التي كنا سنريدها لو كنا نحن أصحاب القرار.
ما الذي يقدّمه لك الموصّل فعلًا
الموصّل عملية مطابقة. ينقل المنتجات والمخزون والأسعار والطلبات بين Odoo والمنصة، وفق جدول زمني، مستخدمًا الحقول التي يتفق عليها الطرفان أصلًا. وحين يتّسع هذا الاتفاق لطبيعة عملك، يكون الموصّل هو الإجابة الصحيحة، ويصبح بناء أي شيء مخصّص هدرًا للمال.
اشترِ الموصّل حين ينطبق عليك معظم ما يلي:
- كتالوجك بسيط: سعر واحد لكل منتج، وضريبة قياسية، ولا أسعار خاصة بعملاء بعينهم.
- أنت راضٍ بالعمل داخل صفحة الدفع الخاصة بالمنصة، كما هي تمامًا.
- حجم طلباتك يتحمّل المزامنة المجدولة بدلًا من الفورية.
- لا تحتاج إلى تطبيق جوال يتصرّف بشكل مختلف عن الموقع.
- لن يطلب أحد في الشركة سير عمل لا توفّره المنصة.
معظم الكتالوجات الصغيرة ينبغي أن تشتري موصّلًا. إذا كان هذا وصفك، فتوقّف عن القراءة واشترِ واحدًا، وستكون جاهزًا للعمل خلال أسابيع وبجزء بسيط من التكلفة.
حيث تنتهي قدرة الموصّلات
تبدأ المشكلة حين تقوم شركتك بشيء لم تتوقّعه عملية المطابقة. وفي الواقع يكون ذلك دائمًا تقريبًا واحدًا من خمسة أمور.
- قوائم الأسعار. تبيع لعملاء الجملة بسعر يختلف عن التجزئة. والموصّل الذي يفترض سعرًا واحدًا لكل منتج لا يستطيع التعبير عن ذلك، والحلول الالتفافية، كتكرار المنتجات أو التعديل اليدوي، تخلق بالضبط المصدر الثاني للحقيقة الذي كنت تحاول تجنّبه.
- ضريبة يجب أن تطابق نظام ERP تمامًا. مراكز مالية ومجموعات ضريبية وقواعد تقريب مضبوطة على طريقة إصدارك للفواتير أصلًا. "قريب بما يكفي" لا يكفي حين يجري فريق المالية التسوية.
- وسائل دفع لا تدعمها المنصة. الدفع عند الاستلام برسوم متغيّرة، وأكواد فوري، والمحافظ المحلية، والتقسيط، وكل ذلك يجب أن يعود إلى Odoo بصيغة يعرفها فريق المالية.
- كتالوج كبير أو كثيف الصور. آلاف الصور بدقة كاملة مسحوبة من نظام ERP ستجعل المتجر غير صالح للاستخدام عبر بيانات الجوال، ما لم يوجد بينهما ما يغيّر أحجامها ويخزّنها مؤقتًا.
- تطبيق جوال ليس مجرد الموقع داخل غلاف. في اللحظة التي تريد فيها سلوكًا أصليًا، ستبني على API في كل الأحوال.
المقارنة الصادقة للتكلفة
الموصّل رخيص الشراء ورخيص البداية. وتظهر تكلفته الحقيقية لاحقًا، في ثلاث صور: الحلول الالتفافية التي تتراكم للتعبير عمّا لا تستطيعه المطابقة، والتسوية اليدوية التي يجريها أحدهم بصمت كل أسبوع، والسقف الذي تصطدم به حين تريد الشركة شيئًا لن تفعله المنصة.
التكامل المخصّص يكلّف أكثر في البداية وأقل عند تطويعه. وهو الخيار الصحيح حين يكون ما تبنيه قناة حقيقية للعمل لا تجربة، وحين تُقاس تكلفة خطأ المتجر بساعات التسوية لا بانزعاج عابر.
اشترِ الموصّل لتختبر ما إذا كانت القناة تنجح. وابنِ التكامل حين تتأكد أنها تنجح.
اختبار يمكنك إجراؤه هذا الأسبوع
قبل أن تلتزم بأي من الخيارين، دوّن الأمور الخمسة التي تقوم بها شركتك ويجدها أي متجر إلكتروني عام غريبة. أسعار مختلفة لعملاء مختلفين. رسوم توصيل تعتمد على المحافظة. خطوة موافقة قبل شحن طلبات معيّنة. منتج يُباع بالوزن. أي شيء على الإطلاق.
ثم خذ هذه القائمة إلى من يبيعك الموصّل، واطلب منه أن يريك كل بند منها وهو يعمل. لا أن يصفه، بل أن يريك إياه. القائمة هي مواصفاتك، والإجابات أرخص بحث ستجريه في حياتك.
ما الذي فعلناه
بالنسبة إلى SG-Mart، وهو موزّع لديه أكثر من 110 فئات وأسعار خاصة بكل عميل واقتصاديات قائمة على الدفع عند الاستلام، كان طريق الموصّل سيحتاج حلولًا التفافية حول كل واحد من هذه الأمور. فبنينا المتجر وتطبيق Flutter على Odoo مباشرة، مع بقاء Odoo المصدر الوحيد للحقيقة في الكتالوج والأسعار والضريبة.
كان ذلك القرار الصحيح لهم. وليس بالضرورة القرار الصحيح لك، وأي مزوّد يقول لك غير ذلك قبل أن يسألك عن قوائم أسعارك يبيع لك، ولا ينصحك.
المزيد عن ما الذي يتعطّل فعلًا حين تربط متجرًا بـ Odoo، وعن نهجنا في ربط أنظمة ERP. وإذا أردت رأيًا مباشرًا في أي جانب تقع، أخبرنا بما تستخدمه.