Rihards Gailums
66ce42ea37
Three corrections grounded in the UAPF SSOT specification (UAPFormat/ UAPF-specification, specification/01-concepts.md, 04-folder-structure.md, 05-level-composition.md, 10-conformance-checklist.md), which had not been read in full before the initial workspace build. 1. Level relabel. The FG3 sub-process stubs fg3-2, fg3-3 and fg3-6 had been marked level: 4 by template inheritance from fg3-1 at Step 4 of the build, despite carrying no BPMN and no resources. Per the spec conformance checklist this fails the L4 requirement. The three are composition placeholders, which the spec models as L3 (composed subprocess / variant). Their uapf.yaml is now level: 3 with cornerstones.bpmn: false — conformant: L1-L3 packages MUST NOT duplicate L4 content. The three real executables fg3-1, fg3-4 and fg3-5 remain L4. 2. BPMN Diagram Interchange. All five .bpmn files in the workspace now carry a bpmndi:BPMNDiagram with BPMNShape and BPMNEdge elements produced by a swim-lane left-to-right auto-layout, so the diagrams preview in bpmn.io, Camunda Modeler and ProcessGit's web view. The spec doesn't require DI (its own examples have none) but practical reviewability does. 3. Transcoder. tools/register-transcoder gains bpmn_di.py — also runnable standalone for retrofitting existing BPMN files. transcode.py now imports it and emits DI by default for newly generated skeletons. sample-output/3.5.2.skeleton.bpmn and 3.5.3.skeleton.bpmn regenerated with DI; the logical-model content is byte-identical to the previous commit, only DI is added. docs/methodology.md updated: adds an explicit Workspace-structure section grounding L0-L4 in the SSOT spec, a Conformance-correction section documenting the Step-4 mislabel and its fix, and drops the now-untrue 'no DI' line from limitations. Validation after the change, full L1-L4 sweep: uapf-cli validate green on all 10 packages (domains/gramatvediba, fg1-fg6, fg3, fg3-1..fg3-6); xmllint clean on all 8 .bpmn/.dmn; every .bpmn has BPMNDiagram present.
FG3-4 — Saimnieciskā norēķina veikšana
Level 4 atomic executable process for economic-expense settlement — the handling of advances and the reconciliation of advances against documented employee expenses. The second FG3 sub-process taken to executable depth.
- UAPF level: L4 (atomic executable)
- Package id:
vk.gramatvediba.fg3-4 - Included by:
processes/fg3(function group FG3). - Source: Valsts Kase Grāmatvedības uzskaites procesu apraksts — FG3 process register, section 3.5.2 (Saimnieciskie norēķini un to kustība) and section 3.5.4 (Avansa atmaksas).
Process
bpmn/saimnieciska-norekina.bpmn (Process_SaimnieciskaNorekina) transcribes
the economic-settlement flow across three lanes mapped from the source RACI
columns:
- Nodarbinātais — submits the advance request (3.5.2.1) and the expense settlement with supporting documents (3.5.2.2).
- Iestāde — approves the advance request and the settlement, and informs the employee of any repayment (3.5.4.2).
- VPC — processes the settlement (3.5.2.3), reconciles it, and prepares a repayment request (3.5.4.1), an additional payment, or posts the document.
Flow: advance request → approval → settlement submission → approval → VPC processing → reconciliation decision → one of three outcomes. Two terminating states: settlement posted or advance repayment requested.
Decision
dmn/avansa-norekins.dmn (Decision_AvansaNorekins) is a FIRST hit-policy
decision table that sets the outcome variable norekinResultats from two
inputs:
| Input | Values |
|---|---|
avansaSituacija |
nav-avansa, avanss-lielaks, avanss-vienads, izdevumi-lielaki |
avansaVeids |
karte, konts, nav |
Outcomes: papildu-izmaksa (no advance, or expenses exceed the advance —
the difference is paid to the employee), slegts (advance equals expenses),
parnesums (a card advance exceeds expenses — the balance carries forward to
the next period), atmaksa (an account advance exceeds expenses — the
difference is repaid). The Task_NoteiktRezultatu business-rule task
evaluates it.
Resources
resources/mappings.yaml binds every BPMN user task and the DMN decision to a
target in resources/roles.yaml / resources/agents.yaml. Human steps are
manual; the AI agent agent.norekinu-asistents is bound assisted to the
settlement processing and the reconciliation decision — it extracts document
data and proposes the outcome, the accountant decides. No step is autonomous.
Transcription note
The advance request (3.5.2.1) is modelled as the process entry point; in
practice it is optional — an economic settlement may be submitted for expenses
already incurred without a prior advance, a case the decision table covers via
the nav-avansa input value. Advance disbursement and the additional payment
themselves are executed in FG2 (payments) and are referenced rather than
duplicated here. Step identifiers use stable BPMN/DMN element ids;
reconciliation against the register process nr. numbering is a tracked
follow-up and any schema/register discrepancy is recorded rather than silently
resolved (see docs/conventions.md).
Status
Draft. The package is structurally complete and validates against the UAPF
2.2.0 schemas; lifecycle status advances to review once the source-numbering
reconciliation is signed off.