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

4.3 KiB

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:

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.