Syteline reporting,
read from the base tables.
You run Infor CloudSuite Industrial. Margin, on-time delivery, and inventory come out
differently depending on who ran the report and which site, date, and cost basis it
read. We build one model on your Syteline data, in your own Microsoft tenant, on
definitions written down once. Julian Bergquist leads the work and reads
coitem_mst, job_mst, and matltran_mst himself.
None of these is a broken report.
Each is a definition nobody wrote down.
A report built on the site-filtered views comes back empty from an outside connection,
because the site the application sets for itself was never set. The on-time report reads
the due date while sales remembers the request date. Margin reads current unit cost in one
report and standard cost in another. Job margin is read before close on the floor and after
variances post in finance. The field that carries the meaning is a Uf_ column
nobody documented. The audit writes each of these down.
| Number | What Syteline holds | The decision to write down |
|---|---|---|
| On-time delivery | A due date, a request date, and a projected date on each order line. When planning re-dates a line, the original due date is kept as the request date. | Which date is the promise, and how many days early or late still count. |
| Margin | A current unit cost that moves with receipts and roll-ups, and a standard unit cost that holds until it is rolled. | One cost basis for margin, stated by name. |
| Job cost | Finished quantity that moves to inventory at planned, actual, or mixed cost until the job closes, depending on a costing parameter. | Whether job margin is read before or after close, and where variances belong. |
From the Syteline technical note, which keeps the full table and its sources.
Same line, same week.
On time, late, and early.
One order line, re-dated once by planning, shipped on the 14th. Each report reads a different date and each one is computing faithfully. The model reads one promise date, named in writing, with the tolerance next to it.
Where your Syteline runs
decides how the data comes out.
On premises and multi-tenant cloud have almost nothing in common. Settle which case you are in before anyone designs a report. The audit’s first session does exactly that.
| Deployment | What you can reach | How it lands in Fabric |
|---|---|---|
| On premises | The SQL Server application database, with a read-only login. | Through an on-premises data gateway, by mirroring, a copy job, or a pipeline. |
| Multi-tenant CloudSuite Industrial | No SQL connection to the application database. Data leaves through Infor’s Data Lake. | Out of the lake by Compass, Stream Pipelines, or the ETL client, then into Fabric. |
| Hosted, single tenant | It depends on the contract. Some arrangements include database access and some do not. | As on premises if you have database access. As the multi-tenant case if you do not. |
What a Syteline build contains.
Extracts of the _mst tables you chose on purpose land untouched in a
lakehouse in your tenant, with site_ref carried on every row. A conformed
layer settles site, fiscal calendar, the promise date, the cost basis, the job-close
rule, and which Uf_ fields carry meaning. One semantic model sits on top,
each measure defined once. Controller, plant, and board views read it and drill to the
same transactions.
Anything that changes the ERP server, such as turning on change data capture for mirroring, is cleared first with whoever supports your Syteline.
- Measure
- On-time delivery, by order line
- Promise date
- Order line due date,
coitem_mst - Actual date
- The shipping transaction date
- Tolerance
- 0 days late. Up to 2 days early counts as on time.
- Partial lines
- On time when the last shipment is
- Site
site_reffiltered to the reporting site, stated on the report- Owner
- Controller
- Reconciled
- Against the ERP’s own delivery report, 2026-10-14
Alongside your Infor partner,
not instead of them.
We sell no Syteline licences, modules, or seats, and take no commission from anyone who does. Your Infor partner keeps the application. We need a read-only route to the data, agreed with whoever supports your system, and we change nothing on the ERP server without their sign-off.
At the end you hold the lakehouse, the pipelines, the model, the reports, and the measure definitions, all in your tenant, under your logins, with runbooks for refresh and for the day a cost rule changes in Syteline. Cancel the practice and it keeps working. There is no portal to pay for and nothing of ours left running in the middle.
Start with the audit.
On Syteline the audit establishes which deployment you are on and what can be reached from outside it, which sites share a database and which reports mix them, which date and cost basis each report uses today, and which modules are healthy, misconfigured, or abandoned.
- 01 Walkthrough How the ERP is really used, in the system and in the spreadsheets around it. We start with transactions, jobs, BOMs, routings, costs, and inventory, not a connector demo.
- 02 Reconcile Where margin, delivery, and inventory numbers disagree across your reports, and the specific cause of each split: cost basis, date logic, a stale rule, a copied measure, an orphaned refresh.
- 03 Grade A report card by ERP module: healthy, misconfigured, or abandoned. An honest picture of what is working, what is quietly wrong, and what was set up once and forgotten.
- 04 Recommend The next step, priced. Whether that is a model built on the system you run, a conversion to one that fits, or nothing at all, it is stated plainly, with the cost attached.
- Graded report card by module
- Reconciliation of conflicting numbers
- Priced recommendation
- On-site option, priced by size and location
Or write to hello@mfg-analytics.com. We reply with a short intake and two or three session times.
Syteline already holds the numbers. What it does not hold is the decision about which date is the promise and which cost is the cost. I write those down with your controller, then build the model so every report reads the same answer. If the audit says do nothing yet, I will say so in writing, and the report is still yours.
Julian Bergquist · Principal, MFG Analytics · About the practice