7 common "decimal processing" models

In the transaction and payment categories, we often find that the decimal is not divided. This article summarizes 7 common "decimal processing" models for you to choose a suitable model in your actual scenario.

In the transaction category and payment category, there are often decimal inexhaustible divisions, or the number of decimal places in the multiplier result is too many, and the decimal needs to be processed, because the database stores decimals, and often sets the number of digits or the minimum unit, such as keeping two decimal places, or the minimum unit of the amount is a minute, and the value can only be an integer.

Common businesses are as follows:

• Decimal processing of the preferential apportionment amount for the scope of the transaction
• The decimal amount of each account is processed for multiple account splits in the payment category
• Handling of collection fees
• Handling fee for multiple refunds
• Treatment of interest

1. Endless scenes

When apportioning, if an order is discounted by 10 yuan and distributed to 3 commodities, then how much is apportioned for each commodity, it is obvious that 10➗3 = 3.333... It is inexhaustible, at this time, how much discount is allocated to each commodity in the end?When dividing the account, such as a collection of 100 yuan, now it is necessary to divide the account 7 equally, how much should each be divided, here 100➗7=14.2857143... , so how to perform account splitting?

2. Scenarios where the number of multiplicative digits increases

When calculating the handling fee, for example, the handling fee rate is 0.38%, and a collection is 568 yuan, at this time, the handling fee receivable is 568 * 0.38% = 2.158 If you need to keep two decimal places, then how much is the final handling fee?

The big principle is definitely "fairness", what is fairness is "not to pay a penny, not to charge a penny, just right", and the appearance of decimal to deal with is also a last resort, then we must also ensure fairness as much as possible, if it is really impossible to do absolute fairness, then all parties can reach a consensus, can accept.

The following summarizes 7 common decimal processing methods and applicable scenarios, all of which are premised on retaining 2 decimal places.

1. Tail removal method

This method will allow the small number to be used in the "cannot be higher" restriction scenario, such as multiple account splits, and the total account amount cannot be exceeded, then the previous accounts can be directly detained, and finally adjust the example:

568 * 0.38% = 2.159, after the tail is 2.15, like the interest that the bank gives to the customer, you can consider the tail method, so that on the whole, it can reduce the bank's capital cost In addition, we often use the tail method to buy things in our daily life, such as buying vegetables, a total of 2.53, you may say "boss, don't ask for a fraction", directly 2.5 can be.

2. Advance the method

As long as there is a value after the number of digits is reserved, it will be directly advanced to one, and the number will be too large to be used in the "not less than" restriction scenario, for example, if you go to buy Coke for the leader, a total of 8 leaders, one bottle per person, if a box has a total of 6 bottles of Coke, then 8➗6 = 1.3333... , can only buy 2 boxes (not for sale) Example: 568 * 0.38% = 2.151, if there are a number of 1, the result is 2.16 after processing

3. Rounding

This is the most common processing method, the overall value will be larger, less than 5 when rounded, greater than or equal to 5 into one like WeChat's transaction collection fee is the "rounding method" example: 568 * 0.38% = 2.158, 8 is greater than 5 directly into 1, is 2.16

4. Round up to five in pairs

This method is more accurate than "rounding", and when the amount of data is large, the result is closer to the true value, because in 1, 2, 3, 4, 5, 6, 7, 8, 9, 5, 5, 5, 5, 7, 8, 9, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5 Then in order to be fairer, take 5 as the dividing line, less than 5 rounded, greater than 5 into 1, and when equal to 5, the situation is handled if there is a number after 5 then into 1, such as 2.12500009, because there is a number after 5, then enter 1, the result is 2.13 If there is no number after 5, it depends on whether the number in front of 5 is odd or even, and when the odd number is rounded 5 into 1, and the even number is rounded off 5 (0 is even), for example: 2.175, the "7" in front of 5 If it is an odd number, then round 5 into 1, the result is 2.182.165, and the "6" in front of 5 is an even number, then round 5 into nothing, the result is 2.16

5. Remainder distribution, make-up method

When the division is not exhausted, set the allocation strategy for the remainder, first deal with the part that is exhausted, and finally make up the difference, so that there are individual errors, but there is no error as a whole, such as the apportionment example at the beginning:

An order discount of 10 yuan, allocated to 3 goods, then how much each commodity is apportioned, it is obvious that 10➗3 is not divided, the integer result is 3, the remainder is 1, then 2 commodities are allocated 3, and the other is allocated 4 If 2 decimal places are retained, then 10➗3 = 3.333333... , 2 of which 3.33 are apportioned, and the last commodity is apportioned 10-3.33-3.33=3.34 This method can be used for preferential apportionment and account sharing, including the processing of refund handling fees, and the remainder allocation method can be used in conjunction with other methods in WeChat's refund handling fee rules to ensure ultimate fairness, such as handling fee processing when WeChat refunds multiple times, according to the "round down" in front The last refund refunds all the handling fees, which is actually a strategy to make up for the remainder, although the previous handling fees are less refunded, but in the end all of them are made up for you

6. Improvement Arrangement

If there is a value, it will be advanced to 1, which will make the value larger, but it will be adjusted in the last time to ensure that there is no error as a whole, for example, the handling fee for WeChat Pay partial refund before the rule adjustment is "rounded up", which means that when there are multiple refunds, the handling fee returned to the merchant in the previous one is high Example: 2.12100009, rounding up the result is 2.13, which looks similar to the effect of the further method

7. Round down

Similar to the rounding up method, the current handling fee return processing strategy for multiple refunds of WeChat Pay is "rounding down" WeChat Pay adopts a variety of decimal processing strategies, and the transaction fee is "rounded", and "rounding down + remainder" is used when multiple refunds are made, for example, the transaction example at the beginning: the handling fee rate is 0.38%, and a collection is 568 yuan, at this time, the handling fee receivable is 568*0.38%=2.158, "rounding" In the future, if it is 2.16, if the full refund is refunded, 2.16 can be refunded directly, if it is partial, the refund fee calculation rules are:

Refund fee = refund amount / total amount * transaction fee

• If the first refund is 268 yuan, then 268/568*2.16=1.019=1.01 (rounded down)
• The second refund is 169 yuan, then 169/568 * 2.16 = 0.642 = 0.64 (round down)
• The third refund of 131 yuan, that is, the refund of the remaining all, the refund fee should be 2.16-1.01-0.64 = 0.51 (the remainder is distributed, the difference is adjusted)

Finally, in practice, we can flexibly select and combine according to the actual business situation, or design a better model, such as "usually round down, and make up the overall difference at the end of the year", etc., to ensure that the model implementation is as fair and acceptable to everyone as possible.

Columnist

Chen Tian Universe, WeChat public account: Chen Tian Universe, everyone is a product manager columnist. Columnist in the field of multi-platform payment, 10 years of senior products, focusing on providing in-depth payment content and services for 100,000 payment product managers, payment institutions and enterprises!

This article was originally published by Everyone is a Product Manager and is prohibited from reprinting without permission.

The title image is from Unsplash and is licensed under CC0.

The views in this article only represent the author's own, everyone is a product manager, and the platform only provides information storage space services.