# 🔒 DOKUMEN PROSEDUR WORKFLOW MODUL PEMBELIAN (PURCHASING)
> **STATUS DOKUMEN:** HAK CIPTA DILINDUNGI (SOFTWARE HOUSE PROPRIETARY)
> **PERINGATAN:** Dilarang keras mengubah, memodifikasi, atau mendistribusikan ulang isi dokumen prosedur ini tanpa izin tertulis dari pihak Software House pengembang sistem Everest. Segala bentuk modifikasi kode program atau alur sistem di luar otorisasi resmi dapat membatalkan garansi sistem.

---

## 1. Pendahuluan
Dokumen ini menjelaskan alur kerja (workflow) standar dari modul **Pembelian (Pembelian)** pada sistem ERP Everest. Alur kerja ini mencakup siklus hidup transaksi mulai dari pembuatan draf pemesanan hingga barang fisik secara resmi diterima di gudang dan masuk ke pencatatan akuntansi.

---

## 2. Alur Kerja Utama (Core Workflow - FG Purchasing / Code 466)

Modul pembelian produk jadi (Finished Goods) menggunakan kode transaksi internal **466**. Proses ini dibagi menjadi 4 langkah wajib:

| Langkah (Step) | Nama Proses | Status Sistem | Deskripsi Fungsional |
| :--- | :--- | :--- | :--- |
| **Step 1** | **PRE PURCHASE ORDER** | *Pending Approval* (Merah) | Staf Purchasing membuat draf usulan pembelian barang kepada supplier tertentu dengan menentukan gudang tujuan, kuantitas, dan estimasi harga. |
| **Step 2** | **PURCHASE ORDER** | *Purchased* (Oranye) | Manager Purchasing meninjau draf usulan. Jika disetujui, sistem menerbitkan PO resmi berseri yang mengunci kuantitas secara administratif (*Locker Stock Hold*). |
| **Step 3** | **PRE GOODS RECEIVED NOTE** | *GRN Made (Preparation)* | Tahap verifikasi saat barang kiriman supplier tiba di gudang. Petugas gudang mencocokkan fisik dengan PO serta menyiapkan data nomor seri (*serial number*) jika produk dilacak per unit. |
| **Step 4** | **GOODS RECEIVED NOTE (GRN)** | *GRN Made (Active)* (Hijau) | Petugas gudang melakukan konfirmasi terima barang secara penuh. Stok dimasukkan ke kartu stok aktif, kunci stok dilepas, dan jurnal akuntansi hutang & persediaan terbentuk secara otomatis. |

---

## 3. Matriks Peran Pengguna & Hak Akses (User Roles Matrix)

Sistem ini menerapkan prinsip pemisahan tugas (*Segregation of Duties*) untuk meminimalkan risiko kesalahan input dan tindakan kecurangan (fraud):

### A. Staf Purchasing (`c_purchasing`)
*   **Wewenang:** Membuat draf usulan pembelian (**Step 1: Pre-PO**) dan memilih vendor/supplier dari master data.
*   **Batasan:** Tidak dapat melakukan persetujuan (approval) atas PO yang diajukannya sendiri.

### B. Admin / Manager Purchasing (`c_purchasing_adm`)
*   **Wewenang:** Meninjau, mengedit detail item/harga jika diperlukan, serta menyetujui (**Step 2: Approval PO**) draf usulan menjadi dokumen PO resmi yang siap dikirim ke supplier.

### C. Petugas Gudang (`c_gudang`)
*   **Wewenang:** Memverifikasi kedatangan barang (**Step 3: Pre-GRN**), melakukan pencocokan fisik, memindai barcode/serial number unit barang, dan melakukan konfirmasi penerimaan barang (**Step 4: GRN**).
*   **Batasan:** Tidak memiliki hak akses untuk membuat PO baru atau melihat rincian harga beli jika kebijakan perusahaan membatasi informasi harga bagi staf operasional gudang.

### D. Divisi Keuangan & Akuntansi (`c_finance`)
*   **Wewenang:** Memvalidasi PPN Masukan dari hasil penerimaan barang, mencocokkan faktur tagihan supplier dengan data GRN, serta menjadwalkan pembayaran hutang dagang.

---

## 4. Mekanisme Keamanan Sistem & Database (Under-the-Hood)

Sistem Everest menggunakan teknologi hibrida untuk menjaga performa dan integritas data transaksi:

1. **Penyimpanan Draf Sementara (MongoDB):**
   * Selama transaksi masih dalam status draf pengajuan (Step 1), data disimpan di database MongoDB untuk menghindari beban kerja database utama MySQL/MariaDB.
2. **Pengunci Transaksi Ganda (Locker Transaksi):**
   * Untuk menghindari konflik pengeditan data oleh dua pengguna secara bersamaan, sistem menggunakan mekanisme *Hold Locker*. Pengguna lain akan diarahkan ke halaman **"Transaksi Terkunci"** jika mencoba mengakses transaksi yang sedang diproses.
3. **Pencatatan Akuntansi & Stok Otomatis:**
   * Begitu Step 4 (GRN) diselesaikan oleh petugas gudang, sistem MariaDB secara otomatis mengeksekusi:
     * Penambahan kuantitas pada tabel kartu stok aktif (`LockerStock` status `.active`).
     * Pembuatan entri Jurnal Akuntansi:
       * **[DEBIT]** Persediaan Barang Jadi (Finished Goods)
       * **[DEBIT]** PPN Masukan (jika ada)
       * **[KREDIT]** Hutang Dagang Supplier

---

## 5. Catatan Kritis Review Kepatuhan (Standar ISO & Best Practice)

Berdasarkan review kepatuhan terhadap standar **ISO 9001:2015 (Klausul 8.4 & 8.5)** serta praktik operasional terbaik (*best practice*), berikut adalah poin kritis terkait penanganan **Serial Number** saat penerimaan barang yang perlu dipahami oleh pembuat modul (Software House):

### 🚨 Isu Kepatuhan: Pembuatan Serial Number Baru Internal vs Registrasi Serial Number Supplier
Pada sistem mentah, terdapat opsi untuk membuat (*generate*) serial number baru internal di gudang penerima saat proses GRN. Pihak pembuat modul wajib memperhatikan batasan bisnis berikut:

1. **Kasus Barang Bergaransi Pabrik (Gadget, Mesin, Elektronik):**
   * **Aturan Kepatuhan:** Sistem **TIDAK BOLEH** memaksa pembuatan serial number baru internal dengan mengabaikan serial number asli dari supplier/pabrikan (*Manufacturer Serial Number*).
   * **Dampak Bisnis:** Jika serial number asli pabrik tidak dicatat, rantai garansi (*warranty chain*) akan terputus. Perusahaan tidak dapat melakukan klaim garansi (*RMA*) ke supplier jika barang rusak karena nomor seri tidak cocok.
   * **Rekomendasi Solusi:** Sistem harus menyediakan fitur input/registrasi serial number asli dari supplier (via scan barcode fisik kemasan produk) untuk dipetakan ke dalam sistem penerimaan barang.

2. **Kasus Barang Curah / Komponen Kustom (Tanpa Serial Number Asli):**
   * **Aturan Kepatuhan:** Membuat serial number internal baru saat GRN **DIPERBOLEHKAN** dan bahkan direkomendasikan untuk memenuhi standar ketelusuran (*Traceability* ISO 9001:2015).
   * **Rekomendasi Solusi:** Nomor seri internal yang dibuat sistem harus mengikuti pola penomoran yang rapi dan mencantumkan informasi tanggal penerimaan/nomor batch (untuk kebutuhan rotasi stok FIFO).

### 🚨 Isu Kepatuhan 2: Kasus Barang Cacat (Defect) & Kebuntuan Logika (*Deadlock*) Serial Number
Dalam operasional riil gudang, sering terjadi ketidaksesuaian jumlah fisik barang baik yang datang dibandingkan dengan dokumen PO. 
*   **Kasus:** Pengajuan PO sebanyak **50 unit**. Pada tahap Pre-GRN (Step 3), petugas gudang mendaftarkan **50 Serial Number** untuk keperluan pengecekan dan pelabelan. Namun, saat GRN (Step 4), terdeteksi **1 unit barang cacat**, sehingga gudang mengoreksi jumlah yang diterima menjadi **49 unit**.
*   **Masalah Sistem Mentah (*Deadlock*):** Sistem saat ini membiarkan data 1 nomor seri barang cacat tersebut menggantung di database dalam keadaan tidak tuntas. Hal ini mengakibatkan ketidakcocokan jumlah barang (49 unit) dengan total nomor seri terdaftar (50 nomor seri), yang kemudian **memblokir seluruh proses transaksi berikutnya** (seperti penjualan atau transfer stok) karena validasi sistem terhambat data serial yang menggantung (*dirty data*).
*   **Ketetapan Standar (ISO 9001:2015 - Klausul 8.7 Pengendalian Output Tidak Sesuai):**
    1.  **Pemisahan Alur (Workflow Splitting):** Sistem **harus mengizinkan** transaksi 49 unit yang berkondisi baik untuk diselesaikan (GRN *Release*) dan langsung lanjut ke proses penjualan/akuntansi tanpa terblokir.
    2.  **Opsi Penandaan Status Serial (SN Flagging):** Pada form GRN, petugas harus bisa menandai status per nomor seri (49 unit = *Diterima*, 1 unit = *Karantina/Cacat*).
    3.  **Karantina Otomatis & Pembersihan Data:** Nomor seri yang ditandai *Cacat* harus otomatis dikeluarkan dari data inventori aktif dan dipindahkan ke dokumen **Retur Pembelian (Purchase Return)** atau **Laporan Ketidaksesuaian (NCR)** yang merujuk ke nomor seri cacat tersebut agar tidak menjadi data sampah yang memblokir transaksi.

### 🚨 Isu Kepatuhan 3: Penanganan Barang Sisa (*Backorder*) yang Dinyatakan *Discontinue*
Sering terjadi skenario di mana 1 unit sisa (selisih barang cacat/kurang kirim) yang awalnya direncanakan untuk dikirim susulan oleh supplier, ternyata dinyatakan **discontinue** (tidak lagi diproduksi/disediakan oleh pabrikan).
*   **Ketetapan Standar (ISO 9001:2015 - Klausul 8.2.4 Perubahan Persyaratan Produk & Jasa):**
    1.  **Amandemen Dokumen PO (PO Amendment):** Sistem harus mendukung proses revisi dokumen PO asli secara hukum bisnis, mengubah jumlah total pesanan secara administratif dari 50 menjadi 49 unit.
    2.  **Penutupan Paksa Selisih (*Short-Close PO*):** Sistem wajib menyediakan tombol fungsi *Short-Close* pada level pembelian. Fitur ini secara paksa menyelesaikan sisa outstanding PO yang menggantung di sistem keuangan agar sisa dana anggaran (*budget commitment/locker value*) untuk 1 unit tersebut dilepaskan kembali ke kas perusahaan.
    3.  **Substitusi Produk (Jika Diperlukan):** Jika unit sisa tersebut tetap wajib dipenuhi, sistem harus mengizinkan penutupan PO lama pada angka 49 dan pembuatan PO Baru/Addendum PO untuk tipe suksesor (produk pengganti setara) dengan harga baru.

### 🚨 Isu Kepatuhan 4: Desain Antarmuka (UI) untuk Proses Amend PO
Untuk mengimplementasikan proses amandemen PO secara aman dan akuntabel, desain antarmuka pengeditan harus memenuhi kriteria kelayakan berikut:

*   **Rekomendasi Utama - Toggling "Mode Amend PO" pada Halaman Utama (Peringkat 1 - TERBAIK & PALING SESUAI):**
    *   **Kepatuhan ISO 9001 (Klausul 6.1 & 8.5.1):** Sangat Patuh. Desain ini menyajikan informasi PO secara menyeluruh (*full context* seperti vendor, tanggal kirim, syarat pembayaran, dan alur otorisasi) sebelum modifikasi dilakukan. Ini memenuhi klausul kendali mutu dan manajemen risiko secara maksimal sehingga menghindari kesalahan input akibat kehilangan konteks data.
    *   **Best Practice ERP:** Luar Biasa. Menggunakan pengeditan di layar utama (*single-screen edit/toggle*) yang menjaga fokus pengguna, mencegah konflik proses (karena tombol aksi lainnya seperti approval/reject disembunyikan selama mode edit aktif), serta meniadakan penumpukan jendela modal pop-up yang mengganggu kenyamanan kerja.
    *   **Efisiensi Sistem:** Sangat DRY (Clean Code). Programmer cukup menambahkan pengondisian logika pada halaman preview yang sudah ada, tanpa perlu membuat file view baru secara terpisah.

### 🛠️ Kesimpulan Tindak Lanjut untuk Software House:
Untuk memastikan modul ini lulus audit operasional klien:
* Sediakan **kolom pemetaan (mapping)** yang menghubungkan `Nomor Seri Internal` dengan `Nomor Seri Asli Supplier` (jika produk memiliki garansi pabrikan).
* Pastikan fitur pemindaian (*scanning*) pada aplikasi mobile scanner gudang mengarahkan input ke registrasi barcode serial number bawaan barang, bukan sekadar men-generate angka acak baru dari sistem.
* Implementasikan mekanisme **SN Flagging & Splitting** di mana serial number barang yang ditandai cacat/ditolak otomatis dipindahkan ke status karantina/retur dan tidak menghalangi kelanjutan transaksi unit yang baik.
* Sediakan fitur **"Short-Close PO"** dan **"PO Amendment"** untuk menangani pembatalan barang sisa yang tidak dapat dikirim lagi akibat discontinue oleh supplier tanpa menahan data keuangan di sistem.