أخطاء رمز QR في الفاتورة الإلكترونية

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

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

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

لماذا يفشل رمز QR رغم أنه يظهر سليمًا؟

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

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

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

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

رسم توضيحي: مسار البيانات من الحقول إلى رمز QR ونقاط الفشل

1. ترميز TLV تالف أو ترتيب وسوم خاطئ

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

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

العَرَض: يقرأ تطبيق «منصة فاتورة» الرمز فيعرض حقولًا فارغة أو قيمًا مشوّهة، أو يرفض الرمز كليًا برسالة «بيانات غير صالحة». أحيانًا يظهر اسم البائع في خانة الرقم الضريبي، أو يظهر جزء من الطابع الزمني داخل اسم البائع، وكلها أعراض لانزياح مؤشّر القراءة عن مواضع البايتات الصحيحة.

السبب: الطول المكتوب لا يساوي عدد بايتات القيمة الفعلية، أو غاب عنصر الطول كليًا فاندمج وسمان، أو رُتّبت الوسوم بترتيب غير تصاعدي، أو استُخدم بايت واحد للطول بينما القيمة تتجاوز 255 بايتًا.

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

// sahih: Tag, Length (bytes), Value bil-tarteeb
Tag=01  Len=14  Value="متجر الواحة"      // 20 bytes UTF-8
Tag=02  Len=0F  Value="300000000000003"  // 15 bytes

// talif: al-tool la yutabiq al-bytes wa al-tarteeb maakous
Tag=02  Len=0F  Value="300000000000003"
Tag=01  Len=08  Value="متجر الواحة"      // al-tool 8 wa al-mahtawa atwal => inziyah

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

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

2. وسوم المرحلة الثانية الناقصة (6 و7 و8 و9)

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

• الوسم 6: قيمة تجزئة الفاتورة (Hash) بصيغة Base64، وتربط الفاتورة بسلسلة الفواتير السابقة لضمان عدم التلاعب.
• الوسم 7: التوقيع الرقمي للفاتورة (Signature) المُولّد بمفتاح خاص.
• الوسم 8: المفتاح العام (Public Key) المقابل، ويستخدمه القارئ للتحقق من التوقيع.
• الوسم 9: ختم الهيئة المشفّر، وهو توقيع الهيئة على المفتاح العام لإثبات أنه صادر عن شهادة معتمدة.

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

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

السبب: النظام يولّد الرمز بمنطق المرحلة الأولى، أو لم يُربط بشهادة التوقيع، فلا يملك قيم الوسوم 7 و8 و9 أصلًا. أحيانًا يكون السبب أن الشهادة منتهية الصلاحية، أو أن محرّك التوقيع فشل صامتًا فأكمل النظام توليد الرمز بالوسوم المتاحة فقط.

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

رسم توضيحي: الوسوم التسعة وأيّها يخصّ المرحلة الثانية

3. تشفير Base64 خاطئ أو تالف

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

الفارق بين النمطين دقيق لكنه قاتل. النمط القياسي يستخدم المحرفين «+» و«/» مع حشوة «=» في النهاية، بينما النمط الآمن للروابط يستبدلهما بـ «-» و«_» ويحذف الحشوة غالبًا. القارئ الذي يتوقّع النمط القياسي يفشل في فك النمط الآخر، فيخرج بايتات لا تشكّل بنية TLV سليمة.

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

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

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

// sahih: fak Base64 yueed silsilat TLV qabila lil-tafkeek
{
  "decoded": "0114...020F300000000000003...",
  "tlv_valid": true,
  "tags_found": [1,2,3,4,5,6,7,8,9]
}

// talif: hashwa naqisa + tarmeez URL-safe
{
  "error": "INVALID_BASE64_PADDING",
  "tlv_valid": false,
  "tags_found": []
}

القاعدة العملية أن تتعامل مع Base64 كخطوة ختامية واحدة على كامل السلسلة، لا كعملية تطبّقها على أجزاء. هذا وحده يمنع معظم حالات «الرمز يُمسح لكن لا يُفكّ».

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

4. الرمز لا يُمسح أو يفشل التحقق في تطبيق «منصة فاتورة»

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

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

العَرَض: الكاميرا لا تلتقط الرمز أصلًا، أو تطبيق «منصة فاتورة» يفتح لكن لا يُكمل القراءة، أو يقرأ الرمز ثم يردّ برسالة فشل تحقق التوقيع رغم نجاح المسح.

السبب: في حالة فشل المسح: دقّة طباعة منخفضة، أو الرمز أصغر من الحد الأدنى الموصى به، أو وُضع على خلفية ملوّنة تضعف التباين، أو ضُغطت الصورة بصيغة فقدان عالية. وفي حالة فشل التحقق بعد المسح: مشكلة في وسوم التوقيع 7 و8 و9، أو شهادة غير صالحة، أو قيمة تجزئة لا تطابق محتوى الفاتورة.

الإصلاح: اطبع الرمز بحجم كافٍ مع هامش أبيض حوله، وبتباين عالٍ بين الوحدات السوداء والخلفية البيضاء، وتجنّب وضعه على خلفيات ملوّنة أو متدرّجة. إن نجح المسح وفشل التحقق فقط، فالمشكلة في طبقة البيانات لا في الصورة، وراجع حينها وسوم التوقيع 7 و8 و9 وحالة الشهادة. خطوات التأكد الكاملة من صحة الفاتورة موجودة في دليل التحقق من الفاتورة الإلكترونية المُشار إليه أعلى الصفحة.

5. الخلط بين عدد البايتات وعدد الأحرف في حساب الطول

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

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

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

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

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

// khata: al-tool = adad al-ahruf
value = "متجر الواحة"     // 11 char (maa al-masafa)
length = value.length     // = 11  X

// sahih: al-tool = adad bytes UTF-8
bytes  = utf8_encode(value)   // 20 bytes
length = bytes.length         // = 20  OK

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

منهجية تشخيص منظّمة بدل التخمين

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

ابدأ بالسؤال: هل يُمسح الرمز بصريًا أصلًا؟ إن لم يُمسح، فالمشكلة في الصورة وحدها، وتوقّف عند الحجم والتباين والهامش دون أن تفتح الترميز. وإن مُسح، انتقل إلى فك Base64 محليًا: إن فشل الفك، فالخلل في نمط الترميز أو الحشوة. وإن نجح الفك، فكّك بنية TLV وتأكّد أن الوسوم تظهر بالترتيب 1 إلى 9 دون فجوات. وإن ظهرت الوسوم سليمة لكن التحقق فشل، فالمشكلة في قيم التوقيع 6 إلى 9 أو في الشهادة.

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

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

كيف يساعدك قيود في تفادي أخطاء رمز QR

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

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

رسم توضيحي: قائمة تشخيص سريعة لأعطال رمز QR

أسئلة شائعة

لماذا يظهر رمز QR سليمًا لكن تطبيق «منصة فاتورة» يرفضه؟

لأن سلامة الصورة لا تعني سلامة البيانات بداخلها. قد يكون الترميز تالفًا في طبقة TLV أو Base64 رغم أن الرمز يُمسح بصريًا. افحص ترتيب الوسوم وحساب الطول أولًا، ثم تحقق من ترميز Base64.

ما الوسوم التي تميّز رمز المرحلة الثانية؟

الوسوم 6 و7 و8 و9: قيمة التجزئة، والتوقيع الرقمي، والمفتاح العام، وختم الهيئة. غيابها يجعل الرمز رمز مرحلة أولى غير مكتمل وغير متوافق مع المرحلة الثانية.

لماذا تفشل فواتيري العربية بينما تعمل الإنجليزية؟

غالبًا لأن الطول في حقل TLV يُحسب بعدد الأحرف لا بعدد البايتات. كل حرف عربي بترميز UTF-8 يشغل بايتين، فيختلّ حساب الطول مع النصوص العربية فقط. احسب الطول من بايتات UTF-8 بعد الترميز.

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

لا. يُصدر قيود الرمز تلقائيًا بوسومه التسعة وترميزه الصحيح على كل فاتورة ضريبية مبسّطة، مطابقًا لمواصفة الهيئة، بعد ربط شهادتك مرة واحدة.

الرمز يُمسح لكن يفشل التحقق من التوقيع، أين الخلل؟

المشكلة في طبقة البيانات والتوقيع لا في الصورة. راجع الوسوم 7 و8 و9 وتأكّد أن النظام مرتبط بشهادة معرّف ختم الامتثال (CSID) المسجّلة لدى الهيئة وأنها سارية الصلاحية.

هل يكفي تكبير حجم الرمز لحلّ مشكلة المسح؟

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