Working with Parent/Child Customers

Many businesses operate with a central buying office that places EDI orders on behalf of multiple ship-to locations — retail stores, distribution centers, or regional warehouses. Some NetSuite accounts are configured with these locations as child customers (sub-customers) under a single parent customer using NetSuite's native parent/child relationship.

The Orderful SuiteApp supports this pattern. When parent/child customers are in use, you configure EDI settings on the parent customer, then map each ship-to location to a child customer using identifiers from the incoming EDI message. The SuiteApp resolves the correct child customer at order import time and creates the Sales Order with the appropriate entity, so billing, shipping defaults, and reporting all flow to the right sub-customer.

📘

A note on customer structure: Using parent/child customers is not the only way to handle multiple ship-to locations. NetSuite's multiple address functionality on a single customer record is generally preferred for performance and simplicity. The parent/child approach described here is for accounts that are already set up this way or have specific business reasons for maintaining separate child customer records (e.g., distinct billing terms, separate reporting, or subsidiary-level requirements).

How It Works

When an inbound 850 (or 875) arrives, the SuiteApp follows this resolution flow:

1. Find the parent customer — Match the sender's ISA ID to a customer record with a matching Production or Test ISA ID.
2. Extract the Ship-To identifier — Read the N1 Ship-To (ST) identification code from the EDI message.
3. Look up the child customer — Search child customers (where parent = [parent customer]) for a matching Ship-To N1 Identification value.
4. Assign the entity — If a matching child is found, the Sales Order is created with the child customer as the entity. If no match is found, the Sales Order is created with the parent customer.

For split orders (SDQ or split-by-store), each resulting Sales Order is independently matched to its child customer based on the store number or DC number in the order data.

Configuration

Step 1: Configure the Parent Customer

All core EDI configuration lives on the parent customer record:

1. Navigate to the parent customer record in NetSuite.
2. On the EDI tab, set the ISA Qualifier and ISA ID fields to match the trading partner's identifiers in Orderful.
3. On the Order Management Config subtab, set the Subcustomers Represent dropdown:
   • Stores — Child customers represent retail store locations. The SuiteApp matches using the store number from the EDI message.
   • DCs — Child customers represent distribution centers. The SuiteApp matches using the DC number from the EDI message.
   • Leave blank if you are not using sub-customer resolution.
4. Enable the Lookup Sub-customer Ship-to By Entity ID checkbox if you want the SuiteApp to also search against the native NetSuite Entity ID on child customers (in addition to the Ship-To N1 Identification field). This is useful when your child customer Entity IDs already contain the store or location code.
5. On the EDI tab, add EDI Enabled Transaction Types for each document type the parent should support (850, 855, 856, 810, etc.).

Step 2: Create and Configure Child Customers

Each ship-to location should be a sub-customer of the parent in NetSuite:

1. Create a new customer record (or edit an existing one) and set the Sub-customer of field to the parent customer.
2. On the EDI tab, set the Ship To N1 Identification field to the EDI identifier for this location. This is the value that appears in the N1 Ship-To (ST) segment of inbound transactions — typically a store number, DC code, or location identifier provided by the trading partner.
3. Set the child customer's address, shipping defaults, and any other fields that should differ from the parent.

Important: The Ship To N1 Identification value must be unique among siblings of the same parent. If two child customers have the same value, the SuiteApp will match the first one found.

Step 3: Verify the Setup

After configuration, test with an inbound 850 that includes a Ship-To identifier:

1. Confirm the Sales Order is created with the child customer as the entity (not the parent).
2. Confirm the shipping address on the Sales Order matches the child customer's default.
3. If using order splitting, confirm each split Sales Order maps to the correct child customer.

What the Child Customer Inherits

Child customers inherit most EDI behavior from the parent, with a "child wins" override pattern:

Enabled Transaction Type Override Example

If the parent customer has enabled transaction types for 850, 855, 856, and 810, and the child customer has an enabled transaction type for 855 only:

• 850: Uses the parent's config (child has none)
• 855: Uses the child's config (child overrides parent)
• 856: Uses the parent's config (child has none)
• 810: Uses the parent's config (child has none)

The child's 855 config carries all of its own settings — JSONata mapper, auto-send, consolidation method, ISA overrides, and process-as-custom flag. It fully replaces the parent's 855, not a partial merge.

Outbound Transactions

When generating outbound documents (855, 856, 810) from a Sales Order that has a child customer as the entity:

1. The SuiteApp reads the entity from the Sales Order (the child customer).
2. It loads both the child and parent customer records.
3. Enabled transaction types are merged using the same child-wins pattern described above.
4. The ISA ID for the outbound message is resolved in priority order:
   1. ISA override on the enabled transaction type record (if set)
   2. ISA ID on the child customer record
   3. ISA ID on the parent customer record
5. If no ISA is found at any level, the outbound message fails with an error.

This means child customers typically don't need their own ISA IDs — they inherit the parent's. You only need to set an ISA on the child if it differs from the parent (uncommon).

Lookup Sub-customer by Entity ID

The Lookup Sub-customer Ship-to By Entity ID setting on the parent customer (or in Global Settings) adds a secondary lookup path. When enabled, the SuiteApp checks both:

1. The Ship To N1 Identification custom field on the child customer
2. The trailing alphanumeric portion of the child customer's native Entity ID (extracted via pattern matching)

This is useful when your NetSuite child customers are named with a convention like Parent Company : 12345 where 12345 is the store number. The SuiteApp extracts 12345 from the Entity ID and matches it against the incoming Ship-To identifier.

The N1 Identification field is checked first. If no match is found there and Entity ID lookup is enabled, the Entity ID is checked as a fallback.

When No Child Customer Is Found

If the incoming EDI message contains a Ship-To identifier but no matching child customer exists:

• The Sales Order is created with the parent customer as the entity.
• No error is thrown — the SuiteApp logs the lookup attempt and proceeds.
• The Ship-To address from the EDI message is still applied to the Sales Order (it comes from the EDI data, not the customer record defaults).

If you expect all orders to resolve to a child customer, monitor for Sales Orders created with the parent entity — this may indicate a missing child customer or a mismatched Ship-To N1 Identification value.

Common Configurations

Troubleshooting