أجهزة نقاط البيع Alhamrani mada الآن متصلة بنظام ERPNext من خلال ERPGulf

Author
١٩ أغسطس ٢٠٢٦
أجهزة نقاط البيع Alhamrani mada الآن متصلة بنظام ERPNext من خلال ERPGulf

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

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

لقد قمنا الآن بربط أجهزة mada التابعة لشركة Alhamrani Universal مباشرةً بنظام ERPNext، وبالتالي لن تحدث هذه المشكلة بعد الآن.

ما الذي يتغير عند نقطة البيع؟

يقوم أمين الصندوق بإتمام عملية البيع كالمعتاد ويختار الدفع بالبطاقة. يظهر المبلغ تلقائياً على جهاز الدفع. يقوم العميل بتمرير البطاقة أو إدخالها، وإدخال الرقم السري إذا لزم الأمر، ويتواصل الجهاز مع Saudi Payments كما هو معتاد.

عند وصول الموافقة، تكتمل عملية البيع ويتم ترحيل الفاتورة، مع تسجيل رمز الموافقة، ورقم المرجع للاسترداد، ونوع البطاقة، ورقم البطاقة المقنّع، ورقم الجهاز الطرفي على الفاتورة تلقائياً.

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

بالنسبة لأمين الصندوق، فهذا يعني خطوة واحدة أقل تقريباً في كل عملية دفع بالبطاقة. وبالنسبة للشخص الذي يقوم بإغلاق الوردية، فهذا هو الفرق بين إجراء التسوية وبين مجرد التأكد من صحة العمليات.

ما الذي يتغير في الإدارة الخلفية؟

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

قد يبدو الأمر بسيطاً حتى يصل أول استفسار حول عملية استرداد أو اعتراض على عملية دفع، أو يعود عميل بعد ثلاثة أسابيع ويؤكد أنه دفع بالبطاقة ولا يستطيع العثور على الإيصال. بدلاً من البحث في سجلات أجهزة الدفع، يمكنك البحث عن الفاتورة.

وتستفيد عمليات الاسترداد من نفس الميزة. يجب أن يرتبط استرداد عملية mada بالمعاملة الأصلية، والحصول على هذا المرجع يدوياً يعني البحث عن الإيصال الأصلي. هنا يكون المرجع موجوداً بالفعل على الفاتورة، لذلك يحمل الاسترداد المرجع الصحيح دون الحاجة إلى البحث عنه.

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

مصمم لنقاط البيع السحابية، وليس فقط لنقاط البيع المستضافة على السحابة

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

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

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

كل جهاز نقطة بيع يتصل بجهاز الدفع الخاص به. ولا تمر أي بيانات عبر خادم مركزي، لذلك لا يتعطل النظام عندما يكون اتصال الإنترنت بطيئاً.

الجزء الذي لا تتحدث عنه معظم التكاملات

تفشل عمليات الدفع بالبطاقة أحياناً بطريقة محددة ومحرجة، ومن المهم أن نكون واضحين بشأنها.

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

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

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

نحن نتعامل معها كحالة مختلفة تماماً.

رفض البطاقة يعني أن شيئاً لم يتم تحصيله، وبالتالي فإن إعادة محاولة الدفع آمنة.

أما الدفع غير المؤكد فهو أمر مختلف: قد تكون العملية قد تمت بالفعل، ولذلك يتوقف النظام ويطلب التحقق.

يتلقى أمين الصندوق تعليمات واضحة — التحقق من شاشة جهاز الدفع أو طباعة آخر إيصال — مع خيارين.

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

وإذا لم توجد موافقة، يقوم أمين الصندوق بتسجيل ذلك، ثم يعيد محاولة الدفع بثقة.

وحتى يتم الرد على هذه الحالة، لن يتم ترحيل الفاتورة.

وهذا مقصود. فعملية الدفع بالبطاقة غير المحسومة هي تحديداً الحالة التي لا ينبغي السماح لها بالاختفاء بهدوء ضمن عمليات اليوم.

نحن نفضل أن نطرح على أمين الصندوق سؤالاً واحداً محرجاً بدلاً من إرسال خصم غير متوقع إلى العميل.

ضوابط مهمة في المتجر الحقيقي

هناك بعض الأمور التي قمنا ببنائها لأن بيئة البيع بالتجزئة أكثر تعقيداً من أي مواصفات نظرية.

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

لذلك يتحقق كل جهاز نقطة بيع من هوية جهاز الدفع عند فتح نظام نقاط البيع، ويرفض إجراء عمليات البيع إذا لم تتطابق الهوية.

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

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

إلى جانب ZATCA وليس بديلاً عنها

يلتزم تجار التجزئة في المملكة العربية السعودية بالفعل بمتطلبات الفوترة الإلكترونية، وقد قمنا بتنفيذ أعمال الامتثال لـ ZATCA منذ المرحلة الأولى.

بيانات الدفع بالبطاقة التي يلتقطها هذا التكامل تظهر إلى جانب متطلبات ZATCA في نفس الفاتورة ونفس الإيصال المطبوع، وليس كنظام ثانٍ يحتاج إلى صيانة منفصلة.

إذا كنتم تستخدمون بالفعل تكامل ZATCA الخاص بنا، فيمكن إضافة هذا التكامل بجانبه.

ما الذي يتطلبه التنفيذ؟

المتطلبات بسيطة عملياً.

تقوم Alhamrani بتمكين وضع ECR على أجهزة الدفع الخاصة بكم — وهذا يتم من خلال طلب إلى فريق الدعم لديهم، وعادةً ما يكون أطول جزء من مدة التنفيذ، لذلك من الأفضل البدء به مبكراً.

يحتاج كل جهاز كمبيوتر عند نقطة البيع إلى تثبيت خدمة Alhamrani المحلية، وهي عملية تثبيت بسيطة يتم تنفيذها مرة واحدة.

تتصل أجهزة الدفع عبر USB أو من خلال شبكة المتجر، اعتماداً على الطراز المستخدم.

كما يتم ربط كل جهاز نقطة بيع بجهاز الدفع الخاص به داخل ERPNext، بحيث تقوم نقطة البيع الصحيحة بتشغيل جهاز الدفع الصحيح.

نتولى نحن جانب ERPNext، ونتولى التنسيق مع Alhamrani بشأن تمكين أجهزة الدفع، ونعمل مع فريق تقنية المعلومات لديكم بشأن متطلبات الشبكة.

تواصل معنا

نحن نعمل على تطوير حلول Frappe وERPNext في المملكة العربية السعودية وقطر والإمارات العربية المتحدة منذ سنوات، مع تركيز خاص على حلول الامتثال والمدفوعات التي يحتاجها قطاع التجزئة في منطقة الخليج، بما في ذلك الفوترة الإلكترونية ZATCA، ومدفوعات mada، والفوترة باللغة العربية، وحلول نقاط البيع على نطاق واسع.

إذا كان جهاز الدفع ونظام نقاط البيع لديكم لا يزالان نظامين منفصلين يعملان بجانب بعضهما البعض، فينبغي أن نتحدث.

ERPGulf — support@erpgulf.com · www.erpgulf.com

Author
كتب بواسطة ERPGulf Team