With S/4HANA there is a clear shift in how customer specific fields are designed and used. The classic customer fields (z fields) that were historically created via append structures in R/3 are no longer recommended. While still technically possible, they do not align with SAP’s Clean Core strategy and are increasingly restricted in modern S/4HANA scenarios.
- Legacy customer fields cannot be used out of the box in new APIs (OData, SOAP)
- Legacy customer fields cannot be used out of the box for In-App Extensibility or Key User Extensibility
In S/4HANA the recommended approach for extending standard data models is using Custom Fields and Logic. Customer fields created via Custom Fields and Logic are fully integrated into the SAP standard technologies such as Fiori, OData and CDS.
In this blog post we clarify the available options for bringing legacy customer fields into the S/4 HANA world. From a complete migration into Custom Fields and Logic to partial solutions, such as ABAP Managed Fields.
Custom Fields and Logic
The gold standard. Future-proof, low maintenance, and considered by SAP during upgrades.
Advantages
- SAP-standard compliant
- Automatic integration into Fiori, OData, CDS, etc.
Disadvantages
- High initial effort if the legacy Z field has many usages
- Complete migration from old Z fields to new Z fields required
- Legacy code must be adapted (reports/interfaces)
- Data migration required
How to
New Custom Fields can be created using the application Custom Fields and Logic (F1481).
When creating a custom field, a business context is mandatory. In the past, database tables were extended. Today extensibility in S/4 HANA is driven by business contexts rather than by tables. To determine the correct mapping from a table to the corresponding business context, you can execute the program CFD_GET_BUS_CTXTS_BY_DB_TABLE. If the program is not in your system refer to SAP Note 3699976.
Changes made via the Custom Fields and Logic application are not automatically recorded in transports at the time of creation. To include changes in transports use the application Register Extensions for Transport (F1589). Maybe its also necessary to use Configure Software Packages (F1590) inbefore.
ABAP Managed Fields
These allow new fields to be defined in a technically clean way in S/4HANA, while existing legacy Z‑fields remain unchanged and can continue to be used internally or mapped.
Advantages
- Old Z field remains in use
- No or minimal data migration
- Old Z reports/interfaces do not need to be adjusted
Disadvantages
- Not sure about this one, you have to create cds views yourself for fields with valuehelps… but besides that…
How to
Pretty straight forward. Call transaction SCFD_EUI. Enter the database table that contains the legacy z-fields. When executing the report it analyzes the table and displays which z-fields can be activated for use in Custom Fields and Logic. If a field cannot be activated directly, the report provides guidance on the required preparation steps or adjustements. After successfull activation, the fields appear in the Custom Fields and Logic app without changing the underlying database structure.
CDS based extensions
If you only need to adapt APIs that are based on CDS, you can also manually extend CDS views. So far, I have not encountered a scenario where I would recommend this approach over ABAP Managed Fields. As soon as a field is activated for Custom Fields and Logic, Fiori, OData, and CDS integration come out of the box – essentially for free.
This makes ABAP Managed Fields clearly the superior approach compared to manually extending CDS views.
Append Fields
Still technically possible and usable for legacy scenarios.
In short: Just don’t do it.