الفاتورة الإلكترونية: ما الذي تطلبه من النظام الذي تشغله الآن

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

والسؤال الذي يسأله من سيدفع ليس «ما هو الالتزام» — هو يعرف أن عليه التزاما — بل: ما الذي يطلبه هذا من النظام الذي أشغله اليوم؟ وفيما يلي إجابته بالترتيب الذي تظهر به الأمور في التنفيذ. والخلاصة قبل التفصيل: الربط نفسه أصغر أجزاء المشروع، وأكبرها قائمة أصنافك.

الالتزام على الفاتورة، لا على برنامج بعينه

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

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

الأكواد الموحدة للأصناف: الشغل الذي لا يضعه أحد في الميزانية

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

أي كود، ومن يقرره

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

المطابقة هي المشروع نفسه

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

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

التوقيع: خطوة في الدورة، وشيء مادي يحفظ الشهادة

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

وهنا تظهر قرارات لا تذكر في الاجتماع الأول وتظهر في أول يوم تشغيل:

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

الإرسال ورقم الفاتورة: متى تكون الفاتورة قد صدرت

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

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

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

الفاتورة المرفوضة هي الحالة التي تحكم على النظام

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

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

ما يجب أن يظهر على الشاشة

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

ومن يتابعه كل يوم

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

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

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

وما يطلبه ذلك من نظامك:

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

الربط الآلي أو الإدخال اليدوي: الأرخص قد يكون الصحيح

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

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

ما يحدد حجم الشغل عندك

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

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

ابدأ من قائمة الأصناف: قائمة مراجعة قبل أول اجتماع

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

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

من ينفذ ومن يقرر

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

والجملة التي نقولها قبل التعاقد لا بعده: الربط قد ينتهي قبل أن تنتهي قائمة أصنافك، لا بعدها. فإن أردت أن يقصر هذا المشروع ويقل ثمنه، ابدأ بالقائمة قبل أن تبدأ بالعرض.