# Plan Adopsi `produk_source` / `produk_target` ke `variant_cutover`

## 1) Tujuan

Mengembalikan desain `produk_jenis` pada modul `variant_cutover` agar konsisten dengan desain modul `konversi`, yaitu:

- gate sumber: `produk_source`
- gate target: `produk_target`

## 2) Root Cause yang Ditemukan

Di `variant_cutover` terjadi mismatch konfigurasi:

- `coTransaksiValues.php` sudah memakai `produk_source` / `produk_target`
- `coTransaksiCore.php` masih memakai nilai generik `produk`

Akibatnya, identitas source/target tidak konsisten antar gate config.

## 3) Scope Plan (Tanpa Ubah Logic Bisnis Lain)

File utama:

- `application/modules/variant_cutover/config/coTransaksiCore.php`
- `application/modules/variant_cutover/config/coTransaksiValues.php` (verifikasi parity)
- `application/modules/variant_cutover/controllers/Transaksi.php` (compatibility read)
- `application/modules/variant_cutover/controllers/Printing.php` (cek dampak output)
- `application/controllers/ExcelWriter.php` (cek dampak export lama)

Flow utama:

- `881` (cabang)
- `7881` (pusat)

## 4) Rencana Eksekusi

### Fase A - Normalisasi Config Core

Untuk flow `881` dan `7881` di `coTransaksiCore.php`, ubah `tableIn_static`:

- `detail.produk_jenis`: `produk` -> `produk_source`
- `detail2.produk_jenis`: `produk` -> `produk_target`
- `detail2_sum.produk_jenis`: `produk` -> `produk_target`
- `rsltItems.produk_jenis`: `produk` -> `produk_source`

Catatan: `coTransaksiValues.php` sudah sesuai, jadi hanya dipakai sebagai baseline parity check.

### Fase B - Backward Compatibility Query

Dokumen lama kemungkinan masih menyimpan `produk_jenis='produk'`.
Untuk query baca/report, gunakan fallback:

- Source reader: `IN ('produk_source', 'produk')`
- Target reader: `IN ('produk_target', 'produk')` bila query butuh agregasi target

Prioritas patch compatibility:

1. `application/modules/variant_cutover/controllers/Transaksi.php`
2. `application/controllers/ExcelWriter.php` (khusus mode export lama)

### Fase C - Verifikasi Runtime Gate

Pastikan saat save/request dan approve:

- `$_SESSION[$cCode]['tableIn_detail'][*]['produk_jenis'] == 'produk_source'`
- `$_SESSION[$cCode]['tableIn_detail2_sum'][*]['produk_jenis'] == 'produk_target'`
- `$_SESSION[$cCode]['tableIn_detail_rsltItems'][*]['produk_jenis'] == 'produk_source'` (jika gate ini dipakai flow)

### Fase D - Verifikasi Persistensi DB

Untuk transaksi baru (`881`, `7881`) lakukan cek:

- `transaksi_data` baris source tersimpan sebagai `produk_source`
- `transaksi_data` baris target tersimpan sebagai `produk_target`
- tidak ada baris `produk_jenis='produk'` pada transaksi baru sesudah patch

## 5) Parameter Bukti Bahwa Kondisi Sudah Benar

### Parameter Konfigurasi

1. Parity `coTransaksiCore` vs `coTransaksiValues` sama untuk 4 gate (`detail`, `detail2`, `detail2_sum`, `rsltItems`) di `881` dan `7881`.
2. Tidak ada nilai generik `produk` di `tableIn_static` untuk gate konversi varian.

### Parameter Runtime (Session)

1. Gate source terisi `produk_source`.
2. Gate target terisi `produk_target`.
3. Mapping source-target tetap valid setelah edit qty/alokasi.

### Parameter Persistensi (DB)

1. `COUNT(*)` source (`produk_source`) > 0 untuk transaksi uji.
2. `COUNT(*)` target (`produk_target`) > 0 untuk transaksi uji.
3. `COUNT(*) produk_jenis='produk'` = 0 untuk transaksi uji baru.

### Parameter Integritas Bisnis

1. Total qty source = total qty target (per transaksi).
2. Total nilai source = total nilai target (per transaksi, sesuai formula existing).
3. Validasi parent-variant tetap lolos pada mapping benar, dan gagal pada mapping salah.

### Parameter Kompatibilitas

1. Dokumen lama (sebelum patch, `produk_jenis='produk'`) tetap bisa dibuka/di-review.
2. Export/report lama tidak hilang data karena filter tunggal `produk`.
3. Tidak ada regression pada flow non-konversi.

## 6) SQL Bukti (Template)

Gunakan `:TRX_ID` untuk transaksi uji:

```sql
SELECT produk_jenis, COUNT(*) AS jml_baris, SUM(valid_qty) AS total_qty
FROM transaksi_data
WHERE transaksi_id = :TRX_ID
  AND trash = 0
GROUP BY produk_jenis;
```

```sql
SELECT
  SUM(CASE WHEN produk_jenis = 'produk_source' THEN valid_qty ELSE 0 END) AS qty_source,
  SUM(CASE WHEN produk_jenis = 'produk_target' THEN valid_qty ELSE 0 END) AS qty_target
FROM transaksi_data
WHERE transaksi_id = :TRX_ID
  AND trash = 0;
```

## 7) Exit Criteria Plan

Plan dianggap siap dieksekusi implementasi jika:

1. Mismatch config sudah dipastikan hanya pada `coTransaksiCore` (flow `881`, `7881`).
2. Daftar query compatibility yang butuh fallback sudah terpetakan.
3. Parameter bukti (config, session, DB, compatibility) disepakati sebagai acceptance gate.