تكامل Oracle مع الأرشفة: الحقول والصلاحيات واتجاه مزامنة البيانات

يحدث السيناريو التالي كثيرًا: يتغير اسم مورد في Oracle بعد اندماج، فيبحث المراجع في الأرشيف بالاسم الجديد ولا يجد فواتير السنوات الثلاث الماضية لأنها أُرشفت بالاسم القديم. لم يتعطل شيء تقنيًا؛ الخلل أن أحدًا لم يقرر من يملك حقل «اسم المورد» بعد الأرشفة. الكلام هنا موجّه لمالك نظام Oracle ومهندس التكامل، ويساعدهما على حسم هذه القرارات قبل أن تتحول إلى بلاغات دعم.

كيف تتعامل Oracle مع المرفقات أصلًا

قبل تصميم الربط، افهم نموذج المرفقات في النسخة التي تستخدمها، لأن الحقول والصلاحيات تُشتق منه.

Oracle E-Business Suite

بحسب توثيق Oracle، يُرفق المستند بـ«كيان» (Entity) مثل صنف أو أمر أو سطر أمر، وتُحفظ معلومات الربط بين الكيان والمستند في جدول FND_ATTACHED_DOCUMENTS، مع قيم المفتاح الأساسي التي تحدد السجل بعينه. ولأن الربط محفوظ منفصلًا عن المستند، يمكن إرفاق المستند نفسه بعدة سجلات. أنواع المرفقات الافتراضية أربعة: ملف يُحمَّل إلى قاعدة البيانات، ونص قصير حتى 4000 بايت، ونص طويل، وصفحة ويب تُرفق كرابط URL.

أما الأمان فيقوم على فئات المستندات (Document Categories) التي تقيّد ما يُعرض أو يُضاف من نموذج أو وظيفة معينة، وعلى سياق أمني قد يكون المنظمة أو دفتر الأستاذ (Set of Books) أو وحدة الأعمال. ويمكن تعريف المستند بأمان «لا شيء» أو «مشترك» ليظهر عبر السياقات.

Oracle Fusion Cloud

يوثّق Oracle ميزة Managed Attachments مع Oracle WebCenter Content، وهي تربط المرفقات ببيانات وصفية للكائن التجاري مع بحث متقدم، وتتطلب بيئة WebCenter Content منفصلة. إن كانت جهتك على Fusion، فاسأل أولًا: هل لدينا WebCenter Content، وما الدور الذي سيبقى له بعد إدخال أرشيف مركزي؟

جدول الحقول: من يملك كل حقل؟

القاعدة الذهبية: كل حقل له مالك واحد. الحقل الذي تملكه Oracle لا يُعدَّل في الأرشيف يدويًا، والحقل الذي يملكه الأرشيف (مثل تصنيف السرية) لا يُكتب من Oracle. الجدول التالي نموذج لفواتير الموردين؛ كرّره لكل نوع مستند.

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

ولا تنسَ الحقول التي لا وجود لها في Oracle أصلًا ويملكها الأرشيف وحده: تصنيف السرية، والوسوم التي يضيفها فريق الوثائق، وملاحظات المراجعة، وحالة الاعتماد إن مرّ المستند بسير عمل داخل الأرشيف. هذه الحقول هي القيمة المضافة للأرشيف فوق مرفقات ERP، ويجب أن يعرف الجميع أنها لا تُكتب من Oracle ولا تُمسح عند المزامنة. اطلب من فريق التنفيذ أن يوضح في وثيقة التصميم أي الحقول «محمية» من الكتابة الآلية، وأن يثبت ذلك في الاختبار بتعديل حقل في Oracle ثم التأكد من أن الوسوم اليدوية بقيت كما هي.

جدول الصلاحيات: ترجمة سياق الأمان

أمان المرفقات في E-Business Suite مبني على الوظيفة والسياق، وأمان الأرشيف مبني على الأدوار والمجلدات والمستندات. لا يوجد تحويل آلي مضمون بين النموذجين، لذلك اكتب الترجمة صراحة:

قرار الاتجاه: ثلاثة أنماط وما يكلفه كل منها

كثير من الجهات تبدأ بالنمط الثاني وتضيف مزامنة حقلين أو ثلاثة من النمط الثالث عند الحاجة. تجنب «مزامنة في الاتجاهين» كعبارة عامة في كراسة الشروط؛ حدد الحقول بأسمائها، وإلا ستُفسَّر العبارة بأوسع أو أضيق مما قصدت.

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

مثال: مجموعة بثلاث وحدات أعمال

اختبارات خاصة بالحقول والصلاحيات

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

هذه الاختبارات تكمّل اختبارات النقل الأساسية (التكرار، وانقطاع الاتصال، وسجل التدقيق) التي تجدها في مقال نطاق ربط مرفقات SAP، فالمبدأ واحد وإن اختلف النظام.

فكّر في الترقية من اليوم الأول

كثير من الجهات التي تعمل على E-Business Suite تدرس الانتقال إلى Fusion Cloud أو إلى نظام آخر خلال سنوات. الربط الذي تبنيه اليوم يجب ألا يصبح عائقًا أمام ذلك القرار. ثلاث ممارسات تحمي استثمارك:

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

ما يقدمه وثيقة هنا

• التكامل: يتكامل وثيقة مع Oracle، ويأتي تكامل SAP وOracle ضمن الباقة المؤسسية كما في صفحة الأسعار.
• قدرات تخدم جدولي الحقول والصلاحيات: تصنيف هرمي وحقول ووسوم مخصصة، وصلاحيات مبنية على الأدوار على مستوى المجلد والمستند المنفرد، وصلاحيات هرمية تتبع الهيكل التنظيمي، واستيراد المستخدمين والأقسام من Active Directory/LDAP، وسجل تدقيق محمي بالتجزئة وقابل للتصدير، وتتبع إصدارات المستند.
• يُحدَّد في النطاق الفني: آلية الربط مع نسختك من Oracle (E-Business Suite أو Fusion)، والحقول المزامَنة بعد الأرشفة، والرابط العائد، وأي تقارير خاصة بوحدات الأعمال.

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

من الجداول الثلاثة إلى طلب العرض

املأ جدول الحقول لنوع مستند واحد فقط، وجدول الصلاحيات لوحدة أعمال واحدة، ثم اختر النمط. ضع الجداول الثلاثة في طلب عرض تكامل Oracle، واشترط أن يرد العرض الفني على كل صف فيها: مشمول، أو يحتاج تهيئة، أو خارج النطاق.