Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
carla_bussolo
Advisor
Advisor


In my first blog post, I would like to introduce myself: I'm Carla Bussolo, nice to meet you! I have been working for SAP, in Product Support, since 2009. I always worked with the Invoice Verification topic, which made me an expert, and nowadays, I'm the Product Lead of the area.

 

Among other things I like in my work environment, I really like my workplace and I selected one nice picture to give you an idea of how it is:



 

Over the last years, after so many trainings, lots of customer interactions, and handling different scenarios, I developed extensive expertise in the S/4HANA Procurement Invoice Verification area - known simple as MM-IV (MM is for Materials Management and IV is for Invoice Verification).


For this post, I would like to share something that I have seen as very common in the IV area: performance issues while working with MIRO transaction.


 

Performance issues in MIRO are mainly caused by 3 factors:

1) Long PO History
2) 'Check for duplicate invoices' functionality active
3) MIRO selection


 

Let's explore each case and solutions.

 

1) Long PO History:


Purchase orders get old and, in some cases, will present a considerable history that includes different types of subsequent documents: goods receipt, invoice receipt, service entry sheets, down payment documents, delivery cost documents, etc.


 

Purchase order history documents are saved in 2 main tables: EKBE and EKBZ.


 

Once these tables present a considerable number of entries, each time you access MIRO and enter a document as a reference, the system will need to search for all the historic documents and this will seriously affect the performance.


How to find out how many entries I have in EKBE and EKBZ tables?


Go to SE17 transaction > enter the table name > fill EBELN with the document number > Execute


How to solve it?


It is necessary to aggregate the purchase order history using the ME87 transaction (RM06EKBE report).


With this action, the purchase order history is aggregated and older data is removed (this is reversible).


Details are described in the following SAP Notes:


311089 - Performance problems because of long PO history
574494 - Explosion the aggregated purchase order history via report
756292 - Consulting: Performance MIRO Enter invoice
756293 - ME87 Aggregation duration purchase order history


 

2) 'Check for duplicate invoices' functionality active:


If 'Check for duplicate invoices' is active for the Company Code and the Vendor, you may face performance issues while executing simple actions in MIRO, such as transitioning between Header tabs.


 

This happens because the affected tables are RBKP and BSIP, as the system needs to perform several searches in these tables.


You might be wondering now... what is this functionality and how can I see if this is active in my system? Easy! Check out this SAP Help link with all the details:


Check for Duplication of Invoice Entry


If you are facing a similar performance issue, use this hint to find out the affected table causing the poor performance:


1. Access ST12 transaction.
2. In 'Trace for' choose 'Current Mode'.
3. Enter a comment and enter MIRO in the Transaction field.
4. Then, choose 'Execute/start trace' button.
5. Now, it is just a matter of performing a test where users face the performance issue.
6. As soon as the test has finished, do not post the invoice. Choose the 'Back' button at the top of the MIRO screen, and do not post the invoice. You will be redirected to the ST12 screen with a message saying 'Trace finished'.
7. Wait a few minutes while the trace gets organized. Then, under 'Trace analyses' just click on the trace line and then choose the 'Performance traces' button.
8. In the trace details, an important hint: go to the menu 'Trace List' > and choose 'Summarize Trace by SQL Statement'. Now you will be able to see the table with higher impact on the performance.


Once you find the affected table, solutions for the performance are very simple! It is necessary to create new indexes.


If the affected table is RBKP, it is necessary to create a new index for this table.
SAP recommends that you create an index with the following fields in table RBKP:


LIFNR
BUKRS
XBLNR


 

For more details read: SAP Note 134660 - Logistics Invoice Verification: Performance (RBKP)


And, if the affected table is BSIP, it is necessary to create a new index for this table, with these fields:


MANDT
LIFNR
WAERS
BLDAT (*)
XBLNR (*)
WRBTR


For this index, read the details as SAP Note 389359 explains:


"Here, it is a non-unique index.


(*) You should include field 'BLDAT'into the index only when flag 'Check invoice date' (T169P-XBLDAT) has been set for ALL company codes in the Customizing under 'Check for duplicate invoices' .
(*) Similarly, it applies for field XBLNR: only include if 'Check reference' (T169P-XXBLNR) has always been set.


For the manual installation, make sure that you save and activate the index.


Since this index should be particularly adjusted to the given Customizing settings, it will not be delivered in an R/3 Support Package."


 

 

3) MIRO selection:


Let's say you have a user that needs to post an Invoice using as a reference just a Vendor number and Delivery Dates.
This is common, right?
The issue is that, if the Vendor number used as a reference has a considerable number of posted documents, even with the delimited Delivery Dates, you will encounter performance issues.


There are cases where the system will need to search entries with multiple account assignments. Therefore, one item line may have 20 multiple account assignment lines. And, if you have 560 item lines, imagine what system will need to search for! This will cause even more line item entries in the invoice, taking always time, as the system has to access a huge amount of data.


And, another point is that if there are unplanned delivery costs in your invoice to be distributed among different items, this can lead to slow performance as well.


Therefore, for cases like this, there is only one option: change the reference used.
In the PO reference tab, use a Purchase Order number, or another document as the reference.


If even using Purchase order numbers as reference lead to performance issues, split the invoice! Post more than one invoice using different references.


 

Let me advise you that it is very important to verify these 3 causes in your SAP system before any other step in the direction of the solution! I have already solved several performance cases just by checking these points in customer systems. So, ask for a little help from your Basis if you need some help and check these points :wink:


 

And, there are SAP Notes related to performance that you may check if it is applied to your system.


Follow some SAP Notes:


2065299 - MIRO/MIR7: Performance when entering an invoice document
2061442 - Getting TIME_OUT dump by using 'Show PO structure' button in MIR4
1926384 - MIRO: Runtime problem with bill of lading number
1796455 - MM-IV: Performance improvement
1783492 - Performance issue after upgrade to SAP ERP EHP5 during invoice creation
1755674 - MIRO: Performance issue with BAdI MRM_PARTNER_CHECK active
569086 - MIRO: Long response times for assignment


 

 



 

Hope you have enjoyed this post!

 

Regards,
Carla Bussolo

5 Comments