Tulisan ini saya tulis hanya ingin berbagi kepada para administrator yang baru berkecimpung dalam dunia per-SIMDA-an. Pengetahuan saya tentang apa yang terjadi di balik database SIMDA masih belum lengkap, masih perlu banyak belajar lagi. Apa saja yang akan saya bahas di sini? Sesuai judulnya, saya akan membedah proses yang terjadi pada database SIMDA terutama permasalah-permasalahan yang sering saya temui di dalam database. Seperti yang para admin sudah ketahui, SIMDA Keuangan BPKP menggunakan Microsoft SQL Server sebagai server database. Karena SIMDA pula saya untuk pertama kali berurusan dengan Microsoft SQL Server, dari yang biasanya lebih familier dengan MySQL.
Di dalam sebuah database tentu saja terdiri dari tabel-tabel. Saya akan membagi tabel-tabel tersebut menurut dua kriteria. Pertama, berdasarkan kriteria, saya sebut saja ‘ayah dan anak’, tabel-tabel dibagi menjadi dua jenis, tabel ayah dan tabel anak. Semua tabel ayah berawalan Ref dan table anak berawalan Ta. Tabel anak menyimpan foreign key yang berasal dari tabel ayah, kira-kira begitulah. Tapi saya tidak akan membahas kriteria yang satu ini. Saya akan membahas kriteria yang kedua, kriteria ‘transaksi dan jurnal’, yaitu tabel-tabel dibagi menjadi dua bagian yaitu tabel transaksi dan table jurnal. Tabel transaksi menyimpan data transaksi, contohnya tabel untuk menyimpan bukti pengeluaran (Ta_Bukti_Penerimaan), STS (Ta_STS), tagihan (Ta_SPP), SP2D (Ta_SP2D), dan jurnal memorial (Ta_Jurnal dan Ta_JurnalAk). Pada saat user menyimpan data pada tabel-tabel tersebut, aplikasi SIMDA secara otomatis membuat jurnalnya yang disimpan di tabel jurnal. Ada 4 tabel untuk menyimpan jurnal tersebut, yaitu Ta_JurnalSemua dan Ta_JurnalSemua_Rinc untuk laporan CTA, Ta_JurnalSemuaAk dan Ta_JurnalSemuaAk_Rinc untuk laporan akrual.
Masalah yang sering timbul karena pembagian ini adalah kedua jenis tabel ini kemungkinan menyimpan data yang tidak sama alias tidak nyambung. Tabel transaksi bilang A, tabel jurnal bilang B, atau tabel transaksi bilang X, tabel jurnal nggak bilang apa-apa alias kosong. Misalnya, seringkali saya melihat perbedaan angka antara laporan di bendahara pengeluaran dengan laporan di pembukuan. Sebenarnya, ketidaknyambungan ini bisa dengan mudah diselesaikan dengan melakukan rebuild total jurnal. Tapi tunggu dulu, rebuild total jurnal menurut saya terlalu ekstrim untuk dilakukan, terutama saat database masih diakses oleh banyak orang. Dan biasanya memakan waktu yang lama, apalagi transaksi sudah sangat banyak. Memang lebih mantap menggunakan rebuild total, tapi saya lebih suka menggunakan query untuk mencari ketidaknyambungan tersebut dan melakukan rebuild secara parsial. Bagaimana saya melakukannya?
Contoh yang sering saya temui yaitu ketidaknyambungan antara tagihan di data entry SPP dan tagihan di posting data. Harap diingat, data entry SPP merepresentasikan isi dari tabel transaksi dan posting data merepresentasikan isi dari tabel jurnal. Ketidaknyambungan ini tentu akan membuat Laporan Operasional tidak valid. Nilai beban bisa lebih saji atau kurang saji.
Langkah pertama, saya ingin melihat apakah ada nomor tagihan ada di tabel jurnal (Ta_JurnalSemuaAk) tapi tidak ada di tabel SPP (Ta_SPP) saya akan menggunakan query berikut:
SELECT A.No_Bukti, B.No_Tagihan FROM Ta_JurnalSemuaAk A LEFT JOIN Ta_SPP B ON A.No_Bukti = B.No_Tagihan WHERE A.Kd_Source = 18 AND B.No_Tagihan IS NULL
Bila ditemukan, maka saya akan langsung menghapus nomor tagihan tersebut, karena merupakan data sampah.
Langkah kedua, saya ingin melihat apakah ada nomor tagihan ada di tabel SPP (Ta_SPP) tapi tidak ada di tabel jurnal (Ta_JurnalSemuaAk) dengan query berikut:
SELECT A.No_SPP, A.No_Tagihan FROM Ta_SPP A LEFT JOIN Ta_JurnalSemuaAk B ON A.Tahun = B.Tahun AND A.No_Tagihan = B.No_Bukti WHERE A.Jn_SPP = 3 AND B.No_Bukti IS NULL
Saya tinggal melakukan ubah simpan pada data entry SPP dengan syarat SPP masih draft dan belum dibuatkan SPM. Bagaimana jika SPP sudah ada SPM atau bahkan sudah SP2D? Hapus SPM dan SP2D dulu. Tapi sangat merepotkan apalagi SP2D udah cair dan di-posting. Cara mudahnya adalah saya akan melakukan rebuild parsial untuk satu nomor tagihan yang bermasalah tersebut dengan menjalankan query:
exec SP_Posting_Ta_SPP 'Tahun', 'Nomor SPP', 'Nomor Tagihan'
Query tersebut merupakan stored procedure yang menghasilkan jurnal secara otomatis pada saat kita klik simpan pada pembuatan SPP. Tapi untuk menjalankan query tersebut Anda tidak bisa menggunakan Microsoft SQL Server Management Studio, karena sudah di-lock. Saya sendiri menggunakan Navicat Premium atau lewat PHP.
Selain kemungkian ketidaknyambungan Ta_SPP dengan Ta_JurnalSemuaAk, masih terdapat kemungkinan ketidaknyambungan yang lain, misalnya Ta_Bukti_Penerimaan dengan Ta_JurnalSemuaAk. Prosesnya hampir mirip dengan yang saya jelaskan di atas.
Contoh-contoh query yang saya gunakan adalah sebagai berikut:
Bukti Penerimaan ada di Ta_Bukti_Penerimaan tapi tidak ada di Ta_JurnalSemuaAk.
SELECT A.Kd_Urusan, A.Kd_Bidang, A.Kd_Unit, A.Kd_Sub, A.No_Bukti FROM Ta_Bukti_Penerimaan A LEFT JOIN Ta_JurnalSemuaAk B ON A.Tahun = B.Tahun AND A.No_Bukti = B.No_Bukti WHERE B.No_Bukti IS NULL
Bukti Penerimaan ada di Ta_JurnalSemuaAk tapi tidak ada di Ta_Bukti_Penerimaan.
SELECT A.No_Bukti FROM Ta_JurnalSemuaAk A LEFT JOIN Ta_Bukti_Penerimaan B ON A.No_Bukti = B.No_Bukti WHERE A.Kd_Source = 1 AND B.No_Bukti IS NULL
Bukti Pengeluaran ada di Ta_JurnalSemuaAk tapi tidak ada di Ta_SPJ_Bukti.
SELECT A.No_Bukti FROM Ta_JurnalSemuaAk A LEFT JOIN Ta_SPJ_Bukti B ON A.No_Bukti = B.No_Bukti WHERE A.Kd_Source = 7 AND B.No_Bukti IS NULL
Bukti Pengeluaran ada di Ta_SPJ_Bukti tapi tidak ada di Ta_JurnalSemuaAk.
SELECT A.Kd_Urusan, A.Kd_Bidang, A.Kd_Unit, A.Kd_Sub, A.No_Bukti FROM Ta_SPJ_Bukti A LEFT JOIN Ta_JurnalSemuaAk B ON A.Tahun = B.Tahun AND A.No_Bukti = B.No_Bukti WHERE B.No_Bukti IS NULL
Masih ada permasalahan-permasalahan lainnya yang saya temukan dan akan saya bagikan di tulisan berikutnya.