BR-KSA-15 تحذير — الفاتورة تُقبل

الفاتورة الضريبية بلا تاريخ توريد (KSA-5)

الفاتورة الضريبية تحمل تاريخين منفصلين: تاريخ إصدارها وتاريخ التوريد. والثاني إلزامي بنص القاعدة وإن كانت درجتها تحذيرًا، ويغيب كثيرًا عن فواتير الخدمات والعقود الشهرية لأن عنصره في XML اسمه Delivery، فيبدو خاصًا بالشحن.

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

The tax invoice ((invoice type code (BT-30) = 388) and (invoice transaction code (KSA-2) has "01" as first 2 digits)) must contain the supply date (KSA-5).

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

القاعدة تخصّ الفاتورة الضريبية وحدها: نوع المستند 388 مع ترميز معاملة (KSA-2) أول خانتين فيه 01. فلا تسمّي الإشعار الدائن (381) ولا المدين (383) ولا الفاتورة المبسطة (02). ولاحظ أن الرسالة أعلاه تسمّي نوع المستند BT-30، بينما تسمّيه بقية القواعد — ومنها BR-KSA-05 — BT-3؛ والعنصر في الحالين واحد: cbc:InvoiceTypeCode.

وتاريخ التوريد (KSA-5) هو العنصر cbc:ActualDeliveryDate داخل cac:Delivery في مستوى الفاتورة، ويُكتب بصيغة YYYY-MM-DD كبقية التواريخ (BR-KSA-F-01). وهو غير تاريخ الإصدار (BT-2) في cbc:IssueDate: الأول يقول متى وقع التوريد، والثاني متى صدر المستند، وقد يختلفان.

واسم العنصر يضلّل من يبيع خدمة: Delivery يوحي بشحنة تُسلَّم، فتظن شركة الصيانة أو الاستشارات أن الحقل لا يخصّها فتحذفه. والقاعدة تسمّيه تاريخ التوريد، وتشترطه في كل فاتورة ضريبية بلا تفريق بين سلعة وخدمة.

وإلى جانبه في الكتلة نفسها تاريخ نهاية التوريد (KSA-24) في cbc:LatestDeliveryDate، وبه يعبّر المستند عن فترة لا عن يوم. ولا توجد في القائمة قاعدة تشترطه على الفاتورة الضريبية، لكنه متى وُجد جرّ قاعدتين: BR-KSA-35 تطلب معه تاريخ التوريد، وBR-KSA-36 تشترط ألا يسبق تاريخُ النهاية تاريخَ التوريد — وكلتاهما تحذير. أما الفاتورة المبسطة الملخّصة فتطلب التاريخين معًا بنص BR-KSA-72، ودرجتها خطأ.

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

لماذا يحدث؟

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

  • كتلة cac:Delivery لا تُبنى إلا حين يوجد عنوان شحن — منطق متجر إلكتروني — فتخرج فواتير الخدمات والعقود بلا تاريخ توريد.
  • قالب مبني على المواصفة الأوروبية EN 16931 حيث تاريخ التسليم اختياري، فيمرّ من التحقق الأوروبي ويسقط هنا.
  • نظام فوترة دورية يولّد فاتورة الشهر من العقد بتاريخ إصدار وحده، ويترك فترة الخدمة لملاحظة نصية حرة.
  • تاريخ نهاية التوريد (KSA-24) مُرسَل وحده لفترة الخدمة دون تاريخ التوريد، فيجتمع هذا التحذير مع BR-KSA-35.

كيف تصلحه

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

  1. 1
    أخرِج الكتلة في كل فاتورة ضريبية

    cac:Delivery في مستوى الفاتورة وفيها cbc:ActualDeliveryDate بصيغة YYYY-MM-DD، على كل مستند نوعه 388 وترميزه يبدأ بـ 01 — سلعةً كان المبيع أو خدمة، وبعنوان شحن أو بدونه.

  2. 2
    حدّد مصدر التاريخ مرة واحدة

    في بيع يُسلَّم يوم فوترته يتطابق التاريخان غالبًا. أما الفاتورة التي تصدر قبل التوريد أو بعده — قسط عقد، أو خدمة نُفّذت الأسبوع الماضي — فاجعل لتاريخ التوريد مصدره في نظامك بدل نسخ تاريخ الإصدار آليًا. وأيّ يوم يُعدّ تاريخ التوريد لخدمة مستمرة سؤال ضريبي مرجعه zatca.gov.sa، لا سؤال XML.

  3. 3
    للفترة حقلان

    إن كانت الفاتورة تغطي فترة — شهرًا من عقد صيانة مثلًا — فالملف يملك لها حقلين في الكتلة نفسها: تاريخ التوريد (KSA-5) وتاريخ نهاية التوريد (KSA-24)، على ألا تسبق النهايةُ تاريخَ التوريد (BR-KSA-36). والفترة المكتوبة نصًّا في ملاحظة لا تقوم مقام أيٍّ منهما. وطريقة فوترة العقد الدوري قسطًا قسطًا في عقد الصيانة الدوري والفوترة الإلكترونية.

  4. 4
    أصلح المُولِّد لا الفاتورة

    الفاتورة التي حملت التحذير مُجازة ولا تحتاج إعادة إصدار لتُقبل. أصلح بناء الـ XML حتى يكتب الحقل دائمًا فتخرج الفواتير التالية نظيفة، وراجع معه وقت الإصدار (KSA-25)، فهو حقل آخر يغيب عن الأنظمة التي لا تخزّن إلا التاريخ: BR-KSA-70.

هذا الكود لا يمنع القبول، فالفاتورة الحالية نظامية. صحّح البيانات لتختفي التحذيرات من الفواتير القادمة.

هل يمنعه ZATCA Tools؟

نعم، في كل مسار. كل فاتورة ضريبية يصدرها ZATCA Tools تحمل تاريخ التوريد: نموذج الفاتورة يجعله مساويًا لتاريخ الفاتورة ما لم تغيّره من «تاريخ الخدمة»، والـ API يقرأ supply_date ويجعله تاريخ الإصدار إن لم يُرسَل، وتحويل عرض السعر إلى فاتورة يأخذ يوم التحويل. ومُولِّد الحمولة نفسه يكتب تاريخ الإصدار إن وصلته فاتورة ضريبية بلا تاريخ توريد مخزَّن، فلا يخرج ملف ضريبي من عندنا بلا KSA-5 — والإشعار الدائن أو المدين على فاتورة ضريبية يحمله كذلك بيوم إصداره وإن لم تطلبه هذه القاعدة. والمستند المطبوع يسمّيه «تاريخ الخدمة». والذي لا نملكه بالأمانة نفسها: تاريخ نهاية التوريد (KSA-24)، فلا حقل له في النموذج ولا في الـ API، والفاتورة التي تغطي شهرًا تحمل في ملفها تاريخًا واحدًا — ولهذا أيضًا لا يمكن أن يصل منّا BR-KSA-35 ولا BR-KSA-36.

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

BR-KSA-35
نص الرسالة الرسمي فيالمرجع الكامل.
BR-KSA-36
نص الرسالة الرسمي فيالمرجع الكامل.
BR-KSA-72
نص الرسالة الرسمي فيالمرجع الكامل.
BR-KSA-70 يرفض الفاتورة
وقت إصدار الفاتورة (KSA-25) ناقص أو بصيغة خاطئة

أسئلة شائعة

هل يرفض هذا الكود فاتورتي؟ +
لا. درجته تحذير: الفاتورة تُجاز ويُسجَّل التحذير معها. لكن الحقل إلزامي بنص القاعدة، والتحذير يتكرر مع كل فاتورة ضريبية ما دام نظامك لا يكتبه — فأصلح المُولِّد لا الفاتورة.
أفوتر عقدًا شهريًا في أول الشهر عن الشهر نفسه — أي تاريخ أكتب؟ +
القاعدة تشترط وجود الحقل ولا تحدد اليوم. والملف يملك لفترة كهذه حقلين: تاريخ التوريد (KSA-5) وتاريخ نهاية التوريد (KSA-24)، على ألا تسبق النهايةُ تاريخَ التوريد (BR-KSA-36). أما أيّ يوم يُعدّ تاريخ التوريد لخدمة مستمرة في نظام ضريبة القيمة المضافة فسؤال ضريبي مرجعه zatca.gov.sa، ولا نفتي فيه. والنصيحة العملية: قرّر القاعدة لعقودك مرة واحدة، وطبّقها في نظامك على كل قسط.
هل يجوز أن يختلف تاريخ التوريد عن تاريخ الفاتورة؟ +
هما حقلان منفصلان، ولا توجد بين القواعد الـ 135 التي نفهرسها قاعدة تقارن أحدهما بالآخر في نصّها: BR-KSA-04 تمنع تاريخ الإصدار وحده من المستقبل، وBR-KSA-36 تقارن تاريخ نهاية التوريد بتاريخ التوريد لا بتاريخ الإصدار. أما متى يجب أن تصدر الفاتورة بالنسبة إلى التوريد فمسألة نظامية مرجعها zatca.gov.sa.
نبيع خدمات لا تُسلَّم — لماذا عنصر Delivery؟ +
لأن الاسم موروث من UBL. والذي تفحصه القاعدة تاريخ التوريد، وهي تطلبه في كل فاتورة ضريبية سلعةً كان المبيع أو خدمة. فاكتب في cbc:ActualDeliveryDate تاريخ توريد الخدمة، ولا تحذف الكتلة لأن لا شحنة عندك.
هل يلزم في الفاتورة المبسطة والإشعارات؟ +
هذه القاعدة لا تسمّيها: شرطها نوع 388 مع ترميز يبدأ بـ 01. واستثناء واحد يستحق أن تعرفه: الفاتورة المبسطة الملخّصة — الخانة السادسة من KSA-2 تساوي 1 — تطلب تاريخ التوريد وتاريخ نهايته معًا بنص BR-KSA-72، ودرجتها خطأ لا تحذير.
أرسلت تاريخ نهاية التوريد فظهر BR-KSA-35 — ما الرابط؟ +
التاريخان زوج: متى وُجد تاريخ نهاية التوريد (KSA-24) لزم معه تاريخ التوريد (KSA-5). فالفاتورة الضريبية التي تحمل النهاية وحدها تجمع التحذيرين — هذا لغياب تاريخ التوريد، وذاك لنهاية بلا تاريخ توريد — ويزولان معًا بكتابة تاريخ التوريد.
أصلحت هذه — ولا تريد التالية

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

ابدأ مجانًا

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