إذا كانت منظومتكم المالية تعمل على Oracle Fusion أو NetSuite، فإن تفويض الفوترة الإلكترونية في دولة الإمارات العربية المتحدة يضعكم أمام مشكلة محددة. فأيٌّ من هذين النظامين لا ينتج، بإعداداته الافتراضية، فاتورة XML متوافقة مع Peppol PINT-AE وجاهزة للإرسال عبر نقطة الوصول. ولديكم ثلاثة عناصر متحركة ينبغي معالجتها: ربط الحقول بين بيانات نظام تخطيط موارد المؤسسة (ERP) وقاموس البيانات الإماراتي، والبرمجيات الوسيطة التي تتولى التحويل والتحقق، وإعداد نقطة الوصول وفق نموذج Peppol خماسي الزوايا الذي تحكمه الهيئة الاتحادية للضرائب (FTA) في الإمارات. يستعرض هذا الدليل الصورة الفعلية لعملية التكامل على أرض الواقع لفرق المالية وتقنية المعلومات في الإمارات، والمواضع التي يحدث فيها الخلل عادةً، وكيفية ترتيب العمل زمنياً قبل اقتراب المواعيد النهائية للهيئة الاتحادية للضرائب.
يتمتع كلا النظامين بامتدادات عالمية للفوترة الإلكترونية؛ إذ يعتمد Oracle Fusion على إطار Collaboration Messaging Framework، بينما يعتمد NetSuite على SuiteTax وتطبيقات SuiteApps المقدَّمة من أطراف ثالثة. غير أن أياً منهما لا يأتي بتهيئة PINT-AE (ملف فاتورة Peppol الدولية، الملف الإماراتي) جاهزة ومعدَّة مسبقاً لدولة الإمارات. فقاموس البيانات الإماراتي يستلزم هياكل حقول، وقوائم رموز، وقواعد تحقق تختلف عن ZATCA في المملكة العربية السعودية، أو MyInvois في ماليزيا، أو Peppol BIS billing الأوروبي.
كثيراً ما تفترض فرق المالية أن مورّد نظام الـ ERP سيتولى الأمر. وفي الواقع العملي، يظل عليكم تحديد الحقول المحلية التي تحمل رموز الإمارات، وتصنيف ضريبة القيمة المضافة (VAT) المواءم للقواعد الإماراتية، ومعرّفات المناطق الحرة، ومؤشرات الاحتساب العكسي للضريبة. وهنا يُثبت الاستشاري المتخصص في الامتثال قيمته الفعلية، إذ يترجم الالتزامات التنظيمية إلى تهيئة في نظام الـ ERP قبل كتابة سطر واحد من كود البرمجيات الوسيطة. وفي المشاريع الفعلية داخل الإمارات، تظهر الفجوة بين ما تنتجه وحدة الـ ERP وما تتوقعه الهيئة الاتحادية للضرائب عادةً خلال اختبار التوافق الأول، لا خلال مرحلة التصميم. والتقاط هذه الفجوة في وقت أبكر مسألة تتطلب مراجعة نموذج البيانات حقلاً بحقل مقابل متطلبات PINT-AE، بحضور شخص قادر على قراءة كلا الجانبين بطلاقة.
يُعدّ ربط الحقول المرحلة الأقل بريقاً، وهي المرحلة التي تخسر فيها معظم المشاريع أسابيع من الوقت. ففي Oracle Fusion، تتوزع بيانات رأس الفاتورة وبنودها عبر وحدات الذمم المدينة (Receivables) والذمم الدائنة (Payables) ووحدة الضرائب. أما NetSuite فيوزّع بيانات مشابهة عبر سجلات Transactions وSubsidiary وSuiteTax.
تشمل قرارات الربط الرئيسية ما يلي:
ومن نقاط الفشل الشائعة توريث دليل حسابات وإعداد ضريبي بُنيا للامتثال لضريبة القيمة المضافة قبل عام 2018. وعادةً ما يحتاج ذلك إلى مراجعة مستهدفة قبل بدء ربط الحقول، لا بعده.
البرمجيات الوسيطة هي الموضع الذي يجري فيه التحويل، والتحقق، والتوقيع الرقمي، وتسجيل بيانات التدقيق. وفي حالة Oracle Fusion وNetSuite، تهيمن ثلاثة أنماط معمارية على عمليات النشر في الإمارات.
وأيّاً كان النمط الملائم، يجب على طبقة البرمجيات الوسيطة أن تتولى الحيلولة دون تكرار الإرسال (idempotency)، ومنطق إعادة المحاولة عند إخفاق نقطة الوصول، والمطابقة بين معرّفات الفواتير في نظام الـ ERP وإشعارات الاستلام من الهيئة الاتحادية للضرائب، إضافة إلى أرشيف قابل للبحث يستوفي قواعد حفظ السجلات في الإمارات. والفرق التي تتجاوز هذه المتطلبات التشغيلية عادةً ما تُعيد بناء هذه الطبقة في غضون عام.
يوجّه نموذج Peppol الخماسي الإماراتي الفواتير على النحو التالي: يسلّم نظام الـ ERP لدى المرسِل (C1) البيانات إلى نقطة الوصول الخاصة به (C2)، التي تُرسلها إلى الهيئة الاتحادية للضرائب (C5)، ثم تُسلَّم إلى نقطة الوصول لدى المستلِم (C3)، التي تُمرّرها بدورها إلى نظام الـ ERP لدى المستلِم (C4). ومنشأتكم تتصل بـ C2 للمعاملات الصادرة وبـ C3 للمعاملات الواردة.
ويشمل إعداد نقطة الوصول اختيار مزود خدمة معتمد (ASP) في الإمارات، وتهيئة معرّف المشارك في Peppol (الذي يعتمد غالباً على رقم التسجيل الضريبي TRN)، وإنجاز اختبار التوافق مقابل البيئات التجريبية للهيئة الاتحادية للضرائب قبل الانطلاق الفعلي. أما المجموعات التي تمتلك كيانات في المملكة العربية السعودية أو البحرين أو غيرهما من دول مجلس التعاون الخليجي، فعليها أن تتوقع تشغيل تهيئات متوازية لنقاط الوصول، تتواءم كل منها مع ملف Peppol الخاص بتلك الولاية القضائية.
وتبرز هنا أهمية الدعم الاستشاري، لأن اختيار مزود الخدمة المعتمد ليس مقارنة متكافئة. فاتفاقيات مستوى الخدمة (SLA) الخاصة بوقت التشغيل، ودعم إصدارات PINT-AE، والتعامل مع المعاملات الواردة لكلا تدفقَي الفواتير، وتوفّر بيئة اختبارية (sandbox)، ونماذج التسعير، كلها تتفاوت فيما بينها. وهذا هو الموضع الذي يُغيّر فيه الشريك الاستشاري المحايد تجاه المورّدين المعادلةَ فعلياً، لأن توصيته مرتبطة بملف فواتيركم، لا بعمولة بائع. واتخاذ القرار الخاطئ يُنتج أعمالاً مُعادة، لا تكلفة مالية فحسب.
ترتيب زمني عملي لغالبية عمليات النشر في السوق الإماراتية المتوسطة والمؤسسية:
وضغط هذا الجدول الزمني ممكن، لكنه يفرض عادةً مقايضات. والفرق التي تُنهي عملها بسلاسة هي تلك التي تبدأ العمل على جاهزية بيانات نظام الـ ERP بينما لا يزال قرار اختيار مزود الخدمة المعتمد قيد الدرس. وتستعرض أدلتنا المتعلقة بالامتثال في مجال الفوترة الإلكترونية عدداً من أنماط الترتيب الزمني هذه بمزيد من التفصيل.
يمكن تهيئة Oracle Fusion وNetSuite للامتثال الكامل للفوترة الإلكترونية في تدفقات B2B وB2G داخل دولة الإمارات، غير أن معظم العمل يقع خارج نظام الـ ERP ذاته، في انضباط ربط الحقول، ومعمارية البرمجيات الوسيطة، واختيار نقطة الوصول. والتعامل مع هذه العناصر الثلاثة بوصفها مسائل هندسية متتابعة، لا قراراً شرائياً واحداً، هو ما يفصل عمليات النشر المنجزة في موعدها عن تلك المتعثرة.
ولتلخيص الركائز الثلاث: ربط الحقول يُواءم بيانات نظام الـ ERP لديكم مع قاموس البيانات الإماراتي. والبرمجيات الوسيطة تتولى التحويل والتوقيع والمطابقة. وإعداد نقطة الوصول يربطكم بشبكة Peppol خماسية الزوايا تحت إشراف الهيئة الاتحادية للضرائب. وبالنسبة لقادة المالية وتقنية المعلومات في الإمارات، فإن الموقع الأقوى هو خارطة طريق محايدة تجاه المورّدين تحترم أنظمتكم القائمة، والتزاماتكم بالامتثال، وطاقتكم التشغيلية.
وإن أردتم رؤية مُفصَّلة لما يبدو عليه التكامل في بيئة Oracle Fusion أو NetSuite لديكم، فاحجزوا تقييم امتثال مُحدَّد النطاق مع فريقنا المتخصص في الفوترة الإلكترونية في الإمارات.
هل يدعم Oracle Fusion ملف PINT-AE الإماراتي بإعداداته الافتراضية؟
يوفّر Oracle Fusion إطار Collaboration Messaging Framework وقدرات عالمية للفوترة الإلكترونية، غير أنه لا يُقدّم ملف PINT-AE مُهيّأً مسبقاً لتفويض دولة الإمارات. ويلزم بناء أو توسيع ربط الحقول المحلية، ومواءمة فئات الضريبة، والاتصال بنقطة الوصول. وتجمع معظم عمليات النشر في الإمارات بين Fusion ومزود خدمة معتمد (ASP) أو طبقة برمجيات وسيطة لاستيفاء قواعد التحقق لدى الهيئة الاتحادية للضرائب ومتطلبات Peppol خماسي الزوايا.
هل NetSuite جاهز للفوترة الإلكترونية الإماراتية دون برمجيات وسيطة؟
يتعامل NetSuite بكفاءة مع محاسبة ضريبة القيمة المضافة في الإمارات، غير أن توليد ملفات XML متوافقة مع PINT-AE، والتوقيع الرقمي، والإرسال عبر نقطة وصول Peppol، كلها خارج نطاقه الأصلي. وتستخدم معظم عمليات التطبيق في الإمارات تكاملات SuiteScript أو موصّلاً معتمداً لمزود خدمة لسدّ هذه الفجوة. وتكاد البرمجيات الوسيطة، سواء كانت مُستضافة لدى مزود خدمة معتمد أم قائمة على iPaaS أم مخصصة، أن تكون جزءاً دائماً من المعمارية لتدفقات الفواتير B2B وB2G المتوافقة مع الهيئة الاتحادية للضرائب في الإمارات.
هل يمكننا استخدام نقطة الوصول ذاتها لفواتير B2B وB2G في الإمارات؟
يمكن لنقطة وصول واحدة معتمدة في الإمارات أن تتعامل مع تدفقات الفواتير B2B وB2G وفق نموذج Peppol خماسي الزوايا، شريطة أن تدعم أنواع مستندات PINT-AE ذات الصلة ومعرّفات المشارك للمشترين. وقد يتطلب المشترون من الجهات الحكومية بيانات توجيه إضافية أو معالجة خاصة لإشعارات الاستلام، لذا ينبغي التحقق من سيناريوهات B2G أثناء اختبار التوافق بدلاً من افتراض أن تهيئة المعاملات الصادرة للمشترين من القطاع الخاص تغطي كل ما ستحتاجونه.
كم يستغرق عادةً تكامل الفوترة الإلكترونية الإماراتية مع Oracle أو NetSuite؟
يستغرق النشر الكامل عادةً من 4 إلى 6 أشهر، تبعاً لعدد الكيانات، وحجم الفواتير، وجودة بيانات نظام الـ ERP القائمة. ويستغرق تقييم الجاهزية من 2 إلى 4 أسابيع، وتنقية بيانات نظام الـ ERP من 4 إلى 8 أسابيع، وبناء البرمجيات الوسيطة واختبار التوافق من 10 إلى 18 أسبوعاً إضافياً. وينبغي للمجموعات متعددة الكيانات التي تملك تخصيصات قديمة أن تخطط للنطاق الأعلى من هذا المدى لتفادي عمليات الانطلاق المتسرعة قُرب المواعيد النهائية للهيئة الاتحادية للضرائب.
ماذا يحدث إذا أرسل نظام الـ ERP لدينا فاتورة ترفضها الهيئة الاتحادية للضرائب؟
الفواتير المرفوضة لا تجتاز التدفق الخماسي الزوايا، ولا يمكن اعتبارها فواتير ضريبية متوافقة في دولة الإمارات. ويجب على البرمجيات الوسيطة لديكم أن تلتقط رمز الخطأ الصادر عن الهيئة الاتحادية للضرائب، وتُوقف معالجة المعاملة في العمليات اللاحقة، وتوجّهها للتصحيح قبل إعادة الإرسال. فتكرار حالات الرفض قد يُحدث تضارباً في تقارير ضريبة القيمة المضافة ويُنشئ تعرضاً تدقيقياً، ولذلك يستحق منطق معالجة الأخطاء والمطابقة قدراً من الاهتمام التصميمي يُوازي ما يحظى به تدفق الإرسال في المسار الناجح.
