Skip to main content

Developer Reference

The Developer page answers the questions of whoever maintains, extends or audits NomaUBL: what is in this table, who writes this column, where is this setting edited and who reads it, which flows a status goes through, what this API returns. Everything on the page is generated when the application is built, from the database DDL, the table and column configuration, the settings editors, the Java sources and the OpenAPI document — it always matches the release that runs.

Open it from Documentation → Developer.

At a glance​

Developer referenceTables and columns, configuration keys, flows, impact and the API — generated at build time.TablesConfigurationFlowsImpactAPI🔍 Search table, column…INVOICE LIFECYCLEF564230 · Log / ArchiveF564231 · UBL Invoice HeaderF564235 · LifecycleF564236 · ValidationE-REPORTING ›NOTIFICATIONS ›SECURITY ›F564230Log / Archive — one row per processed documentACCESSORlogDocRENAMED TO—WRITTEN BYProcessingREAD BY6COLUMNTYPEDESCRIPTIONBTWRITESREADSFEDOCNUMBERDocument number—341FEDCTNCHAR(2)Document type—338FEUPMJNUMBERUpdate date (JDE)—512FEWDS1NCHAR(30)Batch key—29Five viewstables · config · flows · impact · APITables by flowsearch names, columns, BT codesTable cardpurpose, keys, accessor, flowsColumns grida row opens the code references

Tables​

The data dictionary of the sixteen NomaUBL tables, grouped by flow — Invoice lifecycle, E-reporting, Notifications, Security — with a search over table names, columns, comments and BT codes.

  • The table card gives the purpose and notes from the DDL, the primary key and indexes, the accessor and its configuration key, the name currently configured in the NomaUBL database settings when the table is renamed (Renamed to), and the flows that write and read it. The invoice tables carry a clickable strip of the lifecycle across tables, from the archive to the processing log.
  • The columns grid — column, override, type, description (inline and COMMENT ON of the DDL), BT code, accessor, configuration key, screens that show it, flows, write and read counts, nullable, default. A row opens the code references, writes first, grouped by flow: processing, import poll, status poll, received invoices, e-reporting, inbound, jobs, notifications, authentication, API, screens, database, command line. The grid is the shared data table; its view is listed in the List views editor.

The complete reference of the tables is also published in Database tables.

Configuration​

Every configuration key, with where it is edited and who reads it. The templates are listed on the left, grouped like the Settings navigation — Global settings, Documents, PDF templates, API and SQL connectors, E-invoicing, E-reporting, Jobs & inbound… — with their key count and their gaps. The grid shows the keys of the selected template:

ColumnDescription
KeyThe configuration key.
LabelThe field label in the settings editor.
Edited inTemplate, tab and group of the editor field.
Read byThe flows whose code reads the key.
Call sitesNumber of Java reads. A row opens the editor field and the code.
Stateeditable, read · editable, never read · read, not editable.
TemplatesTemplates that carry the key.
HintThe help text of the field.

Two check boxes isolate the gaps, one at a time: Read but not editable (a key the code reads that no screen offers) and Editable but never read (a field that has no effect). Keys built at run time — fetchAll.N.*, folder.N.*, filter.* — are not literal in the code and show as editable only.

Flows​

One short page per flow: process a file, import poll, status poll, e-reporting, watched folders, reprocess. Each gives the trigger, the command-line switch, the log module, the tables touched, the statuses written, the settings read and the steps in order. Pick a flow on the left to read it.

Impact​

What a change reaches. The picker goes in steps:

  1. the kind — Column, Configuration key or Status;
  2. the table or the template;
  3. the item, in a wide list that shows the label first.

The result lists the flows, the screens, the API endpoints and the command-line switches the item reaches, the editor field that exposes it, then the code. Endpoints come from a scan of the server routes down to their handler class; status codes and labels come from the status catalogue of the instance.

API​

The API of the instance, read the way the other views are read:

  • tag groups and tags on the left with their operation counts — Invoices & documents, Processing, Platforms, Operations, Administration, Developer;
  • one row per operation in the shared data table: method, path, summary, tag, group, access (public, any signed-in user, or the action a role must grant);
  • a window per operation with the description, the parameters and request and response samples built from the schemas, references resolved.

Getting started opens the introduction of the document (session and token, rights, responses, invoice key, dates, paging, background runs). Open the public reference (Redoc) opens the same document in Redoc, which also serves readers outside the application — see the API reference of this site.

Access​

Grant Developer in the Documentation group on the Roles page. The page reads the files generated at build time and, for the Renamed to field, the table names of the current settings; it runs no query on the invoice tables.

Tips & best practices​

  • Check Impact before renaming a column or retiring a setting. The flows and endpoints listed are what to retest.
  • Review the gaps of the Configuration view after an upgrade. A key editable, never read is a field to clean up; a key read, not editable is a setting only reachable by editing the file.
  • Send the Flows pages to a new team member before the code: they describe each chain in a page.