Panduan tinjauan mockup sistem rekonsiliasi

1. Apa yang Bapak/Ibu lihat

Ini mockup — tampilan sistem yang sudah bisa diklik dan dijelajahi, tetapi belum tersambung ke data sungguhan. Seluruh angka di dalamnya data contoh yang kami buat sendiri.

Kenapa dibuat sebelum sistemnya dibangun: jauh lebih murah mengubah tata letak dan alur kerja sekarang, saat masih berupa tampilan, daripada setelah kode dan basis datanya jadi.

Yang sudah nyata di dalamnya:

• 48 menu · 12 kelompok, seluruhnya berfungsi — termasuk ruang kerja per bank
• 90 hari data contoh: 31 juta transaksi, 450 kiriman ke bank, 2.016 berkas STM stasiun, 360 batch klaim, 352 berkas balasan bank
• Hasil urai berkas bank yang sebenarnya — 12 berkas balasan asli dari paket sampel PT KAI, terbaca semuanya (menu Uji urai berkas bank)
• Sebelas jenis cacat ditanam, masing-masing dengan tingkat buktinya — terbukti, terindikasi, atau dugaan
• Perubahan yang Bapak/Ibu lakukan tersimpan dan muncul di jejak audit

Yang belum nyata: datanya. Angka dan nama berkasnya karangan kami — dibuat supaya masuk akal, tetapi bukan data LRT yang sesungguhnya.

Yang berubah besar sejak versi sebelumnya

Versi mockup terdahulu dibangun sebagai rekonsiliasi uang: klaim versus rekening koran bank, dengan MDR dan potongan bank sebagai penjelas selisih.

Premis itu keliru, dan sudah dibuang seluruhnya. Rapat 31 Agustus memastikan selisih tidak berasal dari potongan bank. Dokumen Requirement System Rekonsiliasi (56 butir) menggantikan lingkupnya — dan seluruh mockup ini dibangun ulang mengikutinya.

Kalau Bapak/Ibu pernah melihat versi sebelumnya: hampir semuanya berbeda sekarang.

2. Yang kami minta dari Bapak/Ibu

Bukan persetujuan. Koreksi.

Kami ingin tahu di mana kami salah membaca cara kerja Bapak/Ibu sehari-hari — istilah yang tidak dipakai, kolom yang tidak pernah dilihat, langkah yang urutannya keliru, dan angka yang tidak masuk akal.

Satu jam Bapak/Ibu mencoba mockup ini bisa menghemat berhari-hari pekerjaan nanti.

3. Cara masuk

https://lrt.mockapps.id — kata sandi semua akun: lrt2026

Lima peran ini mengikuti §32 pada dokumen requirement. Hak akses tiap peran dapat dilihat di Administrasi › Peran & hak akses.

4. Tiga hal yang perlu diketahui sebelum mulai

① Sistem ini membaca enam tahap, bukan dua

`` Gate → DB SOT → Settlement → Settlement → Berkas STM → Balasan bank stasiun catatan ctm trx tagihan jawaban induk log keluar gate detail tap dikirim bank ``

Enam tahap, lima tempat data bisa mulai kembar. Seluruh pekerjaan sistem ini adalah menunjukkan di tahap mana — bukan menebak.

Urutan ini dikoreksi 22 September 2026 setelah membaca katalog function Settlement Engine: ctm berada sebelum trx, bukan sesudahnya. Isinya log keluar gate, bukan tahap penyiapan tagihan — namanya yang menyesatkan.

② Yang dibandingkan jumlah baris, bukan nilainya

Dua berkas bisa sama totalnya tanpa satu pun transaksi yang sama. Karena itu yang dibaca adalah selisih jumlah baris antar tahap. Bila jumlahnya bertambah dari satu tahap ke tahap berikutnya, di situlah data mulai kembar.

③ Yang membedakan dua baris bukan ID-nya, melainkan isinya

Satu kartu tidak bisa tap dua kali pada detik yang sama. Karena itu yang dipakai membandingkan adalah isi transaksinya — bank, tanggal, jam, nomor kartu, nominal, dan gate. Bukan nomor ID di database.

Ini terbukti di data sungguhan: pada sampel trx.t_d_trx yang tim LRT serahkan, ada baris-baris yang isinya sama persis dan hanya berbeda nomor id.

Nomor kartu tidak pernah disimpan utuh. Hanya empat digit terakhir dan sidiknya.

5. Peta menu

Dua belas kelompok, 46 menu. Pemetaan lengkap tiap menu ke nomor requirement ada di 21-REQUIREMENT-MAP.md.

Yang ditebalkan adalah yang paling ingin kami dapat tanggapannya.

Kelompok Bank — dibuat atas permintaan tim LRT

Bapak/Ibu menyampaikan bahwa bekerja per bank akan lebih mudah, dan bahwa feeding dan response sebaiknya jadi menu, bukan lewat saringan. Begitulah sekarang bentuknya.

Klik salah satu bank, dan bank itu melebar menjadi lima menu:

Memilih bank juga menyalakan konteks bank: seluruh layar lain ikut tersaring ke bank itu, sampai Bapak/Ibu melepasnya. Selama konteks aktif ada bilah penanda di bawah bilah atas — supaya angka yang tersaring tidak pernah terbaca sebagai angka menyeluruh.

Satu peringatan yang perlu kami sampaikan. Layar lintas-bank — Dashboard, Perbandingan lapis, Deteksi duplikat — sengaja tetap lintas-bank. Bila setiap orang hanya melihat banknya sendiri, tidak ada yang menyadari bahwa tiga bank menunjukkan Timing Issue pada hari yang sama — dan bila itu terjadi, penyebabnya hampir pasti di sisi kita, bukan di ketiga bank itu.

6. Lima alur yang paling ingin kami uji

Kalau waktu Bapak/Ibu terbatas, cukup coba lima ini. Alur 2 dan 3 yang paling menentukan.

Alur 1 · Pagi hari — apa yang terjadi semalam (±5 menit)

Masuk sebagai bagas.operation.

1. Buka Dashboard rekonsiliasi. Baris paling atas menunjukkan jumlah transaksi tiap bank.
2. Perhatikan kalimat pembatas di bawah empat angka besar. Empat angka itu menghitung baris berkas; tujuh kartu status di bawahnya menghitung transaksi. Blok Dari baris ke transaksi menguraikan jembatannya — dan uraiannya tutup persis: satu transaksi duplikat menempati dua baris di berkas response, sementara transaksi Missing dan Pending tidak punya baris balasan sama sekali.
3. Lihat kartu Rantai enam lapis. Perhatikan angka di antara kotak — itulah selisihnya.
4. Klik salah satu selisih; rinciannya sudah terurai di bawah — setiap angka dijelaskan komponennya, termasuk Bank DKI yang belum tersambung.
5. Lihat Matriks rekonsiliasi: 5 bank × 30 hari. Kotak merah adalah hari bermasalah. Klik salah satunya.

Pertanyaan kami: apakah urutan informasi di Dashboard sesuai dengan urutan pertanyaan yang sebenarnya Bapak/Ibu tanyakan setiap pagi? Ada yang seharusnya di atas tapi ada di bawah? Ada yang tidak perlu sama sekali?

Alur 2 · Kasus BCA — kiriman 16:00 vs kiriman 04:00 (±6 menit) — paling menentukan

Bisa dimulai dari Bank › Bank Central Asia › Duplikat, atau langsung:

1. Buka Duplikat › Kasus STM ganda — 16:00 vs 04:00.
2. Kartu pertama: BCA · 1 September 2026 · stasiun Cawang. Dua berkas FS dengan 1.240 baris beririsan.
3. Lihat blok "Di tahap mana selisihnya muncul" — jumlah SOT tidak berubah, jumlah Settlement bertambah 1.240. Itulah yang menunjuk Settlement Engine sebagai tempat duplikatnya lahir.
4. Perhatikan: BCA membalas kode 0201 — transaksi duplikat, sudah dibayarkan pada batch sebelumnya. Ini bukan dugaan; bank sendiri yang menyatakannya.
5. Klik Lihat 1.240 transaksinya, lalu klik satu baris.
6. Layar Perbandingan duplikat: dari 11 field, hanya 2 yang berbeda — sumber_fs dan settlement_msg. Sisanya sama persis.

Pertanyaan kami — dan ini yang paling kami butuhkan:

1. FS A dan FS B itu apa persisnya? Dua berkas dari stasiun yang sama dengan periode beririsan, atau dua berkas dari stasiun berbeda? Dugaan kami yang pertama.
2. Kenapa stasiun bisa mengirim dua kali? Dugaan kami: tanda terima berkas pertama tidak sampai, lalu stasiun mengirim ulang. Benar?
3. Apakah pola yang ditampilkan di layar ini cocok dengan yang Bapak/Ibu lihat sehari-hari?

Alur 3 · Menelusuri satu transaksi sampai ke data mentahnya (±5 menit)

Masuk sebagai krisna.invest.

1. Buka Transaksi › Detail investigasi, klik salah satu contoh.
2. Bagian Perjalanan enam tahap: angka di tiap tahap adalah jumlah baris pada tahap itu. Satu berarti sehat, dua berarti duplikat, nol berarti tidak sampai.
3. Gulir ke bawah — empat panel raw data berdampingan: JSON dari DB SOT, baris dari DB Settlement, baris dari berkas STM, baris dari berkas balasan bank.
4. Perhatikan penanda kuning di dalamnya — itulah bagian yang berbeda.

Pertanyaan kami:

1. Apakah bentuk data mentah yang kami tampilkan mirip dengan yang sebenarnya? Kolomnya sudah tepat? Ada yang kurang?
2. Kalau pemeriksa datang dan bertanya "tunjukkan riwayat transaksi ini", apakah layar ini cukup?
3. Apakah DB SOT dan DB Settlement menyimpan nomor urut transaksi? Deteksi transaksi hilang bergantung sepenuhnya pada kolom itu.

Alur 4 · Menahan duplikat sebelum berkas dikirim (±4 menit)

1. Buka Klaim & Settlement › Claim preview.
2. Layar ini menampilkan apa yang dilihat operator sebelum berkas STM dikirim: berapa transaksi eligible, berapa potensi duplikat, berapa exception.
3. Lihat empat pemeriksaan §18 di bawahnya — mana yang lolos, mana yang gagal.
4. Buka Duplikat › Pencegahan duplikat. Empat berkas ditahan karena jumlah duplikatnya melewati ambang.

Pertanyaan kami:

1. Berapa ambang yang masuk akal? Berapa banyak transaksi duplikat yang membuat sebuah berkas layak ditahan seluruhnya, bukan sekadar dicatat?
2. Siapa yang berwenang melepas berkas yang ditahan?
3. Bila berkas ditahan, apa yang sebaiknya terjadi berikutnya — dikirim setelah baris duplikatnya dibuang, atau ditahan sampai tim IT memastikan penyebabnya?

Alur 5 · Menutup satu exception (±4 menit)

Masuk sebagai rina.settlement.

1. Buka Exception & Investigasi › Exception dashboard, klik salah satu baris.
2. Tetapkan root cause dari delapan kategori, ubah pemiliknya, isi catatan.
3. Coba tutup dengan catatan pendek — sistem menolak. Minimal 20 karakter.
4. Buka Administrasi › Jejak audit — tindakan Bapak/Ibu sudah tercatat di baris teratas.

Pertanyaan kami:

1. Apakah sembilan root cause itu sudah mencakup yang sebenarnya terjadi? Ada kategori yang tidak pernah dipakai? Ada yang kurang?
2. Apakah tingkat bukti — terbukti, terindikasi, dugaan — membantu, atau justru membuat layar lebih sulit dibaca?
3. Apakah tujuh status transaksi — Match, Mismatch, Duplicate, Missing, Unclaimed, Rejected, Pending — istilahnya sudah sesuai dengan yang dipakai sehari-hari?

7. Pertanyaan yang tersisa

Empat pertanyaan lama sudah terjawab oleh paket sampel Settlement Engine yang PT KAI serahkan 22 September 2026. Dicatat di sini supaya jelas apa yang sudah selesai.

Yang sekarang perlu dijawab

Berkas contoh — sebagian besar sudah diterima ✅

Paket sampel 22 September sudah memuat: format lima bank, berkas request & balasan nyata, struktur tabel STM/TRX, pola nama berkas, kode status, path FTP, dan daftar function database.

Yang masih dibutuhkan:

• Dua berkas STM untuk hari yang sama — satu bank, satu terminal, seluruh berkasnya (bukan cuplikan). Ini yang menjawab pertanyaan nomor 3
• Struktur tabel DB SOT (DDL saja)
• Business rule per bank — cut-off, siklus, aturan duplikat

8. Yang sengaja belum dijawab

Settlement Engine baru dan arsitektur bridge (§44, §45). Keduanya menentukan sejauh mana sistem ini memegang jalur pengiriman ke bank — dan itu keputusan arsitektur yang harus diambil sadar bersama tim LRT, bukan diselipkan lewat mockup.

Mockup ini memperlihatkan apa yang bisa dicapai tanpa menggantinya: memantau, mendeteksi, mencegah, dan melaporkan — dengan sistem yang sedang berjalan tetap utuh, dan nol operasi tulis ke DB SOT maupun DB Settlement.

Akses DB SOT belum tersedia. Sampai diberikan, jumlah baris tahap SOT pada mockup ini disimpulkan dari berkas FS. Layarnya menyatakan hal itu terbuka.

Rekening koran keluar dari lingkup karena tidak disebut baik di dokumen requirement maupun di paket sampel Settlement Engine. Akibatnya pertanyaan "apakah uangnya benar-benar masuk ke rekening" kini tidak punya pemilik di sistem ini. Kami menyatakannya, bukan mendiamkannya.

9. Cara memberi masukan

Masukan yang paling berguna menyebut layar mana dan apa yang terjadi:

"Di Deteksi duplikat, kolom 'Lahir di lapis' tidak kami pahami — kami biasa menyebutnya tahapan."

"Di Exception dashboard, tenggat 7 hari terlalu pendek untuk root cause Settlement Engine Duplicate — perbaikannya di tim IT dan biasanya perlu dua minggu."

"Kode response BCA untuk duplikat bukan 0201, tapi 0203."

Yang juga sangat membantu:

• Nama menu, kolom, atau status yang membingungkan — sebutkan istilah yang biasa dipakai
• Kolom yang tidak pernah dilihat, dan kolom yang justru kurang
• Angka atau nama berkas yang salah menurut praktik sebenarnya
• Alur kerja yang urutannya tidak sesuai kebiasaan

Tangkapan layar sangat membantu.

10. Daftar periksa singkat

• Masuk dengan bagas.operation, jalankan Alur 1
• Buka Bank › Bank Central Asia, telusuri keempat sub-menunya — apakah bentuk ruang kerja per bank ini sesuai dengan cara Bapak/Ibu bekerja?
• Jalankan Alur 2 — Kasus STM ganda — 16:00 vs 04:00. Ini yang paling kami butuhkan koreksinya
• Masuk dengan krisna.invest, jalankan Alur 3
• Jalankan Alur 4 — Claim preview dan pencegahan duplikat
• Masuk dengan rina.settlement, jalankan Alur 5, lalu periksa Jejak audit
• Buka Parameter › Kode root cause — apakah delapan kategorinya sudah cukup?
• Buka Parameter › Kode response per bank — apakah kodenya benar?
• Buka Administrasi › Peran & hak akses — apakah pembagian wewenangnya sesuai?
• Jawab empat pertanyaan di bagian 7
• Siapkan enam berkas contoh di bagian 7

Mockup ini berisi data contoh fiktif dan bukan sistem produksi PT KAI. Disiapkan untuk Divisi LRT Jabodebek dan Tim Settlement KAI Kantor Pusat.

Yang berubah pada 9 September 2026

Setelah PT KAI menjelaskan alur sistem yang berjalan, dua hal yang kami pakai selama ini ternyata keliru — dan keduanya sudah diperbaiki di seluruh layar:

Dan satu temuan baru yang kini punya layarnya sendiri: berkas STM untuk transaksi satu hari dikirim dua kali — 16:00 hari itu dan 04:00 hari berikutnya. Bila kiriman kedua memilih seluruh transaksi hari itu, ia membawa ulang isi kiriman pertama.

Yang kami minta ditinjau di sini: buka Duplikat › Kasus STM ganda dan Data Sumber › Berkas STM stasiun. Apakah jadwal 16:00 / 04:00 yang kami gambarkan sudah sesuai dengan yang sebenarnya berjalan? Dan apakah berkas STM memang dibentuk per stasiun seperti yang kami modelkan?

Kami menandai pola berulang itu sebagai hipotesis, bukan temuan — sampai irisannya benar-benar diuji dari berkas di FTP KCI.

Yang berubah pada 22 September 2026 — paket sampel Settlement Engine

PT KAI menyerahkan 42 berkas: tiga dokumen hasil pembacaan database production, format lima bank, serta berkas permintaan dan balasan yang benar-benar dikirim bank. Ini bukti pertama yang kami punya dari sistem yang sedang berjalan.

Temuan terbesar: balasan bank tidak pernah dibaca

Katalog function Settlement Engine menulis satu kalimat yang menentukan segalanya:

“tabel resp.tm_* saat ini kosong di production yang dicek, sehingga function recon belum berdampak.”

Bank sudah menjawab. Berkasnya ada di FTP. Tabel penampungnya sudah dibuat. Program rekonsiliasinya sudah ditulis. Yang belum terjadi: membaca berkas itu dan memasukkannya. Akibatnya penanda sah, jumlah sah, jumlah ditolak, dan tanggal bayar tidak pernah terisi.

Menu baru: Balasan Bank › Balasan belum terbaca memperlihatkan akibatnya dalam angka.

Dugaan kami sendiri dibantah — dan kami turunkan

Pada 9 September kami menyebut “kiriman 16:00 dan 04:00 bertumpuk” sebagai kandidat terkuat. Dua berkas yang jamnya bisa kami urai justru bersih: BRI memuat 12 transaksi seluruhnya pukul 16:12–21:20, Mandiri 20 transaksi seluruhnya 06:44–08:34.

Dugaan itu diturunkan. Yang justru punya bukti langsung: baris kembar di dalam database, terlihat pada sampel yang tim LRT serahkan sendiri.

Sejak itu setiap penyebab di layar membawa tingkat buktinya. Sistem yang menyamakan dugaan dengan temuan kehilangan seluruh bobotnya begitu satu dugaan meleset.

Menu baru: Uji urai berkas bank

Seluruh isinya data nyata, bukan simulasi — hasil pengurai kami terhadap berkas yang PT KAI serahkan. 12 berkas, 115 baris, 0 gagal. Empat susunan berkas yang sama sekali berbeda, keluar dalam satu bentuk yang sama.

Yang kami minta ditinjau: buka menu itu dan cocokkan barisnya dengan berkas aslinya. Kalau ada yang salah baca, justru itu yang paling berguna kami ketahui sekarang.