كيف تربط نظامك أو متجرك بالفاتورة والإيصال الإلكتروني في مصر؟

منظومتان مختلفتان لدى مصلحة الضرائب المصرية، وقد تحتاج الاثنتين:

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

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

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

اجعل هدف المشروع أن تتطابق المبيعات والمستندات والمخزون، لا أن يظهر زر «إرسال» فقط.

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

إذا كان البيع يتم عبر متجر ونقاط بيع وفريق جملة، ارسم مصدر كل مستند. هل تصدره قناة البيع أم ERP مركزي؟ لا تسمح لقناتين بإصدار مستندين لنفس العملية. أعط الطلب ومعاملة الدفع والمستند معرفات مترابطة، بحيث يستطيع المحاسب ومكتب الدعم الوصول إلى السلسلة دون مطابقة أسماء العملاء يدويًا.

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

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

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

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

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

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

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

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

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

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

ما الفرق بين الفاتورة الإلكترونية والإيصال الإلكتروني؟

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

ما هو التوكن في الفاتورة الإلكترونية؟

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

ما هو كود الصنف في الفاتورة الإلكترونية؟

كل منتج أو خدمة في الفاتورة يحتاج كودًا معتمدًا: إما كود GS1 العالمي، أو كود داخلي (EGS) تسجله الشركة على المنظومة وتنتظر اعتماده قبل استخدامه.

ما هو الإشعار الدائن والإشعار المدين؟

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