# Dokumen Arsitektur ERP: Manajemen Inventaris Khusus Skala Enterprise
> **Kategori Sistem:** Multi-Company, Multi-Branch, High-Concurrency Web Application  
> **Target Skala Bisnis:** Omset Rp 1 Triliun | Ratusan Ribu Item *Sparepart* Kompleks  
> **Kepatuhan Standar:** ISO 9001:2015 (Mutu & Ketertelusuran) & ISO/IEC 27001 (Keamanan Informasi)

---

## 1. Tata Letak Fisik & Zonasi Gudang (Pendekatan ISO 9001 & 45001)
Untuk mengelola ratusan ribu item dari berbagai merek dan jenis tanpa *picking error*, area fisik toko/gudang wajib dibagi berdasarkan alur kerja proses bisnis (*Process-Based Approach*):

*   **Zona Penerimaan (Inbound Zone):** Area pembongkaran muatan, pemeriksaan kualitas fisik (*QC Gate*), dan pencocokan manifes.
*   **Zona Penyimpanan Utama (Storage Zone):** Dibagi menggunakan **Analisis ABC**:
    *   *Fast-Moving:* Berada di koridor terdekat dengan area pengiriman (akses cepat).
    *   *Medium-Moving:* Berada di baris tengah gudang.
    *   *Slow-Moving:* Berada di area paling belakang atau lantai atas (*Mezzanine*).
*   **Zona Karantina (Quarantine Zone):** Area terisolasi (diberi marka batas merah fisik) untuk menampung barang retur, rusak, atau salah kirim agar tidak bercampur dengan stok komersial.
*   **Zona Pengemasan & Pengiriman (Outbound Zone):** Tempat pengecekan akhir, *packing*, dan serah terima ke kurir/pelanggan.

---

## 2. Struktur Data Utama: Matriks Hubungan Produk (Many-to-Many)
Pencarian konvensional (seperti `SQL LIKE`) tidak valid untuk ratusan ribu item. Software wajib menerapkan **Matriks Hubungan Relasional (Relation Matrix)** untuk memisahkan data "Barang Fisik" dengan data "Kesesuaian Kendaraan".

### A. Klasifikasi Berlapis (Multi-Layer Taxonomy)
Data master barang tidak boleh linier, melainkan harus memiliki struktur hierarki:
*   `Layer 1 (Kategori Utama)` $\rightarrow$ Contoh: Mesin, Kaki-kaki, Elektrikal.
*   `Layer 2 (Sub-Kategori)` $\rightarrow$ Contoh: Sistem Pendingin, Sistem Bahan Bakar.
*   `Layer 3 (Jenis Komponen)` $\rightarrow$ Contoh: Radiator, Water Pump, Thermostat.
*   `Layer 4 (Atribut Spesifik)` $\rightarrow$ Contoh: Ukuran, Material, Berat, Dimensi.

### B. Hubungan Banyak-ke-Banyak (Many-to-Many Mapping)
Satu nomor komponen (*Part Number*) harus bisa dipetakan ke banyak tipe kendaraan (Kompatibilitas Silang / *Cross-Reference*):

┌──────────────────┐               ┌───────────────────────┐│  MATRIKS BARANG  │               │ DATA KENDARAAN (M-M)  ││                  │──────────────►│ 1. Avanza (2012-2019) ││  Kode: PAD-001   │──────────────►│ 2. Xenia (2015-2021)  ││  (Kampas Rem)    │──────────────►│ 3. Rush (2018-Sekarang)│└──────────────────┘               └───────────────────────┘

*   **Fitur Pencarian Pintar:** Menggunakan *Fuzzy Search* (toleransi salah ketik oleh operator) dan *Faceted Navigation* (filter multivariabel di bilah samping aplikasi web).

---

## 3. Standar Penyimpanan Transaksi ke Database (ACID Compliance)
Setiap transaksi penyimpanan data ke basis data wajib dibungkus dalam blok transaksi terpadu untuk menjamin prinsip **Atomicity** (Semua sukses atau batal sama sekali).

### A. Pola Struktur Tabel: Header-Detail (One-to-Many)
Data transaksi wajib dipecah menjadi dua tabel terpisah:
1.  **`transaction_header` (One):** Menyimpan data umum/kolektif seperti `id_transaksi` (Primary Key), `tanggal_waktu`, `id_operator`, dan `total_belanja`.
2.  **`transaction_detail` (Many):** Menyimpan baris detail item seperti `part_number`, `qty_beli`, `harga_satuan`, dan `diskon`.

### B. Otomatisasi Jurnal Keuangan ke COA (Many-to-One)
Operator tidak perlu memahami akuntansi. Namun saat tombol simpan di-klik, sistem di latar belakang wajib melakukan pemetaan (*mapping*) dari banyak item barang ke satu kode akun akunbilitas (**Chart of Accounts - COA**) melalui prinsip *Double Entry*:

```sql
BEGIN TRANSACTION;

-- 1. Catat Identitas Utama
INSERT INTO transaction_header (id, invoice_num, total) VALUES (10025, 'INV/2026/07/001', 250000);

-- 2. Catat Detail Barang (Sisi Operator)
INSERT INTO transaction_detail (header_id, part_number, qty) VALUES (10025, 'BRG-992', 1);

-- 3. Catat Jurnal Keuangan Otomatis (Sisi Manajemen ke COA - Many-to-One)
INSERT INTO accounting_journal (header_id, coa_id, debit, kredit) VALUES (10025, '1101', 250000, 0); -- Kas Toko
INSERT INTO accounting_journal (header_id, coa_id, debit, kredit) VALUES (10025, '4101', 0, 250000); -- Pendapatan

COMMIT;
```

---

## 4. Validasi Data & Kontrol Konkurensi (Mencegah Gagal Audit ISO)
Banyak developer gagal dalam audit ISO karena tidak mengantisipasi risiko tubrukan data (*Race Condition*) saat ribuan operator mengakses sistem bersamaan.

*   **Pemeriksaan/Polling Sebelum Menyimpan (Data Validation):** Aplikasi harus melakukan pengecekan berlapis dari sisi *Frontend* (format input) hingga sisi *Backend* (ketersediaan stok riil di database) sebelum perintah `INSERT` dijalankan.
*   **Concurrency Control (Locking):** Wajib menerapkan mekanisme penguncian data stok (seperti perintah `SELECT ... FOR UPDATE` pada SQL) ketika transaksi sedang berjalan. Hal ini mencegah dua kasir menjual 1 sisa barang terakhir di detik yang sama, yang dapat berakibat pada stok minus (Cacat Mutu Data).
*   **Aturan Perintah UPDATE & DELETE:** 
    *   Perintah `UPDATE` **hanya diperbolehkan** untuk mengubah status alur kerja dokumen (Contoh: status `PACKING` $\rightarrow$ `SHIPPED`).
    *   Perintah `UPDATE` dan `DELETE` **dilarang keras** digunakan pada nilai finansial, kuantitas, atau riwayat transaksi yang sudah sah. Semua koreksi wajib menggunakan `INSERT` baru bermuatan nilai minus (Jurnal Pembalik/Retur) demi menjaga integritas *Audit Trail*.

---

## 5. Standar Identitas Penyimpanan (Internal Keys)
Setiap baris data wajib memiliki dua pengenal independen untuk memisahkan kebutuhan performa mesin dengan kebutuhan bisnis:

1.  **Identitas Urutan Fisik (Technical Key / Surrogate Key):** Menggunakan tipe data angka murni berurutan seperti `BIGINT` dengan klausa `GENERATED ALWAYS AS IDENTITY` (Sesuai standar ANSI SQL modern). Angka ini mencatat urutan kronologis masuknya data ke harddisk secara internal, berperan penting untuk meningkatkan kecepatan indeksasi pencarian data massal, dan **tidak boleh diekspos ke publik** demi alasan keamanan (**ISO 27001**).
2.  **Identitas Bisnis (Business Key / Natural Key):** Nomor dokumen seperti `INV/2026/07/001` yang dibaca oleh operator, manajemen, dan pelanggan.

---

## 6. Filosofi Arsitektur Multi-Database (Skala Korporat 1 Triliun)
Pada arsitektur *Multi-Database*, masing-masing anak perusahaan memiliki basis data yang terisolasi secara fisik demi performa lokal yang maksimal. 

### Peran dan Tanggung Jawab Integrator (Sistem Makro):
Sebagai **Integrator**, Anda memegang derajat pemahaman filosofis tertinggi (*Systems Thinking*) di atas pembuat infrastruktur lokal. Tanggung jawab mutlak Anda meliputi:
*   **Pipa Data & Antrean (Data Pipeline):** Membangun jembatan asinkron menggunakan *Message Broker* (seperti Kafka atau RabbitMQ). Cabang harus tetap bisa bertransaksi secara luring (*offline*) saat internet pusat mati, dan data akan disinkronisasikan secara otomatis menggunakan antrean aman saat jaringan kembali pulih.
*   **Konsolidasi Global (Data Warehouse):** Menyusun kunci komposit (*Composite Key*) gabungan antara `ID_Perusahaan + ID_Increment_Lokal` di server pusat agar jutaan data transaksi cabang tidak saling bertabrakan saat digabungkan untuk keperluan laporan manajemen.
*   **Penyediaan Mesin Pivot Manajemen:** Merancang arsitektur agregasi data makro di hulu (*upstream*) agar pihak **Manajemen** atau **Data Analyst** di hilir dapat menggunakan fitur **Pivot Table** untuk melihat analisis perputaran stok (Analisis ABC), profitabilitas merek, dan laporan keuangan konsolidasi grup secara instan dan akurat.