Many of you are challenged with the need to manage planning processes in SAP NetWeaver Business Intelligence (SAP NetWeaver BI) that have closed-loop mechanisms with transactional systems such as SAP ERP Central Component (ECC). This subsequently enables decision making or triggers a transactional posting with an accounting implication. I will walk you through a couple of business processes that require establishing a closed-loop process from your SAP NetWeaver BI environment. I will also help you understand the implications with respect to segregation of duties (SoD) and how to build controls that help you realize the business process via technical implementation.

In this two-part series, I’ll examine two business processes: one that is commonly found in consumer packaged goods (CPG) industries and another that is a media-specific business process with a generally accepted accounting principles (GAAP) implication.

Target Setting, Plan Creation, Commitments, and Expense Tracking

CPG companies are faced with the increasing need for product innovations, effective promotions, and profitable portfolio mixes. They are always on the lookout for ways and means of improving profitability, increasing market share, and containing costs. To achieve these business goals, it becomes imperative for CPG companies to promote their products and deliver value through continuous improvement in quality and reduction in price. CPG companies invest significant sums of money on marketing and sales to boost both top-line and bottom-line numbers. Typically, you find CPG companies spending on product promotions, pricing promotions, wholesale and retail discounts on off-take, target and volume discounts, promotional packaging — the list goes on. With margins narrowing and consumers demanding more quality and quantity for less money, these companies need to invest wisely, cut costs, and at the same time, boost sales and customer confidence while retaining loyal customers.

One of the key tasks in every CPG company is to continuously manage and monitor their sales and marketing expenses. This becomes challenging, especially when there are several hundred sales and marketing personnel who have to manage their expenses in a consistent manner across a wide geography. Such challenges are usually diverted to the company’s information systems (IS) division, which is constantly asked to come up with solutions that:

1. Provide a single system of access (usually a portal) for the sales and marketing personnel
2. Require the set up a consistent interface for entering and tracking marketing commitments and expenses
3. Provide a secure environment that allows a specific set of users and restricts access only to the information that they need to view and manage
4. Enable SoD
5. Provide data validations and error-checking mechanisms that eliminate user errors or prompt for corrective action

I’ll first examine the CPG marketing spend business process shown in Figure 1. This is a high-level example of the business process and can vary by company, segment, and type of goods offered to customers.

Figure 1

Example business process

This is a simple business process in which corporate approvers set expense targets and make allocations for sales and marketing promotions with a view to increase sales or customer base. The targets are for the upcoming fiscal year. The continent and regional managers then break down the targets into plans, which are categorized and subdivided based on sales territory (regions), brand groups, and customer groups. The managers then submit the territory plans for approval for execution. Based on approval, the plans become actionable and are realized by determining specific types of promotions, creating commitments for expenses and placing vendor orders for goods and services to execute the promotions. The vendor orders are executed, and the marketing team carries out the promotional spend.

Soon after the vendor orders are placed, the sales finance analyst generates and posts accruals for expenses in ECC. Actual expenses are then accounted after reversing accrual postings in the subsequent month. The marketing team then compares actual expenses to plan to determine variances and analysis carried out to determine spend effectiveness. The planning and forecasting team then applies this data from analysis to subsequent quarterly budgets and for the next annual budgeting process.

A number of business process steps originate in SAP NetWeaver BI that you can perform using a Business Planning and Simulation (BPS) planning application and Web interface. These include:

1. The creation of targets and plans in BPS
2. Use of commitments created as internal orders in ECC, which are used in the BPS planning application
3. Status tracking of the commitments
4. Review and challenge of expenses
5. Approval for accrual in ECC – these originate and are triggered from SAP NetWeaver BI to make accrual postings in ECC

You would also notice that various individuals or groups are interested in one or more business process steps. Now I’ll show you how SoD is carried out and how you can configure SoD in the system with the appropriate system controls that guarantee security, integrity of postings, and immediate data availability for reporting (Figure 2).

Figure 2

SoD in the system

The following key guiding principles were established to build the BPS application to support the business process:

1. There should be clear SoD in the system, which is auditable
2. The security and authorization mechanism should be simple to maintain and use
3. The system should be able to accommodate a large number of changes to internal orders that were used to capture promotion spend and assignment of various field sales personnel to these internal orders
4. A single, easy-to-use, consistent interface is required to capture commitments, status tracking, approval of expenses, and initiation of accrual postings to ECC
5. Establish an instant reporting environment to allow reporting of expenses against plan, review status, and report deviations

I’ll examine each section of the business process or processes by the various roles and show how to establish controls in the system.

The sales finance executive team delivered the application to about 400 users all across North America with varying levels of security depending on the geography they covered. The project team had to set up users in SAP NetWeaver BI and create appropriate roles to manage their business processes. It created unique roles for various types of users:

• System and process administrators
• Account administrators
• Budget analysts
• Sales financial analysts

System and Process Administrators

The system administrator had specific tasks to perform relating to the setup of users and providing user access to the planning application, which includes maintaining permissions for various users to view only a portion of the application to which they require access. The former was achieved by creating a role that would allow the assignment of the users to the BPS application and provide the access to the SAP NetWeaver BI portal. The system administrator created users, assigned permissions via transaction code PFCG to those users, and provided access to the users to the SAP portal that was designated as the medium to access the BPS application and reports. SAP provides this type of access and control that allows creation of users and assignment of permissions and calls them delivered controls. As part of the prepackaged application software, SAP delivers the mechanism to create users and maintain permissions in a consistent manner. Figure 3 shows the delivered controls that are standard in the SAP system and the custom controls that system administrators created to manage and maintain BPS.

Figure 3

Controls for system and process administrators

The system administrator also has the responsibility to provide the specific access to the budget analyst and the sales financial analyst. The budget analysts manage the commitments and track the expenses against these commitments. The marketing finance team created the commitments as internal orders in ECC that were extracted into SAP NetWeaver BI. Now, all budget analysts cannot have access to all internal orders, and they would need access only to internal orders that pertain to the specific promotion that they track. Therefore, the account administrators created an internal order hierarchy, and one or more internal order hierarchy nodes were assigned to secure permissions to the budget analysts, as well as sales financial analysts. The internal orders were grouped under various nodes by grouping the type of promotions pertaining to a particular territory.

Permissions were then set at these hierarchy nodes, which would allow the users to access all internal orders under that hierarchy node. This looks pretty straightforward, but there were a few challenges. The internal order hierarchy was constantly growing and changing. The assignment of internal orders to users kept changing frequently, and the users wanted to have an application that would be performance efficient in the front-end user application and at the same time, have an intuitive interface.

The users were required to access only those hierarchy nodes to which they had permissions and select either the node to access all the internal orders under that node or access a specific internal order. Also, the internal order hierarchy node should be accessed by only one user at any given point in time while using the planning application to preserve data integrity. We examined different alternatives for provisioning the access to the internal order hierarchy. We created a portion of the hierarchy tree and displayed it in the application using a custom XML script. This looked good in the UI but was performance inefficient because the hierarchy node contained numerous internal orders and the BPS variable had to read the entire hierarchy before filtering based on user-defined security requirements. Hence, this was not a suitable option.

The other option was to create and use BW- or SAP NetWeaver BI-based roles. You can create BW roles by using transaction code RSSM in BW 3.5 to secure users to specific hierarchy nodes or by using transaction code RSECADMIN in SAP NetWeaver BI 7.0. This would mean that we have to create roles for as many unique combinations and assign them to users. A first pass at this presented us with more than 100 roles. Creating and managing so many roles was going be an onerous task, especially because the security requirements keep changing. This became a task that required continuous maintenance and quick turnaround. Creating BW roles would have to go through the development life cycle and cannot provide quick changes in a production environment. All of this resulted in more maintenance dollars and hence was not a viable option.

We then settled on creating two BPS variables: one for storing the BPS hierarchy assignments to the users and another for reading the hierarchy node for that particular user that the system would only display on the front- end application (Figures 4 and 5). We created the second hierarchy variable as a user exit variable that read the nodes for a specified user.

Figure 4

Hierarchy variable to store user-defined values

Figure 5

Hierarchy variable to read user-defined values

Because the user wanted to select the hierarchy node or the internal order in BPS for expense and status updates, we had to use the Restriction of Values Required by User option. This is automatically set for hierarchy variables. While this option allows users to freely choose the hierarchy node or the internal order with which they wanted to work, it provided another challenge by not restricting the security to only those hierarchy nodes to which the user had access. We considered a user exit variable as an option to read the entire hierarchy values from the first variable and then filter this by the user assignments.

This did not work because the values provided by variables with a user exit did not allow the selection of the values for the user as expected. Moreover, the variable of this type did not allow input by the user. For this, you need to define the variable with replacement type User-Defined values. So the user was presented either with the entire hierarchy rather than the portions to which the user required access or was presented with a hierarchy where the user selection was not allowed because it was a user exit variable. The ability to restrict became meaningless with the entire hierarchy showing up for user selection. This set us back to square one.

We came up with an idea and examined a little further to see which table holds these values in the underlying database. We looked at the UPC_VAR table that stores the configuration information on variable definitions. This table stores for each planning area, the variable name, the type of variable (i.e., characteristic, hierarchy node, numeric, or attributes), replacement type (i.e., fixed value, user-defined values, user exit, or authorization), the flag for user selection, the flag for user restriction, and administrative information on when and by whom it was last changed.

The two fields of interest are the USERSEL field and the USERRESTRICTION field. The USERSEL field is shown in configuration as a flag called Input allowed by user. This determines whether the user can enter values for the variable in the end user application. The first variable shown on the left in Figure 4 is a variable of this type. We used this variable to store all the user assignments to hierarchy nodes. This field is only relevant when using the variable with replacement type User-defined values. The USERRESTRICTION field determines whether the user must select an active value (i.e., active combination) from the values defined in the variable, with which the user is currently working in the planning session. For hierarchy variables, this field is set by default; however, it is not ready for input.

In essence, we wanted to have the user exit variable that allows flags for both these fields, which then enables user restriction and selection and allows input by users. This is not available as standard with the SAP software. We then decided to force the flag USERSEL in table UPC_VAR for the user exit variable, which solved our problem. This is not a standard configuration, and hence we had to write a small program and created a transaction code to set the flag in production. At the same time, we had to secure this activity with the system administrator.

We had to take the challenge to implement in this manner because we wanted to provide the users with the ability they wanted and also create a very simple security model that requires minimal effort on maintenance.

We assigned the process administrators the task of maintaining the user access to hierarchy nodes. This is what provided the users with the requisite access to data in BPS. The user assignment was enabled as a simple BPS variable maintenance. The maintenance required assignment of new users to hierarchy nodes, deletion of user assignments, and changes to user assignments to add or remove one or more hierarchy nodes. We could not directly maintain the BPS variable via the customizing transaction BPS0 because the end-user application would then be locked while the customizing changes take place. To prevent any user disruption, we wrote a separate program that allowed the account administrators to make changes via selection screen, and this was updated directly to the UPC_VAR_CHA_SEL table. This also secured transaction code BPS0 and provided a separate transaction code for user variable maintenance that was accessible only to the process administrators.

With this security model, process administrators were able to set up user security in a couple of minutes that otherwise would have taken hours. The process was simple, effective, and did not disrupt the planning process.

Account Administrators

We created separate roles to manage the tasks of the account administrators. The account administrators maintained the internal order and cost element hierarchy in ECC. They had an internal notification process from the regional sales managers, which was used as the basis to update the internal order and cost element hierarchies in ECC. You can see the configurable controls and inherent controls that are delivered with SAP NetWeaver BI in Figure 6.

Figure 6

Controls for account administrators

The SAP NetWeaver BI system is integrated with ECC and guarantees the accuracy and availability of data in SAP NetWeaver BI. The master data hierarchies are extracted into SAP NetWeaver BI through a standard master data load process, which then ties back automatically with the hierarchy in ECC. In addition, the planning application leverages the same SAP NetWeaver BI back end to consume the master data. This guarantees, for example, referential integrity using only the values that exist for that master data.

In addition, you can enable default values in the planning application. This reduces user error and selection of values, which in turn determines the selection of plan data in the planning application. This is a simple mechanism by which you can restrict data access to users.

Budget Analysts

We created separate roles for the budget analysts to enable them access to the planning application and to access only the internal order hierarchies to which they were assigned permissions. We created the front-end application using an HTML interface using the Web Interface Builder (transaction code BPS_WB) (Figure 7). We secured access to budget analysts in two ways:

Figure 7

Creation of the front-end application using Web Interface Builder

1. We created separate tabs in the planning application and provided budget analysts access only to specific tabs. This was possible by creating tab strip control in the Web Interface Builder and securing the application by providing access only to that tab. We then created a separate BW role that provided access only to that tab. Users were then assigned this role, which allowed them access to the tab where they could insert, change, and delete budget commitments.
2. We further secured actions to be performed by the budget analysts in the application by providing access to specific user actions, such as entering, changing, and manipulating data using planning functions.

The budget analysts had tasks that required them to:

• Record expense commitments for various promotions
• Update the status of these commitments as to whether vendor orders were placed, goods received or services rendered, and vendor invoices were processed
• Approve these commitment line items and enable workflow to pass this on to the sales finance analyst for further processing

The above processes require establishment of appropriate controls that would provide (Figure 8):

1. Requisite access to the application and data (discussed earlier)
2. Necessary checks and balances when entering or changing data. We enabled this by leveraging SAP-delivered controls such as referential integrity for master data (e.g., choose only the list of cost elements required for the application or the status codes for updating document status).
3. Enable workflow so that the sales finance analyst can perform subsequent process steps. We enabled this by using custom process codes, which allowed saving the data created by the budget analyst with one status and then copying the same data set with another status code for use by the sales finance analyst. In essence, we used the characteristic combinations in the data along with the process code to secure data to various roles by providing a specific selection in the planning package. This is a simple and effective way of restricting data to users.
4. User-defined checks to ensure that the data validations are carried out. For example, negative values were not accepted as valid commitment numbers. We configured appropriate error or warning messages to be displayed in the application based on user action.
5. Audit trail of changes made to data. This is one of the key requirements across organizations to capture audit trail of changes made to data and when a specific action has been performed arising out of a business process step. In this application, changes to data were captured using status codes and process codes. The data was then copied over to a history cube to enable audit trail.

Figure 8

Controls for budget analysts

Sales Financial Analysts

We created roles in SAP NetWeaver BI for the sales financial analyst to enable access to the application and to review and approve the entries made by the budget analyst. We restricted access to the tab that allowed review of entries and approval of the accrual postings to ECC.

The configurable controls for the tasks of the sales financial analyst were similar to those of the budget analyst (Figure 9). In addition, the sales financial analyst had the responsibility to review the entries made by the budget analyst and then initiate accrual posting to ECC. We enabled this by building a custom retractor to post the accrual entries for expenses incurred but not paid.

We created the retractor to ECC by leveraging the SAP-delivered retractor available for posting back cost centers and internal order plan values from SAP NetWeaver BI to ECC. SAP does not deliver a retractor to post accounting entries from SAP NetWeaver BI to ECC. We copied over and modified the delivered retractor to pass the parameters necessary for G/L posting.

Figure 9

Controls for the sales finance analysts

We used a remote function call (RFC) to call the SAP-delivered BAPI BAPI_ACC_GL_POSTING_POST in ECC from SAP NetWeaver BI to post the accrual entries in ECC. We then leveraged the SAP-delivered controls for document principle management and the error tracking and message delivery mechanisms delivered with the BAPI. Figure 10 shows a snapshot of the result of the action performed by the sales finance analyst with respect to accrual posting made from the BPS application to ECC. These are inherent controls that SAP has already built and provided via configuration, through entities and relationships, or as technical objects that encapsulate business processes.

Configurable controls include the configuration you can make in ECC to enable the posting to specified accrual accounts and also distinguish and capture the accounting postings arising from SAP NetWeaver BI using a separate document type.

Figure 10

Snapshot of SAP accrual posting from BPS using retraction process