OFBiz - Re: Dev

May 05, 2006; 10:19pm

Jacopo,

Sorry I didn't get back to you more quickly on the last email...

Yes, I think this is just fine and will be a nice enhancement.

-David

Jacopo Cappellato wrote:

I've thought a lot about it and I really think that adding the following 
fields to the InvoiceItem entity would be a nice improvement:

parentInvoiceId
parentInvoiceItemSeqId

A recursive relation to the InvoiceItem is also covered in the Data 
Model Book, though the fields are then not listed in appendix A (!).

So, unless there are objections, I'm going to add the two fields and 
patch the createInvoiceForOrder service to properly fill them.

Jacopo

Jacopo Cappellato wrote:

David,

thanks for your feedback.

So, what about adding the following two new fields to the InvoiceItem 
entity:

sequenceNum
parentInvoiceItemId

?

About the *amazing* world of tax rules: what you describe here is 
exactly what we will need to implement when we will need to create 
invoices for the Italian market:

 > Of course, the only difference between calculating on the total for a
 > group of items versus per-item is one of precision, which of course
 > tax law writers and tax victims alike are concerned with, but it may
 > be acceptable (and is in many place) to use more precise sub-totals
 > that are added together and then rounded for the final value.

I.e. calculate taxes of the totals for each group of products; as you 
have suggested in another thread the idea is to add a flag in the 
TaxAuth to govern this rule and then modify the calcTax service to do 
the grouping etc...
But, at the moment, this is not in my short term plans (even if my short 
term plans usually change very quickly) :-)

Jacopo

David E Jones wrote:

Jacopo,

I haven't worked directly with the invoice stuff for a while, but I don't think there is a way to associate one invoice item with another. Of course, what it gets down to is financial information for accounting purposes, and other various things for tax calculation purposes so you do have to know which product the tax is for and such, and for auditing to make sure the taxes are correct you need some way to trace it back to the item it came from. I guess with the order-based stuff it can be most easily traced back through the order...

So, something may be needed to specify that an InvoiceItem is based on another InvoiceItem... I was going to say that putting it in the description or something might be sufficient, but for anything automated trying to trace it back that wouldn't work so well...

BTW, on the issue of tax calculation for sets of products: in some countries it may be fine to use a single rate for the entire invoice, even if products on the invoice really fall into tax categories, and the "primary" product's category would be used (not necessarily the one with the largest price tag on it...). In many cases, and even in places where that is _acceptable_ it is still optional, and sometimes preferred, to calculate tax for each group of products with a certain tax rate, or in a certain category. This is where things get messy... Of course, the only difference between calculating on the total for a group of items versus per-item is one of precision, which of course tax law writers and tax victims alike are concerned with, but it may be acceptable (and is in many place) to use more precise sub-totals that are added together and then rounded for the final value.

Still, one thing I've found about tax law, and even sales tax law is: ask 2 accountants and get 2 different answers... What you're talking about with making sure things are configurable and such is definitely the way to go to avoid problems and to make it clear to OFBiz users that this is not TaxWare, but we do hope to make it sufficiently configurable to meet your tax calculation needs.

-David

Jacopo Cappellato wrote:

Hi all,

I need to implement tax adjustments for manual invoices and I'd like to 
quickly discuss with you the design of this because I'd like to put it 
into the OFBiz codebase.

Requirement: I need a way to calculate taxes to apply to a manual 
invoice (e.g. an invoice with no order associated to it)

Use case:
- a user (or a batch service) manually enter an invoice header and one 
or more invoice items
- after that all the invoice items for the products have been entered, 
the user clicks on a "create tax adjustments" link and the InvoiceItems 
entries for the taxes are added to the invoice

Implementation details:
- a new service will be implemented "createTaxAdjForInvoice" that takes 
as input the "invoiceId" and returns the list of adjustments 
(InvoiceItems) or write them to the db
- the service above will simply prepare the data to invoke the "calcTax" 
service (so all the settings in the tax data model will be considered)

Questions: with this design, all the InvoiceItems that store tax 
information will be appended at the end of the invoice items; is this a 
problem? Is there a way to associate an InvoiceItem to another one (such 
as the tax adjustments to the product to which they refer) other than 
the position (and their sequence)?

Thanks,

Jacopo

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

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

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

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

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

Re: Dev - Manual invoices and tax adjustments