Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0039974
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajoralways2019-01-18 12:042019-03-06 17:43
ReporternicolasurizView Statuspublic 
Assigned Togorka_gil 
PriorityhighResolutionfixedFixed in VersionRR19Q2
StatusclosedFix in branchFixed in SCM revision7e3dcc1726ae
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Merge Request Status
Review Assigned Toguilleaer
OBNetwork customerGold
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0039974: Wrong behaviour of the destination in the overpayment of an order with pay open tickets and two different payment methods.

DescriptionA pay open tickets with two layaways, and paying them with two different payment methods differents to cash, for example "Voucher" and "Credit Card". Voucher is defined as "0" in overpayment limit and the other is permitted. An overpayment of 0.01 is done, and in backend is registered as an other payment and with two lines of 1 cent each.

Reproduced in livebuilds, retail with modules.

Check this video in case o dubts about the backend register:
https://drive.google.com/file/d/1-GJuC6wHItgR38tfEV2Xq57dCv8__WZC/view [^]
Steps To Reproduce1) Go to backend, Channel touchpoint of "VBS-1" and then navigate to the Touchpoint type.
2) Go to "payment method" tab and define Voucher as not possible to do overpayments with value "0" and credit card allowing overpayments with value "".
3) Login to POS Create two layaways with the same Bussiness partner, one of them with 129.99$ and the other with 49.99$.
4) Open the previous layaways.
5) Do a pay open tickets with both of them.
6) Pay 149.99$ with Voucher as payment method and other with 30$ with credit card.
7) Login to backend, and check the "payment in" window.
8) There is one payment created for the overpayment, and at line level of this payment, there are two lines with 0.01 cents each when the overpayment is only 0.01 in total.
Proposed SolutionThe overpayment should be displayed in the same “payment in” window line with the suppose payment method of the order, in this case should be displayed in the "wire transfer" payment method line, as one line more, and not as another payment. Anyway, it is not correct to have two lines of the same overpayment, it is a mistake.
TagsNo tags attached.
Attached Files? file icon issue_39974.export [^] (12,735 bytes) 2019-02-26 10:07

- Relationships [ Relation Graph ] [ Dependency Graph ]
depends on backport 0040280RR19Q1 closedgorka_gil Wrong behaviour of the destination in the overpayment of an order with pay open tickets and two different payment methods. 

-  Notes
(0109283)
hgbot (developer)
2019-01-28 18:33

 Repository: tools/automation/pi-mobile
Changeset: 03de69d63b090785655f7e63199def067ec7bc63
Author: Alejandro <alekosmp86 <at> gmail.com>
Date: Wed Jan 23 14:20:51 2019 -0500
URL: http://code.openbravo.com/tools/automation/pi-mobile/rev/03de69d63b090785655f7e63199def067ec7bc63 [^]

Related to issue 39974: added automated test

---
A src-test/org/openbravo/test/mobile/retail/pack/selenium/tests/payment/I39974_VerifyOverpaymentWith2DifferentPaymentMethods.java
---
(0109653)
hgbot (developer)
2019-02-07 16:03

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 90341f66b809db8b852e2b54dc89419aa2b453f4
Author: Rafael Queralta <rafaelcuba81 <at> gmail.com>
Date: Wed Feb 06 11:48:26 2019 -0500
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/90341f66b809db8b852e2b54dc89419aa2b453f4 [^]

Fixed issue 39974: Wrong behaviour of the destination in the overpayment of an
order with pay open tickets and two different payment methods.

- Avoided duplicate Payment In record for positive overpayment

---
M src/org/openbravo/retail/posterminal/OrderLoader.java
---
(0109654)
hgbot (developer)
2019-02-07 16:06

 Repository: tools/automation/pi-mobile
Changeset: 246be9d490e514e65d531310399ea4c3c5110d99
Author: Rafael Queralta <rafaelcuba81 <at> gmail.com>
Date: Wed Feb 06 11:51:04 2019 -0500
URL: http://code.openbravo.com/tools/automation/pi-mobile/rev/246be9d490e514e65d531310399ea4c3c5110d99 [^]

Related to issue 39974: Avoided duplicate Payment In record for overpayment

---
M src-test/org/openbravo/test/mobile/retail/pack/selenium/tests/payment/I39726_VerifyNoErrorWithAndWithoutOverpayments.java
---
(0109661)
marvintm (viewer)
2019-02-11 11:13

 The fix is not correct, and not what we want, so it should be reverted.

The root cause of the problem comes from the fact that overpayment limits are not taken into account by the payment distribution algorithm in Pay Open Tickets. Therefore, it could happen that payments are incorrectly distributed between orders and then generating an overpayment when in reality it should not.

The solution is to sort the payments before the payment distribution over ticket happens. We should move the payments related to payment methods without overpayment limit to the beginning of the list, leaving the payments with overpayment limit to the end of the list. This way, all the overpayment will be assigned to the last ticket, and the problem will no longer happen.
(0110099)
hgbot (developer)
2019-02-27 10:08

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 7e3dcc1726ae8b26bae49be36b3b04185ef255ce
Author: Asier Martirena <asier.martirena <at> openbravo.com>
Date: Fri Feb 22 22:52:32 2019 +0100
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/7e3dcc1726ae8b26bae49be36b3b04185ef255ce [^]

Fixed issue 39974: The overpayment was not setting correctly

When overpayment was being generated from the Web POS, instead of the overpayment an empty payment detail was being created caused by a credit generation, which shouldn't happen.

---
M src/org/openbravo/retail/posterminal/OrderLoader.java
---

- Issue History
Date Modified Username Field Change
2019-01-18 12:04 nicolasuriz New Issue
2019-01-18 12:04 nicolasuriz Assigned To => Retail
2019-01-18 12:04 nicolasuriz OBNetwork customer => Gold
2019-01-18 12:04 nicolasuriz Resolution time => 1548802800
2019-01-18 12:04 nicolasuriz Triggers an Emergency Pack => No
2019-01-19 19:25 rqueralta Assigned To Retail => rqueralta
2019-01-19 19:25 rqueralta Status new => scheduled
2019-01-28 18:33 hgbot Checkin
2019-01-28 18:33 hgbot Note Added: 0109283
2019-02-07 16:03 hgbot Checkin
2019-02-07 16:03 hgbot Note Added: 0109653
2019-02-07 16:04 hgbot Status scheduled => resolved
2019-02-07 16:04 hgbot Resolution open => fixed
2019-02-07 16:04 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/90341f66b809db8b852e2b54dc89419aa2b453f4 [^]
2019-02-07 16:06 hgbot Checkin
2019-02-07 16:06 hgbot Note Added: 0109654
2019-02-11 11:13 marvintm Note Added: 0109661
2019-02-11 11:13 marvintm Status resolved => new
2019-02-11 11:13 marvintm Resolution fixed => open
2019-02-11 18:55 marvintm Assigned To rqueralta => asiermartirena
2019-02-15 09:04 marvintm Resolution time 1548802800 => 1551049200
2019-02-22 08:32 marvintm Resolution time 1551049200 => 1551740400
2019-02-26 10:07 asiermartirena File Added: issue_39974.export
2019-02-26 10:26 asiermartirena Assigned To asiermartirena => gorka_gil
2019-02-27 10:08 hgbot Checkin
2019-02-27 10:08 hgbot Note Added: 0110099
2019-02-27 10:08 hgbot Status new => resolved
2019-02-27 10:08 hgbot Resolution open => fixed
2019-02-27 10:08 hgbot Fixed in SCM revision http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/90341f66b809db8b852e2b54dc89419aa2b453f4 [^] => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/7e3dcc1726ae8b26bae49be36b3b04185ef255ce [^]
2019-02-27 10:41 gorka_gil Status resolved => new
2019-02-27 10:41 gorka_gil Resolution fixed => open
2019-02-27 10:42 gorka_gil Status new => scheduled
2019-02-27 10:42 gorka_gil Status scheduled => resolved
2019-02-27 10:42 gorka_gil Resolution open => fixed
2019-03-06 17:43 guilleaer Review Assigned To => guilleaer
2019-03-06 17:43 guilleaer Status resolved => closed
2019-03-06 17:43 guilleaer Fixed in Version => RR19Q2

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker