الإشعارات المدينة (Debit Notes) تقنياً

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

هذا الدليل جزء من سلسلة التوثيق التقني للفوترة الإلكترونية. يركّز حصرًا على الجانب المدين، أي حالة الزيادة على فاتورة قائمة. أما حالة النقص أو الإلغاء أو الخصم فهي موضوع دليل «الإشعارات الدائنة (Credit Notes)» المنفصل. الإشعار المدين والإشعار الدائن توأمان في البنية لكنهما متعاكسان في الاتجاه: المدين يرفع المبلغ، والدائن يخفضه. وقبل أن نبدأ، يفيدك الاطلاع على ترويسة الفاتورة (Invoice Header) في XML، لأن الإشعار المدين يشترك مع الفاتورة في معظم حقول الترويسة.

ما الإشعار المدين ومتى تصدره؟

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

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

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

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

رمز نوع المستند للإشعار المدين (383)

يُعرَّف نوع المستند داخل XML عبر حقل cbc:InvoiceTypeCode. القيمة الرقمية لهذا الحقل تحدد طبيعة المستند وفق ترميز موحّد تعتمده هيئة الزكاة والضريبة والجمارك (ZATCA). للفاتورة الضريبية القيمة 388، وللإشعار الدائن القيمة 381، وللإشعار المدين القيمة 383. هذه القيمة هي العلامة الأولى التي تقرأها المنظومة لتعرف أنها أمام إشعار مدين لا فاتورة عادية.

إلى جانب الرقم 383، يحمل الحقل سمة name تتكوّن من سبع خانات تصف خصائص المستند الفرعية. أهم خانة فيها هي التي تميّز بين المستند الموجّه للأعمال (B2B) والمستند المبسّط الموجّه للمستهلك (B2C). القيمة 0100000 تدل على مستند قياسي موجّه للأعمال يخضع للمقاصة، والقيمة 0200000 تدل على مستند مبسّط موجّه للمستهلك يخضع للإبلاغ.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
  xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
  xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">

  <cbc:ProfileID>reporting:1.0</cbc:ProfileID>
  <cbc:ID>DN-2026-000045</cbc:ID>
  <cbc:UUID>7d2b9f4e-1a6c-4e83-bb20-9f1c5a3d77ec</cbc:UUID>
  <cbc:IssueDate>2026-06-24</cbc:IssueDate>
  <cbc:IssueTime>13:05:42</cbc:IssueTime>
  <cbc:InvoiceTypeCode name="0100000">383</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode>
  <cbc:TaxCurrencyCode>SAR</cbc:TaxCurrencyCode>
</Invoice>

لاحظ أن العنصر الجذر يبقى <Invoice> حتى لو كان المستند إشعارًا مدينًا. معيار UBL 2.1 يستخدم نفس عنصر الجذر للفاتورة والإشعارين، ويميّز بينها برمز نوع المستند فقط. هذا التصميم يبسّط المعالجة: أي نظام يقرأ الملف يبدأ من نفس العنصر ثم يقرأ الرمز 383 ليعرف أنه أمام إشعار مدين.

توضيح بصري لرمز 383 وموقعه

الجدول التالي يجمع رموز أنواع المستندات الثلاثة التي تتعامل معها يوميًا، حتى تميّز بينها بسرعة عند قراءة أي ملف:

الإشارة إلى الفاتورة الأصلية (cac:BillingReference)

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

<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <cbc:ID>INV-2026-000128</cbc:ID>
    <cbc:IssueDate>2026-06-10</cbc:IssueDate>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>

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

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

المعرّف الفريد ورقم العداد وتسلسل الربط (UUID وICV وPIH)

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

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

رقم العداد ICV (اختصار Invoice Counter Value) عدّاد متتابع يزيد بمقدار واحد مع كل مستند تصدره المنشأة، سواء كان فاتورة أو إشعارًا دائنًا أو إشعارًا مدينًا. هذا العدّاد يثبت تسلسل الإصدار ويمنع وجود فجوات. يأتي ICV ضمن كتلة cac:AdditionalDocumentReference تحت معرّف ICV.

<cac:AdditionalDocumentReference>
  <cbc:ID>ICV</cbc:ID>
  <cbc:UUID>47</cbc:UUID>
</cac:AdditionalDocumentReference>

<cac:AdditionalDocumentReference>
  <cbc:ID>PIH</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">
      NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZj
    </cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

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

كيف تترابط مستندات المنشأة في سلسلة واحدة

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

المقاصة والإبلاغ للإشعار المدين

مسار الإشعار المدين عبر منصة فاتورة يتبع نفس قاعدة الفاتورة الأصلية ويعتمد على جمهور المستند. الإشعار المدين الموجّه للأعمال (B2B) يخضع للمقاصة (Clearance)، والإشعار المدين الموجّه للمستهلك (B2C) يخضع للإبلاغ (Reporting). هذا التمييز هو نفسه الذي رأيناه في سمة name ضمن رمز نوع المستند.

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

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

مساري المقاصة والإبلاغ للإشعار المدين

الفرق بين الإشعار المدين والإشعار الدائن

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

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

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

الضريبة على مبلغ الزيادة (cac:TaxTotal)

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

<cac:TaxTotal>
  <cbc:TaxAmount currencyID="SAR">30.00</cbc:TaxAmount>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="SAR">200.00</cbc:TaxableAmount>
    <cbc:TaxAmount currencyID="SAR">30.00</cbc:TaxAmount>
    <cac:TaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>15.00</cbc:Percent>
    </cac:TaxCategory>
  </cac:TaxSubtotal>
</cac:TaxTotal>

في المثال أعلاه، مبلغ الزيادة 200 ر.س، والضريبة عليه 30 ر.س بنسبة 15%. هذه القيم تُحسب على مبلغ التصحيح وحده، لا على قيمة الفاتورة الأصلية. الرمز S داخل cac:TaxCategory يدل على الفئة الخاضعة للنسبة القياسية. لو كان مبلغ الزيادة معفى أو خاضعًا لنسبة صفرية، اختلف الرمز ونسبة الضريبة تبعًا لطبيعة البند.

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

التوقيع ورمز QR والربط مع منصة فاتورة

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

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

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

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

سبب الإصدار وحقل الملاحظة (cbc:Note)

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

<cbc:Note>زيادة كمية لم تُحتسب في الفاتورة الأصلية INV-2026-000128</cbc:Note>

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

أخطاء شائعة في الإشعار المدين وكيف تتجنبها

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

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

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

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

مثال عملي متكامل لإشعار مدين

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

يبدأ النظام بتوليد رمز نوع المستند 383 في الترويسة، ثم يضيف كتلة BillingReference تحمل رقم الفاتورة الأصلية وتاريخها. بعدها يولّد معرّفًا فريدًا UUID جديدًا، ويحسب رقم العداد ICV التالي في سلسلة المنشأة، ويجلب تجزئة المستند السابق PIH. ثم يحسب الضريبة على مبلغ الزيادة وحده في كتلة TaxTotal. أخيرًا يوقّع الملف بشهادة CSID، ويولّد رمز QR، ويرسله للمقاصة إن كان موجّهًا للأعمال.

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

حالات خاصة عند إصدار الإشعار المدين

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

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

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

خلاصة مرجعية لحقول الإشعار المدين

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

أين يقع الإشعار المدين من بقية سلسلة التوثيق؟

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

للاطلاع على حقول الترويسة بالتفصيل، راجع دليل ترويسة الفاتورة (Invoice Header) في XML. ولفهم آلية اعتماد المستند عبر المنصة قبل تسليمه للعميل، راجع دليل المقاصة (Clearance) في الفاتورة الإلكترونية. وللصورة الكاملة عن برنامج الفوترة وكيفية توليده لهذه المستندات تلقائيًا، اطّلع على برنامج الفاتورة الإلكترونية من قيود.

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