عدّاد الفاتورة ICV في الفاتورة الإلكترونية

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

يخلط كثير من المطوّرين بين عدّاد الفاتورة ورقم الفاتورة التجاري (Invoice Number)، وبينه وبين المعرّف الفريد UUID. الثلاثة حقول منفصلة، لكل منها دور مختلف تمامًا. هذا الدليل التقني يركّز على عدّاد الفاتورة وحده: ما هو، أين يقع في XML، كيف يعمل مع تجزئة الفاتورة السابقة (PIH) لبناء سلسلة التجزئة، ولماذا يجب أن يكون متسلسلًا بصرامة على مستوى كل جهاز إصدار (EGS).

المرجع الرسمي هو متطلبات هيئة الزكاة والضريبة والجمارك (ZATCA) للفوترة الإلكترونية. عند أي تعارض بين ما هنا وبين المخطط الرسمي، يُعتمد المخطط الرسمي للهيئة.

ما هو عدّاد الفاتورة ICV بالتحديد؟

عدّاد الفاتورة قيمة عددية صحيحة موجبة تبدأ من 1 وتزيد واحدًا واحدًا. أول فاتورة يُصدرها الجهاز قيمتها 1، والثانية 2، والثالثة 3، وهكذا دون استثناء. لا توجد أرقام عشرية، ولا أصفار بادئة، ولا فراغات. الصيغة عدد صحيح فقط.

الكلمة المفتاحية هنا «الجهاز». العدّاد لا يُحسب على مستوى المنشأة ككل، بل على مستوى وحدة الإصدار (EGS Unit) المسجّلة لدى الهيئة. لو كان لمتجر ثلاثة أجهزة كاشير، كل جهاز يحمل عدّاده الخاص الذي يبدأ من 1 ويتسلسل بمعزل عن الجهازين الآخرين. هذا الفصل ضروري لأن كل جهاز يبني سلسلة تجزئة مستقلة، ولا يمكن لجهازين أن يتشاركا العدّاد نفسه دون كسر السلسلة.

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

أين يقع عدّاد الفاتورة في ملف XML؟

يعيش عدّاد الفاتورة داخل عنصر cac:AdditionalDocumentReference الذي يحمل المعرّف cbc:ID بقيمة نصية ثابتة هي ICV. القيمة العددية للعدّاد تُكتب داخل cbc:UUID ضمن العنصر ذاته. هذا التركيب جزء من بنية الفاتورة المبنية على معيار UBL 2.1 الذي تعتمده الهيئة.

مثال XML كامل لكتلة ICV

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

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

موقع ICV بين كتل AdditionalDocumentReference الأخرى

لا تقتصر فاتورة المرحلة الثانية على كتلة ICV واحدة. توجد عدة كتل AdditionalDocumentReference متتالية، لكل منها معرّف مختلف. الترتيب المعتاد يضع كتلة العدّاد قبل كتلة تجزئة الفاتورة السابقة (PIH):

<cac:AdditionalDocumentReference>
  <cbc:ID>ICV</cbc:ID>
  <cbc:UUID>3</cbc:UUID>
</cac:AdditionalDocumentReference>
<cac:AdditionalDocumentReference>
  <cbc:ID>PIH</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">
      NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZj79KI==
    </cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

الكتلة الأولى تحمل قيمة العدّاد (3)، والثانية تحمل تجزئة الفاتورة السابقة مُرمّزة بترميز Base64. هذا التجاور ليس صدفة: العدّاد و PIH معًا يعرّفان موضع الفاتورة في السلسلة. العدّاد يقول «أنا الفاتورة رقم 3»، و PIH يقول «والفاتورة رقم 2 كانت تجزئتها كذا». التحقّق من الاثنين معًا يثبت سلامة التتابع.

كيف يعمل عدّاد الفاتورة مع PIH لبناء سلسلة التجزئة؟

سلسلة التجزئة (Hash Chain) هي الآلية التي تجعل تعديل أي فاتورة قديمة أمرًا قابلًا للكشف. تعمل بمبدأ بسيط: تجزئة كل فاتورة تعتمد جزئيًا على تجزئة الفاتورة التي سبقتها. لو غيّر أحدهم محتوى فاتورة قديمة، تتغير تجزئتها، فتنكسر التجزئة المخزّنة في الفاتورة التالية، وتنهار السلسلة كلها بعدها.

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

العلاقة بين ICV و PIH خطوة بخطوة

لتوضيح التتابع، إليك ما يحدث عند إصدار الفاتورة رقم 3:

1. يقرأ الجهاز قيمة العدّاد الحالية ويزيدها واحدًا، فتصبح 3.
2. يجلب الجهاز تجزئة الفاتورة رقم 2 المخزّنة محليًا.
3. يكتب تجزئة الفاتورة رقم 2 داخل كتلة PIH للفاتورة رقم 3.
4. يحسب الجهاز تجزئة الفاتورة رقم 3 الكاملة، التي تشمل قيمة PIH ضمن مدخلاتها.
5. تُخزّن تجزئة الفاتورة رقم 3 لتُستخدم بدورها في PIH للفاتورة رقم 4.

الخلاصة: العدّاد يرقّم العقدة في السلسلة، و PIH يربط العقدة بسابقتها. دونهما معًا لا توجد سلسلة قابلة للتحقق. تفاصيل آلية حساب التجزئة نفسها وخوارزمية SHA المستخدمة محلّها مرجع منفصل عن هذا الدليل، فهنا نركّز على دور العدّاد.

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

لماذا يجب أن يكون العدّاد متسلسلًا بصرامة؟

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

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

الأخطاء الشائعة التي تكسر تسلسل العدّاد

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

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

كيف يختلف عدّاد الفاتورة عن UUID؟

هذا أكثر التباسات المطوّرين شيوعًا. عدّاد الفاتورة و UUID حقلان مختلفان جذريًا في الشكل والغرض ومكان التخزين.

المعرّف الفريد UUID سلسلة من 36 خانة بصيغة ست عشرية مثل 3cf5ee9b-1391-4f5c-9a3b-2d1c0e4f9a77، تُولَّد عشوائيًا وتكون فريدة عالميًا. لا علاقة لها بالترتيب: لا يمكن من قيمة UUID معرفة ما إذا كانت الفاتورة الأولى أو المئة. وظيفتها التعريف الفريد المطلق للفاتورة، لا التتابع.

أما العدّاد فعدد صحيح صغير متسلسل، تُعرف منه مباشرة رتبة الفاتورة في سلسلة الجهاز. القيمة 47 تعني الفاتورة السابعة والأربعين. العدّاد متوقَّع ومرتّب، بينما UUID عشوائي وغير مرتّب بقصد.

مقارنة مباشرة

تفاصيل توليد UUID وقواعد تفرّده محلّها مرجع المعرّف الفريد المنفصل. ما يعنينا هنا أن تفرّق بينه وبين العدّاد فلا تكتب قيمة UUID داخل كتلة ICV بالخطأ، ولا العكس.

كيف يختلف عدّاد الفاتورة عن رقم الفاتورة التجاري؟

رقم الفاتورة التجاري (Invoice Number) هو الرقم الذي يراه العميل على الفاتورة المطبوعة، مثل INV-2026-00045. يقع في عنصر cbc:ID على مستوى المستند، ويخضع لقواعد المنشأة التجارية: قد يحوي حروفًا، بادئات، سنة، أو رمز فرع.

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

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

الحقول الثلاثة في نظرة واحدة

التفاصيل الدقيقة لكتلة ICV في المخطط الرسمي

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

القاعدة الثانية أن القيمة داخل cbc:UUID يجب أن تكون عددًا صحيحًا موجبًا يُمثّل نصيًا دون أصفار بادئة. كتابة 003 بدل 3 قد تُقبل في بعض المحلّلات وتُرفض في غيرها، فالأسلم الالتزام بالتمثيل العددي النظيف. كذلك لا يجوز أن تكون القيمة سالبة أو عشرية أو نصية غير رقمية.

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

مثال على فاتورة أولى في عمر الجهاز

الفاتورة الأولى حالة خاصة تستحق مثالًا مستقلًا. عدّادها 1، وقيمة PIH لها قيمة ابتدائية ثابتة محددة من الهيئة لأنه لا توجد فاتورة سابقة تُجزَّأ:

<cac:AdditionalDocumentReference>
  <cbc:ID>ICV</cbc:ID>
  <cbc:UUID>1</cbc:UUID>
</cac:AdditionalDocumentReference>
<cac:AdditionalDocumentReference>
  <cbc:ID>PIH</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">
      NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZj79KI==
    </cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

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

دور العدّاد في مرحلتي الإصدار والربط

تنقسم الفوترة الإلكترونية إلى مرحلتين. مرحلة الإصدار التي بدأت في 4 ديسمبر 2021، ومرحلة الربط والتكامل التي بدأت في 1 يناير 2023 على موجات حسب إيرادات المنشأة. حقول النزاهة التقنية مثل العدّاد و PIH والختم التشفيري تخص المرحلة الثانية، أي مرحلة الربط.

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

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

سيناريو متعدد الأجهزة في منشأة واحدة

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

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

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

اعتبارات عملية للمطوّرين عند تنفيذ العدّاد

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

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

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

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

أخطاء التحقق المرتبطة بالعدّاد وكيفية معالجتها

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

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

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

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

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

قائمة تحقّق سريعة قبل الإرسال

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

تخزين العدّاد والأثر الرقابي طويل المدى

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

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

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

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

كيف يتعامل قيود مع عدّاد الفاتورة؟

يدير قيود قيمة العدّاد لكل جهاز إصدار تلقائيًا. عند إصدار كل فاتورة، يزيد قيود العدّاد بمقدار واحد، ويكتبه في موضعه الصحيح داخل كتلة ICV في ملف XML المبني على معيار UBL 2.1، ثم يربطه بتجزئة الفاتورة السابقة عبر PIH لبناء سلسلة تجزئة متوافقة مع المرحلة الثانية.

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

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

أسئلة شائعة

هل يبدأ عدّاد الفاتورة من صفر أم من واحد؟

يبدأ من 1 لأول فاتورة يُصدرها الجهاز، ثم يزيد واحدًا مع كل فاتورة تالية. لا توجد فاتورة بعدّاد 0.

هل يُصفَّر العدّاد في بداية كل سنة؟

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

هل يمكن لجهازين في المنشأة نفسها استخدام عدّاد مشترك؟

لا. كل جهاز إصدار (EGS) يحمل عدّاده المستقل الذي يبدأ من 1، لأن كل جهاز يبني سلسلة تجزئة منفصلة.

أين تُكتب قيمة العدّاد داخل XML؟

داخل عنصر cac:AdditionalDocumentReference الذي معرّفه cbc:ID يساوي ICV، وتُوضع القيمة العددية في cbc:UUID ضمن العنصر نفسه.

ما الفرق الجوهري بين العدّاد و UUID؟

العدّاد عدد صحيح متسلسل يدل على رتبة الفاتورة، بينما UUID سلسلة 36 خانة عشوائية فريدة عالميًا لا تدل على ترتيب. هما حقلان منفصلان لا يُكتب أحدهما مكان الآخر.

ماذا يحدث لو انكسر تسلسل العدّاد؟

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