رمز الخطأ 1020: مرجع الفاتورة الأصلية مفقود في الإشعار

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

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

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

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

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

الإشعار الدائن (Credit Note) يحمل رمز النوع 381، والإشعار المدين (Debit Note) يحمل الرمز 383. كلاهما مستند معدِّل لفاتورة قائمة، لذلك يخضعان للقاعدة نفسها: لا بد من مرجع يشير إلى الأصل. الفاتورة العادية لا تخضع لهذه القاعدة لأنها مستند قائم بذاته لا يعدّل شيئًا قبله.

كيف تقرأ رسالة الرفض

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

{
  "validationResults": {
    "infoMessages": [
      {
        "type": "INFO",
        "code": "XSD_ZATCA_VALID",
        "category": "XSD validation",
        "message": "Complied with UBL 2.1 standards"
      }
    ],
    "warningMessages": [],
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "1020",
        "category": "Billing reference validation",
        "message": "Original invoice reference is missing for a credit/debit note."
      }
    ],
    "status": "ERROR"
  },
  "clearanceStatus": "NOT_CLEARED",
  "clearedInvoice": null
}

المفاتيح التي تهمّك في القراءة:

• clearanceStatus بقيمة NOT_CLEARED يعني أن المقاصة لم تتم، فالإشعار لم يُعتمد ولا يجوز تسليمه للمشتري.
• status داخل نتائج التحقق بقيمة ERROR يعني أن سبب الإيقاف خطأ مانع، لا مجرد تحذير.
• code بقيمة 1020 هو التعريف الدقيق للسبب، والرسالة تشرحه نصًّا.
• clearedInvoice بقيمة null يؤكد أنه لا توجد نسخة مختومة عائدة إليك.

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

لماذا يلزم الإشعار بمرجع الفاتورة الأصلية

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

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

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

يترتب على ذلك نتيجة مهمة في التصميم: إذا كان نظامك يصدر الفواتير والإشعارات معًا، فلا يجوز أن يطبّق القاعدة نفسها عليها. كتلة BillingReference حقل مشروط: إلزامي عند رمز النوع 381 أو 383، وغائب في الفاتورة العادية. معاملته كحقل ثابت في الجميع تنتج إمّا الخطأ 1020 في الإشعار، أو كتلة لا لزوم لها في الفاتورة. لفهم البنية التقنية الكاملة للإشعارات، راجع دليلي الإشعارات الدائنة (Credit Notes) تقنياً والإشعارات المدينة (Debit Notes) تقنياً.

أين يوضع مرجع الفاتورة الأصلية في ملف XML

مرجع الفاتورة الأصلية له موضع واحد محدّد في الإشعار، وأي وضع له خارج هذا الموضع يساوي غيابه من منظور التحقق. الموضع هو كتلة cac:BillingReference، وتحديدًا داخل cac:InvoiceDocumentReference في العنصر cbc:ID الذي يحمل رقم الفاتورة الأصلية. الكتلة التالية تبيّن البنية الصحيحة:

<cbc:InvoiceTypeCode name="0211010">381</cbc:InvoiceTypeCode>

<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <!-- رقم الفاتورة الأصلية التي يعدّلها الإشعار -->
    <cbc:ID>INV-2026-000148</cbc:ID>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>

ثلاث نقاط دقيقة في هذه الكتلة:

1. المرجع يوضع في cbc:ID داخل cac:InvoiceDocumentReference داخل cac:BillingReference، لا في أي موضع آخر. خطأ شائع أن يوضع الرقم في حقل ملاحظات أو وصف، فلا تقرؤه قاعدة التحقق كمرجع فاتورة.
2. القيمة في cbc:ID يجب أن تطابق رقم الفاتورة الأصلية كما صدر فعلًا (حقل cbc:ID في تلك الفاتورة)، لا رقم الإشعار نفسه، ولا رقمًا داخليًا آخر.
3. رمز النوع InvoiceTypeCode يجب أن يكون 381 للإشعار الدائن أو 383 للمدين. إذا كان رمز النوع 388 (فاتورة) فالمستند ليس إشعارًا أصلًا، والخلل في التصنيف لا في المرجع.

وللمقارنة المباشرة، هذا ما يبدو عليه الإشعار الذي ينتج الخطأ 1020: مستند برمز نوع إشعار، لكن بلا كتلة BillingReference أصلًا.

<cbc:InvoiceTypeCode name="0211010">381</cbc:InvoiceTypeCode>

<!-- كتلة BillingReference غائبة تمامًا -> ينتج الخطأ 1020 -->

<cac:AccountingSupplierParty>
  ...
</cac:AccountingSupplierParty>

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

الفرق بين الفاتورة والإشعار في حقل المرجع

الجدول التالي يلخّص متى يكون مرجع الفاتورة الأصلية إلزاميًا، وما الذي يترتب على غيابه في كل نوع مستند:

كيف تصحّح الإشعار وتعيد إرساله

تصحيح الخطأ 1020 لا يحتاج تعديل بنية الإشعار كلها، بل إكمال كتلة واحدة. اتبع هذه الخطوات بالترتيب:

1. تأكد من نوع المستند أولًا. افتح عنصر رمز النوع وتحقق أنه 381 أو 383. إذا كان 388 فالمستند فاتورة ولا يفترض أن يطلب مرجعًا أصلًا، والخلل في تصنيف المستند لا في حقل المرجع.
2. احصل على رقم الفاتورة الأصلية الصحيح. استخرج رقم الفاتورة التي يعدّلها الإشعار من سجلك. تحقق أنه يطابق حقل cbc:ID في تلك الفاتورة كما صدرت فعلًا، لا رقمًا داخليًا مختلفًا.
3. أضف كتلة BillingReference في الموضع الصحيح. ضع رقم الفاتورة الأصلية في cbc:ID داخل InvoiceDocumentReference، كما في النموذج الصحيح أعلاه.
4. تحقق من تطابق طرفي الإشعار مع الفاتورة الأصلية. الإشعار يرث بيانات البائع والمشتري من الفاتورة التي يعدّلها. إذا اختلف المشتري أو رقمه الضريبي عن الأصل، قد تثور أخطاء تحقق مجاورة بعد حلّ 1020.
5. أعد توليد المستند ووقّعه من جديد. أي تعديل في محتوى الإشعار يغيّر تجزئته، فلا تكتفِ بإضافة الكتلة بل أعد توليد الملف وختمه بشهادة CSID قبل الإرسال.
6. أعد الإرسال إلى المقاصة. مرّر الإشعار المصحّح على مرحلة التحقق المحلي أولًا، ثم أرسله. عند نجاح المقاصة ستحصل على clearanceStatus بقيمة CLEARED ونسخة مختومة في clearedInvoice.

ملاحظة مهمة عن إعادة الإرسال: لا ترسل الإشعار المرفوض مجدّدًا كما هو ظنًّا أن المشكلة عابرة. الرفض بـ 1020 رفض بنيوي ثابت، وسيتكرر حتى تكمل كتلة المرجع فعليًا. كما لا تنشئ إشعارًا جديدًا برقم متسلسل جديد لتجاوز المرفوض، لأن عدّاد المستند ICV يجب أن يبقى متسلسلًا. صحّح الإشعار نفسه وأعد توليده بالعدّاد ذاته.

مسار تصحيح الخطأ 1020 خطوة بخطوة

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

خطأ شائع: الإشارة إلى مستند خاطئ أو غير معتمد

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

• الإشارة إلى رقم الإشعار نفسه. خطأ متكرر أن يملأ النظام cbc:ID برقم الإشعار بدل رقم الفاتورة الأصلية. المرجع يجب أن يشير إلى الأصل، لا إلى المستند الحالي.
• الإشارة إلى فاتورة لم تُعتمد بعد. الفاتورة الأصلية يجب أن تكون قد مرّت بالمقاصة فعلًا. الإشارة إلى مسودة أو فاتورة مرفوضة لا يربط الإشعار بمستند قائم في سجل الهيئة.
• اختلاف صياغة الرقم. الرقم في المرجع يجب أن يطابق حرفيًا رقم الفاتورة كما صدر. اختلاف في البادئة أو الأصفار أو الفواصل يجعل المنصة تعجز عن مطابقة المرجع بالأصل.
• الإشارة إلى فاتورة طرف مختلف. الإشعار يعدّل فاتورة موجَّهة لنفس المشتري. مرجع لفاتورة عميل آخر يكسر اتساق الطرفين بين المستندين.

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

سيناريو عملي: مرتجع بضاعة يحتاج إشعارًا دائنًا

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

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

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

كيف تتحقق من صحة المرجع قبل الإصدار

قبل اعتماد أي إشعار، تحقق من هذه النقاط حتى لا تنتقل من الخطأ 1020 إلى خطأ مرجع آخر:

• رمز النوع صحيح. 381 للدائن و383 للمدين. رمز غير صحيح يغيّر قاعدة التحقق المطبَّقة كليًا.
• المرجع يشير إلى الأصل. القيمة في cbc:ID هي رقم الفاتورة الأصلية، لا رقم الإشعار ولا رقم داخلي آخر.
• الفاتورة الأصلية معتمدة. الفاتورة المشار إليها مرّت بالمقاصة فعلًا، فالإشعار لا يعدّل مسودة.
• اتساق الطرفين. بائع الإشعار ومشتريه يطابقان الفاتورة الأصلية. أي اختلاف يكسر العلاقة بين المستندين.

كيف تمنع تكرار الخطأ نهائيًا

الخطأ 1020 من أكثر الأخطاء قابلية للمنع، لأن سببه إجراء إصدار خاطئ لا خلل تقني عميق. الإجراءات التالية تقفل الباب عليه:

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

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

ماذا يحدث إن تركت الخطأ دون حلّ

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

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

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

أثر التصحيح على سلسلة التجزئة وعدّاد المستندات

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

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

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

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

الإشعارات في مسار المقاصة مقابل الإبلاغ

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

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

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

موضع مرجع الفاتورة الأصلية داخل شجرة الإشعار

هذه الشجرة تختصر القاعدة كلها: رقم الفاتورة الأصلية في cbc:ID داخل InvoiceDocumentReference داخل BillingReference، لا في أي حقل آخر. وضعه في غير موضعه يساوي غيابه. لفهم كامل بنية الإشعارات تقنيًا، راجع الإشعارات الدائنة (Credit Notes) تقنياً والإشعارات المدينة (Debit Notes) تقنياً، ولاستعراض بقية رموز الأخطاء راجع مرجع أخطاء الهيئة في الفوترة.

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

ما الفرق بين الإشعار الدائن والمدين في علاقتهما بالخطأ 1020؟
كلاهما يخضع للقاعدة نفسها. الإشعار الدائن (رمز النوع 381) يخفّض قيمة فاتورة سابقة، والمدين (383) يرفعها، وكلاهما مستند معدِّل يلزمه مرجع الفاتورة الأصلية في كتلة BillingReference. غياب المرجع في أي منهما يُنتج الخطأ 1020.

هل يظهر الخطأ 1020 في الفاتورة العادية؟
لا. الفاتورة العادية (رمز النوع 388) مستند أوّلي لا يعدّل شيئًا قبله، فلا تطلب مرجعًا أصلًا. إذا ظهر لك 1020 في مستند تظنه فاتورة، فالأرجح أنه صُنّف إشعارًا (381 أو 383) عن طريق الخطأ في رمز النوع.

أين يوضع مرجع الفاتورة الأصلية بالضبط في الملف؟
داخل cac:BillingReference / cac:InvoiceDocumentReference / cbc:ID، والقيمة هي رقم الفاتورة الأصلية كما صدر. وضع الرقم في حقل ملاحظات أو وصف لا يقرؤه التحقق كمرجع فاتورة وينتج الخطأ نفسه.

هل المرجع هو رقم الإشعار أم رقم الفاتورة الأصلية؟
رقم الفاتورة الأصلية التي يعدّلها الإشعار، لا رقم الإشعار نفسه. خطأ شائع أن يملأ النظام المرجع برقم الإشعار، فيبقى الخطأ قائمًا لأن المرجع لا يطابق فاتورة معتمدة.

هل أعيد إرسال الإشعار المرفوض كما هو بعد إضافة المرجع؟
لا. أي تعديل في المحتوى يغيّر تجزئة الإشعار، فيجب إعادة توليد المستند وتوقيعه بشهادة CSID من جديد قبل إعادة الإرسال إلى المقاصة. أضف الكتلة، أعد التوليد، ثم أرسل.

كيف أمنع تكرار الخطأ 1020 مستقبلًا؟
أصدر كل إشعار من شاشة الفاتورة الأصلية مباشرة، واجعل كتلة المرجع إلزامية في أي مستند نوعه 381 أو 383، وأضف تحققًا محليًا يرفض الإشعار إن لم يطابق المرجع فاتورة معتمدة. يبني قيود هذه الكتلة تلقائيًا من الفاتورة، فلا يصلك الخطأ من الأساس.