Tax calculation for all order adjustments
Locked
12
12
Tax calculation for all order adjustments
 
|
Current problem:
we manage tax calculation for products by setting up a tax authority. The tax rate for products is set with TaxAuthorityRateProduct. In addition, tax setting for shipping and promotions adjustments can be set as special flags to each TaxAuthorityRateProduct (tax shipping/promotion Y or N). However, these 2 adjustments are taxed only if productCategoryId is empty, and these 2 adjustments look like a hack or temp solution here... I faced with a problem, where all adjustments must be taxed (very common case for VAT tax system) and it is very unhandy when you have to control the tax amount manually. In our case, the system taxes the shipping and promotion adjustments, but we have to add Sales tax to all another adjustments manually. In addition, OFBiz has tax amount correction logic, which compensates the tax difference automatically, example: Prdouct 100 euro Sales tax (VAT 19%) = 100 * 0.19 = 19 euro Shipping charge 10 euro Sales tax (VAT 19%) = 10 * 0.19 = 1.90 euro Other adjustment 20 euro Sales tax (VAT 19%) = 3.80 euro (we have to add it manually) Sales tax (VAT 19%) = - 3.80 euro (it is automatically added difference to correct the sales tax amount, because the sales tax for other adjustment is not taken into account.) and we have to delete the last tax adjustment manually. Solution: As we have TaxAuthorityRateProduct in OFBiz to manage the taxing of products, so why not to have the same mechanism for all adjustments? I propose the solution to have the TaxAuthorityRateAdjustment entity. TaxAuthorityRateAdjustment will have the following fields: Tax type (Sales Tax, etc) Store ID Adjustment Type or (All adjustments) Title Transfer ??? (I do not know, what can you suggest?) Tax Percentage From Date Thru Date Description The settings will be placed in the separate "Adjustment rates" tab, near to "Product rates" (Tax Authority settings). The UI should be very similar! RE: TaxAuthorityRateProduct we should retire Tax Shipping Tax Promotions The tax calculation service must be reworked, <service name="calcTax" engine="java" location="org.ofbiz.accounting.tax.TaxAuthorityServices" invoke="rateProductTaxCalc"> <description>Tax Authority Rate Product Calc Service</description> <implements service="calcTaxInterface"/> </service> <service name="calcTaxInterface" engine="interface" location="" invoke=""> <description>Tax Calc Service Interface</description> <attribute name="productStoreId" type="String" mode="IN" optional="true"></attribute> <attribute name="facilityId" type="String" mode="IN" optional="true"></attribute> <attribute name="payToPartyId" type="String" mode="IN" optional="true"/> <attribute name="billToPartyId" type="String" mode="IN" optional="true"></attribute> <attribute name="itemProductList" type="java.util.List" mode="IN" optional="false"></attribute> <attribute name="itemAmountList" type="java.util.List" mode="IN" optional="false"></attribute> <attribute name="itemPriceList" type="java.util.List" mode="IN" optional="false"></attribute> <attribute name="itemQuantityList" type="java.util.List" mode="IN" optional="true"></attribute> <attribute name="itemShippingList" type="java.util.List" mode="IN" optional="true"></attribute> <attribute name="orderShippingAmount" type="BigDecimal" mode="IN" optional="true"/> <attribute name="orderPromotionsAmount" type="BigDecimal" mode="IN" optional="true"/> <attribute name="shippingAddress" type="org.ofbiz.entity.GenericValue" mode="IN" optional="true"/> <attribute name="orderAdjustments" type="java.util.List" mode="OUT" optional="false"></attribute> <attribute name="itemAdjustments" type="java.util.List" mode="OUT" optional="false"></attribute> </service> This interface must have OrderAdjustment list as IN parameter. That is my draft solution. Any ideas? What is your opinion?
Kind regards,
Sergei |
Re: Tax calculation for all order adjustments
|
|
I am not familiar with VAT so I can not comment on the best way to
approach this for VAT. For USA our Tax Authority is based on Government (IRS) which I guess is similar to VAT But not on Items but gross profit at the end of the fiscal year. In manufacturing you can not charge off the deduction of the piece manufactured till the piece is sold. Under this senario the calculations are done durring the manufaturing process and is additive, then assigned to IRIS ledger.. The Tax authority for Sales is based on Geo with separate Tax authorities. Like State, County, city. These are compounded So Adjustments are complex in computations. I bring this up so that the model that is used will accommodate all Tax Authority scenarios. This was not a simple effort when we did it so I don't think a discussion would be simple. Maybe a Wiki page would be appropriate to come up with a viable design. biletnikov sent the following on 12/3/2011 8:16 AM: > *Current problem:* > we manage tax calculation for products by setting up a tax authority. > The tax rate for products is set with TaxAuthorityRateProduct. > In addition, tax setting for shipping and promotions adjustments can be set > as special flags to each TaxAuthorityRateProduct (tax shipping/promotion Y > or N). However, these 2 adjustments are taxed only if productCategoryId is > empty, and these 2 adjustments look like a hack or temp solution here... > I faced with a problem, where all adjustments must be taxed (very common > case for VAT tax system) and it is very unhandy when you have to control the > tax amount manually. In our case, the system taxes the shipping and > promotion adjustments, but we have to add Sales tax to all another > adjustments manually. > In addition, OFBiz has tax amount correction logic, which compensates the > tax difference automatically, example: > Prdouct 100 euro > Sales tax (VAT 19%) = 100 * 0.19 = 19 euro > Shipping charge 10 euro > Sales tax (VAT 19%) = 10 * 0.19 = 1.90 euro > Other adjustment 20 euro > Sales tax (VAT 19%) = 3.80 euro (we have to add it manually) > *Sales tax (VAT 19%) = - 3.80 euro * (it is automatically added difference > to correct the sales tax amount, because the sales tax for other adjustment > is not taken into account.) > and we have to delete the last tax adjustment manually. > > *Solution:* > As we have TaxAuthorityRateProduct in OFBiz to manage the taxing of > products, so why not to have the same mechanism for all adjustments? > I propose the solution to have the TaxAuthorityRateAdjustment entity. > TaxAuthorityRateAdjustment will have the following fields: > > *Tax type* (Sales Tax, etc) > *Store ID* > *Adjustment Type or (All adjustments)* > Title Transfer ??? (I do not know, what can you suggest?) > *Tax Percentage * > *From Date * > *Thru Date* > *Description* > > The settings will be placed in the separate "Adjustment rates" tab, near to > "Product rates" (Tax Authority settings). > The UI should be very similar! > > RE: TaxAuthorityRateProduct > we should retire > *Tax Shipping* > *Tax Promotions* > > The tax calculation service must be reworked, > > <service name="calcTax" engine="java" > location="org.ofbiz.accounting.tax.TaxAuthorityServices" > invoke="rateProductTaxCalc"> > <description>Tax Authority Rate Product Calc Service</description> > <implements service="calcTaxInterface"/> > </service> > > <service name="calcTaxInterface" engine="interface" location="" > invoke=""> > <description>Tax Calc Service Interface</description> > <attribute name="productStoreId" type="String" mode="IN" > optional="true"></attribute> > <attribute name="facilityId" type="String" mode="IN" > optional="true"></attribute> > <attribute name="payToPartyId" type="String" mode="IN" > optional="true"/> > <attribute name="billToPartyId" type="String" mode="IN" > optional="true"></attribute> > <attribute name="itemProductList" type="java.util.List" mode="IN" > optional="false"></attribute> > <attribute name="itemAmountList" type="java.util.List" mode="IN" > optional="false"></attribute> > <attribute name="itemPriceList" type="java.util.List" mode="IN" > optional="false"></attribute> > <attribute name="itemQuantityList" type="java.util.List" mode="IN" > optional="true"></attribute> > <attribute name="itemShippingList" type="java.util.List" mode="IN" > optional="true"></attribute> > * <attribute name="orderShippingAmount" type="BigDecimal" mode="IN" > optional="true"/> > <attribute name="orderPromotionsAmount" type="BigDecimal" mode="IN" > optional="true"/> > * <attribute name="shippingAddress" > type="org.ofbiz.entity.GenericValue" mode="IN" optional="true"/> > <attribute name="orderAdjustments" type="java.util.List" mode="OUT" > optional="false"></attribute> > <attribute name="itemAdjustments" type="java.util.List" mode="OUT" > optional="false"></attribute> > </service> > > This interface must have /OrderAdjustment/ list as IN parameter. > > That is my draft solution. > Any ideas? What is your opinion? > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4153757.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
Re: Tax calculation for all order adjustments
Administrator
|
>I am not familiar with VAT so I can not comment on the best way to
> approach this for > VAT. > For USA our Tax Authority is based on Government (IRS) which I guess is > similar to VAT But not on Items but gross profit at the end of the > fiscal year. In manufacturing you can not charge off the deduction of > the piece manufactured till the piece is sold. Under this senario the > calculations are done durring the manufaturing process and is additive, > then assigned to IRIS ledger.. > > The Tax authority for Sales is based on Geo with separate Tax > authorities. Like State, County, city. These are compounded So > Adjustments are complex in computations. > > I bring this up so that the model that is used will accommodate all Tax > Authority scenarios. > > This was not a simple effort when we did it so I don't think a > discussion would be simple. > Maybe a Wiki page would be appropriate to come up with a viable design. There is already a page with some points https://cwiki.apache.org/confluence/display/OFBIZ/VAT Jacques > > > biletnikov sent the following on 12/3/2011 8:16 AM: >> *Current problem:* >> we manage tax calculation for products by setting up a tax authority. >> The tax rate for products is set with TaxAuthorityRateProduct. >> In addition, tax setting for shipping and promotions adjustments can be set >> as special flags to each TaxAuthorityRateProduct (tax shipping/promotion Y >> or N). However, these 2 adjustments are taxed only if productCategoryId is >> empty, and these 2 adjustments look like a hack or temp solution here... >> I faced with a problem, where all adjustments must be taxed (very common >> case for VAT tax system) and it is very unhandy when you have to control the >> tax amount manually. In our case, the system taxes the shipping and >> promotion adjustments, but we have to add Sales tax to all another >> adjustments manually. >> In addition, OFBiz has tax amount correction logic, which compensates the >> tax difference automatically, example: >> Prdouct 100 euro >> Sales tax (VAT 19%) = 100 * 0.19 = 19 euro >> Shipping charge 10 euro >> Sales tax (VAT 19%) = 10 * 0.19 = 1.90 euro >> Other adjustment 20 euro >> Sales tax (VAT 19%) = 3.80 euro (we have to add it manually) >> *Sales tax (VAT 19%) = - 3.80 euro * (it is automatically added difference >> to correct the sales tax amount, because the sales tax for other adjustment >> is not taken into account.) >> and we have to delete the last tax adjustment manually. >> >> *Solution:* >> As we have TaxAuthorityRateProduct in OFBiz to manage the taxing of >> products, so why not to have the same mechanism for all adjustments? >> I propose the solution to have the TaxAuthorityRateAdjustment entity. >> TaxAuthorityRateAdjustment will have the following fields: >> >> *Tax type* (Sales Tax, etc) >> *Store ID* >> *Adjustment Type or (All adjustments)* >> Title Transfer ??? (I do not know, what can you suggest?) >> *Tax Percentage * >> *From Date * >> *Thru Date* >> *Description* >> >> The settings will be placed in the separate "Adjustment rates" tab, near to >> "Product rates" (Tax Authority settings). >> The UI should be very similar! >> >> RE: TaxAuthorityRateProduct >> we should retire >> *Tax Shipping* >> *Tax Promotions* >> >> The tax calculation service must be reworked, >> >> <service name="calcTax" engine="java" >> location="org.ofbiz.accounting.tax.TaxAuthorityServices" >> invoke="rateProductTaxCalc"> >> <description>Tax Authority Rate Product Calc Service</description> >> <implements service="calcTaxInterface"/> >> </service> >> >> <service name="calcTaxInterface" engine="interface" location="" >> invoke=""> >> <description>Tax Calc Service Interface</description> >> <attribute name="productStoreId" type="String" mode="IN" >> optional="true"></attribute> >> <attribute name="facilityId" type="String" mode="IN" >> optional="true"></attribute> >> <attribute name="payToPartyId" type="String" mode="IN" >> optional="true"/> >> <attribute name="billToPartyId" type="String" mode="IN" >> optional="true"></attribute> >> <attribute name="itemProductList" type="java.util.List" mode="IN" >> optional="false"></attribute> >> <attribute name="itemAmountList" type="java.util.List" mode="IN" >> optional="false"></attribute> >> <attribute name="itemPriceList" type="java.util.List" mode="IN" >> optional="false"></attribute> >> <attribute name="itemQuantityList" type="java.util.List" mode="IN" >> optional="true"></attribute> >> <attribute name="itemShippingList" type="java.util.List" mode="IN" >> optional="true"></attribute> >> * <attribute name="orderShippingAmount" type="BigDecimal" mode="IN" >> optional="true"/> >> <attribute name="orderPromotionsAmount" type="BigDecimal" mode="IN" >> optional="true"/> >> * <attribute name="shippingAddress" >> type="org.ofbiz.entity.GenericValue" mode="IN" optional="true"/> >> <attribute name="orderAdjustments" type="java.util.List" mode="OUT" >> optional="false"></attribute> >> <attribute name="itemAdjustments" type="java.util.List" mode="OUT" >> optional="false"></attribute> >> </service> >> >> This interface must have /OrderAdjustment/ list as IN parameter. >> >> That is my draft solution. >> Any ideas? What is your opinion? >> >> -- >> View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4153757.html >> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >> |
Re: Tax calculation for all order adjustments
|
Administrator
|
In reply to this post by biletnikov
> From: "BJ Freeman" <[hidden email]>
>>I am not familiar with VAT so I can not comment on the best way to >> approach this for >> VAT. >> For USA our Tax Authority is based on Government (IRS) which I guess is >> similar to VAT But not on Items but gross profit at the end of the >> fiscal year. In manufacturing you can not charge off the deduction of >> the piece manufactured till the piece is sold. Under this senario the >> calculations are done durring the manufaturing process and is additive, >> then assigned to IRIS ledger.. >> >> The Tax authority for Sales is based on Geo with separate Tax >> authorities. Like State, County, city. These are compounded So >> Adjustments are complex in computations. >> >> I bring this up so that the model that is used will accommodate all Tax >> Authority scenarios. >> >> This was not a simple effort when we did it so I don't think a >> discussion would be simple. >> Maybe a Wiki page would be appropriate to come up with a viable design. > > There is already a page with some points https://cwiki.apache.org/confluence/display/OFBIZ/VAT Ha , and I forgot the https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz%27s+Tax+Authority+Data+Model which is maybe not up to date... Jacques > Jacques > >> >> >> biletnikov sent the following on 12/3/2011 8:16 AM: >>> *Current problem:* >>> we manage tax calculation for products by setting up a tax authority. >>> The tax rate for products is set with TaxAuthorityRateProduct. >>> In addition, tax setting for shipping and promotions adjustments can be set >>> as special flags to each TaxAuthorityRateProduct (tax shipping/promotion Y >>> or N). However, these 2 adjustments are taxed only if productCategoryId is >>> empty, and these 2 adjustments look like a hack or temp solution here... >>> I faced with a problem, where all adjustments must be taxed (very common >>> case for VAT tax system) and it is very unhandy when you have to control the >>> tax amount manually. In our case, the system taxes the shipping and >>> promotion adjustments, but we have to add Sales tax to all another >>> adjustments manually. In addition, OFBiz has tax amount correction logic, which compensates the >>> tax difference automatically, example: >>> Prdouct 100 euro Sales tax (VAT 19%) = 100 * 0.19 = 19 euro >>> Shipping charge 10 euro >>> Sales tax (VAT 19%) = 10 * 0.19 = 1.90 euro >>> Other adjustment 20 euro >>> Sales tax (VAT 19%) = 3.80 euro (we have to add it manually) >>> *Sales tax (VAT 19%) = - 3.80 euro * (it is automatically added difference >>> to correct the sales tax amount, because the sales tax for other adjustment >>> is not taken into account.) >>> and we have to delete the last tax adjustment manually. >>> >>> *Solution:* >>> As we have TaxAuthorityRateProduct in OFBiz to manage the taxing of >>> products, so why not to have the same mechanism for all adjustments? >>> I propose the solution to have the TaxAuthorityRateAdjustment entity. >>> TaxAuthorityRateAdjustment will have the following fields: >>> >>> *Tax type* (Sales Tax, etc) >>> *Store ID* >>> *Adjustment Type or (All adjustments)* >>> Title Transfer ??? (I do not know, what can you suggest?) >>> *Tax Percentage * >>> *From Date * >>> *Thru Date* >>> *Description* >>> >>> The settings will be placed in the separate "Adjustment rates" tab, near to >>> "Product rates" (Tax Authority settings). >>> The UI should be very similar! >>> >>> RE: TaxAuthorityRateProduct >>> we should retire *Tax Shipping* >>> *Tax Promotions* >>> >>> The tax calculation service must be reworked, >>> >>> <service name="calcTax" engine="java" >>> location="org.ofbiz.accounting.tax.TaxAuthorityServices" >>> invoke="rateProductTaxCalc"> >>> <description>Tax Authority Rate Product Calc Service</description> >>> <implements service="calcTaxInterface"/> >>> </service> >>> >>> <service name="calcTaxInterface" engine="interface" location="" >>> invoke=""> >>> <description>Tax Calc Service Interface</description> >>> <attribute name="productStoreId" type="String" mode="IN" >>> optional="true"></attribute> >>> <attribute name="facilityId" type="String" mode="IN" >>> optional="true"></attribute> >>> <attribute name="payToPartyId" type="String" mode="IN" >>> optional="true"/> >>> <attribute name="billToPartyId" type="String" mode="IN" >>> optional="true"></attribute> >>> <attribute name="itemProductList" type="java.util.List" mode="IN" >>> optional="false"></attribute> >>> <attribute name="itemAmountList" type="java.util.List" mode="IN" >>> optional="false"></attribute> >>> <attribute name="itemPriceList" type="java.util.List" mode="IN" >>> optional="false"></attribute> >>> <attribute name="itemQuantityList" type="java.util.List" mode="IN" >>> optional="true"></attribute> >>> <attribute name="itemShippingList" type="java.util.List" mode="IN" >>> optional="true"></attribute> >>> * <attribute name="orderShippingAmount" type="BigDecimal" mode="IN" >>> optional="true"/> >>> <attribute name="orderPromotionsAmount" type="BigDecimal" mode="IN" >>> optional="true"/> >>> * <attribute name="shippingAddress" >>> type="org.ofbiz.entity.GenericValue" mode="IN" optional="true"/> >>> <attribute name="orderAdjustments" type="java.util.List" mode="OUT" >>> optional="false"></attribute> >>> <attribute name="itemAdjustments" type="java.util.List" mode="OUT" >>> optional="false"></attribute> >>> </service> >>> >>> This interface must have /OrderAdjustment/ list as IN parameter. That is my draft solution. >>> Any ideas? What is your opinion? >>> >>> -- >>> View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4153757.html >>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >>> |
Re: Tax calculation for all order adjustments
|
|
thanks Jacques
Jacques Le Roux sent the following on 12/4/2011 11:03 AM: >> From: "BJ Freeman" <[hidden email]> >>> I am not familiar with VAT so I can not comment on the best way to >>> approach this for >>> VAT. >>> For USA our Tax Authority is based on Government (IRS) which I guess is >>> similar to VAT But not on Items but gross profit at the end of the >>> fiscal year. In manufacturing you can not charge off the deduction of >>> the piece manufactured till the piece is sold. Under this senario the >>> calculations are done durring the manufaturing process and is additive, >>> then assigned to IRIS ledger.. >>> >>> The Tax authority for Sales is based on Geo with separate Tax >>> authorities. Like State, County, city. These are compounded So >>> Adjustments are complex in computations. >>> >>> I bring this up so that the model that is used will accommodate all Tax >>> Authority scenarios. >>> >>> This was not a simple effort when we did it so I don't think a >>> discussion would be simple. >>> Maybe a Wiki page would be appropriate to come up with a viable design. >> >> There is already a page with some points >> https://cwiki.apache.org/confluence/display/OFBIZ/VAT > > Ha , and I forgot the > https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz%27s+Tax+Authority+Data+Model > which is maybe not up to date... > > Jacques > >> Jacques >> >>> >>> >>> biletnikov sent the following on 12/3/2011 8:16 AM: >>>> *Current problem:* >>>> we manage tax calculation for products by setting up a tax authority. >>>> The tax rate for products is set with TaxAuthorityRateProduct. >>>> In addition, tax setting for shipping and promotions adjustments can >>>> be set >>>> as special flags to each TaxAuthorityRateProduct (tax >>>> shipping/promotion Y >>>> or N). However, these 2 adjustments are taxed only if >>>> productCategoryId is >>>> empty, and these 2 adjustments look like a hack or temp solution >>>> here... >>>> I faced with a problem, where all adjustments must be taxed (very >>>> common >>>> case for VAT tax system) and it is very unhandy when you have to >>>> control the >>>> tax amount manually. In our case, the system taxes the shipping and >>>> promotion adjustments, but we have to add Sales tax to all another >>>> adjustments manually. In addition, OFBiz has tax amount correction >>>> logic, which compensates the >>>> tax difference automatically, example: >>>> Prdouct 100 euro Sales tax (VAT 19%) = 100 * 0.19 = 19 euro >>>> Shipping charge 10 euro >>>> Sales tax (VAT 19%) = 10 * 0.19 = 1.90 euro >>>> Other adjustment 20 euro >>>> Sales tax (VAT 19%) = 3.80 euro (we have to add it manually) >>>> *Sales tax (VAT 19%) = - 3.80 euro * (it is automatically added >>>> difference >>>> to correct the sales tax amount, because the sales tax for other >>>> adjustment >>>> is not taken into account.) >>>> and we have to delete the last tax adjustment manually. >>>> >>>> *Solution:* >>>> As we have TaxAuthorityRateProduct in OFBiz to manage the taxing of >>>> products, so why not to have the same mechanism for all adjustments? >>>> I propose the solution to have the TaxAuthorityRateAdjustment entity. >>>> TaxAuthorityRateAdjustment will have the following fields: >>>> >>>> *Tax type* (Sales Tax, etc) >>>> *Store ID* >>>> *Adjustment Type or (All adjustments)* >>>> Title Transfer ??? (I do not know, what can you suggest?) >>>> *Tax Percentage * >>>> *From Date * >>>> *Thru Date* >>>> *Description* >>>> >>>> The settings will be placed in the separate "Adjustment rates" tab, >>>> near to >>>> "Product rates" (Tax Authority settings). >>>> The UI should be very similar! >>>> >>>> RE: TaxAuthorityRateProduct >>>> we should retire *Tax Shipping* >>>> *Tax Promotions* >>>> >>>> The tax calculation service must be reworked, >>>> >>>> <service name="calcTax" engine="java" >>>> location="org.ofbiz.accounting.tax.TaxAuthorityServices" >>>> invoke="rateProductTaxCalc"> >>>> <description>Tax Authority Rate Product Calc >>>> Service</description> >>>> <implements service="calcTaxInterface"/> >>>> </service> >>>> >>>> <service name="calcTaxInterface" engine="interface" location="" >>>> invoke=""> >>>> <description>Tax Calc Service Interface</description> >>>> <attribute name="productStoreId" type="String" mode="IN" >>>> optional="true"></attribute> >>>> <attribute name="facilityId" type="String" mode="IN" >>>> optional="true"></attribute> >>>> <attribute name="payToPartyId" type="String" mode="IN" >>>> optional="true"/> >>>> <attribute name="billToPartyId" type="String" mode="IN" >>>> optional="true"></attribute> >>>> <attribute name="itemProductList" type="java.util.List" >>>> mode="IN" >>>> optional="false"></attribute> >>>> <attribute name="itemAmountList" type="java.util.List" mode="IN" >>>> optional="false"></attribute> >>>> <attribute name="itemPriceList" type="java.util.List" mode="IN" >>>> optional="false"></attribute> >>>> <attribute name="itemQuantityList" type="java.util.List" >>>> mode="IN" >>>> optional="true"></attribute> >>>> <attribute name="itemShippingList" type="java.util.List" >>>> mode="IN" >>>> optional="true"></attribute> >>>> * <attribute name="orderShippingAmount" type="BigDecimal" >>>> mode="IN" >>>> optional="true"/> >>>> <attribute name="orderPromotionsAmount" type="BigDecimal" >>>> mode="IN" >>>> optional="true"/> >>>> * <attribute name="shippingAddress" >>>> type="org.ofbiz.entity.GenericValue" mode="IN" optional="true"/> >>>> <attribute name="orderAdjustments" type="java.util.List" >>>> mode="OUT" >>>> optional="false"></attribute> >>>> <attribute name="itemAdjustments" type="java.util.List" >>>> mode="OUT" >>>> optional="false"></attribute> >>>> </service> >>>> >>>> This interface must have /OrderAdjustment/ list as IN parameter. >>>> That is my draft solution. >>>> Any ideas? What is your opinion? >>>> >>>> -- >>>> View this message in context: >>>> http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4153757.html >>>> >>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >>>> > |
Re: Tax calculation for all order adjustments
|
|
In reply to this post by Jacques Le Roux
Hello Jacques,
thanks for the links. It is a good idea to keep all tax things in one wiki page. However, these articles can not answer my questions.
Kind regards,
Sergei |
Re: Tax calculation for all order adjustments
|
|
are you planning to add this to the svn or just for yourself?
biletnikov sent the following on 12/5/2011 12:41 AM: > Hello Jacques, > thanks for the links. > It is a good idea to keep all tax things in one wiki page. > However, these articles can not answer my questions. > > ----- > Kind regards, > Sergei > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4159696.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
Re: Tax calculation for all order adjustments
|
|
Firstly, for myself. But I think this solution is useful not only for me, especial for VAT users and if all is ok, it would be grateful to contribute to SVN.
The most tricky question for me is what I should do with "Tax shipping" and "Tax promotion" in the TaxAuthorityRateProduct? Actually, they will be retired, and should not be used anymore, because all tax rate adjustments will be setup in a separate tab.
Kind regards,
Sergei |
Re: Tax calculation for all order adjustments
|
|
Thanks. I am trying to pinpoint how to approach this.
If your doing it for yourself then you have more latitude not to take into considerations like the US Tax authority. The next consideration is when you upgrade you will have to make sure your changes are not overwritten with the SVN image. If you plan to submit a patch then the design has to be reviewed to make sure it does not effect other Tax authority uses. You also have a migration to setup for productions systems. biletnikov sent the following on 12/5/2011 10:35 PM: > Firstly, for myself. But I think this solution is useful not only for me, > especial for VAT users and if all is ok, it would be grateful to contribute > to SVN. > The most tricky question for me is what I should do with "Tax shipping" and > "Tax promotion" in the TaxAuthorityRateProduct? Actually, they will be > retired, and should not be used anymore, because all tax rate adjustments > will be setup in a separate tab. > > ----- > Kind regards, > Sergei > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4163677.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
Re: Tax calculation for all order adjustments
|
In reply to this post by biletnikov
You could introduce a properties setting:
OrderAdjustMentTaxSettingAll=true/false false: as is now: only promotion & shipping according TaxAuthorityRateProduct true: tax on all order adjustments: ignore TaxAuthorityRateProduct Show this setting on the TaxAuthorityRateProduct screen or do not allow setting there so everybody happy.... Regards, Hans On 12/06/2011 01:35 PM, biletnikov wrote: > Firstly, for myself. But I think this solution is useful not only for me, > especial for VAT users and if all is ok, it would be grateful to contribute > to SVN. > The most tricky question for me is what I should do with "Tax shipping" and > "Tax promotion" in the TaxAuthorityRateProduct? Actually, they will be > retired, and should not be used anymore, because all tax rate adjustments > will be setup in a separate tab. > > ----- > Kind regards, > Sergei > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4163677.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. |
Re: Tax calculation for all order adjustments
|
|
That is interesting idea.
But which properties settings do you mean? Because a property setting can be changed manually. If you mean to keep it like a mail settings, that is ok. In this case we can even hide shipping and promotions flags if the use choose OrderAdjustMentTaxSettingAll = true Another idea: we can have the new tax adjustments settings with the current shipping & promotion flag settings in the product rates, but if a user starts to use shipping or promotions in the new tax adjustments tab, the tax calculation function just ignores promotion & shipping flags in the tax product rate tab. What is better?
Kind regards,
Sergei |
Re: Tax calculation for all order adjustments
|
In reply to this post by hans_bakker
Hi Hans,
I don't think it's that simple. Different product stores located in different jurisdictions will have different tax rules. The destination for the order will affect tax rules - it's common that exports are not taxed. A property would apply a blanket rule to all orders, and I don't think that would be flexible enough. Cheers Paul Foxworthy
--
Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ |
Re: Tax calculation for all order adjustments
|
|
Hi Paul,
as you said, the different product stores can depend on different tax jurisdictions, it is ok, you can setup the tax rates per each store. The most important thing is how to design a flexible solution to allow taxing for the necessary adjustments. On the one hand, it is obvious that OFBiz should have the similar "tax rate" design for the adjustments, but on the other hand we already have a design, which marks promotion and shipping adjustments as a special case and we can control them via "TaxAuthorityRateProduct" , it makes this similar to a trick. In my opinion, I would skip "taxShipping" and "taxPromotions" fields from "TaxAuthorityRateProduct" at all, and create "TaxAuthorityRateAdjustment", plus rework the tax calculation. Kind regards, Sergei
Kind regards,
Sergei |
Re: Tax calculation for all order adjustments
|
|
Yes, I agree with that.
Cheers Paul Foxworthy
--
Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ |
Re: Tax calculation for all order adjustments
|
|
This post was updated on .
In reply to this post by biletnikov
Hi Sergei,
Title transfer is about when ownership transfers from the seller to the purchaser. See https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml?hb=true#to1000 for the complete list of values. I don't think title transfer is relevant to adjustments, so I think it is not needed in the new entity. productStoreId is fine for sales, but is useless for purchases. I suggest the entity have both a productStoreId and a sellerGeoId. For purchases, the location of the seller would be used to locate tax rules. I've discussed this issue before on the mailing list at http://ofbiz.135035.n4.nabble.com/Discussion-Potential-Data-Model-Improvements-tp3390620p3446992.html Cheers Paul Foxworthy
--
Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ |
Re: Tax calculation for all order adjustments
|
|
Sergei, Paul.
as you suggested, producrstore should not be used for purchase orders or anything purchase tax related, productstore is for sales only regards, Hans On 12/31/2011 01:44 PM, Paul Foxworthy wrote: > Hi Sergei, > > Title transfer is about when ownership transfers from the seller to the > purchaser. See > https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml?hb=true#to1000 > for the complete list of values. I don't think title transfer is relevant to > adjustments, so I think it is not needed in the new entity. > > productStoreId is fine for sales, but is useless for purchases. I suggest > the entity have both a productStoreId and a sellerGeoId. For purchases, the > location of the seller would be used to locate tax rules. I've discussed > this issue before on the mailing list at > https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml?hb=true#to1000 > . > > Cheers > > Paul Foxworthy > > > biletnikov wrote >> *Current problem:* >> we manage tax calculation for products by setting up a tax authority. >> The tax rate for products is set with TaxAuthorityRateProduct. >> In addition, tax setting for shipping and promotions adjustments can be >> set as special flags to each TaxAuthorityRateProduct (tax >> shipping/promotion Y or N). However, these 2 adjustments are taxed only if >> productCategoryId is empty, and these 2 adjustments look like a hack or >> temp solution here... >> I faced with a problem, where all adjustments must be taxed (very common >> case for VAT tax system) and it is very unhandy when you have to control >> the tax amount manually. In our case, the system taxes the shipping and >> promotion adjustments, but we have to add Sales tax to all another >> adjustments manually. >> In addition, OFBiz has tax amount correction logic, which compensates the >> tax difference automatically, example: >> Prdouct 100 euro >> Sales tax (VAT 19%) = 100 * 0.19 = 19 euro >> Shipping charge 10 euro >> Sales tax (VAT 19%) = 10 * 0.19 = 1.90 euro >> Other adjustment 20 euro >> Sales tax (VAT 19%) = 3.80 euro (we have to add it manually) >> *Sales tax (VAT 19%) = - 3.80 euro * (it is automatically added difference >> to correct the sales tax amount, because the sales tax for other >> adjustment is not taken into account.) >> and we have to delete the last tax adjustment manually. >> >> *Solution:* >> As we have TaxAuthorityRateProduct in OFBiz to manage the taxing of >> products, so why not to have the same mechanism for all adjustments? >> I propose the solution to have the TaxAuthorityRateAdjustment entity. >> TaxAuthorityRateAdjustment will have the following fields: >> >> *Tax type* (Sales Tax, etc) >> *Store ID* >> *Adjustment Type or (All adjustments)* >> Title Transfer ??? (I do not know, what can you suggest?) >> *Tax Percentage * >> *From Date * >> *Thru Date* >> *Description* >> >> The settings will be placed in the separate "Adjustment rates" tab, near >> to "Product rates" (Tax Authority settings). >> The UI should be very similar! >> >> RE: TaxAuthorityRateProduct >> we should retire >> *Tax Shipping* >> *Tax Promotions* >> >> The tax calculation service must be reworked, >> >> <service name="calcTax" engine="java" >> location="org.ofbiz.accounting.tax.TaxAuthorityServices" >> invoke="rateProductTaxCalc"> >> <description>Tax Authority Rate Product Calc Service</description> >> <implements service="calcTaxInterface"/> >> </service> >> >> <service name="calcTaxInterface" engine="interface" location="" >> invoke=""> >> <description>Tax Calc Service Interface</description> >> <attribute name="productStoreId" type="String" mode="IN" >> optional="true"></attribute> >> <attribute name="facilityId" type="String" mode="IN" >> optional="true"></attribute> >> <attribute name="payToPartyId" type="String" mode="IN" >> optional="true"/> >> <attribute name="billToPartyId" type="String" mode="IN" >> optional="true"></attribute> >> <attribute name="itemProductList" type="java.util.List" mode="IN" >> optional="false"></attribute> >> <attribute name="itemAmountList" type="java.util.List" mode="IN" >> optional="false"></attribute> >> <attribute name="itemPriceList" type="java.util.List" mode="IN" >> optional="false"></attribute> >> <attribute name="itemQuantityList" type="java.util.List" mode="IN" >> optional="true"></attribute> >> <attribute name="itemShippingList" type="java.util.List" mode="IN" >> optional="true"></attribute> >> *<attribute name="orderShippingAmount" type="BigDecimal" mode="IN" >> optional="true"/> >> <attribute name="orderPromotionsAmount" type="BigDecimal" mode="IN" >> optional="true"/> >> *<attribute name="shippingAddress" >> type="org.ofbiz.entity.GenericValue" mode="IN" optional="true"/> >> <attribute name="orderAdjustments" type="java.util.List" mode="OUT" >> optional="false"></attribute> >> <attribute name="itemAdjustments" type="java.util.List" mode="OUT" >> optional="false"></attribute> >> </service> >> >> This interface must have /OrderAdjustment/ list as IN parameter. >> >> That is my draft solution. >> Any ideas? What is your opinion? >> > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4247763.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. |
Re: Tax calculation for all order adjustments
|
Administrator
|
This remembers me this dicussion http://markmail.org/message/oisyr3hqq2vn3yfz
There are maybe some good ideas there, are we not looking for cost centers? Jacques From: "Hans Bakker" <[hidden email]> > Sergei, Paul. > > as you suggested, > producrstore should not be used for purchase orders or anything purchase > tax related, > productstore is for sales only > > regards, > Hans > > On 12/31/2011 01:44 PM, Paul Foxworthy wrote: >> Hi Sergei, >> >> Title transfer is about when ownership transfers from the seller to the >> purchaser. See >> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml?hb=true#to1000 >> for the complete list of values. I don't think title transfer is relevant to >> adjustments, so I think it is not needed in the new entity. >> >> productStoreId is fine for sales, but is useless for purchases. I suggest >> the entity have both a productStoreId and a sellerGeoId. For purchases, the >> location of the seller would be used to locate tax rules. I've discussed >> this issue before on the mailing list at >> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml?hb=true#to1000 >> . >> >> Cheers >> >> Paul Foxworthy >> >> >> biletnikov wrote >>> *Current problem:* >>> we manage tax calculation for products by setting up a tax authority. >>> The tax rate for products is set with TaxAuthorityRateProduct. >>> In addition, tax setting for shipping and promotions adjustments can be >>> set as special flags to each TaxAuthorityRateProduct (tax >>> shipping/promotion Y or N). However, these 2 adjustments are taxed only if >>> productCategoryId is empty, and these 2 adjustments look like a hack or >>> temp solution here... >>> I faced with a problem, where all adjustments must be taxed (very common >>> case for VAT tax system) and it is very unhandy when you have to control >>> the tax amount manually. In our case, the system taxes the shipping and >>> promotion adjustments, but we have to add Sales tax to all another >>> adjustments manually. >>> In addition, OFBiz has tax amount correction logic, which compensates the >>> tax difference automatically, example: >>> Prdouct 100 euro >>> Sales tax (VAT 19%) = 100 * 0.19 = 19 euro >>> Shipping charge 10 euro >>> Sales tax (VAT 19%) = 10 * 0.19 = 1.90 euro >>> Other adjustment 20 euro >>> Sales tax (VAT 19%) = 3.80 euro (we have to add it manually) >>> *Sales tax (VAT 19%) = - 3.80 euro * (it is automatically added difference >>> to correct the sales tax amount, because the sales tax for other >>> adjustment is not taken into account.) >>> and we have to delete the last tax adjustment manually. >>> >>> *Solution:* >>> As we have TaxAuthorityRateProduct in OFBiz to manage the taxing of >>> products, so why not to have the same mechanism for all adjustments? >>> I propose the solution to have the TaxAuthorityRateAdjustment entity. >>> TaxAuthorityRateAdjustment will have the following fields: >>> >>> *Tax type* (Sales Tax, etc) >>> *Store ID* >>> *Adjustment Type or (All adjustments)* >>> Title Transfer ??? (I do not know, what can you suggest?) >>> *Tax Percentage * >>> *From Date * >>> *Thru Date* >>> *Description* >>> >>> The settings will be placed in the separate "Adjustment rates" tab, near >>> to "Product rates" (Tax Authority settings). >>> The UI should be very similar! >>> >>> RE: TaxAuthorityRateProduct >>> we should retire >>> *Tax Shipping* >>> *Tax Promotions* >>> >>> The tax calculation service must be reworked, >>> >>> <service name="calcTax" engine="java" >>> location="org.ofbiz.accounting.tax.TaxAuthorityServices" >>> invoke="rateProductTaxCalc"> >>> <description>Tax Authority Rate Product Calc Service</description> >>> <implements service="calcTaxInterface"/> >>> </service> >>> >>> <service name="calcTaxInterface" engine="interface" location="" >>> invoke=""> >>> <description>Tax Calc Service Interface</description> >>> <attribute name="productStoreId" type="String" mode="IN" >>> optional="true"></attribute> >>> <attribute name="facilityId" type="String" mode="IN" >>> optional="true"></attribute> >>> <attribute name="payToPartyId" type="String" mode="IN" >>> optional="true"/> >>> <attribute name="billToPartyId" type="String" mode="IN" >>> optional="true"></attribute> >>> <attribute name="itemProductList" type="java.util.List" mode="IN" >>> optional="false"></attribute> >>> <attribute name="itemAmountList" type="java.util.List" mode="IN" >>> optional="false"></attribute> >>> <attribute name="itemPriceList" type="java.util.List" mode="IN" >>> optional="false"></attribute> >>> <attribute name="itemQuantityList" type="java.util.List" mode="IN" >>> optional="true"></attribute> >>> <attribute name="itemShippingList" type="java.util.List" mode="IN" >>> optional="true"></attribute> >>> *<attribute name="orderShippingAmount" type="BigDecimal" mode="IN" >>> optional="true"/> >>> <attribute name="orderPromotionsAmount" type="BigDecimal" mode="IN" >>> optional="true"/> >>> *<attribute name="shippingAddress" >>> type="org.ofbiz.entity.GenericValue" mode="IN" optional="true"/> >>> <attribute name="orderAdjustments" type="java.util.List" mode="OUT" >>> optional="false"></attribute> >>> <attribute name="itemAdjustments" type="java.util.List" mode="OUT" >>> optional="false"></attribute> >>> </service> >>> >>> This interface must have /OrderAdjustment/ list as IN parameter. >>> >>> That is my draft solution. >>> Any ideas? What is your opinion? >>> >> -- >> View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4247763.html >> Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
Re: Tax calculation for all order adjustments
|
|
Hi Jacques and Happy New Year,
I had thought cost centres are a separate issue. An organization using OFBiz might want to break down a purchase into multiple cost centres even if no tax is involved. Is there a need to consider cost centres as part of this? Why so? Cheers Paul Foxworthy
--
Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ |
Re: Tax calculation for all order adjustments
|
Administrator
|
Hi Paul,
This comes from Hans's answer >>> as you suggested, >>> producrstore should not be used for purchase orders or anything purchase >>> tax related, >>> productstore is for sales only My basic idea was that you set VAT parameters on profit center (VAT fields in ProductStore UI: ...catalog/control/EditProductStore?productStoreId=...) so if you need to set VAT for incoming orders (purchases) the same kind of stuff could be set from a new CostCenter Entity. But really I did not put much thoughts in that, just remembered this thread, and it's maybe not even a good idea... Jacques From: "Paul Foxworthy" <[hidden email]> > Hi Jacques and Happy New Year, > > I had thought cost centres are a separate issue. An organization using OFBiz > might want to break down a purchase into multiple cost centres even if no > tax is involved. > > Is there a need to consider cost centres as part of this? Why so? > > Cheers > > Paul Foxworthy > > > Jacques Le Roux wrote >> >> This remembers me this dicussion >> http://markmail.org/message/oisyr3hqq2vn3yfz >> There are maybe some good ideas there, are we not looking for cost >> centers? >> >> Jacques >> >> From: "Hans Bakker" <mailinglist@> >>> Sergei, Paul. >>> >>> as you suggested, >>> producrstore should not be used for purchase orders or anything purchase >>> tax related, >>> productstore is for sales only >>> >>> regards, >>> Hans >>> >>> On 12/31/2011 01:44 PM, Paul Foxworthy wrote: >>>> Hi Sergei, >>>> >>>> Title transfer is about when ownership transfers from the seller to the >>>> purchaser. See >>>> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml?hb=true#to1000 >>>> for the complete list of values. I don't think title transfer is >>>> relevant to >>>> adjustments, so I think it is not needed in the new entity. >>>> >>>> productStoreId is fine for sales, but is useless for purchases. I >>>> suggest >>>> the entity have both a productStoreId and a sellerGeoId. For purchases, >>>> the >>>> location of the seller would be used to locate tax rules. I've discussed >>>> this issue before on the mailing list at >>>> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml?hb=true#to1000 >>>> . >>>> >>>> Cheers >>>> >>>> Paul Foxworthy >>>> >>>> >>>> biletnikov wrote >>>>> *Current problem:* >>>>> we manage tax calculation for products by setting up a tax authority. >>>>> The tax rate for products is set with TaxAuthorityRateProduct. >>>>> In addition, tax setting for shipping and promotions adjustments can be >>>>> set as special flags to each TaxAuthorityRateProduct (tax >>>>> shipping/promotion Y or N). However, these 2 adjustments are taxed only >>>>> if >>>>> productCategoryId is empty, and these 2 adjustments look like a hack or >>>>> temp solution here... >>>>> I faced with a problem, where all adjustments must be taxed (very >>>>> common >>>>> case for VAT tax system) and it is very unhandy when you have to >>>>> control >>>>> the tax amount manually. In our case, the system taxes the shipping and >>>>> promotion adjustments, but we have to add Sales tax to all another >>>>> adjustments manually. >>>>> In addition, OFBiz has tax amount correction logic, which compensates >>>>> the >>>>> tax difference automatically, example: >>>>> Prdouct 100 euro >>>>> Sales tax (VAT 19%) = 100 * 0.19 = 19 euro >>>>> Shipping charge 10 euro >>>>> Sales tax (VAT 19%) = 10 * 0.19 = 1.90 euro >>>>> Other adjustment 20 euro >>>>> Sales tax (VAT 19%) = 3.80 euro (we have to add it manually) >>>>> *Sales tax (VAT 19%) = - 3.80 euro * (it is automatically added >>>>> difference >>>>> to correct the sales tax amount, because the sales tax for other >>>>> adjustment is not taken into account.) >>>>> and we have to delete the last tax adjustment manually. >>>>> >>>>> *Solution:* >>>>> As we have TaxAuthorityRateProduct in OFBiz to manage the taxing of >>>>> products, so why not to have the same mechanism for all adjustments? >>>>> I propose the solution to have the TaxAuthorityRateAdjustment entity. >>>>> TaxAuthorityRateAdjustment will have the following fields: >>>>> >>>>> *Tax type* (Sales Tax, etc) >>>>> *Store ID* >>>>> *Adjustment Type or (All adjustments)* >>>>> Title Transfer ??? (I do not know, what can you suggest?) >>>>> *Tax Percentage * >>>>> *From Date * >>>>> *Thru Date* >>>>> *Description* >>>>> >>>>> The settings will be placed in the separate "Adjustment rates" tab, >>>>> near >>>>> to "Product rates" (Tax Authority settings). >>>>> The UI should be very similar! >>>>> >>>>> RE: TaxAuthorityRateProduct >>>>> we should retire >>>>> *Tax Shipping* >>>>> *Tax Promotions* >>>>> >>>>> The tax calculation service must be reworked, >>>>> >>>>> <service name="calcTax" engine="java" >>>>> location="org.ofbiz.accounting.tax.TaxAuthorityServices" >>>>> invoke="rateProductTaxCalc"> >>>>> <description>Tax Authority Rate Product Calc >>>>> Service</description> >>>>> <implements service="calcTaxInterface"/> >>>>> </service> >>>>> >>>>> <service name="calcTaxInterface" engine="interface" location="" >>>>> invoke=""> >>>>> <description>Tax Calc Service Interface</description> >>>>> <attribute name="productStoreId" type="String" mode="IN" >>>>> optional="true"></attribute> >>>>> <attribute name="facilityId" type="String" mode="IN" >>>>> optional="true"></attribute> >>>>> <attribute name="payToPartyId" type="String" mode="IN" >>>>> optional="true"/> >>>>> <attribute name="billToPartyId" type="String" mode="IN" >>>>> optional="true"></attribute> >>>>> <attribute name="itemProductList" type="java.util.List" >>>>> mode="IN" >>>>> optional="false"></attribute> >>>>> <attribute name="itemAmountList" type="java.util.List" >>>>> mode="IN" >>>>> optional="false"></attribute> >>>>> <attribute name="itemPriceList" type="java.util.List" mode="IN" >>>>> optional="false"></attribute> >>>>> <attribute name="itemQuantityList" type="java.util.List" >>>>> mode="IN" >>>>> optional="true"></attribute> >>>>> <attribute name="itemShippingList" type="java.util.List" >>>>> mode="IN" >>>>> optional="true"></attribute> >>>>> *<attribute name="orderShippingAmount" type="BigDecimal" mode="IN" >>>>> optional="true"/> >>>>> <attribute name="orderPromotionsAmount" type="BigDecimal" >>>>> mode="IN" >>>>> optional="true"/> >>>>> *<attribute name="shippingAddress" >>>>> type="org.ofbiz.entity.GenericValue" mode="IN" optional="true"/> >>>>> <attribute name="orderAdjustments" type="java.util.List" >>>>> mode="OUT" >>>>> optional="false"></attribute> >>>>> <attribute name="itemAdjustments" type="java.util.List" >>>>> mode="OUT" >>>>> optional="false"></attribute> >>>>> </service> >>>>> >>>>> This interface must have /OrderAdjustment/ list as IN parameter. >>>>> >>>>> That is my draft solution. >>>>> Any ideas? What is your opinion? >>>>> >>>> -- >>>> View this message in context: >>>> http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4247763.html >>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >>> >> > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4254879.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. |
Re: Tax calculation for all order adjustments
|
|
Hi Jacques,
I think there's a difference. Yes, the ProductStore is indeed a profit centre for our organization. It is reasonable to have VAT parameters related to a ProductStore for sales, because the product store is in one location for tax accounting purposes. The entries in TaxAuthorityRateProduct define the tax authorities that are relevant to the location of the product store. Note that the taxAuthGeoId attribute in TaxAuthorityRateProduct is for the location of the purchaser, not the seller. Now, if we had two product stores located close to each other, say in the same state/province, they could well have duplicated VAT information. Provided the number of stores isn't huge, we can live with the duplication. In contrast, for purchases, there are many suppliers, perhaps in many different locations with different VAT policies. The new entity we're envisaging should have rows for each location where there is at least one supplier, and we want estimated VAT to be automatically added to purchase orders. I don't envisage a row for each supplier. That would mean an explosion of rows with duplicated information on the VAT rates for some location. I think it most unlikely that you would want to allocate cost centres to a purchase based just on the *location* of the supplier. You might want to do it based on who the supplier is, which division of our organization is making the purchase, what project the purchase is relevant to, or many other criteria. But none of those facts will be in the new entity we're considering. Cheers Paul Foxworthy
--
Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |