ED02 - Mô hình tổ chức doanh nghiệp nhỏ và vừa: Tenant, Phạm vi, Vai trò

Vấn đề

Một doanh nhân sáng 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 biệt rõ ràng, dễ kiểm chứng và an toàn kiểm toán?

Thực tiễn hiện nay trong lĩnh vực doanh nghiệp nhỏ và vừa không có sự tách biệt rõ ràng:

• Nấu chung một nồi - tài liệu riêng tư và tài liệu kinh doanh trộn lẫn vào nhau 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 con giữ tất cả sổ sách trong một instance, mà không rõ bản ghi nào thuộc về công ty nào.
• Không tách biệt phạm vi - khi có tư cách phi lợi nhuận, các nghiệp vụ ideell, vermögensverwaltend, zweckbetrieblich và wirtschaftlich trộn lẫn vào nhau 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, Buchhalter, Lohn, F&E), nhưng repo không biết người này đang hành động với vai trò nào.
• Không có định danh rõ ràng - các bản ghi không có một định danh duy nhất để gán chúng vào một tổ chức, một phạm vi, một vai trò.

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

Cấu trúc một tổ chức thành một khối liên kết GitCover có nghĩa là: Tenant (tổ chức), Phạm vi (lĩnh vực hoạt động khi có tư cách phi lợi nhuận) 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 artifact - chứ không phải là metadata tùy chọn. Git-Hooks kiểm tra ở mỗi commit rằng việc tách biệt là đầy đủ. Nhờ vậy mà 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, Phạm vi và Vai trò không phải là các nhãn gắn về sau - chúng là 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, Phạm vi, 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, lưu hồ sơ riêng. Trong khối liên kết GitCover, mỗi Tenant được quản lý như một Organization (Git User) riêng, cùng với các Git repo tương ứng (hoặc một Branch-Namespace 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 kết nối 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 - Phạm vi (Lĩnh vực hoạt động, chỉ khi có tư cách phi lợi nhuận)

Phạm vi chỉ có liên quan đối với các tổ chức phi lợi nhuận - nhưng khi đó thì bắt buộc. Luật thuế (§ 51–68 AO) đòi hỏi phải tách biệt bốn phạm vi để không làm tổn hại đến tư cách phi lợi nhuận.

Rủi ro khi thiếu tách biệt phạm vi: Trộn lẫn tài sản (§ 55 Abs. 1 Nr. 5 AO) là một 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 tách biệt các nghiệp vụ wirtschaftlich và ideell sẽ chịu rủi ro bị tước tư cách phi lợi nhuận - và kéo theo việc truy thu thuế đối với quỹ dự trữ (truy hồi tới 15(!) năm).

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

Vai trò ghi lại việc một 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 giữ nhiều vai trò cùng lúc (đặc biệt ở doanh nghiệp nhỏ và vừa) - 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, Buchhalter, nhà nghiên cứu, nhà phát triển và F&E-Leiter. Trong repo, mỗi artifact đều được ghi lại việc anh ấy đã hành động với 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 bảng kê giờ FZul. Nhờ đó vẫn có thể kiểm chứng được một bản ghi ra đời 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, Phạm vi, Vai trò

Mỗi artifact (bản ghi nhật ký, chứng từ, bản ghi sổ địa bạ) đều chứa Tenant, Phạm vi và Vai trò với tư cách 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à 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 mốc thời gian định sẵn (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 điểm ghi nhận được liên kết về mặt 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 (bản ghi JSON, sidecar, chứng từ) mới được đưa vào Git repo. Tài liệu riêng tư sẽ không bao giờ được đưa vào repo, trừ khi chúng đã được đưa vào và phân loại một cách rõ ràng với tư cách artifact. Một khi đã vào rồi thì là đã vào.

{
  "$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 Composite Key: V7GUID (Class Identifier) phân loại tài liệu/Action dựa trên .gitcover Registry (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 sẵn (RFC 9562 §5.7, Unix-ms 48 bit). Cả hai cùng nhau tạo thành GCPN Sidecar Composite Key V7GUID:uuidV7. Một biểu diễn dạng chuỗi datetime hoặc date riêng biệt là dư thừa và không được đưa vào phần dữ kiện - dấu thời gian 48 bit đã nằm sẵn trong uuidV7. Các biểu diễn dạng chuỗi phục vụ truyền tải DTO/HTMX là trách nhiệm của Harness, không thuộc tầng dữ kiện.

Git-Hooks kiểm tra việc tách biệt

Khối liên kết Tenant: Nhiều tổ chức

Một khối liên kết Tenant (holding với các công ty con, liên minh) được kết nối với nhau 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ổ sách kế toán riêng, nhưng Meta-Repo của holding có thể tham chiếu đến chứng từ và bản ghi của các 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 toán - chỉ có tham chiếu chéo. Sổ sách kế toán 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 đủ nằm trong Harness-Anforderungen.md.

Nguồn

• AO (§§ 51–68 - tư cách phi lợi nhuận, tách biệt phạm vi, § 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 phạm vi)
• GoBD (công văn BMF, tài liệu hóa quy trình, tách biệt Tenant)
• AFJD/agents/ (đã ẩn danh) - khái niệm SSoT với Tenant, Phạm vi, Vai trò

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

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