Openbravo Issue Tracking System - Retail Modules
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0045377Retail ModulesWeb POSpublic2020-11-04 17:332020-11-20 08:40
Reportermartinsdan 
Assigned Toranjith_qualiantech_com 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionunable to reproduce 
PlatformOS30OS VersionUbuntu 18.04.1 LTS
Product Version 
Target VersionFixed in VersionRR20Q4 
Merge Request Status
Review Assigned Tomarvintm
OBNetwork customer
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0045377: Rounding payment should not be added if the payment is not added
DescriptionIf the rounding feature is configured for a payment and the payment is canceled when inserting, the rounding payment is still added.
If an OBPOS_preAddPayment adds the flag cancellation to true, the original payment is not added but the rounding payment is.
Steps To Reproduce- Create an OBPOS_preAddPayment hook that adds "args.cancellation = false" if a payment is bigger than 100.
- Add a rounding to the payment method cash
  - Go to Terminal Type | Payment Method
  - Create a new payment method marked as rounding
  - Go to the payment method cash and add a new entry in the subtab Payment Rounding
  - Activate it for sales, Rounding down and "Rounding Multiple in Sales" = 0.05
- Login to the touchpoint
- Add a product that costs 101.23
- Pay it in cash

See that the only payment added is the rounding payment with an amount of 0.03
Proposed SolutionIf the flag canceled is true after running all the hooks, the respective rounding payment should be reverted.
Additional Information
TagsNo tags attached.
Relationships
depends on backport 0045469RR20Q3.2 closed ranjith_qualiantech_com Rounding payment should not be added if the payment is not added 
Attached Filesdiff 45377_posterminal_20Q2.diff (1,143) 2020-11-20 07:57
https://issues.openbravo.com/file_download.php?file_id=15099&type=bug
diff 45377_posterminal_20Q3.diff (1,144) 2020-11-20 08:39
https://issues.openbravo.com/file_download.php?file_id=15100&type=bug
Issue History
Date ModifiedUsernameFieldChange
2020-11-04 17:33martinsdanNew Issue
2020-11-04 17:33martinsdanAssigned To => Retail
2020-11-04 17:33martinsdanResolution time => 1605657600
2020-11-04 17:33martinsdanTriggers an Emergency Pack => No
2020-11-12 09:38ranjith_qualiantech_comAssigned ToRetail => ranjith_qualiantech_com
2020-11-16 09:13ranjith_qualiantech_comStatusnew => scheduled
2020-11-18 11:45martinsdanNote Added: 0124475
2020-11-19 13:09ranjith_qualiantech_comFile Added: 45377.diff
2020-11-20 07:57ranjith_qualiantech_comFile Deleted: 45377.diff
2020-11-20 07:57ranjith_qualiantech_comFile Added: 45377_posterminal_20Q2.diff
2020-11-20 08:38marvintmStatusscheduled => acknowledged
2020-11-20 08:38marvintmStatusacknowledged => scheduled
2020-11-20 08:39ranjith_qualiantech_comFile Added: 45377_posterminal_20Q3.diff
2020-11-20 08:40marvintmReview Assigned To => marvintm
2020-11-20 08:40marvintmNote Added: 0124518
2020-11-20 08:40marvintmStatusscheduled => closed
2020-11-20 08:40marvintmResolutionopen => unable to reproduce
2020-11-20 08:40marvintmFixed in Version => RR20Q4

Notes
(0124475)
martinsdan   
2020-11-18 11:45   
This is reproducible in 20Q2.
https://livebuilds.openbravo.com/retail_mp_3.0RR20Q2.2/web/org.openbravo.retail.posterminal/?terminal=VBS1001#retail.pointofsale [^]
(0124518)
marvintm   
2020-11-20 08:40   
The issue is no longer reproducible in 20Q4 or pi. We have created the backport for 20Q3.2, and we have also attached a patch that should be possible to use in 20Q2 and hopefully earlier versions.