import taxes

[antoineL]

Hi,

I tried to import the taxes (as a way to have a better grip upon the import system.)
I noticed two points:

1. If the "9" format is selected, the [Rate] field (which although it is an INTEGER, behaves as the Amount fields and is scaled by 100 in the database) is not scaled
2. The import system check if the rate exceeds xx% (some high value, I guess 100% but I did not check exactly); however it silently accepts any value below 0,01%, something which is not possible through the GUI

By the way, I do not fully understand why taxes' rates of 0% or negative are not allowed:

• 0% is the correct rate to be applied when the operation is VAT-exempted (for example, U.E. sales, or U.K. VAT around 2017) which is a different case from being Not Subjected to taxation
• Negative rates may happen for some schemes of parafiscal taxes; for example here in Spain, when (some classes of) individuals send B2B invoices, there is a part (usually 15%) which is subtracted from the to-pay amount, which represents the part of provider's income tax withheld; later the customer will declare and pay that amount directly to IRS (a similar scheme applies in France, retenue à la source, under different rules.) The general way to transcribe this system here in Spain in invoicing systems is to add that withholding as a "parafiscal" tax.
• Also, one can easily find to use the (otherwise unused) parafiscal taxes to model some kind of general deduction to be applied on the invoice, for example for early payment

Also, I saw that the parafiscal taxes are always applied cascading, that is TO-PAY=BASE * (1+Tax1) * (1+Tax2) * (1+VAT).
Is it possible to consider variation to this scheme? I do not have a good idea of the complexity this may add (Also, while I have heard of them, I never encountered actual cases when one has to use parafiscal taxes...)

Antoine

[tintinux]

If the "9" format is selected, the [Rate] field (which although it is an INTEGER, behaves as the Amount fields and is scaled by 100 in the database) is not scaled

A "9" import format means simply that the decimal separator is ignored (when present), so the value is always rounded (e.g "20").
The imported amounts or percents are always scaled by 100 in Gestinux database (2000 in the example).
This has nothing to do with the import format.
Finally, the percent will be displayed with 2 decimals and the % sign, "20%" in the example, and computed accordingly.

One can ask why we have not used the DECIMAL(n,m) datatypes. The reason is that they don't exist, or behave the same way, in all DBMS. At least 10 years ago. Scaling all amounts (and percents) by 100 did work.

We can't handle amounts expressed with 3 decimals, do you know a currency requiring more than 2 decimals ?
It is true that percents with more than 2 decimals might exist, and are not handled currently.
The number of decimals is a constant which could be changed, and it should work with 3 after rebuild. This is not perfect, I agree !
There is something to improve, but the impact is heavy !

[tintinux]

The import system check if the rate exceeds xx% (some high value, I guess 100% but I did not check exactly); however it silently accepts any value below 0,01%, something which is not possible through the GUI

Yes the rules are not the same as for keyboard input.
But, in fact, importing taxes is not really used or useful.
I agree that a specific documentation should exist, and that it would be better to have the same checks in import and manual entry (and also in EDI).

I have tried in the past to find a general way to achieve that for every imported data, but did not found anything satisfying and simple enough.
Any suggestions are welcome !

[tintinux]

I do not fully understand why taxes' rates of 0% or negative are not allowed

If you are sure that a 0% rate is useful, you can allow it in the entry. No drawback can occur, I think.

About negative rate, I'm not so sure of the possible consequences.
In my opinion, it must be allowed only after a review of all usages of the taxes.

the parafiscal taxes are always applied cascading. Is it possible to consider variation to this scheme?

Certainly !
The problem is to find a good and simple enough way to specify it.
The point is to be compatible with existing data, and of course to avoid any regression, because currently it works...

[antoineL]

We can't handle amounts expressed with 3 decimals, do you know a currency requiring more than 2 decimals ?

Since 2007, no I do not.

I remember a long time ago (XXth c.) monetary amounts was classically expressed with 4 decimals; I even believe it is the way it was set up in Microsoft Access and later Delphi (the later probably by transitivity). I do not remember currencies with 4 decimal digits subunits (on the other hand British shillings and pence and halfpenny etc before 1971 needed 4 or perhaps 5 digits, and also much extra work to format amounts.) I do remember there were mils or mills, tenth of a penny so thousands of a pound or libra. It was in use as late as 2007, when Malta formally changed to Euro.

We can never be sure of the idea governments could introduce to make their own system "unique." (Time zones show they can be very creative.) But nowadays, 2-digit monetary amounts seems to be a safe bet.

It is true that percents with more than 2 decimals might exist, and are not handled currently.
The number of decimals is a constant which could be changed, and it should work with 3 after rebuild. This is not perfect, I agree !
There is something to improve, but the impact is heavy !

I never encountered more-than-2-digit percentile taxes, but I agree it might be possible, yet not probable.

On the other hand, I do know of 3-digit prices (gasoline and electricity are common examples), and I even have at hand an example of 4-digit price which required our EDI supplier to modify its baseline logic, which expected only 3. I know this can be handled by using different units (so one would have be prices for hl of gasoline or for MWh) but then this requires to have a framework to handle different units for the quantity and for the price and to handle the relationship (and I noticed there are different units for stocks, but no relationships.)

Also, currency exchange rates seems to have settled on 6 digits...

Antoine