The Decisions Hiding Inside "Open"
A defensible open-orders definition over co and coitem answers, explicitly: Which statuses count, only ordered, or others? Are you counting orders or lines? How is remaining quantity computed, ordered minus shipped, and how do returns and backorders figure in?
Do credit-hold orders count? Are fully-shipped-but-uninvoiced lines open? And in multi-site databases, is site_ref filtered deliberately?
Every hand-written report answers all of these, usually implicitly, and any two reports that answer one differently will disagree forever.
- Status filtering: which co and coitem statuses qualify as open.
- Grain: order-level counts and line-level counts are different numbers.
- Quantity arithmetic: ordered vs shipped vs returned determines remaining.
- Edge policies: credit holds, zero-remaining lines never closed, uninvoiced shipments.
The Fix Is Structural: One Definition, One Place
Documentation does not fix this; documents drift from code. The structural fix is a semantic view: encode the full definition once, as SQL in the database, and repoint every consumer, reports, dashboards, exports, at the view. Disagreements then become a review of one view's logic instead of a forensic comparison of report queries, and a definitional change is one edit that propagates everywhere.
This is exactly the pattern SyteRay installs: namespaced SyteRay_ views for open orders, bookings, and shipments, plainly readable by your DBA, used by every SyteRay surface.
What It Looks Like When It Works
With the view in place, the CSR quoting a customer, the plant manager's dashboard tile, a conversational question in chat, and a Deep Research report all return the same number, because they are structurally the same query. On SyteRay's reference deployment, that closed the gap that had one path reporting 830 and another 820: after routing through the shared view, every surface reported the identical count. The meeting about whose number is right simply stops happening.
Try it here, free
SyteLine Purchasing Tables Columns Reference
Searchable column list for SyteLine purchase order, line, vendor and receipt tables with join keys and the formulas behind open, late and unvouchered PO reports.
Frequently asked questions
Why do two SyteLine open order reports show different totals?
Different implicit definitions: status filters, order-versus-line counting, quantity arithmetic, credit-hold policy, or site scoping. Both reports are correct by their own rules. The fix is a single shared definition, ideally a database view every report reads.
Which SyteLine tables does an open orders report use?
Primarily co (order headers) and coitem (order lines), joined to item for descriptions and scoped by site_ref in multi-site environments. The hard part is not the joins but the definitional filters over statuses and quantities.
What is a semantic view in this context?
A database view that encodes a business definition, like what counts as an open order, exactly once, so every report, dashboard, and query reads the same logic. SyteRay creates these as SyteRay_ prefixed views during installation.
End the open-orders argument at your site. See SyteRay's semantic views on your data.