Files
accounting_dev_v2/docs/PRODUCTION-DB-RETUR-REFUND.md
2026-09-11 16:03:00 +07:00

74 lines
4.3 KiB
Markdown

# Deployment Production — Retur & Refund Pembelian
Dokumen ini adalah checklist deployment. Jangan menyalin database Development ke Production.
## Migration wajib
Ambil backup penuh database dan folder `uploads/accounting` sebelum deployment, lalu jalankan migration secara berurutan:
1. `20260905000800_finalize_purchase_returns_refunds.php`
2. `20260905000900_add_purchase_adjustment_reversal_audit.php`
3. `20260905001000_reconcile_duplicate_purchase_receipt_ledger.php`
Migration terakhir tidak menghapus ledger. Jika mendeteksi penerimaan yang dahulu di-backfill lalu diposting ulang oleh PurchaseService, migration membuat mutasi kompensasi `data_reconciliation` yang dapat diaudit. Tinjau hasil deteksinya bersama Finance sebelum production. Migration sengaja tidak menyediakan rollback destruktif karena ledger transaksi bersifat immutable; pemulihan memakai backup atau dokumen reversal baru.
## Mapping COA yang wajib diverifikasi Finance
Pastikan mapping aktif, `allow_posting=1`, berada pada company yang tepat, dan menunjuk COA resmi Production:
- `inventory`
- `accounts_payable`
- `purchase_input_tax`
- `goods_in_transit`
- `supplier_advances`
- `supplier_refund_receivable`
- `purchase_return_adjustment`
- `bank_charge_expense`
- `purchase_price_variance`
Migration Development dapat membuat akun contoh untuk tiga mapping Retur/Refund. ID akun, kode akun contoh, dan mapping Development tidak boleh disalin mentah ke Production.
## Data yang tidak boleh disalin
- User, role, permission, session, dan token Development.
- Nomor sequence Development.
- PO, penerimaan, invoice, pembayaran, retur, refund, Debit Note, jurnal, serta lampiran uji.
- Akun contoh `Piutang Refund Supplier`, `Penyesuaian Retur Pembelian`, atau `Selisih Harga Pembelian` tanpa persetujuan Finance.
- Jurnal baseline/koreksi dengan referensi `DEV-*`.
## Rekonsiliasi sebelum deployment
1. Tutup input transaksi sementara dan ambil cut-off time.
2. Cocokkan PO, penerimaan posted, invoice supplier, pembayaran, dan saldo hutang.
3. Cocokkan qty `items`, `item_barcodes`, `stock_logs`, dan `inventory_ledger` per item/gudang.
4. Identifikasi penerimaan posted yang belum mempunyai invoice supplier. Nilainya merupakan reconciling item sementara pada implementasi existing, bukan alasan membuat jurnal dummy.
5. Cocokkan akun Persediaan, Hutang Usaha, Barang Dalam Perjalanan, Uang Muka Supplier, Pajak Masukan, dan Piutang Refund Supplier.
6. Pastikan tidak ada periode accounting yang salah status open/closed.
Pada Development tanggal 5 September 2026, koreksi duplicate receipt sebanyak 200 unit telah dibuat melalui migration `20260905001000`; kuantitas ledger, stock log, dan cache item sesudahnya sudah sama. Pemeriksaan terakhir menunjukkan reconciling item nilai Rp25.769.435. Rincian utamanya adalah penerimaan posted yang belum selesai menjadi invoice supplier, sehingga nilai fisik sudah masuk ledger tetapi pengakuan akuntansinya masih menunggu penyelesaian dokumen. Angka ini bersifat snapshot dan dapat berubah ketika transaksi development bertambah. Jangan membawa angka Development tersebut ke Production; Production harus dihitung ulang dari dokumen cut-off sendiri.
## Rekonsiliasi setelah deployment
Jalankan:
```powershell
php index.php migrate status
php index.php purchaseadjustmentcheck runtime
php index.php purchaseadjustmentcheck integrity
php index.php stage17check
php index.php payablecheck integrity
php index.php inventorycheck integrity
php index.php inventorycheck reconciliation
vendor\bin\phpunit --colors=never
```
Hasil yang harus nol: jurnal tidak balance, stok negatif, duplicate idempotency, refund melebihi klaim, saldo invoice negatif, orphan attachment/reference, dan kebocoran company. `inventorycheck reconciliation` hanya boleh disetujui jika selisih nol atau seluruh reconciling item penerimaan-belum-invoice mempunyai daftar dokumen dan persetujuan Finance.
## Uji akses dan operasional
1. Logout/login ulang seluruh role agar permission baru terbaca.
2. Uji Purchasing, Gudang, Finance, Approver, Auditor, dan Master Admin secara terpisah.
3. Uji satu retur `UNIT`, satu retur `QTY`, retur multi-item, pengganti parsial, refund parsial, Debit Note invoice terbuka, dan Debit Note invoice lunas.
4. Uji PDF iframe dan upload multi-file pada Chrome/Edge/Firefox serta HP.
5. Simpan hasil rekonsiliasi, screenshot approval, dan output QA sebagai bukti deployment.