Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014161Openbravo ERP04. Warehouse managementpublic2010-08-12 09:412010-09-13 12:38
ReporterRenateNieuwkoop 
Assigned Tosivaraman 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version2.50MP20 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0014161: Pareto report: ABC codes do not get assigned correctly
DescriptionWhen running the Pareto report the outcome show certain ABC codes. However, when assigning the ABC codes in the org specific tab of the product another code appears. See snapshots

Steps To ReproduceTake the latest version of the live build (I took postgres one)
As Openbravo Admin go to Warehouse Management || Analysis Tools || Pareto Product Report || Pareto Product Report
Click 'search' Check that in the report it appears the product "Boot" as "A"
Click 'update ABC'
Go to Master Data Management || Product || Product >> Org Specific for the product "Boot" and check that the abc field has incorrectly the value "C". It should be A as it appears in the Pareto report.

We had issue 8189 pending for quite a while, but the opposite was happening then: the report showed incorrect information, while the product was updated correctly.
In this case the report is showing correct information, but the product is updated incorrectly.
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
related to defect 00081892.50MP7 closed gorkaion 250 VM: Pareto Report: Update ABC is executed incorrectly 
related to defect 0010612 closed adrianromero Work Requirement: Rounding issue for Quantity field for WR created by MRP 
Attached Filespng 120810Pareto1.png (59,338) 2010-08-12 09:41
https://issues.openbravo.com/file_download.php?file_id=2842&type=bug
png
Issue History
Date ModifiedUsernameFieldChange
2010-08-12 09:41RenateNieuwkoopNew Issue
2010-08-12 09:41RenateNieuwkoopAssigned To => adrianromero
2010-08-12 09:41RenateNieuwkoopFile Added: 120810Pareto1.png
2010-08-12 13:40adrianromeroStatusnew => scheduled
2010-08-12 13:40adrianromerofix_in_branch => pi
2010-08-16 11:25adrianromerofix_in_branchpi =>
2010-08-16 11:25adrianromeroSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=684#r684
2010-08-16 12:00adrianromeroRelationship addedrelated to 0008189
2010-08-19 07:47sivaramanAssigned Toadrianromero => sivaraman
2010-08-19 08:05hgbotCheckin
2010-08-19 08:05hgbotNote Added: 0030135
2010-08-19 08:05hgbotStatusscheduled => resolved
2010-08-19 08:05hgbotResolutionopen => fixed
2010-08-19 08:05hgbotFixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/8f81c01795f0ec7894975e6a1dc11843de20f23d [^]
2010-08-19 08:15sivaramanNote Added: 0030136
2010-08-21 00:06hudsonbotCheckin
2010-08-21 00:06hudsonbotNote Added: 0030198
2010-08-23 10:55sureshbabuNote Added: 0030219
2010-08-23 10:55sureshbabuStatusresolved => closed
2010-08-23 11:53adrianromeroRelationship addedrelated to 0010612
2010-08-24 09:22RenateNieuwkoopNote Added: 0030242
2010-08-27 11:12sivaramanNote Added: 0030403
2010-09-13 12:38anonymoussf_bug_id0 => 3065166

Notes
(0030135)
hgbot   
2010-08-19 08:05   
Repository: erp/devel/pi
Changeset: 8f81c01795f0ec7894975e6a1dc11843de20f23d
Author: Sivaraman Rajagopal <sivaraman.rajagopal <at> openbravo.com>
Date: Thu Aug 19 11:35:08 2010 +0530
URL: http://code.openbravo.com/erp/devel/pi/rev/8f81c01795f0ec7894975e6a1dc11843de20f23d [^]

Fixes issue 14161: Pareto report: ABC codes do not get assigned correctly

Root cause and solution:
The inaccuracy of floating point precision causes the issue as it computes one value in report and different value in update category. In order to fix it, the precision has been truncated to 6 digit. Hence, it is working fine as expected.

Impacts:
There is no impacts due to the change.

---
M src-db/database/model/functions/M_GET_PARETO_ABC.xml
---
(0030136)
sivaraman   
2010-08-19 08:15   
Steps to test:

Kindly follow the steps as given in 'Steps To Reproduce' section.
(0030198)
hudsonbot   
2010-08-21 00:06   
A changeset related to this issue has been promoted to main after passing a series of tests and an OBX has been generated:

Changeset: http://code.openbravo.com/erp/devel/main/rev/8f81c01795f0 [^]
Merge Changeset: http://code.openbravo.com/erp/devel/main/rev/eedf97667060 [^]
Tests: http://builds.openbravo.com/view/int/ [^]
OBX: http://builds.openbravo.com/erp/core/obx/OpenbravoERP-2.50CI.18194.obx [^]
(0030219)
sureshbabu   
2010-08-23 10:55   
verified now system shows right value
(0030242)
RenateNieuwkoop   
2010-08-24 09:22   
Hi Sivaraman,

We spoke about the two different logics that were used: one to calculate the code for the report and one for the assigning of the code. Now it seems that the calculation of the assigning is being used, but can you specify the logic? It used to be that the boots product received the A code, now it gets a C, as tested in the live build today. We have an exercise in our Basic Functional Training that uses these data, so I'd like to understand why it's now a C. Also, why aren't there any B codes assigned, I just see A and C code.
This is the logic as I understand it:
The average cost is being calculated by running the 'Generate Average Cost' process. Then for the Pareto report, that average cost gets multiplied by the quantity in stock for the products that have cost type 'average cost'. Then products that represent 80% of the total get a code A, 15% of the total get a B, the remaining 5% get C.

Please advise
Renate
(0030403)
sivaraman   
2010-08-27 11:12   
Hi Renate,

However two different logics were used, both results almost same value. The problem here is they are inaccurate in precisions. For example, The logic in report would result 8.7679684757493791(percentage) while the logic in update results 8.76796847574937898400(percentage). This small difference in percentage causes their category significantly as the first one takes A and the second one takes C. In the fix, I truncated the precision value to 6 digit before calculating the category. Thus, the same category is updated as its displayed in the report.

Pertaining to Category assigning logic, we would require Gorka Ion's comment.

Regards,
Siva