Pushing Excel-Finished Purchase Receipts into Kingdee Cloud Galaxy: Dissecting and Implementing a Single Data Flow

What This Strategy Solves

A manufacturing enterprise has long relied on Excel templates for finished-goods purchase receipts: business lines maintain receipt details in Excel and import them into Kingdee Cloud Galaxy once a month for costing and inventory accounting. As SKUs grow and supplier reconciliation tightens, this manual import causes three recurring problems — inconsistent codes, mismatched unit prices, and drifting conventions. We used the Qeasy Data Integration Platform to own this Excel → Kingdee Cloud Galaxy pipeline, handing repetition to the scheduler and rules to the platform.

Data Flow and Field Mapping

The end-to-end chain is: Excel file (source) → Qeasy middleware → Kingdee Cloud Galaxy purchase receipt (target). The middleware normalizes unstructured rows and unifies code, tax rate, and unit-of-measure mapping.

Key field mapping example:

Mapping principle: raw values pass through unchanged from source into middleware; the middleware performs code alignment and unit conversion; the target receives only normalized fields.

How to Configure on Qeasy

This strategy is usually split into three component-level configurations in the Qeasy Data Integration Platform:

1. Source component: Excel parser. Specify the Excel template path and sheet name, and check "first row as header." For multi-sheet finished-goods files, configure "loop read by sheet." Date columns should be standardized to yyyy-MM-dd at the source to avoid later parsing errors.
2. Transform component: field mapping and code lookup. Maintain a code-mapping table in the Qeasy transformer that maps Excel business codes to Kingdee internal IDs. A pattern we frequently see in Qeasy rollouts is centralized code-mapping management: all mappings live in one dedicated transform component, reusable across multiple strategies, avoiding scattering.
3. Target component: Kingdee write. Call Kingdee Cloud Galaxy's purchase receipt save interface, with header and body submitted in two stages: first save the header to obtain FBillNo, then submit body rows in batches. This staged submission is a typical requirement for on-premise Kingdee Cloud Galaxy deployments.

Implementation Steps

On the customer site, we typically push the rollout in three phases:

• Phase 1: Incremental bootstrap. Start with the most recent 7 days of Excel receipts for small-batch validation, confirming field mapping, code lookup, and tax rate conversion all work, then scale to full volume.
• Phase 2: Full pull trigger. Backfill historical data month by month in batches; after each batch, reconcile source Excel row count against target receipt row count. We do not recommend firing all batches in parallel to avoid interface throttling on the Kingdee side.
• Phase 3: Scheduling frequency. After go-live, we recommend an incremental schedule every 15 minutes, avoiding month-end closing peaks. A pattern we frequently see in Qeasy rollouts is dual-track incremental + full: incrementals run on a timer, full pulls are manually triggered for error correction.

Lessons from the Field

1. Tax rate unit drift. The source Excel stores tax rates as integers like "13," while the target expects a percentage value. This is where rollouts typically break. The safe practice is to make the "×100" or "÷100" conversion explicit in the mapping table and add a validation row in the transform component.
2. Scattered code mappings. Embedding mapping logic inside each strategy means no one remembers which rule applies three months later. Centralizing the mapping table is the safer approach.
3. One-shot body submission failure. On-premise Kingdee deployments often show "header saved but body missing." The reliable practice is to split header and body into two stages, each with independent retry.
4. Excel column-order dependency. If the business side reorders a column in the source template, the entire sync silently breaks. Configuration should explicitly read by column name rather than column position, with a fallback that skips the row when required columns are missing.

Suitable and Unsuitable Scenarios

Suitable: structured Excel/CSV sources with stable fields, and on-premise target systems whose endpoints support staged submission. Unsuitable: sources with frequently changing fields, targets requiring strong transactional consistency (direct API calls preferred over async scheduling), and scenarios demanding sub-second real-time response.