Form Engine
Whenever possible, report data should come from business models and document fields, reducing secondary processing in Excel; when the model changes, the report metrics can be governed accordingly.
Custom report formats and algorithms, combined with dashboards and large screens — the metric standards share the same source as business documents, rather than being another set of 'export and reprocess'.
The reporting engine addresses the final mile of 'using data' for operations and on-site needs: formatted reports, aggregation algorithms, management dashboards, and large screens in workshops/warehouses. Indicators should be derived as much as possible from business models and document records to avoid discrepancies caused by secondary processing in Excel. The permission engine restricts who can see which rows and which sensitive indicators; organizational dimension filtering reuses the department tree.
Runtime queries can be exported as text and charts, or as Office, HTML, and Markdown, for reporting. They do not replace report configuration or official definitions. Delivery attainment, OEE, first-pass yield, inventory accuracy, project load, and labor cost can still be shown together on reports and large screens, with multilingual labels for overseas management.
Whenever possible, report data should come from business models and document fields, reducing secondary processing in Excel; when the model changes, the report metrics can be governed accordingly.
Who can see which rows and which sensitive indicators is consistent with the authorized model; querying and drilling down should not exceed permissions, and exporting and casting to a screen are equally restricted.
Department/organization dimension filters reuse the organization tree, and when comparing multiple factories, the dimension definitions are unified to avoid having two sets of algorithms: 'by workshop' and 'by department'.
Design-time can create report and large-screen pages. Runtime queries can be exported for reporting. Official definitions stay with the reporting engine. Exports do not change metric definitions or bypass permissions.
| Breakpoint | Common cause | Control lever |
|---|---|---|
| Multiple versions of the same indicator | Report Direct-Connected Copy Table | Priority Data Retrieval Business Model/Document |
| Unauthorized indicators seen on the big screen | The large screen is not included in the authorization | Function synchronized with row-level scope |
| After changing the denominator definition, the target does not move | Set the goal first, then determine the definition | Set the target after the definition is frozen |
| Unable to drill down on the query results | Indicator not linked to source | Drill down to the document level in runtime |
| Cross-factory summary string dimension | Organization selection is inconsistent with the tree | Unified Organization Dimension Field |
| Manual Excel is still the data source for large screens | Unclosed data retrieval | Bind publishing indicators to data objects |
| After the monthly settlement, the indicators still change according to the documents | The rules for the recognition date are unclear | Written Attribution Date and Account Locking Strategy |
Common combined indicators include WMS inventory accuracy, MES OEE and downtime, QMS first-pass yield and defect Pareto, SRM OTIF, CRM accounts receivable aging, PMS load, and EHR labor costs: naming and definitions should be unified at the report level, and embedded charts in products and platform dashboards should avoid each calculating separately. For multi-factory comparisons, organizational selection must come from the organizational tree; the rules for the posting date (by business day/by posting day) should be clearly stated in the indicator ledger, and after month-end, documents should not silently change historical indicators.