Create new/custom PO Header or Item Text in Public Cloud

[ruby_hii]

Dear Experts

Can someone advise how to add a custom PO text field so that it will be reflected in the various PO Fiori apps?  Do we have to add them as custom fields via Extensibility (e.g. Custom Fields & Logic app).  The PO will not be printed as it is replicated from another external system and the PO data is only store in the Public Cloud for reference purpose.

Thank you.

[OwenLiu]

Added procure tag

[AndreasMuno]

Hi Ruby,

thanks for your question.

Short answer

Yes – in SAP S/4HANA Cloud, Public Edition, the recommended way to add a custom PO header or item text and make it visible in the Fiori PO apps is to use key‑user extensibility via the “Custom Fields” app (Custom Fields & Logic). You work with the Procurement: Purchasing Document and Procurement: Purchasing Document Item business contexts and then enable the field on the relevant UIs and (optionally) APIs. [help.sap.com], [help.sap.com], [help.sap.com], [help.sap.com]

Because your PO is not printed and is only stored for reference, you do not need to touch forms/output management – you can keep everything in the Fiori and API layer.

---

Recommended approach (header & item text visible in PO Fiori apps)

Below is a generic pattern that works for the standard PO apps in S/4HANA Cloud, Public Edition.

1. Create the custom field in the correct business context

1. Log on to the SAP Fiori launchpad as an administrator / key user.
2. Open the Custom Fields app (in the Extensibility group). [help.sap.com], [help.sap.com], [help.sap.com]
3. Create a new custom field:
   • Choose + (Add).
   • For a header‑level PO text, use business context
     • Procurement: Purchasing Document. [help.sap.com]
   • For an item‑level PO text, use business context
     • Procurement: Purchasing Document Item. [help.sap.com]
   • Choose a suitable field type, for example:
     • Text with appropriate length (for short notes), or
     • Long Text / Text Area if you want a longer, free‑form comment field (depending on what’s offered in your release).
4. Maintain the basic properties (label, tooltip, length, etc.) and save the draft.

The external documentation confirms that key users can extend the purchase order apps using exactly these business contexts for header and item level. [help.sap.com]

---

2. Enable the custom field in the relevant PO UIs (Fiori apps)

After the field is created, you must explicitly enable it for the Fiori apps:

1. In Custom Fields, open your newly created field again.
2. Go to the UIs and Reports tab. [help.sap.com], [help.sap.com]
3. Look for the PO‑related data sources, for example (names may vary slightly by release):
   • Purchase Order GUI Application (header)
   • Purchase Order Item GUI (item) [help.sap.com]
   • Plus any specific Fiori apps you use such as:
     • Manage Purchase Orders
     • Create Purchase Order – Advanced (if applicable) [help.sap.com], [help.sap.com]
4. Tick the checkbox to enable your field for these UIs.
5. Publish the custom field.

According to the PO extensibility documentation, once you have enabled the custom fields for the purchase‑order‑related data sources in the UIs and Reports section, the fields appear in the Custom Fields section of the PO header and/or item details. [help.sap.com]

After publishing, users will typically see your field:

• In the header details → “Custom Fields” or similar subsection.
• In the item details → “Custom Fields” tab/section at item level.

---

3. (Optional) Enable the custom field for APIs used to replicate the PO from the external system

Because your POs are coming from an external system and only stored in S/4HANA Cloud for reference, you likely also want this custom text field to be available in the integration layer.

1. Stay in the same custom field in the Custom Fields app.
2. Still under UIs and Reports, look for API / data source entries, for example:
   • Purchase Order (OData V4) – this API explicitly supports extension fields added via the Custom Fields app. [help.sap.com]
3. Enable the field for the relevant API and re‑publish.

The Purchase Order (OData V4) API documentation states that you can add extension fields to the API via the Custom Fields app and Custom Logic app (Key User Extensibility). [help.sap.com]

If you are using the asynchronous SOAP API PurchaseOrderRequest_In to create or update POs from your external system, you can review that service as well and align the mapping so that your external field (from the source system) is mapped into the new custom field in S/4HANA Cloud. [help.sap.com]

---

4. Use (optional) custom logic for defaults or validations

If you need additional behavior around the new text, you can use key‑user BAdIs via Custom Logic:

1. Open the Custom Logic app. [help.sap.com]
2. Search for PO‑related enhancement options (BAdIs) and create an implementation that:
   • Sets a default value for your text based on other header or item data, or
   • Performs checks/validations (e.g., require a comment if some condition is met).

The general extensibility guide explains that BAdIs can be implemented via Custom Logic to adapt app behavior, including additional checks or default values, and they work nicely in combination with custom fields. [help.sap.com]

---

5. Governance / operations tip

From a project and operations perspective, it’s a good practice to document all extensibility objects (custom fields, logic, CDS views, etc.) so you understand their impact on future releases and upgrades. This is a general recommendation for S/4HANA Cloud Public Edition projects: every change to extensibility objects should be tracked and documented.

This is especially relevant in your scenario where POs are replicated from another system – it ensures everyone knows how the custom text is filled, mapped, and displayed.

---

Notes / constraints

• Edition & scope: The above is valid for SAP S/4HANA Cloud, Public Edition and its PO Fiori apps using the key‑user extensibility framework (Custom Fields app). [help.sap.com], [help.sap.com], [help.sap.com], [help.sap.com]
• No change to standard PO types needed: Adding such a field is done via extensibility. You should not need to change standard PO document type configuration to achieve this. (There is a general recommendation not to change standard PO/PR document type configuration, but to use copies if you need different behavior.)
• Output / printing: Since you explicitly said the PO will not be printed, there is no need to enable the field on forms or email templates. If in future you decide to print, you can also enable the custom field for form templates from the same Custom Fields app. [help.sap.com]

---

Sources

• Extensibility for Purchase Order Apps – business contexts and how custom fields appear in PO header/item custom fields sections [help.sap.com]
• Custom Fields app – overview & procedure – how to create and publish custom fields, enable them for UIs/APIs/templates [help.sap.com], [help.sap.com], [help.sap.com]
• Purchase Order (OData V4) API – support for adding extension fields via Custom Fields & Logic [help.sap.com]
• PurchaseOrderRequest_In (SOAP) – inbound purchase order service for external systems [help.sap.com]
• Adaptation of App Behavior / Custom Logic app – using BAdIs for additional checks, defaulting, mappings with custom fields [help.sap.com]
• Project recommendation: keep track of every change made to extensibility objects – general best practice for S/4HANA Cloud Public Edition projects

---

AI transparency note

Note: This response was prepared with AI‑powered assistance like SAP Joule for Consultants (J4C) (see <https://www.sap.com/products/artificial-intelligence/ai-assistant/sap-consulting-capability.html>) and then reviewed for source support. Please validate against the linked official documentation for your specific release.

If this helps, please mark the answer as accepted so others can benefit as well. Thank you.