I need help with customizing invoice verification functionality. When processing vendor invoices, the system shows all withholding tax codes configured for that vendor. However, I want to limit which tax codes appear based on the purchase order category being processed.
For instance, a vendor might have tax codes 02, 05, 08, and 09 configured. But when processing invoices for a particular PO category, I only want codes 02 and 05 to be visible in the tax selection area.
I attempted using enhancement spots INVOICE_TAX_FILTER and VENDOR_TAX_VALIDATION but they didn’t produce the desired results. The goal is to show only relevant tax codes instead of the complete list.
We’re working on an S/4HANA environment. Has anyone implemented similar filtering logic for withholding taxes during invoice processing?
we fixed this by modifying MM06EF0V_TAX_CODES_GET. override the standard code selection before it reaches the screen. check EKPO-PSTYP for PO category, then cross-reference your custom config table to see which tax codes to show. more direct than BADIs but you’ll need to test carefully during upgrades.
try looking into the user exit MM_INVOICE_WITHHOLDING_TAX. we did exactly that for filtering based on PO categories. just pull the relevant data from the EKPO table and it should do the trick. works like a charm in our S4 environment!
You’re trying to customize invoice verification in S/4HANA to show only relevant withholding tax codes based on the purchase order (PO) category. Existing enhancement spots like INVOICE_TAX_FILTER and VENDOR_TAX_VALIDATION haven’t worked. The goal is to filter the displayed tax codes dynamically based on the EKKO-PSTYP field (PO category) associated with the invoice.
Step-by-Step Guide:
Step 1: Implement BADI INVOICE_UPDATE
This BADI provides a suitable entry point to modify invoice data before it’s displayed. You’ll need to implement the CHANGE_INVOICE_DOCUMENT method. This method receives the invoice data as an input parameter. Crucially, it’s here that you can manipulate the tax codes before they’re presented to the user.
Create an Implementation: Create a new implementation of the INVOICE_UPDATE BADI. Give it a descriptive name (e.g., Z_FILTER_WITHHOLDING_TAX).
Implement CHANGE_INVOICE_DOCUMENT: Within this method, you’ll find an internal table representing the available withholding tax codes. This table likely has a structure like IT_WT_CODES. Modify the code to filter this table based on the PO category. This requires accessing the PO data linked to the invoice.
Access PO Category (EKKO-PSTYP): Use the invoice header data to get the related PO number. Then, read table EKKO using the PO number to fetch the PSTYP field (PO category).
Filter IT_WT_CODES: Implement your filtering logic. You will likely need a custom configuration table (e.g., Z_PO_CATEGORY_TAX_CODES) that maps PO categories (PSTYP) to allowed withholding tax codes. Use this mapping to restrict the contents of IT_WT_CODES to only the relevant codes. The code snippet below shows a basic example.
SELECT SINGLE pstyp
FROM ekko
INTO lv_pstyp
WHERE po_number = invoice_header-po_number.
SELECT *
FROM z_po_category_tax_codes
INTO CORRESPONDING FIELDS OF TABLE lt_allowed_codes
WHERE pstyp = lv_pstyp.
LOOP AT it_wt_codes INTO ls_wt_codes.
READ TABLE lt_allowed_codes INTO ls_allowed_code WITH KEY tax_code = ls_wt_codes-tax_code.
IF sy-subrc NE 0.
DELETE it_wt_codes WHERE tax_code = ls_wt_codes-tax_code.
ENDIF.
ENDLOOP.
Testing and Deployment: Thoroughly test your implementation in a development or quality assurance environment. Pay close attention to edge cases, such as invoices with multiple PO line items having different categories, or scenarios where no tax codes remain after filtering.
Create a custom table (Z_PO_CATEGORY_TAX_CODES) with the following fields:
PSTYP (PO Category): Character field, same data type as EKKO-PSTYP.
TAX_CODE: Character field, same data type as your withholding tax codes.
Populate this table with the mappings between PO categories and the allowed withholding tax codes for each category.
Common Pitfalls & What to Check Next:
Authorization: Ensure the user running this BADI has the necessary authorizations to modify invoice data.
Data Consistency: After implementing the BADI, verify that the IT_WT_CODES table correctly reflects your filtering logic in various scenarios.
Performance: For high invoice volumes, optimize the database queries and filtering logic for performance.
Multiple Line Items: Handle invoices with multiple line items having different PO categories carefully. Decide whether to show all possible tax codes or only the codes applicable to all line items.
Error Handling: Implement robust error handling to gracefully manage situations where no tax codes remain after filtering. Consider adding a warning message or fallback mechanism.
Upgrade Compatibility: Test thoroughly after any SAP system upgrades to ensure your custom BADI remains compatible.
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!
We solved this with a mix of config changes and custom code. Built a custom function module that kicks in during invoice processing instead of just tweaking the standard enhancement spots. The trick was catching the withholding tax code lookup at exactly the right time - when the system’s building those dropdown options. Our function reads the PO category from EKKO using the referenced purchase order, then runs it through filtering rules we stored in a custom table. Basically wraps around the standard tax code logic. Watch out for invoices that pull from multiple POs with different categories - you’ll need to decide if you want all possible codes or just the ones that work for everything. Performance can be a pain since this runs on every invoice line. Don’t forget proper error handling when your filtering leaves zero valid tax codes.
I did this exact thing using enhancement point MIRO_WITHHOLDING_TAX_CODES in MIRO. You need to catch the tax code population during invoice verification. Grab the PO category from EKKO-PSTYP by reading the PO number from the invoice, then build a custom table that maps PO categories to your allowed withholding tax codes. In your enhancement, just filter IT_WT_CODES based on your mapping before the dropdown loads. Don’t forget to handle multiple line items with different PO categories. Works great in our S/4HANA 2021 system and doesn’t mess with standard SAP stuff.
Step-by-Step Guide:
Common Pitfalls & What to Check Next:
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!