نظام EZD المتكامل مع KSeF لا يعني بعد تشغيل تداول الفواتير آليًا

هذا المقال موجّه لأمناء السر وأمناء الصندوق (skarbnik) الذين يسمعون من المورّد عبارة "نظامنا من فئة EZD يدعم KSeF"، ويتساءلون عمّا إذا كان ذلك يغلق ملف تداول الفواتير.

ما الذي يحققه فعليًا التكامل بين EZD وKSeF

اعتبارًا من 1 فبراير 2026 تستقبل الهيئات الحكومية الفواتير المُهيكلة عبر النظام الوطني للفوترة الإلكترونية KSeF. بعض الأنظمة من فئة EZD، ومنها نظام EZD RP، قادرة على استيراد هذه الفاتورة وعرضها كمراسلة واردة. وهذه فائدة حقيقية: فالفاتورة لا تضيع في البريد الإلكتروني، ولها رقم في KSeF وتاريخ ورود، وتظهر في النظام. غير أنها عادةً لا تُحال مباشرةً إلى الملف المعني. فأولًا يراها مكتب استقبال المراسلات، الذي يحيلها إلى الوحدة الموضوعية، وهذه الوحدة هي من يُلحق الفاتورة بالملف. والسؤال هو: هل يعرف مكتب استقبال المراسلات فورًا إلى أي وحدة تنظيمية ينبغي توجيه هذه الفاتورة؟ ويجب أيضًا أن نتذكر أن البيانات الوصفية للفاتورة تصف الفاتورة نفسها: البنود، والمبالغ الصافية والإجمالية، ونسب ضريبة القيمة المضافة. وهذه لا تتطابق دائمًا مع ما يُدرج في استمارة تسجيل المراسلات الواردة، التي يحدد نطاق بياناتها الوصفية دليلُ الأرشفة والتوثيق الداخلي (instrukcja kancelaryjna).

وعند هذا الحد ينتهي دور التكامل. فالفاتورة موجودة في النظام، بل ربما في الملف، لكن لم يصفها أحد بعد، ولم تُعتمد، ولم تُراجَع، ولم تُرحَّل محاسبيًا. ويعتمد مسارها التالي على كيفية تنظيم الهيئة لتداول المستندات المحاسبية. ففي كثير من الهيئات لا يزال المسار كما كان قبل تطبيق KSeF: طباعة، وتوقيعات على ظهر الورقة أو على ختم، وملف يُنقل إلى قسم المالية، وإدخال يدوي في نظام الشؤون المالية والمحاسبية.

مسار الفاتورة من الورود إلى السداد

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

1. الورود. تصل الفاتورة عبر KSeF، لكن ليس عبره حصرًا. فحتى نهاية عام 2026، قد يستمر بعض الموردين الصغار في إصدار الفواتير خارج KSeF، كما أن الموردين الأجانب يصدرونها خارج النظام حتى بعد ذلك التاريخ. وتظل الفواتير ترد عبر البريد الإلكتروني وورقيًا، ويجب مسح الفواتير الورقية ضوئيًا وقراءتها آليًا (OCR) حتى لا تُنسخ بياناتها يدويًا. وفي KSeF لا يوجد عادةً مكان للمرفقات (إذ لا يتيح هيكل FA(3) سوى مرفق محدود في شكل بيانات، ويجب الإبلاغ عن استخدامه)، لذا كثيرًا ما يرسل المورّد الفاتورة نفسها إضافيًا عبر البريد الإلكتروني مرفقةً بالمستندات المصاحبة لها: محضر الاستلام، أو كشف الأعمال، أو المواصفات الفنية. ويحدث أحيانًا أن يرسل المورّد نسخة مطبوعة أو ملف PDF لفاتورة موجودة أصلًا في KSeF، من دون أي مرفقات. وفي حال تعطل نظام KSeF أو العمل في الوضع غير المتصل (offline)، تصل الفاتورة المرفقة برمز QR إلى الهيئة قبل وصولها إلى النظام. لذا يجب أن تعرف الهيئة أن هذه الفاتورة موجودة لديها فعلًا، حتى لا تُعالَج مرتين. وفضلًا عن ذلك، الفاتورة ليست المستند الوحيد ذا الطابع التكلفي؛ فوثائق التأمين، وإيصالات عقود القانون المدني، والإشعارات، والرسوم، وقرارات المستحقات تمر بمسار مشابه: وصف، واعتماد، وتصنيف، وترحيل محاسبي، وسداد. وينبغي أن تصل جميع المستندات ذات الطابع التكلفي، بصرف النظر عن قناة الورود ونوع المستند، إلى مسار تداول واحد. وإلا، فسيكون لدى الهيئة مسار منفصل للفواتير الواردة عبر KSeF ومسار ورقي آخر لكل ما عداها.
2. الربط بالعقد أو أمر الشراء. تتعلق الفاتورة بعقد أو أمر تكليف أو طلب شراء محدد. وقد يكفي أحيانًا ربطها بالعقد، وأحيانًا بأمر الشراء الذي لا يقابله عقد منفصل. وقد يحدث أيضًا أن تُبرم عدة أوامر شراء بموجب عقد إطاري واحد، وتتعلق الفاتورة بأحد هذه الأوامر، فيلزم ربطها بأمر الشراء، ومن خلاله بالعقد. الربط الجيد يُظهر فورًا الوحدة الموضوعية المعنية، والمبلغ المطلوب تسويته، وما تبقى من قيمة أمر الشراء والعقد. وبدون سجل العقود وسجل أوامر الشراء، يضطر أحدهم إلى البحث عن هذه المعلومات يدويًا.
3. الوصف والموافقات. تؤكد الوحدة التي أصدرت طلب الشراء أن الخدمة قد أُنجزت أو البضاعة قد سُلِّمت، وفقًا للعقد أو أمر الشراء. وغالبًا ما لا ينتهي الأمر عند هذا الحد. فإذا كان الشراء مموَّلًا من عدة موازنات تقع مسؤوليتها على وحدات مختلفة، ينبغي أن توافق كل وحدة منها على الجزء الذي يقع على عاتق موازنتها. وإذا كان الإنفاق ذا طابع معلوماتي، فإن دليل التداول غالبًا ما يستلزم موافقة إضافية من قسم تقنية المعلومات، حتى وإن كانت الوحدة الموضوعية قسمًا آخر. وينطبق الأمر نفسه عادةً على النفقات الاستثمارية، والمشاريع الممولة من الاتحاد الأوروبي، والمشتريات العامة. قد تحتاج فاتورة واحدة إذن إلى ثلاث أو أربع موافقات، وقد يكون جمعها جميعًا، خصوصًا على الورق، الجزء الأكثر إرهاقًا في المسار: فالفاتورة تنتظر على مكتب موظف في إجازة، وتعود بسبب نقص توقيع، ولا يعرف أحد في أي مكتب هي الآن.
4. مصدر التمويل والتصنيف الموازني. يجب تحديد الباب والفصل والبند، والمهمة في الخطة المالية، وأحيانًا المشروع ومصدر التمويل. ويتحقق أحدهم مما إذا كانت الاعتمادات متوفرة في الخطة.
5. المراجعة والترحيل الأولي والاعتماد للصرف. يراجع قسم المحاسبة الفاتورة من الناحيتين الشكلية والحسابية، ويؤكد كبير المحاسبين (أمين الصندوق "skarbnik" في وحدات الحكم المحلي JST) إجراء المراجعة الأولية. ويُصنَّف المستند عندئذٍ للإدراج في السجلات المحاسبية. وبعد مراجعة أمين الصندوق، كثيرًا ما يستلزم دليل التداول اعتمادًا إضافيًا من أحد أعضاء الهيئة التنفيذية المسؤول عن إشراف الوحدة الموضوعية (في البلدية يكون ذلك رئيس البلدية "wójt" أو العمدة "burmistrz" أو نائبه)، وفي غيابه من عضو آخر في الهيئة التنفيذية. وهذا يعني شخصًا إضافيًا، وتوقيعًا إضافيًا، ومكانًا إضافيًا قد تنتظر فيه الفاتورة إذا لم يحدد مسار التداول من يحل محل من.
6. القيد في نظام الشؤون المالية والمحاسبية. يجب أن تصل الفاتورة المعتمدة إلى قسم المحاسبة. وهذه أهم نقطة تلاقٍ بين الأنظمة: فإن لم يكن هناك ربط في هذه النقطة، فإن بيانات الفاتورة التي وصلت أصلًا كملف مُهيكل، يعيد أحدهم كتابتها من النسخة المطبوعة.
7. السداد. الدفع عملية منفصلة، مرتبطة بالفاتورة لكنها ليست جزءًا منها. وعادةً ما يتولاها نظام الشؤون المالية والمحاسبية: إذ تُجمَّع دفعات عدة فواتير في حزمة تحويلات واحدة، مع مراعاة المواعيد، ونظام الدفع المقسَّم (split payment) عند الاقتضاء. وينبغي أن يقتصر دور مسار تداول الفاتورة على تزويد قسم المحاسبة بمجموعة البيانات الكاملة، ثم معرفة أن الفاتورة قد سُدِّدت.
8. الأرشفة. تبقى الفاتورة، مع وصفها وموافقاتها وتأكيد سدادها، في مكان واحد، جاهزة للمراجعة والتدقيق.

نظام KSeF المدمج مع EZD يغطي الخطوة الأولى وجزءًا من الخطوة الثامنة. أما الخطوات الست المتبقية فتجري بمعزل عنه.

مثال على العملية في رسم واحد

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

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

كم نظامًا تمر به الفاتورة الواحدة

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

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

أين يضيع الوقت فعليًا

الموافقة الموضوعية أو مراجعة أمين الصندوق هي قرارات، وينبغي أن تبقى بيد البشر. أما الوقت فيضيع في مكان آخر، في المهام المساعدة:

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

هذه الأعمال بالتحديد هي ما يستحق الأتمتة. ليس لأنها صعبة، بل لأنها تتكرر مع كل فاتورة، وعددها في الهيئة الواحدة يبلغ الآلاف سنويًا.

كيف نتعامل مع تداول الفواتير بحكمة

للترتيب أهمية هنا: أولًا العملية، ثم الأداة.

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

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

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

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

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

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

تحديث دليل التداول. فالموافقة الإلكترونية غير المنصوص عليها في الدليل ينتهي أمرها غالبًا بطباعة الفاتورة "للتوثيق فحسب". وعند تعديل العمليات والدليل، يُستحسن أولًا تخيّل الوضع المثالي: أسلوب عمل للموظفين لا يقوم فيه أحد بعد بأي مهمة مساعدة لا داعي لها. وعندها فقط تُصاغ نصوص الدليل بما يتوافق مع هذا الوضع، لا العكس.

المصادر

• وزارة المالية: نطاق نظام KSeF الإلزامي
• قانون المحاسبة الصادر في 29 سبتمبر 1994، نظام ISAP (المادتان 21 و22)
• قانون المالية العامة الصادر في 27 أغسطس 2009، النص الموحَّد الصادر عن مكتب مجلس النواب (المادة 54)
• تقويم الالتزامات لدى Krogis: KSeF وe-Doręczenia وEZD

الوضع القانوني محدَّث حتى 30 أكتوبر 2026.