# Dokumentasi Awal Sistem Apotek Siaga

**Dari Excel ke Prototype Aplikasi Operasional Apotek**  
Tanggal: 30 Juni 2026  
Versi: V0.1 - Catatan awal untuk Notion, Cursor, dan arsip proyek

> Prinsip utama: aplikasi ini bukan harus langsung menggantikan seluruh operasional apotek. Tahap awalnya adalah prototype untuk memahami, merapikan, dan memvalidasi alur kerja Excel yang sudah berjalan.

---

## 1. Gambaran Umum

Proyek ini adalah inisiatif untuk membuat prototype aplikasi web manajemen operasional untuk **Apotek Siaga 24** dan **Apotek Siaga 25**. Saat ini pencatatan operasional masih banyak dilakukan melalui beberapa file Excel yang digunakan admin apotek.

Tujuan awal bukan membuat aplikasi apotek komersial lengkap dari hari pertama, tetapi membuat sistem yang lebih dekat dengan cara kerja apotek saat ini, sehingga alur bisnis bisa dipahami, divalidasi, lalu didigitalisasi secara bertahap.

### Tujuan utama

- Mengubah pencatatan Excel menjadi struktur data yang lebih rapi.
- Membantu owner melihat ringkasan performa bisnis.
- Membantu admin memahami pembelian, penjualan, tagihan supplier, dan cash flow.
- Menjadi dasar untuk pengembangan aplikasi produksi jika prototype terbukti cocok.
- Menghindari fitur terlalu kompleks sebelum alur bisnis benar-benar dipahami.

---

## 2. Ruang Lingkup Bisnis

Apotek yang menjadi konteks awal:

- Apotek Siaga 24
- Apotek Siaga 25

Istilah bisnis yang digunakan admin dan perlu dipertahankan di aplikasi:

- **PBF**: supplier/distributor farmasi.
- **Faktur**: dokumen tagihan/pembelian dari PBF.
- **DPB**: pencatatan barang masuk/pembelian dari PBF.
- **OTC**: penjualan bebas / over the counter.
- **Medis**: penjualan atau transaksi yang terkait pelanggan medis/klinik/layanan medis.
- **Cash Flow**: pencatatan arus kas masuk dan keluar.
- **Tagihan Supplier/PBF**: hutang ke supplier berdasarkan faktur pembelian.
- **Estimasi Pembayaran**: rencana bayar supplier berdasarkan ketersediaan dana.

---

## 3. Sumber Data Excel yang Sudah Diketahui

| No | File Excel | Peran Awal dalam Sistem |
|---:|---|---|
| 1 | `1 HARGA JUNI 2026.xlsx` | Sumber awal master barang/obat dan harga. |
| 2 | `2 BARANG TERJUAL 2026.xlsx` | Sumber awal transaksi/detail barang terjual. |
| 3 | `3 CEK CASH FLOW 2026.xlsx` | Sumber awal cash flow. Sheet yang disebut: `BCA 2026`, `Cash OTC`, `CASH Medis`. |
| 4 | `5. DAFTAR TAGIHAN SUPPLIER.xlsx` | Sumber awal tagihan supplier dan estimasi pembayaran. Sheet yang disebut: `estimasi pembayaran`. |
| 5 | `6 DPB.xlsx` | Sumber awal pembelian barang/DPB dari PBF. |

Catatan penting: file-file ini tidak harus langsung di-import otomatis pada tahap awal. Untuk V0, file tersebut lebih dulu digunakan untuk memahami struktur data dan alur kerja nyata.

---

## 4. Prinsip Pengembangan

### Prinsip produk

- Fokus pada validasi alur bisnis, bukan langsung mengejar aplikasi apotek lengkap.
- Mulai dari fitur kecil yang benar-benar mengikuti file Excel admin.
- Gunakan istilah yang sudah dikenal admin.
- UI harus bersih, sederhana, dan mudah dipahami.
- Hindari membuat fitur besar sebelum modul dasar stabil.

### Prinsip teknis

- Stack awal: Laravel, Blade, Tailwind CSS.
- Database prototype boleh SQLite, tetapi migration harus kompatibel dengan MySQL.
- Nama menu, field, variable, status, dan label menggunakan Bahasa Indonesia.
- Untuk nama tabel Indonesia yang tidak mengikuti pluralisasi Laravel, gunakan `protected $table` di Model agar eksplisit.
- Buat seeder dummy data realistis untuk demo awal.
- Commit kecil setiap selesai satu modul/fase.

---

## 5. Alur Bisnis Utama

### 5.1 Master Data

Admin memiliki data utama berupa:

- Data cabang apotek
- Data obat/barang
- Data harga obat/barang
- Data pelanggan
- Data PBF/supplier

Master data adalah fondasi. Modul transaksi tidak boleh dibuat terlalu jauh sebelum master dasar cukup jelas.

### 5.2 Pembelian Barang / DPB

DPB adalah pencatatan barang masuk dari PBF.

Alur umum:

1. PBF mengirim barang.
2. Faktur diterima.
3. Barang dicatat di DPB.
4. Stok bertambah.
5. Tagihan PBF muncul.
6. Tagihan masuk ke daftar pembayaran supplier.

Data yang biasanya dibutuhkan:

- tanggal terima
- tanggal faktur
- nama PBF
- cabang
- nomor faktur
- kode produk
- nama barang
- SK / isi kemasan
- jumlah
- harga beli
- subtotal
- diskon

### 5.3 Penjualan

Jenis penjualan awal:

- Penjualan Medis
- Penjualan OTC

Alur umum:

1. Pelanggan membeli barang.
2. Transaksi dicatat.
3. Detail barang terjual tersimpan.
4. Stok berkurang.
5. Kas masuk tercatat.

Pada V0, penjualan tidak harus langsung berbentuk POS lengkap. Boleh dimulai dari input transaksi sederhana atau import/manual entry berdasarkan struktur file `BARANG TERJUAL`.

### 5.4 Cash Flow

Sumber kas yang sudah terlihat:

- Kas Medis
- Kas OTC
- Rekening BCA

Setiap mutasi kas idealnya memiliki:

- tanggal
- sumber kas
- jenis mutasi: masuk/keluar
- kategori
- keterangan
- pemasukan
- pengeluaran
- saldo

### 5.5 Tagihan PBF dan Rencana Pembayaran

Setelah pembelian dari PBF, sistem perlu membentuk tagihan supplier.

Data tagihan berisi:

- nama PBF
- cabang
- nomor faktur
- tanggal faktur
- tanggal terima
- tanggal jatuh tempo
- nilai faktur
- jumlah bayar
- sisa tagihan
- status tagihan
- keterangan

Status tagihan:

- Belum Lunas
- Sebagian
- Lunas

Rencana pembayaran adalah daftar rencana bayar supplier berdasarkan ketersediaan uang. Ini bukan pembayaran final.

Status rencana pembayaran:

- Direncanakan
- Dibayar
- Batal

---

## 6. Target V0 - Prototype yang Realistis

V0 harus kecil, rapi, dan bisa dipresentasikan. Targetnya bukan mengganti seluruh operasional, melainkan menunjukkan alur bisnis inti.

### Fitur V0 yang disarankan

1. Dashboard ringkas
2. CRUD data cabang
3. CRUD data obat/barang
4. CRUD data pelanggan
5. CRUD data PBF/supplier
6. Modul DPB/pembelian barang sederhana
7. Modul penjualan Medis dan OTC sederhana
8. Modul stok obat dan mutasi stok
9. Modul tagihan PBF
10. Modul rencana pembayaran PBF
11. Modul cash flow
12. Laporan awal dengan filter tanggal sederhana

### Yang tidak dibuat dulu

- Barcode scanner
- Printer thermal
- BPJS
- Resep dokter detail
- Multi-user permission kompleks
- API eksternal
- Akuntansi lengkap
- Import Excel otomatis penuh
- Migrasi semua data historis dari awal

---

## 7. Rancangan Menu Sidebar

```text
Dashboard

Master Data
- Data Cabang
- Data Obat
- Data Pelanggan
- Data PBF

Pembelian
- DPB / Pembelian Barang
- Detail Pembelian

Penjualan
- Penjualan Medis
- Penjualan OTC
- Barang Terjual

Stok
- Stok Obat
- Mutasi Stok

Keuangan
- Kas Medis
- Kas OTC
- Rekening BCA
- Cash Flow

Supplier / PBF
- Tagihan PBF
- Rencana Pembayaran
- Pembayaran PBF

Laporan
- Laporan Penjualan
- Laporan Pembelian
- Laporan Stok
- Laporan Cash Flow
- Laporan Tagihan PBF
```

---

## 8. Rancangan Modul dan Field Awal

### 8.1 Data Cabang

Tabel: `cabang`

- `id`
- `nama_cabang`
- `alamat`
- `telepon`
- `keterangan`

Seeder awal:

- Apotek Siaga 24
- Apotek Siaga 25

### 8.2 Data Obat

Tabel: `obat`

- `id`
- `kode_obat`
- `nama_obat`
- `golongan_obat`
- `satuan`
- `kemasan_terkecil`
- `isi_kemasan`
- `harga_modal`
- `harga_otc`
- `harga_reg`
- `harga_vip`
- `stok_awal`
- `keterangan`

Fitur:

- pencarian obat
- filter golongan obat
- tabel responsif

### 8.3 Data Pelanggan

Tabel: `pelanggan`

- `id`
- `kode_pelanggan`
- `nama_pelanggan`
- `nama_faktur`
- `area`
- `top`
- `jenis_harga`
- `alamat`
- `nomor_hp`
- `keterangan`

Jenis harga:

- OTC
- REG
- VIP

### 8.4 Data PBF

Tabel: `pbf`

- `id`
- `nama_pbf`
- `alamat`
- `telepon`
- `kontak_sales`
- `keterangan`

### 8.5 Pembelian / DPB

Tabel utama: `pembelian`

- `id`
- `tanggal_terima`
- `tanggal_faktur`
- `pbf_id`
- `cabang_id`
- `nomor_faktur`
- `total_faktur`
- `status_tagihan`
- `keterangan`

Tabel detail: `detail_pembelian`

- `id`
- `pembelian_id`
- `obat_id`
- `kode_produk`
- `nama_barang`
- `sk`
- `jumlah`
- `harga_beli`
- `subtotal`
- `diskon_persen`
- `jumlah_satuan_kecil`
- `harga_satuan_kecil`

Logika awal:

- Saat pembelian disimpan, stok obat bertambah.
- Mutasi stok otomatis tercatat.
- Tagihan PBF dibuat atau diperbarui berdasarkan faktur.

### 8.6 Penjualan

Tabel utama: `penjualan`

- `id`
- `tanggal_penjualan`
- `jenis_penjualan`
- `cabang_id`
- `pelanggan_id`
- `nomor_faktur`
- `total_penjualan`
- `metode_pembayaran`
- `sumber_kas`
- `keterangan`

Tabel detail: `detail_penjualan`

- `id`
- `penjualan_id`
- `obat_id`
- `kode_barang`
- `nama_barang`
- `jumlah`
- `satuan`
- `harga_satuan`
- `subtotal`

Logika awal:

- Saat penjualan disimpan, stok obat berkurang.
- Mutasi stok otomatis tercatat.
- Kas masuk tercatat ke sumber kas terkait.

### 8.7 Stok Obat

Tabel: `stok_obat`

- `id`
- `cabang_id`
- `obat_id`
- `jumlah_stok`
- `stok_minimum`

Status stok:

- Aman
- Menipis
- Habis

### 8.8 Mutasi Stok

Tabel: `mutasi_stok`

- `id`
- `tanggal`
- `cabang_id`
- `obat_id`
- `jenis_mutasi`
- `jumlah`
- `sumber_transaksi`
- `referensi_id`
- `keterangan`

Jenis mutasi:

- Pembelian
- Penjualan
- Koreksi
- Retur

### 8.9 Tagihan PBF

Tabel: `tagihan_pbf`

- `id`
- `pbf_id`
- `cabang_id`
- `nomor_faktur`
- `tanggal_faktur`
- `tanggal_terima`
- `tanggal_jatuh_tempo`
- `nilai_faktur`
- `jumlah_bayar`
- `sisa_tagihan`
- `status_tagihan`
- `keterangan`

Status tagihan:

- Belum Lunas
- Sebagian
- Lunas

### 8.10 Rencana Pembayaran PBF

Tabel: `rencana_pembayaran_pbf`

- `id`
- `tanggal_rencana`
- `pbf_id`
- `cabang_id`
- `jumlah_rencana_bayar`
- `sumber_dana`
- `status`
- `keterangan`

Sumber dana:

- Kas Medis
- Kas OTC
- BCA

Status:

- Direncanakan
- Dibayar
- Batal

### 8.11 Cash Flow

Tabel: `mutasi_kas`

- `id`
- `tanggal`
- `sumber_kas`
- `jenis_mutasi`
- `kategori`
- `keterangan`
- `pemasukan`
- `pengeluaran`
- `saldo`

Kategori:

- Penjualan Medis
- Penjualan OTC
- Pembayaran PBF
- Setor Tunai
- Operasional
- Lain-lain

---

## 9. Dashboard Awal

Dashboard V0 cukup menggunakan card sederhana.

Ringkasan yang ditampilkan:

- total obat
- total pelanggan
- total PBF
- penjualan hari ini
- pembelian bulan ini
- tagihan PBF belum lunas
- kas masuk bulan ini
- kas keluar bulan ini
- saldo kas ringkas
- stok menipis
- stok habis

---

## 10. Laporan Awal

Laporan awal cukup sederhana dan memiliki filter tanggal.

Daftar laporan:

- Laporan Penjualan
- Laporan Pembelian
- Laporan Tagihan PBF
- Laporan Cash Flow
- Laporan Stok Obat

Prioritas laporan pertama:

1. Laporan Tagihan PBF
2. Laporan Cash Flow
3. Laporan Penjualan
4. Laporan Pembelian
5. Laporan Stok

Alasannya: tagihan supplier dan cash flow biasanya lebih cepat memberi manfaat untuk owner/admin karena berhubungan langsung dengan uang keluar/masuk dan kewajiban pembayaran.

---

## 11. Strategi Import dan Migrasi Data

Jangan langsung memaksakan semua Excel di-import otomatis.

Tahapan yang lebih aman:

1. **Mapping kolom Excel**
   - Pahami nama kolom dan arti bisnisnya.
   - Tandai kolom wajib, opsional, dan kolom laporan saja.

2. **Dummy data realistis**
   - Buat seeder berdasarkan contoh data, bukan data real penuh.
   - Tujuannya untuk menguji alur aplikasi.

3. **Input manual terbatas**
   - Uji beberapa data DPB, penjualan, cash flow, dan tagihan.
   - Validasi apakah hasilnya masuk akal.

4. **Import Excel per modul**
   - Mulai dari master obat/harga.
   - Lanjut DPB.
   - Lanjut tagihan supplier.
   - Lanjut penjualan dan cash flow.

5. **Migrasi produksi**
   - Baru dipikirkan setelah owner/admin setuju dengan alur prototype.

---

## 12. Urutan Pengerjaan yang Disarankan

### Fase 0 - Dokumentasi dan Setup

- Rapikan dokumentasi ini.
- Buat repo/project Laravel yang bersih.
- Tentukan stack dan database prototype.
- Buat layout dasar: login sederhana, sidebar, dashboard kosong.

### Fase 1 - Master Data

- Data Cabang
- Data PBF
- Data Obat
- Data Pelanggan

Output fase ini: admin bisa melihat dan mengelola data dasar.

### Fase 2 - Pembelian / DPB

- Input pembelian dari PBF.
- Input detail barang pembelian.
- Stok bertambah.
- Tagihan PBF terbentuk.

Output fase ini: alur barang masuk mulai terlihat.

### Fase 3 - Tagihan dan Rencana Pembayaran

- Daftar tagihan PBF.
- Update status pembayaran.
- Rencana pembayaran supplier.

Output fase ini: admin bisa melihat kewajiban bayar supplier.

### Fase 4 - Penjualan dan Stok Keluar

- Input penjualan Medis.
- Input penjualan OTC.
- Stok berkurang.
- Kas masuk tercatat.

Output fase ini: alur barang keluar dan kas masuk terlihat.

### Fase 5 - Cash Flow dan Laporan

- Mutasi kas.
- Ringkasan kas masuk/keluar.
- Laporan penjualan, pembelian, stok, tagihan, cash flow.

Output fase ini: aplikasi mulai bisa dipakai untuk demo owner/admin.

---

## 13. Prioritas Pengerjaan 7 Hari Pertama

| Hari | Fokus | Output Kecil |
|---:|---|---|
| 1 | Dokumentasi dan struktur menu | Dokumen ini masuk Notion/Cursor, struktur sidebar jelas. |
| 2 | Setup Laravel + layout | Project jalan, sidebar dan dashboard kosong tampil. |
| 3 | Master Cabang dan PBF | CRUD cabang dan PBF selesai. |
| 4 | Master Obat | CRUD obat dan field harga awal selesai. |
| 5 | Pembelian / DPB basic | Form pembelian dan detail pembelian awal. |
| 6 | Tagihan PBF | Tagihan muncul dari pembelian atau input manual. |
| 7 | Review dan demo kecil | Catat gap, rapikan UI, commit kondisi stabil. |

Catatan: jadwal ini bukan tekanan. Ini hanya peta kecil agar tidak merasa harus mengerjakan semuanya sekaligus.

---

## 14. Catatan untuk Agent AI Cursor/Replit

Gunakan instruksi ini jika bekerja dengan AI agent:

```text
Bangun prototype Laravel untuk sistem operasional Apotek Siaga. Fokus pada validasi alur bisnis dari Excel, bukan aplikasi apotek lengkap.

Gunakan Bahasa Indonesia untuk nama menu, label form, field, variable, status, dan nama tabel. UI harus sederhana, bersih, responsive, dan mudah dipahami admin apotek.

Stack: Laravel, Blade, Tailwind CSS. Database prototype boleh SQLite, tetapi migration harus kompatibel dengan MySQL. Gunakan seeder dummy data realistis.

Prioritas awal:
1. Layout dashboard dan sidebar.
2. CRUD Data Cabang.
3. CRUD Data PBF.
4. CRUD Data Obat.
5. CRUD Data Pelanggan.
6. Modul Pembelian / DPB sederhana.
7. Modul Tagihan PBF.
8. Modul Cash Flow sederhana.

Jangan buat dulu barcode scanner, printer thermal, BPJS, resep dokter detail, permission kompleks, API eksternal, akuntansi lengkap, atau import Excel otomatis penuh.

Kerjakan bertahap. Setelah satu modul selesai, pastikan route, controller, model, migration, seeder, dan blade view berjalan. Hindari over-engineering.
```

---

## 15. Risiko dan Batasan

### Risiko scope terlalu besar

Aplikasi apotek bisa melebar menjadi POS, inventory, accounting, supplier management, report, barcode, expiry tracking, dan integrasi lain. Untuk menghindari burnout, V0 harus tetap kecil.

### Risiko data Excel tidak konsisten

File Excel yang sudah dipakai bertahun-tahun mungkin memiliki format tidak konsisten. Karena itu import otomatis jangan dijadikan target awal.

### Risiko aplikasi tidak dipakai

Karena proyek ini belum menjadi permintaan resmi, jangan terlalu banyak mengeluarkan modal sebelum ada demo kecil dan validasi owner/admin.

### Risiko teknis

Jika menggunakan AI agent, hasil bisa cepat tetapi tetap perlu dicek. Jangan langsung percaya seluruh struktur database yang dibuat agent tanpa membaca alur bisnisnya.

---

## 16. Definisi Selesai untuk V0

V0 dianggap cukup jika:

- Admin bisa login dan melihat dashboard.
- Cabang, obat, pelanggan, dan PBF bisa dikelola.
- Pembelian/DPB bisa dicatat.
- Stok bisa bertambah dari pembelian.
- Penjualan sederhana bisa dicatat.
- Stok bisa berkurang dari penjualan.
- Tagihan PBF bisa dilihat dan diberi status.
- Rencana pembayaran PBF bisa dibuat.
- Cash flow masuk/keluar bisa dicatat.
- Ada laporan awal dengan filter tanggal.
- UI cukup rapi untuk ditunjukkan ke owner/admin.

---

## 17. Kalimat Pengingat Scope

> Tujuan V0 adalah membantu membaca dan merapikan alur Excel apotek, bukan menggantikan seluruh operasional apotek dalam sekali jalan.

> Aplikasi ini boleh besar nanti, tetapi langkah pertamanya harus kecil, jelas, dan bisa selesai.

---

## 18. Lampiran — Catatan Tambahan

> Catatan ini melengkapi dokumentasi V0.1 di atas. Section §8 (Rancangan Modul) masih mencerminkan desain awal; untuk implementasi prototype, gunakan catatan di bawah ini sebagai acuan stok dan transaksi.

> **Insight operasional terbaru:** Lihat [`Insight_Proses_Bisnis_Apotek_Siaga.md`](Insight_Proses_Bisnis_Apotek_Siaga.md) untuk aturan bisnis tentang batch/expired dari faktur PBF, perubahan harga beli, dan margin VIP minimal 11%.

### 18.1 Catatan Penting: Stok Obat Berdasarkan Batch dan Expired Date

Untuk aplikasi apotek, stok obat tidak boleh hanya disimpan sebagai satu angka total di master obat. Satu jenis obat bisa memiliki beberapa batch berbeda, expired date berbeda, harga beli berbeda, dan bisa tersebar di cabang berbeda.

Karena itu, stok perlu dicatat berdasarkan kombinasi:

- cabang
- obat
- nomor batch
- tanggal expired
- jumlah stok
- harga beli / modal batch
- sumber pembelian / faktur

#### Prinsip

- **Master `obat`** hanya menyimpan data umum obat, seperti kode obat, nama obat, satuan, kategori/golongan, dan harga jual (OTC/REG/VIP). Tidak ada `stok_awal` atau `harga_modal` di master.
- **Jumlah stok aktual** sebaiknya dihitung dari tabel `stok_batch_obat` (agregat per cabang + obat).
- **Saat pembelian / DPB disimpan**, sistem menambah stok berdasarkan batch dan expired date.
- **Saat penjualan disimpan**, sistem mengurangi stok dari batch tertentu.
- **Untuk tahap awal**, sistem boleh menggunakan aturan **FEFO** (First Expired First Out): stok dengan expired date paling dekat dikeluarkan lebih dulu.
- **Dashboard stok** perlu menampilkan stok menipis, stok habis, dan obat mendekati expired.

#### Tabel `stok_batch_obat`

| Field | Keterangan |
|-------|------------|
| `id` | PK |
| `cabang_id` | FK cabang |
| `obat_id` | FK obat |
| `pembelian_detail_id` | FK sumber pembelian/faktur (nullable untuk koreksi manual) |
| `nomor_batch` | Nomor batch dari supplier |
| `tanggal_expired` | Tanggal kadaluarsa batch |
| `jumlah_stok` | Sisa stok batch ini |
| `harga_beli` | Harga modal batch ini |
| `stok_minimum` | Ambang peringatan menipis (opsional per batch) |
| `keterangan` | Catatan |

**Catatan teknis:**

- Jika DPB ulang dengan kombinasi `cabang + obat + nomor_batch + tanggal_expired` identik, sistem boleh merge (increment `jumlah_stok`) daripada membuat record duplikat.
- `mutasi_stok` sebaiknya mereferensikan `stok_batch_obat_id` agar jejak audit per batch jelas.
- Helper `StokService` disarankan untuk agregat stok, deteksi menipis/habis/mendekati expired, dan logika FEFO.

### 18.2 Logika Transaksi Awal

Setiap peristiwa bisnis memicu efek sistem yang konsisten. Tabel berikut menjadi acuan implementasi:

| Peristiwa | Efek Sistem |
|-----------|-------------|
| **Pembelian / DPB disimpan** | Stok batch obat bertambah berdasarkan cabang, obat, nomor batch, dan tanggal expired. Tagihan PBF dibuat/diperbarui. |
| **Penjualan disimpan** | Stok batch obat berkurang. Jika belum ada pemilihan batch manual, sistem menggunakan aturan **FEFO**: batch dengan expired date paling dekat keluar lebih dulu. |
| **Koreksi stok** | Mutasi stok dibuat pada batch tertentu agar histori perubahan tetap jelas. |
| **Obat mendekati expired** | Ditampilkan sebagai alert/laporan agar admin bisa mengambil tindakan lebih awal. |

```mermaid
flowchart TD
    DPB[Pembelian / DPB disimpan] --> TambahBatch[Stok batch obat bertambah]
    TambahBatch --> Tagihan[Tagihan PBF dibuat / diperbarui]
    Jual[Penjualan disimpan] --> KurangiBatch[Stok batch obat berkurang]
    KurangiBatch --> FEFO{Batch manual?}
    FEFO -->|Tidak| FEFORule[FEFO: expired terdekat keluar dulu]
    FEFO -->|Ya| BatchManual[Kurangi dari batch terpilih]
    Koreksi[Koreksi stok] --> Mutasi[Mutasi stok per batch]
    Expired[Obat mendekati expired] --> Alert[Alert dashboard + laporan]
```

#### Implikasi singkat per fase

- **Fase 2 (DPB)**: setiap `detail_pembelian` (wajib isi `nomor_batch` + `tanggal_expired`) → insert/update `stok_batch_obat` + `mutasi_stok` + `tagihan_pbf`
- **Fase 4 (Penjualan)**: kurangi stok via FEFO + catat `mutasi_stok` + jejak batch di `detail_penjualan_batch`
- **Fase 4 (Koreksi stok)**: pilih batch spesifik → adjust `jumlah_stok` + catat `mutasi_stok` (jenis: Koreksi)
- **Fase 5 (Dashboard/Laporan)**: tampilkan alert obat mendekati expired + laporan stok batch