Hello All,

After talking to some customers and get 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 my favorite transaction – MIRO 😎 -, but until now, I never created documentation describing how to debug this interesting and very useful transaction in Materials Management area.

So, this post is special with debugging hints for those who works with invoice creation via MIRO.

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

A. What MM sends to FI?

B. What FI sends back to MM?

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

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

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

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

See the screen shot with the breakpoints:

MRM_INVOICE_POST_Breakpoints.jpg

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 doubts!

Some hints when you start your debug session:

  • When system stops at the first breakpoint, you will see everything what MM is sending to FI (this is the answer to question A 🙂 ).
  • And, if you hit F8, system stops in the next breakpoint, where you can see everything that FI changed in the MM information or/and what FI added to the MM information (this is the answer to question B 😉 ).

Sometimes I have to analyse 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 breakpoints mentioned and I simulate a new invoice via MIRO.

Once 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 hands, I go to the next breakpoint, when FI already processed the data and sent it back to MM. I access the same internal tables again and collect the same data.
  • Then, it is 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 in the data collected we already can see if FI or MM generated the specific line we are analyzing (now this is the answer to question C 😎 ).

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

Or, there are split lines generated at FI side, so, FI will return to MM several new lines.

And, there are cases that information will be kept as it was sent from MM 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.

Other common scenarios that I use these breakpoints are related to exchange or price differences.

Checking XACCIT-KTOSL (transaction key) I identify if it is an exchange rate difference (XACCIT-KTOSL = KDM) or a price difference (XACCIT-KTOSL = PRD).

If there is an exchange rate difference, 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.

Going beyond in function module MRM_INVOICE_POST in terms of exchange rate, we can check:

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

FORM_zeile_generieren.jpg

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

FORM_accit_kred_aufbauen.jpg

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

FORM_accit_kred_aufbauen_hw.jpg

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

Regards,

Carla

To report this post you need to login first.

7 Comments

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

  1. Pablo Casamayor

    Hi Carla,

    Those break-points, remind me of a younger me.

    The subroutines of exchange rates…thanks for that gift.

    There is always something interesting in your blogs

    Thanks for sharing,

    Best regards,

    Pablo

    (0) 

Leave a Reply