Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | ||||||||
0045844 | ||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
backport | [Openbravo ERP] 04. Warehouse management | critical | always | 2021-02-02 10:40 | 2021-02-08 12:56 | |||
Reporter | gorkaion | View Status | public | |||||
Assigned To | markmm82 | |||||||
Priority | immediate | Resolution | fixed | Fixed in Version | PR20Q4.2 | |||
Status | closed | Fix in branch | Fixed in SCM revision | |||||
Projection | none | ETA | none | Target Version | PR20Q4.2 | |||
OS | Any | Database | Any | Java version | ||||
OS Version | Database version | Ant version | ||||||
Product Version | SCM revision | |||||||
Merge Request Status | approved | |||||||
Review Assigned To | ||||||||
OBNetwork customer | Gold | |||||||
Web browser | ||||||||
Modules | Core | |||||||
Support ticket | 21532 | |||||||
Regression level | Production - Confirmed Stable | |||||||
Regression date | 2019-09-09 | |||||||
Regression introduced in release | 3.0PR19Q4 | |||||||
Regression introduced by commit | https://gitlab.com/openbravo/product/openbravo/-/commit/a0cdfc9f6f68a6235ce22d00b0f53d94504a05d6 [^] | |||||||
Triggers an Emergency Pack | No | |||||||
Summary | 0045844: Error on Fix Backadated Transaction process. A trx is wrongly considered as backdated | |||||||
Description | The fix backdated transaction is not checking the transaction dates by product. This can lead to false positives and adjusting transactions that are not backdated. Having the following transactions processed in the given order: Product A mvt date 01-01-2021 Product A mvt date 10-01-2021 Product A mvt date 01-02-2021 Product B mvt date 20-01-2021 The fix backdated transaction process tries to adjust as backdated transaction the last trasnaction from product B because the previous transaction from Product A has a newer movement date. This is wrong, the transaction from Product B has to be compared with other transactions of the same product. If the fix backdated transactions are already enabled in the costing rule that transaction won't be automatically adjusted as backdated. If the false positive is the 1st transaction of the product the process fails with an error: 2021-02-02 08:57:02,284 [http-6] ERROR org.openbravo.costing.FixBackdatedTransactionsProcess - null java.lang.NullPointerException: null at org.openbravo.costing.AverageCostAdjustment.extendPreviousCosting(AverageCostAdjustment.java:1022) ~[classes/:?] at org.openbravo.costing.AverageCostAdjustment.calculateBackdatedTrxAdjustment(AverageCostAdjustment.java:593) ~[classes/:?] at org.openbravo.costing.CostingAlgorithmAdjustmentImp.searchRelatedTransactionCosts(CostingAlgorithmAdjustmentImp.java:145) ~[classes/:?] at org.openbravo.costing.CostAdjustmentProcess.calculateAdjustmentAmount(CostAdjustmentProcess.java:238) ~[classes/:?] at org.openbravo.costing.CostAdjustmentProcess.processCostAdjustment(CostAdjustmentProcess.java:82) ~[classes/:?] at org.openbravo.costing.CostAdjustmentProcess.doProcessCostAdjustment(CostAdjustmentProcess.java:342) ~[classes/:?] at org.openbravo.costing.FixBackdatedTransactionsProcess.doExecute(FixBackdatedTransactionsProcess.java:143) [classes/:?] at org.openbravo.client.application.process.BaseProcessActionHandler.execute(BaseProcessActionHandler.java:153) [classes/:?] at org.openbravo.client.kernel.BaseActionHandler.execute(BaseActionHandler.java:74) [classes/:?] at org.openbravo.client.kernel.KernelServlet.processActionRequest(KernelServlet.java:319) [classes/:?] at org.openbravo.client.kernel.KernelServlet.doGet(KernelServlet.java:208) [classes/:?] at org.openbravo.client.kernel.KernelServlet.doPost(KernelServlet.java:291) [classes/:?] at javax.servlet.http.HttpServlet.service(HttpServlet.java:661) [tomcat8-servlet-api.jar:?] at org.openbravo.base.HttpBaseServlet.serviceInitialized(HttpBaseServlet.java:200) [openbravo-core.jar:?] at org.openbravo.base.secureApp.HttpSecureAppServlet.service(HttpSecureAppServlet.java:459) [classes/:?] at org.openbravo.client.kernel.BaseKernelServlet.callServiceInSuper(BaseKernelServlet.java:89) [classes/:?] at org.openbravo.client.kernel.BaseKernelServlet.service(BaseKernelServlet.java:60) [classes/:?] at org.openbravo.client.kernel.KernelServlet.service(KernelServlet.java:170) [classes/:?] at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) [tomcat8-servlet-api.jar:?] | |||||||
Steps To Reproduce | On F&B EspaƱa. Check that Costing Rule does not have the fix backdated transactions enabled. Check the newest transaction movement date on some products. Create a new product and set a purchase price. Create a receipt for the new product with a movement date in the past. Ensure that it is a date older than the checked for other products. Ensure that the cost of the receipt is calculated. Go to Costing Rule and execute the Fix Backdated transactions process. Set a starting date before the date used in the receipt. | |||||||
Proposed Solution | The transaction movement dates shall be compared on same product transactions. Change the getTransactions method to sort the transactions also by product and modify the transaction loop to manage when the product changes. | |||||||
Tags | No tags attached. | |||||||
Attached Files | ||||||||
![]() |
||||||||
|
![]() |
|
(0125992) hgbot (developer) 2021-02-04 18:43 |
Merge Request created: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/308 [^] |
(0126026) hgbot (developer) 2021-02-08 12:53 |
Merge request merged: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/308 [^] |
(0126030) hgbot (developer) 2021-02-08 12:56 |
Directly closing issue as related merge request is already approved. Repository: https://gitlab.com/openbravo/product/openbravo [^] Changeset: f05a3df2cb9334af66230bfcafec405c0081fc45 Author: Mark <markmm82@gmail.com> Date: 2021-02-04T14:42:23-03:00 URL: https://gitlab.com/openbravo/product/openbravo/-/commit/f05a3df2cb9334af66230bfcafec405c0081fc45 [^] Fixes ISSUE-45844: Fixed error on Fix Backdated Transaction process. In some cases was possible that transaction ordering without having into account ordering by product, caused that transactions be wrongly considered as backdated. To fix this issue the transaction movement dates is compared on same product transactions. The getTransactions method was changed to sort the transactions also by product and always reset the comparison date of the last transaction for the product when the product changes on the loop. --- M src/org/openbravo/costing/FixBackdatedTransactionsProcess.java --- |
(0126031) hgbot (developer) 2021-02-08 12:56 |
Repository: https://gitlab.com/openbravo/product/openbravo [^] Changeset: 06a791b786f4956f087403e60db0658ae072b76e Author: Mark <markmm82@gmail.com> Date: 2021-02-05T13:58:09-03:00 URL: https://gitlab.com/openbravo/product/openbravo/-/commit/06a791b786f4956f087403e60db0658ae072b76e [^] Related to ISSUE-45844: Improve the ordering by explicitly do by product id column --- M src/org/openbravo/costing/FixBackdatedTransactionsProcess.java --- |
![]() |
|||
Date Modified | Username | Field | Change |
2021-02-03 23:27 | markmm82 | Type | defect => backport |
2021-02-03 23:27 | markmm82 | Target Version | => PR20Q4.2 |
2021-02-04 18:43 | hgbot | Merge Request Status | => open |
2021-02-04 18:43 | hgbot | Note Added: 0125992 | |
2021-02-08 12:53 | hgbot | Merge Request Status | open => approved |
2021-02-08 12:53 | hgbot | Note Added: 0126026 | |
2021-02-08 12:56 | hgbot | Resolution | open => fixed |
2021-02-08 12:56 | hgbot | Status | scheduled => closed |
2021-02-08 12:56 | hgbot | Fixed in Version | => PR20Q4.2 |
2021-02-08 12:56 | hgbot | Note Added: 0126030 | |
2021-02-08 12:56 | hgbot | Note Added: 0126031 |
Copyright © 2000 - 2009 MantisBT Group |