ED02 - Mô hình tổ chức KMU: Tenant, Sphäre, vai trò

Vấn đề

Một doanh nhân thành lập một tổ chức - và đứng trước câu hỏi: Làm thế nào để tôi cấu trúc tổ chức của mình sao cho các nghĩa vụ tuân thủ được thể hiện tách bạch, có thể truy vết và an toàn kiểm toán?

Thực tiễn hiện nay trong lĩnh vực KMU không có sự tách biệt rõ ràng:

• Tất cả trong một nồi - tài liệu riêng tư và tài liệu kinh doanh trộn lẫn trong một hộp thư, một ổ đĩa, một tài khoản cloud.
• Không tách biệt Tenant - một holding với nhiều công ty ghi tất cả sổ sách trong một instance, mà không rõ bản ghi nào thuộc công ty nào.
• Không tách biệt Sphäre - với tổ chức công ích, các giao dịch ideell, vermögensverwaltend, zweckbetrieblich và wirtschaftlich trộn lẫn trong một tài khoản, một thư mục, một repo.
• Không tách biệt vai trò - doanh nhân tự làm mọi thứ (GF, kế toán, tiền lương, F&E), nhưng repo không biết anh ta đang hành động với vai trò nào.
• Không có danh tính rõ ràng - các bản ghi không có định danh duy nhất để gán chúng cho một tổ chức, một Sphäre, một vai trò.

Tuyên bố cốt lõi

Cấu trúc một tổ chức như một Liên hợp GitCover có nghĩa là: Tenant (tổ chức), Sphäre (lĩnh vực hoạt động với tổ chức công ích) và vai trò (chức năng của chủ thể) được định nghĩa là trường bắt buộc của mọi artefact - không phải metadata tùy chọn. Git-Hook kiểm tra ở mỗi commit rằng sự tách biệt là đầy đủ. Nhờ đó hình thành Compliance by Design: Cấu trúc của tổ chức được neo vào cấu trúc của repo.

Compliance by Design: Tenant, Sphäre và vai trò không phải nhãn gắn sau - chúng là trường bắt buộc mang tính cấu trúc, mà thiếu chúng thì một artefact không được đưa vào repo.

Mô hình ba cấp: Tenant, Sphäre, vai trò

Cấp 1 - Tenant (Tổ chức)

Một Tenant là một đơn vị tổ chức có tư cách pháp lý độc lập, có các nghĩa vụ ghi chép riêng. Trong Liên hợp GitCover, mỗi Tenant được quản lý như một Organization riêng (Git User) với các Git-Repo được gán (hoặc namespace nhánh riêng).

Ví dụ thực tiễn: Một doanh nhân (E1) điều hành một holding (ORG-1) với hai công ty con (ORG-1a, ORG-1b). Mỗi công ty con là một Tenant riêng với repo riêng. Holding có một meta-repo liên kết các công ty con qua tham chiếu V7GUID - nhưng sổ sách của các công ty con vẫn tách biệt.

Cấp 2 - Sphäre (lĩnh vực hoạt động, chỉ với tổ chức công ích)

Sphäre chỉ liên quan với các tổ chức công ích - nhưng khi đó là bắt buộc. Luật thuế (§ 51–68 AO) yêu cầu tách biệt bốn Sphäre để không gây nguy hiểm cho tính công ích.

Rủi ro khi thiếu tách biệt Sphäre: Trộn lẫn tài sản (§ 55 Abs. 1 Nr. 5 AO) là căn cứ để thu hồi tính công ích. Một tổ chức công ích không tách biệt các giao dịch wirtschaftlich và ideell sẽ đối mặt với nguy cơ bị thu hồi trạng thái công ích - và do đó bị truy thu thuế đối với quỹ dự trữ (hồi tố tới 15(!) năm).

Cấp 3 - Vai trò (chức năng của chủ thể)

Vai trò ghi lại chủ thể đã hành động với chức năng nào. Điều này quan trọng vì trong nhiều tổ chức, một người thường đảm nhận nhiều vai trò (đặc biệt ở KMU) - và vì vai trò quyết định nghĩa vụ nào được áp dụng.

Ví dụ thực tiễn: Doanh nhân E1 đồng thời là GF, kế toán, nhà nghiên cứu, nhà phát triển và trưởng F&E. Trong repo, với mỗi artefact đều được ghi lại anh ta đã hành động với vai trò nào - ví dụ role: "GF" trong một nghị quyết, role: "F&E-Leiter" trong một bảng chấm công FZul. Nhờ đó có thể truy vết liệu một bản ghi được tạo ra từ góc nhìn GF (hành chính) hay góc nhìn F&E (nghiên cứu).

Vai trò không phải cá nhân: Vai trò mô tả chức năng (và trong các tuyên bố là bên được đại diện), không phải danh tính. Cùng một người có thể hành động hoặc ký một tài liệu với nhiều vai trò; danh tính thực thi kỹ thuật (tài khoản, khóa) lại là một cấp riêng. Năm cấp cá nhân · chức năng · bên được đại diện · danh tính thực thi · hành vi ký được mô tả trong ED03.

Triển khai trong Git-Repo

Cấu trúc thư mục

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}/

Artefact JSON với Tenant, Sphäre, vai trò

Mỗi artefact (mục nhật ký, chứng từ, mục sổ địa chính) chứa Tenant, Sphäre và vai trò như các trường bắt buộc. Nguyên tắc cốt lõi trung tâm của khả năng truy vết theo thời gian: Thời điểm ghi nhận không phải một trường riêng, mà được neo ngay trong uuidV7 - như dấu thời gian 48-bit theo RFC 9562 §5.7. uuidV7 có thể được tạo từ một mốc thời gian định trước (không chỉ now()) qua GitCover Helper (UuidV7Gen), phần còn lại được điền bằng ngẫu nhiên. Nhờ đó thời điểm ghi nhận được gắn kết mật mã với danh tính của artefact và không thể thay đổi về sau.

Quan trọng - Những gì nằm trong Git-Repo: Chỉ những artefact có cấu trúc này (mục JSON, sidecar, chứng từ) mới được đưa vào Git-Repo. Tài liệu riêng tư không bao giờ được đưa vào repo, trừ khi chúng được đưa vào và phân loại rõ ràng như một artefact. Cái gì đã ở trong thì ở trong.

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

Giải thích Composite Key: V7GUID (Class Identifier) phân loại tài liệu/hành động dựa trên registry .gitcover (cái gì/loại nào). uuidV7 (Object ID) là định danh đối tượng cụ thể với mốc thời gian định trước (RFC 9562 §5.7, 48-bit Unix-ms). Cả hai cùng nhau tạo thành GCPN Sidecar Composite Key V7GUID:uuidV7. Một biểu diễn chuỗi datetime hoặc date riêng là dư thừa và không được đưa vào tầng dữ kiện - dấu thời gian 48-bit đã nằm trong uuidV7. Các biểu diễn chuỗi cho truyền DTO/HTMX là trách nhiệm của Harness, không phải tầng dữ kiện.

Git-Hook kiểm tra sự tách biệt

Liên hợp Tenant: Nhiều tổ chức

Một liên hợp Tenant (holding với công ty con, consortium) được liên kết qua tham chiếu V7GUID - không qua repo dùng chung. Mỗi Tenant giữ sổ sách riêng, nhưng meta-repo của holding có thể tham chiếu đến chứng từ và mục của các công ty con mà không sao chép chúng.

Quan trọng: Meta-repo không chứa bút toán - chỉ có tham chiếu chéo. Sổ sách vẫn thuộc về từng Tenant. Meta-repo là một tầng chỉ mục, không phải tầng kế toán.

Đòn bẩy rủi ro

Yêu cầu Harness (xem trước)

Có thể suy ra từ ED02:

Danh sách yêu cầu đầy đủ trong Harness-Anforderungen.md.

Nguồn

• AO (§§ 51–68 - tính công ích, tách biệt Sphäre, § 55 Abs. 1 Nr. 5 - trộn lẫn tài sản)
• EStG (§ 3 Nr. 26/26a - khoản trọn gói, liên quan đến Sphäre)
• GoBD (công văn BMF, tài liệu quy trình, tách biệt Tenant)
• E1/agents/ (ẩn danh) - khái niệm SSoT với Tenant, Sphäre, vai trò

Cấu trúc nguồn và liên kết tham chiếu CDN

Lưu ý: Việc phân loại nguồn, mirror và Community Hub này phản ánh tình trạng hiện tại và có thể thay đổi. Vui lòng kiểm tra nguồn chuẩn tương ứng trên gitcover.org để biết tình trạng hiện tại.