Openbravo Issue Tracking System - Openbravo ERP | |||||
View Issue Details | |||||
ID | Project | Category | View Status | Date Submitted | Last Update |
0044540 | Openbravo ERP | 04. Warehouse management | public | 2020-07-02 10:57 | 2020-07-20 13:23 |
Reporter | gorkaion | ||||
Assigned To | inigo_lerga | ||||
Priority | high | Severity | major | Reproducibility | random |
Status | closed | Resolution | fixed | ||
Platform | OS | 5 | OS Version | ||
Product Version | |||||
Target Version | Fixed in Version | ||||
Merge Request Status | |||||
Review Assigned To | |||||
OBNetwork customer | |||||
Web browser | |||||
Modules | Core | ||||
Support ticket | |||||
Regression level | |||||
Regression date | |||||
Regression introduced in release | |||||
Regression introduced by commit | |||||
Triggers an Emergency Pack | No | ||||
Summary | 0044540: getLastCumulatedCosting returns random average when there are cost with same datefrom and dateto | ||||
Description | When the last cost with cumulative values has the same datefrom and dateto values than others the getLastCumulatedCosting return a random average cost. The method is only ordering by those 2 fields so in case there are several with the same values a random cost is returned. This scenario is caused when there is a document with several lines of the same product (with different attribute or storage bin) and all of them generate an average cost. The normal situation is that from those lines the last processed one has a different dateto. If this transaction is adjusted the cumulative values are nullified so the next transaction with cumulative values have the same dateto and datefrom as other. | ||||
Steps To Reproduce | 1. Create a document with several lines (at least 4) of the same product and quantity but different attributes or storage bin. 1.1. Issue has been detected using manufacturing but it should be reproduced also with a receipt or inventory. 2. Run the costing process. 3. Check that an average cost for each line has been created and that at least 2 of them has the same datefrom and dateto 4. Manually adjust the last calculated transactions. Identified by the average cost that has a different dateto. 5. Check that now the last average cost with cumulative values is one with the same datefrom and dateto. 6. Create a goods movement. 7. Run the background process and debug it to check that the query of getLastCumulatedCosting can return any of the costs with the same datefrom and dateto | ||||
Proposed Solution | Add an additional orderby clause by creation date so in case there are two or more costs with same datefrom and dateto the last created one is returned. | ||||
Additional Information | |||||
Tags | No tags attached. | ||||
Relationships | |||||
Attached Files | |||||
Issue History | |||||
Date Modified | Username | Field | Change | ||
2020-07-02 10:57 | gorkaion | New Issue | |||
2020-07-02 10:57 | gorkaion | Assigned To | => Triage Finance | ||
2020-07-02 10:57 | gorkaion | Modules | => Core | ||
2020-07-02 10:57 | gorkaion | Triggers an Emergency Pack | => No | ||
2020-07-02 10:58 | gorkaion | Resolution time | => 1595455200 | ||
2020-07-02 11:30 | jfrances | Issue Monitored: jfrances | |||
2020-07-03 12:48 | dmiguelez | Assigned To | Triage Finance => inigo_lerga | ||
2020-07-07 10:33 | inigo_lerga | Status | new => scheduled | ||
2020-07-07 12:21 | inigo_lerga | Note Added: 0121298 | |||
2020-07-09 10:31 | hgbot | Note Added: 0121349 | |||
2020-07-20 12:21 | ngarcia | Issue Monitored: ngarcia | |||
2020-07-20 13:23 | hgbot | Resolution | open => fixed | ||
2020-07-20 13:23 | hgbot | Status | scheduled => closed | ||
2020-07-20 13:23 | hgbot | Note Added: 0121529 | |||
2020-07-20 13:23 | hgbot | Note Added: 0121530 |
Notes | |||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|