[OFBiz] Users - Ofbiz use in the UK?

[Matt Green-3]

Hello everyone,

I've been looking at Ofbiz for a while and it looks great, I do have one
question though - has anyone experience of configuring the application to
work in the UK?

Does it handle UK accounting and VAT (sales tax) well?

Thanks in advance,

Matt

----------------------
Matt Green
Green Consulting - http://www.greenconsulting.co.uk
Technology & Software consultancy
----------------------

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[T E Schmitz]

Hello Matt,

Matt Green wrote:
> I've been looking at Ofbiz for a while and it looks great, I do have one
> question though - has anyone experience of configuring the application to
> work in the UK?
>
> Does it handle UK accounting and VAT (sales tax) well?

I've been looking at OFBiz for implementation of a UK e-commerce site
using mixed VAT codes, and like you I am wondering how OFBiz handles VAT.

HMCR (Her Majesty's Customs & Revenue) have very specific rules how to
calculate, round, and total VAT on an invoice. I would be very surprised
if the algorithm covered both US sales tax and various European
countries' VAT correctly.

A few days ago, a French guy had a VAT related question on this forum,
but he did not receive an answer.
http://lists.ofbiz.org/pipermail/users/2005-July/008313.html

--


Regards,

Tarlika Elisabeth Schmitz
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[David E. Jones]

There are various groups doing this, just look over the list of live  
sites on the ofbiz.org home page to see them (like Xinit Systems,  
Ethical Shopper, etc).

Just keep in mind that people running such stores do not always have  
time to keep up with the mailing lists and answer questions that come  
along, so try to be reasonable with your expectations.... Software  
can be free, but as much as people like to help out when they can, by  
nature they aren't free.

-David


On Jul 25, 2005, at 3:01 PM, T E Schmitz wrote:

> Hello Matt,
>
> Matt Green wrote:
>
>> I've been looking at Ofbiz for a while and it looks great, I do  
>> have one
>> question though - has anyone experience of configuring the  
>> application to
>> work in the UK?
>> Does it handle UK accounting and VAT (sales tax) well?
>>
>
> I've been looking at OFBiz for implementation of a UK e-commerce  
> site using mixed VAT codes, and like you I am wondering how OFBiz  
> handles VAT.
>
> HMCR (Her Majesty's Customs & Revenue) have very specific rules how  
> to calculate, round, and total VAT on an invoice. I would be very  
> surprised if the algorithm covered both US sales tax and various  
> European countries' VAT correctly.
>
> A few days ago, a French guy had a VAT related question on this  
> forum, but he did not receive an answer. http://lists.ofbiz.org/ 
> pipermail/users/2005-July/008313.html
>
> --
>
>
> Regards,
>
> 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

[Matt Green-3]

Thanks, I'll have a look at those sites.

Matt

> -----Original Message-----
> From: David E. Jones [mailto:[hidden email]]
> Sent: 26 July 2005 01:33
> To: OFBiz Users / Usage Discussion
> Subject: Re: [OFBiz] Users - Ofbiz use in the UK?
>
>
>
> There are various groups doing this, just look over the list of live  
> sites on the ofbiz.org home page to see them (like Xinit Systems,  
> Ethical Shopper, etc).
>
> Just keep in mind that people running such stores do not always have  
> time to keep up with the mailing lists and answer questions that come  
> along, so try to be reasonable with your expectations.... Software  
> can be free, but as much as people like to help out when they can, by  
> nature they aren't free.
>
> -David
>
>
> On Jul 25, 2005, at 3:01 PM, T E Schmitz wrote:
>
> > Hello Matt,
> >
> > Matt Green wrote:
> >
> >> I've been looking at Ofbiz for a while and it looks great, I do  
> >> have one
> >> question though - has anyone experience of configuring the  
> >> application to
> >> work in the UK?
> >> Does it handle UK accounting and VAT (sales tax) well?
> >>
> >
> > I've been looking at OFBiz for implementation of a UK e-commerce  
> > site using mixed VAT codes, and like you I am wondering how OFBiz  
> > handles VAT.
> >
> > HMCR (Her Majesty's Customs & Revenue) have very specific rules how  
> > to calculate, round, and total VAT on an invoice. I would be very  
> > surprised if the algorithm covered both US sales tax and various  
> > European countries' VAT correctly.
> >
> > A few days ago, a French guy had a VAT related question on this  
> > forum, but he did not receive an answer. http://lists.ofbiz.org/ 
> > pipermail/users/2005-July/008313.html
> >
> > --
> >
> >
> > Regards,
> >
> > 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

[T E Schmitz]

Hello,

Matt Green wrote:
> I've been looking at Ofbiz for a while and it looks great, I do have one
> question though - has anyone experience of configuring the application to
> work in the UK?
>
> Does it handle UK accounting and VAT (sales tax) well?

<quote>
Just keep in mind that people running such stores do not always have
time to keep up with the mailing lists and answer questions that come
along, so try to be reasonable with your expectations....
</quote>

David - sorry if I came across as though I was demanding an answer.

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.

For instance, I have just come another ludicrous rule from Customs &
Revenue: packaged animal feed incurs standard VAT if it is less than
12.5 kg, otherwise zero VAT.

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 don't know OFBiz well enough yet to make an informed comment where and
how these tax issues are handled. I am just presuming that each country
will need its specific VAT implementation.

--

Regards,

Tarlika Elisabeth Schmitz

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Matt Green-3]

Hi,

> 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.

It is indeed very complex though as you say, it is likely to be similar in
other countries.

I guess I could ask the question :-

Does Ofbiz inherently support configuration for differing tax regimes? Or
does it just support the regime in the USA?

(I appreciate that it is the individual implementer who is responsible for
ensuring that individual products are setup with the correct tax settings
etc as per local legislation).

Thanks,
Matt

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[David E. Jones]

> <quote>
> Just keep in mind that people running such stores do not always have
> time to keep up with the mailing lists and answer questions that come
> along, so try to be reasonable with your expectations....
> </quote>
>
> David - sorry if I came across as though I was demanding an answer.

It's no problem, you mentioned the delay so I hoped to clear this up.  
Things are a bit different in open source projects (and even among  
open source projects things vary significantly) and it can take some  
getting used to.

> 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.
>
> For instance, I have just come another ludicrous rule from Customs  
> & Revenue: packaged animal feed incurs standard VAT if it is less  
> than 12.5 kg, otherwise zero VAT.
>
> 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 don't know OFBiz well enough yet to make an informed comment  
> where and how these tax issues are handled. I am just presuming  
> that each country will need its specific VAT implementation.

Right now the tax calculation in OFBiz is fairly simple. Certain  
things can be accommodated, but there isn't a full-featured tax  
calculation piece in OFBiz. It is getting better over time, but like  
you say tax rules can get really funky... We have done integrations  
with TaxWare and the like in the past, but these are quite expensive  
and technically a pain to deal with too....

If you're interested in helping with or sponsoring any of this, that  
would be great... We actually do have some funding for various tax  
extensions right now, so some stuff will be going in soon.

-David


 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Ian Gilbert]

Hi,

Sorry for the delay on this.  We don't do much tax stuff at the moment.
We are likely to investigate this much more fully now that there is some
accounting work done.  The accounts module is likely to be one of the
principle focus of our testing over the next while.

Sorry not to be more use.

Ian

On Mon, July 25, 2005 9:01 pm, T E Schmitz wrote:

> Hello Matt,
>
>
> Matt Green wrote:
>
>> I've been looking at Ofbiz for a while and it looks great, I do have
>> one question though - has anyone experience of configuring the
>> application to work in the UK?
>>
>> Does it handle UK accounting and VAT (sales tax) well?
>>
>
> I've been looking at OFBiz for implementation of a UK e-commerce site
> using mixed VAT codes, and like you I am wondering how OFBiz handles VAT.
>
> HMCR (Her Majesty's Customs & Revenue) have very specific rules how to
> calculate, round, and total VAT on an invoice. I would be very surprised if
> the algorithm covered both US sales tax and various European countries'
> VAT correctly.
>
>
> A few days ago, a French guy had a VAT related question on this forum,
> but he did not receive an answer.
> http://lists.ofbiz.org/pipermail/users/2005-July/008313.html
>
>
> --
>
>
>
> Regards,
>
>
> 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

[T E Schmitz]

Hello David,

David E. Jones 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.
>>
>> For instance, I have just come another ludicrous rule from Customs  &
>> Revenue: packaged animal feed incurs standard VAT if it is less  than
>> 12.5 kg, otherwise zero VAT.

It can get even more funky than that: certain types of goods *MUST NOT*
be mixed on one invoice although the online purchaser could conceivably
put them into his shopping trolley together. (Sorry, no carts in
Britain!) Most users would neither know nor care about this tax issue
and therefore they can hardly be asked to shop and check out twice. In
other words: two invoices for one order need to be produced.

>> There are specific rules for rounding (on which digit, when up,  when
>> down); invoices need to detail VAT codes for every item, etc, etc
>
> Right now the tax calculation in OFBiz is fairly simple. Certain  things
> can be accommodated, but there isn't a full-featured tax  calculation
> piece in OFBiz. It is getting better over time, but like  you say tax
> rules can get really funky...

We have just implemented a /simple/ retail system - it does not cover
shenanigans like special rules for animal feed - but I am fairly
familiar with the UK VAT system in general. (I do our own VAT returns
for a start :-( ). Bear in mind though that the legislation is
constantly changing: invoice formats change, harmonization with Europe,
to name a few.

I think the VAT implementation needs to be pluggable so that any
implementor of an OFBiz solution can plug in the calculations for their
country. For instance, I implemented the VAT calculation as a
locale-based factory.

> If you're interested in helping with or sponsoring any of this, that  
> would be great... We actually do have some funding for various tax  
> extensions right now, so some stuff will be going in soon.

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. As I don't know yet which parts of OFBiz are affected (are
the sources which handle VAT all over the place?), I don't know whether
I will be able to make a usable contribution or whether I will just have
to make do with a quick fudge in the interim.


--


Regards,

Tarlika Elisabeth Schmitz
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Jacopo Cappellato]

Hi all,

there are some situations (specific markets, countries, rules etc... see
the attached messages from this list) in which tax calculation can be
very complex.

In order to provide a flexible/extensible/customizable mechanism for tax
calculation and in the same time to keep things as simple as possible,
what about implementing all tax rules as services that implement the
same service interface?
The specific service to be used for tax calculation could be directly
linked to the product (for example adding a new field to the Product
entity); if you need to implement a new tax rule, you just have to
create a new service that implements the tax service interface and
attach it to the product.
In this way we could quickly collect a good library of tax calculation
algorithms (i.e. services) ready to be used.

This is obviously only a draft of design... I'd love to get your
feedback about it.

Jacopo

David E. Jones 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.
>>
>> For instance, I have just come another ludicrous rule from Customs  &
>> Revenue: packaged animal feed incurs standard VAT if it is less  than
>> 12.5 kg, otherwise zero VAT.
>>
>> 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 don't know OFBiz well enough yet to make an informed comment  where
>> and how these tax issues are handled. I am just presuming  that each
>> country will need its specific VAT implementation.
>
>
>
> Right now the tax calculation in OFBiz is fairly simple. Certain  things
> can be accommodated, but there isn't a full-featured tax  calculation
> piece in OFBiz. It is getting better over time, but like  you say tax
> rules can get really funky... We have done integrations  with TaxWare
> and the like in the past, but these are quite expensive  and technically
> a pain to deal with too....
>
> If you're interested in helping with or sponsoring any of this, that  
> would be great... We actually do have some funding for various tax  
> extensions right now, so some stuff will be going in soon.
>
> -David
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Adrian Crum]

Jacopo,

You're idea sounds great to me! Maybe have geo-ids linked to tax calculation
services in an xml file, so a lookup can be done for each line item.


Jacopo Cappellato wrote:

> Hi all,
>
> there are some situations (specific markets, countries, rules etc... see
> the attached messages from this list) in which tax calculation can be
> very complex.
>
> In order to provide a flexible/extensible/customizable mechanism for tax
> calculation and in the same time to keep things as simple as possible,
> what about implementing all tax rules as services that implement the
> same service interface?
> The specific service to be used for tax calculation could be directly
> linked to the product (for example adding a new field to the Product
> entity); if you need to implement a new tax rule, you just have to
> create a new service that implements the tax service interface and
> attach it to the product.
> In this way we could quickly collect a good library of tax calculation
> algorithms (i.e. services) ready to be used.
>
> This is obviously only a draft of design... I'd love to get your
> feedback about it.
>
> Jacopo
>
> David E. Jones 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.
>>>
>>> For instance, I have just come another ludicrous rule from Customs  &
>>> Revenue: packaged animal feed incurs standard VAT if it is less  than
>>> 12.5 kg, otherwise zero VAT.
>>>
>>> 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 don't know OFBiz well enough yet to make an informed comment  where
>>> and how these tax issues are handled. I am just presuming  that each
>>> country will need its specific VAT implementation.
>>
>>
>>
>>
>> Right now the tax calculation in OFBiz is fairly simple. Certain  
>> things can be accommodated, but there isn't a full-featured tax  
>> calculation piece in OFBiz. It is getting better over time, but like  
>> you say tax rules can get really funky... We have done integrations  
>> with TaxWare and the like in the past, but these are quite expensive  
>> and technically a pain to deal with too....
>>
>> If you're interested in helping with or sponsoring any of this, that  
>> would be great... We actually do have some funding for various tax  
>> extensions right now, so some stuff will be going in soon.
>>
>> -David
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Si Chen-2]

Yes, I think that is a very good idea.

Si

Jacopo Cappellato wrote:

> Hi all,
>
> there are some situations (specific markets, countries, rules etc...
> see the attached messages from this list) in which tax calculation can
> be very complex.
>
> In order to provide a flexible/extensible/customizable mechanism for
> tax calculation and in the same time to keep things as simple as
> possible, what about implementing all tax rules as services that
> implement the same service interface?
> The specific service to be used for tax calculation could be directly
> linked to the product (for example adding a new field to the Product
> entity); if you need to implement a new tax rule, you just have to
> create a new service that implements the tax service interface and
> attach it to the product.
> In this way we could quickly collect a good library of tax calculation
> algorithms (i.e. services) ready to be used.
>
> This is obviously only a draft of design... I'd love to get your
> feedback about it.
>
> Jacopo
>
> David E. Jones 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.
>>>
>>> For instance, I have just come another ludicrous rule from Customs  
>>> & Revenue: packaged animal feed incurs standard VAT if it is less  
>>> than 12.5 kg, otherwise zero VAT.
>>>
>>> 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 don't know OFBiz well enough yet to make an informed comment  
>>> where and how these tax issues are handled. I am just presuming  
>>> that each country will need its specific VAT implementation.
>>
>>
>>
>>
>> Right now the tax calculation in OFBiz is fairly simple. Certain  
>> things can be accommodated, but there isn't a full-featured tax  
>> calculation piece in OFBiz. It is getting better over time, but like  
>> you say tax rules can get really funky... We have done integrations  
>> with TaxWare and the like in the past, but these are quite expensive  
>> and technically a pain to deal with too....
>>
>> If you're interested in helping with or sponsoring any of this, that  
>> would be great... We actually do have some funding for various tax  
>> extensions right now, so some stuff will be going in soon.
>>
>> -David
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[olivier.heintz Neogia.org]

Jacopo,

Yes , it's a good idea, and maybe added in the productStore the same
field, if the new service must be call for most of the product .

Olivier



Jacopo Cappellato a écrit :

> Hi all,
>
> there are some situations (specific markets, countries, rules etc...
> see the attached messages from this list) in which tax calculation can
> be very complex.
>
> In order to provide a flexible/extensible/customizable mechanism for
> tax calculation and in the same time to keep things as simple as
> possible, what about implementing all tax rules as services that
> implement the same service interface?
> The specific service to be used for tax calculation could be directly
> linked to the product (for example adding a new field to the Product
> entity); if you need to implement a new tax rule, you just have to
> create a new service that implements the tax service interface and
> attach it to the product.
> In this way we could quickly collect a good library of tax calculation
> algorithms (i.e. services) ready to be used.
>
> This is obviously only a draft of design... I'd love to get your
> feedback about it.
>
> Jacopo
>
> David E. Jones 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.
>>>
>>> For instance, I have just come another ludicrous rule from Customs  
>>> & Revenue: packaged animal feed incurs standard VAT if it is less  
>>> than 12.5 kg, otherwise zero VAT.
>>>
>>> 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 don't know OFBiz well enough yet to make an informed comment  
>>> where and how these tax issues are handled. I am just presuming  
>>> that each country will need its specific VAT implementation.
>>
>>
>>
>>
>> Right now the tax calculation in OFBiz is fairly simple. Certain  
>> things can be accommodated, but there isn't a full-featured tax  
>> calculation piece in OFBiz. It is getting better over time, but like  
>> you say tax rules can get really funky... We have done integrations  
>> with TaxWare and the like in the past, but these are quite expensive  
>> and technically a pain to deal with too....
>>
>> If you're interested in helping with or sponsoring any of this, that  
>> would be great... We actually do have some funding for various tax  
>> extensions right now, so some stuff will be going in soon.
>>
>> -David
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[T E Schmitz]

Hello Jacopo,

Jacopo Cappellato wrote:

> In order to provide a flexible/extensible/customizable mechanism for tax
> calculation and in the same time to keep things as simple as possible,
> what about implementing all tax rules as services that implement the
> same service interface?
> The specific service to be used for tax calculation could be directly
> linked to the product (for example adding a new field to the Product
> entity); if you need to implement a new tax rule, you just have to
> create a new service that implements the tax service interface and
> attach it to the product.

I think this is an excellent idea, which will be useful to all who set
up an e-commerce store!

> In this way we could quickly collect a good library of tax calculation
> algorithms (i.e. services) ready to be used.

We just need to bear in mind that our country-specific contributions
will never be 100% complete. Developers will likely only implement the
subset of VAT rules which they need for their application. But the
services can grow over time if we contribute our additions back to OFBiz.
Everyone just needs to be aware that the rules are constantly changing.
For example, HMCR* send out a leaflet every quarter detailing the latest
changes.

* Her majesty's Customs & Revenue

> 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

--


Regards/Gruß,

Tarlika Elisabeth Schmitz, Scotland
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Jacopo Cappellato]

Hi,

T E Schmitz wrote:
> Hello Jacopo,
>
> ...
> For example, HMCR* send out a leaflet every quarter detailing the latest
> changes.
>

Yes... and the main reason for this is that there are too many
bureaucrats in the world and too few developers.
I'm sure that, if HMCR's guys, instead of publishing leaflets, had to
implement their rules in Java on their own, they'd start to make things
simpler (and the world would be a better place)
;-)

Jacopo

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[T E Schmitz]

Jacopo Cappellato wrote:

> T E Schmitz wrote:
>
>> Hello Jacopo,
>>
>> ...
>> For example, HMCR* send out a leaflet every quarter detailing the
>> latest changes.
>>
>
> Yes... and the main reason for this is that there are too many
> bureaucrats in the world and too few developers.
> I'm sure that, if HMCR's guys, instead of publishing leaflets, had to
> implement their rules in Java on their own, they'd start to make things
> simpler (and the world would be a better place)
> ;-)

In the meantime we'll just have to make OFBiz simpler ;-)

Are you seriously looking into implementing a service interface?
Do you know which parts of OFBiz are affected?

--


Regards/Gruß,

Tarlika Elisabeth Schmitz
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Jacopo Cappellato]

Hi Tarlika,

tax calc is not an high priority for me right now.
However what I've suggested is rather easy to implement: I've used the
same strategy in the manufacturing component, to assign formulas for
boms calculations.
What I don't know is if this approach can be easily integrated with the
work David Jones (et others) are planning to do in the same area.
Maybe the best thing to do is to create a Jira issue, with the notes
taken from this thread, and then ask them to review it.

Kind regards,

Jacopo

T E Schmitz wrote:

> Jacopo Cappellato wrote:
>
>> T E Schmitz wrote:
>>
>>> Hello Jacopo,
>>>
>>> ...
>>> For example, HMCR* send out a leaflet every quarter detailing the
>>> latest changes.
>>>
>>
>> Yes... and the main reason for this is that there are too many
>> bureaucrats in the world and too few developers.
>> I'm sure that, if HMCR's guys, instead of publishing leaflets, had to
>> implement their rules in Java on their own, they'd start to make
>> things simpler (and the world would be a better place)
>> ;-)
>
>
> In the meantime we'll just have to make OFBiz simpler ;-)
>
> Are you seriously looking into implementing a service interface?
> Do you know which parts of OFBiz are affected?
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[T E Schmitz]

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

[Jacques Le Roux]

> 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

[David E. Jones]

I will be working on the tax stuff in a few week. Some of this work  
has already been started, you can see it in the new TaxAuthority and  
related entities. I would appreciate feedback on these. The  
SimpleSalesTaxCalc entity will be replaced, see the comments in the  
entitymodel.xml file in the order manager, especially in the  
"org.ofbiz.order.tax" package.

-David


On Aug 26, 2005, at 10:15 AM, Jacques Le Roux wrote:

>> 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
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users