Off Boarding Asset Karyawan

01Informasi Dokumen

03Quick Overview

Admin: Pilih Karyawan + Jadwal Penyerahan (tanggal, jam) + Catatan
   ├─ Simpan Draft ─────────────────────────────────────────── draft (item sudah dibuat, asset "terkunci")
   └─ Submit ke Karyawan                                       pengajuan
        • item = SEMUA asset yang dipegang karyawan (tetap + pinjaman)
        • asset pinjaman → dibuatkan transaksi pengembalian KRY05 (child) otomatis
      │
      ▼  (Admin dapat Ubah Jadwal → kembali ke pengajuan)
Karyawan: isi kondisi tiap asset Normal / Rusak (+ keterangan) → Konfirmasi Off Boarding
                                                               dikonfirmasi (child pengembalian → dikonfirmasi)
      │
      ▼
Admin: Terima Penyerahan Asset                                 selesai
   asset → gudang pilihan admin PER ASSET (tersedia / rusak) + asset_trx_log
   child pengembalian → selesai, peminjaman asal → selesai bila semua asset kembali

04Ringkasan Fitur

Off Boarding dipakai Admin Asset untuk menarik seluruh asset yang sedang dipegang seorang karyawan — misalnya saat karyawan berhenti bekerja. Berbeda dengan Retur (dipilih per asset oleh karyawan), Off Boarding:

• Dimulai admin dan otomatis mencakup semua asset yang pemegang_asset = karyawan milik orang tersebut, termasuk asset pinjaman.
• Dapat disimpan sebagai Draft (jadwal opsional) sebelum dikirim ke karyawan.
• Untuk asset pinjaman, sistem membuat transaksi pengembalian pinjaman (KRY05) sebagai child yang ikut bergerak bersama status off boarding, sehingga modul Peminjaman tetap konsisten.
• Karyawan yang menilai kondisi tiap asset (Normal/Rusak + keterangan); admin menutup transaksi dengan menerima asset secara fisik.

⚠️ Belum ditemukan: keterkaitan dengan proses HR (misalnya perubahan status karyawan menjadi resign). Off Boarding tidak mengubah data_karyawan.

05Tujuan Fitur

5.1 Tujuan Bisnis (diturunkan dari kode)

• Memastikan tidak ada asset perusahaan yang tertinggal pada karyawan yang keluar.
• Mendokumentasikan kondisi setiap asset saat diserahkan.
• Menjadwalkan waktu penyerahan yang disepakati.
• Menutup peminjaman aktif karyawan secara otomatis.

5.2 Tujuan Sistem

• Membuat snapshot seluruh asset yang dipegang karyawan beserta sumber transaksinya (onboarding/request/retur/peminjaman).
• Mencegah asset diproses di flow lain selama off boarding aktif.
• Memindahkan asset ke gudang dan mencatat asset_trx_log.
• Menjaga konsistensi dengan modul Peminjaman melalui transaksi child.

06Aktor

07Hak Akses

08Terminologi

09Business Rules

BR-001 — Hanya admin yang membuat & menerima

Semua aksi admin memanggil requireAdmin → "Pengguna tidak terdaftar sebagai admin asset."

BR-002 — Karyawan harus aktif dan memegang asset

Saat simpan/submit: "Karyawan tidak ditemukan atau tidak aktif." / "Karyawan tidak memiliki asset yang sedang dipegang." Opsi karyawan hanya menampilkan karyawan aktif yang memegang ≥1 asset dan belum punya off boarding aktif.

BR-003 — Satu off boarding aktif per karyawan

Status aktif = draft, pengajuan, dikonfirmasi → "Karyawan masih memiliki offboarding aktif."

BR-004 — Item = seluruh asset yang dipegang

employeeAssets: semua asset_data dengan pemegang_asset = karyawan dan id_pemegang_asset = id_karyawan (tanpa filter status_asset). Admin tidak memilih asset.

BR-005 — Asset tidak boleh sedang diproses flow lain (assertNoCrossFlow)

Ditolak bila ada asset yang: - berada di retur aktif (status_transaksi = proses dan status_approval != ditolak), atau - berada di pengembalian pinjaman berstatus pengajuan/dikonfirmasi.

→ "Satu atau beberapa asset sedang diproses pada flow lain."

Selain itu (sejak v1.1) ditolak bila ada asset yang: - berada di upgrade aktif (hasActiveUpgradeAsset) → "Satu atau beberapa asset sedang diproses pada upgrade." - berada di laporan kerusakan aktif (hasActiveRusakAsset) → "Satu atau beberapa asset sedang diproses pada laporan kerusakan." - berada di pemeliharaan terjadwal aktif PML01 (hasActivePemeliharaanAsset, fase ≠ selesai) → "Satu atau beberapa asset sedang diproses pada pemeliharaan."

Karena employeeAssets tidak memfilter status, asset dalam_perbaikan (sedang di teknisi lewat Upgrade atau PML01 mekanisme diserahkan) ikut tercek.

BR-006 — Setiap asset harus punya sumber transaksi

sourceForAsset mencari berurutan: peminjaman aktif (bila dipinjam) → asset_trx_log terakhir ke karyawan → request/penambahan dikonfirmasi → onboarding dikonfirmasi → peminjaman aktif → fallback asset_data (data legacy). Pesan bila gagal: "Asset {nama} tidak memiliki sumber transaksi yang valid." (⚠️ praktis tidak terjadi karena ada fallback).

BR-007 — Jadwal wajib saat submit, opsional saat draft

Controller: tgl_offboarding (Y-m-d) & jam_offboarding (H:i) required bila is_draft = false. Model: "Jadwal offboarding wajib diisi saat pengajuan." Backend tidak memvalidasi tanggal ≥ hari ini (mobile membatasi mulai hari ini).

BR-008 — Draft hanya bisa diubah/dihapus saat berstatus draft

→ "Hanya offboarding berstatus draft yang dapat diubah." / "…dapat dihapus." Saat diubah, seluruh item dibangun ulang dari asset yang dipegang saat itu.

BR-009 — Asset pinjaman menjadi transaksi child

Saat submit (bukan draft), per peminjaman sumber dibuat header pengembalian KRY05 (jenis_status = pengembalian, status = pengajuan, keterangan_serah_terima = "Dibuat otomatis dari offboarding {id}") + item + baris asset_trx_offboarding_relasi. Pengembalian child disembunyikan dari list/pending admin Peminjaman dan tidak dapat dikonfirmasi lewat modul Peminjaman ("Pengembalian ini diproses melalui offboarding.").

BR-010 — Ubah jadwal mengembalikan status ke pengajuan

Status pengajuan/dikonfirmasi → update jadwal, status → pengajuan, approval dikosongkan, child direset ke pengajuan dan kondisi item → belum_dicek (lihat INC-04). Status lain → "Jadwal offboarding sudah tidak dapat diubah."

BR-011 — Konfirmasi karyawan

• Header harus milik karyawan dan berstatus pengajuan → "Offboarding tidak menunggu konfirmasi."
• Daftar asset yang dipegang saat ini harus sama persis dengan item → "Daftar asset yang dipegang karyawan sudah berubah."
• Semua item wajib diisi → "Seluruh kondisi asset offboarding wajib diisi."
• Kondisi normal/rusak; rusak wajib keterangan → "Keterangan kerusakan asset wajib diisi."
• Child pengembalian: item normal → disetujui, rusak → ditolak (+ket_tolak = keterangan rusak); header child → dikonfirmasi.
• Header → dikonfirmasi, user_approval/tgl_approval = karyawan.

BR-012 — Penerimaan admin

• Status harus dikonfirmasi → "Offboarding belum dikonfirmasi karyawan."
• Daftar asset dipegang harus tetap sama; semua item normal/rusak → "Kondisi asset belum dikonfirmasi karyawan."
• Asset tetap: rusak → status_asset = rusak + ket_rusak; normal → tersedia; pemegang = gudang; log offboarding_karyawan.
• Asset pinjaman: diproses via child → asset ke gudang (tersedia/rusak), log pengembalian_karyawan, child → selesai.
• Lokasi gudang tujuan dipilih admin per asset (v1.2): items[] pada request wajib memuat setiap item tepat satu kali dengan id_asset_lokasi_m bertipe gudang pada company yang sama → "Lokasi gudang tujuan setiap asset wajib dipilih." / "Lokasi gudang tujuan tidak valid." Lokasi ditulis ke asset_data.id_asset_lokasi_m dan asset_trx_offboarding_karyawan_item.id_asset_lokasi_m_tujuan; asset pinjaman memakai pemetaan yang sama lewat child.
• Peminjaman sumber → selesai bila tidak ada lagi asset yang dipegang karyawan.
• Header → selesai.

BR-013 — Off boarding aktif mengunci asset di modul lain

hasActiveOffboardingAsset (status draft/pengajuan/dikonfirmasi) dipakai oleh: Retur (ajukan), Peminjaman (ajukan pengembalian), Kerusakan, Upgrade → "…sedang diproses pada offboarding." Draft pun mengunci (RISK-005).

BR-014 — Penomoran

Header/item/relasi: id_company + YYYYMM + 3 digit; no_trx = KRY02-YYYYMMNNN (unique per company). Child pengembalian memakai penomoran KRY05. Log: 5 digit.

10Business Flow

1. Admin: Asset Karyawan → Off Boarding → (+) Tambah Off Boarding Asset
   → Pilih Karyawan → Jadwal Serah Terima (Tanggal & Jam Penyerahan) → Catatan Tambahan
   → Simpan Draft                         [draft · tanpa notifikasi]
   → Submit ke Karyawan                   [pengajuan · child pengembalian pinjaman · notif karyawan]
2. (Opsional) Admin: Ubah Jadwal Penyerahan  [kembali ke pengajuan · notif karyawan]
3. Karyawan: banner Asset Saya / menu Off Board → Detail
   → isi kondisi tiap asset Normal / Rusak (+ Keterangan Kerusakan)
   → Konfirmasi Off Boarding               [dikonfirmasi · notif admin]
4. Serah terima fisik sesuai jadwal
5. Admin: Detail → Terima Penyerahan Asset  [selesai · asset ke gudang · asset_trx_log · notif karyawan]

11Flow Berdasarkan Role

11.1 Admin Asset

1. Halaman Asset Karyawan → aksi Off Boarding atau panel "Off Boarding Perlu Diproses" (berisi draft → tombol Lanjutkan Draft, dan yang sudah dikonfirmasi → tombol Terima Asset).
2. Tambah Off Boarding Asset → Simpan Draft atau Submit ke Karyawan.
3. Draft dapat dibuka lagi (edit) atau dihapus (Hapus Draft).
4. Detail: Ubah Jadwal Penyerahan (pengajuan/dikonfirmasi), Terima Penyerahan Asset (dikonfirmasi).

11.2 Karyawan

1. Asset Saya menampilkan banner Off Boarding Asset ("Periksa jadwal penyerahan dan konfirmasi setelah Anda siap menyerahkan seluruh asset.") atau menu Off Board.
2. Detail → pilih kondisi Normal/Rusak setiap asset → Konfirmasi Off Boarding.

11.3 Approver

Tidak ada approval terpisah; "konfirmasi" dilakukan karyawan, "penerimaan" oleh admin.

11.4 System

Deteksi asset & sumber, cek flow lain, buat/reset/konfirmasi/finalisasi child pengembalian, update asset & log, notifikasi.

12Flow Diagram

flowchart TD
    A[Admin pilih karyawan + jadwal] --> B{Simpan sebagai}
    B -->|Draft| C[draft, item dibuat, tanpa notif]
    C -->|Edit| B
    C -->|Hapus Draft| Z[Dihapus]
    B -->|Submit ke Karyawan| D{Validasi}
    D -->|Gagal| X[Pesan error]
    D -->|OK| E[pengajuan, notif karyawan]
    E --> F{Ada asset pinjaman?}
    F -->|Ya| G[Buat child pengembalian KRY05 status pengajuan]
    F -->|Tidak| H[Menunggu karyawan]
    G --> H
    H -->|Admin ubah jadwal| E
    H --> I[Karyawan isi Normal atau Rusak per asset]
    I --> J[dikonfirmasi, child dikonfirmasi, notif admin]
    J -->|Admin ubah jadwal| E
    J --> K[Admin: Terima Penyerahan Asset]
    K --> L[Asset tetap ke gudang, log offboarding_karyawan]
    K --> M[Asset pinjaman ke gudang via child, log pengembalian_karyawan]
    L --> N[selesai, notif karyawan]
    M --> N

13Sequence Diagram

sequenceDiagram
    actor A as Admin
    actor K as Karyawan
    participant M as Mobile
    participant CA as AssetAdminOffboarding_c
    participant CK as AssetKaryawanOffboarding_c
    participant O as AssetOffboardingKaryawan_m
    participant DB
    participant N as AssetNotification

    A->>M: Pilih karyawan, jadwal, Submit ke Karyawan
    M->>CA: POST /asset/offboarding-karyawan (is_draft false)
    CA->>O: store()
    O->>DB: lock company, cek admin, karyawan aktif, tidak ada offboarding aktif
    O->>DB: ambil semua asset dipegang karyawan (FOR UPDATE), cek retur dan pengembalian aktif
    O->>DB: INSERT header pengajuan + item (sumber transaksi)
    O->>DB: INSERT child pengembalian KRY05 + relasi (asset pinjaman)
    CA->>N: offboarding.diajukan (karyawan)
    K->>M: Isi kondisi, Konfirmasi Off Boarding
    M->>CK: POST /asset/karyawan/offboarding/{id}/konfirmasi
    CK->>O: confirm()
    O->>DB: cek daftar asset tidak berubah, UPDATE item kondisi
    O->>DB: UPDATE child item dan header dikonfirmasi, UPDATE header dikonfirmasi
    CK->>N: offboarding.dikonfirmasi (admin)
    A->>M: Terima Penyerahan Asset
    M->>CA: POST /asset/offboarding-karyawan/{id}/terima
    CA->>O: receive()
    O->>DB: UPDATE asset_data gudang tersedia atau rusak
    O->>DB: INSERT asset_trx_log, child selesai, peminjaman asal selesai
    O->>DB: UPDATE header selesai
    CA->>N: offboarding.diterima (karyawan)

14Status Transaksi

Enum PHP App\Models\Asset\OffboardingStatus (kolom status_approval, enum DB draft, pengajuan, dikonfirmasi, selesai).

Tidak ada status ditolak/dibatalkan (⚠️ Belum ditemukan).

Status item (status_item): belum_dicek → normal / rusak.

Status child pengembalian (tabel peminjaman): pengajuan → dikonfirmasi → selesai.

15State Transition

stateDiagram-v2
    [*] --> draft: Simpan Draft (Admin)
    [*] --> pengajuan: Submit ke Karyawan (Admin)
    draft --> draft: Edit draft (Admin)
    draft --> pengajuan: Submit draft (Admin)
    draft --> [*]: Hapus Draft (Admin)
    pengajuan --> pengajuan: Ubah jadwal (Admin)
    pengajuan --> dikonfirmasi: Konfirmasi kondisi (Karyawan)
    dikonfirmasi --> pengajuan: Ubah jadwal (Admin)
    dikonfirmasi --> selesai: Terima Penyerahan Asset (Admin)
    selesai --> [*]

Status asset_data: | Asset | Dari | Ke | Trigger | |---|---|---|---| | Asset tetap (terpakai @karyawan) | – | tidak berubah | Draft, submit, konfirmasi | | Asset tetap | @karyawan | tersedia / rusak @gudang | Terima | | Asset pinjaman (dipinjam @karyawan) | @karyawan | tersedia / rusak @gudang | Terima (via child) |

16Struktur Database

17Relasi Database

erDiagram
    ASSET_TRX_OFFBOARDING_KARYAWAN ||--o{ ASSET_TRX_OFFBOARDING_KARYAWAN_ITEM : "id_asset_trx_offboarding"
    ASSET_TRX_OFFBOARDING_KARYAWAN ||--o{ ASSET_TRX_OFFBOARDING_RELASI : "id_asset_trx_offboarding_karyawan"
    ASSET_TRX_OFFBOARDING_RELASI }o--|| ASSET_TRX_PEMINJAMAN_KARYAWAN : "id_tabel (child pengembalian)"
    ASSET_DATA ||--o{ ASSET_TRX_OFFBOARDING_KARYAWAN_ITEM : "id_asset_data"
    DATA_KARYAWAN ||--o{ ASSET_TRX_OFFBOARDING_KARYAWAN : "id_karyawan (logis)"
    ASSET_DATA ||--o{ ASSET_TRX_LOG : "id_asset_data"

    ASSET_TRX_OFFBOARDING_KARYAWAN {
        varchar id_asset_trx_offboarding_karyawan PK
        varchar no_trx
        date tgl_offboarding
        time jam_offboarding
        varchar id_karyawan
        enum status_approval
        varchar user_approval
    }
    ASSET_TRX_OFFBOARDING_KARYAWAN_ITEM {
        varchar id_asset_trx_offboarding_item PK
        varchar id_asset_trx_offboarding FK
        varchar id_asset_data FK
        varchar status_item
        varchar ket_rusak
        varchar jenis_transaksi
        varchar id_transaksi_sumber
        varchar tabel_transaksi_sumber
    }
    ASSET_TRX_OFFBOARDING_RELASI {
        varchar id_asset_trx_offboarding_relasi PK
        varchar id_asset_trx_offboarding_karyawan FK
        varchar id_tabel
        varchar nama_tabel
        varchar jenis_transaksi_sumber
    }
    ASSET_TRX_PEMINJAMAN_KARYAWAN {
        varchar id_asset_trx_peminjaman_karyawan PK
        enum jenis_status
        varchar id_peminjaman_asal
        enum status
    }
    ASSET_DATA {
        varchar id_asset_data PK
        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
    }

18Data Dictionary

18.1 asset_trx_offboarding_karyawan (migration)

18.2 asset_trx_offboarding_karyawan_item

18.3 asset_trx_offboarding_relasi

18.4 asset_trx_log

19Database Index

20Backend Architecture

RouteAsset.php (prefix /asset, jwt.api + jwt.ctx)
   ↓
AssetAdminOffboarding_c (validateOffboardingForm / validateRequest → accessError)
AssetKaryawanOffboarding_c (offboardingAccessError: karyawan aktif)
   ↓
AssetOffboardingKaryawan_m ← Asset_m (lockCompany, nextSequence, findActiveKaryawan, findAssetAdmin)
   ↓   ↔ tabel peminjaman (child pengembalian), retur (cek flow), onboarding/request/asset_trx_log (sumber)
DB::transaction (retry 3) → ApiResponse + AssetNotification

21Backend Business Logic

21.1 Simpan / Submit — store

Lock company → admin → karyawan aktif → tidak ada off boarding aktif → ambil semua asset dipegang (FOR UPDATE) → minimal 1 → assertNoCrossFlow → assertSchedule → ID + KRY02-… → INSERT header (draft/pengajuan) → insertItems (snapshot + sumber, status_item = belum_dicek) → bila submit: createLoanReturnChildren. Notifikasi offboarding.diajukan hanya bila submit.

21.2 Edit draft — updateDraft

Header harus draft (FOR UPDATE) → validasi sama seperti store (mengecualikan dirinya sendiri) → hapus child, item, relasi lama → insert item baru → update header (karyawan boleh diganti) → bila submit: buat child + notifikasi.

21.3 Hapus draft — deleteDraft

Header harus draft → hapus item, child, relasi, header. Response {id, no_trx}.

21.4 Ubah jadwal — schedule

Header pengajuan/dikonfirmasi → update jadwal, status pengajuan, kosongkan approval → resetLoanReturnChildren (child → pengajuan, item child & item off boarding → belum_dicek; hanya bila ada child) → notifikasi offboarding.dijadwalkan.

21.5 Konfirmasi karyawan — confirm

Karyawan aktif → header miliknya pengajuan → assertCurrentHoldings → semua item diisi → update item → confirmLoanReturnChildren → header dikonfirmasi (approval = karyawan) → notifikasi offboarding.dikonfirmasi.

21.6 Terima admin — receive

Admin → header dikonfirmasi → assertCurrentHoldings → semua item normal/rusak → resolveItemLocations (lokasi gudang per item, v1.2) → lock asset → per item non-pinjaman: update asset (gudang, id_asset_lokasi_m sesuai pilihan, tersedia/rusak, ket_rusak) + log offboarding_karyawan → finalizeLoanReturnChildren (validasi child dikonfirmasi, status item cocok, update asset + log pengembalian_karyawan, child selesai + tgl/jam_serah_terima = now) → insert log → header selesai → completeLoanSources (peminjaman asal aktif → selesai bila tak ada asset tersisa) → notifikasi offboarding.diterima.

21.7 Query baca

• Opsi: karyawan aktif yang memegang asset dan tanpa off boarding aktif.
• List: tab pengajuan (admin: draft + pengajuan; karyawan: pengajuan), dikonfirmasi, selesai; tanpa tab = semua. jumlah_asset = jumlah item. Key array: offboardings.
• Detail: header + cabang/departemen/jabatan + items (dengan jenis_transaksi & sumber). Karyawan tidak dapat membuka draft.
• Summary admin: offboarding_perlu_proses & offboarding_pending = status draft + dikonfirmasi.

22Dampak terhadap asset_data

23API Documentation

Terkait: GET /asset/summary (offboarding_perlu_proses, offboarding_pending).

24Detail Setiap API

Header umum: Authorization: Bearer <token>, Content-Type: application/json, Accept, locale, versi-app. Format { code, message, data }.

API-001 — Opsi

GET /asset/offboarding-karyawan/options

{ "code": "SUCCESS", "message": "Opsi offboarding asset berhasil ditemukan.",
  "data": {
    "karyawan": [ {"id_karyawan": "KRY0007", "nik": "EMP-007", "nama_karyawan": "Budi Contoh"} ],
    "lokasi_gudang": [ {"id_asset_lokasi_m": "CMP001202610001", "nama_lokasi": "Gudang Pusat", "id_cabang": "CAB-1"} ]
  } }

lokasi_gudang (v1.2): lokasi tipe = gudang milik company, diurutkan menurut nama; dipakai dropdown Lokasi Tujuan Asset saat Terima Penyerahan.

API-002 / API-009 — List

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

tab: pengajuan | dikonfirmasi | selesai ("Filter offboarding tidak valid."); limit 1–50 ("Limit maksimal adalah 50 data.").

{
  "code": "SUCCESS",
  "message": "Data offboarding asset berhasil ditemukan.",
  "data": {
    "offboardings": [
      {
        "id": "CMP001202609004",
        "no_trx": "KRY02-202609004",
        "tgl_offboarding": "2026-09-30",
        "jam_offboarding": "09:00:00",
        "id_karyawan": "KRY0007",
        "nik_karyawan": "EMP-007",
        "nama_karyawan": "Budi Contoh",
        "jumlah_asset": 3,
        "status": "pengajuan",
        "status_approval": "pengajuan",
        "status_label": "Menunggu Diterima",
        "tab": "pengajuan"
      }
    ],
    "filters": [
      {"value": "pengajuan", "label": "Pengajuan"},
      {"value": "dikonfirmasi", "label": "Dikonfirmasi"},
      {"value": "selesai", "label": "Selesai"}
    ],
    "pagination": {"limit": 20, "offset": 0, "next_offset": 1, "has_more": false}
  }
}

API-003 / API-005 — Simpan / Submit / Edit Draft

POST /asset/offboarding-karyawan
PUT  /asset/offboarding-karyawan/{id}

{
  "id_karyawan": "KRY0007",
  "tgl_offboarding": "2026-09-30",
  "jam_offboarding": "09:00",
  "keterangan": "Karyawan mengakhiri kontrak",
  "is_draft": false
}

Pesan umum validasi: "Data offboarding belum lengkap."

Database impact (submit):

INSERT/UPDATE asset_trx_offboarding_karyawan (draft/pengajuan)
INSERT asset_trx_offboarding_karyawan_item (semua asset dipegang)
INSERT asset_trx_peminjaman_karyawan + _item (child pengembalian, bila ada pinjaman)
INSERT asset_trx_offboarding_relasi
INSERT notif_data (submit saja)

Response 201/200 = detail (lihat API-004). Pesan: "Draft offboarding berhasil disimpan." / "Draft offboarding berhasil diperbarui." / "Offboarding asset berhasil diajukan." 422: "Pengguna tidak terdaftar sebagai admin asset.", "Karyawan tidak ditemukan atau tidak aktif.", "Karyawan masih memiliki offboarding aktif.", "Karyawan tidak memiliki asset yang sedang dipegang.", "Satu atau beberapa asset sedang diproses pada flow lain.", "Satu atau beberapa asset sedang diproses pada upgrade." / "…laporan kerusakan." / "…pemeliharaan.", "Jadwal offboarding wajib diisi saat pengajuan.", "Hanya offboarding berstatus draft yang dapat diubah.", "Transaksi peminjaman sumber asset tidak ditemukan." 500: "Terjadi kesalahan saat menyimpan offboarding asset." (POST; pesan exception tidak lagi dikirim ke klien sejak v1.3 — INC-01) / "Terjadi kesalahan saat memperbarui offboarding asset." (PUT).

API-004 / API-010 — Detail

GET /asset/offboarding-karyawan/{id}
GET /asset/karyawan/offboarding/{id}

{
  "id": "CMP001202609004",
  "no_trx": "KRY02-202609004",
  "tgl_offboarding": "2026-09-30",
  "jam_offboarding": "09:00:00",
  "keterangan": "Karyawan mengakhiri kontrak",
  "id_karyawan": "KRY0007",
  "nik_karyawan": "EMP-007",
  "nama_karyawan": "Budi Contoh",
  "nama_cabang": "Kantor Pusat",
  "nama_divisi": "Finance",
  "nama_jabatan": "Staff Finance",
  "status": "pengajuan",
  "status_approval": "pengajuan",
  "status_label": "Menunggu Diterima",
  "tab": "pengajuan",
  "items": [
    {
      "id_asset_trx_offboarding_item": "CMP001202609010",
      "id_asset_data": "CMP00120260100012",
      "nama_asset": "Laptop 14 inch",
      "deskripsi_asset": "Charger",
      "kategori_asset": "Laptop",
      "status_item": "belum_dicek",
      "ket_rusak": "",
      "jenis_transaksi": "onboarding",
      "id_transaksi_sumber": "CMP001202601002",
      "tabel_transaksi_sumber": "asset_trx_onboarding_karyawan"
    },
    {
      "id_asset_trx_offboarding_item": "CMP001202609011",
      "id_asset_data": "CMP00120260100031",
      "nama_asset": "Proyektor Mini",
      "deskripsi_asset": "",
      "kategori_asset": "Proyektor",
      "status_item": "belum_dicek",
      "ket_rusak": "",
      "jenis_transaksi": "peminjaman",
      "id_transaksi_sumber": "CMP001202609002",
      "tabel_transaksi_sumber": "asset_trx_peminjaman_karyawan"
    }
  ]
}

404: "Offboarding asset tidak ditemukan." (termasuk draft untuk karyawan).

Mulai v1.2 detail memuat id_cabang karyawan (dipakai mobile untuk default lokasi) dan setiap items[] memuat id_asset_lokasi_m_tujuan serta nama_lokasi_tujuan (kosong sampai asset diterima).

API-006 — Hapus Draft

DELETE /asset/offboarding-karyawan/{id}

Response DELETED: { "id": "...", "no_trx": "KRY02-..." }, "Draft offboarding berhasil dihapus." 422: "Hanya offboarding berstatus draft yang dapat dihapus."

API-007 — Ubah Jadwal

PUT /asset/offboarding-karyawan/{id}/jadwal

{ "tgl_offboarding": "2026-10-02", "jam_offboarding": "13:30" }

Rule: keduanya required + format ("Jadwal offboarding belum lengkap."). Database impact: header (jadwal, status pengajuan, approval kosong), child & item (reset), notif_data. Response detail, "Jadwal offboarding berhasil diperbarui." 422: "Jadwal offboarding sudah tidak dapat diubah."

API-008 — Terima Penyerahan

POST /asset/offboarding-karyawan/{id}/terima

Body (v1.2): lokasi gudang dipilih per asset.

{
  "items": [
    {"id_asset_trx_offboarding_item": "CMP001202609010", "id_asset_lokasi_m": "CMP001202610001"},
    {"id_asset_trx_offboarding_item": "CMP001202609011", "id_asset_lokasi_m": "CMP001202610002"}
  ]
}

Pesan umum validasi: "Data penerimaan offboarding belum lengkap." Setiap item offboarding wajib muncul tepat satu kali, dan lokasi harus bertipe gudang pada company yang sama. Database impact:

UPDATE asset_data (gudang, id_asset_lokasi_m, tersedia/rusak, ket_rusak)
UPDATE asset_trx_offboarding_karyawan_item (id_asset_lokasi_m_tujuan)
INSERT asset_trx_log (offboarding_karyawan / pengembalian_karyawan)
UPDATE asset_trx_peminjaman_karyawan child → selesai; peminjaman asal → selesai
UPDATE asset_trx_offboarding_karyawan → selesai
INSERT notif_data

Response detail (status = selesai), "Asset offboarding berhasil diterima." 422: "Offboarding belum dikonfirmasi karyawan.", "Daftar asset yang dipegang karyawan sudah berubah.", "Kondisi asset belum dikonfirmasi karyawan.", "Satu atau beberapa asset offboarding tidak ditemukan.", "Asset tidak lagi dipegang karyawan terkait.", "Pengembalian pinjaman belum dikonfirmasi.", "Kondisi pengembalian pinjaman tidak sesuai.", "Relasi pengembalian offboarding tidak valid.", "Transaksi pengembalian offboarding tidak ditemukan.", "Item pengembalian pinjaman offboarding tidak lengkap.", "Asset pinjaman tidak lagi dipegang karyawan terkait.", "Lokasi gudang tujuan setiap asset wajib dipilih.", "Lokasi gudang tujuan tidak valid.", "Lokasi gudang tujuan asset tidak sesuai." 500: "Terjadi kesalahan saat menerima offboarding asset."

API-011 — Konfirmasi Karyawan

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

{
  "items": [
    {"id_asset_trx_offboarding_item": "CMP001202609010", "status_item": "normal", "ket_rusak": ""},
    {"id_asset_trx_offboarding_item": "CMP001202609011", "status_item": "rusak", "ket_rusak": "Lensa retak"}
  ]
}

Pesan umum: "Data konfirmasi offboarding belum lengkap." Database impact: item off boarding, item & header child, header off boarding, notif_data. Response detail (dikonfirmasi), "Offboarding asset berhasil dikonfirmasi." 403: "Karyawan tidak aktif atau tidak ditemukan." 422: "Offboarding tidak menunggu konfirmasi.", "Daftar asset yang dipegang karyawan sudah berubah.", "Seluruh kondisi asset offboarding wajib diisi.", "Keterangan kerusakan asset wajib diisi.", "Item pengembalian offboarding tidak sesuai." 500: "Terjadi kesalahan saat mengonfirmasi offboarding asset."

25Mobile Architecture

Page → AssetOffboardingBloc (mode admin/employee) → AssetOffboardingApi → ApiClient → Backend

26Mobile Screen

26.1 Off Boarding Asset — list

Tab Pengajuan, Dikonfirmasi, Selesai. Kartu: Data Karyawan (admin) / nomor (karyawan), Tanggal Penyerahan, "Jam Penyerahan: …", jumlah asset, badge status (Draft / Menunggu Diterima / Dikonfirmasi / Selesai). Admin: tombol + (Tambah off boarding) dan ikon Hapus Draft pada kartu draft (dialog "Draft off boarding akan dihapus dan tidak dapat dipulihkan."). Kosong: "Belum ada data off boarding asset."

26.2 Tambah Off Boarding Asset (Admin)

26.3 Detail Off Boarding Asset

Header (nomor, status, jadwal), Catatan, Data Karyawan (Jabatan, Cabang, Departemen), daftar asset dipisah Off Boarding Asset (asset tetap) dan Asset yang Dipinjam (pinjaman). Per asset: pilihan Normal / Rusak (+ Keterangan Kerusakan) saat karyawan mengonfirmasi, atau tampilan kondisi.

Dialog Lokasi Tujuan Asset (v1.2): setiap asset (tetap dan pinjaman) punya dropdown gudang sendiri; default-nya gudang yang id_cabang-nya sama dengan cabang karyawan. Tombol Terima Penyerahan Asset pada dialog baru aktif setelah semua asset terpilih, lalu mengirim items[] per asset. Bila belum ada lokasi bertipe gudang muncul "Belum ada lokasi gudang." dan dialog tidak dibuka. Setelah selesai, kartu tiap asset menampilkan "Lokasi Tujuan Asset: {nama gudang}".

Alur status: AssetAlurStepper.offboarding (Draft → Konfirmasi → Serah Terima → Selesai) dan satu kartu timeline per aset (AssetOffboardingTimelineCards): Draft (jenis aset; aset pinjaman dikembalikan otomatis) · Konfirmasi (kondisi Normal/Rusak; chip Rusak) · Serah Terima (jadwal) · Selesai (lokasi gudang tujuan). Kartu timeline disembunyikan saat karyawan mengisi konfirmasi atau admin menerima penyerahan, karena form per aset sudah ada di kartu aset. File: Shared/Widgets/AssetAlurWidgets.dart, Shared/Widgets/AssetOffboardingTimeline.dart.

26.4 Asset Saya (Karyawan)

Banner Off Boarding Asset dari record pertama tab pengajuan + teks info dan jadwal; menu Off Board.

26.5 Asset Karyawan (Admin)

Panel Off Boarding Perlu Diproses (summary.offboarding_pending) dengan tombol Lanjutkan Draft (draft → form) atau Terima Asset (dikonfirmasi → detail).

27Mobile → API

28API → Mobile

29Mapping Mobile → API → Database

30Mapping Database → API → Mobile

31Validation

31.1 Mobile

31.2 Backend — lihat §9 & §24.

31.3 Database — enum status_approval; no_trx unique per company; status_item varchar(30).

31.4 Ringkasan per Field

32Error Handling

33Audit Trail

34Notification

Draft tidak mengirim notifikasi. Child pengembalian pinjaman tidak mengirim notifikasi peminjaman tersendiri.

35Security

36Manual Book User/Admin

A. Admin — Membuat Off Boarding

1. Asset Karyawan → Off Boarding → tekan +.
2. Pilih Karyawan (gunakan Cari Karyawan). Hanya karyawan aktif yang memegang asset dan belum sedang di-off boarding yang muncul.
3. Isi Jadwal Serah Terima: Tanggal Penyerahan dan Jam Penyerahan.
4. Isi Catatan Tambahan bila perlu.
5. Tekan Simpan Draft untuk menyimpan dulu, atau Submit ke Karyawan untuk mengirim.
6. Seluruh asset yang dipegang karyawan (termasuk pinjaman) otomatis masuk daftar.

B. Admin — Draft

• Lanjutkan dari kartu draft atau panel Off Boarding Perlu Diproses → Lanjutkan Draft.
• Hapus dengan ikon Hapus Draft → konfirmasi.

C. Karyawan — Konfirmasi Kondisi

1. Buka banner Off Boarding Asset di Asset Saya atau menu Off Board.
2. Periksa jadwal penyerahan.
3. Untuk setiap asset pilih Normal atau Rusak (isi Keterangan Kerusakan bila rusak).
4. Tekan Konfirmasi Off Boarding → konfirmasi.

D. Admin — Ubah Jadwal

Detail → Ubah Jadwal Penyerahan → pilih tanggal & jam. Bila sudah dikonfirmasi karyawan, status kembali ke Pengajuan dan karyawan harus konfirmasi ulang.

E. Admin — Menyelesaikan

1. Terima asset secara fisik sesuai jadwal dan periksa kondisinya.
2. Detail → Terima Penyerahan Asset.
3. Pada dialog Lokasi Tujuan Asset, pilih gudang untuk setiap asset (default: gudang di cabang karyawan), lalu tekan Terima Penyerahan Asset.
4. Semua asset kembali ke gudang yang dipilih (Tersedia/Rusak), peminjaman aktif karyawan ikut selesai, status Selesai.

37Kondisi Button

38Testing Scenario

Test otomatis yang sudah ada (API): test_offboarding_routes_are_registered, test_offboarding_requires_authentication, test_offboarding_lifecycle_uses_string_statuses, test_admin_pending_lists_draft_and_confirmed_offboarding, test_employee_list_hides_drafts, test_employee_reports_damage_before_admin_receives, test_offboarding_preserves_request_source, test_offboarding_orchestrates_loan_return_as_child_transaction, test_draft_does_not_create_loan_return_child, test_migration_converts_and_restores_offboarding_statuses, test_migration_converts_legacy_string_statuses, test_offboarding_rejects_assets_in_upgrade_or_damage_report (v1.1). v1.2: test_receive_requires_a_valid_warehouse_location, test_options_list_only_warehouse_locations, lokasi per asset pada test_offboarding_orchestrates_loan_return_as_child_transaction; mobile asset_offboarding_widget_test.dart (admin memilih lokasi per asset) dan asset_offboarding_model_test.dart.

39Temuan Ketidaksesuaian

40Edge Case

41Potential Bug / Technical Risk

RISK-001 — Karyawan nonaktif menghentikan alur (TINGGI)

Lokasi: AssetKaryawanOffboarding_c::offboardingAccessError, AssetOffboardingKaryawan_m::confirm (findActiveKaryawan). Masalah: Konfirmasi hanya bisa oleh karyawan aktif. Off boarding umumnya dilakukan saat karyawan keluar; bila status karyawan diubah lebih dulu, off boarding tidak bisa dikonfirmasi dan admin tidak punya jalan lain. Recommendation: Tambah aksi admin untuk mengisi kondisi, atau izinkan karyawan nonaktif yang punya off boarding aktif.

RISK-002 — Selesai (v1.1)

Sebelumnya Kerusakan & Upgrade tidak dicek saat membuat off boarding. assertNoCrossFlow kini memanggil hasActiveUpgradeAsset, hasActiveRusakAsset, dan hasActivePemeliharaanAsset (lihat BR-005). Diuji oleh test_offboarding_rejects_assets_in_upgrade_or_damage_report.

RISK-003 — Tidak ada pembatalan setelah submit (SEDANG)

Hanya draft yang bisa dihapus. Off boarding yang salah karyawan/terlanjur dikirim tidak bisa dibatalkan dan terus mengunci asset.

RISK-004 — Kondisi sepenuhnya dari karyawan (SEDANG)

Admin tidak dapat mengubah Normal/Rusak saat menerima; satu-satunya jalan adalah ubah jadwal (reset) dan meminta karyawan mengonfirmasi ulang.

RISK-005 — Draft mengunci asset (SEDANG)

activeStatuses() memasukkan draft, sehingga draft yang belum dikirim (dan tidak terlihat karyawan) sudah memblokir Retur, Kerusakan, Upgrade, dan pengembalian pinjaman.

RISK-006 — Daftar asset beku setelah submit (SEDANG)

Tidak ada mekanisme menyinkronkan item bila asset karyawan berubah; assertCurrentHoldings akan terus gagal.

RISK-007 — Notifikasi di luar transaksi (RENDAH)

Dikirim setelah commit; kegagalan tidak membatalkan transaksi.

RISK-008 — Kapasitas penomoran (RENDAH)

3 digit/bulan/company untuk header, item, relasi; item memakan satu nomor per asset.

RISK-009 — Lokasi gudang belum tersedia (SEDANG)

Terima Penyerahan mewajibkan lokasi bertipe gudang dari asset_lokasi_m. Tabel ini hanya terdokumentasi di DBML (tidak ada migration pembuatnya di repo); bila tabel kosong, off boarding tidak dapat diselesaikan. Kolom header asset_trx_offboarding_karyawan.id_asset_lokasi_m_tujuan (v1.2 awal) kini tidak dipakai dan dapat dihapus.

42Dependency

Asset dipegang karyawan (Onboarding / Request-Penambahan / Retur pengganti / Peminjaman)
        ↓ deteksi sumber (asset_trx_log, onboarding, request, peminjaman)
Off Boarding (draft → pengajuan → dikonfirmasi → selesai) ──► Notifikasi
        ├─ asset pinjaman → child Pengembalian KRY05 (via asset_trx_offboarding_relasi)
        ↓ Terima
Asset → gudang (tersedia / rusak) + asset_trx_log; Peminjaman asal → selesai

Aturan silang:
  - Off boarding mengecek: Retur aktif, Pengembalian pinjaman aktif, Upgrade aktif, Kerusakan aktif, Pemeliharaan (PML01) aktif
  - Dicek oleh: Retur, Pengembalian pinjaman, Kerusakan, Upgrade, Pemeliharaan PML01 (hasActiveOffboardingAsset)
  - Modul Peminjaman menyembunyikan & menolak konfirmasi child milik off boarding
  - Summary admin: offboarding_perlu_proses / offboarding_pending

43Source Code Reference

44Developer Notes

• Status sebagai enum PHP (OffboardingStatus) — label & tab berasal dari enum, bukan dari tabel.
• Item dibangun otomatis dari asset_data; tidak ada input asset dari klien.
• sourceForAsset menentukan sumber dengan urutan prioritas; asset hasil retur pengganti biasanya terdeteksi lewat asset_trx_log (tabel asset_trx_retur_karyawan) dengan jenis_transaksi = onboarding.
• Transaksi child hanya dibuat saat submit, dihapus saat edit/hapus draft, direset saat ubah jadwal, dikonfirmasi saat karyawan konfirmasi, dan difinalisasi saat terima — semuanya dalam transaksi DB yang sama.
• Migration idempotent dengan tabel marker asset_offboarding_migration_state untuk rollback; mendukung konversi status numerik/legacy.
• Summary admin mengembalikan []/0 bila tabel belum ada (offboardingTablesExist).

45End-to-End Traceability

Admin memilih "Budi" + 30 Sep 09:00 → Submit ke Karyawan
  → AssetOffboardingRequest(idKaryawan, tglOffboarding, jamOffboarding, isDraft=false)
  → POST /asset/offboarding-karyawan
  → store(): employeeAssets() = [Laptop (onboarding), Proyektor (dipinjam)]
  → INSERT header KRY02-… (pengajuan) + 2 item (belum_dicek)
  → createLoanReturnChildren(): header pengembalian KRY05 + relasi
Karyawan: Laptop Normal, Proyektor Rusak "Lensa retak" → Konfirmasi Off Boarding
  → items[].status_item / ket_rusak → confirm()
  → item: normal / rusak; child item: disetujui / ditolak(ket_tolak); header dikonfirmasi
Admin: Terima Penyerahan Asset → receive()
  → Laptop: tersedia @gudang + log offboarding_karyawan
  → Proyektor: rusak @gudang (ket_rusak "Lensa retak") + log pengembalian_karyawan; child selesai; peminjaman asal selesai
  → header selesai → Mobile: badge "Selesai"

45.4 Walkthrough Lengkap dengan Contoh Data

Bagian ini mengikuti satu offboarding dari draft sampai asset kembali ke gudang, 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 (AssetOffboardingKaryawan_m, AssetAdminOffboarding_c, AssetKaryawanOffboarding_c, AssetNotification).

Skenario: Budi berhenti bekerja dan memegang dua asset: laptop (asset tetap dari onboarding) dan proyektor (asset pinjaman aktif). Admin membuat offboarding, menyimpannya sebagai draft, lalu mengirimnya. Budi menilai laptop Normal dan proyektor Rusak. Admin menerima semua asset dan memilih gudang tujuan per asset.

Data awal

Company CMP001. Draft dibuat 22 Oktober 2026, periode ID 202610. Belum ada offboarding, pengembalian, log, atau notifikasi pada periode ini.

data_karyawan

asset_data yang dipegang Budi

Lokasi gudang (asset_lokasi_m, tipe gudang): CMP001202601001 = Gudang Pusat, CMP001202601002 = Gudang Servis.

Penomoran: header, item, dan relasi id_company + YYYYMM + 3 digit, no_trx = KRY02-YYYYMMNNN; pengembalian turunan memakai penomoran peminjaman (KRY05-…); log dan notifikasi 5 digit.

Langkah 0 — Admin membuka form

Mobile: Asset Karyawan → Off Boarding → + → form Tambah Off Boarding Asset → AssetOffboardingApi.getOptions().

Dikirim

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

Diproses API: accessError() (admin asset) → AssetOffboardingKaryawan_m::getOptions: karyawan aktif yang memegang minimal satu asset dan belum punya offboarding aktif (draft, pengajuan, dikonfirmasi), ditambah lokasi_gudang[] (lokasi bertipe gudang milik company, urut nama).

Database: hanya SELECT.

Diterima mobile

{ "code": "SUCCESS", "message": "Opsi offboarding asset berhasil ditemukan.",
  "data": {
    "karyawan": [ { "id_karyawan": "KRY0007", "nik": "EMP-007", "nama_karyawan": "Budi Contoh" } ],
    "lokasi_gudang": [
      { "id_asset_lokasi_m": "CMP001202601001", "nama_lokasi": "Gudang Pusat", "id_cabang": "CAB-1" },
      { "id_asset_lokasi_m": "CMP001202601002", "nama_lokasi": "Gudang Servis", "id_cabang": "CAB-1" }
    ] } }

Admin tidak memilih asset: seluruh asset yang dipegang karyawan otomatis ikut.

Langkah 1 — Admin menyimpan draft

Mobile: admin memilih Budi Contoh, mengisi Catatan Tambahan, lalu Simpan Draft (jadwal belum diisi) → AssetOffboardingApi.store.

Dikirim

POST /asset/offboarding-karyawan

{
  "id_karyawan": "KRY0007",
  "tgl_offboarding": null,
  "jam_offboarding": null,
  "keterangan": "Karyawan mengakhiri kontrak",
  "is_draft": true
}

Diproses API (AssetAdminOffboarding_c::storeOffboardingKaryawan → AssetOffboardingKaryawan_m::store, satu DB::transaction) 1. Validasi: id_karyawan wajib; tanggal dan jam boleh kosong untuk draft (wajib bila bukan draft). 2. lockCompany; requireAdmin → user_input = "ADM-001 - Siti Admin"; findActiveKaryawan("KRY0007"). 3. assertNoActiveOffboarding: Budi belum punya offboarding draft/pengajuan/dikonfirmasi. 4. employeeAssets: semua asset_data dengan pemegang_asset = karyawan dan id_pemegang_asset = KRY0007 (tanpa filter status) → A20 dan A21. Minimal 1. 5. assertNoCrossFlow: asset tidak boleh ada di retur aktif, pengembalian pinjaman pengajuan/dikonfirmasi, upgrade, laporan kerusakan, atau pemeliharaan aktif. 6. assertSchedule: draft lolos tanpa jadwal. 7. Generate ID: header urutan 1 → CMP001202610001, no_trx = KRY02-202610001. 8. INSERT header (draft); insertItems mencari sumber transaksi tiap asset (sourceForAsset) lalu INSERT item dengan status_item = belum_dicek. 9. Draft tidak membuat pengembalian turunan dan tidak mengirim notifikasi. asset_data tidak diubah.

Hasil database

asset_trx_offboarding_karyawan

asset_trx_offboarding_karyawan_item

(Urutan baris item mengikuti hasil query asset yang tidak memakai ORDER BY.) asset_data: tidak berubah (A20 terpakai, A21 dipinjam). Meski begitu, draft sudah mengunci asset untuk modul lain lewat hasActiveOffboardingAsset.

Diterima mobile (HTTP 201): detail seperti API-004 dengan status = draft, status_label = "Draft", tab = "pengajuan" (tab admin), items[] di atas, dan message "Draft offboarding berhasil disimpan.".

Langkah 2 — Admin mengirim ke karyawan

Mobile: panel Off Boarding Perlu Diproses → Lanjutkan Draft → form terisi dari draft. Admin mengisi jadwal 30 Okt 2026 pukul 09:00, lalu Submit ke Karyawan → AssetOffboardingApi.updateDraft.

Dikirim

PUT /asset/offboarding-karyawan/CMP001202610001

{
  "id_karyawan": "KRY0007",
  "tgl_offboarding": "2026-10-30",
  "jam_offboarding": "09:00",
  "keterangan": "Karyawan mengakhiri kontrak",
  "is_draft": false
}

Diproses API (updateDraft) 1. Validasi: tanggal dan jam wajib karena is_draft = false ("Jadwal offboarding wajib diisi saat pengajuan."). Backend tidak memeriksa tanggal ≥ hari ini. 2. Header dikunci, harus draft ("Hanya offboarding berstatus draft yang dapat diubah."). 3. Validasi ulang seperti langkah 1 (karyawan aktif, tidak ada offboarding aktif selain dirinya, asset yang dipegang saat ini, tidak ada konflik flow lain). 4. Seluruh item lama, relasi, dan pengembalian turunan dihapus, lalu item dibangun ulang dari asset yang dipegang saat itu. Karena penghapusan terjadi sebelum penomoran dihitung, ID item dipakai ulang dari awal (…001, …002). 5. UPDATE header: jadwal, status_approval = pengajuan, user_approval = '', tgl_approval = NULL, tgl_update, user_update; karyawan boleh diganti. 6. createLoanReturnChildren: untuk setiap peminjaman sumber (kelompok id_transaksi_sumber) dibuat satu header pengembalian di tabel peminjaman, item, dan satu baris relasi. 7. Setelah commit: AssetNotification::send('offboarding.diajukan', …) ke karyawan.

Hasil database

Header CMP001202610001 (kolom yang berubah)

Item (dibuat ulang, ID dipakai ulang): CMP001202610001 (A20, onboarding) dan CMP001202610002 (A21, peminjaman), keduanya belum_dicek, user_input = ADM-001 - Siti Admin.

Pengembalian turunan (karena A21 adalah asset pinjaman)

asset_trx_peminjaman_karyawan (baris baru)

asset_trx_peminjaman_karyawan_item (baru): CMP001202610001, id_asset_trx_peminjaman = CMP001202610001, A21, Proyektor Mini, status_item = NULL.

asset_trx_offboarding_relasi (baru)

Pengembalian turunan ini disembunyikan dari daftar dan pending modul Peminjaman, dan tidak bisa dikonfirmasi dari sana ("Pengembalian ini diproses melalui offboarding.").

notif_data (1 baris)

Diterima mobile (HTTP 200): detail dengan status = pengajuan, status_label = "Menunggu Diterima", tab = "pengajuan", message "Offboarding asset berhasil diajukan.".

Langkah 3 — Budi membuka detail

Mobile: banner Off Boarding Asset di Asset Saya (atau notifikasi) → detail → GET /asset/karyawan/offboarding/CMP001202610001.

Diproses API: offboardingAccessError (karyawan aktif, selain itu 403 "Karyawan tidak aktif atau tidak ditemukan."); detail hanya untuk transaksi milik Budi dan bukan draft (selain itu 404 "Offboarding asset tidak ditemukan."). SELECT saja.

Diterima mobile (ringkas)

{
  "id": "CMP001202610001", "no_trx": "KRY02-202610001",
  "tgl_offboarding": "2026-10-30", "jam_offboarding": "09:00:00",
  "keterangan": "Karyawan mengakhiri kontrak",
  "status": "pengajuan", "status_label": "Menunggu Diterima", "tab": "pengajuan",
  "items": [
    { "id_asset_trx_offboarding_item": "CMP001202610001", "id_asset_data": "CMP00120260100020",
      "nama_asset": "Laptop 14 inch", "status_item": "belum_dicek", "ket_rusak": "",
      "jenis_transaksi": "onboarding", "id_transaksi_sumber": "CMP001202609001",
      "tabel_transaksi_sumber": "asset_trx_onboarding_karyawan" },
    { "id_asset_trx_offboarding_item": "CMP001202610002", "id_asset_data": "CMP00120260100021",
      "nama_asset": "Proyektor Mini", "status_item": "belum_dicek", "ket_rusak": "",
      "jenis_transaksi": "peminjaman", "id_transaksi_sumber": "CMP001202609005",
      "tabel_transaksi_sumber": "asset_trx_peminjaman_karyawan" }
  ]
}

Langkah 4 — Budi mengonfirmasi kondisi

Mobile: Budi memilih Normal pada laptop, Rusak pada proyektor dengan keterangan "Lensa retak", lalu Konfirmasi Off Boarding → AssetOffboardingApi (karyawan) konfirmasi.

Dikirim

POST /asset/karyawan/offboarding/CMP001202610001/konfirmasi

{
  "items": [
    { "id_asset_trx_offboarding_item": "CMP001202610001", "status_item": "normal", "ket_rusak": "" },
    { "id_asset_trx_offboarding_item": "CMP001202610002", "status_item": "rusak", "ket_rusak": "Lensa retak" }
  ]
}

Diproses API (AssetKaryawanOffboarding_c::konfirmasiOffboardingSaya → confirm) 1. Validasi: status_item ∈ normal/rusak; ket_rusak wajib bila rusak. 2. lockCompany; karyawan aktif; header milik Budi, FOR UPDATE, harus pengajuan ("Offboarding tidak menunggu konfirmasi."). 3. assertCurrentHoldings: daftar asset yang dipegang saat ini harus sama persis dengan item ("Daftar asset yang dipegang karyawan sudah berubah."). 4. Semua item wajib dinilai ("Seluruh kondisi asset offboarding wajib diisi."); UPDATE status_item dan ket_rusak. 5. confirmLoanReturnChildren: item pengembalian turunan diterjemahkan (normal → disetujui, rusak → ditolak + ket_tolak = keterangan rusak); header turunan → dikonfirmasi. 6. UPDATE header offboarding → dikonfirmasi; user_approval dan tgl_approval = karyawan yang mengonfirmasi. 7. Notifikasi offboarding.dikonfirmasi ke seluruh admin. asset_data belum berubah.

Hasil database

notif_data (2 baris ke admin)

Diterima mobile (HTTP 200): detail dengan status = dikonfirmasi, status_label = "Dikonfirmasi Karyawan", tab = "dikonfirmasi", message "Offboarding asset berhasil dikonfirmasi.".

Langkah 5 — Admin menerima penyerahan

Mobile: panel Off Boarding Perlu Diproses (tombol Terima Asset) atau detail → Terima Penyerahan Asset → dialog Lokasi Tujuan Asset: laptop → Gudang Pusat, proyektor → Gudang Servis (default gudang di cabang karyawan) → AssetOffboardingAdminApi.terima.

Dikirim

POST /asset/offboarding-karyawan/CMP001202610001/terima

{
  "items": [
    { "id_asset_trx_offboarding_item": "CMP001202610001", "id_asset_lokasi_m": "CMP001202601001" },
    { "id_asset_trx_offboarding_item": "CMP001202610002", "id_asset_lokasi_m": "CMP001202601002" }
  ]
}

Setiap item offboarding (termasuk asset pinjaman) muncul tepat satu kali.

Diproses API (terimaOffboardingKaryawan → receive) 1. lockCompany; requireAdmin; header harus dikonfirmasi ("Offboarding belum dikonfirmasi karyawan."). 2. assertCurrentHoldings lagi; semua item harus normal/rusak ("Kondisi asset belum dikonfirmasi karyawan."). 3. resolveItemLocations: lokasi tiap item bertipe gudang, company yang sama, satu kali per item. 4. Asset dikunci. Asset tetap (laptop): harus masih dipegang Budi; UPDATE asset_data → gudang, id_pemegang_asset = '', id_asset_lokasi_m pilihan admin, tersedia (normal) atau rusak + ket_rusak; siapkan log offboarding_karyawan. 5. finalizeLoanReturnChildren untuk asset pinjaman: header turunan harus dikonfirmasi dan item cocok dengan kondisi; UPDATE asset_data (proyektor → rusak, gudang, lokasi, ket_rusak), siapkan log pengembalian_karyawan; header turunan → selesai dengan tgl_serah_terima/jam_serah_terima = sekarang. 6. UPDATE item offboarding id_asset_lokasi_m_tujuan; INSERT asset_trx_log; header offboarding → selesai. 7. completeLoanSources: peminjaman asal aktif → selesai bila tidak ada lagi asset pinjaman yang dipegang karyawan. 8. Notifikasi offboarding.diterima ke karyawan.

Hasil database

asset_trx_log (2 baris)

kondisi_awal = asset_data.kondisi_awal; pemegang_asset = gudang, id_pemegang = ''; user_input = ADM-001 - Siti Admin.

notif_data: CMP00120261000004 ke KRY0007, id_ref CMP001202610001, rute asset_employee_detail_offboarding, "Asset offboarding KRY02-202610001 telah diterima admin."

Diterima mobile (HTTP 200): detail dengan status = selesai, status_label = "Selesai", tab = "selesai", items[].id_asset_lokasi_m_tujuan dan nama_lokasi_tujuan terisi, message "Asset offboarding berhasil diterima.".

Kondisi akhir data

asset_trx_offboarding_karyawan: CMP001202610001 / KRY02-202610001, status selesai, user_approval = EMP-007 - Budi Contoh.

asset_trx_offboarding_karyawan_item

asset_data: A20 → tersedia @Gudang Pusat; A21 → rusak @Gudang Servis (ket_rusak = Lensa retak). Pengembalian turunan KRY05-202610001 → selesai; peminjaman KRY05-202609005 → selesai. asset_trx_log: 2 baris. notif_data: 4 baris. Budi tidak lagi memegang asset apa pun.

Variasi

Ubah jadwal (API-007). PUT /asset/offboarding-karyawan/{id}/jadwal dengan {"tgl_offboarding":"2026-11-02","jam_offboarding":"13:30"} hanya untuk status pengajuan atau dikonfirmasi ("Jadwal offboarding sudah tidak dapat diubah." untuk status lain). Efeknya mengulang proses: header kembali pengajuan dengan user_approval = '' dan tgl_approval = NULL; pengembalian turunan kembali pengajuan dengan jadwal baru, item turunan status_item = NULL; seluruh item offboarding kembali belum_dicek dengan ket_rusak = ''. Karyawan harus mengisi kondisi lagi. Notifikasi offboarding.dijadwalkan ke karyawan ("Jadwal offboarding asset {no_trx} telah diperbarui."). Perilaku ini dicatat sebagai INC-04.

Tanpa asset pinjaman. Bila karyawan hanya memegang asset tetap, tidak ada pengembalian turunan dan tidak ada baris relasi; langkah lain sama, dan peminjaman asal tidak terlibat.

Hapus draft (API-006). DELETE /asset/offboarding-karyawan/{id} saat draft: item, pengembalian turunan, relasi, dan header dihapus; asset_data tidak pernah berubah; tanpa notifikasi. Karyawan kembali muncul di opsi.

Draft mengunci asset. Selama draft ada, retur, pengajuan pengembalian peminjaman, kerusakan, dan upgrade atas asset itu ditolak dengan "…sedang diproses pada offboarding." (RISK-005).

Kasus gagal yang umum

Semua pelanggaran aturan dilempar sebagai InvalidArgumentException di dalam DB::transaction, sehingga seluruh perubahan request itu dibatalkan. Pesan exception tidak dikirim mentah ke klien pada kegagalan sistem (500).

Ringkasan siapa mengerjakan apa

46Ringkasan Database Impact

47Checklist Implementasi

Database

• Header, item, relasi + index + unique no_trx
• Migration dengan rollback & konversi legacy
• Selaraskan DBML dengan migration
• Lokasi gudang tujuan: asset_data.id_asset_lokasi_m + item id_asset_lokasi_m_tujuan (v1.2)
• Backfill lokasi asset yang sudah di gudang
• Hapus kolom header id_asset_lokasi_m_tujuan (deprecated)

Backend

• Draft, submit, edit, hapus draft
• Ubah jadwal, konfirmasi karyawan, terima admin
• Orkestrasi pengembalian pinjaman sebagai child
• Kunci asset untuk modul lain
• Test otomatis (12)
• Lokasi gudang tujuan dipilih per asset saat Terima (v1.2)
• Lokasi gudang untuk Retur & Peminjaman
• Hilangkan pesan exception di response 500 (v1.3)
• Cek Kerusakan/Upgrade/Pemeliharaan aktif (v1.1)
• Pembatalan setelah submit
• Jalan keluar untuk karyawan nonaktif / override kondisi oleh admin
• Reset kondisi item saat ubah jadwal tanpa child

Mobile

• List, form (draft/submit), detail, konfirmasi, terima, ubah jadwal
• Banner Asset Saya & panel admin
• Dialog Lokasi Tujuan Asset per asset (v1.2)
• Preview daftar asset di form
• Selaraskan label status

Documentation

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

48Changelog