Are Blanks Required?

Island Rob

Member
My developers insist Blank values are integral to JDE in both UDCs and other attributes. The Data Governance position is to explicitly define all values and not allow blanks to be defaults unless it is for something like address suite where there would not be an entry if one did not exist. My questions are if this were a new JDE install: Are '.' or blank codes for UDCs required? How about the blank descriptions that go along with them? What about blanks for Y/N indicators? How about other attributes?
 
Hi Rob, welcome to JDEList.

1. You will need to leave blank values in UDC tables where blank is a valid value in the fields to be validated. That's the way it is.

2. Put a period or some other small character in the blank UDC description field.

3. General rule. A Yes/No or 1/0 value should only allow those values ... but this is a general rule - not a Universal rule.

4. Developers are always right - except when we're wrong
wink.gif
 
Larry,

If there is never a business reason to have a blank code or description, is it ever required by JDE to have that UDC entry?
 
Beyond Larry's points, because you indicate more than UDCs, there are ZERO null values in the database. If you leave ANYTHING without a specific value the table column will be filled with BLANK (" ").

In fact, the presence of NULL will royally hose your database fetches. In conversions, since many use external copy tools, this is the most prevalent error. The system will absolutely fail to function if NULLs are present in your data.
 
No, you don't 'need' a blank in all UDCs. Only those fields that are optional should have the blank entry (or blank is a valid entry).
 
Thanks for the response Whip. I'm getting pushback from developers that Blanks are required and that JDE cannot be changed to remove them. I suspected that if for instance Blank means 'No' and that you can create an entry for 'No', there is no reason to have blanks as a UDC entry. I didn't think this was rocket science. Is it considered a best practice to have blanks as UDCs in JDE? I know from a data quality or data architecture best practice, it is not desired.
 
One more point I forget to mention. Blanks are never truly needed. If something does not apply, you can have an entry that says 'NA' for Not Applicable. So is there ANY other reason my developers would argue with that?
 
I'm with Darren, no you do not need to have a blank value. Especially if you change the default to some other value.

A perfect example of this is on the AP/AR Terms Code. Historically blank was used for 'net 30 days', but the problem was if you started with a non-blank, then if you wanted to go back to blank, the system thought you didn't put a value in and would put back in your old value. So to get around that short sightedness they also have a '30' for 'net 30 days'. Thus you end up with 2 different codes for 'net 30'.

The "trouble" with not allowing blanks is that it means extra keystrokes for your users. But if you set default values, and since this is a new install they won't know that they could have had blanks.

It will require more diligence and some upfront work. But it sounds like you've got the Governance committee to help make it work. If you've got the time and patience to test everything, I say good for you and go for it. Worst case scenario is that you have to go back and loosen the best practice in a few places. It's much easier to loosen than to try to reign it in later.
 
Blank does have value. As Steve says, you may be throwing some extra work at your users. I haven't seen any clients using 'NA' in place of blanks. If you go that route you may want to experiment with Default values in the Data Dictionary in addition to lots of testing.

Now, one thing to be aware of: the UDC setup may have the Hard Coded flag set to 'Y'. Do not remove any UDC code with this flag turned on. There is at least one program that's written to recognize that specific value.

Now, on the programmers. I'm sorry, but they are terribly misinformed. UDCs are not required to have a 'blank'. Now, saying that, if you remove any blanks that came 'standard' you need to verify removing them doesn't break anything.
 
Hi Island Rob,

[ QUOTE ]
If something does not apply, you can have an entry that says 'NA' for Not Applicable. So is there ANY other reason my developers would argue with that?

[/ QUOTE ]

Just three comments from a developer:

C#1:
Not all UDC 2 char long at least (e.g. 1 char long)

C#2:
NA and NO can be valid already existing values in some vanilla or custom UDC.

C#3:
Not all UDCs are AlfaNumeric, several of UDC-s are Numeric Only.

Regards,

Zoltán
 
Great discussions. Thank you much for your input. My suggestion for N/A instead of blank would only apply if blank was given an implicit meaning of Not Applicable. If blank meant 30, it would be replaced by 30. The governance concept requires that if blank has an implicit value, it is changed to be explicitly defined. What a nightmare it is to try and consume JDE data that has blanks all over it. How does BI know what each blank is supposed to represent?
 
Zoltan, my example of NA was just an example. The value would be whatever makes sense as long as it is not blank. Having a value shows the column has a stated meaning and not overlooked.
 
UDC blanks are so inherent and built into how JDE works globally. To require a non blank value in every single UDC table goes against the nature of how JDE UDC tables work. My personal opinion is that an initial install with no blanks as a valid value and setting up the DD to always have a non blank as a defualt in all the UDCs will have you putting out constant fires. Will it be worth it? Think about future upgrades.

On past implementations, I have had inexperienced clients tell me that a UDC value of blank would not suffice. Usually I am able to communicate verbally the need for blank values. I vaguely remember one time not being able to convince the client. So what I did was I setup a small prototype removing blanks as the default.

Here is what happened:
- Interactive programs highlighted the UDC fields that had no values. OK, so we Sequeled a default value of "NA" - Fixed right? Then we had to do the same for the Data Dictionary for all those that had blanks as defaults (almost all of them)
- Many of the standard JDE reports suddenly grew because of the new valid value of "NA"
- Then by chance we needed a SAR or ESU and suddenly we had more issues and it all came down do blanks as a valid value in a UDC table.

One of the great things about how the UDC table works is when you absolutely require a value. That is when blanks should be removed as a valid value.
 
Thanks Alex. I'm confused. I though additions to UDCs were retained during upgrade.
I think we are OK with extra reporting when it accurately represents what the true meaning of BLANK is. This truly is a governance issue and it forces the business to define what it means to have no value entered for each field. Required fields assign the proper default that can be a true default or something that relates to 'Unknown'.
I can see that this may not work if JDE expect to see a code value of Blank or '.' to initiate some functionality. Does that happen? Is there any way to determine which UDCs are setup that way?
 
You are correct, UDCs are retained during upgrades. I don't remember the specifics but do remember that the JDE developer(s) that created the ESU incorrectly assumed that blanks were always a valid value for a certain set of UDC tables.

Bottom line: there is no problem not having a blank as a valid value, but only for the UDCs your business will be using. ALl UDCs not being used leave as is.
 
Back
Top