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

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0046874
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[POS2] POSmajoralways2021-05-27 16:492021-09-03 10:01
ReporterpsanjuanView Statuspublic 
Assigned Tovmromanos 
PriorityurgentResolutionfixedFixed in Version
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSLinux 64 bitDatabasePostgreSQLJava version7.x
OS VersionOpenbravo Appliance 14.04Database version9.3.xAnt version1.9.x
Product VersionSCM revision 
Review Assigned To
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0046874: Cash up not correct while using Credit Notes feature

DescriptionCash up not correct while using Credit Notes feature
Steps To Reproduce0-Login POS2 as vallblanca with Credit Notes configuration completed.
1-Run a cash up process to be sure that there are no pending receipts, that all the amount has been counted and nothing has been kept in the terminal.
1-Add 1x "of any product. Note that the total sale is 12€ for instance.
2-Pay the sale with the payment method that has been configured to generate credit in case there is an "Overpaument", for instance "Voucher".
3-Pay a higher amount, for instance with a voucher of 20€
4-Complete the sale.
5-Verify that a credit note receipt is printed for an amount of 20-12=8€ (expiration date = at summer time. This is not correct as an expiration number of days is setup).
6-Close the till and keep the voucher amount in the till.

The cash up information shown to count is 20€ of voucher and 8 of the credit. The report print is also not correct as it shows:
Sales 12 € - correct
Retail transactions - 12 € correct
Expected amount = 28€ (this is not correct, it should be 20)
Counted amount = 28 (this is not correct, it should be 20)
Total to keep = 20 (this is correct)
Total to deposit = 8 (not correct it should be 0)
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to defect 0046877 closedvmromanos Credit Note feature does not manage properly the credit do not used. 
depends on backport 0047102TAP closedvmromanos Cash up not correct while using Credit Notes feature 
has duplicate defect 0047586 closedvmromanos JIRA 2297 - Generation through overpayment and payment amount in BO 

-  Notes
(0128731)
psanjuan (developer)
2021-05-27 17:03
edited on: 2021-05-27 17:07

To review once it is possible to have an updated environment running with this feature properly configured, that is related to a "Ticket Restaurant" payment method.

I am not sure about the correct configuration of this feature because it is not explained in this document, whether the payment method "Credit Note" of the Channel Touch point must be configured as "Leave as Credit" or "Cash" (I think it should be Leave as Credit)??).

See: https://docs.google.com/document/d/1fl1MLX7UVexVNazL_B6sCju2a93bOBXkeR9ZvNI8ifY/edit# [^] (see section Create a Touchpoint Type Payment Method)

It should be properly defined how the cash up must look like while using this new feature, under a set of a given scenarios.

(0130467)
dmiguelez (developer)
2021-07-14 13:03

We are not sure if this is a real issue or a configuration problem, it must be reviewed properly.

Therefore, the severity has been updated.
(0130866)
dmiguelez (developer)
2021-07-29 10:05

Verify as a reproducible major issue that has to be fixed
(0131503)
hgbot (developer)
2021-09-02 09:40

Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.giftcards/-/merge_requests/84 [^]
(0131520)
vmromanos (developer)
2021-09-02 17:05

Test plan:

0-Login POS2 as vallblanca with Credit Notes configuration completed.
1-Run a cash up process to be sure that there are no pending receipts, that all the amount has been counted and nothing has been kept in the terminal.
1-Add 1x "of any product. Note that the total sale is 12€ for instance.
2-Pay the sale with the payment method that has been configured to generate credit in case there is an "Overpaument", for instance "Voucher".
3-Pay a higher amount, for instance with a voucher of 20€
4-Complete the sale.
5-Verify that a credit note receipt is printed for an amount of 20-12=8€
6-Close the till

The cash up information shown to count is 20€ of voucher and 8 of the credit. The report print is also not correct as it shows:
Sales 12 €
Retail transactions 12 €

Expected amount = 12 €
* Voucher = 20 €
* Credit Note = -8 €

Counted amount = 12 €
* Voucher = 20 €
* Credit Note = -8 €


Total to deposit = 12 €
* Voucher = 20 €
* Credit Note = -8 €


Go to the backoffice
Search for this Sales Order
Verify two payment details are shown:
* Check (associated to the Voucher): 20 €
* Credit Note: -8 €

Search for the Gift Card Instance just created:
Verify: Initial Balance = Current Balance = 8

Browse to the Payment In:
Verify: Amount: -8€
(0131539)
hgbot (developer)
2021-09-03 10:01

Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.giftcards [^]
Changeset: 415597c282a52f53fe09dab8a07d4325a5c2e111
Author: Víctor Martínez Romanos <victor.martinez@openbravo.com>
Date: 2021-09-02T09:36:47+02:00
URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.giftcards/-/commit/415597c282a52f53fe09dab8a07d4325a5c2e111 [^]

Fixed ISSUE-46874: Credit note generated by overpayment in cashup

Before the fix the credit note generated by an overpayment was shown
in the cashup as a positive amount. This is wrong because actually
we are not paying using a credit note but generating a credit note, so
in this case the credit note's amount should have a negative sign.

The fix sets the credit note's payment amount as a negative amount, so
it's properly shown in the cashup as negative amount too. This is done
in the gift card's prehook in charge of generating this credit note
payment information.

When the Payment In and the Gift Card Instance are registered into the
Backoffice, the former has a negative sign (because it's a credit note
generation) and the latter has a positive sign obviously.

The Sales Order payment details look good after the change, showing two
payment details:
- Positive amount with the overpayment
- Negative amount for the credit note creation
If you sum both amounts, you get the grand total amount

---
M web-jspack/org.openbravo.retail.giftcards/src/model/ticket/CreditNoteTicketExtension.js
---
(0131540)
hgbot (developer)
2021-09-03 10:01

Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.giftcards [^]
Changeset: 7974484a5f8764ae732657b0ceb01cbf43441b75
Author: Víctor Martínez Romanos <victor.martinez@openbravo.com>
Date: 2021-09-02T10:24:03+02:00
URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.giftcards/-/commit/7974484a5f8764ae732657b0ceb01cbf43441b75 [^]

Related to ISSUE-46874: Adapted automatic tests

For the tests where a credit note has been generated from an overpayment,
the amount has been changed to negative because this kind of payments
represents a credit note generation and therefore they are negative payments.

---
M web-jspack/org.openbravo.retail.giftcards/src/model/ticket/__test__/CreditNoteTicketExtension.test.jsx
---
(0131541)
hgbot (developer)
2021-09-03 10:01

Merge request merged: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.giftcards/-/merge_requests/84 [^]

- Issue History
Date Modified Username Field Change
2021-05-27 16:49 psanjuan New Issue
2021-05-27 16:49 psanjuan Assigned To => Retail
2021-05-27 16:49 psanjuan Triggers an Emergency Pack => No
2021-05-27 17:03 psanjuan Note Added: 0128731
2021-05-27 17:03 psanjuan Steps to Reproduce Updated View Revisions
2021-05-27 17:04 psanjuan Note Edited: 0128731 View Revisions
2021-05-27 17:07 psanjuan Note Edited: 0128731 View Revisions
2021-06-14 09:58 guilleaer Resolution time => 1624572000
2021-06-14 09:58 guilleaer Status new => scheduled
2021-06-14 09:59 guilleaer Status scheduled => acknowledged
2021-07-14 13:03 dmiguelez Resolution time 1624572000 => 1628028000
2021-07-14 13:03 dmiguelez Note Added: 0130467
2021-07-14 13:03 dmiguelez Severity major => minor
2021-07-29 10:05 dmiguelez Relationship added related to 0046877
2021-07-29 10:05 dmiguelez Severity minor => major
2021-07-29 10:05 dmiguelez Note Added: 0130866
2021-08-06 11:33 dmiguelez Resolution time 1628028000 => 1629410400
2021-08-31 13:39 vmromanos Assigned To Retail => vmromanos
2021-09-02 09:35 vmromanos Status acknowledged => scheduled
2021-09-02 09:40 hgbot Note Added: 0131503
2021-09-02 16:36 vmromanos Relationship added causes 0047586
2021-09-02 17:05 vmromanos Note Added: 0131520
2021-09-03 10:01 hgbot Resolution open => fixed
2021-09-03 10:01 hgbot Status scheduled => closed
2021-09-03 10:01 hgbot Note Added: 0131539
2021-09-03 10:01 hgbot Note Added: 0131540
2021-09-03 10:01 hgbot Note Added: 0131541
2021-09-03 10:08 vmromanos Relationship replaced has duplicate 0047586


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker