What can I use Logical Dependencies for?

Logical dependencies for master data let you control which values a user can select based on what they have already chosen. Once you set up a dependency between two information codes, the system filters the available values automatically. If you select a gear type, you only see the bike types that match it. If you select a bike type first, you only see the matching gears.

The dependencies work in both directions. You do not have to select one value before the other. The system applies the filter no matter which field you start with.

You can tell whether a dependency exists by looking at the header on the lookup. A plain value list is called an “Information Value List”. A list with dependencies is called a “Logical Information Value List”.

What logical dependencies for master data are

Logical dependencies for master data is a way of determining which data values relate to each other. You can only select certain values once you have selected other values. This lets you build filters on your master data specifications, so users are guided to valid combinations instead of choosing freely from every option.

Take an item as an example. When you open the master data specification, you work with information codes such as material, tire type, gear, and bike type. Each code has a list of values you can select from.

How to tell if an information code has dependencies

The header on the lookup tells you whether dependencies are in play.

• If you drill down on an information code with no logical dependencies, for example “Material” with values like aluminium, the header reads Information Value List. The name tells you no dependencies are defined.
• If you drill down on an information code that has dependencies, for example “Tire type”, the header reads Logical Information Value List. The word “logical” means dependencies exist for that code.

How the filtering works in practice

The dependencies decide which values stay available as you make selections.

If you clear the gear value, the bike type field lets you select from all the different bike types, because nothing restricts it. The header may still say it is logical, but with no other value chosen, your setup allows all bike types.

As soon as you set the gear to a seven-gear bike, the bike type field narrows down. In this example you only have four bike types to select from, because the logical dependencies limit the choice.

It works the other way too. If you clear the bike type and look at the gear field, you see more than four gears to select from. If you then select a seven-gear bike, you only see the bikes that fulfil the dependencies, which in this case is two bikes.

The same applies when you start from the bike type. If you set the bike type to mountain bike and then open the gear field, you only see the two gears that match a mountain bike.

Where the dependencies are set up

The behaviour comes from a setup behind the scenes. When you drill down into an information code, you can view what is called Logical Dependencies.

For the gear information code, the dependencies might say:

• If the gear is a seven-gear, the bike type can be city bike.
• If the gear is a 20- or 21-gear, the bike type has to be mountain bike.

Once you add logical dependencies, the system recognises them when you do a lookup on an information value, and it applies the filter automatically. This is how you build the filters that guide users to valid master data combinations.

Q&A