Memastikan dokumen Customer Payment Import Yayasan Penyelenggaraan Ilahi Indonesia (YPII) yang
berstatus Rejected atau Cancelled hanya dihidupkan kembali bila memang layak, dan bahwa
data yang menyebabkan kegagalannya sudah diperbaiki sebelum dokumen itu diajukan ulang —
sehingga pembayaran pelanggan pada berkas yang sama tidak terlewat, dan dokumen yang sama tidak
gagal berulang karena sebab yang sama.
Prosedur ini dimulai saat sebuah dokumen Customer Payment Import berstatus Rejected atau
Cancelled akan dipakai kembali, dan berakhir saat dokumen tersebut kembali berjalan lewat
prosedur pelaksanaan — atau saat diputuskan dibiarkan pada status gagalnya.
Kedua status gagal dicakup prosedur ini, karena penanda kewenangan Can Restart pada Policy
Template Standard berlaku untuk Rejected maupun Cancelled sekaligus.
Prosedur ini tidak mengulang langkah pelaksanaan. Begitu dokumen kembali berstatus Draft,
sisanya identik dengan
Pelaksanaan Customer Payment Import,
yang dipanggil sebagai satu langkah pada bagian akhir.
Prosedur ini tidak mencakup pembatalan dokumen yang sudah Done. Jalur itu diatur
Pembatalan Customer Payment Import yang Sudah Selesai,
dan prosedur ini justru sering menjadi kelanjutannya: dokumen yang dibatalkan dari status Done
umumnya perlu dihidupkan kembali agar pembayaran pelanggan pada berkas sumbernya tetap diimpor
dengan data yang benar.
account.payment) per baris Import Data.| 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 | mengusulkan pemakaian ulang, memperbaiki data dokumen, dan mengajukannya kembali |
TBD-ORG: jabatan pengisi peran penyetuju/pembatal/pemulih |
grup Odoo Customer Payment Import / Validator (19 akun aktif per 25 Agustus 2026); penanda Can Restart pada status Rejected dan Cancelled, serta Can Input Manual Document Number pada status Draft | memutuskan dan menjalankan pemulaian ulang, serta mereset nomor dokumen |
TBD-ORG: pemetaan grup Odoo Customer Payment Import / User dan / Validator ke jabatan resmi YPII belum ditetapkan.
Pemicu (Start Event): sebuah dokumen Customer Payment Import berstatus Cancelled atau
Rejected akan dipakai kembali untuk mengimpor pembayaran pelanggan pada berkas yang sama.
Pelaku (Lanes): TBD-ORG: jabatan pengaju · TBD-ORG: jabatan penyetuju/pembatal/pemulih
Tipe Gateway: Exclusive (XOR)
Pelaku (Lane): TBD-ORG: jabatan penyetuju/pembatal/pemulih
Input (Data Object): dokumen berstatus Cancelled atau Rejected; sebab kegagalannya
Aturan: Dipakai ulang → langkah 2. Dibuat dokumen baru → Akhir Proses "dokumen dibiarkan gagal", lalu proses berjalan sebagai dokumen baru lewat Pelaksanaan Customer Payment Import.
Penggabungan (Merge): — tidak ada
Catatan: TBD-ORG: kriteria kapan dokumen gagal dipakai ulang dan kapan harus dibuat dokumen baru — misalnya berdasarkan lamanya dokumen menganggur, bergantinya periode akuntansi, atau berat-ringannya perbaikan data.
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), penanda Can Restart.
Input (Data Object): dokumen berstatus Cancelled atau Rejected; keputusan pemakaian ulang
Aktivitas: Menghidupkan kembali dokumen sehingga datanya dapat diubah lagi.
Output (Data Object): dokumen berstatus Draft; Cancellation reason terhapus bila dokumen berasal dari Cancelled; # Document tetap memakai nomor lama
Rincian/turunan: Memulai Ulang Customer Payment Import
Alur berikutnya (Sequence Flow): → langkah 3
Alasan pembatalan hilang begitu dokumen dihidupkan kembali (untuk dokumen yang berasal
dari Cancelled). Untuk dokumen yang berasal dari Rejected, instance ini tidak
menyediakan field alasan penolakan yang setara pada dokumen itu sendiri — jejaknya hanya ada
pada riwayat persetujuan (approval.approval) atau catatan chatter. Catat sebabnya di tempat
lain sebelum menjalankan langkah 2 bila jejaknya masih dibutuhkan.TBD-ORG: di mana jejak sebab kegagalan diarsipkan — catatan pada field Note, pesan chatter, atau lampiran?
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), penanda Can Input Manual Document Number.
Input (Data Object): dokumen berstatus Draft dengan nomor lama
Aktivitas: Mereset nomor dokumen bila kebijakan YPII menghendaki dokumen pakai-ulang memperoleh nomor baru. Bila nomor lama dipertahankan, langkah ini dilewati.
Output (Data Object): # Document bernilai / dan akan terbit ulang saat dokumen mencapai Done, atau tetap memakai nomor lama
Rincian/turunan: Mereset Nomor Dokumen Customer Payment Import
Alur berikutnya (Sequence Flow): → langkah 4
Catatan: Konfigurasi Odoo YPII sudah menentukan mekanismenya: menghidupkan kembali
dokumen tidak mereset nomornya, dan satu-satunya jalan mereset adalah penanda Can Input
Manual Document Number yang hanya dimiliki grup Customer Payment Import / Validator pada
status Draft. Karena itu nilai bawaan langkah ini adalah nomor lama dipertahankan, dan
reset hanya dilakukan bila kebijakan menghendaki. TBD-ORG: apakah YPII menghendaki dokumen yang dipakai ulang memperoleh nomor baru, atau nomor lama dipertahankan agar riwayatnya menyatu?
Tipe Task (BPMN): User Task
Pelaku (Lane): TBD-ORG: jabatan pengaju dokumen
Input (Data Object): dokumen berstatus Draft; sebab kegagalan dokumen
Aktivitas: Memeriksa dan memperbaiki Type, Journal, Account, atau Import File sesuai sebab kegagalannya, lalu memuat ulang data pembayaran bila berkas sumbernya berubah.
Output (Data Object): dokumen berstatus Draft dengan data yang sudah diperbaiki
Rincian/turunan: Mengubah Customer Payment Import
Alur berikutnya (Sequence Flow): → langkah 5
SLA/Durasi: TBD-ORG: berapa hari kerja perbaikan data diselesaikan sejak dokumen dihidupkan kembali?
Tipe Task (BPMN): Call Activity
Pelaku (Lane): TBD-ORG: jabatan pengaju · TBD-ORG: jabatan penyetuju/pembatal/pemulih
Input (Data Object): dokumen berstatus Draft dengan data yang sudah diperbaiki
Aktivitas: Menjalankan kembali prosedur pelaksanaan atas dokumen ini, mulai dari pengajuan sampai dokumen berstatus Done.
Output (Data Object): dokumen berstatus Done, atau kembali gagal
Rincian/turunan: Pelaksanaan Customer Payment Import
Alur berikutnya (Sequence Flow): → Akhir Proses "dokumen selesai"
Akhir Proses (End Event): dokumen selesai — berstatus Done setelah dipakai ulang · dokumen dibiarkan gagal — tetap berstatus Cancelled atau Rejected
TBD-ORG: kapan dokumen yang gagal dipakai ulang, kapan harus dibuat dokumen baru?TBD-ORG: apakah keduanya diperlakukan sama pada prosedur ini, atau ada syarat/kewenangan pakai-ulang yang berbeda di antara keduanya?TBD-ORG: siapa yang berhak menghidupkan kembali dokumen yang berakhir gagal — apakah sama dengan grup Validator saat ini?TBD-ORG: sampai kapan dokumen batal atau ditolak masih boleh dipakai ulang?TBD-ORG: setelah berapa kali kegagalan sebuah dokumen dihentikan pemakaian ulangnya dan dieskalasikan?TBD-ORG: apakah pihak yang sebelumnya diberi tahu tentang pembatalan/penolakan juga perlu diberi tahu bahwa dokumen dipakai kembali?SOP-ea1137c9SOP-b3129431DT-2e6e5174DT-eacece64