We’re experiencing failures with billing invoice IDocs (INVOIC02) when integrating with our external tax calculation system through PI/PO. The IDoc posts successfully in SAP but fails during PI/PO processing with segment mapping errors.
The error occurs specifically in the E1EDP01 segment where tax jurisdiction codes don’t map correctly to the external system’s format. Our output determination procedure triggers the IDoc, but the PI/PO interface configuration seems to reject certain field combinations.
Error from PI/PO monitoring:
Segment E1EDP01: Field MWSKZ value 'V1' invalid
Mapping error: Tax code conversion failed
Target system rejected payload at line 47
This is blocking invoice processing for international customers where tax calculations require the external system. Has anyone dealt with IDoc segment mapping issues in PI/PO interfaces for billing scenarios?
Your issue requires a three-pronged approach addressing IDoc segment mapping, PI/PO interface configuration, and output determination procedure alignment.
IDoc Segment Mapping Fix:
The E1EDP01 segment error indicates your tax code values need transformation. In PI/PO message mapping, create a value mapping table for MWSKZ field:
// Value mapping in PI/PO
V1 -> TAX_STD_RATE
V2 -> TAX_REDUCED_RATE
V0 -> TAX_EXEMPT
Implement this using a user-defined function with lookup to a custom value table.
PI/PO Interface Configuration:
In Integration Directory, modify your interface determination to include field validation before mapping. Add a Java mapping step that validates tax jurisdiction codes against allowed values. This prevents invalid data from reaching the external system.
Update your receiver agreement to handle missing or invalid tax codes gracefully - configure it to use a default tax code when conversion fails rather than throwing errors.
Output Determination Procedure:
In transaction V/06, review your output determination procedure for billing. Ensure the condition records don’t include tax codes that lack mapping definitions. Add a custom requirement routine (VOFM) that validates tax codes before IDoc creation:
IF sy-subrc = 0 AND tax_code NOT IN value_table.
MESSAGE 'Invalid tax code' TYPE 'E'.
ENDIF.
Additional Steps:
In WE20, verify partner profile has correct IDoc type and message type assignments
Check SM59 RFC destination configuration for connectivity to PI/PO
Review PI/PO monitoring (transaction SXMB_MONI) for detailed error stack traces
Implement error handling in your message mapping to log unmapped values to a custom table for analysis
Test with transaction WE19 using a sample INVOIC02 IDoc before processing live billing documents. This approach has resolved similar integration issues in multiple implementations.
This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
I’ve seen similar segment mapping issues. The problem is usually in the graphical mapping where the tax code structure differs between SAP and your external system. Check your value mapping table in PI/PO - the MWSKZ field might need a conversion rule for ‘V1’ to whatever format your tax system expects.
Tested this on S/4HANA 2021 with PI 7.5: creating the MWSKZ value mapping UDF in message mapping immediately resolved our E1EDP01 segment errors with the external tax engine.
Beyond the value mapping, verify your IDoc configuration in WE20 for partner profile settings. The output determination procedure might be sending fields that aren’t expected by the PI/PO interface. I’d recommend checking if the INVOIC02 variant you’re using includes all required segments for tax processing. Also look at the receiver determination in your Integration Directory - sometimes the interface configuration has strict validation that rejects non-standard values. Have you checked the audit log in PI/PO to see exactly which field is causing the rejection?
The E1EDP01 segment issue often relates to how condition types are mapped. Your tax code ‘V1’ needs proper conversion logic in the message mapping. I’d suggest creating a user-defined function in PI/PO that handles the tax code transformation based on country and tax type combinations.
This looks like a configuration mismatch between your output determination and the interface requirements. The output determination procedure in V/06 should be aligned with what PI/PO expects. Check if you have custom condition types in pricing that aren’t mapped in the PI/PO interface. Also verify the partner function assignments - sometimes the wrong partner type sends incorrect tax jurisdiction data. I’ve found that adding explicit field mappings for MWSKZ in the graphical mapping with default value handling helps. Consider implementing a validation step in PI/PO before the actual mapping to catch these mismatches early.