المدفوعات

المدفوعات الإلكترونية والمحافظ في اليمن: كيف تربطها بنظام ERPNext؟

تحصّل الشركات في اليمن أموالها عادة عبر خليط من النقد والمحافظ الإلكترونية والتحويلات البنكية وشركات الصرافة، ويستطيع ERPNext استيعاب هذا الخليط كله: كل قناة تُعرَّف كطريقة دفع (Mode of Payment) بحسابها الخاص ورقمها المرجعي، ثم تُطابَق الحركات مع كشوف البنك أو المحفظة. وعندما يوفّر مزوّد الدفع واجهة برمجية يمكن ربطه مباشرة بتطبيق Frappe. هذا دليل عملي لتنظيم التحصيل الإلكتروني داخل ERPNext دون وعود لا يدعمها الواقع.

واقع التحصيل لدى الشركات في اليمن

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

الهدف من نظام ERP هنا بسيط: أن يكون لكل قناة حساب واضح، ولكل دفعة رقم مرجعي يمكن تتبعه، وأن تُطابَق الدفاتر مع الكشوف بانتظام. ما يلي هو الطريقة التي نهيّئ بها ذلك في يمن فرابي.

تعريف القنوات كطرق دفع بحسابات مستقلة

تبدأ التهيئة بإنشاء Mode of Payment لكل قناة، وربطها بحساب في دليل الحسابات:

• نقد الصندوق: حساب نقدية لكل فرع أو لكل صندوق، بحيث يُعرف رصيد كل كاشير.
• محفظة إلكترونية: حساب مستقل لكل محفظة تملكها الشركة، يُعامَل كحساب بنكي له كشف.
• تحويل بنكي: حساب لكل حساب بنكي للشركة، مع إلزام رقم المرجع وتاريخه في قيد الدفع.
• حوالة صرافة: حساب وسيط حتى تُستلم الحوالة فعلاً، ثم تحويل إلى الصندوق أو البنك.
• حقل رقم العملية: حقل مخصص إلزامي عند اختيار المحفظة أو الحوالة لمنع تسجيل الدفعة نفسها مرتين.

مثال عملي: عميل يرسل صورة إشعار تحويل من محفظة. يسجل المحاسب Payment Entry على الفاتورة بطريقة الدفع الخاصة بالمحفظة ويُدخل رقم العملية. النتيجة: تنخفض مديونية العميل فوراً، ويرتفع رصيد حساب المحفظة في الدفاتر، ويصبح رقم العملية هو مفتاح المطابقة لاحقاً.

استيراد الكشوف والمطابقة التلقائية في الإصدار 16

تسجيل الدفعات وحده لا يكفي؛ يجب التحقق أن المال وصل. في ERPNext تُستورد كشوف البنك أو المحفظة من ملف Excel أو CSV عبر استيراد كشف البنك، فيتحول كل سطر إلى حركة بنكية (Bank Transaction). ثم تُطابَق الحركات مع قيود الدفع في Bank Reconciliation Tool.

يضيف الإصدار 16 Bank Transaction Rule: قواعد تحدد كيف تُطابَق الحركات المتكررة تلقائياً بناءً على الوصف أو المبلغ أو الطرف. مثال: شركة تستلم يومياً عشرات التحويلات الصغيرة على محفظتها. بعد استيراد الكشف تطابق القواعد الحركات التي يحمل وصفها رقم العملية المسجل في قيود الدفع، ويراجع المحاسب الباقي يدوياً. النتيجة: تتحول المطابقة من عمل يوم كامل في نهاية الشهر إلى مراجعة قصيرة للاستثناءات. ومنذ إصدار نهاية سبتمبر 2026 يمكن لتطبيقات التكامل إضافة أنواع مستندات خاصة بها إلى أداة المطابقة، وهو ما يفيد عند وجود تطبيق ربط مع مزوّد دفع.

تعدد العملات وفروق الصرف

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

ويضيف الإصدار 16 العملات المربوطة (Pegged Currencies) للعملات المرتبطة بغيرها بسعر ثابت. ومع اختلاف أسعار الصرف بين المناطق في اليمن، ننصح بتحديد مصدر سعر الصرف الذي تعتمده الشركة داخلياً ومن يملك صلاحية تعديله في جدول Currency Exchange.

نقاط البيع بأكثر من طريقة دفع

في المتجر أو المطعم يدفع العميل أحياناً جزءاً نقداً والباقي من محفظته. يسمح ملف نقطة البيع في ERPNext بتحديد طرق الدفع المسموحة لكل فرع، ويمكن تقسيم الفاتورة الواحدة بينها. مثال: فاتورة يدفع العميل نصفها نقداً ونصفها تحويلاً من محفظة. عند إقفال الوردية يظهر في قيد الإقفال مجموع كل طريقة على حدة. النتيجة: يسلّم الكاشير النقد فقط، ويُطابَق جزء المحفظة مع كشفها، ولا يختلط الاثنان. التفاصيل في صفحة نظام نقاط البيع.

الربط البرمجي مع مزوّد الدفع عندما يتوفر

بعض مزوّدي الدفع في اليمن يوفّرون واجهة برمجية للتجار، وبعضهم لا يوفّرها. عند توفرها يمكن بناء تطبيق Frappe يرسل للعميل طلب دفع، ويستقبل تأكيد العملية، وينشئ قيد الدفع تلقائياً برقم العملية، بالطريقة نفسها الموضحة في مقال ربط بوابات الدفع مع ERPNext. وقد بنت يمن فرابي تطبيق تكامل من هذا النوع على Frappe مع أحد مزوّدي الدفع.

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

الضوابط: الموافقات والمطابقة اليومية

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