Repair the arithmetic that rejects a request exactly at its allowance
An application can display the expected total and still make the wrong comparison behind it. Before replacing the catalogue or changing the business allowance, inspect the values and arithmetic used by the decision.
This fictional example concerns an enquiry tool that checks the sum of requested nominal lengths against an approved administrative allowance. It does not determine how material can physically be cut, account for cutting loss or establish suitability. Those remain separate product and operational decisions.
Define the rule before investigating the rejection
The owner permits a request whose total nominal length is no greater than 2.4 metres. The tool accepts individual lengths at whole-millimetre precision. In the failing fixture, request L-51 contains three entries of 0.8 metres each.
The source entries are correct, and the receiving record preserves all three. The displayed total is 2.4 metres. Yet the tool rejects the request as exceeding the allowance, prompting staff to propose a new catalogue platform.
A mathematical sum of the approved decimal values is 2.4. The first question is why the existing comparison disagrees, not whether the business should increase its allowance to make the message disappear.
Inspect the computed value before display formatting
The inspected JavaScript implementation converts the inputs to ordinary Number values and adds them. The computed result for 0.8 + 0.8 + 0.8 is 2.4000000000000004. A strict comparison with 2.4 therefore reports that the sum is greater.
The display rounds that result to one decimal place, hiding the difference from the operator. Reformatting the message would not change the condition used for acceptance.
The ECMAScript Number specification defines its binary floating-point representation and arithmetic. Some decimal fractions cannot be represented exactly in that system. The relevant defect here is using an inexact calculation for this explicitly exact, bounded business comparison.
Use the precision the owner actually approved
The existing application can be changed without replacing its catalogue records or request process. The selected correction validates each decimal input against the agreed whole-millimetre precision and converts the accepted decimal text exactly to integer millimetres.
For this fixture, 0.8 metres becomes 800 millimetres. Three accepted entries total 2400, and the allowance is 2400. The integer comparison accepts equality. The conversion does not first perform the same inexact metre calculation and then hope that rounding recovers the intended result.
The implementation also defines bounds for individual values, entry count and total so that every intermediate result remains within the selected integer type's supported exact range. “Use integers” is incomplete advice without those limits. If the application needs a larger range or a finer precision, the numeric representation and validation contract need another decision.
Do not solve one boundary by weakening another
Adding an arbitrary tolerance to every comparison could admit values the owner never approved. Rounding an unsupported length could likewise change the request. The selected rule instead makes both precision and allowance explicit.
A request for three 0.801-metre entries totals 2403 millimetres. It remains above the 2400-millimetre allowance and is rejected for that reason. An entry of 0.8005 metres is not silently rounded to 800 millimetres; it is rejected as unsupported precision and returned for clarification under the agreed form contract.
That precision decision belongs to this fictional business process. It is not a claim that every measurement, catalogue or manufacturing application should use millimetres or discard finer information.
Complete the comparison with inspectable results
| Fixture | Exact accepted representation | Result |
|---|---|---|
| L-51: three entries of 0.8 m | 800+800+800=2400 mm | Within the 2400 mm allowance |
| L-52: three entries of 0.801 m | 801+801+801=2403 mm | Exceeds the allowance |
| L-53: one entry of 0.8005 m | Not representable under whole-mm input rule | Precision error; original input remains available to correct |
| L-54: two entries of 1.0 m | 1000+1000=2000 mm | Within the allowance |
The receiving request retains each original accepted decimal entry alongside its exact calculation value. L-51 remains the same request; the repair does not split it into new records or substitute another product. The ordinary L-54 control continues to pass.
The owner checks the resulting wording: passing this arithmetic rule means the nominal request fits the administrative allowance. It does not confirm stock, physical cutting feasibility, price or a sale. The staff assessment remains in place.
Choose repair on the evidence available
The demonstrated cause supports a focused arithmetic and validation correction, with the exact fixtures retained for regression checks. The organisation selects that scope rather than replacing the platform to resolve this one symptom.
This decision does not certify every part of the inherited application. Other issues may justify wider work. For this request, however, the evidence identifies a specific calculation that can be corrected while preserving source records and the business rule.
Bring the entered values, displayed result and rejected decision to an application-care assessment. Seeing all three makes it possible to distinguish a wrong source, a presentation problem and a computation that disagrees with the intended rule.