Mix costing on SAP

On this post I would like to have a look at the mix costing functionality offered by SAP. This functionality could be used to calculate the average standard cost for a material that is procured/produced using multiple sources. Lets look at it step by step.

Step 1 – Define Quantity Structure (Configuration)

Define a quantity structure type as stated below.

Menu path on SPRO - Controlling → Product Cost Controlling → Product Cost Planning → Selected Functions in Material Costing → Define Quantity Structure Types

Step 2 - Define Costing Versions (Configuration)

Assign the quantity structure type to the costing version.

Menu path on SPRO - Controlling → Product Cost Controlling → Product Cost Planning → Selected Functions in Material Costing → Define Costing Versions

Step 3 - Maintain Procurement Alternatives for the material (Master data)

Maintain the procurement alternatives for the selected material using the transaction code CK91N. These would later be used to maintain the mixing ratios.

Step 4 – Maintain the mixing ratio for the selected material (Master data)

Maintain the mixing ratio for the material using the transaction code CK94.

Step 5 – Execute the costing run

Execute the costing run using either CK11N or CK40N. Now the costing run would calculate the standard cost based on mix ratio.

Hope this post helps you guys. Please don't hesitate to drop your comments.

Dual control on GL postings

On this post I would like to share a simple solution that would enable the companies to implement dual control on journal postings. In other words this solution would make sure that two users are involved on each journal posting where one person parks the document and another one posts it. Unlike the traditional authorization based solutions, none of the users are restricted at the transaction code level. This is how the solution works.

1. First user parks the document using FB50. If the user attempts to post, system throws an error message.
2. Second user posts the document using FBV0. If the second user attempts to post his own-parked document, system throws an error message.

Now lets see how this solution is implemented.

Step 1

Create a validation rule at complete document level with userexit.

Step 2

Implement the following logic in the validation userexit.

FORM us007 USING b_result.

* Enhancement by Shathees Loganathan.

select single * from VBKPF where BELNR = BKPF-BELNR and BUKRS= BKPF-BUKRS and BSTAT = 'V'.

if sy-subrc = 0.

if VBKPF-USNAM = SYST-UNAME.

Message e019(ZLF01).

b_result = B_FALSE.

endif.

else.

Message e018(ZLF01).

b_result = B_FALSE.

endif.

ENDFORM.

Now lets see how would this affect the journal entries.

Step 1

First user parks the document using FB50. If the user tries to post the document, the following error message is shown.

First user parks the document.

Second user posts the document using FBV0. If the second user tries to post a document parked by him, the following message is shown.

If the second user posts a document parked by another user, system allows the document to be posted.

This solution could be further enhanced. For example we could allow certain managers to post the document directly through an exception process or we can implement this dual control to certain GL accounts or document types.

Hope this is useful. See you all next time.

Dispute management (Chargeback)

Today I’m going to talk about the dispute management module delivered by SAP under financial supply chain management solution. Typically when the dispute management module is not implemented, users would store key information related to disputes or chargeback on the accounting document line item text on the residual items (Or some where on the accounting document).

When the dispute management module is implemented, one of the key requirements would be to copy this information to the Notes on dispute cases. Using the following solution, this can be easily implemented.

Step 1

Implement the BADI ZFDM_AR_DEF_NOTE.

Step 2

Implement the code shown below in the method GET_DEFAULT_NOTE

Data : wa_note type TLINE,

wa_bseg type bseg.

select single * from bseg into wa_bseg where belnr = I_DISPUTE_DATA-BELNR_AKT and GJAHR = I_DISPUTE_DATA-GJAHR_AKT

and BUZEI = I_DISPUTE_DATA-BUZEI_AKT.

if sy-subrc = 0.

append initial line to c_note.

loop at c_note into wa_note.

wa_note-TDLINE = wa_bseg-SGTXT.

MODIFY c_note INDEX sy-tabix FROM wa_note

TRANSPORTING TDLINE.

endloop.

endif.

endmethod.

Now when the disputes are created using the transaction code FDM_AUTO_CREATE, Line items text would automatically be added to the dispute notes.

Hope this helps. See you next time.

Payment approval on F110

Today I’m going to talk about a solution that I have implemented for one of my clients. The requirement was to implement an approval process for the vendor payments. Basically my client wanted to review and approve the out going payments generated by SAP automatic payment program. For simplicity I have broken down the steps below.

Step 1

Implement the business transaction event 1120. Please refer to my post related to BTE for detailed information.

Step 2

Within the function module that have been created for BTE 1120, Implement the following logic.

As you can see from the above screen print, I have extracted the payment ID and the date from the accounting document header text.

I have created a custom tableZPAAPPROVAL to facilitate a simple approval process. But this can be enhanced based on the approval requirements.

Now lets see how this solution works. When a payment run is executed, system allows the payment proposal to be created but throws an error message when the user tries to execute the payment run.

Manager can approve the payment using the approval logic implemented. In my case, manager approves it using the table ZPAAPPROVAL. Once the approval is obtained, system allows the payment to be made.

I hope this post is useful to you. Please feel free to leave your comments.

SAP’s SME Solutions – A Guide to the Product Portfolio

Dear readers,

I have come across an interesting post regarding various products offered by SAP to cater to various market needs. I thought it would be pretty informative to a potential decision maker.

SAP's SME Solutions - A Guide to the Product Portfolio

Hope the above would be useful to any potential SAP buyer.

See you next time.

Queries

Hi Friends

Would really appreciate if you can post your queries on the forum rather than the comment section of this blog. This will allow other users also to give their input. And I will try to respond to all the queries as soon as possible.

Once again, Thank you very much for all your support.

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.

The concept of Data dictionary on SAP – For functional consultants

You should have heard about the word ‘Data dictionary’ on SAP. Today I thought I would explain the basic concept of data dictionary to the readers. As you know ERP software such as SAP heavily depend on database management systems. Frankly speaking an ERP system works as a front end to the database. Where we capture the data and store it in the database tables, and then we use the captured data to arrive at various business conclusions with the help of the programs provided by the ERP.

Most ERP systems store the configuration, transaction and master data in the database. But SAP has gone one step further and even stores the Program source codes in the database. It’s called SAP Repository. I’ll explain how the programs are being executed by the ABAP processor of the work processes, on a later post.

So as you can see, SAP has to deal with database heavily. As well as SAP has to allow the customer to enhance it’s capabilities, according to the business requirements, which may be done by modifying or creating various database objects such as tables, views and indexes. If SAP allows the customer to directly deal with the underlying database, it may lead to unnecessary problems and even lead the system to an unstable position. As well as it will not be possible to track the changes done to the database.

By taking all those into consideration, SAP has developed its software with a concept of ‘Data dictionary’. You can imagine the data dictionary as a mirror image of the actual database objects, which is part of the SAP itself, where the structures of the database objects such as tables have been replicated. For example every table in the actual database would have a corresponding table structure in the Data dictionary. ABAP programs will deal with the data dictionary objects which intern will connect to the actual database objects. For example if you check the table T000, which stores the client information.

The data dictionary object will look like the image shown below.

The details of same table on the actual database are shown below.

In addition, Data dictionary works like a remote control to the actual database. Developers create the database objects on the data dictionary and activate them; in the background the system will automatically generate the corresponding SQL statements and create the objects on the actual database.

As a strict rule the developers would never create or modify database objects such as tables directly on the actual database, in case if some one has created or modified a database object directly on the database, there is no way that the data dictionary could synchronize with the database object, which will lead to unnecessary problems and may affect the system performance and stability.

We can create objects such as Tables, Structures, Views, Data domains and Data elements on data dictionary. As well as SAP provides various tools to check the consistency between the database and data dictionary objects. I will look at each of those in detail on my future posts.

Please feel free to send me your comments.