Can we get custom reports out of our Vorne XL data?

What can you already get without custom work?

Worth establishing first, because a lot of what people call a custom report is a report that already exists behind a filter. OEE Explorer ships thirteen dashboards tailored to the V2 board structure, from Executive Summary to Six Big Losses, covering OEE, TEEP, Availability, Performance and Quality down to reason codes, reject reasons and downtime. All of them are customizable, and the plant-specific views get laid out in a no-code chart builder with over 40 visualization types rather than by anybody writing code.

For output that has to leave the application, OEE Pulse exposes four export datasets - Metrics, Rejects, Job Punches and Instants. You pick the dataset, pick the columns, filter down to the devices, jobs and window you care about, and take it away as CSV, Excel or PDF. Pulse also sends consolidated performance emails across devices, so a recurring shift or day summary does not need anyone to open anything.

If what you need is one of those with different filters on it, that is something you can do yourself, not a project.

So what counts as a custom report?

Three things reliably push a request past what the built-in tools do. The number does not exist yet, because it is specific to how your plant calculates something. The report has to combine production data with data from another system, so it cannot be built from board records alone. Or the output has to be a document with a fixed shape - paginated, printable, the same every month - rather than a screen somebody scrolls.

What do people ask for?

• Printable, paginated documents. A packet that goes out with a customer complaint, a monthly plant review, a shift report that has to be signed. The requirement is real pagination by an explicit business dimension - a page per device, per plant, or per slice of the hierarchy - with print and export behavior that is reliable rather than best-effort.
• The same report sliced by hierarchy. One definition, produced per line, per area, per plant and for the enterprise, so a site meeting and a corporate review are looking at the same calculation instead of arguing about whose spreadsheet is right.
• A metric nobody else calculates. A blended OEE across lines that do not run the same way, a plant-specific efficiency or yield definition, the cost of rejects and slow running, an operator or team scoreboard with your own scoring rules on it.
• Reports that reach outside the production data. Production joined to work orders from an ERP, to labor from a time system, to maintenance from a CMMS. This is where most of the work goes, and it is worth naming the other system early because it decides the shape of everything else.
• Scheduled delivery. The right document, to the right list, in the right format, at the right time, without a person remembering to run it.
• Data into the BI tool you already use. Power BI, Tableau and Apache Superset are all on the integration list. For a plant with analysts, a starter dashboard set built against your own data and handed over to be published and extended internally often beats anything built for you to look at.
• Reporting on comments and reasons. What operators typed against downtime events, grouped and counted next to the reason codes they were filed under.

What are the inputs?

A report is measures and the dimensions you cut them by, and both are already on the records your boards write. That is the reason this work starts closer to the finish line than it sounds.

The measures are production counts, run and stop time, downtime, rejects, and what is derived from them: OEE, TEEP, Availability, Performance and Quality.

The dimensions are device, job, part, shift, team, employee, reason code and reject reason, plus your plant hierarchy. They are attached to the records already, so slicing a report by any of them is not a modelling exercise first.

The text matters more than people expect. Comments operators typed against downtime events are usually where the reason nobody coded correctly shows up, and they report like anything else.

Two things widen that set. Converted Vorne V1 history reports under the same names as V2 data, so a report can cross the changeover. And anything a report has to pull from outside - ERP work orders, a labor system, a CMMS - comes in over SQL Server, PostgreSQL, a REST API, an Excel import or a scheduling feed. The wider picture of what gets collected, and what can be added to it, is on the sibling page about custom software for Vorne XL.

What does a finished report look like?

Usually one of three things: a dashboard, a document, or a dataset in somebody else's tool. Which one it should be is worth deciding on purpose, because it is the difference between a report that gets read and one that gets exported into a spreadsheet every week by hand.

A document is where the details matter most. Filters are chosen deliberately before anything renders, rather than the report guessing and producing a hundred pages nobody asked for. Filter sets are reusable, so next month is not a re-derivation. And the export has to behave: Pulse already warns before it builds a PDF too long to read and says when a report has too many columns to sit on a page, recommending Excel instead. That is the standard a custom report has to meet too, because a PDF nobody can read is not a report.

Where does the reporting live?

On your server, alongside the rest of the suite, whether that server sits inside your network or is hosted for you. Role-based access covers operators through to executives, so a shift-level report and an executive summary are the same system rather than two. Server requirements, the network access a deployment needs and the offline installation path are on the technical specifications page.

If you are coming from a V1-era reporting tool, the closer question is what produces that report set once your boards are V2, which is covered on the page about reporting after OEE Studio. If the request is really about the software around the reporting - integrations, operator screens, displays - that is the sibling page on custom software for Vorne XL. The reporting and analytics service itself is described on our services page.