Value Proposition: نزاعات الموردين لا تصبح مشكلة عند وجود “فرق” فقط؛ تصبح مشكلة عند غياب ملف واحد يوضح: ما هي الفاتورة محل النزاع؟ ما سبب النزاع (فروقات PO/Invoice / استلام / سعر / ضريبة / تكرار)؟ من المالك؟ ما الإجراء المطلوب (CN/تصحيح PO/تصحيح GRN/إلغاء)؟ وما حالة الفاتورة (Hold/Approved/Partially paid)؟ هذا AP Dispute Tracker يبني نزاع المورد كحالة تشغيل قابلة للإغلاق، وليس سلسلة رسائل وبنود معلّقة تتراكم حتى Month‑End.

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

• AP Dispute Tracker: سجل نزاعات موحد برقم نزاع + رقم فاتورة + مورد + مبلغ + تاريخ/عمر النزاع.
• تصنيف فروقات PO/Invoice (Price/Qty/Tax/Reference/Service acceptance) بدل خانة “مشكلة عامة”.
• قائمة فواتير معلقة النزاع (On hold queue) مع Owner وسبب التوقف والإجراء المطلوب.
• متابعة إشعارات دائن المورد (CN) وربطها بالفاتورة/PO وإغلاق النزاع عند صدور CN أو التصحيح.
• Aging + SLA: قياس النزاعات المتأخرة (7/14/30/60 يوم) لتحديد ما يهدد Month‑End.
• Root Cause Dashboard: ما الذي يكرر النزاعات؟ (سعر؟ استلام؟ PO غير مطابق؟ ضريبة؟) لتصحيح العملية.
• Month‑End Disputes Pack: قائمة النزاعات المفتوحة + أسباب + حالة المستندات + Evidence index للتسليم داخل Closing Pack.

CTA مرتبط بالمخرجات: تستلم Dispute Register + Aging + CN Follow‑up + Month‑End Pack جاهزين للتشغيل والتسليم.

مناسبة لـ

• Accounts Payable (AP): إدارة فواتير معلقة النزاع وربطها بسبب/إجراء/مرفقات بدل الانتظار.
• Procurement + Receiving: حل نزاعات المشتريات الناتجة عن فروقات PO/Invoice أو مشاكل الاستلام/القبول.
• Controller / Head of Accounts: دخول Month‑End بقائمة نزاعات مفتوحة “مفسّرة” قابلة للتسليم ضمن Closing Pack.

غير مناسبة لـ

• إذا كانت شركتك لا تستخدم PO/GRN ولا يوجد أي مراجع للربط — ستحتاج أولًا ضبط مستندات دورة P2P حتى تصبح النزاعات قابلة للتتبع.
• إذا كنت تبحث عن نظام تذاكر (Ticketing) آلي مع إشعارات ومراسلات داخلية — هذا Tracker تشغيلي بملفات وليس منصة.

بدون Tracker / مع Tracker (مقارنة قصيرة)

قبل الاستخدام: 5 أعراض أن نزاعات الموردين تتسبب في “فواتير معلقة” بلا مالك

• قائمة Holds في AP كبيرة لكن بدون سبب مصنّف (هل هي فروقات PO/Invoice؟ استلام؟ سعر؟ ضريبة؟).
• نزاعات فواتير الموردين تُدار عبر مكالمات/رسائل، وعند السؤال لا يوجد رقم نزاع أو تاريخ بدء أو آخر متابعة.
• إشعارات دائن المورد (CN) تُصدر لكن لا تُغلق النزاع لأن لا يوجد ربط بين CN والفاتورة/PO.
• نفس نوع النزاع يتكرر (مثلاً فروقات سعر) بدون تقرير يثبت root cause ومن أين تأتي المشكلة.
• في Week‑4/Month‑End تظهر فواتير معلقة النزاع قديمة تؤثر على cut‑off وتسليم AP ضمن Closing Pack.

كيف تُدار نزاعات الموردين عمليًا من Hold في AP إلى الإغلاق قبل Month‑End؟

الفكرة ليست “نسجل نزاع” فقط؛ الفكرة أن كل نزاع يخرج بقرار واضح: هل نحتاج تصحيح PO؟ هل نحتاج تصحيح GRN/قبول خدمة؟ هل نحتاج CN؟ هل النزاع مجرد Timing وسيُغلق تلقائيًا بعد وصول مستند؟ AP Dispute Tracker يبدأ من قائمة فواتير معلقة النزاع ويحوّلها إلى حالات: تصنيف السبب، تحديد المالك (AP/Procurement/Receiving)، تسجيل الإجراء المطلوب والموعد، ثم إغلاق النزاع عند صدور CN أو تعديل المرجع أو اعتماد الفاتورة. في Week‑4 ينتج tracker قائمة نزاعات مفتوحة/Aging تدخل ضمن Month‑End Reconciliations وClosing Pack.

طريقة التطبيق (3 خطوات)

الخطوة 1: التحضير وجمع التقارير

• استخراج AP open invoices + hold list (Invoice#, Vendor, Amount, Due date, Hold reason إن وجد).
• استخراج مراجع الشراء المرتبطة (PO/GRN/Service acceptance) أو أي مرجع داخلي بديل.
• جمع CN/DN الصادرة من المورد (إن وجدت) + Vendor statement (اختياري عند وجود فروقات حساب مورد).
• تحديد Rule بسيط للتصنيف (Fروقات PO/Invoice، استلام/قبول خدمة، ضريبة، تكرار، مرجع ناقص، نزاع جودة…).

الخطوة 2: Reconciliations + تصنيف النزاعات + متابعة CN

• تسجيل كل فاتورة Hold كـDispute case: سبب النزاع + الوصف + المستندات الناقصة + المطلوب من كل طرف.
• تصنيف فروقات PO/Invoice إلى:
  • Price variance: سعر الفاتورة ≠ سعر PO/الاتفاق.
  • Qty variance: كمية الفاتورة ≠ كمية الاستلام/القبول.
  • Tax/withholding: فرق ضريبة أو معاملة WHT (حسب سياستك).
  • Reference issue: مرجع PO/GRN خاطئ أو غير موجود.
• فتح مسار معالجة: طلب CN / تعديل PO / تصحيح استلام / إلغاء فاتورة مكررة / طلب مستندات.
• تفعيل متابعة إشعارات دائن المورد: رقم CN، تاريخ الإصدار، القيمة، الفاتورة/النزاع المرتبط، وتاريخ تطبيقها في النظام.

الخطوة 3: إغلاق النزاعات + Month‑End Pack

• إغلاق النزاع بواحد من: اعتماد الفاتورة بعد التصحيح، تطبيق CN، إلغاء الفاتورة، أو تسوية مرجع الاستلام.
• إخراج قائمة “Open disputes” بعمر النزاع (Aging) + “Critical disputes” التي تؤثر على Month‑End.
• تجهيز Disputes Pack للتسليم: سجل النزاعات + قائمة CN المفتوحة + Evidence index + Sign‑off ضمن Closing Pack.

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

1. Dispute Intake (استقبال النزاع)
   • الغرض العملي: إدخال النزاع ببياناته الأساسية (Vendor/Invoice/PO/Amount) بدل رسائل غير موحدة.
   • متى يُستخدم: عند وضع الفاتورة على Hold أو عند ظهور نزاع جديد.
   • الدليل الناتج: Dispute ID + تاريخ بدء النزاع + owner.
2. AP Dispute Register (سجل نزاعات الموردين)
   • الغرض العملي: سجل واحد يضم كل نزاعات فواتير الموردين وحالتها وأثرها على الدفع.
   • متى يُستخدم: يوميًا في AP + مراجعة أسبوعية مع المشتريات.
   • الدليل الناتج: Register قابل للتسليم يوضح open/closed disputes.
3. Reason Codes & Root Cause (أكواد أسباب النزاع)
   • الغرض العملي: تحويل النزاع من “مشكلة” إلى سبب قابل للقياس (Fروقات PO/Invoice، استلام، ضريبة…).
   • متى يُستخدم: عند تسجيل النزاع وعند مراجعة تكرار الأسباب شهريًا.
   • الدليل الناتج: Root cause report يُستخدم لتحسين ضوابط P2P.
4. PO/Invoice Variance Log (فروقات PO/Invoice)
   • الغرض العملي: توثيق فروقات السعر/الكمية/الضريبة وربطها بالإجراء المطلوب.
   • متى يُستخدم: أثناء حل النزاع وقبل أي اعتماد استثنائي.
   • الدليل الناتج: Variance log + قرار معالجة + owner.
5. CN Tracker (متابعة إشعارات دائن المورد)
   • الغرض العملي: منع “CN ضائع” وضمان ربطه بالنزاع وتطبيقه في النظام.
   • متى يُستخدم: عند طلب CN وحتى إغلاقه (Issued → Received → Posted → Cleared).
   • الدليل الناتج: قائمة CN المفتوحة + أثرها على إغلاق النزاعات.
6. Hold Queue & Actions (فواتير معلقة النزاع)
   • الغرض العملي: فصل الفواتير المعلقة بسبب نزاع عن الفواتير الجاهزة للدفع.
   • متى يُستخدم: يوميًا + قبل Payment run الأسبوعي.
   • الدليل الناتج: Hold list مع أسباب واضحة وETA للإغلاق.
7. Aging & SLA Dashboard
   • الغرض العملي: إبراز النزاعات المتأخرة التي تؤثر على Month‑End أو تسبب تراكم بنود AP.
   • متى يُستخدم: أسبوعيًا + Week‑4/Month‑End.
   • الدليل الناتج: Aging report (0–7/8–14/15–30/31–60/60+ يوم).
8. Month‑End Disputes Pack
   • الغرض العملي: تجميع تسليم الإقفال: النزاعات المفتوحة + CN open + evidence index + sign‑off.
   • متى يُستخدم: Month‑End وYear‑End داخل Closing Pack.
   • الدليل الناتج: Pack قابل للمراجعة يوضح ما تم إغلاقه وما بقي ولماذا.

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

• 01-AP-Dispute-Tracker.xlsx: الملف الرئيسي (Register + Aging + Dashboards + Root Cause).
• 02-Dispute-Intake-Form.docx: Payment/Invoice dispute intake (بيانات إلزامية + مرفقات).
• 03-Reason-Codes-Matrix.xlsx: أكواد أسباب النزاع + تعريف كل سبب + الإجراء القياسي.
• 04-PO-Invoice-Variance-Log.xlsx: فروقات PO/Invoice (price/qty/tax) + قرار + owner.
• 05-CN-Tracker.xlsx: متابعة إشعارات دائن المورد (Issued/Received/Posted/Cleared) + ربط بالنزاع.
• 06-Hold-Queue.xlsx: قائمة فواتير معلقة النزاع + أسباب + تواريخ متابعة + SLA.
• 07-Vendor-Statement-Tieout.xlsx: (اختياري) ربط Vendor statement مع البنود محل النزاع إذا كانت المشكلة على مستوى حساب المورد.
• 08-Weekly-Dispute-Review-Pack.xlsx: Pack أسبوعي (Open/Closed/Overdue + action owners).
• 09-MonthEnd-Disputes-Pack.xlsx: Pack شهر الإقفال داخل Closing Pack (Snapshot + exceptions + evidence + sign‑off).
• 10-Evidence-Index.xlsx: فهرس الأدلة (PO/GRN/Invoice/CN/Correspondence) + روابط/مسارات.
• 11-Runbook.pdf: تشغيل عملي (Hold → Classify → Resolve → CN/Correction → Close → Pack).
• 12-Controls-Checklist.pdf: نقاط رقابة AP/P2P حول النزاعات والـholds قبل Payment run وMonth‑End.
• 13-Archiving-Map.docx: شجرة حفظ (Year/Month/AP/Disputes/Evidence/CNs) + Naming convention.
• 14-Signoff-Page.docx: Prepared/Reviewed/Approved + نطاق الفترة.

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

• نتيجة تشغيلية للفريق: كل فاتورة في نزاع تصبح Case لها Owner وإجراء وموعد، وتخرج قائمة أسبوعية: ما الذي يحتاج CN؟ ما الذي يحتاج تصحيح PO/استلام؟ وما الذي يمكن اعتماده بعد تعديل؟ بدل انتظار “حلّها بالاتصالات”.
• نتيجة رقابية/تدقيقية: لديك Trace لكل نزاع: Invoice/PO/GRN ↔ سبب النزاع ↔ قرار المعالجة ↔ CN/تصحيح ↔ إغلاق، مع Month‑End Disputes Pack وEvidence index قابلين للتسليم ضمن Closing Pack.

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

هل يناسب AP Dispute Tracker أي نظام ERP؟

نعم. تحتاج فقط استخراج AP open invoices/hold list ومراجع PO/GRN/Invoice. tracker يعمل فوق النظام ويُنتج سجل متابعة وتسليم.

هل يصلح للشركات متعددة الفروع؟

نعم إذا كانت البيانات تحتوي Company/Branch/Cost center. يمكن فلترة النزاعات حسب الفرع وإخراج Pack لكل فرع ثم إجمالي.

هل يغطي نزاعات 3‑Way match وGR/IR؟

يغطيها كحالات نزاع (Fروقات PO/Invoice أو استلام/قبول). إذا لديك 3‑Way Match أو GR/IR toolkit، يمكن ربط المراجع بحيث يكون النزاع جزءًا من ملف Reconciliations قبل Month‑End.

ما الحد الأدنى من البيانات لتسجيل نزاع؟

Vendor + Invoice# + Amount + سبب نزاع مبدئي + مرجع (PO أو GRN أو عقد/قبول خدمة) + Owner. بدون هذه العناصر يصبح النزاع “غير قابل للإغلاق”.

هل يتابع إشعارات الدائن (CN) حتى تطبيقها في النظام؟

نعم عبر CN Tracker بحالات (Issued/Received/Posted/Cleared) وربط كل CN بالنزاع/الفاتورة حتى لا يبقى النزاع مفتوحًا بعد صدور CN.

هل يمكن استخدامه قبل Payment Run الأسبوعي؟

نعم: يخرج Hold queue بفواتير معلقة النزاع، ويساعد AP/Treasury على فصل ما يُدفع وما يُعلق وما يُصعد للمشتريات.

هل يصلح لـMonth‑End وYear‑End؟

نعم: Month‑End يركز على تصفية النزاعات المفتوحة وإخراج قائمة نزاعات/أسباب للتسليم، وYear‑End يركز على النزاعات القديمة وملف أدلة أقوى للمراجعة.

هل يوجد قالب تسليم للمراجع الداخلي؟

نعم: Month‑End Disputes Pack + Evidence index + Sign‑off يوضح النزاعات المفتوحة والمغلقة وأسباب الاستمرار.

هل يُنتج قيود (JE Log) تلقائيًا؟

لا يرحّل قيودًا. لكنه يحدد أين النزاع يؤثر على الإقفال (مثل فواتير معلقة قد تؤثر على cut‑off) ويمكن ربطه يدويًا مع JE Log ضمن Closing Pack حسب سياسة شركتك.

جاهز تحوّل فواتير معلقة النزاع إلى Cases قابلة للإغلاق قبل Month‑End؟

المخرجات: AP Dispute Tracker + Aging + Variance log + CN follow‑up + Month‑End pack.