We migrated our intercompany setup from ECC to S/4HANA 1809 last month and now master data synchronization between company codes is completely broken. The BD64 distribution model shows active but customer and vendor records aren’t syncing across our three legal entities.
I’m seeing RFC destination errors in SM58 and the partner profiles seem mismatched after the migration. When I check SALE transaction, the logical system assignments look correct but data simply won’t flow. Most concerning is that client-specific master data (custom fields for tax IDs and payment terms) appears corrupted during the transfer.
We have blocked intercompany transactions until this is resolved. Has anyone dealt with partner profile configuration issues post-migration? Need urgent guidance on troubleshooting the RFC layer and validating client-specific data integrity.
Check your RFC destinations in SM59 first. After S/4HANA migration, the technical settings often need reconfiguration. Verify the connection type is set to ‘3’ for ABAP connections and test the connection to each target system. The partner profiles in WE20 must match exactly with the logical system names defined in BD54. I’ve seen cases where the migration tool doesn’t preserve custom partner profile parameters.
SM58 errors usually indicate either authorization issues or port configuration problems in the RFC destination. Verify that the communication user in target systems has proper authorization objects (S_RFC, S_IDOCDEFT, S_ALE_ALL). The port definitions in WE21 need to match exactly with what’s configured in SM59. After migration, port assignments sometimes get reset to default values which breaks the message flow between systems.
I had similar RFC destination problems after our 1809 upgrade. Transaction SALE should show green status for all model views, but that’s not enough. You need to regenerate the partner profiles completely. Go to WE20, export your current configuration as backup, then delete and recreate the partner profiles for each logical system. This forces SAP to rebuild the internal routing tables with correct S/4HANA parameters. Also check SCC4 for client role settings.
Check if your filter objects in BD64 distribution model are correctly defined for client-specific fields. The migration might have preserved the model structure but lost the actual filter values. Go into each message type (DEBMAS for customers, CREMAS for vendors) and verify the filter groups include your custom tax ID and payment term fields. These need explicit inclusion in the segment filters or they won’t replicate even if the base master data does.
Your client-specific master data issue needs immediate attention. Run transaction SCC4 to verify client settings are production-enabled with proper logical system assignments. The custom fields for tax IDs and payment terms should be checked in table-level consistency using SE16N. Compare the field mappings in your distribution model filters (BD64) against what actually exists in the target clients. Migration often misses Z-field extensions in standard IDocs.
I’ll walk you through the complete resolution based on similar post-migration scenarios I’ve handled.
Partner Profile Mismatch Resolution:
First, address the partner profile inconsistency. In WE20, verify each partner profile’s outbound parameters match your logical system definitions from BD54. The critical issue after migration is that partner profiles retain old system IDs but point to new technical endpoints. For each partner, check the ‘Partner Type’ is set to ‘LS’ (Logical System) and the ‘Partner Function’ matches your intercompany setup. Delete and recreate profiles if modification dates predate your migration-this ensures S/4HANA-specific parameters are properly initialized.
RFC Destination Issues:
Your SM58 errors indicate RFC layer problems. Open SM59 and test each RFC destination with ‘Connection Test’ and ‘Authorization Test’. For intercompany ALE, you need RFC type ‘3’ with proper logon credentials. Critical settings: check ‘Load Balancing’ is disabled unless explicitly configured, verify ‘Target Host’ points to correct S/4HANA instances, and ensure ‘Logon & Security’ tab has a communication user with S_RFC and S_ALE_ALL authorization objects. After migration, gateway parameters (sapgwXX) often need manual correction in the ‘Technical Settings’ tab.
Client-Specific Master Data:
The corruption in custom fields stems from incomplete filter configuration. Execute BD64 and drill into your distribution model. For each message type (DEBMAS, CREMAS), edit the ‘Filter Objects’ and explicitly add your custom fields for tax IDs (likely in segment E1KNA1M or E1LFA1M) and payment terms. Use transaction WE19 to manually trigger a test IDoc for one customer record, then trace it in WE02/WE05 to see exactly where the custom field data drops off. This pinpoints whether it’s a filter issue or field mapping problem.
Validation Steps:
Run BD82 to check ALE consistency across all company codes
Execute RSALE_SYNC_LOGICAL_SYSTEMS to synchronize system definitions
Test with WE19 manual IDoc generation for one customer/vendor
Monitor WE02 for successful IDoc processing in target systems
Verify actual data in target using SE16N on KNA1/LFA1 tables
The combination of regenerated partner profiles, corrected RFC destinations, and explicit filter inclusion for custom fields should restore your intercompany synchronization. Allow 15-30 minutes for ALE buffers to refresh after configuration changes before retesting.