Re: Dev - Adding the taxAuthorityRateSeqId field to theOrderAdjustment entity
Locked
Re: Dev - Adding the taxAuthorityRateSeqId field to theOrderAdjustment entity
 
|
Hi Michael,
yes I think that a new record will need to be created (and the old one expired using the thruDate). Jacopo Michael Irving wrote: > What if the rates change? If you just update the rate, then all "old" > records using the "old" rate will show the new one instead. > > Will a new record and a new taxAuthorityRateSeqId need to be created in > order to avoid this? > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Jacopo Cappellato > Sent: Friday, March 31, 2006 9:28 AM > To: OFBiz Project Development Discussion (High Traffic) > Subject: [OFBiz] Dev - Adding the taxAuthorityRateSeqId field to > theOrderAdjustment entity > > Hi all, > > what do you think about adding the taxAuthorityRateSeqId field to the > OrderAdjustment entity? > Then, in the TaxAuthorityServices.getTaxAdjustments(...) method, when an > order adjustment (of type SALES_TAX) is created from a matching > TaxAuthorityRateProduct record, the new > OrderAdjustment.taxAuthorityRateSeqId field can be filled to keep track > of the rate applied. > > If you are ok I'll implement this within tomorrow. > > 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 |
|
|
Jacopo,
Sounds like a good idea. What about adding it to ReturnAdjustment as well? It is modeled after the same pattern. Si Jacopo Cappellato wrote: Hi Michael, yes I think that a new record will need to be created (and the old one expired using the thruDate). Jacopo Michael Irving wrote:What if the rates change? If you just update the rate, then all "old" records using the "old" rate will show the new one instead. Will a new record and a new taxAuthorityRateSeqId need to be created in order to avoid this? -----Original Message----- From: [hidden email] [[hidden email]] On Behalf Of Jacopo Cappellato Sent: Friday, March 31, 2006 9:28 AM To: OFBiz Project Development Discussion (High Traffic) Subject: [OFBiz] Dev - Adding the taxAuthorityRateSeqId field to theOrderAdjustment entity Hi all, what do you think about adding the taxAuthorityRateSeqId field to the OrderAdjustment entity? Then, in the TaxAuthorityServices.getTaxAdjustments(...) method, when an order adjustment (of type SALES_TAX) is created from a matching TaxAuthorityRateProduct record, the new OrderAdjustment.taxAuthorityRateSeqId field can be filled to keep track of the rate applied. If you are ok I'll implement this within tomorrow. 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 |
|
|
I have added these to my code
public static final String major_version = "1."; public static final String minor_version = "0.0.0"; public static final String sinceofbizversion = "3.2"; public static final String maxsupportedofbizversion = "3.2"; I have code that would loaded when classes are loaded the checks major/minor ver against sinceofbizversion and maxsupportedofbizversion. it logs info currently to show modules that are outside since and max. If you think this will be of advantage, I will create a jira with the code. _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Adding the taxAuthorityRateSeqId field to theOrderAdjustment entity
|
|
In reply to this post by Jacopo Cappellato
I think the change to add the field is fine. 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? -David Jacopo Cappellato wrote: > Hi Michael, > > yes I think that a new record will need to be created (and the old one > expired using the thruDate). > > Jacopo > > Michael Irving wrote: >> What if the rates change? If you just update the rate, then all "old" >> records using the "old" rate will show the new one instead. >> >> Will a new record and a new taxAuthorityRateSeqId need to be created in >> order to avoid this? >> >> -----Original Message----- >> From: [hidden email] [mailto:[hidden email]] On >> Behalf Of Jacopo Cappellato >> Sent: Friday, March 31, 2006 9:28 AM >> To: OFBiz Project Development Discussion (High Traffic) >> Subject: [OFBiz] Dev - Adding the taxAuthorityRateSeqId field to >> theOrderAdjustment entity >> >> Hi all, >> >> what do you think about adding the taxAuthorityRateSeqId field to the >> OrderAdjustment entity? >> Then, in the TaxAuthorityServices.getTaxAdjustments(...) method, when an >> order adjustment (of type SALES_TAX) is created from a matching >> TaxAuthorityRateProduct record, the new >> OrderAdjustment.taxAuthorityRateSeqId field can be filled to keep track >> of the rate applied. >> >> If you are ok I'll implement this within tomorrow. >> >> 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 |
Re: Dev - Adding the taxAuthorityRateSeqId field to theOrderAdjustment entity
|
|
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 [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Adding the taxAuthorityRateSeqId field to theOrderAdjustment entity
|
|
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 > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Adding the taxAuthorityRateSeqId field to theOrderAdjustment entity
|
|
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 >> [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 - Adding the taxAuthorityRateSeqId field to theOrderAdjustment entity
|
|
Hi all,
a few minutes ago I've committed a few changes for the invoicing services and data model (about some of the things already discussed in this list in the last few days); if you see something you don't like, please let me know and I'll fix it. REVISION 7176 contains some minor changes to the invoice PDF report: if you think that the information that I've added in the report are not relevant, I'll revert the commit (I've kept it separated from the other stuff mainly for this reason). Here are the two commit logs: ************************** REVISION 7175: ************************** In this commit there are two relevant changes to the invoicing process and data model: 1) added the field "taxAuthorityRateSeqId" to the OrderAdjustment, ReturnAdjustment and InvoiceItem entity to maintain a reference back to the TaxAuthorityRate that created the OrderAdjustment (and possibly ReturnAdjustment and InvoiceItem); the mods to the existing services to propagate this value are also in this commit 2) refactored the createInvoicesFromShipment services into two services: createInvoicesFromShipment and createInvoicesFromShipments; the first service simply calls the second passing a List containing one shipmentId; the second one can be used to create 'summary' invoices (i.e. an invoice that can contain order items shipped in different shipments); still the user interface to trigger the createInvoicesFromShipments service is not implemented. ************************** REVISION 7176: ************************** The (sales) shipment id (if available), used to ship the items to the customer, is now printed before the invoice items. Also, if the invoice item is of type SALES_TAX, if the description of the TaxAuthorityRate applied is available, it is shown under the description column. Jacopo 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 > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Adding the taxAuthorityRateSeqId field to theOrderAdjustment entity
Administrator
|
In reply to this post by Jacopo Cappellato
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
|
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |