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

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0044938
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] 04. Warehouse managementmajoralways2020-08-31 14:492020-09-02 08:45
ReportergorkaionView Statuspublic 
Assigned Todmiguelez 
PriorityhighResolutionfixedFixed in VersionPR20Q4
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0044938: Cost Adjustment process do not generate required transaction cost records in some scenarios

DescriptionIt has been observed in a customer environment that some cost adjustment lines have not their related record in the m_transaction_cost table generated.

This is causing wrong costs calculation as some processes are summing the transaction cost amount to calculate the cost.

On the customer instance we have observed that:

1. The affected cost adjustment lines are always negative stock corrections.
2. They are the last cost adjustment line generated for a "parent cost adjustment line"

If a cost adjustment generates missing transaction costs creating a new manual adjustment on the same source transaction reproduces also the issue. Meaning that there must be a way to reproduce the issue in a consistent way.

Adding some log we have found out that the issue is caused by an early return [1] in the while loop of related transactions in AverageCostAdjustment class. That return is existing the getRelatedTransactionsByAlgorithm method. This causes that:
* Flush and clear at the end of each loop [2] is not executed
* Last check on current average cost [3] is not executed



[1] https://gitlab.com/openbravo/product/openbravo/-/blob/master/src/org/openbravo/costing/AverageCostAdjustment.java#L415 [^]
[2] https://gitlab.com/openbravo/product/openbravo/-/blob/master/src/org/openbravo/costing/AverageCostAdjustment.java#L460 [^]
[3] https://gitlab.com/openbravo/product/openbravo/-/blob/master/src/org/openbravo/costing/AverageCostAdjustment.java#L467 [^]
Steps To ReproduceThere are no clear steps to reproduce the issue. It is required to build some steps that generate a negative stock correction line and enters on the if clause that executes the early return.

A probable scenario is:

Negative stock allowed and negative correction preference enabled.
Having a product with following transactions:


Trx 1 +10 units cost 5EUR/unit
Trx 2 -15 units
Trx 3 +10 units cost 7EUR/unit
Trx 4 +10 units
Trx 5 -5 units.

Trx 3 should have a negative stock correction so the average generated by it is 7EUR

On that scenario execute a manual stock correction on Trx 1 so the new price is 6EUR/unit


Proposed SolutionOn customer instance adding the flush & clear just before the return statement seems to solve the issue.

In any case it should be reviewed if that is the best solution as that fix still does not cover the last check on current average.

Alternative fixes would be:
* Consider to execute a "break" statement instead so only the while loop is exited, and execute the flush&clear just before.
* Add a new exit condition to the while clause so the flush&clear at the end of the loop is executed:
  while(trxs.next() || forceExit) {
    ... do things.
    if (new cost match)
      // return --> remove return statement
      forceExit = true;
    }
  }
* Adding a flush&clear on the finally clause [1]. But this would mean an extra flush in normal conditions.


[1] https://gitlab.com/openbravo/product/openbravo/-/blob/master/src/org/openbravo/costing/AverageCostAdjustment.java#L464 [^]
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]

-  Notes
(0122507)
dmiguelez (developer)
2020-09-01 13:17
edited on: 2020-09-01 13:20

 Test Plan:

0.- Enable Negative Stock Correction Preference:
  * Log in as F&B Admin
  * Go to Preference Window and create a new record with:
    - Organization: *
    - Property: Enable Negative Stock Corrections
    - Value: Y
    - All visibility fields empty

0.- Enable Negative Stock:
  * Go to Warehouse and Storage Bins Window
    - Select US West Coast Warehouse
    - Select WC-0-0-0 Storage Bin and click on Change Status button
    - Select Undefined-OverIssue and click ok

1.- Create new Product:
  * Go to Product Window and create a new record with:
    - Organization: F&B US
    - SearchKey: Test
    - Name: Test
    - In Price Tab create a new record with:
      - Price List Version: Be Soft Drinker Price List
      - Unit Price: 10
      - List Price 10
    - In Price Tab create a new record with:
      - Price List Version: General Sales
      - Unit Price: 10
      - List Price 10

2.- Create new Purchase Order (+10 Units at 5€) + Goods Receipt:
  * Go to Purhcase Order and create a new record with:
    - Organization: F&B US
    - Business Partner: Be Soft Drinker
    - Warehouse: US West Coast
    - Move to Lines and create a new record with:
      - Product: Test
      - Ordered Quantity: 10
      - Net Unit Price: 5
      - Tax: Sales Exempt
    - Click on Complete and Ok
  * Go to Goods Receipt Window and create a new record with:
    - Organization: F&B US
    - Business Partner: Be Soft Drinker
    - Warehouse: US West Coast
    - Click on Create lines from and select the previous Purchase Order and WC-0-0-0 as the Storage Bin
    - Click on Complete and Ok

3.- Create Goods Shipment (-15 Units):
  * Go to Goods Receipt Window and create a new record with:
    - Organization: F&B US
    - Business Partner: Healthy Foods Supermarkets
    - Warehouse: US West Coast
    - Move to lines and create a new record with:
      - Product: Test
      - Movement Quantity: 15
      - Storage Bin: WC-0-0-0
    - Click on Complete and Ok

4.- Create new Purchase Order (+10 Units at 7€) + Goods Receipt:
  * Go to Purhcase Order and create a new record with:
    - Organization: F&B US
    - Business Partner: Be Soft Drinker
    - Warehouse: US West Coast
    - Move to Lines and create a new record with:
      - Product: Test
      - Ordered Quantity: 10
      - Net Unit Price: 7
      - Tax: Sales Exempt
    - Click on Complete and Ok
  * Go to Goods Receipt Window and create a new record with:
    - Organization: F&B US
    - Business Partner: Be Soft Drinker
    - Warehouse: US West Coast
    - Click on Create lines from and select the previous Purchase Order and WC-0-0-0 as the Storage Bin
    - Click on Complete and Ok

5.- Create Goods Receipt (+10 Units):
  * Go to Goods Receipt Window and create a new record with:
    - Organization: F&B US
    - Business Partner: Be Soft Drinker
    - Warehouse: US West Coast
    - Move to lines and create a new record with:
      - Product: Test
      - Movement Quantity: 10
      - Storage Bin: WC-0-0-0
    - Click on Complete and Ok

6.- Create Goods Shipment (-5 Units):
  * Go to Goods Receipt Window and create a new record with:
    - Organization: F&B US
    - Business Partner: Healthy Foods Supermarkets
    - Warehouse: US West Coast
    - Move to lines and create a new record with:
      - Product: Test
      - Movement Quantity: 5
      - Storage Bin: WC-0-0-0
    - Click on Complete and Ok

7.- Execute Manual Adjustment for a Transaction:
  * First go to Process Request Window and create a new record with:
    - Organization: *
    - Process: Costing Background Process
    - Click on Schedule Process (if there is any other process costing running at the same time, unchedule it first)
  * Go to Product window, select the previously created product and move to Transaction Tab
    - Order Transactions by Trx Process Date
    - Select the first Transaction (10 Units at 5€)
    - Click on Manual Adjustment and select Incremental + Unit Cost and set 6€
  * Schedule the costing background process again
  * Check the Transactions for the Product, it should be:
      Trx Order: 1 Movement Qty: 10 Total Cost: 56
      Trx Order: 2 Movement Qty: -15 Total Cost: 84
      Trx Order: 3 Movement Qty: 10 Total Cost: 63
      Trx Order: 4 Movement Qty: 10 Total Cost: 70
      Trx Order: 5 Movement Qty: -5 Total Cost: 35
(0122527)
hgbot (developer)
2020-09-01 16:19

 Merge Request created: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/136 [^]
(0122537)
hgbot (developer)
2020-09-02 08:45

 Merge request merged: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/136 [^]
(0122538)
hgbot (developer)
2020-09-02 08:45

 Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/openbravo [^]
Changeset: 8afed91769275f523ce8bedc16eeea1a5388d68d
Author: david.miguelez <david.miguelez@openbravo.com>
Date: 2020-09-02T06:44:57+00:00
URL: https://gitlab.com/openbravo/product/openbravo/-/commit/8afed91769275f523ce8bedc16eeea1a5388d68d [^]

FIXES ISSUE-44938. Fixes problem when persisting information in Costing
process

Before, when finding a particular condtion, a return statement was executed,
finishing the loop but also finalizing the execution for the rest of the
code of the method, which included some final validations + a flush and a clear.
Due to this fact, the changes were not persisted in the Database.

This change allows to break the execution of the loop, but keep executing the
final validations + flush and clear as it was intended.

Also, for this case, a new boolean variable named forceExit has been used
instead of the more common 'break' sentence to finish the loop.
It has been done because the code inside the loop is too big to understand
everything that is happening, so it is better to explicitly explain that
the loop can be prematurely finished, instead of doing it through a buried
return statement.

---
M src/org/openbravo/costing/AverageCostAdjustment.java
---

- Issue History
Date Modified Username Field Change
2020-08-31 14:49 gorkaion New Issue
2020-08-31 14:49 gorkaion Assigned To => Triage Finance
2020-08-31 14:49 gorkaion Modules => Core
2020-08-31 14:49 gorkaion Resolution time => 1600639200
2020-08-31 14:49 gorkaion Triggers an Emergency Pack => No
2020-09-01 13:17 dmiguelez Note Added: 0122507
2020-09-01 13:20 dmiguelez Note Edited: 0122507 View Revisions
2020-09-01 15:34 dmiguelez Assigned To Triage Finance => dmiguelez
2020-09-01 16:19 hgbot Note Added: 0122527
2020-09-02 08:45 hgbot Note Added: 0122537
2020-09-02 08:45 hgbot Resolution open => fixed
2020-09-02 08:45 hgbot Status new => closed
2020-09-02 08:45 hgbot Fixed in Version => PR20Q4
2020-09-02 08:45 hgbot Note Added: 0122538

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker