يجعلكم الإلزام مستقبِلين كما يجعلكم مُصدِرين، وهنا يقع آخر قرارين تشغيليين في هذه الوحدة: ماذا يفعل النظام بمستند المورّد، ومن يُسمح له بحمل بيانات الاعتماد التي يسافر بها المستند. والجواب واحد في الحالتين، وهو جواب الدرس 1.

عندما يستقبل الإجراء المجدول الوارد (أو الـ webhook الاختياري) مستنداً، تُنشئ الوحدة فاتورة مورّد مسوّدة من ملف XML. ولا تُرحَّل تلقائياً أبداً. فتراجعونها وترحّلونها كالمعتاد، تماماً كفاتورة وصلت بالبريد الإلكتروني.

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

ومسار النقر. يفعّل مدير UAE E-Invoice: Fetch inbound documents من الإعدادات ← تقني ← الإجراءات المجدولة (Settings → Technical → Scheduled Actions). ثم تظهر الفواتير مسوّداتٍ في المحاسبة ← الموردون ← الفواتير (Accounting → Vendors → Bills)، ويكون المستند الذي جاءت منه في E-Invoice Documents مع مرشّح Inbound، حيث يعطيكم View XML النسخة الأصلية التي أرسلها المورّد فعلاً.

ومراجعة محسوبة. تصل فاتورة واردة من مورّد: صافٍ 12,000 درهم، وضريبة قيمة مضافة بنسبة 5% قدرها 600 درهم، وإجمالي 12,600 درهم. تحقّقوا من ثلاثة أمور وتكونون قد أدّيتم المهمة: الرقم الضريبي للمورّد مقابل سجل جهة الاتصال لديكم، والإجماليات مقابل أمر الشراء وإشعار الاستلام، والمعالجة الضريبية مقابل طبيعة التوريد فعلاً. ولنفترض أن إشعار الاستلام لا يدعم سوى 11,000 درهم صافياً — إذ سُلِّم أحد السطور ناقصاً — فتكون الفاتورة التي تقبلونها 11,550 درهماً شاملة 550 درهماً ضريبة. أنتم لا تعدّلون مستند المورّد ليتطابق. فملفه غير قابل للتعديل لديه تماماً كما هو لديكم؛ بل تراجعونه في الفرق البالغ 1,000 درهم ويصدر هو إشعاراً دائناً، فيصل بوصفه مستنداً وارداً مستقلاً. والتناظر هو المقصود: ما لا تستطيعون فعله بمستنداتكم المرسَلة لا تستطيعون فعله بمستنداتهم.

والآن الصلاحيات، وهي النصف الآخر من تشغيل هذا بأمان. تُعرّف الوحدة صلاحية UAE E-Invoicing بمجموعتين.

وحقول المزوّد السرّية تظهر للمديرين فقط — مفتاح API وسرّه ومعرّف العميل وسرّ الـ webhook. والمنطق هو المنطق نفسه الذي يسري في هذه الدورة كلها. فتلك البيانات هي الهوية التي ترسل منشأتكم تحتها، وكل ما يُرسل بها ينتج مستندات غير قابلة للتعديل ومبلَّغة إلى الهيئة بوصفها مستنداتكم. وفي المقابل لا يحتاج أحد إلى رؤية السرّ لأداء العمل اليومي: فمجموعة User تستطيع التوليد والتحقق والإرسال وإعادة المحاولة وقراءة حساب المزوّد، وهذا كل ما يلمسه من يشغّل الفحص الصباحي. وتُقيَّد المستندات وحسابات المزوّد إضافةً إلى ذلك لكل شركة عبر قواعد السجلات، فلا تتحول قاعدة بيانات مشتركة إلى صندوق صادر مشترك.

وطرق الفشل تُعرف من النظرة الأولى. قائمتا ASP Accounts أو E-Invoice Documents غير موجودتين، أو حقول بيانات الاعتماد مخفية — المستخدم ليس في المجموعة الصحيحة؛ فيمنحه مدير النظام UAE E-Invoicing ← User، أو Manager حيث تكون بيانات الاعتماد وإدارة الحسابات مطلوبة فعلاً. ولا يصل أي مستند وارد أبداً — إجراء الجلب ما زال معطّلاً، ولا يفعّله إلا مدير. قرّروا الآن من هم الأشخاص المسمّون الذين يحملون Manager، وضعوهم في دليل التشغيل إلى جانب الإجراءات المجدولة التي يملكونها، وأبقوا القائمة قصيرة. ولا يصف الدليل إجراءً لتدوير بيانات الاعتماد، فاتفقوا عليه مع مزوّدكم وضعوه في تقويمكم بأنفسكم.

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