We have a process where a part will be reported completed on a job one at a time on a production of better than one per minute.
We have to capture a tag number, assign a lot number based on the tag number (one lot per part produced), and record heat info for each part.
Rather than have the users report quantity on the part and then go to Job Receipt To Inventory to put it into stock and record the lot/heat info, we’d like to do it all in one step, when we will scan the tag.
Is there an auto-move function (they have the AMM license), or will we need to code something?
Everything I am reading about the auto-receive flag on the operation in these user guides states that the reported quantity needs to exceed the related sales order demand… which makes me think that this flag has nothing to do with MAke to stock jobs… Been a minute since I reviewed this flag.
Make Direct, Up to the qty of the sales order no receipt to stock, Anything reported over the direct job links qty will be received to stock. Even if it is greater than the job qty
We do almost all make to stock and auto receive all of them. Any quantity that goes thru the final operation will auto receive.
The one thing I have not been able to control is the destination bin location. It uses the part’s default bin and I have made multiple attempts to flex that without success.
thanks @E102016 and @gpayne , it’s the request move flag on the end activity screen that’s throwing us off. If that’s checked it doesn’t auto-receive.
But then the KB I look up says that the flag is defaulted IF the auto move checkbox on the resource / resource group associated with the final operation has been checked… and it’s not… so why is it checking itself
Are you using a code block or just setting the field false? We’ve been running into this same issue recently and can’t seem to get our users to not check this box. I’ve been trying to figure out ways to change it back to false but haven’t had any luck. Any insights would be welcome.
on load of end activity I set it to false and although it was not for this purpose I recently hid the tab that has request move on it, so it is not possible to check it. You could just hide the field unless there are sometimes it needs to be checked
I have hidden it before but, being cloud it takes hitting each sysconf after every upgrade. Was hoping to get it done server side. Since it’s not a db field the field security is out and can’t seem to fine a spot in a directive or BPM to get set false at before the write.
@cmulford The process is making a MtlRequest queue, so I would first check what happened to the transaction if it was deleted in the Material Request Queue or Manager.
It might be simpler to let Epicor make the MtlQueue and then delete it post processing as long as it finishes the receipt to inventory. If not you could also process the queue. I know there is code here to do that.
If I was doing this I would try setting the rowState to Deleted and see if Epicor did the rest for you.