Simple SAP workflow

I’m writing this post after a long time and would really like to thank all my readers for their continues support to my work. On this post I would like to share some basic knowledge on Standard SAP workflow configuration for parked document release procedure. For simplicity I have broken down the configuration into the following steps.

Step 1 - Define organization structure for approval process

Use transaction PPOCE to define the organization structures and positions needed for Approval. The positions defined here would be assigned to the approval paths later. Users would be assigned to each position.


Step 2 – Create workflow variant

Use the menu path shown below to create a workflow variant



Make sure to activate the “Posting release” tick (This makes sure that each parked document should be released to be posted). The option “Release from” can be used to define a minimum amount from which the release procedure should be activated.


Step 3 – Assign the workflow variant to company code

Assign the variant created above, to the company code.



Step 4 – Create approval group

Approval groups can be assigned to customer or vendor master data. This will then be used to determine the approval path along with the document types.



Step 5 – Define approval paths

On this step, define the approval paths for approval procedure. Approval path along with workflow variant would determine the Approval steps, amount limits and the approvers.


Step 6 – Determine approval paths

As I said before the approval path would be determined based on accounting document types and the approval groups maintained on customer/vendor master data.



Step 7 – Assign release approval procedure

On this step we would determine the level of approval needed for the given workflow variant, approval path and amount combination. Depending on the approval level needed, we would assign the relevant sub workflow template.

For a one level approval, sub workflow template WS10000052 would be used. For a two level approval, template WS10000053 would be used. For three level approval, template WS10000054 would be used.


Step 8 – Assign approvers

On this step, the positions created on step 1 would be assigned to the appropriate approval paths.



Click on "Details (OrgObject) to assign the approvers


Finally link the workflow variant WS10000051 to the event FIPP – CREATED using transaction SWETYPV.


That’s it. You have configured the basic workflow for the accounting document approval procedure. Now every time a document is parked, a SAP message would be generated and sent to the appropriate approver

Approver can use transaction SBWP to view the messages and approve or reject items.



I hope this post would have given you a basic idea about SAP workflows. Would really appreciate your comments.

New address - www.thesapconsultant.com

Hi everyone,

Thank you very much for visiting my blog. I hope that I have been helpful in someway to you. And now I'm really happy to inform you that, from today you can visit my blog using the new URL www.thesapconsultant.com

Please keep on visiting my site for future updates. Thank you very much for your support and would really appreciate your feedback.

With best regards
Shathees Loganathan

Profit center balance sheet

On this post I would like to look at how the system has been designed to transfer balance sheet items to profit centers using the transactions 1KEH, 1KEI, 1KEJ, 1KEK. Often I have come across situations where the total balance of balance sheet accounts on a report painter report based on the library for GLPCT doesn’t match with the total of the line items on the called up report. This is not a Bug rather this is how the system has been designed.

When the trnasactions 1KEH, 1KEI, 1KEJ, or 1KEK being used, GLPCA table gets updated with the total balance of each object (Customer, Vendor, WIP, Material, F.Asset) for the given period. But GLPCT table update happens based on a delta technique.

Let me explain this logic using the following example.

Imagine that a customer has a constant balance of $200 in periods 1, 2, 3.

Transaction 1KEK for the period 1 would make an entry on GLPCT (Total) for $200 and another entry on GLPCA (Line item) for $200.

For the period 2, since the total balance of the customer for the given period would be updated on GLPCA table, Transaction 1KEK would update $200. But GLPCT will be updated using delta technique hence the value would be $0.

Same procedure would be followed for period 3.

When the user runs the profit center balance sheet for the periods 0-3, total amount based to GLPCT would show the correct amount $200 for the reconciliation account of the given customer. But when the user drills down and calls the standard profit center line item display report, it would show a wrong figure $600.

To correct this mismatch, user has to run the line item report only for period 3 rather than 0-3. A customer development of line item display report with the logic stated above and assignment to the report painter library for profit center reports would solve this issue.

Please feel free to send me your comments. Click on Archives to see my earlier posts.

SAP Business Transaction Events

I’m extremely sorry that I couldn’t write on my blog for some time because of the assignments that I had to finish for my clients! Today I got some free time and decided to talk about SAP business transaction events!

SAP business transaction events are one type of customer enhancements provided by SAP! On this post I’ll talk about how we can change the logic for duplicate vendor invoice check using SAP business transaction events!

We can access the business transaction events using FIBF

Next we have to find the process interface for duplicate invoice check! To do that, follow the following steps.

• Select the menu as stated below

• Execute the info system as stated below

• All the processes will be shown below

• Select the process 1110 and click on “Sample function module” as stated below

• Copy the sample functional module “SAMPLE_PROCESS_00001110” and create “ZSAMPLE_PROCESS_00001110”. Put the customized logic in the functional module “ZSAMPLE_PROCESS_00001110” and activate it!

• Now go back to FIBF and execute the menu as shown below

• Define a new product and activate it

• Now go back to FIBF and execute the menu as shown below

• Assign the function module “ZSAMPLE_PROCESS_00001110” to the process “1110”and the product that was defined in the earlier step.

• Bingo!!!!!! Now every time when a vendor invoice is being posted the invoice check will be carried out using the custom logic built into the function module “ZSAMPLE_PROCESS_00001110”. But make sure that the “double invoice check” tick has been put on the relevant vendor masters!
  

I hope this post about the SAP business transaction events will help your business! Thank you very much for reading my blog! Please feel free to send me your comments!

Allow the company to grow!

Hi guys! I’m really sorry that I couldn’t write anything on my blog during last 3 months. I was really busy with two simultaneous projects. Now one has gone live and the other one is going to cutover in MAY. So I thought I would start writing on my blog from this month again.

Thank you very much for all your comments.

This time I would like to give a small tip. In a business environment, all the companies will eventually grow. A well thought out ERP implementation will never give any problems when the company would like to expand its operations in the future.

For example, we all know that more than one company codes in SAP can be grouped under one controlling area for management accounting purposes. If a controlling area has the currency type company code currency, it’s not possible to have company codes with different local currencies under that controlling area. So if a new company with different local currency has to be added to the same controlling area in the future, it would be impossible.

So it’s always critical to look into future expected development of the company and give room for it when an ERP is being implemented. After all an ERP should never be a bottleneck for the company’s growth.

I wanted to share this with you since I had come across this issue with one of my new clients. I hope this tip would be useful to you.

Reports on SAP

As we all know, all software take the input from the user, process it and give the output. One of the forms on which the output can be given to the users is ‘Reports’. SAP provides a large number of standard reports that can be used during the day to day operations. Today I would like to introduce two important SAP Area menus that can be used to access most of the SAP standard reports.

1. SAP Easy Access Report Selection

SAP Area menu SAP1

2. SAP Easy Access Info Catalog

SAP Area menu SAP2

I hope the above SAP Area menus would help you to explore and utilize the standard reports provided by SAP. Please feel free to send me your comments.

The concept of Table buffers – For functional consultants – Part one

First of all I would like to thank all my SAP friends from all over the world for the emails that you sent me. As well as I would like to thank SAP business community team for the motivation that they have given to me. Thank you guys! I really appreciate it.

Today I’ll talk about the concept of table buffers on SAP. This topic is pretty interesting and gives certain implications on ABAP programming model. I think it’s really useful to the functional consultants to have certain amount of knowledge on this subject.

As we all know, a well developed ERP system should try to optimize its performance by using every possible way. Especially the response time it takes to process the requests from the business user should be minimize as much as possible. By taking this factor into consideration SAP has designed the concept called ‘Table buffer’.

This concept has been developed by considering two main factors.

1. The network traffic between the application server and the database server

As I explained on my earlier posts the SAP database server and the application server can be located on two different physical servers. So every time the application server requests some data from the database, it should be transferred through the network from the database server to the application server which may lead to high network traffic on a typical SAP installation where multiple requests will be passed per second. This factor would slow down the system.

2. The database load

When the programs processed by the application server, directly deal with the tables on the database to manage the data, it increases the database load which will slow down the database’s performance. This will affect a program which uses a specific table in the database as well as other programs which try to use some different tables in the same database.

Solution for the issue

The concept of table buffer simply load the data of a database table into the application server’s RAM. So the programs would access the data from the application server’s RAM rather than directly from the database table.
By buffering data, we increase performance in two important ways:

1.The programs using the buffered data run faster because they don't have to wait for it to come from the database. This reduces delays waiting for the database and the network that connects it.

2.The other programs that need to access the database run faster because there is less load on the database and less traffic on the network.
According to the benchmark tests, buffering a table can cause a select statement to run 10 to 100 times faster or more.

The next question that SAP had was, whether to allow all the tables to be buffered or not. Obviously we all would say ‘Yes’. However, buffers are stored entirely on RAM, so space is limited by the amount of RAM available. In fact, there is so much more data than there is RAM, that tables must be buffered with caution to prevent overruns. If a buffer overruns, it might swap to disk, which can eradicate any performance gained by buffering. So SAP has developed this concept in such a way that each individual table can be configured to be buffered or not. But the tables containing a numeric data type as the primary key cannot be buffered

Buffering can be activated through the technical settings of any table. The following screenshot shows table T001, which has been activated to be buffered.

How does this concept work?

When an ABAP program issues an open sql statement, the application server will first check whether the table has been activated to be buffered or not, if the table has been activated to be buffered, the server will check the RAM for the buffered data.

If the buffer is available, the program will read the data from the RAM else it will read it from the database, populate the buffer and subsequently read from the buffer.

I think this post should have given you a basic idea about the table buffers. Definitely this concept improves the performance of the system, but we have to take certain facts into consideration when we try to activate the table buffer on any table. On my next post I will talk about the implications of table buffers in a more detailed way. As well as I will take a look at the multi application server environment and the table buffers.

Please send me your comments.