في معظم الفواتير يصدر البائع فاتورته بنفسه. لكن منظومة الفوترة الإلكترونية في السعودية تسمح بحالة مختلفة: أن يصدر طرف ثالث الفاتورة نيابةً عن البائع. هذا الطرف ليس المشتري ولا البائع، بل وكيل أو منصة أو مزوّد خدمة فوترة يتولّى إنشاء المستند وتوقيعه وإرساله للمقاصة باسم البائع. على مستوى ملف XML، هذه الحالة لها راية خاصة في رمز النوع، واتفاقية تحكمها، وتوزيع مسؤولية مختلف عن الفاتورة الاعتيادية.
هذا الدليل التقني موجَّه للمطوّرين والمحاسبين التقنيين الذين يريدون فهم الفوترة عبر طرف ثالث (Third Party Billing) من الداخل: من هو الطرف الثالث، وكيف تُرفع رايته داخل خاصية name في حقل InvoiceTypeCode، ومن يحمل معرّف الختم ويوقّع، وكيف توزَّع المسؤولية القانونية بين البائع ووكيله. يندرج هذا الدليل ضمن سلسلة التوثيق التقني للفوترة الإلكترونية.
يبني برنامج الفاتورة الإلكترونية من قيود الفاتورة بحقولها الإلزامية كاملة تلقائيًا، فلا تحتاج لكتابة XML بيدك. لكن فهم متى تُرفع راية الطرف الثالث، ومن يتحمّل التزام التوقيع والإرسال، يساعدك على ضبط العلاقة مع وكيلك أو منصتك، وقراءة الفاتورة المُولَّدة بدقة قبل اعتمادها.
ما المقصود بالفوترة عبر طرف ثالث؟
الفوترة عبر طرف ثالث ترتيب تُصدر فيه جهة مستقلة الفاتورة الضريبية باسم البائع وعلى مسؤوليته. البائع يظلّ صاحب التوريد قانونًا، ويبقى الطرف المسؤول أمام هيئة الزكاة والضريبة والجمارك (ZATCA) عن صحة الفاتورة، لكن العمل التقني للإنشاء والتوقيع والإرسال يقوم به طرف آخر متفّق معه.
الطرف الثالث قد يكون مكتبًا محاسبيًا يدير فوترة عملائه، أو منصة تجميع تصدر فواتير عشرات التجار، أو مزوّد خدمة فوترة متخصّص يربط أنظمة البائعين بمنصة فاتورة. القاسم المشترك أن هذا الطرف ليس مشتريًا في العملية ولا هو البائع الأصلي، بل وسيط تشغيلي يتصرّف بالنيابة بموجب اتفاقية مكتوبة.
الفرق الجوهري عن الفاتورة الاعتيادية ليس في محتوى الفاتورة، بل في هوية مُصدِرها التقني. بيانات البائع تبقى كما هي في قسم البائع، وبيانات المشتري في قسمه، لكن المنظومة تحتاج إشارة تقول إن من بنى هذا المستند ووقّعه هو وكيل لا البائع نفسه. هذه الإشارة هي راية الطرف الثالث، وهي ما يميّز هذا النوع داخل XML.
من المهم ألا نخلط بين الفوترة عبر طرف ثالث والفوترة الذاتية (Self-Billing). في الفوترة الذاتية يصدر المشتري الفاتورة عن مشترياته نيابةً عن البائع، أي أن مُصدِر الفاتورة طرف داخل العملية نفسها. أما في الفوترة عبر طرف ثالث فالمُصدِر طرف خارج العملية تمامًا: ليس بائعًا ولا مشتريًا، بل وكيل تشغيلي. هذا التمييز يقود اختلاف الراية المرفوعة في رمز النوع، واختلاف من تقع عليه المسؤولية القانونية.
نتناول في هذا الدليل أربعة محاور تميّز الفوترة عبر طرف ثالث: راية الطرف الثالث في رمز النوع، والاتفاقية التي تحكم العلاقة، ومن يحمل معرّف الختم ويوقّع، وكيف توزَّع المسؤولية. ثم نجمعها في مثال مستند، ونختم بأكثر الأخطاء البنيوية تكرارًا في هذا النمط.
راية الطرف الثالث: كيف يعرف النظام أن المُصدِر وكيل؟
يبدأ تمييز هذا النوع من الحقل نفسه الذي يميّز كل الفواتير: InvoiceTypeCode في الترويسة. القيمة 388 تعني «فاتورة ضريبية» بمعيار UBL، وخاصية name تحمل سلسلة من سبعة أرقام كل خانة فيها راية تصف صفة في الفاتورة. الخانتان الأوليان تحدّدان النوع (قياسية أو مبسّطة)، أما رايات الحالات الخاصة فتأتي في الخانات التالية.
راية الطرف الثالث تعيش في الخانة الثالثة من السلسلة. عندما يصدر وكيل الفاتورة نيابةً عن البائع، تُرفع هذه الخانة من 0 إلى 1. ففاتورة قياسية اعتيادية تقرأ سلسلتها 0100000، بينما فاتورة قياسية صادرة عبر طرف ثالث تقرأ 0110000. الرقم الثالث هو الفارق الوحيد المرئي في الراية، لكنه يغيّر معنى المستند للمنظومة.
هذه الراية لا تغيّر كون الفاتورة قياسية أو مبسّطة. يمكن أن تصدر منصة فاتورة قياسية لمشترٍ منشأة عبر طرف ثالث، فتقرأ السلسلة 0110000، أو فاتورة مبسّطة لفرد عبر طرف ثالث فتقرأ 0210000. الخانتان الأوليان تبقيان تصفان النوع، والخانة الثالثة وحدها تعلن أن المُصدِر وكيل.
الدرس هنا أن راية الطرف الثالث صفة تكميلية تُضاف فوق نوع الفاتورة، لا نوع مستقل بذاته. المنظومة تقرأ السلسلة كاملة: النوع أولًا، ثم الرايات الخاصة. رفع راية الطرف الثالث يخبر المنظومة أن تتوقّع توقيعًا من شهادة وكيل، وأن تربط الفاتورة باتفاقية تفويض قائمة، لا أن تتعامل معها كفاتورة أصدرها البائع بنفسه.
كتابة هذه السلسلة يدويًا مدخل مباشر للأخطاء، لأن خانة واحدة خاطئة تقلب معنى المستند. أي محرّر فواتير سليم يبني الراية آليًا بناءً على إعداد الحساب: إذا كان الحساب مهيّأً كوكيل يصدر نيابةً عن بائع، يرفع النظام الخانة الثالثة دون تدخّل المستخدم.
0100000: فاتورة اعتيادية (البائع يصدر)
0110000: فوترة عبر طرف ثالث
علم منفصل: الفوترة الذاتية (المشتري يصدر)
يجب أن تطابق الشهادة جهة الإصدار
الاتفاقية: ما الذي يجيز للطرف الثالث أن يصدر باسمك؟
لا يجوز لأي جهة أن تصدر فاتورة باسم بائع دون تفويض. الأساس القانوني للفوترة عبر طرف ثالث اتفاقية مكتوبة بين البائع ووكيله تنصّ صراحةً على أن الوكيل مخوَّل بإنشاء الفواتير الضريبية وتوقيعها وإرسالها للمقاصة نيابةً عن البائع. هذه الاتفاقية شرط سابق لرفع الراية، لا إجراء لاحق.
الاتفاقية تحدّد نطاق التفويض: هل يصدر الوكيل كل فواتير البائع أم فئة منها، وهل يشمل التفويض الإشعارات الدائنة والمدينة، ومدة السريان، وآلية إنهاء التفويض. البائع يبقى مسؤولًا عن صحة البيانات التي يزوّد بها الوكيل، والوكيل مسؤول عن صحة الإصدار التقني وفق ما فُوّض به.
على مستوى المستند، لا تظهر الاتفاقية نصًّا داخل XML، لكن أثرها يظهر في طرفين: راية الطرف الثالث المرفوعة في رمز النوع، وهوية الشهادة التي وُقّعت بها الفاتورة. المنظومة لا تطلب إرفاق الاتفاقية مع كل فاتورة، لكنها تتوقّع أن يكون البائع قد فوّض الوكيل فعلًا، وأن تكون شهادة التوقيع مسجّلة للوكيل لا للبائع.
هذا يعني أن إعداد الفوترة عبر طرف ثالث يبدأ خارج لحظة الإصدار. قبل أن تصدر أول فاتورة، يجب أن تكون الاتفاقية قائمة، وأن يكون الوكيل قد استخرج شهادة الختم الخاصة به من الهيئة، وأن يكون النظام مهيّأً لربط فواتير هذا البائع بحساب الوكيل. هذه التهيئة المسبقة هي ما يجعل الراية صادقة عندما تُرفع.
معرّف الختم والتوقيع: من يوقّع الفاتورة؟
هذا هو الفرق الأعمق بين الفوترة عبر طرف ثالث والفاتورة الاعتيادية. في الفاتورة العادية يوقّع البائع فاتورته بمعرّف ختم الالتزام التشفيري (Compliance Cryptographic Stamp Identifier المعروف اختصارًا بـ CSID) الخاص به. أما في الفوترة عبر طرف ثالث فالتوقيع يتمّ بمعرّف الختم الخاص بالوكيل، لا بالبائع.
معرّف الختم CSID شهادة تشفير تُصدرها الهيئة لكل جهة على حدة بعد تسجيلها في منصة فاتورة. الوكيل الذي يصدر نيابةً عن بائعين متعددين يستخرج شهادته الخاصة، ويوقّع بها كل الفواتير التي يصدرها لعملائه. الشهادة تثبت للمنظومة أن من بنى المستند ووقّعه هو هذا الوكيل تحديدًا، وأن الراية المرفوعة صادقة.
التمييز عملي ومهم. لو وقّع الوكيل فاتورةً برفع راية الطرف الثالث لكن بشهادة البائع لا بشهادته، لظهر تعارض بين الراية والتوقيع، فتردّ المنظومة المستند. الراية تعلن «وكيل أصدر هذا»، والتوقيع يجب أن يثبت أن الوكيل نفسه هو من وقّع. اتساق الراية مع الشهادة شرط لقبول الفاتورة.
قسم البائع داخل المستند لا يتغيّر رغم ذلك. الرقم الضريبي للبائع وعنوانه يبقيان في عنصر AccountingSupplierParty كما لو أصدر الفاتورة بنفسه، لأن التوريد توريده والفاتورة فاتورته قانونًا. الذي يختلف هو الشهادة التي وُقّع بها المستند والراية التي تعلن أن الإصدار تمّ عبر وكيل. البائع صاحب الفاتورة، والوكيل مُصدِرها التقني.
هذا الفصل بين «صاحب الفاتورة» و«مُصدِرها التقني» هو جوهر النمط. منصة تجميع تصدر آلاف الفواتير يوميًا لمئات التجار توقّعها كلها بشهادتها الواحدة، بينما يبقى كل تاجر هو البائع المعرَّف في فاتورته. الراية والشهادة معًا تخبران المنظومة بهذا الترتيب دون لبس.
يفسّر هذا الترتيب لماذا تناسب الفوترة عبر طرف ثالث نماذج أعمال بعينها. المنصات التي تستضيف بائعين كثرًا، ومكاتب المحاسبة التي تدير دفاتر عملائها، ومزوّدو الحلول الذين يربطون أنظمة متعددة بمنصة فاتورة، كلهم يحتاجون إصدار فواتير باسم غيرهم بشهادة واحدة موحَّدة. بدل أن تستخرج كل منشأة شهادتها وتدير اتصالها بالمنصة، يتولّى الوكيل هذا العبء التقني عن الجميع، ويبقى كل بائع معرَّفًا بفاتورته كما لو أصدرها بنفسه.
لكن هذا التوحيد يفرض انضباطًا في ربط كل فاتورة ببائعها الصحيح. الوكيل الذي يصدر لمئات البائعين يجب أن يضمن أن بيانات البائع في كل مستند تعود فعلًا للبائع صاحب التوريد، لا لبائع آخر في النظام. خطأ في ربط الفاتورة ببائعها يُنتج مستندًا صحيح البنية لكنه منسوب لطرف خاطئ، وهذا من أخطر أخطاء بيئات التجميع لأنه لا يوقف المقاصة بالضرورة، بل ينتج فاتورة معتمدة منسوبة لغير صاحبها.
البائع: مالك التوريد
الطرف الثالث: يصدر ويوقّع بشهادته
المشتري: يتسلّم الفاتورة
المقاصة والتبليغ في الفوترة عبر طرف ثالث
راية الطرف الثالث لا تغيّر مسار الاعتماد الذي يحدّده نوع الفاتورة. الفاتورة القياسية الموجَّهة لمنشأة تمرّ بالمقاصة الفورية (Clearance) سواء أصدرها البائع أم وكيله. والفاتورة المبسّطة الموجَّهة لفرد تُسلَّم فورًا ثم تُبلَّغ بها الهيئة خلال أربع وعشرين ساعة، سواء أصدرها البائع أم وكيله. ما يحدّد المسار هو نوع الفاتورة لا هوية مُصدِرها.
الفرق أن الوكيل هو من يقوم بالإرسال نيابةً عن البائع. عند المقاصة الفورية، يرسل الوكيل المستند الموقَّع بشهادته إلى منصة فاتورة، فتتحقق المنصة من البنية والحقول والتوقيع والراية، ثم تعيد الفاتورة مختومة باعتمادها. عندها يسلّم الوكيل الفاتورة المعتمدة للمشتري نيابةً عن البائع.
المنظومة تتحقق في المقاصة من اتساق ثلاثة عناصر معًا: راية الطرف الثالث المرفوعة، وشهادة التوقيع العائدة للوكيل، وبيانات البائع المعرَّف. أي تعارض بين هذه العناصر يردّ المستند برسالة رفض قبل صدور الختم. لذلك يتطلّب هذا النمط ضبطًا دقيقًا في إعداد حساب الوكيل قبل إصدار أي فاتورة.
نركّز هنا على أثر النمط على بنية الفاتورة فقط. أما خطوات المقاصة الكاملة من الإرسال إلى الرد المختوم، فتجدها في سلسلة التوثيق التقني للفوترة الإلكترونية، ولفهم اختلاف الحقول الإلزامية بين الفاتورة القياسية وفاتورة الفرد راجع دليل فواتير B2B بين المنشآت تقنيًا.
توزيع المسؤولية: من يتحمّل ماذا؟
الفصل بين صاحب الفاتورة ومُصدِرها التقني يفرض توزيعًا واضحًا للمسؤولية. البائع يبقى المسؤول الأول أمام الهيئة عن صحة الفاتورة ومحتواها، لأن التوريد توريده والضريبة ضريبته. تفويض الوكيل لا يعفي البائع من مسؤوليته القانونية عن صحة ما صدر باسمه.
الوكيل مسؤول عن الجانب التقني: بناء المستند وفق المعيار، والتوقيع بشهادته الصحيحة، ورفع راية الطرف الثالث، والإرسال للمقاصة في وقتها. إذا أصدر الوكيل فاتورة بنية خاطئة أو بتوقيع غير صالح، فالخلل التشغيلي مسؤوليته، حتى لو ظلّت المسؤولية القانونية عن التوريد على البائع.
هذا التوزيع يجعل جودة البيانات حلقة مشتركة. البائع يزوّد الوكيل ببيانات صحيحة عن التوريد والمشتري، والوكيل يحوّلها إلى مستند متوافق ويصدره في وقته. خطأ في البيانات الواردة من البائع يُنتج فاتورة خاطئة رغم سلامة عمل الوكيل التقني، وخطأ في الإصدار التقني يُفشل فاتورة رغم صحة بيانات البائع. لذلك تتطلّب العلاقة وضوحًا في الاتفاقية حول من يضبط ماذا.
عمليًا، يعني هذا أن البائع لا يتخلّى عن المتابعة بمجرد التفويض. عليه أن يتأكد أن الوكيل يصدر فواتيره في وقتها، وأن يراجع عيّنة من الفواتير الصادرة باسمه، وأن يحتفظ بنسخ منها لأغراض المراجعة الضريبية. التفويض ينقل العمل التقني، لا المسؤولية النهائية.
هناك بُعد آخر للمسؤولية يخصّ سجلّ الفواتير وأرشفتها. كل فاتورة يصدرها الوكيل باسم البائع تظلّ جزءًا من سجلّ البائع الضريبي، ويجب أن تكون متاحة للمراجعة عند طلب الهيئة. لذلك يحتاج البائع إلى آلية تضمن وصوله إلى كل فاتورة صدرت عنه، لا أن تبقى محبوسة في نظام الوكيل وحده. الاتفاقية الجيدة تنصّ على حق البائع في استلام نسخ كاملة من فواتيره ومستنداتها الموقَّعة فور صدورها.
كذلك تتعامل المعاملات التصحيحية مع المسؤولية بالمنطق نفسه. عند إصدار إشعار دائن أو مدين عبر الطرف الثالث، يرث الإشعار راية الطرف الثالث وشهادة الوكيل ذاتها، ويربط بالفاتورة الأصلية التي يصحّحها. يبقى البائع مسؤولًا عن صحة التصحيح، والوكيل مسؤولًا عن إصداره التقني السليم. هذا الاتساق بين الفاتورة وإشعاراتها التصحيحية شرط لقبول المنظومة لها معًا.
مثال متكامل: قراءة فاتورة صادرة عبر طرف ثالث
لنجمع ما سبق في مستند واحد مختصر. الفاتورة التالية فاتورة قياسية صادرة عبر طرف ثالث: لاحظ راية الطرف الثالث المرفوعة في السلسلة 0110000، وقسم البائع الذي يحمل بيانات البائع الأصلي لا الوكيل، والتوقيع الذي سيتمّ بشهادة الوكيل في قسم الامتدادات بعد المقاصة.
اقرأ المستند من أعلاه: راية الطرف الثالث في رمز النوع تخبرك أن المُصدِر وكيل، ثم يأتي البائع ببياناته الأصلية، ثم المشتري، فالبنود، فالإجماليات. عند الإرسال يوقّع الوكيل المستند بشهادته الخاصة، فتعرف المنظومة أن الراية صادقة. أي تعارض بين الراية والشهادة وبيانات البائع يوقف المقاصة فورًا.
أخطاء بنيوية شائعة في الفوترة عبر طرف ثالث
معظم حالات الرفض في هذا النمط تعود إلى عدم اتساق الراية مع التوقيع أو الإعداد. هذه أكثر الأخطاء تكرارًا وكيف تقرأها:
- راية مرفوعة بلا تفويض: رُفعت الخانة الثالثة دون اتفاقية قائمة أو دون تهيئة الحساب كوكيل، فتظهر فاتورة تعلن طرفًا ثالثًا لا أساس له.
- توقيع بشهادة البائع لا الوكيل: رُفعت راية الطرف الثالث لكن المستند وُقّع بمعرّف ختم البائع، فظهر تعارض بين الراية والشهادة.
- خلط بيانات البائع بالوكيل: وُضعت بيانات الوكيل في قسم البائع
AccountingSupplierPartyبدل بيانات البائع الأصلي، فأصبح صاحب التوريد خاطئًا في المستند. - راية في الخانة الخطأ: رُفعت راية في خانة أخرى من السلسلة بدل الخانة الثالثة، فتغيّر معنى الراية كليًا (تصدير أو قطاع طبي بدل طرف ثالث).
لاحظ أن كل هذه الأخطاء تتركّز في طرفين: راية رمز النوع، وشهادة التوقيع. نادرًا ما تُرفض فاتورة الطرف الثالث بسبب البنود أو الإجماليات، لأن هذه أقسام مشتركة مع كل الفواتير. أما الراية والشهادة فهما ما يميّز هذا النمط، وهنا يقع الخطأ غالبًا. ضبط جودة الفوترة عبر طرف ثالث يبدأ من ضبط إعداد حساب الوكيل وشهادته قبل إصدار أي فاتورة.
القاعدة الحاكمة: الراية والتوقيع والإعداد يجب أن تتسق معًا. الفاتورة التي تعلن أن وكيلًا أصدرها يجب أن تُوقَّع بشهادة ذلك الوكيل، وأن تستند إلى تفويض قائم، وأن تحمل بيانات البائع الأصلي، وإلا رفضتها المقاصة قبل أن تصل للمشتري.
كيف يتولّى قيود الفوترة عبر طرف ثالث نيابةً عنك
يدعم قيود إصدار الفواتير وفق متطلبات المرحلة الثانية من الفوترة الإلكترونية، ويبني المستند بحقوله الإلزامية ورمز نوعه الصحيح تلقائيًا اعتمادًا على إعداد الحساب وبيانات العميل. تحصل على هذا دون كتابة سطر XML واحد:
- تحديد النوع تلقائيًا: يبني قيود سلسلة
InvoiceTypeCodeالصحيحة حسب نوع الفاتورة وبيانات المشتري، ويضع القيم المتوافقة دون تدخّل يدوي. - التقاط البيانات الإلزامية: يطلب قيود الحقول اللازمة عند إضافة العميل، فلا تصدر فاتورة ناقصة الحقول التي توقفها المقاصة.
- التوقيع والمقاصة: يوقّع قيود الفاتورة بمعرّف الختم CSID ويرسلها إلى منصة فاتورة للمقاصة الفورية أو التبليغ حسب نوعها، ثم يعيدها مختومة جاهزة للتسليم.
- قراءة رسائل التحقق: إذا ردّت المنصة بتحذير أو رفض، يعرض قيود سبب الرفض بلغة مفهومة بدل شيفرة الخطأ الخام.
أصدر فواتيرك الإلكترونية متوافقة دون كتابة XML
يبني قيود مستند فاتورتك بحقوله الإلزامية ورمز نوعه الصحيح، يوقّعه بمعرّف الختم، ويمرّره عبر المقاصة الفورية جاهزًا للتسليم.
لماذا يهمّك فهم هذا النمط؟
حتى لو لم تكتب XML بنفسك، فهم الفوترة عبر طرف ثالث يجعلك أقدر على ضبط علاقتك بوكيلك أو منصتك. تعرف لماذا يجب أن تكون الاتفاقية قائمة قبل أول إصدار، ولماذا يجب أن يوقّع الوكيل بشهادته لا بشهادتك، ولماذا تبقى مسؤولية صحة الفاتورة عليك رغم أن غيرك أصدرها.
للفرق التقني أثر مباشر على من يبنون تكاملًا برمجيًا. إذا كنت تطوّر منصة تصدر فواتير نيابةً عن تجار، فعليك أن ترفع راية الطرف الثالث في الخانة الثالثة، وأن توقّع كل مستند بشهادة منصتك لا بشهادة كل تاجر، وأن تضع بيانات التاجر الصحيحة في قسم البائع. خلط هذه العناصر هو السبب الأشيع لفشل المقاصة في بيئات التجميع، لأن المنظومة ترفض التعارض بين الراية والشهادة وبيانات البائع.
كذلك يفيدك هذا الفهم إن كنت بائعًا تفكّر في تفويض وكيل. تعرف أنك تظلّ صاحب الفاتورة قانونًا، وأن عليك مراجعة الفواتير الصادرة باسمك، وأن جودة البيانات التي تزوّد بها الوكيل تحدّد جودة فواتيرك. التفويض ينقل العمل التقني، لكن الرقابة تبقى مسؤوليتك.
قائمة تحقّق سريعة لفاتورة طرف ثالث سليمة
قبل إصدار أي فاتورة عبر طرف ثالث، تأكد من اكتمال العناصر التي تميّزها عن الفاتورة الاعتيادية. هذه القائمة تلخّص ما سبق في خطوات قابلة للمراجعة:
- التفويض: اتفاقية مكتوبة قائمة تجيز للوكيل الإصدار باسم البائع وتحدّد نطاقه.
- راية الطرف الثالث: الخانة الثالثة في سلسلة
InvoiceTypeCodeمرفوعة إلى1(مثل0110000). - الشهادة الصحيحة: التوقيع بمعرّف الختم CSID الخاص بالوكيل لا بالبائع.
- بيانات البائع: قسم
AccountingSupplierPartyيحمل بيانات البائع الأصلي صاحب التوريد. - المسار: الفاتورة موجَّهة للمقاصة أو التبليغ حسب نوعها لا حسب هوية مُصدِرها.
اكتمال هذه البنود الخمسة يعني فاتورة طرف ثالث جاهزة للمقاصة من المحاولة الأولى. النظام المحاسبي السليم يطبّق هذه القائمة آليًا، لكن معرفتها تجعلك قادرًا على تفسير أي رفض إن حدث.
اتفاق تفويض مكتوب مسبق
رفع علم الطرف الثالث في النوع الفرعي
شهادة CSID خاصة بالطرف الثالث
بيانات البائع الأصلية في AccountingSupplierParty
المسار الصحيح للمقاصة أو الإبلاغ
الأسئلة الشائعة
ما الفرق بين الفوترة عبر طرف ثالث والفوترة الذاتية؟
في الفوترة عبر طرف ثالث يصدر وكيل خارج العملية (منصة أو مكتب أو مزوّد خدمة) الفاتورة نيابةً عن البائع. أما في الفوترة الذاتية فيصدر المشتري نفسه الفاتورة عن مشترياته نيابةً عن البائع. الفارق أن مُصدِر الطرف الثالث ليس بائعًا ولا مشتريًا، بينما مُصدِر الفاتورة الذاتية هو المشتري، وهذا يقود اختلاف الراية المرفوعة في رمز النوع.
كيف تُرفع راية الطرف الثالث في المستند؟
عبر الخانة الثالثة في سلسلة name داخل حقل InvoiceTypeCode. ترتفع هذه الخانة من 0 إلى 1 عند الإصدار عبر وكيل، فتقرأ سلسلة الفاتورة القياسية 0110000 بدل 0100000.
من يوقّع الفاتورة الصادرة عبر طرف ثالث؟
الوكيل، بمعرّف ختم الالتزام التشفيري (CSID) الخاص به لا بمعرّف البائع. الشهادة تثبت للمنظومة أن من بنى المستند ووقّعه هو الوكيل، وأن الراية المرفوعة صادقة. التوقيع بشهادة البائع مع راية طرف ثالث مرفوعة يُنتج تعارضًا يردّ الفاتورة.
من يتحمّل المسؤولية القانونية عن الفاتورة؟
البائع يبقى المسؤول الأول أمام الهيئة عن صحة الفاتورة ومحتواها لأن التوريد توريده. الوكيل مسؤول عن الجانب التقني من إصدار وتوقيع وإرسال. تفويض الوكيل لا يعفي البائع من مسؤوليته النهائية.
هل تتغيّر بيانات البائع في الفاتورة عند الإصدار عبر طرف ثالث؟
لا. يبقى قسم AccountingSupplierParty يحمل بيانات البائع الأصلي صاحب التوريد. الوكيل لا يظهر بياناته في قسم البائع، بل يظهر أثره في راية رمز النوع وفي شهادة التوقيع فقط.
هل أحتاج لكتابة XML بنفسي لإصدار فاتورة عبر طرف ثالث؟
لا. يبني قيود الفاتورة بحقولها الإلزامية ورمز نوعها تلقائيًا، ويوقّعها بمعرّف الختم ويمرّرها عبر المقاصة أو التبليغ حسب نوعها، فتدخل البيانات عبر واجهة بسيطة وقيود يولّد المستند المتوافق.
