Technical Report
The Technical report tab of the Reports page writes the developer documentation of the release: how NomaUBL is built, what each table and configuration key is for, which flows touch them, what the API offers. It is generated from the code scans bundled in the application at build — the same sources as the Developer reference — so it is identical on every instance of a release, whatever the source system (JD Edwards, SAP, NetSuite or a custom ERP).
It complements the two other documents of the page: the implementation report describes how this instance is configured, the audit report what happened over a period.
At a glance
Controls
| Control | Description |
|---|---|
| Language | French or English; defaults to the interface language. |
| Date label (cover) | Free text printed on the cover; blank = today's date. |
| Sections | The eleven sections, all ticked by default; each shows its id. |
| Detail every API operation (description and parameters) | Shown when API reference is ticked. Off by default: the reference then lists the operations with their access only. |
| Include the code snippets in the appendix (long) | Shown when Appendix: code references is ticked. Off by default. |
| Download PDF / Download Markdown | Generates the file and downloads it (nomaubl-technical-<date>-<time>.pdf or .md). A copy is kept in the environment's reports folder. |
Sections
| Section (id) | Content |
|---|---|
Scope (scope) | The NomaUBL release, its build date, the code scan behind the document, the generation date and author, and the environment whose table names are resolved. |
Architecture (architecture) | Components (interface, server, platform clients, reports), runtime (one folder and one server per environment) and security (authentication, sessions). |
Data model (data) | Every table with its columns, the configuration keys, flows and call sites that use them, and the name resolved in this instance when it differs. |
Flows (flows) | The flow documents — process a file, import poll, status poll, e-reporting, watched folders, reprocess — each completed with the tables, statuses and keys its code touches. |
Configuration reference (configuration) | Every key with its settings field, where it is edited, the flows that read it, its call sites and its state, with a summary of the gaps. |
Status model (statuses) | Invoice and e-reporting statuses: tags, codes, labels, groups and the flows that set them. |
Impact matrix (impact) | Per flow, the most referenced columns and keys. |
API reference (api) | The operations of the API with the access each requires; with the option, their description and parameters. |
Command line (cli) | The switches, from the built-in help. |
Build and packaging (build) | The build steps, the generated artefacts and the layout of the jar. |
Appendix: code references (appendix) | The code references behind the sections; with the option, the snippets. |
Command line and API
java -jar nomaubl.jar -techreport /opt/nomaubl/demo/config/config.json [--lang fr|en] [--format md|pdf] [--out <file>] [--date <label>] [--sections a,b,...] [--api-detail] [--snippets]
Defaults: every section, Markdown, French, output nomaubl-technical-<lang>.md in the current folder (the command line keeps no copy in reports). See Command line.
The API route is GET /api/reports/technical with the parameters lang, format, date, sections, apiDetail and snippets.
Access
The tab belongs to the Reports page — grant Reports on the Roles page. Generating the report also requires the Settings access feature.
Tips & best practices
- Generate it at each upgrade and keep it with the release notes: it is the developer view of what changed.
- Hand it to an integrator with the implementation report of the instance: the first explains the product, the second its configuration.
- Tick only the sections needed for a focused document — the data model and the configuration reference for a database or settings question, the API reference for an integration.