ED02 - El modelo organizativo de PYME: Tenants, Esferas, Roles

Problema

Un empresario funda una organización - y se encuentra ante la pregunta: ¿Cómo estructuro mi organización para que las obligaciones de cumplimiento se reflejen de forma claramente separada, comprensible y a prueba de auditorías?

La práctica actual en el ámbito de las PYME no conoce una separación limpia:

• Todo en el mismo saco - los documentos privados y comerciales se mezclan en un buzón, una unidad, un Cloud-Account.
• Sin separación por Tenant - una holding con varias sociedades lleva todos los libros en una sola instancia, sin que quede claro a qué sociedad pertenece cada registro.
• Sin separación de esferas - con el estatus sin ánimo de lucro, las operaciones ideales, de gestión patrimonial, vinculadas al fin y económicas se mezclan en una cuenta, una carpeta, un repo.
• Sin separación de roles - el empresario lo hace todo él mismo (GF, Buchhalter, Lohn, F&E), pero el repo no sabe en qué rol está actuando.
• Sin identidad clara - los registros no disponen de un identificador unívoco que los asigne a una organización, una esfera, un rol.

Idea central

Estructurar una organización como consorcio GitCover significa: Tenant (organización), Esfera (ámbito de actividad con estatus sin ánimo de lucro) y Rol (función del actor) se definen como campos obligatorios de cada artefacto - no como metadatos opcionales. Los Git-Hooks comprueban en cada commit que la separación esté completa. Así surge Compliance by Design: la estructura de la organización queda anclada en la estructura del repo.

Compliance by Design: Tenant, Esfera y Rol no son etiquetas posteriores - son campos obligatorios estructurales, sin los cuales un artefacto no se incorpora al repo.

El modelo de tres niveles: Tenant, Esfera, Rol

Nivel 1 - Tenant (organización)

Un Tenant es una unidad organizativa jurídicamente independiente para la que existen obligaciones de registro propias. En el consorcio GitCover, cada Tenant se gestiona como Organization propia (Git User) con Git-Repos asignados (o un Branch-Namespace propio).

Ejemplo práctico: Un empresario (E1) dirige una holding (ORG-1) con dos filiales (ORG-1a, ORG-1b). Cada filial es un Tenant propio con su propio repo. La holding tiene un meta-repo que vincula a las filiales mediante referencias V7GUID - pero los libros de las filiales permanecen separados.

Nivel 2 - Esfera (ámbito de actividad, solo con estatus sin ánimo de lucro)

La Esfera solo es relevante en las organizaciones sin ánimo de lucro - pero entonces es obligatoria. El derecho fiscal (§ 51–68 AO) exige la separación de las cuatro esferas para no poner en peligro el estatus sin ánimo de lucro.

Riesgo por falta de separación de esferas: la mezcla de patrimonios (§ 55 Abs. 1 Nr. 5 AO) es un motivo de revocación del estatus sin ánimo de lucro. Una organización sin ánimo de lucro que no separa las operaciones económicas y las ideales arriesga la revocación del estatus sin ánimo de lucro - y con ello la tributación retroactiva de las reservas (hasta 15(!) años hacia atrás).

Nivel 3 - Rol (función del actor)

El Rol documenta en qué función ha actuado un actor. Esto es importante porque en muchas organizaciones a menudo una persona ostenta varios roles (especialmente en las PYME) - y porque el rol determina qué obligaciones se aplican.

Ejemplo práctico: El empresario E1 es a la vez GF, Buchhalter, investigador, desarrollador y F&E-Leiter. En el repo se documenta en cada artefacto en qué rol ha actuado - p. ej. role: "GF" en una resolución, role: "F&E-Leiter" en un justificante de horas FZul. Así queda claro si un registro surgió desde la perspectiva GF (administración) o desde la perspectiva F&E (investigación).

Implementación en el repositorio Git

Estructura de directorios

ORG-1/                          # Tenant: KMU
├── .gitcover/                  # GitCover-Konfiguration
│   ├── LEGAL_ENTITY.v7g.json   # Tenant-Identität (V7GUID)
│   ├── dictionaries/           # Sphären, Rollen, Beleg-Typen
│   └── schemas/                # JSON-Schemata für Artefakte
├── diary/                      # Tagebuch (SSoT)
│   ├── entries/                # Tages-Einträge
│   └── tenants/                # Tenant-Sichten (Symlinks)
├── registry/                   # Behörden-Identifikatoren
├── sources/                    # Belegarchiv (PDF, XML, EML)
├── sidecars/                   # .v7g.md Sidecars
├── checks/                     # Fristen-Check, Sphären-Check
└── {weitere bei Bedarf}/

Artefacto JSON con Tenant, Esfera y Rol

Cada artefacto (entrada de diario, justificante, entrada del registro de la propiedad) contiene Tenant, Esfera y Rol como campos obligatorios. Principio central de la trazabilidad temporal: el tiempo de captura no es un campo separado, sino que está anclado en la propia uuidV7 - como marca de tiempo de 48 bits conforme a RFC 9562 §5.7. La uuidV7 puede generarse a partir de una marca de tiempo predeterminada (no solo now()) mediante el GitCover Helper (UuidV7Gen), rellenando el resto de forma aleatoria. De este modo, el tiempo de captura queda vinculado criptográficamente a la identidad del artefacto y no puede modificarse posteriormente.

Importante - Qué entra en el Git-Repo: solo estos artefactos estructurados (entradas JSON, sidecars, justificantes) se incorporan al Git-Repo. Los documentos privados nunca se incorporan al repo, a menos que hayan sido introducidos y clasificados explícitamente como artefacto. Lo que una vez está dentro, dentro queda.

{
  "$schema": "https://gitcover.org/schemas/diary-entry-1.0.schema.json",
  "V7GUID": "<V7GUID-Class-aus-Registry>",
  "uuidV7": "<uuidV7-Object-mit-vorgegebener-Zeitmarke>",
  "author": "E1",
  "role": "GF",
  "tenant": "ORG-1",
  "sphere": "ideell",
  "source": "E1",
  "source_sha256": "<SHA-256-...>",
  "tags": ["lohnabrechnung", "sv-meldung"]
}

Explicación del Composite Key: V7GUID (Class Identifier) clasifica el documento/la acción según la Registry .gitcover (qué/qué tipo). uuidV7 (Object ID) es el identificador concreto del objeto con la marca de tiempo predeterminada (RFC 9562 §5.7, Unix-ms de 48 bits). Ambos juntos forman el GCPN Sidecar Composite Key V7GUID:uuidV7. Una representación separada como cadena datetime o date es redundante y no se mantiene en los hechos - la marca de tiempo de 48 bits ya está contenida en la uuidV7. Las representaciones como cadena para la transferencia DTO/HTMX son responsabilidad del Harness, no de la capa de hechos.

Los Git-Hooks comprueban la separación

Consorcio de Tenants: varias organizaciones

Un consorcio de Tenants (holding con filiales, consorcio) se vincula mediante referencias V7GUID - no mediante repos compartidos. Cada Tenant conserva su propia contabilidad, pero el meta-repo de la holding puede remitir a los justificantes y entradas de las filiales sin copiarlos.

Importante: el meta-repo no contiene asientos contables - solo referencias cruzadas. La contabilidad permanece en cada Tenant. El meta-repo es una capa de índice, no una capa de contabilidad.

Apalancamiento de riesgo

Requisito para el Harness (vista previa)

Derivable de ED02:

La lista completa de requisitos en Harness-Anforderungen.md.

Fuentes

• AO (§§ 51–68 - estatus sin ánimo de lucro, separación de esferas, § 55 Abs. 1 Nr. 5 - mezcla de patrimonios)
• EStG (§ 3 Nr. 26/26a - sumas globales, referencia a las esferas)
• GoBD (circulares del BMF, documentación de procedimientos, separación por Tenant)
• AFJD/agents/ (anonimizado) - concepto SSoT con Tenant, Esfera y Rol

Topología de fuentes y enlaces de referencia CDN

Nota: esta asignación de fuentes, mirror y community hub refleja el estado actual y puede cambiar. Por favor, compruebe la fuente canónica correspondiente en gitcover.org para conocer el estado actual.