Jacques,
this is just a minor comment to your post (sorry but I have no time at
the moment to study your proposal), just to clarify one little thing:
vat support has nothing to do with showing prices with vat included.
I mean that you could also want to show prices with tax included even if
the tax is not vat.
By the way, in all the ERP systems that I'm aware of, that support vat
tax, prices are entered into the system without tax (so I agree with
what you suggest here).
Just my two cents
Jacopo
Jacques Le Roux wrote:
Hi,
I waited some time and now, that after one week I got any responses on the ML,
I'm asking myself if it's because :
1. I was unclear.
2 . This is interesting nobody.
3. Everybody is OK and just wait for a patch to come and review.
Please feel free to express yourself (even using a single number ;o)
Thanks
Jacques
Of course I forgot to say that if we use this idea we shall have to had some
custom code to show prices with tax included to user
in
backoffice (catalog/prodcut/prices screen at least). And the more I thing about it the
more I believe we shall use "Product Rates"
in a drop down rather that having a new product attribute (adding unneeded
complexity) even if it seems less easy at first glance.
We may encouter rounding issues but I guess pretty much has been said/done
about this already.
Jacques
Hi,
I'm finally considering a pragmatic solution for entering gross prices (tax
included, VAT included more precisely). In my mind
and
the sequel I will assimilate tax as a VAT of a specific rate defined by
product. But I guess this is applicable for other
similar
types of taxes. Actually a gross prices is composed of 2 parts : net prices
(without tax) and tax. At some point it may be
annoying
to loose precision about them; but if we want to enter gross prices we have to
make some choices. And at the end, reconstructing
the
gross prices from the 2 parts seems easy. If we keep enough information (ie
decimals) this might be manageable. As we use now
Big
Decimal for prices this is not a problem (except in POS where I hope to change that
"soon")
Before describing my proposition (very simple actually, because I can't see any
other means) I want to be sure that taxVatCode
is
not used anymore (catalog/product screen). I can't see any use of it except in
ProductForms.xml and in
applications/product/entitydef/entitymodel.xml which are only declarations.
Anybody can confirm, please ? If it's not used
anymore
I
suppose that Tax Category Tax Vat Code and Tax Duty Code fields
are also not needed ?
My proposition is to enhance the existing UI, to allow gross prices entering.
This behaviour will be a store property (prices
tax
included or not).
Actually this will be only at the UI level because we will keep net prices in
DB. So given a price tax included and a tax rate
we
will calculate and store only net prices. By default the store has a tax rate (pecentage)
given by the "Vat Tax Auth Geo Id"
and
"Vat Tax Auth Party Id" fields pair. As tax rates may depends on products we
have to create a specific mechanism and related
field
in catalog/product screen. Either by suggesting defined "Tax Types" in "Tax Autority"
"Product Rate" in a drop down or simply by
entering a tax rate (percentage) in this field (it will then subsume - or
override in other words - the defautl store tax rate).
In
such a case we will need to add a new attribute in Product entity to store the
eventual subsuming percentage. And we may
suppress
(or recycle) related attributes and fields (ie Tax Category Tax Vat Code
and Tax Duty Code).
We shall keep at least 5 decimals for the net price, perhaps even more, what do
you think ? This seems so simple, that I'm
surely
forgetting something :o)
Anyway, we have to go further if we want to facilitate OFBiz acceptation in, at
least, Europe.
Jacques
