ERPNext v16 - Framework (Versi BMP)

Dokumen studi baseline pada level perilaku aplikasi, dilengkapi keputusan scope BMP dan arsitektur keamanan Chinese Wall yang terintegrasi di seluruh chapter. Jangkar codebase (path/flag) disertakan untuk verifikasi di branch v16; yang rawan bergeser ditandai ⚠️.

Prinsip payung keamanan BMP: Meta BMP adalah refleksi kode di compile-time, bukan data di runtime. Kustomisasi runtime terbatas pada data (nilai field sidecar, label, transisi) - tidak pernah pada schema. Dan yang terpenting: setiap user hanya melihat dan menyentuh data yang menjadi kewenangannya - Chinese Wall dijaga di level permission, workspace, dan field.

Chapter 0 - Register Keputusan

Chapter 1 - Build: Mesin No-Code

Mesin apa: domain yang membuat aplikasi bisa mengubah dirinya sendiri tanpa developer. Semua yang lain di Framework (dan di ERPNext) adalah konsumen dari meta-sistem yang dibangun di sini. Di BMP, mesin ini juga menjadi alat penegak Chinese Wall - lewat permlevel di Customize Form, field sensitif disembunyikan dari role yang tidak berwenang.

Perilaku per doctype:

  1. DocType (frappe/core/doctype/doctype/) - record yang mendefinisikan record lain. Perilaku: buat DocType di UI (developer mode) → tabel MariaDB tercipta; tambah field → form, list, print, import, export otomatis mengenali field baru tanpa restart. Flag JSON pengubah perilaku: issingle (settings key-value), is_submittable (docstatus), is_tree (nested set lft/rgt), autoname/naming_series. Catatan BMP: tidak membuat meta runtime; meta = refleksi compile-time Ash; schema hanya lewat migrasi.
  2. Page - halaman server-defined yang bukan doctype (controller Python + JS sendiri), terdaftar sebagai record supaya bisa dicari & di-menu. Contoh: "Permission Manager" dan "User Permission" adalah Page.
  3. Report - record dengan tipe: Report Builder (user menyusun kolom/filter tanpa kode), Query, Script (Python execute(filters)). Perilaku: semua report bisa di-export xlsx/csv, filter bisa disimpan, report script bisa dijadwalkan lewat Auto Email Report (Ch. 4).
  4. Workspace - halaman sidebar sebagai record (JSON di repo di-import saat migrate). Perilaku v14+: user bisa "Edit Workspace" - menambah/menghapus shortcut, mengubah urutan, membuat workspace privat. Catatan BMP: navigasi handcrafted; padanannya saved views, bukan workspace yang diedit user. Role restriction wajib: setiap Workspace di-set role-nya - IT hanya melihat workspace Settings/Users/Integrations/Build; workspace bisnis (Accounting, Stock, Manufacturing, Selling) di-hide dari IT.
  5. Dashboard / Dashboard Chart / Number Card - definisi visual sebagai record; widget di Home & Workspace membacanya; user bisa edit chart tanpa deploy.
  6. Module Def - registry namespace: mengelompokkan doctype/report/page ke modul; menentukan label modul di pencarian dan batas kepemilikan saat export/import fixtures ⚠️.
  7. Customization (frappe/custom/doctype/) - payung untuk menambah field/section ke doctype inti tanpa menyentuh repo; hasil akhirnya selalu record di tiga persistensi di bawah.
  8. Customize Form - doctype transien (meja kerja): memuat cermin meta doctype ke grid editable; perubahan tidak disimpan di dirinya, melainkan ditulis menjadi record Custom Field / Property Setter. Editor vs persistensi terpisah. Peran krusial di BMP: Customize Form adalah senjata utama Chinese Wall. Melalui field permlevel (Permission Level 0-9) di Customize Form, field sensitif di doctype tertentu disembunyikan dari role yang tidak berwenang. Contoh: field rate, amount di BOM Item di-set ke permlevel 1, sehingga hanya role dengan level 1 (Owner/R&D/Finance) yang bisa melihatnya. Role IT (System Manager) hanya punya permlevel 0 - mereka melihat struktur BOM tapi tidak melihat angka.
  9. Custom Field - field tambahan sebagai record; menambah kolom nyata di tabel DB. Muncul serentak di form, list, print, template import, export, report; bertahan upgrade; bisa di-disable tanpa menghapus data. Catatan BMP: versi sidecar JSON, tanpa DDL runtime.
  10. Property Setter - override sifat field/doctype inti (label, hidden, mandatory, default, options) sebagai record; berlaku seketika untuk semua user. Urutan keberlakuan meta: JSON repo < Property Setter < Custom Field. Catatan BMP: override label via lapisan terjemahan per instalasi.
  11. Workflow - state machine sebagai record: states, transitions (state → aksi → state berikut, role yang boleh), field penyimpan state (default workflow_state). Perilaku: tombol aksi hanya untuk transisi yang diizinkan role user; perpindahan tercatat di timeline; state bisa membawa doc_status (mencapai state tertentu bisa auto-submit ⚠️); transisi yang menunggu menciptakan Workflow Action = daftar kerja role tujuan (cikal bakal pola "My Attention"). Server Script & Client Script: DITOLAK - lihat Bab 0.

Lintas domain: meta Build dibaca semua: Printing (field yang bisa dicetak), Data Import (kolom template), Users (permission per doctype), Email (field untuk template Jinja). Customize Form (permlevel) dibaca oleh Users (Role Permission Manager) untuk menegakkan Chinese Wall.

Edge case:

  1. Custom Field + Property Setter = sumber drift antar instalasi.
  2. Property Setter yang men-set field wajib → dokumen lama gagal di-edit sampai terisi.
  3. Hapus Custom Field berisi data = kolom yatim di tabel.
  4. Mengubah permlevel tanpa koordinasi = field sensitif tiba-tiba terlihat oleh role yang salah, atau sebaliknya, Owner kehilangan akses ke field kritis. Perubahan permlevel wajib melalui approval Owner.

Chapter 2 - Users: Identitas & Akses

Mesin apa: siapa boleh masuk, boleh apa, dan jejaknya. Ini adalah chapter paling kritis untuk keamanan BMP - di sinilah Chinese Wall ditegakkan: pemisahan tegas antara apa yang boleh dilihat/diubah oleh IT, Operator Produksi, Admin Sales, Finance, dan Owner.

Perilaku per doctype:

  1. Home - penentu halaman awal per user/role saat login ⚠️.
  2. User - satu record per akun (email = username). Disable → session aktif invalid; riwayat transaksi lama tetap menampilkan namanya; roles sebagai child table; API key untuk akses tanpa browser; password policy & session timeout dipinjam dari System Settings. Aturan BMP: user IT internal bukan role Administrator bawaan Frappe. IT hanya mendapat role System Manager dengan batasan ketat. Penugasan role bisnis (Accounts Manager, Manufacturing Manager, dll) adalah hak prerogatif Owner/HR - IT boleh membuat draft User, tapi tidak boleh klik "Assign Role" untuk modul bisnis.
  3. Role - record kemampuan; pemisah desk (akses UI) vs non-desk (portal/API) ⚠️. Assign role = efek seketika tanpa logout; workspace & menu berubah sesuai role. Role Matrix BMP (Chinese Wall):

  1. Permissions - tiga lapis yang dirasakan user:

4.a. User Permission - aturan sebagai data (frappe/core/doctype/user_permission/): user X boleh (allow=Company/Warehouse/Item) hanya nilai Y; flag apply_to_all_document_types atau daftar doctype. Semua query disaring diam-diam (list, report, dashboard); lapis baris di atas lapis doctype. Perilaku halus: opsi link field ikut tersaring - dropdown Warehouse hanya menampilkan yang diizinkan, sebelum user sempat memilih. Operasi internal bisa men-set ignore_user_permissions ⚠️ - "default tersaring, pengecualian dikendalikan kode".

4.b. Permission Manager - editor tanpa kode (page ⚠️): melihat/mengubah DocPerm per doctype per role, termasuk if_owner dan permission level. Perubahan disimpan sebagai Custom DocPerm (frappe/custom/doctype/custom_docperm/) - analog Custom Field untuk permission; bisa di-reset ke default. Permission level = field-level: field permlevel > 0 (diskon, harga pokok, rate BOM) hanya terlihat oleh role berlevel itu. Efek seketika untuk user online. Implementasi Chinese Wall via permlevel:

4.c. Permission Inspector - debugger ⚠️ (tambahan v16): menjawab "kenapa user ini bisa/tidak melihat dokumen ini?" - menampilkan evaluasi role × user permission × if_owner. Keberadaannya pengakuan bahwa model permission memang kompleks - pola sama seperti Recorder untuk SQL. Catatan BMP: Permission Inspector sendiri harus di-restrict - hanya Owner dan IT yang boleh membukanya, dan IT hanya boleh melihat hasil evaluasi untuk doctype non-sensitif (bukan BOM atau Invoice).

  1. Audits - Access Log (siapa melihat/mengekspor/mencetak dokumen apa, dengan filter mentahnya - admin bisa mereproduksi persis apa yang diambil user); Activity Log (feed komunikasi/kejadian, bukan diff nilai - diff nilai hidup di Version ⚠️); Permission Log (perubahan aturan akses ikut diaudit - "sistem meng-audit dirinya sendiri"). Batasan IT: IT boleh melihat Access Log dan Activity Log untuk keperluan troubleshooting sistem (misal: "kenapa user X tidak bisa submit SO?"). Tapi IT tidak boleh melihat isi dokumen yang diakses - hanya metadata (siapa, kapan, doctype apa, filter apa). Isi dokumen (angka, rate, nama customer) hanya terlihat oleh Owner/Finance.

Lintas domain: Users gerbang semua domain; setiap aksi dicek ke sini dulu; User Permission memfilter query list/report otomatis. Chinese Wall menjalar ke semua modul: Stock (valuation rate hidden dari IT), Manufacturing (BOM rate hidden), Accounting (GL detail hidden), Selling (customer PII tidak ada di BMP).

Edge case:

  1. Permission dicabut saat user membuka form → masih bisa submit sampai reload.
  2. User Permission tumpang tindih → union/intersection tergantung flag "Apply To All" - kebingungan klasik admin.
  3. IT membuat user baru lalu assign role System Manager + Accounts Manager = Chinese Wall jebol. Mitigasi: hanya role Administrator (Owner) yang boleh assign role bisnis. IT membuat draft, Owner yang approve.
  4. IT mengubah permlevel di Customize Form tanpa approval = field sensitif terbuka. Mitigasi: perubahan Customize Form untuk doctype sensitif (BOM, Item Price, Invoice) wajib approval Owner sebelum berlaku.

Chapter 3 - System: Jantung Latar & Kesehatan

Mesin apa: ERP punya dua jantung (request/response user + background). Domain ini jantung kedua plus panel kesehatannya. Di BMP, ini adalah wilayah kekuasaan utama IT - mereka boleh melihat semua log sistem, tapi tidak boleh melihat isi data bisnis.

Perilaku per doctype:

  1. Health Report - diagnostik: ukuran DB, latensi antrean, utilisasi worker ⚠️.
  2. Notifications - dua wajah: Notification (aturan: pada event X kirim alert/email ke Y dengan template) dan Notification Log (kotak masuk in-app = ikon lonceng). Aturan menembak → log tercipta → toast realtime via websocket tanpa refresh.
  3. Notification Settings - per user: saklar jenis notifikasi yang mau diterima + status seen; user memfilter kebisingannya sendiri tanpa menyentuh aturan global.
  4. Background Job (= RQ Job) (frappe/core/doctype/rq_job ⚠️) - snapshot job antrean: status queued/running/failed, argumen, durasi; bisa retry/requeue job gagal. Semua hal async (webhook, flush email, import besar) muncul di sini. RQ Worker - worker hidup (pid, utilisasi): melihat kapasitas; antrean menumpuk + worker sedikit = gejala terlihat. Catatan BMP: IT wajib memantau ini untuk memastikan Repost Item Valuation, Auto-Reorder Material Request, dan Stock Closing berjalan lancar di malam hari. Tapi argumen job (yang mungkin berisi item code atau warehouse) tidak boleh mengandung data finansial.
  5. Scheduled Job Type - katalog job cron (metode + frekuensi + enabled); admin bisa mematikan satu job tanpa mematikan scheduler - saklar halus.
  6. Scheduled Job Log - riwayat eksekusi per job + detail error; menjawab "kenapa reorder tidak jalan semalam".
  7. Scheduler Event - registry pemetaan tick scheduler (all/hourly/daily) ke daftar metode, termasuk event custom ⚠️.
  8. Tools - aksi pemeliharaan admin (clear cache, rebuild) ⚠️. System Console DITOLAK - lihat Bab 0.
  9. Recorder - profiler request bawaan: merekam setiap request beserta semua query SQL yang ORM generate + durasi + call stack per query; bisa EXPLAIN ⚠️. Off by default; hasil disimpan di cache (bukan DB) agar tidak mengotori yang diukur; akses System Manager. Antidot untuk "SQL tak terlihat" yang lahir dari ORM. Catatan BMP: Recorder hanya boleh diakses IT untuk debugging performa. Query SQL yang terekam mungkin mengandung nama tabel/field, tapi tidak boleh di-expose ke user non-IT.
  10. Logs - Error Log (exception + traceback, termasuk kegagalan background yang tak terlihat user; toast bisa "sukses" padahal side-effect gagal); API Requested Log (rekaman request/response REST bila diaktifkan; bisa bengkak - retensi lewat Log Settings); View Log (siapa membuka dokumen apa, kapan; isi "Recently Viewed"); Patch Log (ledger migrasi: patch mana sudah jalan; menjamin tiap patch tepat satu kali). Batasan Chinese Wall di Logs:
  11. Log Settings - retensi per jenis log ("Error Log dibersihkan setelah N hari"); scheduler membuang log kedaluwarsa - satu-satunya purge otomatis Framework, sengaja hanya untuk log, bukan data bisnis.

Lintas domain: semua domain menulis ke Logs; scheduler di sini menggerakkan Automation (Ch. 4), flush Email (Ch. 5), backup (Ch. 6).

Edge case:

  1. Matikan scheduler → job manual hidup, semua otomatisasi mati tanpa notifikasi.
  2. Error Log membesar tak terkendali bila Log Settings tidak diset.
  3. IT menggunakan Error Log untuk mengintip data bisnis (misal: error message mengandung BOM rate). Mitigasi: error message untuk doctype sensitif harus di-sanitize - hanya menampilkan doctype dan docname, bukan isi field.

Chapter 4 - Automation: Aturan yang Jalan Sendiri

Mesin apa: mengubah "kalau terjadi X, lakukan Y" dari kebiasaan manusia menjadi record yang dieksekusi mesin.

Perilaku per doctype:

  1. Assignment Rule (frappe/automation/doctype/assignment_rule/) - per doctype: kondisi assign, strategi (Round Robin / Load Balancing / Based on Field), kondisi unassign. Dokumen baru → melekat ke user tertentu; muncul di daftar kerjanya; ditutup → lepas. Dua aturan se-doctype bisa konflik - ada prioritas ⚠️.
  2. Auto Repeat - dokumen berulang: dari satu Sales Invoice langganan, scheduler membuat draft baru tiap bulan dengan referensi induk. Field next_schedule_date, status Active/Disabled/Completed, opsi notify by email; hasil selalu draft - submit tetap keputusan manusia (kecuali dikonfigurasi).
  3. Milestone (+ Tracker) - menandai momen field mencapai nilai tertentu; masuk timeline dan bisa jadi sumbu report.
  4. Auto Email Report - report terjadwal dikirim email dengan lampiran xlsx/pdf; menggabungkan mesin Report (Ch. 1) + Email Queue (Ch. 5) + scheduler (Ch. 3). Catatan BMP: Auto Email Report untuk laporan sensitif (Financial Reports, BOM cost) hanya boleh dijadwalkan oleh Owner/Finance. IT boleh menjadwalkan report teknis (Error Log summary, Background Job status).
  5. Reminder - pengingat per-user pada waktu tertentu; muncul sebagai notification ⚠️.

Lintas domain: Automation mendengar event dokumen (doc_events), menembak ke Users (assignment), Email (auto report), scheduler System.

Edge case:

  1. Auto Repeat dengan induk di-cancel → perlu aturan berhenti; kalau tidak, draft terus tercipta.
  2. Assignment Rule terlalu luas = semua dokumen "milik semua orang" atau tak seorang pun.

Chapter 5 - Output: Email & Printing

Mesin apa: cara sistem berbicara keluar - lewat layar kertas (PDF) dan kotak masuk. Scope BMP: email transaksional/pengiriman dokumen, bukan mailbox umum/marketing (Bab 0). Chinese Wall berlaku di sini: Print Format untuk dokumen sensitif tidak boleh diedit oleh IT.

Perilaku per doctype:

  1. Email Account - konfigurasi SMTP/IMAP per akun; flag default outgoing/incoming. Save → test koneksi otomatis; incoming di-pull scheduler; "Append To" membuat email masuk nyangkut di timeline dokumen yang cocok.
  2. Communication - record setiap email/komentar yang melekat ke dokumen (dynamic link). Timeline dokumen = Communication + Comment + Version.
  3. Email Domain - setting server per domain yang dipakai ulang banyak akun.
  4. Email Queue - email tidak pernah dikirim sinkron: semua masuk antrean, di-flush worker/scheduler. Status Sent/Error terlihat; gagal → retry; "Send Now" memaksa. Ini kenapa email "terlambat beberapa detik" normal, dan tetap jalan walau penerima down.
  5. Email Template - balasan/beritahuan berisi placeholder Jinja yang diisi data dokumen saat dikirim. Catatan BMP: Email Template untuk dokumen sensitif (Invoice, BOM) tidak boleh mengandung field rate/amount. Template hanya boleh merujuk field non-sensitif (nomor dokumen, tanggal, nama item).
  6. Unhandled Email - email masuk yang gagal dicocokkan ke dokumen; diparkir untuk review admin, bukan dibuang.
  7. Print Format - layout per doctype (Jinja/builder); flag default; custom format menambah pilihan, tidak mengganti bawaan. Chinese Wall di Print Format:
  8. Print Heading - letterhead (logo + judul) sebagai record.
  9. Print Format Builder - editor drag-drop yang menyimpan JSON layout untuk renderer.
  10. Print Settings (single) - ukuran halaman PDF, letterhead on/off, bahasa print; mengubah ini mengubah semua PDF.

Lintas domain: setiap dokumen transaksi melewati Printing saat render dan Email saat notifikasi; keduanya bergabung di "kirim invoice dengan PDF terlampir".

Edge case:

  1. Email Account incoming mati diam-diam (password expired) → Unhandled Email menumpuk & inbox kosong; user tahunya lama.
  2. Print Format custom merujuk Custom Field yang dihapus → PDF error saat dicetak.
  3. IT memodifikasi Print Format BOM untuk memunculkan field rate yang disembunyikan. Mitigasi: Print Format untuk doctype sensitif di-restrict; perubahan wajib approval Owner.

Chapter 6 - Data & Integrations: Keluar-Masuk Sistem

Mesin apa: pintu-pintu resmi untuk memindahkan data secara massal dan menghubungkan sistem ke dunia luar. Chinese Wall berlaku ketat di sini: IT boleh import master data teknis, tapi tidak boleh import/export data finansial atau resep.

Perilaku per doctype:

  1. Data Import - wizard dengan template xlsx dari meta (Ch. 1). Perilaku kunci: setiap baris menjalani jalur save() yang sama dengan input manual - validasi & hook berjalan, import tak bisa menyelundupkan data yang UI tolak; error per baris di Import Log tanpa membatalkan baris lain. Chinese Wall di Data Import:
  2. Data Export - export list terfilter ke xlsx/csv; setiap export tercatat di Access Log (Ch. 2). Chinese Wall di Data Export: sama dengan Data Import. IT boleh export master teknis; tidak boleh export BOM, Invoice, GL. Setiap export tercatat di Access Log - Owner bisa mengaudit siapa export apa.
  3. Bulk Update - set satu field ke nilai sama untuk banyak record terfilter ⚠️ (apakah hook penuh berjalan tergantung versi - verifikasi v16; menentukan apakah "seaman" edit manual). Catatan BMP: Bulk Update untuk field sensitif (rate, amount, valuation_rate) harus di-restrict. IT tidak boleh bulk update field ini.
  4. Backups - backup site + file oleh scheduler/manual; jumlah dibatasi backup_limit (System Settings); tujuan eksternal sesuai konfigurasi integrasi (BMP: lokal/S3). Catatan BMP: Backup mengandung seluruh database termasuk data sensitif. Akses ke file backup hanya untuk Owner dan Vendor Implementor (NDA). IT boleh menjalankan backup scheduler, tapi tidak boleh mengunduh file backup.
  5. Deleted Document - trash, bukan lobang: dokumen hapus diparkir sebagai snapshot JSON, bisa di-restore, di-purge setelah retensi ⚠️. "Hapus" di ERPNext hampir selalu berarti "sembunyikan + simpan jejak".
  6. Connected App - integrasi OAuth2 server-ke-server (scopes, token refresh) sebagai record.
  7. Webhook - per doctype + event (on submit dll.): HTTP POST async ke URL luar dengan signature HMAC; ditembak lewat background job (Ch. 3) sehingga kegagalan endpoint luar tidak memblokir transaksi; retry terbatas. Catatan BMP: Webhook untuk doctype sensitif (BOM, Invoice) hanya boleh dikonfigurasi oleh Owner. IT boleh konfigurasi webhook untuk doctype operasional (Stock Entry, Delivery Note).
  8. Authentication - payung cara masuk (melengkapi Ch. 2 yang menentukan hak): LDAP/OIDC & OAuth. Social login consumer DITOLAK - lihat Bab 0.
  9. LDAP Settings - login terhadap Active Directory/LDAP kantor; password diverifikasi di LDAP; user bisa auto-provisioned dengan role terpetakan dari group LDAP.
  10. OAuth Client - ERPNext sebagai provider: aplikasi pihak ketiga minta token dengan scope; layar konsent user; token terbit dengan scope & expiry.
  11. OAuth Provider - kebijakan provider (expiry, skip authorization untuk client terpercaya) ⚠️.

Lintas domain: Data Import/Export konsumen terbesar meta Build; Webhook cara Framework "berbicara" ke sistem luar tanpa polling.

Edge case:

  1. Import 10.000 baris = 10.000 transaksi dengan hook penuh → lambat by design (keamanan > kecepatan).
  2. Webhook ke endpoint lambat menumpuk di Background Job bila tidak dipantau.
  3. IT menggunakan Data Import untuk mengimpor BOM dengan rate yang sudah dimodifikasi. Mitigasi: Data Import untuk BOM/Invoice hanya untuk role Owner/Finance; import oleh IT ditolak sistem.
  4. IT menggunakan Data Export untuk mengunduh seluruh Item Price list. Mitigasi: export untuk doctype sensitif di-restrict; setiap export tercatat di Access Log.

Chapter 7 - Arsitektur Keamanan: Role IT & Chinese Wall

Mesin apa: chapter ini adalah konsolidasi seluruh aturan keamanan BMP yang sudah tersebar di Chapter 1-6. Ini adalah satu-satunya tempat di mana filosofi, matriks, implementasi, dan edge case keamanan dikumpulkan dalam satu pandangan utuh.

7.1 Filosofi Dasar

Di BMP, staf IT / System Admin diposisikan sebagai "Tukang Kunci & Tukang Listrik", bukan "Manajer Pabrik". IT boleh tahu cara kerja sistem, boleh memperbaiki error, dan boleh menambah user. Tapi IT tidak boleh tahu:

Pemisahan ini disebut Chinese Wall - dinding tak terlihat yang memisahkan "yang boleh tahu cara sistem bekerja" dari "yang boleh tahu apa yang sistem hitung".

7.2 Matriks Hak Akses (Role Matrix)

7.3 Implementasi Teknis di ERPNext (Frappe)

Untuk menegakkan Chinese Wall di atas, konfigurasi berikut wajib dilakukan saat setup awal:

  1. Workspace Restrictions: Sidebar / Workspace menu untuk Accounting, Stock, Manufacturing, Selling di-hide atau di-restrict hanya untuk role bisnis (Accounts Manager, Stock Manager, dll). IT hanya melihat workspace Settings, Users, Integrations, Build.
  2. Field-Level Security (via Customize Form / permlevel):
  3. Data Import/Export Restriction: IT boleh melakukan Data Import untuk master data teknis. Tapi akses impor/ekspor untuk transaksi finansial (Journal Entry, Sales Invoice, BOM, Item Price) dibatasi hanya untuk role Finance/Owner. Implementasi: Role Permission Manager per doctype, atau custom validation di Data Import hook.
  4. Print Format Restriction: Hak akses Print Format untuk dokumen sensitif (BOM, Invoice) di-restrict. IT hanya boleh mengedit Print Format untuk dokumen operasional (Delivery Note, Stock Entry).
  5. Role Assignment SOP: Di ERPNext, hanya role Administrator (Superuser) yang bisa memberikan role sensitif tertentu. Pastikan user IT bukan Administrator bawaan. SOP-nya: IT membuat draft User, tapi hanya Owner / HR yang bisa klik Assign Role untuk modul bisnis (Accounting/Manufacturing/Sales).

7.4 Observability (Alat Kerja IT)

IT memiliki dashboard khusus untuk menjaga kesehatan sistem (tanpa menyentuh data bisnis):

  1. Error Log: Untuk mendebug script atau integrasi API marketplace yang gagal.
  2. Background Jobs & Scheduler: Memastikan Repost Item Valuation, Auto-Reorder Material Request, dan Stock Closing berjalan lancar di malam hari.
  3. Audit Logs (System Level): Melihat siapa yang login, kapan, dan dari IP mana (untuk keamanan akun), tapi tidak bisa melihat isi dokumen yang mereka buka.
  4. Recorder & Health Report: Untuk profiling performa dan diagnostik kapasitas.

7.5 Edge Case & Mitigasi (Celah Keamanan)

  1. Celah: IT membuat user baru, lalu memberi user tersebut role System Manager + Accounts Manager untuk mem-bypass Chinese Wall. Mitigasi: Di ERPNext, hanya role Administrator (Superuser) yang bisa memberikan role sensitif tertentu. Pastikan user IT bukan Administrator bawaan. SOP-nya: IT membuat draft User, tapi hanya Owner / HR yang bisa klik Assign Role untuk modul bisnis (Accounting/Manufacturing).
  2. Celah: IT mengakses database langsung via SQL / Frappe Console (Backend). Mitigasi: Ini adalah batas teknis UI ERPNext. Akses ke server backend (SSH / MariaDB console / Bench console) HANYA dipegang oleh Owner atau Vendor Implementor yang terikat NDA (Non-Disclosure Agreement) ketat. IT internal pabrik hanya diberi akses UI (Front-end browser).
  3. Celah: IT menggunakan fitur "Print Format" untuk memodifikasi template cetak BOM dan memunculkan field rate yang disembunyikan. Mitigasi: Hak akses Print Format untuk dokumen sensitif (BOM, Invoice) di-restrict. IT hanya boleh mengedit Print Format untuk dokumen operasional (Delivery Note, Stock Entry).
  4. Celah: IT menggunakan Data Export untuk mengunduh seluruh Item Price atau BOM list ke Excel. Mitigasi: Data Export untuk doctype sensitif di-restrict via Role Permission Manager. Setiap export tercatat di Access Log - Owner bisa mengaudit siapa export apa kapan.
  5. Celah: IT mengubah permlevel di Customize Form untuk membuka field yang tadinya tersembunyi. Mitigasi: Perubahan Customize Form untuk doctype sensitif (BOM, Item Price, Invoice) wajib approval Owner sebelum berlaku. Tanpa approval, perubahan tidak bisa di-save.
  6. Celah: IT menggunakan Bulk Update untuk mengubah field valuation_rate di banyak Item sekaligus. Mitigasi: Bulk Update untuk field sensitif (rate, amount, valuation_rate) di-restrict. Hanya Owner/Finance yang boleh bulk update field ini.

7.6 Kesimpulan Keamanan

Dengan arsitektur ini, BMP mencapai keseimbangan yang tepat:

Chinese Wall bukan tentang ketidakpercayaan - ini tentang pemisahan tanggung jawab yang sehat. IT ahli di sistem; Owner ahli di bisnis. Keduanya bekerja di domain masing-masing tanpa saling menginjak.