Have you encountered a situation in which an SAP process required one too many steps or you had to remember to notify the appropriate people when a master data change was completed? Do you have business processes that require printed documents to be signed physically? These are just a few of the many opportunities to use workflow to streamline financial processes.

Some workflow applications are as simple as the automatic notification of newly created master data. Others obtain documented approval for an upcoming vacation or financial document. The more complex ones automate cross-functional tasks such as the resolution of purchase price variances, automated creation of production orders, and creation of a new material master record in stages.

I'll give a brief overview of Business Workflow technology, then step through a couple of examples to demonstrate how easily you can integrate this technology.

Business Workflow Overview

The trigger to begin a workflow process is called an "event." The event is linked to a "task" through a "binding." The task may be as simple as sending an email or as complex as a dynamic requisition approval process for a capital expenditure that results in a purchase order to the vendor.

While the task remains relatively consistent over time, a "work item" is created each time the task runs. Think of the work item as an interoffice envelope that carries information and keeps track of the specific steps taken during its particular journey through the business process. This envelope of information is called the "workflow container." Bindings pass information from the initiating event into the workflow container and then communicate between the workflow container and each individual task.

Events

SAP delivers many standard financial events associated with business objects. Delivered events are found in the Business Object Repository (BOR) via transaction SWO2. Figure 1 shows a sampling of the financial objects available, such as Account, AccountingDocument, and GeneralLedgerAccount.

Figure 1

Examples of BOR objects

Figure 2 shows the events available in the standard cost center object, which you access by double-clicking on the object. In this example, Changed is the only event delivered.

Figure 2

Standard cost center events

To validate that an event is triggered at the appropriate time, activate the event trace via transaction SWELS in a test environment. This task is self-explanatory, but your Basis team can assist you if necessary. Then perform the expected triggering activity and confirm the trace captured the event via transaction SWEL, which enables you to view the trace log.

If you are not able to find a standard-delivered event in the BOR, SAP also provides several ways to trigger events. I'll focus on the three that are most relevant to financial processes: change documents, financial validations, and ABAP code.

Change Documents

You can link change documents to events. Just about any change to a master data record generates a change document, such as automatically broadcasting the creation or change of a cost center or cost element to a mailing list of recipients.

As you can see in Figure 2, SAP does not provide an event for cost center creation in the standard business object BUS0012, so I'll use that as an example to show the steps required to create a new event.

Step 1. Confirm that a change document is generated when a new cost center is created. You can confirm that this document will be available by performing an activity creating a cost center in a test environment and then querying table CDHDR by user name and date. Field OBJECTCLAS contains the object name and OBJECTID contains the record key. Figure 3 shows a sample entry found by viewing table contents with transaction SE16. The key fields found in OBJECTID are critical, as they must align in order and format with the key fields in the business object that will be created in the next step.

Figure 3

Sample change document entry in table CDHDR

Step 2. Create a new business object. This is where you can begin to enlist the assistance of your development team. Here, the system creates a new business object (or subtype of the existing object) with these keys along with an appropriate event via transaction SWO1. The change document is subsequently linked to the business object event through a wizard using transaction SWU_EWCD. The first dialog, shown in Figure 4, is where you identify the business object. In this case, it is the newly created ZBUS0012. Note that ZBUS0012 was created with reference to standard object BUS0012. Because of this relationship, you can see the standard event BUS0012/CHANGED in Figure 4.

Figure 4

Identify a business object for a new event

Step 3. Give the new event a name that will be used for future integration to workflows. In Figure 5, the event I named Created has similar textual descriptions.

Figure 5

Create an event

Step 4. Link the new event to a standard change object. This allows the event to be triggered automatically by the system. Figure 6 illustrates the process of choosing the appropriate change document (KOSTL) and selecting its creation event.

Figure 6

Link the new event to a change document

Financial Validations

The second method to trigger an event is the financial validation rule. You can use financial validations to issue error or warning messages to the user when certain customizable conditions are met within financial documents. They are available for both FI (transaction OB28) and CO (transaction OKC7). You can trigger them at various points in the creation of financial documents, such as document header, line item, or completed document.

If you have an existing validation rule, you may simply insert additional steps to trigger workflows. If you are not using validations or do not have them configured at the appropriate locations in document creation, it may be necessary to create a new validation rule, assign it to your company code (FI) or controlling area (CO), and set the activation indicator to a value of 1. This configuration takes place on the initial validation screen, as shown in Figure 7. Use the menu path Environment>Validation to reach the detailed validation rules.

Figure 7

Validation configuration

Two Boolean statements that analyze field values from the document header and line items are configured within each validation step to determine whether the message should be issued. If the prerequisite statement is true and the check statement is false, the message appears. For example, a prerequisite statement could say USERNAME = JDOE and the check statement could be amount < $1,000. If user JDOE attempts to post a line item in excess of $1,000, the configured message is issued. If the Trigger workflow option has been selected in the step configuration, an event is triggered.

Figure 8 shows a simple example of a financial validation that can trigger a workflow whenever a document is posted. The user name (SYST-UNAME) and company code (BKPF-BUKRS) are parameters to the message and are therefore available for use within the workflow. The message contains ampersands where these parameters will be inserted when issuing the warning message to the end user. The setting of I for message type indicates this is only an informational (lowest severity) message, but it will work effectively to trigger the workflow event.

Figure 8

Validation to trigger a workflow

The TRIGGER event associated with object type VALIDATION is generated by a financial document validation. The object key concatenates the Validation name and Validation step. Message variables are passed along as container elements for use in the workflow.

ABAP Code

The final relevant method for triggering workflows uses ABAP code. Custom code or user exit capabilities provide you with the ultimate flexibility to launch workflows, as they are available in numerous locations throughout the system. For example, you could create an internal approval process that takes the results of a scheduled ABAP report and routes the results through managers for review. This workflow could be generated immediately or could be based on user input.

Figure 9 shows an example of code that launches a workflow directly. Alternately, it is possible to trigger events directly through the use of code and subsequently link workflows through configuration. The sample code attaches the current system date and user name as values within the workflow container. You can attach any runtime information that is available within the code to the workflow container for use in subsequent decision-making or information broadcasting. This includes individual values as well as entire tables of information. Realization of this programmed trigger is another opportunity to involve the development team's assistance.

Figure 9

Start workflow directly with custom code

Standard Tasks and Workflow Templates

Once you have chosen an event to start the process, you can build your Business Workflow. The standard documentation for SAP NetWeaver (Application Platform>Business Services>Business Workflow) training classes do a great job of covering the details, so I will include a basic explanation of configuration.

Transaction PFTC_INS initiates workflow template creation. Multiple standard tasks, such as sending an email, soliciting a user's input, or performing a function module, are connected, forming a workflow template. You can incorporate logic into the workflow to control recipients, actions, and process flow. Using the Workflow Builder, which is a graphical toolset, connect these multiple steps directly or with conditional logic. Access the Workflow Builder directly by clicking on the button in the Basic data tab of a Workflow template definition (initial screen linked from transaction PFTC_INS, shown in Figure 10). The fourth tab of the Workflow template definition is also where Triggering events can be linked to the workflow.

Figure 10

Initial screen for Workflow template development

Figure 11 shows an example of a simple cost center process in the Workflow Builder. The workflow notifies management of a new cost center, confirms whether the cost center is acceptable, and either deletes the cost center or notifies other users if it is approved. This could be the workflow triggered by your change document event. Similarly, you could put a process in place based on a financial document validation to notify the controller when a financial document affects cash by more than $100,000.

Figure 11

Sample cost center creation flow

Bindings

Perhaps one of the most critical concepts is that of binding the events to tasks. The event, workflow, and tasks each include their own containers of information automatically. (Recall the example of the interoffice envelope filled with information by the event that hands off key items to each task within the workflow). Binding configuration simply maps similar fields within these containers to pass information throughout the flow.

Figure 12 illustrates the use of bindings for the cost center creation notification. The new cost center number was captured by the creation event and subsequently handed off to the workflow container. Two of the tasks — a user decision (question mark and play button icon) and an email message (mail coming through mail slot icon) — use this information to customize the information provided to the user. The variable component of these messages is represented by an ampersand (&) in the text of the tasks. This key value is also required to complete the task that deletes rejected cost centers. Figure 12 also shows binding from the event into the workflow. You use similar configuration to pass the cost center number into the decision, email, and deletion tasks.

Figure 12

Binding from cost center event into workflow. Available objects head the page; mapping is maintained on the bottom half

Agent Assignment

Now that you have defined the trigger and action to be taken, you need to tell the system how the task will be completed. Each task in the workflow must be completed in the background (by a standard system user) or assigned to one or more end users for completion in the foreground. Users are notified that they have outstanding tasks waiting for completion and may access these tasks through the standard SAP inbox. Agent assignment is maintained in the details of each task. Figure 13 shows an example agent assignment for a cost center notifica-tion where my user name is specified explicitly.

Figure 13

Agent assignment of a typical task

You can accomplish the foreground agent assignment in several ways, from hard-coding a single user or human resources position to writing ABAP code that reads configuration tables dynamically. The organization structure maintained in HR (or a simplified version for Business Workflow) is typically the best approach, as tasks are assigned to positions, jobs, or organizational units rather than individual users. If multiple users are assigned to a single task, it will be considered complete when the first available user takes action on the task.

Standard Workflows

While the previous steps in this article have shown how easily a simple workflow can be constructed from scratch, some terrific standard workflows are delivered by SAP along with the standard installation. You can use the Business Workflow Explorer (transaction SWDM) to browse existing workflows. Although they may require some level of customization (such as definition of approvers), they lend themselves to rapid and complex implementation.

A classic example of a configurable standard workflow is that of release approval for parked documents. The configuration for this workflow controls which users must approve parked documents to allow automatic posting. It is maintained in the IMG under Financial Accounting>Accounts Receivable/Payable>Business Transactions>Incoming Invoices/Credit Memos>Carry Out and Check Settings for Document Parking.

Several workflow options are available depending on the levels of approval needed for document release. For example, in a small accounting department, a single-level approval by the controller may suffice. Larger organizations may route through a divisional controller and even require corporate approval for significant entries. They are also assigned within the configuration — the delivered options are FIPP_SUBWF01 through FIPP_SUBWF007. Figure 14 shows a simple example of an account assignment approved by a manager prior to posting of the parked document.

Figure 14

Standard workflow FIPP_SUBWF04 for account assignment approval

Matt Christensen

Matt Christensen is the director of Enterprise Performance Management at PRAGMATEK Consulting Group in Minneapolis. He has more than seven years of experience implementing a broad set of SAP financial modules, including configuration and development in R/3, Business Information Warehouse, and Strategic Enterprise Management. Matt holds an undergraduate degree in computer science and an MBA in finance.

You may contact the author at matt.christensen@pragmatek.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.