BR-KSA-EN16931-01 يرفض الفاتورة

معرّف العملية (BT-23) ليس reporting:1.0

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

نص الرسالة كما ترسلها الهيئة بالإنجليزية، بلا تعديل

Business process (BT-23) must be "reporting:1.0".

ماذا يعني هذا؟

العنصر هو cbc:ProfileID، ويُكتب في رأس المستند قبل رقم الفاتورة. واسم الحقل في المواصفة الأوروبية EN 16931 هو BT-23 «نوع عملية الأعمال»، وتُختار له هناك قيمة من قائمة ملفات تعريفية. والمواصفة السعودية اختصرت ذلك الاختيار كله إلى نصّ واحد: reporting:1.0.

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

والحرفية تشمل الشكل كله: حروف صغيرة، ونقطتان رأسيتان واحدة، و1.0 بالنقطة. فـReporting:1.0 وreporting:1 وreporting-1.0 نصوص أخرى، ومسافة زائدة أو سطر جديد داخل العنصر نصّ آخر كذلك.

ولا يتغيّر بنوع المستند: القيمة نفسها على الفاتورة الضريبية والمبسطة وإشعاراتهما الدائنة والمدينة، وتبقى reporting:1.0 حتى على مستند يمرّ بإجازة مسبقة لا بتبليغ. وليس في القواعد التي استخرجناها قاعدةٌ أخرى واحدة تتكلم عن BT-23 — فلا شرط ولا استثناء ولا تقييد بعائلة.

وموضعه في الرأس ليس تفصيلًا شكليًّا عند من يكتب موقِّعه بنفسه: في المكتبة التي يستعملها ZATCA Tools تُدرَج كتلة ext:UBLExtensions — وهي التي تحمل الختم والتوقيع — باستبدال نصّي يبحث عن وسم cbc:ProfileID ويضع الكتلة قبله مباشرة. فالعنصر حمّالُ معنى في التحقق وفي التوقيع معًا.

لماذا يحدث؟

مرتّبة من الأشيع إلى الأقل شيوعًا — الأرجح أن سببك في الأول أو الثاني.

  • XML مكتوب على مثال أوروبي، فيحمل قيمة ملف Peppol التعريفي للفوترة بدل النص السعودي.
  • الحقل أُجيب بوصف: clearance، أو reporting بلا إصدار، أو B2C.
  • رقم إصدار رُفع باجتهاد مطوّر ظنّه يتتبع إصدار المواصفة: reporting:2.0.
  • قيمة مشتقة من متغيّر بيئة أو مفتاح إعداد يميّز بيئة التجربة من الإنتاج.
  • مسافة أو سطر جديد داخل العنصر، من تنسيق الملف بعد بنائه.
  • حذف العنصر كليًّا. ولا نستطيع أن نجزم لك أيعود غيابه بهذا الكود أم بخطأ مخطط — فنحن نقرأ نصوص القواعد ودرجاتها لا شروط تنفيذها — والعمل الصحيح واحد في الحالين: اكتبه.

كيف تصلحه

3 خطوات، ثم أعد إرسال الفاتورة.

  1. 1
    اكتب الثابت كما هو

    العنصر cbc:ProfileID بالقيمة reporting:1.0، نصًّا حرفيًّا بلا مسافات محيطة ولا سطر جديد داخله، على كل مستند: فاتورة ضريبية ومبسطة وإشعارًا دائنًا ومدينًا.

  2. 2
    ولا تشتقّه من شيء

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

  3. 3
    وراجع جيرانه في الرأس

    رأس المستند يحمل ثوابت أخرى تخطئ بالطريقة نفسها: ترميز نوع المعاملة KSA-2 في BR-KSA-06، ونوع المستند BT-3 في BR-KSA-05، وعملة الاحتساب الضريبي في BR-KSA-68. والملف المبني على مثال أوروبي يخطئ فيها جميعًا في الغالب، فمراجعتها في مرور واحد توفّر عليك جولات رفض متتابعة.

بعد التصحيح أعد إرسال الفاتورة. الفاتورة المرفوضة لم تُسجَّل عند الهيئة، فلا تحتاج إشعارًا دائنًا — أرسل الفاتورة الصحيحة نفسها.

هل يمنعه ZATCA Tools؟

نعم، ولا سبيل إلى خلافه أصلًا. القيمة reporting:1.0 حقل خاص في صنف الفاتورة داخل المكتبة، مُهيّأ بها ابتداءً، وله قارئ وليس له ضابط — فلا ZATCA Tools ولا أي مستعمل آخر للمكتبة يستطيع تغييره ولو أراد. ونحن لا نمرّر في حمولتنا قيمة ملف تعريفي أصلًا. تحققنا من ذلك في ملف المكتبة نفسه: العنصر يُكتب من ذلك الحقل الثابت في كل مستند، قبل رقم الفاتورة.

أكواد لها علاقة

BR-KSA-06 يرفض الفاتورة
ترميز نوع المعاملة (KSA-2) غير صحيح — بنية NNPNESB
BR-KSA-EN16931-02 يرفض الفاتورة
عملة الاحتساب الضريبي (BT-6) بقيمة غير SAR
BR-KSA-68 يرفض الفاتورة
عملة الاحتساب الضريبي (BT-6) غير موجودة

أسئلة شائعة

فاتورتي تمرّ بإجازة مسبقة لا بتبليغ — أليست لها قيمة أخرى؟ +
لا. القاعدة تسمّي نصًّا واحدًا بلا شرط، وليس في القواعد المستخرجة غيرُها يتكلم عن BT-23. والمسار — إجازة مسبقة أم تبليغ — يقرّره نوع المستند في KSA-2 وواجهة الهيئة التي تناديها، لا هذا الحقل.
هل هو رقم إصدار ألاحقه؟ +
عامله ثابتًا لا متغيّرًا. هو نص حرفي في قواعد التحقق التي استخرجناها، ولا علاقة له بإصدار برنامجك ولا بإصدار تكاملك ولا بإصدار المكتبة التي تستعملها. وإن غيّرته مواصفة لاحقة فمصدر الخبر zatca.gov.sa.
أين موضعه بالضبط؟ +
في رأس المستند: بعد كتلة الامتدادات التي تحمل التوقيع، وقبل رقم الفاتورة ومعرّفها الفريد وتاريخها. وترتيب عناصر الرأس في UBL ليس حرًّا، فوضعه في غير موضعه يُخرج ملفًا لا يطابق المخطط قبل أن يصل إلى هذه القاعدة أصلًا.
أصلحت هذه — ولا تريد التالية

ZATCA Tools يبني التوقيع والبصمة والعدّاد والترميز عنك، ويتحقق من البيانات قبل الإرسال. ابدأ مجانًا، وبدون بطاقة ائتمانية.

ابدأ مجانًا

← كل أكواد أخطاء ZATCA