During a purchasing document creation or a goods movement posting, you may can face some performance issue like any kind of short dump or it may can take long time to execute a transaction. Generally, a performance issue can occur because of a huge data. Sometime system can’t able to read information from table and execute a dump message. That’s because may company prefer the archiving process after some time (even some year). There can be many more different reasons when a performance issue occurs. Normally a performance issue can be resolve by archiving process, but many of cases, you need to do some program correction with the help of some OSS note(s). You can also improve performance by creating index with correspond table. Such as, you have performance issue regarding the table EBAN, then create a database index from transaction SE11 on table EBAN as per your requirement, then save and activate the index, then run your transaction, you can see the performance improvement.

In general, when you create a purchasing document, system checks many function which may not need for you but to avoid any kind of inconsistent, system will check and generate all information into all related tables. Some functions are most important which should be executed when you create a purchasing document like as Price determination, create or update purchase info records, release procedure, partner determination, text determination etc etc. This information should be executed when you will create a purchasing document according to your requirement and IMG configuration. If you read the OSS note 188837 – Purchase order generation performance , you can find how many functions are executed during a purchase order creation. This OSS note has given the information how you can optimize or control these all functions during creation of purchase order. However, it could not be possible to delete some functions which are required as per your business process. Read the OSS note and deactivate the listed functions as per your requirement and be sure that you do not need this function to be executed during purchase order creation. Please read this KBA document 1942976 – Performance issue when using transactions ME21N, ME22N, ME23N , here you can find some more options to avoid the performance issue during purchase order transactions. System can perform a slow performance while creating a account assigned document or even a service document (like service purchase order, service contract, service requisition etc.). It is because of the extra table EKKN, system need to reread the table EKKN for account assignment document, that’s because system can take long time to read data from table.

During a goods movement (like as goods receipt, goods issue, transfer posting), system can take long time to execute. For a general performance issue (or even a runtime error) during goods receipt, use the OSS note 1738158 – Long runtime for goods receipt for purchase order. There can be different different reason as per the transaction. Like when you will post a goods receipt, system can take long time due to the purchase order or schedule agreement’s line item, while you post a goods receipt for many item for purchase order or many purchase order into one goods receipt. System will take long time to fetch data from various purchasing tables (like EKPO, EKKN). You can improve the performance by splitting this into multiple. Slow performance can occur when you will use the price determination process during goods receipt. System will try to fetch many records from various tables for the price determination process during goods receipt. Another reason for slow performance during goods receipt of purchase order or goods issue for a stock transport order is unnecessary copy data for group condition (from GKOMV to TKOMV). Transaction code ST12 has been developed by SAP to trace the performance issue and any kind of ABAP dump.

Let me explain some issues with details explanation (with view from OSS notes), why a performance issue occurs during various purchasing transaction execution or goods movement and how you can improve performance while executing a transaction.

When you set a deletion flag or archiving process for purchasing document, you may face performance issue. The performance issue may can raise at the time accessing table EKKN or EBAN (according to document). The OSS note  1411343 – Setting the deletion flag: Performance problems says there could be performance issue occurs after implementing the OSS note 418988, and if there are no reference of purchasing document, system will try to access all records from table EKKN or EKBN. However, this OSS note 1411343 has given a modification to avoid the same. Read the OSS note accordingly, additionally read the OSS note 673290 – Setting the deletion flag: Performance problems also.

A large number purchase item or purchase order history item can also causes of performance issue. When you call a transaction (like ME2* reports, transaction MIGO, MB01, MIRO, MIR7, MRRL etc) which is fetching data from purchase order item (EKKO) or purchase order history item (EKBE), system can return you a dump message or can take a long time during execution of these t-codes. To improve performance you can use the aggregation facility for purchase order history by using the transaction ME87, which can remove (reversibly) old data from your purchase order history. Read the OSS note for more details 311089 – Performance problems because of long PO history and 574494 – Explosion the aggregated purchase order history via report . However, there are some cautions for the aggregation feature. The caution can be found on the OSS note 311089. This aggregation can remove your purchase order history which are old more than two months (however it is possible to change the period according to the OSS note  756293 – ME87 Aggregation duration purchase order history).

During creation of purchase order from transaction ME57, you may can face performance issue. System read the table EBAN, to fetch information during execution of the transaction ME57. Because of a huge data on EBAN table, system can take long time (or even fail to execute with dump) to create a purchase order. The solution is provided in this KBA  2108907, that you should archive the all old requisition along with give some selection parameter in ME57. Read the KBA document for more information.

You have some issue regarding purchase requisition creation, some performance issue can occur after implement the OSS note 1836886. SAP has given another OSS note to improve the performance after implemented the OSS note. You can find more information in this OSS note 1910134 – Performance Improvement in Purchase Requisition (note: this OSS note is only relevant for Brazil localization).

Some performance issue can occur when you will go for release a purchase requisition from transaction code ME54N, SAP has given an OSS note for a program correction 1377556 – Performance issue during release of PR-ME54N

When you will go for purchase requisition list from ME5A, system can take long time to execute or even can fail to show result. Performance issue can occur also after giving some selection field(s). As per the report logic, system is fetching data from EBAN, during the data fetching, system can take long time to execute. You can implement OSS note 942106 – Performance of ME5A: List display of purchase requisitions to improve the performance. Also by indexing the table EBAN, you can reduce the performance issue, read the KBA document for performance issue during ME5A transaction 2111467 – Performance issues in ME5A

At the time of mass maintenance of purchase requisition from transaction code MEMASSRQ, you can have some performance issue. Its because of as per the logic of mass maintenance, system will call the record twice for a document while it should be called only once per document, this can causes of the performance issue. You can implement the OSS note 1448621 – Performance problems when changing PReqs (transaction MASS) to avoid the performance issue during the mass maintenance transaction.

You may can face some performance issue at the time of converting purchase order from a service purchase requisition. There is an OSS note 1658177 – Performance: Creation of purchase orders , by implementing the OSS note, you can reduce the performance issue.

At the time of using BAPI for purchase order create or change, you can face some performance issue. The reason of this performance issue can be long text. As per the OSS note 917290 – Performance: Long texts in EnjoySAP order BAPI , system can take long time to process the text during execution of BAPI. Read the OSS note for more details and implement the correction to avoid the performance issue. Also please have a look into the OSS note 1355577 – BAPI_PO_CREATE1: Runtime problems when calling RTTS, it also explains about the performance issue regarding the bapi BAPI_PO_CREATE1 or BAPI_PO_CHANGE

There can be poor performance during creating or changing a contract or a schedule agreement via BAPI. With release 600, 602 and 603, SAP has found program error which can causes of the poor performance. By implementing the OSS note 1475971 – BAPI: Performance for contract and scheduling agreements , you can improve the performance for this selected EHP release. Not only performance issue, you can read the OSS note for some additional issue during calling BAPI_CONTRACT_CHANGE and BAPI_SAG_CHANGE.

System can take huge memory during running BAPI_PR_CREATE or BAPI_PR_CHANGE, this can cause of slow performance. This performance can occur for a program coding. You can use this OSS note 1571867 – Performance issue when executing Purchase Requisition BAPI , here a program correction suggested by SAP.

For a higher release (from 605), you can face performance issue during creating a request for quotation from ME41 with multiple items as text item. The causes of the slow performance can be the multiple item for one RFQ document. Either you should divide the RFQ document to multiple or you can try by applying the OSS note 2086200 – ME41: Performance optimization when using item texts to improve the performance while perform multiple line item in one document. Another reason system can take long time to execute the transaction, it is time dependent condition (specially the case of batch input). When you will use time dependent condition for many items in one document, system can take some time to find and execute the supplementary conditions with regards to the time dependent condition.

You may can face a performance issue during goods receipt against outbound delivery for a inter company stock transport order. This slow performance can occur because of a lots of line item in the purchase order (EKPO entry) or a lots of purchase order history line item (EKBE entry). You can implement this OSS note 1328939 – Performance issue when posting Goods Receipt against STO , it includes a program change, which can improve the performance during goods receipt.

Some performance issue can occur after activate SAP HANA during goods receipt from MIGO. It is for enhancement package 6.04 along with the business function LOG_MM_OM_1. In that case, use the OSS note 1729650 – HANA Performance issue when creating Goods Receipt for a program correction.

During posting or reversing a goods receipt with regards to a production order, you may can face some performance issue. This performance issue can occurs due to the volume of large order history, instead of fetching the single order history, system is trying to fetch the total record. To improve the performance issue SAP has given a feature to fetch the data record as summarized. You need to add an entry in the table CKMLMVADMIN as ‘CKMO_READ_MLAUF = S’. A details explanation can be found in this OSS note 1759860 – Incorrect GR reversal for production orders and performance improvement , along with consider this OSS note 1611053 – Performance: Production Order history compression for a manual steps details for production order history compression.

For any goods movement from MIGO, system can perform slow performance. This slow performance can be occurred due to a number of storage locations are assigned to the plant. During the determination of storage location with regards to the transaction, system is copying the number of storage location into an internal table from table T001L and then reads all data from that internal table. After implement the OSS note 1016033 – MIGO: Performance improvement when reading table T001L system has changed the logic not to use the internal table, system will fetch the data directly from table T001L table. This can improve performance during goods movement in MIGO.

During posting a goods receipt from MIGO with regards to a purchase order with multiple account assignment, system can occur slow performance. The main reason of this performance issue is huge data of purchase order history item. Along with at the time of goods receipt for a multiple account assigned PO, system will run the source code of the business function LOG_MM_MAA_1 although this business function is not active. Use this OSS note 1605930 – MAA: MIGO: Poor performance as a source code correction.

At last, there can be some performance issue due to your own custom development / enhancement. Due to poor coding from an ABAPer, you system can issue short dump or even take a long time to execute the function. In that case, you need to consult with your abaper to improve the quality of coding. By using a Badi or user exit, system can take long time to execute the function.

In above, I have given some example of OSS notes with brief explanation about the performance issue. There are many more OSS notes are given in service market place for any kind of performance issue. Most of all performance issues will get improved by implementing correspond OSS note. So, whenever you will face any kind of performance issue, first search in service market place for some OSS notes.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. Dibyendu Patra Post author

      From last month, I was thinking to write a blog post regarding performance issue. So, I started to collect these all OSS notes and SCN contents regarding performance issue and then read them from last three weeks. Then finally, I tried to explain this from the view of various OSS notes in this blog post.

  1. Somnath Manna

    Maybe Simple Logistics will actually alleviate some of these performance issues. Time will tell but I am hoping for the same considering how FICO data model (new ACDOCA table) is adjusted in Simple Finance.




Leave a Reply