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
