Infor SyteLine3 min readNetray Engineering TeamUpdated March 4, 2025

The SyteLine Open Orders Report: Why Yours Disagrees and How to Fix It

Open orders sounds like the simplest number in the building, and it is the one most likely to spark a meeting-room argument, sales says 830, operations says 820, and both reports run against the same database. The disagreement is almost never a bug. It is two different definitions hiding in two WHERE clauses. Building an accurate open orders report means making the definitional decisions explicitly, then making sure only one copy of that definition exists.

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.

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.

Key Takeaways

1The 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..
2The 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.
3What 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.