[
https://issues.apache.org/jira/browse/OFBIZ-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610725#action_12610725
]
Jacques Le Roux commented on OFBIZ-416:
---------------------------------------
David,
I agree with you that we have a solid model, and calculation is mostly right.
But I think that some side aspects of VAT could be improved in OFBiz. For
instance :
* The global order promo issue (should be by item)
* VAT Report
* Please see http://docs.ofbiz.org/display/OFBIZ/VAT for more...
AFAIK, shipping is ok, you have the possiblitiy to set tax on it by products
categories in Tax Auth.
What so you consider regarding prices rules? I have no ideas and no needs yet...
About Interacting with the way prices are displayed
>From my own experience with UK and French clients, backoffice users (customers
>services) don't want to deal with anything but gross prices (VAT included
>prices). So far it was easy for me because my clients were only selling goods
>with the same rate. It's a bit harder in the general case, but, I guess, not
>too much. There are 2 cases to consider
1. Entering prices
2. Showing prices
At 1st sight they seem the same. But it's not from localisation POV : you have
to deal with number separator when entering prices. I used a js snippet for
France in FTL template. I did not need to use form widget, but anyway this
snippet show the idea
<#setting locale="en"/> <#-- TODO : use the same scheme in excludeVat if needed
for another language (ok for french, with "," here) -->
<script language="JavaScript" type="text/javascript">
function excludeVat(AdjustmentId) {
debugger;
myLocale = "${myLocale}";
value = document.getElementById(AdjustmentId).value;
if (myLocale == "fr") {
value = value.replace(",",".");
}
value = value / ${vatFactor};
if (myLocale == "fr") {
value = value.toString().replace(".",",");
}
document.getElementById(AdjustmentId).value = " " + value; // "
" to hide field value during change
}
</script>
<#setting locale=myLocale>
and in FTL
<div class="tabletext"><input type="text" name="amount"
size="6" id="${orderAdjustmentId}" value="<@ofbizAmount
amount=adjustmentAmount*vatFactor />" class="inputBox">
<a
href="javascript:excludeVat(${orderAdjustmentId});document.updateOrderAdjustmentForm${orderAdjustmentId}.submit();"
class="buttontext">${uiLabelMap.CommonUpdate}</a>
As I said before vatFactor was not product dependent but it's only a matter of
using the right rate for each product which comes from TaxAuthorityRateProduct.
I successfully used this approach in my projects so far using a rate from a
vatFactor property in a ressourceBundle file. It could be generalised using
TaxAuthorityRateProduct.
Could you please explain what you did in your patch or at large in your
application from a functionnal POV ?
> Preliminary implementation of GST/VAT for review
> ------------------------------------------------
>
> Key: OFBIZ-416
> URL: https://issues.apache.org/jira/browse/OFBIZ-416
> Project: OFBiz
> Issue Type: Improvement
> Components: ecommerce, order
> Affects Versions: SVN trunk
> Reporter: David Garrett
> Assignee: Jacques Le Roux
> Priority: Minor
> Attachments: vat-03-061128-r478251.patch
>
>
> I have attached a patch against ofbiz SVN rev 465130 - 18 Oct 06.
> The purpose is to show progress toward a GST/VAT implementations and
> importantly to get early feedback.
>
> The implementation is done in ecommerce and concentrates primarily on the
> cart, the adjustments and creating an order. (More to come.)
>
> The display of the cart and order contents are done to varying degrees. In
> addition a few of the promotions have been tested primarily GWP and order
> discount seem OK. I have not got to the Invoice yet.
>
> The approach taken is to base the implementation on the exTax price. I have
> tried and looked at both. There are pros and cons for working based on incTax
> or exTax pricing .... I believe that exTax is probably better. The display
> price is used but reference to promotions etc I have based on
> basePrice/unitPrice.
> PLEASE NOTE: the implementation is NOT ready for production and has a massive
> amount of notes and comments to myself. These will be fixed and cleaned up
> shortly. The reason for the release at this stage is that it was starting to
> generate a little bit of discussion off the list.
> Implementation
> ==============
> The demo data can primarily be seen from the ecommerce/data ... the AU files.
> See the questions below.
> The key definitions are as follows:
> <TaxAuthorityRateType taxAuthorityRateTypeId="GST_TAX" description="Goods
> and Services Tax"/>
> <TaxAuthorityRateType taxAuthorityRateTypeId="VAT_TAX" description="Value
> Added Tax"/>
>
> <OrderAdjustmentType description="GST Tax" hasTable="N"
> orderAdjustmentTypeId="GST_TAX" parentTypeId=""/>
> <OrderAdjustmentType description="VAT Tax" hasTable="N"
> orderAdjustmentTypeId="VAT_TAX" parentTypeId=""/>
> <OrderAdjustmentType description="Gst Tax on Adjustment" hasTable="N"
> orderAdjustmentTypeId="OTHER_GST_TAX" parentTypeId=""/>
> <OrderAdjustmentType description="VAT Tax on Adjustment" hasTable="N"
> orderAdjustmentTypeId="OTHER_VAT_TAX" parentTypeId=""/>
> <OrderAdjustmentType description="Gst Tax on Shipping" hasTable="N"
> orderAdjustmentTypeId="SHIPPING_GST_TAX" parentTypeId=""/>
> <OrderAdjustmentType description="VAT Tax on Shipping" hasTable="N"
> orderAdjustmentTypeId="SHIPPING_VAT_TAX" parentTypeId=""/>
> <TaxAuthorityRateProduct taxAuthorityRateSeqId="9050" taxAuthGeoId="AUS"
> taxAuthPartyId="AUS_ATO" taxAuthorityRateTypeId="GST_TAX"
> productStoreId="9000AU"
> productCategoryId="" titleTransferEnumId="" minItemPrice="0.00"
> minPurchase="0.00" taxShipping="Y" taxPercentage="10"
> defaultOrderAdjTypeId="GST_TAX"
> shippingOrderAdjTypeId="SHIPPING_GST_TAX" otherOrderAdjTypeId="OTHER_GST_TAX"
> fromDate="2001-05-13 00:00:00.001" thruDate=""
> description="Australian GST Tax"/>
> The GST or VAT is recorded separately for each of the key types the
> item->VAT_TAX the SHIPPING_ADJUSTMENT->SHIPPING_VAT_TAX and the "Other"
> Adjustments->OTHER_VAT_TAX
> Other Adjustments attached to an item still require further testing.
> ### The patch defaults to mysql. You may need to change this/
>
> Testing
> =======
> The easiest test is to add productId= GST10 to the cart and create an order
> (either ecommerce or ordermgr) ... the display starts OK then not fully
> implemented (this is not the problem I am chasing at the moment). As best I
> can tell the cart is being created correctly with the correct
> OrderAdjustments. OrderItemAdjustments are not all functioning correctly at
> the moment.
>
> Next order 11 x GST10 ... get a free gift ... seems to work
>
> Next order 1 x GST10PROMO (in PROMOTIONS category) ... price rules seem to
> work OK
>
> Problem ... SPECIAL_PROMOTION ... add code 9021 ... problem comes from the
> pricing basis in getSubTotalForPromotions(...) which uses
> getDisplayItemSubTotal
>
>
> Questions
> =========
> ** Can I use this patch to implement VAT/GST now?
> No. Not yet. This is a VERY early release to show the direction being taken.
> ** Why are there so many changes? What is all this AU and GST stuff.
> To test the GST/VAT I have created a store(9000AU) which implements the
> Australian(AU) implementation of VAT called Goods & Services Tax(GST). In
> order to achieve this there is a lot of demo data that has been created which
> implements ProductPrices, Promotions, Payments, UiLabels etc.
> The WebSiteId in web.xml is not changed at the moment and the default store
> is overwritten as 9000AU.
> Other TaxAuthorities may also be created later.
> ** Isn't GST just another VAT? Why not just implement VAT?
> Yes this is correct. This is probably the way things will go ... with
> customisations based on taxAuthGeoId. HOWEVER I do need things like "GST Tax"
> type descriptions on the orderItem display. So in the short term this GST
> implementation will remain. Call me selfish but I want it to work out of the
> box for me.
> Next Steps
> ==========
> * Address any feedback
> * Get the cart to order process working particulary for the orderItem
> adjustments and promotions
> * The cart internally seems correct So ... get the display of the data
> showing what the user would expect.
> * Focus on getting VAT into the Invoice
> * Address any feedback
> Hope it helps. All feedback/criticism welcome.
>
> David G
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
