ALUR KERJA UTAMA: NOTARYOS (MASTER BLUEPRINT)

Konteks & Aktor

• Actors: Pelanggan, Portal Pelanggan, Sistem Notaris, Sistem Pusat, Petugas/Admin, dan Notaris/Owner.

• Context: Arsitektur sistem adalah federated network di mana masing-masing notaris memiliki servernya sendiri (Local Node) dan subdomainnya sendiri. Client Portal dan Sistem Pusat harus akurat dalam menentukan milik siapa permohonan tersebut atau aktivitas lainnya dalam jaringan (Routing yang presisi).

• Assumption: Notaris telah melakukan konfigurasi awal: mengatur jenis pelayanan (Service Presets), mengundang petugas, serta mengatur peran (Roles) dan hak akses masing-masing peran.

1. TAHAP PENGAJUAN (SUBMISSION)

Skenario A: Jika Diajukan oleh Admin (Walk-in / Manual)

• 1.1 Inisiasi Permohonan:

  Admin membuat permohonan baru pada dashboard internal atas permintaan pelanggan yang datang langsung atau via komunikasi manual (WA/Email).

• 1.2 Konfigurasi Pelayanan:

  Admin memilih Preset Pelayanan, lalu mengisi formulir digital yang mencakup:

  • Data Umum & Data Penghadap.

  • Objek Pajak (jika relevan).

  • Daftar Tugas (Tasks) yang otomatis terisi dari preset.

  • Konfigurasi Tagihan & Biaya.

  • Syarat Berkas (Requirement List).

  • Opsi Admin: Admin diberikan pilihan untuk mengenakan biaya layanan aplikasi atau tidak.

  • Opsi Pembayaran: Admin memilih skema Prabayar (Prepay) atau Pascabayar (Postpay).

  • Status Implisit: Ditentukan oleh opsi pembayaran PENDING_PAYMENT (Prepay) dan ACCEPTED (Postpay)

• 1.3 Upload & Mobile Handoff:

  Sistem mengalihkan ke halaman detail permohonan bagian Directory agar Admin dapat mengunggah berkas.

  • Fitur QR Link: Halaman ini menampilkan Link QR khusus.

  • Fungsi: Jika Petugas Lapangan (yang telah terautentikasi) memindai QR ini, mereka akan dialihkan ke tampilan mobile khusus untuk memotret/scan berkas fisik pelanggan langsung dari HP dan mengunggahnya ke sistem tanpa perlu login ulang di PC.

Skenario B: Jika Diajukan oleh Pelanggan (Self-Service)

• 1.1 Discovery & Routing:

  Pelanggan mengakses Portal Pusat dan memilih notaris terdekat atau spesifik.

  • System Logic: Daftar notaris diambil dari Server Pusat. Server Pusat mengembalikan data notaris lengkap dengan Subdomain-nya. Sistem kemudian mengarahkan pelanggan ke lingkungan server notaris tersebut.

• 1.2 Pemilihan Layanan:

  Pelanggan memilih jenis pelayanan yang diinginkan dari katalog notaris tersebut.

• 1.3 Peninjauan Syarat:

  Client Portal menampilkan detail pelayanan lengkap beserta persyaratan berkas yang wajib dipenuhi.

  • Catatan: Sistem JANGAN menampilkan rincian biaya internal (HPP/Jasa Notaris) kepada pelanggan di tahap ini.

• 1.4 Konfirmasi Awal (Virtual Object):

  Pelanggan melakukan konfirmasi di halaman detail pelayanan.

  • System Logic: Sistem Notaris membuat Objek Pelayanan Virtual di local storage / IndexedDB. Objek ini berfungsi sebagai wadah sementara untuk menampung data sebelum disubmit.

• 1.5 Pemberkasan Mandiri:

  Pelanggan WAJIB mengisi formulir data diri dan mengunggah seluruh persyaratan berkas yang diminta ke dalam objek virtual tersebut.

  • Status Berkas: UNLOCKED (Pelanggan masih dapat menghapus atau mengganti file jika salah upload).

• 1.6 Finalisasi & Pengiriman:

  Pelanggan mengonfirmasi kelengkapan berkas dan menekan tombol kirim.

  • System Logic: Client Portal mengirimkan paket data lengkap ke server notaris yang tepat sesuai subdomain. Status permohonan menjadi PENDING_VALIDATION.

Logika Percabangan Skema Bayar

• [Jika Admin Memilih Pascabayar]:

  • 1.4.1 Penjadwalan Langsung: Sistem menetapkan status permohonan sebagai ACCEPTED dan segera memberikan pilihan kepada Admin untuk menjadwalkan Kickoff (Tanggal Mulai) permohonan. Opsi penjadwalan:

    • VIP: Segera ditangani (Kickoff = Sekarang).

    • Weekly: Masuk ke daftar antrean mingguan terencana.

    • Custom: Memilih tanggal spesifik.

• [Jika Admin Memilih Prabayar]:

  • Logika Pending Order: Sistem menampilkan status permohonan PENDING_PAYMENT atau PENDING_VALIDATION.

  • Logika Transisi: Jika permohonan dibuat oleh pelanggn maka admin harus validasi lagi berkasnya. Setelah berkas valid dan service.pay_order = PREPAY, maka status tertahan di PENDING_PAYMENT.

  • Hak Akses: Jika status PENDING_PAYMENT, ada tugas belum COMPLETED, dan tagihan UNPAID, maka tautan tagihan hanya ditampilkan jika petugas memiliki hak akses MANAGE_BILLS. Permohonan dengan status PENDING_PAYMENT dan tidak ada tugas yang tersisa tidak ditampilkan di sini.

  • Logika Selesai Bayar: Jika bill.status = PAID dan order.status = PENDING_PAYMENT, sistem menampilkan status Lunas dan tombol untuk Mengatur Jadwal.

  • Logika Validasi: Jika service.pay_order = PREPAY | order.pay_order = PREPAY dan order.status = PENDING_VALIDATION maka validasi ini mengubah status ke PENDING_PAYMENT dan penjadwalan hanya bisa setelah bill.status = PAID. PENDING_VALIDATION hanya diajukan dari Client Portal.

  • 1.4.2 Penjadwalan Pasca-Bayar: Setelah Admin menekan tombol atur jadwal, aplikasi menampilkan modal penjadwalan (VIP/Weekly/Custom). Secara implisit, status permohonan diubah menjadi ACCEPTED. Sistem mengembalikan petugas ke tabel Pending Order.

2. TAHAP PEMBAYARAN (PAYMENT)

Konteks: Berlaku jika Admin memilih skema pembayaran di awal (Prabayar) dan status permohonan saat ini adalah PENDING_PAYMENT.

• 1.3.1 Distribusi Tagihan:

  Admin dapat mengirimkan akses tagihan ke pelanggan melalui dua cara:

  • Menunjukkan QR Code pada invoice fisik/layar untuk dipindai pelanggan.

  • Mengirimkan tautan Client Portal yang mengarah langsung ke halaman tagihan via pesan teks (WA/Email).

• 1.3.2 Pembayaran Pelanggan:

  Pelanggan menerima tagihan, melakukan pembayaran (Transfer/Cash), dan mengunggah Bukti Pembayaran melalui Client Portal.

• 1.3.3 Validasi Admin:

  Admin memeriksa bukti pembayaran yang masuk dan menentukan validitasnya.

  • [Skenario Invalid]:

    • 1.3.3.1 Peringatan: Sistem akan memperingati pelanggan di Client Portal melalui notifikasi sistem dan teks peringatan bahwa pembayaran ditolak/salah. Pelanggan diminta upload ulang.

  • [Skenario Valid]:

    • 1.3.3.2 Konfirmasi Lunas: Sistem mengirimkan notifikasi sukses ke pelanggan.

    • System Action: Mengubah status tagihan menjadi PAID (Lunas).

    • System Action: Jika skema Pascabayar (atau pelunasan akhir), ubah status permohonan jadi COMPLETED. Jika skema Prabayar (awal), ubah status permohonan jadi ACCEPTED (Siap Aktivasi).

3. TAHAP AKTIVASI PERMOHONAN (ACTIVATION)

TRIGGER: INTEGRITY LOCK #1

Saat Status Permohonan berubah menjadi ACCEPTED, sistem otomatis mengunci (is_locked = true) seluruh file Persyaratan Pelanggan (KTP, KK, Sertifikat) agar tidak dapat dimanipulasi selama pengerjaan.

Distribusi & Akses

• 1.5.1 Distribusi Tugas Otomatis:

  Tugas-tugas (Tasks) dalam permohonan yang telah diaktifkan secara otomatis didistribusikan/ditugaskan (Assigned) ke para petugas sesuai dengan Peran (Role) yang telah ditetapkan masing-masing dalam preset pelayanan.

• 1.5.2 Akses Monitoring Klien:

  Permohonan aktif dapat diakses melalui Tautan Rahasia (Secret Link). Tautan ini dapat ditempelkan pada surat serah terima fisik (sebagai QR) atau dikirimkan langsung oleh Admin. Pelanggan dapat memantau progres permohonan melalui tautan ini di Client Portal tanpa perlu login rumit.

4. TAHAP AKTIVASI TUGAS (TASK KICKOFF)

• 1.6 Pemicu Waktu (Time Trigger):

  Jika waktu saat ini telah memasuki Tanggal Kickoff yang dijadwalkan:

  • Sistem secara otomatis mengaktifkan tugas-tugas awal.

  • Status Permohonan (orders.status) berubah dari ACCEPTED menjadi WIP (Work In Progress).

  • Tugas-tugas pada Tahap Pertama diubah statusnya dari BLOCKED menjadi PENDING.

  • Sistem menetapkan nilai timestamp kickoff.

5. TAHAP PENGERJAAN TUGAS (EXECUTION)

• 1.7 Monitoring:

  Petugas memasuki tahap pengerjaan tugas dan memantau masing-masing Papan Tugas (Kanban/List) mereka.

• 1.8 Konteks Tugas:

  Petugas melihat detail tugas untuk memahami konteks, seperti: Biodata Penghadap, Persyaratan Berkas (yang sudah terkunci), Riwayat Obrolan Petugas sebelumnya, dan Akses Obrolan ke Pemohon.

Sub-Alur: Registrasi & Finalisasi Akta (Gatekeeper)

Prasyarat Sistem (1.9.1): Seluruh tugas pendahulu (Pemberkasan, Pengecekan, Validasi Pajak) berstatus COMPLETED. Tugas Register terbuka (PENDING).

• 1.9.2 Pengambilan Nomor Register (Reservasi):

  Petugas membuka tugas Register.

  • Aksi: Petugas menekan tombol "Ambil Nomor Register".

  • System Logic: Sistem membaca urutan terakhir di database, lalu menetapkan Nomor Baru (misal: No. 10/II/2026) untuk permohonan ini.

  • Status: Nomor ini sekarang terikat pada permohonan ini, namun status register masih DRAFT.

  • Catatan Penting: Di tahap ini, file belum dikunci.

• 1.9.3 Penyusunan Minuta & Upload:

  • Petugas menyalin Nomor Register yang didapat dari sistem (No. 10/...) ke dalam badan file dokumen kerja (Word/PDF).

  • Petugas mengunggah file tersebut sebagai Draft Minuta Akta.

  • Status File: is_locked = false (Petugas masih bisa hapus/upload ulang jika ada salah ketik/revisi).

• 1.9.4 Pengajuan Validasi:

  Setelah yakin draft benar dan nomor sudah tercantum di dalam dokumen:

  • Petugas mengatur atribut public (Apakah QR Code aktif?) dan visibility (Apakah klien bisa download?).

  • Petugas menekan tombol "Ajukan ke Notaris".

  • Status Tugas: Berubah menjadi IN_REVIEW.

  • Status File: Dikunci Sementara (Temporary Lock / Read-Only untuk staf) selama proses review agar tidak berubah saat Notaris sedang memeriksa.

• 1.9.5 Gatekeeper (Persetujuan Notaris):

  Notaris menerima notifikasi dan memeriksa kesesuaian antara Nomor di Sistem dengan Nomor di dalam File Dokumen.

  • [Skenario A: REJECT (Revisi)]

    • Notaris menekan tombol TOLAK + memberikan Catatan (misal: "Typo nama di halaman 2").

    • Status Tugas: Kembali ke PENDING.

    • Status File: is_locked = false (Terbuka kembali untuk diedit staf).

    • Nomor Register: Tetap terikat pada order ini (Tidak hilang).

    • Alur: Petugas kembali ke langkah 1.9.3 (Perbaiki file -> Upload Ulang -> Ajukan lagi).

  • [Skenario B: APPROVE (Finalisasi)]

    • Notaris menekan tombol SETUJU.

    • System Action: Generate QR Code Kriptografi (mengikat hash file final).

    • System Action (LOCK): File Minuta Akta diubah permanen menjadi is_locked = true.

    • Status Register: Menjadi FINAL / PUBLISHED.

    • Status Tugas: Menjadi COMPLETED.

• 1.9.6 Penandatanganan & Arsip Fisik:

  • Petugas mengunduh file yang sudah disetujui Notaris (yang sudah ada nomornya dan ber-QR Code).

  • Dokumen dicetak (Print Out).

  • Dilakukan penandatanganan basah (Penghadap + Saksi + Notaris).

  • (Opsional) Petugas meng-scan halaman tanda tangan dan mengunggahnya sebagai bukti fisik teralisasi (Scan TTD).

Penyelesaian Tahap

• 1.10 Catatan Internal:

  Petugas memberikan komentar di kolom chat internal sebagai catatan tambahan jika diperlukan (Opsional).

• 1.11 Penyelesaian Tugas:

  Petugas memindahkan tugas dari papan PENDING ke papan COMPLETED (jika tidak otomatis).

• 1.12 Unblocking Tahap Selanjutnya:

  Jika semua tugas dalam satu tahap sudah diselesaikan semua, sistem secara otomatis:

  • Mengubah status tugas pada tahap berikutnya dari BLOCKED menjadi PENDING agar siap dikerjakan.

  • Mengatur nilai kickoff untuk tahap tersebut.

6. TAHAP PENGELOLAAN TAGIHAN & PENYELESAIAN (COMPLETION)

• 1.13 Pengecekan Akhir:

  Jika semua tugas telah diselesaikan pada semua tahap (All Tasks COMPLETED):

  • Sistem mengecek status keuangan global order tersebut.

  • [Jika Lunas]: Ubah status permohonan menjadi COMPLETED.

  • [Jika Belum Lunas]: Ubah status permohonan menjadi PENDING_PAYMENT.

• 1.14 Pelunasan Akhir:

  Petugas memeriksa bukti pembayaran akhir dari pelanggan dan menentukan status pembayaran (Valid/Invalid).

• 1.15 Global Completion & Locking:

  Permohonan secara otomatis diubah statusnya menjadi COMPLETED jika tagihan telah lunas.

  • TRIGGER: INTEGRITY LOCK #3 (Global): Sistem memindai dan mengunci seluruh berkas sisa (Bukti bayar, Scan TTD, Chat log) menjadi `is_locked