# STANDAR KUALITAS MODUL PENJUALAN ERP
## Berbasis ISO/IEC 25010 + Segregation of Duties (SoD) + Proteksi Risiko Operasional

---

## 📌 Ruang Lingkup Dokumen

Dokumen ini menetapkan **standar kualitas minimal yang WAJIB dipenuhi** oleh Modul Penjualan dalam aplikasi ERP. Standar ini mencakup:

| No | Area | Isu yang Dicakup |
|----|------|------------------|
| 1 | **Proteksi Harga & Diskon** | Over diskon, salah harga, diskon tidak sesuai wewenang |
| 2 | **Proteksi Limit Kredit** | Penjualan melebihi plafon kredit pelanggan |
| 3 | **Proteksi Stok & Alokasi** | Rebutan stok antar salesman, negative stock |
| 4 | **Proteksi Pengiriman** | Over kirim (quantity melebihi pesanan) |
| 5 | **Proteksi Tagihan** | Over billing (nilai melebihi pesanan) |
| 6 | **Skema Jual Tanpa Stok** | Dropship, Pre-order (SO dulu, baru PO) |
| 7 | **Segregation of Duties (SoD)** | Pemisahan tugas untuk mencegah fraud |
| 8 | **Kepatuhan Regulasi** | Audit trail, retensi data, perlindungan data pribadi |

---

## DAFTAR ISI

1. Functional Suitability (Kesesuaian Fungsional)
2. Reliability (Keandalan)
3. Performance Efficiency (Efisiensi Kinerja)
4. Usability (Kemudahan Penggunaan)
5. Security (Keamanan)
6. Compatibility (Kompatibilitas)
7. Maintainability (Kemudahan Pemeliharaan)
8. Portability (Portabilitas)
9. Quality in Use (Kualitas Saat Digunakan)
10. **Segregation of Duties (SoD) - Pemisahan Tugas**
11. **Compliance & Audit Readiness - Kepatuhan Regulasi**
12. **Proteksi Harga & Diskon (Price & Discount Control)**
13. **Proteksi Limit Kredit Pelanggan (Credit Limit Control)**
14. **Proteksi Stok & Alokasi (Inventory & Stock Allocation)**
15. **Proteksi Pengiriman & Tagihan (Delivery & Billing Control)**
16. **Skema Jual Tanpa Stok (Dropship & Pre-order)**

---

## 1. FUNCTIONAL SUITABILITY (Kesesuaian Fungsional)

| ID | Sub-Karakteristik | Standar Wajib | Metode Verifikasi |
|----|-------------------|---------------|-------------------|
| FS-01 | **Functional Completeness** | Modul penjualan WAJIB memiliki fungsi: input transaksi, cetak struk/invoice, retur penjualan & nota kredit, laporan penjualan (harian/bulanan/tahunan), tutup kasir (shift closing) | Review dokumen & demo fungsional |
| FS-02 | **Functional Correctness** | Seluruh perhitungan (total belanja, diskon bertingkat, pajak, kembalian) WAJIB akurat 100%. Toleransi error = 0% | Uji 50 skenario transaksi berbeda |
| FS-03 | **Functional Appropriateness** | Fitur yang disediakan WAJIB sesuai dengan jenis bisnis (retail vs grosir vs restoran). Tidak boleh ada fitur yang mengganggu atau tidak relevan | User review & walkthrough |

---

## 2. RELIABILITY (Keandalan)

| ID | Sub-Karakteristik | Standar Wajib | Metode Verifikasi |
|----|-------------------|---------------|-------------------|
| RL-01 | **Maturity** | Crash rate < 1 per 1000 transaksi. Tidak ada memory leak setelah 8 jam operasi terus-menerus | Load testing & soak test |
| RL-02 | **Availability** | Uptime minimal 99.5% selama jam operasional toko (toleransi hanya untuk maintenance terjadwal) | Monitoring tools |
| RL-03 | **Fault Tolerance** | WAJIB memiliki mode offline: transaksi tetap berjalan saat internet putus, sinkronisasi otomatis saat online kembali, data tidak boleh duplikat atau hilang | Simulasi putus koneksi 30 menit |
| RL-04 | **Recoverability** | Jika sistem crash di tengah transaksi, data transaksi WAJIB tersimpan dan bisa dilanjutkan. Waktu recover < 2 menit | Simulasi force close |

---

## 3. PERFORMANCE EFFICIENCY (Efisiensi Kinerja)

| ID | Sub-Karakteristik | Standar Wajib | Metode Verifikasi |
|----|-------------------|---------------|-------------------|
| PE-01 | **Time behavior** | Scan barcode → tampil data produk: < 2 detik. Simpan transaksi → struk terbit: < 1 detik. Buka laporan bulanan (1.000+ transaksi): < 5 detik | Stopwatch di device terendah |
| PE-02 | **Resource utilization** | RAM: maksimal 512 MB (aplikasi mobile) / 256 MB (web). Storage cache: < 500 MB | Task manager / Profiler |
| PE-03 | **Capacity** | Mampu memproses minimal 100 transaksi per menit per kasir. Mampu menampung 500.000+ histori transaksi tanpa penurunan kinerja | Load testing (JMeter/K6) |

---

## 4. USABILITY (Kemudahan Penggunaan)

| ID | Sub-Karakteristik | Standar Wajib | Metode Verifikasi |
|----|-------------------|---------------|-------------------|
| US-01 | **Learnability** | Kasir baru tanpa pelatihan formal WAJIB bisa melakukan transaksi lengkap dalam waktu kurang dari 10 menit (dengan panduan minimal) | User test 3 kasir baru |
| US-02 | **Operability** | Tombol minimal ukuran 48x48 px untuk sentuhan. Warna tombol: Hijau untuk aksi positif (Bayar), Merah untuk batal/hapus. Tersedia keyboard shortcut (F1=bantuan, F2=scan, F3=cetak) | Inspeksi UI |
| US-03 | **User error protection** | Sistem WAJIB menolak: diskon di luar batas wewenang, pembayaran kurang dari total belanja, void transaksi tanpa alasan (wajib isi textbox) | Uji coba input yang salah |
| US-04 | **Accessibility** | Mode kontras tinggi untuk lansia WAJIB tersedia (khusus untuk tender pemerintah) | Checklist WCAG 2.1 level A |

---

## 5. SECURITY (Keamanan)

| ID | Sub-Karakteristik | Standar Wajib | Metode Verifikasi |
|----|-------------------|---------------|-------------------|
| SC-01 | **Integrity** | Invoice yang sudah berstatus APPROVED tidak bisa diubah. Setiap perubahan data (void/refund/edit) WAJIB tercatat di Audit Trail (siapa, kapan, nilai lama, nilai baru) | SQL injection test & review |
| SC-02 | **Non-repudiation** | Setiap transaksi WAJIB memiliki nomor unik + timestamp yang di-hash (digital signature). Kasir tidak bisa menghapus log transaksi | Audit log review |
| SC-03 | **Accountability** | Setiap aksi Void/Refund/Edit harga WAJIB memerlukan login ulang atau otorisasi supervisor (scan sidik jari/approval digital) | Uji coba bypass |
| SC-04 | **Authenticity** | Login WAJIB menggunakan password (minimal 6 karakter alfanumerik) atau biometrik. Shift berakhir → auto logout | Uji penetrasi sederhana |
| SC-05 | **Confidentiality** | Data pelanggan (alamat, nomor HP, riwayat belanja) hanya bisa diakses sesuai role: kasir hanya melihat nama & nota, supervisor dapat melihat semua data | RBAC test |

---

## 6. COMPATIBILITY (Kompatibilitas)

| ID | Sub-Karakteristik | Standar Wajib | Metode Verifikasi |
|----|-------------------|---------------|-------------------|
| CP-01 | **Interoperability** | WAJIB terintegrasi dengan: Modul Stok (auto reduce stok saat penjualan), Modul Akuntansi (posting jurnal penjualan), Modul Pelanggan (update piutang). Setiap transaksi sukses → panggil API modul terkait dalam waktu < 1 detik | Integration testing end-to-end |

---

## 7. MAINTAINABILITY (Kemudahan Pemeliharaan)

| ID | Sub-Karakteristik | Standar Wajib | Metode Verifikasi |
|----|-------------------|---------------|-------------------|
| MT-01 | **Modularity** | Fitur retur, laporan, dan payment WAJIB merupakan modul terpisah. Satu modul error tidak boleh membuat modul lain ikut crash | Code review & separation test |
| MT-02 | **Analyzability** | Setiap error (exception) WAJIB tercatat di log file yang berisi: file, baris kode, timestamp, dan stack trace lengkap. Log tidak boleh hanya berisi "Error occurred" | Inject error, baca log |
| MT-03 | **Modifiability** | Menambah metode pembayaran baru (contoh: QRIS, crypto) WAJIB dapat dilakukan dengan hanya menambah 1 class/function, tanpa mengubah keseluruhan kode | Effort estimation review |

---

## 8. PORTABILITY (Portabilitas)

| ID | Sub-Karakteristik | Standar Wajib | Metode Verifikasi |
|----|-------------------|---------------|-------------------|
| PT-01 | **Installability** | Waktu instalasi < 3 menit (aplikasi mobile) atau cukup membuka browser (versi web). Petunjuk instalasi WAJIB disediakan secara jelas (step by step) | Uji instalasi di 3 perangkat berbeda |
| PT-02 | **Adaptability** | Tampilan WAJIB responsif di: PC (1024x768), tablet (800x1280), dan HP (360x640). Semua tombol tetap terlihat dan bisa diklik di semua ukuran layar | Uji lintas device |

---

## 9. QUALITY IN USE (Kualitas Saat Digunakan)

| ID | Karakteristik | Standar Wajib | Metode Verifikasi |
|----|---------------|---------------|-------------------|
| QU-01 | **Effectiveness** | Minimal 98% transaksi berhasil tanpa perlu pembatalan atau pengulangan dari awal | Observasi 10 shift kasir |
| QU-02 | **Efficiency** | Rata-rata waktu proses per transaksi (dari scan hingga struk keluar) ≤ 60 detik | Stopwatch real transaction |
| QU-03 | **Satisfaction** | Hasil survey kepuasan kasir minimal skor 4.0 dari 5.0 (mencakup kemudahan, kecepatan, dan tingkat stress) | Kuesioner setelah 1 bulan operasi |
| QU-04 | **Freedom from risk** | Sistem WAJIB menolak: penjualan stok kosong (negative stock), diskon yang membuat harga di bawah HPP, penghapusan transaksi tanpa otorisasi | Uji skenario berisiko |
| QU-05 | **Context coverage** | Sistem WAJIB bekerja di skenario: toko ramai (antrean panjang), offline (internet putus), retur barang tanpa struk (manual lookup transaksi) | Uji skenario lengkap |

---

## 10. SEGREGATION OF DUTIES (PEMISAHAN TUGAS)

> *Mencegah satu orang melakukan terlalu banyak fungsi yang berisiko terjadinya fraud atau error*

| ID | Aturan SoD | Standar Wajib | Metode Verifikasi |
|----|------------|---------------|-------------------|
| SoD-01 | **Pembuatan & Approval Sales Order** | User yang membuat Sales Order (SO) TIDAK BOLEH memiliki akses untuk menyetujui SO yang sama. Minimal harus ada 2 role terpisah | RBAC test: coba assign kedua akses ke 1 user → sistem harus tolak |
| SoD-02 | **Pembuatan & Pengiriman Barang** | User yang membuat SO TIDAK BOLEH memiliki akses untuk membuat Delivery Order (DO) untuk SO yang sama | Uji coba akses silang |
| SoD-03 | **Pembuatan & Pencatatan Pembayaran** | User yang membuat invoice TIDAK BOLEH memiliki akses untuk mencatat penerimaan pembayaran (cash receipt) | Uji coba akses silang |
| SoD-04 | **Pembuatan & Void/Refund** | User yang membuat transaksi TIDAK BOLEH melakukan void atau refund atas transaksi yang dibuatnya sendiri. Void/Refund hanya boleh dilakukan oleh Supervisor/Manager | Uji coba kasir void transaksi sendiri |
| SoD-05 | **Input Harga & Approval Diskon** | User yang menginput harga jual normal TIDAK BOLEH memberikan diskon di atas batas wewenangnya tanpa approval | Uji coba akses silang |
| SoD-06 | **Pembuatan Pelanggan & Pemberian Limit Kredit** | User yang membuat master data pelanggan baru TIDAK BOLEH menyetujui limit kredit pelanggan tersebut | Uji coba akses silang |
| SoD-07 | **Pembuatan & Posting Jurnal** | User yang membuat transaksi penjualan TIDAK BOLEH memposting jurnal penjualan ke buku besar (general ledger) | Uji coba akses silang |
| SoD-08 | **Akses Laporan & Transaksi** | User operasional (kasir) hanya boleh melihat data transaksinya sendiri. User dengan akses laporan agregat tidak boleh mengedit transaksi | RBAC test |
| SoD-09 | **User Provisioning & Approval** | User yang membuat user baru TIDAK BOLEH menyetujui akses user tersebut. Wajib ada minimal 2 orang (4 mata prinsip) | Uji alur approval user |
| SoD-10 | **Akses Konfigurasi Sistem** | User dengan akses konfigurasi sistem (ubah diskon global, ubah tax rate) HARUS dipisah dari user operasional. Setiap perubahan konfigurasi wajib tercatat di audit trail | Uji akses & audit log |

---

## 11. COMPLIANCE & AUDIT READINESS (KEPATUHAN REGULASI)

| ID | Aturan Compliance | Standar Wajib | Regulasi Terkait |
|----|-------------------|---------------|------------------|
| CMP-01 | **Audit Trail** | Semua log audit (login, transaksi, void, edit, delete) WAJIB disimpan minimal 5 tahun dan TIDAK BISA DIHAPUS (bahkan oleh admin database sekalipun) | SOX, ISO 27001, PDP Law |
| CMP-02 | **Timestamp** | Semua entri log dan transaksi WAJIB memiliki timestamp dari server (bukan dari perangkat client). Timezone konsisten (UTC+7 atau UTC). Sinkronisasi NTP WAJIB diaktifkan | SOX, PCI-DSS |
| CMP-03 | **Retensi Data** | Data transaksi penjualan WAJIB disimpan minimal 5 tahun (atau sesuai peraturan pajak setempat). Data pelanggan WAJIB mengikuti periode retensi yang diatur GDPR/PDP | UU KUP, GDPR, PDP Law |
| CMP-04 | **Pemisahan Environment** | Data production TIDAK BOLEH digunakan di environment development atau testing. Jika terpaksa, data WAJIB di-anonymize / masking | SOX, ISO 27001 |
| CMP-05 | **Change Management** | Setiap perubahan kode (deployment) ke production WAJIB tercatat: siapa, kapan, apa yang diubah, nomor ticket. Approval perubahan WAJIB dari minimal 2 orang | SOX, ISO 27001 |
| CMP-06 | **Backup & Recovery** | Backup otomatis WAJIB setiap hari. RPO (Recovery Point Objective) ≤ 24 jam. RTO (Recovery Time Objective) ≤ 4 jam. Uji recovery WAJIB dilakukan minimal setiap 3 bulan | ISO 27001, PDP Law |
| CMP-07 | **Enkripsi Data** | Data sensitif (password, token, data pribadi) WAJIB dienkripsi di database (at rest). Semua komunikasi client-server WAJIB menggunakan TLS 1.2 atau lebih tinggi | PDP Law, PCI-DSS |
| CMP-08 | **Password Policy** | Password WAJIB: panjang minimal 8 karakter, mengandung huruf besar, huruf kecil, angka, dan simbol. Masa berlaku maksimal 90 hari. Mencegah pengulangan 5 password terakhir. Lockout setelah 5 percobaan gagal (10 menit) | ISO 27001, SOX |
| CMP-09 | **Multi-Factor Authentication** | MFA WAJIB untuk: Administrator/Superadmin, akses ke database langsung, akses dari luar jaringan kantor (remote access) | SOX, ISO 27001 |
| CMP-10 | **E-Faktur (Pajak)** | Modul penjualan WAJIB menghasilkan data yang kompatibel dengan format e-Faktur (bagi PKP). Faktur pajak digital WAJIB memiliki format yang valid dan tidak bisa dipalsukan | UU PPN |
| CMP-11 | **Perlindungan Data Pribadi** | Modul penjualan WAJIB memiliki mekanisme: consent pelanggan untuk penyimpanan data, hak hapus data (right to be forgotten), pemberitahuan kebocoran data maksimal 72 jam | UU PDP No.27/2022 |
| CMP-12 | **Anti-Fraud Detection** | Sistem WAJIB mendeteksi dan mengirim alert untuk: void/refund di luar jam operasional wajar, transaksi berulang nilai kecil dalam waktu singkat, akses oleh user yang sama dari IP/perangkat berbeda | Fraud Management Framework |
| CMP-13 | **Third-Party Integration** | Semua integrasi dengan pihak ketiga (payment gateway, marketplace) WAJIB menggunakan API yang terautentikasi. Data yang dikirim dan diterima WAJIB di-log untuk keperluan audit | ISO 27001 |
| CMP-14 | **Incident Response** | Sistem WAJIB memiliki prosedur: deteksi insiden keamanan, eskalasi otomatis ke tim security, pencatatan insiden di log khusus | PDP Law, ISO 27001 |
| CMP-15 | **Penetration Testing** | Minimal setiap 6 bulan atau setelah perubahan besar, sistem WAJIB diuji penetrasi oleh pihak independen | ISO 27001, PCI-DSS |

---

## 12. PROTEKSI HARGA & DISKON (PRICE & DISCOUNT CONTROL)

> *Mencegah over diskon, salah harga, dan kebocoran margin yang merugikan perusahaan*

| ID | Aturan | Standar Wajib | Metode Verifikasi |
|----|--------|---------------|-------------------|
| PRC-01 | **Batas Diskon per Role** | Setiap role pengguna (kasir, supervisor, manager) WAJIB memiliki batas maksimum diskon yang dapat diberikan. Contoh: kasir maksimal 5%, supervisor maksimal 15% | Cek konfigurasi role |
| PRC-02 | **Batas Diskon per Produk** | Produk tertentu (misalnya: best seller, produk margin tipis, produk promo) WAJIB dapat memiliki batas diskon khusus yang berbeda dari default role | Cek konfigurasi produk |
| PRC-03 | **Approval Diskon Berlebih** | Jika diskon yang diberikan melebihi batas wewenang role, sistem WAJIB memicu alur persetujuan (approval workflow) sebelum transaksi dapat disimpan | Uji skenario diskon di atas batas |
| PRC-04 | **Peringatan Margin Minimum** | Sistem WAJIB menampilkan peringatan jika margin kotor (harga jual dikurangi HPP) berada di bawah batas minimum yang ditentukan perusahaan | Uji skenario harga tipis |
| PRC-05 | **Larangan Stacking Diskon Ganda** | Sistem WAJIB memiliki aturan yang jelas tentang kombinasi diskon (misalnya: diskon member + diskon promo tidak boleh double). Perhitungan diskon bertingkat WAJIB benar (tidak sekadar dijumlah) | Uji skenario diskon ganda |
| PRC-06 | **Harga Jual Minimum (Price Floor)** | Harga jual setelah diskon TIDAK BOLEH berada di bawah Harga Pokok Penjualan (HPP) ditambah mark-up minimum yang ditentukan | Uji skenario jual rugi |
| PRC-07 | **Harga Jual Maksimum (Price Ceiling)** | Harga jual TIDAK BOLEH melebihi Harga Eceran Tertinggi (HET) yang ditetapkan untuk produk tertentu (jika ada) | Cek validasi harga |
| PRC-08 | **Harga Khusus Pelanggan** | Jika pelanggan memiliki kontrak harga khusus, sistem WAJIB mengutamakan harga tersebut dan melarang input harga manual oleh kasir | Uji skenario pelanggan dengan kontrak |

---

## 13. PROTEKSI LIMIT KREDIT PELANGGAN (CREDIT LIMIT CONTROL)

> *Mencegah penjualan melebihi plafon kredit yang diberikan ke pelanggan*

| ID | Aturan | Standar Wajib | Metode Verifikasi |
|----|--------|---------------|-------------------|
| CL-01 | **Validasi Plafon Kredit** | Sistem WAJIB memeriksa total piutang berjalan pelanggan + nilai transaksi baru. Jika melebihi plafon kredit, sistem WAJIB menolak transaksi | Uji skenario pelanggan melebihi limit |
| CL-02 | **Blokir Pelanggan Bermasalah** | Pelanggan dengan status "Ditangguhkan" (karena tunggakan >90 hari) WAJIB diblokir sistem untuk semua transaksi penjualan baru | Uji skenario pelanggan ditangguhkan |
| CL-03 | **Peringatan Batas Kredit** | Sistem WAJIB mengirimkan notifikasi (email/dashboard) saat saldo piutang pelanggan mencapai 80% dari plafon kreditnya | Uji skenario mendekati limit |
| CL-04 | **Maksimum Jatuh Tempo** | Tanggal jatuh tempo pembayaran pada faktur penjualan WAJIB memiliki batas maksimum (default: 30 hari untuk grosir, 0 hari untuk ritel tunai) | Cek konfigurasi jatuh tempo |
| CL-05 | **Uang Muka untuk Pesanan Khusus** | Penjualan barang yang diproduksi khusus (make-to-order) WAJIB dikenakan uang muka minimal 50% sebelum Sales Order diproses | Uji skenario MTO |
| CL-06 | **Blokir Piutang Lewat Jatuh Tempo** | Sistem WAJIB melarang penjualan kredit kepada pelanggan yang masih memiliki faktur belum dibayar melebihi 60 hari dari tanggal jatuh tempo | Uji skenario pelanggan macet |

---

## 14. PROTEKSI STOK & ALOKASI (INVENTORY & STOCK ALLOCATION)

> *Mencegah rebutan stok antar salesman, negative stock, dan memastikan pengiriman hanya jika stok tersedia*

| ID | Aturan | Standar Wajib | Metode Verifikasi |
|----|--------|---------------|-------------------|
| INV-01 | **Larangan Negative Stock** | Sistem WAJIB menolak Sales Order jika quantity yang dipesan melebihi stok tersedia (available stock) di gudang, KECUALI mode pre-order atau dropship sedang aktif | Uji skenario order melebihi stok |
| INV-02 | **Pengecekan Stok Real-time** | Setiap pembuatan Sales Order WAJIB melakukan pengecekan stok secara real-time (bukan menggunakan cache) untuk mencegah kesalahan data | Uji 2 user bersamaan order produk sama |
| INV-03 | **Alokasi Stok Sementara (Soft Lock)** | Saat Sales Order dibuat, stok WAJIB dialokasikan sementara (soft lock/reserve) untuk mencegah salesman lain mengambil stok yang sama. Alokasi ini WAJIB memiliki masa berlaku (expiry) | Uji 2 salesman order produk sama bersamaan |
| INV-04 | **Pelepasan Alokasi Kadaluarsa** | Jika Sales Order tidak dikonfirmasi atau dikirim dalam waktu tertentu (default: 2 jam), alokasi stok WAJIB dilepaskan secara otomatis oleh sistem | Uji simulasi SO hangus |
| INV-05 | **Prioritas Alokasi Stok** | Sistem WAJIB memiliki aturan prioritas alokasi stok (contoh: pelanggan premium/prioritas mendapat alokasi lebih dulu, atau FIFO berdasarkan waktu SO) | Uji skenario prioritas |
| INV-06 | **Pengiriman Hanya Jika Stok Fisik Tersedia** | Untuk penjualan reguler (bukan pre-order, bukan dropship), Delivery Order (pengiriman barang) WAJIB hanya dapat dibuat jika stok fisik (setelah dikurangi alokasi) mencukupi | Uji skenario kirim tanpa stok |
| INV-07 | **Satu Gudang per Delivery Order** | Satu nomor Delivery Order WAJIB hanya mengambil stok dari SATU gudang yang sama untuk efisiensi kontrol logistik | Uji coba DO multi-gudang |

---

## 15. PROTEKSI PENGIRIMAN & TAGIHAN (DELIVERY & BILLING CONTROL)

> *Mencegah over kirim (kelebihan quantity) dan over billing (kelebihan tagihan)*

| ID | Aturan | Standar Wajib | Metode Verifikasi |
|----|--------|---------------|-------------------|
| OPS-01 | **Toleransi Over Delivery** | Sistem WAJIB memiliki parameter toleransi over delivery (kelebihan kirim) dalam persen, default: 5%. Kelebihan kirim di luar toleransi WAJIB ditolak | Cek konfigurasi toleransi |
| OPS-02 | **Toleransi Under Delivery** | Sistem WAJIB memiliki parameter toleransi under delivery (kekurangan kirim) dalam persen, default: 10%. Kekurangan kirim di luar toleransi WAJIB memerlukan approval manajemen | Cek konfigurasi toleransi |
| OPS-03 | **Otorisasi Khusus Over Kirim** | Hanya user dengan role tertentu (misal: supervisor gudang, manajer) yang diizinkan melakukan over delivery di atas batas toleransi. Setiap over delivery WAJIB tercatat di audit trail | Uji skenario over kirim |
| OPS-04 | **Alasan Over/Under Kirim** | Jika terjadi kelebihan atau kekurangan kirim, sistem WAJIB memaksa user mengisi alasan (contoh: "kerusakan barang", "kelebihan produksi") sebelum dokumen dapat disimpan | Uji skenario pengiriman tidak sesuai |
| OPS-05 | **Toleransi Over Billing** | Sistem WAJIB memiliki parameter toleransi over billing (kelebihan tagihan) dalam persen, default: 0%. Kelebihan tagihan di luar toleransi WAJIB ditolak | Cek konfigurasi toleransi |
| OPS-06 | **Otorisasi Khusus Over Billing** | Hanya user dengan role tertentu (misal: finance manager) yang diizinkan membuat invoice melebihi nilai Sales Order. Setiap over billing WAJIB tercatat di audit trail | Uji skenario over billing |
| OPS-07 | **Konsistensi Harga Antar Dokumen** | Sistem WAJIB memiliki pengaturan apakah harga di Sales Order harus konsisten dengan harga di Delivery Order dan Invoice (default: konsisten wajib) | Uji skenario perubahan harga |

---

## 16. SKEMA JUAL TANPA STOK (DROPSHIP & PRE-ORDER)

> *Mengakomodasi bisnis model di mana perusahaan menjual barang yang belum dimiliki (SO dulu, baru PO ke vendor)*

| ID | Aturan | Standar Wajib | Metode Verifikasi |
|----|--------|---------------|-------------------|
| DPS-01 | **Mode Dropship** | Sistem WAJIB mendukung mode dropship: Sales Order dibuat tanpa mengurangi stok gudang. Sistem WAJIB secara otomatis membuat Purchase Order ke vendor yang ditunjuk. Barang dikirim langsung dari vendor ke customer | Uji skenario dropship |
| DPS-02 | **Mode Pre-order** | Sistem WAJIB mendukung mode pre-order: Sales Order diterima meskipun stok kosong. Stok TIDAK perlu tersedia saat pembuatan Sales Order (berbeda dengan penjualan reguler). Sistem WAJIB mencatat estimasi tanggal ketersediaan stok | Uji skenario pre-order |
| DPS-03 | **Validasi Pengiriman Dropship** | Untuk mode dropship, Delivery Order WAJIB hanya dapat dibuat setelah Purchase Order ke vendor dikonfirmasi dan vendor mengirimkan barang. Stok fisik perusahaan TIDAK berkurang karena barang tidak masuk gudang | Uji alur dropship lengkap |
| DPS-04 | **Validasi Pengiriman Pre-order** | Untuk mode pre-order, Delivery Order WAJIB hanya dapat dibuat ketika stok fisik sudah tersedia (setelah tanggal estimasi ketersediaan). Sistem WAJIB mengirim notifikasi ke customer saat stok tersedia | Uji alur pre-order lengkap |
| DPS-05 | **Dokumen Pendukung Wajib** | Setiap transaksi dropship WAJIB menyimpan referensi ke Purchase Order terkait. Setiap transaksi pre-order WAJIB menyimpan estimasi tanggal ketersediaan stok | Review struktur data |
| DPS-06 | **Akuntansi Khusus** | Sistem WAJIB memperlakukan pendapatan dan HPP pada transaksi dropship secara akurat: pendapatan dicatat dari penjualan ke customer, HPP dicatat dari pembelian dari vendor, stok tidak pernah masuk neraca sebagai persediaan | Uji coba posting jurnal |

---

## ✅ DAFTAR PERIKSA WAJIB SEBELUM RELEASE

> **Berlaku untuk setiap rilis. Jika SATU kriteria di bawah ini tidak terpenuhi, rilis DITOLAK.**

| No | Kriteria | Status (L/G) |
|----|----------|--------------|
| 1 | FS-01: Kelengkapan fungsi minimal (transaksi, struk, laporan, tutup kasir) | ☐ |
| 2 | FS-02: Perhitungan transaksi 100% akurat (uji minimal 50 skenario) | ☐ |
| 3 | RL-03: Mode offline berfungsi & sinkronisasi sempurna | ☐ |
| 4 | PE-01: Scan produk < 2 detik di device terendah | ☐ |
| 5 | US-01: Kasir baru bisa transaksi dalam <10 menit | ☐ |
| 6 | US-03: Sistem menolak diskon di luar batas wewenang | ☐ |
| 7 | SC-01: Invoice approved tidak bisa diedit, audit trail lengkap | ☐ |
| 8 | SC-03: Void/Refund wajib otorisasi supervisor | ☐ |
| 9 | CP-01: Integrasi stok dan akuntansi berjalan real-time | ☐ |
| 10 | **PRC-01: Batas diskon maksimum per role** | ☐ |
| 11 | **PRC-06: Harga jual tidak boleh di bawah HPP + mark-up** | ☐ |
| 12 | **CL-01: Limit kredit pelanggan divalidasi sebelum transaksi** | ☐ |
| 13 | **INV-01: Sistem menolak negative stock (kecuali mode pre-order/dropship)** | ☐ |
| 14 | **INV-03: Soft lock / alokasi stok untuk mencegah rebutan** | ☐ |
| 15 | **OPS-01: Parameter toleransi over delivery terkonfigurasi** | ☐ |
| 16 | **OPS-05: Parameter toleransi over billing terkonfigurasi** | ☐ |
| 17 | **DPS-01: Mode dropship terimplementasi** | ☐ |
| 18 | **DPS-02: Mode pre-order terimplementasi** | ☐ |
| 19 | **SoD-01: Pembuat SO dan approval SO adalah role berbeda** | ☐ |
| 20 | **CMP-01: Audit trail tidak bisa dihapus** | ☐ |

---

## 🚫 LARANGAN TEKNIS (DILARANG KERAS)

| ID | Larangan | Alasan | Konsekuensi |
|----|----------|--------|-------------|
| L-01 | Hard delete data transaksi (perintah DELETE FROM sales) | Audit trail hilang, tidak bisa melacak fraud | GAGAL REVIEW |
| L-02 | Menyimpan password dalam bentuk plain text di database | Kerentanan keamanan tingkat kritis | GAGAL REVIEW |
| L-03 | Mengizinkan negative stock (stok minus) tanpa flag khusus | Potensi menjual barang yang tidak ada | GAGAL REVIEW |
| L-04 | Menggunakan tipe data float untuk uang (harga, diskon, pajak) | Floating point error menyebabkan selisih hitung | GAGAL REVIEW |
| L-05 | Aplikasi crash atau force close saat input yang salah | Buruknya user experience | WAJIB FIX |
| L-06 | Memberikan akses create SO dan approve SO ke 1 user yang sama | SoD violation, berisiko fraud | GAGAL REVIEW |
| L-07 | Mengizinkan over billing (tagihan melebihi SO) tanpa approval | Potensi kerugian finansial | GAGAL REVIEW |
| L-08 | Mengizinkan pengiriman tanpa stok fisik (untuk penjualan reguler) | Menjual barang yang tidak ada | GAGAL REVIEW |

---

## 📊 TARGET KPI SETELAH GO-LIVE

| Metrik | Target |
|--------|--------|
| CSAT (kepuasan) kasir | ≥ 4.2 / 5.0 |
| Rata-rata waktu transaksi | ≤ 60 detik |
| Void / Refund rate | ≤ 2% dari total transaksi |
| **Stock-out karena over-allocation** | **0 kejadian per bulan** |
| **Discount leakage (diskon di luar kebijakan)** | **≤ 1% dari total nilai diskon** |
| **SoD violation terdeteksi (false negative)** | **0 kejadian per bulan** |

---

## 17. KEPATUHAN MINIMUM SISTEM MANAJEMEN (LEAN COMPLIANCE BASELINE)
> *Pelengkap ISO/IEC 25010 agar siap audit minimum untuk organisasi dengan tim kecil.*

### 17.1 Prinsip Implementasi
- Fokus pada kontrol kritikal dengan effort rendah.
- Bukti (evidence) wajib tersedia dan mudah ditelusuri.
- Frekuensi review ringan: bulanan, triwulanan, semesteran.

### 17.2 Tabel Kontrol Minimum Wajib

| ID | Kontrol Minimum | Standar Acuan | PIC Minimum | Frekuensi | Evidence Minimum | Status |
|----|------------------|---------------|-------------|-----------|------------------|--------|
| LC-01 | Risk register keamanan informasi modul penjualan (top risk + mitigasi) | ISO/IEC 27001:2022 | IT Manager / SA | Triwulanan | Dokumen risk register + tanggal update | MANDATORY |
| LC-02 | Incident response SOP 1 halaman (deteksi, eskalasi, pemulihan) | ISO/IEC 27001:2022 | IT Manager | Semesteran | SOP + log insiden | MANDATORY |
| LC-03 | Shared responsibility matrix (cloud provider vs internal) | ISO/IEC 27017 | Infra/DevOps | Tahunan / saat arsitektur berubah | Matrix kontrol + approval | MANDATORY (jika cloud) |
| LC-04 | IAM admin: MFA aktif + least privilege role | ISO/IEC 27017 | Infra/DevOps | Bulanan | Daftar akun admin + bukti MFA | MANDATORY (jika cloud) |
| LC-05 | Inventaris PII, tujuan pemrosesan, retensi & penghapusan | ISO/IEC 27018 | SA / DPO internal | Semesteran | Data inventory + policy retensi | MANDATORY (jika ada PII) |
| LC-06 | Prosedur hak subjek data & notifikasi insiden PII | ISO/IEC 27018 | SA / Legal | Tahunan / saat regulasi berubah | SOP DSAR + template notifikasi | MANDATORY (jika ada PII) |
| LC-07 | CAPA log (temuan, akar masalah, aksi, due date, PIC, status) | ISO 9001 | QA Lead | Bulanan | CAPA tracker | MANDATORY |
| LC-08 | KPI mutu proses: defect leakage, lead time fix, SLA support | ISO 9001 | QA Lead / Support Lead | Bulanan | Laporan KPI | MANDATORY |
| LC-09 | BIA ringkas + target RTO/RPO layanan kritikal | ISO 22301 | IT Manager / Business Owner | Tahunan | BIA + tabel RTO/RPO | MANDATORY |
| LC-10 | Simulasi pemulihan/DR minimal 1x per tahun + lesson learned | ISO 22301 | Infra/DevOps + QA | Tahunan | Laporan drill + tindak lanjut | MANDATORY |
| LC-11 | Register use case AI + klasifikasi risiko + human oversight | ISO/IEC 42001:2023 | Product Owner / AI Owner | Semesteran | AI register + approval | CONDITIONAL (jika pakai AI) |
| LC-12 | Monitoring performa/bias AI dan rollback plan | ISO/IEC 42001:2023 | AI Owner / QA | Bulanan | Log monitoring + checklist rollback | CONDITIONAL (jika pakai AI) |

### 17.3 Kriteria N/A (Not Applicable)
- Kontrol AI (`LC-11`, `LC-12`) boleh `N/A` jika modul tidak menggunakan AI.
- Kontrol cloud (`LC-03`, `LC-04`) boleh `N/A` jika seluruh sistem on-premise.
- Kontrol PII (`LC-05`, `LC-06`) boleh `N/A` jika tidak memproses data pribadi pelanggan.
- Status `N/A` wajib menyertakan alasan tertulis dan approval manajemen.

### 17.4 Compliance Gate pada Release
Selain checklist kualitas ISO/IEC 25010, release wajib lolos gate berikut:

| No | Compliance Gate | Status (L/G/N/A) | Evidence | Keterangan |
|----|------------------|------------------|----------|------------|
| 1 | LC-01 risk register terupdate | ☐ | | |
| 2 | LC-02 SOP insiden tersedia dan terbaru | ☐ | | |
| 3 | LC-03/LC-04 kontrol cloud (jika cloud) | ☐ | | |
| 4 | LC-05/LC-06 kontrol PII (jika ada PII) | ☐ | | |
| 5 | LC-07 CAPA log aktif | ☐ | | |
| 6 | LC-08 KPI mutu bulan berjalan tersedia | ☐ | | |
| 7 | LC-09 BIA dan RTO/RPO valid | ☐ | | |
| 8 | LC-10 hasil uji DR terakhir terdokumentasi | ☐ | | |
| 9 | LC-11/LC-12 governance AI (jika ada AI) | ☐ | | |

### 17.5 Definisi Lulus Kepatuhan Minimum
- Release dinyatakan **LAYAK** jika semua kontrol `MANDATORY` berstatus `L`.
- Kontrol `CONDITIONAL` harus `L` atau `N/A` dengan justifikasi valid.
- Evidence wajib tersimpan di repositori dokumentasi proyek dan dapat diaudit.

### 17.6 Definisi Status Audit (Wajib Konsisten)
- `L` (Lulus): kontrol terpenuhi, evidence lengkap, masih berlaku sesuai frekuensi review.
- `G` (Gap): kontrol belum terpenuhi atau evidence tidak lengkap/tidak valid.
- `N/A` (Not Applicable): kontrol tidak relevan dengan kondisi sistem, wajib ada alasan tertulis + approval.

### 17.7 Template Evidence Minimum per Kontrol
Gunakan format file agar mudah ditelusuri:
- `docs/evidence/sales/<control_id>_<topik>_<yyyy-mm-dd>.md`
- Contoh: `docs/evidence/sales/lc-09_bia_rto_rpo_2026-05-21.md`

Struktur isi evidence minimum:
1. Tujuan kontrol
2. Ruang lingkup
3. Tanggal evaluasi
4. PIC evaluator
5. Hasil evaluasi (`L/G/N/A`)
6. Temuan gap (jika ada)
7. Rencana aksi dan target tanggal
8. Approval (nama + jabatan + tanggal)

### 17.8 Matriks Artefak Kontrol (Implementasi Praktis)

| ID | Artefak Utama | Lokasi Evidence yang Disarankan |
|----|----------------|----------------------------------|
| LC-01 | Risk register modul sales | `docs/evidence/sales/lc-01_risk_register_<tanggal>.md` |
| LC-02 | SOP incident response + log insiden | `docs/evidence/sales/lc-02_incident_response_<tanggal>.md` |
| LC-03 | Shared responsibility matrix cloud | `docs/evidence/sales/lc-03_shared_responsibility_<tanggal>.md` |
| LC-04 | Daftar admin + bukti MFA + role mapping | `docs/evidence/sales/lc-04_admin_iam_mfa_<tanggal>.md` |
| LC-05 | Inventaris PII + retensi/penghapusan | `docs/evidence/sales/lc-05_pii_inventory_<tanggal>.md` |
| LC-06 | SOP DSAR + notifikasi insiden PII | `docs/evidence/sales/lc-06_dsar_incident_notice_<tanggal>.md` |
| LC-07 | CAPA tracker bulanan | `docs/evidence/sales/lc-07_capa_log_<tanggal>.md` |
| LC-08 | Laporan KPI mutu proses | `docs/evidence/sales/lc-08_quality_kpi_<tanggal>.md` |
| LC-09 | BIA + target RTO/RPO | `docs/evidence/sales/lc-09_bia_rto_rpo_<tanggal>.md` |
| LC-10 | Laporan DR drill + lesson learned | `docs/evidence/sales/lc-10_dr_drill_<tanggal>.md` |
| LC-11 | Register use case AI + klasifikasi risiko | `docs/evidence/sales/lc-11_ai_use_case_register_<tanggal>.md` |
| LC-12 | Monitoring AI (performa/bias) + rollback plan | `docs/evidence/sales/lc-12_ai_monitoring_rollback_<tanggal>.md` |

### 17.9 Aturan Gate Audit Rilis (Eksekusi)
1. QA/Compliance menilai tabel 17.4 maksimal H-2 sebelum release.
2. Jika ada satu kontrol `MANDATORY` berstatus `G`, release status otomatis `HOLD`.
3. `N/A` tanpa justifikasi tertulis dan approval dianggap `G`.
4. Semua CAPA dari temuan `G` wajib punya PIC, due date, dan status progres.
5. Rekap gate release disimpan dalam satu dokumen ringkas:
   - `docs/evidence/sales/release_compliance_gate_<release-tag>_<tanggal>.md`

---

## 📖 SUMBER & REFERENSI STANDAR

| Standar | Keterangan |
|---------|-------------|
| **ISO/IEC 25010:2011 & 2023** | Systems and software Quality Requirements and Evaluation (SQuaRE) - Model kualitas produk |
| **ISO 9241-11** | Ergonomics of human-system interaction (Efektivitas, efisiensi, kepuasan) |
| **SOX (Sarbanes-Oxley Act)** | Regulasi kepatuhan untuk Segregation of Duties (SoD) di perusahaan publik |
| **UU PDP No.27/2022** | Perlindungan Data Pribadi Indonesia |
| **PCI-DSS** | Keamanan data kartu pembayaran (jika memproses kartu kredit) |
| **WCAG 2.1 level A** | Web Content Accessibility Guidelines (untuk aksesibilitas) |

---

## 📌 PENUTUP

Dokumen ini bersifat **mengikat** untuk seluruh tim yang terlibat dalam pengembangan modul penjualan ERP.

**Pengecualian** terhadap standar ini dapat diberikan oleh Product Manager, namun WAJIB didokumentasikan dalam bentuk *deviation request* tertulis yang disetujui bersama tim compliance dan security.

---

**Disusun oleh:** [Nama Tim / Departemen]  
**Disetujui oleh:** [Nama Product Manager / CTO]  
**Tanggal Berlaku:** [Tanggal]  
**Versi Dokumen:** 3.0