Most tables of the API support initial values for at least some of their fields. For such fields, initial values will match any given value, which allows the creation of [partly] "generic" customizing entries.

At runtime the customizing will be filtered and the most specific entry will become effective.

In order to keep the subordinate pages short and crisp, the unified documentation format for database tables is described here.

Column	Description
Fieldname	The technical fieldname
Fieldtype	Possible values: Filter, Key, Data
Filter-Priority	Only filled, if Fieldtype is Filter
Description	Describing text for the column

Fieldtype	Is key field?	Description
Filter	Yes	Initial values are considered "generic", meaning that they will match any value at runtime.
Key	Yes	Initial values are NOT considered "generic". They must match the runtime values.
Data	No	Data fields contain the actuall settings.

If multiple fields of type Filter exist, the field Filter-Priority becomes important. If multiple matching customizing entries exist, the Filter-Priority decides, which entry "wins". The entry with lowest number has the highest priority.

The example explains how the filter logic works in detail.

Imagine that the structure description of our table looks like this:

Fieldname	Fieldtype	Filter-Priority	Description
KEY_1	Key		Example key #1
FILTER_1	Filter	2	Example filter #1
FILTER_2	Filter	1	Example filter #2
SETTING	Data		Example setting

NOTE: Field FILTER_2 has the highest priority in this example!

If you look at the table e.g. in SE16, it contains the following data:

KEY_1	FILTER_1	FILTER_2	SETTING
42	HELLO	FOO	1
42	WORLD	BAR	2
42	HELLO		3
42	WORLD		4
42		FOO	5
42		BAR	6
42			7
			8

The initial Filter-fields will match any given value at runtime, which could lead to multiple matching customizing entries.

As we need EXACTLY ONE customizing entry, such collisions will be resolved using the Filter-Priority to find the most specific entry.

The following table shows which input values would produce which results.

Input for KEY_1	Input for FILTER_1	Input for FILTER_2	Potential Matches	Result	Comment
42	HELLO	FOO	1, 3, 5	1	A perfect match always "wins".
42	HELLO	BAR	3, 6	6	6 wins over 3 because FILTER_2 has the higher priority.
42	UNKNOWN	INPUT	7	7	1 - 6 do not match because of the non-initial fields.
12	UNKNOWN	INPUT	N/A	N/A	8 would match, if the input KEY_1 was initial (Key-Fields are NOT generic)