Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-5163

Tax calculated on unit price before adjustments

Agile BoardAttach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Incomplete
    • Trunk
    • None
    • accounting

    Description

      Some taxes cut in at a minimum item price. A promotional adjustment can lower the price the customer is paying, so they should not have to pay any tax. However, the tax is being calculated on the base item price, before any promotional adjustment.

      r1449615 was a partial fix, but only when the order quantity is one. In the more complex situation where the quantity is greater than one, at present the tax calculation does not have the information it needs. All it has is the base unit price for the item ("itemPrice"), and the total amount for the item ("itemAmount", which is itemPrice * quantity - adjustments).

      Here's what I think needs to happen.

      1. We need to define two categories of item adjustments:

      • those which modify the price, including promotional pricing and discounts
      • adjustments for additional services such as shipping, an extended warranty and so on.

      The first category should be combined with the product price before tax calculations are done. The second category may need to be taxed separately.

      So a new attribute should be added to the OrderAdjustment entity to say which it is.

      2. An additional list of data needs to be supplied to the tax calculation, a list of adjusted unit prices with promotional discounts and any other adjustments in the first category above. The tax calculation would, of course, use the adjusted unit price, so the change at https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java?hb=true#to215
      won't be needed any more.

      If we do these, there would be no need for the calcTaxAfterPromotion attribute. In effect, it would always apply, for adjustments in category 1. If anyone didn't want that behaviour, all they would need to do is define an adjustment in category 2, not 1.

      This issue was found and worked on by Tom at ANTWebsystems, thanks for your help.

      Attachments

        Issue Links

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            paulfoxworthy Paul Foxworthy
            paulfoxworthy Paul Foxworthy
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment