تاريخ التسليم في ZUGFeRD وXRechnung (BT-72): النقل الصحيح والتصحيح
تضع كثير من أدوات التحويل الآلية تاريخ الفاتورة ببساطة كتاريخ للتسليم – وهذا خطأ. فتاريخ التسليم أو الأداء الفعلي هو حقل مستقل في EN 16931 (BT-72) ويجب أن يعكس اللحظة الحقيقية للتسليم، لا اليوم الذي كُتبت فيه الفاتورة.
> إجابة مختصرة: تاريخ التسليم (BT-72، ويظهر في XML باسم ActualDeliveryDate) هو يوم التسليم أو الأداء الفعلي – وليس تاريخ الفاتورة (BT-2). وقد يختلف الاثنان. يتعرّف TaxLayer على تاريخ التسليم بشكل مستقل من الفاتورة ويتيح مراجعته وتصحيحه قبل الإنشاء.
تاريخ التسليم ليس تاريخ الفاتورة
تحمل كثير من الفواتير تاريخين مختلفين: تاريخ إصدار الفاتورة، وتاريخ التسليم أو الأداء الفعلي. مثال:
| الحقل | المعنى | مثال |
|---|---|---|
| BT-2 تاريخ الفاتورة | تاريخ إصدار الفاتورة | 24.08.2026 |
| BT-72 تاريخ التسليم/الأداء | يوم التسليم الفعلي | 21.08.2026 |
إذا مُلئ تاريخ التسليم خطأً بتاريخ الفاتورة، فإن الفاتورة الإلكترونية تكون صحيحة شكليًا لكنها غير صحيحة من حيث المضمون – مع تبعات على القيد المحاسبي ولحظة الأداء وضريبة القيمة المضافة.
ما الذي يتطلبه EN 16931
يعرف EN 16931 تاريخ التسليم الفعلي باسم BT-72. وفي كلتا الصياغتين يبدو الأمر كالتالي:
- ZUGFeRD / CII:
ram:ApplicableHeaderTradeDelivery → ram:ActualDeliverySupplyChainEvent → ram:OccurrenceDateTime - XRechnung / UBL:
cac:Delivery → cbc:ActualDeliveryDate
التنسيق هو تاريخ تقويمي (في CII بصيغة YYYYMMDD، رمز التنسيق 102). وهو يصف لحظة التسليم، بصرف النظر عن تاريخ الفاتورة أو تاريخ الاستحقاق.
الخطأ النموذجي لأدوات التحويل الآلية
كثيرًا ما تقرأ أداة تحويل PDF إلى XML البسيطة بيانات الترويسة الظاهرة فقط وتملأ الحقول الناقصة بقيم افتراضية. وإذا غاب التعرف المستقل على تاريخ التسليم، يُدرَج بدلًا منه تاريخ الفاتورة. وطالما كان التاريخان متطابقين لا يظهر ذلك – وبمجرد اختلافهما يظهر في الفاتورة الإلكترونية ActualDeliveryDate خاطئ.
كيف يحل TaxLayer ذلك
يتعرّف TaxLayer على تاريخ التسليم/الأداء بشكل مستقل ومنفصل عن تاريخ الفاتورة. وفي خطوة المراجعة قبل الإنشاء يُعرض في حقل مستقل باسم تاريخ التسليم ويمكن تصحيحه هناك قبل أن يُنشأ ملف ZUGFeRD أو XRechnung. وبعد ذلك يظهر في ملف XML المُنشأ التاريخ الصحيح باسم ActualDeliveryDate.
وهكذا تبقى مسؤولية الصحة من حيث المضمون لديك – ولا يمكن لخطأ آلي أن يمر أصلًا.
الخلاصة
تاريخ التسليم حقل مستقل إلزامي/عملي في EN 16931 (BT-72) ولا يجوز مساواته عشوائيًا بتاريخ الفاتورة. احرص في كل عملية تحويل على أن يعكس ActualDeliveryDate تاريخ التسليم الفعلي.
---
جرّب TaxLayer مجانًا الآن – يتعرّف تلقائيًا على تاريخ التسليم وأرقام الأصناف والمراجع ويتيح مراجعتها قبل الإنشاء. للأسئلة: info@landauer.de.
الأسئلة الشائعة
ما الفرق بين BT-2 وBT-72؟
BT-2 هو تاريخ الفاتورة (تاريخ الإصدار). أما BT-72 فهو تاريخ التسليم أو الأداء الفعلي – اليوم الذي تم فيه تسليم البضاعة أو تقديم الخدمة. وقد يختلف الاثنان.
ماذا يُسمّى تاريخ التسليم في ملف XML؟
في ZUGFeRD/CII يظهر باسم ActualDeliveryDate (داخل العنصر ram:ActualDeliverySupplyChainEvent)، وفي XRechnung/UBL باسم cbc:ActualDeliveryDate ضمن كتلة التسليم. ودلاليًا كلاهما هو BT-72 وفق EN 16931.
هل تاريخ التسليم إلزامي في الفاتورة الإلكترونية؟
وفق EN 16931 ليس BT-72 إلزاميًا في كل فاتورة، لكنه في الواقع العملي مطلوب كثيرًا – خاصة عندما يختلف تاريخ التسليم عن تاريخ الفاتورة. وفي عمليات التسليم داخل الاتحاد الأوروبي وفي كثير من القطاعات يكون مطلوبًا فعليًا.
لماذا تضع أدوات التحويل غالبًا تاريخ الفاتورة كتاريخ للتسليم؟
لأن كثيرًا من الأدوات لا تتعرف على تاريخ التسليم بشكل مستقل، فتضع بدلًا منه تاريخ الفاتورة. وهذا يؤدي إلى ActualDeliveryDate خاطئ إذا كان التسليم قد تم فعليًا في يوم آخر.
هل يمكنني تصحيح تاريخ التسليم في TaxLayer؟
نعم. يتعرّف TaxLayer على تاريخ التسليم من المستند ويعرضه في خطوة المراجعة كحقل مستقل يمكنك تعديله في أي وقت قبل الإنشاء. تجد مراجع إضافية في أرقام الأصناف في ZUGFeRD.