[
https://issues.apache.org/jira/browse/OFBIZ-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13921525#comment-13921525
]
Christian Carlow edited comment on OFBIZ-5561 at 3/5/14 10:50 PM:
------------------------------------------------------------------
It seems the quantity produced of tasks requiring materials should first be
limited to the amount that can be produced from the materials issued, and then
be limited to the amount produced of the previous task. This seems to entail
building the bomTree to determine how much of any material is required to
produce 1 of the end-product.
For example:
Given GZ-BASKET with following BOMs:
GZ-1000 = 1
GZ-1001 = 2
Given a production run to produce 2 of GZ-BASKET with the following tasks
requiring materials and issuances:
1. no material
2. GZ-1000 with 2 issuances
3. GZ-1001 with 2 issuances
Then for the first task, the declaration quantity will have no limit since it
neither requires material nor has prior tasks. For the second task, the
declaration quantity will be limited to 2 since 2 GZ-BASKETs can be made with 2
GZ-1000. For the third task, the declaration quantity will be limited to 1
since only 1 GZ-BASKET can be produced from 2 GZ-1001. However, if 2 more
GZ-1001 are issued then the third task will then be able to produce 2. But if
only 1 GZ-1000 were issued to the second task and 4 GZ-1001 were issued to the
third task, then the second and third tasks would both be limited to 1 because
the third task should be limited by the amount produced in the second.
was (Author: ofbizzer):
It seems the quantity produced of tasks requiring materials should first be
limited to the amount that can be produced from the materials issued, and then
be limited to the amount produced of the previous task. This seems to entail
building the bomTree to determine how much of any material is required to
produce 1 of the end-product.
For example:
Given GZ-BASKET with following BOMs:
GZ-1000 = 1
GZ-1001 = 2
Given a production run to produce 2 of GZ-BASKET with the following tasks
requiring materials and issuances:
1. no material
2. GZ-1000 with 2 issuances
3. GZ-1001 with 2 issuances
Then for the first task, the declaration quantity will have no limit since it
neither requires material nor prior tasks. For the second task, the
declaration quantity will be limited to 2 since 2 GZ-BASKETs can be made with 2
GZ-1000. For the third task, the declaration quantity will be limited to 1
since only 1 GZ-BASKET can be produced from 2 GZ-1001. However, if 2 more
GZ-1001 are issued then the third task will then be able to produce 2. But if
only 1 GZ-1000 were issued to the second task and 4 GZ-1001 were issued to the
third task, then the second and third tasks would both be limited to 1 because
the third task should be limited by the amount produced in the second.
In other words, if the BOMs of GZ-BASKET is 1 GZ-1000 and 2 GZ-1001 and only 2
of each were issued, then the maximum amount that can be produced for the task
is 1 since to produce 2, 2 more GZ-1001 would have to be issued. Tasks that
occur before those requiring materials wont have their quantity
produced/rejected limited at all.
> Production Run task quantity produced can be greater than the prior task
> ------------------------------------------------------------------------
>
> Key: OFBIZ-5561
> URL: https://issues.apache.org/jira/browse/OFBIZ-5561
> Project: OFBiz
> Issue Type: Bug
> Components: manufacturing
> Affects Versions: SVN trunk
> Reporter: Christian Carlow
>
> When completing a production run task, the quantity produced is not limited
> to the quantity produced of the prior task. This issue was mentioned in
> OFBIZ-5526 which is a related issue.
> I created a production run to create 100 pizzas and declared 1 reject for the
> first task and then completed producing 99. Then I started and completed the
> next task and the quantity produced was set to 100. This seems incorrect and
> the quantity produced for the next task should be limited to 99 based on the
> previous task. So if I declared 1 reject also for the second task then the
> third would be limited to 98.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
