الفواتير والفوترة الإلكترونية

SpecSpec: EN 16931-1:2026, BT-24EN 16931-1:2026 BT-24SpecSpec: Factur-X 1.08Factur-X 1.08SpecSpec: ISO 32000-2:2020, §14.13ISO 32000-2:2020 §14.13

لمحة سريعة

الفاتورة الحديثة مستندان في ملف واحد: صفحة يقرأها الإنسان، وحمولة ⁨XML⁩ قابلة للقراءة آلياً يحلِّلها نظام ضريبي. تتتبع هذه الصفحة سيناريو الفاتورة الهجينة من الالتزام إلى المُخرَج: ما الذي يتطلبه ⁨ZUGFeRD⁩ و⁨Factur-X⁩، وكيف يُرفِق ⁨NextPDF⁩ الحمولة المُهيكلة ويفحصها، وأين تنتهي المطابقة بوصفها مهمة للمحرك وتصبح مسؤوليتك أنت.

لماذا يهمّ هذا

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

ضبط هذا الأمر مرة واحدة، في الطبقة التي تُنتِج الملف، أرخص بكثير من اكتشافه بعد تخليص الفواتير واحدة تلو الأخرى.

النسخة المختصرة

• الفاتورة الهجينة المُمتثِلة هي حاملة PDF/A مزوَّدة بـحمولة ⁨XML⁩ مُطابِقة مُضمَّنة كملف مرتبط. يجب أن تُصرِّح بيانات الحاملة الوصفية بالملف.
• الحقل الوحيد الذي يحسم القبول في أغلب الأحيان هو BT-24، مُعرِّف المواصفة. تتطلب قاعدة العمل BR-1 في EN 16931 أن تحمله كل فاتورة. القيمة هي URN يُسمِّي الملف بدقة — على سبيل المثال urn:cen.eu:en16931:2017 الخاص بملف EN 16931 (COMFORT).
• مهمة ⁨NextPDF⁩ هي التضمين والتحقق البنيوي من ⁨XML⁩ المُقدَّم من المُستدعي. فهو لا يؤلِّف محتوى الفاتورة وليس مُتحقِّقاً تابعاً لسلطة ضريبية.
• يظل المُصدِر مسؤولاً عن الصحة القانونية والمالية. نتيجة التحقق النظيفة مُدخَل واحد لذلك القرار، وليست شهادة.

كيف يتعامل ⁨NextPDF⁩ معها

يتعامل ⁨NextPDF⁩ مع الفاتورة المُهيكلة باعتبارها عقداً عابراً للطبقات، لا ميزة منفردة. يُعرِّف المحرك الأساسي الواجهات — مُضمِّن، وواصِف ملف، ومُتحقِّق — وتوفر طبقة ⁨Premium⁩ التطبيقات. هذا الفصل متعمَّد. السطح العام مُجمَّد في النواة، لذا تتعامل مواضع الاستدعاء والاختبارات مع الملف والنتيجة بالطريقة نفسها، بصرف النظر عن الطبقة الموجودة خلفها.

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

1. Author the invoice XMLYou (or your ERP) produce a UN/CEFACT CII or Peppol UBL payload. NextPDF never synthesizes invoice content.
2. Produce the PDF/A carrierA PDF/A-3 or PDF/A-4f document is the human-readable face and the conformant container the standard requires.
3. Embed the payloadThe embedder attaches the XML as an associated file with the correct AFRelationship, and injects the Factur-X XMP profile declaration.
4. Validate, then shipA structural pass checks the root, the required sections, and BT-24 against the declared profile before the file leaves your system.

سيناريو الفاتورة الإلكترونية الهجينة من بدايته إلى نهايته: أنت تؤلِّف XML وتملك صحته القانونية؛ ويحمله NextPDF ويفحصه بنيوياً؛ وتتخذ المنصة المُستقبِلة قرار القبول النهائي.

عقد المُضمِّن هو بايتات داخلة وبايتات خارجة: تدخل حاملة PDF/A وحمولة ⁨XML⁩، وتخرج بايتات ⁨PDF⁩ هجين. قبل إرفاق أي شيء، يُحلَّل ⁨XML⁩ عبر حارس مُحصَّن يرفض DOCTYPE، ويضع سقفاً لحجم المُدخَل، ويرفض محارف التحكم المحظورة في ⁨XML⁩ 1.0. يُزيل هذا هجمات الكيان الخارجي في ⁨XML⁩ (⁨XML⁩ External Entity) وهجمات Billion-Laughs بحكم البنية، لأن ⁨XML⁩ الخاص بالفواتير يصل عادةً من خارج حدود الثقة لديك.

يجيب واصِف الملف عن الأسئلة الأربعة التي يطرحها النظام التالي في سلسلة المعالجة: URN الخاص بالملف القانوني، وقيمة BT-24 الواجب تأكيدها، واسم ثابت للسجلات، ومُميِّز محايد تجاه الطبقات حتى تتمكن اختبارات التكافؤ من تجميع النتائج. والواصِف صريح بشأن الفجوات. لا يحمل ملف ⁨ZUGFeRD⁩ MINIMUM مُعرِّف المواصفة BT-24، ويُرجِع الواصِف null له بدلاً من اختلاق واحد. ولهذا أيضاً لا يكون ⁨MINIMUM⁩ و⁨BASIC WL⁩ مُطابِقَين لـEN 16931. يُرمِّز المحرك واقع التعدُّدية بدلاً من إخفائه.

Human-factors note:Human-factors note

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

مثال عملي

الشكل أدناه توضيحي للوصلة، وليس تكاملاً جاهزاً للنسخ واللصق. بناء الحاملة والمُضمِّن يأتيان من طبقة ⁨Premium⁩، و⁨XML⁩ ملكك أنت.

<?php

declare(strict_types=1);

use NextPDF\Contracts\EInvoice\ProfileType;
use NextPDF\Contracts\EInvoice\ValidatorContext;
use NextPDF\Contracts\EInvoice\ValidatorInterface;
use NextPDF\Contracts\EInvoice\EmbedderInterface;
use NextPDF\Contracts\EInvoice\EmbedderOptions;
use Psr\Log\LoggerInterface;

/**
 * Validate first, embed second, never ship an invalid payload.
 *
 * @param non-empty-string $carrierPdf  PDF/A-3 or PDF/A-4f carrier bytes
 * @param non-empty-string $ciiXml      Caller-authored UN/CEFACT CII XML
 *
 * @return non-empty-string Hybrid invoice bytes, ready to deliver
 */
function buildHybridInvoice(
    ValidatorInterface $validator,
    EmbedderInterface $embedder,
    LoggerInterface $logger,
    string $carrierPdf,
    string $ciiXml,
): string {
    // STRICT mode: a missing BT-24 is a hard error, not a warning.
    $context = new ValidatorContext(
        profile: ProfileType::EN16931,
        strictMode: true,
    );

    $result = $validator->validate($ciiXml, $context);

    if (!$result->isValid) {
        foreach ($result->getErrors() as $finding) {
            $logger->error('invoice.structural_finding', [
                'message' => $finding->message,
            ]);
        }

        // A failed structural check is your signal to stop, not to ship.
        throw new \RuntimeException('Invoice XML failed structural validation.');
    }

    $options = new EmbedderOptions(profile: ProfileType::EN16931);

    return $embedder->embed($carrierPdf, $ciiXml, $options);
}

الترتيب هو جوهر المسألة. التحقق رخيص قياساً بفاتورة مرفوضة ودفعة مُتأخِّرة، لذا يُشغَّل قبل إرفاق الحمولة أصلاً.

مفهوم خاطئ شائع

المفهوم الخاطئ الأكثر تكلفة هو “⁨NextPDF⁩ يجعل فواتيري مُمتثِلة.” وهذا غير صحيح. تقول هذه الصفحة ذلك صراحةً. يُضمِّن المحرك ⁨XML⁩ الذي تؤلِّفه ويفحصه بنيوياً. نتيجة بنيوية ناجحة تعني أن الحمولة تحمل الشكل الذي يتوقعه EN 16931 وتُعلِن الملف الذي طلبته. وهي لا تعني أن الفاتورة كافية قانونياً، أو مُعتمَدة من سلطة ضريبية، أو مضمونة القبول لدى أي منصة تخليص. الامتدادات الوطنية ووسائط نقل التخليص خارج النطاق على مستوى المحرك. وبحسب صياغة EN 16931-1 نفسها، فإن النموذج الأساسي يحمل المعلومات اللازمة لدعم الامتثال. والمُصدِر مسؤول عن استيفاء التشريعات ذات الصلة.

فخ ثانٍ أقل وضوحاً: دعم معيار ما لا يعني مطابقته. المطابقة خاصية للملف النهائي مقروناً بمُتحقِّق، لا خاصية للمكتبة التي أنتجته.

الحدود والقيود

• ⁨NextPDF⁩ لا يؤلِّف محتوى الفاتورة ولا يُصحِّحه. يُقدِّم المُستدعي ⁨XML⁩ صالحاً ويظل مُصدِر الفاتورة. قائمة نتائج خالية لا تجعل حمولة غير مُطابِقة مُطابِقة.
• التضمين المُهيكل والتحقق عبر ⁨Schematron⁩ قدرتان في طبقة ⁨Premium.⁩ تُعرِّف النواة العقود؛ أما التطبيقات فتتطلب الحزمة التجارية. انظر الحد الفاصل أدناه.
• يفحص المُتحقِّق النموذج الدلالي لـEN 16931 وحاوية ⁨ZUGFeRD⁩ / Factur-X / UBL فقط. وهو ليس مُتحقِّقاً تابعاً لسلطة ضريبية. نقل SDI وChorus Pro وXRechnung خارج النطاق على مستوى النقل.
• ملفا MINIMUM وBASIC WL غير مُطابِقَين لـEN 16931 ولا يحملان مُعرِّف المواصفة BT-24 — وذلك بحكم التصميم، انعكاساً لتعدُّدية المعيار، لا قيداً في المحرك.
• يحتاج محرك Schematron إلى ext-xsl. تُترجَم مجموعات القواعد وقت البناء. وتُنفِّذ بيئة التشغيل XSLT المُترجَم مسبقاً فقط، مع تعطيل تحميل الموارد من الشبكة ونظام الملفات.
• تصف هذه الصفحة السلوك على مستوى القدرة. ولا تؤكد القبول لدى أي سلطة أو منصة بعينها.

Structured e-invoice embedding and validation — edition availability

Edition	Availability
Core	○ تُعرِّف النواة العقود العابرة للطبقات (EmbedderInterface، ProfileInterface وValidatorInterface) لكنها لا تُقدِّم أي تطبيق لفاتورة مُهيكلة. حاملة ⁨PDF⁩ بسيطة بلا حمولة مُهيكلة هي نتيجة النواة وحدها.
Pro	○ تضمين Factur-X 1.08 (CII) في حاملة PDF/A وواصِفات ملف EN 16931 متاحة.
Enterprise	○ تضيف تضمين Peppol BIS 3.0 UBL، وXRechnung B2G CIUS، والتحقق من XML بوضعَي COMPAT/STRICT، ومحرك قواعد ⁨Schematron⁩ الذي يعمل ضمن العملية.

مستندات ذات صلة

• الأرشفة وPDF/A — لماذا تكون حاملة الفاتورة ملف PDF/A، وما الذي يضمنه ذلك لقابلية القراءة على المدى الطويل.
• دليل قرار التكامل — أي حزمة في المنظومة تناسب سلسلة معالجة الفوترة (التوليد المُصطَف، أو جسر إطار العمل، أو ⁨Connect⁩).
• تشغيل ⁨NextPDF⁩ في الإنتاج — كيفية مراقبة نتائج التحقق وإخفاقاته عندما تتدفق الفواتير بكثافة.

مسرد المصطلحات

• الفاتورة الهجينة — ملف ⁨PDF⁩ واحد يكون في آنٍ واحد صفحة يمكن للإنسان قراءتها وحمولة فاتورة ⁨XML⁩ مُضمَّنة قابلة للقراءة آلياً.
• ⁨ZUGFeRD⁩ / Factur-X — الاسمان الألماني والفرنسي للنهج نفسه في الفاتورة الهجينة: حمولة ⁨XML⁩ من نوع Cross Industry Invoice (CII) وفق UN/CEFACT مُضمَّنة في حاملة PDF/A.
• EN 16931 — المعيار الأوروبي الذي يُعرِّف النموذج الدلالي لعناصر البيانات الأساسية للفاتورة الإلكترونية.
• BT-24 (مُعرِّف المواصفة) — مصطلح العمل في EN 16931 الذي قيمته URN يُسمِّي الملف الدقيق الذي تُطابِقه الفاتورة. تتطلبه قاعدة العمل BR-1.
• الملف (Profile) — يُسمى أيضاً مستوى المطابقة (MINIMUM وBASIC WL وBASIC وEN 16931 وEXTENDED وXRECHNUNG). يُحدِّد أي مصطلحات عمل يجب أن تحملها الفاتورة.
• الملف المرتبط — ملف مُرفَق داخل ⁨PDF⁩ بعلاقة مُعلَنة (AFRelationship) تصف صلته بالمستند المرئي؛ وهو الآلية التي تحمل ⁨XML⁩ الخاص بالفاتورة.
• Schematron — لغة قواعد تُستخدم للتعبير عن قواعد العمل في EN 16931. يُشغِّل ⁨NextPDF⁩ مجموعات قواعد CEN المُترجَمة إلى XSLT.