منذ غرّة جانفي 2026، صار إيداع شهادات الخصم من المورد يمرّ وجوبًا عبر منظومة تاج، بالنسبة إلى كل المؤسسات التونسية. وأمامها طريقان: الإدخال المباشر، وهو محتمل لبضع شهادات في الشهر، وإيداع ملف XML، وهو الطريق الوحيد العملي متى ارتفع العدد.
يصف هذا الدليل الالتزام وبنية الملف وأسباب الرفض — لأنّ رسالة الخطأ في المنظومة أقلّ نفعًا من المشكل نفسه في أغلب الحالات.
من المعني، وفي أيّ أجل
كل مؤسسة تُجري خصمًا من المورد هي منخرطة في المنظومة وعليها إيداع شهاداتها فيها. والأجل محدّد بـنهاية الشهر الموالي لشهر الدفع: فعملية دُفعت في جويلية 2026 تُحرَّر شهادتها في أجل أقصاه 31 أوت 2026.
فالإيقاع شهري إذن، وهذا له أثر عملي يُستهان به: مسارٌ يتطلّب تدخّلًا يدويًا ينكسر اثنتي عشرة مرّة في السنة، لا مرّة واحدة.
بنية الملف باختصار
الصيغة محدّدة بكرّاس الشروط CCT-RS-V2 وبثلاثة مخطّطات XSD نشرتها الإدارة. والعنصر الجذر هو DeclarationsRS، ويحتوي:
| العنصر | الدور |
|---|---|
Declarant | المعرّف الجبائي للمودِع |
ReferenceDeclaration | نوع الإيداع والسنة والشهر |
AjouterCertificats | الشهادات المضافة، لكلّ منها مستفيدها وعملياتها |
ModifierCertificats | تصحيحات إيداع سابق |
AnnulerCertificats | الإلغاءات |
وتحمل كل Certificat مستفيدًا — يُعرَّف بـواحد فقط من المعرّف الجبائي أو بطاقة التعريف أو جواز السفر أو بطاقة الإقامة — وتاريخ دفع، ومرجعًا خاصًّا بالمصرّح، وعملية أو أكثر.
وتحمل كل Operation المبالغ (دون أداء، والأداء، وبكامل الأداء، والخصم، والصافي المدفوع)، ونسبة الخصم، ورمز العملية من بين ستة وثلاثين رمزًا (RS1_000001 وRS2_000003 وغيرها).
أسباب الرفض الأربعة
1. المبالغ بفاصلة عشرية
وهو الأول بفارق كبير. فالمخطّط يعرّف المبالغ أعدادًا صحيحة مقرَّبة بالمليم. والدينار بثلاث منازل، فمبلغ 1 234,500 د يُكتب:
<MontantHT>1234500</MontantHT>أمّا جدول البيانات فيحفظ المبلغ نفسه 1234.5. وإذا صُدِّر كما هو، أسقطت الفاصلةُ العشرية الإيداعَ كلّه. وهو خلاف الحدس — تكتب مبلغًا فتتوقّع فاصلة — ولهذا تفشل أوّل إيداعات كثيرة.
2. المعرّف الجبائي المختلّ
الصيغة صارمة: سبعة أرقام يتبعها حرف كبير، مثل 1234567A. وهذا يسري على المصرّح وعلى كل مستفيد يُعرَّف بالمعرّف الجبائي.
ومعرّفٌ اقتُطع إلى ستة أرقام، أو تحوّل حرفه إلى صغير أثناء نسخ ولصق، لا يظهر في تصدير من مئات الأسطر.
3. تكرار المراجع
مرجع الشهادة لدى المصرّح (Ref_certif_chez_declarant) يجب أن يكون فريدًا في الإيداع. وسطران يتقاسمانه يُسقطان الكلّ.
والحالة النمطية ليست خطأ إدخال، بل عدّاد أُعيد إلى الصفر مع بداية السنة، أو تصديران دُمجا وكلٌّ منهما يبدأ من 1.
4. الحساب
الصافي المدفوع يجب أن يساوي بالضبط المبلغ بكامل الأداء ناقص الخصم:
MontantNetServi = MontantTTC − MontantRS
وفارق مليم واحد يكفي لإسقاط الفحص، والتقريب يُنتجه بسهولة. والعلاقة بين المبلغ دون أداء والأداء والمبلغ بكامل الأداء تستحقّ الفحص نفسه، وإن كانت أكثر تسامحًا.
التحقّق قبل الإيداع
الصعوبة ليست في فهم هذه القواعد، بل في فحصها على ملف يضمّ مئات الشهادات، حين ترفض المنظومة الكلّ دون أن تذكر السبب.
نشرنا أداة فحص XML للخصم من المورد تفعل ذلك بالضبط: تقرأ الملف داخل متصفّحك، وتطبّق القواعد أعلاه، وتحدّد الشهادة والحقل. ولا يُرسل شيء — فملفٌ يذكر كل مستفيد وكل مبلغ دُفع ليس بيانات تُسلَّم لطرف ثالث لفحص صياغة.
أمّا توليد الملف من قيودك، ففي الدليل التقني تفصيل بناء XML والفحوص التي تُوضع قبله.
الخلاصة
الالتزام شهري وبلا استثناء منذ جانفي 2026. والصيغة موثّقة ومستقرّة؛ وما ينكسر ليس فهم القاعدة في الغالب، بل الطريق بين محاسبتك والملف — تصدير، وجدول بيانات، وتدخّل يدوي.
ومسارٌ يفرض هذا التدخّل كل شهر سينتهي إلى الفشل في شهرٍ لا يجد فيه أحد وقتًا. والفحص موضعه قبل الإيداع، لا بعد الرفض.
المصادر: كرّاس الشروط CCT-RS-V2 والمخطّطات XSD المنشورة على jibaya.tn.