رمز الخطأ 1007: رمز نوع الفاتورة غير صحيح

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

رمز الخطأ 1007 يخص حقلاً واحداً في مستند XML اسمه InvoiceTypeCode. هذا الحقل يحمل قيمتين منفصلتين: رمز نوع المستند (فاتورة، إشعار دائن، إشعار مدين)، ورمز فرعي من سبع خانات يصف طبيعة الفاتورة (ضريبية أم مبسّطة، وأي خصائص إضافية مثل الفوترة الذاتية أو فوترة طرف ثالث). أي قيمة خارج ما تقبله الهيئة في أيٍّ من الجزأين تُنتج هذا الخطأ.

الجمهور المستهدف هنا هو المطوّر أو مسؤول التكامل التقني الذي يبني أو يصون اتصال نظام محاسبي بمنصة فاتورة. لذلك تجد في هذه الصفحة أمثلة JSON فعلية لاستجابة الهيئة، وشرحاً للحقول كما تظهر في مستند UBL 2.1. الرموز التقنية مثل InvoiceTypeCode وvalidationResults تبقى بالإنجليزية لأنها أسماء حقول فعلية في المعيار، لا يصح تعريبها.

ما هو رمز الخطأ 1007 بالضبط

الفاتورة الإلكترونية في المرحلة الثانية مستند XML منظم يتبع معيار UBL 2.1. كل عنصر فيه خاضع لقاعدة تحقق. حقل InvoiceTypeCode من أوائل الحقول التي تفحصها الهيئة، لأنه يحدد نوع المستند ومساره. لو كان هذا الحقل خاطئاً، فلا معنى لمتابعة بقية الفحوص.

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

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

كيف تعيد الهيئة هذا الخطأ في الاستجابة

حين تُرسل الفاتورة عبر واجهة المقاصة أو الإبلاغ، تعيد الهيئة استجابة JSON فيها كائن validationResults. هذا الكائن يحمل الحالة العامة status ومصفوفتي الأخطاء والتحذيرات. عند الخطأ 1007 تكون الحالة رفضاً، ويظهر العنصر داخل errorMessages بالشكل التالي.

{
  "validationResults": {
    "status": "ERROR",
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "1007",
        "category": "XML_FORMAT",
        "message": "Invalid invoice type code"
      }
    ],
    "warningMessages": []
  }
}

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

لاحظ أن مصفوفة warningMessages فارغة في هذا المثال. وجود الرمز 1007 داخل errorMessages وحده يكفي لرفض الفاتورة، بصرف النظر عن أي تحذيرات. عالج الخطأ أولاً، ثم انظر في التحذيرات بعد أن تُقبل الفاتورة.

أسباب الخطأ: الجزء الأول من InvoiceTypeCode

حقل InvoiceTypeCode يحمل أولاً رمز نوع المستند. هذا الرمز رقم من ثلاث خانات مأخوذ من قائمة معتمدة في معيار UBL. الهيئة تقبل ثلاث قيم فقط لهذا الجزء، وأي قيمة أخرى تُنتج الخطأ 1007.

• 388 للفاتورة الضريبية. هذا الرمز يصف الفاتورة بنوعيها الضريبي المعياري (B2B) والمبسّط (B2C). معظم المستندات الصادرة تحمل هذا الرمز.
• 383 لإشعار المدين. يُستخدم عند إضافة مبلغ على فاتورة سابقة، مثل تصحيح نقص في القيمة أو رسوم إضافية.
• 381 لإشعار الدائن. يُستخدم عند تخفيض قيمة فاتورة سابقة، مثل المرتجعات أو الإلغاء الجزئي.

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

أسباب الخطأ: الرمز الفرعي من سبع خانات

الجزء الثاني من تعريف نوع الفاتورة هو رمز فرعي من سبع خانات يظهر في سمة تسمى name داخل عنصر InvoiceTypeCode. هذه الخانات السبع تصف خصائص الفاتورة بدقة، وكل خانة بقيمة 0 أو 1. خطأ في أي خانة، أو طول مختلف عن سبع خانات، يُنتج الخطأ 1007 أيضاً.

أهم خانتين هما الأوليان: تحددان ما إذا كانت الفاتورة ضريبية معيارية أم مبسّطة.

• الخانة الأولى للفاتورة الضريبية المعيارية (B2B). تأخذ القيمة 1 حين تكون الفاتورة معيارية موجَّهة لمنشأة، وهي الفاتورة التي تمرّ بالمقاصة.
• الخانة الثانية للفاتورة المبسّطة (B2C). تأخذ القيمة 1 حين تكون الفاتورة مبسّطة موجَّهة لمستهلك، وهي الفاتورة التي تُبلَّغ خلال 24 ساعة.

القاعدة هنا صارمة: واحدة من الخانتين فقط تأخذ القيمة 1، لا كلتاهما ولا أيٌّ منهما صفر. فاتورة تحمل 1 في الخانتين معاً، أو صفراً فيهما معاً، قيمة غير صالحة. وكثيراً ما يقع هذا حين يخلط النظام بين منطق B2B وB2C أو يترك الحقل بقيمة افتراضية خاطئة.

الخانات الخمس المتبقية تصف خصائص إضافية: الفوترة الذاتية (self-billing) حيث يُصدر المشتري الفاتورة نيابة عن البائع، وفوترة طرف ثالث (third-party billing) حيث يُصدر طرف وسيط الفاتورة، إضافة إلى خصائص أخرى مثل فاتورة التصدير. كل خاصية لها خانتها المخصصة، وتفعيلها في الخانة الخطأ أو خلطها مع خاصية متعارضة معها يرفض الفاتورة.

مثال على البنية الصحيحة لحقل InvoiceTypeCode كما يظهر في مستند XML لفاتورة ضريبية معيارية:

<cbc:InvoiceTypeCode name="0100000">388</cbc:InvoiceTypeCode>

هنا الرمز 388 يعني فاتورة ضريبية، والقيمة 0100000 في سمة name تعني: الخانة الأولى 1 (معيارية)، والخانة الثانية 0 (ليست مبسّطة)، وبقية الخانات أصفار (لا فوترة ذاتية ولا طرف ثالث). أما الفاتورة المبسّطة فتحمل 0200000، أي صفر في الخانة الأولى وواحد في الثانية. أي خلط بين هذين النمطين سبب مباشر للخطأ 1007.

الفوترة الذاتية وفوترة الطرف الثالث: مصدر خفي للخطأ

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

الفوترة الذاتية (self-billing) حالة يُصدر فيها المشتري الفاتورة نيابةً عن البائع، باتفاق مسبق بينهما. هذا نمط معروف في بعض العقود طويلة الأمد حيث يملك المشتري بيانات الاستهلاك أدق من البائع. الخانة المخصصة لها يجب أن تأخذ القيمة 1 فقط حين تكون الفاتورة فعلاً مُصدَرة ذاتياً، وصفراً في كل حالة عادية.

فوترة الطرف الثالث (third-party billing) حالة يتولى فيها وسيط مفوَّض إصدار الفاتورة عن البائع، كمكتب محاسبي أو منصة وساطة. لها خانتها المستقلة كذلك. الخطأ الشائع أن يفعّل النظام إحدى هاتين الخانتين بقيمة افتراضية، فترفض الهيئة الفاتورة رغم أنها معاملة بيع عادية لا علاقة لها بالفوترة الذاتية ولا بالطرف الثالث.

القاعدة العملية: ابدأ بكل الخانات الخمس أصفاراً، ولا تفعّل خانة إلا حين تنطبق حالتها فعلاً على الفاتورة المُصدَرة. التفعيل الافتراضي أو المنسوخ من قالب قديم سبب متكرر للخطأ 1007 يصعب اكتشافه لأن الرمز الرئيسي 388 يبدو صحيحاً للوهلة الأولى.

إشعارا الدائن والمدين: متى يتغير الرمز

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

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

الإشعار يرث مسار فاتورته الأصلية. إشعار على فاتورة ضريبية معيارية يمرّ بالمقاصة، وإشعار على فاتورة مبسّطة يُبلَّغ خلال 24 ساعة. هذا يعني أن سمة name في الإشعار يجب أن تتسق مع نوع الفاتورة الأصلية أيضاً، فلا تجعل إشعاراً على فاتورة B2B يحمل ترميز فاتورة B2C.

أكثر مسبّبات الخطأ 1007 شيوعاً

بعد تشخيص عدد كبير من حالات هذا الخطأ، تتكرر أسباب محددة. الجدول التالي يلخّصها مع التصحيح المباشر لكل منها، ليكون مرجعاً سريعاً عند ظهور الرمز.

كيف تشخّص الخطأ خطوة بخطوة

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

• افتح مستند XML المُرسَل وابحث عن عنصر InvoiceTypeCode. هذا العنصر يقع داخل ترويسة الفاتورة. لمعرفة موضعه الدقيق وبقية حقول الترويسة راجع صفحة ترويسة الفاتورة في XML.
• تحقق من القيمة النصية للعنصر. هل هي 388 أو 383 أو 381؟ أي قيمة أخرى سبب مباشر للخطأ.
• تحقق من سمة name. هل طولها سبع خانات بالضبط؟ هل تحمل 1 في خانة واحدة فقط من الخانتين الأوليين؟
• طابق نوع المستند الفعلي مع الرمز. إن كانت الفاتورة مرتجعاً فالرمز يجب أن يكون 381 لا 388، وهكذا.
• راجع منطق الخصائص الإضافية. إن لم تكن الفاتورة فوترة ذاتية أو طرف ثالث، فالخانات المخصصة لها يجب أن تكون أصفاراً.

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

كيف تميّز الخطأ 1007 عن الأخطاء المجاورة

الخطأ 1007 يخص قيمة حقل نوع الفاتورة تحديداً. لكن مطوّري التكامل يخلطون أحياناً بينه وبين أخطاء أخرى تظهر في الطبقة نفسها أو الطبقة التالية، فيضيّعون الوقت في الموضع الخطأ. التمييز يبدأ من قراءة الرمز والفئة category معاً.

أخطاء فئة XML_FORMAT مثل 1007 تعني عيباً في البنية أو القيمة، وتُعالَج في مستندك قبل أي تفكير في الحسابات. أما أخطاء فئة قواعد الأعمال فتظهر بعد اجتياز الفاتورة طبقة البنية، وتعني أن القيم سليمة شكلاً لكنها غير منطقية، مثل عدم تطابق مجموع البنود مع الإجمالي.

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

كيف تصحّح الخطأ وتمنع تكراره

التصحيح يكون على مستوى منطق النظام الذي يبني حقل InvoiceTypeCode، لا على مستوى الفاتورة الواحدة. عالج المصدر مرة واحدة فتُحلّ كل الفواتير المتأثرة.

• اربط نوع المستند الداخلي برمز واحد صريح. اجعل الفاتورة العادية تُنتج 388، والمرتجع 381، والرسوم الإضافية 383، بلا قيم افتراضية مبهمة.
• اربط نوع العميل بالخانة الصحيحة. عميل منشأة يفعّل الخانة الأولى (معيارية)، ومستهلك فرد يفعّل الخانة الثانية (مبسّطة)، ولا تترك القرار لقيمة افتراضية.
• صفّر الخانات غير المستخدمة. ما لم تكن الفاتورة فوترة ذاتية أو طرف ثالث صراحةً، اضبط خاناتها على صفر.
• افحص الطول قبل الإرسال. أضف تحققاً يرفض أي قيمة name لا يساوي طولها سبع خانات.

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

أثر الخطأ على مسار المقاصة مقابل الإبلاغ

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

في الفاتورة الضريبية المعيارية (B2B)، المسار هو المقاصة. الهيئة تفحص الفاتورة قبل تسليمها للمشتري، فإن عاد الخطأ 1007 توقفت المعاملة عند هذه النقطة ولم تصل الفاتورة إلى المشتري أصلاً. الأثر العملي هنا أبسط: لا فاتورة صادرة تحتاج إلغاءً، يكفي تصحيح القيمة وإعادة الإرسال للحصول على الفاتورة المقاصّة.

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

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

مثال عملي: من الرفض إلى القبول

لنفترض متجراً يبيع للمستهلكين ويصدر فواتير مبسّطة، لكن نظامه القديم يضع 0100000 في سمة name لكل الفواتير. النتيجة أن كل فاتورة مبسّطة تُرمَّز كأنها معيارية، فيعود الخطأ 1007 عند الإبلاغ لأن الترميز لا يطابق طبيعة الفاتورة الفعلية.

الخطوة الأولى فتح مستند XML المُرسَل وقراءة عنصر InvoiceTypeCode. الرمز 388 صحيح لأنها فاتورة، لكن سمة name تحمل 0100000 بينما الفاتورة موجَّهة لمستهلك. التشخيص يكشف فوراً أن الخانة الأولى مفعّلة خطأً بدل الثانية.

الخطوة الثانية تصحيح منطق النظام ليربط نوع العميل بالخانة الصحيحة: مستهلك فرد يفعّل الخانة الثانية، فتصبح القيمة 0200000. الخطوة الثالثة إعادة الإرسال، فتعود الاستجابة بحالة قبول ومصفوفة errorMessages فارغة. وبما أن العيب كان في منطق النظام لا في فاتورة واحدة، فإن التصحيح يحلّ كل الفواتير المبسّطة اللاحقة دفعةً واحدة.

الدرس أن الخطأ 1007 يكاد لا يكون مشكلة فاتورة منفردة، بل عرَض لخلل في طريقة بناء الحقل. عالج المنطق مرة، وثبّت تحققاً يفحص القيمة قبل الإرسال، فتختفي فئة كاملة من الرفض.

اختبر الترميز في البيئة التجريبية قبل الإنتاج

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

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

متى اجتزت عيّنات الاختبار دون الخطأ 1007 في أي حالة، انتقل إلى معرّف الامتثال الإنتاجي الذي يوقّع فواتيرك الحية. التدرّج من البيئة التجريبية إلى الإنتاج ليس إجراءً شكلياً، بل شبكة أمان تمنع وصول خطأ بنيوي متكرر إلى تدفق فواتيرك الفعلي.

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

كيف يساعدك قيود في تجنّب الخطأ 1007

قيود يبني حقل InvoiceTypeCode تلقائياً وفق مواصفة UBL 2.1 للمرحلة الثانية. حين تختار نوع المستند داخل قيود (فاتورة، إشعار دائن، إشعار مدين) ونوع العميل (منشأة أو فرد)، يترجم النظام هذا الاختيار إلى الرمز الصحيح والقيمة الصحيحة من سبع خانات دون تدخّل منك. أنت لا تكتب 388 ولا 0100000 يدوياً.

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

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

الأسئلة الشائعة

ماذا يعني رمز الخطأ 1007 بالضبط؟

يعني أن قيمة حقل InvoiceTypeCode في فاتورتك غير مقبولة لدى الهيئة. السبب إما رمز نوع مستند خاطئ (غير 388 أو 383 أو 381)، أو رمز فرعي خاطئ من سبع خانات في سمة name. الفاتورة تُرفض حتى تُصحَّح القيمة.

ما الرموز الصحيحة لنوع المستند؟

الهيئة تقبل ثلاثة رموز فقط: 388 للفاتورة الضريبية بنوعيها المعياري والمبسّط، و383 لإشعار المدين، و381 لإشعار الدائن. أي رمز آخر من قائمة UBL يُنتج الخطأ 1007.

ما الفرق بين 0100000 و0200000 في سمة name؟

القيمة 0100000 تعني فاتورة ضريبية معيارية موجَّهة لمنشأة (B2B) تمرّ بالمقاصة. القيمة 0200000 تعني فاتورة مبسّطة موجَّهة لمستهلك (B2C) تُبلَّغ خلال 24 ساعة. خلط النمطين سبب شائع للخطأ.

هل يظهر الخطأ 1007 في الفاتورة المبسّطة كما في المعيارية؟

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

لماذا أربط منطق نظامي بحقل code لا بالنص؟

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

صحّحت رمز المستند لكن الخطأ 1007 ما زال يظهر، ما السبب؟

غالباً المشكلة في سمة name لا في الرمز الرئيسي. تحقق أن طولها سبع خانات بالضبط، وأن خانة واحدة فقط من الخانتين الأوليين تحمل القيمة 1، وأن خانات الفوترة الذاتية والطرف الثالث أصفار ما لم تنطبق حالتها. قيمة name خاطئة تُنتج الخطأ نفسه حتى لو كان الرمز 388 سليماً.

هل أحتاج لإلغاء الفاتورة المرفوضة بالخطأ 1007؟

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

هل يعفيني قيود من ضبط هذا الحقل يدوياً؟

نعم. قيود يبني حقل InvoiceTypeCode تلقائياً من اختيارك لنوع المستند ونوع العميل، فلا تكتب الرمز ولا القيمة من سبع خانات بنفسك. هذا يُقصي الخطأ 1007 من جذره. يبقى عليك تسجيل معرّف الامتثال لدى الهيئة مرة واحدة عند البدء.