Maker Checker Approval Adalah
Tisham Candella
Maker-checker (or Maker and Checker or 4-Eyes) is one of the central principles of authorization in the information systems of financial organizations. The principle of maker and checker means that for each transaction, there must be at least two individuals necessary for its completion. While one individual may create a transaction, the other individual should be involved in confirmation/authorization of the same. The segregation of duties plays an important role. In this way, strict control is kept over system software and data, keeping in mind functional division of labor between all classes of employees.
Sebagai seorang Banker atau orang yang bekerja di Bank,tentu kita tidak asing dg istilahM.C.S.Benar..MCS adalah singkatan dari Maker,Checker, dan Signer.sebelum kita membahas lebih jauh tentang MCS.ada beberapa hal yang ingin saya lontarkan :
2.apakah kwajiban itu terbatas pada fungsi yang melekat saja.contoh : Maker hanya bertanggung jawab pada make/membuat saja.kemudian tanggung jawab beralih ke checker,jika checker menyatakan lolos maka maker lepas dr tanggung jawab dan beralih ke checker.kemudian checker setelah melewati proses check dan menyerahkan ke signer.maka tanggung jawab berada di signer.karna dia yang menentukan apakah sebuah transaksi akan disetujuimya atau tidak.jika iya,maka signerlah yang berkewajiban penuh atas proses transaksi yang disetujuinya.ataukah
Seperti yang sudah kita ketahui.bahwa adanya Maker, checker dan signer tak lepas dari usaha suatu perusahaan untuk mewujudkan Good corporate Governance melalui prinsip kehati-hatian.untuk itu di BRI kita mengenal adanya dual control
Dual control adalah suatu bentuk prosedur kerja yang menciptakan suatu pengecekan ulang pekerjaan yang telah dilakukan oleh petugas sebelumnya.untuk itu di BRI tansaksi apapun harus dilakukan oleh minimal tiga orang pegawai yang masing-masing mempunyai peran dan fungsi tersendiri.dan kita menyebutnya dg sistem MCS.mari sedikit kita urai tentang MCS
Nah, yang menjadi persoalan adalah selama ini dari SE ataupun Nota Dinas di BRI hanya menjelaskan tentang prinsip dan tanggung jawab MCS.namun belum pernah menyoal tentang tanggung jawab atau kewajiban jika suatu transaksi menyebabkan kerugian finansial maupun non finansial.
lewat tulisan ini sebenarnya saya ingin sekali mendapatkan gambaran atau pemgertian yang jelas mengenai tanggung jawab MCS jika terjadi suatu kesalahan.misal : jika seorang maker dalam membuat surat ternyata didalam surat itu ada unsur SARA yang menyebabkan seseorang merasa terhina kemudian mengajukan gugatan dengan nilai gugatan sebesar 100 juta rupiah.
Siapakah yang akan menggantinya ?
Untuk menghindari salah-salahan antar pegawai.saya rasa hal ini cukup penting kita bahas.Karna hal ini bukanlah hal yang jauh dari pekerjaan kita.Siapapun berpotensi menjalani kasus ini.untuk itu saya berusaha mengangkatnya untuk mendapatkan pencerahan atau pandangan dari bapak/ibu sekalian paling tidak
Tulisan ini dibuat bukanlah untuk mencari kesalahan atau pembenaran.atau mengkuatkan atas suatu hal tertentu.setidaknya lewat tulisan ini saya berusaha untuk belajar dan semoga berguna dan menambah kehati-hatian kita dalam bekerja.
While defining transaction code, the maker and checker responsibilities can be defined using the access type field available under access grid sub tab. Maker-Checker concept applies only to manual transactions, and not the automated ones.
A checker can use the Authorization screen to view transactions with the status waiting for approval, then approve or reject the transactions. As a checker you can view all the transactions listed within/under your hierarchy, but can authorize or reject only those transactions which qualify the conditions defined for authorization. The same user who initiated the request cannot authorize the transaction even though that user might have the checker responsibility.
The system displays transactions entered on the Maintenance screen with status as error or waiting for approval. If you want to view all transactions with only ERROR status, select View Failed check box.
The Authorization History screen displays the all the transactions with a status of Open, Void, Error, Posted, waiting for approval, and reject. Aged transactions will not be displayed. The Search Criteria section enables you to select the transactions you want to view in the Results section.
The Review Requests screen is primarily a work flow tool used to flag an Account for the attention of another Oracle Financial Services Lending and Leasing user and ask for review / feedback. It allows the system users to send and receive requests (including e-mail) commenting on a specific Account. The Review Request tab supports iterative review of selected Account and also to process the review with multiple reviewers.
The Email section enables you to send an email to either originator or receiver of the review request if an email setup is configured. However, note that a review request cannot be responded or replied back from email recipient.
The Comment History section also allows you to know the actually reviewer when an Account review request is forwarded to multiple reviewers and is reviewed or completed by second or third person other than the one assigned by originator.
The review request tab primarily allows you to flag an Account for the attention of another OFSLL user through a request asking for review / feedback. While doing so, you can either choose to send it to the reviewer immediately on creating the request or only create the request and later send for review.
You can close a review request you created at anytime, regardless of status. However, you can only close review requests that have your user id in the Originator field. When you close a review request, the system removes it from Review Request tab.
Pentingnya peran DJPb dalam kecepatan dan ketersampaian bantuan kepada penerima manfaat sangat terlihat mulai dari proses pembukaan Rekening Dana Kartu Prakerja digunakan untuk menampung Dana Kartu Prakerja untuk biaya pelatihan dan insentif sampai dengan penyaluran dana biaya pelatihan ke rekening platform digital untuk diteruskan kepada Lembaga pelatihan serta penyaluran dana insentif kepada para peserta pelatihan yang telah menyelesaikan pelatihan dan survei.
Proses pembukaan rekening Dana Kartu Prakerja harus mendapat persetujuan Direktur Pengelolaan Kas atas nama Direktur Jenderal Perbendaharaan. Rekening yang kemudian dikelola oleh Manajemen Pelaksana (PMO) ini dibuka di bank umum yang telah ditetapkan sebagai mitra pengelola Rekening Dana Kartu Prakerja. Rekening ini terdiri dari Rekening Induk untuk menampung Dana Kartu Prakerja dan Rekening Virtual untuk menampung dana penerima Kartu Prakerja.
Lebih lanjut, DJPb merespon cepat mekanisme penyaluran dana program kartu prakerja yang bersifat semi bantuan sosial tersebut melalui proses pencairan dana yang beradaptasi dengan perkembangan pembayaran dunia perbankan yang modern dan didukung sistem teknologi informasi yang tinggi.
Berbeda dengan penyaluran bantuan sosial secara konvensional, mekanisme pembayaran dan penyaluran dana program kartu prakerja terlihat lebih kompleks dengan melibatkan DJPb manajemen kartu prakerja atau Project Management Officer (PMO) kartu prakerja, Platform Digital, Lembaga Pelatihan, Bank dan penerima manfaat.
Mekanisme pembayaran biaya pelatihan keoada Lembaga pelatihan dan insentif kepada peserta yang telah selesai melakukan pelatihan dan mengisi survei menggunakan Cash Management System (CMS), yaitu suatu sistem aplikasi dan informasi pelaksanaan transaksi perbankan secara online dan realtime seperti informasi saldo rekening, transfer dana antar rekening, dan fasilitas lainnya.
Terdapat tiga elemen yang menjadi actor penting dalam mekanisme CMS ini, yaitu maker, checker dan approver. Maker adalah petugas yang ditunjuk untuk melakukan aktivitas perekaman tagihan pada CMS. Sementara itu, checker adalah pejabat atau pegawai yang berwenang untuk melakukan pengujian atau penelitian atas perekaman tagihan oleh Maker. Kemudian Approver adalah pejabat yang berwenang untuk melakukan menyetujui hasil perekaman data oleh Maker dan atau yang telah disetujui oleh Checker, serta pembayaran kepada penerima (PMK nomor 25/PMK.05/2020).
Proses bisnis penyaluran dana program kartu prakerja tersebut dapat dijelaskan sebagai berikut:
- Calon peserta mendaftar melalui situs resmi Kartu Prakerja di www.prakerja.go.id
- PMO melakukan verifikasi dan validasi by system yang telah terintegrasi dengan data center Dukcapil dan Dapodik, menetapkan SK peserta jika memenuhi syarat, membuka virtual account (VA) peserta dan menerbitkan SPP/SPM berdasarkan SK peserta.
- Mengajukan Surat Perintah Membayara (SPM) ke Kantor Pelayanan Perbendaharaan Negara (KPPN).
- Berdasarkan SPM tersebut, setelah melalui proses validasi KPPN menerbitkan Surat Perintah Pencairan Dana (SP2D) melalui Sistem Perbendaharaan dan Anggaran Negara (SPAN).
- Berdasarkan SP2D, maka terjadi pencairan dana Kartu Prakerja dari Rekening Kas Umum Negara (RKUN) masuk ke VA masing-masing peserta yang ada di Rekening Dana Kartu Prakerja yang merupakan Rekening Penampungan Lainnya (RPL) yang sebelumnya telah dibuka di Bank Umum atas persetujuan Direktorat Pengelolaan Kas DJPb.
- PMO memberikan notifikasi/pemberitahuan kepada peserta bahwa sudah dapat memilih/membeli pelatihan.
- Peserta memilih/membeli pelatihan melalui platform digital.
- Peserta melaksanakan pelatihan.
- Lembaga pelatihan memberikan notifikasi kepada platform digital bahwa peserta telah menyelesaikan pelatihan.
- Platform Digital memberi laporan /menagih biaya pelatihan kepada PMO.
- Setelah proses maker, checker, dan approval, PMO memerintahkan Bank Umum untuk memindahbukukan biaya pelatihan dari VA peserta ke rekening platform digital.
- Bank Umum memindahbukukan biaya pelatihan ke rekening platform digital untuk diteruskan ke lembaga pelatihan.
- Melalui proses maker, checker, dan approval juga PMO memindahbukukan insentif (pasca pelatihan dan isi survey) dari VA ke rekening pribadi atau e-wallet peserta setelah menyelesaikan pelatihan.