التوقيع الرقمي في نظام الفوترة الوطني لا يقع على عاتق المكلف. فالدليل التقني للربط مع نظام الفوترة الوطني، في إصداره 1.5، لا يطلب من المكلف توقيع فاتورته بنفسه، ولا يطلب منه شهادة رقمية من نوع X.509 ولا توقيعًا بصيغة XAdES. ما يرسله المكلف هو ملف الفاتورة مع رقم المستخدم والمفتاح السري، ثم تعود إليه الفاتورة موقّعة من دائرة ضريبة الدخل والمبيعات ضمن رد النظام.
باختصار، لا شهادة رقمية تشتريها ولا مفتاح توقيع تديره. بيانات الربط في الطلب قيمتان يولّدهما النظام لك من شاشة «ربط الأجهزة»، والفاتورة الموقعة يعيدها النظام في حقل اسمه EINV_SINGED_INVOICE بعد قبول الفاتورة.
يفيد هذا المقال صاحب المنشأة الذي يسمع عن الشهادات الرقمية ويخشى أن يكون الربط مشروعًا تقنيًا مكلفًا، ويفيد المطور الذي يبني الربط ويريد أن يعرف أين ينتهي دوره. ويقف المقال عند ما يقوله الدليل التقني نصًا، ويذكر صراحة ما لا يقوله.
التوقيع الرقمي في نظام الفوترة الوطني كما يرسمه الدليل التقني
لا يحتوي الدليل التقني للربط، في أي صفحة من صفحاته، على خطوة يوقّع فيها المكلف الفاتورة قبل إرسالها، ولا على طلب شهادة رقمية من جهة إصدار. وكل ما يطلبه من المكلف في مسار الإرسال يقع في ثلاثة أمور.
- ملف الفاتورة بصيغة XML مبنيًا على معيار UBL 2.1.
- ترميز الملف بصيغة Base64 ووضعه داخل ملف JSON.
- رقم المستخدم والمفتاح السري اللذين يولّدهما النظام من شاشة «ربط الأجهزة».
أما التوقيع فيظهر في المسار مرة واحدة، في جهة الرد. فالمخطط الرسمي لتسلسل الإرسال يعرض الفاتورة الموقعة ورمز QR بوصفهما ما يعود من نظام الفوترة بعد قبول الفاتورة، لا ما يرسله المكلف إليه.
ولا يشرح الدليل سبب هذا التصميم، ولا يصف كيف توقّع الدائرة الفاتورة، ولا نوع الشهادة التي تستعملها في ذلك. لذلك لا يدخل هذا المقال في أي تفسير لهذه الأسئلة، ويكتفي بما يحدده الدليل من أدوار للطرفين.
وقد يكون القارئ اعتاد في أنظمة فوترة أخرى أن يحمل البائع شهادة رقمية يوقّع بها فواتيره. هذا النموذج غير موجود في نظام الفوترة الوطني بحسب الإصدار 1.5 من الدليل، فلا تنقل خطواته إلى مشروع الربط مع الدائرة.
ما يرسله المكلف في كل فاتورة
يحدد الدليل التقني محتوى الطلب في الصفحة 10، فينص على أن ملف JSON المرسل يحتوي على ثلاثة مكونات. وهذه المكونات هي Client ID وSecret Key والفاتورة بصيغة XML. وتضيف الصفحة نفسها أن القيمتين الأوليين تُؤخذان من شاشة «ربط الأجهزة» في نظام الفوترة الوطني.
لاحظ أن القائمة خالية من أي شهادة أو توقيع أو مفتاح خاص بالمكلف. ويوضح المثال البرمجي في الدليل أين يذهب كل مكون عند الإرسال الفعلي.
- رقم المستخدم والمفتاح السري يُرسلان ترويستين في طلب HTTP باسم
Client-IdوSecret-Key، لا داخل جسم ملف JSON. - ملف الفاتورة يُرمَّز بصيغة Base64 ويوضع في جسم الطلب تحت المفتاح
invoice. - نوع المحتوى يُحدَّد في ترويسة ثالثة بالقيمة
application/json.
وخطوة Base64 ترميز لا أكثر. فترميز Base64 يحوّل الملف إلى نص يمكن نقله داخل JSON، ولا يخفي محتواه ولا يوقّعه، ولا يحتاج إلى مفتاح أو شهادة. وتفاصيل هذه الخطوة في مقال ترميز Base64 في نظام الفوترة الوطني.
وبنية ملف الفاتورة نفسه، من سطر التعريف إلى عناصر البائع والمشتري والبنود، مشروحة في معيار UBL 2.1 في نظام الفوترة الوطني. ولا يضيف الدليل إلى هذه البنية عنصر توقيع يملؤه المكلف.
من أين تأتي الفاتورة الموقعة
يعرض الدليل التقني في الصفحة 9 مخططًا لتسلسل إرسال الفاتورة. يبدأ المخطط من نظام المكلف، فيُبنى ملف XML ويُرمَّز بصيغة Base64 داخل ملف JSON، وتحمل الترويسة رقم المستخدم والمفتاح السري. ثم يصل الطلب إلى نظام الفوترة الوطني، فتخرج منه نتيجة الإرسال في أحد مسارين.
- مسار القبول. حالتا Submitted وAlready Submitted تقودان في المخطط إلى «Signed Invoice & QR Code»، أي الفاتورة الموقعة ورمز QR.
- مسار الخطأ. حالة Error تقود إلى «Error List»، أي قائمة بأسباب الرفض.
ويتطابق ذلك مع وصف الرد في صفحات الدليل الأخيرة. فالحقل EINV_SINGED_INVOICE يحمل الفاتورة الموقعة من الدائرة بترميز Base64، ويعيده النظام نفسه. ويرد اسم الحقل في الدليل وفي أمثلة الرد بهذا الهجاء، فاقرأه في برنامجك كما ورد.
ويلخص الجدول التالي ما يعود في كل حالة من حالات الفاتورة كما يصفها الدليل.
مرِّر الجدول أفقيًا لعرض بقية الأعمدة
النتيجة العملية أن الفاتورة الموقعة لا توجد إلا لفاتورة قبلها النظام. فإن رُفضت الفاتورة فلا شيء موقّع يعود، وسبب الرفض تقرؤه في رسالة الخطأ داخل الرد. ولهذا يوصي الدليل بأن تحكم على الفاتورة من الحقل EINV_STATUS لا من رمز الاستجابة التقني وحده.
وإن ضاع منك رمز QR لفاتورة مقبولة فالطريق الموثق لاستعادته هو إعادة إرسالها بالرقم والمعرّف الفريد نفسيهما، فيعود الرمز الأصلي مع حالة ALREADY_SUBMITTED. وتفاصيل ذلك في مقال حالة ALREADY_SUBMITTED في نظام الفوترة الوطني.
رقم المستخدم والمفتاح السري: بيانات الربط التي يطلبها الدليل
إذا لم تكن هناك شهادة رقمية، فما الذي يعرّف النظام بالجهة المرسلة؟ الجواب في الدليل هو رقم المستخدم (Client ID) والمفتاح السري (Secret Key). وهما القيمتان الوحيدتان المتعلقتان بهوية المرسل في ترويسة الطلب كما يعرضها المثال البرمجي.
وثلاث حقائق عنهما تكفي لفهم موقعهما في مسار الإرسال.
- يولّدهما النظام ولا تشتريهما من جهة خارجية. ينشئهما المستخدم الرئيسي من شاشة «ربط الأجهزة» في حساب المنشأة على نظام الفوترة الوطني، فيكتب اسم مستخدم ويختار تسلسل مصدر الدخل، ثم يولّد النظام القيمتين تلقائيًا.
- يرتبط كل زوج منهما بتسلسل مصدر دخل واحد، وهو التسلسل الذي اختاره المستخدم الرئيسي عند إنشاء الربط.
- يظهران في قائمة ربط الأجهزة في صف يضم رقم المستخدم والمفتاح السري، وبجانب كل منهما زر نسخ.
وخطوات الإنشاء بالتفصيل، مع لقطات الشاشة وأثر الربط على تنظيم الفواتير من البوابة، في رقم المستخدم والمفتاح السري في نظام الفوترة الوطني. ولا يكرر هذا المقال تلك الخطوات.
ويقود الخطأ في هاتين القيمتين إلى أخطاء محددة في الدليل التقني. فرمز الخطأ 403 يربطه الدليل بخطأ في Client_ID أو Secret_Key، وتفاصيله في مقال خطأ 403 في نظام الفوترة الوطني. ويذكرهما الدليل كذلك ضمن أسباب الخطأ 500، لكن «بدرجة أقل» من الرقم الضريبي وتسلسل مصدر الدخل.
حماية رقم المستخدم والمفتاح السري
غياب الشهادة الرقمية لا يعني غياب المسؤولية. فرقم المستخدم والمفتاح السري هما ما يرسل به البرنامج الفواتير باسم المكلف، والدليل التقني يعامل حمايتهما بوصفها إرشادًا مستقلًا من إرشاداته العشرة.
ويقول الإرشاد السابع، وعنوانه «الأمان»، إن على المكلف حماية بيانات الربط وعدم تخزينها مكشوفة في الكود البرمجي. ويضع الدليل مسؤولية سرية القيمتين على المكلف كاملة، فالمكلف بنص الدليل «يتحمّل كامل المسؤولية عن أي استخدام غير مصرح به».
ومن ذلك تخرج قائمة قصيرة تراجعها مع من يبني الربط لك.
- لا تكتب القيمتين داخل الكود البرمجي بشكل مكشوف، كما ينص الإرشاد السابع.
- لا ترسلهما في رسائل عامة أو في لقطات شاشة غير مطموسة، فهما وحدهما بيانات الربط في ترويسة الطلب.
- اعرف أين تجدهما عند الحاجة، وهي قائمة ربط الأجهزة لدى المستخدم الرئيسي.
- لا تنسخ المثال البرمجي في الدليل كما هو. فهو يرسل ترويسة Cookie بقيمة جلسة محددة، وهذه ليست من مكونات الطلب الثلاثة ولا يصح نقلها إلى برنامجك.
أشياء في مسار الفوترة لا تُعد شهادة رقمية
قد يختلط على القارئ اسم «شهادة» بأشياء أخرى في رحلة الانضمام إلى نظام الفوترة الوطني. وهذه أربعة منها، لا يقوم أي منها مقام شهادة توقيع رقمي.
- وثيقة التسجيل. عنوانها الرسمي «وثيقة تسجيل في نظام الفوترة الوطني الالكتروني»، وتنص على أن المنشأة ذات الرقم الضريبي المذكور مسجلة في النظام. فهي إثبات تسجيل، لا ترخيص ولا اعتماد ولا أداة توقيع. وخطوات استخراجها في مقال التسجيل في نظام الفوترة الوطني.
- رمز QR. يعيده النظام في الحقل EINV_QR بعد قبول الفاتورة، ولا يولّده برنامج المكلف. ويشترط الدليل إظهاره على فاتورة البائع، ويجعل وجوده في الرد شرطًا لاعتبار الفاتورة مستلمة ومقبولة.
- ترميز Base64. خطوة تحويل لنقل الملف داخل JSON، لا تحتاج إلى مفتاح ولا تضيف توقيعًا.
- اعتماد البرنامج المحاسبي. يطلب الدليل من المكلف التنسيق مع «مبرمج النظام أو مزود الحلول التقنية المعتمد لديه» لاستكمال المتطلبات الفنية. والمقصود المزوّد الذي يتعامل معه المكلف، إذ لا تنشر الأدلة الرسمية للدائرة برنامجًا لاعتماد البرامج المحاسبية ولا قائمة بمزودين معتمدين.
وفي تطبيق سند، الذي يحصر فيه الدليل التحقق من رمز QR، تظهر على الشاشة الرئيسية أيقونتان باسم «التحقق من المستندات الرقمية» و«التحقق من التوقيع الرقمي». والدليل يوجّه المكلف إلى الأولى للتحقق من الرمز، ولا يشرح الثانية. وطريقة التحقق خطوة بخطوة في مقال التحقق من الفاتورة بتطبيق سند.
ما لا يذكره الدليل التقني عن التوقيع
الدقة هنا أهم من الإجابة الكاملة. فالدليل التقني يحدد من يوقّع، لكنه يسكت عن تفاصيل كثيرة يسأل عنها المطورون، ولا يصح ملء هذا السكوت بتخمين.
- طريقة التوقيع. لا يذكر الدليل الخوارزمية التي توقّع بها الدائرة، ولا نوع الشهادة التي تستعملها.
- بنية الفاتورة الموقعة بعد فك الترميز. يعيد النظام الحقل EINV_SINGED_INVOICE بترميز Base64، لكن الدليل لا يشرح ما يحتويه بعد فك الترميز، فلا تبنِ عليه منطقًا في برنامجك قبل التحقق منه.
- بنية رمز QR من الداخل. لا يوثق الدليل ترتيب البيانات داخل الرمز. وما يذكره أن تطبيق سند يعرض عند صحة الرمز بيانات الفاتورة الأساسية الموجودة داخله.
- حفظ الفاتورة الموقعة. يطلب الإرشاد الخامس تخزين الرقم والمعرّف الفريد ورمز QR والحالة لأغراض التتبع وإعادة الاسترجاع. ولا تذكر قائمته الفاتورة الموقعة، فقرار حفظها قرار تتخذه أنت مع مزوّد برنامجك.
وإذا وجدت مصدرًا يشرح خوارزمية التوقيع في نظام الفوترة الوطني أو يطلب منك شهادة للربط، فاسأل عن مصدره الرسمي قبل أن تبني عليه. فالإصدار 1.5 من الدليل، الصادر في مايو 2026، لا يحتوي على شيء من ذلك.
قائمة فحص قبل بناء الربط
هذه قائمة تراجعها مع فريقك أو مع مزوّد برنامجك المحاسبي قبل بدء العمل، وكل بند فيها يستند إلى الدليل التقني.
- احذف من خطة العمل أي بند لشراء شهادة رقمية أو إعداد توقيع من جهة المكلف، فالدليل لا يطلبه.
- أنشئ رقم المستخدم والمفتاح السري من شاشة «ربط الأجهزة» بالمستخدم الرئيسي، واختر تسلسل مصدر الدخل الصحيح.
- ابنِ ملف الفاتورة على معيار UBL 2.1 وتحقق من الحقول الإلزامية والمجاميع قبل الإرسال، كما ينص الإرشاد الثاني.
- رمّز الملف بصيغة Base64 وضعه في جسم الطلب تحت المفتاح invoice، وأرسل القيمتين في الترويسة.
- اقرأ الحقل EINV_STATUS في كل رد، واحفظ الرقم والمعرّف الفريد ورمز QR والحالة.
- أعد الإرسال بالرقم والمعرّف الفريد نفسيهما عند فشل الإرسال أو انقطاع الاتصال، ولا تولّد معرّفًا جديدًا، كما ينص الإرشادان الثالث والثامن. وتفاصيل المعرّف في مقال المعرّف الفريد UUID.
- أظهر رمز QR العائد على فاتورة البائع، فالدليل يشترط إظهاره.
ولفهم الصورة الأشمل لنظام الفوترة الوطني ومساري الانضمام إليه، من البوابة أو بربط برنامج محاسبي، راجع مقال نظام الفوترة الوطني الإلكتروني في الأردن. وتشرح مقالة مستقلة في هذا القسم نموذج الاعتماد الفوري في نظام الفوترة الوطني، أي موافقة النظام على الفاتورة بعد إرسالها، وهذا وصف منا لا عبارة من الدائرة.
كيف يتعامل قيود مع هذه الخطوة
إذا كنت تستعمل برنامج قيود المتكامل مع نظام الفوترة الوطني، فلا تحتاج إلى شهادة رقمية أو توقيع من طرفك. يبني قيود ملف الفاتورة بمعيار UBL 2.1 مع معرّفها الفريد، ويرسله إلى النظام دون تدخل يدوي. ثم يعرض على الفاتورة رمز QR الذي تعيده الدائرة بعد قبولها.
وقبل الإرسال يفحص قيود حقول كل فاتورة لحظة إنشائها، وهي الرقم الضريبي ونوع المستند وطريقة الدفع ونسبة ضريبة المبيعات العامة واكتمال البنود، وينبهك بأي خطأ قبل إرسالها لتقليل حالات الرفض. وبعد الإرسال تعيد الدائرة حالة الفاتورة ورسالة الخطأ، ويعرضها قيود في لوحة الحالة.
فوترة إلكترونية ومحاسبة متكاملة في نظام واحد
قيود متكامل مع نظام الفوترة الوطني (JoFotara). تُصدر فاتورتك بالدينار الأردني من قيود فتُقيَّد في دفاترك تلقائيًا وتُرسل إلى النظام، وبعد قبولها يعود عليها رمز QR من دائرة ضريبة الدخل والمبيعات.
الأسئلة الشائعة
هل يحتاج المكلف شهادة رقمية للربط مع نظام الفوترة الوطني؟
لا يطلب الدليل التقني للربط في إصداره 1.5 شهادة رقمية من المكلف، ولا توقيعًا من طرفه. ويكتفي في المصادقة برقم المستخدم والمفتاح السري اللذين يولّدهما النظام من شاشة «ربط الأجهزة».
من يوقّع الفاتورة في نظام الفوترة الوطني؟
تعيد دائرة ضريبة الدخل والمبيعات الفاتورة موقعة ضمن رد النظام، في الحقل EINV_SINGED_INVOICE بترميز Base64. ولا يصف الدليل طريقة التوقيع ولا نوع الشهادة التي تستعملها الدائرة.
هل تعود الفاتورة الموقعة إذا رُفضت الفاتورة؟
لا تعود. ففي حالة NOT_SUBMITTED تكون قيمة EINV_SINGED_INVOICE فارغة، ومعها رمز QR والمعرّف الفريد ورقم الفاتورة. وسبب الرفض يظهر في رسالة الخطأ داخل الرد.
هل ترميز Base64 نوع من التوقيع؟
ليس كذلك. ترميز Base64 يحوّل ملف XML إلى نص ينتقل داخل ملف JSON، ولا يحتاج إلى مفتاح ولا يخفي المحتوى ولا يضيف إليه توقيعًا. والتوقيع في المسار كله يأتي من جهة الدائرة في الرد.
هل وثيقة التسجيل في نظام الفوترة الوطني شهادة رقمية؟
ليست كذلك. فوثيقة التسجيل تنص على أن المنشأة ذات الرقم الضريبي المذكور مسجلة في نظام الفوترة الوطني الإلكتروني. ولا تُستعمل في توقيع الفواتير ولا في المصادقة على الإرسال.
من المسؤول إذا استُعمل المفتاح السري دون إذن؟
يضع الدليل التقني المسؤولية على المكلف، إذ ينص على أنه «يتحمّل كامل المسؤولية عن أي استخدام غير مصرح به». ولذلك يطلب الإرشاد السابع حماية بيانات الربط وعدم تخزينها مكشوفة في الكود البرمجي.
المراجع
- دائرة ضريبة الدخل والمبيعات، الدليل التقني للربط مع نظام الفوترة الوطني من خلال واجهة برمجة التطبيقات (API)، الإصدار 1.5، 2026.
- دائرة ضريبة الدخل والمبيعات، دليل إجراءات الانضمام إلى نظام الفوترة الوطني الإلكتروني الأردني.
