All currencyID attributes (BT-5) must have the same value as the invoice currency code (BT-5), except for the invoice total VAT amount in accounting currency (BT-111).
ماذا يعني هذا؟
كل عنصر مالي في UBL يُكتب ومعه الخاصية currencyID: صافي البند، وسعر الوحدة، ومبلغ ضريبة البند، وكل تفصيل ضريبي، ومجموع الضريبة، والمبالغ السبعة في cac:LegalMonetaryTotal. وهذه القاعدة تقول: كلها بلا استثناء تحمل القيمة التي في cbc:DocumentCurrencyCode نفسها.
والاستثناء واحد تسمّيه الرسالة باسمه: مجموع ضريبة الفاتورة بعملة الاحتساب (BT-111). هذا المبلغ يحمل عملة الاحتساب لأنه مُعبَّر بها فعلًا. والقاعدة اضطرت إلى استثنائه لأن عملة الاحتساب مثبَّتة على SAR بنص BR-KSA-EN16931-02، بينما عملة الفاتورة حرة — فالفاتورة بعملة أجنبية تحمل بالضرورة مبلغًا واحدًا بعملة تخالف بقيتها، وهو هذا وحده.
وأربع قواعد تحيط بالعملة، وترتيبها يوفّر عليك جولات: BR-KSA-CL-01 تسأل هل قيمة عملة الفاتورة رمز معتمد، وهذه تسأل هل يردّدها المستند كله، وBR-KSA-68 تسأل هل عملة الاحتساب موجودة، وBR-KSA-EN16931-02 تسأل هل قيمتها SAR. صحةٌ واتساقٌ ووجودٌ وقيمة — أربعة أسئلة على حقلين.
وأشيع آلية تولّد هذا الكود أن للقيمة بابين لا بابًا واحدًا: عنصر الترويسة يُقرأ من سجل الفاتورة، وخاصية currencyID تُكتب من قيمة افتراضية في المُسلسِل أو في مُنسِّق المبالغ. والمكتبة التي يستعملها ZATCA Tools تفعل هذا حرفيًا: كل خاصية currencyID في الملف تُكتب من متغيّر ساكن واحد يُضبط عند استدعاء المُولِّد، والترويسة تأتي من الحمولة. فمن غيّر أحدهما ونسي الآخر أخرج مستندًا يمرّ من CL-01 ويسقط هنا — وهو أشبه ما يكون بالمستند الصحيح حين تقرؤه بعينك.
لماذا يحدث؟
مرتّبة من الأشيع إلى الأقل شيوعًا — الأرجح أن سببك في الأول أو الثاني.
- قالب جُمِّع يدويًا: غُيّرت الترويسة إلى عملة العميل وبقيت خصائص البنود والضريبة على قيمة القالب.
- نظام فيه عملة على مستوى السطر — قوائم أسعار متعددة العملات — فيخرج كل بند بالعملة التي خُزِّن بها سعره.
- مصدران لقيمة واحدة كما سبق: الترويسة من سجل الفاتورة، والخاصية من قيمة افتراضية في المكتبة.
- كتلة منسوخة من مستند أقدم بعملة أخرى: بند شحن مضاف، أو سطر تقريب، أو سطر في إشعار دائن.
-
خاصية فارغة على أحد المبالغ. والفراغ لا يساوي
SAR— وهذا ما نرجّحه من نص القاعدة، وإن كنا لا نقرأ شرط التنفيذ نفسه لنجزم أيقع هنا أم في فحص المخطط. - حروف صغيرة أو علامة عملة في خاصيةٍ أصابت الترويسةُ صيغتَها، فالمقارنة هنا مقارنة نصّ لا مقارنة معنى.
كيف تصلحه
3 خطوات، ثم أعد إرسال الفاتورة.
-
1
ابحث عن currencyID في ملفك
بحث نصّي واحد يجيبك: كل ظهور للخاصية يجب أن يقرأ الحروف الثلاثة نفسها التي في
cbc:DocumentCurrencyCode. وهي أكثر مما يُظن أول مرة — على كل بند مرتين على الأقل، وعلى كل تفصيل ضريبي، وعلى مجموع الضريبة، وعلى سبعة مبالغ في إجماليات المستند. والشاذّة واحدة تكفي. -
2
اجعل للقيمة مصدرًا واحدًا
ثابت واحد على المستند يقرؤه عنصر الترويسة وتقرؤه كل خاصية. وإن كانت مكتبتك تضبط الخاصية من موضع مستقل عن الحمولة — وهذا شائع — فاضبط البابين معًا، ولا تكتفِ بالذي تراه في الترويسة لأنه الأظهر.
-
3
واترك BT-111 كما هو
مجموع الضريبة بعملة الاحتساب هو الاستثناء المنصوص عليه، ويحمل SAR. وتوحيده مع بقية المبالغ في فاتورة بعملة أجنبية يصلح هذا الكود ويكسر
BR-KSA-97، فهي تتوقع اختلاف مبلغَي الضريبة متى كانت عملة الفاتورة غير الريال. وبنية تلك الكتلة الثانية نفسها شأن BR-KSA-EN16931-09.
بعد التصحيح أعد إرسال الفاتورة. الفاتورة المرفوضة لم تُسجَّل عند الهيئة، فلا تحتاج إشعارًا دائنًا — أرسل الفاتورة الصحيحة نفسها.
هل يمنعه ZATCA Tools؟
نعم، وبنية المنتج هي التي تمنعه. مُولِّد الحمولة يكتب SAR نصًّا ثابتًا في عملة الفاتورة، ويُستدعى مُولِّد XML في InvoiceSubmitter بعملته الافتراضية وهي SAR كذلك، فتخرج الترويسة وكل خاصية currencyID بالنص الواحد نفسه. ولا يوجد في المنتج عملة على مستوى البند أصلًا: البند اسم وكمية وسعر وفئة ضريبية، لا غير. والملاحظة التي تستحق أن تُقال كاملة: الريالان يُضبطان في موضعين مستقلين ويتصادف اتفاقهما لأن كليهما غير قابل للضبط — لا لأن شيئًا في المسار يقارن أحدهما بالآخر.
أكواد لها علاقة
أسئلة شائعة
بند واحد فقط خاطئ — لماذا تُرفض الفاتورة كلها؟ +
فاتورتي باليورو — أي المبالغ يبقى باليورو؟ +
صحّحت الترويسة ومازال الرفض قائمًا. +
ZATCA Tools يبني التوقيع والبصمة والعدّاد والترميز عنك، ويتحقق من البيانات قبل الإرسال. ابدأ مجانًا، وبدون بطاقة ائتمانية.
ابدأ مجانًا