Is there a rule of thumb as to using an existing (unused) user-defined field (UserChar1, UserDate1, UserDecimal1, UserInteger1) versus creating one?
Tim K
Is there a rule of thumb as to using an existing (unused) user-defined field (UserChar1, UserDate1, UserDecimal1, UserInteger1) versus creating one?
Tim K
My rule… if you can remember what you used the predefined version of these for, then use them… but otherwise, create your own UD Fields with “real” field-names so that you can remember their purpose in the future. Epicor development did alot of work to make new UD Fields possible and seamless, and once you have used them, you will probably not want to reuse the ones that are already there.
Sometimes when doing customizations, and when I KNOW that the fields are unused, I may use the fields as temporary holding fields to prototype an idea… once the idea is settled, then I will create the new UD Fields and stop using these.
Couldn’t agree more. I’ve wasted so much time over the years trying to figure out what “CheckBox01” or “ShortChar05” etc. was supposed to be. These things never get documented very well, and when they do it’s still an extra step to refer to the documentation.
I used to have to keep an excel file listing all the tables that used Userxxxxx fields, and what they were used for.
But as far as UD columns, theyre not exactly seamless. Close, but not 100%. There’s a couple instances in BPM’s where they need to accessed differently than native columns.