Skip to main content

Trace by Sales Orders

GET 
/api/manufacturing/lot-genealogy/by-sales-orders

Recall (reverse) — backward "made-from" forest for one or more sales orders. For every finished-good batch shipped on each order, traces upstream to the raw-ingredient lots (and their vendors) that went into it. Drives the genealogy page's "trace by sales order(s)" mode and the Sales Orders list view's "Trace Genealogy (Backward)" bulk action. Authentication: requires a Bearer token (PAT).

Required scope: manufacturing:read

Grant this scope to your token under Settings → Developer → Personal Access Tokens.

Accepts sales_order_ids as a comma-separated string or an array. Orders with no shipped finished goods are silently skipped.

Returns:

  • data.roots — one synthetic sales-order root node per traced order (entity_type sales_order, carrying reference, customer_name, and link_parent_id). Each root's children are the backward traces of the finished-good batches that order shipped; each finished-good node's consumed_quantity is the qty of that batch shipped on the order, and its descendants are the component lots with supplier_name on purchased raw-ingredient layers.
  • summary — order_count (ids supplied), traced_order_count (roots returned), finished_good_count (finished-good batches traced).

Errors:

  • 422 when no ids are supplied, or more than 500 are.
  • 404 when none of the supplied orders have shipped finished goods to trace.

The response also embeds affected_lots (rows + summary) — the deduplicated implicated-lots/suppliers list — computed from the same forest build so the UI needn't fetch/rebuild it separately.

requested_orders lists every selected order (traced or not) with its number, so the UI can label each selected-order chip — the SO list endpoint can't resolve multiple ids.

Request​

Responses​

OK

Response Headers
    Content-Type