# DOKUMEN SERAH TERIMA (HANDOVER)
## Perbaikan Validasi Closing Project & Pelacakan Kausalitas Pembagian Termin

Dokumen ini disusun sebagai panduan untuk melanjutkan pekerjaan di komputer lain. Dokumen ini merangkum apa yang sudah diselesaikan, akar masalah konseptual, dan langkah berikutnya untuk memperbaiki hulu data (*Genesis*).

---

## 1. Status Terakhir & Perbaikan yang Sudah Selesai
Masalah penutupan proyek yang terblokir oleh selisih **Rp 1** (akibat pembulatan pecahan desimal) telah diselesaikan untuk transaksi berjalan (*legacy*).

### Perubahan yang Dilakukan
* **Berkas:** `application/modules/master_project/views/transaksi.php`
* **Metode Perbaikan:** Menerapkan batas toleransi materialitas (`$toleranceDpp = 100`) pada logika penonaktifan tombol *Terbitkan* (DP, Termin, dan Retensi).
* **Detail Kode yang Diubah (terdapat di 3 lokasi: baris 6986, 9304, dan 11527):**
  ```php
  // SEBELUM:
  $btnDpDisabled = $dpReadyToBill > 0 ? "" : "disabled";
  $btnTerminDisabled = $terminReadyToBill > 0 ? "" : "disabled";
  $btnRetensiDisabled = $retensiReadyToBill > 0 ? "" : "disabled";

  // SESUDAH (Dikombinasikan dengan Jurnal Penyesuaian Otomatis):
  // START OF COMPLETE REPEATED LOGIC
  $btnDpDisabled = $dpReadyToBill > $toleranceDpp ? "" : "disabled";
  $btnTerminDisabled = $terminReadyToBill > $toleranceDpp ? "" : "disabled";
  $btnRetensiDisabled = $retensiReadyToBill > $toleranceDpp ? "" : "disabled";
  // END OF COMPLETE REPEATED LOGIC
  ```
* **Hasil:** Jika sisa saldo berada di bawah Rp 100 (misalnya selisih Rp 1), tombol penagihan otomatis didefinisikan sebagai `disabled` oleh sistem. Dengan demikian, validasi JavaScript `pendingTerbit` pada fungsi `getReconClosingIssue()` bernilai `0` dan **closing proyek tidak lagi terblokir**.

---

## 2. Analisis Akar Masalah Konseptual (Genesis)
Meskipun transaksi *legacy* sudah aman, kita perlu membenahi hulu data agar transaksi baru di masa depan terbebas dari pecahan desimal desimal secara alami.

### Alur Kausalitas Pembagian Termin
1. Modul **`penerimaanprojek`** (yang menerbitkan invoice termin) **tidak menghitung atau membagi termin secara mandiri**.
2. Modul ini hanya menyalin/mewarisi array **`items3`** dari berkas **registry** milik transaksi induk (Sales Order / SO).
   * Ditemukan di berkas: `penerimaanprojek/controllers/_processSelectNota.php` baris 321:
     ```php
     $_SESSION[$cCode]['items3'] = $items3Registries; // disalin dari registry induk
     ```
3. Sumber pertama masalah (*Genesis*) adalah **bagaimana nominal termin pertama kali dihitung dan disimpan ke registry di modul hulu** (modul penjualan atau budgeting proyek). Sistem saat ini menghitung per termin secara independen berdasarkan persentase mentah, bukan menggunakan sisa akumulatif.

---

## 3. Langkah Berikutnya (Rencana Kerja Komputer Lain)
Untuk membersihkan data pecahan desimal sejak lahir (*Genesis*):

1. **Telusuri Penciptaan Registry `items3` di Hulu:**
   Temukan berkas pembuat registry SO/Budgeting di modul penjualan atau master proyek (kemungkinan di `Create::save()` atau saat penentuan termin kontrak).
2. **Terapkan Logika Pembagian Sisa Akumulatif (Accumulative Residual):**
   Ubah logika perhitungan termin agar termin terakhir tidak menggunakan persentase, melainkan sisa dari pengurangan:
   $$\text{Termin Terakhir} = \text{Total Nilai Proyek} - \sum(\text{Termin-Termin Sebelumnya yang Sudah Bulat})$$
3. **Simpan sebagai Integer/Decimal Bulat:**
   Pastikan nilai hasil kalkulasi di-`round()` ke Rupiah bulat sebelum disimpan ke `transaksi_registry`.

---
*Dokumen ini disimpan di folder Artifacts proyek untuk akses cepat.*