Qeasy Cloud
Get Started

Kingdee Cloud Galaxy Sales Outbound Order API Field Handbook: Authoritative Tutorial

· 系统管理员· Engineering Best Practices· 15 views· 4 min read

What This API Solves

The Kingdee Cloud Galaxy SAL_OUTSTOCK sales outbound order API is one of the most commonly used outbound interfaces in supply chain integration. In retail, trading, and e-commerce businesses, transaction tables, v2 warehouse transfer orders, and miscellaneous outbound orders often need to flow bidirectionally between low-code platforms and Kingdee. This API writes sales outbound business into Kingdee as standard documents, connecting inventory, costing, and financial accounting, directly determining inventory data accuracy.

API Capabilities Overview

Authentication: Kingdee Cloud Galaxy uses OAuth2-style signature authentication based on App ID and App Secret, calling WebAPI through the /k3cloud/ entry, with the interface identifier SAL_OUTSTOCK.

Request Structure: A JSON-encapsulated Model object containing fields such as FBillTypeID, FBillNo, FDate, FSaleOrgId, FCustomerID, FStockId, and FEntity (detail array).

Response Structure: Response contains Result and Status fields; on success returns Result.ResponseStatus.IsSuccess=true and the document inner code FID; on failure returns the Errors array.

Pagination/Incremental Mode: The query interface supports Limit + Offset pagination; incremental sync usually uses updateTime or document date as cursor, with full sync for initial deployment and incremental sync afterwards.

Typical Field Mapping

Field NameTypeMeaningPractical Notes
FBillNoStringDocument numberBusiness key, recommend prefix to avoid duplicates
FBillTypeIDStringDocument typeSales outbound default XSCKD01_SYS
FDateDateOutbound dateFormat datetime to yyyy-MM-dd
FSaleOrgIdStringSales organizationPass using organization code FNumber
FCustomerIDStringCustomerUse customer code mapping table
FStockIdStringOutbound warehouseUse warehouse code mapping table
FOwnerTypeIdHeadStringOwner typeFixed constant BD_OwnerOrg
FOwnerIdHeadStringOwnerUsually consistent with sales organization
FEntityArrayDetail rowsSub-form overall mapping
FMaterialIdStringMaterialMaterial code mapping must be built first
FRealQtyNumberActual quantityConsistent with inventory unit
FStockUnitIdStringInventory unitGenerally material base unit
FNoteStringRemarksDocument-level remarks, use FEntryNote for row level

How to Configure on Qeasy Cloud

In the Qeasy Cloud Data Integration platform, Kingdee Cloud Galaxy sales outbound orders have a mature adapter, typically configured as follows:

  1. Data Source Selection: Choose the low-code platform (transaction table, v2 transfer order, or miscellaneous outbound) as source, and Kingdee Cloud Galaxy's SAL_OUTSTOCK Save interface as target.
  2. Field Mapper: In Qeasy Cloud's field mapping canvas, drag source sub-form fields under the FEntity array, and the platform automatically expands by array index. For foreign key fields like FMaterialId, FCustomerID, FStockId, the mapper calls Qeasy Cloud's built-in code mapping function to automatically replace based on the code mapping table.
  3. Scheduling Orchestration: Recommend 30-minute polling for master data strategies and 10-minute polling for business documents; Qeasy Cloud's scheduler natively supports updateTime-based incrementals.
  4. Exception Handling: Enable Qeasy Cloud's retry and dead-letter queue; document failures will not block subsequent batches, and failure reasons are fully preserved in Qeasy Cloud's run logs.

Cross-Scenario Practical Points

  1. Master Data First: Suppliers, customers, warehouses, and currencies must be synced before business documents, otherwise foreign key mapping will report empty value errors.
  2. Unified Multi-Source Outlet: Transaction tables, transfer orders, and miscellaneous outbound orders may all generate sales outbound; ensure routing through fields (is return, document type, transfer type) for warehouse routing.
  3. Three Code Mappings: Material, customer, and warehouse code mapping tables are the lifeline, typically maintained as an independent mapping table in Qeasy Cloud.
  4. Constants and Organization Branching: Settlement currency PRE001, owner type BD_OwnerOrg, document type XSCKD01_SYS and other constants should be centrally managed in Qeasy Cloud's constant pool; customer/department fields often require conditional branching by sales organization.
  5. Approval Status Filtering: Source documents from the low-code platform must be checked as "approved" before submission; this is key to reducing dirty data on Kingdee side.
  6. Date and Document Number Conventions: Dates uniformly formatted as yyyy-MM-dd; document numbers recommend business prefixes (e.g., XSO-, DB-) to avoid collision with Kingdee's own documents.

Pitfall Review

  1. Null Pointer FK Error: Customer code mapping not built before submission, Kingdee returns FMaterialId/FStockId cannot be empty. The safe approach is to attach a "null fallback" handler to each foreign key field in Qeasy Cloud, routing empty values directly to the dead-letter queue.
  2. Duplicate Document Numbers: Low-code platform and Kingdee generate the same document number simultaneously causing submission failure. Recommend enabling document number prefix rules in Qeasy Cloud, using the source system as part of the prefix.
  3. Detail Row Count Mismatch: Source sub-form has 5 rows but only 3 enter target, usually due to index misalignment in FEntity array mapping. In Qeasy Cloud, clearly select "array overall mapping" rather than row-by-row mapping.
  4. Date Timezone Deviation: The updateTime returned by the source platform carries an 8-hour timezone, written directly to Kingdee causing document date to shift by one day. Qeasy Cloud's date formatter defaults to timezone normalization, but confirm the source platform timezone setting.
  5. Dirty Data from Unapproved Documents: Unapproved documents from the source platform also submitted to Kingdee, causing many unapproved documents in Kingdee. Be sure to add "approval status = approved" in Qeasy Cloud's source-side filter conditions.

When to Use

The sales outbound order interface is suitable for sales fulfillment and inventory outbound scenarios in retail, e-commerce, and trading industries; transaction, transfer outbound, and gift outbound can all converge to this interface. It is not suitable for pure production material requisition or pure transfer (no customer dimension) scenarios; for those, please use miscellaneous outbound or direct transfer order interfaces.

Original content. Please credit the source when reposting: https://www.qeasy.cloud/insights/engineering/hb-p6-175-2364-209c

Comments