Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0029836Openbravo ERP04. Warehouse managementpublic2015-05-08 09:422015-05-11 13:28
Reporterumartirena 
Assigned Toumartirena 
PriorityurgentSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version 
Target Version3.0PR15Q2.1Fixed in Version3.0PR15Q2.1 
Merge Request Status
Review Assigned Toaferraz
OBNetwork customerNo
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0029836: [Cost Adjustments] Unnecessary backdated adjustments are created under certain circumstances
Description[Cost Adjustments] Unnecessary backdated adjustments are created under certain circumstances
Steps To ReproduceIn live builds as System Admin:

 * Go to Currency window:
 * Search EUR currency and set Costing Precision to 4.

In live builds as QA Testing Admin:

 * It is necessary to have a validated costing rule:
   - Starting Date: Before than today
   - Costing Algorithm: Average Algorithm
   - Fix Backdated: Yes
   - Warehouse dimension: Yes

 * Create a product for Spain org

 * Assign Net Price and List Price of 12.45

 * Add a manual Costing record
   - Starting Date: Today
   - Ending Date: 31-12-9999
   - Cost Type: Average
   - Cost: 12.45
   - Warehouse: Spain Warehouse
   - Currency: EUR

 * Create a Goods movement header with movement date tomorrow.
 
 * Add a line for the created product of 15.25 from a Storage Bin of Spain Warehouse to a storage bin of a different warehouse. If there is no different warehouse, create it

 * Process the Goods Movement.

 * Go to Goods receipt window and create a header with movement date of today(backdated)

 * Add a line of 15.25

 * Process the Goods Receipt.

 * Run Costing Background process.

 * Go to Cost Adjustments window and check that 2 new Cost Adjustments have been created:

    - "Negative Stock Correction" with one line. That is correct.
    - "Backdated Transaction" with 3 lines.
       * The first one pointing to V+ -> This is correct
       * The second one pointing to M- -> This is NOT correct
       * The second one pointing to M+-> This is NOT correct

 * The last two adjustment lines are not necessary, they were being created due to precision rounding issues.
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
blocks defect 0029822 closed umartirena [Cost Adjustments] Unnecessary backdated adjustments are created under certain circumstances 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-05-11 10:12umartirenaTypedefect => backport
2015-05-11 10:12umartirenaTarget Version => 3.0PR15Q2.1
2015-05-11 11:54aferrazAssigned ToTriage Finance => umartirena
2015-05-11 13:27hgbotCheckin
2015-05-11 13:27hgbotNote Added: 0077281
2015-05-11 13:27hgbotStatusscheduled => resolved
2015-05-11 13:27hgbotResolutionopen => fixed
2015-05-11 13:27hgbotFixed in SCM revision => http://code.openbravo.com/erp/backports/3.0PR15Q2.1/rev/a76de5445a7f626cf9abd7fdb7ddcb49091c11f7 [^]
2015-05-11 13:28aferrazReview Assigned To => aferraz
2015-05-11 13:28aferrazNote Added: 0077282
2015-05-11 13:28aferrazStatusresolved => closed
2015-05-11 13:28aferrazFixed in Version => 3.0PR15Q2.1

Notes
(0077281)
hgbot   
2015-05-11 13:27   
Repository: erp/backports/3.0PR15Q2.1
Changeset: a76de5445a7f626cf9abd7fdb7ddcb49091c11f7
Author: Unai Martirena <unai.martirena <at> openbravo.com>
Date: Mon May 11 10:15:38 2015 +0200
URL: http://code.openbravo.com/erp/backports/3.0PR15Q2.1/rev/a76de5445a7f626cf9abd7fdb7ddcb49091c11f7 [^]

Fixes bug 29836: Avoid creating unnecessary backdated adjustments.

The problem was happening when costing precision was different from standard precision. When calculating the expected cost of a transaction to know if an adjustment is necessary to be created, it has to be rounded to standard precision because the amounts always have to be created in standard precision. In this case, while comparing expected cost with actual cost from database, as in database values are rounded to standard precision, and expected cost was being rounded to cost precission, an adjustment was being created with the difference, that corresponds just to the precision lost, and finally an adjustment of Zero amount was being created.

---
M src/org/openbravo/costing/AverageCostAdjustment.java
---
(0077282)
aferraz   
2015-05-11 13:28   
Code review + Testing OK