While I assume there is zero chance of getting this now, I have still outlined the idea as I believe it would be of significant benefit to Managers’ functionality in the longer term.
Use case
Jurisdictions have specific requirements for when rounding must occur (which interim or final value) and what rounding is legally allowed. Performing each rounding operation is not hard but the requirement to research what is permitted / required every time a user is forced to manually performed the rounding, is a significant design disadvantage.
Tax calculation worksheets often specify rounding must be performed on multiple interim values. The end result is not the same as rounding the final value. Again doing this manually is not rocket science but is a task more reliably remembered by a computer.
Accounting software should produce the exact legally required accounting calculation, not an approximation.
I want my tax liability accounts to exactly balance when the tax authority required payment is made. To do so the VAT / GST worksheet should calculate a “Rounding adjustment”. Which is equal to the difference between the tax payment required by the tax authority and the no rounding based calculation (ie what current localisations calculate).
User interface
Drill down on values calculated by arithmetic on interim is probably not meaningful or achievable, so best left a simple report values.
Drill down on unrounded values should be maintained.
Worksheet value where rounding occurs should graphically show the user that rounding has occurred and allow drill down to the transactions producing the unrounded value. For example if the transaction sum was 12345.67 and this was rounded down in a localisation, it could be shown as (please ignore the colouring of the truncated cents display)
Report writer interface
To support report writer defined calculation, interim values must be named in some way so they can be referenced.
A spreadsheet style interface is widely recognised and probably the simplest way of defining a report. By which I mean have a localisation development environment which has a layout section (where the user can select a cell in a grid) and a formula section where the user defines what goes in each cell.
When a cell in the layout section is selected, the formula section could show the corresponding formula.
The formula panel could be virtually identical to the prior “Figures” settings except the most specific parameter near the bottom of the panel could have the option to add alternative values (data base search “or”).
For example for a custom field value
Similarly for Tax codes, however where a monetary value is produced (such as his case) then a rounding option would also be available.
A calculation field options would need to be added, built based on formula names defined earlier in the localisation. The displayed result not supporting drill down
Lists generated by the current Employee and Supplier section of the Localisation development environment could continue to be defined in the same way. An alternative would be to have a formula panel option to “For Employees Section”, “End Employee Section” to enter bounds of repeated parts of a report.
Is there any particular country-specific report you wish to implement? If there is, it’s better to show what report that is.
As for rounding, it might not even be needed to specify rounding for each figure. Rounding strategy for the entire report could be sufficent. If all figures on country-specific report should be rounded in your favour, then Manager knows which figures to round which direction without someone explicity stating that for each figure.
My understanding is the rounding requirements vary with each jurisdiction and tax type. As such the rounding method must be specified at the localisation level not the Manager code level. For example
The rounded amount required to be paid to the ATO is different the the amount accumulated in Managers GST Liability account. The rounding differences will accumulate with each BAS submission and not average out over time because of the round down policy.
Australian tax office Annual tax return
income subgroups are rounded down (floor). There are about 25 subgroups all are individually rounded down.
total income must be the sum of the rounded values
expense subgroups can be rounded up (ceiling). There are about 12
total expenses must be the sum of the rounded values.
net taxable income must be income total minus the expenses total. Which typically differs from the same calculation done to 1 cent precision by multiple dollars.
in a trust the after tax profit is the distributed, the amount available for distribution varying if a different amount if tax is actually paid.
Localisation rounding makes sense if there is a method of doing calculations with the rounded intermediate values.
Calculation in a no-coding report generation environment implies having an equation editor.
An equation editor could enable selection of variables to be operated on, from a list on Names currently known and in scope.
Selecting valid variables in this manner would greatly simplify user equation entry as the user would no longer need to know what variables were pre defined and available in any particular localisation.
This functionality is very similar to that required for other ideas, so the user interface (and possibly the code) could also be used for
Hi, regarding rounding, it would be nice to have better rounding options for the Indonesia Rupiah. 1 USD=approx Rp 14,000. Denominations of IDR include 100,000, 50,000, 20,000, 10,000, 5,000, 2,000, 1000, with the smallest coin denomination at 100. Online POS providers use rounding to IDR100, because after adding tax and service charges, there are always amounts that are impossible for cash transactions, which then creates problems for bookkeepers.
