Opencart هي واحدة من المتاجر الأكثر شيوعا على الإنترنت. في كثير من الحالات ، تنشأ مهمة التكامل مع نظام محاسبة المستودعات (في معظم الأحيان مع 1C).
يتضمن التكامل ، على الأقل ، نقل الطلبات من IM إلى نظام المستودع لمعالجة وإرسال البضائع إلى المشتري وتحديث كمية البضائع في IM وفقًا للتوافر الفعلي في المستودع.
وغالبًا ما تكون المهمة هي مزامنة البضائع نفسها ومعاييرها وصورها وما إلى ذلك.
تكمن الصعوبة في أنه ، كقاعدة عامة ، يجب إجراء تغييرات في كلٍ من IM و في نظام المستودع ، مما يعني أن المطور يجب أن يعرف كلا النظامين أو يحتاج إلى إشراك مطور آخر. هناك حلول جاهزة ، ولكنها تتطلب عادةً التشطيب أو الدفع ، ولا تزال تتطلب التشطيب.
لحل هذه المشكلة ، تم إنشاء وحدة نمطية لـ OpenCard والتي تعمل على توسيع واجهة برمجة تطبيقات OpenCart للسماح بإجراء التغييرات فقط على جانب نظام المحاسبة.
الوحدة هي حرة مفتوحة المصدر ، وتقع على
جيثب .
تم تطوير الوحدة النمطية لنظام محاسبة
معين ، ولكن تمت كتابتها بحيث يمكن استخدامها من قبل أي برامج خارجية أخرى.
يتم تثبيت الوحدة النمطية في IM إما بالطريقة القياسية من خلال لوحة المسؤول أو ببساطة عن طريق نسخها إلى مجلد الكتالوج / تحكم / api. تتكون الوحدة من ملف واحد. لا توجد تغييرات على الإعدادات أو بنية opencards مطلوبة.
بالطبع ، في لوحة الإدارة ، تحتاج إلى إنشاء واجهة برمجة تطبيقات KEY ، والتي سيتم تعيينها بعد ذلك في إعدادات نظام المستودع لتسجيل الدخول إلى واجهة برمجة التطبيقات قبل الوصول إليها.
تم التحقق من العمل باستخدام OpenCart 2.3 و 3.0
توفر الوحدة النمطية العديد من وظائف واجهة برمجة التطبيقات (API) للعمل مع الطلبات والبضائع.
وفقًا لاتفاقيات البطاقات المفتوحة ، يتم نقل المعلمات باستخدام طريقة POST ويجب الحصول على رمز مميز خاص قبل الوصول إلى واجهة برمجة التطبيقات. يتم تبادل البيانات في شكل JSON. كل هذه أدوات قياسية للعمل مع OpenCart API.
العمل مع أوامر
عندما تظهر طلبات جديدة في الرسائل الفورية ، يجب استيرادها إلى نظام المستودعات ، أي بناءً عليها ، يجب إنشاء المستندات (السجلات ، وما إلى ذلك) في نظام المستودع ومعالجتها وإرسالها إلى العميل
يتم استيراد الطلبات عن طريق استدعاء وظيفة
orders () .
للحصول على الطلبات الضرورية فقط ، يتم تمرير المعلمة status_id مع حالة الطلبات. نظرًا لأن الحالات الموجودة في الخريطة المفتوحة يتم إنشاؤها بواسطة لوحة المسؤول ويمكن أن تكون أي شيء ، فأنت بحاجة أولاً إلى الحصول على قائمة بالحالات باستخدام طريقة
الحالات () ، والتي تُرجع مصفوفة قيمة مفتاح بها معرفات وأسماء الحالة.
يقدم نظام المحاسبة هذه الحالات للتوضيح في نوع من القائمة المنسدلة. يختار المدير من هذه الحالات الحالة التي تتوافق مع الطلب الجديد.
مع الطلب يأتي قائمة السلع وبيانات العملاء للتسليم.
لتحديد الطلبات ، يجب على النظام المحاسبي كتابة معرف الطلب في بعض سمات الأمر الداخلي. يتم تحديث حالات هذه المعرفات في MI كما تحقق من أن الطلب قد تم استيراده بالفعل.
يتم إجراء تحديثات الحالة في IM بواسطة وظيفة
updateorder ()يختار المدير الأوامر اللازمة (نظام المحاسبة) في الحالة المطلوبة (على سبيل المثال ، يتم معالجة الطلب) ويقوم بتحديث حالات الطلبات الأولية المقابلة في IM. يتم نقل صفيف قيمة المفتاح - معرف الطلب الخاص بـ MI ومعرف حالة MI من القائمة المنسدلة التي يقترحها النظام.
على سبيل المثال ، يمكن تحديث الطلبات بعد قبولها للمعالجة ، وشحنها إلى العميل ، وتسليمها إلى العميل ، وإغلاقها. هذا هو حسب تقدير المدير.
بطبيعة الحال ، إذا كانت الحالات في كلا النظامين محددة بوضوح ولا تتغير ، فإن مكالمات API ذات الحالات الثابتة يمكن تعليقها على بعض المجدول وتدعو تلقائيًا.
العمل مع البضائع
عند العمل مع البضائع ، من الضروري في أغلب الأحيان تحديث الكمية الفعلية للبضائع في المستودع والأسعار في المتجر.
من أجل تبادل البيانات ، يجب مزامنة البضائع في IM مع البضائع في المستودع. يتم توفير التوافق بواسطة المقالة ، ولكن إذا كنت ترغب في ذلك ، يمكنك ضبط الرمز واستخدام معلمة أخرى ، على سبيل المثال ، الاسم (على الرغم من أن هذه ليست فكرة جيدة).
لإضافة منتجات إلى المتجر ، استخدم وظيفة
addproducts () .
البضائع التي لم يتم نقلها بعد إلى المتجر. من أجل عدم نقل التكرارات ، يمكنك الحصول من المتجر على قائمة بالمقالات الموجودة باستخدام طريقة
articles () .
لكي تقع البضائع مباشرة في الفئة المطلوبة ، يجب أولاً الحصول على قائمة بالفئات باستخدام طريقة
القطط () وإعطاء المدير الفرصة لاختيار الفئة المطلوبة من القائمة. بعد ذلك ، يتم إعادة تسجيل البضائع باستخدام أدوات قياسية في لوحة إدارة OpenCart.
يتم نقل البضائع في شكل اسم ، مادة ، وصف (إن وجد) ، السعر والكمية. في بعض الحالات ، تكون المهمة هي نقل السمات وجميع الأوصاف والصور وما إلى ذلك من المستودع. ولكن في هذا الصدد ، هناك شكوك حول مدى استصواب إنشاء كل هذا بجانب نظام المحاسبة.
أولاً ، بالنسبة لمحاسبة المستودع الكلاسيكية ، يكفي اسم ورقم المقالة ، أي البيانات المستخدمة في الفواتير والأوامر.
ثانياً ، لوحة إدارة الدردشة لديها بالفعل وسائل منتظمة لتشكيل بطاقات المنتج.
ثالثًا ، يعد نقل وتنسيق الهياكل المعقدة مثل شجرة الفئات والسمات والصور وما إلى ذلك عملًا مزعجًا للغاية ، وكما هو مذكور أعلاه ، ليس ضروريًا.
مثل هذه الحلول منطقية إذا كان النظام المحاسبي يعمل مع الموارد الأخرى ، وتحميل البيانات إلى الأسواق ، على سبيل المثال. على الرغم من أنني متأكد من أن هناك وحدات للبطاقة المفتوحة التي تقوم بتحميل خصائص وصور البضائع إلى الأسواق من البطاقة المفتوحة.
إذا اتضح أن هناك بالفعل بعض البضائع في IM في وقت تقديم نظام المستودع ، فيمكنك الحصول على قائمة بالسلع من IM باستخدام طريقة
getproducts () وإضافتها إلى
كتالوج البضائع
في نظام المحاسبة. يتم فحص التفرد أيضا من خلال المادة.
بعد ذلك ، الوظائف الرئيسية
updatequantity () و
updateprice () لتحديث الكمية والسعر في MI وفقًا لبيانات المستودع. تنقل الوظائف صفيف قيمة المفتاح (رقم المقالة أو السعر) ولا تتطلب معلمات ، أي ، يمكن تشغيلها بواسطة المجدول.
كما سبق ذكره ، فإن ميزة الوحدة هي عدم وجود أي تغييرات في كود OpenCart. إذا لزم الأمر ، يتم وضع اللمسات الأخيرة على الوحدة النمطية بسهولة - لنقل البيانات الإضافية التي تحتاج فقط إلى إضافة مفتاح جديد إلى مجموعة النقابي المقابلة. سيتم تعبئة البيانات ثم تفريغها بنفس النموذج على جانب المتلقي.
في حالة كتابة نظام المحاسبة بلغة PHP ، هناك وظيفة
جاهزة للاتصال بـ API opencards (يمكنك ببساطة إزالة سطر رسالة الخطأ من النظام).