perancangan dan pengembangan sistem informasi keuangan...
TRANSCRIPT
Perancangan dan Pengembangan Sistem Informasi Keuangan dan
Akuntansi Universitas berbasis Web
(Studi Kasus : Universitas Kristen Satya Wacana kota
Salatiga)
Artikel Ilmiah
Peneliti:
Alden Hariyanto Putra (682012033)
Program Studi Sistem Informasi
Fakultas Teknologi Informasi
Universitas Kristen Satya Wacana
Salatiga
Juli 2016
1
Perancangan dan Pengembangan Sistem Informasi Keuangan dan Akuntansi
Universitas berbasis Web
(Studi Kasus : Universitas Kristen Satya Wacana kota Salatiga)
1)Alden Hariyanto, 2) Frederik Samuel Papilaya 3)Augie David Manuputty
Program Studi Sistem Informasi
Fakultas Teknologi Informasi
Universitas Kristen Satya Wacana
Jl. Diponegoro 52-60 Salatiga
E-mail: 1)[email protected] , 2) [email protected], 3) [email protected]
Abstract
SWCU already introduced a financial and accounting information system to support the
process of financial administration and record keeping. However, there are still
weaknesses in which the process of filing the funds disbursement by the unit/sub-unit could
not be displayed by the system, so that new submissions can only be seen in the
accountability process. In this study, a system of financial and accounting information was
designed and developed with the prototype system development method that can track the
submission of disbursement of funds since the submission process by the unit/sub-unit.
Keywords: Accounting & Financial Information System, Prototype, disbursement of funds.
1) Mahasiswa Fakultas Teknologi Informasi Jurusan Sistem Informasi, Universitas Kristen Satya Wacana Salatiga.
2) Staf Pengajar Fakultas Teknologi Informasi, Universitas Kristen Satya Wacana
3) Staf Pengajar Fakultas Teknologi Informasi, Universitas Kristen Satya Wacana
1. Pendahuluan
2
Universitas Kristen Satya Wacana (UKSW) adalah salah satu universitas
yang besar di kota Salatiga, Jawa Tengah, terutama dengan jumlah mahasiswa yang masuk sebesar kurang lebih 3500 mahasiswa dan terus bertambah tiap tahunnya,
dapat dipastikan bahwa kegiatan administrasi di UKSW sangatlah padat dan kompleks. UKSW terdiri dari 15 fakultas yang tentunya memiliki proses
administrasinya sendiri-sendiri [1]. Dimulai dari proses administrasi pendaftaran mahasiswa per-jurusan yang ada di tiap fakultas, registrasi mata kuliah, sampai dengan proses administrasi keuangan yang semuanya harus
berkoordinasi/terintegrasi dengan pihak universitas pusat. Integrasi inilah yang menuntut UKSW untuk dapat berinovasi dalam mengoptimalkan aktivitas
manajemen dan administrasinya demi memberikan pelayanan pendidikan terbaik. Teknologi Informasi (TI) memungkinkan untuk melakukan pencatatan,
pemrosesan dan menampilkan data secara lebih akurat dibandingkan dengan
pencatatan berbasis kertas. Pemanfaatan TI yang baik dan efektif juga secara otomatis dapat meningkatkan kualitas informasi yang berdampak pada peningkatan
kualitas manajemen. Peningkatan kualitas manajemen memungkinkan organisasi atau perusahaan untuk meningkatkan daya saingnya dengan organisasi/perusahaan lainnya [2]. Sehingga tidak dapat dipungkiri lagi, bahwa TI sudah menjadi
kebutuhan dasar bagi setiap organisasi dan perusahaan dari skala kecil ataupun sampai dengan skala besar untuk dapat bersaing diera global saat ini.
Sesuai perkembangannya, UKSW sudah memanfaatkan teknologi informasi (TI) untuk mendukung sebagian besar operasional administrasi universitas. Teknologi informasi yang sudah diakuisisi oleh UKSW antara lain, Sistem
Informasi Akademik yang disebut dengan SIASAT, Sistem Informasi Manajemen Ruang yang disebut dengan SIMARU, dan juga Sistem Informasi Keuangan dan
Akuntansi Kampus (SIKASA), yang digunakan untuk mengelola seluruh data keuangan dan pencatatan akuntansi universitas UKSW. SIKASA yang ada saat ini terdiri dari beberapa modul yang mewakili setiap proses administrasi keuangan di
Universitas, seperti modul Surat Permintaan Realisasi Anggaran (SPRA), Pengelolaan Anggaran, Realokasi, Carry Forward, Loket, BON dan Pertanggung
Jawaban BON. Modul-modul ini mewakili setiap proses transaksi administrasi keuangan di UKSW. Sebagai contoh, Realokasi digunakan untuk memindahkan anggaran dari satu rekening ke rekening yang lain, dan Carry Forward adalah
modul untuk memindahkan anggaran dari anggaran dari periode berjalan keperiode selanjutnya.
Salah satu modul yang vital di SIKASA adalah modul BON yang befungsi untuk proses pengajuan BON atau pencairan dana anggaran. Namun, SIKASA masih mempunyai kelemahan utama, dimana data pengajuan BON tidak dapat
diketahui sampai dengan proses pertanggung jawaban dilakukan, sehingga jumlah anggaran yang sudah dicairkan baru dapat divalidasi berdasarkan dokumen fisik
yang ada. Hal ini menjadi masalah ketika dokumen fisik tersebut hilang ataupun terjadi Human Error saat proses validasi, sehingga memungkinkan hal seperti kebocoran anggaran dapat terjadi. Masalah-masalah ini dapat diatasi dengan
perubahan mekanisme penggunaan sistem oleh tiap unit/sub-unit, maupun alur pemrosesan data pada sistem.
3
Untuk mengatasi masalah diatas, penulis tertarik untuk menganalisa,
merancang dan mengembangkan sistem informasi keuangan kampus berbasis web di UKSW terkhusus untuk modul BON, yang dapat melacak pengajuan BON sejak pengajuan BON itu dilakukan secara real-time. Modul BON ini nantinya dapat
diakses dengan mudah oleh tiap unit/sub-unit yang ada di kampus UKSW melalui browser standar seperti mozilla firefox dan chrome yang tentunya dapat diakses
oleh setiap perangkat Personal Computer (PC) dan laptop yang terhubung dengan jaringan lokal di UKSW.
Dengan demikian, beberapa masalah yang ingin diatasi oleh penulis adalah
permasalahan transaksi pengajuan BON yang tidak dapat dilacak hingga proses pertanggung jawaban dilakukan. Permasalahan ini seharusnya dapat diatasi dengan
mengimplementasikan alur kerja sistem yang dapat mencatat transaksi pengajuan dari awal transaksi pengajuan dilakukan. Pengembangan sistem ini diharapkan dapat membantu pihak bagian
keuangan kampus untuk kemudian mengoptimalkan sumber daya maupun kinerja yang ada dengan mengatasi faktor kesalahan dan kebocoran yang mungkin terjadi
pada sistem lama. 2. Kajian Pustaka
2.1. Penelitian Terdahulu
Penelitian terdahulu yang berjudul, “Sistem Informasi Keuangan pada
Sekolah ST.Agatha”, membahas mengenai perancangan dan pengembangan sistem
informasi keuangan di sekolah St. Agatha. Hasil dari penelitian tersebut adalah sistem informasi keuangan berbasis desktop sebagai pengganti sistem kerja berbasis
kertas pada administrasi sekolah St. Agatha.[3] Penelitian ini menggunakan kerangka kerja Performance, Information, Economic, Control, Efficiency, dan Service atau sering disebut dengan PIECES. Kerangka kerja PIECES digunakan
dalam proses analisa permasalahan, yang kemudian menjadi dasar perancangan sistem keuangan. Sistem keuangan yang dibuat sudah mencakup proses manajemen
transaksi pembayaran SPP, Gaji, absensi dan mempunyai output laporan keuangan standar, seperti laporan jurnal, buku besar, neraca, perubahan ekuitas, dan laba-rugi. Pengimplementasian Sistem Informasi Keuangan sudah dapat mengatasi sebagian
besar masalah yang teridentifikasi, dikarenakan proses input, pengolahan dan penyimpanan data sudah dilakukan dengan sistem dan database, sehingga
mempercepat proses administrasi keuangan di St. Agatha. Namun, masih ada beberapa saran pengembangan yang diberikan oleh penulis, seperti mengadakan pelatihan bagi karyawan, dan staff administrasi agar sistem keuangan yang dibuat
dapat dimanfaatkan secara keseluruhan. Penelitian lainnya yang berjudul, “Sistem Informasi Keuangan Sesuai
Standar BAN-PT Terintegrasi Sisfo Kampus 4.1”, yang membahas mengenai perancangan dan pengembangan sistem informasi keuangan kampus yang terintegrasi dengan Sisfo Kampus 4.1. sebuah sistem informasi akademik open-
source. Salah satu permasalahan yang diangkat dalam penelitian ini adalah “bagaimana melakukan integrasi sistem keuangan dengan sisfokampus 4.1.”, yang
4
penulis wujudkan dengan cara menggabungkan tabel database sistem informasi
keuangan dengan database Sisfo Kampus 4.1.[4] Integrasi sistem dengan menggabungkan database bukanlah teknik yang
baik digunakan untuk sistem yang terus berkembang. Penggabungan database
membuat beban operasional pada satu database bertambah, dan turut pula menambah kompleksitas tabel yang harus di maintenance. Sebagai contoh, saat
ingin melakukan backup terhadap sistem Sisfo Kampus 4.1. maka database milik sistem keuangan secara otomatis ikut terbackup, nyatanya SISFOKAMPUS sebenarnya adalah sistem informasi akademik yang berdiri sendiri. Masalah lain
adalah pada saat melakukan restore, maka ada kemungkinan data sistem keuangan juga akan tertumpuk oleh data backup dari SISFOKAMPUS 4.1. Oleh karena itulah
cara yang dirasa paling tepat untuk integrasi sistem yang berbeda adalah dengan menggunakan web service.
2.2. Dasar Teori
Menurut organisasi w3, Web Application atau Aplikasi Web, merupakan halaman web ataupun sekumpulan halaman web yang dikirimkan melalui protokol HTTP yang diproses di sisi server ataupun client yang berfungsi seperti aplikasi
didalam browser web[5]. Aplikasi web pada umumnya terbagi menjadi 2 bagian, yaitu back-end dan front-end, definisi front-end pada aplikasi web merupakan
aplikasi yang beroperasi diperangkat pengguna, yang secara sederhana disebut interface atau tampilan yang muncul bagi pengguna. Aplikasi front-end inilah yang nantinya berkomunikasi untuk mengirimkan dan menerima data dari/ke back-end
yang merupakan aplikasi yang beroperasi disisi perangkat penyedia layanan atau sering juga disebut server side.[6]
Masing-masing penyedia layanan pada umumnya memiliki platform-nya sendiri-sendiri. Hal ini menyebabkan komunikasi antara server dengan platform berbeda menjadi sulit untuk dilakukan. Untuk itulah digunakan konsep web service
sebagai untuk memungkinkan komunikasi antar server yang berbeda platform. Web Service merupakan aplikasi yang memungkinkan aplikasi antar platform dapat
saling berkomunikasi melalui internet, dengan menyediakan format standar komunikasi melalui HTTP berupa XML, JSON, dan lain-lain.[7] Akuntansi merupakan suatu sistem pencatatan seluruh aktivitas keuangan
organisasi dan dapat menghasilkan laporan keuangan yang dapat digunakan para pemilik kepentingan dalam mengambil keputusan.[8] Proses administrasi akuntansi
saat ini sudah memanfaatkan IT dalam pelaksanaannya, implementasi IT dalam proses administrasi akuntansi ini seringkali disebut dengan Sistem Informasi Akuntansi. Menurut Hosein, Sistem Informasi Akuntansi adalah suatu sistem
informasi yang dapat mencatat dan memproses data akuntansi, serta dapat menghasilkan informasi yang berguna untuk proses pengambilan keputusan dalam
suatu organisasi. Konsep sistem informasi akuntansi terdiri dari 3 elemen pendiri, yaitu manusia, praktek dan teknologi informasi.[2]
5
Gambar 1. Skema sub-sistem dari sistem informasi keuangan dan
akuntansi.[2]
Sistem informasi Akuntansi terdiri dari beberapa klasifikasi sub-system berdasarkan siklus yang ada di perusahaan, seperti pada gambar 1, terdapat siklus pengeluaran yang terdiri dari proses pembelian dan pembayaran untuk kebutuhan
perusahaan, siklus produksi yang melibatkan aktivitas merubah bahan mentah maupun manusia menjadi barang jadi atau layanan, siklus sumberdaya manusia
yang melibatkan proses manajemen tenaga kerja dan membayar tenaga kerja, siklus pemasukan yang melibatkan proses pemasukan/sales perusahaan, dan siklus keuangan yang melibatkan aktivitas penyediaan anggaran terhadap operasional
perusahaan.[2]
3. Metode Penelitian
Tahapan penelitian ini dimulai dari tahapan identifikasi masalah yang ada
berdasarkan hasil wawancara kualitatif dengan pihak-pihak berkepentingan di SIKASA lama, lalu merumuskan masalah yang sudah teridentifikasi. Berikutnya
adalah melakukan perancangan pengembangan sistem yang dilakukan mulai April 2016 sampai dengan awal Juli 2016. Sistem yang sudah disetujui oleh tester pada proses pengembangan kemudian di-deploy dan di-testing dengan metode blackbox
oleh tiap user pada tiap unit/sub-unit. Penelitian diakhiri dengan tahapan pengambilan kesimpulan. Gambar 2 menggambarkan tahapan penelitian yang
digunakan dalam penelitian ini.
6
Gambar 2. Tahapan Penelitian
Melalui proses tahapan 1, masalah utama yang teridentifikasi dari sistem
keuangan yang lama adalah proses jurnal yang dilakukan hanya saat pertanggung jawaban BON dilakukan, sehingga informasi pengajuan BON tidak terlihat di
sistem sebelum proses pertanggung jawaban dari pengajuan BON tersebut dilakukan oleh unit/sub-unit, hal ini menyebabkan bagian keuangan harus melakukan validasi ulang secara manual berdasarkan dokumen-dokumen fisik
pengajuan yang sudah dilakukan oleh unit/sub-unit sebelumnya.
Gambar 3. Tahapan proses metode pengembangan sistem prototype.[9]
Listen to Customer
Build/ Revise Mock Up
Customer Test Drives/ Mockup
Tahapan 2: Perancangan & Pengembangan Sistem dengan metode Prototype
Hasil yang diharapkan: Aplikasi Keuangan
Tahapan 3: Deployment & user testing
Hasil yang diharapkan: Hasil testing
Tahapan 4: Pengambilan Kesimpulan
Hasil yang diharapkan: Kesimpulan Penelitian
Tahapan 1: Identifikasi & Perumusan masalah
Hasil yang diharapkan: user-requirement
7
Pada tahapan 2, sistem mulai dirancang dan dikembangkan menggunakan
metode pengembangan sistem prototype dengan tahapan-tahapan yang digambarkan pada gambar 3. Melalui proses Listen to Customer, didapatkan informasi bahwa sistem yang dibangun mempunyai 2 halaman utama, yaitu
rangkuman, dan pengajuan. Halaman rangkuman berisi mengenai ringkasan informasi transaksi semua pengajuan BON yang sudah dilakukan oleh unit/sub-unit
yang aktif beserta status pengajuannya, sedangkan pada halaman pengajuan unit/sub-unit dapat melakukan pengajuan pencairan anggaran dengan batasan-batasan seperti total pengajuan tidak boleh melebihi anggaran yang tersedia untuk
rekening, jumlah pengajuan tidak boleh lebih dari 1 transaksi per pengajuan dan jumlah pengajuan tidak boleh lebih kecil sama dengan 0. Use case dari modul BON
dapat dilihat pada gambar 4.
Gambar 4. Diagram use-case dari modul BON.
Terdapat 2 aktor utama pada modul BON, yaitu unit/sub-unit dan keuangan.
Unit/sub-unit dapat melakukan pengajuan, pembatalan dan cetak pengajuan dalam bentuk dokumen PDF maupun file ms-excel 2010. Unit/sub-unit dapat melakukan pengajuan dengan memasukkan data rekening, jumlah pengajuan dan keterangan
pengajuan melalui interface pengajuan BON yang akan disimpan sementara didalam web server cache. Setelah proses input pengajuan selesai, maka unit/sub-
unit harus melakukan proses simpan cetak pengajuan yang artinya mengajukan transaksi tersebut untuk diotorisasi keuangan, selain itu, file pdf akan dihasilkan secara otomatis ketika proses simpan cetak berhasil, yang kemudian dapat
digunakan oleh unit/sub-unit untuk validasi. Pengajuan yang sudah di”simpan cetak” kemudian akan diotorisasi atau ditolak oleh keuangan. Pengajuan akan
secara otomatis dijurnalkan dan memotong anggaran unit/sub-unit untuk rekening yang diajukan pencairannya, hal ini untuk menghindari kemungkinan pengajuan yang melebihi anggaran yang disetujui. Alur pengajuan dan otorisasi dapat dilihat
pada Gambar 5.
8
Gambar 5. Activity diagram dari proses pengajuan unit/sub-unit.
Berdasarkan gambar 5, dapat dilihat bahwa proses pengajuan unit/sub-unit
dapat ditolak oleh bagian keuangan jika dirasa tidak sesuai dengan kriteria bagian
keuangan. Pengajuan yang ditolak ini harus kemudian dibatalkan oleh unit/sub-unit secara manual agar anggaran yang diajukan dapat dipakai untuk pengajuan lainnya.
Berdasarkan gambar 6.secara konseptual terdapat dua Class utama, yaitu BON boundary dan BON Controller. BON Rangkuman boundary mewakili Class tampilan rangkuman, dimana data transaksi pengajuan BON yang sudah dilakukan
akan ditampilkan. Terdapat 5 fungsi yang ada di Class Rangkuman Boundary, yaitu pengajuan() untuk mengakses halaman pengajuan BON, fungsi lihat_detail() untuk
melihat detail transaksi pengajuan yang sudah dilakukan, batalkan pengajuan untuk menghapus transaksi pengajuan yang sudah ditolak oleh bagian keuangan, dan cetak_pengajuan() untuk mencetak file pdf pengajuan selama masih belum
berstatus “telah diotorisasi oleh keuangan”.
9
Gambar 6. Diagram Class dari modul BON.
Class boundary berikutnya adalah pengajuan boundary yang merupakan
Class tampilan pengajuan yang mempunyai 4 fungsi utama, yaitu tambah_pengajuan() yang berfungsi untuk melakukan penambahan transaksi pengajuan BON baru yang akan disimpan di web-server cache sementara, fungsi
ubah_pengajuan() yang berfungsi untuk mengubah data pengajuan dalam cache, fungsi hapus_pengajuan() untuk menghapus record transaksi data pengajuan yang
ada dalam cache, serta simpanCetak() untuk mengirimkan data bersifat final ke web service.
Class terakhir adalah Class Controller, yang merupakan Class utama dari
modul BON, dikarenakan fungsinya sebagai Class pemrosesan data dari/ke tampilan (boundary) maupun ke web service. Terdapat 9 fungsi utama, seperti
fungsi tambah_pengajuan(), ubah_pengajuan(), hapus_pengajuan(), simpan_cetak(), getListRekening_WS(), getAnggaran_WS(), getTanggal_WS(), getPeriode_WS(), dan cetak_pengajuan(), dan 2 fungsi akses boundary seperti
halaman_rangkuman() untuk akses halaman rangkuman BON, dan halaman_pengajuan() untuk akses halaman pengajuan BON. Fungsi
tambah_pengajuan(), ubah_pengajuan(), dan hapus_pengajuan() merupakan fungsi manipulasi data transaksi pengajuan pada web server cache, sedangkan simpanCetak() berfungsi untuk mengirimkan data transaksi yang tersimpan pada
cache ke server melalui web service. Fungsi getListRekening_WS() adalah fungsi untuk mengambil data rekening yang tersedia untuk unit/sub-unit yang aktif melalui
web service, fungsi getAnggaran_WS() adalah fungsi untuk mengambil data anggaran yang tersedia untuk rekening tertentu, fungsi getTanggal_WS() adalah fungsi untuk mengambil tanggal aktif saat ini (hari dimana transaksi dilakukan) dari
web service, dan getPeriode_WS() merupakan fungsi untuk mengambil periode aktif saat transaksi itu dilakukan dari web service.
10
Arsitektur sistem Informasi Keuangan dan Akuntansi terbagi menjadi 2
bagian, yaitu back-end dan web-client. Kedua sistem berkomunikasi melalui web-Service dengan teknologi .NET. sedangkan sistem informasi web-client yang dibangun menggunakan teknologi PHP 5.6 dikarenakan server yang digunakan
untuk sistem informasi keuangan dan akuntansi sudah terdapat apache tomcat. Konsep deployment dapat dilihat pada deployment diagram Gambar 7.
Gambar 7. Diagram deployment dari sistem informasi keuangan modul
BON.
Konsep deployment pada gambar 7. menunjukkan bahwa setiap perangkat
unit/sub-unit akan berhubungan dengan web client server saja. Web client server yang kemudian akan mengambil atau mengirimkan data ke web Service server. Semua data yang didapat dari dan ke web Service server akan terlebih dahulu
difilter dan dibentuk ulang menjadi struktur yang berbeda oleh web client server sebelum disajikan ke client untuk melindungi keamanan data.
4. Hasil dan Pembahasan
Hasil dari proses pengembangan prototype tahap awal adalah halaman tampilan rangkuman dan pengajuan BON yang terstandar dengan tampilan modul
lainnya. Fungsional hanya sebatas fungsi tambah, ubah dan hapus pada cache web-server. Langkah pengembangan berikutnya adalah fungsional akses web Service keuangan yang ada, dimulai dari proses pengambilan data dan kemudian
pengiriman data ke server backend melalui web service. Setelah tahap prototype awal selesai, dilakukan testing oleh user dari bagian keuangan, dan didapatkan
beberapa point evaluasi penting, yaitu : sisa anggaran masih mengembalikan nilai 0 walaupun anggaran lebih besar dari 0 didatabase, masih terdapat error pada proses manipulasi pengajuan transaksi BON, dimana transaksi tidak dapat dihapus, dan
masih ada transaksi pengajuan yang gagal tersimpan ketika melakukan proses simpan cetak pengajuan BON.
Proses pengembangan prototype kedua adalah perbaikan dari evaluasi dipengembangan tahap awal. Hasil dari pengembangan tahap kedua kemudian di-test oleh user, dan didapatkan beberapa poin evaluasi sebegai berikut: nilai sisa
anggaran sudah dapat mengambil nilai dari database, namun nilainya seharusnya berkurang tiap kali dilakukan pengajuan transaksi BON, selain itu inputan masih
belum difilter, sehingga nilai 0 dan kurang dari 0 masih dapat masuk, pengurangan sisa anggaran hanya diranah web server cache, proses simpan cetak BON sudah
11
dapat dilakukan dan berhasil, namun transaksi yang diajukan masih belum tampil
dirangkuman BON. Hasil prototype terakhir adalah perbaikan dari hasil evaluasi pengembangan
tahap kedua, serta pemasangan proteksi/filter terhadap inputan user, seperti
pengajuan tidak boleh kurang dari sama dengan 0, pengajuan tidak boleh melebihi anggaran rekening yang diajukan, dan jumlah transaksi tidak boleh lebih dari 1
transaksi per pengajuan. Secara garis besar, proses bisnis pengajuan BON oleh unit/sub-unit adalah
sebagai berikut, unit/sub-unit melakukan pengajuan BON melalui halaman
pengajuan BON, pada saat pengajuan BON berhasil diajukan, maka akan muncul lembar cetak pengajuan BON yang harus dicetak oleh user, lembar pengajuan ini
berfungsi sebagai validasi/bukti pada saat melakukan pencairan dibagian keuangan. Kemudian record pengajuan tersebut akan muncul di-interface aplikasi bagian keuangan, pada tahap ini bagian keuangan mempunyai 2 pilihan, yaitu melakukan
otorisasi terhadap record pengajuan tersebut ataupun melakukan penolakan jika dirasa tidak sesuai dengan ketentuan yang berlaku. Baik proses otorisasi maupun
penolakan terhadap transaksi pengajuan kemudian akan merubah status pengajuan transaksi yang dapat dilihat pada tampilan rangkuman BON, tepatnya pada kolom “status pengajuan”.
Gambar 8. Tampilan Rangkuman BON
Gambar 8 merupakan halaman rangkuman BON, terdapat form filter
rangkuman BON untuk melakukan filter terhadap data rangkuman yang ditampilkan. Kolom yang disediakan adalah tanggal, status PTJ, dan Kode
Transaksi BON. Tabel rangkuman transaksi BON terdiri dari kolom “Tgl Trans”, “Tgl PTJ”,
“Tgl Harus PTJ”, “periode”, “Unit/Sub-unit”, “No. Bukti Pengajuan”, “No. Bukti
Otorisasi”, “Jumlah”, “Status PTJ”, “Status Transaksi”, dan “Status Pengajuan”. Sedangkan kolom Detail BON dan Hapus adalah button untuk mengakses fungsi
lihat detail transaksi dan pembatalan transaksi yang hanya aktif jika transaksi ditolak oleh bagian keuangan. Kolom “Tgl Harus PTJ” hanya muncul ketika
12
pengajuan sudah diotorisasi oleh bagian Keuangan, sedangkan kolom “status PTJ“
dan “Tgl PTJ“ muncul ketika transaksi sudah diajukan Pertanggung jawabannya oleh unit/sub-unit. Terdapat 5 nilai status pengajuan yang mungkin muncul, yaitu “pengajuan oleh unit kerja”, “pengajuan telah diotorisasi oleh bagian keuangan”,
“telah PTJ, belum diotorisasi PTJ oleh bagian keuangan”, “PTJ BON ditolak oleh bagian keuangan dikembalikan ke unit kerja”, dan “Pengajuan BON ditolak oleh
bagian keuangan”, sedangkan untuk status pembatalan tidak dimunculkan dalam rangkuman.
User dapat mengakses detail transaksi pengajuan BON melalui tombol lihat
detail transaksi BON yang mempunyai icon kaca pembesar pada setiap record transaksi di tabel rangkuman BON. Tampilan detail transaksi dapat dilihat pada
gambar 9.
Gambar 9. Tampilan detail transaksi BON.
Tampilan detail transaksi BON yang menunjukkan informasi detail pengajuan yang tidak ditampilkan pada halaman rangkuman. User juga dapat melakukan cetak pdf terhadap pengajuan yang sudah dilakukan, namun hanya
berlaku untuk pengajuan yang masih berstatus “pengajuan oleh unit kerja” saja. Halaman pengajuan BON dapat diakses melalui tombol pengajuan dibagian
kiri bawah tabel rangkuman. Tampilan halaman pengajuan BON dapat dilihat pada gambar 10.
Gambar 10. Tampilan halaman pengajuan BON.
13
Halaman pengajuan BON seperti pada gambar 10. terdiri dari 2 bagian utama,
yaitu Filter BON dan tabel pengajuan BON. Filter BON berisi informasi tanggal transaksi, periode buku aktif saat transaksi dan nama unit/sub-unit yang aktif. Tabel pengajuan BON berisi data transaksi pengajuan BON yang tersimpan di web-server
cache. Harus diperhatikan bahwa cache akan dihapus ketika melakukan reload halaman ataupun saat user mengakses halaman pengajuan BON.
Gambar 11. Tampilan form tambah pengajuan BON.
User dapat menambahkan pengajuan BON baru dengan mengakses tombol “tambah” di bagian kiri bawah tabel. Gambar 11. menunjukkan tampilan form tambah pengajuan BON. Terdapat beberapa informasi dasar yang ada, yaitu Tgl
Trans, Periode berjalan, Unit/Sub-Unit kerja, Rekening, Sisa anggaran, Jenis Pelaksana, Nama Pengguna Anggaran, Jumlah Pengajuan, dan Keterangan. Tgl
trans adalah tanggal transaksi dilakukan, periode berjalan adalah periode buku aktif saat transaksi dilakukan, unit/sub-unit kerja adalah unit kerja aktif yang melakukan transaksi, rekening yang dipilih adalah rekening yang digunakan untuk pengajuan
BON, ketika user memilih rekening, maka otomatis sisa anggaran akan terupdate dengan nilai besar anggaran setelah dikurangi jumlah pengajuan yang telah
dilakukan.. Setelah proses penambahan pengajuan transaksi BON dinyatakan final, maka
langkah selanjutnya adalah proses “simpan cetak” yang dapat dilakukan dengan
mengakses tombol simpan dibagian bawah kanan tabel pengajuan BON. Saat user mengakses fungsi simpan cetak tersebut, maka otomatis data dalam cache akan
terlebih dahulu divalidasi oleh web client server untuk ketentuan dan standar input data sebelum kemudian dikirimkan ke web Service server untuk proses simpan pengajuan. Jika proses simpan berhasil, maka akan keluar peringatan yang
menyatakan proses penyimpanan telah berhasil dilakukan dan halaman pdf cetak pengajuan BON akan muncul seperti pada gambar 12.
14
Gambar 12. Format PDF cetak pengajuan BON.
Aplikasi saat ini telah digunakan oleh unit/sub-unit di UKSW untuk proses
BON. Menurut hasil wawancara kualitatif terhadap salah satu user bagian keuangan, sistem sudah berjalan dengan baik dan memenuhi fungsi utamanya, status transaksi pengajuan pun berubah secara real-time sesuai dengan tahap
pengajuan yang sudah dilewati, dan dapat dilihat oleh unit maupun bagian keuangan.
Sub-sistem Sistem Informasi
Akuntansi & Keuangan menurut
Husein [2]
Modul yang ada di SIKASA
Pengeluaran
Modul BON, SPRA Produksi
Sumberdaya Manusia
Pemasukan Modul Penerimaan
Penganggaran/Financing Modul Anggaran, CarryForward, Realokasi
Tabel 1. Tabel klasifikasi Modul SIKASA.
Sesuai dengan klasifikasi sub-sistem yang dibahas oleh Husein, maka modul-
modul SIKASA dapat dipetakan kedalam klasifikasi-klasifikasi tertentu yang
ditampilkan dalam tabel 1. Fungsional sub-sistem pengeluaran, produksi, dan sumberdaya manusia dapat ditemukan pada fungsi modul BON dan SPRA, dimana
kedua modul ini adalah modul untuk pengajuan pencairan anggaran tiap unit/sub-unit. Fungsional sub-sistem pemasukan dapat dilakukan dengan modul Penerimaan. Sedangkan Modul Anggaran, Carryforward, dan Realokasi mewakili sub-sistem
Penganggaran. Perbedaan utama dari modul BON dan SPRA terletak pada proses pencairan
dana anggaran. Aktivitas BON berarti proses pencairan dana dilakukan sebelum
15
anggaran tersebut dipakai, sedangkan pada modul SPRA, pencairan bersifat
“mengganti” dana setelah keperluan/kegiatan terjadi. 5. Kesimpulan
SIKASA yang telah dikembangkan saat ini telah beroperasi dan digunakan
oleh unit/sub-unit yang ada di UKSW. Pengajuan BON yang dilakukan oleh unit/sub-unit sudah secara otomatis dijurnalkan dan dapat dilacak oleh bagian keuangan sejak dari proses pengajuan, serta anggaran unit/sub-unit akan berkurang
seiring dengan jumlah pengajuan BON yang telah dilakukan oleh unit. Namun SIKASA yang baru masih dapat dikembangkan lagi, terutama untuk
web service, dimana perlu adanya penambahan parameter limiter yang berguna untuk proses data paging, terutama melihat perkembangan kuantitas data yang cukup pesat dari tiap tahunnya. Pengembangan ini berguna untuk meningkatkan
efisiensi penggunaan bandwith dan menghindari beban terlalu besar pada pemrosesan data yang tidak perlu disisi web client server dan web service server.
6. Daftar Pustaka
[1] Universitas Kristen Satya Wacana, 2016, Program Akademik. http://uksw.edu/id.php/akademik (diakses tanggal 18 Juli 2016).
[2] Alikhani, H., Ahmadi, N. & Mehravar, M., 2013.,Accounting information system versus management information system. , 2(3), pp.359–366.
[3] Syahiduzzaman. et al, 2013, “Sistem Informasi Keuangan Sesuai Standar
Ban-Pt Terintegrasi Sisfo Kampus 4.1”, Jurnal, Malang : Teknik Informatika UIN Maulana Malik Ibrahim Malang.
[4] Tenardi, Wendri. et al, 2009, “Sistem Informasi Keuangan pada Sekolah
ST.Agatha”, Jurusan Sistem Informasi STMIK GI MDP. [5] W3C Organization, 2016, Mobile Web Application Best Practices
https://www.w3.org/TR/mwabp/#webapp-defined (diakses tanggal 17 Juli
2016).
[6] Margaret Rouse, 2016, front-end definition. http://whatis.techtarget.com/definition/front-end (diakses tanggal 17 Juli
2016). [7] Oracle, 2016, The Java EE 6 Tutorial : What Are Web Services?
http://docs.oracle.com/javaee/6/tutorial/doc/gijvh.html (diakses tanggal 17
Juli 2016). [8] Klinik Akuntansi, 2016, Definisi Akuntansi Menurut Para Ahli.
http://www.kompasiana.com/klinikakuntansi/definisi-akuntansi-menurut-para-ahli_54f79be6a33311207e8b46fe (diakses tanggal 18 Juli 2016).
[9] Hartono, Andhika. et al, 2014, “Perancangan dan Implementasi Aplikasi
Media Pembelejaran Bahasa Pemrograman Pascal pada Platform Android”, Jurnal Teknologi Informasi -Aiti: Fakultas Teknologi Informasi.