Production Run "Return Unused Materials To Warehouse" allows all materials to be returned even if quantity produced has been declared

[Christian Carlow-OFBizzer]

Shouldn't the "Return Unused Materials To Warehouse" form limit the
amount of materials that can be returned based on the amount that has
been produced by the first production run task?  In other words, for a
production run to produce 10 pizzas requiring 10 PEPPERS-G as materials
for example, if the first task produces 2 and rejects 2 then shouldn't
the maximum quantity that can be returned be 6 since 4 can be considered
to have been processed into WIP-variants?

If so this problem is complicated by BOM materials required at different
proportions which can't be determined if materials are added on the
"Actual Materials" tab.  Meaning that if 1 PIZZA requires 1 PEPPERS-G
and 2 PEPPERS-H, then without the information being specified as BOMs,
the proportion 2-1 for PEPPERS-H cannot be determined and therefore
cannot have the material return limit rule applied correctly.  This
could be resolved by changing the "Materials" tab that appears before
Production Runs are confirmed so that it accepts a proportional quantity
rather than the actual quantity of the materials needed.  In other words
it would work just like the BOM quantity field.  So for a production run
to produce 10 PIZZA, rather than manually adding 10 PEPPERS-G and 20
PEPPERS-H, instead a BOM quantity of 1 would be specified for PEPPERS-G
and 2 for PEPPERS-H.  Then the production run would look at the quantity
to produce times the BOM quantities to determine how much of single
material is needed to produce a single good.  So 10 PIZZAs are supposed
to be produced so 1*10 = 10 PEPPERS-G and 2*10 = 20 PEPPERS-H.

[Jacopo Cappellato-4]

On Mar 7, 2014, at 5:03 PM, Christian Carlow <[hidden email]> wrote:

> Shouldn't the "Return Unused Materials To Warehouse" form limit the amount of materials that can be returned based on the amount that has been produced by the first production run task?  In other words, for a production run to produce 10 pizzas requiring 10 PEPPERS-G as materials for example, if the first task produces 2 and rejects 2 then shouldn't the maximum quantity that can be returned be 6 since 4 can be considered to have been processed into WIP-variants?

If I am not wrong that screenlet is intended to allow the "return" of potentially any product ids and quantity, not only the ones being issued as materials; I understand this may seem wrong but the idea is that it should be used to generate and store in warehouse products that represent side-effects of the main manufacturing process.
For example, if you are preparing a pizza, and you realize you have issued too much dough, you may create a small tortilla instead of throwing away the unused material.

Jacopo

[Christian Carlow-OFBizzer]

Thanks Jacopo

I think you might have thought that I was referring to the declaration
form which allows for the productId to be specified. If so, then I was
actually referring to the section below it labeled "Return Unused
Materials To Warehouse" below it.

For the pizza scenario, say 1 pizza requires as BOM, 1 big and 1 little
dough with the big containing 2 little.  Then for a production run to
produce 1 pizza, if two big doughs were stocked out as materials,
meaning 1 little dough will be left over, thenit seems  maximum quantity
produced would be 1.  So there would be no conflict returning the 1
little because it would satisfy the material return limit I proposed.  
It seems as though the return app should know that the maximum amount
that should be returned is 0.5.

I can't think of a scenario where the following would apply:

materialReturnQuantity > materialIssueQuantity - (task1QuantityProduced
+ task1QuantityRejected)

Fractions seem to be the only quantities that should be able to be
returned when the following is satisfied:

materialIssueQuantity - (task1QuantityProduced + task1QuantityRejected)
== materialReturnQuantity

On 03/07/2014 11:23 AM, Jacopo Cappellato wrote:
> On Mar 7, 2014, at 5:03 PM, Christian Carlow <[hidden email]> wrote:
>
>> Shouldn't the "Return Unused Materials To Warehouse" form limit the amount of materials that can be returned based on the amount that has been produced by the first production run task?  In other words, for a production run to produce 10 pizzas requiring 10 PEPPERS-G as materials for example, if the first task produces 2 and rejects 2 then shouldn't the maximum quantity that can be returned be 6 since 4 can be considered to have been processed into WIP-variants?
> If I am not wrong that screenlet is intended to allow the "return" of potentially any product ids and quantity, not only the ones being issued as materials; I understand this may seem wrong but the idea is that it should be used to generate and store in warehouse products that represent side-effects of the main manufacturing process.
> For example, if you are preparing a pizza, and you realize you have issued too much dough, you may create a small tortilla instead of throwing away the unused material.
>
> Jacopo

[Christian Carlow-OFBizzer]

Sorry, the bottom scenarios should be described like this instead:

materialReturnQuantity > (sum(WorkEffortInventoryAssign.quantity) of all
tasks for productId) - (sum(WorkEffortInventoryProduced.quantity) for
last task with inventory productId matching material productId)

In other words, WorkEffortInventoryAssign and
WorkEffortInventoryProduced would be used instead of the WorkEffort
entity to determine how much can be returned.  Granted the quantity
field is added to the WorkEffortInventoryProduced table as suggested in
an earlier post.

On 03/07/2014 12:17 PM, Christian Carlow wrote:

> Thanks Jacopo
>
> I think you might have thought that I was referring to the declaration
> form which allows for the productId to be specified. If so, then I was
> actually referring to the section below it labeled "Return Unused
> Materials To Warehouse" below it.
>
> For the pizza scenario, say 1 pizza requires as BOM, 1 big and 1
> little dough with the big containing 2 little.  Then for a production
> run to produce 1 pizza, if two big doughs were stocked out as
> materials, meaning 1 little dough will be left over, thenit seems  
> maximum quantity produced would be 1.  So there would be no conflict
> returning the 1 little because it would satisfy the material return
> limit I proposed.  It seems as though the return app should know that
> the maximum amount that should be returned is 0.5.
>
> I can't think of a scenario where the following would apply:
>
> materialReturnQuantity > materialIssueQuantity -
> (task1QuantityProduced + task1QuantityRejected)
>
> Fractions seem to be the only quantities that should be able to be
> returned when the following is satisfied:
>
> materialIssueQuantity - (task1QuantityProduced +
> task1QuantityRejected) == materialReturnQuantity
>
> On 03/07/2014 11:23 AM, Jacopo Cappellato wrote:
>> On Mar 7, 2014, at 5:03 PM, Christian Carlow
>> <[hidden email]> wrote:
>>
>>> Shouldn't the "Return Unused Materials To Warehouse" form limit the
>>> amount of materials that can be returned based on the amount that
>>> has been produced by the first production run task?  In other words,
>>> for a production run to produce 10 pizzas requiring 10 PEPPERS-G as
>>> materials for example, if the first task produces 2 and rejects 2
>>> then shouldn't the maximum quantity that can be returned be 6 since
>>> 4 can be considered to have been processed into WIP-variants?
>> If I am not wrong that screenlet is intended to allow the "return" of
>> potentially any product ids and quantity, not only the ones being
>> issued as materials; I understand this may seem wrong but the idea is
>> that it should be used to generate and store in warehouse products
>> that represent side-effects of the main manufacturing process.
>> For example, if you are preparing a pizza, and you realize you have
>> issued too much dough, you may create a small tortilla instead of
>> throwing away the unused material.
>>
>> Jacopo
>

[Christian Carlow-OFBizzer]

Sorry again (please bare with me its been a long day),

The scenario described in the first post was correct.  I was getting
confused in my last post which can be disregarded.

On 03/07/2014 01:24 PM, Christian Carlow wrote:

> Sorry, the bottom scenarios should be described like this instead:
>
> materialReturnQuantity > (sum(WorkEffortInventoryAssign.quantity) of
> all tasks for productId) - (sum(WorkEffortInventoryProduced.quantity)
> for last task with inventory productId matching material productId)
>
> In other words, WorkEffortInventoryAssign and
> WorkEffortInventoryProduced would be used instead of the WorkEffort
> entity to determine how much can be returned.  Granted the quantity
> field is added to the WorkEffortInventoryProduced table as suggested
> in an earlier post.
>
> On 03/07/2014 12:17 PM, Christian Carlow wrote:
>> Thanks Jacopo
>>
>> I think you might have thought that I was referring to the
>> declaration form which allows for the productId to be specified. If
>> so, then I was actually referring to the section below it labeled
>> "Return Unused Materials To Warehouse" below it.
>>
>> For the pizza scenario, say 1 pizza requires as BOM, 1 big and 1
>> little dough with the big containing 2 little.  Then for a production
>> run to produce 1 pizza, if two big doughs were stocked out as
>> materials, meaning 1 little dough will be left over, thenit seems  
>> maximum quantity produced would be 1.  So there would be no conflict
>> returning the 1 little because it would satisfy the material return
>> limit I proposed.  It seems as though the return app should know that
>> the maximum amount that should be returned is 0.5.
>>
>> I can't think of a scenario where the following would apply:
>>
>> materialReturnQuantity > materialIssueQuantity -
>> (task1QuantityProduced + task1QuantityRejected)
>>
>> Fractions seem to be the only quantities that should be able to be
>> returned when the following is satisfied:
>>
>> materialIssueQuantity - (task1QuantityProduced +
>> task1QuantityRejected) == materialReturnQuantity
>>
>> On 03/07/2014 11:23 AM, Jacopo Cappellato wrote:
>>> On Mar 7, 2014, at 5:03 PM, Christian Carlow
>>> <[hidden email]> wrote:
>>>
>>>> Shouldn't the "Return Unused Materials To Warehouse" form limit the
>>>> amount of materials that can be returned based on the amount that
>>>> has been produced by the first production run task?  In other
>>>> words, for a production run to produce 10 pizzas requiring 10
>>>> PEPPERS-G as materials for example, if the first task produces 2
>>>> and rejects 2 then shouldn't the maximum quantity that can be
>>>> returned be 6 since 4 can be considered to have been processed into
>>>> WIP-variants?
>>> If I am not wrong that screenlet is intended to allow the "return"
>>> of potentially any product ids and quantity, not only the ones being
>>> issued as materials; I understand this may seem wrong but the idea
>>> is that it should be used to generate and store in warehouse
>>> products that represent side-effects of the main manufacturing process.
>>> For example, if you are preparing a pizza, and you realize you have
>>> issued too much dough, you may create a small tortilla instead of
>>> throwing away the unused material.
>>>
>>> Jacopo
>>
>

[Christian Carlow-OFBizzer]

To be more specific, shouldn't this line in ProductionRunServices.java:
productionRunTaskReturnMaterial() be changed from:

if (quantity.compareTo(totalIssued.subtract(totalReturned) > 0) {

to:

if
(quantity.compareTo(totalIssued.subtract(totalReturned).subtract(quantityProduced.add(quantityRejected)))
 > 0) {

So that the ManufacturingProductionRunTaskCannotReturnMoreItems error is
thrown when trying to return materials that have been allocated as the
task quantity produced and rejected?

On 03/07/2014 02:16 PM, Christian Carlow wrote:

> Sorry again (please bare with me its been a long day),
>
> The scenario described in the first post was correct.  I was getting
> confused in my last post which can be disregarded.
>
> On 03/07/2014 01:24 PM, Christian Carlow wrote:
>> Sorry, the bottom scenarios should be described like this instead:
>>
>> materialReturnQuantity > (sum(WorkEffortInventoryAssign.quantity) of
>> all tasks for productId) - (sum(WorkEffortInventoryProduced.quantity)
>> for last task with inventory productId matching material productId)
>>
>> In other words, WorkEffortInventoryAssign and
>> WorkEffortInventoryProduced would be used instead of the WorkEffort
>> entity to determine how much can be returned. Granted the quantity
>> field is added to the WorkEffortInventoryProduced table as suggested
>> in an earlier post.
>>
>> On 03/07/2014 12:17 PM, Christian Carlow wrote:
>>> Thanks Jacopo
>>>
>>> I think you might have thought that I was referring to the
>>> declaration form which allows for the productId to be specified. If
>>> so, then I was actually referring to the section below it labeled
>>> "Return Unused Materials To Warehouse" below it.
>>>
>>> For the pizza scenario, say 1 pizza requires as BOM, 1 big and 1
>>> little dough with the big containing 2 little.  Then for a
>>> production run to produce 1 pizza, if two big doughs were stocked
>>> out as materials, meaning 1 little dough will be left over, thenit
>>> seems  maximum quantity produced would be 1.  So there would be no
>>> conflict returning the 1 little because it would satisfy the
>>> material return limit I proposed.  It seems as though the return app
>>> should know that the maximum amount that should be returned is 0.5.
>>>
>>> I can't think of a scenario where the following would apply:
>>>
>>> materialReturnQuantity > materialIssueQuantity -
>>> (task1QuantityProduced + task1QuantityRejected)
>>>
>>> Fractions seem to be the only quantities that should be able to be
>>> returned when the following is satisfied:
>>>
>>> materialIssueQuantity - (task1QuantityProduced +
>>> task1QuantityRejected) == materialReturnQuantity
>>>
>>> On 03/07/2014 11:23 AM, Jacopo Cappellato wrote:
>>>> On Mar 7, 2014, at 5:03 PM, Christian Carlow
>>>> <[hidden email]> wrote:
>>>>
>>>>> Shouldn't the "Return Unused Materials To Warehouse" form limit
>>>>> the amount of materials that can be returned based on the amount
>>>>> that has been produced by the first production run task?  In other
>>>>> words, for a production run to produce 10 pizzas requiring 10
>>>>> PEPPERS-G as materials for example, if the first task produces 2
>>>>> and rejects 2 then shouldn't the maximum quantity that can be
>>>>> returned be 6 since 4 can be considered to have been processed
>>>>> into WIP-variants?
>>>> If I am not wrong that screenlet is intended to allow the "return"
>>>> of potentially any product ids and quantity, not only the ones
>>>> being issued as materials; I understand this may seem wrong but the
>>>> idea is that it should be used to generate and store in warehouse
>>>> products that represent side-effects of the main manufacturing
>>>> process.
>>>> For example, if you are preparing a pizza, and you realize you have
>>>> issued too much dough, you may create a small tortilla instead of
>>>> throwing away the unused material.
>>>>
>>>> Jacopo
>>>
>>
>

[Pierre Smits]

Christian,

While the scenario presented by Jacopo is a surely a potentially unexpected
nice-to-have feature in the feature set of OFBiz, you should ask yourself
if that is something that you want in your manufacturing processes.

Manufacturing processes are sets of controlled actions with predictable
outcomes. When you are about to manufacture 100 units of your end product
you would not want more than the required quantities of your components
based on your BoMs. Anything issued more than required will cause extra
actions like returning the surplus back to inventory, creating an extra end
product (the tortilla as Jacopo outlined) that has not been ordered and
might get stale in inventory, or even scrapping it due to quality
degradation issues of the component.
Anything issued less than required will delay the production run with
potentially endangering the quality of the end product.

Another aspect that you need to take into consideration is the cost of
manufacturing involved. Your production run will lead to a cost of
manufacturing that is based on (and in line with) the calculations made up
front. When registering an extra (different) end product (again the
tortilla) what would the effect be on the cost of manufacturing of both the
intended end product and the extra?

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Pierre Smits]

Christian,

If you feel that it has been a long day, maybe you should take a brake from
this to get your thoughts sorted out.

Take care of yourself. OFBiz and this community will surely be there after
you have taken a pause.

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Christian Carlow-OFBizzer]

Thanks Pierre,

My issue is that the material return form allows quantity to be returned
that has been declared/rejected a task.  Meaning the task did something
to it that constitutes a WIP rather than the original material that was
issued.  I think the quantityProduced and quantityRejected should be
accounted for in the material return function as described in my
previous post.

I assume that the tortilla produced in Jacopo's scenario would be
returned using the inventory producing declaration form rather than the
material return form which this post is about.  But now I think the
correct way to handle the the tortilla scenario would be to return the
dough material with a lotId and manually create a separate production
run to produce a tortilla which would stock out the inventory lot from
the previous production run.  I created a patch which prevents more
inventory quantity from being created in the right declaration form than
quantityProduced + quantityRejected of the task (left declaration
form).  Meaning if I declare 1 quantityProduced and 1 quantityRejected
for a task then the maximum amount of inventory quantity that can be
produced is 2.  Currently there is no limit to the amount of by-products
that can result.  This seems incorrect.  I think the amount of
by-products should be limited to the quantityProduced + quantityRejected
declared for the task.

On 03/07/2014 03:37 PM, Pierre Smits wrote:

> Christian,
>
> While the scenario presented by Jacopo is a surely a potentially unexpected
> nice-to-have feature in the feature set of OFBiz, you should ask yourself
> if that is something that you want in your manufacturing processes.
>
> Manufacturing processes are sets of controlled actions with predictable
> outcomes. When you are about to manufacture 100 units of your end product
> you would not want more than the required quantities of your components
> based on your BoMs. Anything issued more than required will cause extra
> actions like returning the surplus back to inventory, creating an extra end
> product (the tortilla as Jacopo outlined) that has not been ordered and
> might get stale in inventory, or even scrapping it due to quality
> degradation issues of the component.
> Anything issued less than required will delay the production run with
> potentially endangering the quality of the end product.
>
> Another aspect that you need to take into consideration is the cost of
> manufacturing involved. Your production run will lead to a cost of
> manufacturing that is based on (and in line with) the calculations made up
> front. When registering an extra (different) end product (again the
> tortilla) what would the effect be on the cost of manufacturing of both the
> intended end product and the extra?
>
> Regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>

[Pierre Smits]

Christian,

Being able to define an unlimited number of by-products (and setting the
associated quantities) is not incorrect. By-products are not the (surplus
quantities of the) components issued, nor are they other end products.

If pizza is the intended end result of a production run, then that is the
end product. If you have issued more dough than needed, than the surplus is
returned to inventory (for convenience sake  other aspects like quality de
If a bolt with 2 washers and a wingnut is your intended end result of a
production run, then that is the end product that goes into inventory. And
it is limited. If you have issued more washers than needed in the
production run, then the surplus is returned to inventory (as a correction
on the issuance).

In the pizza analogy, the surplus dough (let us say 100 grams) can be
regarded either as a returnable good (correction on issuance 100 grams) or
as a by-product (e.g. waste as a result of quality degradation) that can
potentially lead to cost recovery. In the latter case, the by-product
cannot be the component issued but must be different product.

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Christian Carlow-OFBizzer]

Thanks for the clarification Pierre,

I agree that the inventory declaration form logic should prevent
materials from being created as "by-product" inventory items.  The
question is how to properly define "by-product".  In Jacopo's pizza
scenario, the tortilla technically represents a finished good (though
different than the PRun good).  But I think you are saying that the form
should only be used for stocking-in degradated by-products such as
processed-dough.  If so I agree with you.  Otherwise it seems as though
the declaration form would need to incorporate logic to check that there
is enough left over dough to actually make the tortilla.  But that still
seems incorrect since the production run tasks to produce the tortilla
aren't being captured.  Therefore it seems more correct to
return/stock-in the dough as materials with a lotId and then
issue/stock-out that lotId for a separate production run to create the
tortilla.

Also, the inventory declaration form allows the production run finished
good to be produced which seems to violate the same rule as the
materials mentioned above.  I think the "Production Run Declaration And
Produce" forms above should be used instead for stocking-in finished
goods.  I think the service that handles that form always sets the last
task as the one that produced the PRun finished good.  Based on that
logic, can we agree that the last task should be the only one capable of
producing the finished good and therefore prevent the PRun finished good
from being declared using the inventory by-product declaration form?


On 03/07/2014 06:34 PM, Pierre Smits wrote:

> Christian,
>
> Being able to define an unlimited number of by-products (and setting the
> associated quantities) is not incorrect. By-products are not the (surplus
> quantities of the) components issued, nor are they other end products.
>
> If pizza is the intended end result of a production run, then that is the
> end product. If you have issued more dough than needed, than the surplus is
> returned to inventory (for convenience sake  other aspects like quality de
> If a bolt with 2 washers and a wingnut is your intended end result of a
> production run, then that is the end product that goes into inventory. And
> it is limited. If you have issued more washers than needed in the
> production run, then the surplus is returned to inventory (as a correction
> on the issuance).
>
> In the pizza analogy, the surplus dough (let us say 100 grams) can be
> regarded either as a returnable good (correction on issuance 100 grams) or
> as a by-product (e.g. waste as a result of quality degradation) that can
> potentially lead to cost recovery. In the latter case, the by-product
> cannot be the component issued but must be different product.
>
> Regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>

[Jacopo Cappellato-4]

On Mar 8, 2014, at 2:38 AM, Christian Carlow <[hidden email]> wrote:

> In Jacopo's pizza scenario, the tortilla technically represents a finished good (though different than the PRun good).  But I think you are saying that the form should only be used for stocking-in degradated by-products such as processed-dough.

I think we are all on the same line now: in my example, the tortilla by-product could be returned as a special productId as "defective tortilla - do not sell to customers".

Jacopo

[Christian Carlow-OFBizzer]

Thanks Jacopo,

Since we've established the inventory declaration form should only be
used for stocking in defective products, is there a way to prevent
non-defective products from being declared with the form? Is there an
easy way to determine if a product represents a defective one?  If not,
then would using the ProductAssoc entity to relate the defect
(defective-tortilla) to the intended good (good-tortilla) with an
assoTypeId="PRODUCT_DEFECTIVE" be sufficient for modeling the data to
used for applying product declaration limitation rules to the by-product
declaration form?

On 03/08/2014 12:22 AM, Jacopo Cappellato wrote:
> On Mar 8, 2014, at 2:38 AM, Christian Carlow <[hidden email]> wrote:
>
>> In Jacopo's pizza scenario, the tortilla technically represents a finished good (though different than the PRun good).  But I think you are saying that the form should only be used for stocking-in degradated by-products such as processed-dough.
> I think we are all on the same line now: in my example, the tortilla by-product could be returned as a special productId as "defective tortilla - do not sell to customers".
>
> Jacopo

[Christian Carlow-OFBizzer]

Building on the idea I suggested, the ProductAssoc entity could then be
used to prevent anything other than defective products associated with
either the raw material or finished good from being declared.  Can we
agree that logic should be implemented in the service as well?

On 03/08/2014 10:29 AM, Christian Carlow wrote:

> Thanks Jacopo,
>
> Since we've established the inventory declaration form should only be
> used for stocking in defective products, is there a way to prevent
> non-defective products from being declared with the form? Is there an
> easy way to determine if a product represents a defective one?  If
> not, then would using the ProductAssoc entity to relate the defect
> (defective-tortilla) to the intended good (good-tortilla) with an
> assoTypeId="PRODUCT_DEFECTIVE" be sufficient for modeling the data to
> used for applying product declaration limitation rules to the
> by-product declaration form?
>
> On 03/08/2014 12:22 AM, Jacopo Cappellato wrote:
>> On Mar 8, 2014, at 2:38 AM, Christian Carlow
>> <[hidden email]> wrote:
>>
>>> In Jacopo's pizza scenario, the tortilla technically represents a
>>> finished good (though different than the PRun good).  But I think
>>> you are saying that the form should only be used for stocking-in
>>> degradated by-products such as processed-dough.
>> I think we are all on the same line now: in my example, the tortilla
>> by-product could be returned as a special productId as "defective
>> tortilla - do not sell to customers".
>>
>> Jacopo
>

[Pierre Smits]

Christian,

As you have summed it up, it appears that the inventory declaration form
should only be used in only one scenario. A scenario that suits your
business process regarding manufacturing best. But this is only one
scenario. The solution in OFBiz should facilitate more than the scenario
that you described.

Other manufacturing scenarios may dictate that the by-product of a recipe
is not a defective product, but something that generates money as well.
E.g. in the brewing process one of the by-products in one of the process
steps is a product called yeast residue. This product can be used as cattle
feed, fertilizer or even as a component of another end product.
In another manufacturing scenario the by-product could be a waste product
that needs to be registered (and/or processed) due to environmental
regulations.

As you may understand more applications can and may apply. The feature set
of OFbiz Manufacturing delivers just that.

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Jacopo Cappellato-4]

Exactly. This is what I was trying to describe with my (not so good) example of "defective tortilla".

Jacopo

On Mar 8, 2014, at 7:38 PM, Pierre Smits <[hidden email]> wrote:

> Christian,
>
> As you have summed it up, it appears that the inventory declaration form
> should only be used in only one scenario. A scenario that suits your
> business process regarding manufacturing best. But this is only one
> scenario. The solution in OFBiz should facilitate more than the scenario
> that you described.
>
> Other manufacturing scenarios may dictate that the by-product of a recipe
> is not a defective product, but something that generates money as well.
> E.g. in the brewing process one of the by-products in one of the process
> steps is a product called yeast residue. This product can be used as cattle
> feed, fertilizer or even as a component of another end product.
> In another manufacturing scenario the by-product could be a waste product
> that needs to be registered (and/or processed) due to environmental
> regulations.
>
> As you may understand more applications can and may apply. The feature set
> of OFbiz Manufacturing delivers just that.
>
> Regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com