BR-KSA-05: رمز نوع الفاتورة غير صالح (BT-3)
BR-KSA-05: Invalid Invoice Type Code (BT-3)
يجب أن يطابق رمز نوع الفاتورة (BT-3) أحد الرموز المعيارية: 388 للفواتير، 381 للإشعار الدائن، 383 للإشعار المدين، 386 لفواتير الدفع المقدم.
/ubl:Invoice/cbc:InvoiceTypeCode 📌 نبذة عن القاعدة وسبب التدقيق
رمز نوع الفاتورة يجب أن يكون أحد رموز UN/CEFACT 1001 المعتمدة: 388 (فاتورة ضريبية)، 381 (إشعار دائن)، 383 (إشعار مدين)، 386 (دفعة مقدمة).
⚠️ الأسباب الشائعة لظهور الخطأ ورفض الفاتورة
- ✕ استخدام رمز غير مدعوم مثل 380 أو نصوص مخصصة بدلاً من الرموز المعتمدة
- ✕ وجود مسافات زائدة داخل عنصر <cbc:InvoiceTypeCode>
- ✕ عدم توافق هيكل المستند مع نوع الإشعار المرسل
✅ خطوات الحل وتصحيح الفاتورة
اختيار الرمز المعتمد
استخدم 388 للفواتير الضريبية والمبسطة، 381 للإشعار الدائن، 383 للإشعار المدين، 386 للدفعات المقدمة.
إضافة خاصية name لكود المعاملة
تأكد من احتواء خاصية name على رمز المعاملة السباعي NNPNESB.
💻 نموذج برمجي لمقارنة ملف XML (قبل وبعد التصحيح)
<cbc:InvoiceTypeCode name="0100000">380</cbc:InvoiceTypeCode><cbc:InvoiceTypeCode name="0100000">388</cbc:InvoiceTypeCode>تحقق من صحة ملف الفاتورة الآن مجاناً
استخدم أدوات قيمة لفحص بنية XML والتأكد من عدم وجود أخطاء قبل إرسال الفواتير لمنصة زاتكا.
❓ الأسئلة الشائعة حول BR-KSA-05
ما هو الرمز المستخدم للفاتورة الضريبية المبسطة؟
تستخدم الفاتورة الضريبية المبسطة نفس الرمز 388، ويتم تمييزها بخاصية name="0200000".
🔗 قواعد وأخطاء زاتكا ذات صلة
BR-KSA-06: كود المعاملة الفرعية للفاتورة غير صحيح (NNPNESB / KSA-2)
كود المعاملة (KSA-2) في خاصية name يجب أن يتكون من 7 خانات وفق هيكلية NNPNESB المعتمدة من زاتكا.
BR-KSA-56: مرجع الفاتورة الأصلية إلزامي للإشعارات الدائنة والمدينة
للإشعارات الدائنة (381) والمدينة (383)، يجب تضمين رقم الفاتورة المرجعية الأصلية (BT-25) في عقدة BillingReference.
ودّع مشاكل الربط وأخطاء الفوترة مع برنامج قيمة
يتكفل نظام قيمة بكافة متطلبات هيئة الزكاة والضريبة والجمارك تلقائياً في الخلفية: اعتماد فوري للفواتير، توقيع رقمي، وربط كامل مع منصة فاتورة.