SABH-parity spec — Perubahan Perkumpulan (id_aksi 15)

Source of truth: legacy SABH module ahu-online/protected/modules/sabh + the 7 SABH UI
screenshots (2026-08-18). Written by the dev_4 session to grade + correct the existing
Perubahan build (Marvella/Dian, unverified). Mirror of Dian's yayasan-vs-SABH work.

TL;DR — the answer to "harus diverifikasi atau enggak?"

IT DEPENDS ON JENIS (corrected 2026-08-18):

PAD — Perubahan Anggaran Dasar = "Perubahan Anggaran Dasar dengan Persetujuan Menteri /
with Ministerial Approval" (services/perseroan/PemegangSahamService.php:891,
views/votingPerubahanPerseroan/index.php:669). PAD changes legally require ministerial approval,
so they DO route through a verifikator stage — SABH's views/verifikator/verifikasiPerkumpulan.php
("Pengajuan Persetujuan Perubahan Perkumpulan ... menunggu verifikasi").
Non-PAD (Pemberitahuan) = notification only → self-service, SK/SP printed on payment
(controllers/PerkumpulanController.php:1061, gated on status_billing=1).

CORRECTION: an earlier version of this spec said "NO verifikator at all." That was wrong — it
traced only the self-service SK-print path and missed the Persetujuan-Menteri approval flow.

Grading flag #1 (RESOLVED): the existing build's design — PAD jenis create a
VerifikasiPerubahan MENUNGGU_VERIFIKATOR row, non-PAD is self-service — is CORRECT and matches
SABH. Do NOT remove the verifikator staging. (Open sub-question: confirm the exact PAD/non-PAD
boundary per jenis, and whether every PAD jenis for perkumpulan needs approval.)

Jenis Perubahan — 2 groups (perkumpulan)

Must select at least one (checkMinimumSelection). Perkumpulan has 2 top-level groups
(yayasan has 3: PAD/PPAD/NONPAD):

PAD — Perubahan Anggaran Dasar (TransaksiPerkumpulan::$perubahanPAD): Nama, Kegiatan,
Kedudukan, Kepengurusan, Jangka Waktu, Alamat lengkap, Rapat Anggota. When "Kegiatan"/AD is
changed, the AD/ART clause fields re-appear (Lambang, Asas, Hak/Kewajiban, Pengelola,
Mekanisme Penyelesaian Sengketa) — same fields as pendirian (screenshot 14.51).
NONPAD — Perubahan pengurus dan pengawas (commits early via a special push branch,
TransaksiPerkumpulan.php:769).

Name/Kedudukan/Alamat changes require confirming a warning-list (checkAllWarning, refs from
Settings::getRef('RefPADPersetujuanPerkumpulanNama' / '...Kedudukan' / '...Alamat')).

Entry = identity-match gate (NOT a fresh upload)

Perubahan amends an EXISTING badan hukum. The pemohon must supply values that match the current
record or it refuses ("Data yang Anda masukkan tidak sesuai"):
nama, nomor_sk (last SK), nama_notaris, tanggal_akta (FormDataPerubahanPerkumpulan.php:117).
Plus guards: blokir if status_transaksi==2, pending if ==0
(FormDataPerubahanPerkumpulan.php:142,210); banned-name check on any new name.

This is the big shape difference from Pendirian: Perubahan is a DIFF against an existing entity
(old value -> new value), not a from-scratch extraction. Our OCR job is to read the akta
perubahan + notulen and produce the changed fields, anchored to the existing record.

Data captured (what our OCR should extract from the akta perubahan)

Akta perubahan metadata: nomor_akta_notaris, tanggal_akta_notaris, nama_notaris (all required,
FormDataPerubahanPerkumpulanAkta.php:24).
Rapat Anggota: tanggal_rups; kuorum numbers — "Minimal Jumlah Kehadiran" + "Jumlah Korum
Persetujuan" (screenshot 14.49). NOTE: server-side quorum number check is commented out
(FormDataPerubahanPerkumpulanAkta.php:48); only the checkbox attestations (peserta >2/3,
hasil suara >2/3) are enforced.
Changed fields per selected jenis: new nama, new kedudukan, AD/ART clauses (if PAD), new
organ roster (if pengurus/pengawas), jangka waktu, alamat.

Documents

Uploaded file: the corrective akta perubahan — single upload
(UploadAktaController::actionPerkumpulan). No per-jenis document matrix (unlike perseroan).
BO questionnaire is skipped for perubahan in code (id_aksi 14/2 only) — but a Pemilik Manfaat
attestation checkbox still renders in the UI (screenshot 14.51). [verify: attestation only, not
the full BO questionnaire].
Declarative persyaratan ("Persyaratan Dokumen yang harus dimiliki" — attest, don't upload):
minuta akta perubahan AD, notulen rapat anggota, fotokopi NPWP + SPT tahunan, surat pernyataan
tidak dalam sengketa kepengurusan.
Persyaratan Utama attestations (screenshot 14.48): Berita Acara/Notulen Rapat Anggota, kuorum
peserta >2/3, kuorum hasil suara >2/3, pernyataan tidak sengketa, akta Bahasa Indonesia, tanggal
rapat, NPWP, SPT + final pernyataan kebenaran.

Perkumpulan vs Yayasan (for the shared perubahan infra)

Aspect	Perkumpulan (15)	Yayasan (3)
Jenis groups	2 (PAD, NONPAD)	3 (PAD, PPAD, NONPAD)
Organ	Pengurus/Pengawas (+ Rapat Anggota jenis)	Pembina/Pengurus/Pengawas
Verification	none (self-service)	none (self-service) — identical
Documents	akta + declarative syarat	identical; asing docs NOT required in perubahan

Grading checklist for the existing build (verify + correct)

[verification] PAD jenis route to a verifikator (Persetujuan Menteri); non-PAD is
self-service READY -> COMPLETED. The existing build does this correctly. (RESOLVED — build is right)
[jenis] 2 groups modeled for perkumpulan (PAD + NONPAD), with the PAD sub-fields incl. the
5 AD/ART clauses; min-1-selection enforced.
[entry] Identity-match gate against the existing badan hukum (nama/nomor_sk/notaris/tanggal)
+ blokir/pending guards; it's a DIFF flow, not a fresh extraction.
[kuorum] Checkbox attestation (>2/3) enforced; number fields captured but NOT hard-validated.
[docs] Single akta-perubahan upload; the rest are declarative attestations (not uploads).
[name change] New name comes from a pre-approved pesan-nama, not re-checked inline.
[perkumpulan vs yayasan] shared infra keeps the 2-vs-3 group split + organ terminology right.

Open items to confirm next

Does the existing build treat Perubahan as verifikator-staged? (grade against #1)
The Pemilik Manfaat attestation-vs-questionnaire question in perubahan.
Whether Pembubaran's "verifikator-staged" build is itself SABH-correct (separate flow, but the
same self-service pattern may apply — worth a parallel check).