ফাইন্যান্স অ্যাপে মুদ্রার রাউন্ডিং: টাকাকে নিরাপদে সংরক্ষণ করুন

কেন এক-পয়সার বাগ হয়

এক-পয়সার বাগ এমন একটি ভুল যা ব্যবহারকারী তৎক্ষণাৎ লক্ষ্য করে। পণ্যের তালিকায় মোট $19.99 দেখালেও চেকআউটে সেটা $20.00 হয়ে যায়। $14.38 রিফান্ড আসে $14.37 হিসেবে। ইনভয়েস লাইনে লেখা থাকে “Tax: $1.45”, কিন্তু গ্র্যান্ড টোটাল যেন অন্যভাবে যোগ করা হয়েছে।

এই সমস্যাগুলো সাধারণত ছোট ছোট রাউন্ডিং পার্থক্য থেকে আসে যেগুলো জমে যায়। টাকা শুধু "একটি সংখ্যা" নয়—এর নিজস্ব নিয়ম আছে: কোন মুদ্রা কত দশমিক ব্যবহার করে, কখন রাউন্ড করবেন, এবং আপনি কি প্রতিটি লাইন আইটেমে রাউন্ড করবেন নাকি চূড়ান্ত মোটে। অ্যাপে যদি কোথাও ভিন্ন চয়েস করা হয়, তবে একটি সেন্ট যোগ বা কম হয়ে যেতে পারে।

এগুলো অনেকসময় ইন্টারমিটেন্টলি দেখা দেয়, তাই ডিবাগ করা কষ্টকর হয়। একই ইনপুট ডিভাইস বা লোকেল সেটিংস, অপারেশন এর অর্ডার, বা টাইপ কনভার্ট করার ভিন্নতার উপর নির্ভর করে ভিন্ন সেন্ট তৈরি করতে পারে।

সাধারণ ট্রিগারগুলোর মধ্যে রয়েছে float দিয়ে হিসাব করা এবং “শেষে” রাউন্ড করা (কিন্তু “শেষ” সব জায়গায় একরকম নয়), এক স্ক্রিনে আইটেম ভিত্তিভিত্তিক ট্যাক্স আর অন্য স্ক্রিনে সাবটোটালে ট্যাক্স দেয়া, মুদ্রা বা এক্সচেঞ্জ রেটে মিশ্রণ এবং অননুকূল ধাপে রাউন্ড করা, অথবা প্রদর্শনের জন্য ভ্যালু ফরম্যাট করে সেটা আবার সংখ্যায় পার্স করে নেওয়া।

ক্ষতি সবচেয়ে বেশি লাগে যেখানে বিশ্বাস সঙ্কুচিত এবং অ্যামাউন্ট অডিট করা হয়: চেকআউট টোটাল, রিফান্ড, ইনভয়েস, সাবস্ক্রিপশন, টিপ, পেআউট এবং খরচ রিপোর্ট। এক-পয়সার মিল না থাকলে পেমেন্ট ফেলিউর, রিকনসিলিয়েশন ঝামেলা, এবং “আপনার অ্যাপ আমাকে চুরি করছে” ধরনের সাপোর্ট টিকিট দেখা দিতে পারে।

লক্ষ্যটি সহজ: একই ইনপুট সব জায়গায় একই সেন্ট উত্পন্ন করা উচিত। একই আইটেম, একই ট্যাক্স, একই ডিসকাউন্ট, একই রাউন্ডিং নিয়ম—কোনো স্ক্রিন, ডিভাইস, ভাষা বা এক্সপোর্ট নির্বিশেষে।

উদাহরণ: যদি দুইটি $9.99 আইটেমে 7.25% ট্যাক্স থাকে, প্রথমে নির্ধারণ করুন আপনি ট্যাক্স প্রতিটি আইটেমে রাউন্ড করবেন নাকি সাবটোটালে—তারপর ব্যাকএন্ড, ওয়েব UI ও মোবাইল অ্যাপে একইভাবে করুন। ধারাবাহিকতা "এটা এখানে কেন আলাদা?" মুহূর্তটি বন্ধ করে দেয়।

কেন float দিয়ে টাকা ঝুঁকিপূর্ণ

অধিকাংশ প্রোগ্রামিং ভাষাই float এবং double মানগুলো বাইনারি-তে রাখে। অনেক দশমিক মূল্য বাইনারি-তে সঠিকভাবে উপস্থাপন করা যায় না, তাই আপনি যেই সংখ্যা সংরক্ষণ করেছেন সেটি সামান্যভাবে বেশি বা কম থাকে।

ক্লাসিক উদাহরণ হলো 0.1 + 0.2. অনেক সিস্টেমে এটা 0.30000000000000004 হয়ে যায়। এটা অসীম হাস্যকর বলে মনে হতে পারে, কিন্তু টাকা লজিক সাধারণত একটি চেইন: আইটেম মূল্য, ডিসকাউন্ট, ট্যাক্স, ফি, তারপর চূড়ান্ত রাউন্ডিং। ছোট ত্রুটি একটি রাউন্ডিং সিদ্ধান্ত উল্টে দিতে পারে এবং এক-পয়সার পার্থক্য তৈরি করতে পারে।

মানুষ যে লক্ষণগুলো দেখে যখন টাকার রাউন্ডিং ভুল হয়:

• লগ বা API রেসপনসে 9.989999 বা 19.9000001 মতো মান দেখা যায়।
• অনেক আইটেম যোগ করার পরে মোটগুলি ধীরে ধীরে বিচ্যুত হয়, যেখানে প্রতিটি আইটেম ঠিক দেখায়।
• একটি রিফান্ড মোট মূল চার্জের সাথে $0.01 মিলছে না।
• একই কার্ট টোটাল ওয়েব, মোবাইল এবং ব্যাকএন্ডে আলাদা হয়।

ফরম্যাটিং প্রায়ই সমস্যা ঢেকে দেয়। যদি আপনি 9.989999 কে দুইটি দশমিক দিয়ে প্রিন্ট করেন, এটি 9.99 দেখায়, তাই সবকিছু ঠিকই মনে হয়। বাগ পরে দেখা দেয় যখন আপনি অনেক মান যোগ করেন, মোট তুলনা করেন, বা ট্যাক্সের পরে রাউন্ড করেন। এজন্যই অনেক টিম এটাকে চালিয়ে দেয় এবং পরে পেমেন্ট প্রোভাইডার বা একাউন্টিং এক্সপোর্টের সঙ্গে রিকনসিল করার সময় আবিষ্কার হয়।

সোজা নিয়ম: টাকা float হিসেবে সংরক্ষণ বা যোগ করবেন না। টাকাকে মাইনর ইউনিটের একটি ইন্টিজার হিসেবে বিবেচনা করুন (যেমন সেন্ট), অথবা এমন একটি দশমিক টাইপ ব্যবহার করুন যা এক্স্যাক্ট দশমিক গাণিতিক নিশ্চিত করে।

আপনি যদি ব্যাকএন্ড, ওয়েব অ্যাপ বা মোবাইল অ্যাপ বানান (এমনকি কোন-কোড প্ল্যাটফর্মে), একই নীতি সব জায়গায় রাখুন: সঠিক মান সংরক্ষণ করুন, সঠিক মানেই ক্যালকুলেট করুন, এবং শুধুমাত্র প্রদর্শনের জন্য শেষ পর্যন্ত ফরম্যাট করুন।

বাস্তব মুদ্রার সঙ্গে মানানসই একটি মানি মডেল বেছে নিন

অধিকাংশ টাকা বাগ গণনায় যাওয়ার আগেই শুরু হয়: ডেটা মডেলটি বাস্তব মুদ্রার সাথে মেলেনা। মডেলটি সঠিকভাবে নির্ধারণ করুন এবং রাউন্ডিং তখন নিয়মের সমস্যা হবে, অনুমান করার নয়।

সবচেয়ে নিরাপদ ডিফল্ট হলো মুদ্রাকে মাইনর ইউনিটে একটি ইন্টিজার হিসেবে সংরক্ষণ করা। USD-এর জন্য সেটা সেন্ট; EUR-এর জন্য ইউরো সেন্ট। আপনার ডাটাবেস ও কোড সঠিক ইন্টিজার হিসেবে পরিচালনা করে, এবং আপনি কেবল প্রদর্শনের সময় দশমিক যোগ করবেন।

সব মুদ্রারই ২ দশমিক নেই, তাই আপনার মডেলকে মুদ্রা-সচেতন হতে হবে। JPY-তে 0 মাইনর দশমিক (1 yen হচ্ছে সর্বনিম্ন ইউনিট)। BHD-তে সাধারণত 3 দশমিক থাকে (1 dinar = 1000 fils)। যদি আপনি “সব জায়গায় দুই দশমিক” হার্ডকোড করেন, আপনি নীরবভাবে বেশি বা কম চার্জ করবেন।

একটি বাস্তবসম্মত মানি রেকর্ড সাধারণত প্রয়োজন:

• amount_minor (ইন্টিজার, যেমন $19.99 এর জন্য 1999)
• currency_code (স্ট্রিং, যেমন USD, EUR, JPY)
• ঐচ্ছিক minor_unit বা scale (0, 2, 3) যদি সিস্টেমটি নির্ভরযোগ্যভাবে খুঁজে না পারে

প্রতিটি পরিমাণের সঙ্গে currency কোড সংরক্ষণ করুন, এমনকি একই টেবিলেও। পরে যখন আপনি মাল্টি-কারেন্সি প্রাইসিং, রিফান্ড বা রিপোর্ট যোগ করবেন, তখন ভুল হওয়া রোধ হবে।

এছাড়া সিদ্ধান্ত নিন কোথায় রাউন্ডিং অনুমোদিত এবং কোথায় অমান্য। একটি কার্যকর নীতি হলো: অভ্যন্তরীণ টোটাল, এলোকেশন, লেজার, বা চলমান কনভার্সনে রাউন্ড করবেন না; নির্ধারিত বাউন্ডারিতে (যেমন ট্যাক্স ধাপ, ডিসকাউন্ট ধাপ, বা চূড়ান্ত ইনভয়েস লাইন) রাউন্ড করুন; এবং ব্যবহৃত রাউন্ডিং মোড (half up, half even, round down) লগ করুন যাতে ফলাফল পুনরুত্পাদনযোগ্য হয়।

ধাপে ধাপে: মাইনর-ইউনিট ইন্টিজার হিসাবে টাকাকে বাস্তবায়ন করা

কম বিস্ময় পেতে চান? একটি অভ্যন্তরীণ কাঠামো বেছে নিন এবং ভাঙবেন না: পরিমাণগুলো মুদ্রার মাইনর ইউনিটে (প্রায়ই সেন্ট) ইন্টিজার হিসেবে স্টোর করুন।

এটার মানে $10.99 হবে 1099 currency USD এর সাথে। কোন মাইনর ইউনিট নেই এমন মুদ্রায় যেমন JPY, 1,500 yen থাকবে 1500।

একটি সহজ বাস্তবায়ন পথ যা অ্যাপ বাড়ালে স্কেল করে:

1. ডাটাবেস: amount_minor-কে 64-বিট ইন্টিজার ও একটি currency কোড হিসেবে রাখুন। কলামের নাম পরিষ্কার রাখুন যাতে কেউ এটাকে দশমিক ভেবে না নেয়।
2. API কনট্রাক্ট: { amount_minor: 1099, currency: "USD" } পাঠান এবং গ্রহণ করুন। $10.99 মত ফরম্যাটেড স্ট্রিং বা JSON ফ্লোট এড়ান।
3. UI ইনপুট: ইউজার যা টাইপ করে তাকে টেক্সট হিসেবে নিন, সংখ্যার মতো নয়। নরমালাইজ করুন (স্পেস কেটে দিন, একটি দশমিক বিভাজক গ্রহণ করুন), তারপর মুদ্রার মাইনর-ইউনিট ডিজিট ব্যবহার করে কনভার্ট করুন।
4. সব গাণিতিক ইন্টিজারে করুন: টোটাল, লাইন যোগ, ডিসকাউন্ট, ফি, এবং ট্যাক্স সবই ইন্টিজারে কাজ করা উচিত। যেমন “শতাংশ ডিসকাউন্ট প্রথম গণনা করে তারপর মাইনর ইউনিটে রাউন্ড করা হবে”—এমন নিয়ম নির্ধারণ করুন এবং প্রতিবার একইভাবে প্রয়োগ করুন।
5. শুধুমাত্র শেষে ফরম্যাট করুন: যখন আপনি টাকাকে দেখাবেন, amount_minor-কে লোকেল ও মুদ্রা নিয়ম ব্যবহার করে ডিসপ্লে স্ট্রিং এ রূপান্তর করুন। আপনার নিজস্ব ফরম্যাট করা আউটপুটকে কখনো আবার ম্যাথের জন্য পার্স করবেন না।

একটি ব্যবহারিক পার্সিং উদাহরণ: USD-তে "12.3" কে "12.30" হিসেবে ধরা এবং তারপর 1230-এ রূপান্তর করা। JPY-তে ডেসিমাল গ্রহণ না করে অবিলম্বে বাতিল করা।

ট্যাক্স, ডিসকাউন্ট এবং ফি রাউন্ডিং নিয়ম

অধিকাংশ এক-পয়সার বিবাদ গাণিতিক ভুল নয়; এগুলো নীতিগত ভুল। দুটি সিস্টেমই “সঠিক” হতে পারে এবং তবুও ভিন্ন হতে পারে যদি তারা আলাদা সময়ে রাউন্ড করে।

রাউন্ডিং নীতি লিখে রাখুন এবং সব জায়গায় ব্যবহার করুন: ক্যালকুলেশন, রশিদ, এক্সপোর্ট এবং রিফান্ড। সাধারণ পছন্দগুলোর মধ্যে রয়েছে half-up (0.5 উপরে যায়) এবং half-even (0.5 নিকটতম জোড় সেন্টে যায়)। কিছু ফি সবসময় উপরে (ceiling) রাউন্ড করতে হবে যাতে আপনি কখনো কম চার্জ না করেন।

টোটাল সাধারণত কয়েকটি সিদ্ধান্তের উপর নির্ভর করে: প্রতিটি লাইন আইটেমে রাউন্ড করা নাকি ইনভয়েসে, নিয়ম মিশ্রিত করা হচ্ছে কি না (উদাহরণ: লাইনে ট্যাক্স কিন্তু ইনভয়েসে ফি), এবং মূল্যগুলো ট্যাক্স-ইনক্লুসিভ কিনা (আপনি নেট ও ট্যাক্স ব্যাক-ক্যালকুলেট করবেন) বা ট্যাক্স-এক্সক্লুসিভ (নেট থেকে ট্যাক্স গণনা)।

ডিসকাউন্টগুলো আরেকটি বিচ্ছিন্ন পথ যোগ করে। “10% অফ” যদি ট্যাক্সের আগে প্রয়োগ করা হয় তবে তা ট্যাক্সেবল বেস কমায়, আর যদি ট্যাক্সের পরে প্রয়োগ করা হয় তাহলে সেটা গ্রাহক যা দিচ্ছে তা কমায় কিন্তু রিপোর্টকৃত ট্যাক্স বদলায় কিনা সেটাJurisdiction ও কনট্রাক্ট নির্ভর করে।

একটি ছোট উদাহরণ দেখায় কেন কঠোর নিয়ম জরুরি। দুটি $9.99 আইটেম, 7.5% ট্যাক্স। যদি আপনি প্রতিটি লাইনে ট্যাক্স রাউন্ড করেন, তাহলে প্রতিটি লাইনের ট্যাক্স হবে $0.75 (9.99 x 0.075 = 0.74925)। মোট ট্যাক্স হবে $1.50। যদি আপনি ইনভয়েস মোটে ট্যাক্স করেন, এখানেও ট্যাক্স $1.50 হবে, কিন্তু দামগুলো সামান্য বদলে দিলে আপনি 1-পয়সার পার্থক্য দেখতে পাবেন।

নীতি সহজ ভাষায় লিখে রাখুন যাতে সাপোর্ট ও ফাইন্যান্স এটি ব্যাখ্যা করতে পারে। তারপর ট্যাক্স, ফি, ডিসকাউন্ট ও রিফান্ডের জন্য একই হেল্পার পুনঃব্যবহার করুন।

মুদ্রা রূপান্তর যাতে টোটাল ড্রিফট না করে

মাল্টি-কারেন্সি গণিত এমন জায়গা যেখানে ছোট রাউন্ডিং পছন্দগুলো ধীরে ধীরে টোটাল বদলে দিতে পারে। লক্ষ্য সোজা: একবার কনভার্ট করুন, উদ্দেশ্যমূলকভাবে রাউন্ড করুন, এবং মূল তথ্য পরে ব্যাখ্যা করার জন্য রাখুন।

এক্সচেঞ্জ রেটগুলো স্পষ্ট প্রিসিশনসহ সংরক্ষণ করুন। এক সাধারণ প্যাটার্ন হলো স্কেল্ড ইন্টিজার, যেমন “rate_micro” যেখানে 1.234567 কে 1234567 হিসেবে 1,000,000 স্কেলে রাখা হয়। আরেকটি অপশন হল ফিক্সড দশমিক টাইপ, কিন্তু ফিল্ডে স্কেল লিখে রাখুন যাতে সেটা আন্দাজ করা না যায়।

রিপোর্টিং ও একাউন্টিং-এর জন্য একটি বেইস কারেন্সি বেছে নিন (সাধারণত আপনার কোম্পানির কারেন্সি)। ইনকামিং অ্যামাউন্টগুলোকে বেইস কারেন্সিতে কনভার্ট করে লেজার ও অ্যানালিটিক্সে রাখুন, কিন্তু সাথে সাথে মূল মুদ্রা ও পরিমাণও রাখুন। এভাবে পরে প্রতিটি সংখ্যা ব্যাখ্যা করা যায়।

ড্রিফট রোধ করার নিয়মগুলো:

• হালনাগাদ হিসাবের জন্য শুধু একদিকে কনভার্ট করুন (ফরেন থেকে বেইস) এবং বারবার পিছনে-সামনে কনভার্ট করা এড়ান।
• রাউন্ডিং সময় নির্ধারণ করুন: যখন লাইনে মোট দেখাতে হবে তখন লাইনে রাউন্ড করুন, বা শুধুমাত্র গ্র্যান্ড টোটাল দেখালে শেষে রাউন্ড করুন।
• একটি রাউন্ডিং মোড নির্বাচিত করে ডকুমেন্ট করুন এবং সব জায়গায় ব্যবহার করুন।
• প্রতিটি লেনদেনের জন্য মূল পরিমাণ, মুদ্রা এবং ব্যবহার করা সঠিক রেট সংরক্ষণ করুন।

উদাহরণ: গ্রাহক 19.99 EUR পে করে, আপনি এটিকে 1999 মাইনর ইউনিট এবং currency=EUR হিসেবে সংরক্ষণ করেন। আপনি চেকআউটে ব্যবহৃত রেটও সংরক্ষণ করেন (উদাহরণ হিসেবে EUR থেকে USD রেট মাইক্রো ইউনিটে)। আপনার লেজার কনভার্ট করা USD পরিমাণও রাখে (আপনার নির্বাচিত নিয়ম অনুযায়ী রাউন্ড করা), কিন্তু রিফান্ডগুলো সংরক্ষণ করা মূল EUR পরিমাণ ব্যবহার করে, USD থেকে পুনরায় কনভার্ট করলে না। এতে “আমি 19.98 EUR কেন পেয়েছি?” রকম টিকিট রোধ হয়।

ডিভাইস জুড়ে ফরম্যাটিং এবং ডিসপ্লে

শেষ মাইলটি হল স্ক্রিন। স্টোরেজে সঠিক মান থাকা সত্ত্বেও ভিন্ন ফরম্যাটিং থাকলে তা ভুল দেখাতে পারে।

বিভিন্ন লোকেল ভিন্ন বিভাজক ও সিম্বল অবস্থান আশা করে। উদাহরণস্বরূপ, অনেক মার্কিন ইউজার $1,234.50 পড়ে, অথচ ইউরোপের অনেক জায়গায় তারা আশা করে 1.234,50 € (একই মান, ভিন্ন সেপারেটর ও সিম্বল পজিশন)। যদি আপনি ফরম্যাটিং হার্ডকোড করেন, আপনি লোক জনকে বিভ্রান্ত করবেন এবং সাপোর্ট বাড়বে।

একটিই নিয়ম সব জায়গায় পালন করুন: এজে গিয়ে ফরম্যাট করুন, কোরে নয়। আপনার সুত্র-সত্য হওয়া উচিত (currency code, minor units integer)। কেবল প্রদর্শনের জন্য স্ট্রিং-এ রূপান্তর করুন। কখনো ফরম্যাট করা স্ট্রিংকে আবার অর্থের জন্য পার্স করবেন না—এখানেই রাউন্ডিং, ট্রিমিং এবং লোকেল বিস্ময় এসে পড়ে।

রিফান্ডের মতো নেগেটিভ পরিমাণের জন্য একটি ধারাবাহিক স্টাইল বেছে নিন এবং সব জায়গায় ব্যবহার করুন। কিছু সিস্টেম দেখায় -$12.34, অন্যরা দেখায় ($12.34)। দুটিই ঠিক, কিন্তু স্ক্রিন জুড়ে পরস্পর লাফালে সেটা ত্রুটির মতো দেখায়।

একটি সরল ক্রস-ডিভাইস চুক্তি যা ভালো কাজ করে:

• মুদ্রা ISO কোড (যেমন USD, EUR) হিসেবে বহন করুন, শুধু সিম্বল নয়।
• ডিফল্ট হিসেবে ডিভাইস লোকেল অনুযায়ী ফরম্যাট করুন, কিন্তু ইন-অ্যাপ ওভাররাইড অনুমতি দিন।
• মাল্টি-কারেন্সি স্ক্রিনে পরিমাণ পাশে মুদ্রা কোড দেখান (উদা: 12.34 USD)।
• ইনপুট ফরম্যাটিংকে ডিসপ্লে ফরম্যাটিং থেকে আলাদা করে বিবেচনা করুন।
• ফরম্যাটিং-এর আগে আপনার মানি রুল অনুযায়ী একবার রাউন্ড করুন।

উদাহরণ: মোবাইলে গ্রাহক একটি রিফান্ড 10,00 EUR দেখে, তারপর ডেস্কটপে একই অর্ডার খুললে -€10 দেখা যায়। যদি আপনি কোডও দেখান (10,00 EUR) এবং নেগেটিভ স্টাইল ধারাবাহিক রাখেন, তারা বুঝবে না যে এটা বদলে গেছে।

উদাহরণ: চেকআউট, ট্যাক্স এবং রিফান্ড যাতে অপ্রত্যাশিত না হয়

একটি সহজ কার্ট:

• আইটেম A: $4.99 (499 cents)
• আইটেম B: $2.50 (250 cents)
• আইটেম C: $1.20 (120 cents)

সাবটোটাল = 869 cents ($8.69). প্রথমে 10% ডিসকাউন্ট প্রয়োগ করুন: 869 x 10% = 86.9 cents, এটি 87 cents-এ রাউন্ড করুন। ডিসকাউন্টকৃত সাবটোটাল = 782 cents ($7.82). এখন 8.875% ট্যাক্স প্রয়োগ করুন।

এখানেই রাউন্ডিং নীতি ফাইনাল পয়সা বদলে দিতে পারে।

যদি আপনি ইনভয়েস মোটে ট্যাক্স গণনা করেন: 782 x 8.875% = 69.4025 cents, এটি 69 cents-এ রাউন্ড করুন।

যদি আপনি প্রতিটি লাইনে (ডিসকাউন্টের পরে) ট্যাক্স গণনা করে প্রতিটি লাইন রাউন্ড করেন:

• আইটেম A: $4.49 ট্যাক্স = 39.84875 cents, রাউন্ড করে 40
• আইটেম B: $2.25 ট্যাক্স = 19.96875 cents, রাউন্ড করে 20
• আইটেম C: $1.08 ট্যাক্স = 9.585 cents, রাউন্ড করে 10

লাইন ট্যাক্স টোটাল = 70 cents। একই কার্ট, একই রেট, কিন্তু আলাদা বৈধ নিয়ম — 1 সেন্ট পার্থক্য।

ট্যাক্সের পরে একটি শিপিং ফি যোগ করুন, ধরুন 399 cents ($3.99)। মোট হবে $12.50 (ইনভয়েস-লেভেল ট্যাক্স) অথবা $12.51 (লাইন-লেভেল ট্যাক্স)। একটি নিয়ম বেছে নিন, ডকুমেন্ট করুন, এবং ধারাবাহিকভাবে অনুসরণ করুন।

এখন শুধুমাত্র আইটেম B রিফান্ড করুন। এর ডিসকাউন্টকৃত মূল্য রিফান্ড করুন (225 cents) এবং তার সাথে যে ট্যাক্সটি যোগ্য সেটি। লাইনে-স্তরের ট্যাক্স হলে সেটা হবে 225 + 20 = 245 cents ($2.45)। আপনার বাকি টোটালগুলো তখনও সঠিকভাবে রিকনসাইল হবে।

পরবর্তী সময়ে কোনো পার্থক্য ব্যাখ্যা করতে, প্রতিটি চার্জ ও রিফান্ডের জন্য এই মানগুলো লগ করুন:

• প্রতিটি লাইনের নেট সেন্ট, প্রতিটি লাইনের ট্যাক্স সেন্ট, এবং ব্যবহৃত রাউন্ডিং মোড
• ইনভয়েস ডিসকাউন্ট সেন্ট এবং এটি কিভাবে বরাদ্দ করা হয়েছিল
• ট্যাক্স রেট ও ব্যবহার করা ট্যাক্সেবল বেস সেন্ট
• শিপিং/ফি সেন্ট এবং এগুলো ট্যাক্সেবল কি না
• ফাইনাল টোটাল সেন্ট এবং রিফান্ড সেন্ট

টাকা গণনা পরীক্ষা করার উপায়

অধিকাংশ টাকা বাগ "গণিতের বাগ" নয়। এগুলো রাউন্ডিং, অর্ডারিং, এবং ফরম্যাটিং বাগ যা নির্দিষ্ট কার্ট বা তারিখে প্রদর্শিত হয়। ভালো টেস্টগুলো এসব কেসগুলিকে বিরক্তিকর করে তোলে।

গোল্ডেন টেস্ট দিয়ে শুরু করুন: নির্দিষ্ট ইনপুটগুলোর জন্য মাইনর-ইউনিটে (যেমন সেন্ট) স্পষ্ট প্রত্যাশিত আউটপুট দিন। অ্যাসার্শনগুলো কড়াকড়ি রাখুন। যদি একটি আইটেম 199 সেন্ট এবং ট্যাক্স 15 সেন্ট হয়, টেস্টটি ইন্টিজার মান চেক করুন, ফরম্যাটেড স্ট্রিং নয়।

কিছু গোল্ডেন কভার করতে পারে:

• ট্যাক্স, তারপর ডিসকাউন্ট, তারপর ফি সহ একটি সিঙ্গেল লাইন আইটেম (প্রতিটি মাঝামাঝি রাউন্ডিং চেক করুন)
• অনেক লাইন আইটেম যেখানে ট্যাক্স প্রতিটি লাইনে রাউন্ড vs সাবটোটালে রাউন্ড — আপনার নির্বাচিত নিয়ম যাচাই করুন
• রিফান্ড এবং আংশিক রিফান্ড (সাইন এবং রাউন্ডিং দিক পরীক্ষা করুন)
• কনভার্সন রাউন্ড-ট্রিপ (A থেকে B থেকে A) যেখানে রাউন্ডিং কোথায় হয় তা নির্ধারিত
• এজ মান (1 সেন্ট আইটেম, বড় পরিমাণ, খুব বড় টোটাল)

তারপর প্রোপার্টি-বেসড চেক যোগ করুন (বা সহজ র‍্যান্ডম টেস্ট) যাতে বিস্ময় ধরা পড়ে। একবার প্রত্যাশিত নির্দিষ্ট সংখ্যার বদলে, ইনভেরিয়ান্টগুলো assert করুন: মোট সব লাইনের সমান, কখনো fractional minor unit দেখা যাবে না, এবং “total = subtotal + tax + fees - discounts” সবসময় বজায় থাকে।

ক্রস-প্ল্যাটফর্ম টেস্টিং গুরুত্বপূর্ণ কারণ ফলাফল ব্যাকএন্ড ও ক্লায়েন্টের মধ্যে ড্রিফট করতে পারে। যদি আপনার Go ব্যাকএন্ড, Vue ওয়েব অ্যাপ এবং Kotlin/SwiftUI মোবাইল থাকে, প্রতিটি লেয়ারে একই টেস্ট ভেক্টর চালান এবং ইন্টিজার আউটপুটগুলো তুলনা করুন, UI স্ট্রিং নয়।

অবশেষে, সময়-ভিত্তিক কেসগুলো টেস্ট করুন। একটি ইনভয়েসে ব্যবহৃত ট্যাক্স রেট সংরক্ষণ করুন এবং পরে রেট বদলে গেলেও পুরনো ইনভয়েস একই ফলাফল রিক্যালকুলেট করে কিনা যাচাই করুন। অনেক "আগে ম্যাচ করত" বাগ এখান থেকেই জন্ম নেয়।

সাধারণ ফাঁদগুলো যা এড়াতে হবে

অধিকাংশ এক-পয়সার বাগ গণিতগত ত্রুটি নয়; এগুলো নীতিগত ত্রুটি: কোড ঠিকই আপনার বলে দেওয়া কাজটাই করে, শুধু ফাইন্যান্স যা চায় সেটা না করে।

রক্ষার জন্য কিছু ট্র্যাপ:

• বছরের আগেই রাউন্ডিং করা: যদি আপনি প্রতি লাইনে রাউন্ড করেন, তারপর সাবটোটাল রাউন্ড করেন, তারপর ট্যাক্স রাউন্ড করেন, টোটাল ড্রিফট হতে পারে। একটি নিয়ম নির্বাচন করুন (উদাহরণ: লাইন বনাম ইনভয়েস ট্যাক্স) এবং যেখানে নীতি অনুমোদন করে সেখানে মাত্র রাউন্ড করুন।
• একই ফিল্ডে মিশ্রিত মুদ্রা যোগ করা: USD এবং EUR একসাথে "টোটাল" ফিল্ডে যোগ করা ক্ষুদ্র মনে হলেও রিফান্ড, রিপোর্টিং বা রিকনসিলিয়েশনে সমস্যা করে। পরিমাণগুলো তাদের মুদ্রা ট্যাগ সহ রাখুন এবং ক্রস-কারেন্সি যোগ করার আগে একটি সম্মত রেট ব্যবহার করে কনভার্ট করুন।
• ইউজার ইনপুট ভুলভাবে পার্স করা: ইউজাররা টাইপ করে "1,000.50", "1 000,50" বা "10.0"। যদি আপনার পার্সার একটি ফরম্যাট ধরে নেবে, আপনি নীরবে 100050 চার্জ করতে পারেন বা ট্রেইলিং জিরো ফেলে দিতে পারেন। ইনপুট নরমালাইজ করুন, ভ্যালিডেট করুন, এবং মাইনর ইউনিটে সংরক্ষণ করুন।
• API বা ডাটাবেসে ফরম্যাট করা স্ট্রিং ব্যবহার করা: "$1,234.56" শুধুই ডিসপ্লের জন্য। যদি আপনার API এটা গ্রহণ করে, অন্য সিস্টেম আলাদা ভাবে পার্স করতে পারে। ইন্টিজার (মাইনর ইউনিট) এবং currency কোড পাঠান, এবং প্রতিটি ক্লায়েন্ট লোকালি ফরম্যাট করুক।
• ট্যাক্স নিয়ম বা রেট টেবিল ভ্যার্সনিং না করা: ট্যাক্স রেট বদলায়, ছাড়পত্র বদলায়, এবং রাউন্ডিং নিয়ম বদলায়। যদি আপনি পুরনো রেট ওভাররাইট করেন, পুরনো ইনভয়েস পুনরুত্পাদন করা অসম্ভব হয়ে পড়বে। প্রতিটি ক্যালকুলেশনে একটি ভার্সন বা কার্যকরতার তারিখ সংরক্ষণ করুন।

একটি বাস্তবতা চেক: সোমবার ক্রিয়েট করা একটি চেকআউট গত মাসের ট্যাক্স রেট ব্যবহার করে; ব্যবহারকারী শুক্রবার রিফান্ড নেয় পরে রেট বদলে গেলে। যদি আপনি ট্যাক্স রুল ভার্সন ও মূল রাউন্ডিং নীতি সংরক্ষণ না করে থাকেন, আপনার রিফান্ড মূল রসিদের সাথে মিলবে না।

দ্রুত চেকলিস্ট এবং পরবর্তী ধাপ

কম বিস্ময় পেতে চান? টাকাকে একটি ছোট সিস্টেম হিসেবে বিবেচনা করুন যার পরিষ্কার ইনপুট, নিয়ম এবং আউটপুট আছে। অধিকাংশ এক-পয়সার বাগ বাঁচে কারণ কেউ লিখে রাখেনি কোথায় রাউন্ডিং অনুমোদিত।

শিপ করার আগে চেকলিস্ট:

• ডাটাবেস, বিজনেস লজিক এবং API-তে সব জায়গায় মাইনর ইউনিটে (সেন্টের মতো) পরিমাণ সংরক্ষণ করুন।
• সব গাণিতিক ইন্টিজারে করুন, এবং কেবল দেখানোর সময় কনভার্ট করে ডেসিমালে দেখান।
• প্রতিটি ক্যালকুলেশনের জন্য একটি রাউন্ডিং পয়েন্ট বেছে নিন (ট্যাক্স, ডিসকাউন্ট, ফি, FX) এবং এক জায়গায় প্রয়োগ করুন।
• সঠিক মুদ্রা নিয়ম (দশমিক, সেপারেটর, নেগেটিভ ভ্যালু) ব্যবহার করে ওয়েব ও মোবাইলে ধারাবাহিক ফরম্যাটিং করুন।
• এজ কেসগুলোর জন্য টেস্ট যোগ করুন: 0.01, কনভার্সনে পুনরাবৃত্ত দশমিক, রিফান্ড, আংশিক ক্যাপচার, এবং বড় কার্ট।

প্রতি ক্যালকুলেশন টাইপের জন্য একটি রাউন্ডিং নীতি লিখে রাখুন। উদাহরণ: "ডিসকাউন্ট প্রতিটি লাইন আইটেমে নিকটতম সেন্টে রাউন্ড করা হবে; ট্যাক্স ইনভয়েস টোটালে রাউন্ড করা হবে; রিফান্ডগুলো মূল রাউন্ডিং পথ পুনরাবৃত্তি করবে।" এই নীতিগুলো কোডের পাশে এবং টিম ডকে রাখুন যাতে সময়ের সঙ্গে না বদলে যায়।

প্রতিটি গুরুত্বপূর্ণ টাকা ধাপের জন্য হালকা ওজনের লগ রাখুন। ইনপুট ভ্যালু, নির্বাচিত পলিসি নাম, এবং মাইনর-ইউনিটে আউটপুট ধরে রাখুন। যখন গ্রাহক বলে "আমাকে এক পয়সা বেশি দেয়ার হয়েছে", আপনি একটি একক লাইনে দেখে জানতে পারবেন কেন।

প্রোডাকশনে লজিক বদলানোর আগে একটি ছোট অডিট পরিকল্পনা করুন। বাস্তব পুরনো অর্ডারের স্যাম্পলে নতুন লজিক দিয়ে টোটালগুলো আবার ক্যালকুলেট করুন, পুরোনো বনাম নতুন ফলাফল তুলুন এবং মিসম্যাচ সংখ্যা গুনুন। কিছু মিসম্যাচ ম্যানুয়ালি রিভিউ করে নিশ্চিত করুন সেটা আপনার নতুন নীতির সাথে মেলে।

আপনি যদি এই ধরনের end-to-end ফ্লো বানাতে চান কিন্তু তিনবার একই নিয়ম লিখতে চান না, AppMaster ব্র্যান্ডটি এমন সম্পূর্ণ অ্যাপের জন্য ডিজাইন করা আছে। আপনি Data Designer দিয়ে PostgreSQL-এ amount_minor ইন্টিজার মডেল করতে পারেন, একটি Business Process-এ রাউন্ডিং ও ট্যাক্স স্টেপ একবার বাস্তবায়ন করতে পারেন, এবং একই লজিক ওয়েব ও নেটিভ মোবাইল UI-তে reuse করতে পারেন।