Synchronizing Purchase Receipt Documents from Wanjtd to Kingdee Cloud Galaxy: A Single-Strategy Implementation Guide
What Problem This Strategy Solves
In one retail business, purchase receiving documents are first created in an e-commerce operations system and then confirmed by supply-chain and finance users in another business system. The problem is rarely a complete transmission failure. More often, statuses, dates, quantities, and codes drift between the two sides. A purchase receipt synchronization strategy writes finalized upstream documents into the target system, reduces duplicate entry, and preserves source document numbers and execution records for traceability.
Data Flow and Field Mapping
The data flow is:
Wanjtd purchase receipt document → Qeasy data integration platform intermediate layer → Kingdee Cloud Galaxy purchase receipt document.
Qeasy does not own the purchasing process. It reads, transforms, validates, records execution results, and reliably delivers the data required by the target system. In a private deployment, the intermediate layer, execution records, and scheduling configuration should remain within the organization’s managed operational boundary.
| Target field | Suggested source field | Processing note |
|---|---|---|
| Document number | Upstream receipt number | Keep as a business key; retain the source number separately so target-side numbering does not overwrite it |
| Document date | Upstream receipt date | Convert to the date format accepted by the target system |
| Supplier | Upstream supplier code | Apply centralized mapping first; route unmapped values to manual handling |
| Warehouse | Upstream warehouse code | Maintain and track the target warehouse mapping centrally |
| Material code | Upstream product or material code | Material synchronization and validation should normally be completed first |
| Receipt quantity | Upstream actual receipt quantity | Validate that it is greater than zero and preserve quantity precision |
| Batch or serial information | Upstream batch and serial data | Preserve it by line when required; route unsupported cases to the exception queue |
| Source document number | Upstream purchase receipt number | Use for idempotency, retry, reconciliation, and audit |
| Source system identifier | Fixed source identifier | Prevent ambiguity when multiple source systems exist |
| Target-only fields | Target organization configuration | Map according to target-system rules instead of copying source fields directly |
The safest pattern is to manage code mappings centrally. Qeasy can maintain mappings for suppliers, warehouses, and materials and record additions, changes, and activation status. Hard-coded mappings scattered across conversion scripts should be avoided because they are difficult to maintain after an organizational change.
How to Configure It in Qeasy
Create a dedicated purchase receipt synchronization strategy with one direction: read eligible upstream purchase receipt documents and create target purchase receipt documents. Do not combine querying, target approval, target posting, and reverse writeback into one execution entry.
Typical configuration points are:
- Connections and organization: Select the upstream business organization, target accounting scope, and corresponding target organization. In a private deployment, use controlled connection configuration and keep sensitive credentials in platform-managed storage. Never place credentials in scripts, logs, or strategy documentation.
- Read conditions: Extract only documents that meet the defined conditions, such as generated status, identifiable source, update time within the synchronization window, and no existing successful execution record.
- Intermediate model: Standardize source document number, target document number, business date, source line number, target line number, status, error reason, and retry count. A line number should be unique only together with its document number.
- Field transformation: Apply code mappings before converting dates, quantities, units, and empty values. Use explicit conversion rules. Unmappable fields should remain empty and generate a warning rather than being silently discarded.
- Target write: Create the target purchase receipt document according to target-system business rules. Use the stable source key for duplicate prevention and store the target number only after success.
- Validation and retry: Check required fields, codes, quantities, dates, and master-data validity before submission. Retry temporary failures according to policy, but route business errors to manual handling. Retries must not modify the source document.
- Logging and alerts: Include the strategy name, business document number, source line number, target document number, processing status, and failure reason. Classify mapping gaps and target conflicts for notification.
When Qeasy implements this kind of flow, a header-and-line phased approach is a useful default. Synchronize the header and key validation information first, then submit the complete lines after the header has been accepted. This reduces the risk of creating a target document with a header but no lines.
Implementation Steps: Incremental Start, Full Trigger, and Schedule
First, define the incremental starting point. Before go-live, select a clear timestamp and retrieve purchase receipt documents based on upstream update time or another available condition. Incremental queries must include a time window and a defined boundary rule. Do not overwrite a previous success timestamp without considering late or backfilled records.
Second, establish a full reconciliation process. A full run is not a command to create duplicate target documents. It reconciles source document numbers, source line numbers, and target return results. Pause or isolate overlapping incremental work for the same scope during the full run. Handle successful, partially successful, and failed records separately; failed records should enter an exception queue.
Third, define the scheduling frequency. The frequency should reflect document generation volume, target processing capacity, and the team’s ability to resolve exceptions. When business volume is stable, short-cycle incremental runs can be used. When backdated entries, cross-period adjustments, or centralized mapping changes occur, trigger a controlled full reconciliation. Regardless of frequency, set an execution window, concurrency limit, and retry limit.
During go-live, validate in a small scope before expanding the business organization. The validation phase should process test markers or designated organizations and focus on the header, supplier, warehouse, material, quantity, and source document number. Restore normal scheduling only after failures are diagnosable and duplicate creation is ruled out.
Lessons Learned
First, treating the source document number as an ordinary field. A typical mistake is allowing the target system’s new document number to overwrite the source number, making duplicate detection impossible. Keep the source number permanently in the intermediate layer and use it as the primary idempotency key.
Second, writing the header first and adding lines later, then encountering a timeout and creating a half-finished document. This is a common failure. Use a phased header-and-line process: complete header or pre-validation first, then submit lines. If submission fails, query the target state instead of blindly creating another document.
Third, pushing receipt documents before material master data is confirmed. If an unmapped value is replaced with a default code in a script, the target document contains a silent error. Complete material synchronization and validate mappings first. Pause records that cannot be confirmed; do not invent mappings.
Fourth, using update time as the only incremental condition. Backfilled entries, rejected documents that are resubmitted, and cross-day modifications can all cause omissions. Preserve boundary records, deduplicate by source document number, and run periodic full reconciliation. A dual-track incremental-and-full model is a common Qeasy customer pattern.
Fifth, logging only “synchronization failed.” Without the source document number, line number, and error category, retries become duplicate work. Standardize error codes and reasons, separating retryable technical failures from business errors that require manual correction.
When to Use It and When Not to Use It
This strategy is suitable when purchase receipt documents are already completed upstream, the target system must centralize receiving records, and both systems need consistent supplier, warehouse, and material codes. It is not suitable when both sides independently approve and frequently modify the document, or when a complex approval process must finish before receipt can be posted. If upstream documents are not stable or target master data is not synchronized, complete master-data governance and field confirmation before enabling this strategy.