Hi All
Just A quick question
We have issues with people missing data when they input into epicor, So one of the ideas is to have a message pop up that reminds people to fill in the details correctly. would this be a BPM and if so is it possible to detect Purchase order Entry as an example open and then display a message.
Thank you for any pointers.
Cheers
D
Are you wanting to catch the input and stop if it is incomplete or just give them a nag at the start.
Explain exactly what you want. 
So lets say i click on Purchase order entry to make a PO i would like a window to open to give them a nag/reminder that all the correct information needs to be inputed into the PO. and maybe put a few bits of information on the message so if it carries we can take the next step which would be making fields mandatory.
Hope this helps
I would use the Extended Properties to make the fields you want mandatory. They will not be able to get by that without filling out the fields.
Well since this is classic, you could do it client side in the Form_Load.
You could also look through the trace and find a suitable BPM to tack it onto.
Warning, nag too much and you’re gonna get yelled at. You might want to invest some time in training instead.
Bonus. They will still forget. 
I always forget about that!
one nice thing about using a BPM to do this, you can apply it to the .Update method, and the error message can be more conditional. putting a rule into the extended properties is a hard and fast rule… it will just be “required”, but there is no validation… but a BPM can validate too… you can specify that a description is required, AND that it must be more than X charactors long. the Extended properties only says it is required, but the user can simply enter an X and save to get around the requirement.
I also like the ability within a BPM to make the rule dependant on WHO is running (which security group). With this, you can say that someone in the ARCollect group is allowed to take a customer off hold, but someone in Sales is NOT allowed to take them off hold. BUT ANYONE can put them ON HOLD. This can all be done in one BPM (if hold changes from true to false, check security group and reject if not ARCOLLECT… ELSE, if hold changes from false to true… let it happen). I have also done something similar with credit limit… allowing some team members to DECREASE the credit limit, but only certain people can INCREASE the credit limit… or maybe still another group to increase it above a certain level. BPMs can really be your friend with required fields and rules about them.
My only qualm with this is that it makes the field required in order to save the record which can be tough on users. I prefer using BPMs for all the reasons Tim said, plus you can have it trigger when, say, the PO is Approved instead of simply when the header record is saved for the first time.
I like the BPM approach for all the reasons Tim mentioned, plus for the future, all the logic is in one spot instead of scattered in the fields being made required. A Pre-processing Directive on the Update method is used for a LOT of our tables.