شرح مستند البيانات الضريبية في عمان TDD

مستند البيانات الضريبية، أو TDD، من أسهل أجزاء الفوترة عرضة لسوء الفهم. هو ليس الفاتورة نفسها التي ترسل إلى المشتري. هو مستند تقرير ضريبي منفصل يرسل بيانات الفاتورة إلى السلطة الضريبية.

بالنسبة للمطورين، هذا الفرق مهم. إذا تعامل النظام مع TDD كأنه نسخة أخرى من XML الفاتورة الموجهة للمشتري، فسيصعب التحقق والتصحيح والأرشفة وشرح أسباب الفشل.

الجواب المختصر

TDD في عمان مستند تقرير تنظيمي. يقع بجانب مسار الفاتورة، لكنه يجب أن ينفذ كوحدة مستقلة لها نموذج دلالي وربط صيغة وقوائم رموز وقواعد أعمال وأدوات تحقق خاصة بها.

ابنه كمخرج حتمي من بيانات فاتورة محفوظة. واحفظ الروابط بين الفاتورة المصدر، وXML الفاتورة وفق PINT-OM، ومثيل TDD، ونتيجة التحقق، وسجل الأرشيف.

XML الفاتورة وTDD لهما وظيفتان مختلفتان

تمثل فاتورة PINT-OM الفاتورة التجارية أو اشعار الدائن ضمن عملية الفوترة الالكترونية. أما TDD فيبلغ بيانات ضريبية مستخرجة من مستندات المصدر لأغراض التقرير الضريبي والامتثال.

لذلك يكون لكل مستند عمل هندسي مختلف:

المستند	الوظيفة الأساسية	الخطر إذا أسيء فهمه
PINT-OM invoice XML	تمثيل الفاتورة أو اشعار الدائن الصادر ضمن عملية الفوترة.	قد لا يتم التحقق من الفاتورة أو تبادلها بشكل صحيح.
TDD	ابلاغ بيانات ضريبية إلى السلطة الضريبية.	قد يفشل التقرير الضريبي حتى إذا بدا مسار الفاتورة سليما.
الفاتورة المقروءة	عرض فاتورة مفهومة للعميل.	قد يتم الخلط بين PDF أو الورق وبين سجل الامتثال.

لا يجب أن يكون TDD اضافة لاحقة على مولد PDF. يجب أن يكون منتج بيانات مقصودا من نظام الفواتير.

ماذا تحتوي حزمة TDD؟

تتضمن وثائق OpenPeppol الحالية لـ TDD في عمان صفحة عملية، ومواصفة تشغيل بينية، ونموذجا دلاليا، وربط صيغة، وقوائم رموز، وقواعد أعمال، وأدوات Schematron.

للتخطيط، قسم الحزمة هكذا:

الطبقة	ما الذي يجب فحصه؟
العملية	متى ينشأ TDD أو يرسل أو يحدث أو يسحب أو تفحص حالته.
النموذج الدلالي	المصطلحات التجارية وبنية مستند التقرير الضريبي.
ربط الصيغة	كيف يعبر XML عن النموذج الدلالي.
قوائم الرموز	القيم المسموحة التي يجب أن تطابق الأدوات المنشورة.
قواعد الأعمال	شروط الحقول والتقرير الضريبي.
Schematron	قواعد التحقق المقروءة آليا.
ملاحظات الاصدار	الحالة، وتاريخ النشر، والتغييرات المهمة.

استخدم ملاحظات الاصدار كجزء من ضبط التغيير. لا ينبغي أن يعمل موائم كتب لاصدار واحد ضد اصدار آخر دون دليل اختبار.

نموذج بيانات TDD: ماذا تحفظ؟

احفظ بيانات مصدر كافية لاعادة توليد TDD وشرحه وتدقيقه لاحقا.

كحد أدنى، احفظ:

• معرف الفاتورة المصدر؛
• تاريخ اصدار الفاتورة المصدر؛
• نوع المستند؛
• معرفات البائع والمشتري؛
• معرفات التسجيل الضريبي؛
• اجماليات الفاتورة واجماليات الضريبة؛
• فئات الضريبة على مستوى السطر أو الملخص حسب النموذج النهائي؛
• مراجع مستندات المصدر؛
• اصدار أداة التحقق؛
• وقت انشاء TDD؛
• وقت الارسال أو الحالة إذا انطبق؛
• تاريخ التصحيح أو التحديث أو السحب عند الحاجة.

لا تحفظ سلسلة XML الناتجة وحدها. احفظ بيانات المصدر، والمستند الناتج، ونتيجة التحقق، والعلاقة بينها.

حد الوحدة البرمجية المقترح

افصل تنفيذ TDD عن عرض الفاتورة وتسليمها للعميل.

معمارية نظيفة تضم:

الوحدة	المسؤولية
نموذج الفاتورة المصدر	يملك بيانات الفاتورة الأساسية للمحاسبة وXML وTDD والأرشيف.
موائم PINT-OM	يولد XML الفاتورة أو اشعار الدائن الموجه للمشتري.
موائم TDD	يولد مستند التقرير الضريبي من بيانات المصدر.
المدقق	يشغل XSD وقوائم الرموز وقواعد الأعمال وSchematron.
محول الارسال والحالة	يتعامل مع اتصالات المزود أو الجهة الرسمية عند الحاجة.
الأرشيف	يحفظ بيانات المصدر والمخرجات ونتائج التحقق والطوابع وروابط التصحيح.

هذا الفصل يتيح اصلاح مشكلة TDD دون اعادة كتابة PDF الفاتورة، واصلاح مشكلة مواءمة الفاتورة دون اخفاء فشل في التقرير الضريبي.

التعامل مع الأخطاء

لا تعرض أخطاء Schematron الخام وحدها لموظفي المالية. احتفظ بالخطأ الخام، لكن أضف شرحا مفهوما واربطه بالشخص الذي يملك بيانات المصدر.

يجب أن يحدد تدفق الخطأ:

• المستند المتأثر؛
• هل الفشل في جانب الفاتورة أو TDD أو بيانات المصدر؛
• حقل المصدر الذي يحتاج إلى تصحيح؛
• القاعدة أو طبقة التحقق التي فشلت؛
• هل يمكن اعادة توليد المستند بعد التصحيح؛
• هل يحتاج مستند مرسل سابقا إلى تحديث أو سحب.

اختبر تدفق الأخطاء بحالات غير صالحة قبل بدء التطبيق.

حالات اختبار لتنفيذ TDD

أنشئ fixtures قبل اختبار المزود.

مجموعة مقترحة:

• فاتورة B2B بسيطة؛
• فاتورة B2C بسيطة؛
• اشعار دائن مرتبط بفاتورة أصلية؛
• اشعار مدين أو حالة تصحيح؛
• حالة تصدير؛
• حالة استيراد أو فوترة ذاتية عند الحاجة؛
• فاتورة بأكثر من نسبة ضريبة؛
• فاتورة فيها خصم أو رسم؛
• نص عربي لمشتر أو صنف؛
• TDD غير صالح عمدا لكل طبقة تحقق؛
• سيناريو تحديث أو سحب إذا أكدته العملية النهائية.

يجب أن تتضمن كل حالة بيانات المصدر، ومخرج TDD المتوقع، ونتيجة التحقق المتوقعة، وسبب الاختبار.

الأرشفة والتتبع

تؤكد الأسئلة الشائعة لجهاز الضرائب أن الأرشفة تبقى مسؤولية الخاضع للضريبة. لذلك، يجب أن يدعم تنفيذ TDD التتبع، وليس الارسال فقط.

لكل TDD، يجب أن تستطيع الاجابة:

• أي فاتورة مصدر أنتجته؛
• أي اصدار موائم ولده؛
• أي اصدار أداة رسمية تحقق منه؛
• متى نجح التحقق أو فشل؛
• هل أرسل أو حدث أو سحب أو رفض؛
• من صحح بيانات المصدر؛
• أين تحفظ XML الفاتورة والنسخة المقروءة المرتبطة.

هذا هو الفرق بين عرض تجريبي يعمل وعملية انتاج قابلة للتدقيق.

ما الذي لا يجوز الجزم به بعد

لا تنشر أو تعتمد على النقاط التالية دون دليل أولي حالي:

• أسماء حقول TDD النهائية الدقيقة؛
• أعداد قواعد أعمال TDD النهائية؛
• سلوك الارسال أو التحديث أو السحب النهائي الذي يتجاوز نص عملية OpenPeppol الحالي؛
• تفاصيل QR/TLV الدقيقة؛
• مبالغ الجزاءات النهائية؛
• ادعاءات أن بائعا أو موصلا يدعم TDD العماني بالكامل.

الادعاء الآمن هو أن TDD مستند تقرير ضريبي منفصل ويجب تنفيذه والتحقق منه واصداره وأرشفته بشكل منفصل عن XML الفاتورة الموجهة للمشتري.

الخطوة التالية

خذ فاتورة حقيقية واحدة وابن جدول تتبع. ضع فيه سجل الفاتورة المصدر، وXML الفاتورة وفق PINT-OM، وTDD الناتج، ونتائج التحقق، واصدارات الأدوات، وموقع الأرشيف. إذا كان ملء هذا الجدول صعبا، فالتنفيذ يحتاج إلى نموذج بيانات أوضح قبل بدء التطبيق.