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

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0038859
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajorhave not tried2018-06-28 18:452018-07-26 10:33
ReporterguilleaerView Statuspublic 
Assigned Toranjith_qualiantech_com 
PrioritynormalResolutionfixedFixed in VersionRR18Q4
StatusclosedFix in branchFixed in SCM revision1ad43c7c4a84
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Merge Request Status
Review Assigned Tomarvintm
OBNetwork customerOBPS
Support ticket2701
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0038859: Calculations performed when cash management is done are not being managed in a transactional way

DescriptionCode 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 ReproduceN/A
Proposed SolutionUse a transactianal approach for the process explained above
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]

-  Notes
(0105710)
hgbot (developer)
2018-07-12 10:54

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: d0c321969e06bffeb59b4a84be9201f30d7325ec
Author: Ranjith S R <ranjith <at> qualiantech.com>
Date: Thu Jul 12 14:24:36 2018 +0530
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/d0c321969e06bffeb59b4a84be9201f30d7325ec [^]

Fixed issue 38859 : Added transaction for cash management dal operations

* Transaction is added while doing DONE operation in Cash management

---
M web/org.openbravo.retail.posterminal/js/cashmgmt/model/cashmgmt-model.js
M web/org.openbravo.retail.posterminal/js/utils/cashUpReportUtils.js
---

- 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

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker