Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | ||||||||
0046874 | ||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
defect | [POS2] POS | major | always | 2021-05-27 16:49 | 2021-09-03 10:01 | |||
Reporter | psanjuan | View Status | public | |||||
Assigned To | vmromanos | |||||||
Priority | urgent | Resolution | fixed | Fixed in Version | ||||
Status | closed | Fix in branch | Fixed in SCM revision | |||||
Projection | none | ETA | none | Target Version | ||||
OS | Linux 64 bit | Database | PostgreSQL | Java version | 7.x | |||
OS Version | Openbravo Appliance 14.04 | Database version | 9.3.x | Ant version | 1.9.x | |||
Product Version | SCM revision | |||||||
Review Assigned To | ||||||||
Regression level | ||||||||
Regression date | ||||||||
Regression introduced in release | ||||||||
Regression introduced by commit | ||||||||
Triggers an Emergency Pack | No | |||||||
Summary | 0046874: Cash up not correct while using Credit Notes feature | |||||||
Description | Cash up not correct while using Credit Notes feature | |||||||
Steps To Reproduce | 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€ (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) | |||||||
Tags | No tags attached. | |||||||
Attached Files | ||||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | ||||||||||||||||||||||
|
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 |