[OFBiz] Dev - New TaxAuthority Data Model
Locked
[OFBiz] Dev - New TaxAuthority Data Model
 
|
Here is a short write up on the new TaxAuthority data model. This is based on some recent refinements and I plan to start coding on it right away, but I would appreciate any feedback anyone might have... -David ============================================================= --TaxAuthority The primary entity for the new tax calculation model is "TaxAuthority". In that entity there are various fields that are used to specify how the TaxAuthority operates. A TaxAuthority is identified by a Geo and a Party (the field names are taxAuthGeoId and taxAuthPartyId). We use the combination to represent the organization that is responsible for taxation and the geographic boundary it is responsible for. The main fields on the TaxAuthority entity right now that determine operational constraints are: requireTaxIdForExemption: if Y then a tax ID must be on file for the customer to receive a tax exemption taxIdFormatPattern: constrains the format of the tax ID, uses regexp syntax includeTaxInPrice: for VAT style taxation, if Y sales tax will be included in prices shown to consumers In general the TaxAuthority entity is a place for settings related to how the TaxAuthority operates, independent of categories (types) of products, and so on. --TaxAuthorityAssoc & TaxAuthorityAssocType The TaxAuthorityAssoc and related Type entity are used to describe associations or relationships between TaxAuthorities. One example of such an association would be Exemption Inheritance where if a customer is setup to receive an exemption for one TaxAuthority then that may qualify the customer for exemptions for various other TaxAuthorities. The taxAuthorityAssocTypeId is used to define how the two tax authorities are associated. --TaxAuthorityCategory The TaxAuthorityCategory entity is used to keep track of which ProductCategories are associated with the TaxAuthority. This is mainly to ease administration so that there is a place to attach categories that are created for taxation purposes so they can be easily referred to later, like when creating or updating a TaxAuthorityRateProduct record. --TaxAuthorityGlAccount The TaxAuthorityGlAccount entity is used to configure which GlAccount should be used to gather sales tax transactions, and periodically balancing entries as the tax is paid to the Tax Authority organization. --TaxAuthorityRateType The TaxAuthorityRateType entity contains information about different type of tax rates, or different types of taxes. It is used to organize the related rate entities like the TaxAuthorityRateProduct entity. Different types of rates (or taxes) include sales tax, use tax, income tax, export tax, etc. --TaxAuthorityRateProduct The TaxAuthorityRateProduct entity is one of the more complex parts of the TaxAuthority data model. This entity is used for specifying the rate to use when the conditions for the sales tax being calculated match the settings on that record. When the tax is calculated various factors are passed in and all matching records are looked up and an adjustment (line/item level) is created for each matching record (generally one per TaxAuthority). Things that are passed in typically include: - taxAuthGeoId & taxAuthPartyId OR shipping address(es) (and optionally billing address) - point of title transfer (optional) - productId - purchase price - order pre-tax subtotal - productStoreId - taxAuthorityRateTypeId Depending on what is passed in various things may be looked up in the database, like TaxAuthorities where the internal organization has a nexus (sufficient presence for taxation) based on productStoreId -> payToPartyId and the shipping (or if no shipping then billing) address. --PartyTaxAuthInfo The PartyTaxAuthInfo entity is used to keep track of information about the TaxAuthority for a given Party. This is used for customers as well as internal organizations (ie the company or divisions of it and such) to keep track of tax ID numbers whether the Party is tax exempt for the TaxAuthority, and also (mainly for internal organizations) if the Party has a "tax nexus" in/for the TaxAuthority. By tax nexus I mean that the organization has a sufficient presence there to be required to collect taxes on behalf of the TaxAuthority. --ProductStore The ProductStore entity has some settings which are tax related. For stores that represent a company or division that is in a jurisdiction that uses a VAT style tax you can specify that taxes should be included in prices shown to consumers (the showPricesWithVatTax indicator) and if this is set to Y the vatTaxAuthGeoId and vatTaxAuthPartyId should be specified so that we know which TaxAuthority to calculate taxes for (in other cases this is decided based on TaxAuthorities where the company has a nexus and the order is being shipped to, or in some cases shipped to if there is no shipping address). _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
smime.p7s (3K)
Re: [OFBiz] Dev - New TaxAuthority Data Model
|
|
Re: [OFBiz] Dev - New TaxAuthority Data Model
|
|
Si, Yes, TaxAuthorityRateProduct would replace the old SimpleSalesTaxLookup entity. It ties to a TaxAuthority so it has a taxAuthGeoId and a taxAuthPartyId, so for something such as US sales taxes a TaxAuthority should be created for each state, county, city, etc that you want to model sales tax for, and then TaxAuthorityRateProduct records should be created for each actual rate and such. -David On Oct 25, 2005, at 8:07 AM, Si Chen wrote: > David, > > This looks good. So does TaxAuthorityRateProduct replace the old > SimpleSalesTaxLookup? Would it have a field for geoId and amount > to set up the standard US sales taxes? > > Si > > David E. Jones wrote: > > >> >> Here is a short write up on the new TaxAuthority data model. This >> is based on some recent refinements and I plan to start coding on >> it right away, but I would appreciate any feedback anyone might >> have... >> >> -David >> >> ============================================================= >> >> --TaxAuthority >> >> The primary entity for the new tax calculation model is >> "TaxAuthority". In that entity there are various fields that are >> used to specify how the TaxAuthority operates. A TaxAuthority is >> identified by a Geo and a Party (the field names are taxAuthGeoId >> and taxAuthPartyId). We use the combination to represent the >> organization that is responsible for taxation and the geographic >> boundary it is responsible for. >> >> The main fields on the TaxAuthority entity right now that >> determine operational constraints are: >> >> requireTaxIdForExemption: if Y then a tax ID must be on file for >> the customer to receive a tax exemption >> taxIdFormatPattern: constrains the format of the tax ID, uses >> regexp syntax >> includeTaxInPrice: for VAT style taxation, if Y sales tax will be >> included in prices shown to consumers >> >> In general the TaxAuthority entity is a place for settings related >> to how the TaxAuthority operates, independent of categories >> (types) of products, and so on. >> >> --TaxAuthorityAssoc & TaxAuthorityAssocType >> >> The TaxAuthorityAssoc and related Type entity are used to >> describe associations or relationships between TaxAuthorities. >> One example of such an association would be Exemption Inheritance >> where if a customer is setup to receive an exemption for one >> TaxAuthority then that may qualify the customer for exemptions >> for various other TaxAuthorities. The taxAuthorityAssocTypeId is >> used to define how the two tax authorities are associated. >> >> --TaxAuthorityCategory >> >> The TaxAuthorityCategory entity is used to keep track of which >> ProductCategories are associated with the TaxAuthority. This is >> mainly to ease administration so that there is a place to attach >> categories that are created for taxation purposes so they can be >> easily referred to later, like when creating or updating a >> TaxAuthorityRateProduct record. >> >> --TaxAuthorityGlAccount >> >> The TaxAuthorityGlAccount entity is used to configure which >> GlAccount should be used to gather sales tax transactions, and >> periodically balancing entries as the tax is paid to the Tax >> Authority organization. >> >> --TaxAuthorityRateType >> >> The TaxAuthorityRateType entity contains information about >> different type of tax rates, or different types of taxes. It is >> used to organize the related rate entities like the >> TaxAuthorityRateProduct entity. Different types of rates (or >> taxes) include sales tax, use tax, income tax, export tax, etc. >> >> --TaxAuthorityRateProduct >> >> The TaxAuthorityRateProduct entity is one of the more complex >> parts of the TaxAuthority data model. This entity is used for >> specifying the rate to use when the conditions for the sales tax >> being calculated match the settings on that record. When the tax >> is calculated various factors are passed in and all matching >> records are looked up and an adjustment (line/item level) is >> created for each matching record (generally one per >> TaxAuthority). Things that are passed in typically include: >> >> - taxAuthGeoId & taxAuthPartyId OR shipping address(es) (and >> optionally billing address) >> - point of title transfer (optional) >> - productId >> - purchase price >> - order pre-tax subtotal >> - productStoreId >> - taxAuthorityRateTypeId >> >> Depending on what is passed in various things may be looked up in >> the database, like TaxAuthorities where the internal organization >> has a nexus (sufficient presence for taxation) based on >> productStoreId -> payToPartyId and the shipping (or if no >> shipping then billing) address. >> >> --PartyTaxAuthInfo >> >> The PartyTaxAuthInfo entity is used to keep track of information >> about the TaxAuthority for a given Party. This is used for >> customers as well as internal organizations (ie the company or >> divisions of it and such) to keep track of tax ID numbers whether >> the Party is tax exempt for the TaxAuthority, and also (mainly >> for internal organizations) if the Party has a "tax nexus" in/for >> the TaxAuthority. By tax nexus I mean that the organization has >> a sufficient presence there to be required to collect taxes on >> behalf of the TaxAuthority. >> >> --ProductStore >> >> The ProductStore entity has some settings which are tax related. >> For stores that represent a company or division that is in a >> jurisdiction that uses a VAT style tax you can specify that taxes >> should be included in prices shown to consumers (the >> showPricesWithVatTax indicator) and if this is set to Y the >> vatTaxAuthGeoId and vatTaxAuthPartyId should be specified so that >> we know which TaxAuthority to calculate taxes for (in other cases >> this is decided based on TaxAuthorities where the company has a >> nexus and the order is being shipped to, or in some cases shipped >> to if there is no shipping address). >> >> >> >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> 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: [OFBiz] Dev - New TaxAuthority Data Model
|
|
Re: [OFBiz] Dev - New TaxAuthority Data Model
|
|
Manuel, I'm not sure what you are talking about with the adjustments. OrderAdjustments can be associated with and OrderItem or with the OrderHeader. Unless you are using a really old version of OFBiz (I think pre-2.1.0) tax calculation is done per line item, not for the entire order. Promotions are different and different promotion actions adjust either an item or the whole order. Tax calculation in OFBiz pretty much has been and always will be calculated per item. All you need to do is look at the calcTaxInterface service definition to see that this is the case. -David On Oct 27, 2005, at 8:28 AM, Manuel Meyer wrote: > Hi David, > I think that this sounds great, and I like the includeTaxInPrice > concept. > > The only concern that I have is regarding order adjustment and > promotion on > order total. Is the new TaxAuthority mechanism going to reflect in > the tax > total that there is a global adjustment? (my question might be pure > non > sense) > > That is an issue I am facing, so I cannot use the tax mechanism fully. > I'll be glad to give a help working on that topic, if needed. > > Regards, > Manuel > > -----Message d'origine----- > De : [hidden email] [mailto:dev- > [hidden email]] De la > part de David E. Jones > Envoyé : Tuesday, October 25, 2005 11:34 AM > À : OFBiz Project Development Discussion > Objet : [OFBiz] Dev - New TaxAuthority Data Model > > > Here is a short write up on the new TaxAuthority data model. This is > based on some recent refinements and I plan to start coding on it > right away, but I would appreciate any feedback anyone might have... > > -David > > ============================================================= > > --TaxAuthority > > The primary entity for the new tax calculation model is > "TaxAuthority". In that entity there are various fields that are used > to specify how the TaxAuthority operates. A TaxAuthority is > identified by a Geo and a Party (the field names are taxAuthGeoId and > taxAuthPartyId). We use the combination to represent the organization > that is responsible for taxation and the geographic boundary it is > responsible for. > > The main fields on the TaxAuthority entity right now that determine > operational constraints are: > > requireTaxIdForExemption: if Y then a tax ID must be on file for the > customer to receive a tax exemption > taxIdFormatPattern: constrains the format of the tax ID, uses regexp > syntax > includeTaxInPrice: for VAT style taxation, if Y sales tax will be > included in prices shown to consumers > > In general the TaxAuthority entity is a place for settings related to > how the TaxAuthority operates, independent of categories (types) of > products, and so on. > > --TaxAuthorityAssoc & TaxAuthorityAssocType > > The TaxAuthorityAssoc and related Type entity are used to describe > associations or relationships between TaxAuthorities. One example of > such an association would be Exemption Inheritance where if a > customer is setup to receive an exemption for one TaxAuthority then > that may qualify the customer for exemptions for various other > TaxAuthorities. The taxAuthorityAssocTypeId is used to define how the > two tax authorities are associated. > > --TaxAuthorityCategory > > The TaxAuthorityCategory entity is used to keep track of which > ProductCategories are associated with the TaxAuthority. This is > mainly to ease administration so that there is a place to attach > categories that are created for taxation purposes so they can be > easily referred to later, like when creating or updating a > TaxAuthorityRateProduct record. > > --TaxAuthorityGlAccount > > The TaxAuthorityGlAccount entity is used to configure which GlAccount > should be used to gather sales tax transactions, and periodically > balancing entries as the tax is paid to the Tax Authority > organization. > > --TaxAuthorityRateType > > The TaxAuthorityRateType entity contains information about different > type of tax rates, or different types of taxes. It is used to > organize the related rate entities like the TaxAuthorityRateProduct > entity. Different types of rates (or taxes) include sales tax, use > tax, income tax, export tax, etc. > > --TaxAuthorityRateProduct > > The TaxAuthorityRateProduct entity is one of the more complex parts > of the TaxAuthority data model. This entity is used for specifying > the rate to use when the conditions for the sales tax being > calculated match the settings on that record. When the tax is > calculated various factors are passed in and all matching records are > looked up and an adjustment (line/item level) is created for each > matching record (generally one per TaxAuthority). Things that are > passed in typically include: > > - taxAuthGeoId & taxAuthPartyId OR shipping address(es) (and > optionally billing address) > - point of title transfer (optional) > - productId > - purchase price > - order pre-tax subtotal > - productStoreId > - taxAuthorityRateTypeId > > Depending on what is passed in various things may be looked up in the > database, like TaxAuthorities where the internal organization has a > nexus (sufficient presence for taxation) based on productStoreId -> > payToPartyId and the shipping (or if no shipping then billing) > address. > > --PartyTaxAuthInfo > > The PartyTaxAuthInfo entity is used to keep track of information > about the TaxAuthority for a given Party. This is used for customers > as well as internal organizations (ie the company or divisions of it > and such) to keep track of tax ID numbers whether the Party is tax > exempt for the TaxAuthority, and also (mainly for internal > organizations) if the Party has a "tax nexus" in/for the > TaxAuthority. By tax nexus I mean that the organization has a > sufficient presence there to be required to collect taxes on behalf > of the TaxAuthority. > > --ProductStore > > The ProductStore entity has some settings which are tax related. For > stores that represent a company or division that is in a jurisdiction > that uses a VAT style tax you can specify that taxes should be > included in prices shown to consumers (the showPricesWithVatTax > indicator) and if this is set to Y the vatTaxAuthGeoId and > vatTaxAuthPartyId should be specified so that we know which > TaxAuthority to calculate taxes for (in other cases this is decided > based on TaxAuthorities where the company has a nexus and the order > is being shipped to, or in some cases shipped to if there is no > shipping address). > > > > > > _______________________________________________ > 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: [OFBiz] Dev - New TaxAuthority Data Model
|
|
Re: [OFBiz] Dev - New TaxAuthority Data Model
|
|
Then you'll have to use per-item discounts and not per-order discounts. There has been discussion about this on the lists and the issues with adjustments in general on the order level related to various types of adjustments on the item level. There doesn't seem to be any reasonable way (that has been proposed so far) to handle this universally, so if there is something funky you want then custom code is required. You may not think that your need is "funky" or unique in any way, but get a few people in the conversation and talk about a few different scenarios and types of adjustments and things get fun. -David On Oct 28, 2005, at 6:11 AM, Manuel Meyer wrote: > Hi David, > I took a look, and saw that all the adjustments of type SALES_TAX > are per > item. I totally agree with you. > > My concern is about sales tax and promotion on order total. > If I can give you an example, > I've done the following test, using the very last version of OFBiz: > (6030) > > 1.I've removed all the promotions and price rules > 2.I've created a product (digital good) called test-tax, list price > 100. > 3.I've created the following tax entry : country _NA_, state _NA_, tax > category _NA_, rate = 10% > > > When I order 1 test-tax, my order is > Test-tax 100 > Adjustment sales tax: 10 > Grand Total 110 > > Perfect. > > Now, I've restored the promotion 'Test percent off entire purchase, no > condition [9011]' and re-order a test-tax > Test-tax price 100 > Adjustments sales tax:10 > Subtotal 100 > Promotion (10) > Sales taxes 10 > Grand Total 100 > > According to me, and to the way we calculate taxes here, the total > should > not be 100 but 99, because according to the French (European may > be?) law, > taxes must be applied after all rebates and promotions have been > applied. So > if you sale for 90 of product with a tax rate of 10%, then the tax > amount > should be 9. > > On the other hand, if you set a promo of 10%, no condition on the > product > test-tax, then the result is: > > Subtotal $100.00 > Promotion ($10.00) > Shipping and Handling $0.00 > Sales Tax $9.00 > Grand Total $99.00 > > I understand that the 2 situations are different, but don't you > think that > regarding the promotion on the total order, the promotion should also > concern taxes? Can't it lead to an accounting problem, because you > sale for > 90 of product but ask for 10 of taxes? > > Best regards, > Manuel > > -----Message d'origine----- > De : [hidden email] [mailto:dev- > [hidden email]] De la > part de David E. Jones > Envoyé : Thursday, October 27, 2005 10:17 PM > À : OFBiz Project Development Discussion > Objet : Re: [OFBiz] Dev - New TaxAuthority Data Model > > > Manuel, > > I'm not sure what you are talking about with the adjustments. > OrderAdjustments can be associated with and OrderItem or with the > OrderHeader. Unless you are using a really old version of OFBiz (I > think pre-2.1.0) tax calculation is done per line item, not for the > entire order. Promotions are different and different promotion > actions adjust either an item or the whole order. > > Tax calculation in OFBiz pretty much has been and always will be > calculated per item. All you need to do is look at the > calcTaxInterface service definition to see that this is the case. > > -David > > > On Oct 27, 2005, at 8:28 AM, Manuel Meyer wrote: > > >> Hi David, >> I think that this sounds great, and I like the includeTaxInPrice >> concept. >> >> The only concern that I have is regarding order adjustment and >> promotion on >> order total. Is the new TaxAuthority mechanism going to reflect in >> the tax >> total that there is a global adjustment? (my question might be pure >> non >> sense) >> >> That is an issue I am facing, so I cannot use the tax mechanism >> fully. >> I'll be glad to give a help working on that topic, if needed. >> >> Regards, >> Manuel >> >> -----Message d'origine----- >> De : [hidden email] [mailto:dev- >> [hidden email]] De la >> part de David E. Jones >> Envoyé : Tuesday, October 25, 2005 11:34 AM >> À : OFBiz Project Development Discussion >> Objet : [OFBiz] Dev - New TaxAuthority Data Model >> >> >> Here is a short write up on the new TaxAuthority data model. This is >> based on some recent refinements and I plan to start coding on it >> right away, but I would appreciate any feedback anyone might have... >> >> -David >> >> ============================================================= >> >> --TaxAuthority >> >> The primary entity for the new tax calculation model is >> "TaxAuthority". In that entity there are various fields that are used >> to specify how the TaxAuthority operates. A TaxAuthority is >> identified by a Geo and a Party (the field names are taxAuthGeoId and >> taxAuthPartyId). We use the combination to represent the organization >> that is responsible for taxation and the geographic boundary it is >> responsible for. >> >> The main fields on the TaxAuthority entity right now that determine >> operational constraints are: >> >> requireTaxIdForExemption: if Y then a tax ID must be on file for the >> customer to receive a tax exemption >> taxIdFormatPattern: constrains the format of the tax ID, uses regexp >> syntax >> includeTaxInPrice: for VAT style taxation, if Y sales tax will be >> included in prices shown to consumers >> >> In general the TaxAuthority entity is a place for settings related to >> how the TaxAuthority operates, independent of categories (types) of >> products, and so on. >> >> --TaxAuthorityAssoc & TaxAuthorityAssocType >> >> The TaxAuthorityAssoc and related Type entity are used to describe >> associations or relationships between TaxAuthorities. One example of >> such an association would be Exemption Inheritance where if a >> customer is setup to receive an exemption for one TaxAuthority then >> that may qualify the customer for exemptions for various other >> TaxAuthorities. The taxAuthorityAssocTypeId is used to define how the >> two tax authorities are associated. >> >> --TaxAuthorityCategory >> >> The TaxAuthorityCategory entity is used to keep track of which >> ProductCategories are associated with the TaxAuthority. This is >> mainly to ease administration so that there is a place to attach >> categories that are created for taxation purposes so they can be >> easily referred to later, like when creating or updating a >> TaxAuthorityRateProduct record. >> >> --TaxAuthorityGlAccount >> >> The TaxAuthorityGlAccount entity is used to configure which GlAccount >> should be used to gather sales tax transactions, and periodically >> balancing entries as the tax is paid to the Tax Authority >> organization. >> >> --TaxAuthorityRateType >> >> The TaxAuthorityRateType entity contains information about different >> type of tax rates, or different types of taxes. It is used to >> organize the related rate entities like the TaxAuthorityRateProduct >> entity. Different types of rates (or taxes) include sales tax, use >> tax, income tax, export tax, etc. >> >> --TaxAuthorityRateProduct >> >> The TaxAuthorityRateProduct entity is one of the more complex parts >> of the TaxAuthority data model. This entity is used for specifying >> the rate to use when the conditions for the sales tax being >> calculated match the settings on that record. When the tax is >> calculated various factors are passed in and all matching records are >> looked up and an adjustment (line/item level) is created for each >> matching record (generally one per TaxAuthority). Things that are >> passed in typically include: >> >> - taxAuthGeoId & taxAuthPartyId OR shipping address(es) (and >> optionally billing address) >> - point of title transfer (optional) >> - productId >> - purchase price >> - order pre-tax subtotal >> - productStoreId >> - taxAuthorityRateTypeId >> >> Depending on what is passed in various things may be looked up in the >> database, like TaxAuthorities where the internal organization has a >> nexus (sufficient presence for taxation) based on productStoreId -> >> payToPartyId and the shipping (or if no shipping then billing) >> address. >> >> --PartyTaxAuthInfo >> >> The PartyTaxAuthInfo entity is used to keep track of information >> about the TaxAuthority for a given Party. This is used for customers >> as well as internal organizations (ie the company or divisions of it >> and such) to keep track of tax ID numbers whether the Party is tax >> exempt for the TaxAuthority, and also (mainly for internal >> organizations) if the Party has a "tax nexus" in/for the >> TaxAuthority. By tax nexus I mean that the organization has a >> sufficient presence there to be required to collect taxes on behalf >> of the TaxAuthority. >> >> --ProductStore >> >> The ProductStore entity has some settings which are tax related. For >> stores that represent a company or division that is in a jurisdiction >> that uses a VAT style tax you can specify that taxes should be >> included in prices shown to consumers (the showPricesWithVatTax >> indicator) and if this is set to Y the vatTaxAuthGeoId and >> vatTaxAuthPartyId should be specified so that we know which >> TaxAuthority to calculate taxes for (in other cases this is decided >> based on TaxAuthorities where the company has a nexus and the order >> is being shipped to, or in some cases shipped to if there is no >> shipping address). >> >> >> >> >> >> _______________________________________________ >> 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: [OFBiz] Dev - New TaxAuthority Data Model
|
|
RE: [OFBiz] Dev - New TaxAuthority Data Model
|
|
| Free forum by Nabble | Edit this page |