think
16px
820px
← all files

Rencana: Yayasan/Perkumpulan jadi "Permohonan Baru" seperti PT

Tujuan

Sidebar notaris untuk badan hukum nirlaba dibuat sama polanya dengan PT: tiap entitas cukup 2 entri.

Sekarang:

YAYASAN            Permohonan Baru
PERKUMPULAN        Permohonan Baru
YAYASAN & PERKUMPULAN   Perubahan · Perbaikan · Pembubaran · Penggabungan Yayasan

Target:

YAYASAN            Permohonan Baru · Perbaikan Data Yayasan
PERKUMPULAN        Permohonan Baru · Perbaikan Data Perkumpulan

Grup "Yayasan & Perkumpulan" dihapus. Perubahan, Pembubaran, dan Penggabungan dilipat ke dalam "Permohonan Baru" lewat classifier. Perbaikan berdiri sendiri sebagai "Perbaikan Data" (persis seperti "Perbaikan Data PT").

Kenapa ini bukan sekadar edit sidebar

Perbedaan arsitektur antara PT dan nirlaba sekarang:

PT Nirlaba (sekarang)
Titik masuk transaksi 1 classifier (/klasifikasi) Halaman "pilih badan hukum dulu" per transaksi
Urutan Upload akta lalu deteksi Pilih entitas dulu, baru upload
Identitas entitas Diambil dari isi akta saat ekstraksi Diisi manual di halaman select
Jenis akta transaksi yang dikenali classifier pendirian, perubahan, pembubaran, penggabungan, dst hanya pendirian

Jadi "seperti PT" berarti membalik urutan flow nirlaba: dari pilih-dulu lalu upload menjadi upload lalu deteksi.

Desain: classify-first + langkah "pilih entitas" jadi interstitial

Pola ini sudah ada di PT: PERBAIKAN_DATA_PT dibuat oleh classifier, lalu dialihkan ke /perbaikan/{id}/select-pt sebelum lanjut. Kita pakai pola yang sama untuk transaksi nirlaba.

flowchart TD A["Permohonan Baru Yayasan
(/yayasan/klasifikasi)"] --> B[Upload akta + klasifikasi] B --> C{Jenis akta terdeteksi} C -->|Pendirian| D["/yayasan/:id/extraction"] C -->|Perubahan| E["/nirlaba/perubahan/:id/select
(pilih entitas + jenis)"] C -->|Pembubaran| F["/nirlaba/pembubaran/:id/select
(pilih entitas)"] C -->|Penggabungan| G["/nirlaba/penggabungan/:id/select
(pilih sumber-sumber)"] E --> H[extraction to review to status] F --> H G --> H D --> H

Bedanya dengan sekarang: halaman select tidak lagi membuat submission (POST /start). Submission sudah dibuat oleh classifier; halaman select berubah jadi langkah menempelkan identitas entitas (dan jenis) ke submission itu, lalu lanjut ekstraksi.

Daftar perubahan

Backend

  1. services/nirlaba-akta-classifier.ts — tambah label + aturan judul akta:
    AKTA_PERUBAHAN_YAYASAN/PERKUMPULAN, AKTA_PEMBUBARAN_YAYASAN/PERKUMPULAN, AKTA_PENGGABUNGAN_YAYASAN.
  2. services/submission-type-inference.ts — petakan label akta di atas ke tipe submission
    PERUBAHAN_YAYASAN, PEMBUBARAN_PERKUMPULAN, dst.
  3. routes/klasifikasi.ts — jalankan classifier nirlaba untuk akta transaksi (bukan hanya AKTA_PENDIRIAN).
  4. routes/klasifikasi-doc-types.ts — katalog label per track (type=yayasan|perkumpulan) ikut menampilkan lane akta transaksi.
  5. Route nirlaba (nirlaba-perubahan.ts dll) — ubah POST /start (membuat) jadi POST /:id/select (menempel entitas/jenis ke submission yang sudah ada). Endpoint lama bisa dipertahankan sementara untuk kompatibilitas, lalu dipensiunkan.

Frontend

  1. components/layout/sidebar.tsx — hapus grup "Yayasan & Perkumpulan"; tambah "Perbaikan Data Yayasan/Perkumpulan" ke masing-masing grup.
  2. pages/KlasifikasiPage.tsx — navigateToSubmission arahkan tipe nirlaba transaksi ke halaman select interstitial-nya.
  3. Halaman select nirlaba (NirlabaPerubahanSelectPage dll) — jadikan interstitial: baca submissionId dari route, tempel entitas/jenis, lalu lanjut ke extraction/review.
  4. routes.tsx — tambah route select ber-:submissionId; entry lama tanpa id boleh dihapus dari sidebar.

Kompleksitas dan catatan

  • Penggabungan multi-sumber, yayasan saja. Classifier hanya melihat satu akta, sedangkan penggabungan butuh beberapa yayasan sumber. Langkah interstitial-nya harus mengumpulkan sumber-sumber itu. Ini konversi yang paling rumit, jadi paling cocok dikerjakan terakhir. (Perkumpulan tidak punya penggabungan di SABH.)
  • Jenis perubahan (jalur PAD/PPAD/PPD) tetap dipilih di langkah interstitial, karena menentukan apakah butuh verifikator. Tidak diambil dari akta dulu.
  • Perbaikan tetap select-first dan berdiri sendiri, sama seperti "Perbaikan Data PT".

Usulan bertahap

  • Fase 1 — Sidebar + fold Perubahan (transaksi paling umum) end-to-end.
  • Fase 2 — Fold Pembubaran.
  • Fase 3 — Fold Penggabungan (multi-sumber).

Tiap fase berdiri sendiri, bisa dites dan di-commit terpisah. Selama fold belum jadi, entri lama tetap bisa diakses supaya tidak ada flow yang putus.