Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | ||||||||
| 0018053 | ||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
| defect | [Openbravo ERP] 06. Material requirement planning (MRP) | major | always | 2011-07-21 12:44 | 2015-05-13 13:41 | |||
| Reporter | andreaferaco | View Status | public | |||||
| Assigned To | mirurita | |||||||
| Priority | normal | Resolution | duplicate | Fixed in Version | ||||
| Status | closed | Fix in branch | pi | Fixed in SCM revision | ||||
| Projection | none | ETA | none | Target Version | ||||
| OS | Linux 64 bit | Database | PostgreSQL | Java version | 1.6.0_18 | |||
| OS Version | Professional Appliance | Database version | 8.3.9 | Ant version | 1.7.1 | |||
| Product Version | SCM revision | |||||||
| Review Assigned To | ||||||||
| Web browser | Mozilla Firefox | |||||||
| Modules | Core | |||||||
| Regression level | ||||||||
| Regression date | ||||||||
| Regression introduced in release | ||||||||
| Regression introduced by commit | ||||||||
| Triggers an Emergency Pack | No | |||||||
| Summary | 0018053: Suggested Work Requirement not generated by MRP | |||||||
| Description | When MRP is processed for a product configured with a minimum stock, the application does not suggest any work requirement to re-establish minimum stock. | |||||||
| Steps To Reproduce | 1) Create a product P flagged as "production" and linked to a process plan. 2) Set minimum stock for this product P to 25 units 3) From manufacturing plan window run the process "Process Manufacturing Plan" 4) When the process is completed just two records are inserted in the table MRP_RUN_PRODUCTIONLINE: |A|Minimum Stock|-25 |A|Stock|0 No suggested work requirement records have been created. Actually it was expected at least a third record: |A|Suggested Work Requirement|25 5) We have noticed that if the "Process Manufacturing Plan" is executed a second time without deleting existing records in MRP_RUN_PRODUCTIONLINE, the application correctly creates the records for the suggested work requirements. The application behaviour after the second execution is consistent with the expected behaviour, however this behaviour was expected immediately after the first execution. We analysed the code and realised that the stored procedure "mrp_run_initialize" inserts in MRP_RUN_PRODUCTIONLINE just the lines of stock (ST) and minimum stock (MS) having the flag "isexploded" = 'Y'. Because of this condition, the stored procedure "mrp_run_explode", invoked after "mrp_run_initialize", excludes those records, and therefore it does not generate any Suggested Work Requirement because of the Minimum Stock. When the procedure is run the second time, the stored procedure "mrp_production_run" executes this SQL statement before invoking the other procedures: UPDATE MRP_RUN_PRODUCTIONLINE SET isexploded = 'N' WHERE MRP_RUN_PRODUCTION_ID = v_Record_ID AND qty <0 AND INOUTTRXTYPE <> 'WR'; You can see that it sets to N the flag isexploded, therefore even if "mrp_run_initialize" skips the product P because already created in the table MRP_RUN_PRODUCTIONLINE, however the "mrp_run_explode" takes it into account and correctly generates the Suggested Work Requirement. We tried to modify the "mrp_run_initialize" so to take the record related to minimum stock (MS) at the first execution, but the procedure raises an exception (it tries to fill a null value in the planneddate field). | |||||||
| Tags | VMA-Reviewed | |||||||
| Attached Files | ||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
||||||||
|
||||||||
 Relationships |
|
Notes |
|
|
(0041323) gorkaion (developer) 2011-09-27 16:38 |
It is intended to consider the safety stock only in case there is some demand. On the second run it shouldn't propose any production. The update clause should be fixed to filter out stock and safety stock transaction types. |
|
(0077380) plujan (manager) 2015-05-13 13:41 |
A similar issue was reported later and it was fixed without noticing this previous report, so I am closing it as duplicated. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2011-07-21 12:44 | andreaferaco | New Issue | |
| 2011-07-21 12:44 | andreaferaco | Assigned To | => jonalegriaesarte |
| 2011-07-21 12:44 | andreaferaco | Web browser | => Mozilla Firefox |
| 2011-07-21 12:44 | andreaferaco | Modules | => Core |
| 2011-07-21 12:53 | riccardogervasi | Issue Monitored: riccardogervasi | |
| 2011-07-21 12:53 | riccardogervasi | Issue End Monitor: riccardogervasi | |
| 2011-07-21 12:54 | riccardogervasi | Issue Monitored: riccardogervasi | |
| 2011-09-27 16:38 | gorkaion | Status | new => scheduled |
| 2011-09-27 16:38 | gorkaion | Note Added: 0041323 | |
| 2011-09-27 16:38 | gorkaion | fix_in_branch | => pi |
| 2012-04-03 12:20 | jonalegriaesarte | Assigned To | jonalegriaesarte => vmromanos |
| 2012-04-10 16:13 | vmromanos | Tag Attached: VMA-Reviewed | |
| 2012-05-10 12:12 | gorka_gil | Assigned To | vmromanos => mirurita |
| 2015-05-13 13:41 | plujan | Relationship added | duplicate of 0019435 |
| 2015-05-13 13:41 | plujan | Note Added: 0077380 | |
| 2015-05-13 13:41 | plujan | Status | scheduled => closed |
| 2015-05-13 13:41 | plujan | Resolution | open => duplicate |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |