EDI Trading Partner Integration Suite

Winning the purchase order from a national retailer, a grocery banner or a large distributor is rarely the hard part. The hard part arrives a fortnight later as a vendor routing guide and an EDI compliance packet. You are now expected to receive an 850 electronically, return an 855 acknowledgement inside a stated window, transmit an 856 advance ship notice before the trailer reaches the distribution centre, apply GS1-128 carton labels whose SSCC-18 numbers reconcile exactly to that ASN, and invoice on an 810 that matches line for line. Miss a segment, a qualifier or a deadline and the chargebacks start - and chargebacks are deducted from remittance, so they quietly consume the margin on the order you fought to win.

NetSuite has no native EDI engine. Most teams bridge the gap with a shared mailbox, a spreadsheet of partner item numbers and someone re-keying orders. That holds until the second trading partner arrives, or volume doubles, or the routing guide is revised and nobody notices until the debit memo lands.

What ECOSIRE builds

This is a build-to-order engagement. We build an EDI suite as NetSuite customisations inside your own account - SuiteScript 2.1, custom records and SuiteFlow - shaped around the specific routing guides you send us. There is no shrink-wrapped product to download and no free trial, because the value is entirely in the mapping work that matches your partners and your item master.

The inbound path

Inbound interchanges are collected on a Map/Reduce schedule and parsed into a staging layer before anything touches a live transaction. Every ST transaction is written to a custom EDI Transaction record holding the raw payload, the partner, the ISA/GS/ST control numbers, a parse status and a link to whatever NetSuite record it eventually produced. Only once a transaction validates does a second Map/Reduce create the Sales Order through the N/record module.

That creation step is where the real work lives: partner item numbers (UPC, GTIN, buyer part number) are resolved against a cross-reference custom record to your NetSuite item internal IDs; ship-to DC codes are resolved against entries in the Customer address book; and the fields a retailer cares about - PO number, department, cancel-after date, routing instructions, allowance codes, mark-for - are stamped onto custom transaction body and column fields so they survive through to the ASN and the invoice. An 860 purchase order change is applied against the existing order rather than creating a duplicate, with a rejection path when the order has already shipped.

The outbound path

• 855 is generated from the saved Sales Order with line-level accept, reject, date-change and price-change codes derived from what NetSuite actually committed.
• 856 is built from the Item Fulfillment package subtab, so the HL loop hierarchy (shipment, order, tare, pack, item) is generated from the same pack structure the warehouse physically built. The SSCC-18 on each carton comes from a controlled counter on a custom record, and is written to both the label and the ASN from a single source.
• 810 is mapped from the NetSuite Invoice, including SAC allowance and charge segments, terms discount and the reference qualifiers the guide demands.
• 940 / 945 provide the warehouse shipping order and shipping advice pair when your inventory sits with an outsourced warehouse, with 944 receipt advice and 947 adjustment advice added where the flow needs them.
• 846 inventory advice is produced from a Saved Search of quantity available by Location on a Scheduled Script cadence set per partner.
• 997 functional acknowledgements are generated for every inbound interchange and reconciled against outbound ones, so an unacknowledged transmission becomes a visible exception rather than a silent hole.

Transport, envelopes and control numbers

Each trading partner gets a profile custom record: ISA and GS qualifiers and IDs, X12 version, element and segment delimiters, test or production indicator, per-document enable flags, mapping overrides, and control-number counters that increment atomically so two concurrent script executions cannot issue the same ISA13. SFTP collection and delivery run through the N/sftp module on a Map/Reduce schedule. Where a partner mandates AS2, the suite hands off to the AS2 endpoint or VAN you already have over N/https rather than pretending to terminate S/MIME and MDNs inside SuiteScript - that boundary is drawn deliberately and we will be explicit about it at scoping.

Fitting your account, not a template

The build respects how your account is actually configured. In OneWorld, partner profiles, item cross-references and control-number sequences are scoped by Subsidiary so two selling entities can trade with the same retailer without colliding. Item behaviour differs by type - inventory items, kits and packages, assemblies, matrix items and lot- or serial-numbered items each map differently on an 856 - and we handle them explicitly rather than assuming a flat item master. Custom Segments already in use for brand, channel or programme can be carried onto EDI-created transactions. Roles and permissions are set so warehouse and customer-service users can work the exception queue without holding script or setup permissions.

Exceptions are the product

A quiet EDI system is not the same as a working one. The suite ships with a Saved Search driven exception dashboard and a portlet showing parse failures, unmapped items, unresolved ship-to codes, documents approaching a partner acknowledgement window and interchanges with no matching 997. N/email alerts route to the people who can act. Map/Reduce stages yield correctly under governance so a large interchange does not abort mid-run.

Who this is for

Brands, distributors and manufacturers entering big-box, grocery, pharmacy or club retail programmes for the first time. Companies already trading with one partner by hand who have just signed a second. Teams shipping through an outsourced warehouse that needs 940/945 rather than a portal login. Anyone whose finance team is reconciling chargebacks that trace back to ASN or label mismatches.

How delivery works

1. Scoping call. Send us the routing guides and EDI specifications for the partners in scope, a sample of your item master, and a description of your fulfilment path. We walk the document set, the transport method and the edge cases. 2. Fixed quote. You receive a written scope naming every document, every partner and every mapping, with a fixed price and a delivery window. Nothing is built before you approve it. 3. Build. We develop against sample interchanges from your guides, using your item and customer data shape. Typical lead time is two to four weeks depending on document count and partner count. 4. Install in sandbox. The suite is deployed to your NetSuite sandbox as an SDF project and unmanaged bundle. You test with partner test envelopes (test indicator set) and your own operators run real scenarios end to end. 5. Production. After your sign-off we install into production, configure deployments and schedules, and run the first live interchanges alongside your team. 6. Support. A post-go-live support window agreed in the quote covers defects and map corrections, with a written change-request route for new partners and new documents afterwards.

What this is not

We are not a VAN and we do not resell EDI connectivity, mailbox fees or partner onboarding fees - those stay between you and your provider. We do not certify your account with a retailer; the retailer controls that testing timeline. And nothing here is available as an instant download: every installation is built for the guides you give us.