I’m working on a requirement where we need to control which withholding tax codes appear during invoice verification (MIRO) based on the purchase order category.
Currently, when processing invoices through MIRO, the system shows all withholding tax codes that are configured for the vendor master data. However, the business wants to limit these tax codes to only show the ones that are relevant for the specific PO category being processed.
For instance, let’s say we have a supplier where the system currently displays withholding tax codes 02, 05, 08, and 09 during MIRO processing. But for a particular PO category, we only want to show codes 02 and 05 in the withholding tax section.
I’ve attempted to use enhancement spots MRM_WT_SPLIT_UPDATE and MRM_HEADER_CHECK but haven’t been able to achieve the desired filtering functionality.
The goal is to hide the irrelevant tax lines and only present the applicable ones based on the purchase order type.
We’re running on S/4HANA system. Has anyone implemented similar functionality or knows the correct approach to achieve this filtering?
I dealt with this same issue about six months ago, but took a different route. Instead of messing with the withholding tax display, I used user exit MRM_WITHHOLDING_TAX_CHECK that fires when users pick tax codes. Built a config table that links material groups (from PO line items) to valid withholding tax types. What’s great about this is it doesn’t mess with standard MIRO display logic - just stops users from posting with wrong tax codes. Hit an invalid combo? System throws a custom error telling them which codes work for that PO category. Way more stable than screen mods and easier to maintain since business users can update the config table themselves. Downside? Users still see all tax codes upfront, but they get instant feedback if they pick the wrong ones.
Check transaction OBCD for withholding tax setup - there’s a doc category field that should work. We customized ours to link tax codes directly with PO categories in config instead of custom coding. Setup’s a bit tricky but runs smooth once you get it right. Skip the enhancement spots - they’re way too much and you’ll hate maintaining them later.
Just dealt with this three months ago. Here’s what worked for us: added a custom field in vendor master that links to PO categories, then used BTE 00001130 that fires during MIRO processing. We built a Z-table to map PO categories to valid withholding tax codes. The BTE grabs the PO category from the header, checks our config table, and strips out invalid tax codes before the screen loads. This approach rocks because it doesn’t mess with core SAP logic and fits right into standard MIRO flow. Business users can update mappings through SM30 without bugging developers. Performance is solid since we indexed the Z-table correctly. One gotcha - mixed PO categories in single invoices. We handle this by showing all valid codes when multiple categories exist in one document.
We had the same requirement last year and solved it with a custom BADI. You’re right - the standard enhancement spots don’t cut it for this kind of filtering. We used BADI MRM_WITHHOLDING_TAX since it gives you access to both PO data and withholding tax info during MIRO processing. Here’s what we did: created a custom table mapping PO categories to allowed withholding tax codes, then used the BADI to filter accordingly. The trick was modifying the internal table with the withholding tax codes before it hits the MIRO screen. We’d read the PO category from the invoice document, check it against our config table, and strip out the irrelevant tax codes. Just heads up - test this thing thoroughly because BADI errors will crash MIRO. We also had to handle edge cases where one invoice document had multiple PO categories.