مدقق فواتير ‎UBL‎/‎Peppol‎

تحقّق من الشكل قبل أن تتحقق منه الشبكة نيابة عنك

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

ما هو الفحص الهيكلي — وما هو Schematron

الصدق مهم هنا. التحقق الرسمي من ‎Peppol BIS Billing 3.0‎ هو مجموعة قواعد ‎Schematron‎: مئات القواعد التجارية التي تفحص أمورًا مثل ما إذا كانت رموز فئات ضريبة القيمة المضافة متسقة وما إذا كانت إجماليات الضريبة تساوي مجموع البنود. ولا تشغّل هذه الأداة تلك القواعد. اقرأ النتيجتين وفقًا لذلك: الفشل هنا نهائي — فملف لا يتم تحليله، أو يفتقد حقولًا إلزامية، سيفشل في كل مكان، فأصلحه قبل الإرسال. أما النجاح هنا فيعني أن الشكل قابل للاستخدام، لا أن كل قاعدة تجارية مستوفاة؛ فقد ترفضه الشبكة رغم ذلك بسبب مخالفة على مستوى القواعد. والفحص الهيكلي أولًا، ثم ‎Schematron‎ بعده، هو الترتيب الطبيعي للتحقق. والحد هنا مقصود لا كسل: فمجموعات القواعد الرسمية مُرقَّمة بالإصدارات وتُصان مركزيًا، وتشغيلها بشكل صحيح هو عمل بنية ‎Peppol‎ التحتية نفسها — وتقليد ذلك بشكل سيّئ سيخدمك بشكل أسوأ من ذكر الحد بوضوح.

الإخفاقات التي نراها فعليًا

تقع معظم الملفات المرفوضة ضمن حفنة من الأنماط. الملف إشعار دائن لا فاتورة — نوع مستند ‎UBL‎ مختلف لا يغطيه هذا المدقق بعد. أو أنه ملف ‎PDF‎ بصيغة ‎Factur-X‎ لا ‎XML‎ خام — فالفاتورة مضمَّنة داخل ‎PDF‎ وتحتاج إلى استخراج أولًا بأداة ‎Factur-X‎ على هذا الموقع. أو أنه اقتُطع أو أُعيد ترميزه في مكان ما خلال رحلة بريد إلكتروني، فلم يعد ‎XML‎ قابلًا للتحليل. أو أن تصدير ‎ERP‎ ترك حقول طرف أو إجمالي إلزامية فارغة لأن سجل بيانات رئيسي كان ناقصًا. ويسمّي المدقق ما هو مفقود، وهو ما يشير عادة مباشرة إلى أي من هذه الحالات وقع. وثمة تنويعة أدق تستحق أن تُعرف: ملف يُفتح بسلاسة في محرر نصوص قد يفشل رغم ذلك في التحليل لأن بوابة بريد إلكتروني أو خطوة نسخ ولصق غيّرت ترميز الأحرف — أمر غير مرئي للعين، لكنه قاتل لـ‎XML‎. أعِد التصدير من النظام المصدر بدلًا من الإصلاح اليدوي.

المحلِّل نفسه المستخدَم في محوّل PDF — ومتى تتصل بمزوّدك

يشترك هذا المدقق في محلِّله، سطرًا بسطر، مع أداة تحويل فاتورة UBL/Peppol إلى PDF على هذا الموقع. وهذا يمنحك مسار عمل موثوقًا صغيرًا: تحقّق من الملف، ثم صيّره واقرأ الفاتورة كما يقرأها إنسان — فرقم ‎IBAN‎ خاطئ أو إجمالي غير معقول غالبًا ما يكون أسهل ملاحظة على صفحة منه في ‎XML‎. واعرف أين يقع الحد: إذا نجح ملف هنا، وصُيّر بشكل معقول، ثم ظل مرفوضًا من شبكة ‎Peppol‎، فإن المشكلة تقع على مستوى القواعد التجارية أو الإرسال. وتلك محادثة تخص نقطة الوصول أو مزوّد البرنامج لديك، الذي يمكنه رؤية تقرير التحقق الرسمي — أحضر معك رسالة خطئه، فهي تسمّي القاعدة الدقيقة التي أثارته.

ما الذي تتحقق منه هذه الأداة فعليًا

تتحقق هذه الأداة من أن الملف بصيغة ‎XML‎ سليمة البنية، وأنه يحتوي على عنصر جذر Invoice بصيغة ‎UBL‎، وأنه يضم الحقول التي تحتاجها فاتورة قابلة للقراءة: رقم الفاتورة، والتواريخ، وأطراف المورّد والعميل، وبنود السطور، والإجماليات. إنها فحص هيكلي أساسي، وليست التحقق الرسمي من نوع ‎Schematron‎ الخاص بمعيار ‎Peppol BIS Billing 3.0‎ — فهي لا تكتشف كل مخالفة لقواعد العمل (مثل إجماليات ضريبية لا تُجمع بشكل صحيح)، بل تتحقق فقط من أن الشكل العام قابل للاستخدام أصلًا.