I am trying to set up a process by which an operation (and subsequent operations) can be frozen, such that an operator cannot clock on to those operations.
So far I have set up a checkbox in Job Entry that links to an extended field in the JobOper table and begun wrapping my head around the customization for StartProdActivity.
I have managed to set up an event handler that triggers when selecting the OprSeq, as well as an FKV and STV that gets me the JobOper table. What I would like to do now is pull in the “Frozen” bit field that tells me at which operation the job should be frozen. I am not sure how to pull in the corresponding operation sequence that has a “1” in the “Frozen” bit field. If I had that operation, I could then do an if statement and say if the selected operation sequence is higher than the frozen operation sequence, then bar the operator from selecting that operation.
if there is only going to be one “freeze Point”, then why not make this a field on the JobHead table that specifies where work is stopped.
I am assuming that the reason for the “freeze” is because you want to work until “Step 30” at which point, you stop until someone unfreezes it.
Taking this approach, a UD Field would be needed in the JobHead table to hold the freeze step, and then a BPM that would check this against the operation that is attempted to be started. If the job operation sequence is >= freeze step, then reject.
That’s a good idea…that makes it less complicated. The only issue I can foresee is how to pull in the JobHead table in the BPM. For this particular BPM, I would need to modify the Labor.DefaultOprSeq method, which doesn’t have JobHead in the temporary table list. How does one pull another table in for comparison?
BPM to do the validation is actually pretty simple. Add a new condition widget in the BPM, and choose the condition for “Number of rows in the designed query”.
Then design your query… you would link the ttLaborDtl table to the JobHead, and create the relations
THEN you add the criteria to specify that only records that are LESS THAN the frozen will be returned…
Something special about this WIDGET… it gives you a record count… so now we just need to tweak this. BECAUSE, if we find one, it is good, if it returns nothing (because it is on/after the frozen value).
All that is left is to add an Exception message to stop the transaction:
I think this is working…the only problem is if I select an operation that is frozen, I can’t select any other operation without it defaulting to the frozen operation I chose previously. Perhaps I can force it to reset value in OprSeq field to 0.
I got this to work. I changed it to a post-processing directive because it was firing only if the previously selected operation was frozen. If no operations should be frozen, the default setting for the frozen process field is 0, so I added a condition to check for that case (do nothing). Then I added a widget to set the OprSeq variable to 0 if an exception is thrown, which allows the user to select a valid job instead.
