Sales Order Sync: Marketing Cloud to ERP Outbound Document Integration

What This Strategy Solves

In many retail enterprises, the front-end marketing cloud handles order intake, requester placement, and agreement numbering, while the back-end ERP handles outbound delivery, inventory deduction, and accounts receivable reconciliation. The "sales order to outbound document" sync may look like a simple push, but if the encoding mapping, incremental anchor, or scheduling frequency isn't designed carefully, the numbers on both sides drift apart within three months. In real customer projects, we use the Qeasy Data Integration Platform to carry such business document flows. This tutorial dissects the "New Order – Outbound Document" strategy, breaking down data flow, field mapping, configuration essentials, and practical pitfalls.

Data Flow and Field Mapping

The overall direction is "Marketing Cloud → Qeasy middle layer → Target ERP." The source side pulls approved agreement order headers via POST /api/openapi/v1/erp/order/honour/agreement/header, while the target side writes sales outbound documents via POST /jdy/v2/scm/sal_out_bound.

Customer master records, units of measure, and other base data should be synced via a "base data sync" strategy first, then referenced by the outbound document strategy. This avoids dirty data in the first batch.

How to Configure on Qeasy

On the Qeasy Integration Platform, this strategy typically lives under the "Business Documents" domain. Configuration focus is concentrated in four areas:

1. Data source registration. Register the source marketing cloud platform_id and the target ERP platform_id separately, using standard public cloud authorization. Connection details stay inside the platform and never appear in scheduling scripts.

2. Field mapping editor. Qeasy's mapping editor supports both variables and functions. {{approveDt|date}} is a typical date formatting function that converts the source string into the yyyy-MM-dd format the target ERP requires. {{clientAppNo}} uses _findCollection to look up the customer master set and convert external codes to ERP internal IDs. This "centralized encoding mapping" is a common pattern among Qeasy customers—when switching ledgers or adding requesters, only this one collection needs updating.

3. Idempotency and deduplication. Enable idCheck, set the number field to id, ensuring the same order will never generate duplicate outbound documents no matter how many times it is retried.

4. Exception handling and alerts. Configure a retry policy for write failures on the target ERP side (3 retries with exponential backoff is recommended), and dump failed rows into an "exception queue" for later patching.

Implementation Steps

We typically break such business document sync into three phases:

Phase 1: Align the incremental anchor. Use the maximum value of the id field as a cutoff; the source starts pulling from the next record. The target side clears test data at the same time to ensure both sides start from the same baseline. After this step, smoke testing begins.

Phase 2: Full-volume trigger with header and body phased execution. Another common Qeasy customer pattern is "header and body in phases": first run order headers, confirming every record generates a corresponding outbound header; then run order line items separately, bringing product, quantity, and price into the outbound detail. Leave a 5–10 minute observation window between the two to avoid overwhelming the target ERP with a single massive batch.

Phase 3: Scheduling frequency and incremental normalization. Source crontab set to */2 8-21 * * * (every 2 minutes during business hours), target set to */3 7-23 * * * (every 3 minutes covering the full business window). The two frequencies are offset to form an "incremental and full-volume dual-track": the source keeps pulling new orders, while the target runs a small full-volume reconciliation during idle windows.

During the first week, manually reconcile document counts and the exception queue every hour. Drop to twice a day in week two, and switch to weekly reports once stable.

Pitfall Recap

1. Inconsistent time field formats. The marketing cloud returns a full timezone-aware timestamp string, but the target ERP only accepts yyyy-MM-dd. If you don't explicitly apply the |date function in the mapping, the write will be rejected. The typical mistake is relying on the target system to auto-detect the format.

2. Running outbound document sync before the customer master set is ready. When _findCollection cannot find the corresponding customer ID, the entire document fails immediately. The safe approach is to explicitly declare the dependency on the base data sync in depends_on.

3. Wrong idempotency key. Some engineers take a shortcut and use no (document number) as the idempotency key. The result: after the same order is modified and pushed again, the platform treats it as a new document and generates another outbound document. Always use the source-side id, never the business document number.

4. Scheduling frequency collides with the target system's settlement window. Some ERP systems run daily settlement overnight. If the source crontab keeps pulling data past midnight, the writes will be blocked by the settlement job. The safe approach is to explicitly constrain the source scheduling window to business hours.

5. No one watches the exception queue. In the first version we deployed, dozens of "customer master missing" errors piled up in the exception queue for three days before anyone noticed. Always wire exception alerts into the team chat (WeCom Work or DingTalk).

Applicable and Non-Applicable Scenarios

Applicable: Retail, wholesale, and healthcare/nutrition enterprises where the marketing cloud or e-commerce front-end generates agreement orders with clear requesters and suppliers, and the ERP handles outbound delivery. Daily order volume ranges from thousands to tens of thousands, and reconciliation delays within hours are acceptable.

Not applicable: Complex business flows with frequent order status changes (approved → unapproved → repriced → re-approved), and scenarios requiring strong real-time inventory linkage. For those, an event-driven approach is recommended over scheduled polling.