Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt

Use this file to discover all available pages before exploring further.

The Reporter Module uses a small set of core objects. They are related, but the operator does not always start by creating a Data Source. In some environments, internal Data Sources for Lerian products such as Midaz or CRM are already configured. This page is the shortest path to the mental model.

​
Core flow

Reporter has two common entry paths:
  • Internal product data already configured: Template → Report → Download
  • External or missing data connection: Data Source → Template → Report → Download
  • The Template says what the report should look like and in which format.
  • The Data Source says where the data comes from. It may already exist for internal products or be added manually for external databases.
  • The Report is the generated file, produced by running a Template against the connected data, optionally narrowed by filters.
  • The Download is the operator action that takes the finished file out of the Console.

​
What each object means

ObjectWhat it representsWhy it exists first or later
Data SourceA configured data connection. It can be an internal product connection already created for the environment, or an external database connection such as PostgreSQL or MongoDB.It exists before generation, but the operator only needs to create one manually when the required connection is not already configured.
TemplateA reusable definition of structure and output format (CSV, XML, HTML, TXT, or PDF), uploaded as a .tpl file or built visually with the Template Builder.It describes what the report should look like. It does not execute anything by itself.
FilterAn optional rule applied at generation time (Database + Table + Field + Operator + Value).It narrows the data used for a single Report run, without changing the Template.
ReportThe output produced when a Template is run against the data. Has a status (Processing, Finished, Failed, Error).It is the actual artifact the operator delivers.
PreviewThe in-Console view of a Finished report, adapted to its output format.It lets the operator validate the result before sending it out.
DownloadThe action that takes the finished report file out of the Console in its configured format.It is the operational endpoint of the whole flow.
ReminderAn optional delivery deadline tracked from the Overview page (Once, Daily, Weekly, Monthly, Semiannual, Annual).Used when a Report has a recurring delivery cadence to manage operationally.

​
When a Template becomes a Report

A Template by itself is just a definition. It becomes a Report at one specific moment: when you click Generate Report in the 4-step wizard on the Reports page. At that point:
  1. Reporter takes the selected Template.
  2. It applies any filters you configured.
  3. It reads from the Data Sources referenced by the Template.
  4. It produces a file in the Template’s output format and adds it to the Reports list with Processing status.
  5. When generation finishes, the status moves to Finished and the file becomes downloadable.
Until that moment, you have only a template. After that moment, you have a report.

​
Which fields actually matter

When operators get stuck, it is usually around the same handful of fields. This is the short list of the ones with real operational effect.

​
When checking or adding a Data Source

  • Connection Name — How the connection shows up everywhere else (in templates, in report filters). For external Data Sources, pick something that identifies the environment, not just the engine (e.g., production-db, not just postgres).
  • Database Type — Determines the default port, whether schemas are supported, and the connection driver used.
  • Host / Port / Database Name / Username / Password — The minimum required to reach the database.
  • Schemas (PostgreSQL, Oracle, SQL Server) — Limits which schemas Reporter can browse. Leave empty to use the default (public) for engines that support it.
  • SSL Configuration — Optional, but use it whenever the network path is not fully trusted.

​
When adding a Template

  • .tpl file (upload mode) — The actual template definition. Required.
  • Template Name — How the Template appears in lists and pickers.
  • Output Format — Locks the final file type (CSV, XML, HTML, TXT, or PDF). When PDF is selected in the Template Builder, the generated code is HTML, rendered as PDF at generation time.

​
When generating a Report

  • Template — The Template you want to run.
  • Filters (optional) — Each row is Database + Table + Field + Operator + Value(s). Use filters to produce a narrower slice without editing the Template.

​
Practical reading of the UI

Use this interpretation when guiding users:
  • Templates defines what the output should look like.
  • Reports is where the structure and the data come together and produce a file.
  • Data Sources defines what Reporter is allowed to read. Use it to inspect existing connections, test connectivity, or add external databases.
  • Overview is the operational dashboard: KPIs, the delivery calendar, and reminders for upcoming or overdue deliveries.

​
When users usually get lost

A Template is a definition. A Report is a generated file. The same Template can be turned into many Reports over time (each with its own filters, run date, and status).
The Data Source is the connection Reporter uses to read data. A Filter is a per-run narrowing that does not change the Template or the Data Source — only what data the current Report includes.
The Template Builder generates .tpl code from blocks you assemble in the Console. Uploading a .tpl skips the builder and uses a file prepared externally. Both end up as the same kind of Template, but only builder-created templates can be re-edited in the visual editor.
A Report reaching Finished means the file is generated and downloadable. Whether it was actually delivered (sent to a regulator, archived, etc.) is tracked separately via reminders on the Overview page.
Pair this page with Setup path when onboarding new users. One page explains the model; the other explains the order.