محرك تحكم تكلفة المشاريع في D365 F&O للمقاولات: تحويل Procurement + Warehouse + Finance إلى رؤية يومية على BOQ/Activity

الملخص التنفيذي

حولت دورة المشتريات والمخازن والفوترة في D365 إلى لغة تكلفة واحدة تربط كل حركة بـ BOQ/Activity/WBS، وتعرض Committed vs Actual يوميًا، مع محرك تخصيص تلقائي للخصومات/الشحن/الضريبة وفروقات الاستلام/الفوترة ورايات Settlement.

السياق

البيئة كانت مقاولات متعددة المواقع مع تعدد موردين وتنوع بنود (مواد، خدمات، معدات)، وفي نفس الوقت كل مشروع عنده BOQ/WBS خاص به. البيانات كانت موجودة داخل D365، لكن القراءة كانت محاسبية أكثر من كونها تشغيلية، وبالتالي المتابعة اليومية كانت صعبة.

المطلوب كان واضح: نظام يومي يربط الحركة التشغيلية بالتكلفة الفعلية والالتزام المالي، ويخرج بلغة يفهمها Finance وProject Control وProcurement بدون تضارب تعريفات أو اجتهادات يدوية.

المشكلة

المشكلة لم تكن في غياب البيانات، بل في غياب نموذج تكلفة موحد يحترم طبيعة كل نوع بند.

1) Committed vs Actual حسب نوع البند

• مواد المخزون كانت ترتبط بالاستلام، بينما الخدمات ترتبط بالفاتورة.
• نفس التقرير كان يعامل البنود كلها بنفس المنطق فينتج عنه قراءة مضللة.

2) Header discounts/charges

• خصومات أو Charges على رأس مستند الشراء كانت تُهمل أو تتوزع يدويًا.
• غياب التوزيع العادل كان يغيّر تكلفة الوحدة الحقيقية لكل Activity.

3) VAT base

• قاعدة الضريبة كانت تتأثر بتوقيت الخصومات والإضافات.
• أي ترتيب خاطئ في الحساب ينتج فروقات reconciliation مع Finance.

4) Received vs Invoiced

• فرق زمني طبيعي بين الاستلام والفاتورة كان يُفسر كخطأ بدلاً من كونه حالة تشغيلية يجب إدارتها.
• غياب منطق واضح للحالات المفتوحة زاد عدد الاستفسارات بين الفرق.

5) Settlement risk

• بعض المعاملات كانت تُغلق محاسبيًا بينما ما زالت تشغيليًا غير مكتملة.
• عدم وجود Flags واضحة رفع مخاطر إقفال مبكر أو متأخر.

المنهج

Solution Architecture (Layer 1..5)

1. Layer 1 - Data Capture: استخراج حركات PO/PR/Product receipt/Vendor invoice من D365 مع مفاتيح Project + BOQ + Activity.
2. Layer 2 - Classification: تصنيف البند (Material / Service / Equipment) لتحديد منطق الاعتراف الصحيح.
3. Layer 3 - Allocation Engine: توزيع خصومات الرأس والشحن والضريبة على مستوى السطر حسب قواعد موزونة.
4. Layer 4 - Cost Fact Model: إنتاج Fact موحد يعرض Committed وActual وVariance عبر WBS hierarchy.
5. Layer 5 - Decision Layer: لوحات تنفيذية وتشغيلية مع Flags استثنائية وDrill-down حتى مستوى المعاملة.

النموذج

Allocation Engine steps (A..D)

1. Step A: بناء Base Amount لكل سطر حسب نوع البند وتوقيت الاعتراف.
2. Step B: توزيع Header discounts بنسبة مساهمة كل سطر في إجمالي المستند.
3. Step C: توزيع Charges (شحن/مناولة/رسوم) بنفس منهجية موحدة قابلة للتدقيق.
4. Step D: احتساب VAT base بعد الخصم والإضافة ثم إعادة ربط النتيجة مع Project/BOQ/Activity.

Received vs Invoiced logic

• للمواد: الاعتراف التشغيلي يبدأ من Product Receipt، والتحول لـ Actual invoice يتم عند الفاتورة.
• للخدمات: الاعتراف الأساسي يعتمد على Vendor Invoice مع إظهار committed منفصل.
• لكل سطر يتم إنشاء Status واضح: Received-not-invoiced / Invoiced / Partially invoiced.

Settlement flags

• Flag 1: Invoice posted but unmatched quantity/value.
• Flag 2: Receipt aging تجاوز الحد المسموح بدون فاتورة.
• Flag 3: Unexpected negative variance بعد settlement.
• Flag 4: Header allocations outlier مقارنة بالنمط التاريخي.

اللوحات (4 صفحات)

الأثر

• انخفاض كبير في زمن reconciliation بين Procurement وFinance بفضل قواعد موحدة.
• وضوح يومي للاستهلاك مقابل الميزانية على مستوى BOQ/Activity بدل الرؤية الشهرية المتأخرة.
• تحويل تقارير التكلفة من "ما حدث" إلى "أين الخطر القادم" عبر Flags استباقية.
• تحسن سرعة اتخاذ القرار في مشاريع متعددة المواقع مع لغة تشغيلية واحدة.

الأدلة

يمكن مراجعة ملفات داعمة للتصميم وطريقة العرض التنفيذي عبر الروابط التالية: