الفوترة الإلكترونية في الأردن: دليل التكامل مع جوفوترة

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

منصة إبلاغ، لا بوابة مصادقة

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

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

رمز نوع الفاتورة: ثلاثة أرقام لثلاثة أسئلة

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

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

ما الذي يجب أن يحمله المستند

• مستند XML وفق UBL 2.1 — بملف تعريف جوفوترة الخاص، يُرسَل إلى نقطة استقبال المنصة كحقل مُرمَّز بترميز Base64 داخل جسم JSON، لا كملف يُرفَع مباشرة.
• الرقم الضريبي للبائع (TIN): من ٨ إلى ١٢ رقمًا، وليس رقمًا وهميًا مكررًا مثل ٠٠٠٠٠٠٠٠.
• قيمة عداد الفاتورة (ICV) — عدّ بلا فجوات لكل مستند أبلغ عنه البائع، منفصل عن رقم الفاتورة المقروء.
• فئة ضريبية لكل بند من رموز جوفوترة الثلاثة الخاصة بها — S لنسبة خاضعة أعلى من صفر، وO للنسبة الصفرية، وZ للمعفى.
• في إشعار الدائن: إشارة إلى رقم الفاتورة الأصلية ومعرّفها الفريد (UUID)، مع سبب الإصدار. الإشعار بلا مرجع يُرفض مباشرة.

التسجيل: بلا شهادة، بيانات اعتماد فقط

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

1. 1سجّل المنشأة في بوابة جوفوترة (jofotara.gov.jo) واحصل على Client-Id وSecret-Key — بيانات الاعتماد الوحيدة التي تتحقق منها نقطة الاستقبال.
2. 2حيثما يستلزم تسجيل البائع ذلك، دوّن رقم تسلسل مصدر الدخل الصادر عند التسجيل — فهو يحدّد النشاط المسجَّل الذي يتبعه الإيراد، ويُترك كليًا بدل إرساله فارغًا.
3. 3اختبر على بيئة المحاكاة أولًا، ببيانات اعتماد من الشكل نفسه الذي تصدره الدائرة لها — بيانات المحاكاة لا تلامس السجل الفعلي أبدًا.
4. 4أرسل فاتورة حقيقية واقرأ ما يعود قبل أن تعتمد عليه: يحمل ردّ القبول رمز الاستجابة السريعة، وهذا الرمز — لا رمز يولّده نظامك بنفسه — هو ما يجب طباعته على الفاتورة.
5. 5انتقل إلى بيانات اعتماد الإنتاج بعد أن تُقبَل إرسالات المحاكاة بلا مشاكل، بما في ذلك إشعار دائن واحد على الأقل.

قائمة تحقّق التكامل

1. 1احصر كل نظام يُصدر فاتورة، كما في أي مشروع فوترة إلكترونية — نظام تخطيط الموارد، ونقطة البيع، وصفحة الحجز.
2. 2تحقّق من الرقم الضريبي عند الإدخال: من ٨ إلى ١٢ رقمًا، وارفض القيم الوهمية قبل أن تصل إلى إرسال فعلي.
3. 3احسب رمز نوع الفاتورة من نطاق العملية الفعلي وطريقة سدادها وصفة تسجيل البائع نفسه — لا تُثبّته أبدًا.
4. 4حدّد من يملك تسلسل عداد الفاتورة (ICV). عدّاد واحد، نظام واحد — بصرامة سلسلة تجزئة زاتكا نفسها، رغم أن لا شيء هنا مرتبط تشفيريًا.
5. 5خزّن رمز الاستجابة السريعة الذي تعيده المنصة مقابل سجل الفاتورة، واطبع هذا الرمز نفسه — لا بديلًا مولَّدًا محليًا أبدًا.
6. 6اجعل إشعارات الدائن والمدين تحمل رقم الفاتورة الأصلية ومعرّفها الفريد وسببًا مذكورًا قبل أن يسمح نظامك بإرسالها.
7. 7قرّب مبالغ الدينار الأردني إلى ثلاث خانات عشرية دومًا لا خانتين — فالدينار ينقسم إلى ألف فلس، والتقريب بخانتين يولّد فرقًا حقيقيًا عبر دورة فواتير كاملة.
8. 8احتفظ بملف XML وردّ المنصة ورمز الاستجابة السريعة المُعاد معًا — لا بتقرير إجماليات فقط — للمدة التي يحدّدها مستشارك الضريبي للسجلات الأردنية.
9. 9أكّد أي أنشطتك المسجَّلة مشمولة فعليًا بالإلزام، ومنذ أي تاريخ، مباشرة مع دائرة ضريبة الدخل والمبيعات — فالتطبيق اتسع تدريجيًا، وهذا الافتراض هو ما لا تستطيع هذه القائمة أن تكشفه عنك.

أين تتعثّر الفرق فعليًا

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

كيف تتعامل فاتورتي مع هذا

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

لا يُرسَل إشعار الدائن بلا مرجع فوترة إلى الفاتورة التي يعدّلها — رقمها ومعرّفها الفريد، مع سبب الإصدار — لأن الإشعار بلا مرجع لن تقبله المنصة أصلًا. ولأنه لا توجد شهادة يُسجَّل بها النظام، فإن نقل مساحة عمل أردنية من بيئة المحاكاة إلى الإنتاج يقتصر على تبديل Client-Id وSecret-Key في الإعدادات، لا جولة جديدة من توليد المفاتيح.

من أين تبدأ

ابدأ بالتسجيل لا بالبرمجة. يستغرق الحصول على Client-Id وSecret-Key من الدائرة وقتًا أطول من إعدادهما بعد وصولهما، فاطلبهما في الأسبوع نفسه الذي تبدأ فيه تنظيف الأرقام الضريبية وتصنيف أي من بنود إيرادك محلي أو تصدير أو منطقة حرة أو منطقة تطوير. وبحلول وصول بيانات الاعتماد، ينبغي ألا يبقى سؤال مفتوح سوى: هل تعود فواتيرك التجريبية مقبولة؟