I’m working on a project in S/4HANA and I’ve got a tricky problem with withholding taxes in MIRO. Right now all the withholding taxes set up for a vendor show up during MIRO. But we need to show only the ones that match the specific Purchase Order type.
For instance if a vendor has EH taxes 01 04 06 and 07 we might want to display just 01 and 04 for a certain PO type. I’ve tried using the BAdIs MRM_WT_SPLIT_UPDATE and MRM_HEADER_CHECK but no luck so far.
Here’s what the current setup looks like:
PO Type | Tax Code | Description
--------|----------|------------
Type A | 01 | Income Tax
Type A | 04 | VAT
Type B | 06 | Sales Tax
Type B | 07 | Import Duty
We want to filter this so only the relevant taxes appear based on PO type. Any ideas on how to achieve this? I’m stumped and could really use some help. Thanks!
Having worked on similar S/4HANA projects, I can suggest exploring the BAdI MRM_INVOICE_CHECK. This BAdI offers a method called CHECK_INVOICE that’s executed during invoice verification. You could implement this BAdI to check the PO type and adjust the withholding tax options accordingly.
To use this approach, you’d need to create a custom implementation class for the BAdI. In your implementation, retrieve the PO type from the invoice data, then use it to filter the applicable withholding taxes. This method allows for dynamic adjustment without modifying standard SAP code.
Remember to thoroughly test your implementation across various scenarios. Also, document the changes clearly for future maintenance. If you’re not comfortable with ABAP development, consider engaging your IT department or an SAP consultant for assistance.
I’ve encountered a similar issue in my S/4HANA implementation. The solution we found was to use the BAdI MM_INVOICE_UPDATE, specifically the method CHANGE_INVOICE_BEFORE_SAVING. This BAdI allows you to modify invoice data before it’s saved, including withholding tax information.
In the implementation, we checked the PO type and then filtered the withholding taxes accordingly. It required some custom coding, but it worked well for our needs. You’ll need to create a custom class that implements the BAdI, then register it in the IMG.
Keep in mind that this approach might require thorough testing, especially if you have complex tax scenarios. Also, ensure you’ve got proper change management processes in place, as this modification can impact financial processes significantly.
If you’re still struggling, consider reaching out to SAP support or consulting with an experienced S/4HANA developer. They might have additional insights or alternative solutions.
hey pete, have u tried the MRM_INVOICE_VERIFY badi? it mite help with ur withholding tax problem. u can check PO type there and filter taxes. might need some coding but could work. jus an idea, lemme kno if it helps!
hey Pete, have u tried using the BAdI MRM_INVOICE_POST? It lets you modify invoice data before posting, including WT stuff. You could check the PO type there and filter taxes. Might need some custom coding but could work. jus a thought, hope it helps!
I’ve dealt with a similar challenge in my S/4HANA implementation. We ended up leveraging the user exit MRMH0002, which is specifically designed for withholding tax modifications in MIRO. This exit allows you to manipulate the withholding tax data before it’s displayed on the screen.
In our implementation, we wrote custom logic to check the PO type and filter the withholding taxes accordingly. It required some ABAP coding, but it gave us the flexibility we needed. We accessed the PO type from the EKKO table and used it to determine which tax codes should be displayed.
One thing to watch out for is performance. Depending on your data volume, you might need to optimize the code to ensure it doesn’t slow down the MIRO process. Also, make sure to thoroughly test all scenarios, especially with different vendor and PO type combinations.
If you’re not comfortable with ABAP coding, you might want to engage your SAP basis team or an external consultant. They can help implement and test the solution properly.