Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | ||||||||
| 0041428 | ||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
| feature request | [Retail Modules] Web POS | minor | have not tried | 2019-07-23 10:12 | 2019-09-12 09:57 | |||
| Reporter | adrianromero | View Status | public | |||||
| Assigned To | adrianromero | |||||||
| Priority | normal | Resolution | fixed | Fixed in Version | RR19Q4 | |||
| Status | closed | Fix in branch | Fixed in SCM revision | 174cc3511d2f | ||||
| Projection | none | ETA | none | Target Version | ||||
| OS | Any | Database | Any | Java version | ||||
| OS Version | Database version | Ant version | ||||||
| Product Version | SCM revision | |||||||
| Review Assigned To | marvintm | |||||||
| Regression level | ||||||||
| Regression date | ||||||||
| Regression introduced in release | ||||||||
| Regression introduced by commit | ||||||||
| Triggers an Emergency Pack | No | |||||||
| Summary | 0041428: Define a new Payment type UNDEFINED to always have a payment method to assign transactions | |||||||
| Description | In the functionality Payment Methods grouping by Provider http://wiki.openbravo.com/wiki/Retail:Payment_Methods_grouping_by_Provider_User_Guide [^] may happen if there is not a payment method defined with the type returned by the provider. If this is the case an error is displayed to the user warning that the payment has been charged to the customer but it cannot be added any payment line to the receipt because there is not any payment method that can be assigned to the type returned. This situation is hard to manage because the customer has been charged and the money must be returned to him manually. | |||||||
| Steps To Reproduce | In description | |||||||
| Proposed Solution | Create an special payment type named "UNDEFINED" that in case there is no payment method with the payment type returned by the payment provider then use the payment method with the special payment type "UNDEFINED". This way, all approved transactions will have a payment method even in the case there is no match because in this case the payment method with payment type "UNDEFINED" will be used. | |||||||
| Tags | No tags attached. | |||||||
| Attached Files | ||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
|
 Relationships |
|
Notes |
|
|
(0114316) hgbot (developer) 2019-08-29 08:59 |
Repository: erp/pmods/org.openbravo.retail.posterminal Changeset: 174cc3511d2f16b9c129ec72373a258fb42701f1 Author: Adrián Romero <adrianromero <at> openbravo.com> Date: Tue Jul 23 10:12:57 2019 +0200 URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/174cc3511d2f16b9c129ec72373a258fb42701f1 [^] Fixes issue 0041428: Define a new Payment type UNDEFINED to always have a payment method to assign transactions --- M web/org.openbravo.retail.posterminal/js/components/modalprovidergroup.js --- |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2019-07-23 10:12 | adrianromero | New Issue | |
| 2019-07-23 10:12 | adrianromero | Assigned To | => Retail |
| 2019-07-23 10:12 | adrianromero | Triggers an Emergency Pack | => No |
| 2019-08-29 08:59 | hgbot | Checkin | |
| 2019-08-29 08:59 | hgbot | Note Added: 0114316 | |
| 2019-08-29 08:59 | hgbot | Status | new => resolved |
| 2019-08-29 08:59 | hgbot | Resolution | open => fixed |
| 2019-08-29 08:59 | hgbot | Fixed in SCM revision | => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/174cc3511d2f16b9c129ec72373a258fb42701f1 [^] |
| 2019-09-03 09:26 | shuehner | Assigned To | Retail => adrianromero |
| 2019-09-12 09:57 | marvintm | Review Assigned To | => marvintm |
| 2019-09-12 09:57 | marvintm | Status | resolved => closed |
| 2019-09-12 09:57 | marvintm | Fixed in Version | => RR19Q4 |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |