I assume this is related to the “Customer Display” form. If so, the CustID field is used for retrieving existing customers, not changing the loaded customer’s CustID. To do that you use the “Change ID…” button.
Entering a different CustID in to the Customer field will just load that other customer into the form. And if no customer sexists with that ID, then it asks if you want to make a new one.
I don’t want to change the ID. In Customer Entry, when I click on the new button, I have codes that generate a ID and populate the CustID Field. I don’t want people to modify this field so I want CustID to be ReadOnly.
You just need to save the record after the CustID field is populated. That “locks in” the Cust ID. If they were to change it to something else, it would be like retrieving a different customer record.
And you’re doing this in the Form via a customization? So the users would do something like:
Launch Customer entry program
Click a button or do something that initiates your function to “build” the desired CustID
Insert that built CustID into the Customer field
Make changes to other fields (address, etc…)
Save the record.
But without the user being able to change the ID prior to step 5.
My problem is that I already set a lot (5-6) of fields required so i can’t save with just an ID.
And yes, I would do these 5 steps but I need that between 3 and 4, the Customer ID field (textbox) becomes read-only/not modifiable
There’s really no other way? That way, it’s just creating useless entries if the person finally doesn’t create the client and forget to delete it or whatever.
I can’t believe that there isn’t a simple way to put a field read only on whatever condition when creating a new entry?
Why don’t you just make your BPM force the ID to what you want it to be? That way, even if they try to change it, they can’t. Once they hit save, it goes back to what it should be.
I can see a lot of things that can go wrong if I generate my ID in my customization and then i regenerate it in my BPM after. Placing a control over it would be a hack as you said.
Isn’t there a simple way to say control.ReadOnly = true or something like that ? I want to limit the code to my customization only if possible
Quoting from the Bible of Bart, Customization (client side) is for ease of use, BPM (server side) is for security. If you don’t want the user to be able to change it, just do it in the BPM and forget the client side customization. If you just want it to generate a “suggestion” then do it on the client side, because it will allow them to change it. (like you are seeing). It sounds like you want security, not just ease of use. Why is it a big deal if the BPM generates the ID after they hit save?
The other elephant in the room is simply training your users. Not usually as easy as it sounds, but sometimes the right answer.
I’m not sure of the business case for you but Customer ID (and Supplier ID) are not regular key fields like other tables. There’s an internal CustNum (and VendNum) that all transactions will point to. The Cust ID can be changed at any time. There’s no meaning to the number in Epicor except for multi-company.
Are we trying to make the new system look like the old one?
It’s just that we decided to change the CustID from a string of text to a unique number that will be an incremented number. I can,t change that decision so I’m trying to think of the best way to implement it in Epicor.
No, I’m not trying to make the system looks like the old one
Totally agree with training users. So far, we’re still migrating so we haven’t trained anyone yet. I always prefer to know what solutions are available before I think : “Let’s just tell them it works that way”.
I tried the enable property but it’s still updateable. It’s not so much a big deal if the BPM generates the ID after they save it if it’s the best solution that we find, it’s the one that I’ll use