Order-to-cash IDoc integration fails in cloud due to missing partner profile configuration

ERP SAP S/4HANA
, , , , , , , ,
1

Our outbound IDocs for order-to-cash processes are failing to send from S/4HANA Cloud 1809 to our external billing system. The orders are created successfully in the system, but the IDoc transmission never triggers.

Checking WE02, I see the IDocs stuck in status 30 (ready for dispatch) with this error:


Partner profile not found for message type ORDERS05
Partner Number: BILL_SYS_01
Partner Type: LS (Logical System)
Message Type: ORDERS05

I’ve verified in WE20 that the partner profile exists for BILL_SYS_01, and the message type ORDERS05 is configured with the correct port. The logical system assignment looks correct in SALE, but something isn’t connecting properly. In our on-premise environment, this same configuration worked flawlessly.

The failure is blocking approximately 50 orders daily from reaching our billing system, causing significant order processing delays. Is there a cloud-specific configuration step for partner profiles that differs from on-premise setups?

2

I’ve resolved this exact issue multiple times in cloud migrations. The error message is somewhat misleading - the partner profile exists, but the system can’t find it because of how cloud handles logical system resolution. Here’s the comprehensive solution:

1. Logical System Assignment Validation: The cloud environment requires explicit logical system assignments at multiple levels. First, verify your own logical system:


Transaction: SALE -> Basic Settings -> Logical Systems
Define Logical System: Assign name and description
Assign Logical System to Client: Link to your client number

Then ensure BILL_SYS_01 is defined as a separate logical system entry, not just referenced in the partner profile.

2. Partner Profile Configuration (WE20): The cloud version is stricter about partner profile hierarchy. You must configure:

  • Partner type: LS (Logical System)
  • Partner number: BILL_SYS_01 (must exactly match the logical system name)
  • Under Outbound Parameters:
    • Message type: ORDERS (not ORDERS05 - that’s the extension)
    • Process code: ME10
    • Output mode: Transfer IDoc Immediately (option 2)
    • Basic type: ORDERS05 (specify the actual IDoc type here)

A critical cloud-specific requirement: The “Partner Role” field must be populated. Set it to “LS” explicitly - leaving it blank causes the profile lookup to fail even though the profile appears to exist.

3. IDoc Message Type Configuration: Verify in transaction WE82 that ORDERS05 is properly linked to message type ORDERS. In cloud environments, custom message type extensions sometimes don’t get properly registered during system provisioning.

4. RFC Destination and Port Setup: In SM59, ensure your RFC destination has these settings:

  • Connection type: 3 (ABAP Connection) or T (TCP/IP) depending on target system
  • In WE21, create a transactional RFC port pointing to this destination
  • The port name in WE20 partner profile must exactly match the port name in WE21

5. Partner Determination in Sales Order: This is often the actual root cause in cloud setups. The system creates the IDoc but can’t determine which partner profile to use. Configure:

  • Transaction VOE2: Link partner function to logical system
  • In the sales order document type configuration (VOV8), ensure output determination is active
  • Check NACE for output type configuration - the output type must have partner function determination rules

6. Cloud-Specific Synchronization: After configuration changes, cloud systems need explicit cache refresh:


Transaction: WE20
After saving partner profile changes:
Go to Environment -> Generate Partner Profiles
Then run transaction BD87 to reprocess stuck IDocs

7. Authorization Check: Cloud environments enforce stricter IDoc authorization. Ensure the background user (typically SAP*/DDIC equivalent) has these authorization objects:

  • S_IDOCDEFT: IDoc definition authorization
  • S_ALE_ALL: ALE authorization for message types
  • B_ALE_RECV: Authorization for partner profiles

Testing Approach: Rather than waiting for orders to trigger IDocs, test immediately:

  1. Use WE19 to create a test IDoc with partner BILL_SYS_01 and message type ORDERS05
  2. If WE19 dispatch succeeds but automatic doesn’t, the issue is in output determination (NACE/VOE2)
  3. If WE19 also fails with the same error, the issue is in the partner profile setup itself

For your specific case with 50 orders daily stuck, I recommend running BD87 after implementing these fixes to reprocess the failed IDocs. The most common cloud-specific gotcha is the Partner Role field in WE20 - this field is optional in on-premise but effectively mandatory in cloud for logical system partners.

3

Check the partner determination configuration in NACE for transaction type. The output type needs to be properly configured to trigger IDoc creation. Also verify in WE19 if you can manually create and send a test IDoc with the same partner and message type - this will confirm whether the issue is in the partner profile itself or in the automatic output determination. If manual dispatch works but automatic doesn’t, the problem is upstream in the order processing workflow.

4

The “partner profile not found” error in cloud typically means the logical system assignment isn’t properly synchronized with the partner profile. Here’s what to check: In SALE, verify the logical system assignment for your client. Then in WE20, make absolutely sure you’re maintaining the partner profile under the OUTBOUND parameters section, not inbound. For message type ORDERS05, you need to specify the basic type ORDERS, process code, and output mode. One common mistake is creating the partner profile in the wrong partner type - ensure you’re using LS (Logical System) not KU (Customer) or any other type.