Qeasy Cloud
Get Started

Other Inbound (Negative) to Other Outbound: An Inventory Sync Playbook on Qeasy

· 系统管理员· Integration Solutions· 11 views· 4 min read
吉客云Kingdee Cloud供应链集成Inventory Sync其他入库单其他出库单轻易云负数入库

What This Strategy Solves

In inventory accounting, some companies express adjustments, returns, and corrections as negative-quantity 'other inbound' documents. However, negative inbound entries are not universally supported by target systems, which usually require these adjustments to land as 'other outbound' documents to keep the business semantics consistent.

The goal is to translate negative-quantity other inbound documents from the source into other outbound documents in the target — flipping the sign per line item, while keeping quantity, warehouse, date, stock direction, and document number aligned for cross-system reconciliation. This is one of the most underestimated strategies in supply-chain integration, yet it has an outsized impact on inventory ledger accuracy.

Data Flow and Field Mapping

Data flow: Source (Other Inbound, possibly negative quantities) → Qeasy integration platform (sign inversion, field mapping) → Target (Other Outbound).

Key field mapping (drawn from typical field practice):

Source Field (Other Inbound)Transformation LogicTarget Field (Other Outbound)
goodsdocNo (Inbound Doc No.)Pass-through as traceability idFJKYNo (Source doc number)
Creation timePass-throughFDate (Document date)
Warehouse codeMapped via warehouse masterFStockOrgId / FBillTypeID
Item detailsExpanded per lineBody: FBizBillEntry
QuantitySign flipped, absolute value writtenFQty
Stock direction (Inbound)Mapped to dropdown valueFStockDirect

Key takeaways: the sign flip must be applied at the line-item level, not at the header level; keep the original source document number and let the target system generate its own number so cross-system reconciliation is straightforward.

Configuring This on Qeasy

In Qeasy, this strategy is typically split into two stages: query source documents + write to target.

Source-side configuration:

  • Select the source connector (e.g., the inventory platform), locate the inbound category, and filter for "other inbound" entries with negative quantities.
  • Use pageIndex / pageSize pagination; 50 per page is a good balance — too small slows throughput, too large risks hitting response size limits.
  • Bind startDate / endDate to {{LAST_SYNC_TIME}} and {{CURRENT_TIME}} to enable incremental sync.

Mid-layer configuration:

  • In Qeasy's field mapping panel, apply a sign-invert + absolute value expression to the quantity column.
  • Centralize code mapping: warehouses, items, reason codes, stock directions — keep them in a single mapping table, not scattered across strategies. This is one of the most common patterns we see on customer sites.
  • Stage header and body separately: write the header first (FJKYNo, FDate, FBillTypeID, FStockOrgId), then iterate through body line items.

Target-side configuration:

  • Call a batch-save interface such as batchSave against the other outbound document entity.
  • Leave the target's bill number blank so it is auto-generated, avoiding collisions.
  • Map FStockDirect according to the target's dropdown list; write the original source document number into a custom field (FJKYNo) for cross-system traceability.

Implementation Steps

We recommend a phased rollout:

  1. Cold-start full sync: Run a one-time full sync over a historical time window to verify document count, amount, and stock direction on both sides. The goal is to establish a baseline.
  2. Switch to incremental: Move startDate to the last successful sync timestamp and run incrementally thereafter. Use Qeasy's "last sync time" variable rather than hard-coded timestamps.
  3. Scheduling cadence: A typical source-side cron runs more frequently during business hours and throttles at night. Stagger target-side writes (for example, source every 2 hours, target every 2 hours offset) so the two systems don't peak simultaneously.

A safe pattern is incremental + full dual-track: incremental handles day-to-day sync, while a periodic full sync (monthly or quarterly) acts as a reconciliation backstop. If drift is detected, re-run the full sync over the affected window.

Lessons from the Field

  • Sign flip applied at the wrong level: A classic mistake is flipping the total at the header level, which only affects the last line item in multi-line documents. Apply the sign flip per line item.
  • Mapping hard-coded into the strategy: When warehouse and reason code mappings are scattered across many strategies, every change requires updates in N places. Centralize them in a single maintainable mapping table.
  • Ignoring the target's bill numbering rules: Writing the source document number directly into the target's bill number field leads to duplicates or rejections. Keep the source number in a custom field (FJKYNo) and leave the target's bill number blank.
  • Time window too short: If you only fetch the last hour, negative entries that cross midnight may be missed. Use a 24-hour sliding window at minimum — trade a little performance for accuracy.
  • No reconciliation loop: Once writes succeed, the job is considered "done"; three months later, the two systems don't agree. Add a lightweight reconciliation job in Qeasy that periodically looks up source documents via FJKYNo and writes any drift to a "to investigate" table.

When to Use, When Not To

Use when: the source expresses adjustments/returns as negative other inbound documents, but the target requires other outbound documents; inventory accounting requires per-line sign flipping; cross-system stock direction (IN/OUT) semantics differ.

Don't use when: the source already produces positive other outbound documents and no sign translation is needed; the target natively supports negative inbound entries; sub-minute real-time sync is required — this strategy is designed for batch, near-real-time workloads.

Original content. Please credit the source when reposting: https://www.qeasy.cloud/insights/solutions/strat-p2ea595-kingdee-cloud-5924-nc9405605-becdf3e2

Comments