Inbound EDI integration fails in distribution management due to custom field mapping issues

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

We’re experiencing failures processing inbound EDI 850 purchase orders through Oracle Integration Cloud to Distribution Management in OFC 23c. The EDI to JSON mapping works for standard fields, but custom fields we added to the order header (customer_priority, delivery_instructions) are not being mapped correctly.

Our middleware configuration includes:


<customField name="customer_priority" path="/order/header/priority"/>
<customField name="delivery_instructions" path="/order/header/instructions"/>

The integration logs show “Field mapping error: custom attributes not found in target schema.” Orders with only standard fields process fine, but any order containing these custom fields gets rejected. The custom fields exist in our Distribution Management setup and work when orders are created manually through the UI.

Has anyone dealt with custom field handling in EDI integrations? How do you ensure the middleware recognizes custom schema extensions?

2

Let me provide some additional context on EDI custom field handling since there’s confusion about the path structure. The OIC logs mention target schema, which is key here.

3

Also check your OIC mapper - you need to explicitly map to the DFF (Descriptive Flexfield) context in the target structure. The path notation matters. Instead of /order/header/custom_field, it should be something like /order/header/flexfields/context[@code=‘ORDER_CUSTOM’]/segment[@code=‘PRIORITY’]. The exact path depends on how you set up the DFF in Distribution Management. Review the REST API documentation for the importOrders service - there’s a section on extensible attributes that shows the correct payload structure.

4

I agree with scm_architect about the flexible layout approach. We had the exact same problem in 23c. Standard order import APIs don’t support custom fields in the main payload structure.

What worked for us: use the extensible flexfield (EFF) framework. In your OIC mapping, structure custom fields under a descriptive flexfield segment. The JSON should nest them properly so Distribution Management knows to route them to the EFF tables rather than trying to match them against the standard order header columns.

5

Let me address all three focus areas systematically since this is a common integration challenge.

EDI to JSON Mapping: Your current mapping treats custom fields as standard header attributes, which won’t work. The correct approach uses Oracle’s Extensible Flexfield (EFF) structure. Modify your OIC mapper to target the flexfield context:

"__FLEX_Context": "ORDER_HEADER_EFF",
"customer_priority": "HIGH",
"delivery_instructions": "Dock B loading"

This tells the API to route these fields to the EFF tables rather than trying to match them to standard columns.

Custom Field Handling: In Distribution Management setup, verify three things:

  1. Custom fields are defined as Descriptive Flexfields (not just custom attributes)
  2. The context code matches what you’re sending in JSON (ORDER_HEADER_EFF or similar)
  3. The “Enabled for Integration” flag is checked

The key distinction: custom attributes added through UI customization aren’t automatically exposed to APIs. They must be implemented as DFFs with proper API enablement.

Middleware Configuration: Your XML configuration snippet shows direct path mapping, which bypasses the flexfield framework. Replace it with:

<flexContext name="ORDER_HEADER_EFF">
  <segment code="PRIORITY" source="/EDI/priority"/>
  <segment code="INSTRUCTIONS" source="/EDI/instructions"/>
</flexContext>

In OIC, after updating the mapping, regenerate the connection metadata AND test with a small payload first. The error “custom attributes not found in target schema” will disappear once the mapper correctly routes to the __FLEX_Context structure.

One more critical point: if you’re on 23c, check if Oracle’s latest integration patch (23c.2 or higher) is applied. Earlier 23c versions had a bug where DFF mappings weren’t properly validated during schema refresh. The patch fixes the metadata generation to include EFF definitions.

After implementing these changes, your EDI orders with custom fields should process successfully. The middleware will properly handle the transformation from EDI segments to the flexfield JSON structure that Distribution Management expects.

6

The target schema reference suggests your integration is trying to write to a specific API endpoint that hasn’t been updated. Are you using the standard importOrders REST API or a custom endpoint? Standard endpoints have fixed schemas that don’t automatically include custom fields.

You might need to use the Flexible Layout feature in Distribution Management. This allows custom attributes to be passed in a separate flexfield structure rather than as direct order header fields. The JSON payload would look different - custom fields go into a flexAttributes section instead of being mapped directly to header level.