الفوترة الإلكترونية ومتجرك: ما الذي ينفّذه فريق الويب، وما الذي يقرره غيره

إيصال الطلب ليس فاتورة ضريبية

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

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

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

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

ثلاث بنى شائعة للربط، ولكل واحدة ثمن مختلف

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

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

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

البيانات التي يجب أن يلتقطها الموقع من اليوم الأول

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

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

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

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

ماذا يحدث حين يفشل الربط؟ هذا هو السؤال الذي يفصل عرضاً جاداً عن غيره

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

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

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

حدودنا معلنة مسبقاً

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

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

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

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