ترميز TLV في رمز الفاتورة

كل فاتورة مبسّطة في السعودية تحمل رمز استجابة سريع (QR) مطبوعًا في زاويتها. خلف هذا الرمز بنية بيانات دقيقة تُعرف باسم ترميز TLV، وهي الصيغة التي فرضتها هيئة الزكاة والضريبة والجمارك (ZATCA) لتغليف حقول الفاتورة قبل تحويلها إلى نص يقرأه أي تطبيق هاتف. هذا الدليل التقني يشرح بنية البايتات في TLV: كيف يتكوّن كل حقل من وسم (Tag) وطول (Length) وقيمة (Value)، وكيف تتجمّع هذه الحقول ثم تُرمَّز بصيغة Base64 لتُحقن داخل رمز QR. الهدف أن يخرج المطوّر أو المحاسب التقني بفهم كامل لطريقة بناء المحتوى الذي يقف وراء كل رمز على الفاتورة.

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

ما المقصود بترميز TLV؟

اختصار TLV يعني Tag-Length-Value، أي «وسم، طول، قيمة». هي صيغة ترميز ثنائية (binary) معروفة منذ عقود في بطاقات الدفع ومعايير الاتصالات، واختارتها الهيئة لتغليف حقول الفاتورة داخل رمز الاستجابة السريع. الفكرة بسيطة: بدلًا من كتابة الحقول كنص حر يصعب تحليله، يُغلَّف كل حقل في ثلاثة أجزاء متتابعة:

• الوسم (Tag): رقم يحدّد نوع الحقل (اسم البائع، رقم التسجيل الضريبي، وهكذا).
• الطول (Length): عدد البايتات التي تشغلها القيمة التي تلي الطول مباشرة.
• القيمة (Value): المحتوى الفعلي للحقل، مرمَّزًا بصيغة UTF-8.

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

هذا ما يجعل TLV مناسبًا لرمز QR: صيغة مدمجة، لا لبس فيها، وقابلة للتحليل آليًا على أي جهاز دون الحاجة إلى اتصال بالإنترنت. لفهم رمز QR نفسه ودوره الكامل على الفاتورة، راجع دليل رمز الاستجابة السريع (QR) على الفاتورة الإلكترونية.

بنية البايت في TLV: تشريح الحقل الواحد

كل حقل في سلسلة TLV التي اعتمدتها الهيئة للمرحلة الأولى يتكوّن من بنية بايت ثابتة وواضحة. لنفصّل كل جزء على حدة.

الوسم (Tag): بايت واحد

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

• الوسم 1: اسم البائع (Seller name).
• الوسم 2: رقم التسجيل في ضريبة القيمة المضافة (VAT registration number).
• الوسم 3: الطابع الزمني للفاتورة (Timestamp) بصيغة ISO 8601.
• الوسم 4: إجمالي الفاتورة شاملًا الضريبة (Invoice total with VAT).
• الوسم 5: مبلغ ضريبة القيمة المضافة (VAT total).

بما أن الوسم بايت واحد، فإن قيمته تتراوح نظريًا بين 0 و255، وهو مدى يكفي تمامًا لعدد الحقول المطلوبة. المرحلة الثانية تضيف وسومًا أعلى (6 و7 وما بعدهما) للختم التشفيري والمفتاح العام، لكن مبدأ البايت الواحد للوسم يبقى ثابتًا.

الطول (Length): بايت واحد

الطول يلي الوسم مباشرة، ويشغل بايتًا واحدًا أيضًا. قيمته رقم صحيح يساوي عدد البايتات التي تشغلها القيمة التالية بالضبط. مثلًا، إذا كانت قيمة اسم البائع تشغل 12 بايتًا بعد ترميزها UTF-8، فإن بايت الطول يحمل القيمة 12 (أو 0x0C بالنظام الست عشري).

النقطة الدقيقة هنا أن الطول يُحسب على البايتات لا الأحرف. الحرف العربي الواحد في UTF-8 يشغل بايتين عادةً، والرمز التعبيري قد يشغل أربعة. لذلك اسم بائع عربي من ستة أحرف قد يساوي 12 بايتًا في حقل الطول، لا 6. الخلط بين عدد الأحرف وعدد البايتات هو أكثر خطأ يقع فيه من يبني الترميز يدويًا لأول مرة.

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

القيمة (Value): بطول متغيّر

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

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

كيف تتجمّع الحقول في سلسلة واحدة

بعد بناء كل حقل على هيئة ثلاثية «وسم، طول، قيمة»، تُرصّ الحقول الواحد تلو الآخر في سلسلة بايتات متصلة دون أي فاصل بينها. الترتيب المعتمد في المرحلة الأولى هو الوسم 1 ثم 2 ثم 3 ثم 4 ثم 5. السلسلة الناتجة تبدو على هذا النحو المفاهيمي:

[Tag1][Len1][Value1][Tag2][Len2][Value2][Tag3][Len3][Value3][Tag4][Len4][Value4][Tag5][Len5][Value5]

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

هذه السلسلة الثنائية هي «الحمولة» (payload) الخام. هي ليست بعد جاهزة للطباعة داخل رمز QR، لأنها بايتات ثنائية قد تحوي قيمًا غير قابلة للعرض كنص. هنا يأتي دور الخطوة التالية: ترميز Base64.

من TLV إلى Base64: الخطوة الأخيرة قبل رمز QR

سلسلة TLV الثنائية تُمرَّر عبر ترميز Base64 الذي يحوّل البايتات الخام إلى نص من حروف وأرقام آمنة للطباعة والنقل. الناتج نص Base64 واحد هو ما يُحقن فعليًا داخل رمز الاستجابة السريع، فيصبح قابلًا للمسح بأي تطبيق هاتف يدعم QR.

باختصار، المسار الكامل لمحتوى الرمز يمرّ بثلاث محطات:

1. تُبنى حقول الفاتورة كثلاثيات TLV وتُرصّ في سلسلة بايتات واحدة.
2. تُرمَّز السلسلة بصيغة Base64 لتصبح نصًا آمنًا للطباعة.
3. يُحقن نص Base64 داخل رمز QR ويُطبع على الفاتورة.

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

مثال ترميز عملي خطوة بخطوة

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

بيانات الفاتورة الافتراضية:

• اسم البائع: Qoyod
• رقم التسجيل الضريبي: 301234567800003
• الطابع الزمني: 2026-06-24T10:30:00Z
• الإجمالي شامل الضريبة: 115.00
• مبلغ الضريبة: 15.00

الحقل الأول: اسم البائع

الوسم 1، والقيمة Qoyod تشغل 5 بايتات في UTF-8 (كل حرف لاتيني بايت واحد). إذن الطول 5. تركيب الحقل:

Tag    = 01            (هذا الحقل اسم البائع)
Length = 05            (القيمة تشغل 5 بايتات)
Value  = 51 6F 79 6F 64  (الترميز الست عشري لـ Q o y o d)

البايتات الناتجة: 01 05 51 6F 79 6F 64

الحقل الثاني: رقم التسجيل الضريبي

الوسم 2، والقيمة 301234567800003 رقم من 15 خانة، كل خانة بايت واحد في UTF-8، فالطول 15 (أو 0F بالست عشري):

Tag    = 02
Length = 0F            (15 بايتًا)
Value  = ترميز UTF-8 للنص "301234567800003"

البايتات الناتجة: 02 0F 33 30 31 32 33 34 35 36 37 38 30 30 30 30 33

الحقل الثالث: الطابع الزمني

الوسم 3، والقيمة 2026-06-24T10:30:00Z نص بصيغة ISO 8601 يشغل 20 بايتًا، فالطول 20 (أو 14 بالست عشري):

Tag    = 03
Length = 14            (20 بايتًا)
Value  = ترميز UTF-8 للنص "2026-06-24T10:30:00Z"

الحقلان الرابع والخامس: الإجمالي والضريبة

الوسم 4 للإجمالي 115.00 (6 بايتات، الطول 6)، والوسم 5 لمبلغ الضريبة 15.00 (5 بايتات، الطول 5):

Tag    = 04
Length = 06
Value  = ترميز UTF-8 للنص "115.00"
البايتات: 04 06 31 31 35 2E 30 30

Tag    = 05
Length = 05
Value  = ترميز UTF-8 للنص "15.00"
البايتات: 05 05 31 35 2E 30 30

تجميع السلسلة النهائية

نرصّ البايتات الناتجة من الحقول الخمسة بالترتيب في سلسلة واحدة. ثم نمرّر هذه السلسلة عبر Base64 لنحصل على النص النهائي الذي يدخل رمز QR:

سلسلة TLV (مفاهيميًا):
01 05 [Qoyod] 02 0F [VAT] 03 14 [Timestamp] 04 06 [Total] 05 05 [Tax]

       │
       ▼  ترميز Base64

نص Base64 جاهز للحقن في رمز QR

لاحظ أن اسم بائع عربي مثل قيود يتصرّف على نحو مختلف في حساب الطول. الحرف العربي الواحد يشغل بايتين في UTF-8، فكلمة قيود من أربعة أحرف تشغل 8 بايتات لا 4، ويصبح بايت الطول 8 (أو 08 بالست عشري). هذه النقطة بالذات تُكسر أي تطبيق يحسب الطول بعدد الأحرف بدلًا من البايتات.

حساب البايتات بدقة: النظام الست عشري وUTF-8

بناء ترميز TLV صحيح يتطلّب إتقان حساب البايتات، وهنا يلتقي مفهومان: التمثيل الست عشري وترميز UTF-8. القيم في أمثلتنا مكتوبة بالنظام الست عشري (Hexadecimal)، حيث يمثّل كل بايت برقمين من 00 إلى FF. الرقم 0x0C يساوي 12 عشريًا، و0x0F يساوي 15، و0x14 يساوي 20. هذا التمثيل قياسي في بروتوكولات الترميز لأنه يطابق حدود البايت بدقة.

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

خذ الطابع الزمني كمثال. صيغة ISO 8601 الكاملة 2026-06-24T10:30:00Z تتكوّن من محارف لاتينية وأرقام ورموز فصل، كلها بايت واحد لكل محرف، فمجموعها 20 بايتًا. لو استُخدمت صيغة مختلفة بطول مختلف، تغيّر بايت الطول تبعًا لذلك. هذا يؤكّد أن الطول ليس قيمة ثابتة بل يُحسب لكل فاتورة حسب محتواها الفعلي.

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

كيف يقرأ التطبيق سلسلة TLV ويفكّها

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

1. يقرأ البايت الأول ويفسّره كـ وسم، فيعرف نوع الحقل القادم.
2. يقرأ البايت التالي ويفسّره كـ طول، فيعرف كم بايتًا تشغل القيمة.
3. يقرأ من البايتات عددًا يساوي الطول بالضبط، ويفسّرها كـ قيمة بعد فكّ ترميز UTF-8.
4. يعود إلى البايت التالي مباشرة ويعامله كوسم جديد، ويكرّر الدورة حتى نهاية السلسلة.

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

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

لماذا اختارت الهيئة صيغة TLV تحديدًا؟

كان بإمكان الهيئة اختيار صيغ أخرى لتغليف بيانات رمز QR، مثل النص المفصول بفواصل أو صيغة JSON. لكن TLV تفوّقت عليها لأسباب عملية:

• الإحكام (Compactness): رمز QR محدود المساحة. كل بايت زائد يكبّر الرمز ويصعّب مسحه. TLV لا يضيف إلا بايتي تغليف لكل حقل (وسم وطول)، بينما JSON يضيف أقواسًا وعلامات تنصيص وأسماء مفاتيح طويلة.
• انعدام اللبس (Unambiguity): لا يوجد محتوى نصّي قد يتعارض مع فاصل، لأن الطول يحدّد الحدود لا الفاصل. اسم بائع يحوي فاصلة لن يربك القارئ كما يحدث في الصيغ المفصولة.
• سهولة التحليل الآلي: دورة القراءة بسيطة وحتمية، تعمل على أي معالج وأي لغة برمجة دون مكتبات تحليل معقّدة.
• قابلية التوسّع: إضافة حقل جديد لا تكسر القارئات القديمة، لأنها تتخطّى الوسوم المجهولة بأمان.

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

الفرق بين TLV والنص الحر العادي

لتوضيح قيمة TLV، قارن بين تغليف حقلين بصيغة نص حر مفصول بفاصلة، وتغليفهما بصيغة TLV:

نص حر مفصول:
Qoyod,301234567800003

المشكلة: لو احتوى اسم البائع على فاصلة (Qoyod, LLC)
انهار التحليل لأن القارئ لا يعرف أين ينتهي الحقل.

ترميز TLV:
01 05 [Qoyod] 02 0F [301234567800003]

الميزة: الطول يحدّد الحدود بدقة. أي محرف داخل القيمة
(فاصلة، مسافة، رمز) لا يربك القارئ إطلاقًا.

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

التحقق من سلامة ترميز TLV

عند بناء أو تدقيق رمز QR، يمكن التحقق من سلامة طبقة TLV بخطوات عملية:

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

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

المرحلة الثانية: حقول إضافية بالمنطق نفسه

في المرحلة الثانية من الفوترة الإلكترونية (مرحلة الربط والتكامل)، تضيف الهيئة حقولًا جديدة إلى سلسلة TLV بالبنية نفسها تمامًا: وسم بايت واحد، طول بايت واحد، ثم قيمة. أبرز هذه الحقول الإضافية:

• الوسم 6: تجزئة الفاتورة (Invoice hash) المبنية على خوارزمية SHA-256.
• الوسم 7: الختم التشفيري (Cryptographic stamp / digital signature).
• وسوم أعلى: المفتاح العام (Public key) وختم الهيئة على المفتاح العام في فواتير المنشأة.

الفرق الجوهري أن قيم هذه الحقول ثنائية مشفّرة لا نصوص بشرية، لكنها تبقى مغلّفة بالمنطق ذاته: وسم، طول، قيمة. آلية SHA-256 التي تنتج حقل التجزئة لها تفصيلها المستقل في دليل خوارزمية التجزئة SHA-256 في الفاتورة الإلكترونية. أما البنية الكاملة لملف الفاتورة الذي تُشتقّ منه هذه القيم فيشرحها دليل بنية فاتورة XML في الفوترة الإلكترونية.

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

أخطاء شائعة في بناء ترميز TLV

من يبني الترميز يدويًا أو يتحقق منه يقع غالبًا في الأخطاء التالية:

• حساب الطول بالأحرف لا البايتات: أشهر خطأ. النص العربي يضاعف عدد البايتات، فاحسب الطول دائمًا بعد ترميز UTF-8.
• إغفال ترتيب الوسوم: الحقول تُرصّ بترتيب الوسم 1 ثم 2 ثم 3 وهكذا. خلط الترتيب يُربك بعض القارئات الصارمة.
• إضافة فواصل بين الحقول: TLV لا يحتاج فاصلًا. أي بايت زائد يفسد قراءة الطول التالي.
• الترميز المزدوج بـ Base64: تمرير السلسلة عبر Base64 مرتين ينتج نصًا لا يفكّه القارئ.
• تجاوز حد البايت الواحد للطول: قيمة أطول من 255 بايتًا تحتاج معالجة خاصة. حقول الفاتورة المبسّطة تبقى تحت الحد، لكن انتبه عند التوسّع.

ترميز TLV في الواقع العملي للمنشآت

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

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

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

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

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

كيف يساعدك قيود في ترميز TLV والامتثال

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

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

الأسئلة الشائعة

ما معنى TLV في رمز الفاتورة؟

TLV اختصار لـ Tag-Length-Value، أي «وسم، طول، قيمة». هي صيغة تغليف كل حقل من حقول الفاتورة في ثلاثة أجزاء متتابعة: وسم يحدّد نوع الحقل، وطول يحدّد عدد بايتات القيمة، ثم القيمة نفسها مرمَّزة UTF-8.

كم بايتًا يشغل الوسم والطول في TLV؟

الوسم يشغل بايتًا واحدًا، والطول يشغل بايتًا واحدًا أيضًا. أما القيمة فطولها متغيّر، ويساوي بالضبط الرقم المخزَّن في بايت الطول.

هل يُحسب الطول بعدد الأحرف أم البايتات؟

بعدد البايتات بعد ترميز UTF-8، لا بعدد الأحرف. الحرف العربي يشغل بايتين عادةً، فاسم بائع عربي من أربعة أحرف يساوي 8 بايتات في حقل الطول لا 4.

لماذا تُرمَّز سلسلة TLV بصيغة Base64؟

لأن سلسلة TLV بايتات ثنائية خام قد تحوي قيمًا غير قابلة للطباعة. يحوّلها Base64 إلى نص من حروف وأرقام آمنة للحقن في رمز QR والمسح بأي تطبيق هاتف.

هل تتغيّر بنية TLV بين المرحلة الأولى والثانية؟

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

هل أحتاج إلى بناء ترميز TLV يدويًا؟

لا. أي نظام محاسبي معتمد يبني سلسلة TLV ويرمّزها Base64 ويحقنها في رمز QR تلقائيًا في كل فاتورة. قيود يتولّى ذلك بالكامل دون تدخّل يدوي.