منصّتك تُصدر الطلبات لعشرات المنشآت: من يُصدر الفاتورة الإلكترونية — المنصّة أم التاجر؟

إن كنت تملك تطبيق توصيل أو تأجير أو حجز أو خدمات منزلية يخدم عشرات المنشآت، فسؤالك الأول عن الفوترة الإلكترونية ليس «أي برنامج» بل «فاتورة مَن؟». وفي كل طلب يمرّ عبر منصّتك هناك فاتورتان لا واحدة، ولكلٍّ منهما مُصدر مختلف وحكم مختلف. الخلط بينهما هو ما يجعل منصّات كثيرة تظنّ أنها ملزمة بشيء ليست ملزمة به، أو معفاة من شيء هي ملزمة به.

الفاتورة الأولى: عمولتك

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

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

الفاتورة الثانية: الخدمة نفسها

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

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

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

ما يعنيه النموذج الثاني تقنيًا

«الإصدار نيابةً» ليس زرًّا في نظامك، بل ثلاثة أشياء يجب أن تكون صحيحة في كل فاتورة:

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

ثم يأتي نوع الفاتورة بحسب العميل: فرد بلا رقم ضريبي ← فاتورة مبسّطة تُبلَّغ خلال أربع وعشرين ساعة؛ منشأة مسجّلة ← فاتورة ضريبية تُعتمد قبل التسليم. والإلغاء والاسترجاع ← إشعار دائن يشير إلى الفاتورة الأصلية، لا حذف ولا سطر سالب.

كيف تبنيه من دون أن تبني طبقة التوقيع بنفسك

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

قائمة قصيرة قبل أن تبدأ

1. اقرأ شروط استخدام تطبيقك: من يتعاقد مع العميل النهائي؟ هذا يحدّد النموذج.
2. افصل الفاتورتين في نظامك: عمولة (منك إلى التاجر) وخدمة (من التاجر إلى العميل).
3. قرّر من يُصدر فاتورة الخدمة، وإن كانت المنصّة فاجعل ربط التاجر جزءًا من تسجيله عندك.
4. عرّف نوع العميل في كل طلب (فرد أم منشأة برقم ضريبي) لأن نوع الفاتورة ومسارها يختلفان.
5. ابدأ بتاجر واحد على بيئة الاختبار، ثم افتح حسابك وانتقل إلى الإنتاج حين تصحّ أول فاتورة.