Configuración de procesos en OOD

01

1. No empieces por la pantalla.

1. Elija un caso específico e indique su inicio y su final.
2. Enumere los participantes, las responsabilidades, los documentos de entrada y los sistemas autorizados.
3. Separe la norma legal o interna de la costumbre actual y las limitaciones técnicas.
4. Complete las excepciones: documento faltante, discrepancia de monto, rechazo, inactividad, exceso de usuarios y error de integración.

02

2. Borrador de definición

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. Formulario y datos

• Cada campo tiene un nombre, tipo, origen, obligación, visibilidad y derechos de modificación.
• Para los datos copiados, conserve la fuente y, si es necesario, el valor original y el corregido.
• Tome los libros de numeración de un sistema autorizado; la copia local debe tener un propietario y un método de sincronización.
• La validación debe indicar al usuario qué es lo que falla y cómo corregir el error.
• Los archivos adjuntos tienen un tipo, tamaño, propósito y reglas de envío permitidos para CUL/eSSL.

04

4. Roles, multitudes y el principio de los cuatro ojos

• Defina las funciones por responsabilidades, no por nombres de personas específicas.
• ZST delega únicamente el rol, el módulo y el período especificados; no transfiere la cuenta de usuario.
• Antes de la transición, se comprueban las combinaciones de roles prohibidas y los límites.
• La aprobación obligatoria por parte de dos personas debe ser independiente y quedar registrada en la auditoría.
• La escalada de inactividad no determina la aprobación automática a menos que la regla lo permita explícitamente.

05

5. Integración y documentos

• Para cada dirección, especifique el sistema de evidencia, el contrato, la autenticación, el tiempo de espera, el reintento, la clave de idempotencia y el ID de correlación.
• Cree una versión de la plantilla DOG junto con la definición del proceso y los datos de prueba.
• EPK/WSCS separa las decisiones comerciales de las firmas técnicas.
• El envío a eSSL asigna el documento, los metadatos y los identificadores de acuerdo con el perfil de integración confirmado.
• El error del sistema objetivo crea un estado solucionable; no debe desaparecer en el registro sin que se le asigne una tarea.

06

6. Prueba, publicación y cambio

1. Prueba el paso normal, cada rama de retorno, la multitud, la prohibición de roles, el tiempo de espera y la integración no disponible.
2. Utilice datos anónimos o sintéticos y resultados esperados.
3. El responsable del proceso deberá confirmar el significado de las reglas y el departamento de TI deberá confirmar el comportamiento de la integración.
4. Publique una versión sin modificar de la definición; el cambio en curso no debe afectar a los casos en ejecución que no tengan una regla de migración.
5. Anota los cambios, su impacto, la aprobación y la posibilidad de volver a la definición anterior.