http://ofbiz.116.s1.nabble.com/Dev-Manual-invoices-and-tax-adjustments-tp167837p167840.html
> 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>