الدليل العملي لربط ووردبريس مع أنظمة ERP (SAP Business One): من واقع بيئات تصنيع وشركات سعودية

خلال إدارتي لتقنية المعلومات على مدار أكثر من سبع سنوات وقيادتي لتنفيذ ساب بزنس ون (SAP Business One) بدورة كاملة في بيئات تصنيع ومؤسسات تجارية في السعودية، رأيت عشرات المشاريع التي تفشل فيها محاولات الربط بين الواجهة الرقمية (الموقع أو المتجر الإلكتروني) والنظام المالي والإداري الخلفي. المشكلة ليست في ووردبريس كمنصة، ولا في ساب كنظام عملاق؛ المشكلة تكمن دائماً في غياب المعمارية البرمجية الصحيحة لتدفق البيانات وتجاهل الفوارق الجوهرية بين سرعة تعامل الويب ودقة القيود المحاسبية.

في هذا الدليل العملي المتقدم، أشاركك المنهجية المعمارية الدقيقة التي نطبقها لربط ووردبريس بنظام SAP Business One بنجاح، مع معالجة تحديات الأداء، إدارة الجلسات، ومزامنة المخزون، والامتثال لمتطلبات هيئة الزكاة والضريبة والجمارك (ZATCA) في المملكة العربية السعودية.

1. المعمارية الهندسية: Service Layer مقابل الطرق التقليدية (DI API / Direct SQL)

الخطأ الأول والأخطر الذي يقع فيه مطورو الويب عند محاولة ربط ووردبريس مع ساب هو محاولة الاتصال المباشر بقاعدة البيانات (سواء كانت SAP HANA أو MS SQL Server) عبر استعلامات SQL خارجية. هذا التصرف خطير لسببين حاسمين:

• انتهاك سلامة البيانات (Data Integrity Violation): قاعدة بيانات ساب لا تقتصر على تخزين الجداول؛ بل تحتوي على آلاف القيود المحاسبية ومحددات الأعمال. أي إدراج مباشر في جدول مثل ORDR أو OINV دون المرور بمحرك النظام قد يتسبب في تدمير قيود اليومية، ويعرض المنشأة لفقدان الدعم الفني الرسمي من شركة SAP.
• التوقف الكامل عند التحديثات: أي ترقية لنظام ساب قد تغير هيكلية الجداول، مما يكسر الموقع تماماً.

في معماريتنا الحديثة، نعتمد كلياً على SAP B1 Service Layer المبنية على معيار OData v3/v4 وواجهات RESTful عبر بروتوكول HTTPS. هذه الواجهة تضمن مرور كل طلب عبر محرك المنطق المحاسبي لساب، مع دعم التشفير والتشغيل السحابي وبيئات لينكس.

2. معمارية المزامنة غير المتزامنة (Asynchronous Architecture)

واحدة من أكبر الكوارث التي تصيب المتاجر الإلكترونية عند الربط هي تجميد المتصفح للمستخدم عند الضغط على “إتمام الطلب” بانتظار رد ساب. خادم ساب قد يستغرق بين 2 إلى 4 ثوانٍ للتحقق من العميل واحتساب الضرائب وتوليد القيد. إذا انتظر العميل هذه الثواني في كل طلب، ستتراجع تجربة المستخدم بشكل حاد، وإذا كان خادم ساب تحت ضغط أو صيانة، ستفشل عملية الشراء بالكامل!

الهيكل الهندسي السليم لحل المشكلة:

1. التسجيل المحلي الفوري: يُسجل الطلب في ووردبريس خلال أجزاء من الثانية ويصل إشعار النجاح للمستخدم فوراً.
2. طابور المعالجة في الخلفية (Background Queue): يوضع الطلب في جدول مهام وسيط (Action Scheduler أو Redis Queue).
3. المعالج الخلفي (Worker): يقوم العامل بسحب الطلبات ودفعها تباعاً إلى ساب عبر Service Layer.
4. معالجة حالات الفشل وإعادة المحاولة (Exponential Backoff): إذا تعذر الوصول لساب، يعيد النظام المحاولة تلقائياً بعد دقيقة، ثم 5 دقائق، ثم 15 دقيقة، مع تسجيل كامل للأحداث في سجل التدقيق (Audit Log).

3. إدارة الجلسات في Service Layer (Session Pooling)

عند الاتصال بـ Service Layer، يتطلب ساب تسجيل دخول للحصول على كوكيز الجلسة: B1SESSION و ROUTEID. الخطأ الكارثي هو عمل Login جديد لكل عملية استعلام أو تحديث، لأن ساب يملك حداً أقصى لعدد الجلسات المتزامنة لكل رخصة مستخدم (License Seat).

الحل البرمجي المطبق: نقوم بتخزين معرف الجلسة في ذاكرة التخزين المؤقت لووردبريس (WordPress Transients أو Redis) لمدة 25 دقيقة (مع العلم أن مدة انتهاء جلسة ساب الافتراضية هي 30 دقيقة). في كل طلب، نستخدم نفس الجلسة، ولا نطلب جلسة جديدة إلا عند استقبال خطأ 401 Unauthorized.

4. هيكل البيانات لطلب إنشاء أمر بيع (Sales Order Payload)

إليك نموذج البيانات الذي يتم إرساله إلى الـ Endpoint المخصص POST /b1s/v2/Orders لإنشاء أمر بيع مطابق للشروط والممارسات السعودية:

{
  "CardCode": "C200100",
  "DocDate": "2026-10-15",
  "DocDueDate": "2026-10-16",
  "Comments": "طلب ووردبريس رقم #59201 - دفع إلكتروني مدى",
  "U_WP_OrderID": "59201",
  "PaymentGroupCode": 1,
  "DocumentLines": [
    {
      "ItemCode": "PRD-0041",
      "Quantity": 3,
      "UnitPrice": 250.00,
      "VatGroup": "S15",
      "WarehouseCode": "WH-MAIN-RYD"
    }
  ]
}

5. التكامل مع الفاتورة الإلكترونية السعودية (ZATCA المرحلة الثانية)

في منشآت الأعمال السعودية الخاضعة لمرحلة الربط والتكامل (Phase 2)، التحدي الرئيسي هو: أين يتم إصدار الفاتورة الضريبية وتوليد رمز الاستجابة السريعة (QR Code بصيغة TLV مشفرة) ورمز UUID؟

القاعدة الإدارية والمحاسبية الصارمة: نظام ERP هو الحقيقة الوحيدة المطلقة (Single Source of Truth). لا يجوز أبداً جعل ووردبريس يصدر أرقام فواتير ضريبية مستقلة تتطابق عشوائياً مع قيود ساب.

• يرسل المتجر أمر البيع (Sales Order) كمسودة تجارية.
• يقوم قسم المحاسبة أو الوحدة الآلية في ساب باعتماد الفاتورة (AR Invoice)، والتي تتولى التشفير والربط السحابي مع منصة “فاتورة” التابعة لهيئة الزكاة والضريبة والجمارك.
• يقوم ووردبريس عبر Webhook أو استعلام مجدول بسحب ملف الـ PDF المعتمد والرمز المولد وعرضه للعميل في لوحة حسابه.

6. مزامنة المخزون الذكية (Available to Promise – ATP)

المخزون ليس مجرد رقم خام مسجل في المستودع؛ في ساب بزنس ون يوجد:

• الموجود الفعلي (In Stock): البضاعة الموجودة فيزيائياً في الرف.
• المحجوز (Committed): بضاعة مباعة لأوامر بيع لم تشحن بعد.
• المطلوب (Ordered): بضاعة في طريقها من الموردين.

المتجر الإلكتروني يجب أن يعرض فقط المخزون المتاح الفعلي (Available Quantity) المحسوب رياضياً: (In Stock - Committed). كما يجب الاعتماد على تحديث التغيرات (Delta Sync) بالاعتماد على حقل UpdateDate و UpdateTime لتقليل استهلاك موارد السيرفر بنسبة 90%.

الخلاصة وتوصيات التنفيذ لمدراء التقنية

النجاح في مشاريع تكامل الأنظمة المؤسسية لا يتوقف على جودة الأكواد فقط، بل يتطلب فهماً عميقاً لدورة المبيعات وسلاسل الإمداد ومحاسبة التكاليف. إذا بنيت واجهات برمجية مستقلة، مع حماية أداء الويب عبر طوابير المعالجة الخلفية، ستضمن بيئة رقمية سريعة وموثوقة بنسبة توافر 99.9%.

إذا كانت منشأتك تخطط لمشروع تكامل مع SAP Business One أو تواجه عقبات في مشاريع قائمة، يسعدني تقديم الاستشارة ومشاركة خبراتنا الميدانية عبر صفحة التواصل الخاصة بي.