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 phản ánh một cách tách bạch rõ ràng, dễ truy vết và an toàn khi kiểm toán?

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

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

Thông điệp cốt lõi

Cấu trúc một tổ chức theo mô hình 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à vai trò (chức năng của tác nhân) được định nghĩa là trường bắt buộc của mọi artifact - chứ không phải là metadata tùy chọn. Git-Hooks kiểm tra ở mỗi commit rằng sự phân tách là đầy đủ. Nhờ đó hình thành Compliance by Design: Cấu trúc của tổ chức được neo giữ trong cấu trúc của repo.

Compliance by Design: Tenant, Sphäre và vai trò không phải là các nhãn dán bổ sung về sau - chúng là các trường bắt buộc mang tính cấu trúc, thiếu chúng thì artifact sẽ 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 lập về mặt pháp lý, có các nghĩa vụ ghi chép riêng của mình. Trong GitCover-Verbund, mỗi Tenant được quản lý như một Organization riêng (Git User) với các Git-repo tương ứng (hoặc branch-namespace riêng).

Ví dụ thực tế: 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 được giữ tách biệt.

Cấp 2 - Sphäre (Lĩnh vực hoạt động, chỉ áp dụng cho tổ chức phi lợi nhuận)

Sphäre chỉ có liên quan đối với các tổ chức phi lợi nhuận - nhưng khi đó là bắt buộc. Pháp luật thuế (§ 51–68 AO) đòi hỏi phân tách bốn Sphäre để không đặt tư cách phi lợi nhuận vào nguy cơ.

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

Cấp 3 - Vai trò (Chức năng của tác nhân)

Vai trò ghi lại việc một tác nhân đã 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 giữ nhiều vai trò (đặc biệt ở KMU) - và vì vai trò quyết định những nghĩa vụ nào được áp dụng.

Ví dụ thực tế: 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 bộ phận F&E. Trong repo, với mỗi artifact đều ghi rõ anh ấy đã hành động trong vai trò nào - ví dụ role: "GF" đối với một nghị quyết, role: "F&E-Leiter" đối với một chứng từ giờ FZul. Nhờ đó, vẫn truy vết được một bản ghi được tạo ra từ góc nhìn GF (hành chính) hay từ góc nhìn F&E (nghiên cứu).

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

Artifact JSON với Tenant, Sphäre, Vai trò

Mỗi artifact (mục nhật ký, chứng từ, mục sổ địa bạ) đều 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 của khả năng truy vết theo thời gian: Thời gian ghi nhận không phải là một trường riêng biệt, mà được neo ngay trong chính uuidV7 - dưới dạng dấu thời gian 48-bit theo RFC 9562 §5.7. uuidV7 có thể được sinh ra từ một dấu thời gian định trước (không chỉ now()) thông qua GitCover Helper (UuidV7Gen), phần còn lại được điền bằng giá trị ngẫu nhiên. Nhờ đó, thời gian ghi nhận được liên kết một cách mật mã với định danh của artifact và không thể bị thay đổi về sau.

Quan trọng - Những gì được đưa vào Git-repo: Chỉ những artifact 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 cá nhân 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 với tư cách là artifact. Cái gì đã vào rồi thì ở luôn trong đó.

{
  "$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"]
}

Giải thích về 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 dấu 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 biệt là dư thừa và không được lưu trong tầng dữ kiện - dấu thời gian 48-bit đã nằm sẵn trong uuidV7. Các biểu diễn chuỗi phục vụ truyền DTO/HTMX là trách nhiệm của Harness, không thuộc tầng dữ kiện.

Git-Hooks kiểm tra sự phân tách

Liên kết Tenant: Nhiều tổ chức

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

Quan trọng: Meta-repo không chứa bất kỳ bút toán nào - chỉ có tham chiếu chéo. Bộ sổ kế toán vẫn nằm tại 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 đối với Harness (xem trước)

Có thể suy ra từ ED02:

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

Nguồn

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

Topology nguồn và các liên kết tham chiếu CDN

Lưu ý: Việc phân bổ này giữa nguồn, mirror và community-hub phản ánh hiện trạng và có thể thay đổi. Vui lòng kiểm tra nguồn chính tắc tương ứng trên gitcover.org để biết trạng thái hiện hành.