فواتير B2C للأفراد تقنياً

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

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

ما هي الفاتورة الضريبية المبسّطة (B2C)؟

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

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

في المرحلة الثانية من الفوترة الإلكترونية، لم يعد الإيصال مجرّد ورقة. صار مستندًا رقميًا منظَّمًا بصيغة UBL 2.1، يحمل توقيعًا تشفيريًا ورمز QR ومعرّفًا فريدًا، ويُرسَل لاحقًا إلى منصة فاتورة للإبلاغ عنه. التغيير جذري في البنية، حتى لو بقي شكل الإيصال للعميل بسيطًا كما كان.

لماذا توجد فئة مستقلة للأفراد أصلًا؟

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

لو طُبّقت المقاصة اللحظية على كل عملية بيع في متجر تجزئة مزدحم، لتوقفت طوابير الدفع عند كل انقطاع للإنترنت. لذلك اختارت الهيئة نموذج الإبلاغ المؤجّل لفواتير الأفراد: أصدر الفاتورة، سلّمها للعميل فورًا، ثم أبلِغ عنها خلال 24 ساعة. هذا الفصل بين المسارين هو سبب وجود نوع فرعي مستقل في بنية الـ XML، وهو ما سنفكّكه في الأقسام التالية.

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

كيف تتمايز فئة الأفراد عن فئة المنشآت بصريًا

النوع الفرعي للفاتورة: لماذا القيمة 02؟

كل فاتورة إلكترونية تحمل حقلًا يحدّد نوعها على مستويين. المستوى الأول هو نوع المستند (فاتورة، إشعار دائن، إشعار مدين)، والمستوى الثاني هو حقل النوع الفرعي الذي يميّز بين فاتورة المنشآت وفاتورة الأفراد. هذا الحقل هو نقطة الانطلاق التي تحدّد المسار كله.

في مواصفات الهيئة، يُعبَّر عن نوع المستند برمز رقمي في الحقل InvoiceTypeCode: القيمة 388 تعني «فاتورة ضريبية» بحسب معيار UN/CEFACT. أما التمييز بين القياسية والمبسّطة فيأتي من سمة name المرافقة، وهي سلسلة من سبع خانات. الخانة الأولى تحمل 01 للفاتورة القياسية (B2B) و02 للفاتورة المبسّطة (B2C).

إليك المقطع كما يظهر في XML فاتورة مبسّطة:

<cbc:InvoiceTypeCode name="0211010">388</cbc:InvoiceTypeCode>

هنا القيمة 388 ثابتة لأنها «فاتورة»، بينما السمة name="0211010" هي التي تحمل التصنيف: الخانتان الأوليان 02 تعنيان «مبسّطة»، وبقية الخانات أعلام رقمية لحالات مثل الإعفاء الضريبي والتصدير والتأجير. للمقارنة، الفاتورة القياسية تبدأ سمتها بـ 01 بدلًا من 02. تغيير خانة واحدة يقلب المسار من المقاصة إلى الإبلاغ.

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

الرقم الضريبي للمشتري: لماذا هو غير مطلوب هنا؟

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

عمليًا، يكون وسم بيانات المشتري في فاتورة B2C إما محذوفًا بالكامل أو مختصرًا إلى الحد الأدنى. هذا ليس ترخيصًا في البيانات، بل هو تبسيط مقصود في المواصفة. الهيئة لا تطلب ما لا يُستخدم.

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

<cac:AccountingCustomerParty>
  <cac:Party>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>399999999900003</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:PartyTaxScheme>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>شركة المشتري المحدودة</cbc:RegistrationName>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>

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

انتبه إلى استثناء واحد: إذا طلب الفرد فاتورة باسمه للاسترداد أو لأي غرض، يمكن إضافة معرّفه (مثل رقم الهوية الوطنية) كحقل اختياري، لكن ذلك لا يحوّل الفاتورة إلى B2B. تبقى مبسّطة ما دامت لمستهلك نهائي.

رمز الاستجابة السريعة QR: إلزامي وحامل للتوقيع

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

رمز QR في المرحلة الثانية ليس مجرّد نص مقروء. إنه حقل مشفَّر بصيغة TLV (نوع، طول، قيمة) ثم مرمّز بـ Base64، ويحوي ثمانية حقول إلزامية:

• اسم البائع.
• الرقم الضريبي للبائع.
• الطابع الزمني للفاتورة.
• إجمالي الفاتورة شاملًا الضريبة.
• قيمة ضريبة القيمة المضافة.
• قيمة تجزئة الفاتورة (Hash).
• التوقيع التشفيري للفاتورة.
• المفتاح العام للبائع.

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

إليك كيف يظهر الحقل داخل XML بعد ترميزه (القيمة مختصرة للتوضيح):

<cac:AdditionalDocumentReference>
  <cbc:ID>QR</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">
      AQ1Rb3lvZCBTdG9yZQIPMzk5OTk5OTk5OTAwMDAzAhM...Base64
    </cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

المهم أن تدرك أن هذا الحقل يُولَّد آليًا بعد توقيع الفاتورة، لأنه يحوي التوقيع نفسه. لا يمكن لمحاسب أن يكتبه يدويًا. النظام المحاسبي هو من يبني سلسلة TLV ويوقّعها ويرمّزها ويضعها في مكانها.

تفكيك بنية الفاتورة المبسّطة حقلًا حقلًا

العناصر التشفيرية: التوقيع وUUID والتجزئة

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

1. المعرّف الفريد UUID

كل فاتورة تحمل معرّفًا عالميًا فريدًا بصيغة UUID من 36 خانة. هذا المعرّف يختلف عن رقم الفاتورة التسلسلي الذي يراه العميل. UUID مخصّص للأنظمة، ويضمن ألا تتكرر هوية فاتورتين في العالم. يظهر في وسم مستقل:

<cbc:UUID>3cf5ee18-ee25-44ea-a444-2c37ba7f28be</cbc:UUID>

2. تجزئة الفاتورة السابقة (Hash)

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

<cac:AdditionalDocumentReference>
  <cbc:ID>PIH</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">
      NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzk=
    </cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

3. التوقيع التشفيري وشهادة CSID

التوقيع التشفيري هو ختم رقمي يُولَّد باستخدام شهادة معتمدة من الهيئة تُسمّى CSID (معرّف ختم الامتثال التشفيري). هذه الشهادة تثبت أن النظام المُصدِر مسجَّل ومعتمد. التوقيع يُحسَب على محتوى الفاتورة، فأي تعديل لاحق على أي حقل يُبطل التوقيع.

تفاصيل شهادة CSID وكيفية الحصول عليها وتجديدها مشروحة في دليل شهادة CSID. ما يهمّنا هنا أن فاتورة B2C تُوقَّع بنفس الشهادة، لكن مسار ما بعد التوقيع يختلف: تُسلَّم للعميل فورًا بدل انتظار رد المقاصة.

ملاحظة دقيقة في التسمية: الاختصار الصحيح هو CSID، لا CCSI. الخلط شائع، والاسم الكامل هو Compliance Cryptographic Stamp Identifier. اكتبه دائمًا CSID لتفادي الالتباس في التوثيق التقني.

مسار B2C مقابل B2B: أين يفترق الـ XML فعليًا؟

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

• النوع الفرعي: B2C تبدأ سمتها بـ 02، وB2B بـ 01.
• الرقم الضريبي للمشتري: إلزامي في B2B، غير مطلوب في B2C.
• رمز QR: إلزامي وظاهر على الإيصال في B2C، وأقل صرامة في B2B.
• مسار المنصة: B2B تمرّ بالمقاصة قبل التسليم، وB2C تُسلَّم فورًا ثم يُبلَّغ عنها.
• توقيت إرسال المنصة: لحظي للمقاصة في B2B، وخلال 24 ساعة للإبلاغ في B2C.

المقاصة نفسها (المسار الذي تسلكه فاتورة المنشآت) مشروحة في دليل المقاصة (Clearance). الفرق الجوهري أن المقاصة تحدث قبل وصول الفاتورة للمشتري، بينما الإبلاغ في B2C يحدث بعد التسليم. هذا ما يجعل البيع للأفراد سريعًا حتى عند ضعف الاتصال.

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

دورة حياة فاتورة B2C على مستوى البيانات

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

1. بناء المستند المنظَّم: ينشئ النظام مستند UBL 2.1 بكل الوسوم: البائع، البنود، الكميات، الأسعار، نسبة الضريبة 15% والإجماليات. هنا تُضبط خانة النوع الفرعي على 02.
2. توليد UUID والتجزئة: يُسنَد للفاتورة معرّف فريد، وتُحسَب تجزئتها وتُربَط بتجزئة الفاتورة السابقة لإكمال السلسلة.
3. التوقيع بشهادة CSID: يُحسَب التوقيع التشفيري على محتوى الفاتورة باستخدام المفتاح الخاص المرتبط بالشهادة.
4. توليد رمز QR: تُبنى سلسلة TLV من الحقول الثمانية بما فيها التوقيع، ثم تُرمَّز بـ Base64 وتُوضَع في الفاتورة.
5. الإصدار والتسليم الفوري: يُطبَع الإيصال أو يُرسَل للعميل رقميًا فورًا، دون انتظار أي رد من المنصة.
6. الإبلاغ خلال 24 ساعة: تُرسَل نسخة الفاتورة الموقَّعة إلى منصة فاتورة عبر واجهة برمجية خلال المهلة الملزمة.

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

قاعدة الـ 24 ساعة وما تعنيه تقنيًا

منصة فاتورة لا تنتظر فاتورة B2C لتوافق عليها قبل التسليم. الفاتورة صالحة وسارية من لحظة إصدارها وتسليمها للعميل. التزام المنشأة هو أن ترسل نسختها للمنصة خلال 24 ساعة من الإصدار.

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

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

كيف يتدفّق الإبلاغ بعد التسليم الفوري

بنية البنود والإجماليات الضريبية في الفاتورة المبسّطة

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

تحمل الفاتورة المبسّطة وسم TaxTotal الذي يجمع قيمة الضريبة، ووسم LegalMonetaryTotal الذي يحمل الإجمالي قبل الضريبة والإجمالي شاملًا الضريبة والمبلغ المستحق. نسبة الضريبة القياسية 15% تظهر في وسم فرعي لكل بند خاضع، مع رمز فئة الضريبة. إليك مقطعًا مبسّطًا للإجماليات:

<cac:TaxTotal>
  <cbc:TaxAmount currencyID="SAR">15.00</cbc:TaxAmount>
</cac:TaxTotal>
<cac:LegalMonetaryTotal>
  <cbc:TaxExclusiveAmount currencyID="SAR">100.00</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="SAR">115.00</cbc:TaxInclusiveAmount>
  <cbc:PayableAmount currencyID="SAR">115.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

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

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

إشعار دائن لفاتورة مبسّطة: استرجاع منتج من فرد

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

إشعار الدائن للفاتورة المبسّطة يتبع نفس بنية B2C: نوع فرعي يبدأ بـ 02، رمز QR إلزامي، توقيع تشفيري، وإبلاغ خلال 24 ساعة. الفرق الوحيد أن قيمة المستند في InvoiceTypeCode تصبح 381 بدل 388 لتدلّ على «إشعار دائن».

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

<cbc:InvoiceTypeCode name="0211010">381</cbc:InvoiceTypeCode>
<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <cbc:ID>INV-2026-00451</cbc:ID>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>

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

جاهزية منشأتك تقنيًا لإصدار فواتير B2C

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

• نظام معتمد: تأكد أن نظامك يولّد UBL 2.1 ويوقّع بشهادة CSID. الأنظمة القديمة التي تطبع PDF فقط لا تكفي للمرحلة الثانية.
• تسجيل الشهادة: سجّل شهادة CSID لدى الهيئة عبر منصة فاتورة. هذه خطوة لمرة واحدة لكل جهاز أو نقطة إصدار.
• اختبار في بيئة المحاكاة: جرّب إصدار فواتير في بيئة المحاكاة قبل الإنتاج، للتأكد من قبول البنية دون مخاطرة على بياناتك الحقيقية.
• إدارة الطابور دون اتصال: تحقّق أن نظامك يستمر في الإصدار عند انقطاع الإنترنت، ويبلّغ لاحقًا ضمن المهلة.
• مراقبة حالة الفواتير: اعتمد لوحة تعرض حالة كل فاتورة: موقَّعة، في الطابور، مبلَّغ عنها، مقبولة.

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

الأخطاء الشائعة في بناء فاتورة B2C

من واقع التوثيق التقني، تتكرّر أخطاء محدّدة عند فرق التطوير التي تبني مولّد فواتير مبسّطة لأول مرة:

• ضبط النوع الفرعي خطأً: وضع 01 بدل 02 يوجّه الفاتورة لمسار المقاصة فتُرفَض. تحقّق من الخانة الأولى في سمة name.
• توليد QR قبل التوقيع: رمز QR يحوي التوقيع، فلا يمكن بناؤه قبل توقيع الفاتورة. الترتيب الصحيح: وقّع أولًا ثم ابنِ TLV.
• كسر سلسلة التجزئة: إهمال ربط الفاتورة بتجزئة سابقتها يكسر السلسلة ويُبطل التحقّق. حافظ على تسلسل صارم.
• كتابة CCSI بدل CSID: خطأ تسمية شائع يربك التوثيق. الاختصار الصحيح دائمًا CSID.
• تجاوز مهلة الإبلاغ: ترك الفواتير في الطابور أكثر من 24 ساعة يعرّض المنشأة للمخالفة. راقب عمر كل فاتورة في الطابور.

كل خطأ من هذه يختفي عمليًا حين يتولّى نظام محاسبي معتمد توليد البنية بدلًا من بنائها يدويًا. هذا بالضبط ما يقدّمه قيود.

كيف يتولّى قيود بنية فاتورة B2C بالكامل

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

بعدها يتولّى قيود الطبقة التشفيرية كاملة: يسنِد UUID، ويحسب التجزئة ويربطها بالسلسلة، ويوقّع الفاتورة بشهادة CSID المُدارة تلقائيًا، ويبني رمز QR بصيغة TLV ويرمّزه. كل هذا يحدث خلف نقطة البيع في أجزاء من الثانية.

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

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

إذا أردت إصدار فواتير B2C متوافقة دون أن تبني مولّد XML بنفسك، ابدأ من هنا:

أسئلة شائعة عن فواتير B2C تقنيًا

ما القيمة التي تحملها فاتورة B2C في حقل النوع الفرعي؟

تبدأ سمة name في وسم InvoiceTypeCode بالخانتين 02 لتدلّ على فاتورة مبسّطة، بينما تبقى قيمة الوسم نفسها 388 لأنها «فاتورة». الفاتورة القياسية للمنشآت تبدأ سمتها بـ 01.

هل يجب أن أضع الرقم الضريبي للمشتري في فاتورة الأفراد؟

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

متى تُسلَّم فاتورة B2C للعميل؟

تُسلَّم فورًا لحظة الإصدار دون انتظار أي رد من منصة فاتورة. هذا يختلف عن الفاتورة القياسية التي تمرّ بالمقاصة قبل التسليم. تفاصيل المقارنة في دليل المقاصة.

كم المهلة لإرسال فاتورة B2C إلى المنصة؟

المهلة 24 ساعة من لحظة الإصدار. تظل الفاتورة سارية وصالحة طوال هذه النافذة، والالتزام هو إرسال نسختها للمنصة خلالها. التفاصيل الكاملة في دليل الإبلاغ.

هل رمز QR إلزامي على إيصال الأفراد؟

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

ما الاختصار الصحيح لشهادة الختم التشفيري؟

الاختصار الصحيح هو CSID، اختصارًا لـ Compliance Cryptographic Stamp Identifier. تُكتب أحيانًا خطأً CCSI. اعتمد CSID دائمًا في التوثيق. مزيد من التفاصيل في دليل شهادة CSID.