أصدر برنامج الفوترة لديك ملف PDF متناسقاً، وقامت منصتك المعتمدة (PA في فرنسا، والتي كانت تُعرف سابقاً بـ PDP) بإرساله… لكن الفاتورة عادت مرفوضة، وغالباً برمز خطأ لا يفهمه أحد. الخبر السار: نادراً ما يكون الرفض لغزاً لا حل له. لقد فحصت المنصة طبقات تقنية لا يعرضها قارئ PDF المعتاد — ويمكن تشخيص هذه الطبقات بشكل منهجي، بما في ذلك محلياً، دون إرسال الفاتورة إلى خدمة تابعة لجهة خارجية.
منذ 1 سبتمبر 2026، أصبح استلام الفواتير الإلكترونية إلزامياً لجميع الشركات الفرنسية، ويتعين على الشركات الكبرى والمتوسطة إصدارها بالفعل عبر منصة معتمدة (أما الشركات الصغيرة والمتوسطة والشركات متناهية الصغر: سبتمبر 2027). تتوالى حالات الرفض على المصدرين الذين يكتشفون هذه الصيغة حديثاً — ويساعدك هذا الدليل على فهم سبب رفض فاتورتك.
لماذا بدت الفاتورة “سليمة تماماً”
فاتورة Factur-X هي ملف هجين: يتكون من PDF/A-3 قابل للقراءة البشرية، بالإضافة إلى ملف XML مهيكل مضمن كمرفق تقرؤه البرمجيات. عند فتح الفاتورة في قارئ PDF، لا ترى سوى النصف الأول. أما أسباب الرفض فتكمن في النصف الثاني — أو في الخصائص التقنية للحاوية نفسها، وهي غير مرئية عند العرض.
المنصة المعتمدة لا “تقرأ” فاتورتك بالطريقة التي تقرؤها بها: بل تقوم بفك الحاوية، واستخراج ملف XML، وتطبيق قواعد التحقق قبل قبول المستند أو توجيهه. وبالتالي، يمكن أن يتعايش مظهر مرئي لا تشوبه شائبة مع ملف XML مفقود، أو تالف، أو غير متناسق حسابياً.
الأسباب الحقيقية للرفض، طبقة تلو الأخرى
يتبع تشخيص الفاتورة المرفوضة ترتيباً منطقياً: من الحاوية إلى المحتوى. وهذا هو الترتيب ذاته الذي تطبقه أداة تشخيص Factur-X من Document Flare، والتي تفحص خمس طبقات وتتوقف عند أول عائق حاسم.
1. الحاوية ليست بصيغة PDF/A-3
تتطلب Factur-X معيار PDF/A-3 (ISO 19005-3)، ويُشار إليه في بيانات XMP الوصفية عبر pdfaid:part=3. يفشل أي ملف PDF عادي — أو PDF/A بملف تعريف آخر — عند هذه المرحلة. ويتم فحص مؤشرين تكميليين: وجود OutputIntent (ملف تعريف الألوان، وهو إلزامي في PDF/A) والتصريح عن مخطط امتداد Factur-X في بيانات XMP (fx:DocumentType والعناصر المرافقة له: ConformanceLevel، وDocumentFileName، وVersion).
الحالة الشائعة: فاتورة تم “تسطيحها” (flattened) أو إعادة تحويلها لاحقاً بواسطة أداة عامة — حيث ينتج عن التحويل ملف PDF قياسي، وتفقد الفاتورة خاصية PDF/A-3.
2. ملف XML مفقود، أو مسمى بشكل خاطئ، أو غير مصرّح به بالشكل السليم
يجب إرفاق ملف XML تحت اسم معتمد: factur-x.xml (الأكثر شيوعاً)، أو zugferd-invoice.xml، أو xrechnung.xml للأنماط الألمانية. الملف المرفق باسم facture.xml أو data.xml لا يُعد Factur-X — فالمنصة ببساطة لن تجد أي فاتورة إلكترونية داخل ملف PDF الخاص بك.
وهناك فخان إضافيان في هذه الطبقة:
- AFRelationship: يجب التصريح عن علاقة المرفق بالمستند — وتعد القيمة المتوقعة لـ Factur-X هي
Alternative(بينما يتم التسامح معData). يؤدي غياب هذه العلاقة أو تعيينها بشكل غير صحيح إلى الرفض لدى المنصة المعتمدة (PA) على الرغم من وجود ملف XML بشكل سليم. - تلف ملف XML: الملف موجود بالفعل لكنه غير قابل للتحليل البرمجي — بسبب تصدير مبتور أو ترميز معطوب. لا يوجد ما يمكن تشخيصه هنا: بل يجب إعادة توليده من جديد.
يمكنك التحقق من وجود ملف XML يدوياً باستخدام أداة استخراج المرفقات، أو تلقائياً عبر أداة تشخيص Factur-X.
3. بنية XML غير مكتملة
يُعد ملف XML الخاص بـ Factur-X فاتورة بتنسيق CII (أي CrossIndustryInvoice). وتوجد ثلاثة أقسام لا غنى عنها: ExchangedDocumentContext (الذي يصرّح رمز URN الخاص به عن ملف التعريف)، وExchangedDocument (الرقم والتاريخ)، وSupplyChainTradeTransaction (البائع، المشتري، بنود الفاتورة، والمجاميع). كما يجب تضمين التلخيص المالي (SpecifiedTradeSettlementHeaderMonetarySummation).
وتندرج البيانات الإلزامية الدنيا للمعايير ضمن هذه الطبقة أيضاً: رقم الفاتورة (BR-1، BT-1)، تاريخ الإصدار (BR-2، BT-2)، اسم البائع (BR-11، BT-27)، واسم المشتري (BR-17، BT-44).
4. عدم تطابق المجاميع (قواعد BR-CO-*)
تُعد قواعد EN 16931 الحسابية سبباً رئيسياً للرفض: فهي تتحقق من اتساق ملف XML مع نفسه. وأبرز هذه القواعد:
| القاعدة | الشرط الواجب تحققه |
|---|---|
| BR-CO-10 | مجموع مبالغ البنود يساوي إجمالي صافي البنود (BT-106) |
| BR-CO-13 | الإجمالي الصافي (BT-109) = البنود − الخصومات + الرسوم الإضافية |
| BR-CO-14 | إجمالي ضريبة القيمة المضافة (BT-110) = مجموع الضريبة حسب كل نسبة (BT-117) |
| BR-CO-15 | الإجمالي الشامل (BT-112) = الإجمالي الصافي + ضريبة القيمة المضافة |
| BR-CO-16 | المبلغ المستحق الدفع (BT-115) = الإجمالي الشامل − الدفعات المقدمة + التقريب |
تتسامح المقارنات مع فارق نصف سنت (نظراً لوجود تقريبات حسابية وسيطة). وتُضاف إلى ذلك قواعد الدقة BR-DEC: مبالغ الفاتورة بحد أقصى خانتين عشريتين، وسعر الوحدة بحد أقصى 4 خانات عشرية. وأخيراً، تتطلب القاعدة BR-16 وجود بند فاتورة واحد على الأقل بمجرد تجاوز ملف التعريف لمستوى MINIMUM — فالفاتورة التي لا تحتوي على بنود وتُعرّف نفسها كملف BASIC صريح ستُرفض حتماً.
5. المعرّفات الفرنسية غير مطابقة للصيغة
الطبقة الخاصة بفرنسا: يجب أن يتكون رقم SIREN (المخطط 0002) من 9 أرقام، ورقم SIRET (المخطط 0009) من 14 رقماً، سواء من جانب البائع (BT-30) أو المشتري (BT-47). وأي معرّف يُصرّح به بمخطط خاطئ أو طول غير صحيح يتم الإبلاغ عنه كخطأ.
ملاحظة: غالباً ما تتجاوز المنصات التحقق من مجرد الصيغة — حيث تتحقق من كون رقم SIREN نشطاً في الدليل الرسمي، وأن المستلم معروف. لذلك، يمكن لرقم SIREN سليم التنسيق لكنه مشطوب تجارياً أن يجتاز تشخيص الملف ويفشل لاحقاً عند الإرسال الفعلي.
تشخيص الفاتورة المرفوضة عملياً
تطبق أداة تشخيص Factur-X هذا التسلسل بالكامل داخل متصفحك مباشرة — فالملف لا يغادر جهازك أبداً، وهو أمر بالغ الأهمية لمستند يحتوي على مبالغك المالية وبيانات عملائك وتفاصيلك المصرفية أحياناً.
- أسقط ملف PDF المرفوض (ملف واحد في كل مرة).
- اقرأ التقرير المفصل لكل طبقة: حيث تُصنف كل طبقة بأنها متوافقة (compliant)، أو بها تعارض (discrepancy)، أو معيقة (blocking / خطأ فادح)، أو لم تُقيّم (not evaluated).
- الطبقة المعيقة توقف فحص الطبقات اللاحقة تلقائياً — فلا جدوى من البحث عن خطأ BR-CO إذا كان ملف XML مفقوداً أساساً: عالج الطبقة المعيقة أولاً، ثم أعد التشخيص.
- بالنسبة للتعارضات المشمولة بالفحص، يوضح التقرير القاعدة المحددة (مثل BR-CO-10 أو FX-EMBEDDED-AFREL…) مع تقديم مسار مقترح للتصحيح.
يغطي التشخيص النواة المختبرة (الإصدار 1.3.16 من أدوات التحقق، وقوائم الرموز كما في 15 مايو 2026). إنه تشخيص أولي وسريع: ولا يعيد تشغيل كافة قواعد Schematron الرسمية بالكامل — ولإجراء تحقق شامل، تظل أداة التحقق التابعة لـ FNFE-MPE هي المرجع الأساسي.
هل تُصلح الملف أم تعيد توليده؟
تختلف الإجابة باختلاف الطبقة التي تحتوي على الخلل:
- أعد التوليد إذا كان ملف XML مفقوداً، أو تالفاً، أو ناقص البنية، أو إذا كانت المبالغ المصرح بها غير صحيحة. فالبيانات التجارية (المجاميع، البنود، الهويات) مصدرها برنامج الفوترة أو منصتك: ولا يمكن لأي أداة PDF ابتكارها بدقة. تحقق من إعدادات التصدير — ملف تعريف Factur-X المختار، واستيفاء البيانات الإلزامية — ثم أعد التصدير مجدداً.
- طبقة الحاوية هي المجال الوحيد الذي يمكن فيه تصور إصلاح على مستوى الملف (مثل غياب OutputIntent أو خطأ في تصريح AFRelationship). ولكن عملياً، يظل الحل السليم في يد نظام التوليد نفسه: فمحاولة “إصلاح” الحاوية يدوياً دون إتقان مواصفات PDF/A-3 تؤدي غالباً إلى رفض جديد. وتذكير مفيد: تحويل ملف PDF إلى PDF/A ليس كافياً بمفرده — فخدمة تحويل PDF/A في Document Flare تنتج أفضل ملف تعريف 1b متاح، وليس حزمة PDF/A-3 + XML + XMP المتكاملة التي تشكّل فاتورة Factur-X.
- إذا جاءت نتيجة التشخيص سليمة تماماً واستمرت المنصة في الرفض: فإن السبب يكمن في جانب الإرسال (رقم SIREN غير نشط، الدليل، أو إعدادات تدفق البيانات). وتصبح رسالة رفض المنصة المعتمدة (PA) ودعمها الفني دليلك الأفضل لمعرفة السبب.
عادة توفر عليك الوقت: احتفظ بنص رسالة الرفض الدقيق. فعبارة “الفاتورة غير متوافقة” لا توجهك بنفس الطريقة التي توجهك بها “BR-CO-10” — فالأخيرة تأخذك مباشرة إلى فحص الطبقة الرابعة.
باختصار
يتم تشخيص رفض الفاتورة الإلكترونية عبر التدرج في الطبقات: فحص PDF/A-3، وملف XML المضمن والمصرّح به بشكل سليم، وبنية CII المكتملة، وحسابات EN 16931، والمعرّفات الفرنسية. تنشأ معظم حالات الرفض من الطبقتين الأوليين — وهما غير مرئيتين في ملف PDF، لكن يمكن اكتشافهما في ثوانٍ محلياً. ابدأ بالتشخيص أولاً، ثم أعد التوليد من برنامج الإصدار ثانياً: فهناك تكمن البيانات، وهناك يتم تصحيحها. أما بالنسبة لملفات التعريف MINIMUM وBASIC التي تُرفض رغم أن الملف “يجتاز” أدوات التحقق، فهذه مسألة أخرى — طالع أي ملف تعريف Factur-X يجب اختياره.
