تكامل نظام تحصيل الديون مع Microsoft Dynamics عبر API

شركتك تدير المبيعات والعملاء والفواتير داخل Microsoft Dynamics، لكن ملفات المديونية المتأخرة تخرج من النظام على هيئة تقارير Excel يعيد فريق التحصيل إدخالها يدوياً في أداة منفصلة. النتيجة: إدخال مزدوج، أرقام لا تتطابق بين المالية والتحصيل، ومدين يُتابَع بعد أن سدّد فعلاً. السؤال العملي ليس «هل نستبدل Dynamics؟» بل «كيف نجعل نظام التحصيل يتصل به تلقائياً؟» وهنا يأتي دور تكامل نظام التحصيل مع Dynamics عبر واجهات API.

قبل الدخول في التفاصيل، تنبيه مهم لتفادي سوء الفهم: لا يوجد «موصل جاهز» بضغطة زر يربط أي نظام تحصيل بأي نسخة من Dynamics تلقائياً. Microsoft Dynamics عائلة منتجات (Business Central، Finance & Operations، Dynamics 365 Sales/CRM) لكل منها بنية بيانات مختلفة. لذلك نتحدث هنا عن إطار تكامل عبر API: منهجية عامة يتصل بها نظام التحصيل بمنصة Dynamics باعتبارها فئة من أنظمة ERP/CRM المؤسسية، بتخصيص يناسب نسختك.

أين تقع بيانات المديونية داخل Dynamics؟

قبل بناء أي ربط، يجب أن تعرف من أين تأتي البيانات. في منظومة Dynamics تتوزع بيانات المديونية عادةً على أكثر من كيان (Entity)، وفهم هذا التوزيع هو أساس أي تكامل ناجح:

• حساب العميل (Customer / Account): الاسم التجاري، الرقم الضريبي، بيانات التواصل، وحد الائتمان الممنوح.
• الفواتير (Sales Invoices / Posted Invoices): رقم الفاتورة، تاريخ الإصدار، تاريخ الاستحقاق، والقيمة الإجمالية.
• الأرصدة المفتوحة (Customer Ledger Entries): المبالغ غير المسددة والمبالغ المتبقية بعد أي سداد جزئي.
• المدفوعات المسجّلة (Payments): ما تم تحصيله فعلاً وربطه بالفواتير.

الخطأ الشائع هو محاولة سحب «كل شيء». التكامل الفعّال يختار فقط الحقول التي يحتاجها فريق التحصيل، ويترك بقية بيانات المحاسبة داخل Dynamics حيث موضعها الطبيعي. تحديد هذه الحقول بدقة هو ما تعالجه ميزة التكاملات عبر API في CollectPro عند إعداد أي ربط.

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

ما الذي ينتقل إلى نظام التحصيل؟

ليس كل ما في Dynamics ذا صلة بالتحصيل. الهدف هو نقل «ملف المديونية» فقط: العميل الذي عليه رصيد متأخر، مع تفاصيل الفواتير التي تسبّبت في هذا التأخر. عملياً ينتقل ما يلي في الاتجاه من Dynamics إلى نظام التحصيل:

• بيانات العميل الأساسية لإنشاء ملف المدين أو تحديثه دون إدخال يدوي.
• الفواتير المتأخرة عن تاريخ استحقاقها مع أعمارها (Aging) لتحديد الأولوية.
• إجمالي الرصيد المستحق لكل عميل، لا مجرد قيمة فاتورة واحدة.
• أي مرجع أو رقم أمر بيع يساعد فريق التحصيل على الاستناد إلى مستند واضح أثناء التواصل.

بمجرد وصول هذه البيانات، يبدأ عمل نظام التحصيل الحقيقي: توزيع الحالات على المحصّلين، جدولة التذكيرات، وتسجيل وعود السداد. هذه المرحلة هي ما يفصل بين مجرد «عرض أرقام» و«إدارة عملية تحصيل»، ويمكنك الاطلاع على تفاصيلها في ميزة توزيع الحالات.

كيف تعمل واجهات API في الربط؟

واجهة API هي «لغة مشتركة» تسمح لنظامين مختلفين بتبادل البيانات دون أن يفتح أحدهما قاعدة بيانات الآخر مباشرة. Dynamics يوفّر واجهات قياسية (مثل OData وWeb API) تُخرج الكيانات على هيئة بيانات منظّمة، ونظام التحصيل يستهلك هذه البيانات ويحوّلها إلى ملفات مدينين. توجد ثلاث طرق شائعة لإدارة هذا التبادل:

1. السحب المجدول (Scheduled Pull)

يستعلم نظام التحصيل من Dynamics على فترات منتظمة (كل ليلة مثلاً) عن الفواتير المتأخرة الجديدة. مناسب لأغلب الشركات لأن التحصيل لا يتطلب لحظية بالثواني.

2. الدفع الفوري عبر Webhooks

يرسل Dynamics إشعاراً فورياً إلى نظام التحصيل عند وقوع حدث معيّن (تجاوز فاتورة لاستحقاقها). يناسب من يريد تحديثاً لحظياً دون انتظار الدورة الليلية.

3. المزامنة الوسيطة (Middleware)

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

النمط	التحديث	الأنسب لـ
سحب مجدول	دوري (ليلي)	معظم شركات التحصيل الداخلي
Webhooks	فوري	الحاجة لمتابعة لحظية للتعثر
Middleware	مرن	قواعد عمل معقّدة أو مصادر متعددة

مزامنة حالة السداد في الاتجاه المعاكس

التكامل الناجح ليس اتجاهاً واحداً. أخطر مشكلة في التحصيل اليدوي أن العميل يسدّد داخل Dynamics بينما يستمر فريق التحصيل في ملاحقته لأن نظامه لا يعلم بالسداد. لذلك يجب أن يتدفق «حدث السداد» في الاتجاه المعاكس أيضاً:

• عندما تُسجَّل دفعة في Dynamics، ينعكس ذلك على ملف المدين في نظام التحصيل فيُغلق أو يُحدَّث رصيده.
• عندما يوثّق المحصّل وعد سداد أو تسوية، يمكن أن ينعكس ذلك كملاحظة أو حقل مرجعي في Dynamics ليراه الفريق المالي.

هذا التزامن ثنائي الاتجاه هو ما يمنع «المطاردة بعد السداد» ويحافظ على تطابق الأرقام بين المالية والتحصيل. إدارة وعود السداد والتسويات ضمن هذه الدورة موضّحة في ميزة وعود السداد، وهي جزء أساسي من قيمة الربط.

سيناريو تبادل واقعي خطوة بخطوة

لنجعل الصورة ملموسة عبر رحلة فاتورة واحدة داخل بيئة مترابطة:

• يصدر قسم المبيعات فاتورة لعميل داخل Dynamics بتاريخ استحقاق محدّد.
• عند تجاوز التاريخ دون سداد، يلتقط نظام التحصيل الفاتورة عبر API ويُنشئ ملف مدين تلقائياً بكامل بياناته.
• يوزّع النظام الحالة على المحصّل المناسب، فيبدأ التواصل عبر القنوات المعتمدة (مكالمة، رسالة، بريد) ويسجّل وعد سداد بتاريخ محدّد.
• يسدّد العميل، فتُسجَّل الدفعة في Dynamics، ويُحدَّث رصيد المدين في نظام التحصيل تلقائياً فيُغلق الملف.

لا إدخال مزدوج، ولا تقارير Excel تُنقل يدوياً، ولا مطاردة بعد السداد. الفريق المالي يبقى في Dynamics، وفريق التحصيل يعمل في أداته المتخصصة، والبيانات تتحرك بينهما بصمت. هذا هو جوهر ما تحققه ميزة التكاملات عبر API في CollectPro حين تُربط بمنظومة ERP قائمة.

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

خطوات عملية قبل بدء التكامل

لتفادي مشروع ربط يتعثّر، جهّز هذه النقاط قبل كتابة أي سطر تكامل:

• حدّد نسخة Dynamics بدقة (Business Central أم Finance & Operations أم Dynamics 365 Sales) لأن بنية الكيانات وواجهات API تختلف بينها.
• اتفق على «تعريف التأخر» — بعد كم يوم من الاستحقاق تنتقل الفاتورة إلى التحصيل؟ هذا القرار يحدد الفلترة.
• عيّن مفتاح ربط فريد (رقم العميل أو الرقم الضريبي) لضمان عدم تكرار ملفات المدينين عند المزامنة.
• حدّد صلاحيات الوصول عبر حساب خدمة (Service Account) بأقل صلاحية لازمة، ضمن ضوابط الأمان مثل RBAC وسجل العمليات.
• ابدأ بمجموعة تجريبية صغيرة من العملاء قبل ربط قاعدة البيانات كاملة، للتحقق من تطابق الأرقام.

البدء بنطاق محدود ثم التوسّع التدريجي يقلّل المخاطر ويجعل تصحيح الفروقات أسهل. وإن كنت تقارن بين ربط نظام مخصّص أو الاكتفاء بوحدات Dynamics نفسها، فراجع نظام تحصيل أم ERP؟ لفهم أين ينتهي دور ERP ويبدأ دور نظام التحصيل المتخصص.

أخيراً، خصّص آلية لمعالجة الأخطاء منذ اليوم الأول. ماذا يحدث إن كان عنوان بريد العميل مفقوداً في Dynamics، أو تعذّر الوصول إلى الواجهة لدقائق؟ التكامل الجيد يسجّل هذه الحالات في سجل واضح بدل أن يتجاهلها بصمت، ليعرف المسؤول أي الملفات لم تُزامَن ولماذا. هذه التفاصيل التشغيلية هي ما يفصل بين ربط يعمل في العرض التقديمي وربط يصمد في الاستخدام اليومي على قاعدة بيانات حقيقية.

الأسئلة الشائعة

هل يوجد موصل جاهز يربط CollectPro بـ Microsoft Dynamics تلقائياً؟

لا نتحدث عن موصل جاهز بضغطة زر. الربط يتم عبر واجهات API كإطار عام يتكيّف مع نسختك من Dynamics وبنية بياناتك، لأن منتجات Dynamics تختلف في كياناتها وواجهاتها.

ما البيانات التي تنتقل من Dynamics إلى نظام التحصيل؟

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

هل ينعكس السداد المسجّل في Dynamics على نظام التحصيل؟

نعم، هذا جوهر التكامل ثنائي الاتجاه. عند تسجيل دفعة في Dynamics ينعكس ذلك على ملف المدين فيُحدَّث رصيده أو يُغلق، ما يمنع ملاحقة عميل سدّد فعلاً.

هل يتطلب التكامل تحديثاً لحظياً بالثواني؟

ليس بالضرورة. أغلب شركات التحصيل تكتفي بمزامنة مجدولة (ليلية مثلاً)، بينما تناسب Webhooks من يحتاج التقاط التعثر لحظياً. الاختيار يعتمد على وتيرة عملك.

كيف نتجنب تكرار ملفات المدينين عند المزامنة؟

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

من أين نبدأ مشروع الربط عملياً؟

ابدأ بتحديد نسخة Dynamics وتعريف «التأخر» ومفتاح الربط، ثم اربط مجموعة تجريبية صغيرة للتحقق من تطابق الأرقام قبل التوسّع إلى القاعدة كاملة.

إخلاء: هذا المحتوى لأغراض معرفية لمساعدتك على فهم إطار التكامل، وتفاصيل التنفيذ الفعلية تعتمد على نسختك من Microsoft Dynamics وبنية بياناتك.