SAP S/4HANA Output Management: A Look at the Architecture and Tools
Output management has changed fundamentally with SAP S/4HANA. Therefore, this article sheds light on the most important architectural components – both the database (CDS views vs. tables) and the set of rules (BRF+) and also the central Fiori applications. Plus, learn more in this article by diving deeper into how the new tools work to make your processes efficient.
Table of Contents
- The Paradigm Shift: From Classic NAST to Modern S/4HANA Output Management
- Fiori App F2279: Monitor Output Requests
- SAP S/4HANA Output Management: Fiori Apps for Scheduled Processing
- CDS View COUTREQITEM and Table APOC_D_OR_ITEM: Difference and Relationship
- BRF+: The Role of the Business Rule Framework plus in Output Management
The Paradigm Shift: From Classic NAST to Modern S/4HANA Output Management
Probably the most significant architectural change in SAP output took place with the switch from SAP ERP to S/4HANA. While the old, proven system of classic message control was based on the **NAST** table, it has now been replaced by agile, centralized **S/4HANA Output Management**. As a result, this change is much more than just a technical update – it is a fundamental paradigm shift in the control of document output.
A look at the key differences
| Focus | Classic Message Control (NAST) | S/4HANA Output Management (Modern) |
|---|---|---|
| Rule Logic | Based on the condition technique configured via transaction NACE and associated Customizing tables. | Leverages the powerful **Business Rule Framework plus (BRF+)** for flexible, non-modification-based rule definition. |
| Data | Direct storage of the message data in the physical table NAST, embedded in legacy frameworks. |
Relies on **Virtual Data Models (CDS Views)** that are based on modern tables such as APOC_D_OR_ITEM . |
| Construction | Module-centered and strongly tied to the respective applications (e.g. SD, MM). | **Centralized** and unified across all applications, optimized for cloud and on-premise environments. |
| User interface | Primarily controllable via the SAP GUI and the classic transactions. | Managed and monitored via **Fiori apps** (e.g. F2279 “Monitor Output Requests”). |
The new Output Management is designed to meet **cloud requirements** and also offers end-to-end **centralized management** of all expenses. In addition, data is consistently provided via modern interfaces such as CDS Views (basis for COUTREQITEM). Although the old NAST controller in S/4HANA On-Premise still exists for certain legacy applications, the new Output Management is still the clear standard for all current and future SAP applications as well as for the entire Fiori world.
Fiori App F2279: Monitor Output Requests
The Fiori app **F2279** with the title **”Monitor Output Requests”** plays a central role for users because they work with output management in SAP S/4HANA. As a result, it enables both business departments and IT staff to get an **overview** of all generated output orders.
- Purpose: The app is used to monitor and troubleshoot the printing and e-mail traffic triggered by the system (e.g. order confirmations, invoices, delivery documents).
- Database: The app accesses the data of the issue order items directly or indirectly. This includes status information and references to the underlying documents, the details of which are usually provided via CDS views such as
COUTREQITEM. - Functionality: Users can check the **current status** of the output jobs (e.g. *Successful*, *Failed*), view details and often also resend (*Retry*) or cancel the output jobs.
In short: The Fiori App F2279 is thus the **frontend tool** for managing the data, which is technically stored in tables such as APOC_D_OR_ITEM on the one hand and provided via views on COUTREQITEM the other.
SAP S/4HANA Output Management: Fiori Apps for Scheduled Processing
In the **new SAP S/4HANA Output Management**, the processing of outputs is controlled via application-specific Fiori Apps as soon as they are marked with **DISPATCH_TIME 2 (Scheduled). However, there is **no single, generic app** for all output types that bundles this process.
As a result, the names of these apps often follow the pattern: either “Schedule [Application Object] Output” or “Schedule the Release of [Application Object] Outputs”.
Examples of Fiori apps for scheduling output jobs
| Business Application | Fiori App Name (Examples) | Fiori App ID (example) |
|---|---|---|
| Invoicing (Billing) | Schedule Billing Output | F1510 |
| Purchase Order | Schedule the Release of Purchase Order Outputs | F5367 |
| Sales Documents | Schedule Sales Document Output | F2459 |
| General monitoring | Application Jobs (to manage all scheduled jobs) | – |
Important notes on how it works
- Fiori app as interface: The app only serves as a **user interface** to define the selection criteria (e.g. document numbers, organizational units, etc.) for the background job.
- Background: The actual processing takes place in the background as a **job** that uses the **Generic Job Scheduling Framework**.
- Targeted selection: These apps only process output items that are marked with the **Scheduled Time 2** (“Scheduled” or “Scheduled”). Messages of sending time 1 (“Immediately” or “Sofort”) are processed directly when the receipt is saved.
CDS View COUTREQITEM and Table APOC_D_OR_ITEM: Difference and Relationship
The fundamental relationship between the physical table (e.g. APOC_D_OR_ITEM) and the CDS View (e.g. COUTREQITEM) reflects the design principle of the Virtual Data Model (VDM) in SAP S/4HANA:
- The physical source: The raw, technical data of the output order items are stored in the database table (
APOC_D_OR_ITEM). It is the repository of truth. - The logical interface: The CDS View (
COUTREQITEM) is the standardized, stable and often performance-optimized access layer. It abstracts and provides the data for use.
Conclusion: In modern S/4HANA environments, you should always use the CDS View to access data. On the one hand, it offers the necessary abstraction of complex table structures and is also the future-proof method in the SAP ecosystem.
BRF+: The Role of the Business Rule Framework plus in Output Management
In S/4HANA Output Management, the entire logic for **finding output parameters** is no longer mapped in the classic condition technique (NAST), but instead centrally controlled by the **Business Rule Framework plus (BRF+)**.
BRF+ also acts as a powerful tool for modeling and executing business rules that determine:
- When an output order is created (e.g. after posting an invoice).
- Which one output settings (printer, e-mail address, fax number).
- Which one Form or which type of send is used.
These rules are organized in **functions** that access context objects (such as your document data) on the one hand and make decisions on the other hand, which consequently lead to the creation of the output order items (database for COUTREQITEM).
Key BRF+ access points
Although BRF+ is primarily configured via the Web Dynpro-based Workbench, it is still accessed via the Fiori Launchpad:
- Fiori App “Output Parameter Determination” (Transaction OPD)
- This app is the **central, simplified Fiori interface** (often a wrapper for the Web Dynpro application of transaction OPD) for configuring the output rules in S/4HANA Output Management. It provides a case-by-use view of the BRF+ regulations and is the most important entry point for functional consultants.
- Transaction BRF+ (or BRFPLUS)
- The classic transaction to start the **BRFplus Workbench** (Web Dynpro). This is the expert interface in which the underlying applications, functions and the actual decision rules (decision tables, etc.) are directly modeled.
