Files
accounting_dev_v2/docs/PRODUCTION-DB-SALES-INVOICE.md
T
2026-09-11 16:03:00 +07:00

3.2 KiB

Deployment Database Production — Penjualan

Sebelum deployment

  1. Buat backup database dan folder uploads/accounting.
  2. Pastikan seluruh migration sampai 20260906001100 sudah diterapkan.
  3. Rekonsiliasi invoice lama, jurnal penjualan, stock_logs, inventory_ledger, dan status barcode. Tandai khusus invoice legacy yang sudah pernah mengurangi stok.
  4. Pastikan mapping akun Penjualan lengkap untuk setiap company.

Migration

Jalankan berurutan:

  • 20260907000100_finalize_sales_invoice_workflow
  • 20260907000200_complete_sales_document_metadata
  • 20260907000300_expand_sales_return_barcode_status
  • 20260907000400_scope_document_numbering_by_company

Migration bersifat additive dan tidak menghapus kolom/tabel lama. company_id, metadata invoice, tabel Surat Jalan, relasi multi-barcode, sumber pembayaran, pengakuan pendapatan, dan retur akan ditambahkan. Enum barcode mempertahankan seluruh status Pembelian/Persediaan yang sudah ada dan menambah quarantine serta damaged. Migration keempat mengganti unique index nomor dokumen global menjadi per-company dan membuat sequence atomik per perusahaan. Struktur data transaksi tidak dihapus.

Setelah deployment

  1. Jalankan php index.php salescheck.
  2. Uji satu invoice Development: pilih barcode → post Surat Jalan → ajukan → approve/post → bayar dengan bukti.
  3. Bandingkan saldo invoice dengan akun Piutang dan saldo inventory ledger dengan akun Persediaan/Persediaan Dalam Penjualan.
  4. Verifikasi permission per role dan isolasi company.
  5. Pastikan folder uploads/accounting/sales dapat ditulis PHP tetapi eksekusi script diblokir oleh konfigurasi web server.

Rollback

Jangan menjalankan down() pada data transaksi aktif. Rollback yang aman adalah mengembalikan backup database dan source secara bersamaan. Dokumen yang sudah posted harus direversal melalui workflow, bukan dihapus manual.

Data yang perlu direkonsiliasi

  • Invoice lama tanpa company_id yang customer-nya ambigu.
  • Invoice dengan stock_posted_at tetapi tidak mempunyai inventory ledger yang sepadan.
  • Satu barcode legacy pada invoice_details.barcode_id yang belum tercermin pada relasi multi-barcode.
  • Pembayaran lama tanpa payment_sources atau bukti pembayaran.
  • Jurnal lama dengan keterangan atau ref_type/ref_id yang tidak lengkap.

Tambahan deployment editor invoice

Terapkan migration 20260907000500_finalize_invoice_editor setelah 20260907000400. Migration additive ini menambah idempotency/version header invoice, tipe dan idempotency baris invoice, indeks daftar/detail/pengelompokan Surat Jalan Draft, serta permission can_submit pada role terkait.

Lanjutkan dengan 20260907000600_finalize_sales_payment_permissions untuk memberi can_post penerimaan pelanggan kepada role Finance yang memang memiliki hak posting Kas/Bank, sekaligus menambah indeks riwayat pembayaran dan alokasi invoice.

Setelah migration:

  1. Jalankan php index.php salescheck.
  2. Minta pengguna logout/login agar snapshot permission session memuat can_submit terbaru.
  3. Uji alur singkat: buat header, tambah satu barang atau jasa, post Surat Jalan bila barang, ajukan, approve/post otomatis, lalu bayar dengan bukti.
  4. Jangan mengaktifkan kembali mutasi legacy Invoices::save/add_item/delete_item/bayar.