يحمل كل ملف فاتورة يُرسل إلى نظام الفوترة الوطني تاريخًا في رأسه، وأول ما يسأل عنه من يبني هذا الملف هو الشكل الذي يُكتب به ذلك التاريخ. صيغة تاريخ الفاتورة في نظام الفوترة الوطني هي yyyy-mm-dd، أي السنة بأربعة أرقام ثم الشهر ثم اليوم، وتفصل بينها شرطة قصيرة، كما في القيمة 2023-10-30. وتُكتب هذه القيمة في العنصر cbc:IssueDate داخل ملف XML.
وخلاصة القاعدة أن تكتب التاريخ بالصيغة yyyy-mm-dd كما في جميع أمثلة XML في الدليل التقني الصادر عن دائرة ضريبة الدخل والمبيعات، وهي أيضًا الصيغة التي يذكرها جدول الوصف في قالب معلومات الفاتورة الأساسية (ص12). أما الوقت والمنطقة الزمنية فلا يحدد الدليل لهما صيغة.
يعرض هذا المقال نص الدليل عن التاريخ، وموضع العنصر في الملف، وما يقوله الإرشاد التاسع عن التنسيق الزمني الموحد، والفرق بين العنصر في ملف XML وحقل التاريخ في نموذج الفاتورة على البوابة. ثم يفصل ما لا يحدده الدليل، حتى لا يُبنى نظامك على قاعدة تُنسب إلى الدائرة وهي ليست من كلامها.
صيغة تاريخ الفاتورة في نظام الفوترة الوطني كما يصفها الدليل التقني
يرد وصف التاريخ في جدول معلومات الفاتورة الأساسية في الدليل التقني للربط مع نظام الفوترة الوطني من خلال واجهة برمجة التطبيقات، الإصدار 1.5 (ص12). يضع الجدول في عمود القالب العنصر cbc:IssueDate وبداخله عبارة «تاريخ الفاتورة» مظللة بالأصفر، ويكتب في عمود الوصف النص الآتي.
«تاريخ الفاتورة ويجب أن يكون حسب الصيغة التالية yyyy-mm-dd».

الصيغة yyyy-mm-dd رمز من ثلاثة أجزاء، ولكل جزء عدد ثابت من الخانات. والجدول الآتي يفكك القيمة 2023-10-30 التي يستخدمها الدليل في مثال معلومات الفاتورة الأساسية (ص14).
ومن أمثلة الدليل نفسها يتضح أمر يغفل عنه بعض المطورين، وهو أن الشهر الذي يتكون من رقم واحد يُكتب بخانتين. ففي أحد أمثلة الدليل يرد التاريخ 2022-09-27، والشهر فيه مكتوب 09 لا 9. والترتيب ثابت أيضًا، فالسنة أولًا ثم الشهر ثم اليوم.
وهذه الصيغة هي صيغة التاريخ في معيار ISO 8601، وهي الصيغة التي يستخدمها معيار UBL للتواريخ. ولهذا تنسجم مع اشتراط الدليل أن يلتزم ملف الفاتورة كله بمعيار UBL 2.1، وهو المعيار المشروح في مقال معيار UBL 2.1 في نظام الفوترة الوطني.
أين يقع عنصر IssueDate في ملف الفاتورة
يقع العنصر cbc:IssueDate في رأس الفاتورة ضمن قالب «معلومات الفاتورة الأساسية» (ص12)، مع العناصر التي تعرّف الفاتورة نفسها، ومنها رقم الفاتورة cbc:ID والمعرّف الفريد cbc:UUID ونوع الفاتورة cbc:InvoiceTypeCode وعملة الفاتورة. وشكل العنصر في القالب كما يلي.
<cbc:IssueDate>تاريخ الفاتورة</cbc:IssueDate>
ولقراءة هذا السطر تحتاج إلى مفتاح الألوان الذي يضعه الدليل أعلى القالب. نصه أن «العناصر المظللة باللون الأصفر … تدل على متغيرات مطلوب تعبئتها (إجبارية) من خلال نظام البائع». وعبارة «تاريخ الفاتورة» داخل العنصر مظللة بالأصفر، فالتاريخ قيمة إجبارية يملؤها نظامك في كل فاتورة. أما اسم العنصر ووسما الفتح والإغلاق فوصف ثابت يُنسخ كما هو. وطريقة قراءة التظليل في بقية عناصر الملف مشروحة في مقال الحقول الإجبارية والاختيارية في نظام الفوترة الوطني.
ويعرض الدليل بعد القالب مثالًا معبأً (ص14)، يظهر فيه العنصر بقيمة فعلية.

القيمة 2023-10-30 في هذا المثال قيمة توضيحية. فلا تنسخها ثابتة في نظامك، لأن العنصر يحمل تاريخ كل فاتورة على حدة.
لماذا نعتمد yyyy-mm-dd في كل فاتورة
تعرض صفحات الدليل التقني وصف التاريخ بالصيغة yyyy-mm-dd. لكن إذا نسخت نص الوصف من ملف PDF ولصقته في محرر، فقد يظهر ترتيب أجزاء التاريخ في بعض الصفحات مختلفًا عن الأمثلة (منها ص33 وص46 وص73). هذا الاختلاف في نص الوصف المنسوخ وحده، أما أمثلة XML فمتفقة.
فكل مثال XML في الدليل يكتب التاريخ بالصيغة yyyy-mm-dd، ومن قيم التاريخ الواردة في أمثلته 2023-10-30 و2023-11-01 و2023-11-20 و2022-09-27 و2026-02-27. والصيغة نفسها هي التي يذكرها وصف التاريخ في قالب معلومات الفاتورة الأساسية (ص12)، وهي صيغة معيار ISO 8601 الذي يتبعه معيار UBL.
لذلك فالقاعدة التي نعتمدها في هذا المقال، وفي كل ما ننشره عن نظام الفوترة الوطني، أن يُكتب التاريخ بالصيغة yyyy-mm-dd كما في جميع أمثلة XML في الدليل، وألا يُعامل الترتيب المختلف في النص المنسوخ على أنه صيغة بديلة مقبولة.
ولا يذكر الدليل ما يحدث إذا أُرسل التاريخ بصيغة أخرى، فلا يصح أن يُنسب إليه قبول أو رفض في هذه الحالة. وهذه واحدة من عدة ملاحظات على قراءة الدليل التقني نجمعها في مقال مستقل عن أمثلة الدليل التقني وما لا يُنسخ منها حرفيًا.
الإرشاد التاسع والتنسيق الزمني الموحد
يضع الدليل التقني في الصفحة 104 عشرة إرشادات للأنظمة المرتبطة بنظام الفوترة الوطني، تاسعها بعنوان «التوقيت الزمني»، ونصه كما يلي.
«استخدام تنسيق زمني موحد (Standard Time Format) لتجنب اختلافات المعالجة بين الأنظمة».

في هذا النص أمران منصوصان وثلاثة أمور غير منصوصة، والفصل بينها يمنع أن تُحمَّل عبارة الإرشاد أكثر مما فيها.
- المنصوص. أن يستخدم نظامك تنسيقًا زمنيًا موحدًا، وأن الغاية من ذلك تجنب اختلافات المعالجة بين الأنظمة.
- غير المنصوص في الإرشاد. لا يسمّي الإرشاد صيغة بعينها، ولا يحدد منطقة زمنية، ولا يحدد صيغة لكتابة الوقت.
والقراءة العملية لهذا الإرشاد، وهي قراءة منّا وليست نصًا في الدليل، أن يكتب نظامك التاريخ بصيغة واحدة في كل فاتورة وفي كل موضع يخزن فيه التاريخ أو يرسله، وأن تكون هذه الصيغة yyyy-mm-dd التي تستخدمها أمثلة الدليل. فإذا كان برنامجك يعرض التاريخ للمستخدم بشكل آخر، كأن يبدأ باليوم، فاجعل التحويل إلى yyyy-mm-dd خطوة ثابتة عند بناء الملف.
وشرح بقية الإرشادات العشر وما يعنيه كل منها للأنظمة المرتبطة موجود في مقال الإرشادات العشر لنظام الفوترة الوطني.
حقل التاريخ في نموذج الفاتورة على البوابة
كل ما سبق يخص ملف XML الذي يبنيه نظام محاسبي مرتبط. أما من يصدر فواتيره من البوابة مباشرة فلا يكتب ملف XML، بل يملأ نموذج «فاتورة جديدة» الذي يعرضه دليل إجراءات تنظيم الفاتورة الصادر عن الدائرة (إصدار 2026، ص6). ويضم هذا النموذج في قسم «بيانات الفاتورة» ثلاثة حقول، وهي نوع الفاتورة، وحقل «تاريخ إصدار الفاتورة» مع علامة النجمة التي تدل على أنه إجباري، ونوع العملة.
والفرق بين الموضعين جدير بالانتباه.
فصيغة yyyy-mm-dd شأن من يبني ملف XML. ومستخدم البوابة لا يحتاج إلى معرفتها لإصدار فاتورته، ولا يصح أن يُطلب منه كتابة التاريخ بها في الحقل لأن دليل الدائرة لا يذكر ذلك. وشرح بقية خانات النموذج موجود في مقال خانات تنظيم الفاتورة في نظام الفوترة الوطني.
وصيغة التاريخ مسألة شكل، أما أي تاريخ يُكتب فمسألة قانونية يحكمها نظام تنظيم شؤون الفوترة والرقابة عليها. فالمادة (3) منه تجعل وقت بيع السلعة أو الخدمة وتاريخه وقت تحقق واقعة البيع وتاريخها، وتربط المادة (5/د) إصدار الفاتورة بتحقق واقعة البيع، وتجعل المادة (5/أ) «تاريخ التنظيم والإصدار» من البيانات التي تشتمل عليها الفاتورة. وشرح المواد في مقال نظام تنظيم شؤون الفوترة والرقابة عليها رقم 34 لسنة 2019.
التاريخ بعد اعتماد الفاتورة ورمز QR
لا ينتهي دور التاريخ عند إرسال الملف. فبعد اعتماد الفاتورة يعيد نظام الفوترة الوطني رمز الاستجابة السريع، ويجب إظهاره على فاتورة البائع. ويشرح الدليل (ص105 إلى ص107) التحقق من هذا الرمز بمسحه في تطبيق سند من خيار «التحقق من المستندات الرقمية». فإذا كانت الوثيقة صحيحة يعرض التطبيق بيانات الفاتورة الأساسية الموجودة داخل الرمز، وهي ست بيانات منها تاريخ الفاتورة.
فالتاريخ الذي ترسله في ملفك هو من البيانات الأساسية التي يذكر الدليل أنها تظهر عند التحقق من الفاتورة. ومصدر الرمز وتوقيت عودته مشروحان في مقال رمز QR الصادر من دائرة ضريبة الدخل والمبيعات EINV_QR.
ما لا يحدده الدليل عن التاريخ والوقت
عبارة «تنسيق زمني» في الإرشاد التاسع تطرح على المطور أسئلة تتجاوز التاريخ. والجدول الآتي يضع كل سؤال أمام ما يجده في الدليل التقني بإصداره 1.5.
فما الذي تفعله أمام هذه الأسئلة المفتوحة؟ إليك ثلاثة أمور.
- لا تخترع صيغة للوقت وتنسبها إلى الدائرة. إذا احتاج نظامك إلى تسجيل وقت الفاتورة داخليًا، فهذا قرار في تصميم نظامك، وليس متطلبًا منصوصًا في الدليل.
- وثّق قراراتك على أنها تصميم. المنطقة الزمنية التي يعتمدها خادمك، وطريقة تحويل التاريخ من شكل العرض إلى yyyy-mm-dd، قراران تكتبهما في توثيقك الداخلي على أنهما من تصميم نظامك.
- اسأل الجهة المختصة حين يلزم. يوجّه الدليل (ص104) الاستفسارات إلى لجنة الدعم الفني لشؤون الفوترة في دائرة ضريبة الدخل والمبيعات عبر موقع الدائرة.
قائمة فحص لتاريخ الفاتورة قبل الإرسال
هذه القائمة تجمع ما ينص عليه الدليل عن التاريخ، وتفصل عنه ما هو قراءة عملية منّا، حتى تعرف مصدر كل بند.
- العنصر في موضعه.
cbc:IssueDateموجود في رأس الفاتورة ضمن قالب معلومات الفاتورة الأساسية (ص12). - القيمة غير فارغة. التاريخ مظلل بالأصفر في القالب، فهو قيمة إجبارية (ص12).
- الترتيب صحيح. السنة ثم الشهر ثم اليوم، والفاصل شرطة قصيرة، كما في الصيغة yyyy-mm-dd.
- عدد الخانات صحيح. أربع خانات للسنة، وخانتان للشهر، وخانتان لليوم، كما في المثال 2022-09-27.
- قيمة المثال ليست ثابتة. القيمة 2023-10-30 في مثال الدليل (ص14) لا تُنسخ في كل فاتورة.
- النص المنسوخ ليس مرجعًا. صيغة التاريخ في ملفك هي صيغة أمثلة XML، لا ما يظهر في نص الوصف إذا نُسخ من ملف PDF.
- صيغة واحدة في نظامك كله. التاريخ يُكتب بالصيغة نفسها في كل فاتورة وفي كل موضع، وهذه قراءتنا العملية للإرشاد التاسع.
وفحص التاريخ جزء من فحص أوسع يطلبه الإرشاد الثاني، «التحقق قبل الإرسال»، وهو التحقق من المجاميع والضرائب ورقم المكلف ورقم المشتري والحقول الإجبارية قبل إرسال الفاتورة إلى النظام.
كيف يتعامل قيود مع ملف الفاتورة
كل ما سبق عمل يقع على نظام المكلف، أي على البرنامج الذي يبني ملف الفاتورة ويرسله. ويعمل تكامل قيود مع نظام الفوترة الوطني على هذه الطبقة كما يلي.
- بناء الملف وإرساله. يبني قيود ملف الفاتورة بصيغة UBL 2.1 مع المعرّف الفريد، ويرسله إلى نظام الفوترة الوطني دون أي تدخل يدوي.
- تنبيه قبل الإرسال. يفحص قيود كل فاتورة على مستوى الحقول لحظة إنشائها، ومنها الرقم الضريبي، ونوع المستند وطريقة الدفع، ونسبة ضريبة المبيعات العامة، واكتمال البنود، وينبهك بأي خطأ قبل إرسالها لتقليل حالات الرفض.
- حالة كل فاتورة أمامك. تعيد الدائرة حالة الفاتورة ورسالة الخطأ، ويعرضها قيود في لوحة الحالة، ومنها «مرسلة» و«مرسلة مسبقًا» و«لم تُرسل» مع رسالة الخطأ.
- إعادة إرسال بالمعرّف نفسه. حين تعيد إرسال الفاتورة من لوحة الحالة، تُرسل بالمعرّف UUID نفسه.
ولصورة أوسع عن النظام وطريقة ربط منشأتك به، اقرأ مقال نظام الفوترة الوطني الالكتروني، أو تعرّف على ما يقدمه قيود في نظام الفوترة الوطني.
فوترة إلكترونية ومحاسبة متكاملة في نظام واحد
قيود متكامل مع نظام الفوترة الوطني (JoFotara). تُصدر فاتورتك بالدينار الأردني من قيود فتُقيَّد في دفاترك تلقائيًا وتُرسل إلى النظام، وبعد قبولها يعود عليها رمز QR من دائرة ضريبة الدخل والمبيعات.
الأسئلة الشائعة
ما صيغة تاريخ الفاتورة في نظام الفوترة الوطني؟
يُكتب التاريخ بالصيغة yyyy-mm-dd، أي السنة بأربع خانات ثم الشهر بخانتين ثم اليوم بخانتين، مع شرطة قصيرة بين كل جزأين، مثل 2023-10-30. وهي الصيغة المستخدمة في جميع أمثلة XML في الدليل التقني لدائرة ضريبة الدخل والمبيعات.
في أي عنصر من ملف XML يُكتب تاريخ الفاتورة؟
يُكتب في العنصر cbc:IssueDate في رأس الفاتورة، ضمن قالب معلومات الفاتورة الأساسية في الدليل التقني (ص12). وقيمة التاريخ فيه مظللة بالأصفر، وهو اللون الذي يدل على الحقول الإجبارية.
لماذا يظهر ترتيب التاريخ مختلفًا عند نسخ نص الدليل التقني؟
تعرض صفحات الدليل وصف التاريخ بالصيغة yyyy-mm-dd، لكن نص الوصف إذا نُسخ من ملف PDF قد يظهر بترتيب مختلف في بعض الصفحات (منها ص33 وص46 وص73). وجميع أمثلة XML تكتب التاريخ بالصيغة yyyy-mm-dd، لذلك تُعتمد صيغة الأمثلة، ولا يُعامل النص المنسوخ على أنه صيغة بديلة.
ماذا يقصد الإرشاد التاسع بالتنسيق الزمني الموحد؟
ينص الإرشاد على «استخدام تنسيق زمني موحد (Standard Time Format) لتجنب اختلافات المعالجة بين الأنظمة»، دون أن يسمّي صيغة بعينها. ولا يحدد الدليل صيغة للوقت ولا منطقة زمنية.
هل أكتب التاريخ بصيغة yyyy-mm-dd عند إصدار الفاتورة من البوابة؟
تخص هذه الصيغة ملف XML الذي يبنيه نظام محاسبي مرتبط. أما نموذج الفاتورة على البوابة ففيه حقل «تاريخ إصدار الفاتورة» الإجباري، ولا يوثّق دليل الدائرة شكل عرض التاريخ فيه.
المراجع
- دائرة ضريبة الدخل والمبيعات، الدليل التقني للربط مع نظام الفوترة الوطني من خلال واجهة برمجة التطبيقات (API)، الإصدار 1.5، 2026، ص12 وص14 وص33 وص46 وص73 وص104 إلى ص107.
- دائرة ضريبة الدخل والمبيعات، دليل إجراءات تنظيم الفاتورة في نظام الفوترة الوطني الإلكتروني الأردني، إصدار 2026، ص6 وص8.
- نظام تنظيم شؤون الفوترة والرقابة عليها رقم (34) لسنة 2019 وتعديلاته، المادتان (3) و(5).
