المدفوعات

ربط بوابات الدفع الإلكتروني مع ERPNext: كيف تستلم المدفوعات داخل النظام؟

تستلم ERPNext المدفوعات الإلكترونية عبر سلسلة واضحة: طلب دفع (Payment Request) يحمل رابط دفع يُرسَل للعميل، وحساب بوابة دفع (Payment Gateway Account) يربط البوابة بحساب الذمم والعملة، ثم قيد دفع (Payment Entry) يُنشأ تلقائياً عند تأكيد الدفعة فتنخفض المديونية على الفاتورة ويُرحَّل القيد المحاسبي. البوابات نفسها تأتي من تطبيق Payments مفتوح المصدر أو من تطبيق Frappe مخصص يتصل بواجهة مزوّد الدفع. في هذا المقال نشرح المكوّنات وما يحدث عند النجاح والفشل وكيف تُطابَق المدفوعات، مع ما يهم الشركات في اليمن.

المكوّنات الأساسية لاستلام الدفع داخل ERPNext

قبل الحديث عن أي بوابة، يجب فهم القطع التي يتكون منها مسار الدفع في ERPNext، لأن كل بوابة تتصل بها بالطريقة نفسها تقريباً:

القاعدة المهمة هنا أن البوابة لا تسجّل شيئاً في الحسابات بنفسها؛ ERPNext هو الذي يقرر القيد بناءً على إعدادات الحساب والعملة، وهذا ما يجعل النتيجة المحاسبية متسقة مهما تغيّرت البوابة.

تطبيق Payments والبوابات المتاحة فيه

تطبيق Payments تطبيق Frappe مفتوح المصدر بترخيص MIT، يضيف تكاملات جاهزة مع عدد من بوابات الدفع العالمية: Stripe وPayPal وBraintree وRazorpay وPaytm وGoCardless وM-Pesa وPaymob. لكل بوابة صفحة إعدادات تُدخَل فيها مفاتيح الحساب لدى المزوّد، ثم يُنشأ لها Payment Gateway Account في ERPNext.

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

ماذا يحدث عند نجاح الدفع: ثلاثة أمثلة عملية

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

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

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

الإشعارات الراجعة (Webhooks) والتحقق من الدفعة

العميل قد يغلق المتصفح بعد الدفع مباشرة، لذلك لا يُعتمد على عودته إلى صفحة النجاح. الطريقة الصحيحة أن يرسل مزوّد الدفع إشعاراً راجعاً (Webhook) إلى رابط في السيرفر، فيتحقق التطبيق منه قبل إنشاء أي قيد:

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

فشل الدفع والاسترداد

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

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

المطابقة: هل وصل المال فعلاً؟

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

الأمان والصلاحيات

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

وعندما يحتاج المسار إلى تعديل في شكل طلب الدفع أو قواعد إنشائه، نتولاه ضمن تخصيص ERPNext دون المساس بالكود الأساسي.