XBRL ببساطة: ليش الوزارة تبي صيغة خاصة بدل PDF؟
ملف الـ PDF يقرأه الإنسان ولا يفهمه الحاسب. رقم «321.000» في مستند PDF مجرد حبر: لا يعرف النظام هل هو إيراد أم مصروف، ولا لأي سنة يعود. XBRL تحل هذه المشكلة بأن تلصق بكل رقم بطاقة تعريف تقول ما هو ولأي فترة.
التاكسونومي: قاموس المصطلحات
التاكسونومي قائمة معتمدة بأسماء البنود المالية (concepts) مثل Revenue و Inventories و ProfitLoss. عندما تكتب رقم مبيعاتك، تربطه بالمفهوم Revenue من التاكسونومي، فيفهم أي نظام في العالم أن هذا الرقم هو إيراد. معظم الدول تبني تاكسونوميتها على تاكسونومي المعايير الدولية IFRS مع إضافات محلية عند الحاجة.
context: لأي فترة يعود الرقم؟
هنا يقع أكثر الأخطاء شيوعاً. بنود قائمة الدخل (مبيعات، مصاريف، صافي ربح) تخص فترة ممتدة: من 1 يناير إلى 31 ديسمبر — وتسمى duration. أما بنود المركز المالي (رصيد البنك، المخزون، رأس المال) فتخص لحظة واحدة: 31 ديسمبر — وتسمى instant. خلط النوعين يجعل الملف غير صالح حتى لو كانت كل الأرقام صحيحة.
unit و decimals
كل مبلغ يحتاج وحدة عملة — عندنا iso4217:KWD — وعدد الخانات العشرية. الدينار الكويتي يُكتب بثلاث خانات لأن الدينار = 1000 فلس، فتظهر القيمة هكذا: 321.000. هذا سبب إصرارنا على التعامل مع كل المبالغ بالفلس كأعداد صحيحة داخلياً: أي كسر عشري في منتصف الحسابات يولّد فرق تقريب يكسر الترابط الحسابي في الملف.
calculation linkbase: من أين تأتي الإشارات
قواعد الجمع والطرح بين البنود معرّفة في التاكسونومي نفسها، لا في الأرقام. لذلك تُكتب المصاريف بقيم موجبة داخل الملف، وتتكفل قواعد الحساب بطرحها. من يكتب المصاريف بالسالب يضاعف الطرح ويحصل على نتائج لا تتطابق مع المجاميع.
لماذا تُرفض الملفات؟
- الأصول لا تساوي الالتزامات + حقوق الملكية ولو بفلس واحد.
- مجموع معلن لا يطابق تفاصيل بنوده.
- استخدام context خاطئ للبند (لحظة بدل فترة أو العكس).
- رقم هوية المنشأة أو الفترة ناقص أو غير مطابق.
- غياب عمود المقارنة للسنة السابقة.
الخبر الجيد أن هذه الأخطاء ميكانيكية بالكامل: لو صحّ القالب مرة، صحّ دائماً. لهذا نبني الملف من قالب واحد مُتحقَّق منه بدلاً من تجميعه يدوياً في كل مرة.
نُعِدّ ونُحوّل، ولا نُدقّق ولا نُودع. يعتمدها مدقق مرخّص وفق قانون الشركات 1/2016.
