Modul Permohonan

Spesifikasi Perilaku & Alur

Skenario 1: Membuat Permohonan atas Kuasa Pemohon (Walk-in)

INFO

presumption: Admin telah terautentikasi dan memiliki izin MANAGE_ORDERS

[!example]- User Story 1: Inisiasi Permohonan Sebagai Admin,
Saya ingin membuat permohonan baru untuk pelanggan yang datang langsung atau melalui komunikasi manual (WA/Email),
Agar permohonan mereka dapat diproses secara digital di sistem.
Acceptance Criteria:
Admin dapat mengakses tombol "Buat Permohonan Baru" di dashboard internal.
Sistem mencatat sumber permohonan (langsung/WA/Email) sebagai metadata.

Diagram ini menggambarkan bagaimana Admin membuat permohonan baru atas permintaan pemohon (walk-in / manual) dengan formulir bertahap (wizard).

(Sequence Diagram) %% sequence diagram with mermaid.js syntax %% (Flowchart Diagram) %% flowchart with mermaid.js syntax if needed %%

SKENARIO 1.1: Memilih pelayanan pada submenu pelayanan

[!example]- User Story 2: Konfigurasi Pelayanan dengan Preset Sebagai Admin,
Saya ingin memilih preset pelayanan dan mengisi formulir digital sesuai kebutuhan pelanggan,
Agar konfigurasi layanan menjadi konsisten dan efisien.
Acceptance Criteria:
Admin dapat memilih dari daftar preset pelayanan yang tersedia.
Formulir digital menampilkan field berdasarkan preset yang dipilih, meliputi:
Data Umum & Data Penghadap.
Objek Pajak (jika relevan).
Daftar Tugas (Tasks) yang terisi otomatis.
Konfigurasi Tagihan & Biaya.
Daftar Syarat Berkas (Requirement List).
Semua field wajib terisi sebelum permohonan disimpan.

Aktor	Admin & Sistem
Rincian	Given Admin mengakses submenu pertama yaitu pelayanan pada formulir permohonan baru When Admin memilih salah satu pelayanan yang dituju Then Sistem menyimpan detail pelayanan ke dalam state fromulir sehingga formulir tugas, biaya, dan syarat berkas terisi otomatis

- Feature Details

[!ABSTRACT]- Data Type Definitions

type Service = {
  id: string;
  name: string;
  chargeAppFee: boolean;
  paymentMode: 'POSTPAY' | 'PREPAY' | 'DOWNPAYMENT';
  description?: string | null;
  category: 'NOTARIS' | 'PPAT';
  coverFileId?: string | null;
  createdAt: Date;
  updatedAt: Date;
};

[!ABSTRACT]- Data Operations Operasi data terbatas pada pembacaan (READ) daftar layanan yang tersedia. Tidak ada mutasi data pada tahap ini selain penyimpanan state lokal di sisi klien.

[!ABSTRACT]- API Endpoints
GET /services
Query Params: ?category={NOTARIS|PPAT}&limit={number}&offset={number}
Response: Array<Service>
Description: Mengambil daftar layanan yang tersedia untuk dipilih oleh Admin.

[!ABSTRACT]- UI Screens
Service Selection Grid/List:
Menampilkan kartu-kartu layanan dengan Nama, Deskripsi singkat, dan Kategori.
Fitur pencarian (Search bar) untuk memfilter layanan berdasarkan nama.
Dropdown filter untuk kategori (Notaris/PPAT).
Indikator visual untuk layanan yang aktif/populer (jika ada).

[!ABSTRACT]- Business Rules
Hanya layanan dengan status aktif (jika ada flag status) yang ditampilkan.
Admin dengan role tertentu mungkin hanya bisa melihat kategori layanan tertentu (RBAC MANAGE_SERVICES vs MANAGE_ORDERS).
Jika layanan memerlukan pembayaran dimuka (PREPAY), UI harus memberikan indikasi visual kepada Admin.

[!ABSTRACT]- Test Cases 4. TC-1.1-01: Verifikasi daftar layanan muncul sesuai dengan data di database. 5. TC-1.1-02: Verifikasi filter kategori 'NOTARIS' hanya menampilkan layanan notaris. 6. TC-1.1-03: Verifikasi pemilihan layanan menyimpan ID layanan ke state aplikasi/local storage. 7. TC-1.1-04: Verifikasi respons UI saat layanan tidak ditemukan (Empty State).

SKENARIO 1.2: Melengkapi formulir permohonan

- Rincinan *behavior* formulir permohonan

Submenu selanjutnya adalah Informasi Umum, Objek Pajak (opsional), Para Pihak, Tagihan, Penugasan, dan Syarat Berkas. Pemilihan pelayanan sebelumnya melengkapi detail tagihan, penugasan, dan syarat berkas dengan preset yang telah diatur. Setiap perubahan state memanggil fungsi bertugas untuk menyimpan state ke dalam localStorage sebagai draft.

- Alur Transisi Status Permohonan

Status tidak diatur secara manual oleh admin. Perubahan status ditentukan dari opsi pembayaran pada submenu tagihan dan asal pembuatan. Jika admin memilih PREPAY atau DOWNPAYMENT maka status awal menjadi PENDING_PAYMENT. Jika pembayaran POSTPAY maka status awalnya ACCEPTED. Jika permohonan dibuat dari portal pelanggan, maka status awalnya pasti selalu PENDING_VALIDATION lalu diikuti oleh transisi sebelumnya berdasarkan opsi pembayaran.

Aktor	Admin & Sistem
Rincian	Given Admin mengakses submenu selanjutnya formulir permohonan baru When Admin melengkapi formulir selanjutnya Then Sistem menyimpan detail formulir yang telah dilengkapi untuk dikirimkan ke server melalui API nantinya.

- Feature Details

[!ABSTRACT]- Data Type Definitions

type Identity = {
  id: string;
  nik: string;
  name: string;
  address: string;
  // ... (prop lain sesuai schema)
};

type OrderDraft = {
  serviceId: string;
  applicant?: Identity; // atau reference ID
  // ... field draft lainnya
};

[!ABSTRACT]- Data Operations Operasi utama adalah penyimpanan state formulir secara lokal (WRITE to localStorage). Pembacaan data (READ) dilakukan saat mencari identitas penghadap yang sudah ada.

[!ABSTRACT]- API Endpoints
POST /orders/draft (Opsional, jika draft disimpan di server)
Body: Partial<Order>
GET /identities/search
Query: q={nik_or_name}
Description: Autocomplete untuk mencari data penghadap yang sudah ada.

[!ABSTRACT]- UI Screens
Multi-step Wizard:
Step 1: Data Umum (Judul, Deskripsi, Tanggal Kickoff/Deadline).
Step 2: Data Subjek (Penghadap/Applicant). Form input dengan fitur pencarian NIK.
Step 3: Data Objek (Jika relevan).

[!ABSTRACT]- Business Rules
Auto-save: Setiap perubahan input harus memicu penyimpanan ke localStorage untuk mencegah kehilangan data.
Validation: Pindah antar step hanya diizinkan jika field mandatory pada step saat ini sudah valid.
NIK Uniqueness: Jika input NIK baru, sistem akan mengecek apakah NIK sudah terdaftar. Jika ya, tawarkan untuk autofill.

[!ABSTRACT]- Test Cases 4. TC-1.2-01: Verifikasi perpindahan step validasi (Next button disabled jika form kosong). 5. TC-1.2-02: Verifikasi fitur resume (refresh halaman, data form tetap ada). 6. TC-1.2-03: Verifikasi pencarian identitas existing berhasil mengisi form otomatis.

SKENARIO 1.2.1: Mengatur detail tagihan

- Pengaturan Pajak

Jika sebelumnya admin mengisi objek pajak. Maka ditampilkan opsi untuk menambahkan rincian pajak seperti BPHTB, PPN dan lain-lainnya.

[!example]- User Story 3: Opsi Biaya Layanan Aplikasi Sebagai Admin,
Saya ingin memilih apakah akan mengenakan biaya layanan aplikasi atau tidak,
Agar dapat menyesuaikan dengan kebijakan atau kesepakatan dengan pelanggan.
Acceptance Criteria:
Terdapat toggle atau checkbox "Kenakan Biaya Layanan Aplikasi" pada formulir.
Jika diaktifkan, biaya layanan ditambahkan ke total tagihan.
Jika dinonaktifkan, biaya layanan tidak dimasukkan dalam perhitungan.

[!example]- User Story 4: Pemilihan Skema Pembayaran Sebagai Admin,
Saya ingin memilih skema pembayaran (Prabayar atau Pascabayar),
Agar status permohonan dapat ditentukan secara otomatis dan proses tagihan sesuai ketentuan.
Acceptance Criteria:
Terdapat opsi pilihan "Prabayar (Prepay)" dan "Pascabayar (Postpay)".
Jika memilih Prabayar, status permohonan otomatis menjadi PENDING_PAYMENT.
Jika memilih Pascabayar, status permohonan otomatis menjadi ACCEPTED.

Aktor Admin & Sistem

Rincian Given Admin menavigasi ke submenu rincian tagihan
When Admin mengatur rincian tagihan dengan cara
- Memilih opsi pembayaran
- Mengatur rincian biaya (Menghapus, Menambahkan, dan Mengubah)
Then Sistem menampilkan antarmuka untuk memilih pembayaran, tabel dinamis, dan switch button untuk memasuki biaya aplikasi ke dalam tagihan (sehingga biaya aplikasi dibebankan ke pelanggan). Perubahan disimpan ke dalam state halaman formulir permohonan baru.

Aktor	Admin & Sistem
Rincian	Given Admin menavigasi ke submenu rincian tagihan When Admin mengatur rincian tagihan dengan cara - Memilih opsi pembayaran - Mengatur rincian biaya (Menghapus, Menambahkan, dan Mengubah) Then Sistem menampilkan antarmuka untuk memilih pembayaran, tabel dinamis, dan switch button untuk memasuki biaya aplikasi ke dalam tagihan (sehingga biaya aplikasi dibebankan ke pelanggan). Perubahan disimpan ke dalam `state` halaman formulir permohonan baru.

- Feature Details

[!ABSTRACT]- Data Type Definitions

type BillItem = {
  description: string;
  amount: number;
};

type BillConfig = {
  paymentMode: 'PREPAY' | 'POSTPAY' | 'DOWNPAYMENT';
  chargeAppFee: boolean;
  items: BillItem[];
};

[!ABSTRACT]- Data Operations Melibatkan manipulasi array lokal untuk item tagihan (CREATE, UPDATE, DELETE on local state). Pembacaan (READ) dilakukan jika mengambil template biaya dari server.

[!ABSTRACT]- API Endpoints
Tidak ada interaksi API langsung saat mengedit, data dikirim sebagai bagian dari payload akhir POST /orders.
GET /cost-templates?serviceId={id} (Untuk memuat preset biaya).

[!ABSTRACT]- UI Screens
Billing Configuration Panel:
Toggle: "Beferbankan Biaya Aplikasi ke Pelanggan".
Radio Group: Mode Pembayaran (Prabayar / Pascabayar / DP).
Table: Daftar item biaya (Deskripsi, Jumlah). Bisa tambah/edit/hapus row.
Summary: Total tagihan yang dihitung otomatis.

[!ABSTRACT]- Business Rules
App Fee Injection: Jika toggle "Biaya Aplikasi" aktif, item biaya tambahan otomatis ditambahkan ke list/kalkulasi akhir, namun mungkin tidak bisa diedit manual nilainya (tergantung config sistem).
Status Inference: Pilihan Payment Mode akan menentukan status awal Order (PENDING_PAYMENT vs ACCEPTED).
Total Calculation: Total harus selalu sum(items) + (chargeAppFee ? appFeeAmount : 0).

[!ABSTRACT]- Test Cases 4. TC-1.2.1-01: Toggle Biaya Aplikasi mengubah Total Tagihan. 5. TC-1.2.1-02: Menambah item biaya baru merefleksikan perubahan di Total. 6. TC-1.2.1-03: Memilih 'Prabayar' memberikan indikasi visual status 'Pending Payment' di ringkasan.

SKENARIO 1.2.2: Mengatur syarat berkas

[!example]- User Story 5: Upload Berkas Awal oleh Admin Sebagai Admin,
Saya ingin diarahkan ke halaman detail permohonan untuk mengunggah berkas setelah konfigurasi selesai,
Agar dokumen pendukung dapat segera dikumpulkan.
Acceptance Criteria:
Setelah menyimpan permohonan, sistem mengalihkan ke halaman detail permohonan.
Pada halaman detail, terdapat bagian "Directory" dengan fungsi upload berkas.
Admin dapat mengunggah file dari perangkat lokal.

[!ABSTRACT]- Jenis berkas Admin dapat mengupload berbagai jenis berkas yang tidak dibatasi. Namun ada 2 jenis berkas khusus yang digunakan dalam aplikasi ini. Yaitu, application/vnd.notaryos.directory, application/vnd.notaryos.form. Jenis directory tidak memiliki file. Jenis form disimpan dengan 2 cara yaitu dengan format JSON sederhana ke dalam atribut content di mana keys adalah kolom input, type adalah jenis input, dan value adalah isiannya. Setiap perubahan didampingi juga perubahan pada bentuk HTML nya di filesystem secara reflective . Sehingga notaris bisa membuka formulir itu dengan nyaman.

[!ABSTRACT]- Mekanisme upload Mekanisme bulk upload ini sedikit rumit karena pengguna dapat mengupload bentuk struktur yang rekursif sekaligus. Sedangkan ID setiap file harus dibuat dari sistem. Oleh karena itu, dibutuhkan atribut pendukung yang dinamakan tags. Nilai atribut ini diatur dari sisi client dengan nilai randomUUID. Sehingga client hanya perlu mengupload file memacu pada atribut yang telah diatur ini tidak peduli sedalam apa struktur directorynya.

Aktor	Admin & Sistem
Rincian	Given Admin menavigasi ke submenu rincian syarat berkas When Admin mengatur syarat berkas dengan menambahkan, mengubah, dan menghapus rincian yang sudah diatur sebelumnya pada pelayanan. Then Sistem akan menyusun objek rekursif yang membentuk struktur direktori yang telah diatur dengan tampilan file system.

- Feature Details

[!ABSTRACT]- Data Type Definitions

type FileNode = {
  id: string; // client-side UUID
  name: string;
  type: 'FILE' | 'FOLDER';
  mimetype: string; // 'application/vnd.notaryos.directory' for folders
  children?: FileNode[];
  tags?: string; // randomUUID for mapping uploads
};

[!ABSTRACT]- Data Operations Manipulasi struktur pohon direktori secara lokal (CREATE, DELETE nodes). READ untuk mengambil template struktur folder awal berdasarkan layanan.

[!ABSTRACT]- API Endpoints
POST /orders (Payload akhir berisi struktur file ini sebagai metadata).
GET /folder-templates?serviceId={id} (Memuat struktur awal).

[!ABSTRACT]- UI Screens
File System Tree View:
Menampilkan hierarki folder dan file.
Ikon folder (bisa expand/collapse).
Context menu: "Add Folder", "Add File Request", "Rename", "Delete".
Kolom "Tags/ID" (hidden atau debug mode) untuk mapping upload fisik nanti.

[!ABSTRACT]- Business Rules
Recursive Structure: Sistem harus mendukung kedalaman folder yang tidak dibatasi (N-level).
Unique Tags: Setiap node file yang mengharapkan upload fisik harus memiliki tags unik (UUID) yang di-generate di client saat node dibuat.
Virtual Types: Tipe application/vnd.notaryos.directory dan application/vnd.notaryos.form ditangani khusus sebagai container, bukan file fisik.

[!ABSTRACT]- Test Cases 4. TC-1.2.2-01: Menambahkan sub-folder dan file request berfungsi dalam struktur tree. 5. TC-1.2.2-02: Menghapus parent folder menghapus seluruh anak-anaknya (cascade delete di UI state). 6. TC-1.2.2-03: Verifikasi struktur JSON yang dihasilkan sesuai dengan spesifikasi rekursif saat submit.

SKENARIO 1.3: Upload & Mobile Handoff via QR code.

[!example]- User Story 6: Akses Mobile via QR Code untuk Petugas Lapangan Sebagai Admin,
Saya ingin halaman detail permohonan menampilkan QR code unik,
Agar petugas lapangan dapat memindainya dan langsung mengunggah berkas via mobile tanpa login ulang.
Acceptance Criteria:
QR code ditampilkan di halaman detail permohonan (bagian Directory).
QR code mengarah ke URL unik yang terhubung dengan permohonan tersebut.
Petugas lapangan yang terautentikasi dapat memindai QR dan diarahkan ke halaman mobile untuk upload.

[!example]- User Story 7: Unggah Berkas Langsung via Mobile oleh Petugas Lapangan Sebagai Petugas Lapangan,
Saya ingin memindai QR code di permohonan dan diarahkan ke halaman mobile untuk mengunggah foto/scan berkas fisik,
Agar dapat mengumpulkan dokumen langsung dari lokasi pelanggan tanpa menggunakan PC.
Acceptance Criteria:
Petugas lapangan yang sudah login di aplikasi mobile dapat memindai QR code.
Sistem membuka halaman upload khusus untuk permohonan tersebut.
Petugas dapat memotret/scan dokumen fisik dan mengunggahnya langsung ke sistem.
Tidak diperlukan login ulang di perangkat lain.

Aktor	Sistem, Admin, & Petugas Lapangan
Rincian	Given Admin telah menyimpan permohonan baru dan sistem mengalihkan ke halaman detail permohonan bagian Directory When Admin mengunggah berkas awal (jika ada) dan melihat QR Link yang ditampilkan And Petugas Lapangan yang terautentikasi memindai QR code tersebut Then Sistem mengalihkan Petugas ke tampilan mobile khusus untuk memotret/scan berkas fisik dan mengunggahnya langsung ke sistem tanpa perlu login ulang di PC.

Aktor

Sistem, Admin, & Petugas Lapangan

Rincian

Given Admin telah menyimpan permohonan baru dan sistem mengalihkan ke halaman detail permohonan bagian Directory
When Admin mengunggah berkas awal (jika ada) dan melihat QR Link yang ditampilkan
And Petugas Lapangan yang terautentikasi memindai QR code tersebut
Then Sistem mengalihkan Petugas ke tampilan mobile khusus untuk memotret/scan berkas fisik dan mengunggahnya langsung ke sistem tanpa perlu login ulang di PC.

- Feature Details

[!ABSTRACT]- Data Type Definitions

// Struktur untuk representasi berkas dalam direktori permohonan
type FileNode = {
  id: string;                   // UUID unik
  orderId: string;              // ID permohonan
  name: string;                 // Nama file/folder
  type: 'FILE' | 'FOLDER';      // Tipe node
  mimetype: string;             // MIME type, 'application/vnd.notaryos.directory' untuk folder
  path: string;                 // Path relatif dalam direktori
  uploadToken?: string;         // Token unik untuk mapping upload (khusus file)
  uploadedBy?: string;          // ID user yang mengunggah
  uploadedAt?: Date;            // Waktu upload
  fileSize?: number;            // Ukuran file dalam bytes
  status: 'PENDING' | 'UPLOADED' | 'VERIFIED'; // Status berkas
  children?: FileNode[];        // Anak-anak (untuk folder)
};

// Token akses QR code
type QRToken = {
  token: string;                // Token unik (terenkripsi)
  orderId: string;              // ID permohonan terkait
  userId?: string;              // ID petugas yang diotorisasi (jika sudah login)
  expiresAt: Date;              // Waktu kedaluwarsa token
  scope: 'UPLOAD' | 'VIEW';     // Hak akses token
};

[!ABSTRACT]- Data Operations Operasi WRITE intensif untuk upload berkas (multipart/form-data) ke storage server. READ untuk mengambil struktur direktori terkini dan status upload. Generasi token QR (CREATE) terjadi di sisi server namun dipicu oleh flow ini.

[!ABSTRACT]- API Endpoints
GET /orders/{orderId}/directory
Mendapatkan struktur direktori dan metadata permohonan.
Response: { order: Order, directory: FileNode[], qrToken: string }
POST /orders/{orderId}/upload
Upload berkas ke direktori permohonan (untuk Admin).
Headers: Authorization: Bearer <admin_token>
Body: multipart/form-data dengan field path dan file
GET /qr/upload/{token}
Endpoint akses via QR code. Verifikasi token dan redirect ke halaman mobile upload.
Query Params: ?platform=ios|android (opsional untuk optimasi UI)
POST /mobile/upload
Upload dari perangkat mobile (dilindungi token sesi mobile).
Headers: X-QR-Token: <token>
Body: { orderId: string, path: string, file: File }

[!ABSTRACT]- UI Screens
Halaman Detail Permohonan - Bagian Directory (Admin View):
Tree view struktur folder dengan status tiap node
Tombol "Upload File" dan "Create Folder"
Panel QR Code dengan:
QR gambar yang bisa diunduh
Short link untuk berbagi
Informasi kedaluwarsa token
Log aktivitas upload
Halaman Mobile Upload (Petugas Lapangan View):
Header: Nama permohonan dan petunjuk singkat
Preview kamera langsung dengan overlay panduan
Tombol: "Ambil Foto", "Pilih dari Galeri", "Upload"
Progress bar saat upload
Konfirmasi sukses/gagal

[!ABSTRACT]- Business Rules
Token QR Code:
Dibuat otomatis saat permohonan berstatus ACCEPTED atau PENDING_PAYMENT
Masa berlaku: 7 hari dari pembuatan, dapat diperpanjang oleh Admin
Token menjadi invalid setelah permohonan COMPLETED atau CANCELLED
Keamanan Upload:
Admin dapat upload kapan saja melalui dashboard
Petugas lapangan hanya dapat upload jika:
Token QR valid dan belum kedaluwarsa
Petugas telah login di aplikasi mobile
Permohonan masih dalam status aktif
File yang diupload divirus scan terlebih dahulu
Struktur Direktori:
Root folder dibuat otomatis sesuai preset layanan
Admin dapat membuat subfolder tambahan
Nama file otomatis dinormalisasi: {timestamp}_{originalName}

[!ABSTRACT]- Test Cases 4. TC-UPLOAD-01: Admin berhasil diarahkan ke halaman directory setelah membuat permohonan 5. TC-UPLOAD-02: QR code berhasil ditampilkan dan dapat di-scan 6. TC-UPLOAD-03: Token QR invalid jika sudah kedaluwarsa 7. TC-UPLOAD-04: Petugas lapangan terautentikasi berhasil upload via mobile setelah scan QR 8. TC-UPLOAD-05: File yang diupload muncul di struktur direktori dengan status UPLOADED 9. TC-UPLOAD-06: Upload gagal jika melebihi ukuran maksimal (10MB per file)

Skenario 2: Membuat Permohonan Melalui Client Portal

Presumption: pengguna telah terautentikasi dan bio data telah divalidasi`

SKENARIO 2.1: Discovery & Routing

[!example]- User Story 8: Mencari notaris yang siap melayani Sebagai Pelanggan,
Saya ingin halaman utama menampilkan Listing notaris,
Agar saya dapat lanjut mengajukan permohonan berdasarkan pelayanan yang saya inginkan.
Acceptance Criteria:
Menu utama yang menampilkan Listing Notaris
Pencarian berdasarkan pelayanan
Pencarian berdasarkan daerah

Aktor	Sistem, Pelanggan
Rincian	Given Pelanggan telah registrasi dan terautentikasi When Pelanggan navigasi ke menu utama yaitu halaman daftar notaris terdekat. Then Sistem menampilkan Listing notaris yang tersedia When Pelanggan memilih notaris Then Sistem navigasi ke halaman selanjutnya yaitu pemilihan Layanan dan menyimpan pilihan pengguna ke dalam state Routing ke notaris tersebut

- Feature Details

[!ABSTRACT]- Data Type Definitions

// Matches 'offices' table in control.schema.ts
type Office = {
  id: string;           // UUID
  address: string;
  email: string;        // Unique, Contact Email
  phone?: string;       // Optional Contact Phone
  domain: string;       // Unique Subdomain/Handle (e.g., "notaris-ani")
  tunnelId?: string;    // Networking Tunnel ID
  createdAt: Date;
  updatedAt: Date;
};

[!ABSTRACT]- Data Operations
READ: Mengambil daftar notaris dari Server Pusat.
WRITE (Client-side): Menyimpan office.domain atau office.id ke dalam State Aplikasi (Client Routing) untuk menentukan API endpoint tujuan pada langkah berikutnya.

[!ABSTRACT]- API Endpoints
GET /offices
Query: q={search_term}, limit={n}, offset={n}
Response: Array<Office>
Description: Pencarian kantor notaris berdasarkan domain, alamat, atau email.

[!ABSTRACT]- UI Screens
Notary Discovery List:
Search Bar (Placeholder: "Cari nama atau alamat kantor...").
Card List Item:
Judul: Domain/Nama Kantor.
Subjudul: Alamat Lengkap.
Kontak: Email & Phone.
Action: Tombol "Pilih Kantor".

[!ABSTRACT]- Business Rules
Hanya kantor dengan status aktif (jika ada flag di sistem kontrol) yang dapat dipilih.
Pemilihan kantor mengubah konteks aplikasi (API Base URL) ke lingkungan notaris tersebut (via subdomain atau tunnel).

[!ABSTRACT]- Test Cases 4. TC-2.1-01: Search mengembalikan hasil yang sesuai dengan address atau domain. 5. TC-2.1-02: Klik "Pilih Kantor" menyimpan domain ke sub-state routing.

SKENARIO 2.2: Pemilihan Layanan

[!example]- User Story 9: Memilih Layanan dari Katalog Notaris Sebagai Pelanggan, Saya ingin melihat daftar layanan yang disediakan oleh notaris yang saya pilih, Agar saya dapat mengajukan permohonan yang spesifik.

Aktor	Pelanggan & Sistem
Rincian	Given Pelanggan telah memilih notaris (routing state set) When Pelanggan melihat katalog layanan Then Sistem menampilkan layanan yang tersedia di server notaris tersebut.

- Feature Details

[!ABSTRACT]- Data Operations
READ: Mengambil daftar layanan (services) dari Server Notaris (bukan Server Pusat).

[!ABSTRACT]- API Endpoints
GET [Notary_URL]/services
Response: Array<Service> (Sama dengan definisi di Skenario 1.1)

SKENARIO 2.3: Peninjauan Syarat

[!example]- User Story 10: Meninjau Persyaratan Layanan Sebagai Pelanggan, Saya ingin melihat detail persyaratan dokumen dan estimasi waktu, Agar saya bisa mempersiapkan berkas sebelum memulai permohonan.

Aktor	Pelanggan & Sistem
Rincian	Given Pelanggan memilih satu layanan When Pelanggan membuka halaman detail layanan Then Sistem menampilkan deskripsi, estimasi waktu, dan daftar syarat berkas.

- Feature Details

[!ABSTRACT]- Business Rules
Cost Privacy: Sistem DILARANG menampilkan rincian struktur biaya internal (HPP, Jasa Notaris, dll) kepada pelanggan. Hanya tampilkan Total Estimasi (jika dikonfigurasi public) atau sembunyikan informasi biaya sepenuhnya pada tahap ini.
Requirement Consistency: Daftar syarat harus sesuai dengan konfigurasi Requirement List yang diatur Admin Notaris tersebut.

SKENARIO 2.4: Konfirmasi Awal (Virtual Object)

[!example]- User Story 11: Memulai Permohonan (Drafting) Sebagai Pelanggan, Saya ingin mengonfirmasi niat saya untuk mengajukan permohonan, Agar sistem menyiapkan ruang kerja (workspace) untuk saya mengunggah berkas.

Aktor	Pelanggan & Sistem
Rincian	Given Pelanggan di halaman detail layanan When Pelanggan menekan tombol "Ajukan Permohonan" Then Sistem membuat Objek Pelayanan Virtual di penyimpanan lokal peramban.

- Feature Details

[!ABSTRACT]- Data Operations
CREATE (Client-side): Membuat entry baru di localStorage atau IndexedDB.
Objek Virtual: Berfungsi sebagai holding area untuk form data dan file blobs sebelum dikirim ke server.

SKENARIO 2.5: Pemberkasan Mandiri

[!example]- User Story 12: Melengkapi Data dan Berkas Sebagai Pelanggan, Saya ingin mengisi formulir dan mengunggah dokumen syarat secara mandiri, Agar permohonan saya lengkap.

Aktor	Pelanggan & Sistem
Rincian	Given Pelanggan dalam mode pengajuan (Virtual Object aktif) When Pelanggan mengisi form dan upload file Then Sistem menyimpan data tersebut ke objek virtual local.

- Feature Details

[!ABSTRACT]- Business Rules
Unlocked State: Selama masih di tahap ini (belum submit), status berkas adalah UNLOCKED. Pelanggan bebas menghapus, mengganti, atau menambah file.
Validation: Validasi kelengkapan (file mandatory) dilakukan di sisi client sebelum tombol kirim diaktifkan.

SKENARIO 2.6: Finalisasi & Pengiriman

[!example]- User Story 13: Mengirim Permohonan Sebagai Pelanggan, Saya ingin mengirimkan seluruh data dan berkas yang sudah saya lengkapi, Agar notaris dapat mulai memproses permohonan saya.

Aktor	Pelanggan & Sistem
Rincian	Given Pelanggan telah melengkapi semua syarat wajib When Pelanggan menekan tombol "Kirim Permohonan" Then Sistem mengunggah paket data dari objek virtual ke Server Notaris dan menetapkan status awal.

- Feature Details

[!ABSTRACT]- Data Operations
WRITE (Server): POST /orders (payload lengkap termasuk multipart/files).

[!ABSTRACT]- Business Rules
Initial Status: Setelah berhasil terkirim, status permohonan di server di-set menjadi PENDING_VALIDATION.
Virtual Cleanup: Setelah sukses response 200 OK, objek virtual di local storage harus dibersihkan untuk menghemat memori.

[!ABSTRACT]- API Endpoints
POST [Notary_URL]/orders
Payload: Data pemohon + Opsi Layanan + File-file syarat.

%% Rincian ditulis mengikuti format Given-When-Then yang diadopsi dari pendekatan Behavior-Driven-Development (BDD).

Diagram yang pertama menggambarkan prilaku antara sistem dan pengguna. Diagram kedua menampilkan diagram flowchart yang menggambarkan cara kerja internal dari skenario tersebut.

Modul Permohonan ​

Spesifikasi Perilaku & Alur ​

Skenario 1: Membuat Permohonan atas Kuasa Pemohon (Walk-in) ​

Skenario 2: Membuat Permohonan Melalui Client Portal ​

Diagram yang pertama menggambarkan prilaku antara sistem dan pengguna. Diagram kedua menampilkan diagram flowchart yang menggambarkan cara kerja internal dari skenario tersebut. ​

Modul Permohonan

Spesifikasi Perilaku & Alur

Skenario 1: Membuat Permohonan atas Kuasa Pemohon (Walk-in)

Skenario 2: Membuat Permohonan Melalui Client Portal

Diagram yang pertama menggambarkan prilaku antara sistem dan pengguna. Diagram kedua menampilkan diagram flowchart yang menggambarkan cara kerja internal dari skenario tersebut.