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
<[email protected]> 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
