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

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 phản ánh một cách tách bạch, có thể truy vết và có thể 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 chỗ - hồ sơ riêng và hồ sơ kinh doanh trộn lẫn trong một hộp thư, một ổ đĩa, một tài khoản đám mây.
• Không có tách biệt Tenant - một holding với nhiều công ty hạch toán 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 có tách biệt Sphäre - trong hoạt động phi lợi nhuận, các nghiệp vụ 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 có tách biệt Rolle - doanh nhân tự làm mọi việc (GF, Buchhalter, Lohn, F&E), nhưng repo không biết anh ta đang hành động trong Rolle nào.
• Không có danh tính rõ ràng - các bản ghi không có mã định danh duy nhất để gán chúng cho một tổ chức, một Sphäre, một Rolle.

Luận điểm cốt lõi

Cấu trúc một tổ chức như một GitCover-Verbund có nghĩa là: Tenant (tổ chức), Sphäre (lĩnh vực hoạt động trong trường hợp phi lợi nhuận) và Rolle (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-Hooks 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à Rolle không phải là nhãn gắn thêm về sau - chúng là các trường bắt buộc mang tính cấu trúc, mà nếu thiếu thì một artefact không được đưa vào repo.

Mô hình ba cấp độ: Tenant, Sphäre, Rolle

Cấp độ 1 - Tenant (tổ chức)

Một Tenant là một đơn vị tổ chức có tư cách pháp nhân độc lập, có các nghĩa vụ ghi chép riêng. Trong GitCover-Verbund, mỗi Tenant được quản lý như một Organization (Git User) riêng 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 các 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ỉ trong trường hợp phi lợi nhuận)

Sphäre chỉ có ý nghĩa đối với các tổ chức phi lợi nhuận - 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 đe dọa tư cách phi lợi nhuận.

Rủi ro khi thiếu tách biệt Sphäre: Việc trộn lẫn tài sản (§ 55 Abs. 1 Nr. 5 AO) là lý do bị tước tư cách phi lợi nhuận. Một tổ chức phi lợi nhuận không tách biệt các nghiệp vụ kinh tế và ideell sẽ đối mặt với việc bị tước tư cách phi lợi nhuận - và do đó phải truy thu thuế đối với các khoản dự trữ (truy hồi tới 15(!) năm).

Cấp độ 3 - Rolle (chức năng của chủ thể)

Rolle 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, thường một người đảm nhận nhiều Rolle (đặc biệt ở KMU) - và vì Rolle 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, Buchhalter, nhà nghiên cứu, nhà phát triển và F&E-Leiter. Trong repo, mỗi artefact đều được ghi lại anh ta đã hành động trong Rolle nào - ví dụ role: "GF" trong một nghị quyết, role: "F&E-Leiter" trong một bảng giờ FZul. Nhờ đó có thể truy vết liệu một bản ghi được tạo ra từ góc nhìn GF (quản lý) hay góc nhìn F&E (nghiên cứu).

Rolle không phải là con người: Rolle mô tả chức năng (và trong các tuyên bố thì 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 Rolle; 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 độ Person · Funktion · 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.gc.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/                   # .gc.md Sidecars
├── checks/                     # Fristen-Check, Sphären-Check
└── {weitere bei Bedarf}/

Artefact JSON với Tenant, Sphäre, Rolle

Mỗi artefact (bản ghi nhật ký, chứng từ, mục sổ địa chính) chứa Tenant, Sphäre và Rolle 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 là 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 được chỉ định trước (không chỉ now()) thông qua GitCover Helper (gc-v7guid), phần còn lại được lấp đầy 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ì được đưa vào 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. Những 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à mã định danh đối tượng cụ thể với mốc thời gian được chỉ đị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 biệt 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 tải DTO/HTMX là trách nhiệm của harness, không phải tầng dữ kiện.

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

Tenant-Verbund: Nhiều tổ chức

Một Tenant-Verbund (holding với công ty con, liên danh) được liên kết qua các tham chiếu V7GUID - không qua các 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. Việc hạch toán vẫn thuộc về mỗi 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ư cách phi lợi nhuận, tách biệt Sphäre, § 55 Abs. 1 Nr. 5 - trộn lẫn tài sản)
• EStG (§ 3 Nr. 26/26a - các khoản phụ cấp, liên quan 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, Rolle

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

Lưu ý: Việc phân định nguồn, mirror và community hub này phản ánh trạng thái 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 trạng thái hiện tại.