BR-KSA-71الفاتورة المبسطة الملخَّصة لا تسمّي المشتري

يفحص مطابق ملف XML للفاتورة الإلكترونية في المرحلة الثانية قبل إرساله: تحقق مسبق وفق متطلبات هيئة الزكاة والضريبة والجمارك المنشورة، لا اعتماداً من الهيئة. وتشرح هذه الصفحة قاعدة واحدة هي BR-KSA-71.

افحص 5 فواتير مجاناً

خمس عمليات فحص شهرياً في باقة المجان. يُفحص الملف في الذاكرة ولا يُحفظ.

الرسالة كما تنشرها هيئة الزكاة والضريبة والجمارك

If the Invoice is a simplified invoice type and is a summary invoice (KSA-2, position 1 and 2 = 02, position 6 = 1),then the buyer name must be present.

ما الذي يذكره مطابق

مدخل لكل حالة تُذكر فيها هذه القاعدة في التقرير.

صورة القيمة في التقرير
صورة القيمة التي وُجدت — empty وnot_15_digits وما شابههما — لا القيمة نفسها.

الفاتورة المبسطة الملخَّصة لا تسمّي المشتري

صورة القيمة في التقريرname_element_missingعنصر الاسم غير موجود

ما الخلل

كتلة طرف المشتري لا تحمل عنصر cbc:RegistrationName تحت أي عنصر cac:PartyLegalEntity في أي موضع تحتها، فاسم المشتري غائب. ويرصد الإصدار 3.4.8 من حزمة أدوات التطوير SDK التي تنشرها هيئة الزكاة والضريبة والجمارك ذلك بموجب القاعدة BR-KSA-71 تحذيراً لا خطأً، فالتحذير وحده لا يؤدي إلى رفض المستند. وهذه القاعدة تخصّ اسم المشتري لا عنوانه، مهما أوحى موضعها في قائمة القواعد بغير ذلك: فهي تقرأ العنصر cbc:RegistrationName تحت أي عنصر cac:PartyLegalEntity يقع في أي موضع تحت cac:AccountingCustomerParty/cac:Party مهما تعمّق، وهو المصطلح نفسه الذي تقرؤه القاعدة BR-KSA-42 عبر مسار أضيق منه. وكانت الإصدارات السابقة (3.0.8) تشترط كذلك أن يكون العنصر cac:Country/cbc:IdentificationCode للمشتري مساوياً لـ SA تماماً، وكان شرط دخولها يحمل خطأً مطبعياً جعلها لا تُبلَغ إلا على رمز نوع معاملة يحمل المحرف 6 في موضعه السادس، وهو رمز لا تحمله أي فاتورة مطابقة، فكادت القاعدة لا تُرصد قطّ. أما الإصدار 3.4.8 فأسقط شرط الدولة وصحّح شرط الدخول إلى رمز نوع المعاملة الذي تصفه رسالة الهيئة نفسها (KSA-2 يبدأ بـ 02 وموضعه السادس يساوي 1)، فصارت هذه القاعدة تُرصد على الفاتورة المبسطة الملخَّصة المعتادة التي لا تسمّي المشتري، أياً كانت دولته.

ما الذي تتحقق منه في وحدة الفوترة الإلكترونية

موضع النظر اسم المشتري نفسه: كتلة المشتري في الفاتورة المبسطة مختصرة أو غائبة عادةً لأن العميل مستهلك نهائي؛ فإن كنت تقصد تسمية المشتري فموضع الاسم هو cac:PartyLegalEntity/cbc:RegistrationName لا cac:PartyName/cbc:Name الذي لا يقرؤه هذا الفحص.

اسم المشتري في الفاتورة المبسطة الملخَّصة فارغ

صورة القيمة في التقريرname_emptyالاسم موجود لكنه فارغ

ما الخلل

كتلة طرف المشتري تحمل تحتها العنصر cbc:RegistrationName لكن كل نسخة منه فارغة، فاسم المشتري بلا قيمة. ويرصد الإصدار 3.4.8 من حزمة أدوات التطوير SDK التي تنشرها هيئة الزكاة والضريبة والجمارك ذلك بموجب القاعدة BR-KSA-71 كما يرصد غياب الاسم، تحذيراً لا خطأً، فالتحذير وحده لا يؤدي إلى رفض المستند. ويكفي اسم واحد غير فارغ تحت كتلة طرف المشتري لتحقيق الفحص، فظهور هذه الملاحظة يعني أنها كلها خالية. وهذه القاعدة تخصّ اسم المشتري لا عنوانه، مهما أوحى موضعها في قائمة القواعد بغير ذلك: فهي تقرأ العنصر cbc:RegistrationName تحت أي عنصر cac:PartyLegalEntity يقع في أي موضع تحت cac:AccountingCustomerParty/cac:Party مهما تعمّق، وهو المصطلح نفسه الذي تقرؤه القاعدة BR-KSA-42 عبر مسار أضيق منه. وتسري على الفاتورة المبسطة الملخَّصة، أي ما يبدأ رمز نوع معاملة الفاتورة KSA-2 فيه بـ 02 وموضعه السادس يساوي 1، كما تصفها رسالة الهيئة نفسها. وكانت الإصدارات السابقة (3.0.8) تحمل شرط دخول فيه خطأ مطبعي جعل القاعدة لا تُبلَغ إلا على رمز يحمل المحرف 6 في ذلك الموضع، وتشترط كذلك أن يكون العنصر cac:Country/cbc:IdentificationCode للمشتري مساوياً لـ SA تماماً؛ فصحّح الإصدار 3.4.8 الأول وأسقط الثاني.

ما الذي تتحقق منه في وحدة الفوترة الإلكترونية

البنية تُكتب والقيمة لا تُكتب، وهذا يعني عادةً أن التصدير يُخرج كتلة الكيان النظامي للمشتري في كل مستند بينما يأتي الاسم من حقل خالٍ في حالة العميل العابر أو العميل النقدي. فإما أن يُملأ الحقل وإما أن يُكفّ عن إخراج الكتلة في المستندات التي لا مشترٍ مسمّى فيها.

الفحص الذي يُنفَّذ

منقول حرفياً من ملفات قواعد التحقق التي تنشرها الهيئة، عند الملف والسطر المذكورين أدناه. والتعبير المُنفَّذ هو ما يُقيَّم على المستند، أما التعبير المذكور في التقرير فهو ما يظهر عند الإخفاق، وهما لا يتطابقان دائماً.

التعبير المُنفَّذ

not(exists(//cac:AccountingCustomerParty/cac:Party//cac:PartyLegalEntity/cbc:RegistrationName) and normalize-space(//cac:AccountingCustomerParty/cac:Party//cac:PartyLegalEntity/cbc:RegistrationName)!='')

التعبير المذكور في التقرير

not(exists(//cac:AccountingCustomerParty/cac:Party//cac:PartyLegalEntity/cbc:RegistrationName) and //cac:AccountingCustomerParty/cac:Party//cac:PartyLegalEntity/cbc:RegistrationName !='')
العناصر التي يُقيَّم عليها
cbc:InvoiceTypeCode[substring(@name, 1, 2) = '02']
المصدر
vendor/zatca/schematron/20210819_ZATCA_E-invoice_Validation_Rules.xsl:2078

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

مثال عملي

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

المستند
bad-47-simplified-summary-no-buyer-name.xml
ما حكم به مطابق
اجتاز
صورة القيمة في التقرير
name_element_missingعنصر الاسم غير موجود

نزّل هذا المثال (.xml)افحصه في مطابق

مثال هذه الصفحة، يُفحص بالقواعد نفسها التي يمر بها ملفك عند الرفع. بلا رفع وبلا تسجيل دخول.

قواعد تُقيَّم على الموضع نفسه من المستند، وكثيراً ما تُرصد عدة قواعد منها معاً بسبب قيمة واحدة خاطئة.

افحص فاتورة

افحص فاتورتك

© 2026 Hayatiq AI Solutions F.Z.E. جميع الحقوق محفوظة.