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

[Christian Carlow]

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.

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

[Jacopo Cappellato]

On Mar 7, 2014, at 5:03 PM, Christian Carlow  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

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

[Christian Carlow]

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  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

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

[Christian Carlow]

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 
 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

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

[Christian Carlow]

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 
 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

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

[Christian Carlow]

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 
 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

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

[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 *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

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

[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 *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

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

[Christian Carlow]

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 *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

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

[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 *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

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

[Christian Carlow]

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 *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

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

[Jacopo Cappellato]

On Mar 8, 2014, at 2:38 AM, Christian Carlow  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

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

[Christian Carlow]

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  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

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

[Christian Carlow]

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 
 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

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

[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 *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

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

[Jacopo Cappellato]

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  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 *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com