في أي مؤسسة صغيرة ومتوسطة تدفع لمورّديها بالتحويل، الخطر رقم 1 ليس عدم الدفع — بل الدفع المزدوج. من بين 100 نهاية شهر دُقّقت في 2025، كانت 38% من المؤسسات الصغيرة والمتوسطة قد أرسلت على الأقل تحويلاً مزدوجًا لمورّد، بسبب غياب نظام مركزي للمتابعة. مؤشّر «تمّت المعالجة» الجديد في المورد يقضي على هذه المنطقة الرمادية بنقرة واحدة.
مشكلة الدفع المزدوج
السبب دائمًا هو نفسه: ثلاثة أشخاص مختلفون (المحاسب، المالك، المسيّر) ينظرون إلى نفس قائمة الديون، أحدهم يقوم بالتحويل، والآخر يُعيده بعد يومين لأنه «لا يتذكّر إن كان قد تمّ بالفعل».
حالتان مستقلّتان لكل التزام
كل التزام مورّد في المورد له الآن حالتان:
-
الحالة المحاسبية — تلقائية، مبنية على مجموع
الدفعات المرتبطة:
- «للإنجاز» ← لا توجد أي دفعة.
- «جزئي» ← دفعات جزئية.
- «مُسدَّد» ← الدفعات ≥ المبلغ المستحق.
- «مُلغى» ← التزام مُلغى يدويًا.
-
مؤشّر المعالجة — زرّ يدوي ✓ ينقره المستخدم
عندما يكون التحويل البنكي قد انطلق فعلاً:
- غير مؤشّر ← يظهر في تصدير التحويلات CSV.
- مؤشّر ← مُستبعَد من التصدير، السطر مُعتّم، وسم أخضر «تمّت المعالجة».
لماذا حالتان؟ الحالة المحاسبية تتعلق بإدخال الدفعات في المورد، وهو ما قد يستغرق عدة أيام بعد التحويل الفعلي. أمّا مؤشّر المعالجة فيقول ببساطة: «لقد نقرت إرسال في أداة البنك لهذا الالتزام». هذا يكفي لإزالته من قائمة التحويلات الواجب إنجازها، دون انتظار تأكيد التحويل وإدخال الدفعة.
المسار المُوصى به في 4 خطوات
- الخطوة 1: إنشاء الالتزام بمجرد معرفته. بمجرد استلام فاتورة مورّد (أو معرفة اشتراك قادم)، يُنشأ الالتزام في المورد ← حسابات الموردين ← المورّد ← التزام جديد. الحقول الدنيا: التاريخ، البيان، المبلغ، رقم BL إن وُجد.
- الخطوة 2: التصدير إلى CSV في نهاية الفترة. حين يحين وقت الدفع (عادةً نهاية الشهر)، انقر تصدير التحويلات (CSV) من صفحة حسابات الموردين. الملف يحتوي فقط الالتزامات الواجب إنجازها وغير المعالَجة.
- الخطوة 3: تنفيذ التحويلات في البنك. استورد ملف CSV في أداة البنك الإلكترونية (BNA، BEA، CPA، CCP).
- الخطوة 4: تأشير كل التزام كـ«تمّت معالجته». العودة إلى المورد ← حسابات الموردين ← المورّد. على كل سطر التزام مُحوَّل، انقر الزرّ الأخضر ✓.
الأثر الفوري للنقرة
- يصبح السطر رماديًا + مُعتّمًا في الجدول.
- يتحوّل الوسم إلى «تمّت المعالجة» (أخضر).
- في التصدير التالي إلى CSV، لن يظهر هذا الالتزام من جديد.
- يُسجَّل التاريخ والمستخدم اللذان أشّرا للتدقيق.
الزرّ قابل للتراجع
إذا أشّر مستخدم بالخطأ (أو إذا رُفض التحويل من البنك)، يكفي نقر الزرّ الذي أصبح سهمًا رماديًا ↻ لـ إلغاء التأشير. يستعيد السطر لونه العادي، ويعود الوسم إلى «للإنجاز»، ويظهر الالتزام من جديد في التصدير التالي.
التتبّع للتدقيق
كل تأشير يخزّن:
done_at— طابع زمني دقيق (datetime).done_by— المستخدم الذي نقر.
حالة نمطية: «لماذا لا يظهر هذا التحويل إلى Saudia في قائمة الواجب تنفيذها بتاريخ 30؟» ← الجواب في ثانيتين: «لأن Karim أشّره كمُعالَج يوم 28 على الساعة 14h32». ملائم للتدقيق وللنزاعات.
نصيحة عملية: عضو مخصّص للتأشير
في مؤسسة صغيرة ومتوسطة، يأتي الدفع المزدوج غالبًا من كون لا أحد مكلّف رسميًا بالتأشير. أفضل ممارسة:
- المالك (أو المحاسب الرئيسي) مسؤول عن النقر ✓.
- المستخدمون الآخرون يُنشئون الالتزامات وينفّذون التحويلات، لكنهم لا يلمسون زرّ ✓.
- مرة في الأسبوع، تدقيق سريع: تُراجَع قائمة «للإنجاز». إن كانت هناك ازدواجيات محتملة، تُكتشف قبل التصدير التالي.
طُبّق على 8 مؤسسات نموذجية: 0 دفع مزدوج مُكتشَف خلال الأشهر الأربعة الأخيرة.
الدمج مع تصدير CSV
التصدير والمؤشّر يعملان جنبًا إلى جنب:
- التصدير دون تأشير — نرى ما يجب دفعه (معاينة، محاكاة).
- التأشير بعد التصدير — نؤكّد ما حوّلناه فعلاً.
- التصدير بعد التأشير — نرى فقط ما تبقّى للإنجاز (الفارق).
هذه الحلقة، السلسة في بضع نقرات، تقضي على المنطقة الرمادية «هل تمّ ذلك أم لا؟» التي تسبّب أكبر عدد من الدفعات المزدوجة.
مكافأة لوكالات السفر SafarPro: نفس الآلية تنطبق على دفعات ONPO، Saudia، FlyNas والفنادق. لا خيار يجب تفعيله — يظهر الزرّ ✓ تلقائيًا على كل التزام مورّد، سواء كنّا في وضع Core (مؤسسة) أو SafarPro (وكالة سفر).