SAP Business Workflow in materials management processes

Creating master data

The first area in which the SAP Business Workflow technology (the workflow) can significantly improve the processes is the creation of master data. The best candidate is the process of master data maintenance for a material  in SAP. A material master record  is a central point from which default values are copied to documents and which controls the processes running in multiple SAP ECC’s modules, such as Sales & Distribution, Materials Management etc. The number of fields from individual business areas to be maintained is very large. Therefore their maintenance usually requires engaging a lot of people. Besides, material master records  are created quite often. Thus, the process is ideally suited for the implementation with workflow.

Most frequently, the process which is similar to a standard material master record  maintenance logic is implemented, consisting in a concurrent maintenance of the so called material master views. In this case, the workflow takes care of distributing the view maintenance tasks to appropriate  recipients, e.g. the Purchasing view is forwarded to a buyer, and other views to other people. The material master record is activated through an automatic status change only when all recipients finish maintaining the data for which they are responsible.

The added value of this solution is very high, despite its simplicity. We are guaranteed that the right people receive the view maintenance tasks immediately when the need be, which results in a rapid maintenance of all required data. This in turn leads to a smooth processing of a material  within the processes, because there will be no situations where the relevant data is not available, e.g. the entry of a material number to a purchase order item will never be stopped due to the unmaintained Purchasing view (after the material master record activation). To explain the solution’s logic, a specific example is described below.

Example 1. Creating material master views

Suppose that a raw material requires four views for proper functioning in the system: Master Data, Purchasing, General Plant Data/Storage, and Accounting. The workflow is started automatically when the Master Data view is saved by a process engineer. The workflow sends three tasks concurrently: the Purchasing view maintenance task to a buyer, the Accounting view maintenance task to a stock valuation specialist and the General Plant Data/Storage view maintenance task to a warehouse manager.

When all those persons finish with the maintenance of their views, the system notifies a process engineer via e-mail that the process is finished. At this point, thea material master record  is ready and can be productively used in the system.

Material master workflow vs. centralization of activities

A different type of material master  maintenance workflow results from a business requirement for centralizing the master data maintenance function, e.g. when a company implements the Shared Services Centre (SSC)  In this case, the workflow is used to transfer a new master data request from requesting persons, e.g. process engineers, to a person responsible for the master data in SSC.

In such a model, the workflow is an essential communication tool. An important element in this workflow variant is the way in which the above-mentioned master data request is implemented. Two options are possible: the request is either a new object in the SAP system or an external file, e.g. an Excel file. For one of its customers, BCC (now All for One Poland) implemented an advanced solution based on an Excel file. A new transaction in SAP, was created for uploading a request to the system and sending the request through the workflow. After its approval by SSC, the Excel file can be used to automatically generate a material master record  (without manual rewriting).

Usually, the creation of a material master record itself is not sufficient. It is often necessary to maintain a series of other material-related master data. A material master record  creation workflow can be expanded to include the creation of all the required data. For a finished product, for example, it is also necessary to create a bill of materials (BOM), routings, production versions, and a cost collector, as well as to execute a standard price calculation and its release.

All these tasks can be integrated in a single workflow. In this case, the sequence of activities is very important. For example, you cannot create a production version if BOM is not maintained. This is the criterion which qualifies such a process for the implementation with workflow.

Releasing the purchasing documents

Any types of document release-related processes are another area in which workflow proves to be excellent. As a rule, such processes are repetitive, require involvement of many people (a requesting person and many releasing persons) and always have a well defined release sequence. The Materials Management module contains standard, configurable functionality called release strategy designed to release purchasing documents, which can be integrated with workflow.

SAP ECC contains a ready-to-use workflow which can be run together with release strategies, but it is very meagre. In fact, the standard workflow enables you to merely make acceptances according to defined release steps. However, based on the standard workflow, this process can be greatly enhanced by a number of interesting features and functions, such as:

• Precise descriptions: the requesting person (first and last name), document number and type, total document value, the purchasing organization responsible and the purchasing group, etc.
• Control of the acceptance deadline which takes into account the working time, holidays and public holidays; for example, assuming the working time from 7 a.m. to 5 p.m., an 8-hour deadline for a release task which appears on Friday at 3 p.m. will expire on Monday at 1 p.m.
• Forwarding the release task automatically to a superior if a relevant accepting person does not execute his task within a defined deadline.
• Informing the requesting person of the decisions on an ongoing basis via e-mail.
• In the case of rejection, starting a simple editor allowing the accepting person to quickly inform (by e‑mail) the requesting person of his/her decision.
• In the case of rejection, allowing the requesting person to edit a document from the workflow inbox, resubmit the document for release together with a justification or to withdraw the document and cancel the workflow.

BCC has experience in the implementation of various improvements in a purchasing document release process, and the above-mentioned ones are only a subset of them. Practically, during each implementation, the described process undergoes a metamorphosis so as to meet diverse customer requirements (there are certain limitations due to the fact that behind the mechanism there is a standard configuration. Certainly, it is also possible to create a totally independent workflow, rarely practiced, though.)

Invoice verification

The workflow implementation (here understood in broad sense – not as an SAP workflow) brings the greatest benefits to companies in an invoice verification area. Therefore, the workflow in this area is lately a very desirable functionality and more and more organizations decide to implement such a solution. The advantages of having the electronic document flow in place are obvious: significant improvement of a process through its organization and structuring, fast archiving of physical documents, ability to immediately view an electronic copy of a document, etc.

The most common are two workflow implementation varieties for invoices (where the SAP system is the target accounting system):

• A workflow run by a dedicated, external tool; an invoice document ready for final posting is uploaded to SAP through an interface. There are many such external systems on the market that can be integrated with SAP. Because this article covers the SAP Business Workflow technology, this variety will not be further detailed.
• A workflow run within the SAP system by using the SAP Business Workflow and ArchiveLink technologies. This variety may be further divided with respect to the way the documents are entered into the SAP system: manually or by using an external scanning system (possibly with OCR – Optical Character Recognition).

An invoice verification workflow implemented in SAP usually consists of the following steps (here we assume the simplest variety where the document is entered manually):

• Entry of an electronic document to a repository (on the so called Content Server)
• Parking a system document
• Connecting a system document with an electronic copy from a repository – executed by the system
• Completing a document
• Releasing the document that meets certain criteria, e.g. amount limits (optionally)
• Posting a document
• Blocking a document for payment if there are differences in quantities and/or value
• Processing the differences in quantity and/or value, if any
• Releasing the document for payment, if it was blocked due to differences.

The first two steps may be merged into one – then a person entering an electronic document is also obligated to create a system document in a parking mode. A standard SAP functionality supports three invoice document statuses:

• Parked (possibility to enter only a header)
• Parked – complete
• Posted.

A correctly implemented workflow should use these standard statuses because this guarantees correctness and consistency of the process with a standard system. To better illustrate the workflow, a specific example is described below.

Example 2. Workflow for invoices

Invoices are received at a secretary’s office. A secretary scans a document and, having received an electronic copy on an operating system desktop, uploads it into SAP with a dedicated transaction – using drag and drop. The document in an electronic form is archived, a workflow is started in SAP, and a physical document is forwarded directly to the accounting department and does not circulate around the company.

The first participant of the process is a junior accountant/clerk or other appointed person who receives a task in SAP – he/she has to park the system document (based on the electronic copy which is shown on a screen in the second window), i.e. to enter at least a header, specifically the invoice date, total gross amount, invoice issuer, etc., and appoint a person to complete and verify the invoice.

The system document is connected with a copy from the repository automatically in the background while saving. The electronic copy is visible as an attachment to the system document. Then, the workflow sends a task to a person appointed as the completing person. This may be e.g. an IT manager (if the invoice concerns computer hardware). The IT manager enters items by entering references to a purchase order document and finds and corrects inconsistent items unless a junior accountant has done it earlier.

Of course, it is possible to display the invoice in an electronic form at any time. For example, if an IT manager finds out that he is not the owner of the invoice, he enters a different completing person and rejects the document. If he does not know who he should return it to, he simply rejects it without appointing the new completing person. In this case, the workflow returns to the junior accountant/clerk.

The completing person may also be authorized to change the account assignment data for a cost invoice (cost centre / CO order, etc.), if allowed. The end of completing the document is confirmed by saving it as complete. Finally, the invoice goes to an accountant responsible for posting invoices. He/She verifies the document and may either post the invoice or reject it and return it to the person completing the document in a previous step for further clearance.

At the time of posting, the system checks if the tolerances for value and quantity differences are exceeded. If so, the document is automatically blocked for payment. The workflow sends the task to the person responsible for clearing the differences. Quantity differences require additional GR document or a quantity adjustment request, whereas value differences require a change in purchase order or a value adjustment request. The person responsible for clearing the differences may be the same person who completes the system document, or a different person. After the differences are cleared, the invoice is released for payment.

The workflow is finished.

The presented example is of course for illustration purposes, but it gives some idea of how the invoice verification workflow may be implemented in SAP. While describing the invoice verification area, it is worth mentioning the off-the-shelf products that are available in the market. The example of such a product is the Vendor Invoice Management package by OpenText. Such solutions offer many interesting functions and integrate with a standard system very well.

Non-standard workflow capabilities

This article presents examples of non-standard workflow solutions in materials management. The material master record creation workflows in the master data management area are described. Obviously, this is not the only process that can be streamlined by using workflow – the creation of vendors or customers may be improved as well. The workflow also works well in releasing the purchasing documents, such as a purchase order or a purchase requisition. Although the standard system provides a predefined workflow for this purpose, it can be significantly improved by implementing the described functions.

The possibilities of implementing the workflow in the invoice verification area are also presented. In each area, the use of the SAP Business Workflow technology can bring significant benefits by streamlining the processes. Such processes are faster because they have a specific structure and the system takes care of their execution – it can easily track and monitor them by using the tools available in the system. Additionally, using the SAP Business Workflow technology does not require any additional licenses (it is available within the SAP ERP license – unless licensed third-party solutions are also implemented).