Configuration des processus dans OOD

01

1. Ne commencez pas par l'écran

1. Choisissez un cas précis et indiquez son début et sa fin.
2. Liste des participants, des responsabilités, des documents d'entrée et des systèmes faisant autorité.
3. Distinguer la règle légale ou interne des usages et limitations techniques actuels.
4. Indiquez les exceptions : document manquant, montant incorrect, rejet, inactivité, forte affluence et erreur d’intégration.

02

2. Définition provisoire

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. Formulaire et données

• Chaque champ possède un nom, un type, une source, une obligation, une visibilité et des droits de modification.
• Pour les données copiées, conservez la source et, si nécessaire, la valeur originale et la valeur corrigée.
• Utilisez les manuels numériques provenant d'un système faisant autorité ; la copie locale doit avoir un propriétaire et une méthode de synchronisation.
• La validation doit indiquer à l'utilisateur ce qui ne va pas et comment corriger l'erreur.
• Les pièces jointes doivent respecter un type, une taille, un objectif et des règles de soumission autorisés pour CUL/eSSL.

04

4. Rôles, foules et principe des quatre yeux

• Définissez les rôles par les responsabilités, et non par les noms de personnes spécifiques.
• ZST délègue uniquement le rôle, le module et la période spécifiés ; il ne transfère pas le compte utilisateur.
• Les combinaisons de rôles interdites et les limites sont vérifiées avant la transition.
• L'approbation forcée par deux personnes doit être indépendante et consignée dans l'audit.
• L'escalade de l'inactivité n'entraîne pas une approbation automatique, sauf si la règle le prévoit explicitement.

05

5. Intégration et documents

• Pour chaque direction, spécifiez le système de preuve, le contrat, l'authentification, le délai d'expiration, la nouvelle tentative, la clé d'idempotence et l'identifiant de corrélation.
• Versionnez le modèle DOG avec la définition du processus et les données de test.
• EPK/WSCS sépare les décisions commerciales des signatures techniques.
• La soumission à eSSL associe le document, les métadonnées et les identifiants conformément au profil d'intégration confirmé.
• L'erreur système cible crée un état résoluble ; elle ne doit pas disparaître dans le journal sans qu'une tâche soit effectuée.

06

6. Test, publication et modification

1. Testez le passage normal, chaque branche de retour, la foule, l'interdiction de rôle, le délai d'attente et l'intégration indisponible.
2. Utiliser des données anonymes ou synthétiques et obtenir les résultats attendus.
3. Faites confirmer la signification des règles par le responsable du processus et le comportement d'intégration par le service informatique.
4. Publiez une version non modifiée de la définition ; la modification en cours ne doit pas affecter les cas en cours sans règle de migration.
5. Notez les changements, leur impact, l'approbation et la possibilité de revenir à la définition précédente.