# BLUEPRINT ARSITEKTUR & ROADMAP PERBAIKAN EDIT SETTING RAB **Proyek:** ERP Everest History **Modul Terdampak:** `master_project`, `penerimaanprojek`, `distribusifgproject`, `spk` **Status:** Draf Desain & Roadmap Implementasi Bertahap **Tanggal:** 25 September 2026 --- ## 1. Latar Belakang & Kasus Ekstrem Fitur **Edit Setting RAB** pada modul `master_project` (`MasterData/index/{project_id}`) berfungsi untuk melakukan penyesuaian rincian teknis (spesifikasi, material, volume/qty, dan harga) pada proyek yang sudah berjalan. ### Simulasi Kasus Ekstrem: Kenaikan QTY 2x Lipat (50 Unit $\rightarrow$ 100 Unit) * **Kondisi Awal**: - Material AC: Qty 50 unit @ Rp 22.830.000 (Harga Jual) & Rp 22.162.169 (Budget HPP). - Subtotal Jual: Rp 1.141.500.000 | Subtotal Budget: Rp 1.108.108.450. - Realisasi SPK lapangan: Sudah terbit SPK untuk 50 unit (`used = 50`, sisa kuota = 0). * **Perubahan Ekstrem**: - Qty dinaikkan menjadi 100 unit. - Subtotal Jual Baru: Rp 2.283.000.000 (+Rp 1.141.500.000). - Subtotal Budget Baru: Rp 2.216.216.900 (+Rp 1.108.108.450). - Sisa Kuota Baru: `100 - 50 = 50 unit` siap dialokasikan ke SPK baru. Pertanyaan krusial: **Kemana saja efek dari perubahan ini menjalar, dan tabel/sistem apa saja yang WAJIB diperbarui?** --- ## 2. Analisis Efek Rantai Sistem (Cascading Impacts) Kenaikan Qty material di RAB tidak berdiri sendiri, melainkan berdampak langsung pada 6 layer arsitektur: ``` [ LAYER 1: Master RAB & Komposisi Workorder ] │ (project_komposisi_workoder, project_komposisi_sub_workoder 5582, project_produk) ▼ [ LAYER 2: Kontrak Penjualan / SO Induk ] │ (transaksi 749, transaksi_detail, transaksi_data_registry) ▼ [ LAYER 3: Penagihan / Modul Penerimaan Projek ] │ (penerimaanprojek 7499, alokasi items3 Termin vs items4 DP vs items5 Retensi) ▼ [ LAYER 4: Operasional & SPK (Work Order) ] │ (sisa kuota material bertambah, penerbitan SPK tambahan untuk 50 unit baru) ▼ [ LAYER 5: Gudang & Logistik ] │ (reservasi stok & pengeluaran material SPPB via distribusifgproject) ▼ [ LAYER 6: Akuntansi & Progress Monitoring ] (dilusi persentase progres fisik/keuangan & rekalkulasi margin laba/rugi) ``` --- ### Layer 1: Master RAB & Komposisi Work Order * **Tabel `project_komposisi_workoder`**: * Baris item material yang diedit wajib diperbarui: * `jml` = 100 (kuota total baru). * `debet` & `saldo` = $100 \times \text{harga jual}$ (Rp 2.283.000.000). * `debet_budget` & `saldo_budget` = $100 \times \text{harga budget}$ (Rp 2.216.216.900). * `sub_hpp` = $100 \times \text{hpp live/snapshot}$. * `qty_debet` & `qty_saldo` = disesuaikan dengan kuota baru. * `last_update` = waktu update terkini. * **Tabel `project_komposisi_sub_workoder` (jenis_transaksi = '5582')**: * Master breakdown sub-komposisi BOM wajib disinkronkan agar data preview dan detail teknis konsisten. * **Tabel `project_produk` (Header Proyek)**: * Kolom `harga` (nilai proyek tanpa pajak): Jika ini adendum kenaikan nilai proyek, total nilai proyek harus naik sesuai kenaikan rincian item. * Kolom `subtotal` & snapshot summary proyek. --- ### Layer 2: Kontrak Penjualan & Order Induk (`transaksi` 749) * **Tabel `transaksi` (jenis = '749' - SPK Kontrak Project)**: * Nilai kontrak induk (`transaksi_nilai`, `transaksi_dpp`, `transaksi_ppn`, `transaksi_total`) harus diselaraskan. * Jika nilai kontrak tidak diupdate, maka terjadi diskrepansi antara rincian RAB (Rp 2,28 M) dengan kontrak legal di sistem (masih Rp 1,14 M). * **Tabel `transaksi_detail`**: * Baris item project disesuaikan kuantitas/nilainya. * **Tabel `transaksi_data_registry` (`main`)**: * Snapshot data kontrak awal yang di-serialize harus diperbarui agar modul-modul turunan membaca angka terbaru. --- ### Layer 3: Penagihan / Modul `penerimaanprojek` (DP, Termin, Retensi) * **Pemisahan Alokasi Wadah Pembayaran**: * **DP (`items4`)**: Kuota DP yang telah disepakati/diterbitkan di awal **TETAP AMAN & TIDAK BERUBAH**. * **Retensi (`items5`)**: Biasanya dihitung persentase (misal 5%) di akhir penyerahan proyek. * **Termin (`items3`)**: * Penambahan nilai Rp 1.141.500.000 **WAJIB DIALOKASIKAN KE POS TERMIN**. * Di `penerimaanprojek/controllers/Create.php`, fungsi `validateProjectTypePaymentQuota()` membatasi penerbitan tagihan termin maksimal sebesar total alokasi `items3` di session/kontrak. * **Jika alokasi Termin tidak ditambah**: Bagian keuangan akan diblokir sistem (*"Penerbitan TERMIN melebihi alokasi"*) saat mencoba menagih sisa 50 unit tambahan tersebut ke konsumen! * **Solusi**: Dibuatkan baris jadwal pembayaran baru (misal *Termin 4 - Pekerjaan Tambah / Addendum Material*) pada daftar alokasi termin. --- ### Layer 4: Operasional & SPK (Work Order) * **Status Pemakaian Material (`$used`)**: * Nilai `$used` (50 unit) dihitung dari SPK yang sudah terbit di `project_komposisi_sub_workoder` (`jenis_transaksi = 'sub_wo'`). * SPK lama yang sedang berjalan atau sudah selesai **TIDAK BOLEH DIRUBAH** riwayatnya. * Kenaikan Qty dari 50 ke 100 secara otomatis menghasilkan **Sisa Kuota = 50 unit**. * Kuota 50 unit ini otomatis tersedia untuk diterbitkan ke dalam: * SPK Baru (Fase berjalan atau Fase baru), atau * Penambahan alokasi pada SPK berikutnya. --- ### Layer 5: Logistik, Gudang, & Stok * **Pengeluaran Fisik Barang**: * Stok gudang tidak langsung dipotong saat Edit RAB disimpan. * Pemotongan stok terjadi saat SPK 50 unit baru tersebut diterbitkan menjadi SPPB (Surat Perintah Pengeluaran Barang) dan diproses melalui modul `distribusifgproject`. * **Ketersediaan Stok**: * Penambahan 50 unit AC menuntut pengecekan ketersediaan stok fisik / pemesanan ke supplier (PO Auto-purchase). --- ### Layer 6: Akuntansi, HPP, & Progres Proyek * **Dilusi Persentase Progres Fisik**: * Di `MasterData.php` fungsi `recalculateProgressProject($produk_id)`: $$\text{Progres (\%)} = \frac{\text{Total Realisasi Biaya \& Material}}{\text{Total Nilai Proyek}} \times 100\%$$ * Jika nilai proyek (penyebut) naik 2x lipat sementara fisik di lapangan baru selesai 50 unit lama, maka **angka progres proyek otomatis terkoreksi turun (terdilusi)**. * Contoh: Dari 100% (50/50 unit) menjadi 50% (50/100 unit). Ini mencerminkan status riil bahwa ada 50 unit baru yang belum dikerjakan. * **Margin Laba/Rugi (Profit Margin)**: * Pada `showSummaryProject()`, total budget bertambah Rp 1,10 M, total jual bertambah Rp 1,14 M. * Estimasi laba nominal bertambah $+Rp\ 33.391.550$, dan kalkulasi R/L otomatis ter-refresh. --- ## 3. Checklist Master Perbaikan Bertahap (7 Tahap End-to-End) Agar penanganan amandemen proyek / Edit Setting RAB aman secara menyeluruh dan tidak ada yang tertinggal dari hulu ke hilir, pekerjaan dibagi menjadi **7 Tahap Terstruktur**: ### [x] TAHAP 1: Level Master RAB & UI (Fondasi Data & Guardrail Pemakaian Lapangan) - SELESAI - [x] **1.1. Backend `update_qty()` di `MasterData.php`**: Mengisi fungsi di baris 31663 yang saat ini sudah aktif dan terintegrasi transaksi DB atomik. - [x] **1.2. 3-Way Matching Guardrail (Fail-Fast)**: Validasi batas bawah input Qty terhadap `$used` dari `MdlProdukProject::getRekapKomposisi()` dan `project_komposisi_sub_workoder` (`sub_wo`). - [x] **1.3. Rekalkulasi Nilai Finansial Baris**: Hitung ulang `debet` & `saldo` ($new\_qty \times jual$), `debet_budget` & `saldo_budget` ($new\_qty \times budget$), `sub_hpp` ($new\_qty \times hpp$), `qty_debet`, dan `qty_saldo` ($new\_qty - used$). - [x] **1.4. Sinkronisasi Sub-BOM `5582`**: Helper `syncSubKomposisiQtyFromMain()` aktif menyelaraskan kuantitas dan nilai rincian breakdown. - [x] **1.5. Pembersihan UI Double Badge Kembar**: Duplikasi cetak badge `[used] : 2 [used] : 2` telah diperbaiki menjadi 1 badge rapi dengan tooltip jelas. - [x] **1.6. Respon JSON Standar**: Mengembalikan `{status: true, msg: '...', new_qty: ...}` untuk x-editable frontend. ### [x] TAHAP 2: Level Sales & Kontrak Induk (`588st` / `749`) - SELESAI - [x] **2.1. Sinkronisasi Header `project_produk`**: Perbarui kolom `harga` (nilai jual tanpa PPN), `tarif_ppn`, `ppn`, `harga_nppn`, dan snapshot summary proyek. - [x] **2.2. Sinkronisasi Kontrak Induk `588st`**: Perbarui data transaksi induk (`transaksi` jenis `749` / `project_start_id` dan `quot_id`): `transaksi_nilai`, `ppn_nilai`, dan `transaksi_net`. - [x] **2.3. Sinkronisasi `transaksi_detail`**: Sesuaikan baris item kontrak penjualan proyek (`transaksi_data` where `produk_id = 0`: `produk_ord_hrg`, `ppn`). - [x] **2.4. Sinkronisasi `transaksi_data_registry` (`main`)**: Perbarui snapshot JSON registry dengan perhitungan PPN dinamis (`$ppnFactor`), hilangkan pembagi statis `/ 1.11` pada `main`, `items3`, `items4`, `items5`, dan `items7`. ### [x] TAHAP 3: Level Penagihan Keuangan (`penerimaanprojek` - DP, Termin, Retensi) - SELESAI - [x] **3.1. Proteksi Immutability Uang Muka (DP)**: Kunci wadah DP (`items4` / `_key = 'dp'`) jika faktur sudah terbit atau lunas. Dilarang merusak atau membagi ulang DP yang sudah selesai. Nominal DP terkunci, persentase disesuaikan. - [x] **3.2. Alokasi Kenaikan Nilai ke Termin**: Salurkan 100% selisih kenaikan nilai jual (+Rp 1,14 M) murni ke wadah Termin (`items3`), baik dengan memperbesar kuota termin berjalan atau menerbitkan baris Termin Tambahan (*Termin Addendum (Pekerjaan Tambah)*). - [x] **3.3. Rekalkulasi Retensi (`items5`)**: Hitung persentase retensi dari total nilai proyek baru (jika retensi belum diproses kasir) atau kunci jika sudah pernah dicairkan. - [x] **3.4. Validasi Balancing Equation Check**: Pastikan $\text{Total Nilai Proyek} \equiv \text{DP} + \text{Termin} + \text{Retensi}$ sebelum transaksi disimpan, menyerap pembulatan sen ke termin terakhir. - [x] **3.5. Koreksi Rumus Saldo `transaksi_payment_source`**: Gunakan rumus aman `sisa = max(0, new_tagihan - terbayar)` dan `lunas = ($sisa <= 0 && $new_tagihan > 0) ? 1 : 0` (mencegah bug reset saldo terbayar menjadi nol). ### [x] TAHAP 4: Level Purchasing & Pengadaan Material (`pembelianfgproject` - PO 1466) - SELESAI - [x] **4.1. Perbaikan Bug Skip Autopurchase Pool**: Modifikasi di `MasterData.php` (`resendAutopurchasePool` & `syncAutopurchasePool`). Menghapus logic `continue;` yang men-skip item yang sudah ada di pool. - [x] **4.2. Mekanisme Delta Kebutuhan PO**: Menerapkan update kebutuhan: `qty_kebutuhan = new_qty`, `qty_sisa = max(0, new_qty - qty_po_terbit)`, status dinamis (`OPEN`/`PARTIAL`/`CLOSED`), dan trigger otomatis pada `update_qty()` agar kuota tambahan material langsung terbaca oleh tim Purchasing di Modul 1466. ### [x] TAHAP 5: Level Operasional Lapangan & Gudang (`distribusifgproject` - SPPB 5833 & SPK) - SELESAI - [x] **5.1. Proteksi Snapshot SPK Berjalan**: Kunci snapshot nominal `nilai_sub_fase` pada SPK lama (`FollowUp.php:5662`) agar bobot rupiah pekerjaan lama tidak terdilusi atau melambung; persentase bobot dihitung balik terhadap total kontrak baru. - [x] **5.2. Rilis Kuota Sisa Material Baru**: Penerbitan SPK berikutnya membaca sisa kuota baru (`qty_saldo = max(0, new_qty - used) = 50 unit`) untuk dialokasikan ke pelaksana lapangan. - [x] **5.3. Sinkronisasi Pengeluaran Gudang**: Modul `distribusifgproject` (SPPB 5833) memfilter & mengeluarkan barang murni berdasarkan kuota SPK yang diterbitkan (`jenis_transaksi='sub_wo'`). ### [x] TAHAP 6: Level Akuntansi & Buku Besar (`akunting` & `laporankeuangan`) - SELESAI - [x] **6.1. Penerbitan Jurnal Adendum Kontinjensi**: Menerbitkan jurnal komitmen tambahan (Debet: `1010070030` Piutang Kontinjensi vs Kredit: `4030` Penjualan Kontinjensi) sebesar selisih kenaikan kontrak (+Rp 1,14 M), mencegah akun kontinjensi defisit/minus saat seluruh termin ditagihkan. - [x] **6.2. Sinkronisasi Buku Pembantu Penjualan Proyek**: Update `_rek_pembantu_penjualan_project` untuk mencegah "fiktif rugi / cost overrun" pada laporan laba/rugi di `laporankeuangan` saat 50 unit baru dikeluarkan dari gudang. - [x] **6.3. Rekonsiliasi PPN Keluaran (`2030060`)**: Sinkronisasi kewajiban PPN 11% (+Rp 125,4 Juta) agar selaras dengan modul pelaporan pajak / e-Faktur. ### [x] TAHAP 7: Level Tata Kelola, Otorisasi, & Audit Trail - SELESAI - [x] **7.1. Reaktivasi Tiket Otorisasi BOM**: Tiket otorisasi BOM pada `getPendingBomRequest()` telah direaktivasi dari bypass `return null;` menjadi membaca request `state = 2`, dengan dukungan fleksibilitas bypass via konstanta `BYPASS_BOM_AUTHORIZATION`. - [x] **7.2. Logging Audit Trail**: Implementasi `logRabItemAuditTrail()` terintegrasi di 3 endpoint utama (`update_qty`, `update_harga`, `update_budget`) serta peningkatan `logKontrakHistory()` dengan pencatatan IP Address, User ID, Timestamp, Before/After, dan Selisih. --- ## 4. Mekanisme 3-Way Matching Pre-Update Guardrail Untuk memastikan integritas data tetap 100% terjaga dan tidak merusak transaksi yang sudah berjalan sebelum adendum dilakukan, setiap titik update wajib menjalankan **3-Way Matching (Pencocokan 3 Pilar)** sebelum query eksekusi dijalankan: ``` [ PILAR 1: PROPOSAL / RAB BARU ] • Qty / Harga Baru yang diinput di antarmuka • Usulan Total Nilai Proyek Baru • Rencana Pembagian Pos: DP, Termin, Retensi ▲ │ (3-Way Reconciliation Check) ▼ [ PILAR 2: KONTRAK AKTIF (588st) ] ◄════════► [ PILAR 3: REALISASI KASIR / ARUS KAS ] • Snapshot transaksi_data_registry • Riwayat transaksi_payment_source • items4 (Alokasi DP Kontrak) • Faktur DP yang sudah terbit / lunas • items3 (Alokasi Termin Kontrak) • Faktur Termin 1..n yang sudah cair • items5 (Alokasi Retensi Kontrak) • Retensi yang sudah dipotong • Jurnal Kontinjensi (Piutang vs Penjualan) • Transaksi penerimaan kasir (penerimaanprojek) ``` ### A. Matriks 3-Way Matching per Wadah Pembayaran | Pos Pembayaran | Yang Diperiksa (Pilar 2 & 3) | Aturan Guardrail (Fail-Fast Rule) | |---|---|---| | **1. Uang Muka (DP - `items4`)** | Cek tabel `transaksi_payment_source` (`_key = 'dp'`) dan modul `penerimaanprojek`: Apakah DP sudah terbit faktur / sudah dibayar konsumen? | • Jika DP sudah lunas/terbit: **NILAI DP DIKUNCI (IMMUTABLE)**.
• Nilai usulan baru **TIDAK BOLEH** lebih kecil dari nominal yang sudah dibayar.
• Adendum penambahan nilai dilarang mengubah pos DP yang sudah selesai. | | **2. Termin Fisik (`items3`)** | Cek tabel `transaksi_payment_source` (`_key = 'termin'`): Berapa total termin (Termin 1, 2, dst.) yang sudah diterbitkan faktur atau dicairkan kasir? | • Total alokasi Termin baru harus $\ge$ Total termin yang sudah terbit.
• Seluruh selisih penambahan nilai proyek (+Rp 1,14 M) **wajib dialokasikan ke pos Termin** (memperlebar sisa plafon atau membuat termin addendum). | | **3. Retensi (`items5`)** | Cek tabel `transaksi_payment_source` (`_key = 'retensi'`): Apakah ada retensi yang sudah diproses? | • Dihitung ulang dari nilai akhir proyek baru (misal 5% dari total baru), dengan syarat belum ada pencairan retensi mendahului. | ### B. Persamaan Keseimbangan Neraca (Balancing Equation Check) Sebelum commit ke database, sistem memvalidasi kesetaraan total: $$\text{Total Nilai Proyek Baru} \equiv \sum \text{Alokasi DP Baru} + \sum \text{Alokasi Termin Baru} + \sum \text{Alokasi Retensi Baru}$$ * Jika terjadi selisih $\neq 0$, sistem membatalkan proses dengan pesan: `"Pembaruan Gagal: Total alokasi (DP + Termin + Retensi) tidak seimbang dengan Total Nilai Proyek (Selisih: Rp X)"` ### C. 3-Way Matching pada Sisi Material & Biaya Pola 3-Way Matching yang sama juga diterapkan pada komponen fisik dan pengeluaran: 1. **Material:** $$\text{Qty RAB Baru} \ge \text{Qty SPK (Used)} \ge \text{Qty Pengeluaran Fisik (SPPB / Distribusi)}$$ 2. **Biaya & Subkon:** $$\text{Koreksi Budget Biaya} \rightarrow \text{Cek apakah voucher biaya (3674) sudah dicairkan Kasir?}$$ * Jika kasir sudah mencairkan dana $\rightarrow$ **Tolak koreksi budget** (sebagaimana pola guardrail di `MasterData.php` baris 35147). --- ## 5. Peta Ekosistem Hulu-ke-Hilir (10 Modul Terkait `master_project`) Modul `master_project` bertindak sebagai **jantung operasional proyek (Central Hub)** yang terhubung langsung ke **10 modul spesifik** di 5 domain bisnis: ``` ┌─────────────────────────────┐ │ penjualanproject │ (Quotation & Sales Order 588) └──────────────┬──────────────┘ ▼ ┌────────────────────────────────────────────────────────────────────────────────────────┐ │ MASTER_PROJECT │ │ • Master Proyek (project_produk) • Tasklist / SPK Lapangan (project_tasklist) │ │ • Master RAB (project_komposisi_workoder) • Realisasi Fisik (project_sub_tasklist) │ └───────┬───────────────────────────────┬───────────────────────────────┬────────────────┘ │ │ │ ▼ (Pengadaan Material & Jasa) ▼ (Logistik Fisik Lapangan) ▼ (Penagihan Kasir) ┌───────────────────────────────┐┌──────────────────────────────┐┌───────────────────────┐ │ • pembelianfgproject (1466) ││ • distribusifgproject (5833) ││ • penerimaanprojek │ │ (PO Unit/Material FG Proyek)││ (Kirim FG ke Pelaksana SPK)││ (Termin/DP/Retensi │ │ • pembelianprojek (3463) ││ • distribusisuppliesproject ││ 7499) │ │ (PO Jasa & Subkontraktor) ││ (Kirim Alat/Bahan 5834) ││ • umproject (4468) │ └───────────────────────────────┘└──────────────────────────────┘│ (Tagihan Uang Muka) │ └───────────┬───────────┘ ┌────────────────────────────────────────────────────────────────────┘ ▼ (Biaya Lapangan & Akuntansi) ┌────────────────────────────────────────────────────────────────────────┐ │ • biaya / kas : Voucher operasional lapangan (3674) │ │ • akunting : Jurnal Kontinjensi (1010070030 vs 4030) & HPP │ │ • laporankeuangan : Rekap Laba/Rugi & Buku Pembantu Proyek │ │ • pembatalan : Rollback/Voiding voucher & SPK proyek (9911) │ └────────────────────────────────────────────────────────────────────────┘ ``` ### Tabel Rincian 10 Modul Terkait | No | Nama Modul | Kode Transaksi | Hubungan & Data yang Dipertukarkan dengan `master_project` | |---|---|---|---| | **1** | **`penjualanproject`** | `588` (`588spo`, `588so`) | **Pintu Masuk Penawaran**: Menangani penawaran awal (Step 1 Quotation) dan persetujuan SO (Step 2). Saat disetujui, modul inilah yang men-generate baris awal RAB `project_komposisi_workoder`. | | **2** | **`penerimaanprojek`** | `7499` (Target `749`) | **Penagihan Piutang Proyek**: Mengambil kuota dari `transaksi_payment_source` yang diinisiasi oleh `master_project` saat kick-off (`588st`). Menangani tagihan **DP**, **Termin**, dan **Retensi**. | | **3** | **`umproject`** | `4468` | **Khusus Uang Muka (DP)**: Menangani penagihan uang muka proyek sebelum pekerjaan fisik dimulai, membaca data langsung dari `MdlProdukProject` (`quot_status = 1`). | | **4** | **`pembelianfgproject`** | `1466` | **Pengadaan Material FG**: Mengambil kebutuhan unit dari `project_purchase_pool` yang didaftarkan otomatis saat `master_project` melakukan kick-off (`588st`). | | **5** | **`pembelianprojek`** | `3463` | **Pengadaan Jasa / Subkon**: Menangani kontrak kerja subkontraktor dan sewa alat sesuai budget biaya di komposisi RAB proyek. | | **6** | **`distribusifgproject`** | `5833` | **Pengeluaran Material Gudang**: Mengeluarkan material fisik (dengan scan serial/barcode) ke tim pelaksana lapangan berdasarkan SPK yang diterbitkan dari `master_project`. | | **7** | **`distribusisuppliesproject`** | `5834` | **Pengeluaran Bahan Pembantu**: Mengeluarkan perlengkapan instalasi, kabel, pipa, dan supplies kerja berdasarkan SPK. | | **8** | **`biaya` / `kas`** | `3674` | **Voucher Kas Lapangan**: Menangani pencairan kas operasional/reimburse pekerjaan proyek. Jika voucher sudah dicairkan kasir, budget di `master_project` terkunci otomatis. | | **9** | **`akunting`** | Otomatis via Component | **Buku Besar & Jurnal**: Mencatat Jurnal Kontinjensi saat proyek dimulai (`588st`: Piutang Kontinjensi `1010070030` vs Penjualan Kontinjensi `4030`), serta mutasi HPP dan pendapatan saat serah terima. | | **10** | **`laporankeuangan`** | Reporting | **Monitoring Profitabilitas**: Menampilkan Laporan Laba/Rugi per Proyek, Buku Pembantu Piutang Konsumen per Proyek, dan evaluasi realisasi vs budget. | --- ## 6. Analisis Dampak Mendalam pada Akuntansi & Buku Besar Setiap perubahan nilai kontrak pada Edit Setting RAB memiliki efek domino terhadap 4 pos akuntansi utama: ### A. Saldo Akun Kontinjensi Menjadi MINUS / DEFISIT di Buku Besar * **Mekanisme Normal:** 1. Saat proyek Kick-off (`588st` di `master_project`), sistem menerbitkan **Jurnal Kontinjensi (Komitmen Kontrak)**: * **(D) 1010070030** (Piutang Usaha Kontinjensi) = Rp 2.000.000.000 * **(K) 4030** (Penjualan Kontinjensi) = Rp 2.000.000.000 2. Saat termin ditagihkan (`7499` di `penerimaanprojek`), sistem **membalik (reverse)** jurnal kontinjensi tersebut secara bertahap seiring terbitnya tagihan definitif: * **(K) 1010070030** (Membalik Piutang Kontinjensi) = Sebesar nilai termin * **(D) 4030** (Membalik Penjualan Kontinjensi) = Sebesar nilai termin * *(Lalu mengakui Piutang Riil `1010020010` dan Penjualan Riil `4010`)*. * **Risiko Fatal Saat Edit RAB:** Jika nilai proyek dinaikkan dari Rp 2 Miliar menjadi **Rp 3,14 Miliar** (+Rp 1,14 M), namun jurnal kontinjensi `588st` tidak disesuaikan: Ketika kasir menagihkan seluruh termin hingga lunas Rp 3,14 Miliar, modul `penerimaanprojek` akan membalik akun kontinjensi sebesar Rp 3,14 Miliar! Akibatnya: Akun Piutang Kontinjensi dan Penjualan Kontinjensi di Buku Besar akan **MINUS / DEFISIT (-Rp 1.140.000.000)** karena di awal hanya dicatat Rp 2 Miliar tetapi dibalik Rp 3,14 Miliar. * **Solusi Akuntansi:** Saat amandemen nilai proyek disetujui, sistem wajib menerbitkan **Jurnal Adendum Kontinjensi**: * **(D) 1010070030** = +Rp 1.140.000.000 * **(K) 4030** = +Rp 1.140.000.000 *(Sehingga saldo akun kontinjensi pas kembali ke Rp 0 saat seluruh termin baru lunas).* ### B. Distorsi Laba/Rugi Menjadi "FIKTIF RUGI / COST OVERRUN" * Kenaikan Qty material (+50 unit) otomatis menaikkan pengeluaran fisik barang di `distribusifgproject` dan menambah beban HPP Realisasi proyek (+Rp 1,10 Miliar). * Jika penambahan nilai kontrak (+Rp 1,14 Miliar) tidak disinkronkan ke Buku Pembantu Penjualan Proyek (`RekeningPembantuPenjualanProject`), laporan profitabilitas proyek di `laporankeuangan` membaca seolah-olah biaya membengkak tanpa ada kenaikan pendapatan, sehingga proyek **terlihat merugi / boncos secara akuntansi**. ### C. Kerusakan Rekonsiliasi Kewajiban Uang Muka Konsumen (`2010050`) * Uang Muka yang sudah disetor konsumen dicatat sebagai kewajiban lancar: **(K) 2010050** (Uang Muka Konsumen). * Jika persentase DP dihitung ulang dari nilai total baru, sistem akan mencoba membalik akun `2010050` melebihi uang kas riil yang pernah masuk ke bank, memicu selisih neraca audit (*unbalanced audit trail*). ### D. Diskrepansi Pajak PPN Keluaran (`2030060`) & Faktur Pajak * Penambahan nilai jual Rp 1,14 Miliar membawa kewajiban penambahan **PPN Keluaran (11%) sebesar Rp 125,4 Juta**. * Tanpa sinkronisasi kontrak induk, bagian perpajakan/akuntansi akan kesulitan merekonsiliasi antara e-Faktur Pajak fisik dengan nilai kontrak sistem. --- ## 7. Keputusan Arsitektur: Penempatan Menu Amandemen (Model Hybrid) > **STATUS**: ✅ Disetujui oleh Developer pada 25 September 2026 ### A. Keputusan Penempatan menu-menu amandemen proyek menggunakan **Model Hybrid (Dashboard Terpusat + Eksekusi Terdistribusi)**: ``` ┌─────────────────────────────────────────────────────────────────────┐ │ MASTER_PROJECT (Command Center) │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ DASHBOARD AMANDEMEN PROYEK (Halaman Baru) │ │ │ │ • Ringkasan status amandemen aktif per proyek │ │ │ │ • Daftar 6 titik amandemen dengan status masing-masing │ │ │ │ • Tombol navigasi ke modul eksekusi terkait │ │ │ │ • Riwayat audit trail delta semua amandemen │ │ │ └──────────┬────────────┬────────────┬──────────────────────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌──────────────┐ ┌──────────┐ ┌───────────────┐ │ │ │ Edit RAB │ │ Edit SO │ │ Edit Purchase │ ← Eksekusi di │ │ │ (Tahap 1 ✅) │ │ Kontrak │ │ Pool │ modul existing │ │ │ master_proj │ │ 588st │ │ pembelianfg │ │ │ └──────────────┘ └──────────┘ └───────────────┘ │ │ ┌────────────┐ ┌───────────────┐ ┌─────────────┐ │ │ │ Edit Termin│ │ Edit Alokasi │ │ Edit Jadwal │ │ │ │ penerimaan │ │ distribusifg │ │ Milestone │ │ │ │ projek │ │ project │ │ master_proj │ │ │ └────────────┘ └───────────────┘ └─────────────┘ │ └─────────────────────────────────────────────────────────────────────┘ ``` ### B. Alasan Pemilihan Model Hybrid 1. **Tidak perlu membuat modul baru**: Cukup tambah 1 halaman dashboard + endpoint di `master_project`. 2. **Menghindari duplikasi logika**: Eksekusi perubahan tetap dijalankan oleh modul yang sudah memiliki business logic tersebut. 3. **User Experience optimal**: Pengguna memiliki 1 pintu masuk (dashboard) untuk melihat semua status amandemen, dengan navigasi langsung ke modul yang tepat. 4. **Audit Trail terpusat**: Semua riwayat perubahan dicatat di satu tempat (`project_amendments` / log amandemen) meskipun eksekusi terjadi di modul berbeda. ### C. Komponen Dashboard yang Akan Dibangun | Komponen | Lokasi | Deskripsi | |---|---|---| | `showAmendmentDashboard()` | `MasterData.php` | Halaman utama dashboard amandemen per proyek | | `getAmendmentSummary()` | `MdlProdukProject.php` | Query ringkasan status 6 titik amandemen | | `createAmendmentLog()` | Model baru `ComAmendmentLog` | Pencatatan audit trail delta ke MongoDB | | Tabel `project_amendments` | MySQL | Header ringkasan pengajuan amandemen | | Tabel `project_amendment_details` | MySQL | Detail delta tracking (before/after) | --- ## 8. Standar Amandemen Enterprise: Pemetaan 6 Titik Amandemen vs Codebase Everest Merujuk pada dokumen standar arsitektur amandemen industri trading & instalasi AC enterprise ([`PANDUAN_LENGKAP_AMANDEMEN_PROJECT.MD`](file:///z:/everest_history/PANDUAN_LENGKAP_AMANDEMEN_PROJECT.MD)), proses amandemen mencakup 6 pilar yang saling terhubung dengan modul-modul riil di ERP Everest: | No | Titik Amandemen (Panduan Enterprise) | Entitas & Modul Riil Codebase Everest | Mekanisme & Dampak Teknis di Sistem | |---|---|---|---| | **1** | **Amandemen RAB / WBS**
*(Spesifikasi AC, volume pipa tembaga, material pendukung, target profit)* | `master_project`
• `project_komposisi_workoder`
• `project_komposisi_sub_workoder` (`5582`) | • Validasi inline edit `update_qty()` (Tahap 1 - Selesai), `update_harga()`, dan `update_budget()`.
• Sinkronisasi otomatis ke master sub-komposisi BOM via `syncSubKomposisiQtyFromMain()`.
• Rekalkulasi estimasi laba/rugi dan margin via `reloadSummaryProject()`. | | **2** | **Amandemen SO & Kontrak**
*(Change Order developer, skema termin DP, progres, retensi)* | `penjualanproject` (`588`), `master_project` (`588st`/`749`), `penerimaanprojek` (`7499`) | • Update header `project_produk.harga` dan transaksi induk `transaksi` (749).
• Pembaruan snapshot kontrak `transaksi_data_registry` (`main`).
• Penyaluran seluruh selisih kenaikan kontrak ke wadah Termin (`items3`) tanpa merusak DP (`items4`). | | **3** | **Amandemen PO Supplier**
*(Kuota inden Daikin/Panasonic, project price prinsipal, substitusi SKU)* | `pembelianfgproject` (`1466`), `project_purchase_pool` | • Pembaruan tabel `project_purchase_pool` melalui perbaikan fungsi `resendAutopurchasePool()`.
• Menghapus bug `continue;` agar sisa kebutuhan 50 unit baru langsung terbaca oleh tim Purchasing untuk penerbitan PO Supplier baru. | | **4** | **Amandemen Alokasi Barang**
*(Stock reservation, alih unit antar-proyek, pelepasan ke retail)* | `distribusifgproject` (`5833`), `ComLockerStockDualWrite` | • Sisa kuota baru (`new_qty - used`) otomatis tersedia untuk penerbitan SPK baru.
• Reservasi dan pengeluaran fisik gudang (SPPB) dikunci oleh kuota SPK aktif.
• Integrasi dual-write stock locker untuk mencegah alokasi ganda unit AC di gudang. | | **5** | **Amandemen Kontrak Subkon**
*(Tarif teknisi luar per titik, bobokan dinding/plafon tak terduga)* | `project_tasklist`, `pembelianprojek` (`3463`), `biaya`/`kas` (`3674`) | • Koreksi budget biaya jasa induk & rincian sub-komponen via fitur Dual-Level Koreksi Budget.
• Rekalkulasi proporsional `nilai_sub_fase` SPK.
• Pembatalan resmi (9911) voucher lama dan posting ulang voucher 3674 baru. | | **6** | **Amandemen Jadwal & Milestone**
*(Mobilisasi unit & instalasi fisik bangunan rumah mewah)* | `project_produk` (`end_dtime`), `project_tasklist`, `penerimaanprojek` | • Pembaruan tenggat waktu (`end_dtime`) dan timeline tasklist proyek.
• Sinkronisasi tanggal jatuh tempo penagihan termin konsumen dengan progres fisik lapangan. | --- ## 9. Kepatuhan Standar Mutu ISO 9001:2015 & Regulasi Perpajakan Indonesia Untuk memenuhi kepatuhan tata kelola perusahaan enterprise, implementasi amandemen pada ERP Everest mengadopsi standar internasional dan regulasi perpajakan DJP Indonesia: ### A. Standar ISO 9001:2015 (Sistem Manajemen Mutu) 1. **Klausul 8.2.4 (Perubahan Persyaratan Produk & Layanan)**: - Ketika spesifikasi atau kuantitas material AC diubah pada menu Edit Setting RAB, spesifikasi baru tersebut **secara otomatis terdistribusi**: * Ke Modul Pembelian (`pembelianfgproject` / `project_purchase_pool`) agar tim Purchasing tidak salah memesan tipe unit ke pabrik/prinsipal. * Ke Modul Gudang (`distribusifgproject`) agar staf gudang hanya mengeluarkan barang sesuai revisi SPK yang sah. 2. **Klausul 7.5 (Informasi Terdokumentasi & Versioning Cetak)**: - Setiap cetakan dokumen proyek (Surat Perintah Kerja, Surat Jalan SPPB, Layout Plan, Invoice) wajib mencantumkan **Kode Versi Revisi Dokumen** (misal: `PRJ-2026-001 Rev 2.0`) beserta stempel tanggal update terkini (`last_update`). - Hal ini mencegah tim teknisi/instalator di lapangan perumahan memasang pipa atau AC berdasarkan cetakan dokumen versi lama yang sudah kedaluwarsa (*superseded*). ### B. Regulasi Perpajakan Indonesia (UU Harmonisasi Peraturan Perpajakan / UU HPP) 1. **Tata Kelola PPN 11% & e-Faktur Pajak**: - **Kasus Amandemen SEBELUM Faktur Pajak Terbit**: Nilai penagihan termin berikutnya otomatis disesuaikan dengan nilai kontrak baru. Tidak ada implikasi hukum perpajakan. - **Kasus Nilai Kontrak TURUN SETELAH Faktur Pajak Terbit**: Modul penagihan memfasilitasi penerbitan **Nota Retur / Nota Pembatalan** di modul AR yang siap diekspor ke aplikasi e-Faktur DJP. - **Kasus Nilai Kontrak NAIK SETELAH Faktur Pajak Terbit (Kasus Ekstrem: +Rp 1,14 Miliar)**: * Faktur Pajak atas Uang Muka (DP) yang sudah terbit **TIDAK BOLEH DIRUBAH ATAU DIBATALKAN**. * Penambahan nilai kontrak (+Rp 1,14 Miliar) dialokasikan ke **Termin Tambahan / Addendum Baru** di modul `penerimaanprojek`. * Atas Termin Addendum ini, bagian pajak menerbitkan **Faktur Pajak Baru (Kode 010)** atas nilai selisih kontrak tersebut, atau **Faktur Pajak Pengganti (Kode 011)** jika ada koreksi pada faktur berjalan. 2. **Tata Kelola PPh (Split Line Items - Pemisahan Material vs Jasa)**: - Proyek instalasi AC melibatkan gabungan pengadaan barang (Material) dan pengerjaan (Jasa). Struktur tabel `project_komposisi_workoder` di Everest telah memisahkan kedua pos ini secara baku: * **Material (`jenis = 'produk'`)**: Hanya dikenakan PPN 11%. * **Jasa (`jenis = 'biaya'`)**: Dikenakan **PPh Pasal 23** (tarif 2% bagi yang ber-NPWP) ATAU **PPh Final Jasa Konstruksi** (sesuai kualifikasi SBU/NIB perusahaan). - Saat amandemen mengubah komponen biaya jasa teknisi luar/subkontraktor, sistem menghitung ulang potongan PPh secara otomatis pada bukti potong/voucher kasir `3674` agar laporan SPT Masa PPh valid. --- ## 10. Arsitektur Data, Versioning, & Audit Trail (Golden Rule) ### A. Golden Rule Integritas Data (Anti-Overwrite Policy) > **PRINSIP MUTLAK:** > Data transaksi yang sudah berstatus *Approved/Active* dan telah melahirkan transaksi keuangan hilir (seperti Faktur Uang Muka yang sudah lunas, mutasi kas/bank, jurnal akuntansi, atau Surat Jalan fisik gudang) **DILARANG KERAS DITIMPA (OVERWRITE) ATAU DIHAPUS (DELETE)**. ### B. Siklus Hidup Status Dokumen (Document Life Cycle) ``` [ 1. DRAFT AMANDEMEN ] ──► [ 2. PENDING APPROVAL ] ──► [ 3. APPROVED / ACTIVE v2.0 ] │ │ ▼ (Ditolak) ▼ (Arsip Riwayat) [ TETAP ACTIVE v1.0 ] [ SUPERSEDED v1.0 ] ``` 1. **Active v1.0**: Kondisi proyek sebelum adendum berjalan. 2. **Under Amendment / Pending**: Pengajuan perubahan Qty/Harga/Budget sedang ditinjau. 3. **Approved v2.0**: Nilai kontrak baru diberlakukan, jurnal adendum kontinjensi diterbitkan, dan kuota sisa material baru dirilis. 4. **Superseded v1.0**: Snapshot kontrak awal diarsipkan di `transaksi_data_registry` sebagai data historis legal yang tidak boleh hilang. ### C. Komponen Audit Trail & Delta Tracking Setiap amandemen dicatat ke dalam log audit (`project_tasklist_log` atau tabel log amandemen) dengan mencakup 5 komponen wajib: 1. **Timestamp**: Tanggal dan jam presisi saat amandemen disimpan. 2. **User ID**: Identitas petugas yang mengajukan dan menyetujui amandemen. 3. **Delta Log (Before vs After)**: Nilai sebelum (`old_qty`, `old_price`) dan sesudah (`new_qty`, `new_price`). 4. **Financial Impact**: Selisih nilai kontrak (Delta Rp) dan dampak terhadap estimasi laba kotor. 5. **Change Reason**: Alasan justifikasi amandemen (wajib diisi oleh pengguna). --- ## 11. Kesimpulan & Rekomendasi Langkah Lanjutan Dokumen panduan amandemen enterprise ([`PANDUAN_LENGKAP_AMANDEMEN_PROJECT.MD`](file:///z:/everest_history/PANDUAN_LENGKAP_AMANDEMEN_PROJECT.MD)) memperkuat arah arsitektur yang telah kita bangun: 1. **Tahap 1 (Selesai)**: Fondasi data RAB dan guardrail pemakaian lapangan (`update_qty()` dan pembersihan double badge UI) telah aktif dan 100% kompatibel dengan PHP 5.6. 2. **Tahap 2 (Selesai)**: Sinkronisasi Nilai Sales & Kontrak Induk `588st` / `749`, penyesuaian header `project_produk`, pembaruan registry kontrak dengan tarif PPN dinamis, serta hooking ke seluruh endpoint perubahan nilai (`update_qty`, `update_harga`, `update_budget`, `saveBom`, `authorizeBom`). 3. **Tahap 3 (Selesai)**: Penerapan aturan perpajakan e-Faktur dan pemisahan wadah Termin Addendum (`items3`) tanpa merusak DP (`items4`) yang sudah lunas (`rebalanceProjectPaymentAllocation`). 4. **Tahap 4 (Selesai)**: Distribusi otomatis kebutuhan pengadaan material ke purchasing pool (`syncAutopurchasePool` & `resendAutopurchasePool` di modul `pembelianfgproject`). 5. **Tahap 5 (Selesai)**: Proteksi snapshot nilai nominal SPK lama di modul operasional lapangan dan rilis kuota material sisa untuk SPK / SPPB gudang berikutnya (`distribusifgproject`). 6. **Tahap 6 (Selesai)**: Penerbitan jurnal adendum kontinjensi buku besar (`syncProjectAccountingAddendum`), rekonsiliasi PPN keluaran, dan update buku pembantu penjualan proyek. 7. **Tahap 7 (Selesai)**: Reaktivasi otorisasi BOM berjenjang (`getPendingBomRequest`) dan pencatatan audit trail delta komprehensif (`logRabItemAuditTrail` & `logKontrakHistory`). --- ## 12. Arsitektur Penempatan Menu: Model Hybrid (Central Command Hub & Distributed Spokes) Menjawab pertanyaan arsitektural: > *"Apakah menu-menu amandemen perlu kita tempatkan dalam 1 wadah besar adendum project dari semua adendum tersebut? Atau akan tersebar di masing-masing modul yang memerlukan adendum?"* Berdasarkan analisis arsitektur HMVC CodeIgniter 3 di Everest dan matriks pemisahan wewenang (*Separation of Duties*), disepakati penerapan **Model Hybrid (Hub & Spoke)**: ``` ┌──────────────────────────────────────────────┐ │ CENTRAL COMMAND HUB │ │ (master_project) │ │ • Dashboard Ringkasan Amandemen Proyek │ │ • Version Tracking (v1.0 -> v2.0) │ │ • Delta Keuangan (Kontrak, Budget, Laba) │ │ • Status Approval & Multi-Modul Health Check│ └──────────────────────┬───────────────────────┘ │ (Deep-link & Orkestrasi) ┌───────────────────┬───────────────────────┼───────────────────────┬───────────────────┐ ▼ ▼ ▼ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ RAB & SPK │ │ PENAGIHAN KASIR │ │ PURCHASING │ │ GUDANG LOGISTIK │ │ AKUNTANSI │ │ (master_project)│ │(penerimaanprojek│ │(pembelianfgproj)│ │(distribusifgproj│ │ (akunting) │ │ • Edit Setting │ │ • Termin Tambah │ │ • PO Unit Tambah│ │ • SPPB Kuota SPK│ │ • Jurnal Addendum │ │ RAB (Material)│ │ • Immutability │ │ • Auto-Purchase │ │ • Dual-Write │ │ • Buku Pembantu │ │ • Dual-Level │ │ DP Lunas │ │ Pool Delta │ │ Stock Locker │ │ Penjualan │ │ Koreksi Biaya │ │ • e-Faktur PPN │ │ • Project Price │ │ • Pengeluaran │ │ • Rekonsiliasi │ │ (Jasa/Subkon) │ │ & PPh Jasa │ │ Prinsipal │ │ Fisik Lapangan│ │ PPN Keluaran │ └─────────────────┘ └─────────────────┘ └─────────────────┘ └─────────────────┘ └─────────────────┘ ``` ### Keunggulan Model Hybrid: 1. **Tidak Ada Duplikasi Kode (Zero Redundancy)**: - Modul `penerimaanprojek`, `pembelianfgproject`, dan `distribusifgproject` sudah memiliki alur transaksi, otorisasi, dan validasi yang matang. Menyatukan semuanya ke dalam satu controller baru yang monolitik akan merusak batas arsitektur HMVC dan menciptakan ribuan baris kode duplikat. 2. **Pemisahan Hak Akses & Keamanan (Separation of Concerns)**: - Staf Purchasing hanya berwenang menerbitkan PO di modul pembelian. - Staf Keuangan/Kasir hanya berwenang mengelola termin dan penagihan. - Staf Gudang hanya berwenang memvalidasi fisik barang. - Project Manager dan Direksi mengawasi seluruh riwayat dan dampak amandemen dari satu **Dashboard Pusat Kendali di `master_project`**. 3. **Standar Kepatuhan ISO 9001:2015**: - Seluruh amandemen lintas modul memiliki satu nomor induk versi proyek (`current_version = 2.0`) yang seragam, sehingga dokumen cetak di lapangan (SPK, SPPB, PO, Tagihan) terhubung pada versi amandemen yang sama. --- ## 13. Checklist Master Amandemen Proyek - Fase 2 (Enterprise Standard) > **STATUS**: 📋 Disetujui oleh Developer pada 26 September 2026 untuk Panduan Eksekusi Bertahap. > **PRINSIP UTAMA**: > 1. Tetap mematuhi standar teknologi: PHP 5.6 murni, CodeIgniter 3.1.8 HMVC. > 2. Murni menggunakan database MySQL / MariaDB relational (TIDAK MENGGUNAKAN MONGODB). > 3. Zero placeholder rule & transaksi database atomik. > 4. Seluruh hasil implementasi harus selaras dengan alur bisnis trading & instalasi AC tanpa merusak transaksi existing. ### [ ] FASE 2.1: Versioning Dokumen Cetak Lapangan (ISO 9001 - Klausul 7.5) - [ ] **2.1.1. Watermark & Label Versi SPK**: Menambahkan stempel nomor revisi dokumen (misal: `PRJ-xxx Rev 2.0`) dan tanggal cetak pada cetakan Surat Perintah Kerja (SPK) di `master_project/controllers/Printing.php` agar teknisi/mandor tidak menggunakan acuan usang. - [ ] **2.1.2. Label Versi Surat Jalan SPPB Gudang**: Menambahkan kode revisi SPK referensi pada cetakan Surat Perintah Pengeluaran Barang di modul `distribusifgproject`. - [ ] **2.1.3. Label Versi Invoice / Faktur Termin**: Menampilkan nomor addendum kontrak pada cetakan tagihan di modul `penerimaanprojek`. ### [ ] FASE 2.2: Matriks Otorisasi Berjenjang Berbasis Nilai Rupiah - [ ] **2.2.1. Skema Batas Nominal (Threshold Approval)**: - Penambahan nilai amandemen $\le$ Rp 50 Juta: Cukup disetujui oleh Project Manager / Supervisor. - Penambahan nilai amandemen $>$ Rp 50 Juta atau penurunan profit margin: Wajib disetujui oleh Direksi. - [ ] **2.2.2. Flagging & Role Validation**: Validasi hak otorisasi pada tombol approval tiket BOM dan integrasi statusnya ke Dashboard Amandemen. ### [ ] FASE 2.3: Skema Tabel Dedicated Amandemen MySQL (Anti-MongoDB) - [ ] **2.3.1. Tabel Header `project_amendments`**: Tabel relational MySQL untuk mencatat header permohonan amandemen resmi (`amendment_id`, `project_id`, `version_number`, `status`, `requested_by`, `approved_by`, `reason`, `dtime`). - [ ] **2.3.2. Tabel Detail `project_amendment_details`**: Tabel relational MySQL untuk mencatat rincian perbandingan per item barang/jasa sebelum vs sesudah (`old_qty`, `new_qty`, `old_price`, `new_price`, delta nilai). ### [ ] FASE 2.4: Integrasi 5 Pilar Amandemen Lanjutan - [ ] **2.4.1. Amandemen PO Supplier (Modul 1466 `pembelianfgproject`)**: Menangani alur retur PO, pembatalan kuota, atau substitusi tipe AC yang sudah terbit di supplier Daikin/Panasonic jika stok pabrik kosong atau terjadi negosiasi *project price*. - [ ] **2.4.2. Amandemen Alokasi Gudang & Stock Reservation (Modul 5833 `distribusifgproject`)**: Fitur transfer hak reservasi unit antar-proyek atau pelepasan alokasi stok proyek kembali ke stok retail toko. - [ ] **2.4.3. Amandemen Sales Order & Kontrak Mandiri (Modul 588 `penjualanproject`)**: Alur *Change Order* yang diinisiasi langsung dari modul penawaran/kontrak penjualan tanpa melalui tombol Edit RAB. - [ ] **2.4.4. Amandemen Kontrak Sub-Kontraktor / Jasa Lapangan**: Fitur addendum ongkos kerja teknisi luar per titik atau pekerjaan tambah bobokan dinding/plafon di luar RAB awal. - [ ] **2.4.5. Amandemen Jadwal & Milestone Proyek**: Penyesuaian tanggal serah terima (`end_dtime`) dan timeline tasklist saat terjadi kendala/keterlambatan fisik bangunan di lapangan.