OFBiz
  1. OFBiz
  2. OFBIZ-416

Preliminary implementation of GST/VAT for review

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: SVN trunk
    • Fix Version/s: None
    • Labels:
      None

      Description

      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.

          1. 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

        Issue Links

          Activity

          Hide
          David Garrett added a comment -

          Great discussion and some fundamental requirements. If this patch proves to be useful this patch may be best associated with OFBIZ-366

          Show
          David Garrett added a comment - Great discussion and some fundamental requirements. If this patch proves to be useful this patch may be best associated with OFBIZ-366
          Hide
          Eriks Dobelis added a comment -

          If there are different types of adjustments for GST, VAT, etc. then it is difficult to perform some operations, which apply to all VAT-type taxes. E.g. it is usually requirement in VAT countries that invoice should be shown with and without VAT tax. If we would have one type of adjustment it would be easy to subtract this type from total. If there are many types then some kind of attribute "VAT tax" would be helpful. Another possiblity is a separate table listing all VAT-type adjustments. Yet another option would be to have those listed in some configuration file. Otherwise, it is hard to remember all of them each time, and there is a risk of incosistency, e.g. in a row like
          + <#if orderItemAdjustment.orderAdjustmentTypeId == "SALES_TAX" || orderItemAdjustment.orderAdjustmentTypeId == "GST_TAX" || orderItemAdjustment.orderAdjustmentTypeId == "VAT_TAX">

          In such a row it is quite easy to forget GST_TAX.

          Show
          Eriks Dobelis added a comment - If there are different types of adjustments for GST, VAT, etc. then it is difficult to perform some operations, which apply to all VAT-type taxes. E.g. it is usually requirement in VAT countries that invoice should be shown with and without VAT tax. If we would have one type of adjustment it would be easy to subtract this type from total. If there are many types then some kind of attribute "VAT tax" would be helpful. Another possiblity is a separate table listing all VAT-type adjustments. Yet another option would be to have those listed in some configuration file. Otherwise, it is hard to remember all of them each time, and there is a risk of incosistency, e.g. in a row like + <#if orderItemAdjustment.orderAdjustmentTypeId == "SALES_TAX" || orderItemAdjustment.orderAdjustmentTypeId == "GST_TAX" || orderItemAdjustment.orderAdjustmentTypeId == "VAT_TAX"> In such a row it is quite easy to forget GST_TAX.
          Hide
          David Garrett added a comment -

          Thanks Eriks,

          Yes I agree.

          It would be nice to combine these. I expect to do this however ... the implementation is coming from a previous implementation of GST.

          I am introducing a parallel VAT implementation (along with a lot of restructure and improvement).

          There are issues for me such as UI labels that I have not yet done the changes for. These will come later. I expect these will be associated with the TaxAuthority.
          eg TaxAuth: geoId= AUS, paytyId=ATO will have UI labels such as InvoiceLabel= Tax Invoice, InvoiceVatSummary=GST Included in Invoice ...etc
          whereas
          TaxAuth: geoId= GBR, paytyId=HMRC will have UI labels such as (I don't know what it should be but it is likely to be different) InvoiceLabel=UK VAT Invoice, InvoiceVatSummary=VAT Included in Invoice ...etc

          On the point of prices incVAT exVAT I believe this is seperate and calcuations are centralised. The final objective is to REMOVE lines like the following from ftl
          <#if orderItemAdjustment.orderAdjustmentTypeId == "SALES_TAX" || orderItemAdjustment.orderAdjustmentTypeId == "GST_TAX" || orderItemAdjustment.orderAdjustmentTypeId == "VAT_TAX">
          with eg
          <#if Static["org.ofbiz.accounting.tax.UtilTax"].isTaxAdjustment(orderItemAdjustment) >

          I am trying to transition smoothly from my GST to a generalised VAT without loosing a working system out of the box for my requirements.

          I have been doing little else but work on this over the last few weeks. Maybe today/tomorrow I will have a better implementation to upload which better deals with orderItem adjustments.

          I have been trying for MINIMAL change to the existing implementation. There have been many implementation strategies I have tried to get what I think is the cleanest solution. Each one has side effects with varying levels of ugliness and complexity.

          Show
          David Garrett added a comment - Thanks Eriks, Yes I agree. It would be nice to combine these. I expect to do this however ... the implementation is coming from a previous implementation of GST. I am introducing a parallel VAT implementation (along with a lot of restructure and improvement). There are issues for me such as UI labels that I have not yet done the changes for. These will come later. I expect these will be associated with the TaxAuthority. eg TaxAuth: geoId= AUS, paytyId=ATO will have UI labels such as InvoiceLabel= Tax Invoice, InvoiceVatSummary=GST Included in Invoice ...etc whereas TaxAuth: geoId= GBR, paytyId=HMRC will have UI labels such as (I don't know what it should be but it is likely to be different) InvoiceLabel=UK VAT Invoice, InvoiceVatSummary=VAT Included in Invoice ...etc On the point of prices incVAT exVAT I believe this is seperate and calcuations are centralised. The final objective is to REMOVE lines like the following from ftl <#if orderItemAdjustment.orderAdjustmentTypeId == "SALES_TAX" || orderItemAdjustment.orderAdjustmentTypeId == "GST_TAX" || orderItemAdjustment.orderAdjustmentTypeId == "VAT_TAX"> with eg <#if Static ["org.ofbiz.accounting.tax.UtilTax"] .isTaxAdjustment(orderItemAdjustment) > I am trying to transition smoothly from my GST to a generalised VAT without loosing a working system out of the box for my requirements. I have been doing little else but work on this over the last few weeks. Maybe today/tomorrow I will have a better implementation to upload which better deals with orderItem adjustments. I have been trying for MINIMAL change to the existing implementation. There have been many implementation strategies I have tried to get what I think is the cleanest solution. Each one has side effects with varying levels of ugliness and complexity.
          Hide
          David Garrett added a comment -

          Eriks,

          By the way, the bigger related problem that concerns me is not forgetting to consider GST when implementing VAT ...

          but rather

          forgetting about VAT when imlementing SALES_TAX !!!!

          I am attempting to get the one method call to return the correct values for bot VAT and SALES_TAX with minimal ise of "if VAT"s. Where possible this is done within the existing method names.

          David G

          Show
          David Garrett added a comment - Eriks, By the way, the bigger related problem that concerns me is not forgetting to consider GST when implementing VAT ... but rather forgetting about VAT when imlementing SALES_TAX !!!! I am attempting to get the one method call to return the correct values for bot VAT and SALES_TAX with minimal ise of "if VAT"s. Where possible this is done within the existing method names. David G
          Hide
          David Garrett added a comment -

          This GST/VAT patch seems to handle the cart and the creation of the order correctly. It has been made against Revision 465130. Maybe I need to do something to creatre a better formatted patch. Please let me know.

          Implementation:
          I have kept it independent of the ecommerce module.
          A new module has been created - vatecommerce. It uses a new webSiteId=VatWebStore and corresponding productStoreId=9000AU
          goto htty://localhost:8080/vatecommerce

          Testing
          I have primarily used the following products:
          GST10
          GZ-1005
          GST10PROMO

          Limitation/Problems:
          Rounding problem ... order 20 x GZ-1005
          Rounding problem ... order 1 x GST10PROMO + Shipping $11 ... rounding issue for VAT
          I don't think Giftcards, variations and configurations work yet

          Next:
          VAT in Invoices

          All comments greatfully received

          Thanks
          David G

          Show
          David Garrett added a comment - This GST/VAT patch seems to handle the cart and the creation of the order correctly. It has been made against Revision 465130. Maybe I need to do something to creatre a better formatted patch. Please let me know. Implementation: I have kept it independent of the ecommerce module. A new module has been created - vatecommerce. It uses a new webSiteId=VatWebStore and corresponding productStoreId=9000AU goto htty://localhost:8080/vatecommerce Testing I have primarily used the following products: GST10 GZ-1005 GST10PROMO Limitation/Problems: Rounding problem ... order 20 x GZ-1005 Rounding problem ... order 1 x GST10PROMO + Shipping $11 ... rounding issue for VAT I don't think Giftcards, variations and configurations work yet Next: VAT in Invoices All comments greatfully received Thanks David G
          Hide
          Jacques Le Roux added a comment -

          Hi David,

          Some comments :

          You did not check the ASF authorisation for this last patch (8/11/2006)

          To be commited in futur the following files need an ASL2 header and no author information :
          applications/ecommerce/config/EcommerceUiLabels_en_AU.properties
          applications/ecommerce/data/DemoTaxDataAU.xml
          applications/ecommerce/data/DemoPartyAU.xml
          applications/ecommerce/data/DemoProductAU.xml

          if applications/vatecommerce is untended to be commited (did not had enough time to review it in detail, seems to be a duplicate at first glance
          applications/vatecommerce/docs/GST/VAT Setup.txt
          applications/vatecommerce/data/DemoTaxDataAU.xml
          applications/vatecommerce/data/DemoPartyAU.xml
          applications/vatecommerce/data/DemoProductAU.xml
          applications/vatecommerce/build.xml

          applications/order/config/OrderUiLabels_en_AU.properties

          there are an unneeded copies :
          applications/ecommerce/data/Copy of DemoProductAU.xml
          applications/vatecommerce/data/Copy of DemoProductAU.xml
          applications/order/webapp/ordermgr/entry/cart/Copy of showcartitems.ftl

          some very few tabs in
          applications/ecommerce/webapp/ecommerce/order/orderitems.ftl (around lines 240+)
          applications/vatecommerce/build.xml (around line 86)

          The file applications/ecommerce/ofbiz-component.xml is in the patch but unchanged (2 lines added not needed)

          This a primary review and I believe it would be helpful to separate data (demo, properties, etc.) from procedures (all the rest). Thus it will be easier to review the sources because it's a huge patch ;o)

          I look forward for more complete patches before testing. Except if you really need someone to test the work done so far.

          If you are ok I will delete old patches progressively (ok for 1st one ?)

          Thanks

          Show
          Jacques Le Roux added a comment - Hi David, Some comments : You did not check the ASF authorisation for this last patch (8/11/2006) To be commited in futur the following files need an ASL2 header and no author information : applications/ecommerce/config/EcommerceUiLabels_en_AU.properties applications/ecommerce/data/DemoTaxDataAU.xml applications/ecommerce/data/DemoPartyAU.xml applications/ecommerce/data/DemoProductAU.xml if applications/vatecommerce is untended to be commited (did not had enough time to review it in detail, seems to be a duplicate at first glance applications/vatecommerce/docs/GST/VAT Setup.txt applications/vatecommerce/data/DemoTaxDataAU.xml applications/vatecommerce/data/DemoPartyAU.xml applications/vatecommerce/data/DemoProductAU.xml applications/vatecommerce/build.xml applications/order/config/OrderUiLabels_en_AU.properties there are an unneeded copies : applications/ecommerce/data/Copy of DemoProductAU.xml applications/vatecommerce/data/Copy of DemoProductAU.xml applications/order/webapp/ordermgr/entry/cart/Copy of showcartitems.ftl some very few tabs in applications/ecommerce/webapp/ecommerce/order/orderitems.ftl (around lines 240+) applications/vatecommerce/build.xml (around line 86) The file applications/ecommerce/ofbiz-component.xml is in the patch but unchanged (2 lines added not needed) This a primary review and I believe it would be helpful to separate data (demo, properties, etc.) from procedures (all the rest). Thus it will be easier to review the sources because it's a huge patch ;o) I look forward for more complete patches before testing. Except if you really need someone to test the work done so far. If you are ok I will delete old patches progressively (ok for 1st one ?) Thanks
          Hide
          Jacques Le Roux added a comment -

          above "(all the rest)" means "(whole remainder)"
          sorry for this false friends error

          Show
          Jacques Le Roux added a comment - above "(all the rest)" means "(whole remainder)" sorry for this false friends error
          Hide
          David Garrett added a comment -

          Add-on to previous patch to allow order to be viewed in ordermgr

          Show
          David Garrett added a comment - Add-on to previous patch to allow order to be viewed in ordermgr
          Hide
          David Garrett added a comment -

          Jacques,

          Thanks for the comment.

          The patch is DEFINITELY NOT ready for inclusion yet. Btw, I like your idea for seperating the data/procedures.

          The purpose is to show the progress and , as David J suggested ...
          ... "The code doesn't have to be perfect, or even pretty. The point is to have a starting point for different areas that others can review and improve as approaches "perfection"."

          The code particularly the ecommerce cart/order UI is very ugly and full of my debug comments and working notes. My intention is to remove these and do a clean up well before the changes should be considedred even close for inclusion.

          I am working on the Invoice creation at the moment and want to get posting to the GL before I come back to cleanup.

          In the mean time at least anyone "enthusiastic" can see the direction that the change is going. The UI may be hard to interpret but the cart -> order process seems OK to me.

          There is a lot of work and changes as you point out so if it is going in the wrong direction ... NOW would be a good time to be told!!

          Thanks
          David G

          PS Yes. The first patch can be deleted. I could not find this in my attachment management options.

          Show
          David Garrett added a comment - Jacques, Thanks for the comment. The patch is DEFINITELY NOT ready for inclusion yet. Btw, I like your idea for seperating the data/procedures. The purpose is to show the progress and , as David J suggested ... ... "The code doesn't have to be perfect, or even pretty. The point is to have a starting point for different areas that others can review and improve as approaches "perfection"." The code particularly the ecommerce cart/order UI is very ugly and full of my debug comments and working notes. My intention is to remove these and do a clean up well before the changes should be considedred even close for inclusion. I am working on the Invoice creation at the moment and want to get posting to the GL before I come back to cleanup. In the mean time at least anyone "enthusiastic" can see the direction that the change is going. The UI may be hard to interpret but the cart -> order process seems OK to me. There is a lot of work and changes as you point out so if it is going in the wrong direction ... NOW would be a good time to be told!! Thanks David G PS Yes. The first patch can be deleted. I could not find this in my attachment management options.
          Hide
          Jacques Le Roux added a comment -

          David,

          The 1st patch is deleted, this is an option with special rights. ASA I will try to review deeper your patches.

          Take your time, thanks for all your good work !

          Show
          Jacques Le Roux added a comment - David, The 1st patch is deleted, this is an option with special rights. ASA I will try to review deeper your patches. Take your time, thanks for all your good work !
          Hide
          David Garrett added a comment -

          Updated VAT/GST patch (please disregard/delete previous patches).

          This patch can get all the way from cart to posted to GL (requires opentaps/financials)

          The user interface has been cleaned up of most of the debug messages. Althought there is still significant number of messages.

          This is a good, reasonably clean, version that is worth a look for those interested in this VAT issue. There is still more work required.

          ALL feedback appreciated!!

          David G

          Show
          David Garrett added a comment - Updated VAT/GST patch (please disregard/delete previous patches). This patch can get all the way from cart to posted to GL (requires opentaps/financials) The user interface has been cleaned up of most of the debug messages. Althought there is still significant number of messages. This is a good, reasonably clean, version that is worth a look for those interested in this VAT issue. There is still more work required. ALL feedback appreciated!! David G
          Hide
          Jacopo Cappellato added a comment -

          David G.,

          I've removed the old attachments as per your request.

          Show
          Jacopo Cappellato added a comment - David G., I've removed the old attachments as per your request.
          Hide
          Jacques Le Roux added a comment -

          David,

          Beware that if your code requires opentaps/financials it can't be at last included in OFBiz... (opentaps is GPL)

          Show
          Jacques Le Roux added a comment - David, Beware that if your code requires opentaps/financials it can't be at last included in OFBiz... (opentaps is GPL)
          Hide
          David E. Jones added a comment -

          Jacques: depending on how the code "depends" on the OSS financials component it may be okay. The only restriction is that it can't refer to code that is part of that module. If it sets things up so that when the stuff there is triggered, or uses the results of it running, that is fine.

          Show
          David E. Jones added a comment - Jacques: depending on how the code "depends" on the OSS financials component it may be okay. The only restriction is that it can't refer to code that is part of that module. If it sets things up so that when the stuff there is triggered, or uses the results of it running, that is fine.
          Hide
          Jacques Le Roux added a comment -

          Thanks David for this complement

          Show
          Jacques Le Roux added a comment - Thanks David for this complement
          Hide
          David Garrett added a comment -

          Sorry for not being clear.

          There is NO dependency on GPL code.

          The only link with financials is an opentaps/financials SECA (I think) which results in a postInvoiveToGL (or similar). This is all managed and setup in opentaps/Financials.

          I want a complete cart-to-gl VAT solution. All I do is ensure everything in Ofbiz is ready for financials to take over.

          Accordingly, I do not believe there is any licencing issue. More importantly my objective is to ensure there is no cross licence GPL issue introduced.

          David G

          Show
          David Garrett added a comment - Sorry for not being clear. There is NO dependency on GPL code. The only link with financials is an opentaps/financials SECA (I think) which results in a postInvoiveToGL (or similar). This is all managed and setup in opentaps/Financials. I want a complete cart-to-gl VAT solution. All I do is ensure everything in Ofbiz is ready for financials to take over. Accordingly, I do not believe there is any licencing issue. More importantly my objective is to ensure there is no cross licence GPL issue introduced. David G
          Hide
          Jacques Le Roux added a comment -

          Thanks for clarification David

          Show
          Jacques Le Roux added a comment - Thanks for clarification David
          Hide
          Jacques Le Roux added a comment -

          Hi David,

          I think there will be a new effort regarding VAT in OFBiz (see http://docs.ofbiz.org/display/OFBIZ/VAT). Do you think that these patches should still be considered ?

          Show
          Jacques Le Roux added a comment - Hi David, I think there will be a new effort regarding VAT in OFBiz (see http://docs.ofbiz.org/display/OFBIZ/VAT ). Do you think that these patches should still be considered ?
          Hide
          David Garrett added a comment -

          Jacques,

          I think it was a very good & (at the time) very close implementation. It was incomplete and still had screen comments and debug. Given that time has progressed there is another process of reintegration with the current head. This is a pain and the reason that I originally put the effort in to try to include the code into the base.

          Anyway I am open to getting involved again.

          The key issue from my experience is not the modeling and calculation of VAT on prices but more so

          • interacting with the way prices are displayed, and
          • inclusion of VAT adjustments with price rules, promotion and shipping

          If you are starting from a "clean page" look at the way prices are displayed and possibly consider whether a rework in this area may make the implementation easier.

          David

          Show
          David Garrett added a comment - Jacques, I think it was a very good & (at the time) very close implementation. It was incomplete and still had screen comments and debug. Given that time has progressed there is another process of reintegration with the current head. This is a pain and the reason that I originally put the effort in to try to include the code into the base. Anyway I am open to getting involved again. The key issue from my experience is not the modeling and calculation of VAT on prices but more so interacting with the way prices are displayed, and inclusion of VAT adjustments with price rules, promotion and shipping If you are starting from a "clean page" look at the way prices are displayed and possibly consider whether a rework in this area may make the implementation easier. David
          Hide
          Jacques Le Roux added a comment -

          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 :

          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 ?

          Show
          Jacques Le Roux added a comment - 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 ?
          Hide
          David Garrett added a comment -

          Some comments ...

          It is definitely easier to deal (initially) with tax inclusive pricing in ProductPrice but I think this leads to further downline issues particularly when considering how to post the base and tax amounts as accounting transactions. Having different tax adjustment types provides the benefit that it allows for configurable posting rules.

          My view and implementations have always been based on the fact that it is best to keep the tax separate all through the process. Maybe I have been wrong. I have seen that there are differing views on this point. It would probably be worth getting a common view on this.

          My approach (from memory, without diving into the code again) was to base the implementation on prices being exVAT. I used TaxAuthorityRateProduct to get the tax adjustment. I think this was done after the initial price rules. The promotion adjustments are typically based on the exTax price therefore additional VAT adjustments were created to match the Promotion. There was a weakness in this approach that the underlying implementation did not allow for maintaining the relationship between the exTax Adjustment and the associated VAT adjustment (Thereby passing a problem to returns!).

          I implemented a few promotions that I wanted.

          Does this make sense. Let me know and I can clarify.

          David

          Show
          David Garrett added a comment - Some comments ... It is definitely easier to deal (initially) with tax inclusive pricing in ProductPrice but I think this leads to further downline issues particularly when considering how to post the base and tax amounts as accounting transactions. Having different tax adjustment types provides the benefit that it allows for configurable posting rules. My view and implementations have always been based on the fact that it is best to keep the tax separate all through the process. Maybe I have been wrong. I have seen that there are differing views on this point. It would probably be worth getting a common view on this. My approach (from memory, without diving into the code again) was to base the implementation on prices being exVAT. I used TaxAuthorityRateProduct to get the tax adjustment. I think this was done after the initial price rules. The promotion adjustments are typically based on the exTax price therefore additional VAT adjustments were created to match the Promotion. There was a weakness in this approach that the underlying implementation did not allow for maintaining the relationship between the exTax Adjustment and the associated VAT adjustment (Thereby passing a problem to returns!). I implemented a few promotions that I wanted. Does this make sense. Let me know and I can clarify. David
          Hide
          Jacques Le Roux added a comment -

          David,

          I have no intention to deal with tax inclusive pricing. I think (like everyone so far I guess) that it's better to keep prices are they are (tax exclusive) and to deal with taxes at the UI level. Sometime, as you pointed out) you need to add some adjustments here and there (also when users change prices in order view for instance) but without changing genuine prices, as these prices changes are only temporary changes.

          For the weakness you speak about, I remember having troubles also and did some hacks in the data model but without degrading it. I used some orderAdjustment fields (orderItemSeqId, shipGroupSeqId and comments IIRW) which were unused in the cases I had to deal with in. Maybe some other stuff I can't recall from the top of my head. Anyway if needed we could add some new fields. I don't know if I will find the time to backport and adapt the work I did. It was with release4.0 which is not too much different. So hopefully I will create a patch for the community to review. Actuallly if I do that, I will try to create many incremental patches to have a chance to be reviewed...

          Show
          Jacques Le Roux added a comment - David, I have no intention to deal with tax inclusive pricing. I think (like everyone so far I guess) that it's better to keep prices are they are (tax exclusive) and to deal with taxes at the UI level. Sometime, as you pointed out) you need to add some adjustments here and there (also when users change prices in order view for instance) but without changing genuine prices, as these prices changes are only temporary changes. For the weakness you speak about, I remember having troubles also and did some hacks in the data model but without degrading it. I used some orderAdjustment fields (orderItemSeqId, shipGroupSeqId and comments IIRW) which were unused in the cases I had to deal with in. Maybe some other stuff I can't recall from the top of my head. Anyway if needed we could add some new fields. I don't know if I will find the time to backport and adapt the work I did. It was with release4.0 which is not too much different. So hopefully I will create a patch for the community to review. Actuallly if I do that, I will try to create many incremental patches to have a chance to be reviewed...
          Hide
          Jacques Le Roux added a comment -

          Hi David,

          This patch is far too big and too old now. But I hope to continue on analysis and design using David's HEMP method on this subject. It looks really appropriate.

          Show
          Jacques Le Roux added a comment - Hi David, This patch is far too big and too old now. But I hope to continue on analysis and design using David's HEMP method on this subject. It looks really appropriate.
          Hide
          Jacques Le Roux added a comment -

          Also I'd like to close this issue, WDYT ?

          Show
          Jacques Le Roux added a comment - Also I'd like to close this issue, WDYT ?
          Hide
          David Garrett added a comment -

          Please close this issue.

          Show
          David Garrett added a comment - Please close this issue.

            People

            • Assignee:
              Jacques Le Roux
              Reporter:
              David Garrett
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development