Algorithms For Rounding In Fiscal Devices In Bulgaria

 

Sales through fiscal devices cannot be equated to a simple printing process in a regular ESC/POS printer. The calculations are delegated to fiscal devices which are inspected and certified before being released onto the market. 

In many cases the document about to be printed out by the fiscal device has to be visualized beforehand. In these cases, as well as when an invoice with which a fiscal receipt is to be attached, software developers need to be aware of the rounding algorithm used by fiscal devices. Incorrect rounding can be the cause of many woes. For example, an invoice is printed where the sum total does not match the sum total on the fiscal receipt. Another example would be the accumulation of such differences over time. If the income numbers in the databases of commercial sites and the references printed out from those databases are different from what is printed out by fiscal devices, a serious problem with reports at the end of the month (or year) occurs. For the sake of avoiding such troubles, several algorithms are presented in this article. They are used by the most widely-employed fiscal devices in Bulgaria - those made by Datecs Ltd.

When calculating (for the purposes of visualizing, recording or printing an invoice) the sums you need, it would be preferable to keep in mind the model of fiscal device you are working with. This is becouse depending on the model you might have to use a different rounding algorithm. 

The difference in algorithms (between models) exists due to historical reasons. For a long period of time, the firmware of a large number of Datecs Ltd models was produced in other firms. As of present, these firms have been acquired by Datecs but because these models have been on the market for years, replacing the calculations algorithm is impossible without causing inconvenience to customers which have been using the already-existing and developed software for years. 

The need for compatibility necessitates the current maintenance of the those same calculation and rounding algorithms that fiscal devices used when they were launched years ago. The articles listed below describe the differences between algorithms where it is necessary. For greater clarity, we will divide Datecs fiscal devices into groups depending on their low-level communication protocol and some differences into the API:

1. Group "A" - FP-2000, FP-800, FP-650, SK-21F, SK-31F, FMP-10, FP-700;
2. Group "B" - DP-05, DP-15, DP-25, DP-35, DP-150, WP-50;
3. Group "C" - FP-700X, DP-25X, DP-150X, WP-50X, WP-500X, FMP-55X, FMP-350X, DP-05C;

 

• Algorithm for calculating the sum for a given row of sales in a fiscal receipt;
• Algorithm for calculating a correction on a row of the sale through percentage;
• Algorithm for calculating a correction on a row of the sale through a specifically defined amount;
• Algorithm for calculating the accumulation of sums in tax groups and the current total sum;
• Algorithms for calculating the current total sum (subtotal):
  • Algorithm for the correction of a subtotal with a specifically defined amount;
  • Algorithm for the correction of a subtotal with a given percentage;
• Algorithm for calculating the accumulated net sums and tax sums;
• Algorithm for recalculating in a Z-report;

 

At the time of writing of this article, the normative documents which define the units for measurement permitted in the Republic of Bulgaria can be found here. Speaking of rounding numbers in fiscal devices, Bulgarian law mandates that it occur up to the second decimal after the decimal separator. Mathematical rounding is used in Bulgaria (in some programming languages there exists a so-called banker’s rounding, which is not to be used in this case). For the sake of additional clarification, here are some examples of mathematical rounding:

• The sum of 0.014 is rounded to one stotinka: 0.01
• The sum of 0.015 is rounded to two stotinki 0.02
• The amount of 1.1954 is rounded to 1.195
• The amount of 1.1954478 is rounded to 1.196

Usually the unit price of a single item is stored in databases without the relevant taxes added. Each of the sold items can be placed in only one tax group. Generally speaking, sales through fiscal devices involve more than one item and the software has to send the fiscal device a sum which already includes taxes from the relevant tax group.

 

---

If the data or something else in this article is incorrect - please email me to correct the article.