Shannon's JD Edwards CNC Blog: Building blocks

Tuesday, 4 October 2016

Building blocks–exactly what a DD is!

This is a post for all DEV and CNC people to use when deciding how they are going to change some description on a screen. It’s important to consider the lifecycle of the change, not just the time it takes for you to hack the change into FDA. You need to think about ESU’s, upgrades and more to ensure that you are doing the right thing and the cheapest method of making your change.

Verbatim from oracle support – “To override the data dictionary default text in the application, the following methods are available and the text override method is applied in the following order:”

And here are the handy documents and some description from me.

Data Dictionary Text Change
Review Document 626622.1 E1: DD: Data Dictionary Text Change
Data Dictionary Jargon
Review Document 626565.1 E1: DD: Data Dictionary Jargon Code
Vocabulary Overrides
Review Document 626466.1 E1: DD: Vocabulary Overrides
Event Rule Code
Review Document 865183.1 E1: DD: Override Application Text using Event Rule code

DD

DD Text is easy and goes everywhere that there has not been a specific override done, P92001
DD affects interactive and batch the same
Do a full package after a DD change, just to be sure. Then you’ll know what you have to do next if some text does not change
If you have made a change with FDA / Jargon or Vocab overrides – this is NOT going to work!

Jargon

This is like an override per system code
So finance people call MCU Business Unit and Distribution call it warehouse, cool
We have a Jargon code for a task which says whether it’s 09 or 42 and we have an alternate description based upon that
Note that a task can have a jargon code, and a application can define it with OMW Product System Code of the Application

Note that the screen shot above is for the various descriptions per system code for MCU

Vocab overrides (VO)

first rule of vocab overrides is don’t use vocab overrides
The second rule of vocab overrides is don’t use vocab overrides
The third rule of vocab overrides is to understand them to use them properly! (thanks fightclub!)
Apart from changing code, this is as hard core as configuration gets.
The only thing that is going to trump a VO is code change. So – unless you are tucking into FDA and RDA – this is your last chance to get your description correct.
Remember that vocab overrides write DIRECTLY to central objects, no check-out needed! WOW!
So you change a VO, the change is written to the F987* files for the pathcode that the project status allows you to check-in to. There is a leap of faith there, I hope you understand what I wrote. It does not change your local SPECS. You need to do a get! (When making Vocabulary Override changes in the Vocabulary Overrides application, the application updates the information in the Central Objects repository directly. The information is not updated in the local client specifications. In order to see the changes the specifications can be deployed in a package or the specifications can be refreshed on the individual local client.)
You should only do VO’s under the guise of OMW, as the objects will need to be promoted.
They are cheeky and sometimes require a bunch of builds and deploys.
You need a fatty for them
They do not survive an upgrade or ESU
After checking in the application, the vocabulary overrides can be verified using P9220
Vocabulary Overrides are stored by language:

in FDATEXT by Interactive Application name, TextID, Language
in RDATEXT By Batch Application template/version, TextID, Language

Below is an interesting sequence of screen shots demonstrating JDE not recognising a subsequent change to a VOCAB, a rechange / back to original messes everything up.
It shows that the specs on the app have the new description of “Shannon”, but the vocab overrides app thinks that it’s the first changed value – wow – what a mess.