Jiwa

Customer is migrating from Jiwa 6 to 7.2.1 SR5. We'd like to use the production planning to help automate some stuff they're currently doing manually.

The key thing we're trying to tackle at the moment is their 'cut shop', where they're cutting sheets of raw material. We're wanting to collate all orders that use a specific raw material, so that they can be combined in a CAD system to optimise the cutting.

I've made a copy of the build-to-order plugin, which is a close match to our requirements (being largely made-to-order parts). Since the customer has a Bill No = Part No setup, I've modified the stored procedure so that the 'Part No' range works as a 'component' range. That is working to give me a list of potential work orders that use a specific component.

But I'm a bit stuck on the next bit, which is to generate a single work order that creates multiple outputs instead of multiple work orders each producing a single output.

Do I need to intercept MakeWorkOrdersUltraButton_Click() or ProductionPlan.Process() ?

Or is this something there's already a process for that I've missed?

pricerc wrote:Do I need to intercept MakeWorkOrdersUltraButton_Click() or ProductionPlan.Process() ?

ProductionPlan.Process() is what I would use - In there you would meddle with the ProcessCandidates collection.

Each ProcessCandidate in that collection has a WorkOrder property which is simply a normal WorkOrder business logic instance.

Ok,

I've made some good headway with this project.

I ended up bypassing ProductionPlan.Process().

Creating the candidate WorkOrder up front results in a single candidate per raw material, with no UI for selecting which demand within that to fulfil.

So I instead I populated the candidate list 'normally', and then hooked ProductionPlan.ProcessStart in SetupBeforeHandlers, and parsed the candidates manually, creating a new job per raw material, honouring the 'Process' flag. I then throw a UserCancelledException.

I have a bit of fine-tuning to go, but it seems to be (mostly) working.

I could use some guidance on populating extra columns on the candidate list. Because I'm generating output items from the candidate list, I'd like to add a 'share of cost' column to the candidate list. While it's easy enough get get extra data out of the stored procedure, I can't seem to find an event I can hook into.

Ok, just when I thought I was winning....

I can get the 'fresh' workorder looking great:


However, it seems that the underlying logic for allocating input to output cannot cope with this.

In the example presented, the idea is that the *combination* of inputs creates the *combination* of outputs. However, I am unable to (manually at least, I haven't tried programatically) set all the output quantities without getting a complaint about unsufficient inputs for allocation.

I take a look at the allocations page after adding just the first output quantity of 1 for the first line, I see that it has allocated all the inputs to just one output:


And then I get this when I try to set the quantity output value to 6 on the second item:


So a couple of questions:
1) can I turn off the automatic allocation so that I can do it manually later? I don't need it happening in real time while the operator is entering the numbers.
2) will that even work? i.e. if I can disable the automatic allocations, and say intercept the 'close' function and do it there, would the structures support it?
3) is there a better way I should be doing this?
4) is this a futile exercise with the 7.2.1 incarnation of WorkOrders? Looking at the (decompiled) code, there are a few places where I can see I'll have to completely override the standard behaviour, with no obvious means.

further to question 2:
In my example, all of the outputs use the 'CUTTING' and 'OVERHEAD' 'parts', and then at least one of the 'J*' parts. Each raw material 'J*' part is a sheet of gasket material, which gets cut with a laser or mechanical cutter (depending on the material). Because not all gaskets are the same size, it is possible to nest small ones inside large ones, and the amount of raw material used for a small one is (usually, but not always, because geometry) less than the raw material used for the big one. And shapes matter too, because different combinations of shapes can produce less waste for a given sheet of raw material.

So there is no single 'primary' output, they are all primary outputs. The overall cost, including waste and fixed costs (setup time for machines), will be divided up between the outputs depending on their theoretical share of the raw material.