UDC best practices

[johndanter]

Hi guys,

I've been asked to inform the business on the best practice approach for UDC maintenance in my company. Amongst other things like Item Branch config etc.

I'm of the opinion that UDCs should be first entered and tested in PY, moved up and tested before going into PROD.

I am also aware that users can just sign on into PROD and change UDCs there and then. So we thereby lose any UDC environment harmony that may have once existed.

How do you guys handle your UDCs?

Do have updates down from PROD to PY UT etc? What happens when UDCs get promoted up into PROD? How do you keep a track to ensure they are all in synch?

I'd be interested to hear the different approaches

Thanks

John

 

[Chan Rana]

John,
Looks like you on full JDE rollercoaster ride!!!.

We have this handelled by Business manager who can create projects and does all the maintenance thru it. It would start from DV upto PD. All updates to PD would go thru the approval as per the deployment cycle. Normally all Core SMEs have access to their UDCs tables and can change description. Prod data would be refresh once in a month(s) to PY & if required to DV.

Chan

 

[Larry_Jones]

We treat UDCs like objects.
IT makes changes responding to user requests and normal test/promotion process follows.

Due to the potential impact of user's Add/Change/Delete UDCs we do not give them that ability.

 

[johndanter]

Ok cheers guys.

Keep them coming

 

[David Robertson]

We treat them like data, with a limited group able to maintain them in production, refreshed to test environments with business data.
Promotion via projects would only apply for particular projects where appropriate, such as a new UDC.

 

[peterbruce]

We treat them like data, with a limited group able to maintain them in production, refreshed to test environments with business data.
Promotion via projects would only apply for particular projects where appropriate, such as a new UDC.

That's basically how we handle UDCs too.

 

[johndanter]

Hi Dave and Peter,

Dave are you saying, brand new UDCs go up (I think that must be right) but changed existing UDCs come down in a refresh?

That's fine but what new key changes to the same UDC in PD and DV?

Example 12 FM, I've added new values to PD but I also have a few new values for an on going project in Dv that will come up.
How would handle that

 

[peterbruce]

John,

The problem with UDC promotion is that existing key values (F0005.DRKY) get overwritten with the promoted values.

For example in DV you have the following key values for UDC 59/AA:

AB
AC
BD

... and in PY you have these values:

BD
C4
CH

After promoting UDC 59/AA from DV to PY the values in PY will be:

AB
AC
BD

You will have lost C4 and CH.

Though this situation is an argument for doing all UDC add/change/delete in DV and promoting up the chain to production, if you add UDC key values that have been created in production to the test/development UDCs the problem is avoided.

Our practice is that all new UDC sets (new System Code - F0005.DRSY and Code Type - F0005.DRRT combinations) are added in DV and promoted through to production. For existing UDC sets at the time of (immediately before) development we ensure that the UDC sets start off with the same key values.

 

[johndanter]

Hi Peter,

Thanks for that.

I was under the impression UDCs would be merged?
So you'd end up with:
AB
AC
BD
C4
CH in PY

This maybe a site to site config option, but I checked this with my CNC a while ago and was told they are merged. So.....?

Although merging does raise issues for me on how you delete UDCs from below. So yeah, confused. But what you say makes sense. You would lose C4 CH

 

[peterbruce]

John,

Sorry for delayed reply, I've been away.

There is a difference between running the UDC Merge (UBE I think) used during an upgrade and promoting UDCs using OMW.