0045845: Error on Fix Backadated Transaction process. A trx is wrongly considered as backdated

Openbravo Issue Tracking System - Openbravo ERP

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0045845

Openbravo ERP

04. Warehouse management

public

2021-02-02 10:40

2021-02-08 12:56

Reporter

gorkaion

Assigned To

markmm82

Priority

immediate

Severity

critical

Reproducibility

always

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

Target Version

PR20Q3.4

Fixed in Version

PR20Q3.4

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

Summary

0045845: 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.

Additional Information