Value Proposition: Source to Target Mapping هو المستند الذي يُغلق سؤال “ده بيروح فين؟” قبل ما يتحول المشروع إلى Rejects وإعادات تحميل. بدل ما تتحول قواعد التحويل إلى تعديلات داخل ملفات التحميل أو كود غير موثق، هذا Source-to-Target Template يثبت: مصدر الحقل، وجهته في النظام الجديد، قاعدة تحويل البيانات Transformation، أي Lookup Tables مطلوبة، ومن اعتمد القرار—بحيث تصبح Iterations الترحيل قابلة للتكرار وبأدلة (Mapping Matrix + Rule Log + Sign-off).

في 20 ثانية: ماذا ستحصل عليه؟

• Data Mapping Sheet على مستوى الحقل: Source field → Target field + نوع البيانات + Mandatory/Optional.
• سجل قواعد تحويل البيانات Transformation (Rule IDs): Trim/Normalize/Date parsing/Derivations/Sign conventions.
• Lookup Tables للكودات (Old code → New code) + سجل Unmapped values قبل التحميل.
• Mapping بين الأنظمة مع تعريف Keys/Joins وقرارات Deduplication عند وجود مصادر متعددة.
• خطة تحويل البيانات (Sequence & Dependencies): ما الذي يُحمّل أولًا وما الذي يعتمد على ماذا.
• قواعد Validation: Mandatory/Formats/Uniqueness/Referential integrity + Control totals.
• صفحة اعتماد: Prepared/Reviewed/Approved + Version + تاريخ سريان (Effective date) لكل Dataset.

التحميل مرتبط بالمخرجات: تستلم Mapping Matrix + Transformation Rules + Lookup Tables جاهزة للاعتماد ثم التنفيذ داخل ملفات الترحيل/ETL.

مناسبة لـ

• فرق ERP/Data Migration التي تحتاج مرجع واحد يضبط قرارات التحويل قبل Test loads وUAT.
• Finance/Accounting عند Mapping COA/Tax/Terms/Dimensions بين الأنظمة بشكل لا يترك مساحة “لتفسيرات” لاحقة.
• مشاريع Multi-entity حيث اختلاف الأكواد بين الفروع يسبب Unmapped/Rejects متكررة.

غير مناسبة لـ

• من لا يملك Target model/Upload template أو لا يستطيع تحديد Target fields — لا يمكن عمل Source-to-Target بدون طرفين واضحين.
• من يريد “تحميل سريع” بدون توثيق واعتماد — المنتج مصمم لتقليل مخاطر إعادة التحميل وفروق UAT عبر قرارات موثقة.

بدون الـSheet / مع الـSheet (مقارنة قصيرة)

قبل الاستخدام: 5 أعراض أن الترحيل يُدار بالاجتهاد

• كل Iteration تظهر نفس الأسئلة: “ده بيروح فين؟” لأن Mapping غير موثق.
• تكرار Rejects بسبب Mandatory/Formats بدون قاعدة فحص قبل التحميل.
• اختلاف أكواد المصدر والهدف (Tax/Terms/UoM/Status) بدون Lookup Tables.
• دمج مصدرين (ERP قديم + CRM مثلًا) ينتج Duplicates/Drop records لأن Keys غير محددة.
• فروق في تقارير UAT لأن Transformation (التاريخ/الإشارة/العملة) غير ثابت أو غير معروف.

كيف يعمل Source to Target Mapping عمليًا؟

الخطوة 1: التحضير وجمع مواصفات المصدر والهدف

• تثبيت Source exports: اسم التقرير/الملف + تاريخ الاستخراج + Owner.
• تثبيت Target fields: Upload template أو API fields + Data types + Mandatory + Constraints.
• تعريف Domains (COA/Customers/Vendors/Items/Opening balances…) وتعيين Owner لكل Domain.

الخطوة 2: Mapping + Transformation + Lookup Tables

• ملء Data Mapping Sheet: لكل Target field ما مصدره؟ وما Rule التحويل؟ وما Default value إن لزم؟
• تسجيل قواعد تحويل البيانات Transformation كـRule IDs مع أمثلة Input/Output.
• إعداد Lookup Tables للكودات وتصنيف Unmapped values (Map/Add/Block) بقرار Owner.

الخطوة 3: Validation + Tie-outs + اعتماد النسخة

• تشغيل Validation: Mandatory/Format/Uniqueness/Referential integrity + كشف Duplicates بعد الدمج.
• إصدار Control totals (Counts/Amounts) قبل/بعد التحويل وقبل/بعد التحميل (إن أمكن).
• إصدار Version مع Sign-off: Prepared/Reviewed/Approved بحيث تصبح هذه هي القواعد التي يتم التنفيذ بها في Iteration/Cutover.

مكونات الـSheet (جرد واضح)

1. Source-to-Target Mapping Matrix
   • الغرض العملي: توثيق Mapping بين الأنظمة على مستوى الحقل (Source → Target) مع نوع البيانات وإلزاميتها.
   • متى يُستخدم: قبل أي Test load، ومع أي تغيير في Target template.
   • الدليل الناتج: Mapping matrix مع Owners وStatus لكل حقل (Mapped/Unmapped/Needs decision).
2. Transformation Rules Log (تحويل البيانات Transformation)
   • الغرض العملي: تثبيت قواعد التحويل كقواعد مرقمة (Rule IDs) بدل “تحويلات داخل ملف التحميل”.
   • متى يُستخدم: عند تجهيز ملفات الترحيل/ETL وعند تفسير فروق UAT.
   • الدليل الناتج: Rule ID + وصف القاعدة + Example input/output + Owner approval.
3. Lookup Tables Library
   • الغرض العملي: ربط القيم بين الأنظمة (Old code → New code) وتحديد Unmapped قبل التحميل.
   • متى يُستخدم: قبل التحميل وعند ظهور Code جديد في المصدر.
   • الدليل الناتج: Lookup tables + Unmapped list + قرار Owner لكل قيمة.
4. Keys & Merge Logic
   • الغرض العملي: توثيق مفاتيح الربط (Keys) ومنطق الدمج/الأولوية (Source precedence) لتفادي Duplicates أو Drop records.
   • متى يُستخدم: عند وجود أكثر من مصدر، أو عند دمج نفس الـMaster من إدارات مختلفة.
   • الدليل الناتج: Key definition + Merge rules + Dedup criteria + حالات استثناء.
5. Validation & Control Totals
   • الغرض العملي: فحوصات قبول قبل التحميل + Tie-outs بعد التحويل لتقليل Rejects وفروق غير مفسرة.
   • متى يُستخدم: في كل Iteration (Test load 1/2/3) وقبل Cutover.
   • الدليل الناتج: Validation results + Error list + Control totals (Counts/Amounts).
6. Versioning + Change Log + Sign-off
   • الغرض العملي: ضبط النسخة المعتمدة ومنع تضارب القواعد بين الفرق وبين Iterations.
   • متى يُستخدم: عند أي تعديل في mapping/rules/lookups أو عند تحديث Target fields.
   • الدليل الناتج: Version register + Change log + Prepared/Reviewed/Approved.

ما الذي يجب أن يكون موجودًا داخل التسليم؟

• 01-Pack Index: نطاق الـDatasets + Owners + Version + تاريخ سريان.
• 02-Source Register: سجل مصادر البيانات (Export name/date/owner/location).
• 03-Data Mapping Sheet: Source → Target mapping + Mandatory/Type/Format + Default values.
• 04-Transformation Log: خطة تحويل البيانات وقواعد Transformation (Rule IDs + أمثلة + اعتماد).
• 05-Lookup Tables: Codes mapping (Lookup Tables) + Unmapped list + قرارات معالجة.
• 06-Keys & Merge: تعريف Keys + Join logic + قواعد إزالة التكرارات بعد الدمج.
• 07-Validation: قواعد فحص + نتائج + Error/Exception register.
• 08-Control Totals: Counts/Amounts قبل/بعد التحويل + Tie-out rules (عند توفر بيانات مالية/كمية).
• 09-Change Log: سجل تغييرات mapping/rules بين الإصدارات + سبب + أثر.
• 10-Sign-off: Prepared/Reviewed/Approved + Ready criteria لكل Dataset قبل التحميل.

بعد التطبيق (نقطتان فقط)

• نتيجة تشغيلية للفريق: Iterations الترحيل تصبح مسار ثابت: تحديث Source exports → تطبيق Mapping/Transformation/Lookups → Validation → تحميل، بدل تعديل يدوي داخل كل ملف تحميل.
• نتيجة رقابية/تدقيقية: يمكن تتبع أي قيمة في Target إلى قرار موثق: Field mapping + Rule ID + Lookup + Version + Sign-off، ما يدعم تفسير فروق UAT أو فروق Post‑Go‑Live.

FAQ — أسئلة قبل الشراء

هل هذا المنتج مناسب لأي نظام ERP؟

نعم. لأن المخرجات “مواصفات Mapping وتحويل” تُستخدم سواء كان التحميل عبر Upload templates أو API أو أداة ETL.

هل هو بديل لقوالب الترحيل (Data Migration Templates)؟

لا. هذا يسبقها: يوثق Source-to-Target + Transformations + Lookups. ثم تُبنى ملفات الترحيل وفق هذه القواعد.

هل يدعم Mapping بين الأنظمة في حالة وجود أكثر من مصدر؟

نعم عبر جزء Keys & Merge logic لتحديد أولوية المصادر وقواعد الدمج وإزالة التكرارات.

متى نستخدم Lookup Tables؟

عندما تختلف الأكواد بين الأنظمة (Tax/Payment terms/UoM/Status/Groups). الهدف إغلاق Unmapped قبل التحميل بدل اكتشافه كـReject.

كيف نوثق قواعد تحويل البيانات Transformation بدون تعقيد؟

كل قاعدة تُسجل كـRule ID مع مثال Input/Output وOwner approval، ثم تُستخدم في التنفيذ داخل Power Query/ETL/ملفات التحويل.

هل يدعم تعدد الكيانات والعملات؟

نعم بإضافة Entity/Currency في mapping وقواعد تحويل خاصة عند الحاجة (مثل Defaults أو Translation codes) مع Versioning لكل نطاق.

ما الحد الأدنى من المدخلات المطلوبة للبدء؟

Source exports من النظام القديم + تعريف Target fields/قيود التحميل + تحديد Owners للقرارات + تعريف Keys للربط.

كيف يساعد في UAT؟

أي فرق في النتائج يمكن ربطه بـMapping/Rule/Lookup بدل افتراض أنه “مشكلة نظام”، وبالتالي التشخيص يصبح بالأدلة.

جاهز تثبّت قرارات الـMapping قبل بدء التحميل؟

المخرجات: Source to Target Mapping + تحويل البيانات Transformation + Lookup Tables مع Validation وVersion/Sign-off.