Openbravo Issue Tracking System - Retail Modules
View Issue Details
0039974Retail ModulesWeb POSpublic2019-01-18 12:042019-03-06 17:43
0039974: Wrong behaviour of the destination in the overpayment of an order with pay open tickets and two different payment methods.
A 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: [^]
1) 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.
The 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.
No tags attached.
depends on backport 0040280RR19Q1 closed gorka_gil Wrong behaviour of the destination in the overpayment of an order with pay open tickets and two different payment methods. 
? issue_39974.export (12,735) 2019-02-26 10:07
Issue History
2019-01-18 12:04nicolasurizNew Issue
2019-01-18 12:04nicolasurizAssigned To => Retail
2019-01-18 12:04nicolasurizTriggers an Emergency Pack => No
2019-01-19 19:25rqueraltaAssigned ToRetail => rqueralta
2019-01-19 19:25rqueraltaStatusnew => scheduled
2019-01-28 18:33hgbotCheckin
2019-01-28 18:33hgbotNote Added: 0109283
2019-02-07 16:03hgbotCheckin
2019-02-07 16:03hgbotNote Added: 0109653
2019-02-07 16:04hgbotStatusscheduled => resolved
2019-02-07 16:04hgbotResolutionopen => fixed
2019-02-07 16:04hgbotFixed in SCM revision => [^]
2019-02-07 16:06hgbotCheckin
2019-02-07 16:06hgbotNote Added: 0109654
2019-02-11 11:13marvintmNote Added: 0109661
2019-02-11 11:13marvintmStatusresolved => new
2019-02-11 11:13marvintmResolutionfixed => open
2019-02-11 18:55marvintmAssigned Torqueralta => asiermartirena
2019-02-26 10:07asiermartirenaFile Added: issue_39974.export
2019-02-26 10:26asiermartirenaAssigned Toasiermartirena => gorka_gil
2019-02-27 10:08hgbotCheckin
2019-02-27 10:08hgbotNote Added: 0110099
2019-02-27 10:08hgbotStatusnew => resolved
2019-02-27 10:08hgbotResolutionopen => fixed
2019-02-27 10:08hgbotFixed in SCM revision [^] => [^]
2019-02-27 10:41gorka_gilStatusresolved => new
2019-02-27 10:41gorka_gilResolutionfixed => open
2019-02-27 10:42gorka_gilStatusnew => scheduled
2019-02-27 10:42gorka_gilStatusscheduled => resolved
2019-02-27 10:42gorka_gilResolutionopen => fixed
2019-03-06 17:43guilleaerReview Assigned To => guilleaer
2019-03-06 17:43guilleaerStatusresolved => closed
2019-03-06 17:43guilleaerFixed in Version => RR19Q2

2019-01-28 18:33   
Repository: tools/automation/pi-mobile
Changeset: 03de69d63b090785655f7e63199def067ec7bc63
Author: Alejandro <alekosmp86 <at>>
Date: Wed Jan 23 14:20:51 2019 -0500
URL: [^]

Related to issue 39974: added automated test

A src-test/org/openbravo/test/mobile/retail/pack/selenium/tests/payment/
2019-02-07 16:03   
Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 90341f66b809db8b852e2b54dc89419aa2b453f4
Author: Rafael Queralta <rafaelcuba81 <at>>
Date: Wed Feb 06 11:48:26 2019 -0500
URL: [^]

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/
2019-02-07 16:06   
Repository: tools/automation/pi-mobile
Changeset: 246be9d490e514e65d531310399ea4c3c5110d99
Author: Rafael Queralta <rafaelcuba81 <at>>
Date: Wed Feb 06 11:51:04 2019 -0500
URL: [^]

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

M src-test/org/openbravo/test/mobile/retail/pack/selenium/tests/payment/
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.
2019-02-27 10:08   
Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 7e3dcc1726ae8b26bae49be36b3b04185ef255ce
Author: Asier Martirena <asier.martirena <at>>
Date: Fri Feb 22 22:52:32 2019 +0100
URL: [^]

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/