Sejak versi 2.0, siklus penentuan tarif Uang Pangkal (UP) dan Uang Sekolah (US) YPII dijalankan
lewat siklus RAB tahunan berjenjang di aplikasi Budget YPII — menggantikan SOP siklus RJP
5-tahunan dan SOP Penentuan SPP Pokok versi sebelumnya. Instruksi Kerja teknis aplikasi ada di
Instruksi Kerja — Budget YPII.
Tiga model dokumen beasiswa Odoo YPII, masing-masing dengan prosedur pelaksanaan dan prosedur
penggunaan ulang dokumen yang gagal.
Kewenangan membatalkan dokumen yang sudah berstatus Done berbeda antar model, dan
perbedaan itu menentukan ada-tidaknya prosedur pembatalan. Pada Scholarship Award dan
Scholarship Deduction, penanda Can Cancel hanya berlaku sampai status sebelum selesai,
sehingga dokumen yang sudah Done terkunci dan tidak ada prosedur pembatalannya. Pada
Scholarship Deduction Recognition, Can Cancel mencakup status Done — sehingga model
itu punya prosedur pembatalan tersendiri.
Seksi ini menampung dua model dokumen Odoo YPII. School Fee Waiver mencatat komitmen
pemberian keringanan biaya sekolah bagi seorang siswa atas sebuah sumber tagihan, lalu menurunkan
rencana realisasinya per termin pembayaran. School Fee Waiver Deduction mewujudkan rencana itu
menjadi potongan nyata: ia memilih baris rencana mana yang direalisasi sekarang dan menempatkan
nilainya pada tagihan siswa yang masih terbuka. Masing-masing model memiliki dua prosedur —
pelaksanaan dan penggunaan ulang dokumen yang berakhir gagal.
Dari kedua model itu, hanya School Fee Waiver Deduction yang berdampak akuntansi: entri jurnal
terbentuk dan direkonsiliasi ke tagihan siswa begitu dokumen itu disetujui. Dokumen School Fee
Waiver sendiri tidak membentuk jurnal sama sekali; ia berhenti pada rencana.
Pada kedua model, kewenangan pembatalan tidak mencakup status Done — penanda Can Cancel
hanya berlaku pada Draft, Waiting for Approval, dan On Progress. Karena itu tidak ada
prosedur pembatalan dokumen yang sudah selesai bagi keduanya, dan pembatalan sebelum selesai
ditangani sebagai jalur gagal di dalam prosedur pelaksanaan masing-masing.
Seksi ini menampung tiga model dokumen Odoo YPII yang berurutan. Promotion Code menerbitkan
sebuah kode voucher atau kode referral beserta masa berlaku dan batas pemakaiannya.
Promotion Code Usage mencatat penebusan kode itu pada baris termin pembayaran School Admission
atau School Enrollment, lalu membukukan potongannya dan merekonsiliasikannya dengan tagihan siswa.
Promotion Code Usage Recognition melepaskan potongan yang ditangguhkan sedikit demi sedikit,
masing-masing dengan entri jurnalnya sendiri. Aturan besaran potongannya sendiri tidak ditulis di
ketiga dokumen itu, melainkan diwarisi dari data master Promotion Type.
Dari ketiganya, Promotion Code tidak berdampak akuntansi — ia hanya menerbitkan kode.
Promotion Code Usage dan Promotion Code Usage Recognition keduanya membentuk entri jurnal,
dan keduanya membalikkannya kembali bila dokumennya dibatalkan.
Kewenangan pembatalan berbeda antar model, dan perbedaan itu menentukan jumlah prosedurnya.
Pada Promotion Code, penanda Can Cancel hanya berlaku pada Draft,
Waiting for Approval, dan On Progress — dokumen yang sudah Done tidak dapat dibatalkan
siapa pun, sehingga model ini tidak punya prosedur pembatalan dokumen yang sudah selesai. Pada
Promotion Code Usage, pembatalan mencakup Done, tetapi tertutup begitu dokumen itu punya
dokumen pengakuan — pengakuannya harus dibereskan lebih dulu. Pada Promotion Code Usage
Recognition, pembatalan dokumen Done terbuka tanpa syarat tambahan, dan akibatnya merambat:
dokumen pemakaian yang tadinya selesai kembali terbuka dengan sendirinya.
Pembatalan sebelum dokumen selesai bukan prosedur tersendiri pada ketiga model — ia ditangani
sebagai jalur gagal di dalam prosedur pelaksanaan masing-masing.
Seksi ini menampung satu model dokumen, Customer Payment Import, yang membentuk pembayaran
pelanggan secara massal dari satu berkas rekapitulasi bank: berkas dibaca menjadi satu baris per
transaksi, dokumennya disetujui, lalu pembayaran dibentuk satu per satu lewat antrean pekerjaan.
Model ini memiliki ketiga varian SOP — pelaksanaan, pembatalan dokumen yang sudah selesai, dan
penggunaan ulang dokumen yang berakhir gagal.
Dokumen Customer Payment Import sendiri tidak membentuk jurnal. Dampak akuntansinya dipikul
pembayaran pelanggan yang terbentuk darinya; pada Type yang menyalakan penandaan Auto
Post, pembayaran itu langsung diposting sehingga jurnalnya terbentuk tanpa langkah tambahan.
Kewenangan pembatalan pada model ini mencakup status Done: dokumen yang sudah selesai masih
dapat dibatalkan, dan tidak ada syarat kelengkapan maupun penghalang perpindahan status yang
mengunci jalur itu. Karena itulah model ini punya SOP pembatalan tersendiri, di samping SOP
pelaksanaan dan SOP penggunaan ulang.
SOP payung yang menetapkan urutan aman bulanan penagihan Uang Sekolah lintas fitur — Virtual
Account, Create Due Invoice, Customer Invoice Export, unggah ke bank/PintuKelas, dan Customer
Payment Import — tanpa mengulang langkah teknis tiap wizard.
Seksi ini menampung dokumen Loan Out di Odoo YPII — pinjaman yang diberikan Yayasan
Penyelenggaraan Ilahi Indonesia (YPII) kepada pihak lain, yang di Odoo YPII berupa pinjaman
karyawan. Satu dokumen memuat pokok pinjaman, bunga, jadwal angsuran, dan jurnal realisasi
pencairannya.
Dua hal membentuk jumlah prosedurnya. Pertama, persetujuan terakhir melakukan tiga hal
sekaligus: memindahkan dokumen ke Ready to Process, menerbitkan nomor dokumen, dan
membentuk jurnal realisasi pencairan — sesudah itu perjalanan dokumen berjalan sendiri
mengikuti rekonsiliasi jurnal dan pelunasan angsuran, tanpa tombol yang perlu ditekan siapa
pun. Kedua, dokumen yang sudah berjalan tidak dapat dibatalkan: kewenangan pembatalan
hanya berlaku sampai status Ready to Process, dan Odoo menolaknya begitu jurnal
realisasinya terekonsiliasi atau ada angsuran yang terbayar. Karena itu Loan Out tidak punya
prosedur pembatalan dokumen yang sudah selesai — pembatalan sebelum dokumen berjalan
ditangani sebagai jalur gagal di dalam prosedur pelaksanaannya.