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



كيف تمتثل المتاجر الإلكترونية في السعودية للمرحلة الثانية من الفوترة؟

كل طلب إلكتروني يجب أن يولّد فاتورة مبسطة (B2C) لحظة الدفع — أي ملف XML موقّع يحمل ختمًا تشفيريًا (CSID) ورمز QR بصيغة TLV/Base64 — ثم ترحيلها إلى منصة فاتورة خلال 24 ساعة من الإصدار.

عمليًا يعني ذلك؛ ربط Webhooks بوابة الدفع في متجرك بمحرك فوترة ينشئ ويوقّع ويرحّل تلقائيًا: تطبيقات بنقرة واحدة لمنصتي سلة وزد، أو ربط عبر REST API لشوبيفاي وووكومرس والمنصات المخصصة، فالفوترة اليدوية لا تنجو من حجم التجارة الإلكترونية، فالأتمتة هي استراتيجية الامتثال. إليك ما يغطيه هذا الدليل:

• ما الذي تغيّر فعليًا على المتاجر الرقمية في المرحلة الثانية، وقاعدة الـ24 ساعة التي تكسرها مواسم التخفيضات.
• كيف تربط سلة وزد وشوبيفاي وووكومرس والمنصات المخصصة بمنصة فاتورة.
• التشريح التقني الكامل لدورة حياة الطلب: من Webhook الدفع إلى قبول الهيئة.
• الحالات الخاصة التي تُسقط أي متجر: المرتجعات، وأكواد الخصم، والدفع عند الاستلام، والدفع الآجل (تابي وتمارا)
• كيف يؤتمت وافِق كل ذلك دون إبطاء عمليات الشراء؟

ما الذي يتغير على المتاجر الرقمية في المرحلة الثانية من الفوترة الإلكترونية؟

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

ما الفرق بين فاتورة الشراء التقليدية وفاتورة الضريبية المبسطة (B2C)؟

متجرك يُصدر النوعين على الأرجح، ولكل منهما مسار امتثال مختلف:

• الفاتورة الضريبية المبسطة (B2C) — إيصال طلب المستهلك، تُصدر لحظة البيع مع رمز QR للمرحلة الثانية (تسعة حقول بيانات بصيغة TLV مغلّفة بـBase64، تشمل الختم التشفيري وبصمة الفاتورة)، وموقّعةً بـمعرف الإنتاج (CSID) الخاص بجهازك، ثم تُرحَّل إلى هيئة الزكاة والدخل خلال 24 ساعة. العميل يستلمها فورًا؛ والهيئة خلال يوم.
• الفاتورة الضريبية القياسية (B2B) — تُصدر عندما يشتري عميل تجاري برقم تسجيل ضريبي (طلبات الجملة، والمشتريات المؤسسية عبر متجرك) وتتبع نموذج الاعتماد الأكثر صرامة، حيث يجب إرسال الـXML إلى الهيئة وختمه تشفيريًا قبل أن تكون الفاتورة قابلة قانونًا للمشاركة مع المشتري.

تعرّف على: لماذا يظهر عنوان الفاتورة أحياناً "فاتورة ضريبية مبسطة" بدلاً من "فاتورة ضريبية"؟

لماذا ينكسر شرط الترحيل خلال 24 ساعة في مواسم التخفيضات (Flash Sales)؟

تبدو الـ24 ساعة طويلة حتى تُجري حسابات الجمعة البيضاء، على سبيل المثال، متجر ينفّذ 200 طلب يوميًا يُنتج 200 فاتورة للترحيل؛ والمتجر نفسه في موسم تخفيضات قد يُنتج 15,000 فاتورة في ست ساعات، وهنا تتراكب أنماط الفشل:

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

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

فصّلنا لوحة القياس كاملة في دليلنا: مؤشرات الأداء للتحقق من نجاح ربط نظامك مع منصة فاتورة.

كيف تربط سلة أو زد أو شوبيفاي أو متجرك المخصص بمنصة فاتورة؟

هناك نموذجا ربط، والاختيار الصحيح يعتمد على مكان متجرك.

متجرك على سلة أو زد؟ الربط بنقرة واحدة من متجر التطبيقات

في المنصات السعودية الجاهزة، العبء الثقيل مُنتَج مسبقًا. فتثبيت وافق من متجر تطبيقات سلة أو زد يربط كل حدث طلب بمحرك فوترة مطابق: المنصة تدفع بيانات الطلب تلقائيًا، وطبقة المحاسبة تتولى تسجيل معرف الإنتاج (CSID) (تسجيل الجهاز عبر رمز التحقق OTP على منصة فاتورة)، وتوليد الـXML، والتوقيع، وحقن رمز QR، والترحيل خلال 24 ساعة.

فريقك لا يلمس ملف XML أبدًا. وقرارات التاجر الحقيقية على مستوى الإعداد فقط: أي حسابات في الدفتر تُربط بالمبيعات والشحن ورسوم البوابة، وكيف تُرحَّل المرتجعات.

متجرك على شوبيفاي أو ووكومرس أو نظام مخصص؟ استخدم REST API والـWebhooks

المنصات العالمية لا تتحدث لغة الهيئة أصلًا، فشوبيفاي لن توقّع لك فاتورة UBL. والبنية المجرَّبة:

• الـWebhooks كمحفّز. اشترك في حدث نجاح الدفع (orders/paid في شوبيفاي، أو woocommerce_order_status_completed، أو استدعاء الالتقاط من بوابة دفعك). فالطلب المدفوع — لا الطلب المُنشأ — هو لحظة الفوترة.
• الـREST API كمحرك فوترة. يرسل معالج الـWebhook حمولة الطلب (البنود، والضريبة والخصومات، والشحن، ونوع المشتري) إلى واجهة فوترة إلكترونية مثل واجهة وافِق، التي تبني XML وفق UBL 2.1، وتحسب الضريبة، وتوقّع بمعرف المتجر، وتولّد رمز QR بصيغة TLV، وترحّل إلى الهيئة.
• الاستجابة تُغلق الحلقة. تعيد الواجهة الفاتورة المطابقة (برمز QR) لإرفاقها ببريد تأكيد الطلب، مع حالة قبول الهيئة لسجلاتك.

كيف تبدو دورة حياة الفاتورة تقنيًا من سلة التسوق إلى منصة فاتورة؟

تتبّع طلبًا واحدًا عبر سلاسل الإمداد، وسيجد كل متطلب مكانه:



كيف تعالج المرتجعات وأكواد الخصم والدفع عند الاستلام والدفع الآجل بشكل صحيح؟

المسار السعيد سهل، لكن امتثال التجارة الإلكترونية يُكسب أو يُخسر في الحالات الخاصة.

ماذا يحدث عند استرداد العميل لأمواله أو إلغاء الطلب؟

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

وفي التجارة الإلكترونية يجب أتمتة ذلك من طرف إلى طرف: Webhook الاسترداد من بوابة الدفع يجب أن يُطلق توليد الإشعار الدائن مع حلّ الربط بالفاتورة الأصلية تلقائيًا، بما يشمل الاستردادات الجزئية (بند واحد مرتجع من خمسة).

قواعد التوثيق كاملة في: كيفية إصدار إشعار دائن متوافق مع المرحلة الثانية للفوترة الإلكترونية؟

أين تذهب أكواد الخصم ورسوم الشحن داخل هيكل الـXML؟

كوبون 20% على كامل المتجر ليس رقمًا واحدًا، بل يجب تمثيله في UBL 2.1 بحيث تبقى المبالغ الخاضعة متسقة: الخصومات توزَّع على مستوى البنود أو كسماح على مستوى المستند، مع احتساب الضريبة على الوعاء الخاضع بعد الخصم، ومطابقة كل إجمالي مصرَّح مع بنوده حتى الهللة، أما الشحن فهو بند توريد خاضع بذاته (بالنسبة الأساسية للتوصيل المحلي)، لا رقمًا سحريًا يُلحق بالإجمالي. والأنظمة التي تحسب الخصم في السلة دون هيكل الـXML تُنتج رفض «عدم تطابق التقريب» الكلاسيكي.

كيف تُصدر فواتير الدفع عند الاستلام (COD) دون خلق التزامات ضريبية وهمية؟

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

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

كيف يؤثر الدفع الآجل (تابي وتمارا) على الفاتورة؟

يُربك الدفع الآجل الفرقَ المالية لوجود تدفقين ماليين مختلفين: فاتورة العميل وتسوية المزود. فالفاتورة الضريبية للعميل تكون بـكامل قيمة الطلب وكامل ضريبته — العميل مدين بالسعر كله؛ وتابي أو تمارا تموّله فحسب.

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

كيف يضمن نظام "وافِق" أتمتة الفوترة لمتجرك دون إبطاء عمليات الشراء؟

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

• معالجة غير متزامنة عالية الإنتاجية. يُقرّ استلام Webhooks الدفع فورًا وتجري الفوترة خارج مسار الشراء — فدفقات مواسم التخفيضات بآلاف الطلبات في الساعة تصطف وتُعالج دون مساس بالتحويل.
• طوابير تخزين احتياطي لانقطاعات الهيئة. إذا تباطأت منصة فاتورة أو تعذّر الوصول إليها وقت الذروة، تُخزَّن الفواتير بموثوقية ويُعاد إرسالها تلقائيًا بتباعد محسوب — فمهلة الـ24 ساعة يديرها الطابور، لا مهندس يوقَظ منتصف الليل.
• فحص مسبق قبل كل إرسال. تُفحص كل حمولة مقابل مخطط الهيئة وقواعدها — الحقول الإلزامية، حسابات الضريبة، توزيع الخصومات، حالة سلسلة الـHash — فتُصلَح الأخطاء عند المصدر بدل أن تصل كرفض.
• موصلات جاهزة وواجهات مفتوحة. تطبيقات بنقرة واحدة لسلة وزد؛ وواجهات REST وWebhooks موثقة لشوبيفاي وووكومرس والأنظمة المخصصة — بمحرك التوقيع وQR والترحيل نفسه تحتها جميعًا.
• سطح مطابقة واحد. كل طلب وفاتورة وإشعار دائن وحالة لدى الهيئة في دفتر واحد، فيصبح إقفال شهرك مراجعةً لا تحقيقًا.



اقرأ أيضًا: لماذا ترفض منصة فاتورة فواتيرك؟[مع حلول عملية للأخطاء]

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

الأسئلة المتداولة حول الفوترة الإلكترونية للمتاجر الإلكترونية

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

نعم. كل عملية بيع خاضعة من متجر مسجل في ضريبة القيمة المضافة يجب أن تُنتج فاتورة إلكترونية — مبسطة لطلبات المستهلكين (B2C) تُرحَّل للهيئة خلال 24 ساعة، أو قياسية للمشترين التجاريين (B2B) تُعتمد من الهيئة قبل مشاركتها. ولا يوجد حد أدنى للحجم أو إعفاء للطلبات الصغيرة.

كيف أتعامل مع فواتير الدفع عند الاستلام؟

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

هل يمكن ربط متجر شوبيفاي (Shopify) بـالهيئة مباشرة؟

ليس ربطًا أصيلًا — فشوبيفاي لا تولّد XML موقّعًا مطابقًا لمتطلبات الهيئة ولا تدير معرفات الإنتاج. البنية المعيارية تربط Webhooks الدفع في شوبيفاي بمحرك فوترة معتمد عبر REST API، يبني فاتورة UBL ويوقّعها ويولّد رمز QR ويرحّل إلى منصة فاتورة تلقائيًا.

كيف تؤثر أكواد الخصم على حساب ضريبة الفاتورة؟

تُحسب الضريبة على المبلغ الخاضع بعد الخصم، ويجب تمثيل الخصم داخل هيكل XML الفاتورة — موزَّعًا على البنود أو كسماح على مستوى المستند — بحيث تتطابق الإجماليات المصرَّحة مع البنود تمامًا. وتطبيق الخصم في سلة التسوق دون هيكل الـXML سببٌ شائع لرفض «عدم تطابق التقريب».

ماذا يحدث عند تعثر سيرفرات الهيئة أثناء الضغط العالي في المتجر؟

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