Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0029822Openbravo ERP04. Warehouse managementpublic2015-05-08 09:422015-05-11 21:53
Reporterumartirena 
Assigned Toumartirena 
PriorityurgentSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version 
Target VersionFixed in Version3.0PR15Q3 
Merge Request Status
Review Assigned Toaferraz
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0029822: [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
depends on backport 00298363.0PR15Q2.1 closed umartirena [Cost Adjustments] Unnecessary backdated adjustments are created under certain circumstances 
depends on backport 00298373.0PR15Q1.4 closed umartirena [Cost Adjustments] Unnecessary backdated adjustments are created under certain circumstances 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-05-08 09:42umartirenaNew Issue
2015-05-08 09:42umartirenaAssigned To => Triage Finance
2015-05-08 09:42umartirenaModules => Core
2015-05-08 09:42umartirenaTriggers an Emergency Pack => No
2015-05-11 10:12umartirenaStatusnew => scheduled
2015-05-11 10:12umartirenaAssigned ToTriage Finance => umartirena
2015-05-11 11:51hgbotCheckin
2015-05-11 11:51hgbotNote Added: 0077271
2015-05-11 11:51hgbotStatusscheduled => resolved
2015-05-11 11:51hgbotResolutionopen => fixed
2015-05-11 11:51hgbotFixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/a2ff7c6b51a42c07a02c139f358dcef9a47c8f71 [^]
2015-05-11 11:53aferrazReview Assigned To => aferraz
2015-05-11 11:53aferrazNote Added: 0077272
2015-05-11 11:53aferrazStatusresolved => closed
2015-05-11 11:53aferrazFixed in Version => 3.0PR15Q3
2015-05-11 21:53hudsonbotCheckin
2015-05-11 21:53hudsonbotNote Added: 0077316

Notes
(0077271)
hgbot   
2015-05-11 11:51   
Repository: erp/devel/pi
Changeset: a2ff7c6b51a42c07a02c139f358dcef9a47c8f71
Author: Unai Martirena <unai.martirena <at> openbravo.com>
Date: Fri May 08 09:51:11 2015 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/a2ff7c6b51a42c07a02c139f358dcef9a47c8f71 [^]

Fixes bug 29822: 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
---
(0077272)
aferraz   
2015-05-11 11:53   
Code review + Testing OK
(0077316)
hudsonbot   
2015-05-11 21:53   
A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/a55bc3c14e8c [^]
Maturity status: Test