Remove 0 from numeric fields?

So I have a custom RMA form I’m working on. We sometimes have our own people/installer deliver orders and them to grab the RMA while at the customers site. The “Pickup With” field is for the CSR to enter in the SONum of the order to which this RMA should be picked up with.

However, the field always shows a zero on new records, or ones that don’t need/have a SONum entered. How do I remove the zero like the standard SONum fields on forms?


I wonder if you can just change the default value for field from 0 to null in table maintenance

Sadly, I tried that… it also keeps coming back with a zero.

Make another UD field named PkUpSONumTxt_c, of type text.

And us a DD, BPM , or UI Code to convert the value of PkUpSONum_c to a text string for PkUpSONumTxt_c

Hmm, Google a bit and found this infragistics tip: I’ll try to see if I can get this to work on form load event.

The standard Epicor fields for Sales Order use a Text fields, so like @ckrusen suggested.

What if you change the Format from >>>>>>>>>>>>>>9 to >>>>>>>>>>>>>> ??

Couldn’t the SO number simply be a string? It’s not like you’ll be doing any math with it right?


I think @Banderson has the correct plan. I’m using the entered SO# to pull data from the Order table (actually ShipTo via the order table). I changed the code to convert to int32 and it’ll pull the data just fine.

The following error occurs when either text is entered or the occasions when the SO# will need to be cleared back to empty.

How do I restrict text entry? I tried setting the FieldFormat on UD Column Maintenance but it still allows text to be entered. Must be someway in code to do it.

We could probably live with the 0 or this error even if necessary but this is a good learning experience for me too.

Did you delete and re-add your UD field? (as an nvarchar?) and are you looking for a valid SO number from epicor? If so use an adapter and do a GetByID, then you can know that it’s not only numeric, it’s also a valid SO#

I got the GetByID doing the SO# verify the SO#s.

1 Like

Are you still getting your format error?

Yeah, it’ll be up to the users if they want to go with a number only field and live with a zero or do a text field and get those errors.

You should be able to do a text field and not get those errors.

Did you remove and re-add your UDField so it’s a text field instead of a numeric field?


That is a good point from Brandon…
Delete the original ud field regenerate all and recycle…(or put back it’s original type…and dont use it…)

Then add a new UD field nvarchar.

I had similiar issue, where getting same error…not just me, the other users trying to print…as I did not redo a regenerate… not all settings were in sync…

So my rule of thumb : if a need to change type, do not change current field…create a new one… got me less problems…:wink:



I did add new UD fields, I’ve never gotten the type to change on existing UDs.

The error isn’t the issue, the problem was as a nvchar field, it allows text to be entered. This is a SONumber field, which doesn’t allow text. If a user enters text the script tries to verify the SO# against the database. The result should be an error and that’s what we get:

but if they enter a number, then it works fine? So Basically, with your GetByID validation, it effectively does what you want it to right? Block them from putting in an invalid SO number. (Or does this make it never work?)

Could you throw in a try statement to try a convert the value to an int, then if it doesn’t throw a more intelligent error?

Yes it works perfect, if they enter a good SO# they don’t get any error. If I could stop text entry at all that’d be cool but not a biggie.

I think you should be able to change in the input mask on the text box to only allow for numerals. I started googling, but haven’t found specifically what you need yet, but I think it’s entirely possible.

You could do validation on each keystroke and check if it’s a numeric field. I’m pretty sure there is a keydown event in the wizards. (this might be overkill… anyone can feel free to jump in and give a better suggestion if you have one)

I’ve done some google searches too. This is the initial design of the new form and more iterations will come as the users get into testing it. I was going down this rabbit hole as I was waiting on feedback from them.

Thanks for the help @Banderson and everyone else.