So instead of custom mod’ing the DLL and having to recompile and redeploy everytime this customer upgrades I have decided to try and pull this into a BPM. But I have never attempted to pull a BO.Service Method into a BPM to manipulate it before. I reviewed both the ICE and Customization guides and couldn’t find any documentation on the mechanics.
Within the validateLotNum method from the BO.Service.IssueReturn there is a pcLotNum string field that gets checked for empty and then returns the message highlighted below in the screenshot.
I either need to suppress that validateLotNum method OR pass a value into the pcLotNum before it gets checked but I have no idea on where to get started with this.
Thanks for any feedback.
Jason
So that validateLotNum method gets called from OnChangeLotNum or when PerformMaterialMovement is called…
But it only matters if the Part is LotTracker and you do not have a lot number?
Can you explain why you want to bypass this?
One option is to simply Set… the LotNum field… but again it should only be an issue if the Part is lot tracked
What’s the underlying story?
The complete BOM for each of the finished goods are all parts on the fly and all PO’s are bought to job. So there are no part table records, no parttran records aside from the initial receipt, and no part lot table records. But each of these parts are required by regulation to be lot tracked through the production process. So I need to track Lot Numbers through WIP.
On the PO Receipt AND OnChangeLotNum method I can populate the LotNum field of the WIP table. But when it comes to a Wip to Wip movement that hits the PerformMaterialMovement it runs another validation that looks like its against the Part table to check for the LotTracked flag. So even though I have a LotNumber in the PartWip table this validateLotNum on the PerformMaterialMovement process ignores it.
Got it, if its not a real lot tracked part, why don’t you just use a UD Field?
Initially I did. And it works great until you come to the WIP to WIP transaction. So when I have a qty of 10 for example, and I begin moving those from the WIP OutBin of one OP to the InBin of the next OP the UD field is ignored in the PartWIP table and it drops them into a single QTY becuase those 10 pieces are all the same partnumber and going into the same Bin. So instead of getting a LOT layer, of 1 piece in the Wip Bin I get a single row with 10 pieces and the UD field just holds the value of the last transaction.
I see… what version of Epicor are you in?
You might be able to leverage / cheat by using PCID. PCID Generates a unique record so you could assign a different PCID to each of those (assuming its supported in WIP-WIP)
But frankly if you need this level of tracking it seems to be the best thing to do is do it properly and create the lot tracked parts.
Tried PCID as I like that functionality, however that created a lot of issues. I had no idea that the PCID functionality enables a whole slew of additional methods and rules I never knew were kicking off.
They have around 70 to 80K worth of part on the fly records a year come through their production floor so creating part records for all purchased parts would be impractical.
I may not have any other choice then to MOD that DLL, but that will be a last resort.
THanks for your help. I appreciate it
