ANALISA PERMASALAHAN DAN SOLUSI APLIKASI SIPKD oleh Hadi Wiratmono pada 14 Maret 2011 jam 16:58

ANALISA PERMASALAHAN DAN SOLUSI APLIKASI SIPKD
oleh Hadi Wiratmono pada 14 Maret 2011 jam 16:58

ANALISA & PERMASALAHAN TEKNIS

PENYUSUNAN LAPORAN KEUANGAN –APLIKASI SIPKD

I. PENGANTAR

Kegiatan Pengembangan dan Implementasi SIPKD-Regional SIKD yang dilaksanakan oleh Kementerian Dalam Negeri yang dilaksanakan sejak awal Tahun 2008, telah selesai pada bulan Oktober 2010 yang lalu. Berdasarkan monitoring dan laporan para konsultan, saat ini terdapat 105 daerah yang masih memiliki komitmen untuk melanjutkan implementasi SIPKD, meskipun ada beberapa daerah yang hingga saat ini belum menunjukkan komitmen yang nyata untuk melaksanakan implementasi karena beberapa persoalan internal masing-masing daerah.

Pada Tahun 2011 dari 105 daerah implementasi, kurang lebih terdapat 51 daerah yang sedang melaksanakan Penyusunan Laporan Keuangan TA. 2010. Penyusunan laporan keuangan dengan mengunakan aplikasi SIPKD pada tahun ini bukan lah yang pertama, karena sesungguhnya sejak Tahun 2008, SIPKD sudah mampu memberikan support yang nyata dalam penyusunan laporan keuangan, salah satu contohnya adalah Laporan TA. 2008 Provinsi Sumatera Barat.

Penyusunan laporan keuangan pemerintah daerah merupakan salah satu output yang dihasilkan dari Modul Pertanggungjawaban pada Aplikasi Modul Core System. Modul Pertanggungjawaban ini pun juga mengikuti pengembangannya dalam 3 (tiga) tahun ini. Mulai dari versi Alpa hingga versi Release. Meskipun demikian secara teknis sejak masih versi Beta, aplikasi sudah mampu memberikan hasil yang memang dibutuhkan oleh pemerintah daerah yaitu berupa Laporan Realisasi Anggaran.

Jika ada beberapa daerah yang gagal menyelesaikan operasional aplikasi SIPKD yaitu belum menghasilkan laporan keuangan, sesungguhnya bukan karena ketidakmampuan aplikasi atau persoalan teknis aplikasi, tetapi karena lebih disebabkan oleh cara memperlakukan aplikasi yang tidak sesuai, hal ini perlu dicermati oleh tim admin dan juga oleh para konsultan dalam melaksanakan transfer knowlegde pada setiap kesempatan supervisi. Cara memperlakukan aplikasi SIPKD merupakan hal penting yang harus diperhatikan oleh setiap pihak baik konsultan maupun admin, karena skenario pengoperasian aplikasi sangat mempengaruhi persoalan teknis yang akan muncul pada saat penyusunan laporan maupun pada setiap interaksi operator dengan aplikasi. Kami membagi menjadi 2 model/ skenario pengoperasian aplikasi dalam rangka penyusunan laporan keuangan yaitu :

1. Normal

Pengertiannya adalah laporan keuangan akan dihasilkan dari proses pengoperasian aplikasi yang dimulai dari Modul Penganggaran, Modul Pelaksanaan dan Penatausahaan serta Modul Pertanggungjawaban. Sehingga laporan keuangan merupakan pengolahan transaksi-transaksi yang ada pada modul sebelumnya yang dilaksanakan secara berurutan dan diinput secara harian sesuai dengan kejadian transaksinya. Skenario pengoperasian aplikasi ini pun dibagi berdasarkan dukungan infrastruktur, yaitu :

* Operasioan online tersebar, contoh : Prov. Sumbar dan Kota Depok
* Operasional online terpusat, contoh : Kab. Tanah Toraja, Kab. Aceh besar
* Operasional offline tersebar, contoh : Kab Kampar

2. Tidak Normal

Pengertiannya adalah laporan keuangan dapat dihasilkan dengan cara melaksanakan entri ulang transaksi baik anggaran dan penatausahaan secara rekap. Proses ini biasanya dilaksanakan secara terpusat baik melibatkan operator dari SKPD maupun tidak. Adapun skenario yang tidak normal ini pun terdapat 2 model, yaitu :

* Entri ulang rekap dokumen transaksi, contoh ; Prov. Sumut
* Entri ulang secara by pass melalui jurnal memorial, contoh Kab. Lima Puluh Kota dan Kab. Agam

Kedua skenario ini secara teknis tetap mampu memberikan output yang diharapkan berupa laporan keuangan, akan tetapi permasalahan yang muncul pada ke dua model ini berbeda-beda dan kompleks. Adapun kasus-kasus yang sering muncul pada proses penyusunan laporan keuangan secara teknis dapat dikelompokkan sebagai berikut, adalah sebagai berikut :

1. Beberapa report pada modul pertanggungjawaban tidak muncul
2. Angka realisasi pada laporan tidak valid
3. Neraca tidak balance

II. PROSES INPUT DATA

Sebelum kami menjelaskan permasalahan dan solusi terhadap penyusunan laporan keuangan, perlu kami sampai kembali beberapa hal yang harus diperhatikan sebelum kita menghasilkan sebuah laporan keuangan melalui aplikasi SIPKD versi Release, yaitu :

A. KEBUTUHAN DATA TRANSAKSI

Tersedianya data transaksi merupakan syarat utama untuk menghasilkan laporan keuangan berupa LRA, LAK dan NERACA. Adapun data-data utama yang dibutuhkan berdasarkan cara hitung aplikasi untuk menghasilkan laporan keuangan antara lain :

1. BKU STS : yaitu data STS-Pendapatan yang telah dibukukan pada Menu Penerimaan dan Penyetoran, adapun jenis transaksi yang dipilih pada saat input data STS ini yakni ;

* Penerimaan-Tunai, artinya input data dimulai dari input data TBP
* Penerimaan-Rek. Bend, artinya input data juga dimulai dari input data TBP
* Penerimaan-Rek BUD, artinya input data langsung pada data STS saja

2. BKU SP2D : yaitu seluruh data SP2D yang telah dibukukan dalam BKU bendahara pada Menu BKU Bendahara Pengeluaran.

3. Pengesahan SPJ : yaitu seluruh data SPJ yang telah input pada Menu Pertanggungjawaban UP/GU/TU, baik secara bulanan maupun rekap

4. BKU TBP : yaitu seluruh data STS-Pengembalian belanja yang telah dibukukan dalam BKU bendahara pada Menu BKU Bendahara Pengeluaran.

5. BKU BUD Penerimaan : yaitu seluruh data STS-Pendapatan dan STS-Pengembalian Belanja, yang telah dibukukan dalam BKU BUD pada menu Validasi Kas Daerah

6. BKU BUD Pengeluaran : yaitu seluruh data SP2D yang telah dibukukan dalan BKU BUD pada menu Validasi Kas Daerah

7. Jurnal Memorial : yaitu seluruh bukti memorial yang telah dijurnal, adapun bukti memorial ini digunakan untuk input data transaksi jurnal penyesuaian atau pun jurnal balik terhadap rekening APBD maupun rekening neraca.

8. Jurnal Korolari : yaitu seluruh transaksi pengakuan atas belanja modal menjadi Aktiva Tetap

9. Saldo Awal Neraca : yaitu data saldo awal neraca SKPD dan neraca PPKD yang telah diinput pada menu Cetak-Setting-Saldo Awal. Jika belum tersedia data neraca awal SKPD, minimal dapat disediakan neraca awal pemerintah daerah, yang diinput menjadi neraca awal PPKD saja.

Berdasarkan penjelasan diatas, kita dapat menyimpulkan bahwa aplikasi dapat menghasilkan laporan keuangan jika terpenuhinya data-data transaksi tersebut. Pada proses penyusunan laporan keuangan biasanya juga dilengkapi dengan buku jurnal dan buku besar, hal ini pun secara teknis dapat dipenuhi oleh aplikasi dengan syarat transaksi harus tersedia secara lengkap, detail dan rinci sesuai tanggal transaksinya.

Semakin tidak lengkap dokumen transaksi yang tersedia berbanding lurus dengan output yang dihasilkan, contohnya bagi daerah yang melakukan entri data by pass langsung pada jurnal memorial maupun entri data secara rekap, maka laporan keuangan tidak dapat dilengkapi dengan buku jurnal dan buku besar yang menggambarkan detail transaksi keuangannya.

B. SETTING APLIKASI

Selain kebutuhan data transaksi, Modul Pertanggungjawaban juga membutuhkan beberapa settingan yang harus dilakukan, seperti yang telah dijelaskan pada buku Pedoman Pengoperasian Aplikasi SIPKD. Berikut menu-menu setting yang harus dilakukan pada Modul Data Master, antara lain :

1. Mapping SAP

Menu ini perlu dilakukan untuk dapat menghasilkan LRA dengan format SAP (PP 24), yaitu mengelompokkan rekening APBD kedalam format SAP

2. Mapping Arus Kas

Menu ini perlu dilakukan untuk dapat menghasilkan LAK, yaitu pengelompokkan rekening APBD ke dalam kelompok laporan arus kas.

3. Mapping Transaksi Bendahara

Menu ini diiperlukan untuk setting nama-nama bendahara SKPD baik bendahara penerimaan, bendahara pengeluaran dan bendahara pengeluaran pembantu dengan rekening konsolidasi yaitu RK-SKPD (nama rekening RK harus dirinci sesuai jumlah SKPD nya). Kecuali Bendahara Pengeluaran dan Bendahara Penerimaan PPKD TIDAK PERLU DI MAPPING, karena PPKD tidak ada RK SKPD nya.

4. Set Rekening Neraca

Tersedia pada menu Rekening yang berisikan seluruh rekening masing-masing daerah baik rekening pendapatan, belanja, pembiayaan dan rekening neraca.

5. Set Arus Kas

Menu ini diperlukan untuk setting terhadap nilai saldo awal kas yang dimunculkan pada laporan arus kas, berupa saldo awal kas bendahara dan kas di kasda.

6. Set Korolari

Menu ini disediakan untuk proses memunculkan jurnal korolari secara otomatis saat entri data bukti korolari, sehingga memudahkan operator saat membukukan pengakuan belanja modal menjadi aktiva tetap.

C. PROSES PERHITUNGAN LAPORAN

Setelah data transaksi dan settingan yang dibutuhkan telah dipenuhi maka langkah berikutnya adalah melakukan proses perhitungan atau dalam istilah akuntansinya melakukan posting. Adapun proses perhitungan yang disediakan dalam aplikasi, antara lain :

a. Proses – Jurnal otmatis

Proses jurnal otomatis ini selain memudahkan proses penjurnalan transaksi (tanggal valid) juga untuk memastikan tidak ada transaksi yang belum dijurnal. Proses ini berlaku seluruh jurnal di SKPD dan jurnal Konsolidator kecuali jurnal memorial dan jurnal korolari, sementara ini kedua jurnal tersebut masih harus dilakukan jurnal per transaksi. Prosesnya adalah dengan memberikan tanggal sesuai periode laporan yang akan disusun, yaitu akhir Bulan Juni atau akhir Bulan Desember.

b. Proses – Perhitungan

Proses perhitungan ini dilakukan untuk menghitung seluruh transaksi sesuai periode laporan yang akan disusun. Proses hitung dan jurnal otomatis merupakan satu paket setiap kali kita akan melakukan perhitungan realisasi anggaran. Setiap ada perubahan data transaksi maka proses hitung dan jurnal otomatis harus selalu diulang kembali.

Proses Perhitungan pada aplikasi disediakan 2 (dua) cara yaitu :

* Perhitungan per SKPD

Perhitungan ini hanya mempengaruhi realisasi anggaran pada SKPD yang dihitung saja.

* Perhitungan semua SKPD sekaligus

Perhitungan ini mempengaruhi realisasi seluruh SKPD sekaligus untuk dapat menghasilkan laporan realisasi pemda (konsolidator). Khusus proses perhitungan ini masih ada kelemahannya pada aplikasi yaitu tidak dapat dilakukan melalui menu (time out terus), sehingga sampai saat ini masih dilakukan melalui SQL secara langsung. Hal ini perlu menjadi perhatian bagi Tim Pengembangan untuk segera mencarikan solusinya.

III. PERMASALAHAN DAN SOLUSI

Setelah kita mengulas hal-hal yang harus diperhatikan terkait pengoperasian modul pertanggungjawaban untuk menghasilkan laporan keuangan, berikut kita bahas kasus-kasus, permasalahan dan solusi dari persoalan yang masuk pada Bagian Dukungan Layanan.

1. Beberapa Report pada Modul Pertanggungjawaban tidak muncul. (kasus)

Kasus ini biasanya terjadi pada report-report yang ada di Modul Pertanggungjawaban, kasus-kasus ini secara umum dapat dikelompokan menjadi 2 jenis, yaitu :

* Report tidak muncul nilainya
* Report tidak bisa dibuka (error)

Permasalahan :

Kasus-kasus diatas permasalahannya disebabkan oleh beberapa hal sehingga solusinya juga berbeda-beda, antara lain :

a. Perbedaan versi aplikasi

Permasalahan ini contohnya terjadi di Kab. Kapuas Hulu (Aplikasi R3) , Kab. Tana Toraja dan Kab. Aceh Besar (Aplikasi R4 release bulan Juli 2010).

Perlu diingatkan kembali bahwa aplikasi terus mengalami penyempurnaan-penyempurnaan sehingga apa bila perbedaan versi aplikasi yang terlalu jauh akan menimbulkan solusi perbaikan yang harus dilakukan lebih sulit, karena apabila dikirimkan script perbaikan report nya misalnya maka script tersebut kemungkinan tidak cocok dengan aplikasi yang terpasang.

Apalagi kalau masih menggunakan Aplikasi R3, karena R3 secara ruang lingkup di Modul Pertanggungjawaban belum mengakomodir proses akuntansi yang mengunakan mekanisme pemisahan entitas SKPD dan entitas Pemda (konsolidator).

Solusi :

Solusi untuk kasus dan permasalahan ini adalah Migrasi Aplikasi ke versi terbaru (Versi :10/10/10), karena secara teknis Tim Dukungan Layanan akan lebih mudah dalam memberikan dukungannya terkait permasalahan-permasalahan terutama pada Modul Pertanggungjawaban. Artinya Migrasi wajib dilakukan untuk mengatasi permasalahan yang muncul.

b. Pemahaman user terhadap mekanisme pengoperasian aplikasi

Kasus tidak munculnya nilai realisasi pada report bisa juga disebabkan oleh pengetahuan user tentang cara menggunakan aplikasi, contohnya antara lain :

* Belum dilakukannya proses Perhitungan (Jurnal otomatis dan Perhitungan)
* Belum dilakukan beberapa setting yang dibutuhkan seperti yang dijelaskan tentang Setting Aplikasi diatas.

Solusi :

Untuk memastikan bahwa permasalahan ini dari kasus yang dilaporkan, perlu klarifikasi dari yang menerima pengaduan, khususnya untuk mengklarifikasi bahwa proses-proses yang dibutuhkan untuk mengeluarkan report tersebut telah dipenuhi oleh user. Jika ternyata belum maka solusi untuk masalah ini adalah edukasi tentang cara mengoperasikannya.

c. Aplikasi belum sempurna (script report)

Kasus tidak munculnya nilai realisasi bisa juga disebabkan oleh permasalahan aplikasi nya yang belum sempurna (script report), contohnya tidak munculnya realisasi Pembiayaan pada LRA Pemda, sementara pada LRA PPKD nilai realisasi Pembiayaan muncul.

Solusi :

Untuk permasalahan ini Tim Dukungan Layanan bisa menyelesaikan permasalahan ini dengan segera mengirimkan perbaikan script dan rpt.

2. Angka realisasi pada laporan tidak valid (kasus)

Untuk kasus tidak validnya angka realisasi yang muncul pada laporan, berdasarkan laporan pengaduan yang masuk kasus-kasusnya antara lain :

* Nilai realisasi pada LRA SAP berbeda dengan LRA APBD
* Nilai realisasi pada Laporan Pertanggungjawaban lampiran 1 berbeda dengan Lampiran yang lain
* Nilai realisasi LRA tidak sama dengan nilai pada SPJ Fungsional
* Nilai realisasi pada LAK tidak sama dengan LRA

Untuk kasus-kasus diatas, berdasarkan data yang dikumpulkan dari hasil klarifikasi, secara umum di-dominasi karena kasus-kasus data transaksi yang ada. Sehingga kasus-kasus ini bisa saja dikelompokkan permasalahannya diantaranya sebagai berikut :

a. Pemahaman user terhadap mekanisme pengoperasian aplikasi

Pemahaman user tentang mekanisme pengoperasian aplikasi yang dimaksud antara lain :

* User belum mengetahui tentang menu setting yang harus dilakukan pada Modul Data Master, contohnya Mapping SAP dan Mapping Arus Kas.
* User belum mengetahui perbedaan menu entri untuk kasus STS-Pengembalian, karena untuk jenis pengembalian belanja terdapat 3 jenis transaksi dengan menggunakan menu yang berbeda pula. Tiga jenis pengembalian itu adalah :

1. Pengembalian sisa UP/GU/TU tahun lalu – Menu nya Pengembalian UP
2. Pengembalian sisa UP/GU/TU tahun berjalan – Menu nya Pengembalian UP
3. Pengembalian kelebihan atas belanja (Jenis SP2D-LS) – Menu nya Pengembalian BTL, BL dan Pembiayaan. Jenis pengembalian ini bersifat mengurangi realisasi belanja.

* User belum melakukan proses hitung ulang setiap terjadinya perbaikan data transaksi.

Solusi :

Solusi untuk permasalahan ini relatif lebih mudah, karena cukup memberikan penjelasan langkah-langka yang harus dilakukan.

b. Kesalahan entri data

Permasalahan ini merupakan salah satu Permasalahan yang dominan yang menyebabkan validasi angka realisasi belum valid. Permasalahan ini pun bisa terjadi dibeberapa kasus yang umumnya terletak pada Modul Pelaksanaan dan Penatausahaan. Laporan realisasi yang menjadi Output dari Modul Pertanggungjawaban merupakan hasil pengolahan data transaksi yang ada pada Modul Pelaksanaan dan Penatausahaan, sehingga kesalahan validasi angka realisasi lebih banyak disebabkan dari kesalahan entri data pada modul sebelumnya.

Adapun permasalahan kesalahan entri dimaksud, antara lain :

* Adanya TBP atau STS yang belum di-bku-kan pada BKU Bendahara Penerimaan
* Adanya TBP yang tidak ada STS nya
* Adanya STS yang tidak nyambung dengan TBP nya
* Adanya transaksi penatausahaan bendahara pengeluaran yang belum di-bku-kan pada BKU Bendahara Pengeluaran, contoh : SP2D, Pajak, BPK atau STS Pengembalian belanja.
* Adanya kesalahan tanggal BKU SKPD baik BKU Bendahara Penerimaan maupun Bendahara Pengeluaran
* Adanya perbedaan dokumen STS dan SP2D antara yang di-bku-kan pada BKU Bendahara dengan yang di-bku-kan pada BKU BUD (Menu validasi kasda).
* Adanya dokumen yang belum disahkan (menu persetujuan) contohnya TBP, STS dan SPJ.

Solusi :

Solusi terhadap kesalahan entri data tentu saja perbaiki datanya. Semakin banyak kesalahan entri data akan semakin lama pula penyelesaian laporan keuangan.

Pada kesempatan kali ini untuk Kasus kesalahan entri data, kami perlu jelaskan pula beberapa hal yang bisa menjadi acuan bagi operator, admin, konsultan serta Tim Dukungan Layanan. Hal ini bisa menjadi rekomendasi terhadap fungsi masing-masing dalam mencegah/meminimalkan resiko kesalahan entri data.

Hal-hal yang harus diperhatikan pada Modul Pelaksanaan dan Penatausahaan, antara lain :

1. Adanya Menu Persetujuan pada beberapa menu entri dokumen transaksi (TBP, STS, SP2D, dll) berfungsi untuk memisahkan data yang sudah valid dengan yang belum, sehingga jika ada dokumen yang belum diberikan tanggal persetujuan-nya melalui menu ini, maka dokumen tersebut belum bisa di-bku-kan dalam BKU Bendahara dan atau tidak bisa dibaca pada menu berikutnya.

2. Angka realisasi Pendapatan secara teknis diambil dari transaksi TBP dan STS yang telah di-bku-kan pada Menu Penerimaan dan Penyetoran ditambah/dikurangi transaksi memorial (penyesuaian). Sehingga jika ada TBP dan atau STS yang belum di-bku-kan, tidak akan terhitung menjadi realisasi pendapatan.

3. Adanya tiga jenis transaksi yang harus dipilih pada menu entri STS Pendapatan dan Penerimaan Pembiayaan sesuai transaksi penerimaan yang terjadi, yaitu :

* Penerimaan Tunai

Jenis transaksi ini adalah untuk menginput data penyetoran yang sebelumnya terjadi proses penerimaan terlebih dahulu, dari wajib bayar kepada Bendahara Penerimaan secara tunai. Sehinggan proses entri datanya dimulai dari dokumen TBP selanjutnya diikuti dengan dokumen STS dengan jenis transaksi yang sama yaitu Penerimaan Tunai.

* Penerimaan Rek. Bend

Jenis transaksi ini adalah untuk menginput data penyetoran yang sebelumnya terjadi proses penerimaan terlebih dahulu, dari wajib bayar kepada Bendahara Penerimaan melalui proses transfer ke rekening Bendahara Penerimaan. Sehinggan proses entri datanya dimulai dari dokumen TBP selanjutnya diikuti dengan dokumen STS dengan jenis transaksi yang sama yaitu Penerimaan Rek.Bend

* Penerimaan Rek. BUD

Jenis transaksi ini adalah untuk menginput data penyetoran mana prosesnya tidak melalui Bendahara Penerimaan tetapi langsung ke rekening Kas Daerah. Sehinggan proses entri datanya langsung pada menu entri dokumen STS dengan jenis transaksi Penerimaan Rek.BUD.

Penjelasan fungsi jenis transaksi pada menu entri STS diatas, dimaksudkan untuk penjelasan terjadinya kasus “ TBP yang tidak ada STS nya dan atau adanya data TBP dan STS yang tidak nyambung”. Hal ini dimungkinkan karena sewaktu entri data STS jenis transaksi yang seharusnya dipilih adalah jenis transaksi penerimaan tunai/penerimaan Rek.Bend, user justru memilih jenis transaksi Rek. BUD. Hal ini menyebabkan pengakuan realisasi pendapatannya menjadi double.

4. Tersedianya Option “Validasi Tgl BKU Bendahara terhadap Tgl Cair” pada Modul Penatausahaan.

Menu ini disediakan bertujuan untuk percepatan implementasi penatausahaan SKPD, agar tidak tergantung dengan belum selesainya proses entri Menu Validasi Kasda untuk pengakuan STS dan SP2D cair di BKU BUD.

Hal-hal yang perlu dipahami oleh semua fungsi mengenai Menu BKU, adalah bahwa sumber utama pengolahan data transaksi menjadi laporan realisasi anggaran salah satunya adalah data BKU. Ada 3 (tiga) menu BKU yang ada dalam aplikasi, yaitu :

* BKU Penerimaan – Menu Penerimaan dan Penyetoran
* BKU Pengeluaran – Menu BKU Bendahara Pengeluaran
* BKU BUD – Menu Validasi Kas Daerah

Perlu diketahui bahwa Menu Validasi Kasda merupakan sumber data utama untuk menghasilkan laporan konsolidasi tingkat pemerintah daerah. Sehingga antara data-data STS dan SP2D yang telah dibukukan dalam BKU Bendahara harus sama dengan data STS dan SP2D yang dibukukan pada BKU BUD. Adanya Option “Validasi Tgl BKU Bendahara terhadap Tgl Cair” jika diaktifkan “ya”, maka konsekuensinya adalah tim admin dan operator harus memperhatikan kesamaan data yang dientri pada BKU Bendahara dan BKU BUD, khususnya data STS dan SP2D.

Karena dari beberapa kasus yang muncul mengenai “angka realisasi anggaran antara Laporan SKPD dengan Laporan Pemda”, hal tersebut disebabkan user tidak memperhatikan dan menjaga dampak dari option tersebut.

Perlu diketahui dari informasi yang ada di daerah, pengoperasian Modul Penatausahaan khususnya Menu Validasi Kasda secara penuh tercatat hanya terlaksana di Provinsi Sulawesi Selatan. Sementara daerah lainnya masih melaksanakan menu ini sebatas entri ulang, sehingga permintaan option ini dari user, dilatarbelakangi oleh belum dioperasikannya menu validasi kasda secara penuh sehingga penatausahaan bendahara bisa terlambat jika entri data pada menu tersebut juga terlambat.

Penjelasan ini untuk menjawab penyebab terjadinya “perbedaan dokumen STS dan SP2D antara yang di-bku-kan pada BKU Bendahara dengan yang di-bku-kan pada BKU BUD (Menu validasi kasda)”.

5. Proses entri dokumen transaksi pada BKU Bendahara dan BKU BUD secara teknis default tanggal nya menunjukkan tanggal komputer (tanggal hari ini), dan masih bisa tersimpan apabila tahun anggarannya berbeda dengan tahun periode transaksi. Hal ini bisa dikatakan kelemahan aplikasi, karena hal tersebut menjadi salah satu persoalan yang rawan dari human error berupa “kesalahan tanggal BKU”. Hal ini harus menjadi perhatian juga dalam entri data, karena dampaknya data tersimpan tapi tidak dihitung dalam laporan.

6. Permasalahan data yang disebabkan dampak dari kelemahan aplikasi versi sebelumnya. Kelemahan yang dimaksud adalah adanya 1 (satu) dokumen transaksi yang di-bku-kan 2 (dua) kali, khususnya pada BKU BUD.

Permasalahan ini kemungkinan ada jika daerah telah mengoperasikan Modul Penatausahaan dengan menggunakan versi sebelum release terbaru. Jika sejak awal sudah menggunakan versi terbaru kemungkinan besar tidak akan ada masalah ini.

Hal penting lainnya yang harus menjadi perhatian untuk user terkait BKU BUD adalah, secara teknis proses input data STS dan SP2D pada BKU BUD maksimal dapat dilakukan oleh 2 (dua) orang user secara bersamaan, jika lebih dari itu maka akan terjadi kesalahan data berupa 1 (satu) dokumen dapat di-bku-kan lebih dari satu nomor BKU. Kenapa hal tersebut harus demikian, karena secara teknis BKU BUD adalah dokumen yang harus dikontrol harian dan memiliki nomer BKU yang berurutan dari awal hingga akhir tahun.

7. Permasalahan data Neraca juga bisa menyebabkan validasi angka pada Neraca SKPD dan Neraca PPKD berbeda. Permasalahan pada angka Neraca yang dimaksud antara lain :

* Nilai Saldo Awal RK SKPD di Neraca PPKD berbeda dengan Nilai Saldo Awal RK PPKD di Neraca SKPD
* Jurnal Balik untuk Rekening RK SKPD di PPKD berbeda nilainya dengan Jurnal Balik Rekening RK PPKD di SKPD
* Sisa UP tahun yang disetor pada tahun berikutnya jika diinput melalui Jurnal Penyesuaian maka user harus memastikan jurnal tersebut dibuat 2 (dua) kali, yaitu di SKPD bersangkutan dan di PPKD. (Sebaiknya tetap pada menu Pengembalian UP pada Modul Penatausahaan)