Hello All,
Recently, while preparing a presentation to partners, I had to define some points to share from the Invoice Verification area. I came up with totally different topics and shared the main ways we could analyze and understand them. As I believe these points could be valid for all of you, I decided to share them via a blog 😊
Stepping into the first topic, nothing better than debugging tips! Thinking about IV as a world, I mapped a general path for your debugging – save it, you will use it a lot!
For MIRO, MIRA, and MRBP transactions, the IV processing starts in the following function module:
For all the other processes, such as IDoc, BAPI, MR8M, MRRL, MRNB, and MRIS, the IV processing starts with the function module:
Then, for the preparation of the data, the IV processing goes thru the following function modules:
Well, many of the questions we receive in Product Support are related to valuation, currencies, and posting logic. Going in the same direction, here goes one more debugging tip 😊 A good point to start an analysis is to check a function module called MR_POSTING_GENERATE. This is the most important function module for debugging, as it shows how the system calculates the amounts for the following transactions:
WRX – GR/IR clearing
FR1 – freight clearing
PRD – price difference
KDM – exchange rate difference
BSX – inventory posting
KBS – account-assigned purchase order difference
Once the breakpoint hits this function module, you will see the system selects the sub-routine to perform the calculations based on the BUSTW – Posting String for Values:
Within these sub-routines, the required calculation logic is called depending on whether the document is a debit (invoice/subsequent debit) or a credit (credit memo/subsequent credit) posting:
As a clarification:
S = Soll = Debit
H = Haben = Credit
In this context, know that Procurement always determines the amounts in the transaction and local currency. If the material is active (which is always true for S/4HANA, read note 2332591) the amounts in the second and third local currency are determined by Procurement too. However, if the material ledger is not active (possible for ERP), the amounts in the second and third local currencies are determined by FI.
In Procurement, the exchange rate used for the second and third currencies is a combination of the transactions OB22 and OB08. Note the manual exchange rate – entered in MIRO – is not used for those currencies.
Want more debugging tips? Check out this blog post I created a few years ago: What about debugging MIRO? Let’s try it!
Another topic that we handle on a weekly basis in Product Support, generating always many questions, is message determination. And, for most of these cases, customers are trying to use this functionality to send outputs via EDI thru MIRO.
Via MIRO, the only allowed output types are:
REKL and REK6 (Complaints)
MLPP (Mail to Purchasing)
And, from these allowed types, the only output type that could be used with the EDI functionality is the REK6, as explained in note 2367797. If you need to use this type, you should copy the settings from the type ERS6, as it is in note 129643.
The output type REK6, as well as the REKL, is used if an invoice is reduced manually or automatically, as you can have the system send a letter of complaint to the vendor.
Moving away from classic topics, do you know why SAP recommends the usage of flexible workflows? It is because it is easier to configure without the need for many hours of consulting. This is the opposite of the classic standard workflow, which used to require heavy consulting work. Take a look at note 2617270 to understand the differences and benefits of flexible workflows compared to the classic standard ones.
And, talking about it, in the IV area we have two flexible workflows available: WS00800251 and WS00800303.
WS00800251 is for blocked invoices. The approval steps can be:
WS00800303 works for “parked and completed” invoices, and its approval steps are the same as the ones for the workflow WS00800251 and the following in addition:
And, in case of rejection in My Inbox, the “Rework Invoice” is possible.
Have you been facing workflow issues? I suggest reading note 2658950 - How to handle and analyse workflow errors for Manage Supplier Invoice app.
Going from debugging, passing thru valuation and message determination, and ending with workflow, I hope you enjoyed a bit of the IV world 🤩
Regards,
Carla Bussolo
Recently, while preparing a presentation to partners, I had to define some points to share from the Invoice Verification area. I came up with totally different topics and shared the main ways we could analyze and understand them. As I believe these points could be valid for all of you, I decided to share them via a blog 😊
Stepping into the first topic, nothing better than debugging tips! Thinking about IV as a world, I mapped a general path for your debugging – save it, you will use it a lot!
For MIRO, MIRA, and MRBP transactions, the IV processing starts in the following function module:
MRM_ASSIGNMENT
For all the other processes, such as IDoc, BAPI, MR8M, MRRL, MRNB, and MRIS, the IV processing starts with the function module:
MRM_INVOICE_CREATE
Then, for the preparation of the data, the IV processing goes thru the following function modules:
- Reading data:
- ME_READ_ITEM_INVOICE: used for PO reference tab, for material and service items
- ME_READ_COND_INVOICE: used for PO reference tab, for delivery costs items
- ME_READ_ITEM_INVOICE_FIR: used for the Contract reference tab
- Checking data: MRM_FINAL_CHECK
- Posting: MRM_INVOICE_POST
Well, many of the questions we receive in Product Support are related to valuation, currencies, and posting logic. Going in the same direction, here goes one more debugging tip 😊 A good point to start an analysis is to check a function module called MR_POSTING_GENERATE. This is the most important function module for debugging, as it shows how the system calculates the amounts for the following transactions:
WRX – GR/IR clearing
FR1 – freight clearing
PRD – price difference
KDM – exchange rate difference
BSX – inventory posting
KBS – account-assigned purchase order difference
Once the breakpoint hits this function module, you will see the system selects the sub-routine to perform the calculations based on the BUSTW – Posting String for Values:
Within these sub-routines, the required calculation logic is called depending on whether the document is a debit (invoice/subsequent debit) or a credit (credit memo/subsequent credit) posting:
As a clarification:
S = Soll = Debit
H = Haben = Credit
In this context, know that Procurement always determines the amounts in the transaction and local currency. If the material is active (which is always true for S/4HANA, read note 2332591) the amounts in the second and third local currency are determined by Procurement too. However, if the material ledger is not active (possible for ERP), the amounts in the second and third local currencies are determined by FI.
In Procurement, the exchange rate used for the second and third currencies is a combination of the transactions OB22 and OB08. Note the manual exchange rate – entered in MIRO – is not used for those currencies.
Want more debugging tips? Check out this blog post I created a few years ago: What about debugging MIRO? Let’s try it!
Another topic that we handle on a weekly basis in Product Support, generating always many questions, is message determination. And, for most of these cases, customers are trying to use this functionality to send outputs via EDI thru MIRO.
Via MIRO, the only allowed output types are:
REKL and REK6 (Complaints)
MLPP (Mail to Purchasing)
And, from these allowed types, the only output type that could be used with the EDI functionality is the REK6, as explained in note 2367797. If you need to use this type, you should copy the settings from the type ERS6, as it is in note 129643.
The output type REK6, as well as the REKL, is used if an invoice is reduced manually or automatically, as you can have the system send a letter of complaint to the vendor.
Moving away from classic topics, do you know why SAP recommends the usage of flexible workflows? It is because it is easier to configure without the need for many hours of consulting. This is the opposite of the classic standard workflow, which used to require heavy consulting work. Take a look at note 2617270 to understand the differences and benefits of flexible workflows compared to the classic standard ones.
And, talking about it, in the IV area we have two flexible workflows available: WS00800251 and WS00800303.
WS00800251 is for blocked invoices. The approval steps can be:
- Specific user (with My Inbox authorization)
- Agent Determination by BAdI
- Manager of Last Approver
- The person responsible for cost centers or WBS elements
WS00800303 works for “parked and completed” invoices, and its approval steps are the same as the ones for the workflow WS00800251 and the following in addition:
- Creator of the purchase order
- The person responsible for internal orders or profit centers
And, in case of rejection in My Inbox, the “Rework Invoice” is possible.
Have you been facing workflow issues? I suggest reading note 2658950 - How to handle and analyse workflow errors for Manage Supplier Invoice app.
Going from debugging, passing thru valuation and message determination, and ending with workflow, I hope you enjoyed a bit of the IV world 🤩
Regards,
Carla Bussolo
- SAP Managed Tags:
3 Comments
