Documents

The Documents editor defines how NomaUBL turns a raw source XML spool — or an already-formed UBL invoice — into the persisted record on which the rest of the platform operates. NomaUBL is source-agnostic: the same configuration model works whether the spool comes from JD Edwards, SAP, NetSuite, a custom ERP, or any other system that can emit XML or UBL. (Only the Extract and BIP sync features are JD Edwards-specific.)

For every document type you tell NomaUBL three things:

1. Where the data comes from — the source selector picks between an XML spool that needs an XSL transform, a UBL 2.1 invoice that's already structured, and a SQL or REST connector that returns the data live without any file (Document tab).
2. How to transform each document into UBL and PDF (Processing tab).
3. How fast to run the transformation (Advanced tab).

A fourth tab — PDF Template — is dedicated to the per-document PDF layout (which sections appear, in which order, with which columns and toggles).

---

At a glance

---

Load an XML sample (optional, recommended)

At the top of the editor click Load XML sample and pick a representative spool file from your source system. Once loaded, every XPath field shows a small ⌘ browser button — clicking it opens a side drawer that lists all tag paths found in the sample, so you can pick the right tag without typing it. The drawer supports filtering and shows the value of each path as a hint.

You can configure documents without loading a sample, but the picker makes it much faster to avoid typos.

---

Tab 1 — 📄 Document

This tab tells NomaUBL where to find each piece of data on every incoming document.

Source

Field	Values	Description
Source	XML (default) / UBL / Connector / PDF	Picks the input pipeline. PDF — a text PDF from any system, converted into a flat XML and then processed exactly like an XML spool — see PDF extraction. XML — an XML spool from any source system, transformed to UBL 2.1 by the XSL pipeline. UBL — files that are already UBL 2.1 invoices (your ERP emits UBL natively, or the file came from an upstream system in UBL form); no XSL transform runs. Connector — no file at all: NomaUBL calls a SQL query or a REST endpoint that returns the document, then runs the same XSL pipeline against the result.
Direction	Issued (default) / Received	What side of the transaction this template handles. Issued — invoices the operator emits to a customer. Received — invoices the operator gets from a supplier; the row's counterparty is the supplier party, the emit-only seller actions (Resend to PA, Send completed, Credit note…) are hidden in the detail modal, and the Invoices list shows the row under the Received filter chip. Set on the received-ubl bundled template by default.

The Source choice flips the rest of this tab between three distinct sets of fields. The remaining sections of the page — Processing, Advanced, PDF Template — apply identically to all three sources. The Direction field is orthogonal: any combination of Source × Direction is valid, although Received is most often paired with UBL (PA-pushed supplier invoices).

Direction is stored on the row

The Direction value is written once on the row at insert time (column UHDRIN on F564231 — '1' for received, '2' for issued). Changing the template's Direction afterwards does not re-classify the rows that already exist — the Invoices list filter, notification rules and e-Reporting envelopes read the frozen value, not the live template setting. Pick the right Direction before processing the first invoice on a new template; flip it later only if you accept that historical rows stay on the previous side.

Document Identification (when Source = UBL)

A UBL file carries no spool to extract from, so the Activity and Type that the XML source pulls by XPath are entered here as plain text. The group sits at the top of the UBL branch and both fields are mandatory — they are written to the F564230 tracking row that the PA send and fetch-import rely on.

Field	Description
Activity	The activity code stamped on the row (e.g. UBL). Stored in F564230.FEAA10.
Type	The document type (e.g. FACTURE). Stored in F564230.FEAA20.

Why the row matters

The UBL-source pipeline inserts the same F564230 tracking row the XML pipeline produces, reading the rest of its values straight from the UBL: BT-47 buyer SIREN → FEALKY, BT-115 PayableAmount → FEAEXP, BT-2 IssueDate → FEIVD, BT-9 DueDate → FEARDU. Without it the PA send would have no row to stamp with its transaction id, FEUKIDSZ would stay empty and fetch-import would have nothing to poll. Replace mode updates the existing row instead of duplicating it; non-replace mode skips an already-processed invoice with the usual warning.

Document key (when Source = UBL)

The Document key (doc / dct / kco) group decides how a UBL document gets its (doc, dct, kco) primary key — the same triplet that identifies the document everywhere else in NomaUBL. The Key mode selector offers two ways:

Key mode	Behaviour
From cbc:ID (regex pattern) (default)	The key is parsed from the invoice's cbc:ID with a regex — see below.
Sequence (NomaUBL numbers the document)	NomaUBL hands out the document number itself, under a fixed document type and company.

Sequence mode

Meant for received invoices, whose cbc:ID follows each supplier's own format, and usable for emitted UBL when the numbering format is not known.

Field	Description
Document type (dct)	Fixed JDE document type of the sequence — II (incoming invoice) when empty. Pick a type JD Edwards does not use for the same company.
Company (kco)	Fixed company code. Required.
Sequence start	First number handed out; afterwards, one above the highest number stored for this document type and company.

The supplier's invoice number stays stored as the UBL number (BT-1). Each processing hands out a new number: a document received twice gets two numbers.

From cbc:ID (regex pattern)

The key is parsed from the invoice's cbc:ID via a regex with named groups. There is no filename convention to follow; the file can be named anything.

Field	Description
ID Pattern	Regex applied to cbc:ID. Allowed groups: doc, dct, kco. Any subset is allowed; missing groups fall back to the defaults below.
doc default	Used when the regex does not match or the doc group is missing.
dct default	Used when the dct group is missing.
kco default	Used when the kco group is missing — common when the cbc:ID does not include a company code.

Sample cbc:ID + Suggest + Test helper

To avoid writing the regex by hand, the section includes a small inline assistant:

Action	Effect
Sample cbc:ID	Paste a real ID from one of your invoices (e.g. 38706889RI00001 or F202600025).
Suggest	Generates an idPattern by splitting the sample on letter / digit transitions, fills in the matching defaults, and runs Test on the result.
Test	Runs the current idPattern + defaults against the sample and shows the extracted (doc, dct, kco) live — green when it matches, red on a regex error.

Worked examples:

Sample	Suggested idPattern	Defaults	Extracted
F202600025	^(?<dct>[A-Z]+)(?<doc>\d+)$	kcoDefault = 00001	doc=202600025, dct=F, kco=00001
38706889RI00001	^(?<doc>\d+)(?<dct>[A-Z]+)(?<kco>\d+)$	(none)	doc=38706889, dct=RI, kco=00001

Document number lookup (when Source = UBL)

On a Received template, the UBL's cbc:ID is the supplier's invoice number — not the operator's internal key. The default Suggest + Test regex-on-cbc:ID path then no longer makes sense: the operator needs to look the internal (doc, dct, kco) triplet up from supplier-side fields (UBL number, supplier name, supplier VAT, etc.).

A new Document number lookup group on the Document tab (visible only when Source = UBL) wires the lookup against a SQL connector or an API connector.

Field	Description
Connector	The SQL or API connector that holds the lookup query / endpoint.
Target	The named query (SQL) or endpoint (API) on the selected connector. Parameters declared by the target become the placeholder set the lookup can supply.
Parameter values	Free text + placeholders mapped per target parameter. Supplier-side placeholders available out of the box: {ublNumber}, {supplierName}, {supplierVat}, {supplierAddress}, {issueDate}, {totalTtc}, {currency}.
Mapping	Which response fields hold the resolved doc, dct and kco. Defaults to the first row's columns of those names on a SQL connector; on an API connector pick the JSON keys with the same picker used elsewhere.

When the group is filled in, the lookup runs before the regex-on-cbc:ID path and its result wins. Leave the group empty to keep the legacy behaviour — the regex assistant and the (doc, dct, kco) defaults below continue to apply unchanged.

The bundled received-ubl template ships with this group present but empty: pick the connector and the target in Settings → Documents, fill in the parameters, and the receive-side flow is wired end-to-end.

Input folder and routing (when Source = UBL)

A UBL-source template scans its own input folder <input>/<template> — the same per-template convention as an XML template — so several UBL templates can run on schedule against different folders. A UBL file that processes successfully is removed from the folder; a file that fails, and validation-only runs, keep it.

Each UBL invoice is validated and routed by its own transaction type — B2B, B2G, B2C or B2B international — read from the invoice's routing note, so a batch mixing types is handled file by file. A file that carries no routing note uses the template's default document type.

Connector source (when Source = Connector)

When Source is Connector, NomaUBL fetches the document data live from a SQL connector or an API connector instead of reading a file. The same XSLT pipeline then turns the result into UBL — no spool, no file watcher, no transient directory.

Two patterns are supported:

Mode	When to use it
Single call	One query / endpoint returns the header and the nested line array in one shot. Best when the source can join the header with its lines server-side (typical for a SQL view or a REST endpoint built for invoicing).
Two calls	One call returns the header, a second one returns the lines. Useful when the line endpoint accepts the header keys as parameters ({customer}, {docNumber}…) — line parameters can reuse any value returned by the header call via {header.field} placeholders.

Header source

Pick a SQL or API connector, then its query or endpoint. Optional parameters become the form fields shown on Process Document.

Lines source (optional)

Leave empty for single-call mode. Otherwise pick a second connector — its parameters can read every value the header call returned, including the keys themselves.

Output shape

The connector response is materialised as an XML document with the same shape an XML spool would have, so the existing XSLT chain runs without change. Every XPath you already use still applies.

Once a connector is wired, the rest of Tab 1 (Burst Key, Document Identification, Document Data, Date format) reads exactly like Source = XML — the XPath fields point at the XML shape produced by the connector response, not at a file on disk. Use Load connector sample in the XSL Editor to pull a real response so the XPath picker autocompletes against actual data.

Running a connector-sourced document is described on Processing → Process Document: the page replaces the file picker with the parameter form derived from the header connector. The same parameters are passed from the CLI via repeatable --param key=value arguments (see Command Line).

Bursting (Document Root) (when Source = XML)

Field	Description
Burst Key	XML tag name used to split the spool into individual documents. This element marks the root of one document — every occurrence in the spool produces one output document.

Document Identification (when Source = XML)

NomaUBL uses these five fields to know which document it is, who owns it, and what business type it belongs to. Each field accepts a default for cases where the tag is absent.

Field	Maps to source-system concept
Activity	Business activity / module the document belongs to.
Type	Document type code as known in NomaUBL.
Document ID	Invoice number / document number.
Document Type (JDE)	Document type as defined in the source system (named after JD Edwards' RI/RM codes, but works with any source value).
Company (JDE)	Company / business unit owning the document in the source system (legacy field name, applies to any ERP).

Document Data (XPath) (when Source = XML)

Functional data NomaUBL reads from the spool to populate the UBL invoice and to drive routing.

Field	Description
Customer Number	Customer / address book number.
Amount	Document gross amount.
Document Date	Issue date of the document.
Due Date	Payment due date.
Routing Code	Code used to route the document to the correct delivery channel: archive, email, postal mail, dispatch to a Plateforme Agréée, etc.
Office	XML tag in the spool that contains the office / business unit code.
Processing Type	XML tag carrying the processing-type code (B2B, B2BINT…). Leave empty to fall back to the default defined in Document Types.

💡 Each Document Data field has its own default value. Defaults are used when the XML tag is missing or empty, which is useful when a value is constant for a given template.

Date format (when Source = XML)

Field	Default	Description
dateInputFormat	yyyy-MM-dd (ISO)	Java SimpleDateFormat pattern used to parse document and due dates extracted from the source XML before they are written to F564230 / F564231. UBL sources are always ISO (the XSL emits ISO); on XML sources the spool format is locale-dependent (dd/MM/yyyy for many French ERPs, MM/dd/yyyy for North-American spools, etc.).

Pick the pattern that matches the source dates literally. Common values:

Source date sample	Pattern
2026-05-12	yyyy-MM-dd (default — ISO)
12/05/2026	dd/MM/yyyy
12.05.2026	dd.MM.yyyy
05/12/2026	MM/dd/yyyy
20260512	yyyyMMdd

The pattern applies only when the document's Source is XML. UBL sources keep emitting ISO through the XSL, so the field is ignored there. The default keeps existing UBL flows back-compat without any edit.

PDF extraction (when Source = PDF)

With Source = PDF, the template takes a text PDF from any system — not only JD Edwards — and converts it into a flat XML that the XSL editor maps like a spool. The conversion rebuilds the page layout and writes what it reads; it knows nothing about invoices. Scanned PDFs (images without text) are refused with an explicit error.

What the PDF holds	What the XML gets
A row read as Label : value (or label and value in two columns)	One element named after the label — Montant TTC 1 189,55 € → <Montant_TTC>1189.55</Montant_TTC>. Amounts and percents use a dot decimal, dd/MM/yyyy dates become ISO, identifiers printed with spaces (VAT number, SIREN, postal code) are compacted.
A rate inside a label (TVA 20,00%)	A sibling element, so the name stays stable: <TVA>198.26</TVA><TVA_taux>20.00</TVA_taux>.
A value made of segments separated by /, some carrying their own label (VIREMENT / IBAN : FR76 … / BIC : CCBPFRPPBDX / Titulaire : ACME SA)	The unlabelled part stays in the element and each labelled segment becomes a sibling — Paiement, Paiement_IBAN, Paiement_BIC, Paiement_Titulaire — each mappable on its own; grouping spaces inside the IBAN are removed.
A period (01/09/2026 – 30/09/2026)	Its two bounds as <…_debut> and <…_fin>, each mappable to its own UBL field.
The table between the start and end anchors	<Lignes>/<Ligne>, columns named after the header row (inferred from the first row when the header is a single cell); wrapped labels are merged, a ruled line closes the table.
The party boxes	<Adresse_N> blocks — Nom, Rue lines, Code_postal, Ville, Pays, plus the labelled lines printed in the box (supplier code, SIRET, VAT, phone, e-mail).
Every printed row	<Textes>/<Texte n="…" page="…">, cells separated by |, so anything the rules above missed stays reachable by XPath.
The file itself	<FichierPDF> with its path — use {FichierPDF} as an additional attachment to embed the original PDF in the UBL.

The PDF extraction group sets the conversion:

Field	Description
Table start	Regex matched on a row: that row's cells name the table columns (e.g. PRESTATION | Qté | P.U. HT | Montant HT).
Table end	Regex matched on the first row after the table — the row itself is not part of it.
Layout match	Optional regex the page text must contain; a file that does not match is refused — useful when a folder mixes several layouts.
Page match	Optional regex: only the pages whose text matches are converted — a print holding a statement and the invoice keeps the invoice pages only.
Field 1 … Field 5	Name|regex run on the page text; the first group (else the whole match) becomes <Name>. Add =>text to rewrite the match, $1 allowed — Type_JDE|^FACTURE=>F9. Two fields may share a name when only one of them can match.

A converted sample looks like this:

<Document fichier="invoice-2026-0412.pdf" pages="1">
  <Numero>F2026-0412</Numero>
  <Date_document>2026-10-05</Date_document>
  <Période>01/09/2026 – 30/09/2026</Période>
  <Période_debut>2026-09-01</Période_debut>
  <Période_fin>2026-09-30</Période_fin>
  <TVA>198.26</TVA>
  <TVA_taux>20.00</TVA_taux>
  <Montant_TTC>1189.55</Montant_TTC>
  <Adresse_1>
    <Nom>ACME SERVICES</Nom>
    <Rue>12 rue des Lilas</Rue>
    <Code_postal>75011</Code_postal>
    <Ville>PARIS</Ville>
    <SIRET>80320631700015</SIRET>
  </Adresse_1>
  <Lignes>
    <Ligne><PRESTATION>Maintenance</PRESTATION><Qté>1</Qté><P_U_HT>991.29</P_U_HT><Montant_HT>991.29</Montant_HT></Ligne>
  </Lignes>
  <Textes>
    <Texte n="1" page="1">FACTURE | N° : F2026-0412</Texte>
  </Textes>
  <FichierPDF>/data/input/invoices/invoice-2026-0412.pdf</FichierPDF>
</Document>

The document editor and the XSL editor both load a sample straight from a PDF — the PDF is converted server-side with the template's saved settings (save the template first after changing the anchors). The Process Document page, the watched folders and the command line process PDF-source templates like XML ones; -pdf2xml <in.pdf> <out.xml> --text converts a single file on its own (see Command line).

---

Tab 2 — 🔧 Processing

This tab controls what NomaUBL does with the data extracted in Tab 1. It applies to both XML and UBL sources, although several fields (XSL, RTF) are only meaningful on the XML pipeline.

XSL Transformation

Field	Values	Description
Transform	Y / N	Whether to apply an XSL transformation pipeline before generating UBL.
XSL Pre-processing	path	Optional XSL applied before indexation, e.g. to normalise the raw source XML (JD Edwards, SAP, NetSuite, custom ERP…). It must be safe to run twice: a reprocess replays the archived source, which already went through it — guard every element the XSL adds with not(...) so a second pass adds nothing.
XSL Indexation	path	XSL used to generate the indexation / metadata applied to the document. Produces an XML file paired with the generated PDF for indexing purposes.
RTF Template	path	RTF template used by BI Publisher to render the human-readable PDF.

UBL

Field	Values	Description
UBL XSLT	path	XSL transform from the source XML to UBL 2.1. The placeholder %APP_HOME% is expanded to the NomaUBL install root.
Custom Schematron	path(s)	One or more precompiled Schematron stylesheets (.xsl, comma-separated, %APP_HOME% / %ENV% accepted) holding this customer's own rules — a mandatory classification, a buyer-reference pattern… They run after the standard packs, on this template only, so customer rules never touch the shipped packs the upgrade refreshes. A stylesheet is loaded once per file stamp: an edited file is picked up on the next validation without a restart. Findings land in the validation errors under a short source derived from the file name (BR-ACME-rules.xsl → ACME); a missing or broken file is reported as an error on the invoice. Batch and single processing, the Validate button and the validate API all honour it.
Rule set	(blank = derived) / EN 16931 basic / EN 16931 / France extended (CTC)	The standard the document is produced under: the validation packs and the required fields shown in the XSL editor's mapping tab come from this set. Blank keeps the choice derived from the customization id of the UBL defaults. See Rule sets.
Post-transform	path	Stylesheet run on the validated UBL to write another syntax next to it — for example the shipped ubl-to-cii.xsl (UBL to CII D16B). Blank = none. See Post-transform.
Post-transform output	suffix, default -cii.xml	Replaces the .xml of the UBL file name; the download of the invoice and document windows uses the same name.
Post-transform name	text	Short name of the converted syntax on the download buttons (CII → Download CII). The platform connector can send the converted file with {{derivedContent}} / {{derivedFilePath}}.
Attachment	— None / create / attach / generate	How the main PDF is associated with the UBL. create = render via RTF / BI Publisher and embed it. attach = reuse a PDF already in the input directory. generate = render the PDF with the PDF-template designer and attach it as a PJA (cac:AdditionalDocumentReference) — use it when the designed PDF isn't a compliant French readable copy. Empty = no PDF. Independent of LISIBLE below.
LISIBLE	Y / N	When Y, render a readable PDF from the UBL through the resolved PDF template and embed it as the LISIBLE copy (cbc:ID="LISIBLE"). Independent of Attachment — both can be on.
Invert sign	N – No (default) / Credit notes only / All documents	Flips the sign of the amounts read from the source: line net amounts, document totals, prepaid and rounding amounts, total VAT and every VAT breakdown row. The unit price is always emitted as a positive value, allowance and charge amounts are read as absolute values, and the quantity takes the sign of its line amount. Credit notes only applies to documents resolved as 381, 396, 261, 262, 502 or 503. A spool that prints a credit note with negative amounts thus yields the positive CreditNote the standard expects, with no change to the document XSL.

Processing rules

The Processing rules group routes the documents of the XML pipeline before anything is generated. Each rule combines one or more conditions on the document with one outcome. Rules are evaluated per document once its document type is resolved, in order — the first match wins; no matching rule means normal processing. They apply to every XML ingestion path: scheduler, watched folders, process, fetch-single and Fetch Input. UBL-source documents are deliberately left out — their transaction type is already written in the document.

GratuitiesTreat as document type ▾ARCHIVEONLY ▾↑ ↓ Remove

ifInvoice amount (montant) ▾is zero / empty ▾

＋ Add condition

Internal documentsExclude (record only) ▾↑ ↓ Remove

ifJDE document type (typeJDE) ▾in list (a, b, c) ▾RX, RZ

＋ Add condition

＋ Add rule

Outcome	Effect
Treat as document type	The document continues as the chosen document type, with that type's send / validate / mode / keep settings — e.g. a zero-amount gratuity routed to ARCHIVEONLY.
Exclude (record only)	The document is only recorded: its source is archived and its header stored, with the status Excluded by rule (9914, the message being the rule name) and a lifecycle event. It is visible in the invoice list and counted by the integrity checks, but never validated, output nor sent.

Conditions — every condition of a rule must match (if … and …). Fields: JDE document type, resolved document type, processing type (raw spool value), invoice amount, company, activity code, type piece, customer number, document number, or XPath on the document… (any XPath or spool tag, e.g. Code_Nature_ID12). Operators: in list / not in list (RM, RX), =, ≠, is zero / empty, is not zero, <, >, is empty, is not empty, matches regex. ↑ / ↓ reorder the rules; the rule name shows in the log and in the status message.

Additional Attachments

Beyond the main human-readable PDF, a document type can embed extra files into the UBL — a delivery note, a purchase order, bank details, an annex. Add one row per file:

Field	Description
Code	The attachment's business code, picked from a dropdown (delivery note, purchase order, RIB, annex…). It tags the embedded file inside the UBL so the recipient knows what each attachment is.
Path	Where to read the file from. Supports the path placeholders %APP_HOME%, %ENV%, %DOCNAME%, %KCO%, %DOC%, %DCT% and any {{token}} from the invoice catalogue, so the path resolves per invoice — e.g. %APP_HOME%/cgv/CGV_{{kco}}.pdf.

The { } button next to the path field opens a searchable token list and inserts the chosen token at the cursor — the invoice catalogue tokens ({{kco}}, {{fedoc}}, …) and the path constants %APP_HOME%, %ENV%, %PROCESS_HOME% — so you don't have to remember the exact spelling. Add attachment adds another row.

UBL-source templates embed attachments too

A template with Source = UBL embeds the same PDFs as the XML flow — after validation and before the database insert, so the stored UBL matches what is sent to the PA:

• Attachment attach embeds a sibling PDF from the input directory under cbc:ID="PJA".
• The readable PDF (lisible) is rendered straight from the parsed UBL by the modern PDF engine and embedded under cbc:ID="LISIBLE" (DocumentTypeCode 916).
• Additional Attachments loop exactly as above; the path tokens resolve per invoice.

attachment=create stays unsupported for UBL source — it needs BI Publisher rendering from a source XML, which a UBL file doesn't have. Use attach or lisible instead.

Output

Field	Description
No-Data Key	Name of an XML element that must exist in the spool. If absent, NomaUBL considers the document empty and skips it. Useful to filter out spool sections that aren't real invoices.
Set Locale	Locale used to render the PDF (e.g. en_US, fr_FR). Affects date and number formatting in the PDF only.
Allow reprocess	Y / N (default N). When Y, invoices produced from this template can be reprocessed — rebuilt from the JDE XML source archived at first submission — when they were deposited but not transmitted (status 200, reason NON_TRANSMISE). Reprocessing regenerates the e-invoice, PDF and XML, keeps the invoice's current status, records a Retraitement entry in its history and never re-sends to the platform; each invoice is reprocessed once. XML and PDF sources are eligible. Reprocessing is triggered from the Invoices list, the IT dashboard or the CLI.
Allow full reprocess	Y / N (default N). When Y, an invoice in Validation failed (9905) can be reprocessed in full from its archived source once the data was corrected at the source: the enrichment is queried again, the UBL regenerated, validated and sent to the PA when the template and document type say so. The status history is kept and a reprocess marker opens a new cycle. XML and PDF sources. Triggered from the invoice window (Reprocess button on a 9905), the Invoices list, the IT dashboard, the API (kind: "full") or -reprocess --full.

---

Tab 3 — ⚙️ Advanced

Field	Description
Number of CPUs	Number of parallel threads used by the processing pipeline for this document type. Increase to speed up large spools, decrease if the host is under memory pressure. Default: 4.

---

Tab 4 — 🖼 PDF Template

The fourth tab picks the PDF layout applied when this document is rendered. Layouts are first-class shareable resources stored in config-pdf.json and edited on the dedicated PDF Templates page — this tab simply references one of them by name via the template's pdfTemplate property.

Field	Description
PDF Template	Dropdown listing every saved layout (the pdf-template resources from PDF Templates), plus the bundled built-in. Leave empty to fall back to the global default (global.defaultPdfTemplate); empty + no global default falls back to built-in.

The resolution chain at render time is therefore: this field → global.defaultPdfTemplate → built-in. Every persisted invoice carries the document name in F564231.UHTMPL, so the PDF generator re-renders on demand against the layout that was active for that document.

Editing the layout itself

The visual editor — section list, per-section drawer, live preview, block sections — lives on Management → PDF Templates. Open it once to author or tune a layout, then come back here to point the document at it. A single layout can serve many documents.

---

Tab 5 — 🔗 Enrichment

When the source spool is missing data the invoice needs — a customer's VAT number, a label from a reference table — the Enrichment tab fetches it from a SQL or API connector and injects it into the spool before the XSL transform runs. The fetched values then map in the XSL editor like any other spool field, and are archived with the source.

Each rule describes one lookup:

Setting	What it does
Scope	An XPath that picks where the rule applies — the whole document, or a repeating node such as each invoice line. Fields from that scope feed the lookup, and the results are written back inside it.
Connector + query / endpoint	The SQL query or REST endpoint to call.
Parameters	Fields taken from the scope, sent as query / endpoint parameters.
Output	Each returned column / field → the name of the new element written into the spool.
Target	Where the new elements land — on the scope node itself, in a new group, or in an existing group.
Result	A single flat set of fields, or a repeating group (one child per returned row).

Rules run in order, so a later rule can use what an earlier one added; identical lookups are cached, so the connector is called once per distinct key. The enriched spool is stored with the archived source (F564230), so a reprint doesn't call the connector again. A full reprocess queries it again, and the enrichment then replaces the rows of the previous run instead of adding to them (single-row rules already overwrote their fields). Nothing runs unless a rule is configured — existing templates are unaffected.

Dry run — with a sample spool loaded, Dry run tries the rules against it: it calls the real connectors and shows the enriched XML, a summary and any warnings, without changing anything. Download the result (named after the sample, e.g. 26000001CG00005_enrich.xml) to build the XSL mapping straight away.

---

Tips & best practices

• Always set defaults on Document Identification fields — they save you from spool variations that omit a tag occasionally.
• For UBL sources, use Suggest to bootstrap the regex — it handles the common patterns (digits-only, letters + digits, digits + letters + digits). Tweak by hand only when the format is unusual.
• Leave Processing Type empty unless this template needs to override the per-document-type default; this keeps the configuration DRY.
• For new document types, start by loading an XML sample, configure Tab 1 using the picker, then test on a few documents before tuning the XSL chain in Tab 2.
• The Burst Key is the most critical XML field — getting it wrong produces either one giant document or no documents at all.
• Edit the PDF layout on its own page. PDF Templates hosts the visual editor with the live preview; this tab just picks the right one. Sharing one layout across several documents avoids editing N copies when a legal mention or a column set changes.