1
0
Files
Rihards Gailums 66ce42ea37 Spec-conformance fix: correct stub levels and add BPMN-DI
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.
2026-05-20 06:44:14 +00:00
..

FG3-5 — Komandējuma norēķina veikšana

Level 4 atomic executable process for business-trip (travel) settlement — the processing of trip requests, cancellations, post-trip expense reports and the reconciliation of travel advances against documented expenses. The third FG3 sub-process taken to executable depth.

  • UAPF level: L4 (atomic executable)
  • Package id: vk.gramatvediba.fg3-5
  • Included by: processes/fg3 (function group FG3).
  • Source: Valsts Kase Grāmatvedības uzskaites procesu apraksts — FG3 process register, section 3.5.3 (Komandējuma (darba brauciena) dokumenti un to kustība), with the advance-repayment tail in section 3.5.4.

Process

bpmn/komandejuma-norekina.bpmn (Process_KomandejumaNorekina) transcribes the business-trip settlement flow across three lanes mapped from the source RACI columns:

  • Nodarbinātais — submits the trip request (3.5.3.1) and, after the trip, the expense report (3.5.3.3).
  • Iestāde — approves the trip expense report in its defined flow.
  • VPC — processes the request, annuls it if the trip is cancelled (3.5.3.2), processes the report (3.5.3.4), reconciles it, and prepares a repayment request, an additional payment, or posts the document.

Flow: request processing → cancellation branch → expense-report submission and approval → VPC processing → reconciliation decision → one of three outcomes. Two terminating states: settlement posted or trip request annulled.

Decision

dmn/komandejuma-norekins.dmn (Decision_KomandejumaNorekins) 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
nakamaisKomandejums ir, nav

Outcomes: papildu-izmaksa (no advance, or expenses exceed the advance — the difference is paid to the employee), slegts (advance equals expenses), parnesums (the advance exceeds expenses and the employee has a next approved trip from the same funding — the balance carries forward to that trip), atmaksa (the advance exceeds expenses with no next trip — 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.komandejumu-asistents is bound assisted to the request processing, the report processing and the reconciliation decision — it extracts document data and proposes the outcome, the accountant decides. No step is autonomous.

Transcription note

The trip request itself is prepared and approved in the personnel-management process (PP); FG3-5 begins where the request enters accounting handling, so the start event represents that hand-off. Advance disbursement, the additional payment and the detailed advance-repayment steps (3.5.4) are executed in their own processes and are referenced rather than duplicated here. The carry-forward rule (parnesums) transcribes the 3.5.4 condition that an advance surplus is retained against a next approved trip from the same funding. 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.