Untouched SABH PT Flows, Ranked by OCR-Transformation Quality-of-Life Impact
Executive Summary
Of the eleven SABH PT transaction types the PoC does not yet transform, the highest-leverage next builds are Akuisisi PT (Pengambilalihan), Pelaporan RUPS Tahunan (Annual Report), Perbaikan Data PT (SABH's own correction flow), and Akuisisi's sibling akta-driven actions (Pembubaran / Merger / Peleburan / Berakhirnya Status). Akuisisi is the single best target: it is a pure akta-driven ownership-change deed whose entire heavy payload — the full share register, modal tables, direksi/komisaris, KBLI, plus per-shareholder KTP/NPWP — maps 1:1 onto extractors the PoC already ships (the akta-perubahan schema even models peralihan_saham as dari→kepada transfer rows), so it earns a clean transformability 5 at M effort. Pelaporan RUPS Tahunan is the QoL sleeper: modest per-filing typing but statutory, recurring, every-active-PT-every-year volume (the highest-frequency untouched flow), and it is a terminal self-service submit with no verifier — making OCR cross-validation-at-entry unusually valuable. Perbaikan Data PT is a high-reuse, high-value extension (its inverted Surat-Pernyataan flow is already anticipated by the PoC), though its real transcription burden lives downstream on the verifikator, not the notaris. The three flows the user named — Pembubaran, Merger, Akuisisi — all exist and all rank "high", with Akuisisi the standout and Merger carrying the heaviest integration cost (L) because no document is uploaded during data entry. Do NOT spend OCR effort on Pesan Nama, Social Enterprise, Perbaikan SK, or Perbaikan Modal Dasar: they are pure registry/name/blocking/back-office actions with zero (or nonexistent) document surface.
Ranked Table
| # | Flow | OCR-transformability | QoL impact | Build effort | Reuse | Recommendation |
|---|---|---|---|---|---|---|
| 1 | Akuisisi PT (Pengambilalihan) | 5 | 4 | M | Very high (akta-perubahan schema, change-type-detector, RUPS matcher, KTP/NPWP, company-lookup) | Top priority |
| 2 | Pelaporan RUPS Tahunan | 4 | 4 | M | High akta side; new akuntan-publik extractor | High |
| 3 | Perbaikan Data PT (SABH) | 4 | 4 | M | Very high (akta/NPWP/SK/domisili + inverted Surat-Pernyataan flow) | High |
| 4 | Peleburan PT (Konsolidasi) | 5 | 3 | M | Very high (Pendirian-grade pengisian, all extractors) | High |
| 5 | Berakhirnya Status Badan Hukum | 5 | 3 | M | Very high (6 docs → 6 existing extractors) | High |
| 6 | Pembubaran PT (Dissolution) | 4 | 3 | M | High (akta-perubahan + RUPS matcher + surat-pernyataan) | High |
| 7 | Merger PT (Penggabungan) | 4 | 3 | L | High extraction; L integration (no in-wizard upload) | High |
| 8 | Perubahan Status PT (= Berakhirnya, mislabeled) | 4 | 2 | M | High (akta + surat + laporan + date normalizer) | Medium |
| 9 | Penyesuaian PT | 4 | 2 | S | Very high (rides Perubahan pipeline near-verbatim) | Medium |
| 10 | Likuidator Management | 4 | 2 | M | High (akta + surat/SK + KTP), but no upload surface today | Medium |
| 11 | Pemblokiran / Buka Blokir PT | 3 | 2 | M | Medium (surat/akta/KTP/SK; new court-doc class) | Low |
| 12 | Pesan Nama PT | 1 | 1 | S | None | Not OCR-suitable |
| 13 | Perbaikan Modal Dasar | 1 | 1 | S | None | Not OCR-suitable |
| 14 | Perbaikan SK PT | 1 | 1 | S | None (flow doesn't exist as a user action) | Not OCR-suitable |
| 15 | Social Enterprise PT | 1 | 1 | S | None (not a standalone flow) | Not OCR-suitable |
Note on rows 5/8: "Berakhirnya Status Badan Hukum" and "Perubahan Status PT" are the same flow discovered twice (the code path is named
PerubahanStatus*but every view/label says "Berakhirnya Status Badan Hukum"). The higher-scored row 5 reflects the fuller 6-doc → 6-extractor mapping; row 8 is the same flow's more conservative read. Treat as one build.
Top Priority
Akuisisi PT (Pengambilalihan) — transformability 5, QoL 4, effort M
What it is: A registered PT undergoes an acquisition (control change via share transfer), filed by a notaris as its own transaction (id_aksi_transaksi = 19). A 4-step wizard: identify the PT + voucher + persyaratan-utama checklist; type deed header + RUPS date + newspaper announcement + attendance + legal-path radios; pick change-types; then re-key the entire "Format Isian Pengambilalihan" — full share register, modal ditempatkan/dasar, direksi/komisaris, KBLI. No document is uploaded anywhere; the notary self-declares.
What OCR auto-fills: From the akta pengambilalihan — nomor/tanggal akta, tanggal RUPS, jenis_dokumen, AND the whole Step-4 payload: every shareholder identity + shares + harga, modal tables, direksi/komisaris, KBLI; peralihan_saham dari→kepada rows encode the acquisition itself, and change-type-detector auto-ticks Step-3 flags. From KTP/NPWP — per-shareholder NIK/NPWP/nama/TTL/alamat/kewarganegaraan. From SK Menkumham — nomor SK (Step-1 identity key). Not doc-derived: persyaratan-utama quorum checklist, vouchers, Tertutup/Terbuka legal-path election, koran fields.
Reuses: akta-perubahan schema (already models pemegang_saham_lama/baru + detail_pemegang_saham + peralihan_saham + direksi/komisaris lama/baru + KBLI — the near-exact Step-4 payload); akta-notaris base extractor + document-processor (35B-A3B); change-type-detector.ts; rups-attendance-matcher.ts; KTP/NPWP two-pass card extractor + identity-matcher.ts; SK extractor; company-lookup.ts / sabh-perseroan.ts; perubahan-diff.ts + perubahan-processor.ts + cross-validator.ts wholesale (akuisisi IS a perubahan-family transaction).
Key SABH files: controllers/persero/AkuisisiController.php; models/FormDataPerseroanAkuisisiAkta.php; views/persero/akuisisi/_formAkuisisi{,Syarat,Akta,List,Detail}.php; models/TransaksiPerseroan.php (createAkuisisiTransaksi ~L2292); views/perseroan/_formPemegangSaham.php.
Dependencies/caveats: Needs a new SubmissionType with an akuisisi field-mapping wired into reMatchAndValidate/queueReMatchAndValidate (else field edits silently wipe validations). Add a newspaper/pengumuman field for Step-2; the Tertutup/Terbuka path stays manual. Low-volume corporate event (dedicated id_aksi 19), so per-transaction relief is enormous but aggregate count is niche — this caps QoL at 4, not 5.
High
Pelaporan RUPS Tahunan (Laporan Tahunan) — transformability 4, QoL 4, effort M
What it is: The statutory annual filing every active PT must submit (UUPT Ps.66-68), notaris-driven, 4-step, terminal self-service submit with no verifier queue. Backlog-fileable up to 10 years.
What OCR auto-fills: From the akta RUPS PDF — no_akta_notaris + tanggal_akta_notaris (Step-3's two typed fields) + cross-validate resolved PT name/notaris. From the laporan keuangan (wajib-audit only) — nama_akuntan_publik, izin_akuntan_publik, tanggal_izin_akuntan. That covers every free-text field the user types. Not fillable: jenis_audit (system-forced), tahun_laporan (dropdown); the 6 laporan PDFs are opaque file storage with no target fields (latent upside: direksi/komisaris susunan + gaji docs).
Reuses: akta-notaris extractor + rups-attendance-matcher.ts (the akta here is a Risalah/BA RUPS — same shape); document-processor.ts + PaddleOCR; company-lookup.ts/sabh-perseroan.ts for Step-1; cross-validator.ts; field-confirmation.ts/field-transformer.ts.
Key SABH files: controllers/PelaporanRupsTahunanController.php; models/PelaporanRupsTahunan.php, PelaporanRupsTahunanDokumen.php, FormDataPelaporanRupsTahunan.php; views/pelaporanRupsTahunan/_step1.php, _step3_upload.php, _step4.php, detail.php.
Dependencies/caveats: The akuntan-publik extractor (financial-statement audit-opinion page) is genuinely new — no PoC extractor for it. Half the fields are audit-conditional. But this is the highest-volume untouched flow (every active PT, annually), and because submit is terminal with no downstream verifier, validation-at-entry (catching akta-number/date typos and mismatched izin) is unusually valuable.
Perbaikan Data PT (SABH — Permohonan Perbaikan Data Badan Hukum) — transformability 4, QoL 4, effort M
What it is: A registered PT with a master-record error; the notaris searches by exact name + SK/SP number + date, buys a voucher, checkboxes which of ~12 categories are wrong, and uploads a signed Surat Pernyataan + evidence. A two-tier staff→kasi verifikator then corrects the master record. Weekday 08:00-16:00 gated.
What OCR auto-fills: Salinan Akta Pendirian/Perubahan (richest) → jangka_waktu, nomor/tanggal akta, maksud & tujuan, modal, saham, pemegang saham, direksi/komisaris. Akta Pemindahan Saham + DPS → share ownership. NPWP badan hukum. Surat Keterangan Domisili → kedudukan + alamat. Surat Pernyataan Perbaikan → the per-field before→after corrections (the ONLY place the corrected values are stated). Highest-value target is the verifikator side: SABH stores only WHICH categories are wrong (data_diperbaiki = JSON of labels), so the corrected values are hand-keyed downstream by staff reading akta + Surat Pernyataan.
Reuses: Akta extractor verbatim; NPWP extractor; the PoC's inverted surat-pernyataan-extract.ts ("Perbaikan data PT" flow, already anticipates this exact case); SK/domisili path; registry-snapshot diff harness; confirm-LOCK UI.
Key SABH files: controllers/PerbaikanDataController.php (2069 lines); models/PerbaikanData.php, FormPerbaikanData.php; views/perbaikanData/index.php, checklistSuratPernyataan.php, uploadDataDiperbaikiV2.php; controllers/VerifikasiPerbaikanDataController.php; helpers/VerifikasiPerbaikanCompareHelper.php.
Dependencies/caveats: The classic notaris-side auto-fill surface is thin (the notary only checkboxes categories); the transcription burden lives on the verifikator, so the highest-value build is a verifikator-side pre-fill + master-diff surface — new UI/glue, hence M. Voucher- and time-gated → bounded volume, rarer than Pendirian/Perubahan.
Peleburan PT (Konsolidasi) — transformability 5, QoL 3, effort M
What it is: Two-or-more PTs consolidate into a brand-new entity (id_aksi_transaksi = 35). Step 4 is structurally a Pendirian-grade "pengisian" form for the new PT; the akta-upload partial is commented out (line 649 of _formLeburPengisian.php), so today every field is hand-typed under one self-declaration.
What OCR auto-fills: Akta Peleburan / Pernyataan Keputusan RUPS + Risalah RUPS → the entire Step-4 new-PT form (nama/jenis/jangka waktu, full domisili, NPWP perseroan, akta block, modal dasar/ditempatkan/disetor, all pengurus + pemegang saham incl. badan-hukum shareholders, BO, KBLI). Per-PT NPWP + surviving-PT NPWP (Step 2). RUPS date + newspaper rows with the Pasal 127(2) ≥30-day check pre-validated.
Reuses: Pendirian/Perubahan akta extractor; pengurus & pemegang saham row extractor (incl. asing/passport/KITAS, badan-hukum nomor akta/SK); KTP/NPWP card extractor; SK/registry cross-validation; region + KBLI matching; apostille date-normalization; 35B-A3B + 3B grounded fallback.
Key SABH files: controllers/persero/PeleburanController.php; models/FormPermohonanPeleburan.php, FormDataPerseroanLebur.php, PeleburanPerseroan.php; TransaksiPerseroan.php (createLeburTransaksi ~L6674-6990); views/persero/peleburan/_form_*.php, _formLeburPengisian.php.
Dependencies/caveats: Maximal document-richness, near-total PoC reuse, only a small bukti-pengumuman extractor is net-new. The limiter is volume: true consolidation into a new entity requiring 2+ active PTs + full RUPS + ≥30-day koran lifecycle is one of the rarest SABH actions → QoL capped at 3.
Berakhirnya Status Badan Hukum PT — transformability 5, QoL 3, effort M
(Same flow as "Perubahan Status PT" below — the code path is PerubahanStatus* but is titled "Berakhirnya Status Badan Hukum". Build once.)
What it is: The terminal transaction ending a PT's legal personhood after dissolution + liquidation (id_aksi_transaksi = 36, code 70). 3-step wizard; Step-3 hand-keys ~19 metadata fields and uploads 6 PDFs; 2-level verifier pool.
What OCR auto-fills (all 6 PDFs → ~19 fields): Akta Notaris → nomor/tanggal akta, nama+id notaris (SABH-matched), notaris_pengganti, nomor/tanggal akta pembubaran. Risalah RUPS → nomor/tanggal RUPS, jumlah kehadiran. Surat Permohonan → nomor/tanggal. Laporan Akhir Likuidasi → nama likuidator, nomor/tanggal surat, sisa kekayaan. Bukti Pengumuman Pasal 149 → nama koran, tanggal, nomor pengumuman[]. Bukti Pengumuman Pasal 152 → same for hasil likuidasi. Not OCR'd: nomor voucher, registry/blocking checks.
Reuses: akta-notaris extractor + llm-extract-onprem.ts; BeritaAcaraRupsExtraction + rups-attendance-matcher.ts; surat-pernyataan-extract.ts; apostille-generic-extract.ts (grounded number/date + normalizeWordDateViaLlm/recoverDocNumberViaLlm, purpose-built for the bukti-pengumuman shape); PaddleOCR + 35B-A3B; SABH notaris cross-validation.
Key SABH files: models/PermohonanBerakhirnyaStatusBadanHukum.php, VerifikasiBerakhirnyaPerseroan{,Detail}.php, VerifikatorBerakhirnyaPerseroan.php, FormDataPerseroanPerubahanStatusDetail.php; PerseroanController.php (actionPerubahanStatus* ~L9082-9625); VerifikatorPerseroanController.php; dto/CreatePermohonanBerakhirnyaStatusBadanHukumDto.php.
Dependencies/caveats: The flow's own model comment notes essentially every Step-3 field is a header of one of the 6 uploaded PDFs → near-ideal auto-fill. No new document class invented → M. Volume is the cap: terminal once-per-company, gated behind completed pembubaran + likuidasi, tiny 2-verifier pool, [BSBHP-log] debug scaffolding still present → QoL 3.
Pembubaran PT (Dissolution) — transformability 4, QoL 3, effort M
What it is: A registered PT is dissolved (id_aksi_transaksi = 12), notaris- or court-Likuidator-initiated. Wizard: lookup PT; hand-key dissolution deed(s) + RUPS date + repeating newspaper rows + attendance checkboxes + substitute notary; separately a full liquidator responsibility letter.
What OCR auto-fills: Akta Pembubaran/BA RUPS → nomor/tanggal akta (dual deeds) + tanggal RUPS + notaris pengganti; run the RUPS-attendance matcher to pre-tick per-shareholder "attended" boxes (currently every box manual). Bukti Pengumuman koran clippings → Tanggal Cetak + Nama Surat Kabar (+ nomor pengumuman for the berakhirnya stage). Surat Pertanggungjawaban/Penunjukan Likuidator → nama, nomor/tanggal surat, alamat, RT/RW/kodepos/kecamatan, telepon, email, dasar_penunjukan. SK Menkumham terakhir → nomor SK lookup key. Not doc-derived: voucher, registry NPWP/jenis/status/shareholder list, sisa_kekayaan.
Reuses: akta-perubahan.ts schema/extractor; rups-attendance-matcher.ts; notaris-pengganti-enrichment.ts; surat-pernyataan-extract.ts + schema; SK/surat-keterangan extractor; apostille bukti-pengumuman base.
Key SABH files: controllers/persero/PembubaranController.php; models/FormDataPerseroanPembubaran.php, PerseroanPembubaran.php, PerseroanLikuidator.php, PermohonanBerakhirnyaStatusBadanHukum.php; views/persero/pembubaran/_formPembubaran{,Akta,Likuidator}.php.
Dependencies/caveats: One net-new shallow newspaper-announcement extractor (2-3 fields). A meaningful chunk of high-value payload (NPWP, jenis/status, shareholder list) comes from the registry, not a document → transformability 4. Terminal, once-per-company, lower-volume → QoL 3.
Merger PT (Penggabungan) — transformability 4, QoL 3, effort L
What it is: Filed by/for the surviving PT (id_aksi_transaksi = 11); ~6-step wizard including the full step-6 anggaran-dasar change set (functionally a Perubahan PT). Critically, NO document is uploaded during data entry — the signed merger akta lands in a separate later upload stage (_formUploadAkta.php).
What OCR auto-fills: Akta Penggabungan (up to 2) + BA/Notulen RUPS + conditional Akta Pemindahan Hak Saham → per-deed notaris/nomor/tanggal (step 4); tanggal RUPS + attendee roster (step 5); the entire step-6 AD change set (nama, kedudukan, KBLI, modal, pemegang saham, direksi, komisaris, BO); step-3 perubahan-tipe pre-select. Not fillable: vouchers, syarat-utama quorum checkboxes, surviving-PT identification (registry), newspaper fields.
Reuses: akta-perubahan.ts + perubahan-processor.ts; akta-notaris.ts; change-type-detector.ts; rups-attendance-matcher.ts + quorum validation; company-lookup.ts + loadOldData; cross-validator.ts; surat-pernyataan-extract.ts; sabh-pt-snapshot.ts/sabh-perseroan.ts (id_aksi 11 already labelled); PaddleOCR pipeline.
Key SABH files: controllers/persero/MergerController.php; models/FormDataPerseroanMerger{,Akta}.php; TransaksiPerseroan.php (createMergerTransaksi @L2685, id_aksi 11 @L2728); views/persero/merger/_formMerger{Pilih,Akta,Tipe,Syarat}.php; views/badan_hukum/_formUploadAkta.php (the real OCR entry point).
Dependencies/caveats: Effort is L, not M, because of a structural mismatch: the wizard has no in-entry upload. Either inject a doc-first upload step up front (the PP form-first pattern) or run OCR at the later stage as post-hoc cross-validation instead of auto-fill. Plus merger-specific wrinkles (two deeds, merging-PT list, share-transfer deed, snapshot semantics, voucher-gated tipe) and a new SubmissionType into reMatchAndValidate. Extraction stack is reusable; the cost is flow-shape and integration.
Medium
Perubahan Status PT (mislabeled — = Berakhirnya Status Badan Hukum) — transformability 4, QoL 2, effort M
Same flow as row 5 above, conservative read. Notaris looks up an already-dissolved PT; ~13-15 number/date/name fields transcribed off 6 required PDFs (akta, RUPS minutes, surat permohonan, likuidasi report, two Pasal 149/152 koran cuttings). Reuses: akta extractor, surat-pernyataan extractor, laporan/SK number+date extractor, generic doc-date normalizer, notaris→id_notaris registry match, bbox-grounded confirm UI. Caveat: two of six docs are low-structure (koran name + date), and the bulkiest content (company/shareholder data) is DB-pulled — OCR removes typing but not the biggest data block. Terminal, status_transaksi==3-gated, a handful per year → QoL 2. Build once with row 5.
Penyesuaian PT — transformability 4, QoL 2, effort S
What it is: A legally-mandated one-time migration of pre-2007 PTs to UU 40/2007 (Pasal 157(3), id_aksi 27), implemented in SABH as a thin subclass of Perubahan. Zero document upload today; the whole anggaran dasar is re-keyed.
What OCR auto-fills: Akta Penyesuaian/Perubahan → Step-3 metadata + Step-4 jenis + full Step-5 AD (nama, kedudukan/alamat, KBLI, modal, direksi, komisaris, pemegang saham, BO); RUPS BA → tanggal + quorum; SK → nomor_sk match. Not OCR: voucher, tbl_perseroan__penyesuaian eligibility flag, name reservation, checkbox attestations.
Reuses: Perubahan pipeline near-verbatim (akta-perubahan.ts, perubahan-processor.ts, change-type-detector.ts, perubahan-diff.ts + post-perubahan-roster.ts, cross-validator.ts, company-lookup.ts). Only new code: eligibility read + NPWP-validation suppression (already SABH behavior) → effort S.
Key files: PerseroanController.php (actionPenyesuaian ~3366); models/FormDataPerseroanPenyesuaian{,Detail,Type}.php; views/perseroan/_formPenyesuaian*.php; TransaksiPerseroan.php (createPerubahanTransaksi ~1682).
Caveat: Cheap to build (rides Perubahan), high per-doc payoff, but a shrinking, time-bounded niche — each eligible PT does it exactly once, drawn from a monotonically-shrinking hand-seeded table → QoL 2. Do it as a near-free rider on the Perubahan pipeline, not a standalone priority. Requires bolting an upload step onto a form never designed for it.
Likuidator Management — transformability 4, QoL 2, effort M
What it is: The liquidator is registered as a step inside PT dissolution (PembubaranController::actionLikuidator → PerseroanLikuidator), not a standalone screen. (The UserLikuidatorController/DclUserLikuidator files are just login-account CRUD — no business data.) Zero upload widgets today.
What OCR auto-fills: Akta Pembubaran/RUPS → nomor/tanggal akta (+2nd), tanggal RUPS. Surat Penunjukan Likuidator → nomor/tanggal surat + dasar_penunjukan free-text (100% hand-typed today). Likuidator KTP → nama, alamat, RT/RW, kodepos, kecamatan (telepon/email stay manual). Koran → nama/tanggal. Not OCR'd: PT master data (registry-served).
Reuses: akta extractor; surat/SK extractor; KTP card extractor + parseKtpHeader; WILAYAH resolver; confirm/LOCK pipeline; 35B-A3B + grounded fallbacks.
Key files: PembubaranController.php (actionLikuidator ~L182-245); PerseroanLikuidator.php; views/persero/pembubaran/_formPembubaranLikuidator.php; PerseroanPembubaran.php; FormDataPerseroanPembubaran.php.
Caveat: All extractors reused, but the flow has zero upload widgets — the Yii session-wizard needs an added upload+verify surface, and OCR must precede hard session/registry guards. Terminal once-per-PT, tiny expired-gated likuidator pool → QoL 2. Overlaps heavily with Pembubaran; best built together.
Low
Pemblokiran / Pembukaan Blokir Akses PT — transformability 3, QoL 2, effort M
What it is: A dispute/litigation-driven request to freeze/unfreeze a PT's record or a specific shareholder (Go backend + Alpine dashboard proxy, voucher-paid, 4-tier internal review). Rare, bespoke, historically a password-gated one-off operator action.
What OCR auto-fills: Surat Permohonan → nomor/tanggal. Surat Kuasa / Akta Kuasa → nomor/tanggal akta + namaNotaris. Putusan/Penetapan Pengadilan, Putusan Pailit, Penetapan Pencabutan Perkara, Akta Perdamaian → their respective nomor scalars (a new free-form court/bankruptcy legal-document class, needing only grounded nomor+tanggal). Surat Keterangan Waris → nomor. Applicant KTP → nama + NIK. SEBAGIAN target-shareholder identity block. Laporan Keuangan Audit / SPT are attachments only.
Reuses: surat-pernyataan extractor; akta extractor; KTP + NPWP; SK extractor; apostille grounded single-field recovery; cross-validation/auto-fill harness.
Key files: BlokirPerseroanController.php; PermohonanPemblokiranPT.php; services/api/PemblokiranProxyService.php, BlokirAuthService.php; views/blokirPerseroan/detail/_{dokumenPersyaratan,pemohonData,permohonanData}.php; PemegangSahamBlokirController.php, BlokirPemegangSahamSemiPermanent.php.
Caveat: Clears the "nothing to OCR" bar (every typed field lives in a PDF), but the extractable payload is shallow (isolated nomor/tanggal scalars + two identity blocks), not a rich akta field-set. Rare, dispute-driven → aggregate hours saved modest. The four highest-value docs are a new legal-document class, and the branched requirement schema (applicant type × BLOKIR/BUKA × SELURUHNYA/SEBAGIAN × via-kuasa) means many permutations. Safe reuse target for a later phase; low priority.
Not OCR-Suitable (do NOT spend OCR effort here)
Pesan Nama PT (Name Reservation) — transformability 1
The archetypal pure-registry action with zero document surface. The user is inventing a prospective PT name that exists on no document — there is nothing to OCR (the akta comes later, at Pendirian, and must match the reserved name, not the reverse). The whole engine is text/registry rules (Soundex, banned-word lists, min-3-words). Four typed fields (name, abbreviation, jenis, voucher code); no file input on pesannama.php. Despite being the highest-volume SABH transaction, volume cannot rescue OCR value when there is literally nothing to OCR. De-scope explicitly. Files: PerseroanController.php (actionPesannama), BaseController.php (pesannama rule engine), OrderNamePerseroan.php, views/badan_hukum/pesannama.php.
Perbaikan Modal Dasar — transformability 1
An internal AHU back-office "Tool", not a citizen/notaris transaction. Operator types a SIMPONI voucher code + corrected capital figure; overwrites billing_modal_dasar; inserts a riwayat row. Zero documents uploaded (empty inputDocuments, no file input in _form.php). The corrected capital is a value fixed by human judgment, not read off any deed. The real document-bearing work lives in the sibling UploadModalDasar/Reupload Bukti Setor path — a different flow. Files: PerbaikanModalDasarController.php, FormPerbaikanModalDasar.php, views/perbaikanModalDasar/create.php, _form.php.
Perbaikan SK PT — transformability 1 (flow does not exist as a user action)
Despite the name, this is not a user-initiated correction. It is a read-only reprint/notification utility for a one-time 2014 government-side SK-number-duplication data-fix. Zero data entry, zero upload, zero write; it only renders pre-backfilled *_sk_duplikat rows for a hardcoded ~180 affected 2014 SP numbers. No ongoing volume. Files: controllers/persero/PerbaikanSKController.php, DuplikatSK.php, views/persero/perbaikanSK/index.php.
Social Enterprise PT — transformability 1 (not a standalone flow)
Not a standalone transaction — a flag + embedded sub-form riding inside Pendirian/Perubahan (a Ya/Tidak radio, a ≥51%-reinvestment checkbox, an SDG-goal picker from a fixed catalog, and hand-typed founder demographics). No dedicated controller, no SE-specific document upload. The genuine document (the akta with SDG clauses) is already extracted by the parent Pendirian/Perubahan flows the PoC transforms. Nothing net-new to OCR. Files: SocialEnterprise.php, _formSocialEnterprise{,Founder}Modal.php, _formPengisianPerseroan.php.
Status of the User's Three Named Candidates
- Pembubaran PT — EXISTS, ranked High (transformability 4, QoL 3, effort M). Genuine akta-driven action; RUPS-attendance matcher solves its single most tedious sub-task. One net-new shallow koran extractor. Registry-sourced NPWP/status/shareholder list caps transformability at 4; terminal once-per-company caps QoL at 3.
- Merger PT (Penggabungan) — EXISTS, ranked High (transformability 4, QoL 3, effort L). Heaviest single SABH flow per-transaction; extraction stack fully reusable, but the "no in-wizard upload" structural mismatch forces an added doc-first stage → L effort. Lowest-priority of the three named due to build cost.
- Akuisisi PT (Pengambilalihan) — EXISTS, ranked #1 / Top Priority (transformability 5, QoL 4, effort M). The standout: pure akta payload maps 1:1 onto the existing akta-perubahan pipeline (incl.
peralihan_sahamdari→kepada rows), no new extractor needed. Build this first of the three.
All three are confirmed present in SABH (id_aksi 12 / 11 / 19 respectively, each with a dedicated controller), and all three rank "high" or better — the user's instinct is sound; the refinement is prioritize Akuisisi over Merger because Merger's flow-shape (later-stage upload) makes it materially more expensive.
Gaps / Needs More Investigation
The discovery step flagged several PT transaction types in the full menu that were not individually deep-read and have no assessment record; before committing a roadmap they warrant a quick confirmation pass:
- Perubahan Anggaran Dasar (SP-AD), Pemberitahuan Anggaran Dasar (SK), and Perubahan Data Perseroan (SP-DP) — these are the three billed sub-jenis of the monolithic "Perubahan" (
id_aksi 10, split viatipe_perubahanindetail_transaksi.php:204-211). The PoC's PERUBAHAN_PT flow likely already covers their akta OCR surface, but the per-sub-jenis voucher/document gating and whether each needs its own SubmissionType mapping was not verified. - KeberatanKreditor (creditor-objection, attached to Pembubaran/Peleburan) — flagged as new but not assessed; likely a thin surat/putusan surface, probably Low.
- Blokir Pemegang Saham (semi-permanent) — distinct from company-level Blokir; folded into the Pemblokiran assessment but not separately scored.
- Perpanjangan PesanNama, BannedNama/Pemblokiran Nama, Pembatalan Transaksi, Upload/Reupload Modal Dasar — name-reservation renewal, name-blocklist admin, transaction cancellation, and modal-dasar proof upload. The first three are almost certainly registry/admin actions with no OCR surface (Not-OCR-suitable), but Upload/Reupload Modal Dasar is explicitly flagged as the sibling high-volume, year-sharded, notaris-facing proof-of-capital-deposit upload (
tbl_upload_modal_dasar_YYYY) — a genuine bukti-setor OCR candidate that was not deep-read and should be the next flow investigated, given the PoC already has a Bukti Setor extractor.
Recommended next discovery: deep-read Upload/Reupload Modal Dasar (potential high-volume, high-reuse win) and confirm the three Perubahan sub-jenis are fully subsumed by the existing PERUBAHAN_PT flow.