Value Proposition: سياسة ائتمان العملاء ليست ملف “سياسات” للعرض؛ هي آلية تشغيل تمنع سيناريو شائع: مبيعات مستمرة لعميل Overdue أو متجاوز الحد، ثم تظهر المشكلة في AR Aging وDSO وبعدها تبدأ التسويات (Credit notes/Write‑off) تحت ضغط الإقفال. هذه الحزمة تربط بين حدود ائتمان العملاء وشروط السداد للعملاء وقرار إيقاف البيع عند تجاوز الحد عبر سجل واحد + Workflow موافقات + أدلة (Traceability) من الطلب حتى التحصيل.

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

• Credit Limit Template: سجل حدود ائتمان العملاء (Limit/Utilization/Available) مع تاريخ سريان ومراجعة.
• Policy مختصر: سياسة الائتمان والتحصيل (من يعتمد؟ متى نوقف البيع؟ متى نرفع الحد؟).
• تقييم مخاطر العملاء: Risk scoring مبني على AR aging/payment behavior/Concentration.
• شروط السداد للعملاء: قاموس Terms موحد (Net 30/45/60…) وربطه بالتصنيف والمخاطر.
• Overlimit Monitoring: قائمة “متجاوز الحد” + “متأخر” + “High risk” مع Owner وإجراء.
• Credit Hold/Stop‑Sell: نموذج قرار إيقاف البيع عند تجاوز الحد + سجل رفع/إزالة الحظر.
• Override Workflow: نموذج استثناء (تجاوز حد/تمديد Terms) مع موافقات وتعليل وأثر على التعرض.

CTA مرتبط بالمخرجات: تستلم Credit Limit Register + Risk Scoring + Overlimit/Hold Logs + Override Approvals جاهزين للتطبيق.

مناسبة لـ

• AR / Credit Control: تشغيل التحصيل والائتمان كقائمة عمل (Limits/Overdue/Actions) بدل متابعة غير موثقة.
• Controller / Chief Accountant: ضبط التعرض الائتماني قبل الإقفال وربط الاستثناءات بموافقات وأثر على AR.
• Sales Ops / Commercial Finance: توحيد قرار “بيع/لا بيع” على أساس قواعد واضحة بدل تفاوض لحظي.

غير مناسبة لـ

• من يريد نظام Credit management آلي داخل ERP يوقف الطلبات تلقائيًا — المنتج يقدم الإطار والسجلات، والتطبيق داخل نظامك.
• من لا يملك بيانات AR Aging أو تاريخ سداد/تعرض — الحد الأدنى من البيانات ضروري ليكون تقييم المخاطر واقعيًا.

بدون سياسة/سجل ائتمان / مع سياسة/سجل ائتمان (مقارنة قصيرة)

قبل الاستخدام: 5 أعراض أن الائتمان يُدار برد فعل

• عميل متأخر ويستمر البيع له لأن “لا أحد يملك قرار الإيقاف”.
• شروط السداد تتغير حسب الصفقة (Net 30/60/90) بدون موافقات أو مبرر مكتوب.
• لا توجد صورة واضحة للتعرض (Exposure) مقابل الحد لكل عميل، فتظهر مفاجآت في Overdue AR.
• تجاوزات الحد تتم عبر مكالمات/رسائل ولا يوجد Override log يمكن مراجعته.
• في الإقفال تُفتح نقاشات “هل هذا العميل High risk؟” بدون Risk scoring أو تاريخ مراجعة.

كيف تُطبّق سياسة ائتمان العملاء عمليًا من فتح العميل حتى التحصيل؟

المنهج هنا تشغيلي: تبدأ ببيانات العميل وماضي السداد (إن وُجد)، ثم تحدد حد ائتمان وشروط سداد مع تصنيف مخاطر، وبعد التشغيل تتابع الاستخدام (Utilization) والتأخر (Overdue). أي تجاوز للحد أو تمديد Terms لا يتم “بالشفهي”؛ يتم عبر Override request بموافقة، ويُسجل في ملفات الإقفال كأثر على التعرض والمخاطر.

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

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

• تجميع Customer master (الأكواد/الكيان/المجموعة/الفرع) وربطها بقائمة AR open items/AR aging.
• تحديد قاموس شروط السداد للعملاء المعتمدة (قيم قياسية) ومن يملك حق تغييرها.
• تحديد قواعد التعرض: هل الحد على مستوى “عميل” أم “مجموعة/شركة قابضة”؟ وهل يشمل “طلبات غير مفوترة”؟

الخطوة 2: تقييم المخاطر + تحديد الحد + مسار الموافقات

• تشغيل تقييم مخاطر العملاء: عوامل مثل (Days overdue history / Concentration / Disputes / Payment behavior) وإخراج Risk tier.
• تسجيل حدود ائتمان العملاء في Credit Limit Template مع تاريخ السريان، سبب الحد، وموعد المراجعة.
• تفعيل مسار الاستثناءات: Override request (تجاوز حد/تمديد Terms) + موافقات + تعليل + مدة الاستثناء.

الخطوة 3: تشغيل المتابعة + Credit Hold + ملف الإقفال

• متابعة أسبوعية: قائمة “Overlimit / Overdue / High risk” مع Owner وإجراء (تحصيل/تجميد/تصعيد).
• تطبيق إيقاف البيع عند تجاوز الحد كقرار تشغيلي: فتح Hold + إغلاق Hold بقرار موثق عند التحصيل/التسوية.
• Month‑End: إخراج Snapshot للتعرض والمخاطر + سجل الاستثناءات والموافقات + أي مذكرات عن Customers high risk لدعم قرارات المخصص/الإيقاف.

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

1. Credit Policy (سياسة ائتمان وتحصيل)
   • الغرض العملي: تعريف قواعد الائتمان: من يعتمد الحد؟ متى نوقف البيع؟ متى نرفع الحد؟ ومتى نراجع العملاء؟
   • متى يُستخدم: عند اعتماد التشغيل/الحوكمة ثم يُرجع إليه عند أي استثناء.
   • الدليل الناتج: Policy document معتمد يمكن الرجوع له في المراجعة.
2. Credit Limit Register (Credit Limit Template)
   • الغرض العملي: سجل حدود الائتمان لكل عميل/مجموعة: Limit، Utilization، Available، Review date.
   • متى يُستخدم: عند فتح عميل جديد + مراجعات دورية.
   • الدليل الناتج: سجل حدود مع تاريخ سريان وملاحظات واعتمادات.
3. Risk Scoring Matrix (تقييم مخاطر العملاء)
   • الغرض العملي: تحويل “الإحساس بالمخاطر” إلى درجة/تصنيف (Low/Medium/High) مع عوامل واضحة.
   • متى يُستخدم: عند التأسيس + مراجعة شهرية/ربع سنوية أو عند تغير سلوك السداد.
   • الدليل الناتج: Risk score لكل عميل + تفسير مختصر (Drivers) قابل للحفظ.
4. Terms Dictionary & Rules (شروط السداد للعملاء)
   • الغرض العملي: توحيد Terms ومنع إدخال حر + ربط terms بالمخاطر وبسياسة التحصيل.
   • متى يُستخدم: عند فتح/تعديل عميل وعند مراجعة الاستثناءات.
   • الدليل الناتج: سجل Terms معتمد + سجل تغيير Terms (إن وُجد).
5. Exposure & Overlimit Monitoring
   • الغرض العملي: كشف العملاء المتجاوزين حد الائتمان أو المعرضين للتجاوز خلال فترة قصيرة.
   • متى يُستخدم: أسبوعيًا (أو يوميًا في بيئات حركة عالية).
   • الدليل الناتج: Overlimit list + تاريخ ظهور الحالة + Owner + إجراء.
6. Stop‑Sell / Credit Hold Workflow (إيقاف البيع عند تجاوز الحد)
   • الغرض العملي: نموذج قرار Hold: من طلب؟ لماذا؟ ما المعيار؟ ومتى يُرفع الحظر؟
   • متى يُستخدم: عند تجاوز الحد/تكرار التأخر أو نزاعات غير مغلقة.
   • الدليل الناتج: Hold log يثبت تطبيق الضابط وعدم تركه “مزاجي”.
7. Override Request & Approval (استثناءات الائتمان)
   • الغرض العملي: توثيق تجاوز حد/تمديد شروط سداد مع موافقة وتعليل ومدة الاستثناء.
   • متى يُستخدم: عند أي استثناء تجاري/تشغيلي يحتاج تجاوز السياسة.
   • الدليل الناتج: Override approvals log + أثر الاستثناء على التعرض.
8. Periodic Review Pack + Sign‑off
   • الغرض العملي: مراجعة دورية: تحديث حدود/مخاطر/Terms وتوقيع مسؤولين (Credit/Controller).
   • متى يُستخدم: شهريًا أو ربع سنويًا + قبل الإقفال السنوي.
   • الدليل الناتج: Review snapshot + توقيعات + قرارات قابلة للتتبع.
9. Evidence Index & Archiving Map
   • الغرض العملي: فهرسة الأدلة الداعمة (AR aging exports، مراسلات اعتماد، مذكرات نزاع) وربطها بالسجلات.
   • متى يُستخدم: مع كل مراجعة أو استثناء + ضمن ملف الإقفال.
   • الدليل الناتج: Evidence index جاهز للتسليم يقلل طلبات “هات الموافقة/القرار”.

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

• 01-Customer-Credit-Policy.docx: سياسة ائتمان العملاء + تعريف الصلاحيات (Approvals) وقواعد الإيقاف/الاستثناء.
• 02-Credit-Limit-Template.xlsx: Credit Limit register (Limit/Utilization/Available/Review date) + حقول اعتماد.
• 03-Risk-Scoring-Matrix.xlsx: تقييم مخاطر العملاء + عوامل/أوزان + Risk tier output.
• 04-Payment-Terms-Dictionary.xlsx: شروط السداد للعملاء (قاموس Terms) + قواعد تطبيق/استثناء.
• 05-Exposure-Overlimit-Dashboard.xlsx: لوحة متابعة التعرض + قائمة Overlimit/High risk.
• 06-Credit-Hold-StopSell-Log.xlsx: سجل إيقاف البيع (Hold/Release) + سبب + تاريخ + من اعتمد.
• 07-Override-Request-Approval-Form.docx: نموذج استثناء (زيادة حد/تمديد Terms) + تعليل + مدة + توقيع.
• 08-Override-Approvals-Log.xlsx: سجل موافقات الاستثناءات + أثر على التعرض + انتهاء الاستثناء.
• 09-Periodic-Review-Calendar.xlsx: تقويم مراجعات الائتمان (Monthly/Quarterly) + مسؤوليات.
• 10-Review-Signoff-Pack.docx: صفحة توقيع مراجعة الائتمان + قرارات التعديل + ملخص المخاطر.
• 11-Evidence-Index.xlsx: فهرس أدلة (Exports/Approvals/Disputes) + روابط/مسارات.
• 12-Runbook.pdf: تشغيل عملي (Onboarding → Monitoring → Hold/Override → Month‑End pack).
• 13-Archiving-Map.docx: شجرة حفظ (Year/Month/Credit/Overrides/Holds/Evidence) + Naming convention.

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

• نتيجة تشغيلية للفريق: يصبح لديك “حالة” لكل عميل: Limit/Utilization + Overdue + Next action، وأي تجاوز يُدار كاستثناء بموافقة أو يتحول إلى Credit hold بسجل رفع/إزالة.
• نتيجة رقابية/تدقيقية: يمكن تتبع قرارات الائتمان: Policy → Risk score → Limit/Terms → Overlimit/Hold → Override approvals → Review sign‑off، بدل قرارات شفوية تظهر كملاحظة ضعف ضوابط.

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

هل تناسب الحزمة أي نظام ERP؟

نعم. لأن الحزمة تعمل فوق النظام عبر Exports (AR Aging/Open items/Sales exposure) وتنتج سجلات وقرارات. تطبيق Hold داخل ERP يتم حسب صلاحياتك وإعداداتك.

هل تصلح لشركات متعددة الفروع أو المجموعات (Group credit limit)؟

نعم. يمكنك تعريف الحد على مستوى Customer أو على مستوى Group/Parent وربط الفروع تحته، مع تقارير Exposure مجمّعة.

هل تشمل شروط السداد للعملاء وتغييرها؟

نعم: قاموس Terms موحد + قواعد تغيير Terms، ويمكن تشغيل Workflow استثناء لتمديد شروط السداد عند الحاجة مع موافقة.

هل “إيقاف البيع عند تجاوز الحد” يتم تلقائيًا؟

المنتج يوفر القواعد ونماذج القرار والسجل. الإيقاف التلقائي يعتمد على إمكانيات ERP لديك. حتى لو لم يكن تلقائيًا، وجود Hold log وOverlimit list يجعل التطبيق التشغيلي قابل للتتبع.

كيف يتم تقييم مخاطر العملاء داخل النموذج؟

عبر Risk scoring يعتمد على عوامل قابلة للتخصيص مثل (Days overdue، سلوك السداد، نزاعات مفتوحة، تركّز المبيعات/التعرض). الهدف إنتاج Risk tier يمكن اتخاذ قرار بناء عليه.

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

Customer master + AR aging/open items + شروط سداد حالية + تعرض مبيعات (فواتير مفتوحة/طلبات إن كانت متاحة). بدون هذه المدخلات سيصبح الحد تقديريًا أكثر من اللازم.

هل يمكن ربطها مع نموذج AR Aging وخطة التحصيل؟

نعم. عمليًا: الـOverdue وDSO ونتائج التحصيل تغذي قرار تعديل الحد/الإيقاف، وملف الائتمان يعطي التحصيل “قواعد تصعيد” واضحة.

هل يوجد نموذج للاستثناءات (Override)؟

نعم: Override request form + approvals log يثبت من وافق ولماذا ومدة الاستثناء، ويُظهر أثره على التعرض.

هل تصلح لـB2C مثل B2B؟

الأكثر شيوعًا استخدامها في B2B (Limits/Terms/Collections). في B2C يمكن استخدامها لو لديك حسابات مدينة أو بيع آجل (أو نقاط بيع تمنح ائتمان).

جاهز توحّد قرار الائتمان وتطلع ملف موافقات قابل للمراجعة؟

المخرجات: Credit Limit Template + Risk Scoring + Overlimit/Hold + Override Approvals + Review Sign‑off.