Posted by
Jacques Le Roux on
URL: http://ofbiz.116.s1.nabble.com/OFBiz-Users-Ofbiz-use-in-the-UK-tp135221p135226.html
> The problem, however, is that the line level VAT, as we call it, needs
> to have 3 decimal digits rounded in a specific way (there are various
> algorithms) and the final VAT invoice total is the sum of the line level
> VAT figures, rounded or truncated to 2 decimal digits.
That's a good point Tarlika,
There is also some informations in Wiki
see
http://ofbizwiki1.go-integral.com/Edit.jsp?page=Accounting :: National
requirements
and in peculiar "Euro conversion"
BTW here the wiki seems to have some problems with indentation...
I tried some modifications but none worked.
Jacques
----- Original Message -----
From: "T E Schmitz" <
[hidden email]>
Cc: "OFBiz Users / Usage Discussion" <
[hidden email]>
Sent: Friday, August 26, 2005 4:14 PM
Subject: Re: [OFBiz] Users - Ofbiz use in the UK?
> T E Schmitz wrote:
> >
> >>> I was just trying to point out how hellishly complicated VAT
> >>> classification, calculation and invoicing can get in the UK and
> >>> undoubtedly in other countries, too.
> >
> >>> There are specific rules for rounding (on which digit, when up, when
> >>> down); invoices need to detail VAT codes for every item, etc, etc
> >
> > I have only just started looking at OFBiz and we are intending to use it
> > for an ecommerce solution, for which the VAT issue needs to be
> > addressed. ...
>
> I have dug a bit further ... which still makes me no OFBiz expert. But I
> would like to add a few more thoughts.
>
> Apart from the floating point problem
> (
http://jira.undersunconsulting.com/browse/OFBIZ-377), there might be
> the need to restructure the code to be able to implement VAT calculation
> appropriate for the UK.
>
> I looked at
> applications\order\src\org\ofbiz\order\order\OrderServices.java +
> OrderReadHelper.java and as far as I understand SalesTax is intertwined
> with other orderAdjustments, for instance shipping. The SalesTax figure
> is calculated for each Product and truncated to two decimal digits. The
> result is a List of orderAdjustments, which is summed up in
OrderReadHelper.
>
> The problem, however, is that the line level VAT, as we call it, needs
> to have 3 decimal digits rounded in a specific way (there are various
> algorithms) and the final VAT invoice total is the sum of the line level
> VAT figures, rounded or truncated to 2 decimal digits.
>
> I briefly thought about fudging the VAT related code in those two source
> files but I wasn't too sure how or whether the VAT interacts with the
> other adjustments and am just ignoring the issue for the moment.
>
> I would think that if you follow Jacopo's suggestion to implement VAT as
> a service then it would really need to be separate from the other
> adjustments.
>
> --
>
>
> Regards/Gruß,
>
> Tarlika Elisabeth Schmitz
>
> _______________________________________________
> Users mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/users>
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users