Openbravo Issue Tracking System - Retail Modules | |||||
| View Issue Details | |||||
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0038859 | Retail Modules | Web POS | public | 2018-06-28 18:45 | 2018-07-26 10:33 |
| Reporter | guilleaer | ||||
| Assigned To | ranjith_qualiantech_com | ||||
| Priority | normal | Severity | major | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Platform | OS | 5 | OS Version | ||
| Product Version | |||||
| Target Version | Fixed in Version | RR18Q4 | |||
| Merge Request Status | |||||
| Review Assigned To | marvintm | ||||
| OBNetwork customer | OBPS | ||||
| Support ticket | 2701 | ||||
| Regression level | |||||
| Regression date | |||||
| Regression introduced in release | |||||
| Regression introduced by commit | |||||
| Triggers an Emergency Pack | No | ||||
| Summary | 0038859: Calculations performed when cash management is done are not being managed in a transactional way | ||||
| Description | Code executed when "DONE" button is pressed in cash mangement window after add a drop or deposit should be transactional. why? There is information which is written in different tables and it must be consistent. Currently if the process fails or if it is interrupted we can have unpredictable discrepancies in tables afected by a cash management (cashup, cashmanagement and paymentmethodcashup) The first function which should start the transaction is OB.UTIL.sumCashManagementToCashup which is called inside the function updateCashupInfo which is called recursively. -> Here paymentmethodcashup is readed, with those values and values coming from the action, new values are calculated and then updated and saved back in the DB. After that, cashup is updated through OB.UTIL.composeCashupInfo. As you can see, above functions are being managed without transaction, so any error could lead into a situation like: ------> payment method cashup updated but not cashup *note that OB.UTIL.composeCashupInfo is already prepared to work with tx but we are not using it Next function to analyze is setCashupObjectInCashMgmt. This function is called recursively after updateCashupInfo. We need to analyze it from 2 perspectives. a) For every iteration (except last one) a save is done in cashmanagment table. After this save, function is called again (recursively) until every event is processed. ----->>>>> This save should be also transactional b) When all has been processed OB.UTIL.calculateCurrentCash function is executed. Again this function is already prepared to work with transactions but we are NOT using it. It can create a problem having cash management action without updating current cash -->> The execution of OB.UTIL.calculateCurrentCash should be included in the same transaction used for all of the previous actions explained in this issue. Then, synchronization can start. Here a different transaction starts already managed by synchronization engine so here there is nothing to do. | ||||
| Steps To Reproduce | N/A | ||||
| Proposed Solution | Use a transactianal approach for the process explained above | ||||
| Additional Information | |||||
| Tags | No tags attached. | ||||
| Relationships | |||||
| Attached Files | |||||
| Issue History | |||||
| Date Modified | Username | Field | Change | ||
| 2018-06-28 18:45 | guilleaer | New Issue | |||
| 2018-06-28 18:45 | guilleaer | Assigned To | => Retail | ||
| 2018-06-28 18:45 | guilleaer | OBNetwork customer | => Yes | ||
| 2018-06-28 18:45 | guilleaer | Support ticket | => 2701 | ||
| 2018-06-28 18:45 | guilleaer | Resolution time | => 1531951200 | ||
| 2018-06-28 18:45 | guilleaer | Triggers an Emergency Pack | => No | ||
| 2018-06-28 23:52 | egoitz | Issue Monitored: egoitz | |||
| 2018-07-05 14:05 | ranjith_qualiantech_com | Status | new => scheduled | ||
| 2018-07-06 08:03 | ranjith_qualiantech_com | Assigned To | Retail => ranjith_qualiantech_com | ||
| 2018-07-12 10:54 | hgbot | Checkin | |||
| 2018-07-12 10:54 | hgbot | Note Added: 0105710 | |||
| 2018-07-12 10:54 | hgbot | Status | scheduled => resolved | ||
| 2018-07-12 10:54 | hgbot | Resolution | open => fixed | ||
| 2018-07-12 10:54 | hgbot | Fixed in SCM revision | => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/d0c321969e06bffeb59b4a84be9201f30d7325ec [^] | ||
| 2018-07-17 16:58 | guilleaer | Review Assigned To | => guilleaer | ||
| 2018-07-17 16:58 | guilleaer | Status | resolved => closed | ||
| 2018-07-17 16:58 | guilleaer | Fixed in Version | => RR18Q4 | ||
| 2018-07-19 08:31 | hgbot | Checkin | |||
| 2018-07-19 08:31 | hgbot | Note Added: 0105786 | |||
| 2018-07-19 08:31 | hgbot | Status | closed => resolved | ||
| 2018-07-19 08:31 | hgbot | Fixed in SCM revision | http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/d0c321969e06bffeb59b4a84be9201f30d7325ec [^] => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/1ad43c7c4a84b337cd8e23a082b41feb17ed7d15 [^] | ||
| 2018-07-20 08:17 | ranjith_qualiantech_com | Note Deleted: 0105786 | |||
| 2018-07-26 10:33 | marvintm | Review Assigned To | guilleaer => marvintm | ||
| 2018-07-26 10:33 | marvintm | Status | resolved => closed | ||
| Notes | |||||
|
|
|||||
|
|
||||