أتمتة إعداد تقارير ضريبة القيمة المضافة لكل دولة والتحقق من نظام (VIES)

دليل عملي للمطورين لدمج الامتثال لضريبة القيمة المضافة في الاتحاد الأوروبي داخل الأسواق والمنصات الرقمية باستخدام واجهة برمجة تطبيقات المحاسبة السحابية.

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

يستعرض هذا الدليل كيفية أتمتة إعداد تقارير ضريبة القيمة المضافة لكل دولة والتحقق عبر نظام (VIES) باستخدام واجهة برمجة تطبيقات المحاسبة السحابية، مع اتخاذ واجهة برمجة التطبيقات الخاصة بـ Nordlet سياقاً للتنفيذ. الهدف هو بناء نظام يلتقط الأدلة الصحيحة لحظة إتمام البيع، ويسجل قيود دفتر الأستاذ غير القابلة للتعديل، وينتج بيانات جاهزة للإقرارات مبوبة حسب الآلية والدولة العضو، وذلك دون الحاجة لإعادة احتساب الإجماليات في جدول بيانات لاحقاً.

ما يخبرك به نظام (VIES) حقاً وما لا يخبرك به

نظام (VIES) هو نظام تبادل معلومات ضريبة القيمة المضافة التابع للاتحاد الأوروبي. فعند إرسال رمز الدولة ورقم ضريبة القيمة المضافة، فإنه يستعلم عن قاعدة البيانات الوطنية ذات الصلة في الوقت الفعلي ليحدد ما إذا كانت بيانات ضريبة القيمة المضافة سارية أم لا. هذا هو نطاق النظام كاملاً؛ فهو يؤكد فقط أن الرقم مسجل، وحيثما تدعم الدولة العضو ذلك، فهو مفعل للتجارة داخل الاتحاد الأوروبي.

إنه لا يمنح الحق في إفاء التوريدات داخل الاتحاد الأوروبي، وتُعد المفوضية الأوروبية صريحة جداً في هذا الشأن. فالاستجابة السارية من نظام (VIES) هي دليل واحد ضمن عدة أدلة أخرى، إذ لا يزال يتعين عليك التأكد من أن العميل هو المستلم الفعلي، وأن التوريد مؤهل لكي يكون داخل الاتحاد الأوروبي، وأن أدلة النقل أو الشحن موجودة، وأن الفاتورة تتضمن عبارات الإعفاء من الضريبة أو عكس الشحنة المطلوبة.

لذا، فإن قرار التصميم الأول هو قرار هيكلي: احتفظ بحالة نظام (VIES) ومعاملة ضريبة القيمة المضافة في حقلين منفصلين. لا تربط أبداً قيمة viesStatus: valid مباشرة بالقيمة zeroRated: true. ففي اللحظة التي تدمج فيها هذين المفهومين، تفقد القدرة على الدفاع عن المعاملة المحاسبية عند الطعن في الأدلة.

المتطلبات الأساسية قبل كتابة كود التكامل

قبل استدعاء أي نقطة نهاية (endpoint)، حدد نطاق ما تقوم بالإبلاغ عنه. هذا الجزء يبدو روتينياً، لكن تخطيه يعد مكلفاً للغاية:

الدول التي تأسست فيها الشركة أو التي توجد فيها منشآت ثابتة لها
الدول التي تحتفظ فيها بتسجيلات ضريبة القيمة المضافة
ما إذا كانت الشركة تبيع سلعاً أو خدمات أو خدمات رقمية أو مزيجاً من ذلك
ما إذا كانت المعاملات بين الشركات (B2B) أو موجهة للمستهلك النهائي (B2C) أو كليهما
ما إذا كنت تستخدم التسجيلات المحلية، أو آلية الشباك الواحد (OSS)، أو نظام استيراد الشباك الواحد (IOSS)، أو الشحن العكسي، أو قواعد المورد المفترض للأسواق الرقمية
المخرجات التي يجب أن تنتجها واجهة برمجة التطبيقات: بيانات الإقرار المحلي، أو بيانات (OSS/IOSS)، أو سجلات الفواتير مثل نظام (i.SAF) في ليتوانيا، أو قيود دفتر الأستاذ فقط، أو حزم بيانات (payloads) لمزود إقرار منفصل

تكتسب هذه النقطة أهميتها من كون نظام الشباك الواحد (OSS) لا يغطي كل معاملة؛ فالخدمات الموردة في بلد تملك فيه الشركة منشأة تابعة تنتمي عموماً إلى الإقرار المحلي لهذا البلد وليس إلى إقرار الشباك الواحد. قم بنمذجة المنشآت بشكل منفصل منذ البداية، وإلا ستتم توجيه تلك التوريدات بشكل خاطئ عند مرحلة التجميع.

لا تقم أيضاً بترميز نسبة ضريبة قيمة مضافة واحدة لكل دولة بشكل ثابت (hard-code). فالـاتحاد الأوروبي يطبق معدلات قياسية، ومخفضة، وشبه منعدمة، ومخفضة جداً، وصفرية، ومعاملات خاصة بالمنتجات، وهي متغيرة باستمرار. المصدر الموثوق للمنتج المحدد في دولة عضو محددة هو السلطة الضريبية في تلك الدولة، مع توفير المفوضية قاعدة بيانات (TEDB) لنظرة عامة عبر الدول. احفظ المصدر والإصدار وراء كل قرار خاص بنسبة الضريبة حتى لا يؤدي التحديث اللاحق لجدول النسب إلى إعادة كتابة طريقة ظهور المعاملات القديمة سراً.

نمذجة القرار الضريبي وليس فقط نسبة الضريبة

جوهر التكامل المستدام يكمن في طبقة الفئات الضريبية الواقعة بين المنتجات ونسب الضريبة. قم بربط المنتجات بالفئات، والفئات بالرموز الضريبية الخاصة بكل دولة، ثم بنسب الضريبة المقترنة بتواريخ سريان محددة:

product/service
    → tax category
    → country-specific tax code
    → effective-dated rate and treatment

النسخة غير الآمنة التي تسبب انحراف التقارير هي product SKU → 21% VAT. فالمنتج نفسه يحمل نسباً مختلفة في دول مختلف، كما أن النسبة قد تتغير في منتصف الفترة الضريبية. توصي إرشادات الامتثال الضريبي الخاصة بـ Nordlet EU VAT compliance guidance تماماً بهذا الربط المستند إلى الفئات بدلاً من ربط المنتجات بالضرائب النسبية مباشرة.

يجب أن يكون تصنيف الفئات الضريبية لديك مستقراً وداخلياً: سلع ذات معدل قياسي، سلع ذات معدل مخفض، خدمات مقدمة إلكترونياً، خدمات عادية، توريدات معفاة، توريدات بمعدل صفر، تحويل عكسي للمعاملات التجارية بين الشركات داخل الاتحاد الأوروبي (intra-EU B2B reverse charge)، مبيعات المسافات داخل الاتحاد الأوروبي، استيراد عبر نظام (IOSS)، معاملة المورد المفترض. وكل العمليات اللاحقة تعتمد على هذا التصنيف.

التحقق عبر (VIES) كعملية أدلة غير متزامنة (Asynchronous)

تكشف خدمة (VIES) الرسمية عن واجهة (SOAP/WSDL) تأخذ رمز دولة مكوناً من حرفين ورقم ضريبة القيمة المضافة. أخطاؤها الموثقة مهمة لمعالجة الأخطاء لديك: المدخلات غير الصالحة، حدود التزامن العالمية وللدول الأعضاء، عدم توفر الخدمة، عدم توفر خدمة الدولة العضو، وانتهاء مهلة الاتصال. تعامل مع هذه الحالات بنتائج متميزة ومستقلة وليست ككتلة واحدة «فاشلة».

يبدو سير العمل الذي يتحمل ضغط الأحمال والمراجعة بالشكل التالي:

تطبيع رقم ضريبة القيمة المضافة (normalize): تحويل بادئة الدولة إلى أحرف كبيرة، وإزالة المسافات أو علامات الترقيم المسموحة، والاحتفاظ بالقيمة الأصلية التي أدخلها المستخدم بشكل منفصل.
التحقق محلياً من رمز الدولة وشكل الرقم قبل إجراء أي استدعاء شبكي.
إرسال الرقم المطبع إلى نظام (VIES).
تخزين الرقم المطبع، والطوابع الزمنية للطلب والاستجابة، وحالة الصلاحية (ساري/غير ساري/لم تتم معالجته)، والاستجابة الخام، وأي خطأ في الخدمة، ومعرفات العميل والفاتورة، وقرار التطبيق.
التخزين المؤقت للنتائج الناجحة لفترة محددة وموثقة.
إعادة المحاولة عند حدوث أعطال فنية مؤقتة مع اعتماد فترات تأخير تصاعدية (backoff).
توجيه الحالات غير المحسومة أو المتناقضة للمراجعة اليدوية.
إعادة التحقق عندما تصبح النتيجة المخزنة مؤقتاً قديمة أو قبل تنفيذ معاملة تمثل فيها الأدلة أهمية جوهرية.

تقوم Nordlet بالتحقق من رقم ضريبة القيمة المضافة في الاتحاد الأوروبي عند إضافة العميل وإعادة التحقق منه قبل إصدار الفاتورة عندما تكون النتيجة السابقة قديمة، وهو السلوك الذي تريد تكراره سواء تم التحقق داخل المنصة أو في الكود الخاص بك.

القاعدة الحاسمة: لا تجعل عملية الدفع متزامنة مع نظام (VIES). تعطل الخدمة لا يعني أن الرقم غير صالح. إذا انتهت مهلة الاتصال بـ (VIES) أثناء عملية بيع، احتفظ بالمعاملة للمراجعة أو اعتبرها في حالة مؤقتة. إن إيقاف عملية الدفع بسبب وقت تشغيل خدمة تابعة للمفوضية يمثل مصدراً لطلبات الدعم الفني، وتصنيف العميل الجيد بشكل خاطئ على أنه غير صالح هو أمر أسوأ بكثير.

فصل حالة التحقق عن المعاملة الضريبية

بمجرد حصولك على نتيجة من (VIES)، يكون لدى محرك القرار مزيد من العمل للقيام به. قم بتخزين هذه القيم كحقول منفصلة:

{
  "viesStatus": "valid",
  "vatTreatment": "intra_eu_b2b_reverse_charge",
  "evidenceStatus": "reviewed",
  "placeOfSupply": "DE"
}

قبل تطبيق العكس الضريبي (reverse-charge) أو الإعفاء، يجب على المحرك اختبار ما إذا كان العميل هو المستلم حقاً، وما إذا كانت دولة العميل وبادئة الضريبة متطابقتين، وما إذا كان التوريد مؤهلاً كعملية داخل الاتحاد الأوروبي، وما إذا كانت قواعد مكان التوريد الخاصة تطبق، وما إذا كانت أدلة النقل موجودة، وما إذا كان البائع يعمل كمورد مفترض، وما إذا كانت الفاتورة تحتوي على الصياغة المطلوبة. حالة (VIES) السارية التي لا تجتاز أي من هذه الاختبارات الأخرى لا تُعد ضوءاً أخضر.

إنشاء قرار ضريبي غير قابل للتعديل وقت إصدار الفاتورة

عند إنشاء الفاتورة، احتفظ بالقرار الكامل إلى جانبها وليس فقط النسبة النهائية:

invoice
  ├─ line tax category
  ├─ place of supply
  ├─ VAT scheme
  ├─ country-specific rate
  ├─ rate-table version
  ├─ VIES evidence reference
  ├─ location-evidence references
  ├─ legal-basis reference
  └─ marketplace-role flags

تتطلب قواعد الفوترة في الاتحاد الأوروبي تفاصيل المورد والعميل، ورقم الفاتورة، ووصف السلع، والمبلغ الخاضع للضريبة، ونسبة ضريبة القيمة المضافة، ومبلغ الضريبة، وأية معلومات عن العكس الضريبي أو الإعفاء. تتطلب إشعارات الدائن والتعديلات إشارة لا لبس فيها إلى الفاتورة الأصلية.

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

الترحيل (Posting)، وويب هوك (Webhooks)، ومعاملة القبول الذاتي (Idempotency)

تسجل عملية البيع قيود محاسبية مزدوجة تحافظ على كل من المعاملة التجارية وتوزيع الالتزام الضريبي مقسماً حسب الدولة والنظام. قد يسجل البيع المحلي القيود التالية:

Dr Accounts receivable / payment clearing
    Cr Revenue
    Cr VAT payable - DE - domestic

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

قم بقيادة تغيرات الحالة باستخدام خطافات الويب (webhooks) بدلاً من الاستعلام المتكرر (polling). تصدر Nordlet أحداثاً مثل sale_invoice.paid، وتوقع عمليات التسليم، وتجري إعادة محاولات مع فترات زمنية متصاعدة. امنح كل عملية كتابة مفتاح قبول ذاتي (idempotency key) محدد وثابت:

sale:{platform_order_id}:invoice:{invoice_version}

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

التجميع لنظام (OSS) وإنتاج الصادرات الجاهزة للإقرارات

بالنسبة لمعاملات (OSS) المؤهلة، قم بتجميع بيانات دفتر الأستاذ حسب النظام، ودولة العضو المستهلكة، نوع التوريد، فئة النسبة، النسبة، المبلغ الخاضع للضريبة، مبلغ ضريبة القيمة المضافة، دولة العضو للشحن أو المنشأة، العملة، وفترة التصحيح.

إقرار نظام الشباك الواحد الاتحادي (Union scheme return) يفصل التوريدات حسب دولة العضو المستهلكة ويميز الخدمات القادمة من دولة العضو للتعريف، والخدمات من المنشآت الثابتة الأخرى، والسلع المشحونة من دول أعضاء مختلفة. وهو يبلغ عن المبالغ الخاضعة للضريبة ومبالغ ضريبة القيمة المضافة بشكل منفصل للنسب القياسية والمخفضة. أما التوريدات المعفاة وتلك الخاضعة لنسبة الصفر فتبقى خارج إقرار الشباك الواحد تماماً.

بعض التفاصيل التشغيلية التي قد توقع بالمطورين:

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

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

كن دقيقاً بشأن ما تقدمه واجهة برمجة التطبيقات هنا. تقوم Nordlet بحساب إقرارات (OSS) و (IOSS) من الفواتير ودفتر الأستاذ متضمنة التصحيحات للفترات السابقة، وتشحن حزم الإقرارات المحلية لكل من ليتوانيا (FR0600)، وألمانيا (UStVA)، وبولندا (JPK_V7M)، وتنتج سجلات (i.SAF) الجاهزة للاستخدام في ليتوانيا. هذه هي البيانات الجاهزة للإقرار. استدعاء واحد لواجهة برمجة التطبيقات لا يقوم بإرسال إقرار ضريبة القيمة المضافة لكل دولة عبر كل بوابة وطنية، ولا يتم تقديم أي إقرار إلى السلطة الضريبية نيابة عنك. احتفظ بالمحاسبة، وإنشاء الإقرارات، والتصدير، والإرسال عبر البوابة، وتأكيد الدفع كحالات منفصلة في نظامك. دليل محرك ضريبة القيمة المضافة في الاتحاد الأوروبي يوثق الحالات التي يحلها المحرك والمكان الذي تطلق فيه تحذيراته.

قفل الفترة (Locking the period)

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

أنماط الفشل الشائعة وكيفية تجنبها

نمط الفشل	سبب حدوثه	إجراءات التخفيف
اعتبار نتيجة (VIES) السارية كافية لتطبيق نسبة الصفر	لا يمنح نظام (VIES) حقوق الإعفاء الضريبي	تخزين أدلة العميل، والتوريد، والنقل، والفاتورة إلى جانب النتيجة
اعتبار النتيجة غير السارية دليلاً على عدم وجود تسجيل	قد لا يكون الرقم مفعلاً للتجارة داخل الاتحاد الأوروبي، أو قد تتأخر قاعدة البيانات	التمييز بين الحالات غير السارية، وغير المعالجة، والفشل الفني؛ وتوجيه النزاعات للمراجعة
جعل عملية الدفع متزامنة مع نظام (VIES)	قيود التزامن، انتهاء المهلة، الأعطال	التحقق غير المتزامن، التخزين المؤقت قصير الأجل، المحاولات المتصاعدة، والحالات المؤقتة
التخزين المؤقت للنتائج إلى الأبد	تتغير حالة التسجيل والتفعيل	تخزين الطوابع الزمنية وتواريخ انتهاء الصلاحية؛ إعادة التحقق قبل الفوترة إذا كانت قديمة
ربط المنتجات بنسب ضريبة القيمة المضافة مباشرة	تعتمد النسب والإعفاءات على الدولة والتاريخ	الانتقال من المنتج إلى الفئة إلى رمز الدولة ثم النسبة المحددة بالتاريخ
إعادة بناء إقرارات (OSS) من جداول البيانات	تغفل الإجماليات التصحيحات، ودول الشحن، والأدلة	الاشتقاق من دفتر الأستاذ غير القابل للتعديل مع الأبعاد الموجودة في كل قيد
تضمين خدمات المنشآت المحلية في إقرار (OSS)	بعض الخدمات تنتمي إلى الإقرار المحلي	نمذجة المنشآت بشكل منفصل، والتوجيه حسب النظام قبل التجميع
إغفال الإقرارات صفرية القيمة	يتطلب نظام (OSS) إقراراً في كل فترة	إنشاء قائمة تحقق وإنشاء إقرارات صفرية القيمة تلقائياً
تعديل الفواتير المغلقة للتصحيح	يدمر الرابط بين الإقرار والتصحيح	استخدام إشعارات الدائن والقيود العكسية في فترة لاحقة

ما نقوم به أولاً

إذا كنا سنبدأ هذا التكامل غداً، فسوف نبني طبقة الفئات الضريبية وسجل القرار الضريبي قبل لمس أي نقطة نهاية للتقارير. اجعل التوصيف مستقراً، واجعل المنتجات مرتبطة بالفئات، واجعل سجل القرار يلتقط إشارات الدول الخام بالإضافة إلى سبب اختيار مكان التوريد. كل شيء آخر - مثل (VIES)، والترحيل، وتجميع (OSS)، والتصدير - يعتمد على صحة هذا النموذج.

بعد ذلك، سنقوم بربط نظام (VIES) كخطوة أدلة غير متزامنة مع فصل الحالات الأربع، وتشغيله مقابل شركة تجريبية في بيئة الاختبار (sandbox company) مزودة بحالات اختبار للحالات الصعبة (انتهاء المهلة، النتائج غير المعالجة، البادئات غير المتطابقة) قبل السماح لها بالاقتراب من بيئة الإنتاج. يمكن تجنب أنماط الفشل المذكورة أعلاه بالكامل تقريباً إذا كان نموذج البيانات يحمل الأدلة وأبعاد التقارير منذ القيد الأول.

الأسئلة الشائعة

هل تعني استجابة (VIES) السارية أنه يمكنني تطبيق نسبة الصفر على عملية بيع B2B داخل الاتحاد الأوروبي؟

لا. يؤكد (VIES) أن رقم ضريبة القيمة المضافة مسجل، وحيثما تدعم الدولة ذلك، فهو مفعل للتجارة داخل الاتحاد الأوروبي. الحق في إعفاء التوريدات داخل الاتحاد الأوروبي يعتمد على أدلة إضافية: كون العميل هو المستلم الفعلي، وإثبات النقل أو الشحن، والمكان الصحيح للتوريد، وصياغة الفاتورة المطلوبة. احفظ نتيجة (VIES) كمدخل واحد، وليس كالقرار النهائي.

هل يجب أن يوقف التحقق عبر (VIES) عملية الدفع؟

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

هل يمكن لواجهة برمجة تطبيقات المحاسبة السحابية تقديم إقرارات ضريبة القيمة المضافة تلقائياً؟

يمكنها إنتاج بيانات جاهزة للإقرارات مبوبة حسب النظام والدولة العضو، ومحسوبة من دفتر الأستاذ غير القابل للتعديل مع تضمين التصحيحات. أما عما إذا كانت تقوم أيضاً بالإرسال عبر كل بوابة إقرار وطنية، فهذا يعتمد على المنتج والدولة. تقوم Nordlet بحساب إقرارات (OSS) و (IOSS)، وتشحن حزم الإقرارات المحلية لليتوانيا وألمانيا وبولندا، وتنتج سجلات (i.SAF) الجاهزة لليتوانيا، ولكنها لا تقدم أي شيء إلى السلطة الضريبية نيابة عنك. تعامل مع المحاسبة، وإنشاء الإقرارات، والتصدير، والإرسال عبر البوابة، والدفع كحالات منفصلة بدلاً من افتراض أن استدعاءً واحدأ يقدم الإقرارات في كل مكان.

كيف أتعامل مع التصحيحات بعد قفل الفترة؟

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