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

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0039974
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajoralways2019-01-18 12:042019-02-15 09:04
ReporternicolasurizView Statuspublic 
Assigned Toasiermartirena 
PriorityhighResolutionopenFixed in Version
StatusnewFix in branchFixed in SCM revision90341f66b809
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
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

- Relationships Relation Graph ] Dependency Graph ]

-  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 (developer)
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.

- 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 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


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker