Order import fails in order fulfillment due to missing configuration attribute in ofc-23c environment

SCM Oracle Fusion Cloud SCM
, , , , , , , ,
1

We’re experiencing consistent order import failures in our order fulfillment module after migrating to 23C. The REST API integration is rejecting orders with error ‘Missing required attribute: SourceOrderSystem’. Our payload includes all mandatory fields according to documentation, but the validation keeps failing.

Here’s a sample payload structure we’re sending:

{
  "OrderNumber": "SO-2025-0315",
  "BuyingPartyId": "300000047369732",
  "OrderDate": "2025-03-15T09:00:00Z"
}

The attribute mapping in our integration interface shows SourceOrderSystem as optional in the setup, but runtime validation treats it as mandatory. This is blocking our entire order ingestion process. Has anyone encountered similar payload validation issues with order attribute mapping after upgrade?

2

I’ve seen this exact issue. The problem is that even though SourceOrderSystem shows as optional in the interface configuration, there’s a validation rule at the orchestration level that requires it when using REST API. Check your Manage Order Orchestration Reference Objects setup - there’s likely a validation rule enforcing this field for external system orders.

3

This is a common gap between FBDI and REST API behavior in 23C. FBDI imports can bypass certain validations that REST enforces. The SourceOrderSystem attribute became stricter in recent releases for API integrations to support better order source tracking. You need to add it to your payload mapping and ensure it matches a valid value in your source system lookup. Also verify your integration interface configuration has the correct attribute mappings defined for all required fields.

4

Check your DOO_DEF_SOURCE_TYPE lookup values. In 23C, when you don’t provide SourceOrderSystem in the REST payload, the system tries to default it based on your trading community setup. If that defaulting fails, you get the missing attribute error. The validation isn’t in orchestration rules - it’s in the order import preprocessor logic. Make sure your integration user has a proper source system association in the trading community architecture.

5

I had this same issue last month. The root cause was that our REST integration wasn’t passing the HeaderContext segment properly. Even though SourceOrderSystem appeared in our payload, it wasn’t being recognized because the context mapping was incomplete. Double-check that your integration interface configuration includes the proper context attribute mapping, not just the order header attributes.

6

Your issue stems from incomplete configuration across three areas. Let me address each of your focus points systematically.

Order Attribute Mapping: The SourceOrderSystem attribute must be explicitly mapped in both your REST payload and integration interface. Navigate to Setup and Maintenance > Manage Order Management Source Systems and verify your external system is registered. Then update your payload:

{
  "SourceOrderSystem": "EXTERNAL_ERP",
  "OrderNumber": "SO-2025-0315",
  "BuyingPartyId": "300000047369732",
  "OrderDate": "2025-03-15T09:00:00Z"
}

Payload Validation: The validation occurs at the Order Import preprocessor level, not orchestration. In 23C, REST API enforces stricter validation than FBDI for source system tracking. Go to Manage Integration Interface Definitions > Search for your interface > Edit Attribute Mappings. Ensure SourceOrderSystem is mapped with transformation rule ‘Direct Mapping’ and source path points to your JSON element.

Integration Interface Config: Your interface definition needs three critical settings:

  1. Source System Context: Set to ‘External’ in interface header
  2. Attribute Mapping: Add SourceOrderSystem with data type VARCHAR2(50)
  3. Validation Rule: Change from ‘Optional’ to ‘Conditional Required’ based on source type

Go to Manage Trading Community Source Systems and create/verify an entry for your external system. The SourceOrderSystem value in your payload must exactly match the Source System Code defined here. Also enable ‘Allow API Import’ flag on the source system definition.

After making these changes, redeploy your integration interface and test with the updated payload structure. The validation will pass once the three-way mapping is complete: payload element > interface attribute > source system registry.

7

Thanks for the insights. I checked the orchestration reference objects and don’t see any explicit validation rule for SourceOrderSystem. Could this be inherited from a seeded profile or trading community configuration? Our integration interface setup shows all standard attributes mapped, but wondering if there’s a hidden dependency.