# MASTER BLUEPRINT ENTERPRISE SYSTEM ## Volume 2 — Functional Specification and Workflow ### Django + Next.js for Multi-Module Enterprise Platform **Versi:** 1.0 **Posisi dokumen:** lanjutan dari Volume 1 **Tujuan utama:** menerjemahkan domain blueprint menjadi spesifikasi fungsional, alur kerja, status transaksi, aturan validasi, dan relasi proses lintas modul. --- ## Cara Membaca Volume 2 Jika Volume 1 menjawab: - sistem ini dibangun dengan filosofi apa - modul apa saja yang ada - siapa pemilik domain apa - bagaimana authorization dipikirkan maka Volume 2 menjawab: - fitur inti tiap modul apa - alur proses utama seperti apa - status dan transisi dokumen bagaimana - validasi penting apa yang harus diterapkan - event/side effect apa yang terjadi - relasi lintas modul terjadi pada titik mana Dokumen ini bukan daftar layar UI. Dokumen ini adalah **spesifikasi perilaku sistem**. --- ## Prinsip Dasar Volume 2 1. Fokus pada objek bisnis, bukan halaman. 2. Setiap workflow harus punya status yang jelas. 3. Setiap transisi status harus punya aturan. 4. Setiap aksi penting harus punya side effect yang terdefinisi. 5. Setiap modul harus jelas titik integrasinya dengan modul lain. 6. Tidak semua fitur harus dibuat di fase pertama, tapi struktur perilakunya harus dipikirkan sejak awal. # 1. Vocabulary dan Aturan Umum ## 1.1 Istilah Dasar ### Draft Dokumen belum final, masih bisa diubah oleh pihak yang berwenang. ### Submitted Dokumen sudah diajukan ke proses berikutnya dan tidak boleh diedit bebas seperti draft. ### Under Review Dokumen sedang dalam proses peninjauan / approval. ### Approved Dokumen disetujui untuk dipakai sebagai dasar proses berikutnya. ### Rejected Dokumen ditolak dan biasanya kembali butuh revisi atau dihentikan. ### Cancelled Dokumen dibatalkan secara resmi dan tidak boleh dipakai untuk proses lanjutan. ### Closed Dokumen dianggap selesai dan tidak lagi aktif untuk proses lanjutan normal. ### Posted Dokumen atau efek transaksi sudah menjadi catatan resmi yang memengaruhi ledger atau kontrol final. ### Reversed Efek transaksi resmi sudah dibalik melalui mekanisme yang sah. ## 1.2 Aturan Umum Validasi Workflow - Status hanya boleh berpindah melalui aksi yang valid. - Setiap perpindahan status harus tercatat. - Dokumen yang sudah diapprove tidak boleh diedit bebas. - Dokumen yang sudah dipakai modul lain harus punya kontrol pembatalan yang lebih ketat. - Side effect hanya boleh terjadi dari service layer backend. - Approval tidak boleh hanya mengandalkan visibilitas tombol di frontend. ## 1.3 Pola Fungsi yang Disarankan Setiap objek bisnis minimal memiliki fungsi berikut sesuai kebutuhan: - create - update draft - submit - approve / reject - cancel - view detail - list / search - attach documents / notes - history / timeline - print / export jika relevan Tidak semua modul perlu semua fungsi, tetapi pola ini membantu standarisasi desain. # 2. Functional Specification — Governance Governance adalah modul pengendali aturan. Ia tidak berfokus pada transaksi barang atau uang, tetapi pada **aturan siapa boleh berbuat apa**, **bagaimana approval berjalan**, dan **bagaimana sistem dikontrol**. ## 2.1 Tujuan Fungsional - mengelola role bisnis - mengelola assignment role - mengelola authorization object dan action exposure - mengelola approval rule - mengelola delegation rule - menyediakan akses audit tertentu - menyediakan pusat kebijakan pengendalian tertentu ## 2.2 Subdomain Governance - Authorization Management - Role Assignment Management - Approval Rule Management - Delegation Management - Audit Visibility - Policy Registry ringan (opsional) ## 2.3 Objek Bisnis Inti - Role - User Role Assignment - Authorization Object - Role Permission - Role Context Rule - Approval Rule - Delegation Rule - Audit Log ## 2.4 Fitur Inti ### 2.4.1 Role Management Fungsi: - buat role - ubah nama/deskripsi role - aktifkan/nonaktifkan role - lihat daftar role - lihat detail role - duplikasi role dari template - lihat permission role - lihat context rule role Validasi penting: - role code unik - role yang masih dipakai aktif tidak boleh dihapus keras - perubahan role kritikal sebaiknya tercatat ### 2.4.2 Role Permission Management Fungsi: - tambah permission ke role - cabut permission dari role - lihat permission matrix role - filter permission berdasarkan modul/object/action Validasi: - kombinasi role + object + action harus unik - action harus berasal dari kamus action resmi - object harus aktif ### 2.4.3 Role Context Rule Management Fungsi: - tambah rule context - ubah rule context - nonaktifkan rule context - lihat rule context per role - lihat rule context per object Validasi: - field context harus valid - operator harus dikenali engine - value harus cocok dengan tipe field target ### 2.4.4 User Role Assignment Fungsi: - assign role ke user - ubah masa berlaku assignment - nonaktifkan assignment - lihat histori assignment - assign role sementara - assign role lintas unit tertentu Validasi: - assignment duplikat dicegah - assignment kadaluarsa tidak ikut dihitung aktif - assignee dan assigner harus tercatat - beberapa kombinasi role mungkin perlu warning SoD ### 2.4.5 Approval Rule Management Fungsi: - buat approval rule - ubah approval rule - aktifkan/nonaktifkan rule - lihat rule per modul/object - lihat rule berdasarkan batas nominal/unit/company Validasi: - rule tidak boleh ambigu untuk kondisi yang sama tanpa prioritas jelas - rule harus mengacu ke role approver yang valid - histori perubahan rule penting harus tersedia ### 2.4.6 Delegation Rule Management Fungsi: - buat delegasi approver - tentukan masa berlaku - batalkan delegasi - lihat delegasi aktif Validasi: - delegasi tidak boleh aktif tanpa batas jika policy melarang - delegasi tidak boleh membuat konflik ekstrem tanpa warning - delegasi harus tercatat jelas ### 2.4.7 Audit Access Fungsi: - lihat audit log - filter berdasarkan modul/aksi/user/tanggal - lihat perubahan entitas tertentu - ekspor audit subset tertentu jika diizinkan Validasi: - akses audit dibatasi ketat - data sensitif di audit mungkin perlu masking atau pembatasan tampilan tertentu ## 2.5 Workflow Utama ### Workflow A — Membuat Role Baru 1. Governance Admin membuka daftar role 2. pilih create role 3. isi code, name, description 4. simpan role 5. tambah permission 6. tambah context rule jika perlu 7. aktivasi role untuk dipakai Status implisit role: - DRAFT/INACTIVE (opsional) - ACTIVE - INACTIVE ### Workflow B — Assign Role ke User 1. Governance Admin buka detail user 2. tambahkan role assignment 3. tentukan valid_from / valid_to 4. simpan 5. assignment aktif dan mulai dihitung engine authorization ### Workflow C — Membuat Approval Rule 1. Governance Admin pilih modul/object 2. tentukan kondisi rule: - company - business unit - nominal min/max - level approval 3. tentukan approver role 4. simpan dan aktifkan ## 2.6 Side Effect Penting - perubahan role assignment langsung memengaruhi authorization runtime - perubahan approval rule memengaruhi transaksi yang belum final sesuai policy - perubahan governance harus masuk audit log ## 2.7 Risiko dan Catatan Implementasi - governance harus punya proteksi sendiri - jangan izinkan user mudah mengubah akses dirinya sendiri tanpa kontrol - jangan jadikan modul ini area “semua setting” - approval rule dan role assignment sangat sensitif dan harus teraudit # 3. Functional Specification — Master Data Master Data adalah pusat kualitas data referensi. Bila modul ini lemah, modul lain akan ikut lemah. ## 3.1 Tujuan Fungsional - menyediakan data referensi standar - mencegah duplikasi entitas inti - menjaga konsistensi coding dan atribut bisnis - menyediakan status aktif/nonaktif dan lifecycle data referensi ## 3.2 Objek Bisnis Inti - Company - Business Unit - Branch - Department - Warehouse - Vendor - Customer - Item - Item Category - UOM - Currency - Tax Code - Payment Term - Cost Center - Account reference tertentu ## 3.3 Fitur Inti Umum untuk Semua Master - create master - update master - activate/deactivate master - search/filter/list - view detail - lihat histori perubahan - import data terbatas jika relevan - export data jika relevan - relasi / dependency check sebelum deactivation ## 3.4 Aturan Umum Master Data - code harus unik dalam scope yang ditentukan - hard delete dihindari - entity penting pakai `is_active` - perubahan master kritikal harus tercatat - data yang sudah dipakai transaksi harus punya batas perubahan tertentu ## 3.5 Vendor Management ### Fungsi - create vendor - update vendor - deactivate vendor - klasifikasikan vendor - tetapkan payment term default - tetapkan tax profile tertentu - lihat histori penggunaan vendor ### Validasi - vendor code unik per company atau global sesuai kebijakan - nama vendor minimal tervalidasi - payment term/tax/currency default valid - vendor nonaktif tidak bisa dipakai transaksi baru ### Workflow Vendor 1. Master Data Admin create vendor 2. isi data inti 3. simpan 4. optional review/approval jika company menginginkan 5. vendor aktif dan bisa dipakai Purchasing / AP Status vendor minimal: - ACTIVE - INACTIVE - PENDING_REVIEW (opsional) ## 3.6 Customer Management ### Fungsi - create customer - update customer - deactivate customer - tetapkan term pembayaran - tetapkan credit policy reference jika nanti dipakai - lihat histori transaksi customer ### Validasi - customer nonaktif tidak bisa dipakai SO baru - code unik - relasi company/business unit valid ## 3.7 Item Management ### Fungsi - create item - update item - deactivate item - klasifikasi item - set unit of measure - set inventory flag / service flag - set costing behavior reference - set default warehouse rule jika perlu ### Validasi - item code unik - UOM wajib - item inventory harus punya aturan stok - item service tidak diperlakukan seperti item stok ### Status item minimal - ACTIVE - INACTIVE ## 3.8 Warehouse Management ### Fungsi - create warehouse - update warehouse - deactivate warehouse - atur relasi ke company/unit - atur jenis warehouse ### Validasi - warehouse harus terkait ke company/unit yang valid - warehouse nonaktif tidak bisa dipakai transaksi baru ## 3.9 Company / Business Unit / Department Entitas ini penting karena banyak context authorization dan reporting bergantung padanya. ### Fungsi - create - update - activate/deactivate - lihat relasi hierarki ### Validasi - code unik di scope relevan - tidak boleh menonaktifkan entitas yang masih dipakai aktif tanpa kontrol ## 3.10 Risiko dan Catatan Implementasi - master data jangan dijadikan modul “form sederhana” - buat standar code - buat relasi yang kuat - buat batas perubahan field sensitif - tentukan master mana yang perlu approval dan mana yang cukup by role # 4. Functional Specification — Purchasing Purchasing menangkap kebutuhan, mengubahnya menjadi komitmen pembelian, dan menjadi dasar transaksi barang/jasa serta kewajiban keuangan. ## 4.1 Tujuan Fungsional - mencatat kebutuhan pembelian - mengontrol approval kebutuhan - mengubah kebutuhan yang sah menjadi order pembelian - mengontrol vendor dan nilai pembelian - menyediakan dasar receiving dan payable ## 4.2 Objek Bisnis Inti - Purchase Request - Purchase Request Line - Purchase Order - Purchase Order Line - Vendor Reference - Purchase Approval Record - Attachment / Supporting Document - Receiving Reference - Invoice Matching Reference ## 4.3 Fitur Purchase Request ### Fungsi - create PR - edit draft PR - tambah/edit/remove line - submit PR - cancel PR - approve / reject PR - view history PR - clone PR jika diperlukan - attach supporting document ### Data Utama PR - request_no - requester - company - business_unit - department (opsional sesuai desain) - requested_date - description/header note - total amount - status ### Data Utama PR Line - item/service - quantity - UOM - expected date - estimated price - note - cost center / project reference jika perlu ### Status PR - DRAFT - SUBMITTED - UNDER_REVIEW - APPROVED - REJECTED - CANCELLED - CLOSED ### Rule Per Status #### DRAFT - bisa diubah oleh pembuat / role tertentu - belum memicu approval #### SUBMITTED - tidak boleh diedit bebas - masuk jalur review/approval #### UNDER_REVIEW - sedang diproses approver #### APPROVED - menjadi kandidat sumber PO - perubahan harus sangat terkendali #### REJECTED - tidak dapat dipakai lanjut kecuali melalui mekanisme revisi/clone/reopen sesuai policy #### CANCELLED - dihentikan resmi #### CLOSED - seluruh kebutuhan sudah terpenuhi / ditutup ### Validasi PR - wajib punya company dan business unit valid - wajib punya minimal satu line - item/service valid - quantity > 0 - estimasi harga jika diwajibkan harus valid - requester harus punya izin create pada context tersebut - submit hanya boleh jika data lengkap ### Workflow PR 1. user create PR 2. isi line dan detail 3. save as draft 4. submit 5. sistem menentukan approval path 6. approver approve/reject 7. jika approved, PR dapat dijadikan dasar PO 8. jika semua line terpenuhi atau dibatalkan, PR dapat closed ### Approval PR Approval rule dapat berdasarkan: - company - business unit - nominal total - jenis item / kategori - requester role / department (opsional) ## 4.4 Fitur Purchase Order ### Fungsi - create PO from approved PR - create manual PO (hanya role tertentu bila policy mengizinkan) - edit draft PO - submit PO for approval - approve / reject PO - issue PO - cancel PO - close PO - view receiving summary - view matched invoice summary ### Data Utama PO - po_no - vendor - company - business_unit - currency - payment term - tax reference - total amount - status ### Status PO - DRAFT - PENDING_APPROVAL - APPROVED - ISSUED - PARTIALLY_RECEIVED - FULLY_RECEIVED - CLOSED - CANCELLED ### Rule Per Status #### DRAFT - masih bisa diubah #### PENDING_APPROVAL - menunggu approval #### APPROVED - sah tapi belum diissue #### ISSUED - dikirim / resmi ke vendor #### PARTIALLY_RECEIVED - sebagian line sudah diterima #### FULLY_RECEIVED - semua line diterima sesuai rule #### CLOSED - tidak aktif untuk receiving lanjutan #### CANCELLED - dibatalkan resmi ### Validasi PO - vendor wajib aktif - source PR (bila diwajibkan) harus valid dan approved - total line harus konsisten - company / business unit / currency / payment term valid - quantity/price valid - item valid - issue hanya jika status APPROVED ### Workflow PO 1. buyer pilih PR approved 2. sistem buat draft PO 3. buyer lengkapi detail vendor/term jika perlu 4. submit approval 5. approver approve/reject 6. jika approved, PO dapat issue 7. PO digunakan Inventory untuk receiving 8. PO dipakai Finance/AP untuk matching invoice 9. setelah selesai, PO closed ## 4.5 Side Effect Penting Purchasing - approved PR membuka jalur pembuatan PO - issued PO membuka jalur receiving - receiving summary memengaruhi status PO - invoice matching memengaruhi AP / closing PO - cancel/close membutuhkan validasi terhadap transaksi turunan ## 4.6 Risiko Implementasi - PR dan PO dicampur - manual PO terlalu longgar - receiving tanpa PO - invoice tanpa dasar PO/receiving - user dapat mengubah dokumen approved tanpa kontrol # 5. Functional Specification — Sales Sales mengelola siklus order penjualan dari permintaan pelanggan sampai pengiriman dan penagihan. ## 5.1 Tujuan Fungsional - mencatat order penjualan - mengontrol harga dan diskon - mengontrol komitmen pengiriman - memicu reservation / fulfillment inventory - menjadi dasar invoice dan AR ## 5.2 Objek Bisnis Inti - Sales Quotation (opsional) - Sales Order - Sales Order Line - Delivery Order / Shipment - Sales Invoice Reference - Return / Credit Reference - Discount Approval Reference ## 5.3 Fitur Sales Order ### Fungsi - create SO - edit draft SO - submit SO - confirm SO - approve diskon/override tertentu - cancel SO - view fulfillment status - view invoice status ### Data Utama SO - so_no - customer - company - business_unit / branch / sales_org - order_date - requested_delivery_date - payment term - price list reference - currency - status ### Data SO Line - item - quantity - UOM - price - discount - tax - warehouse source / fulfillment rule reference ### Status SO - DRAFT - SUBMITTED - CONFIRMED - PARTIALLY_DELIVERED - FULLY_DELIVERED - INVOICED - CLOSED - CANCELLED ### Validasi SO - customer aktif - item aktif - quantity valid - price valid - discount sesuai rule atau butuh approval - context user valid - confirm hanya jika data lengkap dan policy terpenuhi ### Workflow SO 1. sales create SO 2. isi line, harga, diskon 3. simpan draft 4. submit / confirm 5. jika ada diskon/override tertentu, approval mungkin dibutuhkan 6. setelah confirmed, Inventory dapat membuat reservation 7. pengiriman dilakukan 8. invoice dibuat 9. AR diproses 10. order closed jika selesai ## 5.4 Fitur Delivery / Shipment ### Fungsi - create delivery dari SO confirmed - allocate stock - issue goods - confirm delivery - view delivery history ### Status Delivery - DRAFT - READY_TO_PICK - PICKED - SHIPPED - DELIVERED - CANCELLED ### Validasi - source SO valid dan belum terpenuhi penuh - stok tersedia / allocation valid - issue tidak boleh melebihi quantity yang sah ## 5.5 Pricing and Discount Control Sistem sebaiknya mendukung: - harga default dari price list - diskon dalam batas role tertentu - override di atas batas memerlukan approval - histori perubahan harga/diskon pada order ## 5.6 Side Effect Penting Sales - SO confirmed memicu reservation - delivery memicu stock issue - invoice memicu AR - retur memicu stock/finance effect sesuai rule ## 5.7 Risiko Implementasi - order dikonfirmasi tanpa kontrol stok / harga - diskon liar - invoice tidak sinkron dengan delivery - stok negatif karena reservation tidak disiplin # 6. Functional Specification — Inventory Inventory adalah penjaga realitas stok. Modul ini harus disiplin karena kesalahan stok akan memengaruhi pembelian, penjualan, costing, dan keuangan. ## 6.1 Tujuan Fungsional - mencatat pergerakan stok - menghitung saldo stok yang dipercaya - mendukung reservation, receiving, issue, transfer, adjustment - menyediakan visibilitas stok untuk modul lain ## 6.2 Objek Bisnis Inti - Warehouse - Stock Balance - Stock Movement - Goods Receipt - Goods Issue - Transfer Order - Stock Adjustment - Stock Reservation - Batch/Lot/Serial (opsional) ## 6.3 Prinsip Penting Inventory - jangan mengubah saldo stok langsung tanpa movement - movement adalah sumber kebenaran - receiving dan issue harus punya dasar bisnis yang sah - adjustment harus sangat terkendali ## 6.4 Goods Receipt ### Fungsi - create receipt from PO - receive quantity - confirm receipt - cancel/reverse receipt sesuai policy - view receipt history ### Status - DRAFT - POSTED - CANCELLED / REVERSED ### Validasi - source PO valid dan issued - vendor/item valid - warehouse valid - quantity tidak melebihi toleransi - user punya otorisasi context warehouse/company ### Side Effect - menambah stock movement masuk - menambah stock balance - memperbarui status receiving PO ## 6.5 Goods Issue ### Fungsi - create issue from delivery / internal request - confirm issue - reverse sesuai policy ### Validasi - stok tersedia - source document valid - warehouse valid - quantity sah ### Side Effect - stock movement keluar - pengurangan available stock - update fulfillment delivery/order ## 6.6 Transfer Order ### Fungsi - create transfer antar warehouse - approve jika perlu - ship transfer - receive transfer - close transfer ### Status - DRAFT - APPROVED - IN_TRANSIT - RECEIVED - CLOSED - CANCELLED ### Catatan Transfer sebaiknya menghasilkan dua sisi movement: keluar dari asal, masuk ke tujuan. ## 6.7 Stock Adjustment ### Fungsi - create adjustment - reason code wajib - approve jika diperlukan - post adjustment ### Validasi - hanya role tertentu - alasan wajib - audit kuat - quantity dan arah adjustment jelas ### Risiko Adjustment sering disalahgunakan untuk menutupi proses yang buruk. Karena itu harus dibatasi ketat. ## 6.8 Reservation ### Fungsi - reserve stock untuk SO / proses lain - release reservation - consume reservation saat issue ### Validasi - reservation tidak melebihi available stock sesuai policy - cancellation order harus me-release reservation ## 6.9 Laporan / View Penting Inventory - stock on hand - available stock - reserved stock - stock movement history - aging atau snapshot tertentu jika perlu ## 6.10 Risiko Implementasi - stok dihitung dari angka statis tanpa movement - receiving dan issue tidak sinkron - reservation tidak dirawat - warehouse context diabaikan # 7. Functional Specification — Expense and Costing Modul ini menangani biaya operasional dan alokasi biaya. Pada beberapa perusahaan, modul ini bisa dibangun bertahap dimulai dari expense approval sederhana. ## 7.1 Tujuan Fungsional - mencatat pengajuan dan realisasi biaya operasional - mengontrol approval biaya - mengaitkan biaya dengan cost center/unit - menyediakan dasar posting ke finance - mendukung analisa biaya ## 7.2 Objek Bisnis Inti - Expense Request / Claim - Expense Line - Expense Category - Cost Center - Allocation Rule - Expense Approval Record - Petty Cash Entry (opsional) - Reimbursement Record (opsional) ## 7.3 Fitur Expense Request ### Fungsi - create expense request - edit draft - submit - approve/reject - cancel - post to finance candidate - attach supporting documents ### Data Utama - expense_no - requester - company - business_unit - expense_date - expense_category - amount - cost_center - notes - attachment ### Status - DRAFT - SUBMITTED - APPROVED - REJECTED - POSTED - CANCELLED ### Validasi - amount > 0 - category valid - cost center valid - attachment wajib untuk kategori tertentu - approval mengikuti rule ### Workflow 1. user buat expense 2. isi detail 3. submit 4. approval 5. jika approved, siap diposting / direalisasikan 6. finance atau modul terkait memproses posting ## 7.4 Allocation Jika biaya perlu dibagi: - sistem bisa menyimpan allocation line - total allocation harus sama dengan total biaya - rule allocation tertentu bisa didukung bertahap ## 7.5 Side Effect - approved expense dapat menjadi payable / journal candidate - posted expense memengaruhi finance - allocation memengaruhi reporting biaya ## 7.6 Risiko Implementasi - biaya dibebankan tanpa cost center - approval lemah - bukti biaya tidak tercatat - tidak ada hubungan ke posting finance # 8. Functional Specification — Finance Finance menerima hasil transaksi operasional dan mengelolanya menjadi pencatatan keuangan formal. ## 8.1 Tujuan Fungsional - mencatat dan memposting jurnal - mengelola payable dan receivable - mengelola cash/bank tertentu - mengelola posting/reversal - mengontrol period - menjadi sumber laporan keuangan formal ## 8.2 Objek Bisnis Inti - Journal Entry - Journal Line - Accounts Payable Document - Accounts Receivable Document - Payment - Receipt - Bank/Cash Account - Fiscal Period - Reconciliation Record ## 8.3 Journal Entry ### Fungsi - create draft journal - validate journal balance - submit/post journal - reverse journal - view journal history ### Status - DRAFT - READY_TO_POST - POSTED - REVERSED - CANCELLED (untuk draft) ### Validasi - total debit = total credit - period terbuka - account valid - context company valid - post hanya oleh role yang berwenang ### Catatan Journal manual sebaiknya dibatasi. Lebih baik banyak jurnal berasal dari modul operasional. ## 8.4 Accounts Payable ### Fungsi - create AP from vendor invoice / matched PO - validate payable - approve payable jika policy butuh - post payable - record payment - view outstanding AP ### Status - DRAFT - VALIDATED - POSTED - PARTIALLY_PAID - FULLY_PAID - CLOSED - CANCELLED ### Validasi - vendor valid - source document valid jika diwajibkan - amount cocok - payment tidak boleh melebihi outstanding ## 8.5 Accounts Receivable ### Fungsi - create AR from sales invoice - post AR - record receipt - view aging - allocate receipt ### Status - DRAFT - POSTED - PARTIALLY_PAID - FULLY_PAID - CLOSED ## 8.6 Payment and Receipt ### Fungsi - create payment - approve payment jika policy perlu - post payment - reverse payment - create receipt - post receipt - reconcile ### Validasi - bank/cash account valid - period terbuka - outstanding document valid - amount valid - payment/receipt method valid ## 8.7 Fiscal Period Control Sistem finance yang sehat harus punya konsep: - open period - close period - blocked period untuk posting baru Ini penting walaupun implementasi awal sederhana. ## 8.8 Side Effect Finance - posting jurnal memengaruhi ledger - payment menurunkan outstanding AP - receipt menurunkan outstanding AR - reversal harus tercatat, bukan edit langsung ## 8.9 Risiko Implementasi - finance jadi tempat input liar semua transaksi - period control tidak ada - posting dan edit bercampur - reversal tidak resmi # 9. Cross-Module Workflow Scenarios Bagian ini sangat penting karena sistem enterprise gagal bukan hanya karena modulnya salah, tetapi karena **hubungan antar modulnya tidak didefinisikan**. ## 9.1 Scenario A — Procure to Receive to Pay ### Ringkasan Kebutuhan pembelian berubah menjadi order, diterima, lalu menjadi kewajiban bayar. ### Alur 1. User membuat PR di Purchasing 2. PR disubmit dan diapprove 3. Buyer membuat PO dari PR 4. PO diapprove lalu diissue 5. Warehouse / receiving role melakukan goods receipt di Inventory 6. Vendor invoice direkam / dimatch 7. Finance membuat / memvalidasi AP 8. Finance memproses payment 9. AP ditutup jika lunas ### Titik Kontrol Penting - PR approval - PO approval - receiving against PO - invoice matching - payment approval ### Risiko jika tak didefinisikan - bayar tanpa receiving - receive tanpa PO - PO tanpa approval - AP tanpa source document sah ## 9.2 Scenario B — Order to Deliver to Cash ### Alur 1. Sales membuat SO 2. SO dikonfirmasi 3. Inventory reserve stock 4. Delivery dibuat dan goods issue dilakukan 5. Finance/AR membuat invoice 6. Receipt dicatat 7. AR ditutup ### Titik Kontrol - harga/diskon approval - stock availability - delivery validity - invoice source - receipt allocation ## 9.3 Scenario C — Expense to Post ### Alur 1. User membuat expense request 2. approval expense 3. finance memvalidasi 4. posting ke jurnal / payable sesuai desain 5. payment / reimbursement dilakukan ## 9.4 Scenario D — Master Data Change Impact ### Contoh 1. vendor dinonaktifkan 2. sistem harus mencegah vendor dipakai transaksi baru 3. transaksi lama tetap historis 4. laporan tetap bisa membaca histori Ini terlihat sederhana, tapi sangat penting untuk integritas data. # 10. State Transition Tables (Representative) Bagian ini memberi contoh pola transition. Implementasi rinci per objek dapat dikembangkan dari sini. ## 10.1 Purchase Request | Status Asal | Action | Status Tujuan | Catatan | |---|---|---|---| | DRAFT | update | DRAFT | hanya pembuat/role terkait | | DRAFT | submit | SUBMITTED | validasi lengkap | | SUBMITTED | start_review | UNDER_REVIEW | opsional jika workflow multi-step | | SUBMITTED | approve | APPROVED | bila single-step | | UNDER_REVIEW | approve | APPROVED | setelah review final | | SUBMITTED/UNDER_REVIEW | reject | REJECTED | alasan wajib | | DRAFT/SUBMITTED | cancel | CANCELLED | sebelum turunannya terkunci | | APPROVED | close | CLOSED | setelah terpenuhi / dihentikan secara sah | ## 10.2 Purchase Order | Status Asal | Action | Status Tujuan | Catatan | |---|---|---|---| | DRAFT | update | DRAFT | sebelum approval | | DRAFT | submit_approval | PENDING_APPROVAL | validasi lengkap | | PENDING_APPROVAL | approve | APPROVED | | | PENDING_APPROVAL | reject | DRAFT/REJECTED | tergantung kebijakan | | APPROVED | issue | ISSUED | resmi ke vendor | | ISSUED | receive_partial | PARTIALLY_RECEIVED | melalui receiving | | ISSUED/PARTIALLY_RECEIVED | receive_complete | FULLY_RECEIVED | | | FULLY_RECEIVED | close | CLOSED | | | DRAFT/APPROVED | cancel | CANCELLED | jika belum ada turunan terlarang | ## 10.3 Sales Order | Status Asal | Action | Status Tujuan | Catatan | |---|---|---|---| | DRAFT | update | DRAFT | | | DRAFT | submit | SUBMITTED | | | SUBMITTED | confirm | CONFIRMED | setelah validasi/approval | | CONFIRMED | deliver_partial | PARTIALLY_DELIVERED | | | CONFIRMED/PARTIALLY_DELIVERED | deliver_complete | FULLY_DELIVERED | | | FULLY_DELIVERED | invoice | INVOICED | | | INVOICED | close | CLOSED | setelah AR tertutup jika policy demikian | | DRAFT/SUBMITTED | cancel | CANCELLED | | ## 10.4 Expense Request | Status Asal | Action | Status Tujuan | Catatan | |---|---|---|---| | DRAFT | update | DRAFT | | | DRAFT | submit | SUBMITTED | | | SUBMITTED | approve | APPROVED | | | SUBMITTED | reject | REJECTED | | | APPROVED | post | POSTED | ke finance | | DRAFT/SUBMITTED | cancel | CANCELLED | | # 11. Non-Functional Considerations Derived from Workflow Walaupun Volume 2 fokus ke fungsi, beberapa kebutuhan non-fungsional langsung muncul dari workflow: ## 11.1 Auditability Setiap approval, reject, cancel, post, reverse harus tercatat. ## 11.2 Idempotency Aksi seperti submit, approve, post, issue, receipt perlu tahan terhadap double-click / retry agar tidak menciptakan side effect ganda. ## 11.3 Concurrency Control Transaksi stok, approval, posting keuangan memerlukan kontrol konkurensi yang cukup. ## 11.4 Performance List transaksi butuh filter yang baik; timeline dan history sebaiknya efisien. ## 11.5 Traceability Dokumen turunan harus bisa ditelusuri ke dokumen sumber: - PO ke PR - Receipt ke PO - AP ke invoice vendor / PO / receipt - Delivery ke SO - Invoice ke SO/delivery ## 11.6 Reporting Readiness Field context, status, referensi sumber, dan timestamp harus cukup untuk pelaporan operasional. # 12. Deliverable Teknis yang Diturunkan dari Volume 2 Setelah Volume 2 selesai, tim seharusnya bisa menurunkan beberapa artefak berikut: 1. daftar endpoint per objek dan action 2. matriks hak akses per workflow 3. ERD detail per modul 4. list service backend per action 5. test scenario per status transition 6. route/page map frontend 7. approval engine requirement lebih rinci Dengan kata lain, Volume 2 adalah jembatan antara blueprint arsitektur dan implementasi nyata. # 13. Kesimpulan Volume 2 Volume 2 menetapkan perilaku sistem di level proses. Ia menjelaskan: - fitur inti tiap modul - status transaksi utama - transisi yang sah - validasi penting - side effect - skenario lintas modul Dengan Volume 1 dan Volume 2 bersama-sama, tim sudah memiliki: - fondasi arsitektur - domain map - workflow core Ini cukup untuk mulai menurunkan: - access control matrix - ERD rinci - API contract - service layer backend - test scenario --- ## Langkah Lanjutan yang Direkomendasikan Sesudah Volume 2, dokumen yang paling penting adalah: ### Volume 3 — Access Control Matrix and Authorization Pack Isi utamanya: - role families final awal - authorization object catalogue - action catalogue - role × object × action × context matrix - SoD awal - policy enforcement notes - seed strategy Dokumen itu akan menjadi tulang punggung backend permission, frontend guard, dan test authorization.