Dev - Manual invoices and tax adjustments
Locked
Dev - Manual invoices and tax adjustments
 
|
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 |
Re: Dev - Manual invoices and tax adjustments
|
|
Jacopo,
When would these adjustments be made? Would it be adequate to apply the adjustments at the point the invoice status was marked as ready. Would adjustments be applied to the InvoiceItems one by one or to the (taxable) total? Could this be the default behaviour for InvoiceItems with the taxableFlag? -- Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Manual invoices and tax adjustments
|
|
Andrew,
see my comments inline: Andrew Sykes wrote: > Jacopo, > > When would these adjustments be made? > > Would it be adequate to apply the adjustments at the point the invoice > status was marked as ready. > As soon as the service is implemented, we can run it manually or trigger it from a status change. > Would adjustments be applied to the InvoiceItems one by one or to the > (taxable) total? > It depends on the tax setup; the "calcTax" service can create both item and header adjustments (if I'm not wrong at the moment, the item adj are for sales taxes and the header ones for sales taxes applied to shipping) > Could this be the default behaviour for InvoiceItems with the > taxableFlag? Yes, this is a good idea I think. Jacopo _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Manual invoices and tax adjustments
|
|
In reply to this post by Jacopo Cappellato
Jacopo,
Good idea, looked into it but ran out of time. Is it then possible to calculate for example 19% sales tax on all items and add this in a single extra item? Hans On Tuesday 02 May 2006 19:29, 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 Regards, Hans Bakker ANT Websystems Co.,Ltd (http://www.antwebsystems.com) If you want to verify that this message really originates from from the above person, download the public key from: http://www.antwebsystems.com/hbakkerAntwebsystems.asc _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
attachment0 (196 bytes)
Re: Dev - Manual invoices and tax adjustments
|
|
Hans,
this is something that we need to do also in Italy (i.e. to calculate taxes from totals instead of for each item)... however, in order to do this, I think we have to modify the way the calcTax service actually works (maybe also adding flags to the TaxAuth entity); at the moment, I'm not focused on this, because I want to create a service that calls the calcTax service in order to add taxes to an invoice. Jacopo Hans Bakker wrote: > Jacopo, > Good idea, looked into it but ran out of time. > Is it then possible to calculate for example 19% sales tax on all items and > add this in a single extra item? > > Hans > > > On Tuesday 02 May 2006 19:29, 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 |
Re: Dev - Manual invoices and tax adjustments
|
|
In reply to this post by Jacopo Cappellato
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 |
Re: Dev - Manual invoices and tax adjustments
|
|
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 |
Re: Dev - Manual invoices and tax adjustments
|
|
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 |
Re: Dev - Manual invoices and tax adjustments
|
|
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 |
|
|
Hi everybody-
Sorry I'm late to the party on this one. I think the entity model changes are a good idea. Also, Jacopo: maybe your service should at a minimum screen out InvoiceItems which are tax items in themselves. Later maybe we add support for which types of InvoiceItems and product combinations are taxable in which TaxAuth jurisdiction for which organization Party... if anybody needs it. Si David E Jones wrote: 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: _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |