Technical Articles
Key User Custom Fields: When to use what type of code list
Do you want to create a key user custom field, which offers a value help, but you don’t know which type of code list field is the right one for your specific use case? Or do you wonder which types of code list custom fields are offered in general and which one to choose in which situation?
If your answer is yes, then this blog post is just for you.
This blog post covers the following topics:
- Which types of code lists are supported for custom fields
- Typical patterns when to use which type of code list
Which types of code lists are supported for custom fields
There are three types of custom fields that provide a code list at runtime:
- “Association to Business Object”:
This can be either an SAP standard business object like “Company Code” or “Cost Center”, or a key user custom business object. At runtime, the records offered in the value help are the instances of this associated business object.
For most of the associated business objects, a forward navigation to the UI of the respective business object is offered, too.
Note that in almost all cases the key of the associated business object consists of exactly one component. - “Code List”:
You statically specify the code values together with their language-dependent descriptions as part of the metadata of the custom field. These code values and descriptions can only be changed in the development system and are transported together with the custom field to subsequent systems (e.g., to the test or production system).
At runtime, the records offered in the value help are exactly these code values and their language-dependent descriptions. - “Code List based on CDS View”:
This can be a key user custom CDS view, a developer extensibility custom entity or a C1-released CDS view.
Note that the key fields defined in the value help view will be used as components of the custom field. For fields of this type, you can specify a UI navigation, so that the field becomes a link at runtime in the extended UI in display mode.
This field type is by far the most flexible code list field type, as you can:- Use a developer extensibility custom entity and implement the logic entirely in ABAP (see this blog for further details). For example, you can create a developer extensibility custom RAP BO and wrap that with a developer extensibility custom entity and use that one as value help view.
- Re-use other key user objects by wrapping them via a key user custom CDS view:
- Key user custom code list: With this, you can create a static code list like the one you specify with a custom field of type “Code List”, but in a re-usable way e.g. by user key user custom fields
- Key user custom business object: i.e., multi-key cases can also be supported
The following table provides a crisp and simple overview of the pros and cons:
Field Type | Pros | Cons | Complexity |
Code List | – Simple | – Static code values – Change of code values only via transport from development system |
Very simple |
Association to Business Object |
– Many pre-configured features – Change of code values directly in production system |
– Not all SAP BOs available – Restricted feature set for Custom BOs |
Simple |
Code List based on CDS View | – Maximum flexibility | – Manual configuration effort | Complex |
Overview of custom field types supporting code list
Typical patterns and rules when to use which code list type
Now let’s have a look at a couple of typical patterns in custom field use cases that help you decide which of the code list field types to choose.
The “Static code values only” pattern:
Situation:
You want to have a static code list for which you don’t need to change the code values in the test and production system, independent from the development system.
Solution:
Use code list type “Code List”. If you want to re-use the code list for several custom fields or several key user objects, then use code list type “Code List based on CDS View” and wrap a key user custom code list with a key user custom CDS view as value help.
The “Dynamic code values only” pattern:
Situation:
You want to have a code list for which the code values are created locally in the test and production system.
Solution:
In this case, one of the two code list types “Code List based on CDS View” or “Association to Business Object” are the right choice.
The “simplicity” rule:
In cases where your use case fits the “Dynamic code values only” pattern, you should always first have a look at the “Association to Business Object” code list type, as it’s simpler than the “Code List based on CDS View” code list type and has in almost all cases built-in intent-based navigation.
Also, before you decide to implement your own developer extensibility custom entity, always check first whether a standard SAP CDS view you can take as value help view exists, or whether you can create your own key user custom CDS view that fits to your needs. The reason for that is that implementing a value help view with a developer extensibility custom entity requires in-depth development skills and consumes by far more effort.
The following table provides an overview of the most important aspects when choosing between code list field types:
Aspect | Code List | Association to Business Object | Code List based on CDS View |
Complexity | Very Simple | Simple | Complex |
Availability | All versions | – SAP BO: Since S/4HANA 1809 – Custom BO: Since S/4HANA 1709 |
– Since S/4HANA 2021 (Custom CDS Views) – Since S/4HANA 2022 (Other views) |
Number of key fields | Single key only |
– SAP BO: usually single key – Custom BO: single key only |
Depends on used objects / Can be configured |
UI Navigation Support | Not supported | – SAP BO: usually available – Custom BO: runtime UI can be generated |
Can be configured |
Where to maintain? | Development system | Locally in system | Depends on used objects |
Who can maintain? | Key User | Business user | Depends on used objects |
How to maintain? | Custom Fields app | – SAP BO: usually maintenance UI exists – Custom BO: maintenance UI can be generated |
Depends on used objects |
External API exists? | No | – SAP BO: depends on used objects – Custom BO: can be generated |
Depends on used objects |
Feature matrix of custom field types supporting code list
Feedback, Comments, or Questions
You’re cordially invited to provide them in the comments section below. Please follow my profile to get updates when I publish more posts on these topics.
Feel invited to post and answer questions here (https://answers.sap.com/tags/270c4f37-c335-46e1-bfad-a256637d5e26) and read other posts on the topic (https://blogs.sap.com/tags/270c4f37-c335-46e1-bfad-a256637d5e26/).
I want to thank Yasmina van Rooij and Karsten Schaser for their extremely helpful contributions.
Other related blog posts:
- How to implement a custom field of type “Code List based on CDS view” with a developer extensibility custom entity: https://blogs.sap.com/2022/07/26/sap-s-4hana-key-user-extensibility-powered-by-embedded-steampunk-custom-field-with-abap-implemented-value-help/
Also: “How to implement a custom entity in the ABAP RESTful Programming Model using remote function modules” - How to configure the value help as a context-dependent value help: https://blogs.sap.com/2022/07/27/sap-s-4hana-key-user-extensibility-custom-field-with-abap-context-dependent-value-help/
- How to configure intent-based navigation on a key user custom field of type “Code List based on CDS View”: https://blogs.sap.com/2023/06/06/enrich-sap-s-4hana-key-user-custom-fields-with-intent-based-navigation/
and in this case, how to easily find the fitting semantic object and semantic object parameter: Custom field type “Code list based on CDS view”: Finding/defining the right value help view and the right Semantic Object and Semantic Object Parameter for Intent-Based Navigation - Custom fields in S/4HANA: Key User versus Developer Extensibility