Hi Jacopo, I was reading this old thread in Nabble and I wonder if you remember having commited something reusable in what I believe is EU case (calculate Tax for each rate). Else simply forget this message.
Thanks Jacques Jacopo Cappellato wrote: > > David, > > yes, of course! > At the moment I'm in the process of setting up things in OFBiz to make > this 'Italian market' customization possible; then I'll do my best to > implement it in a clean and pluggable way: if I'll succeed, I'll send to > this list a patch for review (so that if you all think is worth > including it in OFBiz it would be great), and only after your comments > I'll eventually commit it. > So, for now, is it ok if I commit a patch to add (and fill with proper > values) the taxAuthorityRateSeqId to the following entities: > > OrderAdjustment > ReturnAdjustment > InvoiceItem (?) > > in order to maintain a reference to the tax rule that created an > adjustment and from it an invoice item? > > Jacopo > > David E. Jones wrote: >> Jacopo, >> >> As you are working on this just make sure it is an option and not the >> default way of doing it. The rules that I am most familiar with are those >> of the USA, Canada, and the UK. The rules of those three countries are >> different from what you describe. >> >> The field to configure the option should be on the TaxAuthority entity >> itself, which contains the per-jurisdiction settings for how taxes should >> be handled. >> >> -David >> >> >> Jacopo Cappellato wrote: >>> Hi David, >>> >>> please see my comments below: >>> >>> David E. Jones wrote: >>>> I think the change to add the field is fine. >>>> >>> Ok, and based of Si's comments, should I add it to the ReturnAdjustment >>> too? >>> And, is it worth adding the field to the InvoiceItem? >>> >>>> One thing to note about rates changing or in general >>>> source data changing is that reference back to the rules >>>> should not generally be meant as a substitute for data in >>>> the resulting records (in this case the OrderAdjustment record), >>>> unless the source data is considered immutable. >>>> >>>> The immutable solution is only helpful in certain circumstances. >>>> We do use it with ContactMechs and could certainly use that >>>> pattern in other places, if it's needed. Usually it's applicable >>>> when the source does not change very much, which would certainly >>>> apply in this case, but also when a reference back to it is >>>> the only source of certain information. >>>> So, I guess the question is what is the information that this >>>> would be the only source of? >>>> >>> Well, it would be nice to have a reference back to >>> TaxAuthorityRateProduct in order to retrieve the description of the rate >>> applied (this would be useful in order reports but also in invoices, if >>> we will add the reference to the InvoiceItem too). >>> >>> But another reason is the following one: >>> >>> I'm going to implement a few changes to the invoice creation routine to >>> make it compliant with the Italian (and hopefully other countries as >>> well) customs: here the sales taxes are computed in the following way: >>> >>> 1) order items are grouped together by type of sales tax applied >>> (taxAuthorityRateSeqId) >>> >>> 2) the sales tax rate is applied to the total amount of that group (not >>> to each order item) >>> >>> In fact, in Italian invoices, sales taxes are not shown for each invoice >>> items but only at the bottom of the invoice. >>> For example, consider an invoice that contains some products to which >>> the sales tax "VAT 20%" is applied (the subtotal amount is 500€) and >>> some products to which the sales tax "VAT 10%" is applied (the subtotal >>> amount is 200€); at the bottom of the invoice you'll find something like >>> this: >>> >>> |taxable income|tax type|rate|tax amount|total| >>> | 500€| VAT 20%| 20%| 100€| 600€| >>> | 200€| VAT 10%| 10%| 20€| 220€| >>> Grand Total: 820€ >>> >>> So I'll need to sum together the sales taxes and I'll need a good way to >>> group them together: I could use the rate itself (20%, 10%) but I don't >>> like this very much (I'd like to show two subtotals for two different >>> taxes with the same rate). >>> >>> Jacopo >>> >>> >>>> -David >>>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [EMAIL PROTECTED] >>> http://lists.ofbiz.org/mailman/listinfo/dev >> >> _______________________________________________ >> Dev mailing list >> [EMAIL PROTECTED] >> http://lists.ofbiz.org/mailman/listinfo/dev >> > > > _______________________________________________ > Dev mailing list > [EMAIL PROTECTED] > http://lists.ofbiz.org/mailman/listinfo/dev > > -- View this message in context: http://www.nabble.com/Re%3A-Dev---Adding-the-taxAuthorityRateSeqId-field-to%09theOrderAdjustment-entity-tp3690436p18369254.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.