Dev - Questions about the way taxes are calculated
Locked
Dev - Questions about the way taxes are calculated
 
|
Hi all,
I have some questions about the way taxes are calculated (in the "calcTax" service, implemented by the TaxAuthorityServices.rateProductTaxCalc method): 1) why applicable tax rates are filtered by productStoreId? and why the productStoreId is a mandatory parameter? 2) when applicable tax rates are searched, the rates for the _NA_ geoId and taxAuthPartyId are always applied (in addition to others, country specific, taxes); shouldn't the _NA_ taxes only applied when no other taxes are found? I cannot see how the _NA_ taxes would be useful as they are now... About #1, I'd prefer to make the productStoreId optional so that, at least: - if the store is passed, only the tax rates for the product stores are applied (exactly as is now) - if the store is not passed, only the tax rates in which the productStoreId is null are applied However, I really don't see big advantages of keeping the productStoreId in the TaxAuthorityRateProduct at all. As things are implemented now, if I'm not wrong, if I want to set up a tax rate of 20% for all the Italian customers, and I have 20 stores, I'll have to create 20 different rules (one for each store) for the same rate (20%)... Thanks for your help!!! Jacopo _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Questions about the way taxes are calculated
|
|
Jacopo Cappellato wrote: > Hi all, > > I have some questions about the way taxes are calculated (in the > "calcTax" service, implemented by the > TaxAuthorityServices.rateProductTaxCalc method): > > 1) why applicable tax rates are filtered by productStoreId? and why the > productStoreId is a mandatory parameter? Answer below... > > 2) when applicable tax rates are searched, the rates for the _NA_ geoId > and taxAuthPartyId are always applied (in addition to others, country > specific, taxes); shouldn't the _NA_ taxes only applied when no other > taxes are found? I cannot see how the _NA_ taxes would be useful as they > are now... This is intended to work kind of like the productStoreId (as described below). What did you have in mind as for how this would work? The idea for them is to apply taxes when you don't care about the geo or taxAuthority, though I'm not sure that is ever a good idea anyway... > > About #1, I'd prefer to make the productStoreId optional so that, at least: > - if the store is passed, only the tax rates for the product stores are > applied (exactly as is now) > - if the store is not passed, only the tax rates in which the > productStoreId is null are applied > > However, I really don't see big advantages of keeping the productStoreId > in the TaxAuthorityRateProduct at all. > As things are implemented now, if I'm not wrong, if I want to set up a > tax rate of 20% for all the Italian customers, and I have 20 stores, > I'll have to create 20 different rules (one for each store) for the same > rate (20%)... The way this _should_ be working (unless I messed up the implementation or wasn't thinking clearly at the time...) is that the productStoreId should be passed in, and to address the issue you are talking about when querying the TARP records it should look for all with that productStoreId or that are null. That way if you want a global tax setting, you leave the productStoreId null. If you want to constrain it to a store then you set it in the TARP record. In order for that to work it should always be passed into the service though... -David _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Questions about the way taxes are calculated
|
|
David,
please see my comments below: David E Jones wrote: > > Jacopo Cappellato wrote: >> Hi all, >> >> I have some questions about the way taxes are calculated (in the >> "calcTax" service, implemented by the >> TaxAuthorityServices.rateProductTaxCalc method): >> >> 1) why applicable tax rates are filtered by productStoreId? and why the >> productStoreId is a mandatory parameter? > > Answer below... > >> 2) when applicable tax rates are searched, the rates for the _NA_ geoId >> and taxAuthPartyId are always applied (in addition to others, country >> specific, taxes); shouldn't the _NA_ taxes only applied when no other >> taxes are found? I cannot see how the _NA_ taxes would be useful as they >> are now... > > This is intended to work kind of like the productStoreId (as described below). > > What did you have in mind as for how this would work? The idea for them is to apply taxes when you don't care about the geo or taxAuthority, though I'm not sure that is ever a good idea anyway... > says: "apply _NA_ taxes unless there are other specific taxes" would more useful than the rule "apply _NA_ taxes together with other specific taxes, if any"... but this is probably a matter of taste! Plese see my other comment below: >> About #1, I'd prefer to make the productStoreId optional so that, at least: >> - if the store is passed, only the tax rates for the product stores are >> applied (exactly as is now) >> - if the store is not passed, only the tax rates in which the >> productStoreId is null are applied >> >> However, I really don't see big advantages of keeping the productStoreId >> in the TaxAuthorityRateProduct at all. >> As things are implemented now, if I'm not wrong, if I want to set up a >> tax rate of 20% for all the Italian customers, and I have 20 stores, >> I'll have to create 20 different rules (one for each store) for the same >> rate (20%)... > > The way this _should_ be working (unless I messed up the implementation or wasn't thinking clearly at the time...) is that the productStoreId should be passed in, and to address the issue you are talking about when querying the TARP records it should look for all with that productStoreId or that are null. That way if you want a global tax setting, you leave the productStoreId null. If you want to constrain it to a store then you set it in the TARP record. In order for that to work it should always be passed into the service though... > storeCond = new EntityExpr("productStoreId", EntityOperator.EQUALS, productStore.get("productStoreId")); and so only the TARP with the productStoreId field set are retrieved; so, I propose to use the following code to implement what you are describing: storeCond = new EntityExpr( new EntityExpr("productStoreId", EntityOperator.EQUALS, productStore.get("productStoreId")), EntityOperator.OR, new EntityExpr("productStoreId", EntityOperator.EQUALS, null)); However, I really like to make the productStoreId an optional parameter (I need to invoke the calcTax service to calculate the taxes of a manually created invoice with no order and no store behind it) and so I'd suggest the code in the attached patch: in this way, if the productStoreId is passed, all the TARP records for that store and also the TARP records with an empty productStoreId are selected; if the productStoreId is not passed, only the TARP records with an empty productStoreId are selected. What do you think of this? Can I go on with this change? Thanks Jacopo > -David > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev > Index: applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java =================================================================== --- applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java (revision 7537) +++ applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java (working copy) @@ -223,7 +223,15 @@ } // store expr - EntityCondition storeCond = new EntityExpr("productStoreId", EntityOperator.EQUALS, productStore.get("productStoreId")); + EntityCondition storeCond = null; + if (productStore != null) { + storeCond = new EntityExpr( + new EntityExpr("productStoreId", EntityOperator.EQUALS, productStore.get("productStoreId")), + EntityOperator.OR, + new EntityExpr("productStoreId", EntityOperator.EQUALS, null)); + } else { + storeCond = new EntityExpr("productStoreId", EntityOperator.EQUALS, null); + } // build the TaxAuthority expressions (taxAuthGeoId, taxAuthPartyId) List taxAuthCondOrList = FastList.newInstance(); _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Questions about the way taxes are calculated
|
|
In reply to this post by Jacopo Cappellato
Jacopo,
Isn't the productStoreId necessary if an instance of OFBiz had stores from more that one tax authority? On Sat, 2006-05-06 at 19:39 +0200, Jacopo Cappellato wrote: > Hi all, > > I have some questions about the way taxes are calculated (in the > "calcTax" service, implemented by the > TaxAuthorityServices.rateProductTaxCalc method): > > 1) why applicable tax rates are filtered by productStoreId? and why the > productStoreId is a mandatory parameter? > > 2) when applicable tax rates are searched, the rates for the _NA_ geoId > and taxAuthPartyId are always applied (in addition to others, country > specific, taxes); shouldn't the _NA_ taxes only applied when no other > taxes are found? I cannot see how the _NA_ taxes would be useful as they > are now... > > About #1, I'd prefer to make the productStoreId optional so that, at least: > - if the store is passed, only the tax rates for the product stores are > applied (exactly as is now) > - if the store is not passed, only the tax rates in which the > productStoreId is null are applied > > However, I really don't see big advantages of keeping the productStoreId > in the TaxAuthorityRateProduct at all. > As things are implemented now, if I'm not wrong, if I want to set up a > tax rate of 20% for all the Italian customers, and I have 20 stores, > I'll have to create 20 different rules (one for each store) for the same > rate (20%)... > > Thanks for your help!!! > > Jacopo > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev 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 - Questions about the way taxes are calculated
|
|
In reply to this post by Jacopo Cappellato
Jacopo Cappellato wrote: > Ok, this makes sense, however right now the following condition is used: > > storeCond = new EntityExpr("productStoreId", EntityOperator.EQUALS, > productStore.get("productStoreId")); > > and so only the TARP with the productStoreId field set are retrieved; > so, I propose to use the following code to implement what you are > describing: > > storeCond = new EntityExpr( > new EntityExpr("productStoreId", EntityOperator.EQUALS, > productStore.get("productStoreId")), > EntityOperator.OR, > new EntityExpr("productStoreId", EntityOperator.EQUALS, null)); This change looks good, either on its own or in the attached patch. > However, I really like to make the productStoreId an optional parameter > (I need to invoke the calcTax service to calculate the taxes of a > manually created invoice with no order and no store behind it) and so > I'd suggest the code in the attached patch: > > in this way, if the productStoreId is passed, all the TARP records for > that store and also the TARP records with an empty productStoreId are > selected; if the productStoreId is not passed, only the TARP records > with an empty productStoreId are selected. > > What do you think of this? Can I go on with this change? This is a good point... In the calcTax service it users the productStoreId to get the payToPartyId (needs this to know the tax nexuses that apply to the company party), so we should add a condition inside the service that says if the productStoreId is empty then make sure the payToPartyId is _not_ empty. For the calcTaxForDisplay service the situation is different and it is much more simple, but limited in applicability of course. It uses the taxAuthority settings on the ProductStore to determine the 1 tax authority to use rather than looking for all tax authorities where the company has a nexus (a sufficient presence to be required to pay taxes there; of course that doesn't apply for all tax authorities...). -David _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Questions about the way taxes are calculated
|
|
David,
thanks for your feedback: the mods are in svn with revision 7548 Jacopo David E Jones wrote: > > Jacopo Cappellato wrote: >> Ok, this makes sense, however right now the following condition is used: >> >> storeCond = new EntityExpr("productStoreId", EntityOperator.EQUALS, >> productStore.get("productStoreId")); >> >> and so only the TARP with the productStoreId field set are retrieved; >> so, I propose to use the following code to implement what you are >> describing: >> >> storeCond = new EntityExpr( >> new EntityExpr("productStoreId", EntityOperator.EQUALS, >> productStore.get("productStoreId")), >> EntityOperator.OR, >> new EntityExpr("productStoreId", EntityOperator.EQUALS, null)); > > This change looks good, either on its own or in the attached patch. > >> However, I really like to make the productStoreId an optional parameter >> (I need to invoke the calcTax service to calculate the taxes of a >> manually created invoice with no order and no store behind it) and so >> I'd suggest the code in the attached patch: >> >> in this way, if the productStoreId is passed, all the TARP records for >> that store and also the TARP records with an empty productStoreId are >> selected; if the productStoreId is not passed, only the TARP records >> with an empty productStoreId are selected. >> >> What do you think of this? Can I go on with this change? > > This is a good point... In the calcTax service it users the productStoreId to get the payToPartyId (needs this to know the tax nexuses that apply to the company party), so we should add a condition inside the service that says if the productStoreId is empty then make sure the payToPartyId is _not_ empty. > > For the calcTaxForDisplay service the situation is different and it is much more simple, but limited in applicability of course. It uses the taxAuthority settings on the ProductStore to determine the 1 tax authority to use rather than looking for all tax authorities where the company has a nexus (a sufficient presence to be required to pay taxes there; of course that doesn't apply for all tax authorities...). > > -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 |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |