الفوترة الإلكترونية في مصر: ما الذي تطلبه مصلحة الضرائب فعليًا

تطلب السعودية والأردن والإمارات جميعًا من المنشأة إرسال مستند XML، موقّعًا أو مختومًا بشيء يمكن للمنشأة نفسها الاحتفاظ به. أما مصلحة الضرائب المصرية (ETA) فتطلب مستند JSON، موقّعًا بشهادة لا يمكنها عادةً — بحكم تصميمها — مغادرة رمز USB مادي. وهذا الفرق الواحد يُشكّل التكامل بأكمله.

التزامان لا التزام واحد

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

المستند JSON، والإرسال دفعة واحدة

الفاتورة نفسها كائن JSON لا مستند UBL — ومصر هي الاستثناء في المنطقة على مستوى الصيغة كما على مستوى التوقيع. وتستقبل نقطة الدخول مصفوفة: يمكن إرسال عدة مستندات في استدعاء واحد، ويفصل الردّ ما قُبل عمّا رُفض. ورمز الاستجابة HTTP 200 على ذلك الاستدعاء يعني أن المصلحة قرأت الدفعة، لا أنها قبلت كل مستند فيها.

التوقيع: CAdES-BES من رمز تملكه أنت، لا تصدره المصلحة

يحتاج كل مستند توقيع CAdES-BES يُنتَج بشهادة المكلَّف نفسه — وتقيم تلك الشهادة على رمز مادي (Hardware Token)، في مقر المنشأة فعليًا، بحكم التصميم. لا تستطيع أي خدمة سحابية الاحتفاظ بها نيابة عن المنشأة، لأن جوهر الرمز المادي هو ألا يغادر المفتاح مكانه أبدًا.

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

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

ما الذي يحمله المستند أيضًا

• نوعا المُصدِر والمستلِم — البائع دائمًا نوع «B» (منشأة)؛ والمشتري «B» إن كان له رقم ضريبي أو «P» لشخص بلا رقم.
• رقم فاتورة البائع نفسه كحقل internalID — وهو الحقل الذي تُطابِق عليه المصلحة إشعار الدائن، لا أي معرّف داخلي في قاعدة البيانات.
• كل مبلغ مُعاد بيانه بالجنيه المصري، حتى في فاتورة بعملة أجنبية — مع المبلغ الأصلي وسعر الصرف مرفقَين لا بديلَين عنه. فالفاتورة بالدولار التي تُصرِّح بأرقامها الدولارية كأنها جنيهات تُقلّل الوعاء الضريبي بمقدار سعر الصرف في كل بند.
• توقيع CAdES-BES تحت النوع «I» — توقيع المُصدِر نفسه، وهو ما يحتاجه كل إرسال أيًا كان نوع المستند.
• في إشعار الدائن، إشارة إلى internalID الخاص بالفاتورة الأصلية. الإشعار الذي لا يُسمّي شيئًا يُرفض بوصفه توريدًا سالبًا غير مرتبط.

التسجيل: الرمز المادي يسبق البرمجيات

1. 1سجّل المنشأة في بوابة المكلَّفين لدى المصلحة واحصل على Client ID وSecret بنظام OAuth2 — وهذان يوثّقان استدعاء الواجهة البرمجية، لا المستند نفسه.
2. 2احصل على شهادة توقيع على رمز مادي عبر مزوّد مرخَّص. هذه الخطوة أطول مراحل التكامل زمنًا، وتستحق البدء بها قبل كتابة أي شيفرة.
3. 3شغّل خدمة توقيع محلية تصل إلى الرمز المادي وتُنفّذ صيغة التسلسل القانونية الخاصة بالمصلحة، أو وجّه فاتورتي إليها إن كانت قائمة بالفعل.
4. 4أرسل مستندات تجريبية إلى بيئة ما قبل الإنتاج (preprod.invoicing.eta.gov.eg) واقرأ تقسيم acceptedDocuments وrejectedDocuments في كل ردّ، لا رمز HTTP وحده.
5. 5انتقل إلى مضيفات الإنتاج فقط بعد أن تعود فاتورة قياسية وإشعار دائن، كلاهما، مقبولَين من بيئة ما قبل الإنتاج.

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

1. 1ابدأ إجراءات الحصول على الرمز المادي في الأسبوع الأول — فهو الأطول زمنًا هنا، لا الشيفرة البرمجية.
2. 2قرّر ماذا يحدث حين يتعذّر الوصول إلى حامل الرمز. رمز USB مادي واحد بلا خطة احتياطية نقطة فشل وحيدة لكل فاتورة تُصدرها المنشأة.
3. 3ابنِ خطوة التسلسل القانوني مطابقة لقاعدة المصلحة تمامًا، حقلًا حقلًا، واختبرها على مستند بمصفوفات متداخلة قبل الوثوق بها على فاتورة حقيقية.
4. 4حوّل كل بند إلى الجنيه المصري بسعر صرف الفاتورة نفسه، واحتفظ بالمبلغ بالعملة الأصلية بجانبه لا بدلًا منه.
5. 5اقرأ تقسيم المقبول والمرفوض في كل ردّ عبر الشيفرة، لا رمز HTTP وحده أبدًا.
6. 6اربط إشعارات الدائن بـ internalID الخاص بالبائع على الفاتورة الأصلية، لا بمعرّف سجل داخلي.
7. 7أكّد بشكل منفصل ما إذا كان التزام الإيصال الإلكتروني ينطبق أيضًا على أي جانب من نقاط بيع المنشأة — فتكامل الفاتورة الإلكترونية لا يغطيه.
8. 8احتفظ بالحمولة الموقَّعة، والنص القانوني الذي وُقِّع عليه، وردّ المنصة معًا — فإعادة إنتاج توقيع لاحقًا يحتاج الثلاثة.

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

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

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

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

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

من أين تبدأ

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