وحدة توليد الفواتير EGS

عند ربط نظامك المحاسبي بمنصة فاتورة، تتعامل هيئة الزكاة والضريبة والجمارك (ZATCA) مع كل جهاز يصدر فواتير على أنه «وحدة توليد فواتير» مستقلة. هذه الوحدة هي ما يُعرف في المواصفة التقنية باسم E-invoice Generation Solution، واختصارها EGS. فهم هذه الوحدة هو حجر الأساس لأي تكامل صحيح مع المرحلة الثانية من الفوترة الإلكترونية، لأن كل ما يأتي بعدها (الشهادة، العدّاد، سلسلة التجزئة، التهيئة) مبني عليها.

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

ما هي وحدة توليد الفواتير EGS؟

وحدة توليد الفواتير (EGS Unit) هي أي مكوّن برمجي أو جهاز قادر على إنشاء فاتورة إلكترونية متوافقة مع مواصفة الهيئة، وتوقيعها، وإرسالها إلى منصة فاتورة. المصطلح لا يصف برنامجًا واحدًا كبيرًا، بل يصف كل «نقطة إصدار» على حدة داخل منشأتك.

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

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

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

الفرق بين الحلّ والوحدة

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

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

لماذا يُعدّ كل جهاز أو نقطة بيع أو فرع وحدة EGS مستقلة؟

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

أولًا: الشهادة الخاصة بكل وحدة (CSID)

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

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

ثانيًا: العدّاد التسلسلي المستقل (ICV)

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

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

ثالثًا: سلسلة التجزئة المستقلة (PIH)

تربط كل وحدة فواتيرها في سلسلة عبر قيمة تجزئة الفاتورة السابقة PIH. كل فاتورة تحمل بصمة (hash) للفاتورة التي سبقتها داخل نفس الوحدة. أول فاتورة في الوحدة تستخدم قيمة ابتدائية متفقًا عليها، ثم تبني كل فاتورة بصمتها فوق سابقتها.

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

خلاصة هذه العناصر الثلاثة: الشهادة تحدّد «من أصدر»، والعدّاد يحدّد «الترتيب»، وسلسلة التجزئة تحدّد «التتابع السليم». الثلاثة معًا لا تعمل إلا داخل حدود وحدة واحدة، ولهذا يجب أن يكون كل جهاز وحدة قائمة بذاتها.

كيف تحصل كل وحدة على هويتها الخاصة؟

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

المرحلة الأولى: طلب الشهادة المبدئية

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

POST /compliance
Headers:
  OTP: 123456
  Accept-Version: V2
  Content-Type: application/json
Body:
{
  "csr": "<base64-encoded-CSR>"
}

Response 200:
{
  "requestID": 1234567890,
  "binarySecurityToken": "<base64 compliance CSID>",
  "secret": "<shared secret>"
}

الحقل binarySecurityToken هو شهادة الامتثال المبدئية مرمّزة بصيغة base64، والحقل secret هو السر المشترك الذي تستخدمه الوحدة لاحقًا في المصادقة. تُخزَّن القيمتان بأمان داخل النظام لأنهما مفتاح كل طلب لاحق.

المرحلة الثانية: إصدار الشهادة التشغيلية

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

POST /production/csids
Headers:
  Authorization: Basic <base64(compliance_token:secret)>
  Accept-Version: V2
  Content-Type: application/json
Body:
{
  "compliance_request_id": "1234567890"
}

Response 200:
{
  "requestID": 9876543210,
  "binarySecurityToken": "<base64 production CSID>",
  "secret": "<production shared secret>"
}

الناتج هنا هو شهادة الإنتاج (Production CSID) الخاصة بهذه الوحدة وحدها. من هذه اللحظة تصبح الوحدة مهيأة بالكامل: لها شهادة توقّع بها، وعدّاد تبدؤه من واحد، وقيمة تجزئة ابتدائية تبني فوقها سلسلتها. تفاصيل هذه الخطوة الكاملة موثّقة في صفحة التهيئة والربط (Onboarding) مع منصة فاتورة.

بنية بيانات الوحدة بعد التهيئة

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

{
  "egs_unit_id": "POS-RIYADH-01",
  "vat_number": "300000000000003",
  "branch_name": "Riyadh Main Branch",
  "production_csid": "<base64 certificate>",
  "private_key_ref": "keystore://egs/pos-riyadh-01",
  "secret_ref": "vault://egs/pos-riyadh-01/secret",
  "icv": 0,
  "pih": "NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZj79..."
}

القيمة icv تبدأ من صفر وتزيد مع كل فاتورة، والقيمة pih تبدأ بالقيمة الابتدائية المتفق عليها ثم تتغير مع كل فاتورة جديدة. أما private_key_ref وsecret_ref فيشيران إلى مخزن آمن، إذ لا يجوز إطلاقًا تخزين المفتاح الخاص أو السر بشكل صريح داخل قاعدة البيانات.

كيف تُسجَّل وحدات EGS وتُهيّأ؟

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

الخطوة الأولى: توليد رمز التفعيل من بوابة فاتورة

يدخل المكلّف إلى بوابة فاتورة عبر حسابه في الهيئة، ويختار خيار توليد رمز تفعيل (OTP) لكل وحدة يريد تسجيلها. يمكن توليد عدة رموز دفعة واحدة عند تسجيل أجهزة كثيرة. كل رمز صالح لمدة محدودة، لذا يُستخدم فور توليده.

الخطوة الثانية: إدخال الرمز في النظام المحاسبي

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

الخطوة الثالثة: اجتياز فحوص الامتثال

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

POST /compliance/invoices
Headers:
  Authorization: Basic <base64(compliance_token:secret)>
  Accept-Version: V2
Body:
{
  "invoiceHash": "<sha256 base64>",
  "uuid": "3cf5ee18-ee25-44ea-a444-2c37ba7f28be",
  "invoice": "<base64 signed XML>"
}

Response 200:
{
  "validationResults": {
    "status": "PASS",
    "warningMessages": [],
    "errorMessages": []
  }
}

عند ظهور "status": "PASS" لكل نوع مطلوب، تجتاز الوحدة الفحص وتنتقل لطلب شهادة الإنتاج. أي رسالة في errorMessages توقف العملية حتى تُصحَّح بنية المستند أو التوقيع.

الخطوة الرابعة: بدء الإصدار الفعلي

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

إعداد عدة وحدات (Multi-unit Setups)

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

القاعدة: وحدة لكل نقطة إصدار

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

أنماط شائعة للتعدّد

هناك نمطان رئيسيان لتوزيع الوحدات على المنشأة:

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

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

إدارة دورة حياة الوحدات

التعدّد يفرض إدارة مستمرة لا تنتهي عند التهيئة. ثلاث مهام تتكرر:

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

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

ثالثًا، إيقاف وحدة عند سحب جهاز من الخدمة. تُحفظ سجلات الوحدة المتوقفة كاملةً للرجوع إليها عند أي مراجعة، ولا يُعاد استخدام معرّفها لجهاز آخر تفاديًا للالتباس.

أخطاء متكررة في إعداد عدة وحدات

من أكثر الأخطاء التي ترفضها المنصة:

مشاركة شهادة واحدة بين جهازين، فتبدو الفواتير وكأنها من مصدر واحد. والحل أن لكل جهاز شهادته.

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

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

آلية التوقيع داخل الوحدة خطوة بخطوة

التوقيع هو قلب عمل وحدة EGS، وفهمه يوضّح لماذا تحتاج كل وحدة هويتها المستقلة. عند إنشاء أي فاتورة، تمرّ الوحدة بسلسلة عمليات ثابتة تنتهي بمستند موقّع جاهز للإرسال.

أولًا، تبني الوحدة مستند الفاتورة بصيغة XML وفق مواصفة UBL، وتضمّن فيه بيانات البائع والمشتري والبنود ومبالغ الضريبة. ثانيًا، تحسب بصمة (hash) للمستند بخوارزمية SHA-256، وهذه البصمة تمثّل الفاتورة تمثيلًا فريدًا، فأي تغيير بحرف واحد يغيّرها بالكامل. ثالثًا، توقّع الوحدة هذه البصمة بمفتاحها الخاص المرتبط بشهادتها، فينتج توقيع رقمي يثبت أن هذه الوحدة بالذات أصدرت الفاتورة. رابعًا، تُدمج قيمة تجزئة الفاتورة السابقة (PIH) ورقم العدّاد (ICV) داخل المستند، فتنضمّ الفاتورة إلى سلسلة الوحدة.

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

# تمثيل مبسّط لتسلسل التوقيع داخل وحدة EGS
1. xml      = build_ubl_invoice(seller, buyer, lines, vat)
2. hash     = sha256_base64(canonicalize(xml))
3. signature= sign(hash, unit.private_key)   # ربط بالشهادة
4. xml      = embed(xml, icv=unit.icv + 1, pih=unit.pih, signature=signature)
5. qr       = build_qr(seller, vat_number, timestamp, total, vat, hash, signature)
6. unit.icv = unit.icv + 1
7. unit.pih = hash      # تصبح بصمة هذه الفاتورة مرجعًا للتالية

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

الفرق بين مسار B2B ومسار B2C داخل الوحدة

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

الفاتورة القياسية (B2B): اعتماد قبل التسليم

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

POST /invoices/clearance/single
Headers:
  Authorization: Basic <base64(production_csid:secret)>
  Clearance-Status: 1
  Accept-Version: V2
Body:
{
  "invoiceHash": "<sha256 base64>",
  "uuid": "<invoice uuid>",
  "invoice": "<base64 signed XML>"
}

Response 200:
{
  "clearanceStatus": "CLEARED",
  "clearedInvoice": "<base64 cleared XML>"
}

الفاتورة المبسّطة (B2C): تسليم فوري ثم إبلاغ

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

POST /invoices/reporting/single
Headers:
  Authorization: Basic <base64(production_csid:secret)>
  Clearance-Status: 0
  Accept-Version: V2
Body:
{
  "invoiceHash": "<sha256 base64>",
  "uuid": "<invoice uuid>",
  "invoice": "<base64 signed XML>"
}

Response 200:
{
  "reportingStatus": "REPORTED"
}

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

التهيئة في بيئات دون اتصال دائم

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

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

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

دور النظام المحاسبي في تبسيط وحدات EGS

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

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

مثال تطبيقي: سلسلة تجزئة بثلاثة فروع

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

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

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

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

اعتبارات الحوكمة والامتثال للوحدات

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

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

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

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

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

الأسئلة الشائعة

هل كل نقطة بيع تُعدّ وحدة EGS مستقلة؟
نعم. كل جهاز ينشئ الفاتورة ويوقّعها محليًا يُعامَل وحدةً مستقلة، له شهادته وعدّاده وسلسلة تجزئته، حتى لو كانت كل الأجهزة تحت نفس الرقم الضريبي.

هل يمكن أن تتشارك وحدتان نفس شهادة CSID؟
لا. الشهادة تميّز الجهاز الذي أصدر الفاتورة، ومشاركتها بين وحدتين تكسر منطق التتبع لدى المنصة وتُرفض في التحقق.

من أين تبدأ قيمة العدّاد ICV في الوحدة الجديدة؟
تبدأ من واحد عند أول فاتورة، وتزيد بمقدار واحد مع كل فاتورة لاحقة دون انقطاع ودون تكرار داخل الوحدة نفسها.

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

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

هل تسجيل عدة فروع يحتاج عدة رموز تفعيل؟
نعم. يُولّد المكلّف رمز تفعيل لكل وحدة يريد تسجيلها من بوابة فاتورة، ويمكن توليد عدة رموز دفعة واحدة عند تسجيل أجهزة كثيرة.