# MASTER BLUEPRINT ENTERPRISE SYSTEM
## Volume 3 — Access Control Matrix and Authorization Pack
### Django + Next.js for Multi-Module Enterprise Platform

**Versi:** 1.0  
**Posisi dokumen:** lanjutan dari Volume 1 dan Volume 2  
**Tujuan utama:** menerjemahkan blueprint arsitektur dan workflow menjadi kerangka authorization yang implementable, auditable, dan scalable.

---

## Tujuan Volume 3

Jika Volume 1 membangun fondasi arsitektur dan domain, dan Volume 2 membangun perilaku proses, maka Volume 3 membangun **kontrol hak akses nyata** yang mengikat semuanya.

Dokumen ini bertujuan untuk:

- mendefinisikan keluarga role inti
- mendefinisikan katalog authorization object
- mendefinisikan action catalogue yang seragam
- menyusun prinsip context-based authorization
- menyusun matriks akses awal lintas modul
- memberi dasar Segregation of Duties (SoD)
- memberi dasar implementasi backend permission dan frontend guard
- menjadi bahan seeding role/object/action/context

Dokumen ini bukan sekadar daftar “siapa boleh apa”.  
Dokumen ini adalah **paket kebijakan operasional sistem**.

---

## Prinsip Dasar

1. Hak akses diberikan ke **role**, bukan langsung ke user.
2. Hak akses menempel ke **authorization object**, bukan ke menu.
3. Hak akses selalu terkait **action** yang eksplisit.
4. Hak akses dapat dibatasi oleh **context**.
5. Context adalah bagian inti, bukan tambahan opsional.
6. Role harus dibentuk berdasarkan tanggung jawab nyata.
7. Kombinasi role tertentu harus diawasi karena berpotensi konflik.
8. Frontend boleh memakai ringkasan hak akses, tetapi backend tetap final authority.

# 1. Struktur Authorization yang Dipakai

Model yang digunakan:

```text
User
 └── UserRoleAssignment
      └── Role
           ├── RolePermission
           │    └── AuthorizationObject
           └── RoleContextRule
```

Pada runtime, alurnya adalah:

1. Sistem mengambil semua role aktif milik user
2. Sistem memeriksa apakah ada role yang punya `object + action`
3. Sistem memeriksa apakah context cocok
4. Sistem memeriksa rule konflik jika ada
5. Jika lolos, aksi diizinkan
6. Jika tidak, aksi ditolak

## 1.1 Prinsip “Union of Permission, Filtered by Context”
Secara umum, user yang punya banyak role akan mendapatkan gabungan izin dari role-role aktifnya.  
Tetapi izin itu tetap harus dipotong oleh context.

Contoh:
- Sebagai `Purchasing_Staff`, user boleh CREATE PR untuk company 1000
- Sebagai `Sales_Admin`, user boleh CREATE SO untuk company 1000
- Sebagai `Auditor`, user boleh READ lintas modul, tetapi hanya read

## 1.2 Prinsip “Menu Follows Permission”
Menu tidak boleh menjadi sumber kebenaran security.  
Menu dan page visibility hanya mengikuti permission summary.

## 1.3 Prinsip “Default Deny”
Jika tidak ada permission yang eksplisit mengizinkan, maka aksi dianggap tidak boleh.

# 2. Role Family yang Direkomendasikan

Agar role tidak liar dan cepat meledak, gunakan keluarga role berikut.

## 2.1 Governance Roles
- Governance Admin
- Security Admin
- Workflow Admin
- Auditor

## 2.2 Master Data Roles
- Master Data Viewer
- Vendor Master Admin
- Customer Master Admin
- Item Master Admin
- Organization Master Admin

## 2.3 Purchasing Roles
- Purchase Requester
- Purchasing Staff
- Purchasing Supervisor
- Purchasing Manager
- Purchasing Viewer

## 2.4 Sales Roles
- Sales Admin
- Sales Supervisor
- Sales Manager
- Sales Viewer

## 2.5 Inventory Roles
- Warehouse Staff
- Warehouse Supervisor
- Inventory Controller
- Inventory Viewer

## 2.6 Expense / Costing Roles
- Expense Submitter
- Expense Reviewer
- Cost Controller
- Expense Viewer

## 2.7 Finance Roles
- AP Officer
- AR Officer
- GL Officer
- Treasury Staff
- Finance Supervisor
- Finance Manager
- Finance Viewer

## 2.8 Cross-Cutting Roles
- Executive Viewer
- Internal Auditor
- System Support (sangat terbatas)
- Data Migration Admin (sementara, highly controlled)

## 2.9 Prinsip Pembentukan Role
- Jangan bentuk role berdasarkan satu layar
- Jangan bentuk role terlalu mikro dari awal
- Jangan campur create/approve/post semua dalam satu role tanpa alasan jelas
- Gunakan multi-role assignment untuk kasus pekerjaan ganda
- Gunakan masa berlaku assignment untuk kebutuhan sementara

# 3. Authorization Object Catalogue

Authorization object harus stabil, berbasis fungsi bisnis, dan bisa dipakai lintas backend, frontend, testing, dan governance.

## 3.1 Governance Objects
- ROLE
- ROLE_ASSIGNMENT
- AUTHORIZATION_OBJECT
- ROLE_PERMISSION
- ROLE_CONTEXT_RULE
- APPROVAL_RULE
- DELEGATION_RULE
- AUDIT_LOG
- SYSTEM_POLICY

## 3.2 Master Data Objects
- COMPANY
- BUSINESS_UNIT
- BRANCH
- DEPARTMENT
- WAREHOUSE
- VENDOR
- CUSTOMER
- ITEM
- ITEM_CATEGORY
- UOM
- CURRENCY
- TAX_CODE
- PAYMENT_TERM
- COST_CENTER
- ACCOUNT_MASTER_REFERENCE

## 3.3 Purchasing Objects
- PURCHASE_REQUEST
- PURCHASE_REQUEST_LINE
- PURCHASE_ORDER
- PURCHASE_ORDER_LINE
- PURCHASE_APPROVAL
- PURCHASE_DOCUMENT_ATTACHMENT

## 3.4 Sales Objects
- SALES_ORDER
- SALES_ORDER_LINE
- SALES_DELIVERY
- SALES_PRICING_OVERRIDE
- SALES_RETURN

## 3.5 Inventory Objects
- GOODS_RECEIPT
- GOODS_ISSUE
- STOCK_TRANSFER
- STOCK_ADJUSTMENT
- STOCK_RESERVATION
- STOCK_BALANCE
- STOCK_MOVEMENT

## 3.6 Expense / Costing Objects
- EXPENSE_REQUEST
- EXPENSE_CATEGORY
- EXPENSE_ALLOCATION
- PETTY_CASH_ENTRY
- COST_ALLOCATION_RULE

## 3.7 Finance Objects
- JOURNAL_ENTRY
- ACCOUNTS_PAYABLE
- ACCOUNTS_RECEIVABLE
- PAYMENT
- RECEIPT
- CASH_BANK_ACCOUNT
- FISCAL_PERIOD
- RECONCILIATION

## 3.8 Reporting / Visibility Objects
- DASHBOARD
- OPERATIONAL_REPORT
- FINANCIAL_REPORT
- EXPORT_JOB

## 3.9 Catatan Penting
Tidak semua object harus langsung aktif di fase pertama.  
Tetapi daftar ini membantu menjaga bahasa sistem tetap konsisten.

# 4. Action Catalogue

Gunakan action catalogue yang stabil. Jangan buat tiap modul punya kata kerja liar sendiri jika maknanya sama.

## 4.1 Action Umum
- CREATE
- READ
- UPDATE
- DELETE
- LIST
- EXPORT

## 4.2 Action Workflow
- SUBMIT
- APPROVE
- REJECT
- CANCEL
- CLOSE
- REOPEN
- CONFIRM

## 4.3 Action Operasional
- ISSUE
- RECEIVE
- RESERVE
- RELEASE
- ALLOCATE
- TRANSFER
- ADJUST

## 4.4 Action Finansial
- POST
- REVERSE
- PAY
- RECEIVE_PAYMENT
- RECONCILE

## 4.5 Action Governance
- ASSIGN
- DELEGATE
- ACTIVATE
- DEACTIVATE

## 4.6 Prinsip Pemakaian Action
- `READ` dipakai untuk view detail
- `LIST` dipakai untuk melihat daftar/search
- `UPDATE` hanya untuk ubah data yang diizinkan
- `APPROVE` tidak sama dengan `UPDATE`
- `POST` tidak sama dengan `APPROVE`
- `CANCEL` tidak sama dengan `DELETE`
- `REVERSE` bukan edit balik, tapi tindakan resmi pembalikan

## 4.7 Mapping Action ke UI
Frontend dapat memakai action catalogue untuk:
- show/hide tombol
- enable/disable aksi
- guard halaman tertentu

Tetapi sekali lagi, backend tetap final authority.

# 5. Context Catalogue

Context menentukan cakupan data yang boleh disentuh user. Ini adalah kunci agar satu sistem bisa dipakai lintas unit tanpa menjadi liar.

## 5.1 Context Inti yang Direkomendasikan
- company_code
- business_unit_code
- branch_code
- department_code
- warehouse_code
- cost_center_code
- sales_org_code
- currency_code (jika relevan untuk policy tertentu)
- fiscal_period
- owner_user_id (untuk draft milik sendiri)
- vendor_group
- customer_group
- item_category_code

## 5.2 Prinsip Penggunaan Context
- gunakan hanya context yang memang punya nilai bisnis
- jangan menambahkan context terlalu banyak sejak awal
- pastikan field context benar-benar ada di data transaksi/master
- context harus bisa di-evaluate oleh backend secara deterministik

## 5.3 Context Global vs Object-Specific
Beberapa context rule berlaku lintas object dalam satu role.  
Contoh:
- company_code = 1000 untuk hampir semua object operasional role itu

Beberapa context rule hanya berlaku untuk object tertentu.  
Contoh:
- warehouse_code hanya relevan untuk inventory object
- owner_user_id hanya relevan untuk draft tertentu

## 5.4 Pola Rule Context
- EQUALS
- IN
- NOT_EQUALS
- OWNS_RECORD
- SAME_BUSINESS_UNIT
- SAME_COMPANY

Untuk fase awal, EQUALS dan IN sudah cukup kuat.

# 6. Role Definition Detail

Bagian ini mendefinisikan tanggung jawab tiap role family secara lebih nyata.

## 6.1 Governance Admin
Tanggung jawab:
- mengelola role
- mengelola role assignment
- mengelola role permission
- mengelola role context rule
- mengelola approval rule
- melihat audit log governance dan operasional tertentu

Batasan:
- tidak otomatis boleh melakukan transaksi purchasing/sales/finance operasional
- tidak otomatis boleh memposting finance
- perubahan governance harus teraudit

## 6.2 Security Admin
Tanggung jawab:
- mengelola aspek keamanan hak akses tertentu
- review permission conflict
- membantu hardening governance

Batasan:
- tidak menjadi superuser bisnis
- akses operasional sangat terbatas

## 6.3 Auditor
Tanggung jawab:
- membaca data dan audit tertentu
- melihat histori perubahan
- melihat jejak approval dan posting

Batasan:
- read-only
- export dibatasi policy

## 6.4 Master Data Viewer
Read-only ke master relevan.

## 6.5 Vendor Master Admin
- create/update vendor
- activate/deactivate vendor
- melihat histori vendor

Batasan:
- tidak otomatis boleh membuat transaksi purchasing atau AP

## 6.6 Item Master Admin
- create/update item
- activate/deactivate item
- maintain item category/UOM tertentu bila dirancang demikian

## 6.7 Purchase Requester
- create PR
- edit draft PR sendiri
- submit PR sendiri
- read PR dalam context yang diizinkan
- cancel draft/submitted PR sesuai policy

Batasan:
- tidak boleh approve PR
- tidak boleh create/approve PO

## 6.8 Purchasing Staff
- read PR
- create PO
- update draft PO
- submit PO
- read vendor/item yang relevan

Batasan:
- approval tergantung role tambahan
- tidak otomatis boleh maintain vendor

## 6.9 Purchasing Supervisor
- review PR/PO
- approve PR/PO pada level tertentu
- melihat transaksi purchasing dalam scope lebih luas

## 6.10 Purchasing Manager
- approve PR/PO level tinggi
- close/cancel tertentu dengan kontrol
- melihat laporan purchasing lebih luas

## 6.11 Sales Admin
- create SO
- edit draft SO
- submit/confirm SO sesuai policy
- maintain operational sales document

## 6.12 Sales Supervisor / Manager
- approve override harga/diskon tertentu
- approve/confirm order penting
- melihat kinerja sales dan transaksi dalam scope

## 6.13 Warehouse Staff
- read receiving/issue tasks
- create/post goods receipt tertentu
- create/post goods issue tertentu
- execute transfer tertentu

Batasan:
- stock adjustment dibatasi
- tidak maintain item master

## 6.14 Inventory Controller
- review stock movement
- approve/post adjustment tertentu
- lihat stock balance lintas warehouse sesuai scope

## 6.15 Expense Submitter
- create expense request sendiri
- update draft sendiri
- submit sendiri
- lihat histori expense sendiri dan sesuai scope

## 6.16 Cost Controller
- review allocation
- lihat analisa biaya
- maintain cost allocation rule jika policy mengizinkan

## 6.17 AP Officer
- create/validate payable
- post AP sesuai role
- record payment draft sesuai separation

## 6.18 AR Officer
- create/post receivable
- record receipt
- monitor outstanding AR

## 6.19 GL Officer
- create/post journal tertentu
- reverse journal sesuai rule
- manage reconciliation tertentu

## 6.20 Treasury Staff
- execute payment/receipt movement
- manage bank/cash operational record
- tidak otomatis boleh membuat AP/AR

## 6.21 Finance Manager
- approve posting / reversal tertentu
- kontrol period tertentu
- lihat laporan keuangan sesuai scope

# 7. Access Control Matrix — Governance

Matriks berikut adalah referensi awal. Implementasi riil bisa menyesuaikan, tetapi pola kontrolnya sebaiknya dijaga.

## 7.1 Governance Matrix

| Role | Object | Actions | Context | Catatan |
|---|---|---|---|---|
| Governance Admin | ROLE | CREATE, READ, UPDATE, ACTIVATE, DEACTIVATE, LIST | company/global policy scope | perubahan teraudit |
| Governance Admin | ROLE_ASSIGNMENT | CREATE, READ, UPDATE, ASSIGN, DEACTIVATE, LIST | company/business unit scope | masa berlaku didukung |
| Governance Admin | ROLE_PERMISSION | CREATE, READ, UPDATE, DEACTIVATE, LIST | global | object/action harus valid |
| Governance Admin | ROLE_CONTEXT_RULE | CREATE, READ, UPDATE, DEACTIVATE, LIST | global | |
| Governance Admin | APPROVAL_RULE | CREATE, READ, UPDATE, ACTIVATE, DEACTIVATE, LIST | company/business unit scope | histori perubahan penting |
| Governance Admin | DELEGATION_RULE | CREATE, READ, UPDATE, DEACTIVATE, LIST | approver scope | |
| Governance Admin | AUDIT_LOG | READ, LIST, EXPORT | policy-limited | export dibatasi |
| Security Admin | ROLE | READ, LIST | global | biasanya read-heavy |
| Security Admin | ROLE_PERMISSION | READ, LIST | global | review keamanan |
| Security Admin | ROLE_CONTEXT_RULE | READ, LIST | global | review keamanan |
| Security Admin | ROLE_ASSIGNMENT | READ, LIST | scoped | review assignment |
| Security Admin | AUDIT_LOG | READ, LIST, EXPORT | policy-limited | |
| Auditor | AUDIT_LOG | READ, LIST, EXPORT | audit scope | read-only |
| Auditor | APPROVAL_RULE | READ, LIST | scoped | untuk audit kontrol |
| Auditor | ROLE | READ, LIST | scoped | |
| Auditor | ROLE_ASSIGNMENT | READ, LIST | scoped | |

# 8. Access Control Matrix — Master Data

## 8.1 Master Data Matrix

| Role | Object | Actions | Context | Catatan |
|---|---|---|---|---|
| Master Data Viewer | COMPANY | READ, LIST | scope per company | |
| Master Data Viewer | BUSINESS_UNIT | READ, LIST | scope per company | |
| Master Data Viewer | WAREHOUSE | READ, LIST | scope per company/BU | |
| Master Data Viewer | VENDOR | READ, LIST | scope per company | |
| Master Data Viewer | CUSTOMER | READ, LIST | scope per company | |
| Master Data Viewer | ITEM | READ, LIST | scope per company/category | |
| Vendor Master Admin | VENDOR | CREATE, READ, UPDATE, ACTIVATE, DEACTIVATE, LIST | company_code | tidak untuk transaksi purchasing |
| Customer Master Admin | CUSTOMER | CREATE, READ, UPDATE, ACTIVATE, DEACTIVATE, LIST | company_code | |
| Item Master Admin | ITEM | CREATE, READ, UPDATE, ACTIVATE, DEACTIVATE, LIST | company_code / item_category | |
| Organization Master Admin | COMPANY | READ, LIST | assigned scope | biasanya tidak create sembarang |
| Organization Master Admin | BUSINESS_UNIT | CREATE, READ, UPDATE, ACTIVATE, DEACTIVATE, LIST | company_code | |
| Organization Master Admin | BRANCH | CREATE, READ, UPDATE, ACTIVATE, DEACTIVATE, LIST | company_code | |
| Organization Master Admin | DEPARTMENT | CREATE, READ, UPDATE, ACTIVATE, DEACTIVATE, LIST | company_code/business_unit | |
| Organization Master Admin | WAREHOUSE | CREATE, READ, UPDATE, ACTIVATE, DEACTIVATE, LIST | company_code/business_unit | |

# 9. Access Control Matrix — Purchasing

## 9.1 Purchasing Matrix

| Role | Object | Actions | Context | Catatan |
|---|---|---|---|---|
| Purchase Requester | PURCHASE_REQUEST | CREATE, READ, LIST, UPDATE, SUBMIT, CANCEL | company_code, business_unit_code, owner_user_id untuk draft tertentu | draft/edit milik sendiri |
| Purchase Requester | PURCHASE_REQUEST_LINE | CREATE, READ, UPDATE, DELETE | parent PR context | selama PR draft |
| Purchase Requester | VENDOR | READ, LIST | company_code | read-only |
| Purchase Requester | ITEM | READ, LIST | company_code / item_category | read-only |
| Purchasing Staff | PURCHASE_REQUEST | READ, LIST | company_code, business_unit_code | visibility operasional |
| Purchasing Staff | PURCHASE_ORDER | CREATE, READ, LIST, UPDATE, SUBMIT, CANCEL | company_code, business_unit_code | create dari PR approved / manual by policy |
| Purchasing Staff | PURCHASE_ORDER_LINE | CREATE, READ, UPDATE, DELETE | parent PO context | selama draft |
| Purchasing Staff | VENDOR | READ, LIST | company_code | |
| Purchasing Staff | ITEM | READ, LIST | company_code | |
| Purchasing Supervisor | PURCHASE_REQUEST | READ, LIST, APPROVE, REJECT | company_code, business_unit_code | level approval tertentu |
| Purchasing Supervisor | PURCHASE_ORDER | READ, LIST, APPROVE, REJECT | company_code, business_unit_code | level approval tertentu |
| Purchasing Manager | PURCHASE_REQUEST | READ, LIST, APPROVE, REJECT, CLOSE | company_code | approval level tinggi |
| Purchasing Manager | PURCHASE_ORDER | READ, LIST, APPROVE, REJECT, ISSUE, CLOSE, CANCEL | company_code | policy-controlled |
| Purchasing Viewer | PURCHASE_REQUEST | READ, LIST | scoped | read-only |
| Purchasing Viewer | PURCHASE_ORDER | READ, LIST | scoped | read-only |

# 10. Access Control Matrix — Sales

## 10.1 Sales Matrix

| Role | Object | Actions | Context | Catatan |
|---|---|---|---|---|
| Sales Admin | SALES_ORDER | CREATE, READ, LIST, UPDATE, SUBMIT, CONFIRM, CANCEL | company_code, business_unit_code, sales_org_code | confirm sesuai policy |
| Sales Admin | SALES_ORDER_LINE | CREATE, READ, UPDATE, DELETE | parent SO context | selama draft |
| Sales Admin | CUSTOMER | READ, LIST | company_code / sales_org_code | |
| Sales Admin | ITEM | READ, LIST | company_code / item_category | |
| Sales Admin | SALES_DELIVERY | READ, LIST | scope operasional | jika delivery ditangani tim lain, create bisa dibatasi |
| Sales Supervisor | SALES_ORDER | READ, LIST, APPROVE, REJECT, CONFIRM | company_code, sales_org_code | approval diskon/override |
| Sales Supervisor | SALES_PRICING_OVERRIDE | APPROVE, REJECT, READ, LIST | company_code, sales_org_code | |
| Sales Manager | SALES_ORDER | READ, LIST, APPROVE, REJECT, CLOSE, CANCEL | company_code | level tinggi |
| Sales Manager | SALES_PRICING_OVERRIDE | APPROVE, REJECT, READ, LIST | company_code | |
| Sales Viewer | SALES_ORDER | READ, LIST | scoped | read-only |
| Sales Viewer | SALES_DELIVERY | READ, LIST | scoped | read-only |

# 11. Access Control Matrix — Inventory

## 11.1 Inventory Matrix

| Role | Object | Actions | Context | Catatan |
|---|---|---|---|---|
| Warehouse Staff | GOODS_RECEIPT | CREATE, READ, LIST, RECEIVE, POST, CANCEL | company_code, warehouse_code | against valid PO |
| Warehouse Staff | GOODS_ISSUE | CREATE, READ, LIST, ISSUE, POST, CANCEL | company_code, warehouse_code | against valid source |
| Warehouse Staff | STOCK_TRANSFER | CREATE, READ, LIST, TRANSFER, CONFIRM | company_code, warehouse_code | source/target scope per policy |
| Warehouse Staff | STOCK_BALANCE | READ, LIST | warehouse_code | |
| Warehouse Staff | STOCK_MOVEMENT | READ, LIST | warehouse_code | |
| Warehouse Supervisor | GOODS_RECEIPT | READ, LIST, APPROVE, CANCEL | warehouse/company scope | jika approval receiving diterapkan |
| Warehouse Supervisor | GOODS_ISSUE | READ, LIST, APPROVE, CANCEL | warehouse/company scope | |
| Warehouse Supervisor | STOCK_TRANSFER | READ, LIST, APPROVE, CANCEL, CLOSE | warehouse/company scope | |
| Inventory Controller | STOCK_ADJUSTMENT | CREATE, READ, LIST, UPDATE, SUBMIT, APPROVE, POST, CANCEL | company_code, warehouse_code | sangat sensitif |
| Inventory Controller | STOCK_BALANCE | READ, LIST | company_code, warehouse_code | |
| Inventory Controller | STOCK_MOVEMENT | READ, LIST, EXPORT | company_code, warehouse_code | |
| Inventory Viewer | STOCK_BALANCE | READ, LIST | scoped | |
| Inventory Viewer | STOCK_MOVEMENT | READ, LIST | scoped | |

# 12. Access Control Matrix — Expense and Costing

## 12.1 Expense / Costing Matrix

| Role | Object | Actions | Context | Catatan |
|---|---|---|---|---|
| Expense Submitter | EXPENSE_REQUEST | CREATE, READ, LIST, UPDATE, SUBMIT, CANCEL | company_code, business_unit_code, owner_user_id | draft/own-focused |
| Expense Submitter | EXPENSE_ALLOCATION | CREATE, READ, UPDATE, DELETE | parent expense context | jika allocation dibuka ke submitter |
| Expense Reviewer | EXPENSE_REQUEST | READ, LIST, APPROVE, REJECT | company_code, business_unit_code / cost_center | |
| Cost Controller | EXPENSE_REQUEST | READ, LIST | company_code, cost_center_code | analisa biaya |
| Cost Controller | EXPENSE_ALLOCATION | CREATE, READ, UPDATE, APPROVE, LIST | company_code, cost_center_code | |
| Cost Controller | COST_ALLOCATION_RULE | CREATE, READ, UPDATE, ACTIVATE, DEACTIVATE, LIST | company_code | |
| Expense Viewer | EXPENSE_REQUEST | READ, LIST | scoped | |

# 13. Access Control Matrix — Finance

## 13.1 Finance Matrix

| Role | Object | Actions | Context | Catatan |
|---|---|---|---|---|
| AP Officer | ACCOUNTS_PAYABLE | CREATE, READ, LIST, UPDATE, VALIDATE, POST | company_code | against valid source policy |
| AP Officer | PAYMENT | CREATE, READ, LIST, UPDATE, SUBMIT | company_code, cash_bank_scope | payment execution dipisah bila perlu |
| AR Officer | ACCOUNTS_RECEIVABLE | CREATE, READ, LIST, UPDATE, POST | company_code | |
| AR Officer | RECEIPT | CREATE, READ, LIST, UPDATE, POST | company_code, cash_bank_scope | |
| GL Officer | JOURNAL_ENTRY | CREATE, READ, LIST, UPDATE, POST, REVERSE | company_code, fiscal_period | restricted by policy |
| GL Officer | RECONCILIATION | CREATE, READ, LIST, UPDATE, CLOSE | company_code | |
| Treasury Staff | PAYMENT | READ, LIST, APPROVE, PAY, POST | company_code, cash_bank_scope | execution-focused |
| Treasury Staff | RECEIPT | READ, LIST, RECEIVE_PAYMENT, POST | company_code, cash_bank_scope | |
| Finance Supervisor | ACCOUNTS_PAYABLE | READ, LIST, APPROVE, REJECT, CLOSE | company_code | |
| Finance Supervisor | ACCOUNTS_RECEIVABLE | READ, LIST, APPROVE, CLOSE | company_code | |
| Finance Supervisor | JOURNAL_ENTRY | READ, LIST, APPROVE, REVERSE | company_code, fiscal_period | |
| Finance Manager | FISCAL_PERIOD | READ, LIST, OPEN, CLOSE | company_code | highly sensitive |
| Finance Manager | JOURNAL_ENTRY | READ, LIST, APPROVE, REVERSE, EXPORT | company_code | level tinggi |
| Finance Manager | PAYMENT | READ, LIST, APPROVE, EXPORT | company_code | |
| Finance Viewer | JOURNAL_ENTRY | READ, LIST | scoped | read-only |
| Finance Viewer | ACCOUNTS_PAYABLE | READ, LIST | scoped | |
| Finance Viewer | ACCOUNTS_RECEIVABLE | READ, LIST | scoped | |

# 14. Access Control Matrix — Reporting and Visibility

## 14.1 Reporting Matrix

| Role | Object | Actions | Context | Catatan |
|---|---|---|---|---|
| Executive Viewer | DASHBOARD | READ, LIST | company_code / executive scope | mostly read-only |
| Executive Viewer | OPERATIONAL_REPORT | READ, LIST, EXPORT | company_code | |
| Executive Viewer | FINANCIAL_REPORT | READ, LIST, EXPORT | company_code | policy-limited |
| Internal Auditor | OPERATIONAL_REPORT | READ, LIST, EXPORT | audit scope | |
| Internal Auditor | FINANCIAL_REPORT | READ, LIST, EXPORT | audit scope | |
| Internal Auditor | EXPORT_JOB | CREATE, READ, LIST | audit scope | for controlled exports |

# 15. SoD (Segregation of Duties) — Aturan Awal

SoD tidak harus langsung menjadi engine yang sangat kompleks, tetapi aturan dasarnya sebaiknya sudah didefinisikan.

## 15.1 Prinsip Umum
- maker dan approver sebaiknya dipisah untuk transaksi sensitif
- creator master data kritikal tidak otomatis menjadi approver transaksi turunannya
- poster finansial tidak otomatis menjadi approver semua sumber operasional
- governance admin tidak otomatis menjadi finance/purchasing operator

## 15.2 SoD Rules Awal yang Direkomendasikan

### Rule 1
User yang memiliki role `Vendor Master Admin` tidak sebaiknya sekaligus memiliki wewenang final untuk `PAYMENT.APPROVE` tanpa kontrol tambahan.

### Rule 2
User yang membuat `PURCHASE_REQUEST` tidak sebaiknya menjadi approver final untuk request yang sama jika policy perusahaan mensyaratkan pemisahan.

### Rule 3
User yang membuat draft `PURCHASE_ORDER` tidak sebaiknya menjadi approver final PO yang sama pada level tertentu.

### Rule 4
User yang memiliki `STOCK_ADJUSTMENT.POST` tidak sebaiknya sekaligus memegang approval keuangan final tanpa kontrol tambahan.

### Rule 5
User yang memiliki `JOURNAL_ENTRY.POST` tidak sebaiknya bebas melakukan `FISCAL_PERIOD.CLOSE` tanpa pembatasan role lebih tinggi.

### Rule 6
User yang memiliki `ROLE_ASSIGNMENT.ASSIGN` tidak sebaiknya bisa assign role governance sensitif ke dirinya sendiri tanpa mekanisme dual control.

### Rule 7
User yang memiliki `PAYMENT.PAY/POST` tidak sebaiknya sekaligus membuat vendor dan memvalidasi AP final tanpa kontrol.

### Rule 8
User yang memiliki `SALES_PRICING_OVERRIDE.APPROVE` tidak sebaiknya juga bisa membuat seluruh setup pricing policy tanpa governance yang memadai.

## 15.3 Bentuk Implementasi Awal SoD
- warning pada assignment role
- daftar kombinasi role terlarang atau perlu approval
- report berkala user-role conflict
- validasi transaksi tertentu berbasis “maker != approver”

## 15.4 Bentuk Implementasi Lanjutan
- matrix conflict formal
- exception approval workflow
- periodic SoD review
- detective control reports

# 16. Policy Notes per Area

## 16.1 Draft Ownership Policy
Untuk beberapa object seperti PR, SO, Expense:
- creator boleh edit draft sendiri
- setelah submit, rule berubah
- owner-based context sering diperlukan

## 16.2 Cross-Unit Policy
Untuk role operasional:
- scope sebaiknya dibatasi company / business unit
- cross-unit access diberikan hanya jika memang perlu

## 16.3 Viewer Policy
Role viewer sebaiknya:
- read/list only
- export dibatasi
- tidak punya action workflow

## 16.4 Export Policy
Export data adalah aksi sensitif.  
Tidak semua role READ otomatis boleh EXPORT.

## 16.5 Approval Policy
Approval tidak sama dengan update.  
Role yang boleh update draft belum tentu boleh approve.

## 16.6 Posting Policy
Posting di finance/inventory adalah aksi berisiko tinggi.  
Bila perlu, pisahkan:
- prepare draft
- approve
- post

# 17. Implementasi Teknis yang Diturunkan dari Volume 3

Volume ini harus diturunkan menjadi artefak implementasi berikut:

## 17.1 Seed Data
- seed role families
- seed authorization objects
- seed action catalogue
- seed default role permissions
- seed role context template

## 17.2 Backend
- `RolePermission` model population
- `RoleContextRule` population
- `authorize(user, object, action, context)` service
- DRF permission class generik
- permission summary endpoint untuk frontend

## 17.3 Frontend
- menu map berdasarkan module visibility
- action guard untuk tombol dan page actions
- route guard untuk halaman yang sangat sensitif
- permission-aware table actions

## 17.4 QA / Testing
- matriks skenario per role
- uji maker/approver separation
- uji context restriction
- uji multi-role user
- uji default deny

## 17.5 Governance Operation
- prosedur review assignment
- prosedur review SoD conflict
- histori perubahan role dan approval rule

# 18. Contoh Permission Summary untuk Frontend

Frontend tidak perlu menerima seluruh rule detail, tetapi akan sangat terbantu jika backend menyediakan ringkasan seperti:

```json
{
  "roles": ["PURCHASING_STAFF", "PURCHASE_REQUESTER"],
  "modules": {
    "purchasing": true,
    "sales": false,
    "inventory": false,
    "finance": false,
    "governance": false
  },
  "permissions": {
    "PURCHASE_REQUEST": ["CREATE", "READ", "LIST", "UPDATE", "SUBMIT"],
    "PURCHASE_ORDER": ["CREATE", "READ", "LIST", "UPDATE", "SUBMIT"]
  },
  "contexts": {
    "company_code": ["1000"],
    "business_unit_code": ["BU01"]
  }
}
```

Catatan:
- ini hanya summary
- backend tetap memeriksa izin sebenarnya per request
- frontend memakai summary ini untuk UX, bukan enforcement final

# 19. Checklist Validasi Authorization Sebelum Go-Live Modul

Gunakan checklist ini sebelum modul dinyatakan siap digunakan.

## 19.1 Role
- Apakah semua role awal sudah didefinisikan?
- Apakah role campur aduk sudah dihindari?
- Apakah multi-role scenario sudah diuji?

## 19.2 Object
- Apakah daftar authorization object final awal sudah disepakati?
- Apakah object berbasis fungsi bisnis, bukan menu?

## 19.3 Action
- Apakah action vocabulary konsisten?
- Apakah `APPROVE`, `POST`, `EXPORT`, `CANCEL`, `REVERSE` dibedakan dengan jelas?

## 19.4 Context
- Apakah transaksi punya field context yang cukup?
- Apakah context rules sudah diuji di backend?
- Apakah lintas company / business unit sudah aman?

## 19.5 SoD
- Apakah kombinasi role sensitif sudah diidentifikasi?
- Apakah maker/approver separation diuji?

## 19.6 Frontend
- Apakah menu tidak menunjukkan akses palsu?
- Apakah tombol disembunyikan/disable sesuai summary?

## 19.7 Backend
- Apakah semua endpoint kritikal memakai permission check?
- Apakah tidak ada shortcut bypass?
- Apakah default deny berlaku?

## 19.8 Audit
- Apakah approval, reject, cancel, post, reverse, assignment tercatat?

# 20. Kesimpulan Volume 3

Volume 3 mengubah blueprint arsitektur dan workflow menjadi **sistem kontrol nyata**.

Isi utamanya:
- role family
- authorization object catalogue
- action catalogue
- context catalogue
- role definition detail
- matriks hak akses lintas modul
- SoD awal
- arahan implementasi ke backend/frontend/testing

Dengan Volume 1, 2, dan 3 digabung, tim sudah memiliki:
- fondasi arsitektur
- domain dan workflow
- kontrol hak akses yang implementable

Ini adalah titik di mana sistem mulai benar-benar bisa dibangun dengan disiplin.

---

## Langkah Lanjutan yang Direkomendasikan

Dokumen paling natural setelah Volume 3 adalah:

### Volume 4 — Global ERD and Django Implementation Pack
Isi utamanya:
- ERD lintas modul yang lebih lengkap
- Django models per domain
- service layer pattern
- contoh `authorize()` yang lebih matang
- DRF permission class generik
- seed strategy rinci
- transaction boundary pattern
- audit hook strategy

Volume 4 akan menjadi jembatan langsung ke codebase backend.