Lesson 3 of 5
Custom fields
9 min
When the data a business needs simply is not in SAP's object, a custom field adds it. Key users create custom fields in the Custom Fields app (in older releases the combined Custom Fields and Logic app). The field is added to the business object, and the key user then decides where it should appear and travel.
Creating a field
- Choose the business contextThe object and level the field belongs to, for example sales document header
- Define the fieldLabel, technical name (generated with a customer prefix, typically YY1_), and type: text, number, amount, date, checkbox or a list of values
- SaveThe field definition is stored but not yet usable
- Enable usagesChoose the apps, reports, forms, email templates, APIs and business scenarios where it is available
- PublishThe system generates the field and its usages; this takes a few moments
- Add to the UIUse Adapt UI to place the field on the screens where users need it
Choosing the right type
| Type | Use it for | Watch out for |
|---|---|---|
| Text | Free references such as a contract number | Free text is hard to report on; set a sensible length |
| List of values (code list) | Controlled values such as fleet segment A, B, C | Values are part of the field definition; changing them later needs a new publish and transport |
| Number, amount or quantity | Measurable values | Amounts need a currency and quantities a unit |
| Date | Contract start, warranty end | Agree whether the date is mandatory and who fills it |
| Checkbox | Yes/no flags such as "fleet priority" | A checkbox cannot express "unknown" |
Field types and their trade-offs.
Usages: where the field lives
A field that is only on the screen is half a field. The usages decide whether it can be seen in the app's UI and its reports, printed on forms and in email templates, read and written through APIs, and carried from one document to the next. For document chains, SAP offers business scenarios that copy a custom field from a predecessor to a successor, for example from sales order to billing document, where such a scenario exists for that pair.
- Sales order headerFleet contract number entered by the order desk
- Business scenario enabledField copied forward where SAP provides the scenario
- Billing documentField carried on the invoice
- Invoice formField printed for the customer, if enabled for the form
- AnalyticsField available in queries on billing data, if enabled for the data source
The lifecycle: from creation to transport
On SAP S/4HANA on-premise and private cloud, key user extensions are handled by the Adaptation Transport Organizer, which Basis sets up once (in SAP GUI with S_ATO_SETUP). New extensions are first saved locally. A key user or administrator then assigns them to a software package and a transport request with the Register Extensions for Transport app (with packages maintained in Configure Software Packages). The transport request is then released and imported through the normal landscape, development to quality to production, like any other change.
In SAP S/4HANA Cloud Public Edition, the mechanism differs: key user extensions are collected in the development system's customizing tenant with the Export Software Collection app and brought into test and production with the Import Collection app. Dependent items, such as a field and the logic that uses it, should travel in the same collection.
Fields and existing documents
A new field starts empty on every document created before it existed. At Contoso, hundreds of open fleet orders were in the system when the contract number field went live. Decide what should happen to them: leave them empty, fill them by a controlled mass change, or accept that only new orders carry the value. Then test that open orders still deliver, bill and print correctly without the field, because any logic or form that assumes the field is filled will meet these documents first.
What would you do?
Maria creates the fleet contract number field in the Contoso development system, publishes it and sees it on the order screen. She asks Priya to test it in QAS client 100 the same afternoon, but the field is not there. What is the most likely reason?
- Custom fields are created in a business context, saved, enabled for usages, published and then added to the UI.
- Choose the type carefully; value lists and lengths are hard to change after go-live.
- Usages decide where the field appears and travels: UIs, reports, forms, APIs, business scenarios.
- On-premise and private cloud: Adaptation Transport Organizer and Register Extensions for Transport. Public Edition: Export Software Collection and Import Collection.
Check your understanding · not graded
Lesson check
1. In which app do key users create custom fields in current releases?
2. What does enabling a usage for a custom field do?
3. Which on-premise app assigns key user extensions to a transport request?
4. Why should field type and value list be agreed before publishing?