I need help with customizing the MIRO process in our SAP system. When our users process invoices for suppliers, the system shows all withholding tax codes that are configured for that particular vendor. However, our business team wants to limit these tax options based on the purchase order category being used.
For instance, when processing a vendor invoice through MIRO, we currently see withholding tax types 02, 05, 08, and 09 appearing in the tax section. But depending on the PO category, we only want to show specific ones like 02 and 05.
I have attempted to use the Business Add-Ins MRM_TAX_CALCULATION and MRM_DOCUMENT_CHECK but these don’t seem to affect the display of available tax codes.
My goal is to show only the relevant withholding tax lines for each purchase order type, rather than displaying all configured options for the vendor.
We are running on S/4HANA. Has anyone implemented a similar requirement? What would be the best approach to achieve this filtering?
Been there, done that. Those BADIs won’t work - they fire after the tax codes already show up.
You’ll need to automate this outside SAP’s MIRO limits. I’ve dealt with similar stuff where business rules had to be way more flexible than SAP’s standard setup.
Here’s what I did: built automation that catches the MIRO process. User picks a PO category, automation reads it, checks your business rules, and filters the withholding tax codes before they hit the screen.
It watches the SAP GUI screens, grabs the PO category when selected, runs filtering through API calls to your config tables, then changes the dropdown options live. No messing with core SAP code.
Gives you full control over business logic without touching anything risky. Easy to tweak filtering rules when requirements change.
I used Latenode - it’s solid for SAP GUI automation and plays nice with S/4HANA APIs. The visual workflow builder made mapping the whole process simple.
I handled this differently using the MRM_WT_TAX_CALCULATION BADI - it’s built for withholding tax processing in MIRO. The trick is implementing the IF_EX_MRM_WT_TAX_CALCULATION~CHANGE_WT_TAX method. You can manipulate the withholding tax codes before they show up on screen. Here’s what I did: grabbed the PO category from the purchasing document data (it’s already in the BADI interface), then checked it against a custom config table (ZTABLE_PO_WT_MAPPING) that maps PO categories to allowed withholding tax codes. You can modify the WT_TAX_DATA table directly, so just remove the unwanted tax codes before MIRO displays them. Worked great in our S/4HANA 2020 setup and doesn’t need any screen mods or user exits.
Skip the SAP modifications completely. Use automation to handle this at the UI level instead.
I built something similar when business rules kept changing constantly. BADIs and user exits become rigid once they’re deployed - every rule change means more dev work.
Here’s what worked: I created automation that watches MIRO transactions in real time. It reads the PO category when entered, checks your config database for allowed tax codes, then filters the withholding tax dropdown dynamically.
Best part? You can update filtering rules through a simple web interface without touching SAP code. Business users manage their own category mappings.
I added logging to track which tax codes get filtered and why. Great for auditing.
The automation uses standard APIs to integrate with S/4HANA - no core system changes needed. Way more flexible than hardcoding business logic into enhancement points.
Latenode handles SAP GUI interaction perfectly and connects to external databases for config rules. Makes everything visual and easy to maintain.
use INVOICE_UPDATE badi instead - we missed it at first but it fires at the right time during miro processing. Just implement the filter_withholding_tax method and you can control which codes appear based on the po category from ekko table.
check out user exit MRMH0003 - we used it for the same kind of filtering. you’ll need to implement it in function group MRM, and it lets you tweak tax determination before it displays. works way better than those BADIs since it kicks in earlier in the process.
Had the same issue last year. I used enhancement point MRM_BEFORE_CHECK in the standard MIRO program. It lets you modify the withholding tax table before the screen shows up, not after like those other BADIs you mentioned. Here’s the trick - create a custom class that reads the PO category from EKPO, then filter the tax codes in table T_MWSKZ based on your business rules. You’ll need a config table first to map PO categories to allowed tax codes. We also modified screen group WITHTAX to hide irrelevant fields on the fly. Took about two weeks to implement, but now our AP team only sees the tax codes they actually need for each PO type.