All runbooks
Under construction · working draft requires a release manifest

Technical runbook

Process configuration in OOD

How to translate the organization's actual progress into states, roles, rules, forms, and integrations.

Audience
Process analyst, trained administrator, implementation partner, process owner
Outcome
A published definition has an owner, tested normal and error branches, and a traceable version.

01

1. Don't start with the screen

  1. Choose one specific case and name its beginning and end.
  2. List participants, responsibilities, input documents, and authoritative systems.
  3. Separate the legal or internal rule from today's custom and technical limitation.
  4. Fill in the exceptions: missing document, amount mismatch, rejection, inactivity, crowd, and integration error.

02

2. Draft definition

Working exampleReplace <…> values from the release
Proces: Přijatá faktura
Verze definice: 1.0-draft

Společné stavy:
  PRIJATA -> KONTROLA_DAT -> VECNE_SCHVALENI
  -> KONTROLA_ROZPOCTU -> SCHVALENA_K_UCETNIMU_ZPRACOVANI

Volitelná interní účetní kontrola:
  SCHVALENA_K_UCETNIMU_ZPRACOVANI -> UCETNI_KONTROLA
  -> PRIPRAVENA_PRO_EIS

Předání ekonomickému systému:
  PRIPRAVENA_PRO_EIS -> ODESLANA_DO_EIS -> EIS_TECHNICKY_PRIJAL

Další stav smí odpovídat jen tomu, co EIS skutečně vrací:
  CEKA_NA_UCETNI | DOKLAD_ZALOZEN_V_EIS | ZAUCTOVAN_V_EIS

Výjimky:
  KONTROLA_DAT -> VRACENA_DODAVATELI
  VECNE_SCHVALENI -> VRACENA_REFERENTOVI
  KONTROLA_ROZPOCTU -> NEDOSTATECNE_KRYTI
  ODESLANA_DO_EIS -> EIS_ODMITL_DATA | CHYBA_PRENOSU_EIS
  NEJASNY_VYSLEDEK -> NUTNA_REKONCILIACE

Před publikací ověřit:
  role, zástupy, limity, termíny, notifikace,
  idempotenci integrací, audit, návratové větve a podmínku uzavření.
  Technické přijetí ani ID dávky samo o sobě neznamená zaúčtování.

03

3. Form and data

  • Each field has a name, type, source, obligation, visibility, and change rights.
  • For copied data, keep the source and, if necessary, the original and corrected value.
  • Take the number books from an authoritative system; the local copy must have an owner and a method of synchronization.
  • Validation must tell the user what is wrong and how to fix the error.
  • Attachments have an allowed type, size, purpose, and submission rule for CUL/eSSL.

04

4. Roles, crowds and the four-eyes principle

  • Define roles by responsibilities, not by names of specific people.
  • ZST delegates only the specified role, module and period; it does not transfer the user account.
  • Prohibited role combinations and limits are checked before transition.
  • Forced approval by two people must be independent and recorded in the audit.
  • Escalation of inactivity does not determine automatic approval unless the rule explicitly allows it.

05

5. Integration and documents

  • For each direction, specify the system of evidence, contract, authentication, timeout, retry, idempotency key, and correlation ID.
  • Version the DOG template together with the process definition and test data.
  • EPK/WSCS separates business decisions from technical signatures.
  • Submission to eSSL maps the document, metadata, and identifiers according to the confirmed integration profile.
  • The target system error creates a solvable state; it must not disappear into the log without a task.

06

6. Test, publication and change

  1. Test the normal pass, each return branch, the crowd, the role ban, the timeout, and the unavailable integration.
  2. Use anonymous or synthetic data and expected results.
  3. Have the process owner confirm the meaning of the rules and IT confirm the integration behavior.
  4. Publish an unmodified version of the definition; the change in progress must not affect running cases without a migration rule.
  5. Write down the changes, impact, approval, and the possibility of returning to the previous definition.