اتصالات أنظمة تخطيط الموارد (ERP)

تربط اتصالات ERP نظام تخطيط الموارد في شركتك بـ VEXORS. وهي متاحة على باقة Scale ويديرها مسؤولو الشركة من الإعدادات ثم اتصالات أنظمة تخطيط الموارد (ERP). يغطي VEXORS مرحلة التوريد حتى الترسية، ويتولى نظام ERP لديك كل ما بعدها.

ما الذي يفعله الاتصال

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

يُحدَّد كل ما يدعمه نظام ERP عند إنشاء الاتصال، ويمكنك إلغاء تحديد ما لا تريده. يُحفظ الاتصال الجديد كـ مسودة، ولا يفعل شيئاً إلى أن ينجح في اختبار الاتصال، وعندها فقط يمكن تفعيله. ويفحص الاختبار ما تحتاجه كل مزامنة محددة، فلا ينجح اتصالٌ حُدِّدت فيه أوامر الشراء إلا بعد اكتمال إعداد أوامر الشراء.

الاعتماد والاستلام والدفع تبقى في نظام ERP لديك

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

ما الذي يُرسَل وما الذي لا يُرسَل أبداً

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

لا يرسل VEXORS أبداً بقية مقدّمي العروض ولا أسعارهم ولا ترتيبهم، ولا تعليقاتك الداخلية ولا رسائل المحادثة ولا التقييمات.

بيانات الاعتماد لا تغادر VEXORS. تُشفَّر بيانات الاعتماد التي تدخلها أثناء التخزين، ولا تظهر مرة أخرى بعد حفظها (يعرض الاتصال معاينة قصيرة فقط مثل آخر أربعة أحرف من معرّف العميل)، ولا تُكتب في السجلات، ولا تعيدها أي واجهة API من VEXORS. ولتغييرها تُدخل بيانات جديدة. يتم كل طلب إلى نظام ERP لديك عبر HTTPS إلى العنوان العام الذي سجّلته، وتُرفض العناوين الواقعة في شبكات خاصة أو داخلية.

إعداد اتصال

1. افتح الإعدادات ثم اتصالات أنظمة تخطيط الموارد (ERP) واختر إضافة اتصال.
2. اختر نظام ERP وسمِّ الاتصال وحدد بيئته (تجريبية أو إنتاج). ابدأ بالبيئة التجريبية.
3. أدخل عنوان نظام ERP وبيانات الاعتماد التي جهّزتها (قوائم التحقق أدناه).
4. شغّل اختبار الاتصال. يتحقق بالترتيب من أن النظام يمكن الوصول إليه، وأن تسجيل الدخول يعمل، وأن صلاحية الوصول إلى واجهة API التي يحتاجها VEXORS ممنوحة، وأن إعداد المنظمة سليم. يعرض كل فحص نجاحه أو فشله برسالة واضحة.
5. أبقِ المزامنات التي تريدها (تبدأ كل المزامنات المدعومة محددة) ثم فعّل الاتصال.

يمكن اختبار الاتصال مجدداً وتعطيله وتفعيله في أي وقت. يوقف التعطيل المزامنة ويلغي العمليات في الانتظار، ويزيل الحذف كذلك بيانات الاعتماد المحفوظة. يمكن للشركة أن تحتفظ بخمسة اتصالات كحد أقصى.

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

قائمة التحقق لكل نظام

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

Test ERP

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

SAP S/4HANA Cloud, Public Edition

المدعوم: سجل المورّدين (الشركاء التجاريون المصنّفون كمورّدين) يُسحب إلى دليل Connect لديك، وتسليم الترسية كأمر شراء معلّق (مسودة)، وقراءة حالة أمر الشراء. التأهيل بالتجربة الفعلية: قيد الانتظار: أُثبت على محاكاة لـ SAP مبنية من تعريفات الواجهات التي نشرتها SAP؛ ولم يُجرَ التشغيل على مستأجر اختبار SAP حقيقي بعد.

كيف تعمل المسودة في SAP. لا يوفّر SAP عبر واجهته البرمجية طريقة لإنشاء أمر شراء كمسودة. لذلك تنشئ VEXORS أمر الشراء معلّقاً (يعرضه SAP بحالة Held): محفوظاً لكنه غير مكتمل، ولم يُصدَر، ولم يُرسَل إلى المورد. يفتحه المشتري لديك في تطبيق Manage Purchase Orders ويراجعه ويُكمله؛ ومن بعدها يسري سير عمل الاعتماد وإعدادات الإرسال لديك كالمعتاد. وإذا أجاب SAP يوماً بأمر غير معلّق، تتوقف VEXORS وتذكر رقم الأمر ولا تغيّره أبداً، ليتحقق منه فريقك في SAP. لذا ينبغي أن يكون لدى مستأجرك سير عمل لاعتماد أوامر الشراء قبل تفعيل تسليم الترسية.

يجهّز مسؤول SAP لديك ما يلي في SAP Fiori:

1. مستخدم اتصال (Maintain Communication Users) بكلمة مرور. هذا هو اسم المستخدم وكلمة المرور اللذان تدخلهما في VEXORS. لا تُستخدم الشهادات ولا OAuth.
2. نظام اتصال (Communication Systems) لـ VEXORS، يكون مستخدم الاتصال ذاك مستخدمَه الوارد.
3. ترتيبات اتصال (Communication Arrangements) لسيناريوهين: SAP_COM_0008 "Business Partner, Customer and Supplier Integration" (مطلوب) وSAP_COM_0053 "Purchase Order Integration" (لازم لتسليم الترسية).
4. عنوان مضيف واجهة API لمستأجرك، مثل https://my300000-api.s4hana.cloud.sap. هذا هو عنوان ERP الذي تدخله: المضيف فقط دون مسار.
5. قيم الهيكل التنظيمي لأوامر الشراء: رمز الشركة (دائماً)، ولتسليم الترسية: منظمة المشتريات، ومجموعة المشتريات، والمصنع، ومجموعة المواد المستخدمة للبنود النصية، وفئة تخصيص الحساب (مثل K) مع مركز التكلفة وحساب الأستاذ العام، واختيارياً نوع مستند أمر الشراء (NB افتراضياً). أدخل كل قيم أوامر الشراء أو لا شيء منها.
6. خريطة وحدات القياس من وحدات VEXORS إلى وحدات SAP (وحدات SAP لا تتجاوز 3 أحرف، مثل PC وEA وKG)، وخريطة عملات إن كنت تسعّر بعملة يسميها SAP باسم مختلف.

لا حاجة إلى حقل مخصص في SAP: تكتب VEXORS مرجعاً من 12 حرفاً يبدأ بـ VX في حقل Your Reference القياسي لأمر الشراء (CorrespncExternalReference) وتجد الأمر فيه مجدداً، فلا يؤدي ردٌّ ضائع إلى أمر شراء ثانٍ: تبحث VEXORS عن المرجع قبل أن تنشئ مرة أخرى. أبقِ هذا الحقل دون تغيير حتى يظهر رقم الأمر في صفحة الترسية. هذا مُثبت اليوم على محاكاة لـ SAP؛ والتشغيل على مستأجر حقيقي جزء من تأهيل SAP بالتجربة الفعلية.

ما الذي يفحصه اختبار اتصال SAP. إمكانية الوصول؛ تسجيل الدخول بمستخدم الاتصال؛ استجابة واجهة Business Partner (SAP_COM_0008)؛ وعند تحديد أوامر الشراء: أن قيم أوامر الشراء مضبوطة، واستجابة واجهة Purchase Order (SAP_COM_0053)، وإمكانية البحث في حقل Your Reference على مستأجرك، وأن الخدمة تسمح لـ VEXORS بإنشاء أمر شراء معلّق بذلك المرجع. وإذا حُدِّدت أوامر الشراء دون قيمها، يفشل الاختبار ويذكرها؛ ألغِ تحديد أوامر الشراء لاتصال يقتصر على سجل المورّدين.

قيود ينبغي معرفتها. تسجيل الدخول باسم مستخدم وكلمة مرور فقط. أوصاف البنود التي تتجاوز 40 حرفاً تُقتطع في نص البند. القراءة التزايدية للمورّدين تعتمد على تاريخ التغيير في SAP، لذا يُقرأ المورّد الذي تغيّر في يوم آخر قراءة مرة أخرى (دون ضرر). لا ينشر SAP حدّاً لمعدل الطلبات؛ وتتراجع VEXORS عند ردّي "طلبات كثيرة جداً" و"غير متاح".

Microsoft Dynamics 365 Finance & Supply Chain Management

المدعوم: يُسحب مورّدو الكيان القانوني المضبوط إلى دليل Connect لديك، وتسليم الترسية كمسودة أمر شراء، وقراءة حالة أمر الشراء. التأهيل بالتجربة الفعلية: قيد الانتظار: أُثبت على محاكاة لـ Dynamics 365 مبنية من البيانات الوصفية المنشورة لبيئة حقيقية؛ ولم يُجرَ التشغيل على بيئة اختبار Dynamics 365 حقيقية بعد.

كيف تعمل المسودة في Dynamics 365. يكون أمر الشراء في حالة Draft في Dynamics 365 فقط عندما تنطبق عليه إدارة التغيير (change management). تطلب VEXORS إدارة التغيير لكل أمر شراء تنشئه، وتتحقق من أن الأمر في حالة Draft فعلاً قبل أن تضيف أي بند. وقبل أن تنشئ أي شيء، تقرأ VEXORS إعدادات المورد الفائز: فإن لم تكن إدارة التغيير مفعّلة لهذا المورد ولا مسموحاً بها لكل أمر شراء، لا يُنشأ شيء وتذكر صفحة الترسية المورد والإعداد الواجب تغييره. وإذا جعلت بيئتك الأمر معتمداً فوراً رغم ذلك، تتوقف VEXORS قبل إضافة البنود وتذكر رقم الأمر الفارغ ليلغيه مسؤول النظام أو يحذفه. في Procurement and sourcing parameters فعّل إدارة التغيير (واسمح بها لكل مورد عند الحاجة) قبل تفعيل تسليم الترسية.

يجهّز مسؤول Dynamics 365 لديك ما يلي:

1. تطبيق Microsoft Entra (تسجيل تطبيق) في مستأجرك مع سرّ عميل. دوّن معرّف الدليل (المستأجر) ومعرّف التطبيق (العميل) وقيمة السر. في VEXORS تُدخلها بوصفها عنوان الرمز https://login.microsoftonline.com/<معرّف المستأجر>/oauth2/v2.0/token، ومعرّف العميل، وسرّ العميل، والنطاق https://<مضيف بيئتك>/.default. لا تُستخدم الشهادات.
2. تسجيل التطبيق في Dynamics 365: في finance and operations، System administration > Setup > Microsoft Entra applications، أضف معرّف العميل واربطه بـمستخدم حساب خدمة مخصص يحمل أدوار الأمان لقراءة المورّدين، ولتسليم الترسية، إنشاء أوامر الشراء.
3. عنوان البيئة، مثل https://contoso-test.sandbox.operations.dynamics.com. هذا هو عنوان ERP الذي تدخله: المضيف فقط دون مسار.
4. الكيان القانوني (معرّف الشركة، مثل usmf). كل قراءة للمورّدين وكل أمر شراء تنشئه VEXORS يُحصر فيه.
5. لتسليم الترسية: فئة المشتريات التي تستخدمها VEXORS لبنود الترسية (تُنشأ البنود كبنود فئة لا بنود صنف)، واختيارياً موقع ومستودع للاستلام.
6. خريطة وحدات القياس من وحدات VEXORS إلى رموز وحدات Dynamics 365 (مثل ea وpcs وkg)، وخريطة عملات عند الحاجة.

لا حاجة إلى حقل مخصص في Dynamics 365: تكتب VEXORS مرجعها في حقل Vendor reference لأمر الشراء (VX:<معرّف الترسية>:L<عدد البنود>) وتجد الأمر به مجدداً داخل كيانك القانوني. أبقِ هذه القيمة دون تغيير ما دام الأمر في حالة Draft.

ما الذي يفحصه اختبار اتصال Dynamics 365. تسجيل الدخول بتطبيق Entra؛ وأن البيانات الوصفية OData للبيئة تكشف كيانات المورّدين والشركات (ومع تحديد أوامر الشراء: كيانات أوامر الشراء) بالحقول التي تستخدمها VEXORS، ومنها إعدادات إدارة التغيير للمورّدين، وأن مرجع المورد وطلب إدارة التغيير قابلان للكتابة عند الإنشاء؛ وأن الكيان القانوني موجود؛ ومع تحديد أوامر الشراء: أن فئة المشتريات مضبوطة، وأن أوامر الشراء قابلة للبحث بمرجع المورد في بيئتك، وأن مورّداً واحداً على الأقل في الكيان القانوني يمكنه استلام مسودات أوامر الشراء (إدارة التغيير مفعّلة له أو مسموح بها لكل أمر). وإذا حُدِّدت أوامر الشراء دون الفئة، يفشل الاختبار ويذكرها.

قيود ينبغي معرفتها. لا يحمل مورّدو Dynamics 365 طابعاً زمنياً للتغيير، لذا كل سحب للمورّدين قراءة كاملة للكيان القانوني. يُكتب أمر الشراء كرأس تتبعه بنوده؛ وإن رُفض بند بعد وجود الرأس، يفشل التسليم برقم أمر الشراء في Dynamics 365 والسبب، وتُكمل المحاولة التالية الأمر نفسه بدل إنشاء آخر. وإن نفدت المحاولات قبل ذلك، تعرض صفحة الترسية أن التسليم فشل، أو تذكر أن أمر الشراء موجود لكنه غير مكتمل؛ وفي الحالتين أعد إرسال الترسية وستُكمل VEXORS الأمر نفسه. تحدّ Microsoft من التكاملات الثقيلة برد "طلبات كثيرة جداً" مع مدة انتظار؛ وتحترمها VEXORS.

Oracle Fusion Cloud ERP (Procurement)

المدعوم: يُسحب المورّدون الذين يمكن لوحدة الأعمال الطالبة لديك الشراء منهم إلى دليل Connect، وتسليم الترسية كمسودة أمر شراء، وقراءة حالة أمر الشراء. التأهيل بالتجربة الفعلية: قيد الانتظار: أُثبت على محاكاة لـ Oracle Fusion مبنية من توثيق REST الذي نشرته Oracle؛ ولم يُجرَ التشغيل على بيئة اختبار Oracle حقيقية بعد.

كيف تعمل المسودة في Oracle. تنشئ VEXORS مسودة أمر شراء (مسودات أوامر الشراء في Oracle تُنشأ ولا تُبلَّغ إلى المورد بعد) وتتركها في حالة Incomplete. يراجعها المشتري لديك في Oracle، ويضيف موقع المورد وأي شيء آخر تتطلبه إجراءاتكم، ثم يقدّمها؛ ومن هناك يقرر اعتماد Oracle.

يجهّز مسؤول Oracle لديك ما يلي:

1. مستخدم تكامل مخصص في Oracle Fusion (Security Console) بكلمة مرور، يحمل أدوار قراءة المورّدين، ولتسليم الترسية، دور Procurement REST Service duty (ORA_PO_PROCUREMENT_REST_SERVICE_DUTY) مع صلاحية إنشاء أوامر الشراء؛ ويجب أن يكون المستخدم وكيل مشتريات في وحدة أعمال المشتريات. تسجّل VEXORS الدخول باسم المستخدم وكلمة المرور هذين (HTTP Basic عبر HTTPS). لا تُستخدم تسجيلات OAuth.
2. عنوان البيئة (pod)، مثل https://acme-test.fa.em2.oraclecloud.com. هذا هو عنوان ERP الذي تدخله: المضيف فقط دون مسار. تستدعي VEXORS موارد Procurement REST تحت /fscmRestApi/resources/11.13.18.05/.
3. معرّف وحدة الأعمال الطالبة (القيمة الرقمية RequisitioningBUId). كل قراءة للمورّدين تستخدمه (يُسرد المورّدون عبر باحث Oracle "find by requisitioning BU").
4. لتسليم الترسية: معرّف وحدة أعمال المشتريات، والمشتري (معرّف شخص وكيل المشتريات)، ومعرّف نمط مستند الشراء، وفئة الشراء التي تستخدمها VEXORS لبنود الترسية (تُنشأ البنود كبنود "Goods" غير كتالوجية بوصف الصنف لا برقم صنف)، واختيارياً رمزا موقع الشحن وموقع التسليم.
5. خريطة وحدات القياس من وحدات VEXORS إلى أسماء وحدات Oracle (مثل Each)، وخريطة عملات عند الحاجة.

لا حاجة إلى حقل مخصص أو flexfield في Oracle: تبدأ VEXORS وصف أمر الشراء بمرجعها (VX:<معرّف الترسية>:BU<معرّف وحدة الأعمال>:L<عدد البنود>، ووحدة الأعمال هنا هي وحدة أعمال المشتريات) يليه مرجع الطلب وعنوانه، وتجد الأمر به مجدداً. أبقِ بداية هذا الوصف دون تغيير ما دام الأمر مسودة.

ما الذي يفحصه اختبار اتصال Oracle. تسجيل الدخول بمستخدم التكامل وإمكانية قراءة المورّدين؛ وإمكانية سرد المورّدين لوحدة الأعمال الطالبة لديك (باحث Oracle)؛ ومع تحديد أوامر الشراء: أن قيم التسليم مضبوطة، وإمكانية قراءة مسودات أوامر الشراء والبحث فيها بالوصف داخل وحدة أعمال المشتريات لديك. وإذا حُدِّدت أوامر الشراء دون قيمها، يفشل الاختبار ويذكرها. يُتوقَّع أن يُجيب معرّف وحدة الأعمال غير المعروف بقائمة مورّدين فارغة لا بخطأ (يُؤكَّد ذلك على بيئة Oracle حقيقية)، فتحقّق من المعرّف في Oracle.

قيود ينبغي معرفتها. لا يمكن تصفية مورد المورّدين في Oracle بتاريخ آخر تحديث، لذا كل سحب للمورّدين قراءة كاملة. لا تُقرأ عناوين بريد المورّدين (جهات الاتصال مورد منفصل). يُرسل أمر الشراء بكل بنوده في طلب واحد؛ وإن ضاع الرد، تبحث المحاولة التالية عن الأمر بوصفه قبل إنشاء أي شيء، فلا تنشئ VEXORS أمر شراء ثانياً أبداً. من حالات أمر الشراء في Oracle لا تُؤكَّد من التوثيق إلا "Incomplete"؛ وتُربط الحالات الأخرى بأسمائها في دليل المستخدم، وتُعرض الحالة غير المألوفة بوصفها غير معروفة حتى تُؤكَّد على بيئة حقيقية.

Odoo (16–20)

المدعوم: يُسحب مورّدو شركة Odoo المضبوطة (والمورّدون المشتركون بين الشركات) إلى دليل Connect لديك، مع سحب تزايدي للمورّدين الذين تغيّروا مؤخراً؛ وتسليم الترسية كمسودة أمر شراء؛ وقراءة حالة أمر الشراء. التأهيل بالتجربة الفعلية: قيد الانتظار: أُثبت على خوادم Odoo Community حقيقية بالإصدارات 16.0 و17.0 و18.0 و19.0 و20.0 (الإصدارات الرسمية) في مختبر الاختبار الخاص بـ VEXORS؛ ولم يُجرَ التشغيل على قاعدة بيانات اختبار Odoo لدى عميل بعد، وستُراقب الاتصالات الحقيقية الأولى عن كثب.

كيف تعمل المسودة في Odoo. تنشئ VEXORS أمر شراء في حالة المسودة موجَّهاً إلى المورد الفائز، ولا تؤكده ولا ترسله أبداً. يسمّي Odoo نفسه مسودة أمر الشراء "RFQ" (طلب عرض أسعار) ويدرجها تحت Requests for Quotation إلى أن يؤكدها أحد: هذا هو اسم Odoo لأمر شراء غير مؤكد، وليس جولة توريد ثانية. يراجعها المشتري لديك ويؤكدها، ومن بعدها تسري قواعد الاعتماد في Odoo (مثل الاعتماد المزدوج فوق مبلغ معيّن).

إصدارات Odoo وأنواع النشر المدعومة: Odoo 16.0 و17.0 و18.0 و19.0 و20.0. تسأل VEXORS خادمك عن إصداره وتستخدم واجهة البرمجة الخارجية الخاصة بذلك الإصدار — واجهة JSON-RPC الخارجية على 16 و17 و18، وواجهة External JSON-2 على 19 و20 — فلا شيء تختاره؛ ويمكنك إدخال الإصدار الذي تتوقعه، فيتوقف الاتصال — اختباره وكل مزامنة — إذا أبلغ الخادم عن إصدار مختلف (بعد الترقية، حدّث ذلك الحقل أو امسحه). اختُبرت الإصدارات الخمسة كلها على خوادم Community حقيقية. يستخدم Enterprise (باستضافة ذاتية أو على Odoo.sh) واجهة البرمجة الخارجية نفسها وسجلات المشتريات وجهات الاتصال نفسها، لذا يُتوقَّع أن يتصرف بالطريقة نفسها، لكنه لم يُختبر بعد على خادم Enterprise. يعمل Odoo Online بالإصدارات الوسيطة الخاصة بـ Odoo (مثل saas~18.3)، وتقرؤها VEXORS على أنها الإصدار الذي جاءت منه؛ لم تُختبر بعد، وإذا اختلف أحدها يتوقف اختبار الاتصال قبل إنشاء أي شيء. وفيه تتاح واجهة البرمجة الخارجية في خطة Custom فقط (لا في One App Free ولا Standard)، ولم تُقَس حدود الطلبات الخاصة بـ Odoo Online. تُرفض الإصدارات الأقدم من 16 والأحدث من 20 بالاسم.

يجهّز مسؤول Odoo لديك ما يلي:

1. مستخدم روبوت مخصص (Settings > Users) له صلاحية الوصول إلى جهات الاتصال في الشركة التي ستربطها، ولتسليم الترسية صلاحية Purchase: User، ويفضَّل ألا تكون له صلاحيات أخرى؛ وتوصي Odoo بتعطيل تسجيل الدخول بكلمة المرور لهؤلاء المستخدمين.
2. مفتاح API لذلك المستخدم: Preferences > Account Security > New API Key، مع وصف (ومدة أيضاً بدءاً من Odoo 18). انسخ المفتاح مرة واحدة — لا تعرضه Odoo مجدداً. في VEXORS تُدخل اسم دخول مستخدم الروبوت بوصفه اسم المستخدم ومفتاح API بوصفه كلمة المرور (على 16 و17 و18 تسجّل VEXORS الدخول بالاثنين معاً؛ وعلى 19 و20 يكفي المفتاح وحده لتحديد المستخدم). لا تقبل VEXORS في ذلك الحقل إلا مفتاح API من Odoo، وترفض كلمة مرور المستخدم. على Odoo 20 استخدم مفتاحاً أُنشئ في Odoo 20 نفسه: لا يقبل Odoo 20 إلا المفاتيح ذات النطاق "RPC" الذي تمنحه إياها شاشة المفاتيح فيه، ويرفض المفتاح الذي بلا نطاق. عند انتهاء صلاحية المفتاح أو حذفه يتوقف الاتصال بخطأ مصادقة حتى يُدخل مفتاح جديد وينجح الاختبار.
3. عنوان النسخة، مثل https://acme.odoo.com. هذا هو عنوان ERP الذي تدخله: المضيف فقط دون مسار. أدخل اسم قاعدة البيانات أيضاً: فهو مطلوب على Odoo 16 و17 و18 (كل استدعاء يذكره)، وعلى 19 و20 لا يلزم إلا إذا كان خادم واحد يستضيف عدة قواعد بيانات.
4. معرّف الشركة (المعرّف الرقمي للشركة تحت Settings > Companies، ويظهر في عنوان الصفحة). كل قراءة للمورّدين وكل أمر شراء يُحصر في تلك الشركة؛ ويجب أن يكون مستخدم الروبوت مسموحاً له بالعمل فيها.
5. لتسليم الترسية: تطبيق Purchase، ومنتج واحد قابل للشراء تكتب VEXORS كل بنود الترسية عليه (يصبح نص الترسية وصف البند؛ ومنتج الخدمة لا يُنشئ استلاماً)، وخريطة وحدات القياس من وحدات VEXORS إلى وحدات القياس في Odoo، وأن تكون عملة الترسية مفعّلة في Odoo (أو خريطة عملات).

لا حاجة إلى حقل مخصص. تكتب VEXORS مرجعها في حقل Source Document لأمر الشراء (VX:<معرّف الترسية>:C<معرّف الشركة>:L<عدد البنود>) وتجد الأمر فيه مجدداً، فلا يؤدي ردٌّ ضائع إلى أمر شراء ثانٍ. يجب تثبيت تطبيق Invoicing أو Purchase لمزامنة المورّدين (فهو يوفّر رتبة المورّد التي تعتمد عليها المزامنة؛ ويذكر اختبار الاتصال ذلك عند غيابه). تُعد جهة الاتصال مورّداً عندما تكون قد استُخدمت كمورّد في Odoo (رتبة المورّد لديها أعلى من الصفر — أُنشئت من تطبيق المشتريات أو استلمت فاتورة)؛ أما جهة اتصال أُنشئت يدوياً ولم يكن لها شراء أو فاتورة فلا تُسحب حتى تُستخدم كمورّد.

ما الذي يفحصه اختبار اتصال Odoo. أن العنوان يجيب بوصفه خادم Odoo، وما إصداره (وأنه الإصدار الذي أدخلته، إن أدخلت واحداً)؛ وتسجيل الدخول بمفتاح API الخاص بمستخدم الروبوت؛ وأن الشركة موجودة وأن مستخدم الروبوت مسموح له بالعمل فيها؛ وأن جهات الاتصال قابلة للقراءة ضمن تلك الشركة؛ ومع تحديد أوامر الشراء: أن المنتج مضبوط، وأن أوامر الشراء قابلة للقراءة والبحث بحقل Source Document في تلك الشركة، وأن مستخدم الروبوت مسموح له بإنشاء أوامر الشراء، وأن بند أمر الشراء فيه حقل وحدة القياس الخاص بإصدارك، وأن المنتج المختار قابل للشراء في تلك الشركة. وإذا حُدِّدت أوامر الشراء دون المنتج، يفشل الاختبار ويذكره.

قيود ينبغي معرفتها. Odoo من 16.0 إلى 20.0 فقط. يمكن حذف مفاتيح API في أي وقت، وبدءاً من Odoo 18 تنتهي صلاحيتها. يُسحب المورّدون الذين تغيّروا مؤخراً تزايدياً بحسب وقت آخر تعديل؛ والسحب الكامل متاح دائماً، ويلتقط أيضاً المورّد الذي لا وقت آخر تعديل له (مورّد كُتب في قاعدة البيانات خارج Odoo). تُستنتج رموز الدول من قائمة الدول في Odoo؛ والمورّد بلا دولة لا رمز له. لا تُطابَق بنود الترسية مع منتجاتك في Odoo: كل بند يستخدم المنتج الواحد الذي اخترته.

لا يُعد أي مما في هذه الصفحة وعداً بموعد. كل نظام أعلاه متاح بكل ما يُذكر أنه مدعوم؛ ويبيّن تأهيله بالتجربة الفعلية إن كانت VEXORS قد شغّلته أيضاً على بيئة اختبار حقيقية لدى عميل (اليوم: قيد الانتظار للأنظمة الأربعة). أما أنظمة ERP الأخرى، مثل NetSuite وInfor، فليست متاحة بعد.