Request & Penambahan Asset Karyawan

01Informasi Dokumen

03Quick Overview

Satu tabel, dua pintu masuk, satu pintu keluar:

PENAMBAHAN (sumber_pengajuan = admin)            PENGAJUAN (sumber_pengajuan = karyawan)
Admin: pilih karyawan + asset + jadwal            Karyawan: ketik jenis asset (teks) + alasan
        │ Submit ke Karyawan                              │ Submit ke Admin
        │ asset_data → proses                             ▼
        │                                         Admin: Tolak ──► status ditolak (selesai)
        │                                                 │ Setujui → alokasi asset + jadwal
        │                                                 │ Submit ke PIC → asset_data → proses
        ▼                                                 ▼
        └──────────────► Karyawan: Konfirmasi Asset (Normal / Rusak per item) ◄──┘
                                          │
              ┌── semua Normal ───────────┴───────── ada Rusak ──┐
              ▼                                                  ▼
  status dikonfirmasi ("Selesai")                     status tetap proses ("Butuh Proses")
  semua asset → terpakai, pemegang karyawan           TIDAK ada asset diserahkan
  + asset_trx_log                                         ⚠️ tidak ada mekanisme lanjutan (RISK-001)

04Ringkasan Fitur

Fitur ini mencatat pemberian asset tambahan kepada karyawan yang sudah bekerja (berbeda dari Onboarding yang untuk penyerahan awal). Ada dua jalur yang disimpan di tabel yang sama:

• Penambahan Asset (admin) — Admin Asset langsung memilih karyawan, asset dari gudang (boleh lintas kategori), dan jadwal serah terima, lalu mengirim ke karyawan.
• Pengajuan Asset (karyawan) — Karyawan mengajukan jenis asset (teks bebas yang diketik sendiri, maks 150 karakter) beserta alasan. Admin meninjau: menolak dengan alasan, atau menyetujui dengan mengalokasikan asset fisik apa pun dari stok gudang (tidak dibatasi jenis yang diajukan) dan menentukan jadwal serah terima. Alokasi dapat disimpan sebagai draft terlebih dulu.

Kedua jalur berakhir di konfirmasi karyawan: tiap asset dinilai Normal atau Rusak. Berbeda dengan Onboarding, serah terima di fitur ini bersifat all-or-nothing: asset baru berpindah ke karyawan jika semua item Normal. Jika ada item Rusak, transaksi berhenti di status "Butuh Proses" dan tidak ada endpoint lanjutan di source.

05Tujuan Fitur

5.1 Tujuan Bisnis (diturunkan dari kode)

• Karyawan dapat meminta asset tambahan secara tercatat dengan menuliskan jenis asset yang dibutuhkan (teks bebas) beserta alasan.
• Admin dapat menyetujui atau menolak permintaan dengan alasan yang tersimpan.
• Admin dapat memberikan asset tambahan tanpa menunggu permintaan.
• Penyerahan asset dijadwalkan (tanggal & jam) dan diverifikasi fisik oleh karyawan.
• Setiap perpindahan asset ke karyawan tercatat di asset_trx_log.

5.2 Tujuan Sistem

• Menyimpan pengajuan/penambahan dengan nomor KRY-03-1-....
• Mengalokasikan asset fisik yang tersedia di gudang; admin bebas memilih asset apa pun dari stok (tidak dibatasi jenis yang diajukan).
• Mengunci asset (status_asset = proses) setelah dikirim ke karyawan.
• Memindahkan pemegang asset ke karyawan setelah konfirmasi normal.
• Mengirim notifikasi inbox + push ke pihak terkait.

06Aktor

07Hak Akses

08Terminologi

09Business Rules

BR-001 — Endpoint admin hanya untuk Admin Asset

Asset_c::accessError (asset_admin + karyawan aktif) → 401/403; model memanggil findAssetAdmin → 422 "Pengguna tidak terdaftar sebagai admin asset."

BR-002 — Penambahan: karyawan wajib dipilih & aktif

Validasi id_karyawan required; findActiveKaryawan → "Karyawan tidak ditemukan atau tidak aktif."

BR-003 — Minimal satu asset, tanpa duplikat

asset_ids array min 1, distinct → "Minimal satu asset wajib dipilih." / "Asset yang sama tidak boleh dipilih lebih dari sekali."

BR-004 — Asset harus tersedia di gudang

requestLockedAssets: status_asset = tersedia AND pemegang_asset = gudang (FOR UPDATE) → "Satu atau beberapa asset tidak tersedia untuk penambahan." / "Satu atau beberapa asset tidak tersedia." (alokasi).

BR-005 — Asset tidak boleh aktif di onboarding atau penambahan lain

hasActiveOnboardingAsset → "…sedang diproses pada onboarding." hasActiveRequestAsset (header proses saja, sumber admin atau pengajuan yang sudah disetujui) → "…sedang diproses pada penambahan lain." Transaksi dikonfirmasi (selesai) tidak lagi mengunci asset. Asset yang masih dipegang karyawan tetap tidak bisa dipilih karena syarat status_asset = tersedia + pemegang_asset = gudang, sehingga asset hasil Retur/Offboarding bisa ditambahkan lagi (RISK-002, sudah diperbaiki v1.1).

BR-006 — Jadwal serah terima wajib saat dikirim

Penambahan & alokasi: tgl_serah_terima (Y-m-d) dan jam_serah_terima (H:i) required bila is_draft=false. Draft boleh kosong (disimpan 0000-00-00 / 00:00:00). Backend tidak memvalidasi tanggal ≥ hari ini (mobile membatasi firstDate = hari ini).

BR-007 — Pengajuan: jenis asset wajib (teks bebas)

jenis_asset (string, di-trim, maks 150) required bila bukan draft; draft boleh kosong. Tidak ada validasi terhadap asset_kategori_m. Disimpan ke nama_kategori; id_asset_kategori_m dan urgensi diisi NULL. Field id_asset_kategori_m dan urgensi dari klien lama diabaikan → "Jenis asset wajib diisi." (422 VALIDATION_ERROR; bila ada field lain yang gagal, message induk "Data pengajuan asset belum lengkap.")

BR-008 — Pengajuan: alasan wajib saat dikirim

keterangan required bila bukan draft → "Alasan pengajuan wajib diisi." Urgensi tidak ada lagi pada Pengajuan (dihapus v1.4): tidak ada form, validasi, maupun tampilan.

BR-009 — Tolak/alokasi hanya saat pengajuan belum disetujui

Syarat: sumber_pengajuan = karyawan, status_approval = proses, tgl_approval IS NULL → "Pengajuan asset sudah tidak menunggu persetujuan." / "…sudah tidak dapat dialokasikan."

BR-010 — Alasan penolakan wajib (maks 255)

→ "Alasan penolakan wajib diisi."

BR-011 — Alokasi bebas lintas jenis (v1.4)

Admin dapat memilih asset apa pun dari stok gudang. Jenis yang diajukan karyawan (teks bebas) hanya informasi dan tidak dibandingkan dengan asset_data.id_asset_kategori_m; pengecekan "Asset harus sesuai dengan jenis yang diajukan." dihapus dan options alokasi tidak lagi memfilter kategori. Validasi lain tetap: tersedia + di gudang (BR-004), tidak aktif di transaksi lain (BR-005), status pengajuan (BR-009), otorisasi admin (BR-001), serta lock/transaksi.

BR-012 — Alokasi dapat disimpan sebagai draft dan diulang

Setiap alokasi menghapus item lama lalu menulis item baru. Draft tidak mengunci asset dan tidak mengisi tgl_approval.

BR-013 — Karyawan hanya melihat & mengonfirmasi transaksi miliknya yang sudah dikirim

Detail/konfirmasi memfilter id_karyawan = ctx.id_karyawan, bukan draft, dan untuk pengajuan harus sudah disetujui → "Pengajuan asset belum disubmit oleh admin."

BR-014 — Semua item pending wajib dinilai; rusak wajib alasan

→ "Seluruh asset penambahan wajib dicek." / "Alasan kerusakan wajib diisi." / "Tidak ada asset penambahan yang perlu dicek."

BR-015 — Serah terima all-or-nothing

Asset baru diserahkan (terpakai, pemegang karyawan, asset_trx_log) hanya jika seluruh item Normal. Jika ada Rusak, status tetap proses dan tidak ada asset yang berubah.

BR-016 — Tidak ada tindak lanjut asset rusak

⚠️ Belum ditemukan: endpoint ganti/tarik/batal untuk transaksi request. Lihat RISK-001.

BR-017 — Penomoran

ID header & item: id_company + YYYYMM + 3 digit (maks 999/bulan/company, dipakai bersama Penambahan & Pengajuan). no_trx = KRY-03-1-YYYYMMNNN.

10Business Flow

10.1 Penambahan (Admin → Karyawan)

Admin: Asset Karyawan → Penambahan → (+)
  → Pilih Karyawan → Tambah Asset (boleh multi kategori) → Jadwal Serah Terima (tgl + jam) → Catatan Tambahan
  → Simpan Draft  : status draft, asset TIDAK dikunci; dibuka lagi lewat Ubah Draft lalu disimpan/dikirim (PUT)
  → Submit ke Karyawan : status proses, asset_data → proses, notif ke karyawan
Karyawan: Asset Saya → banner "Penambahan Asset" → Konfirmasi Penambahan Asset
  → Normal/Rusak tiap asset → Konfirmasi Asset
  → semua Normal : status dikonfirmasi, asset → terpakai/karyawan, asset_trx_log, notif admin
  → ada Rusak    : status proses (tgl_approval terisi), tidak ada perubahan asset, notif admin "Laporan Asset Rusak"

10.2 Pengajuan (Karyawan → Admin → Karyawan)

Karyawan: Asset Saya → Pengajuan → (+)
  → Jenis Asset (ketik bebas) → Alasan → Simpan Draft / Submit ke Admin
  → Submit : status proses, tgl_approval NULL, tanpa item, notif ke semua admin
Admin: Asset Karyawan → Pengajuan (tab Pengajuan) → Detail
  → Tolak  : isi alasan → status ditolak, item dihapus, notif karyawan
  → Setujui: pilih asset apa pun dari stok + jadwal + catatan
       → Simpan Draft : "Draft Alokasi" (item tersimpan, asset belum dikunci)
       → Submit ke PIC: tgl_approval terisi, asset_data → proses, notif karyawan "Disetujui"
Karyawan: Pengajuan (tab Dikonfirmasi, "Menunggu Konfirmasi") → Konfirmasi Pengajuan Asset
  → sama seperti konfirmasi Penambahan

11Flow Berdasarkan Role

11.1 Admin Asset

1. Buka Asset Karyawan → aksi Penambahan atau Pengajuan (juga panel "Pengajuan Asset Perlu Diproses" berisi maks. 3 pengajuan tertua, tombol "Tinjau Pengajuan" / "Lanjutkan Alokasi").
2. Penambahan: tab Pending / Dikonfirmasi / Selesai; tombol + untuk membuat; tap kartu → detail (read-only).
3. Pengajuan: tab Pengajuan / Proses / Dikonfirmasi / Selesai; tap kartu → Konfirmasi Pengajuan Asset (detail) → Tolak atau Setujui → form Setujui Pengajuan Asset → Simpan Draft / Submit ke PIC.

11.2 Karyawan

1. Asset Saya → menu Pengajuan → daftar pengajuan (tab Pengajuan / Dikonfirmasi / Ditolak / Selesai) → + untuk membuat.
2. Pengajuan yang sudah dialokasikan & menunggu dicek dibuka langsung ke Konfirmasi Pengajuan Asset.
3. Penambahan dari admin muncul sebagai banner Penambahan Asset di Asset Saya (hanya yang pertama) dan via notifikasi.

11.3 Approver

Peran approver dijalankan Admin Asset pada Pengajuan (§11.1 langkah 3).

11.4 System

Lock master_company, generate ID/nomor, validasi asset & kategori, reservasi asset saat dikirim, penentuan status/label/tab, serah terima + asset_trx_log saat semua normal, notifikasi setelah commit.

12Flow Diagram

flowchart TD
    subgraph P[Penambahan - Admin]
        A1[Admin isi form penambahan] --> A2{Aksi}
        A2 -->|Simpan Draft| A3[status draft - bisa diubah lalu dikirim (PUT)]
        A2 -->|Submit ke Karyawan| A4[status proses, asset proses, notif karyawan]
    end
    subgraph Q[Pengajuan - Karyawan]
        B1[Karyawan ketik jenis asset dan alasan] --> B2{Aksi}
        B2 -->|Simpan Draft| B3[status draft - bisa diubah lalu dikirim (PUT)]
        B2 -->|Submit ke Admin| B4[status proses, tanpa item, notif admin]
        B4 --> B5{Keputusan admin}
        B5 -->|Tolak + alasan| B6[status ditolak, notif karyawan]
        B5 -->|Setujui| B7[Alokasi asset dari stok + jadwal]
        B7 -->|Simpan Draft| B8[Draft Alokasi]
        B8 --> B5
        B7 -->|Submit ke PIC| B9[tgl_approval terisi, asset proses, notif karyawan]
    end
    A4 --> C1[Karyawan: Konfirmasi Asset]
    B9 --> C1
    C1 --> C2{Semua item Normal?}
    C2 -->|Ya| C3[status dikonfirmasi - Selesai, asset terpakai, asset_trx_log, notif admin]
    C2 -->|Tidak| C4[status proses - Butuh Proses, asset tetap proses, notif admin]
    C4 --> C5[Tidak ada tindak lanjut di sistem]

13Sequence Diagram

13.1 Pengajuan karyawan sampai disetujui

sequenceDiagram
    actor K as Karyawan
    actor A as Admin
    participant M as Mobile
    participant CK as AssetKaryawanPengajuan_c
    participant CA as AssetAdminPenambahan_c
    participant R as AssetRequestKaryawan_m
    participant DB
    participant N as AssetNotification

    K->>M: Ketik jenis asset dan alasan, Submit ke Admin
    M->>CK: POST /asset/karyawan/pengajuan
    CK->>R: storePengajuanKaryawan()
    R->>DB: lock company, cek karyawan aktif
    R->>DB: INSERT header (sumber karyawan, proses, nama_kategori = jenis asset)
    CK->>N: pengajuan.diajukan (semua admin)
    A->>M: Buka detail, Setujui, pilih asset + jadwal
    M->>CA: GET /asset/pengajuan-karyawan/{id}/options
    M->>CA: POST /asset/pengajuan-karyawan/{id}/alokasi (is_draft false)
    CA->>R: alokasikanPengajuanAdmin()
    R->>DB: validasi asset tersedia di gudang, tidak aktif, tanpa filter kategori
    R->>DB: DELETE item lama, INSERT item baru
    R->>DB: UPDATE header jadwal, user_approval, tgl_approval
    R->>DB: UPDATE asset_data status proses
    CA->>N: pengajuan.disetujui (karyawan)
    CA-->>M: 200 SUCCESS

13.2 Konfirmasi karyawan (kedua alur)

sequenceDiagram
    actor K as Karyawan
    participant M as Konfirmasi Penambahan/Pengajuan
    participant C as AssetKaryawanPengajuan_c
    participant R as AssetRequestKaryawan_m
    participant DB
    participant N as AssetNotification

    K->>M: Nilai Normal/Rusak tiap asset, Konfirmasi Asset
    M->>C: POST /asset/karyawan/penambahan/{id}/konfirmasi
    C->>R: konfirmasiKaryawan()
    R->>DB: lock company, header milik karyawan FOR UPDATE
    R->>DB: UPDATE item status_item, ket_rusak
    R->>DB: UPDATE header status, user_approval, tgl_approval
    alt semua item normal
        R->>DB: UPDATE asset_data terpakai, pemegang karyawan
        R->>DB: INSERT asset_trx_log request_karyawan
        C->>N: penambahan.dikonfirmasi (admin)
    else ada item rusak
        C->>N: penambahan.rusak (admin)
    end
    C-->>M: 200 UPDATED

14Status Transaksi

Field asset_trx_request_karyawan.status_approval (enum status_request_karyawan: draft, proses, ditolak, dikonfirmasi; default proses). Label & tab dihitung dari status + tgl_approval + item, dan berbeda per sudut pandang.

14.1 Penambahan — tampilan Admin (requestStatusMetadata)

14.2 Pengajuan — tampilan Admin (pengajuanAdminStatusMetadata, draft tidak ditampilkan)

14.3 Pengajuan — tampilan Karyawan (pengajuanStatusMetadata)

Status item (status_item): belum_dicek → normal / rusak. Migrasi 2026_09_17_000008: nilai lama 0=draft, 1=proses, 2=ditolak, 3=dikonfirmasi.

15State Transition

stateDiagram-v2
    [*] --> draft: Simpan Draft (Admin / Karyawan)
    [*] --> proses: Submit (Admin / Karyawan)
    state proses {
        MenungguAdmin --> DraftAlokasi: Alokasi draft (Admin)
        DraftAlokasi --> DraftAlokasi: Alokasi draft ulang (Admin)
        MenungguAdmin --> MenungguKaryawan: Submit ke PIC (Admin)
        DraftAlokasi --> MenungguKaryawan: Submit ke PIC (Admin)
        MenungguKaryawan --> ButuhProses: Konfirmasi ada rusak (Karyawan)
    }
    proses --> ditolak: Tolak (Admin, hanya pengajuan belum disetujui)
    proses --> dikonfirmasi: Konfirmasi semua normal (Karyawan)
    ditolak --> [*]
    dikonfirmasi --> [*]

Status asset_data.status_asset: | Dari | Ke | Trigger | |---|---|---| | tersedia (gudang) | proses | Submit penambahan; Submit alokasi (bukan draft) | | proses (gudang) | terpakai (karyawan) | Konfirmasi dengan semua item normal | | proses | proses (tetap) | Konfirmasi dengan item rusak — tidak berubah |

16Struktur Database

17Relasi Database

erDiagram
    ASSET_TRX_REQUEST_KARYAWAN ||--o{ ASSET_TRX_REQUEST_KARYAWAN_ITEM : "id_asset_trx_request"
    ASSET_DATA ||--o{ ASSET_TRX_REQUEST_KARYAWAN_ITEM : "id_asset_data"
    ASSET_KATEGORI_M |o--o{ ASSET_TRX_REQUEST_KARYAWAN : "id_asset_kategori_m (legacy, nullable)"
    ASSET_KATEGORI_M ||--o{ ASSET_DATA : "id_asset_kategori_m"
    DATA_KARYAWAN ||--o{ ASSET_TRX_REQUEST_KARYAWAN : "id_karyawan (logis)"
    ASSET_DATA ||--o{ ASSET_TRX_LOG : "id_asset_data"
    ASSET_TRX_REQUEST_KARYAWAN ||--o{ ASSET_TRX_LOG : "id_transaksi (logis)"

    ASSET_TRX_REQUEST_KARYAWAN {
        varchar id_asset_trx_request_karyawan PK
        varchar no_trx
        enum sumber_pengajuan
        varchar id_asset_kategori_m "nullable, legacy"
        varchar nama_kategori "jenis asset teks bebas"
        varchar urgensi "nullable, legacy"
        varchar id_karyawan
        date tgl_serah_terima
        enum status_approval
        timestamp tgl_approval
        varchar id_company
    }
    ASSET_TRX_REQUEST_KARYAWAN_ITEM {
        varchar id_asset_trx_request_item PK
        varchar id_asset_trx_request FK
        varchar id_asset_data FK
        enum status_item
        varchar ket_rusak
    }
    ASSET_DATA {
        varchar id_asset_data PK
        varchar id_asset_kategori_m FK
        enum status_asset
        enum pemegang_asset
        varchar id_pemegang_asset
    }
    ASSET_TRX_LOG {
        varchar id_asset_trx_log PK
        varchar id_asset_data FK
        enum jenis_log
        varchar id_transaksi
    }

Relasi logis (tanpa ref DBML): id_karyawan → data_karyawan, id_asset_kategori_m (header, legacy/nullable) → asset_kategori_m, asset_trx_log.id_transaksi → header. Semua JOIN mencocokkan id_company. Kolom item parent_id ada di DBML tetapi selalu '' (tidak ada penggantian).

18Data Dictionary

18.1 asset_trx_request_karyawan

18.2 asset_trx_request_karyawan_item

18.3 asset_data (field yang dipakai)

id_asset_data, id_asset_kategori_m (snapshot kategori; tidak lagi dipakai membatasi alokasi), nama_asset, deskripsi, kode_asset, merek, status_asset (tersedia → proses → terpakai), pemegang_asset (gudang → karyawan), id_pemegang_asset, kondisi_awal (disalin ke log), tgl_update, user_update.

18.4 asset_trx_log (diisi saat semua normal)

jenis_log = request_karyawan, id_transaksi = ID header, nama_tabel_transaksi = asset_trx_request_karyawan, kondisi_awal = asset_data.kondisi_awal, kondisi_akhir = normal, posisi_awal = pemegang sebelumnya (gudang), posisi_akhir = pemegang_asset = karyawan, id_pemegang, nama_pemegang, user_input = karyawan.

19Database Index

Pencarian hasActiveRequestAsset berdasarkan atrki.id_asset_data tidak diawali kolom index yang ada (potensi lambat, ⚠️ belum diukur).

20Backend Architecture

routes/modules/asset/RouteAsset.php (prefix /asset, middleware jwt.api + jwt.ctx)
   ↓
AssetAdminPenambahan_c / AssetKaryawanPengajuan_c  (validateRequest inline, accessError)
   ↓
AssetRequestKaryawan_m  ← extends Asset_m (lock, sequence, findActiveKaryawan, findAssetAdmin, hasActiveOnboardingAsset)
   ↓                    ← memakai AssetAdmin_m::getOnboardingOptions untuk opsi penambahan/alokasi
DB (Query Builder, DB::transaction retry 3)
   ↓
ApiResponse + AssetNotification (setelah commit)

21Backend Business Logic

Semua aksi tulis: DB::transaction(fn, 3) + lockCompany().

21.1 Penambahan — store

1. Validasi request → cek admin.
2. Lock; requestLockedAssets (tersedia + gudang, FOR UPDATE), jumlah harus sama.
3. hasActiveOnboardingAsset, hasActiveRequestAsset.
4. findActiveKaryawan, findAssetAdmin.
5. Jadwal wajib bila bukan draft.
6. Generate ID + no_trx = KRY-03-1-YYYYMMNNN.
7. Tentukan kategori: satu kategori → id & nama; banyak → '' & "Multi Kategori".
8. INSERT header (sumber_pengajuan = admin, draft/proses, tgl_approval NULL).
9. INSERT item (belum_dicek, snapshot).
10. Hanya jika bukan draft: UPDATE asset_data.status_asset = proses.
11. Notifikasi penambahan.dikirim (bukan draft). Response 201.

21.2 Pengajuan — storePengajuanKaryawan

Lock → karyawan aktif → jenis_asset (di-trim) dan alasan wajib bila bukan draft → generate ID/no_trx → INSERT header (sumber = karyawan, nama_kategori = jenis_asset, id_asset_kategori_m = NULL, urgensi = NULL, tanpa item, jadwal kosong) → notifikasi pengajuan.diajukan (bukan draft). Response 201.

21.3 Tolak — tolakPengajuanAdmin

Lock → admin → header (sumber karyawan, FOR UPDATE) harus proses & tgl_approval NULL → alasan wajib → DELETE item (draft alokasi) → UPDATE header ket_tolak, status_approval = ditolak, user_approval, tgl_approval = now → notifikasi pengajuan.ditolak.

21.4 Alokasi — alokasikanPengajuanAdmin

Lock → admin → header syarat sama dengan tolak → asset tersedia di gudang (tanpa filter kategori; jenis asset pengajuan hanya informasi) → tidak aktif di onboarding/penambahan lain (kecuali transaksi ini) → jadwal wajib bila bukan draft → DELETE item lama → INSERT item baru → UPDATE header jadwal, ket_tolak = '', user_approval/tgl_approval (hanya bila bukan draft) → bila bukan draft UPDATE asset_data = proses → notifikasi pengajuan.disetujui (bukan draft). Response 200 SUCCESS (kirim) / UPDATED (draft).

21.5 Konfirmasi — konfirmasiKaryawan

1. Lock; header milik karyawan (FOR UPDATE), status proses; pengajuan harus sudah disetujui.
2. Karyawan aktif; item dikunci; pending = belum_dicek.
3. Validasi lengkap & alasan rusak.
4. UPDATE item.
5. semuaNormal atas seluruh item → dikonfirmasi, selain itu tetap proses.
6. UPDATE header status_approval, user_approval, tgl_approval = now.
7. Jika semua normal: UPDATE asset_data terpakai/karyawan/id_pemegang_asset + INSERT asset_trx_log per asset.
8. Jika ada rusak: tidak ada perubahan asset_data (tetap proses).
9. Notifikasi penambahan.dikonfirmasi / penambahan.rusak.

21.6 Query baca

• Options penambahan: AssetAdmin_m::getOnboardingOptions(excludeEmployeesWithOnboarding: false) → semua karyawan aktif, asset tersedia di gudang, pohon kategori.
• Options alokasi: sama (seluruh stok tersedia di gudang), tanpa filter kategori (v1.4). Hanya bila pengajuan proses & belum disetujui (selain itu 404).
• Options pengajuan karyawan (legacy): hanya kategori_asset (semua kategori company); daftar urgensi dihapus. Mobile v1.4 tidak lagi memanggil endpoint ini.
• List: JOIN item, hitung jumlah_asset, jumlah_pending, jumlah_rusak; urut tgl_input DESC.
• Detail karyawan pengajuan: sebelum disetujui, jadwal dikosongkan, jumlah_asset = 0, items = [].
• Detail (getDetail): objek karyawan memuat jabatan (LEFT JOIN master_jabatan lewat data_karyawan.id_jabatan; '' bila kosong) selain cabang dan divisi.
• Response list/detail/pending Pengajuan: nama_kategori dan nama_asset = teks jenis asset; id_asset_kategori_m = '' untuk data baru; tanpa urgensi (termasuk detail Penambahan admin yang berbagi query; penulisan urgensi pada store() Penambahan admin tetap ada, nullable).

22Dampak terhadap asset_data

Draft penambahan dan draft alokasi tidak mengubah asset_data.

23API Documentation

Endpoint terkait: GET /asset/karyawan/onboarding (Asset Saya, bagian penambahan[]) dan GET /asset/summary (pengajuan_perlu_proses, pengajuan_pending). Endpoint hapus draft, batal, dan tindak lanjut rusak: ⚠️ Belum ditemukan. Edit draft tersedia lewat PUT (API-016, API-017).

Format response sama dengan modul asset lain: { "code", "message", "data" }; error validasi { "code": "VALIDATION_ERROR", "message", "errors" }. HTTP: 200/201, 401, 403, 404, 422, 500.

24Detail Setiap API

Header umum: Authorization: Bearer <token>, Content-Type: application/json, Accept: application/json, locale, versi-app.

API-001 — Opsi Penambahan

GET /asset/penambahan-karyawan/options

Response data: { "karyawan": [{id_karyawan, nik, nama_karyawan}], "kategori_asset": [{id_asset_kategori_m, parent_id, flag_parent, nama_kategori}], "assets": [{id_asset_data, kode_asset, nama_asset, id_asset_kategori_m, kategori_asset, merek, deskripsi, kondisi_awal}] }. Message: "Opsi penambahan asset berhasil ditemukan." Semua karyawan aktif ditampilkan (tidak dikecualikan seperti onboarding).

API-002 — List Penambahan

GET /asset/penambahan-karyawan?tab=pending&limit=20&offset=0

Tab: pending = draft atau proses belum dikonfirmasi karyawan; dikonfirmasi = proses & tgl_approval terisi; selesai = ditolak/dikonfirmasi.

{
  "code": "SUCCESS",
  "message": "Data penambahan asset karyawan berhasil ditemukan.",
  "data": {
    "filters": [
      {"value": "pending", "label": "Pending"},
      {"value": "dikonfirmasi", "label": "Dikonfirmasi"},
      {"value": "selesai", "label": "Selesai"}
    ],
    "requests": [
      {
        "id": "CMP001202609004",
        "no_trx": "KRY-03-1-202609004",
        "id_asset_kategori_m": "CMP001202601002",
        "nama_kategori": "Laptop",
        "keterangan": "",
        "ket_tolak": "",
        "id_karyawan": "KRY0002",
        "nik_karyawan": "EMP-002",
        "nama_karyawan": "Sari Contoh",
        "tgl_pengajuan": "2026-09-26",
        "tgl_serah_terima": "2026-09-29",
        "jam_serah_terima": "09:00:00",
        "keterangan_serah_terima": "Ambil di ruang IT",
        "status_approval": "proses",
        "status_label": "Menunggu Diterima",
        "tab": "pending",
        "jumlah_asset": 1,
        "jumlah_pending": 1,
        "jumlah_rusak": 0,
        "tgl_approval": ""
      }
    ],
    "pagination": {"limit": 20, "offset": 0, "next_offset": 1, "has_more": false}
  }
}

Tanpa parameter → data berupa array.

API-003 — Buat Penambahan

POST /asset/penambahan-karyawan

{
  "id_karyawan": "KRY0002",
  "asset_ids": ["CMP00120260100005"],
  "tgl_serah_terima": "2026-09-29",
  "jam_serah_terima": "09:00",
  "keterangan_serah_terima": "Ambil di ruang IT",
  "keterangan": "",
  "urgensi": "",
  "is_draft": false
}

Database impact:

INSERT asset_trx_request_karyawan (sumber_pengajuan = admin)
INSERT asset_trx_request_karyawan_item
UPDATE asset_data (status_asset = proses)   -- hanya bila bukan draft
INSERT notif_data                            -- hanya bila bukan draft

{ "code": "CREATED", "message": "Penambahan asset berhasil dikirim ke karyawan.",
  "data": { "id": "CMP001202609004", "no_trx": "KRY-03-1-202609004",
            "status_approval": "proses", "status_label": "Menunggu Diterima", "tab": "pending" } }

Draft: "Draft penambahan asset berhasil disimpan." Error 422: "Satu atau beberapa asset tidak tersedia untuk penambahan.", "…sedang diproses pada onboarding.", "…sedang diproses pada penambahan lain.", "Karyawan tidak ditemukan atau tidak aktif.", "Pengguna tidak terdaftar sebagai admin asset.", "Nomor transaksi untuk periode ini sudah mencapai batas." 500: "Terjadi kesalahan saat menyimpan penambahan asset."

API-004 — Detail Penambahan (Admin)

GET /asset/penambahan-karyawan/{id}

{
  "code": "SUCCESS",
  "message": "Detail penambahan asset berhasil ditemukan.",
  "data": {
    "id": "CMP001202609004",
    "no_trx": "KRY-03-1-202609004",
    "id_asset_kategori_m": "CMP001202601002",
    "nama_kategori": "Laptop",
    "keterangan": "",
    "ket_tolak": "",
    "tgl_pengajuan": "2026-09-26",
    "tgl_serah_terima": "2026-09-29",
    "jam_serah_terima": "09:00:00",
    "keterangan_serah_terima": "Ambil di ruang IT",
    "status_approval": "proses",
    "tgl_approval": "",
    "status_label": "Menunggu Diterima",
    "tab": "pending",
    "jumlah_asset": 1,
    "karyawan": { "nik": "EMP-002", "nama_karyawan": "Sari Contoh", "jabatan": "Staff Finance", "cabang": "Kantor Pusat", "divisi": "Finance" },
    "items": [
      {
        "id_item": "CMP001202609010",
        "parent_id": "",
        "id_asset_data": "CMP00120260100005",
        "kode_asset": "LPT-0005",
        "nama_asset": "Laptop 14 inch",
        "deskripsi": "Charger, tas",
        "kategori_asset": "Laptop",
        "merek": "MerekX",
        "status_item": "belum_dicek",
        "ket_rusak": "",
        "perlu_dicek": true,
        "diganti": false
      }
    ]
  }
}

404: "Penambahan asset tidak ditemukan." (hanya sumber admin). karyawan.jabatan (v1.4) berasal dari join master_jabatan, '' bila kosong; key divisi dipertahankan (label UI: Departemen). Response tidak memuat urgensi.

API-005 — List Pengajuan (Admin)

GET /asset/pengajuan-karyawan?tab=pengajuan&limit=20&offset=0

tab: pengajuan (belum disetujui, termasuk Draft Alokasi), proses (disetujui, ada item pending), dikonfirmasi (disetujui, tanpa item pending — kasus rusak), selesai (ditolak/dikonfirmasi). Draft karyawan tidak pernah tampil. Struktur data sama dengan API-002 dengan filters Pengajuan/Proses/Dikonfirmasi/Selesai. Message: "Data pengajuan asset karyawan berhasil ditemukan."

API-006 — Detail Pengajuan (Admin)

GET /asset/pengajuan-karyawan/{id}

Struktur sama dengan API-004 (keterangan = alasan; nama_kategori dan nama_asset = teks jenis asset, id_asset_kategori_m = '' untuk data baru; tanpa urgensi), label/tab dari §14.2. 404 "Pengajuan asset tidak ditemukan." bila tidak ada atau masih draft.

API-007 — Opsi Alokasi

GET /asset/pengajuan-karyawan/{id}/options

Sama dengan API-001: assets memuat seluruh stok tersedia di gudang, tanpa filter kategori (v1.4). 404 "Opsi pengajuan asset tidak ditemukan." bila pengajuan bukan proses atau sudah disetujui. Message: "Opsi persetujuan pengajuan asset berhasil ditemukan."

API-008 — Tolak Pengajuan

POST /asset/pengajuan-karyawan/{id}/tolak

{ "ket_tolak": "Stok laptop belum tersedia bulan ini" }

Database impact: DELETE item (bila ada draft alokasi), UPDATE header (ditolak, ket_tolak, user_approval, tgl_approval), INSERT notif_data.

{ "code": "UPDATED", "message": "Pengajuan asset berhasil ditolak.",
  "data": { "id": "CMP001202609005", "no_trx": "KRY-03-1-202609005",
            "status_approval": "ditolak", "status_label": "Ditolak", "tab": "selesai" } }

422: "Pengajuan asset tidak ditemukan.", "Pengajuan asset sudah tidak menunggu persetujuan." 500: "Terjadi kesalahan saat menolak pengajuan asset."

API-009 — Alokasi / Setujui Pengajuan

POST /asset/pengajuan-karyawan/{id}/alokasi

{
  "asset_ids": ["CMP00120260100007"],
  "tgl_serah_terima": "2026-09-30",
  "jam_serah_terima": "10:00",
  "keterangan_serah_terima": "Serah terima di ruang IT lantai 2",
  "is_draft": false
}

Alokasi tidak dibatasi kategori (v1.4): asset apa pun dari stok boleh dipilih. Validasi sama dengan API-003 untuk asset_ids, jadwal, keterangan_serah_terima, is_draft (message: "Data persetujuan pengajuan belum lengkap.").

Database impact:

DELETE asset_trx_request_karyawan_item (item lama)
INSERT asset_trx_request_karyawan_item
UPDATE asset_trx_request_karyawan (jadwal, ket_tolak='', user_approval/tgl_approval bila kirim)
UPDATE asset_data (status_asset = proses)   -- bila bukan draft
INSERT notif_data                            -- bila bukan draft

{ "code": "SUCCESS", "message": "Pengajuan asset berhasil disetujui.",
  "data": { "id": "CMP001202609005", "no_trx": "KRY-03-1-202609005", "status_approval": "proses",
            "status_label": "Menunggu Konfirmasi", "tab": "proses", "jumlah_asset": 1 } }

Draft: code UPDATED, "Draft alokasi pengajuan asset berhasil disimpan.", label "Draft Alokasi", tab pengajuan. 422: "Pengajuan asset sudah tidak dapat dialokasikan.", "Satu atau beberapa asset tidak tersedia.", "…sedang diproses pada onboarding.", "…sedang diproses pada penambahan lain.", "Tanggal/Jam serah terima wajib diisi." 500: "Terjadi kesalahan saat menyetujui pengajuan asset."

API-010 — Opsi Pengajuan (Karyawan) — legacy

GET /asset/karyawan/pengajuan/options

{
  "code": "SUCCESS",
  "message": "Opsi pengajuan asset berhasil ditemukan.",
  "data": {
    "kategori_asset": [
      {"id_asset_kategori_m": "CMP001202601001", "parent_id": "", "flag_parent": 1, "nama_kategori": "Elektronik"},
      {"id_asset_kategori_m": "CMP001202601002", "parent_id": "CMP001202601001", "flag_parent": 0, "nama_kategori": "Laptop"}
    ]
  }
}

Catatan v1.4: urgensi dihapus dari response. kategori_asset dipertahankan hanya untuk klien lama; mobile v1.4 tidak lagi memanggil endpoint ini.

API-011 — List Pengajuan Saya

GET /asset/karyawan/pengajuan?tab=pengajuan&limit=20&offset=0

tab: pengajuan (draft + menunggu admin), dikonfirmasi (disetujui, belum selesai), ditolak, selesai. Sebelum disetujui: jadwal dikosongkan dan jumlah_asset = 0. Filters: Pengajuan/Dikonfirmasi/Ditolak/Selesai.

API-012 — Buat Pengajuan

POST /asset/karyawan/pengajuan

{ "jenis_asset": "Laptop", "keterangan": "Laptop lama sering mati, butuh untuk presentasi klien",
  "is_draft": false }

Database impact: INSERT asset_trx_request_karyawan (sumber karyawan, tanpa item; nama_kategori = jenis_asset, id_asset_kategori_m = NULL, urgensi = NULL); INSERT notif_data (bukan draft).

{ "code": "CREATED", "message": "Pengajuan asset berhasil dikirim ke admin.",
  "data": { "id": "CMP001202609005", "no_trx": "KRY-03-1-202609005",
            "status_approval": "proses", "status_label": "Menunggu Konfirmasi", "tab": "pengajuan" } }

422: "Karyawan tidak ditemukan atau tidak aktif." Kegagalan validasi: 422 VALIDATION_ERROR "Jenis asset wajib diisi." / "Alasan pengajuan wajib diisi." (bila lebih dari satu field gagal, message induk "Data pengajuan asset belum lengkap."). 500: "Terjadi kesalahan saat menyimpan pengajuan asset."

Kompatibilitas klien lama (< v1.4): submit tanpa jenis_asset ditolak 422 "Jenis asset wajib diisi."; id_asset_kategori_m dan urgensi dari klien lama diabaikan. Draft lama mempertahankan nama_kategori yang tersimpan (lihat API-017). Response list/detail mengisi nama_kategori dan nama_asset dengan teks jenis asset; id_asset_kategori_m bernilai '' untuk data baru.

API-013 — Detail Pengajuan Saya

GET /asset/karyawan/pengajuan/{id}

Struktur seperti API-004 + isu_rusak; sebelum disetujui items = [], jadwal kosong. 404 "Pengajuan asset tidak ditemukan."

API-014 — Detail untuk Konfirmasi

GET /asset/karyawan/penambahan/{id}

Berlaku untuk kedua sumber: transaksi milik karyawan, bukan draft; pengajuan harus sudah disetujui. Struktur seperti API-004. 404 "Penambahan asset tidak ditemukan."

API-015 — Konfirmasi Asset

POST /asset/karyawan/penambahan/{id}/konfirmasi

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

Database impact:

UPDATE asset_trx_request_karyawan_item (status_item, ket_rusak)
UPDATE asset_trx_request_karyawan (status_approval, user_approval, tgl_approval)
UPDATE asset_data (terpakai, pemegang karyawan)   -- hanya jika semua normal
INSERT asset_trx_log (request_karyawan)                -- hanya jika semua normal
INSERT notif_data (semua admin)

{ "code": "UPDATED", "message": "Penambahan asset berhasil dikonfirmasi.",
  "data": { "id": "CMP001202609004", "no_trx": "KRY-03-1-202609004",
            "status_approval": "dikonfirmasi", "status_label": "Selesai", "tab": "selesai" } }

Ada rusak: "Laporan kerusakan penambahan asset berhasil dikirim.", status_approval: proses, label "Isu Rusak", tab dikonfirmasi. 422: "Penambahan asset tidak ditemukan.", "Penambahan asset sudah tidak menunggu konfirmasi.", "Pengajuan asset belum disubmit oleh admin.", "Karyawan tidak ditemukan atau tidak aktif.", "Tidak ada asset penambahan yang perlu dicek.", "Seluruh asset penambahan wajib dicek.", "Alasan kerusakan wajib diisi.", "Satu atau beberapa asset penambahan tidak ditemukan." 500: "Terjadi kesalahan saat mengonfirmasi penambahan asset."

API-016 — Ubah / Kirim Draft Penambahan

PUT /asset/penambahan-karyawan/{id}

Body dan validasi sama dengan API-003 (id_karyawan, asset_ids[], jadwal serah terima, is_draft). Hanya untuk penambahan sumber admin berstatus draft; selain itu 422 "Hanya draft penambahan langsung yang dapat diperbarui.". id, no_trx, dan tanggal pengajuan dipertahankan; item lama dihapus lalu ditulis ulang. Dengan is_draft=false status menjadi proses, asset dikunci (asset_data.status_asset = proses), dan notifikasi penambahan.dikirim dikirim.

Response: code UPDATED, "Draft penambahan asset berhasil disimpan." (draft) atau "Penambahan asset berhasil dikirim ke karyawan.".

API-017 — Ubah / Kirim Draft Pengajuan Saya

PUT /asset/karyawan/pengajuan/{id}

Body dan validasi sama dengan API-012 (jenis_asset, keterangan, is_draft). Pada PUT draft (is_draft=true) tanpa key jenis_asset, nama_kategori yang tersimpan dipertahankan (draft lama tetap utuh); bila key dikirim, nilainya menggantikan nama_kategori dan id_asset_kategori_m di-NULL-kan, urgensi selalu NULL. Saat is_draft=false, jenis_asset dan keterangan wajib (422 "Jenis asset wajib diisi." / "Alasan pengajuan wajib diisi."; message induk "Data pengajuan asset belum lengkap."). Hanya untuk pengajuan milik pemanggil yang masih draft, belum disetujui (tgl_approval kosong), dan belum punya item; selain itu 422 "Pengajuan asset sudah tidak dapat diubah karena bukan draft." dan 404 "Pengajuan asset tidak ditemukan." bila bukan miliknya. Dengan is_draft=false status menjadi proses, tgl_pengajuan diisi hari ini, dan notifikasi pengajuan.diajukan dikirim.

Response: code UPDATED, "Draft pengajuan asset berhasil disimpan." atau "Pengajuan asset berhasil dikirim ke admin.".

25Mobile Architecture

Page → Bloc → Api Service → ApiClient (Dio + Bearer JWT) → Backend

Routes: | Route | Page | Event awal | |---|---|---| | /asset_admin_penambahan_karyawan | List Penambahan | LoadAssetRequestKaryawanList (tab pending) | | /asset_admin_add_penambahan_karyawan | Form Penambahan | LoadAssetRequestKaryawanOptions | | /asset_admin_detail_penambahan_karyawan | Detail Penambahan | LoadAssetRequestKaryawanDetail(id) | | /asset_admin_pengajuan_karyawan | List Pengajuan admin | LoadAssetPengajuanAdminList (tab pengajuan) | | /asset_admin_detail_pengajuan_karyawan | Detail Pengajuan admin (title "Konfirmasi Pengajuan Asset") | LoadAssetPengajuanAdminDetail(id) | | /asset_admin_setujui_pengajuan_karyawan | Form Setujui | LoadAssetPengajuanAdminOptions(id), argumen record | | /asset_pengajuan | List Pengajuan karyawan | LoadAssetPengajuanKaryawanList | | /asset_tambah_pengajuan | Form Pengajuan | Form baru: tanpa event awal; LoadAssetPengajuanKaryawanDraft(id) saat ubah draft | | /asset_detail_pengajuan | Detail Pengajuan karyawan | LoadAssetPengajuanKaryawanDetail(id) | | /asset_konfirmasi_pengajuan | Konfirmasi (isPengajuan: true) | LoadAssetKonfirmasiPenambahan(id) | | /asset_konfirmasi_penambahan | Konfirmasi Penambahan | LoadAssetKonfirmasiPenambahan(id) |

26Mobile Screen

26.1 Penambahan Asset (Admin) — list

Tab Pending / Dikonfirmasi / Selesai; kartu: no transaksi, "Tanggal Penambahan", badge status, nik - nama, "{jumlah} Asset", "Jadwal Serah Terima" (bila ada). Tombol + ("Tambah penambahan asset"). Tap → detail.

26.2 Tambah Penambahan Asset (Admin)

26.3 Detail Penambahan Asset (Admin)

Tanggal Penambahan, badge status, Nomor Pengajuan; Data Karyawan (nama, NIK, Jabatan, Cabang, Departemen); Jadwal Serah Terima (tanggal, jam, catatan); daftar asset. Tidak ada tombol aksi dan kondisi item (Normal/Rusak) tidak ditampilkan.

Alur status: AssetAlurStepper.pengajuan (Pengajuan → Alokasi → Konfirmasi → Selesai; berpindah dari Alokasi ke Konfirmasi setelah admin mengalokasikan asset; disembunyikan bila ditolak). File: Shared/Widgets/AssetAlurWidgets.dart.

26.4 Pengajuan Asset (Admin) — list

Tab Pengajuan / Proses / Dikonfirmasi / Selesai; kartu menampilkan tanggal, status, karyawan, jadwal (bila ada); tanpa Urgensi (dihapus v1.4).

26.5 Konfirmasi Pengajuan Asset (Admin, detail)

Tanggal Pengajuan & status; Data Karyawan (Jabatan, Cabang, Departemen); Pengajuan Asset (Jenis Asset sebagai teks, Alasan); Alasan Penolakan (bila ditolak); Jadwal Serah Terima (bila ada); daftar asset (bila dialokasikan). Tombol Tolak (merah; bottom sheet "Alasan Penolakan" wajib → Kirim) dan Setujui (hijau), keduanya berbentuk pil tinggi 44, tampil jika status proses dan tab pengajuan (termasuk Draft Alokasi).

Stepper alur status sama seperti §26.3 (AssetAlurStepper.pengajuan).

26.6 Setujui Pengajuan Asset (Admin)

Ringkasan Jenis Asset (teks) dan alasan, tanpa Urgensi; "Penambahan Asset" + tombol "Tambah Asset" (lebar penuh, pil hijau; picker memakai seluruh kategori tanpa filter jenis pengajuan, draft alokasi terisi otomatis); Jadwal Serah Terima & Jam (wajib saat kirim; kosong sampai admin mengisi: nilai 0000-00-00 / 00:00:00 dari DB dianggap kosong, tanggal bertahun < 2000 dan jamnya dikosongkan, sehingga tidak lagi tampil 30-11-0001 / 00:00); Catatan Tambahan; tombol Simpan Draft (biru terisi) / Submit ke PIC (outline biru), keduanya pil tinggi 44.

26.7 Pengajuan Asset (Karyawan) — list

Tab Pengajuan / Dikonfirmasi / Ditolak / Selesai; kartu: tanggal, status (Draft, Menunggu Konfirmasi, Dikonfirmasi Admin, Butuh Proses, Ditolak, Selesai), alasan (tanpa Urgensi). Tap: bila disetujui & ada item pending → Konfirmasi Pengajuan Asset, selain itu → Detail.

26.8 Tambah Pengajuan Asset (Karyawan)

26.9 Detail Pengajuan Asset (Karyawan)

Nomor Pengajuan, data karyawan (Jabatan, Cabang, Departemen), Jenis Asset, Alasan, Alasan Penolakan (bila ditolak), Jadwal, asset beserta kondisi Normal/Rusak dan Report Kerusakan.

Stepper alur status sama seperti §26.3 (AssetAlurStepper.pengajuan).

26.10 Konfirmasi Penambahan / Pengajuan Asset (Karyawan)

Info transaksi (Tanggal & Kode Penambahan / Nomor Pengajuan), Data Karyawan (Jabatan, Cabang, Departemen), Jadwal Serah Terima, (Pengajuan: Jenis Asset, Alasan), "Penting! Periksa kondisi asset…", per asset Kelengkapan + tombol Normal/Rusak + "Report Kerusakan " (maks 255), pernyataan tanggung jawab, tombol Konfirmasi Asset*.

26.11 Asset Saya

Menu Pengajuan; banner Penambahan Asset untuk transaksi pertama yang menunggu dicek.

27Mobile → API

28API → Mobile

29Mapping Mobile → API → Database

30Mapping Database → API → Mobile

31Validation

31.1 Mobile

31.2 Backend

Lihat §9 dan §24.

31.3 Database

ENUM sumber_pengajuan, status_approval, status_item; UNIQUE no_trx (DBML); NOT NULL default untuk jadwal (0000-00-00, 00:00:00); id_asset_kategori_m dan urgensi NULL diperbolehkan setelah SQL v1.4 dijalankan.

31.4 Ringkasan per Field

32Error Handling

33Audit Trail

34Notification

Mekanisme sama dengan modul asset lain: INSERT notif_data + push FCM, dipanggil setelah commit, kegagalan hanya di-log.

35Security

36Manual Book User/Admin

A. Admin — Penambahan Asset

1. Buka Asset Karyawan → aksi Penambahan → halaman Penambahan Asset (tab Pending, Dikonfirmasi, Selesai).
2. Tekan + → Tambah Penambahan Asset.
3. Pilih Karyawan.
4. Tambah Asset → pilih kategori → pilih asset (boleh beberapa, boleh beda kategori).
5. Isi Jadwal Serah Terima dan Jam Serah Terima, serta Catatan Tambahan bila perlu.
6. Tekan Submit ke Karyawan. Asset langsung dikunci dan karyawan mendapat notifikasi.

B. Admin — Meninjau Pengajuan

1. Buka Asset Karyawan → aksi Pengajuan (atau panel Pengajuan Asset Perlu Diproses → Tinjau Pengajuan).
2. Tab Pengajuan → pilih pengajuan → halaman Konfirmasi Pengajuan Asset (Jenis Asset, Alasan).
3. Menolak: tekan Tolak → isi Alasan Penolakan → Kirim.
4. Menyetujui: tekan Setujui → halaman Setujui Pengajuan Asset → Tambah Asset (boleh asset apa pun dari stok; jenis yang diajukan hanya informasi) → isi jadwal (kosong sampai Anda mengisi) → Submit ke PIC. - Simpan Draft menyimpan pilihan sebagai Draft Alokasi; buka lagi dari tab Pengajuan (Lanjutkan Alokasi) untuk mengirim.
5. Pengajuan berpindah ke tab Proses (menunggu karyawan), lalu Selesai setelah karyawan mengonfirmasi semua asset Normal.

C. Karyawan — Mengajukan Asset

1. Buka Asset Saya → menu Pengajuan → tekan +.
2. Ketik Jenis Asset (teks bebas, maks 150 karakter, mis. Laptop atau Monitor 24 inch) dan isi Alasan.
3. Tekan Submit ke Admin.
4. Pantau status di tab Pengajuan, Dikonfirmasi, Ditolak, atau Selesai. Jika ditolak, alasan tampil di detail.

D. Karyawan — Menerima & Mengonfirmasi Asset

1. Buka notifikasi Penambahan Asset Baru / Pengajuan Asset Disetujui, banner Penambahan Asset di Asset Saya, atau pengajuan berstatus Menunggu Konfirmasi di tab Dikonfirmasi.
2. Periksa setiap asset secara fisik, pilih Normal atau Rusak (isi Report Kerusakan bila rusak).
3. Tekan Konfirmasi Asset. - Semua Normal → asset menjadi milik Anda, status Selesai. - Ada Rusak → status Butuh Proses; hubungi Admin Asset karena tindak lanjut belum tersedia di aplikasi.

37Kondisi Button

38Testing Scenario

Happy Path

Validation

Status

Asset

API / Security / Network

39Temuan Ketidaksesuaian

40Edge Case

41Potential Bug / Technical Risk

RISK-001 — Laporan rusak membuat transaksi & asset macet (TINGGI)

Lokasi: AssetRequestKaryawan_m::konfirmasiKaryawan; tidak ada route tindak lanjut. Masalah: Jika satu item rusak, status tetap proses, tidak ada item pending, semua asset tetap status_asset = proses (termasuk yang normal), dan tidak ada endpoint ganti/tarik/batal. UI admin read-only dan tidak menampilkan item rusak. Impact: Transaksi tidak pernah selesai; asset tidak bisa dipakai transaksi apa pun (hanya status tersedia yang bisa dipilih). Current Handling: Notifikasi "Laporan Asset Rusak" ke admin saja. Recommendation: Implementasi alur seperti Onboarding (ganti asset rusak) atau aksi admin untuk melepas asset rusak ke gudang dan menyerahkan yang normal.

RISK-002 — Asset bekas penambahan terkunci selamanya (TINGGI) — ✅ DIPERBAIKI v1.1

Status: Diperbaiki 2026-09-29. hasActiveRequestAsset kini hanya memfilter status_approval = proses. Regression test: tests/Asset/AssetModelTest.php::test_returned_asset_from_confirmed_addition_can_be_added_again. Lokasi (sebelum): hasActiveRequestAsset (whereIn status_approval [proses, dikonfirmasi], tanpa filter status item). Masalah: Transaksi yang sudah selesai tetap dihitung aktif. Setelah asset dikembalikan ke gudang (Retur/Offboarding menyetel tersedia + gudang), asset muncul di pilihan tetapi store/alokasi menolak "…sedang diproses pada penambahan lain." Impact: Asset tidak bisa ditambahkan ulang via Penambahan/Pengajuan. Recommendation: Batasi ke STATUS_PROSES (dan item belum diserahkan).

RISK-003 — Draft tidak dapat dihapus (RENDAH)

Lokasi: Route (ada PUT untuk edit/kirim draft, tetapi tidak ada DELETE untuk penambahan & pengajuan karyawan). Masalah: Draft Penambahan (admin) dan draft Pengajuan (karyawan) kini dapat diedit dan dikirim, tetapi tidak dapat dihapus. Draft penambahan juga tidak mengunci asset. Recommendation: Tambah endpoint hapus draft (pola onboarding).

RISK-004 — no_trx UNIQUE global tanpa kode company

Lokasi: DBML no_trx [unique], format KRY-03-1-YYYYMMNNN. Masalah: Dua company pada bulan & urutan sama menghasilkan no_trx identik. Impact: Jika unique index fisik ada, insert company kedua gagal (500). ⚠️ Asumsi: belum diverifikasi di DB. Recommendation: Unique (id_company, no_trx).

RISK-005 — Tanggal nol 0000-00-00

Lokasi: store, storePengajuanKaryawan, alokasikanPengajuanAdmin. Masalah: MySQL strict mode (NO_ZERO_DATE) menolak nilai ini. ⚠️ Asumsi: tergantung konfigurasi SQL mode. Recommendation: Kolom nullable.

RISK-006 — Jejak approval tertimpa

user_approval/tgl_approval dari admin ditimpa karyawan saat konfirmasi (INC-10).

RISK-007 — Jadwal lampau diterima backend

parseJadwalValue (validasi tanggal ≥ pengajuan) tersedia di Asset_m tetapi tidak dipakai fitur ini.

RISK-008 — Tidak ada pembatasan pengajuan ganda

Karyawan dapat membuat pengajuan jenis sama berulang kali.

RISK-009 — Kapasitas penomoran

3 digit per bulan per company, dipakai bersama Penambahan & Pengajuan (header) dan semua item.

RISK-010 — Notifikasi di luar transaksi

Kegagalan notif hanya di-log.

RISK-011 — Tolak menghapus draft alokasi (hard delete)

Tidak ada jejak asset yang sempat dialokasikan.

RISK-012 — SQL v1.4 belum dijalankan sebelum deploy API (TINGGI)

Kolom id_asset_kategori_m masih NOT NULL di DB sampai sql-pengajuan-karyawan-jenis-asset-bebas.sql dijalankan, sehingga INSERT Pengajuan baru (NULL) gagal (500). Status saat ini: SQL belum dijalankan (langkah user, sebelum API dipakai). Cek charset/collation nama_kategori (SHOW CREATE TABLE) lebih dulu.

RISK-013 — Jenis asset teks bebas tidak ternormalisasi (RENDAH)

Tidak ada master atau validasi isi; ejaan beragam menyulitkan laporan per jenis. Bila nama_kategori memakai latin1, karakter non-latin/emoji dapat gagal atau rusak (pertimbangkan utf8mb4).

42Dependency

Master Company / Data Karyawan / Asset Admin
      ↓
Master Kategori ──► Penambahan (snapshot kategori)   [Pengajuan: jenis asset teks bebas, tanpa master]
      ↓
Asset Data (tersedia @gudang)
      ↓
Request / Penambahan (header + item) ──► Notifikasi
      ↓ konfirmasi semua normal
Asset Data (terpakai, karyawan) ──► Asset Log (request_karyawan)

Bergantung pada / dipakai oleh:
  - Onboarding: hasActiveOnboardingAsset & AssetAdmin_m::getOnboardingOptions (opsi karyawan/asset)
  - Summary Admin: countPendingForAdmin / getPendingForAdmin
  - Asset Saya: getPendingForEmployee (banner penambahan)
  - Offboarding: menelusuri sumber asset dari request `dikonfirmasi` dengan item normal (jenis "onboarding")
  - Retur/Offboarding mengembalikan asset ke gudang → asset bisa ditambahkan lagi (RISK-002 diperbaiki v1.1)
  - SQL manual sql-pengajuan-karyawan-jenis-asset-bebas.sql (kolom header nullable) harus dijalankan sebelum API v1.4 dipakai

43Source Code Reference

44Developer Notes

• Satu tabel dua alur: selalu filter sumber_pengajuan. getDetail(..., sumber = null) sengaja dipakai konfirmasi karyawan agar kedua sumber bisa dibuka.
• Tahap pengajuan tanpa kolom tahap: dibedakan oleh status_approval, tgl_approval (NULL = belum disetujui), dan jumlah item (ada item + belum disetujui = Draft Alokasi).
• Label dihitung di tiga fungsi berbeda (requestStatusMetadata, pengajuanAdminStatusMetadata, pengajuanStatusMetadata) dan dipetakan ulang di mobile — ubah bersamaan.
• Karyawan tidak melihat alokasi sebelum disetujui: mapPengajuanKaryawanRecords & getDetailPengajuanKaryawan mengosongkan jadwal/item.
• Opsi asset memakai fungsi onboarding (AssetAdmin_m::getOnboardingOptions dengan excludeEmployeesWithOnboarding: false).
• Jenis asset Pengajuan = teks bebas (v1.4): nama_kategori menyimpan teks; id_asset_kategori_m dan urgensi NULL (baris lama tetap berisi kategori/urgensi). Jangan memfilter alokasi dengan id_asset_kategori_m header.
• Sisa urgensi di kode: store() Penambahan admin masih menulis urgensi = '' (kolom nullable) dan mobile AssetRequestKaryawanRequest masih mengirim ''; dibiarkan agar kontrak Penambahan tidak berubah.
• Reservasi hanya saat kirim; draft tidak mengunci asset (beda dengan onboarding).
• Jam dikirim H:i, disimpan H:i:s; tanggal kosong disimpan 0000-00-00 dan diabaikan mobile lewat hasSchedule.
• asset_trx_log.jenis_log = request_karyawan — dipakai Offboarding untuk menelusuri asal asset.
• Technical debt: RISK-001/003 (RISK-002 sudah diperbaiki), enum ganda, parent_id/diganti tidak terpakai.

45End-to-End Traceability

45.1 Pengajuan → jenis asset

Karyawan mengetik "Laptop" di field Jenis Asset
  → _categoryController.text.trim()
  → AssetPengajuanKaryawanRequest.jenisAsset
  → JSON "jenis_asset"
  → AssetKaryawanPengajuan_c::storePengajuanSaya (trim, required saat kirim, max:150)
  → AssetRequestKaryawan_m::storePengajuanKaryawan
  → asset_trx_request_karyawan.nama_kategori = "Laptop" (id_asset_kategori_m = NULL, urgensi = NULL)
  → (admin) getPengajuanAdminOptions: seluruh stok tersedia, tanpa filter kategori

45.2 Alokasi → asset diterima karyawan

Admin memilih asset di Setujui Pengajuan Asset
  → _selectedAssets[].idAssetData → AssetPengajuanAdminAlokasiRequest.assetIds
  → JSON "asset_ids"
  → alokasikanPengajuanAdmin: tersedia @gudang (tanpa filter kategori)
  → INSERT asset_trx_request_karyawan_item (belum_dicek)
  → UPDATE asset_data.status_asset = proses
Karyawan memilih Normal → statusByItem → JSON items[].status_item
  → konfirmasiKaryawan: semua normal
  → UPDATE asset_data: terpakai, pemegang_asset = karyawan, id_pemegang_asset = id_karyawan
  → INSERT asset_trx_log (request_karyawan)
  → asset tampil di Asset Saya

45.3 DB → UI

asset_trx_request_karyawan.ket_tolak
  → getDetail → API "ket_tolak"
  → AssetRequestKaryawanRecord.ketTolak
  → UI "Alasan Penolakan" (detail admin & karyawan)

45.4 Walkthrough Lengkap dengan Contoh Data

Bagian ini mengikuti dua transaksi dari awal sampai selesai, langkah demi langkah: apa yang dilakukan pengguna di mobile, apa yang dikirim, apa yang diproses API, dan apa yang tersimpan di database. Data bersifat sintetis, tetapi format ID, nama kolom, urutan proses, label status, dan pesan diambil dari kode (AssetRequestKaryawan_m, AssetAdminPenambahan_c, AssetAdminPengajuan_c, AssetKaryawanPengajuan_c, AssetKaryawanPenambahan_c, AssetNotification).

Dua jalur memakai tabel yang sama (asset_trx_request_karyawan + _item); pembedanya sumber_pengajuan.

Data awal

Company CMP001. Tanggal kejadian 22 Oktober 2026, periode ID 202610. Belum ada transaksi request, log, atau notifikasi pada periode ini.

data_karyawan

KRY0099 dan KRY0100 terdaftar di asset_admin.

asset_data (semua status_asset = tersedia, pemegang_asset = gudang, id_pemegang_asset = '', kondisi_awal = normal)

Penomoran ID bersama untuk kedua jalur: header id_company + YYYYMM + 3 digit, item id_company + YYYYMM + 3 digit, no_trx = KRY-03-1-YYYYMMNNN, log dan notifikasi 5 digit.

Skenario A — Penambahan oleh Admin

Langkah A0 — Admin membuka form dan memuat opsi

Mobile: route /asset_admin_add_penambahan_karyawan → LoadAssetRequestKaryawanOptions → AssetRequestKaryawanApi.getOptions().

Dikirim

GET /asset/penambahan-karyawan/options
Authorization: Bearer <access_token_admin>

Diproses API: jwt.api + jwt.ctx → accessError() (harus admin asset) → AssetRequestKaryawan_m::getOptions → AssetAdmin_m::getOnboardingOptions(excludeEmployeesWithOnboarding: false). Berbeda dari Onboarding, semua karyawan aktif muncul (termasuk yang sudah pernah di-onboarding). Asset yang tampil: tersedia + gudang.

Database: hanya SELECT.

Diterima mobile: karyawan[], kategori_asset[] (pohon), assets[] (A5, A6, A7) seperti API-001. Dipakai untuk bottom sheet Pilih Karyawan dan pohon Tambah Asset.

Langkah A1 — Admin menyimpan draft (1 asset)

Mobile: admin memilih Sari Contoh, menambah Laptop 14 inch, mengisi jadwal 29 Okt 2026 pukul 09:00 dan catatan, lalu Simpan Draft → AssetRequestKaryawanApi.store(AssetRequestKaryawanRequest) dengan isDraft: true.

Dikirim

POST /asset/penambahan-karyawan

{
  "id_karyawan": "KRY0002",
  "asset_ids": ["CMP00120260100005"],
  "tgl_serah_terima": "2026-10-29",
  "jam_serah_terima": "09:00",
  "keterangan_serah_terima": "Ambil di ruang IT",
  "keterangan": "",
  "urgensi": "",
  "is_draft": true
}

(urgensi legacy, mobile masih mengirim ''.)

Diproses API (AssetAdminPenambahan_c::savePenambahanKaryawan → AssetRequestKaryawan_m::store, satu DB::transaction) 1. Validasi request, lalu accessError(). 2. lockCompany("CMP001"). 3. requestLockedAssets: A5 harus tersedia + gudang (FOR UPDATE); jumlah harus sama. 4. hasActiveOnboardingAsset dan hasActiveRequestAsset (hanya header proses yang mengunci): lolos. 5. findActiveKaryawan("KRY0002") dan findAssetAdmin("KRY0099") → user_input = "ADM-001 - Siti Admin". 6. Karena is_draft = true, jadwal boleh kosong (di sini terisi). 7. Generate ID header: urutan 1 → CMP001202610001, no_trx = KRY-03-1-202610001. 8. Kategori: semua asset satu kategori → id_asset_kategori_m = CMP001202601002, nama_kategori = Laptop. 9. INSERT header (draft), INSERT item. 10. Draft tidak mengunci asset dan tidak mengirim notifikasi.

Hasil database

asset_trx_request_karyawan

asset_trx_request_karyawan_item

asset_data: tidak berubah (A5 tetap tersedia).

Diterima mobile (HTTP 201)

{
  "code": "CREATED",
  "message": "Draft penambahan asset berhasil disimpan.",
  "data": { "id": "CMP001202610001", "no_trx": "KRY-03-1-202610001",
            "status_approval": "draft", "status_label": "Draft", "tab": "pending" }
}

Langkah A2 — Admin menambah mouse lalu publish

Mobile: admin membuka draft (kartu tab Pending), menambah Mouse Wireless, menekan Submit ke Karyawan → AssetRequestKaryawanApi.update(id, request).

Dikirim

PUT /asset/penambahan-karyawan/CMP001202610001

{
  "id_karyawan": "KRY0002",
  "asset_ids": ["CMP00120260100005", "CMP00120260100006"],
  "tgl_serah_terima": "2026-10-29",
  "jam_serah_terima": "09:00",
  "keterangan_serah_terima": "Ambil di ruang IT",
  "keterangan": "",
  "urgensi": "",
  "is_draft": false
}

Diproses API (store(data, id) dengan $idRequest terisi) 1. Header dicari dengan sumber_pengajuan = admin, FOR UPDATE; harus draft, selain itu 422 "Hanya draft penambahan langsung yang dapat diperbarui." 2. Validasi asset (A5 dan A6 tersedia + gudang, tidak aktif di onboarding/penambahan lain), karyawan, admin. Jadwal wajib karena is_draft = false. 3. ID header dan no_trx dipertahankan; tgl_pengajuan dan tgl_input juga dipertahankan. 4. Kategori: dua kategori berbeda (Laptop dan Aksesoris) → id_asset_kategori_m = '', nama_kategori = 'Multi Kategori'. 5. UPDATE header → proses; nextSequence item dihitung sebelum item lama dihapus (terakhir …001 → mulai 2), lalu DELETE item lama dan INSERT item baru. 6. Karena bukan draft: UPDATE asset_data A5 dan A6 → proses. 7. Controller memanggil AssetNotification::send('penambahan.dikirim', …) setelah commit.

Hasil database

Header (kolom yang berubah)

Item: baris …001 dihapus dan diganti (ID lama tidak dipakai ulang):

asset_data: A5 dan A6 status_asset tersedia → proses (tgl_update 09:10:00, user_update ADM-001 - Siti Admin).

notif_data (1 baris)

Diterima mobile (HTTP 200)

{
  "code": "UPDATED",
  "message": "Penambahan asset berhasil dikirim ke karyawan.",
  "data": { "id": "CMP001202610001", "no_trx": "KRY-03-1-202610001",
            "status_approval": "proses", "status_label": "Menunggu Diterima", "tab": "pending" }
}

Langkah A3 — Sari mengonfirmasi: semua Normal

Mobile - Push membuka /asset_konfirmasi_penambahan → LoadAssetKonfirmasiPenambahan(id) → GET /asset/karyawan/penambahan/CMP001202610001 (API-014). Detail berisi 2 item belum_dicek, perlu_dicek: true, jadwal serah terima, dan karyawan (nik, nama, jabatan, cabang, divisi). - Sari memilih Normal pada keduanya, Konfirmasi Asset → SubmitAssetKonfirmasiPenambahan → AssetSayaApi.konfirmasiPenambahan.

Dikirim

POST /asset/karyawan/penambahan/CMP001202610001/konfirmasi

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

ket_rusak hanya ikut dikirim untuk item rusak.

Diproses API (AssetKaryawanPenambahan_c::konfirmasiPenambahanSaya → AssetRequestKaryawan_m::konfirmasiKaryawan) 1. Validasi items (id unik, status_item ∈ normal/rusak, ket_rusak wajib bila rusak). 2. lockCompany; header diambil dengan id_karyawan = KRY0002 + FOR UPDATE; harus proses. Untuk Pengajuan, tgl_approval wajib terisi (jalur ini admin, jadi tidak diperiksa). 3. Karyawan harus aktif. Item dikunci; item pending = belum_dicek = …002 dan …003; jumlah dan ID yang dikirim harus sama persis. 4. UPDATE item: status_item = normal, ket_rusak = ''. 5. semuaNormal dihitung atas seluruh item → true → status dikonfirmasi. 6. UPDATE header: status_approval, user_approval, tgl_approval = now, tgl_update, user_update. 7. Karena semua normal: asset dikunci, UPDATE asset_data → terpakai, karyawan, id_pemegang_asset = KRY0002, id_asset_lokasi_m = NULL; INSERT asset_trx_log satu baris per asset. 8. Controller memanggil AssetNotification::send('penambahan.dikonfirmasi', …) ke seluruh admin.

Hasil database

asset_trx_log (2 baris, urutan sesuai id_asset_data pada transaksi)

notif_data (2 baris, satu per admin)

Rute admin dipilih dari sumber_pengajuan header (admin → detail penambahan, karyawan → detail pengajuan).

Diterima mobile (HTTP 200)

{
  "code": "UPDATED",
  "message": "Penambahan asset berhasil dikonfirmasi.",
  "data": { "id": "CMP001202610001", "no_trx": "KRY-03-1-202610001",
            "status_approval": "dikonfirmasi", "status_label": "Selesai", "tab": "selesai" }
}

Laptop dan mouse kini muncul di Asset Saya Sari.

Variasi A — ada asset rusak (all-or-nothing)

Bila pada langkah A3 laptop dinilai Rusak ("Ada garis pada layar") dan mouse Normal:

{ "items": [
  { "id_item": "CMP001202610002", "status_item": "rusak", "ket_rusak": "Ada garis pada layar" },
  { "id_item": "CMP001202610003", "status_item": "normal" } ] }

Respons: message "Laporan kerusakan penambahan asset berhasil dikirim.", status_label = "Isu Rusak", tab = "dikonfirmasi". Tidak ada endpoint lanjutan, sehingga kedua asset tertahan di proses (RISK-001). Ini berbeda dari Onboarding yang menyerahkan item Normal per item dan menyediakan penggantian.

Skenario B — Pengajuan oleh Karyawan

Langkah B1 — Dewi menyimpan draft pengajuan

Mobile: Asset Saya → Pengajuan → (+) → route /asset_tambah_pengajuan. Dewi mengetik Jenis Asset (teks bebas, maks 150) dan Alasan, lalu Simpan Draft → AssetPengajuanKaryawanApi.store(AssetPengajuanKaryawanRequest).

Dikirim

POST /asset/karyawan/pengajuan
Authorization: Bearer <access_token_dewi>

{ "jenis_asset": "Monitor 24 inch", "keterangan": "Monitor lama bergaris dan sering mati", "is_draft": true }

Diproses API (AssetKaryawanPengajuan_c::storePengajuanSaya → AssetRequestKaryawan_m::storePengajuanKaryawan) 1. Validasi: jenis_asset (string, maks 150) dan keterangan wajib hanya bila bukan draft; is_draft boolean. Field id_asset_kategori_m dan urgensi dari klien lama diabaikan. 2. lockCompany; findActiveKaryawan("KRY0003") (tanpa cek admin: pengguna biasa). 3. Generate ID: nextSequence header → urutan 2 (urutan 1 dipakai skenario A) → CMP001202610002, no_trx = KRY-03-1-202610002. 4. INSERT header saja (tanpa item); nama_kategori = teks jenis asset; id_asset_kategori_m dan urgensi = NULL (butuh SQL v1.4 agar kolom nullable). 5. Draft: tidak ada notifikasi.

Hasil database — asset_trx_request_karyawan (satu baris baru)

asset_trx_request_karyawan_item dan asset_data: tidak berubah.

Diterima mobile (HTTP 201)

{ "code": "CREATED", "message": "Draft pengajuan asset berhasil disimpan.",
  "data": { "id": "CMP001202610002", "no_trx": "KRY-03-1-202610002",
            "status_approval": "draft", "status_label": "Draft", "tab": "pengajuan" } }

Langkah B2 — Dewi mengirim pengajuan ke admin

Mobile: kartu draft di tab Pengajuan → LoadAssetPengajuanKaryawanDraft(id) mengisi form → Submit ke Admin → AssetPengajuanKaryawanApi.update(id, request).

Dikirim

PUT /asset/karyawan/pengajuan/CMP001202610002

{ "jenis_asset": "Monitor 24 inch", "keterangan": "Monitor lama bergaris dan sering mati", "is_draft": false }

Diproses API (updatePengajuanKaryawan) 1. Header dicari dengan id_karyawan = KRY0003 dan sumber_pengajuan = karyawan (bukan milik pemanggil → 404 "Pengajuan asset tidak ditemukan."). 2. Syarat draft: status_approval = draft, tgl_approval NULL, user_approval kosong, belum punya item; selain itu 422 "Pengajuan asset sudah tidak dapat diubah karena bukan draft." 3. Saat kirim, jenis_asset dan keterangan wajib. 4. UPDATE header: keterangan, urgensi = NULL, status_approval = proses, tgl_update, user_update, tgl_pengajuan = hari ini; nama_kategori ditimpa bila key jenis_asset dikirim. 5. Controller memanggil AssetNotification::send('pengajuan.diajukan', …) ke seluruh admin.

Hasil database

Diterima mobile (HTTP 200)

{ "code": "UPDATED", "message": "Pengajuan asset berhasil dikirim ke admin.",
  "data": { "id": "CMP001202610002", "no_trx": "KRY-03-1-202610002",
            "status_approval": "proses", "status_label": "Menunggu Konfirmasi", "tab": "pengajuan" } }

Dari sudut pandang admin, label transaksi ini "Menunggu Diterima", tab pengajuan (belum disetujui, tanpa item).

Langkah B3 — Admin meninjau pengajuan

Mobile: notifikasi membuka /asset_admin_detail_pengajuan_karyawan → LoadAssetPengajuanAdminDetail(id) → GET /asset/pengajuan-karyawan/CMP001202610002. Daftar (GET /asset/pengajuan-karyawan?tab=pengajuan) menampilkan transaksi proses yang belum disetujui; draft karyawan tidak pernah tampil di sisi admin.

Diproses API: getDetailPengajuanAdmin, hanya SELECT. Jenis asset dibaca dari nama_kategori dan dikirim sebagai nama_kategori serta nama_asset; id_asset_kategori_m = ''.

Tombol Tolak dan Setujui tampil karena status proses dan tab pengajuan.

Langkah B4 — Admin menyimpan draft alokasi

Mobile: Setujui → route /asset_admin_setujui_pengajuan_karyawan → LoadAssetPengajuanAdminOptions(id) → GET /asset/pengajuan-karyawan/CMP001202610002/options (seluruh stok gudang, tanpa filter kategori; hanya bila pengajuan proses dan belum disetujui, selain itu 404). Admin memilih Monitor 24 inch (A7), mengisi jadwal, lalu Simpan Draft → AssetPengajuanAdminApi.allocate.

Dikirim

POST /asset/pengajuan-karyawan/CMP001202610002/alokasi

{ "asset_ids": ["CMP00120260100007"], "tgl_serah_terima": "2026-10-30", "jam_serah_terima": "10:00",
  "keterangan_serah_terima": "Serah terima di ruang IT lantai 2", "is_draft": true }

Diproses API (alokasikanPengajuanAdmin) 1. Validasi dan cek admin; lockCompany. 2. Header (sumber karyawan, FOR UPDATE) harus proses dan tgl_approval NULL; selain itu 422 "Pengajuan asset sudah tidak dapat dialokasikan." 3. A7 harus tersedia + gudang; tidak aktif di onboarding atau penambahan lain (transaksi ini dikecualikan). Jenis asset yang diajukan tidak dibandingkan dengan kategori A7. 4. Jadwal boleh kosong untuk draft. 5. nextSequence item → 4; DELETE item lama (tidak ada), INSERT item. 6. UPDATE header: jadwal, ket_tolak = '', user_approval = '', tgl_approval = NULL (draft), tgl_update, user_update. 7. Draft: asset_data tidak diubah, tidak ada notifikasi.

Hasil database

Diterima mobile (HTTP 200)

{ "code": "UPDATED", "message": "Draft alokasi pengajuan asset berhasil disimpan.",
  "data": { "id": "CMP001202610002", "no_trx": "KRY-03-1-202610002", "status_approval": "proses",
            "status_label": "Draft Alokasi", "tab": "pengajuan", "jumlah_asset": 1 } }

Dewi belum melihat jadwal atau asset: untuk karyawan, sebelum disetujui items = [], jadwal kosong, jumlah_asset = 0.

Langkah B5 — Admin mengirim alokasi (Submit ke PIC)

Dikirim

POST /asset/pengajuan-karyawan/CMP001202610002/alokasi

{ "asset_ids": ["CMP00120260100007"], "tgl_serah_terima": "2026-10-30", "jam_serah_terima": "10:00",
  "keterangan_serah_terima": "Serah terima di ruang IT lantai 2", "is_draft": false }

Diproses API: sama dengan B4, dengan perbedaan: - jadwal wajib (kosong → 422 "Tanggal serah terima wajib diisi." / "Jam serah terima wajib diisi."); - nextSequence item → terakhir …004 → 5, item lama …004 dihapus lalu diganti …005; - header: user_approval = ADM-001 - Siti Admin, tgl_approval = now (pengajuan dianggap disetujui); - UPDATE asset_data A7 → proses; - AssetNotification::send('pengajuan.disetujui', …).

Hasil database

Diterima mobile (HTTP 200, code SUCCESS karena bukan draft)

{ "code": "SUCCESS", "message": "Pengajuan asset berhasil disetujui.",
  "data": { "id": "CMP001202610002", "no_trx": "KRY-03-1-202610002", "status_approval": "proses",
            "status_label": "Menunggu Konfirmasi", "tab": "proses", "jumlah_asset": 1 } }

Langkah B6 — Dewi mengonfirmasi asset

Mobile: push membuka /asset_konfirmasi_pengajuan (isPengajuan: true) → LoadAssetKonfirmasiPenambahan(id) → GET /asset/karyawan/penambahan/CMP001202610002. Sekarang item, jadwal, jenis asset, dan alasan tampil. Dewi memilih Normal → Konfirmasi Asset.

Dikirim

POST /asset/karyawan/penambahan/CMP001202610002/konfirmasi

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

Endpoint konfirmasi sama untuk kedua jalur.

Diproses API: konfirmasiKaryawan seperti langkah A3, ditambah syarat Pengajuan: tgl_approval harus terisi, jika tidak 422 "Pengajuan asset belum disubmit oleh admin."

Hasil database

Diterima mobile (HTTP 200): status_approval: "dikonfirmasi", status_label: "Selesai", tab: "selesai".

Karena tgl_approval dan user_approval ditimpa, pelaku dan waktu persetujuan admin tidak tersimpan setelah konfirmasi; hanya tgl_update pada langkah-langkah sebelumnya yang pernah memuat jejaknya.

Variasi B — admin menolak pengajuan

Pada langkah B3, admin menekan Tolak dan mengisi alasan.

POST /asset/pengajuan-karyawan/CMP001202610002/tolak

{ "ket_tolak": "Stok monitor belum tersedia bulan ini" }

Diproses API (tolakPengajuanAdmin): header harus proses dan belum disetujui; alasan wajib (maks 255); DELETE seluruh item (draft alokasi bila ada); UPDATE header.

Respons: code UPDATED, "Pengajuan asset berhasil ditolak.", status_label = "Ditolak", tab = "selesai" (di sisi karyawan tab ditolak). Status ditolak bersifat final.

Kondisi akhir data

asset_trx_request_karyawan

asset_trx_request_karyawan_item

ID item …001 dan …004 pernah ada dan sudah dihapus; nomornya tidak dipakai ulang (menggerus kapasitas 999/bulan, RISK-004).

asset_data: A5, A6 → terpakai/karyawan/KRY0002; A7 → terpakai/karyawan/KRY0003. asset_trx_log: 3 baris. notif_data: 8 baris (1 penambahan dikirim, 2 dikonfirmasi, 2 pengajuan diajukan, 1 disetujui, 2 dikonfirmasi).

Kasus gagal yang umum

Semua pelanggaran aturan dilempar sebagai InvalidArgumentException di dalam DB::transaction, sehingga seluruh perubahan request itu dibatalkan. Pesan tersedia dalam bahasa Indonesia dan Inggris mengikuti header locale (respons en memakai teks Inggris, mis. "Asset addition confirmed successfully.").

Ringkasan siapa mengerjakan apa

46Ringkasan Database Impact

47Checklist Implementasi

Database

• Header & item
• Kolom sumber_pengajuan + index list
• Status enum
• Log serah terima
• Migration CREATE TABLE baseline
• Unique no_trx per company
• Kolom tanggal nullable
• SQL manual sql-pengajuan-karyawan-jenis-asset-bebas.sql + DBML: id_asset_kategori_m dan urgensi nullable (v1.4) disiapkan

Backend

• Route, controller, validasi, transaksi, notifikasi
• Tolak & alokasi (termasuk draft alokasi)
• Konfirmasi karyawan
• Edit / kirim draft (PUT); hapus draft belum ada
• Tindak lanjut asset rusak
• Perbaikan hasActiveRequestAsset (v1.1)
• Pengajuan: jenis_asset teks bebas, urgensi dihapus, alokasi lintas kategori (v1.4; 99 tes API lulus)
• Validasi tanggal serah terima ≥ hari ini

Mobile

• List, form, detail Penambahan (admin)
• List, detail, tolak, setujui Pengajuan (admin)
• List, form, detail Pengajuan (karyawan)
• Konfirmasi Penambahan/Pengajuan
• Lanjutkan (ubah) draft
• Form Jenis Asset teks bebas tanpa Urgensi; Bloc tanpa options (v1.4)
• Data Karyawan menampilkan Jabatan, Cabang, Departemen
• Tombol pil (Tambah Asset, Simpan Draft, Submit ke PIC, Tolak, Setujui); nilai awal jadwal/jam layar Setujui kosong (38 tes mobile lulus)
• Tampilkan kondisi item di detail admin
• Semua banner penambahan di Asset Saya

Rilis / Deploy v1.4

• Jalankan sql-pengajuan-karyawan-jenis-asset-bebas.sql di database SEBELUM deploy API v1.4 (langkah user; belum dijalankan; cek charset nama_kategori lebih dulu)
• Deploy API v1.4
• Rilis aplikasi mobile v1.4 (klien lama tanpa jenis_asset ditolak 422)

Documentation

• Business Flow, DB, API, Mobile, Mapping, Manual Book, Testing
• Screenshot

48Changelog