ربط نقاط البيع بمتجر سلة وزد: دليل التكامل الكامل
إذا كان لديك متجر فعلي + متجر إلكتروني على سلة أو زد، فأنت تواجه تحدي المخزون المزدوج: بيعة في المتجر تنقص الرصيد، لكن الموقع لا يعرف. النتيجة: زبون يطلب منتجاً نفد، وتجربة سيئة. هذا الدليل يحل المشكلة.
١. لماذا تكامل المخزون مهم؟
أكبر سبب لخسارة العملاء في التجارة الإلكترونية السعودية هو "out of stock بعد الطلب". تخيّل:
- الزبون يطلب منتج من سلة الساعة ١٠ صباحاً.
- الكاشير في المحل باع آخر قطعة الساعة ٩:٤٥ ولم يعرف أحد.
- تتصل بالعميل تعتذر، يلغي الطلب، ينشر review سلبي.
الحل = نظام واحد يدير المخزون في الموقع والمتجر معاً، بمزامنة لحظية.
٢. ما الذي يجب مزامنته؟
| العنصر | الاتجاه | التكرار |
|---|---|---|
| المنتجات (اسم، سعر، صور) | POS → سلة/زد | عند إضافة/تعديل |
| المخزون (الكميات) | POS ↔ سلة/زد | لحظياً (webhook) |
| الأسعار والعروض | POS → سلة/زد | عند تعديل |
| الطلبات الجديدة | سلة/زد → POS | لحظياً |
| حالة الطلب (شحن، استلام) | POS → سلة/زد | عند تغيير |
| فواتير ZATCA | POS تُصدر | لحظياً |
٣. الخيارات المتاحة في السوق
الخيار ١: تكامل أصلي (Native)
بعض الأنظمة (Rewaa، Foodics) لها تكامل مباشر مع سلة/زد. تثبّت الـ app من متجر سلة، توافق على الصلاحيات، وتشتغل المزامنة تلقائياً.
✓ مميزات: أبسط حل، صفر تطوير. ✗ عيوب: أسعار باقات أعلى، قيود على عدد المنتجات/الطلبات.
الخيار ٢: التكامل عبر API + middleware
إذا نظام الكاشير عنده API (مثل POS SAAS)، يمكنك بناء middleware صغير (Node/PHP/Python) يستمع لـ webhooks من سلة وينقل البيانات للـ POS API والعكس.
✓ مميزات: تحكم كامل، تكاليف منخفضة. ✗ عيوب: يحتاج مطوّر.
الخيار ٣: المزامنة اليدوية الدورية
تصدير CSV من POS كل صباح + استيراده في سلة/زد. عملي للمتاجر الصغيرة (<100 منتج، <10 طلبات يومياً).
✓ مميزات: صفر تكلفة. ✗ عيوب: ليس لحظي، خطر تعارض.
الخيار ٤: Zapier / Make (No-code)
منصات الـ no-code تربط بين APIs بدون كود. سلة وزد عندهما triggers و actions جاهزة.
✓ مميزات: سريع، بدون مبرمج. ✗ عيوب: مكلف للحجم العالي (~٥٠$ شهرياً).
٤. سلة API — الأساسيات
منصة سلة توفّر REST API مع OAuth 2.0:
- Base URL:
https://api.salla.dev/admin/v2 - Webhooks: Order Created/Updated/Cancelled, Product Updated, Inventory Changed
- Endpoints مهمة:
/products,/products/quantities,/orders - المعدل: 1000 طلب/ساعة
- Embedded apps: يمكن نشر تطبيقك في متجر تطبيقات سلة
٥. زد API — الأساسيات
- Base URL:
https://api.zid.sa/v1 - Auth: OAuth 2.0 + Manager Token
- Webhooks: order.create, order.status.update, product.update
- Endpoints:
/products,/products/inventories,/orders,/managers/store/orders - السوق: Zid Market لتوزيع تطبيقك
٦. خطة عملية للتكامل (POS SAAS)
POS SAAS يوفر API كامل للمنتجات والمخزون والمبيعات. الـ middleware البسيط الذي يربطه بسلة/زد يمكن بناؤه في أيام:
- إنشاء token API من POS SAAS Settings → API.
- تسجيل تطبيق Salla في salla.dev + الحصول على Client ID/Secret.
- كتابة middleware (PHP/Node) يستمع لـ webhooks من سلة:
order.created→ POST/api/v1/salesفي POS SAASproduct.update→ POST/api/v1/products
- cron كل 15 دقيقة يقرأ المخزون من POS SAAS ويحدّث في سلة (احتياط).
- اختبار في بيئة Sandbox سلة قبل الإنتاج.
٧. تحديات شائعة وحلولها
تعارض المخزون
بيعة في المحل + طلب من سلة في نفس اللحظة على آخر قطعة.
الحل: اعتمد POS كمصدر الحقيقة. سلة تحجز "soft" والـ confirmation يأتي من POS.
SKU/باركود مختلف
المنتج في سلة بـ ID مختلف عن POS.
الحل: أنشئ جدول mapping في الـ middleware (salla_product_id ↔ pos_product_id).
إصدار فاتورة ZATCA لطلب من سلة
طلب الموقع يحتاج فاتورة معتمدة.
الحل: POS SAAS يصدر ZATCA invoice تلقائياً عند استقبال طلب من API. ترسلها لعميل الموقع.
٨. ملاحظات قانونية
- كل بيعة في سلة/زد لعميل سعودي تحتاج فاتورة ZATCA إلكترونية.
- المخزون في الموقع والمتجر يجب أن يكون تحت نفس CR وVAT.
- إذا فصلت كياناً قانونياً للمتجر الإلكتروني، تحتاج CSID منفصل من ZATCA.
ابدأ الآن
POS SAAS يدعم API كامل لمزامنة المنتجات/المخزون/الطلبات/الفواتير مع أي منصة. ابدأ تجربة 14 يوم مجاناً أو راجع توثيق API.