Openbravo Issue Tracking System - Retail Modules
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0034275Retail ModulesDiscounts and Promotionspublic2016-10-21 20:462016-12-21 11:50
Reporterrbianchini 
Assigned Tomarvintm 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product VersionRR16Q3.2 
Target VersionFixed in VersionRR17Q1 
Merge Request Status
Review Assigned Toguilleaer
OBNetwork customer
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0034275: Sell at cost discount wrong calculate if the sales price list includes tax
DescriptionWhen you sell at cost and the sales pricelist includes taxes, the total = cost = gross unit price and net unit price = gross unit price - taxes.
Also, in sales order line window, the field discount is set to 0, when it should be filled with the % discounted
Steps To Reproduce1 - Install the modules:
http://centralrepository.openbravo.com/openbravo/org.openbravo.forge.ui/ForgeModuleDetail/Product-Cost-For-WebPOS [^] and
http://centralrepository.openbravo.com/openbravo/org.openbravo.forge.ui/ForgeModuleDetail/Sell-At-Cost-Discretionary-Discount [^]
2 - Make sure that the product has a record in unit cost tab: http://wiki.openbravo.com/wiki/Projects:Stock_Valuation#Stock_Valuation [^] and the sales price list include taxes.
3 - Configure a new discount "sell at cost" with this link: http://wiki.openbravo.com/wiki/Modules:Sell_Cost_Price [^]
4 - In web pos, insert a product in the receipt, in the menu, select the option Receipt discount and apply the sell at cost discount created in step 3
5 - Go to ERP and open the Sales ordered created in previous step
6 - Realize that net unit price is less than the cost, and the cost is equals to the gross unit price. The right gross unit price should be cost + taxes and the net unit price should be the cost, other way the bussiness is loosing money.
7 - Also realize that the discount field is 0, when it should be filled with the % discounted
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
related to defect 0034084 new Retail Pending test to be developed 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2016-10-21 20:46rbianchiniNew Issue
2016-10-21 20:46rbianchiniAssigned To => Retail
2016-10-21 20:46rbianchiniResolution time => 1478833200
2016-10-21 20:46rbianchiniTriggers an Emergency Pack => No
2016-10-22 21:25eugeniIssue Monitored: eugeni
2016-10-29 01:02rbianchiniDescription Updatedbug_revision_view_page.php?rev_id=13527#r13527
2016-10-29 01:02rbianchiniSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=13529#r13529
2016-11-15 17:38jorge-garciaAssigned ToRetail => jorge-garcia
2016-11-17 11:57marvintmResolution time1478833200 =>
2016-11-17 11:57marvintmNote Added: 0091630
2016-11-17 11:57marvintmTypedefect => design defect
2016-11-17 12:10jorge-garciaAssigned Tojorge-garcia => Retail
2016-11-17 13:47eugeniNote Added: 0091634
2016-11-24 09:06marvintmNote Added: 0091771
2016-11-24 09:07marvintmRegression date => 2016-12-08
2016-11-24 09:07marvintmTypedesign defect => defect
2016-11-28 12:53maiteResolution time => 1481151600
2016-11-28 12:53maiteRegression date2016-12-08 =>
2016-11-30 18:55marvintmStatusnew => scheduled
2016-11-30 18:55marvintmAssigned ToRetail => marvintm
2016-12-06 12:21hgbotCheckin
2016-12-06 12:21hgbotNote Added: 0092136
2016-12-06 12:21hgbotStatusscheduled => resolved
2016-12-06 12:21hgbotResolutionopen => fixed
2016-12-06 12:21hgbotFixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.retail.discounts.cost/rev/ba618b2af8c43367048e8f11e9c9666dacee43a5 [^]
2016-12-06 12:23marvintmRelationship addedrelated to 0034084
2016-12-19 12:59guilleaerNote Added: 0092776
2016-12-19 12:59guilleaerStatusresolved => new
2016-12-19 12:59guilleaerResolutionfixed => open
2016-12-19 12:59guilleaerNote Edited: 0092776bug_revision_view_page.php?bugnote_id=0092776#r14060
2016-12-19 13:00guilleaerNote Edited: 0092776bug_revision_view_page.php?bugnote_id=0092776#r14061
2016-12-20 19:41hgbotCheckin
2016-12-20 19:41hgbotNote Added: 0092869
2016-12-20 19:41hgbotStatusnew => resolved
2016-12-20 19:41hgbotResolutionopen => fixed
2016-12-20 19:41hgbotFixed in SCM revisionhttp://code.openbravo.com/erp/pmods/org.openbravo.retail.discounts.cost/rev/ba618b2af8c43367048e8f11e9c9666dacee43a5 [^] => http://code.openbravo.com/erp/pmods/org.openbravo.retail.discounts.cost/rev/f6e478dd178936d661d0eebab7ecceddace3d426 [^]
2016-12-21 11:50guilleaerReview Assigned To => guilleaer
2016-12-21 11:50guilleaerStatusresolved => closed
2016-12-21 11:50guilleaerFixed in Version => RR17Q1

Notes
(0091630)
marvintm   
2016-11-17 11:57   
The module was implemented with the idea that the discount can be computed directly by checking just the product price and the cost. This is correct when using price including taxes, but not when not using price not including taxes.

Implementing the discount as described would probably not be correct, as taxes are computed from the total of the line, not the price, and fixing this problem would involve changing the fundamental implementation of the module.
(0091634)
eugeni   
2016-11-17 13:47   
@marvintm:

"This is correct when using price including taxes, but not when not using price not including taxes" --> I would say that is exactly the opposite, i.ed:

This is correct when using price excluding taxes, but not when using price including taxes. Using price including VAT is the regular way to deal with prices at point of sales for most retailers, therefore this module is basically useless for them. As a tip, take a look to margin indicator module, now it works properly with prices including taxes
(0091771)
marvintm   
2016-11-24 09:06   
Hi Eugeni,

Sorry, I wrote my comment in a bit of a rush. You are of course right, the module works correctly when using price not including taxes, but doesn't work in the case of price including taxes.

When we looked at this issue, we thought that the Margin Indicator module was a different situation, because it is computed when the taxes have already been calculated, and the net price is available.

In the case of the Sell at Cost discount, we originally misunderstood as we thought that the discount was applied automatically. Automatic discounts are applied before taxes are calculated, which meant that we didn't know which were the net amounts, and particularly the net price, as those were not computed yet.

However, this module actually adds a discretionary discount rule, which means that we do have access to the net amounts, so now we believe that we can fix the problem, and we will try to do so.
(0092136)
hgbot   
2016-12-06 12:21   
Repository: erp/pmods/org.openbravo.retail.discounts.cost
Changeset: ba618b2af8c43367048e8f11e9c9666dacee43a5
Author: Antonio Moreno <antonio.moreno <at> openbravo.com>
Date: Tue Dec 06 12:21:29 2016 +0100
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.discounts.cost/rev/ba618b2af8c43367048e8f11e9c9666dacee43a5 [^]

Fixed issue 34275. Discount will now be correct with price including taxes. Fixed async problem with latest Retail releases.
- Now when using price including taxes, the discount will be computed so that the final price without taxes is equal to the cost. This means that the final total amount will be the cost amount, plus the taxes.
- Additionally, a calculateGross call has been added at the end of the process, to fix an async problem with this module and the latest versions of Retail.

---
M web/org.openbravo.retail.discounts.cost/source/promotion-cost.js
---
(0092776)
guilleaer   
2016-12-19 12:59   
(edited on: 2016-12-19 13:00)
It seems that calculations are not working properly when line qty are incremeted or new lines are added to the receipt

I have added this log line to the code

definition.amt = OB.DEC.mul(price.subtract(OB.DEC.toBigDecimal(costPrice)).multiply(OB.DEC.toBigDecimal(rate)), line.get('qty'));
+ console.log("rate:" + rate + " price: " + price.toString() + " net: " + net.toString() + " def: " + definition.amt + " cost: " + costPrice + " lineGross: " + line.get('gross'));

If you add a product, then apply cost discount to that product and then you add a new unit to this line... calculations are wrong

rate:1.21 price: 2.39669421487603305785 net: 2.39669421487603305785 def: 1.77 cost: 0.93 lineGross: 2.9 -->> OK
VM7903:1 add unit
8345fcf…_WebPOS.js:71719 rate:3.12 price: 0.46474358974358974359 net: 0.92948717948717948718 def: -2.9 cost: 0.93 lineGross: 2.9 -->> WRONG

it seems that rate value is causing the issue.

Some strange problems are also happening if you add new lines to the ticket after apply the discount to the line
(0092869)
hgbot   
2016-12-20 19:41   
Repository: erp/pmods/org.openbravo.retail.discounts.cost
Changeset: f6e478dd178936d661d0eebab7ecceddace3d426
Author: Antonio Moreno <antonio.moreno <at> openbravo.com>
Date: Tue Dec 20 19:41:41 2016 +0100
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.discounts.cost/rev/f6e478dd178936d661d0eebab7ecceddace3d426 [^]

Fixed issue 34275. Several additional changes have been made:
- Removed unnecessary calculateGross.
- Find has been replaced fin findUsingCache. This improves performance, and removes asynchronous behavior, indirectly fixing a problem with asynchronous execution of the manual discount rule by the automatic discounts engine.
- Replaced linerate by linerateWithPrecision. This property has the correct value in all circumstances, and has greater precision, which is better for our purposes.
- Gross will be computed from the quantity and price. Standard gross property may not have the final value in this case, as calculateGross has not been executed yet (it comes after the discounts engine has finished), but quantity has the right value.

---
M web/org.openbravo.retail.discounts.cost/source/promotion-cost.js
---