Should that be “Added”, “Changed”, or “Updated”? I can never keep them exactly straight.
I check the part to see if Part.Tracklots is true but otherwise the same.
That is a good question and why I posted this, I hoped someone would know the proper context. Also in response to your other questions, we have no other BPM’s on that method directive at all. We have maybe 6 in total on other directives, and I think 4 are circumvented by required field check box in extended properties now. I need to verify that and remove them if they are.
Seeing as how we don’t have much custom programming I’m unfamiliar with how to run a trace, so I’m glad you did to see what is used. 
I will try it against the PreCommitTransfer as Ron noted, as well as check it against the Part.Tracklots value. It sounds like it works for him, so hopefully it does for me to.
To trace …
- Click the Tracing Otions icon on the toolbar (no idea where it is on the Modern Shell)
- Enable Tracing
- Enable Track Chanegs Only
- Apply
- Clear log (this is just to flush out any prior log info)
Now go use E10 as normal, then return to that Tracing options
- Click View
EDIT
DON’T FORGET TO UNCHECK the ‘Enable Trace Logging’ and click Apply or OK, when you’re done !!!
1 Like
Thanks Calvin.
Ron, when I setup the BPM on PreCommitTransfer I do not have the option to check against the field Part.TrackLots, the only option available for a field is the ttInvTrans.TrackLots field. Can you link the BPM to check other tables not present in the current method?
Not a big deal on the field check… it’s a success for this test… Now to try a SN controlled part to make sure it wont prevent that from going through.
Doesn’t block SN tracked parts so that field check on ttInvTrans.TrackLots works as it should!
Thanks for the conformation, and Calvin, it worked using “the changed row”
If you did need to check that the Part was lot controlled, use:
Where qry1 is:
with the Table Criteria:
(or something like this … The “Number of Rows in the Query …” condition tends to throw me off)
That’s almost exactly what we did. Only difference is we don’t use tt tables in the condition query. We set the Part number in an argument/variable first and then use that variable in the query. We were advised by @josecgomez that this is the recommended way. I hope I was right about that.
1 Like
Yup don’t join to ttTable! !EVER! 
1 Like
I believe it is checking to see if the part is lot controlled… Unless I’m reading this condition line incorrectly.
I have to assume when you select the part, it brings in the value that is present on the part master into that field on the InvTransfer table, so then the BPM can check to see if it’s a “track lots” part.
I’m under the assumption it’s doing this because I can leave that field blank when it’s inactive on a SN part transfer and I don’t get the Exception.
I did read that just the other day too…
I’ll now go to the penalty box and feel shame …
I don’t have any BPM’s with argument variable and query’s in them… that’s beyond my level here. I’m a one man show in IT and starting to become the only guy who can figure out, and want to figure out, Epicor problems too, now that my father retired.
You’ve earned the title “SAD” (System Administrator by Default)
Well I’ve also been here for 20yrs… Worked on populating Vantage when I started here and moved up to the Network Admin over the years, went through vantage, to Epicor 9 then 10.1 and 10.2 last month. My father was always the Epicor functionality guru, and now that is falling back on me. Tough when you don’t have a cost accounting background.
1 Like
Learning by doing, is the best way to learn. You might not learn the best ways to do things, but you learn lots of bad ways to avoid. 
1 Like
Yes, it is!!!