معمارية التكامل (Integration Architecture)

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

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

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

ما الذي تعنيه «معمارية التكامل» هنا تحديدًا

كثير من المطوّرين يخلط بين «التكامل» بمعنى ربط نظامين، وبين «المعمارية» بمعنى توزيع المسؤوليات بين مكوّنات النظام. في سياق الفوترة الإلكترونية، نقصد بمعمارية التكامل الأمور التالية:

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

الفكرة الحاكمة في كل ما يلي هي فصل الاهتمامات (separation of concerns): يبقى نظام العمل مسؤولًا عن منطق البيع، وتبقى طبقة الامتثال مسؤولة عن صياغة المستند وتوقيعه وإرساله. خلط المسؤوليتين في كود واحد هو السبب الأول لأنظمة فوترة هشّة يصعب صيانتها.

أين تجلس طبقة التوقيع والامتثال

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

• توليد مستند XML متوافق مع معيار UBL 2.1 من بيانات الفاتورة الخام.
• التوقيع التشفيري للمستند باستخدام شهادة CSID المرتبطة بوحدة توليد الفواتير.
• إدارة سلسلة الربط بين الفواتير المتتابعة عبر عدّاد ICV وتجزئة الفاتورة السابقة PIH.

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

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

وحدة EGS لكل جهاز: قرار معماري لا تفصيل ثانوي

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

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

EGS device #1  ──►  CSID #1  ──►  ICV: 1, 2, 3, 4 ...   PIH chain A
EGS device #2  ──►  CSID #2  ──►  ICV: 1, 2, 3, 4 ...   PIH chain B
EGS device #3  ──►  CSID #3  ──►  ICV: 1, 2, 3, 4 ...   PIH chain C

كل وحدة سلسلة مستقلة. لا تشارك العدّاد بين الأجهزة.

ثلاثة أنماط معمارية: مباشر، وسيط، ومزوّد متوافق

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

النمط الأول: التكامل المباشر (Direct Integration)

في هذا النمط يبني فريقك كل شيء داخل نظامك: توليد UBL، والتوقيع، والربط بمنصة فاتورة مباشرة عبر واجهتها البرمجية. نظامك يتحدّث إلى واجهة المقاصة Clearance API وواجهة الإبلاغ Reporting API دون طبقة بينية.

┌──────────────┐      ┌──────────────────┐      ┌─────────────┐
│  نظام العمل  │ ───► │ توليد + توقيع XML │ ───► │ منصة فاتورة │
│ (Sales/POS)  │      │   (داخل نظامك)    │      │  (ZATCA)    │
└──────────────┘      └──────────────────┘      └─────────────┘

متى يناسب: حين يملك فريقك خبرة تشفير عميقة، وتريد تحكّمًا كاملًا، ولديك قدرة على متابعة تحديثات المواصفة الفنية باستمرار.

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

النمط الثاني: الوسيط (Middleware)

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

┌────────────┐
│  نظام ERP  │ ──┐
└────────────┘   │     ┌────────────────────┐      ┌─────────────┐
┌────────────┐   ├──►  │  طبقة وسيطة موحّدة  │ ───► │ منصة فاتورة │
│  نظام POS  │ ──┤     │  توليد + توقيع XML │      │  (ZATCA)    │
└────────────┘   │     └────────────────────┘      └─────────────┘
┌────────────┐   │
│ متجر ويب   │ ──┘
└────────────┘

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

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

النمط الثالث: استخدام مزوّد متوافق (مثل قيود)

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

┌──────────────┐      ┌───────────────────────────┐      ┌─────────────┐
│  نظام العمل  │ ───► │  قيود (طبقة امتثال جاهزة)  │ ───► │ منصة فاتورة │
│              │ ◄─── │  UBL + توقيع + ICV + PIH   │ ◄─── │  (ZATCA)    │
└──────────────┘      └───────────────────────────┘      └─────────────┘

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

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

الإصدار غير المتزامن القائم على طابور

السؤال المعماري الثاني بعد «أين تجلس طبقة الامتثال» هو «متى تُصدَر الفاتورة». هنا يبرز الفرق الحاسم بين التصميم المتزامن والتصميم غير المتزامن.

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

في التصميم غير المتزامن القائم على طابور، يفصل النظام بين «تسجيل الفاتورة» و«إرسالها للامتثال». يكتب نظام العمل الفاتورة في طابور (queue) ويردّ على المستخدم فورًا. ثم تسحب خدمة معالجة (worker) الفواتير من الطابور بمعدّل تتحكّم فيه، وتعالج كل فاتورة باستقلالية، وتسجّل النتيجة.

نظام العمل ──► [ طابور الفواتير ] ──► عامل معالجة ──► منصة فاتورة
   (ردّ فوري)                          (معدّل متحكَّم به)

  ┌─ فاتورة 1 ─┐
  ├─ فاتورة 2 ─┤   ◄── يسحبها العامل واحدة تلو الأخرى
  ├─ فاتورة 3 ─┤       باحترام حدود المعدّل
  └─ فاتورة 4 ─┘

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

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

منطق إعادة المحاولة وطابور الرسائل الميتة

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

الأخطاء المؤقّتة تستحقّ إعادة المحاولة. لكن لا تعد المحاولة فورًا في حلقة ضيّقة، لأن ذلك يفاقم الضغط ويستهلك حدّ المعدّل. استخدم تراجعًا أسّيًا (exponential backoff): انتظر ثانية، ثم ثانيتين، ثم أربعًا، وهكذا، مع حدّ أعلى لعدد المحاولات. تفاصيل هذا النمط في منطق إعادة المحاولة (Retry Logic).

المحاولة 1 ──► فشل مؤقّت ──► انتظر 1s
المحاولة 2 ──► فشل مؤقّت ──► انتظر 2s
المحاولة 3 ──► فشل مؤقّت ──► انتظر 4s
المحاولة 4 ──► فشل مؤقّت ──► انتظر 8s
المحاولة 5 ──► تجاوز الحدّ ──► حوّل إلى طابور الرسائل الميتة

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

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

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

فصل الاهتمامات: من يملك ماذا

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

• نظام العمل مصدر الحقيقة لبيانات البيع: المنتجات، الأسعار، العملاء، فئات الضريبة. لا يعرف شيئًا عن التوقيع التشفيري.
• طبقة الامتثال مصدر الحقيقة للمستند المتوافق: توليد UBL، التوقيع، إدارة ICV وPIH. لا تعرف شيئًا عن منطق التسعير أو الخصومات.
• الطابور مسؤول عن الفصل الزمني والمرونة: يحتفظ بالفواتير بين الإنشاء والإرسال، ويتيح إعادة المحاولة.
• طبقة المراقبة مسؤولة عن الرؤية: تسجّل كل فاتورة وحالتها، وتنبّه حين يمتلئ طابور الرسائل الميتة.

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

التوافر العالي وبيئات التشغيل

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

ثلاثة مبادئ عملية تحقّق ذلك. أولًا، تكرار العامل (worker redundancy): شغّل أكثر من عامل معالجة، فلو سقط واحد استمرّ الآخرون في سحب الطابور. ثانيًا، الطابور المعمّر (durable queue): اجعل الطابور يكتب على قرص دائم، فلو أُعيد تشغيل الخدمة لم تضِع الفواتير غير المعالَجة. ثالثًا، عزل البيئات: لا تختبر على الإنتاج أبدًا.

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

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

كيف تختار النمط المناسب لمنشأتك

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

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

السؤال الثاني: كم مصدر فواتير لديك؟ لو كان لديك نظام واحد فقط يصدر الفواتير، فالتكامل المباشر معقول. لكن لو تعدّدت المصادر (مبيعات، نقطة بيع، متجر إلكتروني، تطبيق جوّال)، فالوسيط يوفّر عليك تكرار منطق الامتثال في كل نظام.

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

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

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

عدم القابلية للتكرار (Idempotency) والرقابة

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

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

إنشاء الفاتورة ──► توليد UUID ثابت ──► تخزينه مع الفاتورة
   │
   ├─ محاولة 1: أرسل UUID ──► نجح ولكن ضاع الردّ
   └─ محاولة 2: أرسل UUID نفسه ──► «سبق معالجتها» ──► أعد النتيجة المخزّنة
                                       (لا توليد مستند جديد)

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

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

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

كيف يساعدك قيود

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

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

جرّب قيود مجانًا لمدة 14 يومًا، بدون بطاقة ائتمان.

أسئلة شائعة

هل قيود نظام ERP يحلّ محلّ نظامي الحالي؟

لا. قيود نظام محاسبي متكامل يوفّر طبقة فوترة إلكترونية متوافقة مع المرحلة الثانية. حين تملك نظامًا قائمًا، يعمل قيود كطبقة امتثال تستقبل بيانات الفاتورة وتولّد مستند UBL وتوقّعه وتربطه بمنصة فاتورة.

أي نمط معماري أختار: مباشر، أم وسيط، أم مزوّد؟

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

لماذا أحتاج إصدارًا غير متزامن قائمًا على طابور؟

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

ما الفرق بين الخطأ المؤقّت والخطأ الدائم؟

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

ما دور طابور الرسائل الميتة (dead-letter queue)؟

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

لماذا تحتاج كل وحدة EGS عدّاد ICV مستقلًا؟

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