# Finalisasi Penjualan dan Invoice

## Arsitektur final

`SalesService` adalah sumber tunggal transaksi baru untuk invoice, reservasi barcode, Surat Jalan, posting stok, posting invoice, penerimaan pembayaran, pengakuan pendapatan, dan retur penjualan. `Sales` hanya menangani HTTP, permission, upload, JSON, dan PDF. Halaman lama Draft/Riwayat Invoice diarahkan ke workspace `sales`; penerimaan dari halaman Piutang juga memanggil `SalesService`.

## Alur

Penawaran tidak membuat jurnal atau stok. Penawaran yang diterima dapat dikonversi idempotent menjadi Sales Order. Sales Order diterima menjadi sumber invoice, tetapi gudang dan barcode tetap diverifikasi ulang.

Invoice mendukung `one_time` dan `running`. Baris yang ditambahkan ke Draft membuat Surat Jalan Draft dan mereservasi barcode. Invoice berjalan dapat ditambah lintas tanggal selama masih Draft. Surat Jalan posted mengurangi stok tepat sekali dan menjurnal Persediaan Dalam Penjualan terhadap Persediaan. Setelah semua pengiriman posted, invoice diajukan. Approval terakhir otomatis memposting invoice; tidak ada tombol Post kedua.

Metode Akrual mengakui pendapatan dan HPP saat invoice posted. Metode Setelah Pembayaran menampung nilai bersih pada Pendapatan Ditangguhkan, lalu mengakui pendapatan dan HPP secara proporsional pada setiap alokasi pembayaran. Ledger pengakuan memakai idempotency key.

Pembayaran dapat dialokasikan ke beberapa invoice dan berasal dari beberapa akun Kas/Bank. Kelebihan wajib menjadi uang muka. Bukti gambar/PDF wajib. Receipt tersedia sebagai PDF inline.

Retur memvalidasi dokumen pengiriman, barcode, dan saldo qty yang pernah dikirim. Workflow-nya Draft → Diajukan → Disetujui → Diterima/Diperiksa → Posted/Selesai. Posting menghasilkan jejak barcode, inventory ledger, stock log, item movement, credit note, dan jurnal tanpa membalik seluruh invoice.

## Dokumen dan laporan

Invoice PDF memisahkan halaman ringkasan dengan lampiran barcode. Surat Jalan, Retur, dan Bukti Penerimaan mempunyai PDF inline. Laporan Profesional menyediakan rekap penjualan, per customer, barang, barcode, invoice berjalan, retur, pengakuan pendapatan, Surat Jalan belum ditagihkan, serta rekonsiliasi piutang.

## Mapping akun

Tidak ada ID akun hardcoded. Mapping yang digunakan: `accounts_receivable`, `goods_revenue`, `deferred_revenue`, `inventory`, `inventory_in_sales`, `cost_of_goods_sold`, `sales_tax_payable`, dan `customer_advances`.

## Kompatibilitas legacy

Kolom legacy seperti `invoice_details.barcode_id` tetap dipertahankan. Transaksi lama tetap dapat dibaca. Data baru menggunakan `invoice_line_barcodes`, `sales_delivery_barcodes`, serta `revenue_recognition_ledger`. Invoice legacy yang pernah memposting stok langsung perlu direkonsiliasi sebelum dipindahkan ke workflow baru; sistem tidak membuat ulang ledger tersebut secara otomatis.

## Finalisasi editor 7 September 2026

- `Invoices` adalah controller utama daftar dan editor invoice melalui `/invoices`, `/invoices/create`, `/invoices/edit/{id}`, dan `/invoices/detail/{id}`.
- `SalesService` tetap menjadi pusat business logic. `Sales` menangani ringkasan, pengiriman, retur, upload, dan PDF; `Receivables` menangani UI pembayaran tetapi memposting melalui `SalesService`.
- Header disimpan lebih dahulu sebagai Draft. Barang/jasa kemudian ditambahkan satu per satu dan langsung tersimpan sehingga invoice akumulasi dapat dilanjutkan pada hari berikutnya.
- Baris persediaan hanya mereservasi barcode saat Draft. Stok fisik berkurang hanya ketika Surat Jalan diposting. Baris jasa tidak membuat Surat Jalan, stock log, inventory ledger, item movement, atau HPP.
- Daftar invoice/item memakai server-side pagination. Lookup customer, akun pendapatan, barang, gudang, barcode, dan Kas/Bank memakai AJAX pagination.
- Pembayaran customer memakai satu proses multi-invoice, multi-akun Kas/Bank, bukti wajib, uang muka terkontrol, receipt PDF, dan jurnal otomatis.
- Menu aktif disederhanakan. Data Penawaran/Sales Order tidak dihapus; navigasinya disembunyikan sampai dibutuhkan kembali.