Sales Order Delivery Notification Sync: From ERP to OA Approval Flow — A Practical Walkthrough
What This Strategy Solves
At one manufacturing client, the shipping stage kept getting stuck at a cross-system boundary: once the warehouse posted a delivery in the ERP, the same document had to be re-entered by a sales assistant into the OA system to start the approval flow. The same delivery notification ended up being maintained in two systems. Over a month, the OA flow and the ERP ledger drifted by one to two days, and unit or quantity mismatches appeared from time to time.
The fix is to sync the ERP delivery notification, keyed by its document number, into the OA approval flow and write the OA approval result back. The whole thing lives inside a single sync strategy.
Data Flow and Field Mapping
The flow is one-way push: ERP → middleware → OA. The source system is the ERP, triggered by a document-save event; the target is the OA, where each push becomes a new approval-flow instance.
Key field mapping (simplified):
| Business Meaning | ERP Field | OA Field | Notes |
|---|---|---|---|
| Document No. | FBillNo | request_no | Primary key, deduplicated |
| Customer Code | FCustId.FNumber | cust_code | Customer master must sync first |
| Document Date | FDate | apply_date | Unified date format |
| Warehouse | FStockId.FNumber | warehouse | Code mapping maintained centrally |
| Line Material | FEntity.FMaterialId.FNumber | item_code | Line item |
| Quantity | FEntity.FQty | qty | Carries unit |
| Applicant | FProposerId.FNumber | apply_user | Maps to OA login |
A real-world gotcha: the material plus quantity on each line must be submitted in the same payload as the header. The OA side does not allow late-arriving line items.
How to Configure It on Qeasy
On customer sites we use the Qeasy data integration platform (轻易云数据集成平台) and treat this strategy as a single integration flow. Configuration typically breaks into three pieces:
- Source event ingestion: enable a document-save event on the ERP side and push the whole delivery notification, header plus lines, in one call, to avoid multiple fetches.
- Middleware transformation: inside the Qeasy transformer, do code mapping, unit conversion, and date formatting. We prefer centralized code mapping — a single mapping table — so later changes to materials, customers, or organizations only need to be made in one place, not in the flow.
- Target landing: call the OA approval-flow creation API, write the prepared fields into the flow form, and write the returned flow instance ID back to a custom field on the ERP side for later reconciliation.
The safe pattern is to go live with the header first, stabilize it, then add the lines; for the lines, validate in full before switching to incremental.
Implementation Steps
We usually split rollout into four phases and verify each one:
- Incremental starting point: confirm the last-modified timestamp of the latest document in the ERP, and use that as the incremental starting point so historical documents are not replayed into OA.
- First full pass: after the incremental starting point is set, run a small-scope full sync — for example one organization or one customer — to validate the mapping table, fields, and units end to end.
- Phased scheduling:
- Header goes live first, incremental pull every 5 minutes;
- once lines are stable, tighten the frequency to every 1 minute;
- failed documents go to a retry queue and are handled separately.
- Write-back and reconciliation: when the OA flow ends, write the approval result and final shipping time back to the ERP; run a daily reconciliation and send the diff list to the business owner for confirmation.
Throughout the chain we keep an "incremental plus full, dual track" approach: incremental handles day-to-day traffic, and a small batch reconciliation runs over the weekend so missed documents can be caught.
Lessons Learned
- Scattered code mapping. One client hard-coded material mappings into transformer scripts. After three months of additions and changes, edits were missed. The safe pattern is to centralize everything in one mapping table.
- Header and lines shipped together make debugging hard. Pushing the whole document at once means a failure could be dirty header data or out-of-bounds line data, and you cannot tell which. The safe pattern is to roll out header first, then lines, in phases.
- Wrong incremental starting point causes historical replay. If the starting point is rolled back or manually edited, historical documents get re-pushed and duplicate OA flows are created. The safe pattern is to lock the starting point configuration and add a document-number deduplication safety net.
- Approval flow timeout never gets written back. If an OA flow sits open for a long time, the ERP never sees the final state. The safe pattern is a timeout fuse plus a human-intervention node, not an infinite wait.
- Units and precision ignored. The ERP base unit and the OA flow form's quantity precision do not match, so lines arrive with wrong decimal places. The safe pattern is to unify precision and convert units once in the middleware layer.
When It Fits and When It Doesn't
Fits: enterprises with stable document structures, mid-range volumes, and a need for cross-system approval and audit trails; supply chain scenarios where both ERP and OA expose standard APIs and fields can be mapped one to one.
Doesn't fit: scenarios that need complex branching approvals or parallel sign-off; scenarios where ERP and OA field structures differ too much and require heavy custom development; or lightweight scenarios where minute-level real time is not required and manual entry is acceptable.