← 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.
01
1. Don't start with the screen
- Choose one specific case and name its beginning and end.
- List participants, responsibilities, input documents, and authoritative systems.
- Separate the legal or internal rule from today's custom and technical limitation.
- 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
- Test the normal pass, each return branch, the crowd, the role ban, the timeout, and the unavailable integration.
- Use anonymous or synthetic data and expected results.
- Have the process owner confirm the meaning of the rules and IT confirm the integration behavior.
- Publish an unmodified version of the definition; the change in progress must not affect running cases without a migration rule.
- Write down the changes, impact, approval, and the possibility of returning to the previous definition.
Next runbook
