الفوترة الإلكترونية
الفوترة الإلكترونية ليست إرسال ملف PDF إلى جهاز الضرائب. هي أن يُخرج نظامك فاتورة مهيكلة بحقول محدّدة، تنتقل عبر مزوّد خدمة معتمد. والجزء الذي يقع داخل نظامك أنت هو الجزء الذي لا يتولّاه عنك أحد، وهو عملنا. Dynacloud ليست مزوّد خدمة معتمداً ولا ترسل فواتيرك، ولهذا نحن محايدون تجاه المزوّد الذي تختاره.
منظومة الفوترة الإلكترونية في عُمان (فوترة) تنقل الفاتورة من ورقة أو ملف إلى بيانات. وقد اعتُمد لعُمان إطار Peppol مع مواصفة فنية خاصة بها، ويقوم التبادل على نموذج خماسي الأطراف. والنتيجة العملية أن نظامك لن يتصل بالجهاز مباشرة، بل عليه أن يُنتج مستنداً صالحاً يقبله مزوّد الخدمة المعتمد.
الفاتورة تصبح ملف XML بحقول إلزامية، لا صورة ولا ملف PDF ولا ورقة ممسوحة.
المواصفة الفنية العُمانية تُعرف باسم PINT OM ضمن إطار Peppol، وترد أيضاً بصيغة OM PINT في بعض المصادر، ويرافق الفاتورة مستند بيانات الضريبة (Tax Data Document).
أطراف التبادل خمسة: أنت، ومزوّد الخدمة المعتمد لديك، ومزوّد المشتري، والمشتري، وجهاز الضرائب.
المنشأة لا ترسل فواتيرها إلى الجهاز بنفسها. كل فاتورة تمرّ عبر مزوّد خدمة معتمد.
Dynacloud ليست مزوّد خدمة معتمداً، ولا نقطة تبادل، ولا ننقل فواتيرك، ولا نتحدّث باسم جهاز الضرائب. نعمل داخل نظامك: نقرأ نموذج بياناته، ونحدّد ما ينقصه، ونجعله يُخرج ما تطلبه الفاتورة المهيكلة، ثم نوصّله بمزوّد الخدمة المعتمد الذي تتعاقد أنت معه. وهذا الحياد مقصود: من يبيع القناة له مصلحة في الجواب، ونحن لا نبيع قناة. والصراحة تقتضي جملة ثانية: ربط الفوترة الإلكترونية عرض جديد لدينا، لا سجلاً نستعرضه. والخبرة التي نأتي بها ليست في المنظومة نفسها بل فيما تقوم عليه، وهو أنظمة ERP وترحيل البيانات وتكامل الأنظمة، وما ليس جديداً هو العمل الذي يقوم عليه هذا الربط: أنظمة تخطيط الموارد، وترحيل البيانات، وتكامل الأنظمة، وهذا ما نعمله منذ سنوات.
القرار ليس بين الالتزام وعدمه، بل بين موضعين يقع فيهما العمل.
أبقِ نظامك ونحن نربطه: مناسب إن كان النظام يخدمك، وبُنيت حوله تكاملات، وكانت المشكلة في الحقول والتصنيف والترقيم لا في النظام نفسه.
أو انتقل إلى نزرو: مناسب لمحل أو عيادة أو ورشة تعمل اليوم على الورق أو على جداول بيانات أو على نظام لا يفرّق بين المعاملات الضريبية. وتحمل فواتير نزرو ضريبة لكل بند وترقيماً متسلسلاً وسجلاً لا يُعدَّل.
وكلا الطريقين ينتهي عند مزوّد خدمة معتمد. والفارق أين يقع العمل: داخل نظامك، أو داخل نظام يحمل البنية أصلاً.
تسع مراحل، مرتّبة كما تقع فعلاً، لا كما تبدو في عرض تقديمي.
1. الاستكشاف على بياناتك أنت، لا على نموذج عام. أين تسكن الضريبة فعلاً؟ في Dynamics 365 Finance and Operations تسكن على حركة الضريبة لا على سطر البيع، وفي النظام المخصّص تكون غالباً نسبة واحدة على رأس الفاتورة، وفي SAP تكون في سجلات الشروط. وكل ما يأتي بعد ذلك يعتمد على هذا الجواب.
2. خريطة الحقول: وثيقة تعتمدها أنت بالتوقيع، تربط كل حقل مطلوب بمصدره في نظامك، أو تعلن صراحة أنه غير موجود.
3. تنظيف ملف العملاء والفئات: الأرقام الضريبية لعملائك من المنشآت، والاسم القانوني بدل اسم جهة الاتصال، والعنوان الصالح للاستخدام.
4. التصنيف الضريبي لكل بند، وهو قرار محاسبك لا قرار مبرمج: أي الفئات خاضعة بالنسبة الأساسية، وأيها بنسبة صفر، وأيها معفاة، وما سبب الإعفاء المكتوب.
5. الترقيم وعدم قابلية التعديل داخل نظامك، وهذا غالباً هو التغيير الذي يحرّك تاريخ التشغيل، لأنه يقع في شيفرة النظام نفسه لا في طبقة الربط.
6. الاختبار على البيئة التجريبية لدى المزوّد، بعيّنات تغطي ما يحدث في نشاطك فعلاً: بند خاضع، وبند بنسبة صفر، وبند معفى، وفاتورة مختلطة، وإشعار دائن يشير إلى أصله، وفاتورة دفعة مقدّمة، وعملة أجنبية.
7. مسار الرفض، وهو أكثر ما يُستهان به: ماذا يرى الموظف على الشاشة حين يُرفض المستند، ومن يصحّحه، وهل تكتمل عملية البيع بينما المستند في الطريق؟
8. الحفظ والاسترجاع: أين تُحفظ الفاتورة المهيكلة وردّ المزوّد، ولكم من الوقت، ومن يستطيع إخراجها عند الطلب. وحفظ نسخة PDF ليس حفظاً للمستند المهيكل، والمدقّق يطلب الثاني.
9. التشغيل: أي أنواع المستندات تتحرّك وفي أي تاريخ، وفترة تشغيل متوازٍ، ومطابقة بين ما أصدره نظامك وما نقله المزوّد، وجواب مكتوب عن سؤال: ماذا يحدث عند نقطة البيع إذا تعذّر الوصول إلى المزوّد؟ يُكتب هذا الجواب قبل التشغيل، لا بعد أول انقطاع.
هذه هي القائمة التي نبدأ منها في كل مشروع، وهي التي تُظهر بسرعة أين ينقص نظامك:
عن البائع: الاسم، والرقم الضريبي، ورقم السجل التجاري، والعنوان.
عن المشتري: الاسم القانوني، ومعرّفه الضريبي إن كان مسجّلاً في ضريبة القيمة المضافة، والعنوان، وهل هو منشأة أم فرد.
عن المستند: نوعه، ورقمه المتسلسل، وتاريخ الإصدار، وتاريخ التوريد، والمرجع إلى المستند الأصلي إن كان إشعاراً دائناً، والعملة وسعر الصرف إن لم تكن بالريال العُماني.
عن كل سطر: الوصف، والكمية، ووحدة القياس، وسعر الوحدة، والخصم، والوعاء الخاضع، ونسبة الضريبة، ومبلغها، وسبب الإعفاء حيث يوجد إعفاء.
عن الإجماليات: المجموع قبل الضريبة، ومجموع الضريبة، والخصم، وفرق التقريب إن وُجد، والمبلغ المستحق.
ليست البرمجة هي ما يطيل هذه المشاريع، بل هذه الأربعة:
ملف العملاء. الأرقام الضريبية غائبة، والاسم المسجّل اسم شخص لا اسم منشأة، والعنوان ناقص. وهذه عادة أطول مهمة في المشروع كله، وهي مهمة موظفيك لا مهمتنا، ولهذا نبدأ بها مبكراً.
التصنيف الضريبي. نظامك على الأرجح يحمل خانة واحدة: خاضع أو غير خاضع. والمطلوب ثلاث معاملات، والفرق بين نسبة الصفر والإعفاء ليس شكلياً: أحدهما يُبقيك مسترداً لضريبة المدخلات والآخر لا.
الترقيم وعدم التعديل. رقم متسلسل بلا فجوات ولا تكرار، وفاتورة لا تُعدَّل بعد إصدارها. وأخذ أعلى رقم وإضافة واحد داخل التطبيق يُنتج أرقاماً مكرّرة عند البيع المتزامن، والتسلسل الخام يترك فجوات يحتاج كل منها إلى تفسير. وهذا تغيير داخل نظامك، وهو الذي يحرّك التواريخ.
الدفعات المقدّمة والعرابين. الضريبة تستحق حين يصل المال، والفاتورة النهائية يجب ألا تُخضع المبلغ نفسه مرتين. وهذه أكثر نقطة نراها مكسورة في الأنظمة المخصّصة.
لا يستطيع أحد أن يعطيك مدة صادقة قبل أن يرى نظامك، ومن يعطيك رقماً في المكالمة الأولى فهو يخمّن. أربعة أشياء تحدّد المدة، وثلاثة منها عندك لا عندنا: حالة ملف عملائك، وسرعة محاسبك في اعتماد التصنيف الضريبي، وهل يحتاج ترقيم نظامك تعديلاً في شيفرته، ومدى ازدحام البيئة التجريبية لدى المزوّد. وأسرع مشروع هو الذي يبدأ صاحبه بتنظيف بياناته قبل أن يوقّع عقداً مع أحد. وهذه قائمة ما نطلبه في أول اجتماع:
نسخة من فاتورة ضريبية كاملة وأخرى مبسطة من إصدارك الحالي.
اسم نظامك وإصداره، ومن يملك صلاحية تعديله.
تصدير لملف العملاء، لنقيس كم منه يحمل رقماً ضريبياً واسماً قانونياً وعنواناً.
قائمة فئات أصنافك أو خدماتك، ومعاملتها الضريبية كما يراها محاسبك اليوم.
أنواع المستندات التي تصدرها فعلاً: فواتير، وإشعارات دائنة، وعروض أسعار، وسندات قبض، وفواتير دفعات مقدّمة.
مرحلتك في الإلزام كما أبلغك بها جهاز الضرائب.
الخلط بين الاسمين شائع عند من عمل في السوقين. برنامج المملكة العربية السعودية اسمه فاتورة وتشرف عليه هيئة الزكاة والضريبة والجمارك، وله متطلباته الخاصة من رمز الاستجابة السريعة والتوقيع الرقمي. وبرنامج سلطنة عُمان اسمه فوترة، ويشرف عليه جهاز الضرائب، ويقوم على إطار Peppol وعلى مزوّدي خدمة معتمدين. والنظامان مختلفان، ونسبة الضريبة نفسها مختلفة: 5% في عُمان و15% في السعودية. ومن ربط نظامه ببرنامج السعودية لا ينقل الربط كما هو إلى عُمان، وإن كان جزء كبير من التجهيز داخل البيانات مشتركاً بينهما.
الإلزام يصل على مراحل. والمراحل التي نشرها جهاز الضرائب ثلاث. وهناك مرحلة لاحقة تخصّ الجهات الحكومية لم نجد لها تاريخاً مثبّتاً في مصدر رسمي نحيلك إليه، فلن نكتب لك تاريخاً لها. وأياً كانت مرحلتك، تأكّد منها مع جهاز الضرائب مباشرة ولا تعتمد على جدول في موقع بائع، بما في ذلك هذا الموقع. وإن كنت في المرحلة الثالثة فأنت لست متأخراً، لكن العمل الذي يسبق الربط يقع كله عندك، وهو الذي يستهلك الوقت.
أغسطس 2026: نحو 100 من كبار المكلّفين، وقد أُبلغوا مباشرة.
فبراير 2027: بقية كبار المكلّفين المسجّلين في ضريبة القيمة المضافة.
أغسطس 2027: كل منشأة أخرى مسجّلة في ضريبة القيمة المضافة، وهنا تقع الأغلبية.
لا، ليس بالضرورة. المطلوب أن يُخرج نظامك فاتورة مهيكلة بالحقول المطلوبة، وأن يكون ترقيمه متسلسلاً وفواتيره غير قابلة للتعديل بعد إصدارها. كثير من الأنظمة تصل إلى ذلك بتعديل. وبعضها لا يصل، فيصبح الاستبدال أقل كلفة من الترقيع. وهذا قرار يُتّخذ بعد النظر في النظام لا قبله.
خبرتنا الأعمق في Microsoft Dynamics 365 وBusiness Central وPower Platform وDataverse وAzure. ونعمل كذلك مع الأنظمة المخصّصة وقواعد البيانات المباشرة. أما SAP وOracle فنعمل على مخرجاتها وطبقة التكامل معها، لا داخل تخصيصها العميق. وإن كان نظامك يُخرج بياناته بأي صيغة قابلة للقراءة، فهناك طريق.
لا. Dynacloud ليست مزوّد خدمة معتمداً ولا نقطة تبادل، ولا ننقل فواتيرك، ولا نتحدّث باسم جهاز الضرائب. عملنا داخل نظامك حتى يُنتج ما يقبله المزوّد الذي تختاره أنت. وهذا الفصل في مصلحتك: من يبيع القناة ليس الجهة المحايدة التي تسألها أي قناة تختار.
تحدّده أربعة أشياء: حالة ملف عملائك، وسرعة محاسبك في اعتماد التصنيف الضريبي لكل فئة، وهل يحتاج ترقيم نظامك وحماية فواتيره من التعديل إلى تغيير في شيفرته، ومدى ازدحام البيئة التجريبية لدى المزوّد. وأطولها في العادة ملف العملاء، وهو العمل الذي تستطيع البدء فيه اليوم بلا عقد.
هذا سؤال يُجاب عنه في التصميم لا عند أول انقطاع. نحدّد ما يظهر للموظف على الشاشة، ومن يملك تصحيح المستند وإعادة إرساله، وهل تكتمل عملية البيع بينما المستند في الطريق، وأين تُحفظ المستندات التي لم تُنقل بعد. ويُكتب الجواب في وثيقة التشغيل قبل تاريخ الإلزام.
الفاتورة الكاملة تحمل بيانات المشتري كاملة وتُستعمل بين المنشآت. والمبسطة تُستعمل مع المستهلك النهائي وتحمل بيانات أقل. وأيّهما تُصدر يعتمد على نوع المشتري وعلى حدّ المبلغ الوارد في اللائحة التنفيذية، ويُضبط هذا الحدّ في النظام مرة واحدة فلا يُترك لتقدير الموظف عند كل عملية.
تُحفظ الفاتورة المهيكلة وردّ المزوّد عليها، وليس صورة مطبوعة منها فقط. ونحدّد في المشروع مكان الحفظ ومدّته ومن يملك استخراج مستند بعينه عند طلب المدقّق. وكثير من المنشآت تكتشف عند أول طلب أنها تحتفظ بملف PDF بينما المطلوب هو المستند نفسه.