Memastikan pembayaran pelanggan Yayasan Penyelenggaraan Ilahi Indonesia (YPII) yang diterima
lewat bank — misalnya mutasi rekening virtual account — diimpor, dicocokkan dengan pelanggan
yang benar, disetujui, dan tercatat sebagai pembayaran pelanggan di Odoo YPII secara tertelusuri,
tanpa duplikasi maupun baris data yang terlewat.
Prosedur ini dimulai saat tersedia berkas pembayaran dari bank yang perlu diimpor sebagai
pembayaran pelanggan, dan berakhir saat dokumen Customer Payment Import berstatus Done dengan
nomor dokumen sudah terbit. Termasuk di dalamnya dua jalur akhir alternatif: dokumen ditolak
penyetuju, dan dokumen dibatalkan sebelum selesai.
Prosedur ini tidak mencakup pembatalan dokumen Customer Payment Import yang sudah
berstatus Done. Jalur itu tersedia di Odoo YPII dan diatur tersendiri di
Pembatalan Customer Payment Import yang Sudah Selesai.
Pemakaian kembali dokumen yang berstatus Rejected atau Cancelled diatur
Penggunaan Ulang Customer Payment Import yang Ditolak atau Dibatalkan.
Prosedur ini tidak mencakup pembuatan atau pemeliharaan Customer Payment Import Type
(data master yang menentukan format berkas, pemetaan kolom, serta jurnal/akun yang boleh
dipilih) — model itu didokumentasikan sebagai Instruksi Kerja tersendiri, bukan SOP.
account.payment)./ sampai dokumen mencapai status Done.| Peran dalam prosedur | Kewenangan teknis di Odoo YPII | Kewenangan yang dipikul |
|---|---|---|
TBD-ORG: jabatan pengisi peran pengaju dokumen |
grup Odoo Customer Payment Import / User (19 akun aktif per 25 Agustus 2026); penanda Can Confirm pada status Draft | membuat dokumen, memuat data pembayaran dari berkas, dan mengajukannya untuk persetujuan |
TBD-ORG: jabatan pengisi peran penyetuju/pembatal/pemulih |
grup Odoo Customer Payment Import / Validator (19 akun aktif per 25 Agustus 2026); penanda Can Approve dan Can Reject (sebagai kumpulan penyetuju pada Approval Template Standard), Can Cancel, Can Restart, Can Restart Approval, dan Can Input Manual Document Number | menyetujui atau menolak dokumen, membatalkan sebelum selesai, memulai ulang, dan mereset nomor dokumen |
| Odoo YPII (Sistem) | — | menyusun daftar penyetuju, membentuk dan menyelesaikan antrean pembentukan pembayaran, dan menerbitkan nomor dokumen |
TBD-ORG: pemetaan grup Odoo Customer Payment Import / User dan / Validator ke jabatan resmi YPII belum ditetapkan.
Grup User dan Validator saat ini beranggotakan 19 akun yang sama persis (identik dengan
grup Viewer). Tidak ada pemisahan tugas pada model ini: setiap pengguna yang boleh membuat dan
mengajukan dokumen juga berwenang menyetujui, membatalkan, dan memulai ulangnya sendiri. Ini
adalah fakta konfigurasi instance, bukan cacat prosedur ini — keputusan memisahkannya ada di
tangan YPII.TBD-ORG: apakah YPII memisahkan keanggotaan grup User dan Validator, dan bila ya, siapa yang tetap berada di grup Validator?
Pemicu (Start Event): tersedia berkas pembayaran dari bank (mis. mutasi rekening virtual
account) yang perlu diimpor dan dicocokkan sebagai pembayaran pelanggan YPII.
Pelaku (Lanes): TBD-ORG: jabatan pengaju · TBD-ORG: jabatan penyetuju/pembatal/pemulih ·
Odoo YPII (Sistem)
Tipe Task (BPMN): User Task
Pelaku (Lane): TBD-ORG: jabatan pengaju dokumen — kewenangan teknisnya ada pada anggota grup Odoo Customer Payment Import / User (19 akun), penanda Can Confirm.
Input (Data Object): berkas pembayaran dari bank; Customer Payment Import Type yang sesuai
Aktivitas: Membuat dokumen, mengisi Type, Journal, dan Date, mengunggah berkas pada Import File, lalu menjalankan Load Data untuk membentuk baris Import Data dari berkas tersebut.
Output (Data Object): dokumen berstatus Draft dengan # Document bernilai /; tab Import Data terisi
Rincian/turunan: Membuat Customer Payment Import
Alur berikutnya (Sequence Flow): → langkah 2
SLA/Durasi: TBD-ORG: batas waktu dokumen dibuat sejak berkas pembayaran dari bank diterima.
Tipe Task (BPMN): User Task
Pelaku (Lane): TBD-ORG: jabatan pengaju dokumen
Input (Data Object): dokumen berstatus Draft dengan Import Data sudah terisi
Aktivitas: Mengajukan dokumen untuk memperoleh persetujuan.
Output (Data Object): dokumen berstatus Waiting for Approval; permintaan persetujuan terbentuk otomatis
Serah-terima (Message Flow): tanggung jawab berpindah kepada penyetuju berupa dokumen yang menunggu persetujuan
Rincian/turunan: Mengonfirmasi Customer Payment Import
Alur berikutnya (Sequence Flow): → langkah 3
Tipe Task (BPMN): Business Rule Task
Pelaku (Lane): Odoo YPII (Sistem)
Input (Data Object): dokumen berstatus Waiting for Approval
Aktivitas: Sistem mengevaluasi Approval Template yang berlaku dan menyusun daftar penyetuju pada field Active Users.
Output (Data Object): daftar penyetuju pada field Active Users
Rincian/turunan: Persetujuan Customer Payment Import
Alur berikutnya (Sequence Flow): → langkah 4
Tipe Task (BPMN): Send Task
Pelaku (Lane): TBD-ORG: jabatan pengaju dokumen
Input (Data Object): daftar penyetuju pada field Active Users
Aktivitas: Memberitahukan kepada penyetuju bahwa ada dokumen Customer Payment Import yang menunggu persetujuannya, di luar sistem. Odoo YPII tidak memiliki otomasi pengiriman notifikasi untuk model ini.
Output (Data Object): pemberitahuan tersampaikan kepada penyetuju
Serah-terima (Message Flow): pemberitahuan kepada TBD-ORG: jabatan penyetuju/pembatal/pemulih
Rincian/turunan: Menyetujui Customer Payment Import
Alur berikutnya (Sequence Flow): → langkah 5
Tipe Task (BPMN): User Task
Pelaku (Lane): TBD-ORG: jabatan penyetuju/pembatal/pemulih — kewenangan teknisnya ada pada anggota grup Odoo Customer Payment Import / Validator (19 akun), sekaligus kumpulan penyetuju pada Approval Template Standard.
Input (Data Object): dokumen berstatus Waiting for Approval; hasil pencocokan pelanggan dan pemilihan jurnal/akun pada baris Import Data
Aktivitas: Memeriksa kewajaran hasil pencocokan pelanggan dan pemilihan jurnal/akun pada baris Import Data, lalu menyetujui atau menolak dokumen.
Output (Data Object): baris persetujuan pada tab Approvals berisi keputusan penyetuju
Rincian/turunan: Menyetujui Customer Payment Import dan Menolak Customer Payment Import
Alur berikutnya (Sequence Flow): → langkah 6
SLA/Durasi: TBD-ORG: batas waktu penyetuju memutuskan sejak dokumen berstatus Waiting for Approval.
Tipe Gateway: Exclusive (XOR)
Pelaku (Lane): TBD-ORG: jabatan penyetuju/pembatal/pemulih
Aturan: Disetujui → langkah 7. Ditolak → langkah 9 (jalur gagal).
Penggabungan (Merge): — tidak ada; jalur ditolak berakhir pada Akhir Proses "ditolak"
Tipe Task (BPMN): Script Task
Pelaku (Lane): Odoo YPII (Sistem)
Input (Data Object): Seluruh tingkat persetujuan pada dokumen Customer Payment Import sudah disetujui.
Aktivitas: Sistem menjalankan otomasi pasca-persetujuan untuk dokumen ini.
Output (Data Object): dokumen berstatus Queue To Done; antrean pembentukan pembayaran per baris Import Data mulai diproses
Rincian/turunan: Melakukan Otomasi Pasca-Persetujuan Customer Payment Import
Alur berikutnya (Sequence Flow): → langkah 8
Tipe Task (BPMN): User Task
Pelaku (Lane): TBD-ORG: jabatan pengaju dokumen — tidak ada baris kewenangan (*_ok) khusus untuk aksi ini; siapa pun anggota grup Odoo Customer Payment Import / User yang memiliki akses tulis atas dokumen dapat menjalankannya.
Input (Data Object): dokumen berstatus Queue To Done dengan sebagian baris Import Data berstatus Error
Aktivitas: Memperbaiki data mentah baris yang keliru, mengulang (retry) baris yang sudah diperbaiki penyebabnya di luar sistem, atau mengabaikan baris yang memang tidak perlu diproses — satu per satu atau sekaligus untuk seluruh baris Error.
Output (Data Object): seluruh baris Import Data berstatus Done atau Ignored, tidak ada lagi yang berstatus Error; begitu antrean tuntas, otomasi pasca-persetujuan (langkah 7) melanjutkan dokumen ke Done dan menerbitkan # Document
Rincian/turunan: Mengulang Seluruh Baris Bermasalah, Mengabaikan Seluruh Baris Bermasalah, Mengulang Satu Baris Impor, Mengabaikan Satu Baris Impor, dan Mengubah Data Mentah Satu Baris Impor
Alur berikutnya (Sequence Flow): → Akhir Proses "selesai" (jalur normal)
Bila seluruh baris Import Data sudah Done begitu antrean selesai diproses, langkah ini
dilewati dan dokumen langsung mencapai Done tanpa campur tangan manusia.
Tipe Task (BPMN): User Task
Pelaku (Lane): TBD-ORG: jabatan penyetuju/pembatal/pemulih
Input (Data Object): dokumen berstatus Waiting for Approval yang tidak memenuhi syarat
Aktivitas: Menolak dokumen.
Output (Data Object): dokumen berstatus Rejected
Rincian/turunan: Menolak Customer Payment Import
Alur berikutnya (Sequence Flow): → Akhir Proses "ditolak" — jalur gagal, tidak kembali ke alur utama
Tipe Event: Boundary Event (interrupting)
Melekat pada langkah: 1–6
Pelaku (Lane): TBD-ORG: jabatan penyetuju/pembatal/pemulih — kewenangan teknisnya ada pada anggota grup Odoo Customer Payment Import / Validator (19 akun), penanda Can Cancel.
Pemicu: pengguna memutuskan membatalkan dokumen selagi masih berstatus Draft atau Waiting for Approval
Aktivitas: Membatalkan dokumen dan memilih alasan pembatalan pada wizard Select Cancel Reason.
Output (Data Object): dokumen berstatus Queue To Cancel; alasan pembatalan tersimpan dan memicu otomasi pasca-pembatalan yang melanjutkan dokumen ke Cancelled
Rincian/turunan: Membatalkan Customer Payment Import dan Melakukan Otomasi Pasca-Pembatalan Customer Payment Import
Alur berikutnya (Sequence Flow): → Akhir Proses "dibatalkan sebelum selesai" — jalur gagal, tidak kembali ke alur utama
Rentang 1–6 diturunkan dari kewenangan Can Cancel, yang pada penanda kewenangan ini berlaku
pada status Draft dan Waiting for Approval — yaitu status dokumen sepanjang langkah 1
sampai 6. Penanda Can Cancel juga mencakup status Done, tetapi pembatalan pada status itu
adalah proses tersendiri dengan keputusan organisasi yang lebih berat, dan diatur
Pembatalan Customer Payment Import yang Sudah Selesai.
Can Cancel tidak berlaku pada status Queue To Done (langkah 7–8) — dokumen yang sedang di
sana tidak dapat dibatalkan lewat boundary ini; lihat Titik Kontrol butir 4.
Akhir Proses (End Event): dokumen selesai — berstatus Done dengan nomor dokumen terbit (jalur normal) · ditolak — berstatus Rejected · dibatalkan sebelum selesai — berstatus Cancelled
CPI/<tahun>/<6 digit> dengan tahun diambil dari field Date dokumen. Rinciannya diTBD-ORG: kepada siapa keterlambatan persetujuan dieskalasikan bila penyetuju berhalangan?TBD-ORG: siapa yang dihubungi (mis. administrator Odoo YPII atau penanggung jawab job runner) dan berapa lama menunggu sebelum kasus ini dieskalasikan?TBD-ORG: berapa lama batas waktu penuntasan baris Error sejak dokumen memasuki Queue To Done sebelum kasusnya dieskalasikan, dan kepada siapa?TBD-ORG: apakah YPII memisahkan keanggotaan kedua grup tersebut?TBD-ORG: siapa yang berwenang mengubah konfigurasi Customer Payment Import Type (format berkas, pemetaan kolom, jurnal/akun) bila kesalahan berasal dari konfigurasi Type, bukan dari data satu dokumen?SOP-b3129431SOP-b85224b7DT-2e6e5174DT-2b9b95f7DT-c9629f50DT-5197c1a0DT-4b8f88cfDT-eacece64