How to filter withholding tax entries based on Purchase Order type during MIRO processing?

[Oscar64]

I’m working on customizing our invoice verification process and need some help with a specific requirement.

When processing invoices through MIRO, the system automatically pulls all withholding tax codes that are configured for a particular vendor. However, my business users want to limit these tax entries based on the Purchase Order category being processed.

Here’s what currently happens:

• Vendor has multiple withholding tax types configured: EH codes 01, 04, 06, 07
• During invoice entry, all four tax codes appear in the withholding tax tab
• Business wants only specific codes (like 01 and 04) to show based on the PO category

I’ve attempted to implement this using enhancement spots MRM_WT_SPLIT_UPDATE and MRM_HEADER_CHECK, but these BAdIs don’t seem to affect the tax display logic.

The goal is to show only relevant withholding tax lines instead of displaying all vendor-level tax configurations. We’re running on S/4HANA system.

Has anyone successfully implemented similar filtering logic for withholding taxes during invoice processing? Any guidance on the correct enhancement points or configuration options would be greatly appreciated.

Thanks for any suggestions!

[emmad]

Hit the same issue during our S/4HANA rollout about 8 months back. You’ve got to catch the withholding tax determination way earlier than those BAdIs let you. What worked for us was custom logic in the MRM_WT_CODES_DETERMINE enhancement spot - it fires during initial tax code retrieval. We built a Z-table mapping purchasing doc categories to allowed withholding tax codes, then filter results before they hit MIRO. The tricky bit is handling internal table structures right - you need to modify the WT_CODES table that bounces between tax calculation routines. This keeps all standard SAP tax logic intact while just limiting your options. Heads up though - some PO types skip this enhancement completely, so you might need extra checks in user exit MRM00005 depending on your doc flow. Performance was fine for us with ~5000 invoices monthly.

[pixelPilot]

Been dealing with SAP customizations for years and honestly, the enhancement approach will eat up your development cycles. Every SAP update risks breaking those custom implementations.

I handle these filtering requirements outside SAP entirely. Set up automation that monitors your MIRO processing events and applies business rules in real time. You can intercept tax code selection before it hits the user interface and filter by PO categories.

Keeps all your business logic in one place instead of scattered across different enhancement spots. Plus you get better visibility - logs, error handling, everything.

Built something similar for a client who needed complex withholding tax rules based on vendor type, PO category, and seasonal factors. Instead of diving into SAP’s tax calculation maze, we created workflow automation that reads PO data, applies filtering rules, and pushes only relevant tax codes back to MIRO.

Way cleaner than debugging enhancement points and much easier to maintain. Check out Latenode for this kind of SAP integration work: https://latenode.com

[Hermione_Book]

The Problem:

You’re encountering issues filtering withholding tax codes in MIRO based on the Purchase Order (PO) category. The standard BADIs (MRM_WT_SPLIT_UPDATE and MRM_HEADER_CHECK) aren’t providing the necessary control over tax code display during invoice processing. You aim to show only relevant withholding tax lines based on the PO category, rather than displaying all vendor-level tax configurations in your S/4HANA system.

Understanding the “Why” (The Root Cause):

The standard BADIs you’ve tried are likely triggered after the initial withholding tax code determination. Therefore, modifying the tax codes within these BADIs won’t prevent the initially retrieved codes from being displayed. To achieve the desired filtering, you need to intercept the tax code determination process before these codes are populated in MIRO. This requires an enhancement point earlier in the withholding tax calculation process.

Step-by-Step Guide:

1. Enhancement Point MRM_WT_DETERMINE_SPLIT: This enhancement point within the CALCULATE_TAX_FROM_GROSSAMOUNT function module is the key. It controls the initial selection of withholding tax codes. Implement a custom routine within this enhancement spot.

2. Create a Custom Mapping Table: Create a custom Z-table (e.g., ZPO_CATEGORY_WT_CODES) with two fields:

   • PO_CATEGORY (character string, representing your PO category)
   • WT_CODE (character string, representing the allowed withholding tax codes for that category. Consider using a comma-separated string or a separate table for many-to-many relationships).

3. Implement Filtering Logic: In your custom routine within MRM_WT_DETERMINE_SPLIT, retrieve the PO_CATEGORY from the current PO document. Then, query your custom Z-table (ZPO_CATEGORY_WT_CODES) to find the allowed WT_CODE values for that category.

4. Filter the WT_CODES Internal Table: The enhancement provides an internal table WT_CODES. Filter this table, keeping only the entries where the WT_CODE is present in the list of allowed codes retrieved from your Z-table. Ensure you modify the WT_CODES internal table directly; otherwise, the filtering might be overridden later in the process.

5. Thorough Testing: Test thoroughly with different PO categories and various invoice types. The behavior of this enhancement can be impacted by the specific invoice flow and document type.

Common Pitfalls & What to Check Next:

• Internal Table Handling: Pay close attention to the structure and modification of the WT_CODES internal table within the MRM_WT_DETERMINE_SPLIT enhancement. Incorrect handling could lead to unexpected results.

• Data Consistency: Ensure your custom Z-table (ZPO_CATEGORY_WT_CODES) is up-to-date and accurately reflects your business requirements.

• PO Category Determination: Double-check how you obtain the PO_CATEGORY from the relevant PO document to avoid data discrepancies.

• Alternative Enhancement Points: If you encounter issues with MRM_WT_DETERMINE_SPLIT, explore the MRM00005 user exit as a potential alternative enhancement point for additional filtering logic, especially if the MRM_WT_DETERMINE_SPLIT enhancement does not cover all your document types.

• Debugging: Utilize SAP’s debugging tools to trace the execution flow and identify any issues with your filtering logic within the CALCULATE_TAX_FROM_GROSSAMOUNT function module.

Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!