Openbravo Issue Tracking System - Openbravo ERP |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0055634 | Openbravo ERP | 04. Warehouse management | public | 2024-05-30 21:01 | 2024-06-13 18:41 |
|
| Reporter | sdossantos | |
| Assigned To | AtulOpenbravo | |
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | |
| Platform | | OS | 5 | OS Version | |
| Product Version | pi | |
| Target Version | | Fixed in Version | PR24Q3 | |
| Merge Request Status | approved |
| Review Assigned To | |
| OBNetwork customer | OBPS |
| Web browser | |
| Modules | Core |
| Support ticket | 96211 |
| Regression level | |
| Regression date | |
| Regression introduced in release | |
| Regression introduced by commit | |
| Triggers an Emergency Pack | No |
|
| Summary | 0055634: Error with columns in Valued Stock Report |
| Description | Depending on the last update of the costing rule, you can see the columns Actual Average Algorithm Cost and Actual Average Algorithm Valuation. |
| Steps To Reproduce | 1- Check the update in costing rule, for example in for organization The White Valley Franchise, the date is 04-07-2013 20:01:13
2- Go to Valued Stock Report with this organization The White Valley Franchise, checked Consolidated warehouse, date 05-07-2013, we can see all columns.
But if the date is 03-07-2013, we can not see the columns Actual Average Algorithm Cost and Actual Average Algorithm Valuation. |
| Proposed Solution | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | |
| Attached Files |  Videograbación 2024-05-30 16:02:02.mp4 (1,416,653) 2024-05-30 21:02
https://issues.openbravo.com/file_download.php?file_id=19838&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2024-05-30 21:01 | sdossantos | New Issue | |
| 2024-05-30 21:01 | sdossantos | Assigned To | => Triage Omni WMS |
| 2024-05-30 21:01 | sdossantos | OBNetwork customer | => OBPS |
| 2024-05-30 21:01 | sdossantos | Modules | => Core |
| 2024-05-30 21:01 | sdossantos | Support ticket | => 96211 |
| 2024-05-30 21:01 | sdossantos | Triggers an Emergency Pack | => No |
| 2024-05-30 21:02 | sdossantos | File Added: Videograbación 2024-05-30 16:02:02.mp4 | |
| 2024-06-11 16:37 | mtaal | Note Added: 0165803 | |
| 2024-06-11 16:37 | mtaal | Note Added: 0165804 | |
| 2024-06-11 18:59 | AtulOpenbravo | Status | new => scheduled |
| 2024-06-11 18:59 | AtulOpenbravo | Assigned To | Triage Omni WMS => AtulOpenbravo |
| 2024-06-11 19:06 | hgbot | Merge Request Status | => open |
| 2024-06-11 19:06 | hgbot | Note Added: 0165812 | |
| 2024-06-13 18:40 | hgbot | Merge Request Status | open => approved |
| 2024-06-13 18:41 | hgbot | Note Added: 0165921 | |
| 2024-06-13 18:41 | hgbot | Resolution | open => fixed |
| 2024-06-13 18:41 | hgbot | Status | scheduled => closed |
| 2024-06-13 18:41 | hgbot | Fixed in Version | => PR24Q3 |
| 2024-06-13 18:41 | hgbot | Note Added: 0165922 | |
|
Notes |
|
|
(0165803)
|
|
mtaal
|
|
2024-06-11 16:37
|
|
Analysis by Gorka Ion:
very corner case, but it could be a real issue
those columns where added in 2013 when the current cost engine was implemented. in the previous engine the stock valuation was calculated by multiplying the stock level with the average cost valid on the date in the filter. in the new engine the valuation is calculated by summing the cost of the transactions (and the unit cost by dividing teh valuation by the stock)
so the report has to execute a different query when you are filtering by a date before the migration or after the migration. that date is defined as the oldest update date within the costing rules existing in the ad_client_id
this usually works since the update date is when the costing rule is processed and later is not modified anymore
but there is a single process that can modify the updates. If the fix backdated transactions process is executed later.
Gorka Ion Damián, 3:31 PM
there are two possible approaches:
1. keep the current check assuming that there are still customers with costs calculated with the previous engine (that is already removed from the code). then we need to
a. modify the "Fix Backdated Transactions" process to it does not update the costing rule updated date when the backdated transactions fixed flag and timestamp is set. this requires the customers affected to modify through the database the updated date to an unknown timestamp between the creation and the updated.
b. modify the check to search if the average costs calculated in the filter date are related to the current or the old engine instead of getting the oldest updated date. This query is worse from the performance point of view but can be fast enough
2. assume that there are no customers with costs calculated in the old engine and refactor the report to remove the queries getting the data calculated with the old engine. we can assume that any customer with such data has migrated long time ago so they won't execute the report on those dates. |
|
|
|
(0165804)
|
|
mtaal
|
|
2024-06-11 16:37
|
|
the idea is to implement option 2. The original code is [1], we will keep only [2]
[1]
String compare = DateTimeData.compare(readOnlyCP, strDate, ReportValuationStockData
.getCostingMigrationDate(readOnlyCP, legalEntity.getClient().getId()));
String strCostOrg = "";
String strCostClientId = "";
if (StringUtils.equals(compare, "-1")) {
// Date is before migration, available types are ST and AV. These costs are created at
// client level and organization can be any that belong to the client.
strCostType = "'AV', 'ST'";
strCostClientId = OBContext.getOBContext().getCurrentClient().getId();
orgs = osp.getChildTree("0", true);
} else if (ca != null) {
strCostType = getCostType(ca);
strCostOrg = strLegalEntity;
}
[2]
strCostType = getCostType(ca);
strCostOrg = strLegalEntity; |
|
|
|
(0165812)
|
|
hgbot
|
|
2024-06-11 19:06
|
|
|
|
|
(0165921)
|
|
hgbot
|
|
2024-06-13 18:41
|
|
|
|
|
(0165922)
|
|
hgbot
|
|
2024-06-13 18:41
|
|
|