Openbravo Issue Tracking System - Retail Modules
View Issue Details
0023456Retail ModulesWeb POSpublic2013-04-02 05:422014-02-25 17:51
sureshbabu 
guilleaer 
highminoralways
closedinvalid 
5
 
 
guilleaer
No
0023456: When a product is wrongly assigned to 2 different types of discount categories, then both the discounts are applied in POS o
When a product is wrongly assigned to 2 different types of discount categories, then both the discounts are applied in POS without warning.
At Backend, from discounts and promotion window i have defined 2 different types of discount categories and assigned Alphine Sking Backpack 27L in both the categories

a) Created Fixed discount

Discount: 100%

Product: Alphine Sking Backpack 27L

b) Pack for promotion price of 333.33 and included two products

Alphine Sking Backpack 27L Qty: 14

Baby Carrier qty: 14

And i missed to assign priorities for both the categories.
Then in webpos, i tried to create receipt By adding the above defined pack. Right now system wrongly apply both the discounts(fixed discount as well as promotion price) without any warning (please refer the screen shot, for the below receipt, user cannot complete the receipt since the total amount is in -ve amount)

Note: And more over usually in promotions, no two promotions cannot be clubbed or combined.

Edited by @guilleaer
This issue is not well reported. You must indicate all the details about how are discounts configured.

Case 1 (current issue):
- No priorities
- Apply next ENABLED
Expected result: Both discount should be applied without a specific order, because the priorities are not set.
Current result: WRONG -> Just pack is used and both should be used

Case 2:
- No priorities
- Apply next DISABLED
Expected result: Just one discount should be applied, but we don't know which because priorities are not set.
Current result: OK. Just pack is applied. (if just fixed is applied also will be OK)

Case 3A
- More priority to fixed discount
- Apply next ENABLED
Expected result: Both discounts should be applied, applying first the fixed discount.
Current result: OK

Case 3B
- More priority to fixed discount
- Apply next DISABLED
Expected result: Just fixed discount should be applied
Current result: OK

Case 4A
- More priority to pack
- Apply next ENABLED
Expected result: Both discounts should be applied, applying first the pack.
Current result: Wrong -> Just pack is applied

Case 4B
- More priority to pack
- Apply next DISABLED
Expected result: Just pack should be applied
Current result: OK
No tags attached.
png When two different discount categories (Pack and fixed discount), are applied for same product and when i use the product in POS, system wrongly apply both the discounts with out any warning.png (254,329) 2013-04-02 05:42
https://issues.openbravo.com/file_download.php?file_id=6047&type=bug
png
Issue History
2013-04-02 05:42sureshbabuNew Issue
2013-04-02 05:42sureshbabuAssigned To => marvintm
2013-04-02 05:42sureshbabuFile Added: When two different discount categories (Pack and fixed discount), are applied for same product and when i use the product in POS, system wrongly apply both the discounts with out any warning.png
2013-04-02 21:20sureshbabuSeveritymajor => minor
2014-01-10 16:47guilleaerTriggers an Emergency Pack => No
2014-01-10 16:47guilleaerSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=5322#r5322
2014-02-25 17:47guilleaerAssigned Tomarvintm => guilleaer
2014-02-25 17:50guilleaerNote Added: 0064573
2014-02-25 17:51guilleaerReview Assigned To => guilleaer
2014-02-25 17:51guilleaerNote Added: 0064574
2014-02-25 17:51guilleaerStatusnew => closed
2014-02-25 17:51guilleaerResolutionopen => invalid

Notes
(0064573)
guilleaer   
2014-02-25 17:50   
For packs, apply next discounts field is not taken into account. As explained in the documentation this field is always false for packs

"Apply Next Discount: Because this promotion type requires multiple line to be computed, it does not allow to apply other promotions after it, so this flag is forced to be false."

Looking to the steps to reproduce added by @guilleaer and taking into account this limitation, this issue can be closed.
(0064574)
guilleaer   
2014-02-25 17:51   
As explained in the previous note, this issue is not valid. -> Closed