What about debugging MIRO? Let's try it!

[carla_bussolo]

Hello All,

 

After talking to some customers and getting feedback about documentation, one of the points mentioned was the need for more information about debugging hints in the SAP transactions.

Thinking about this, I realized I'm always debugging :cool: -, but, until now, I never created documentation describing how to debug transactions in the Procurement area.

Therefore, this post is special with debugging hints for those who work with invoice creation using MIRO.

 

One of the main scenarios I usually debug is the integration between MM and FI, where common questions are:

A. What IV sends to FI?

B. What FI sends back to IV?

C. Is IV or FI responsible to generate a specific line in the subsequent FI document?

 

In order to know the answers to all of these questions, two important breakpoints should be set inside the function module MRM_INVOICE_POST:

1. The first breakpoint needs to be set in the call of function module CKMV_AC_DOCUMENT_CREATE.

2. The second breakpoint needs to be set right after the call of this same function.

See the screenshot with the breakpoints:

During MIRO execution, these breakpoints will be called when you choose Simulate button.

Basically, as the comment in the code says, when function module MRM_INVOICE_POST calls function module CKMV_AC_DOCUMENT_CREATE, this is the calling to the accounting interface.

 

ℹ TIP: Always read the comments in the code, it can clarify potential questions!

 

Some hints when you start your debug session:

• When the system stops at the first breakpoint, you will see everything that IV is sending to FI (this is the answer to question A :smile: ).
  
  
  
  • Just keep in mind that not all lines are calculated by IV at this point. For example, the tax lines (transaction key = VST) are calculated in a step before by FI, in the function module CALCULATE_TAX_DOCUMENT.
  
  
  
  


• If you hit F8, the system stops in the next breakpoint, where you can see everything that FI changed in the IV information and/or what FI added to the IV information (this is the answer to question B :wink: ).
  
  
  
  • In general, you will see here additional lines, such as the withholding tax lines (WIT) calculated by FI, or, modifications caused by FI substitutions. You can also see additional lines generated by CO.
  
  
  
  

 

Sometimes, I have to analyze why a FI document is posted with the wrong G/L account, or why a G/L account line is presenting wrong values.

For this, I set the mentioned breakpoints and I simulate a new invoice in MIRO.

Once the system stops in the first breakpoint:

• I open XACCIT: this internal table keeps the item information from the accounting interface.

From this table I collect the data from the following fields:

- POSNR = Accounting Document Line Item Number

- KTOSL = Transaction Key

- SAKNR = G/L Account Number

• Then, I open XACCCR: this internal table keeps the currency information from the accounting interface.

From this table I collect the data from the following fields:

- POSNR = Accounting Document Line Item Number

- CURTP = Currency type and valuation view

- WAERS = Currency Key

- WRBTR = Amount or tax amount in the currency of the currency types

- KURSF = Exchange rate

• With this data in my hands, I go to the next breakpoint, when FI already processed the data and sent it back to IV. I access the same internal tables again and collect the same data.


• Then, it is a matter of analyzing the data collected.

 

ℹ TIP: Keep in mind that the collected data after the second breakpoint is the one that will be posted in the FI document after the invoice posting.

 

At a first look at the data collected, we already can see if FI or IV generated the specific line we are analyzing (now this is the answer to question C :cool: ).

Sometimes, FI changes a G/L account number because there is a FI substitution involved.

Or, there are split lines generated on the FI side. Therefore, FI will return to IV with several new lines.

And, there are cases where information will be kept as it was sent from IV to FI, with no differences.

These breakpoints are also very useful during cancellations via MR8M transaction.

The logic is the same, and I use it to check posting differences between the original invoice posted and the current cancellation posting values.

 

Important: How to identify the MM lines?

• Analyzing the XACCIT data, the MM lines are the ones where the column BELNR is filled with the Purchase Order number


• The most common lines calculated by MM are:
  
  
  
  • WRX - GR/IR account
  
  
  • BSX - stock posting
  
  
  • PRD - price differences
  
  
  • KDM - exchange rate differences
  
  
  • KBS - account assignment
  
  
  
  

 

Other common scenarios I see are related to exchange, price, or stock differences.

Checking XACCIT-KTOSL (transaction key), I identify if it is an exchange rate difference if XACCIT-KTOSL = KDM, a price difference if XACCIT-KTOSL = PRD, or a stock difference if XACCIT-KTOSL = BSX. Please, don't rely on the G/L account number or its description! The correct way to identify a line in a FI document is always checking the transaction key!

Since all of these values (KDM, PRD, BSX) are calculated by MM, you should set a breakpoint in the function module MR_POSTING_GENERATE to see the logic that calculates each value.

 

When different currencies are involved, and translations are required, the next step is to check XACCCR-KURSF (exchange rate) values, to see what is the exchange rate used and then identify from where this is coming.

In the function module MRM_INVOICE_POST in terms of exchange rate, we can check:

- PERFORM zeile_generieren: it calculates items values in local currency. If the material ledger is active for the plant, this form calculates also items values in the second local currency:

- PERFORM accit_kred_aufbauen: this form calculates the value of the vendor line in local currency:

- PERFORM accit_kred_aufbauen_hw: this form calculates the value of the vendor line in local currency. And, if the material ledger is active, this form also calculates the value of the vendor line in the second local currency:

 

ℹ TIP:

MM always calculates values in local currency, and then, translates them to document currency. Second, third, and other parallel currencies are calculated as follows:

• If the material ledger is active: MM also calculates it


• If the material ledger is not active: FI calculates it

 

Hope these debugging hints help you to better perform your invoice posting analysis, whenever you need it :smile:

 

Regards,

Carla Bussolo