كيف يتم إصدار إشعار دائن متوافق مع المرحلة الثانية للفوترة الإلكترونية



كيف يتم إصدار إشعار دائن متوافق مع المرحلة الثانية للفوترة الإلكترونية (فاتورة)؟

الإجابة المباشرة: الإشعار الدائن المتوافق مع متطلبات هيئة الزكاة والضريبة والجمارك هو مستند UBL 2.1 يحمل كود نوع المستند "381"، ويجب ربطه ربطاً تشفيرياً صارماً — عبر كتلة BillingReference وهاش الفاتورة السابقة (PIH) — بفاتورة ضريبية أصلية تم تخليصها (B2B) أو الإبلاغ عنها (B2C) مسبقاً عبر منصة فاتورة. يجب إصداره خلال 15 يوماً تقويمياً من نهاية الشهر الذي وقع فيه حدث التعديل، مع تضمين كود سبب الإصدار في حقل KSA-10 المطابق لأحد الحالات الخمس المعتمدة في قاموس بيانات الهيئة. إخفاق أي من هذه الاشتراطات الهيكلية أو الزمنية أو التشفيرية يؤدي إلى رفض فوري على بوابة واجهة الـ API لمنصة فاتورة، ويُعدّ المستند باطلاً نظامياً.

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

• الإطار النظامي بموجب المادة الأربعين من اللائحة التنفيذية لنظام ضريبة القيمة المضافة، والحالات الخمس المعتمدة التي تُجيز إصدار إشعار دائن وفق قاموس بيانات الهيئة.
• الفروقات الهيكلية والتشفيرية بين الإشعارات الدائنة الضريبية (B2B) المعالَجة وفق نموذج التخليص الفوري، والإشعارات الدائنة المبسطة (B2C) المُقدَّمة وفق نموذج الإبلاغ.
• وسوم XML الدقيقة وفق معيار UBL 2.1، وأنواع البيانات، والكتل المتداخلة اللازمة لاجتياز التحقق في المرحلة الثانية، بما تشمل InvoiceTypeCode وBillingReference وربط UUID وتجميع TaxTotal.
• أبرز خمسة أخطاء في التحقق وأكوادها في بيئة الهيئة التي تتسبب في الرفض ضمن البيئة التجريبية وبيئة الإنتاج على منصة فاتورة.
• قواعد الأتمتة والتحسين العملي وأفضل الممارسات المعمارية لمطوري أنظمة ERP وحلول إعداد الفواتير الإلكترونية (EGS) عند بناء مسارات عمل الإشعارات الدائنة المتوافقة مع اشتراطات الهيئة.

الضوابط النظامية للإشعارات الدائنة والحالات الخمس المعتمدة

الأساس النظامي: المادة الأربعون من اللائحة التنفيذية لنظام ضريبة القيمة المضافة

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

في إطار منظومة هيئة الزكاة والضريبة والجمارك، يؤدي الإشعار الدائن وظيفة مستند التعديل السلبي: إذ يُخفِّض القيمة الخاضعة للضريبة للتوريد الأصلي ويُقلِّص بالمقابل مبلغ ضريبة القيمة المضافة الذي سبق احتسابه والإبلاغ عنه. في المقابل، يُعدّل الإشعار المدين قيمة التوريد تعديلاً تصاعدياً. يتشارك النوعان هيكلاً برمجياً واحداً في معيار UBL 2.1، غير أنهما يتمايزان بقيم InvoiceTypeCode — "381" للإشعارات الدائنة و"383" للإشعارات المدينة — إذ يوفر خاصية name أعلاماً إضافية لمعالجة المستند في سلسلة ثنائية مؤلفة من ستة أرقام.

المدة النظامية الصارمة: قاعدة الخمسة عشر يوماً

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

الحالات الخمس المعتمدة حصراً لإصدار الإشعار الدائن

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

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

البنية التقنية لملف XML وتنسيق UBL 2.1

نظرة عامة: الفرق بين الإشعارات الدائنة الضريبية الإشعارات الدائنة المبسطة

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

الإشعارات الدائنة الضريبية (B2B — نموذج التخليص Clearance): تُصدَر هذه الإشعارات في مقابل فواتير ضريبية قياسية أصلية، وهي بحد ذاتها خاضعة للتخليص الفوري من الهيئة قبل أن تكتسب سريانها النظامي. لذا يجب أن يستند الإشعار الدائن الضريبي إلى فاتورة أصلية مُخلَّصة. يُقدَّم المستند إلى واجهة API للتخليص في منصة فاتورة، حيث تتحقق الهيئة من السلسلة التشفيرية ومرجع الفاتورة وكافة الحقول الهيكلية في الوقت الفعلي قبل إعادة ختم التخليص الرقمي. لا يكتسب الإشعار الدائن سريانه القانوني إلا بعد تلقي حالة "CLEARED" (مُخلَّص) من الـ API.

الإشعارات الدائنة المبسطة (B2C — نموذج الإبلاغ Reporting): تُصدَر هذه الإشعارات في مقابل فواتير ضريبية مبسطة. يُولّد حل إعداد الفواتير الإلكترونية (EGS) الإشعار الدائن المبسط محلياً، ويوقّعه بمفتاح ECDSA مرتبط بالجهاز، ويُضمّن رمز QR يحوي ستة حقول TLV إلزامية، ويُبلّغ به إلى واجهة API للإبلاغ في منصة فاتورة خلال 24 ساعة من الإصدار. لا يُشترط التخليص الفوري، غير أن السلسلة التشفيرية والتوقيع الرقمي ومحتويات رمز QR يجب أن تكون جميعها صحيحة هيكلياً وكاملة.

الوسم <cbc:InvoiceTypeCode name="381">

يُعدّ عنصر InvoiceTypeCode المُعرِّف الأساسي الذي يُنبّه منصة فاتورة إلى أن المستند المُقدَّم إشعار دائن لا فاتورة ضريبية. يحمل العنصر قيمتين في آنٍ معاً: قيمة رقمية "381" بوصفها محتوى نصياً للعنصر، وخاصية name تُرمّز أعلام المعالجة السلوكية الإضافية في سلسلة ثنائية مؤلفة من ستة أرقام مُتوافقة مع جدول أكواد نوع المستند السعودية.

بالنسبة للـ إشعار الدائن الضريبي (B2B) ضمن نموذج التخليص، تكون قيمة خاصية name هي "381000"، حيث تُرمّز الأرقام الثلاثة الأولى النوع الفرعي للمستند وتُرمّز الأرقام الثلاثة التالية أعلام المعالجة. أما بالنسبة للـ إشعار الدائن المبسط (B2C) ضمن نموذج الإبلاغ، فإن قيمة خاصية name هي "381100"، حيث تُشير الـ "1" في الموضع الرابع إلى علم الفاتورة المبسطة. يُوجب عدم التطابق بين قيمة خاصية name والبنية الفعلية للمستند فشلاً فورياً في التحقق من المخطط عند بوابة API لمنصة فاتورة.

في صيغة XML الخام تظهر هذه العناصر على النحو الآتي: للإشعار الدائن الضريبي القياسي (B2B) يُكتب <cbc:InvoiceTypeCode name="381000">381</cbc:InvoiceTypeCode>، وللإشعار الدائن المبسط (B2C) يُكتب <cbc:InvoiceTypeCode name="381100">381</cbc:InvoiceTypeCode>.

كتلة <cac:BillingReference>

تُعدّ كتلة BillingReference أهم العناصر المعمارية في هيكل الإشعار الدائن بأكمله، إذ تُثبّت الربط الإلزامي بنسبة 1 إلى 1 بين الإشعار الدائن وفاتورته الضريبية الأصلية. تشترط الهيئة أن يكون هذا المرجع واضحاً لا لبس فيه، ومكتملاً هيكلياً، ومقابلاً لفاتورة موجودة فعلاً في منظومة فاتورة بحالة CLEARED (مُخلَّص) أو REPORTED (مُبلَّغ عنه).

تتضمن الكتلة عنصرين فرعيين يعملان معاً: يجب أن يحوي عنصر <cbc:ID> داخل <cac:InvoiceDocumentReference> رقم الفاتورة المتسلسل الدقيق للفاتورة الضريبية الأصلية — حرفاً بحرف، بما يشمل أي بادئات أو أصفار ملحقة تُستخدم في نظام ERP الخاص بالمورد. هذا ليس حقل مطابقة تقريبية: يجب أن تتوافق القيمة تماماً مع معرف الفاتورة الذي قُدِّم وخُلِّص أو أُبلّغ عنه في المعاملة الأصلية. أي انحراف — بما يشمل المسافات الزائدة في النهاية، أو اختلاف الأحرف الكبيرة والصغيرة، أو بادئة الترقيم غير المتطابقة — سيُفعّل خطأ التحقق BR-KSA-56.

بالإضافة إلى الرقم المتسلسل للفاتورة القابل للقراءة البشرية، تشترط بنية الهيئة أيضاً أن يستند الإشعار الدائن إلى UUID الفاتورة الضريبية الأصلية. يُدرج الـ UUID داخل هيكل BillingReference جنباً إلى جنب مع InvoiceDocumentReference على النحو الآتي في XML الخام:

<cac:BillingReference> <cac:InvoiceDocumentReference> <cbc:ID>INV-2024-00123</cbc:ID> <cbc:UUID>6f4d3c2a-89b7-4e3f-a102-dc334f5e9876</cbc:UUID> </cac:InvoiceDocumentReference> </cac:BillingReference>

مطابقة الـ <cbc:UUID>

يجب أن يحوي عنصر <cbc:UUID> المضمَّن داخل BillingReference المُعرِّف الفريد عالمياً (UUID) المؤلَّف من 128 بت للفاتورة الضريبية الأصلية، مُنسَّقاً كسلسلة سداسية عشرية وفق المعيار 8-4-4-4-12. يُولّد حل إعداد الفواتير (EGS) هذا الـ UUID لحظة إنشاء الفاتورة الأصلية، ويجب تخزينه بصورة دائمة في قاعدة بيانات EGS أو ERP ليُسترجع عند توليد الإشعار الدائن المقابل.

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

الحقل الحرج KSA-10: <cbc:InstructionNote> — كود سبب الإصدار

الحقل KSA-10 — المُنفَّذ في XML كـ <cbc:InstructionNote> ضمن الكتلة المجمِّعة <cac:PaymentMeans> — هو كود السبب اللغوي الطبيعي الإلزامي الذي يجب إرفاقه بكل إشعار دائن أو مدين. هذا الحقل غير اختياري ولا يجوز إبقاؤه فارغاً أو حشوه بنص نائب عام. يجب أن يصف نص القيمة سبب التعديل بأسلوب يُعادل جوهرياً أحد الحوافز القانونية الخمسة المُحدَّدة في القسم الثاني.

قيمة PaymentMeansCode "10" هي الكود المُفروض من الهيئة لوسائل الدفع في الإشعارات الدائنة والمدينة ضمن نطاق الامتداد السعودي. رغم أن الهيئة لا تفرض مفردات مضبوطة بعينها لنص InstructionNote، يجب أن يكون المحتوى ذا معنى جوهري ويُحدد فئة الحافز القانوني بجلاء. قيمة مجردة كـ "تعديل" دون سياق مُحدِّد ستجتاز التحقق من المخطط لكن قد يُشار إليها خلال مراجعة الهيئة أو تفتيش ضريبي.

حقول <cac:TaxTotal> وسلسلة الهاش التشفيري

تتبع كتلة TaxTotal في الإشعار الدائن القواعد الهيكلية ذاتها المعمول بها في الفاتورة الضريبية القياسية، إلا أنها تستخدم قيماً نقدية سالبة تُمثّل الضريبة الجاري عكسها. يجب أن يكون TaxableAmount متوافقاً رياضياً مع مجموع كافة قيم LineExtensionAmount عبر جميع عناصر InvoiceLine في الإشعار الدائن، ويجب أن يساوي TaxAmount حاصل ضرب TaxableAmount في نسبة ضريبة القيمة المضافة المنطبقة، مع تطبيق التقريب إلى منزلتين عشريتين وفق قاعدة التقريب للأعلى عند منتصف النطاق على مستوى المجمِّع لا على مستوى سطور محسوبة مسبقاً. انحرافات قدرها ريال سعودي واحد فحسب بسبب منهجية تقريب خاطئة ستُفعّل خطأ عدم تطابق مجمِّع الضريبة.

سلسلة الهاش التشفيري — هاش الفاتورة السابقة (PIH): تشترط الهيئة لكل من الإشعارات الدائنة الضريبية والمبسطة تضمين المستند إشارة إلى الهاش SHA-256 للمستند السابق مباشرة في السلسلة المتسلسلة لحل إعداد الفواتير (EGS). يُخزَّن هذا الهاش في كتلة <cac:AdditionalDocumentReference> بمعرّف وثيقة "PIH". قيمة EmbeddedDocumentBinaryObject هي الهاش SHA-256 المُرمَّز بـ Base64 للـ XML المُعياري (Canonicalized) للمستند السابق مباشرة في سلسلة EGS المتسلسلة — وليس بالضرورة الفاتورة الأصلية المُشار إليها في BillingReference. هذا التمييز مصدر شائع للارتباك المعماري وأخطاء التنفيذ.

أشهر 5 أخطاء برمجية في التحقق وأكوادها

• الخطأ الأول: غياب مرجع الفاتورة الأصلية أو صياغته بشكل خاطئ (مخالفة BR-KSA-56)

تُلزم قاعدة الأعمال BR-KSA-56 الخاصة بالهيئة كلَّ إشعار دائن باحتواء BillingReference صالح يُشير إلى InvoiceID وUUID دقيقَيْن لفاتورة أصلية موجودة مُخلَّصة أو مُبلَّغ عنها مرتبطة برقم التسجيل الضريبي للمورد المُقدِّم. يتجلى هذا الخطأ في صورتين: إما غياب كتلة BillingReference كلياً عن مستند XML، أو عدم مطابقة قيمة <cbc:ID> داخل <cac:InvoiceDocumentReference> لأي فاتورة في منظومة الهيئة. تُفعّل كلتا الصورتين رفضاً فورياً من الـ API مع حمولة خطأ تُحدد صراحةً BR-KSA-56. يقتضي التصحيح استرجاع رقم الفاتورة الدقيق من التخزين الدائم لحل EGS وإعادة بناء كتلة BillingReference بأمانة على مستوى الحرف الواحد.

• الخطأ الثاني: عدم تطابق مجاميع الأسطر والضرائب وفروقات التقريب

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

• الخطأ الثالث: أخطاء ترميز رمز QR للإشعارات الدائنة المبسطة

يجب أن يُضمِّن الإشعار الدائن المبسط رمز QR يُرمِّز بالضبط ستة حقول بيانات بتنسيق Base64 TLV (وسم-طول-قيمة): اسم البائع، ورقم التسجيل الضريبي للبائع، والطابع الزمني للإصدار (بتنسيق ISO 8601)، وإجمالي الفاتورة شاملاً ضريبة القيمة المضافة، وإجمالي مبلغ ضريبة القيمة المضافة، وهاش SHA-256 لمستند XML الموقَّع. خطأ تنفيذي شائع يتمثل في توليد رمز QR قبل الانتهاء من توقيع مستند XML وإنهائه — مما يُفضي إلى هاش XML مُضمَّن خاطئ — أو إغفال أحد الحقول الستة الإلزامية لـ TLV. تتحقق واجهة API للإبلاغ في منصة فاتورة من محتويات رمز QR مقارنةً بالـ XML المُقدَّم، وأي عدم تطابق يُوقف طلب الإبلاغ باستجابة خطأ مهيكلة.

• الخطأ الرابع: خطأ سلسلة الهاش التشفيري — عدم تطابق PIH

يجب أن يكون هاش الفاتورة السابقة (PIH) المُخزَّن في كتلة AdditionalDocumentReference هاش SHA-256 للـ XML المُعياري للمستند السابق مباشرة في السلسلة المتسلسلة لحل EGS. خطأ شائع يقع حين يُعيد مطورو ERP تهيئة سلسلة الهاش أو إعادة ضبطها عقب عطل نظام أو استعادة قاعدة بيانات، مما يجعل الـ PIH في المستند التالي المُقدَّم يستند إلى هاش لا تتعرف عليه سجلات الهيئة ولا تتوقعه. يكسر هذا سلسلة السجل التشفيري لوحدة EGS تلك. يستلزم التصحيح عادةً التواصل مع الهيئة عبر قناة امتثال رسمية لطلب إجراء إعادة ضبط السلسلة، الذي ينطوي على إعادة توفير بيانات اعتماد جهاز EGS.

• الخطأ الخامس: مخالفة تسلسل التخليص التزامني للإشعارات B2B

لا يجوز قانونياً للإشعار الدائن الضريبي (B2B) الاستناد إلا إلى فاتورة ضريبية قياسية أصلية حققت بالفعل حالة "CLEARED" (مُخلَّص) على منصة فاتورة. محاولة تقديم إشعار دائن في مقابل فاتورة بحالة PENDING (قيد الانتظار) أو FAILED (فاشلة) أو REJECTED (مرفوضة) — أو فاتورة لم تُقدَّم أصلاً إلى الهيئة — تُشكّل مخالفة لتسلسل التخليص. تُعيد واجهة API لمنصة فاتورة خطأً يفيد بأن الفاتورة المُشار إليها غير موجودة بحالة مُخلَّصة. يجب أن تُنفِّذ مسارات التكامل في ERP آلية فحص حالة تتحقق من حالة تخليص الفاتورة الأصلية قبل الشروع في توليد الإشعار الدائن وتقديمه. مسار عمل إشعار دائن يخلو من هذا الفحص الأولي هو مسار غير مكتمل معمارياً.

اقرأ أيضًا: أخطاء الفوترة الإلكترونية الشائعة وكيفية تجنبها في السعودية.

كيف تتعامل وافِق مع الإشعارات الدائنة المتوافقة مع متطلبات هيئة الزكاة والضريبة والجمارك؟

إدارة التعقيدات التقنية للإشعارات الدائنة في المرحلة الثانية من الفوترة الإلكترونية يدوياً ليست خياراً عملياً أو قابلاً للتوسع للمنشآت العاملة في المملكة العربية السعودية. وهنا يأتي دور وافِق بدعم مباشر ومدمج لكل هذه المتطلبات.

وافِق هو نظام محاسبة سحابي معتمد من هيئة الزكاة والضريبة والجمارك، يُؤتمت كل اشتراط هيكلي وتشفيري تناوله هذا الدليل. عند إصدار إشعار دائن داخل وافِق، يُسند النظام تلقائياً كود نوع المستند "381" الصحيح، ويسترجع الرقم المتسلسل وUUID الخاص بالفاتورة الأصلية لبناء كتلة BillingReference صالحة، ويحتسب مجاميع الضريبة على مستوى المجمِّع بتمريرة تقريب واحدة صحيحة، ويُولّد PIH من المستند السابق في سلسلة EGS، ويُقدّم المستند إلى واجهة API للتخليص أو الإبلاغ في منصة فاتورة بحسب نوع المعاملة.

بالنسبة للإشعارات الدائنة المبسطة B2C، يُولّد حل EGS المدمج في وافق توقيع ECDSA محلياً باستخدام CSID الخاص بمنشأتك، ويُرمّز الحقول الستة الإلزامية في رمز QR قبل إنهاء المستند. أما للإشعارات الدائنة الضريبية B2B، فيُجري وافق فحصاً مسبقاً لحالة تخليص الفاتورة الأصلية قبل السماح بتوليد الإشعار الدائن — ما يُلغي خطأ مخالفة تسلسل التخليص من جذره على مستوى مسار العمل.

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

اقرأ أيضًا: لماذا ترفض منصة فاتورة فواتيرك؟ [مع حلول عملية لأخطاء الربط والتكامل]

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

الأسئلة المتداولة حول الإشعارات الدائنة

هل يسمح نظام هيئة الزكاة والضريبة والجمارك بإصدار إشعار دائن واحد لعدة فواتير ضريبية؟

لا. يُوجب الإطار التنظيمي لهيئة الزكاة والضريبة والجمارك وتطبيقها لمعيار UBL 2.1 علاقة 1 إلى 1 صارمة بين الإشعار الدائن والفاتورة الضريبية الأصلية التي يُعدِّلها. هذا القيد ليس مجرد اصطلاح تقني — بل يُطبَّق معمارياً عبر كتلة BillingReference التي تستوعب بالضبط عنصر InvoiceDocumentReference واحداً يُشير إلى رقم متسلسل وUUID لفاتورة أصلية واحدة. سبب هذا الربط الصارم هو الحفاظ على السلسلة التدقيقية التشفيرية: يجب أن يُردَّ كل إشعار دائن إلى مستند واحد لا لبس فيه مُخلَّص أو مُبلَّغ عنه. إن احتاج المورد إلى إصدار تعديلات لثلاث فواتير منفصلة، وجب توليد ثلاثة إشعارات دائنة مستقلة وتقديمها إلى منصة فاتورة كل على حدة. تجميع تعديلات فواتير متعددة في مستند إشعار دائن واحد سيُخفق في التحقق من قاعدة الأعمال BR-KSA-56.

ماذا يحدث إذا رُفض الإشعار الدائن أثناء عملية التخليص الفوري عبر واجهة الـ API؟

حين يُخفق الإشعار الدائن الضريبي (B2B) في التحقق من واجهة API للتخليص الفوري لمنصة فاتورة، تُعيد المنصة استجابة HTTP 400 أو HTTP 422 تحوي حمولة خطأ مهيكلة تُحدد قواعد الأعمال المخالَفة ومسارات XML المسؤولة عن الفشل. لا يُخلَّص الإشعار الدائن، ولا يجوز تقديمه قانونياً للمشتري ولا تسجيله في حسابات ضريبة القيمة المضافة للمورد. يجب على ERP أو نظام إعداد الفواتير تحليل حمولة الخطأ، وتحديد الأسباب الجذرية لكل فشل في التحقق، وتوليد نسخة XML جديدة ومصحَّحة — لا نسخة مُرقَّعة من المستند الفاشل. يجب أن تحمل النسخة الجديدة رقم الفاتورة ذاته لكنها تشتمل على طابع زمني توقيع مُحدَّث وتوقيع ECDSA محسوب من جديد. يجب أن يعكس PIH في إعادة التقديم هاش آخر مستند مُخلَّص أو مُبلَّغ عنه بنجاح في سلسلة EGS — لا هاش التقديم الفاشل الذي لم يُسجَّل في سجل الهيئة.

هل يجب أن يحتوي الإشعار الدائن المبسط (B2C) على توقيع رقمي؟

نعم. يُلزَم الإشعار الدائن المبسط الصادر في نموذج الإبلاغ B2C بحمل توقيع رقمي وفق خوارزمية ECDSA (خوارزمية التوقيع الرقمي للمنحنى الإهليلجي) مُولَّد محلياً بواسطة جهاز حل إعداد الفواتير. بخلاف الإشعارات الدائنة الضريبية التي تتلقى ختم تخليص رقمي من خوادم الهيئة أثناء التخليص الفوري، يوقِّع حل EGS الإشعارات الدائنة المبسطة ذاتياً بشهادة رقمية مرتبطة بالجهاز تم توفيرها خلال عملية الإعداد لدى الهيئة — وتحديداً CSID (معرِّف الختم التشفيري) الصادر أثناء تبادل API لمرحلة الامتثال. يُضمَّن التوقيع الرقمي في XML ضمن عنصر <ds:SignatureValue> داخل كتلة امتداد UBL. علاوة على ذلك، يجب أن يشمل رمز QR المطبوع أو المعروض على الإشعار الدائن المبسط هاش SHA-256 لـ XML الموقَّع بوصفه أحد حقوله الستة الإلزامية في TLV، مما يكفل ارتباطاً تشفيرياً وتأميناً ضد التلاعب بين المستند المطبوع والـ XML المُبلَّغ عنه. حل EGS يُصدر إشعارات دائنة مبسطة دون توقيع ECDSA صالح يُعدّ في مخالفة صريحة للمعايير التقنية للمرحلة الثانية لهيئة الزكاة والضريبة والجمارك.

كيف يميز نظام المنشأة الصغيرة بين الإشعار الدائن والإشعار المدين داخل هيكل ملف XML؟

يتحقق التمييز بين الإشعار الدائن والإشعار المدين في معيار UBL 2.1 الخاص بهيئة الزكاة والضريبة والجمارك كلياً عبر عنصر <cbc:InvoiceTypeCode>. يجب أن يستخدم الإشعار الدائن — الذي يُخفِّض القيمة الخاضعة للضريبة لتوريد أصلي ويُقلِّص الالتزام الضريبي للمورد — قيمة الكود "381". في المقابل، يجب أن يستخدم الإشعار المدين — الذي يرفع القيمة الخاضعة للضريبة لتوريد أصلي ويزيد الالتزام الضريبي للمورد — قيمة الكود "383". تتغير خاصية name لعنصر InvoiceTypeCode تبعاً لذلك: "381000" أو "381100" للإشعارات الدائنة الضريبية والمبسطة على التوالي، و"383000" أو "383100" للإشعارات المدينة الضريبية والمبسطة على التوالي. يتشارك النوعان هياكل BillingReference متطابقة، واشتراطات ربط UUID، والتزامات حقل InstructionNote في KSA-10، وسلسلة الهاش التشفيري استناداً إلى PIH. قيمة InvoiceTypeCode هي المفتاح الثنائي الوحيد الذي يُحدد ما إذا كان المستند يُعالَج كتعديل مالي تنازلي أو تصاعدي في سجل الهيئة التدقيقي.