Penambahan Asset ke Ruangan Aktif (ALK-RGN04)

01Informasi Dokumen

02Daftar Isi

Lihat panel navigasi di samping.

03Quick Overview

Ruangan yang sudah beroperasi bisa ditambah aset lewat dua jalur dalam satu tabel (asset_trx_request_ruangan), dibedakan kolom sumber_pengajuan seperti request karyawan KRY-03-1. Pada Jalur A PIC Ruangan mengajukan (jenis aset, alasan, urgensi); Admin/HR menyetujui dengan memilih aset gudang dan jadwal, atau menolak dengan alasan. Pada Jalur B Admin/HR langsung memilih aset dan jadwal tanpa persetujuan. Setelah dijadwalkan, alurnya sama dengan RGN01: aset gudang tersedia → proses, PIC menilai setiap aset Normal atau Rusak, Admin/HR mereview lalu mengonfirmasi (aset menjadi terpakai di ruangan) atau menjadwalkan pengganti untuk aset rusak (ronde berikutnya) sampai semua normal.

04Ringkasan Fitur

05Tujuan Fitur

• Menambah aset ke ruangan yang sudah aktif tanpa mengulang onboarding ruangan (RGN01).
• Memberi PIC Ruangan jalur resmi untuk meminta aset tambahan, lengkap dengan alasan dan urgensi.
• Memberi Admin/HR keputusan terdokumentasi: setujui (dengan aset dan jadwal) atau tolak (dengan alasan).
• Memastikan serah terima fisik tercatat (waktu dan identitas PIC) dan aset rusak diganti sebelum selesai.

06Aktor

07Hak Akses

08Terminologi

09Business Rules

10Business Flow

1. Jalur A. PIC mengisi form (ruangan, jenis aset, alasan, urgensi) dan mengirim. Admin/HR dinotifikasi (request_ruangan.diajukan).
2. Admin/HR membuka tab Pengajuan, mereview. - Tolak: isi alasan → status ditolak, PIC dinotifikasi. Selesai. - Setujui: pilih aset gudang dan jadwal → aset proses, item ronde 1 dan jadwal dibuat, PIC dinotifikasi (disetujui).
3. Jalur B. Admin/HR memilih ruangan aktif, aset, jadwal → langsung seperti langkah setujui; PIC dinotifikasi (dikirim).
4. Pada jadwal, HR menyerahkan aset di ruangan. PIC menilai tiap aset Normal/Rusak lalu Terima & Kirim Checklist. Admin dinotifikasi (diterima).
5. Admin/HR mereview: - Semua normal → Konfirmasi Selesai: aset terpakai di ruangan, log aset dicatat, PIC dinotifikasi (selesai). - Ada rusak → Jadwalkan Pengganti: aset rusak → rusak (gudang), pengganti → proses, item ronde + 1, jadwal baru; PIC dinotifikasi (pengganti). Kembali ke langkah 4.

11Flow Berdasarkan Role

12Flow Diagram

flowchart TD
    A([Mulai]) --> J{Jalur}
    J -->|A: PIC mengajukan| P[Pengajuan: ruangan, jenis aset, alasan, urgensi]
    J -->|B: Admin langsung| B[Pilih ruangan, aset gudang, jadwal]
    P --> R{Admin/HR review}
    R -->|Tolak + alasan| T([Ditolak - selesai])
    R -->|Setujui| S[Pilih aset gudang + jadwal]
    S --> L[Aset tersedia → proses, PIC dinotifikasi]
    B --> L
    L --> H[Serah terima: PIC cek tiap aset]
    H --> V{Ada aset rusak?}
    V -->|Tidak| K[Admin konfirmasi: aset terpakai di ruangan]
    V -->|Ya| G[Admin jadwalkan pengganti, ronde + 1]
    G --> H
    K --> Z([Selesai])

13Sequence Diagram

sequenceDiagram
    participant PIC as PIC Ruangan (Mobile)
    participant API as API Lumen
    participant DB as Database
    participant ADM as Admin/HR (Mobile)
    PIC->>API: POST pic-ruangan/request
    API->>DB: insert header (proses, tanpa jadwal)
    API-->>ADM: notifikasi request_ruangan.diajukan
    ADM->>API: POST request-ruangan/{id}/setujui
    API->>DB: aset → proses, insert item ronde 1 + jadwal
    API-->>PIC: notifikasi request_ruangan.disetujui
    PIC->>API: POST pic-ruangan/request/{id}/terima
    API->>DB: item.status_item, jadwal.tgl_terima_pic
    API-->>ADM: notifikasi request_ruangan.diterima
    ADM->>API: POST request-ruangan/{id}/konfirmasi
    API->>DB: aset → terpakai/ruangan, asset_trx_log, header dikonfirmasi
    API-->>PIC: notifikasi request_ruangan.selesai

14Status Transaksi

Hanya status_approval yang disimpan. Fase diturunkan dari status header dan jadwal ronde terakhir.

draft ada di enum tetapi tidak dipakai alur ini. Status aset: lihat §22.

15State Transition

stateDiagram-v2
    [*] --> menunggu_persetujuan: PIC ajukan (Jalur A)
    [*] --> menunggu_serah_terima: Admin inisiasi (Jalur B)
    menunggu_persetujuan --> ditolak: Admin tolak
    menunggu_persetujuan --> menunggu_serah_terima: Admin setujui
    menunggu_serah_terima --> menunggu_serah_terima: Admin ubah jadwal
    menunggu_serah_terima --> menunggu_review: PIC kirim checklist
    menunggu_review --> menunggu_serah_terima: Jadwalkan pengganti (ronde + 1)
    menunggu_review --> selesai: Admin konfirmasi
    ditolak --> [*]
    selesai --> [*]

16Struktur Database

Tabel lama asset_trx_penambahan_ruangan (+ _item) digantikan; perintah DROP-nya tersedia di SQL tetapi dikomentari dan datanya tidak dimigrasi.

17Relasi Database

erDiagram
    asset_lokasi_m ||--o{ asset_trx_request_ruangan : "id_asset_lokasi_m"
    asset_trx_request_ruangan ||--o{ asset_trx_request_ruangan_jadwal : "id_asset_trx_request_ruangan"
    asset_trx_request_ruangan ||--o{ asset_trx_request_ruangan_item : "id_asset_trx_request"
    asset_data ||--o{ asset_trx_request_ruangan_item : "id_asset_data"
    asset_lokasi_m ||--o| asset_lokasi_pic_m : "PIC ruangan"

PIC pada header disimpan sebagai id_karyawan_pic (snapshot nama_pic, nik_pic); master PIC dibaca dari asset_lokasi_pic_m.

18Data Dictionary

asset_trx_request_ruangan

asset_trx_request_ruangan_jadwal: id_..._jadwal (PK), id_asset_trx_request_ruangan, ronde, tanggal, jam, tgl_terima_pic (NULL = belum diterima), keterangan, audit.

asset_trx_request_ruangan_item: id_asset_trx_request_item (PK), id_asset_trx_request, parent_id (default ''), id_asset_data, snapshot nama_asset, deskripsi_asset, kategori_asset, ronde, status_item (normal/rusak/belum_dicek), ket_rusak, audit.

19Database Index

20Backend Architecture

Controller memvalidasi input, memanggil model dalam DB::transaction, lalu mengirim notifikasi setelah transaksi sukses. Aksi admin memakai mutateAssetTrx.

21Backend Business Logic

• ajukanPic: kunci company; validasi karyawan aktif, ruangan milik PIC (BR-03), kategori, alasan, urgensi; buat header proses tanpa jadwal.
• storeAdmin: validasi admin dan ruangan; PIC dari master ruangan; buat header lalu alokasikan().
• setujui: header harus fase menunggu_persetujuan; alokasikan(); isi user_approval dan tgl_approval.
• alokasikan: kunci aset tersedia (FOR UPDATE), pastikan jumlah sama dengan yang diminta, buat item ronde 1 (belum_dicek) + jadwal ronde 1, isi jadwal terkini di header, set aset proses.
• tolak: fase harus menunggu_persetujuan; alasan wajib; status ditolak. Tidak ada aset yang berubah.
• updateJadwal: fase menunggu_serah_terima; tambah baris jadwal; perbarui jadwal terkini header.
• terima (PIC): fase menunggu_serah_terima; semua item ronde harus dicek; isi status_item/ket_rusak; isi tgl_terima_pic pada jadwal terakhir. Status aset tidak berubah di sini.
• jadwalkanPengganti: fase menunggu_review; semua aset rusak ronde ini wajib punya pengganti unik; aset rusak → rusak, id_pemegang_asset=''; pengganti → proses; item ronde + 1 dengan parent_id; jadwal baru.
• konfirmasi: fase menunggu_review dan tidak ada aset rusak aktif; aset aktif (belum digantikan) → terpakai, pemegang_asset='ruangan', id_pemegang_asset dan id_asset_lokasi_m = ruangan; asset_trx_log jenis penambahan_ruangan; header dikonfirmasi.

22Dampak terhadap asset_data

23API Documentation

Base asset/. Semua memakai JWT dan envelope ApiResponse.

Tambahan: GET karyawan/pic-ruangan (beranda PIC) kini menyertakan key request_ruangan.

24Detail Setiap API

API-04 · POST asset/request-ruangan (Jalur B)

{ "id_asset_lokasi_m": "RGN-1", "asset_ids": ["AST-1", "AST-2"],
  "tanggal": "2026-10-20", "jam": "09:00", "catatan": "Bawa kunci", "keterangan": "" }

Respons CREATED: { "id": "COMP202610001", "no_trx": "RGN04-202610001", "fase": "menunggu_serah_terima" }. Validasi: asset_ids wajib, minimal 1, tidak boleh ganda; tanggal Y-m-d; jam H:i.

API-12 · POST asset/karyawan/pic-ruangan/request (Jalur A)

{ "id_asset_lokasi_m": "RGN-1", "id_asset_kategori_m": "KAT-KOM",
  "keterangan": "Tim bertambah dua orang", "urgensi": "mendesak" }

Respons CREATED: { "id": "...", "no_trx": "RGN04-...", "fase": "menunggu_persetujuan" }. urgensi ∈ normal|secepatnya|mendesak.

API-05 · POST .../{id}/setujui

{ "asset_ids": ["AST-1"], "tanggal": "2026-10-20", "jam": "09:00", "catatan": "Bawa kunci" }

Respons UPDATED: { "id", "no_trx", "fase": "menunggu_serah_terima" }.

API-06 · POST .../{id}/tolak: { "ket_tolak": "Stok kosong" } → { "status_approval": "ditolak", "fase": "ditolak" }.

API-07 · PUT .../{id}/jadwal: { "tanggal", "jam", "keterangan" }.

API-08 · POST .../{id}/pengganti

{ "items": [{ "id_item": "<id baris rusak>", "id_asset_data": "AST-3" }],
  "tanggal": "2026-10-22", "jam": "10:00", "keterangan": "Unit pengganti" }

Respons: { "ronde": 2, "jumlah_pengganti": 1 }.

API-14 · POST .../request/{id}/terima

{ "items": [
  { "id_item": "ITM-1", "status_item": "normal" },
  { "id_item": "ITM-2", "status_item": "rusak", "ket_rusak": "Layar retak" } ] }

Respons: { "ada_rusak": true, "fase": "menunggu_review" }.

API-03 / API-13 · Detail mengembalikan: id, no_trx, sumber_pengajuan, ruangan + cabang + departemen, PIC, nama_kategori, alasan, urgensi, ket_tolak, tgl_pengajuan, jadwal terkini, ronde, fase, fase_label, jadwal[] (riwayat), items[] (id_item, parent_id, nama_asset, ronde, status_item, ket_rusak, diganti, perlu_dicek). Khusus admin ditambah bisa_setujui, bisa_ubah_jadwal, bisa_konfirmasi, perlu_pengganti[]; khusus PIC bisa_diterima.

25Mobile Architecture

Flutter + flutter_bloc + dio. Halaman RGN01 dipakai ulang lewat parameter agar tidak menggandakan kode.

File baru: Bloc/Asset/AssetPicRuanganRequestFormBloc.dart, UI/Modul/Asset/PicRuangan/HalamanAjukanRequestPicRuangan.dart.

26Mobile Screen

Detail Admin menampilkan kartu info pengajuan (jenis aset, urgensi, alasan, penolakan), stepper, dan timeline per aset. Saat bisa_setujui, muncul panel pilih aset gudang + jadwal serta tombol Tolak dan Setujui & Jadwalkan.

27Mobile → API

28API → Mobile

Model: mAssetPicRuangan.dart (AssetPicRuanganRequest, AssetPicRuanganRequestOptions, AssetPicRuanganAjukanRequest, detail diperluas dengan sumberPengajuan, namaKategori, alasan, urgensi, ketTolak) dan mAssetAdminRuangan.dart (AssetAdminRuanganSetujuiRequest, bisaSetujui, daftar membaca key requests selain onboardings). Fase baru: menunggu_persetujuan dan ditolak.

29Mapping Mobile → API → Database

30Mapping Database → API → Mobile

31Validation

Mobile menampilkan error wajib pada form pengajuan (ruangan, jenis, urgensi, alasan) dan menonaktifkan tombol Setujui sampai aset dan jadwal dipilih serta tombol Tolak pada dialog sampai alasan diisi.

32Error Handling

33Audit Trail

• Header: user_input, tgl_input, user_update, tgl_update; user_approval + tgl_approval (setujui, tolak, konfirmasi).
• Jadwal: satu baris per penetapan/perubahan; tgl_terima_pic = waktu PIC menerima.
• Item: user_input per baris; rantai pengganti lewat parent_id.
• asset_trx_log jenis penambahan_ruangan saat konfirmasi (posisi gudang → ruangan).

34Notification

Rute tujuan di aplikasi: asset_pic_ruangan_request (PIC) dan asset_admin_detail_request_ruangan (Admin). Notifikasi dibuat setelah transaksi database sukses; kegagalan kirim tidak membatalkan transaksi.

35Security

• JWT wajib; ctx memuat id_company dan id_karyawan. Seluruh query dibatasi id_company.
• Aksi admin memeriksa keanggotaan asset_admin; sisi PIC dibatasi id_karyawan_pic.
• Aset dikunci FOR UPDATE dan company dikunci per transaksi untuk mencegah alokasi ganda dan nomor ganda.
• Input divalidasi di controller dan model; tidak ada query mentah dari input pengguna.
• Foto/berkas: tidak dipakai di alur ini.

36Manual Book User/Admin

PIC Ruangan: mengajukan penambahan 1. Buka Asset → PIC Ruangan, ketuk Ajukan Penambahan Asset. 2. Pilih Ruangan, Jenis Asset, Urgensi, isi Alasan, ketuk Kirim Pengajuan. 3. Pantau status di banner beranda ("Menunggu persetujuan Admin/HR"). Bila ditolak, alasan terlihat di detail.

PIC Ruangan: menerima aset 1. Setelah disetujui/dikirim, banner berubah menjadi serah terima dengan jadwal. 2. Pada jadwal, periksa fisik tiap aset, pilih Normal atau Rusak (isi keterangan bila rusak). 3. Ketuk Terima & Kirim Checklist. Checklist tidak dapat diubah setelah dikirim.

Admin/HR: memproses pengajuan 1. Buka Asset → Ruangan → Penambahan, tab Pengajuan, pilih transaksi. 2. Tinjau jenis aset, urgensi, alasan. Pilih Tolak (isi alasan) atau pilih aset gudang + tanggal + jam lalu Setujui & Jadwalkan.

Admin/HR: inisiasi langsung (Jalur B) 1. Di daftar Penambahan, ketuk Tambah Asset. 2. Pilih ruangan (PIC tampil otomatis), tambah aset, tetapkan jadwal, Kirim ke PIC Ruangan.

Admin/HR: review 1. Tab Proses, buka transaksi. Bila PIC belum menerima, Ubah Jadwal tersedia. 2. Setelah checklist masuk: semua normal → Konfirmasi Selesai; ada rusak → pilih pengganti untuk setiap aset rusak, tetapkan jadwal, Jadwalkan Pengganti.

37Kondisi Button

38Testing Scenario

Hasil terakhir: API 207 test di tests/Asset lolos; mobile 29 test ruangan lolos.

39Temuan Ketidaksesuaian

Perbandingan dengan dokumen bisnis RGN04 v1.0.

40Edge Case

41Potential Bug / Technical Risk

42Dependency

• Data master: asset_lokasi_m (tipe ruangan, status_aktif), asset_lokasi_pic_m, asset_kategori_m, data_karyawan, asset_admin.
• Modul lain: Onboarding Ruangan RGN01 (syarat ruangan beroperasi dan pola serah terima), asset_data, asset_trx_log, notifikasi (notif_data, FCM).
• Berbagi komponen: AssetAdminRuangan_m::getOptions, showAssetOnboardingAssetPicker, showAssetPickerSheet, timeline AssetRuanganTimeline.

43Source Code Reference

44Developer Notes

• Skema mengikuti pola KRY-03-1: satu tabel dua jalur lewat sumber_pengajuan, enum status dipakai bersama.
• Fase tidak disimpan. Bila menambah fase, ubah AssetRequestRuangan_m::fase() dan stepper mobile (langkahAktifRuangan).
• Aset tidak berpindah pemegang sebelum konfirmasi; PIC mengirim checklist tanpa mengubah asset_data.
• terimaPenambahan (bukan terimaRequest) adalah nama metode API mobile agar tidak bentrok dengan field pada fake API di test.
• Hook GateGuard menolak pembuatan/edit pertama setiap file; ulangi percobaan.
• Master PIC ruangan adalah asset_lokasi_pic_m (komentar lama SQL RGN01 menyebut asset_ruangan_pic_m).

45End-to-End Traceability

45.4 Walkthrough Lengkap dengan Contoh Data

Walkthrough berikut mengikuti Jalur A: PIC Ruangan mengajukan penambahan aset, Admin/HR menyetujui, serah terima gagal sebagian sehingga ada satu ronde penggantian, lalu selesai. Sesudahnya dijelaskan variasi penolakan dan Jalur B (Admin/HR langsung). Setiap langkah menjelaskan apa yang dilakukan di mobile, apa yang dikirim, apa yang diproses API, apa yang tersimpan di database, dan apa yang diterima mobile. Data bersifat sintetis, tetapi nama kolom, urutan proses, dan pesan diambil dari kode (AssetRequestRuangan_m, AssetAdminRequestRuangan_c, AssetKaryawanRequestRuangan_c, AssetNotification).

Data awal

Company CMP001. Tanggal 22 Oktober 2026, periode ID 202610.

data_karyawan (semua aktif)

asset_lokasi_m: LOK0007 "Ruang Meeting Lt.2" (tipe = ruangan, status_aktif = 1, cabang "Jakarta", departemen "Operasional"). asset_lokasi_pic_m menunjuk LOK0007 → KRY0030. Ruangan sudah beroperasi: ada onboarding dikonfirmasi untuk LOK0007 (syarat BR-02; tanpa itu ruangan tidak muncul di opsi).

asset_kategori_m: KAT-MON "Monitor".

asset_data (semua tersedia, pemegang_asset = gudang, id_asset_lokasi_m = LOK0001)

Penomoran: header, item, dan jadwal memakai id_company + YYYYMM + 3 digit (urut per tabel); no_trx = RGN04-YYYYMMNNN; asset_trx_log dan notifikasi memakai 5 digit. Satu tabel melayani dua jalur, dibedakan kolom sumber_pengajuan (karyawan = Jalur A, admin = Jalur B).

Langkah 0 — PIC membuka form pengajuan

Mobile: halaman PIC Ruangan → kartu Penambahan/Request → Ajukan (AssetPicRuanganBloc, assetPicRuanganApi).

Dikirim

GET /asset/karyawan/pic-ruangan/request/options
Authorization: Bearer <access_token_dewi>

Diproses API: getOptionsPic hanya membaca: ruangan aktif yang dimiliki PIC login (join asset_lokasi_pic_m) dan sudah beroperasi, daftar kategori, dan pilihan urgensi (normal, secepatnya, mendesak). Database: hanya SELECT.

Diterima mobile: LOK0007 sebagai satu-satunya ruangan pilihan, kategori (termasuk Monitor), dan tiga pilihan urgensi.

Langkah 1 — PIC mengajukan penambahan monitor

Mobile: Dewi memilih ruangan, jenis aset Monitor, urgensi Mendesak, mengisi alasan, lalu Kirim.

Dikirim

POST /asset/karyawan/pic-ruangan/request
Authorization: Bearer <access_token_dewi>

{ "id_asset_lokasi_m": "LOK0007", "id_asset_kategori_m": "KAT-MON",
  "keterangan": "Tim bertambah dua orang", "urgensi": "mendesak" }

Diproses API (AssetKaryawanRequestRuangan_c → AssetRequestRuangan_m::ajukanPic, satu DB::transaction(…, 3)) 1. Validasi controller: id_asset_lokasi_m ("Ruangan wajib dipilih."), id_asset_kategori_m ("Jenis aset wajib dipilih."), keterangan ("Alasan wajib diisi.", maksimal 1000), urgensi ("Urgensi wajib dipilih." / "Urgensi pengajuan tidak valid."). 2. lockCompany; karyawan harus aktif ("Karyawan tidak ditemukan atau tidak aktif."). 3. findRuanganTujuan dengan filter PIC: ruangan harus aktif, punya PIC, milik Dewi, dan sudah beroperasi ("Ruangan tujuan tidak ditemukan, tidak aktif, atau belum memiliki aset."). 4. Kategori harus ada ("Jenis aset tidak ditemukan."), alasan tidak kosong ("Alasan wajib diisi."), urgensi salah satu dari tiga nilai ("Urgensi wajib dipilih."). 5. Nomor header: nextHeaderId → CMP001202610001, RGN04-202610001. 6. INSERT header saja (belum ada item, jadwal, dan belum ada aset yang dikunci). 7. Controller mengirim request_ruangan.diajukan ke semua admin asset.

Hasil database

asset_trx_request_ruangan (1 baris)

Tabel item dan jadwal masih kosong; asset_data tidak berubah. Karena belum ada baris jadwal, fase turunan = menunggu_persetujuan.

notif_data: satu baris per admin asset (misalnya KRY0099), rute asset_admin_detail_request_ruangan, judul "Pengajuan Penambahan Asset Ruangan", isi "Dewi PIC mengajukan penambahan asset untuk Ruang Meeting Lt.2 (RGN04-202610001).". Push FCM dikirim; kegagalan push hanya dicatat di log.

Diterima mobile (HTTP 201)

{ "code": "CREATED", "message": "Pengajuan penambahan asset berhasil dikirim ke Admin/HR.",
  "data": { "id": "CMP001202610001", "no_trx": "RGN04-202610001", "fase": "menunggu_persetujuan" } }

Langkah 2 — Admin menyetujui dan memilih aset

Mobile: tab Pengajuan menampilkan RGN04-202610001; Siti membuka detail (GET /asset/request-ruangan/CMP001202610001 dan opsi aset), memilih Monitor LG dan Monitor Dell, jadwal 23 Okt 2026 pukul 09:00, lalu Setujui.

Dikirim

POST /asset/request-ruangan/CMP001202610001/setujui
Authorization: Bearer <access_token_admin>

{ "asset_ids": ["AST0201", "AST0202"], "tanggal": "2026-10-23", "jam": "09:00", "catatan": "Bawa kunci ruangan" }

Diproses API (setujuiRequestRuangan → setujui) 1. Validasi: asset_ids wajib, minimal satu, tidak kembar ("Minimal satu asset wajib dipilih." / "Asset yang sama tidak boleh dipilih lebih dari sekali."), tanggal Y-m-d, jam H:i. 2. lockCompany, admin ("Pengguna tidak terdaftar sebagai admin asset."), lockHeader (ada dan status_approval = proses: "Penambahan aset tidak ditemukan." / "Penambahan aset sudah selesai."). 3. Fase harus menunggu_persetujuan ("Pengajuan sudah tidak menunggu persetujuan."). 4. alokasikan: getLockedAssets (aset tersedia di gudang, FOR UPDATE; "Satu atau beberapa asset tidak tersedia untuk dialokasikan."), parseJadwalValue ("Tanggal serah terima tidak boleh sebelum tanggal pengajuan."), INSERT 2 item ronde 1, INSERT jadwal ronde 1, UPDATE header (jadwal + catatan), UPDATE asset_data → proses. 5. UPDATE header: user_approval, tgl_approval, tgl_update, user_update. status_approval tetap proses; yang berubah adalah fase turunan karena jadwal sudah ada. 6. Controller mengirim request_ruangan.disetujui ke PIC.

Hasil database

asset_trx_request_ruangan_item (2 baris)

asset_trx_request_ruangan_jadwal (1 baris)

asset_trx_request_ruangan (header)

asset_data (AST0201 dan AST0202): status_asset tersedia → proses; pemegang dan lokasi tetap gudang LOK0001; user_update = ADM-001 - Siti Admin.

notif_data: baris untuk KRY0030, rute asset_pic_ruangan_request, judul "Pengajuan Disetujui", isi "Pengajuan penambahan asset RGN04-202610001 untuk Ruang Meeting Lt.2 disetujui. Cek jadwal serah terima.".

Diterima mobile (HTTP 200): { "code": "UPDATED", "message": "Pengajuan disetujui dan dijadwalkan ke PIC Ruangan.", "data": { "id": "CMP001202610001", "no_trx": "RGN04-202610001", "fase": "menunggu_serah_terima" } }. Transaksi pindah dari tab Pengajuan ke Proses.

Langkah 3 — Admin mengubah jadwal

Dikirim

PUT /asset/request-ruangan/CMP001202610001/jadwal

{ "tanggal": "2026-10-24", "jam": "13:30", "keterangan": "Ruangan belum siap" }

Diproses API (updateJadwal): lockCompany, admin, lockHeader; fase harus menunggu_serah_terima ("Jadwal hanya dapat diubah sebelum PIC Ruangan menerima asset."); rondeSaatIni = 1; parseJadwalValue; INSERT jadwal baru (append-only, ronde 1); UPDATE jadwal terkini di header; controller mengirim request_ruangan.jadwal_diubah ke PIC.

Hasil database

asset_trx_request_ruangan_jadwal (riwayat bertambah)

Header: tgl_serah_terima = 2026-10-24, jam_serah_terima = 13:30:00, tgl_update/user_update diperbarui. Item dan asset_data tidak berubah. notif_data untuk KRY0030: "Jadwal Serah Terima Diperbarui" / "Jadwal serah terima RGN04-202610001 telah diperbarui.".

Diterima mobile (HTTP 200): message "Jadwal serah terima berhasil diperbarui.", data = { id, no_trx }.

Langkah 4 — PIC mengirim checklist (satu rusak)

Mobile: Dewi membuka detail dari notifikasi, menilai Normal pada Monitor LG dan Rusak pada Monitor Dell dengan keterangan, lalu Terima & Kirim Checklist.

Dikirim

POST /asset/karyawan/pic-ruangan/request/CMP001202610001/terima
Authorization: Bearer <access_token_dewi>

{ "items": [
  { "id_item": "CMP001202610001", "status_item": "normal" },
  { "id_item": "CMP001202610002", "status_item": "rusak", "ket_rusak": "Layar bergaris vertikal" } ] }

Diproses API (terimaRequestRuangan → AssetRequestRuangan_m::terima) 1. Validasi controller: items wajib ("Kondisi item wajib diisi."), id tidak kembar ("Item yang sama tidak boleh dikirim lebih dari sekali."), status_item wajib dan hanya normal/rusak ("Kondisi setiap item wajib dipilih." / "Kondisi item harus normal atau rusak."), ket_rusak wajib bila rusak ("Keterangan kerusakan wajib diisi."). 2. lockCompany; header dicari dengan filter id_karyawan_pic = pengguna login (FOR UPDATE): milik PIC lain atau tidak ada → "Penambahan aset tidak ditemukan.". 3. Fase harus menunggu_serah_terima ("Penambahan aset sudah tidak menunggu serah terima."); karyawan aktif. 4. Semua item ronde berjalan wajib dicek, tidak kurang dan tidak berlebih ("Seluruh item pada serah terima wajib dicek."); rusak tanpa keterangan ditolak. 5. UPDATE status_item/ket_rusak per item, isi tgl_terima_pic pada jadwal terakhir, sentuh header. asset_data tidak diubah oleh PIC. 6. Controller mengirim request_ruangan.diterima ke admin.

Hasil database

Diterima mobile (HTTP 200)

{ "code": "UPDATED", "message": "Serah terima dikirim. Kerusakan akan ditindaklanjuti admin.",
  "data": { "id": "CMP001202610001", "no_trx": "RGN04-202610001", "ada_rusak": true, "fase": "menunggu_review" } }

Langkah 5 — Admin menjadwalkan pengganti

Dikirim

POST /asset/request-ruangan/CMP001202610001/pengganti

{ "items": [ { "id_item": "CMP001202610002", "id_asset_data": "AST0203" } ],
  "tanggal": "2026-10-26", "jam": "10:00", "keterangan": "Unit pengganti monitor" }

Diproses API (jadwalkanPengganti) 1. Validasi: "Asset pengganti wajib dipilih.", pengganti tidak kembar. 2. lockCompany, admin, lockHeader; fase harus menunggu_review ("Pengganti hanya dapat dijadwalkan setelah PIC Ruangan mengirim checklist."). 3. asetRusakRondeIni kosong → "Tidak ada asset rusak yang perlu diganti."; pilihan admin harus cocok penuh dengan daftar rusak → "Seluruh asset rusak wajib diberi asset pengganti."; pengganti kembar → "Asset pengganti yang sama tidak boleh dipilih lebih dari sekali."; pengganti harus tersedia di gudang → "Satu atau beberapa asset pengganti tidak tersedia.". 4. UPDATE aset rusak → rusak; INSERT item ronde 2 (parent_id = item rusak); INSERT jadwal ronde 2; UPDATE header; UPDATE pengganti → proses. 5. Controller mengirim request_ruangan.pengganti ke PIC.

Hasil database

Diterima mobile (HTTP 200): message "Asset pengganti berhasil dijadwalkan ke PIC Ruangan.", data = { id, no_trx, ronde: 2, jumlah_pengganti: 1 }.

Langkah 6 — PIC mengirim checklist ronde 2

Checklist ronde 2 hanya berisi item pengganti.

{ "items": [ { "id_item": "CMP001202610003", "status_item": "normal" } ] }

Proses sama dengan langkah 4 dengan ronde = 2. Hasil database: item CMP001202610003 → normal; jadwal CMP001202610003 → tgl_terima_pic = 2026-10-26 10:20:00; fase menunggu_review; notifikasi request_ruangan.diterima ke admin. Diterima mobile: "Serah terima berhasil dikirim.", ada_rusak = false.

Langkah 7 — Admin mengonfirmasi selesai

Dikirim

POST /asset/request-ruangan/CMP001202610001/konfirmasi

(tanpa body)

Diproses API (konfirmasi) 1. lockCompany, admin, lockHeader; fase harus menunggu_review ("Penambahan aset belum menunggu review Admin/HR."). 2. Tidak boleh ada aset rusak pada ronde berjalan ("Masih ada asset rusak. Jadwalkan penggantian sebelum menyelesaikan penambahan."). 3. asetAktif: item yang belum digantikan → AST0201 dan AST0203 (AST0202 tidak ikut). Aset dikunci dan harus proses/gudang ("Satu atau beberapa asset tidak dapat diserahkan ke ruangan."). 4. UPDATE asset_data, INSERT asset_trx_log per aset (jenis penambahan_ruangan), UPDATE header → dikonfirmasi. 5. Controller mengirim request_ruangan.selesai ke PIC.

Hasil database

Diterima mobile (HTTP 200)

{ "code": "UPDATED", "message": "Penambahan asset ke ruangan berhasil diselesaikan.",
  "data": { "id": "CMP001202610001", "no_trx": "RGN04-202610001", "status_approval": "dikonfirmasi", "jumlah_asset": 2 } }

Kondisi akhir

Variasi

Penolakan (Jalur A). Setelah langkah 1, Admin menolak:

POST /asset/request-ruangan/CMP001202610001/tolak

{ "ket_tolak": "Stok monitor kosong" }

Proses tolak: admin, lockHeader, fase harus menunggu_persetujuan ("Pengajuan sudah tidak menunggu persetujuan."), alasan tidak kosong ("Alasan penolakan wajib diisi."). Header: status_approval → ditolak, ket_tolak = Stok monitor kosong, user_approval, tgl_approval, tgl_update, user_update terisi. Tidak ada item, jadwal, atau perubahan asset_data. PIC dinotifikasi request_ruangan.ditolak ("Pengajuan Ditolak": "Pengajuan penambahan asset RGN04-202610001 untuk Ruang Meeting Lt.2 ditolak. Lihat alasan penolakan."). Respons UPDATED, "Pengajuan penambahan asset ditolak.", data = { id, no_trx, status_approval: "ditolak", fase: "ditolak" }. Transaksi ditolak tidak dapat diproses lagi karena lockHeader menolak status selain proses.

Jalur B (Admin langsung). Admin memakai tombol Tambah Asset dan memanggil POST /asset/request-ruangan dengan { "id_asset_lokasi_m": "LOK0007", "asset_ids": ["AST0201","AST0202"], "tanggal": "2026-10-23", "jam": "09:00", "catatan": "…", "keterangan": "" }. storeAdmin memvalidasi ruangan aktif yang sudah beroperasi, mengambil PIC dari master ("PIC Ruangan tidak ditemukan atau tidak aktif." bila nonaktif; Admin tidak dapat memilih PIC lain), lalu dalam satu transaksi: INSERT header sumber_pengajuan = admin (tanpa kategori/urgensi; pembuat = admin), alokasikan (item, jadwal, asset_data → proses). Respons CREATED, "Penambahan asset ke ruangan berhasil dikirim ke PIC Ruangan.", fase = menunggu_serah_terima, notifikasi request_ruangan.dikirim. Langkah 3 dan seterusnya sama dengan Jalur A. user_approval dan tgl_approval baru terisi saat konfirmasi.

Kasus gagal

Semua kesalahan aturan bisnis dilempar sebagai InvalidArgumentException di dalam transaksi, sehingga seluruh perubahan di-rollback dan controller membalas BUSINESS_RULE_VIOLATION dengan pesan di bawah.

Ringkasan siapa mengerjakan apa

46Ringkasan Database Impact

47Checklist Implementasi

• DBML diperbarui ([REVISI ALK-RGN04])
• SQL manual dibuat (sql-alk-rgn04-request-penambahan-ruangan.sql)
• SQL manual dijalankan lengkap, status_approval bertipe enum (periksa)
• DROP tabel lama penambahan (hanya bila kosong)
• Model, controller, route, notifikasi API
• Test API (12) dan seluruh tests/Asset (207) lolos
• Model, API client, bloc, halaman, route, teks mobile
• Test mobile (11) dan 29 test ruangan lolos
• Uji di server/emulator, termasuk push notifikasi
• Pembatalan oleh Admin (belum ada)

48Changelog