Hi Paul,
Your proposal is very good, I am agree totally with you.
What I had in mind as a long term fix was generalising the calcTax service
> and rateProductTaxCalc (line 141 in
> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java)
> to take a list of order adjustments, instead of specifically one shipping
> and one promotion amount.
The calls to getTaxAdjustments on lines 224 and 228 would be changed to
> call a separate method that searches a different table, not
> TaxAuthorityRateProduct. This new table would define tax rules for the
> various order adjustment types, much as TARP defines tax rules for product
> categories.
It is very strange for me that the shipping and promotion adjustments have
the special taxable status in OFBiz, although another adjustments are out
of the taxable context.
Do you have an implementation plan?
Also, please notice that this calculation interface gets only promotion and
shipping amounts.... so that follows to changing of another dependent code.
<service name="calcTaxInterface" engine="interface" location=""
invoke="">
<description>Tax Calc Service Interface</description>
<attribute name="productStoreId" type="String" mode="IN"
optional="true"><!-- this will be used to find the payToPartyId, if the
payToPartyId parameter is not explicitly passed, and as one of the columns
to constrain by on the lookup --></attribute>
<attribute name="payToPartyId" type="String" mode="IN"
optional="true"/>
<attribute name="billToPartyId" type="String" mode="IN"
optional="true"><!-- would like to have this not-optional, but in some
circumstances may need a tax estimate without knowing who the customer is
--></attribute>
<attribute name="itemProductList" type="java.util.List" mode="IN"
optional="false"><!-- List of GenericValues --></attribute>
<attribute name="itemAmountList" type="java.util.List" mode="IN"
optional="false"><!-- List of BigDecimals --></attribute>
<attribute name="itemPriceList" type="java.util.List" mode="IN"
optional="false"><!-- List of BigDecimals --></attribute>
* <attribute name="itemShippingList" type="java.util.List" mode="IN"
optional="true"><!-- List of BigDecimals --></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"><!-- List of GenericValues (OrderAdjustment)
--></attribute>
<attribute name="itemAdjustments" type="java.util.List" mode="OUT"
optional="false"><!-- List of Lists of GenericValues (OrderAdjustment), one
List of Adjustments per item --></attribute>
</service>
Of course, it is needed to be refactored.
Kind regards,
Sergei
On Thu, Dec 1, 2011 at 9:50 AM, Paul Foxworthy [via OFBiz] <
[email protected]> wrote:
> Hello Sergei,
>
> I had a suggestion to address this in February:
>
>
> http://ofbiz.135035.n4.nabble.com/VAT-is-not-applied-for-the-shipping-tp3234699p3303377.html
>
> I haven't had a need to work on the proposal yet. What do you think of the
> idea?
>
> Cheers
>
> Paul Foxworthy
>
> biletnikov wrote
> Hello,
> I use for my project a tax calculation in VAT style.
> For this goal I use the OFBiz Tax authority settings and *
> TaxAuthorityRateProduct* mechanism.
> To be more precise, I added the content of the entity here:
>
> *<TaxAuthorityRateProduct description="VAT 19%" productStoreId="BStore"
> taxAuthGeoId="DEU" taxAuthPartyId="taxAuthority"
> taxAuthorityRateSeqId="10004" taxAuthorityRateTypeId="SALES_TAX"
> taxPercentage="19.000000" taxPromotions="Y" taxShipping="Y"/> *
>
> Please, notice that : *productCategoryId* is not specified - it is empty
> (null).
> The empty *productCategoryId* allows to calculate taxes for shipping and
> promotions.
> Why it is so, could be find in
> org.ofbiz.accounting.tax.TaxAuthorityServices.getTaxAdjustments() method.
> As result, the tax calculation for shipping and promotions works fine.
> But what is about another adjustments? We have another adjustments which
> must be taxed as well, but the system does not allow to setup this
> somewhere.
> Why only shipping charge and promotion adjustments have a special status
> and can be controlled in the tax authority settings?
>
> "calcTax" service is one key service in tax calculation, and it is obvious
> which input data it expects for:
> ...
> *<attribute name="orderShippingAmount" type="BigDecimal" mode="IN"
> optional="true"/>
> <attribute name="orderPromotionsAmount" type="BigDecimal" mode="IN"
> optional="true"/>*
> ...
> and again, shipping charge amount and promotions amount have a special
> role in tax calculation...
> Is it a good design for tax calculation in context where each adjustment
> has to be taxed? I do not think so.
>
> I am looking for an elegant solution to fix my problem.
> Thanks.
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4119597p4127264.html
> To unsubscribe from Tax calculation for all order adjustments, click
> here<http://ofbiz.135035.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4119597&code=YmlsZXRuaWtvdkBnbWFpbC5jb218NDExOTU5N3wyMDcwNzk3NDQ4>
> .
> NAML<http://ofbiz.135035.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
Best regards,
Sergei Biletnikov
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4119597p4127318.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
