Lorixen.

لماذا يختلف مجموع البنود عن المبلغ النهائي في تطبيق الأعمال؟

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

يساعد هذا الدليل صاحب العمل على وصف السلوك المطلوب. وهو لا يحدد طريقة حساب الضرائب أو المتطلبات القانونية للفواتير أو تحويل العملات أو تقريب المدفوعات النقدية. ينبغي أن يؤكد المختص المعني هذه المتطلبات قبل تنفيذها.

افهموا الفرق قبل طلب إصلاح تقني

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

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

مثال صغير يوضح موضع الاختلاف

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

عند تقريب كل بند أولًا، تصبح قيمة البند 0.34، ويكون المجموع 1.02. أما جمع القيم الأصلية أولًا فيعطي 1.005، ثم يصبح المجموع 1.01 باستخدام القاعدة نفسها. الطريقة واحدة، لكن مرحلة تطبيقها مختلفة. هذا مثال حسابي افتراضي، وليس تعليمات لحساب الضريبة أو إصدار فاتورة.

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

عبارة «التقريب المعتاد» لا تكفي

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

عند تقريب 1.005 إلى منزلتين عشريتين، تعطي الطريقة الأولى 1.01 وتعطي الثانية 1.00. سجّلوا النتيجة المتوقعة إلى جانب المدخل، بدل الاكتفاء باسم الطريقة. اختبروا التصحيحات السالبة وعكس العمليات أيضًا؛ فقد تكون كلمة «لأعلى» ملتبسة عندما تكون القيمة سالبة.

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

احتفظوا بما يفسر النتيجة

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

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

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

وحّدوا النتيجة بين الشاشة والمستندات والأنظمة

حددوا نتيجة حساب معتمدة لكل عملية مؤكدة. ينبغي أن تستخدم شاشة الطلب وملف التصدير والمستند الناتج هذه النتيجة، بدل أن يعيد كل منها حساب المجموع من القيم التي تصله بصورة منفصلة.

وعند الربط بخدمة أخرى، وثّقوا المبلغ والعملة والوحدة التي تتوقعها الخدمة المستقبلة. لا تفترضوا أن الرقم يحمل المعنى نفسه في النظامين. اتفقوا على ما يراه الموظف وما يفعله إذا اختلف الإجمالي الوارد عن الحساب المحلي. استبدال قيمة بأخرى دون تفسير ليس آلية تسوية.

ما الذي يجب عرضه قبل القبول؟

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

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

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

المصدر وحدود الدليل

وثائق Python حول decimal وطرق التقريب والتحويل من الفاصلة العائمة: https://docs.python.org/3/library/decimal.html

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

WhatsAppلنتحدث