دليل حزمة التطوير SDK

إذا كنت مطوّرًا تبني تكاملًا مع منصة فاتورة (Fatoora)، فأمامك طريقان: أن تستدعي واجهات الـ API الخام بنفسك، أو أن تستعين بحزمة تطوير (SDK) تختصر عليك جزءًا كبيرًا من العمل المتكرّر. هذه الصفحة تشرح ما الذي تقدّمه حزمة التطوير في سياق الفوترة الإلكترونية، وكيف تختار واحدة وتثبّتها، وكيف يبدو مثال مبسّط للتهيئة وإصدار أول فاتورة، ومتى يكون استخدام SDK أفضل من الـ API الخام، وكيف تبني غلافك الخاص إن لم تجد حزمة جاهزة تناسبك.

نتحدّث هنا بلغة عامة عن مفهوم الـ SDK، لا عن حزمة رسمية محدّدة باسمها. قيود يوفّر واجهة API للتكامل، لكن التركيز في هذه الصفحة على المبدأ: كيف تغلّف طبقة الـ API المعقّدة (المصادقة، وبناء الـ XML، والتوقيع، واستدعاء الواجهات) خلف دوال بسيطة تستدعيها من شيفرتك. الهدف أن تخرج وأنت تعرف متى توفّر الحزمة وقتك فعلًا، ومتى يكون بناؤها أو الاستغناء عنها أحكم.

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

ما هي حزمة التطوير (SDK) ولماذا تحتاجها؟

حزمة التطوير (Software Development Kit) مجموعة من المكتبات والأدوات الجاهزة بلغة برمجة معيّنة، تغلّف التعامل مع واجهة API خلف دوال واضحة. بدلًا من أن تكتب طلب HTTP يدويًا، وتبني ترويساته، وتوقّع حمولته، وتفسّر استجابته الخام، تستدعي دالة واحدة باسم مفهوم مثل «أصدر فاتورة» فتتكفّل الحزمة بالباقي خلف الكواليس.

الفائدة الجوهرية أن الحزمة تنقل التعقيد من شيفرتك إلى داخلها. التعامل مع الفوترة الإلكترونية يتطلّب خطوات تقنية دقيقة: توليد الختم التشفيري (Cryptographic Stamp)، وحساب بصمة (Hash) الفاتورة السابقة لضمان سلامة السلسلة، وبناء ملف XML بصيغة UBL المعتمدة، وإدارة شهادة CSID. الحزمة المصمّمة جيدًا تخفي هذه الخطوات وراء واجهة بسيطة، فتكتب أنت منطق عملك لا منطق التشفير.

تتلخّص قيمة الحزمة في أربعة أمور تختصرها نيابة عنك. تتولّى المصادقة وإدارة الرموز (Tokens) وتجديدها. تبني ملف الـ XML من بيانات الفاتورة دون أن تكتب وسومه يدويًا. توقّع الفاتورة وتُلحق بها البصمة و رمز QR. وأخيرًا تستدعي الواجهة الصحيحة (مقاصة أو إبلاغ) وتعيد لك النتيجة بصيغة جاهزة للقراءة. هذه الطبقات الأربع هي ما يستهلك معظم وقت بناء التكامل من الصفر.

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

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

ماذا تغلّف الحزمة بالضبط؟

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

1. المصادقة وإدارة الرموز

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

2. بناء ملف XML

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

3. التوقيع والبصمة و رمز QR

كل فاتورة يجب أن تحمل ختمًا تشفيريًا، ومعرّفًا فريدًا (UUID)، وبصمة للفاتورة السابقة، و رمز QR مبنيًا وفق صيغة TLV المعتمدة. هذه أكثر الخطوات حساسية وأصعبها على من يبنيها أول مرة. الحزمة تتولّاها كاملة بعد بناء الـ XML مباشرة، فلا تتعامل أنت مع تفاصيل التشفير منخفض المستوى.

4. استدعاء الواجهة الصحيحة

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

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

كيف تختار حزمة تطوير مناسبة؟

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

أول معيار هو اللغة والتوافق. تأكّد أن الحزمة مكتوبة للّغة التي يعمل بها مشروعك (PHP، أو Python، أو Node.js، أو غيرها)، وأنها تدعم إصدار اللغة الذي تستخدمه. حزمة مكتوبة لإصدار قديم قد تعطّل ترقية مشروعك لاحقًا، فهذا المعيار يوازن بين الراحة الآنية والمرونة المستقبلية.

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

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

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

تثبيت الحزمة وتهيئتها

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

# PHP (Composer)
composer require vendor/einvoice-sdk

# Node.js (npm)
npm install einvoice-sdk

# Python (pip)
pip install einvoice-sdk

بعد التثبيت تهيّئ الحزمة ببيانات الاعتماد الخاصة بك: عنوان القاعدة (Base URL) للبيئة التي تعمل عليها، وشهادة CSID، والمفتاح السرّي. القاعدة الذهبية أن تبدأ دائمًا من بيئة المحاكاة (Sandbox)، وألّا تضع بيانات الإنتاج في شيفرتك مباشرة، بل في متغيّرات بيئة (Environment Variables) معزولة. فيما يلي مثال تهيئة مبسّط بلغة PHP.

<?php
require 'vendor/autoload.php';

use Vendor\EInvoice\Client;

// التهيئة على بيئة المحاكاة
$client = new Client([
    'environment' => 'sandbox',          // sandbox | production
    'csid'        => getenv('FATOORA_CSID'),
    'secret'      => getenv('FATOORA_SECRET'),
]);

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

مثال عملي: إصدار أول فاتورة

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

// بناء بيانات الفاتورة
$invoice = [
    'type'     => 'standard',          // standard (B2B) | simplified (B2C)
    'customer' => [
        'name' => 'شركة المثال التجارية',
        'vat'  => '300000000000003',
    ],
    'items' => [
        [
            'description' => 'خدمة استشارية',
            'quantity'    => 1,
            'price'       => 1000.00,
            'vat_rate'    => 15,        // 15%
        ],
    ],
];

// استدعاء واحد يتكفّل بكل الطبقات
$result = $client->issueInvoice($invoice);

if ($result->isCleared()) {
    echo 'تم اعتماد الفاتورة: ' . $result->getUuid();
} else {
    echo 'رُفضت الفاتورة: ' . $result->getErrorMessage();
}

الفكرة التي يجب أن تستوعبها من هذا المثال أن الحزمة لا تلغي حوار الخطوتين مع منصة فاتورة، بل تخفيه. الفاتورة ما زالت تُرسَل ثم تُراجَع ثم تُعتمد أو تُرفَض، لكنك تتعامل مع نتيجة جاهزة عبر دالتَي isCleared() و getErrorMessage() بدل تفسير الاستجابة الخام بنفسك.

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

متى تستخدم حزمة جاهزة ومتى تتعامل مع الـ API الخام؟

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

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

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

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

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

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

بناء غلافك الخاص (Wrapper) حول الـ API

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

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

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

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

انتبه مع ذلك إلى أن الغلاف الخاص يحمّلك مسؤولية لا تنتهي عند الكتابة الأولى. أنت من يتابع تحديثات منصة فاتورة ويطبّقها على غلافك، وأنت من يكتب اختبارات تغطّي حالاته، وأنت من يصلح أعطاله. لذلك لا تبنِ غلافًا إلا إذا كنت مستعدًا لصيانته على المدى الطويل. الغلاف المهمَل أسوأ من الـ API الخام، لأنه يخفي تعقيدًا توقّف عن العمل دون أن تدري.

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

الاختبار في بيئة المحاكاة قبل الإنتاج

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

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

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

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

الأخطاء الشائعة عند استخدام الحزم

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

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

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

أين يقع قيود في هذه الصورة؟

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

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

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

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