Page 1
Perancangan dan Impementasi Aplikasi Desktop Pengajuan
Anggaran Sistem Informasi Keuangan dan Akuntansi Satya
Wacana (SIKASA)
Studi Kasus : Universitas Kristen Satya Wacana, Salatiga
Artikel Ilmiah
Diajukan kepada
Fakultas Teknologi Informasi
Untuk memperoleh Gelar Sarjana Sistem Informasi
Peneliti :
Indra Prasetya
682015603
PROGRAM STUDI SISTEM INFORMASI
FAKULTAS TEKNOLOGI INFORMASI
UNIVERSITAS KRISTEN SATYA WACANA
SALATIGA
2016
Page 6
Perancangan dan Impementasi Aplikasi Desktop Pengajuan Anggara Sistem
Informasi Keuangan dan Akuntansi Satya Wacana (SIKASA)
Studi Kasus : Universitas Kristen Satya Wacana, Salatiga
1)Indra Prasetya,
2) 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]
Abstrak
Universitas Kristen Satya Wacana (UKSW) sudah menerapkan sistem informasi
keuangan dan akuntansi Satya Wacana untuk membantu dalam proses administrasi
berupa pencatatan semua pemasukan dan pengeluaran yang dilakukan oleh Universitas.
Namun ada beberapa fungsi yang belum ada seperti pengajuan anggaran non-rutin yang
belum dilakukan menggunakan sistem sehingga hanya bisa dilakukan dengan melakukan
inject langsng kedalam database, selain itu pada sistem lama pengguna dapat mengelola
data pada masa periode lampau sehingga hal tersebut memungkinkan untuk terjadinya
perubahan data yang sebenarnya sudah bersifat read-only. Dalam penelitian ini dengan
menggunakan metode prototype akan merancang dan mengimplementasikan sebuah
aplikasi dekstop pengajuan anggaran untuk sistem informasi keuangan dan akuntansi di
UKSW dengan tujuan untuk mempermudah bagian keuangan agar dapat melakukan
pengajuan anggaran non-rutin menggunakan sistem secara real-time. Serta membatasi
pengguna untuk mengelola pengajuan anggaran periode yang sedang berlangsung dan
periode yang akan datang saja.
Kata Kunci: Aplikasi Desktop, Sistem Infomasi Keuangan dan Akuntansi.
Abstract
Satya Wacana Christian University (SWCU) have applied information systems financial
and accounting to assist in the administrative process of recording all entry and
expenditure be undertaken by universities. But there is some function who has not yet
been as the submission of non routine budget that have not done use the system so that
can only be done by implementing inject directly into a database, in addition to the old
system users can manage data during the past period so that it is possible to change the
data that actually can not be changed. In this study by using the prototype method will
design and implement a desktop application budget submissions for financial and
accounting information systems in SWCU to facilitate the finance department in order to
perform non-routine budget submissions using the system in real-time. And limit users to
manage the budget submission period of on going and next periods only.
Keywords: desktop applications, financial and accounting information system.
_______________________________________________________________________ ¹Mahasiswa Fakultas Teknologi Informasi Universitas Kristen Satya Wacana
²Staff Pengajar Fakultas Teknologi Informasi Universitas Kristen Satya Wacana
³Staff Pengajar Fakultas Teknologi Informasi Universitas Kristen Satya Wacana
Page 7
1
1. Pendahuluan
Teknologi Informasi (TI) mampu membuat informasi menjadi lebih efisien
dan efektif, dengan hal ini banyak organisasi yang sudah memanfaatkan dan
berinovasi dalam TI untuk diterapkan dalam membantu proses bisnis.
Pemanfaatan TI secara baik dan tepat dapat membuat informasi dalam proses
bisnis menjadi lebih akurat, real time, relevan, ekonomis serta dapat membantu
dalam mengambil keputusan terkait dengan kebijakan manajemen. Dengan
pengambilan kebijakan yang tepat pada manajemen maka akan berdampak pada
kemajuan suatu organisasi sehingga organisasi tersebut akan siap bersaing dengan
organisasi lain. Oleh karena itu tidak dapat dipungkiri bahwa penggunaan IT
dalam suatu organisasi merupakan suatu keharusan terlebih pada organisasi
berskala besar seperti Universitas Kristen Satya Wacana (UKSW).
UKSW merupakan perguruan tinggi swasta yang berdiri sejak tahun 1956.
Pada tahun 2016 UKSW memiliki 15 fakultas dengan 56 Program Studi beserta
14.000 mahasiswa yang aktif registrasi. Dengan besarnya UKSW ini menuntut
adanya pengelolaan sistem administrasi keuangan dan akuntansi yang
professional dan saling terintegrasi untuk mengoptimalkan dalam memberikan
pelayanan pendidikan.
Pada tahun 1998 UKSW mulai menerapkan Sistem Informasi Akademik
Satya Wacana (SIASAT), proses utama pada sistem ini adalah proses registrasi,
pengambilan mata kuliah dan melihat nilai akademik oleh mahasiswa. Siasat juga
digunakan oleh dosen sebagai acuan untuk melakukan perwalian dan memberi
nilai atas matakuliah yang diampu. Pada awalnya SIASAT hanya sebatas sistem
dengan cakupan area intranet, karena kebijakan tertentu pada tahun 2004 SIASAT
sudah menjadi online dan dapat diakses dari mana saja menggunakan internet.
Sistem Manajemen Ruang (SIMANRU) juga dikembangkan dan diterapkan oleh
UKSW pada tahun 2012 untuk mengelola semua ruang yang ada di UKSW. Di
sisi lain pada tahun 2003 UKSW sudah mulai menerapkan Sistem Informasi
Keuangan dan Akuntansi Satya Wacana terkomputerisasi (SIKASA) berbasis
Website. Sikasa dirancang untuk mengelola pendapatan yang ditermia Universitas
secara umum dan mengelola pengeluaran UKSW baik aktivitas operasional
Universitas seperti gaji pegawai maupun pengeluaran yang dilakukan atas
kebijakan tertentu (khusus) yang dilakukan oleh UKSW. Sehingga sejak tahun
2003 UKSW melakukan kegiatan berupa pencatatan, pemrosesan dan pelaporan
keuangan dan akuntansi sudah berbasis komputer . Namun pada SIKASA ini
masih memiliki beberapa kelemahan berupa durasi yang dibutuhkan unit/subunit
untuk melakukan kegiatan pencatatan/pelaporan cukup lama, unit/subunit bisa
secara bebas melakukan perubahan terhadap data lama dan belum terpenuhinya
beberapa fungsi seperti pengajuan anggaran yang hanya bisa dilakukan untuk
kelompok pengajuan anggaran rutin dan discretionary saja. Sehingga untuk
pengajuan anggaran kelompok non-ruitn masih dilakukan dengan cara inject
langsung ke dalam database di mana cara seperti ini cukup berbahaya karena jika
perubahan data dilakukan langsung melalui database data tidak akan bisa di-filter
oleh aplikasi, hal ini juga akan mempengaruhi kinerja database serta aplikasi
SIKASA. Oleh sebab itu diperlukan sebuah sistem yang mampu melakukan
Page 8
2
pengajuan anggaran untuk kelompok rutin, discretionary dan juga non-rutin
secara baik serta bisa melakukan pencatatan dan pelaporan pengajuan anggaran
dengan waktu singkat untuk megelola data pengajuan anggaran dalam periode
buku yang sedang berlangsung dan periode yang akan datang saja.
Dari permasalahan di atas maka penulis akan merancang sekaligus
mengimplementasikan aplikasi desktop sistem informasi keuangan dan akuntansi
Satya Wacana khusus dalam pengajuan anggaran yang mampu melakukan
pengajuan kelompok rutin, discretionary dan non-rutin untuk data pengajuan
anggaran periode yang sedang berlangsung dan periode yang akan datang beserta
pelaporan pengajuan anggaran. Aplikasi desktop ini nantinya akan digunakan oleh
semua unit/subunit kerja yang ada di lingkungan UKSW serta dapat digunakan
oleh universitas pusat (bagian keuangan) untuk mengelola dan memantau semua
pengajuan anggaran yang dilakukan oleh unit/subunit.
2. Kajian Pustaka
2.1 Penelitian terdahulu
Penelitian yang dilakukan oleh Wina Setiawati dengan judul “Aplikasi
Laporan Keuangan Berbasis Web Untuk Kelurahan Dukuh” melakukan
perancangan sistem dengan menggambarkan alur proses bisnis aplikasi dengan
diagram Data Flow Diagram (DFD), perancangan database yang digambarkan
menggunakan Entity Relation Diagram (ERD) serta menggunakan Dreamweaver
sebagai editor, bahasa pemrogaman PHP , MySQL sebagai database serta ajax
untuk menunjang tampilan yang efektif. Hasil dari perancangan ini adalah
membuat proses pelaporan keuangan yang dilakukan secara manual menjadi
terotomatisasi dan mempermudah dalam pengelolaan dan akses bagi warga untuk
mengetahui perihal anggaran kelurahan Dukuh [1].
Penelitian dengan judul “Rancang Bangun Sistem Informasi Pengelolaan
Keuangan Daerah (Studi Kasus pada SKPD dinas Energi dan Sumber Daya
Mineral Kabupaten Kepulauan Sangihe)” Penelitian ini membahas perancangan
dan membangun sebuah aplikasi keuangan berbasis desktop yang sebelumnya
belum ada pada dinas terkait, untuk memudahkan proses penatausahaan
pengeluaran yaitu pengajuan dana dan pembuatan laporan dengan menggunakan
metode FAST (Framework for Application of System Thinking) dengan
microsoft Visual Basic 8.0 dan database MYSQL [2].
Dari penelitian-penelitian terdahulu yang pernah dilakukan terkait
perancangan dan pembangunan aplikasi keuangan, penelitian ini dengan judul
“Perancangan dan Implementasi Aplikasi Desktop Pengajuan Anggaran Sistem
Informasi Keuangan dan Akuntansi Satya Wacana (SIKASA) Studi Kasus:
Universitas Kristen Satya Wacana, Salatiga” membahas mengenai merancang dan
membangun sebuah aplikasi keuangan berbasis desktop tingkatan Universitas
menggunakan visual studio bahasa pemrograman .Net yaitu VB.Net dan C#
dengan menggunakan web service dan Json sebagai penghubung antara front-end
serta back-end . Aplikasi ini ditujukan untuk bagian keuangan Universitas Satya
Wacana yang mengelola anggaran untuk memudahkan dalam menjalankan proses
bisnis sesuai dengan prosedur yang ada.
Page 9
3
2.2 Landasan Teori
Sistem informasi merupakan seperangkat prosedur yang terorganisasi
dengan sistematik yang jika akan dilaksanakan akan menyediakan informasi yang
dapat dimanfaatkan dalam proses pembuatan keputusan [3]. Pada suatu sistem
informasi juga terdapat perancangan sistem, dimana perancangan sistem adalah
suatu fase dimana diperlukan suatu keahlian perancangan untuk elemen-elemen
komputer yang akan mengunakan sistem yaitu pemilihan peralatan dan program
komputer untuk sistem yang baru. Tujuan dari perancangan sistem informasi
adalah untuk memenuhi kebutuhan pemakaian sistem (user) dan untuk
memberikan gambaran yang jelas dan menghasilkan rancangan bangun yang
lengkap kepada pemograman komputer dan ahli-ahli teknik lainnya yang terlibat
dalam pengembangan atau pembuatan sistem [4].
Impelentasi adalah suatu tindakan atau pelaksanaan dari sebuah rencana
yang sudah disusun secara matang dan terperinci. Implementasi biasanya
dilakukan setelah perencanaaan sudah dianggap fix. Sedangkan implementasi
sistem adalah prosedur yang dilakukan untuk menyelesaikan desain yang ada
dalam dokumen desain sistem yang disetujui dan menguji, meng instal, memulai
menggunakan sistem yang baru atau sistem yang diperbaiki [5].
Anggaran merupakan suatu rencana yang disusun secara sistematis dalam
bentuk angka dan dinyatakan dalam unit moneter yang meliputi seluruh kegiatan
perusahaan untuk jangka waktu (periode) tertentu di masa yang akan datang. Oleh
karena rencana yang disusun dinyatakan dalam bentuk unit moneter, maka
anggaran seringkali disebut juga dengan rencana keuangan. Dalam anggaran,
satuan kegiatan dan satuan uang menempati posisi penting dalam arti segala
kegiatan akan dikuantifikasikan dalam satuan uang, sehingga dapat diukur
pencapaian efisiensi dan efektivitas dari kegiatan yang dilakukan [6].
Akuntansi merupakan suatu sistem pencatatan seluruh aktivitas keuangan
organisasi dan dapat menghasilkan laporan keuangan yang dapat digunakan para
pemilik kepentingan dalam mengambil keputusan. Proses administrasi akuntansi
saat ini sudah memanfaatkan IT dalam pelaksanaanny. Implementasi IT dalam
proses administrasi akuntansi ini seringkali disebut dengan Sistem Informasi
Akuntansi [7].
Gambar 1. Arsitektur web service.
Web service dapat diartikan juga sebuah metode pertukaran data, tanpa
memperhatikan di mana sebuah database ditanamkan, dibuat dalam bahasa apa
Page 10
4
sebuah aplikasi yang mengkonsumsi data, dan di platform apa sebuah data itu
dikonsumsi. Web service mampu menunjang interoperabilitas. Sehingga web
service mampu menjadi sebuah jembatan penghubung antara berbagai sistem
yang ada [8].
3. Metode Penelitian
Dengan menggunakan metode penelitian kualitatif, identifikasi dan
perumusan masalah didapat berdasarkan interaksi wawancara secara langsung
dengan developer SIKASA lama, unit/subunit dan bagian keuangan selaku
pengguna SIKASA. Selanjutnya adalah perancangan sistem menggunakan metode
prototype, setelah sistem berhasil dibuat maka akan dilakukan testing dan akan
diimplementasikan setelah semua fungsi dinyatakan berjalan dan disetujui oleh
tester. Pada tahap akhir akan dilakukan monitoring dan evaluasi.
Gambar 2. Tahapan penelitian.
Dari tahapan identifikasi dan perumusan masalah diketahui bahwa pada
modul pengajuan anggaran SIKASA lama hanya bisa melakukan pengajuan
anggaran untuk kelompok rutin dan discretionary saja, sedangkan untuk
kelompok non-rutin dilakukan dengan cara inject langsung kedalam database. Hal
ini menyebabkan bagian keuangan tidak bisa melakukan pengajuan anggaran
non-rutin secara mandiri dengan menggunakan sistem karena harus meminta
bantuan kepada bagian IT untuk melakukan inject database. Selain itu pengajuan
Tahapan 1: Identifikasi dan perumusan masalah
Hasil yang diharapkan : user-reqirement
Tahapan 2: Perancangan dan pengembangan sistem menggunakan metode
prototype
Hasil yang diharapkan : Aplikasi desktop pengajuan anggaran
Tahapan 3: Testing
Hasil yang diharapkan : Perbaikan aplikasi desktop pengajuan anggaran
Tahapan 4: Implementasi
Hasil yang diharapkan : instalasi untuk mulai digunakan user
Tahapan 5: Monitoring dan evaluasi
Hasil yang diharapkan : Memantau dan mengevaluasi sistem
Page 11
5
anggaran yang dilakukan dengan cara inject tidak akan ada proses filter data
sehingga besar kemungkinan terjadi kesalahan. Pengajuan anggaran non-rutin
tidak memiliki batasan periode sehingga bisa dilakukan kapan saja. Data yang
dapat dikelola hanya data pengajuan anggaran non rutin untuk periode buku yang
sedang berlangsung dan periode buku yang akan datang saja. Dari permasalahan
pokok yang ditemukan maka perancangan sistem pengajuan anggaran akan fokus
untuk menyelesaikan permasalahan pengajuan anggaran kelompok non-rutin.
Pengajuan anggaran kelompok non-rutin hanya bersifat sebagai pencatatan saja.
Pada pengajuan anggaran kelompok rutin dan discretionary dimana daftar
anggaran yang diajukan oleh setiap unit kerja akan di-review oleh Komite
Anggaran UKSW kemudian akan diputuskan mata anggaran mana saja yang
disetujui, diperbaiki atau dibatalkan secara bersama-sama dengan pimpinan unit
kerja (Perwalian Anggaran). Berbeda dengan anggaran kelompok non-rutin,
berikut adalah diagram alur mengenai pengajuan anggaran non-rutin :
Start
Persetujuan Rapat pembina oleh Pimppinan
dan Yayasan
Pengajuan anggaran oleh
jajaran pimpinan
ke yayasan
Hasil rapat persetujuan
anggaran
Disetujui
A
A
Ya
Tidak
Input data pengajuan
anggaran non rutin
Simpan pengajuan
Cetak Laporan pengajuan
Penandatanganan laporan
End
Realisasi anggaran
Gambar 3. Diagram flowchart proses bisnis pengajuan anggaran non rutin.
Alur dari pengajuan anggaran non rutin sedikit berbeda dengan pengajuan
anggaran lainnya. Pengajuan anggaran non rutin tetap memiliki tahap perencanaan
di mana yang melakukan perencanaan adalah jajaran pemimpin di Universitas
yang nantinya akan diajukan pada tingkat Yayasan karena sumber dana anggaran
non rutin adalah dari Yayasan, pada tahap pengajuan ini banyak sekali
pertimbangan yang dilakukan seperti tingkat urgent hingga nominal pengajuan
yang dipengaruhi oleh pengajuan anggaran sebelumnya. Setelah pengajuan
dilakukan pada waktu tertentu akan diadakan rapat pembina oleh pimpinan
Universitas dan Yayasan yang mengulas persetujuan setiap anggaran yang
Page 12
6
diajukan. Hasil dari tahapan ini adalah menentukan anggaran mana saja yang akan
disetujui, ditunda atau ditolak. Jika terjadi penolakan pengajuan anggaran bisa
dilakukan pengajuan atas kebutuhan yang sama pada periode selanjutnya, jika
anggaran disetujui maka data dari pengajuan anggaran akan dimasukan ke dalam
sistem pengajuan anggaran non-rutin oleh bagian keuangan untuk disimpan
sebagai pencatatan kemudian daftar pengajuan anggaran akan dicetak untuk
dimintakan tanda tangan oleh Bagian Keuangan, Pimpinan Unit Anggaran dan
Unit Anggaran untuk diarsipkan. Tahapan terakhir adalah merealisasikan
anggaran yang telah diajukan untuk digunakan sesuai dengan perencanaan.
Pada tahapan perancangan dan pengembangan sistem ini dilakukan
menggunakan metode prototype.
Gambar 4. Tahapan pengembangan sistem dengan metode Prototype [9].
Mulai dari tahapan listen to customer di mana sistem yang akan dibangun
dibagi menjadi 2 halaman utama. Halaman rangkuman untuk menampilkan data
pengajuan anggaran kelompok non-rutin yang telah diajukan oleh unit/subunit
pada periode yang sedang berlangsung dan yang akan datang. Kemudian halaman
pengajuan anggaran non-rutin yang digunakan untuk mengajukan anggaran oleh
unit/subunit dan bagian keuangan di mana jumlah pengajuan untuk setiap
unit/subunit bisa lebih dari 1 rekening sekaligus. Pada halaman rangkuman
terdapat fitur pembatalan pengajuan dengan syarat dana yang dibatalkan tidak
boleh lebih dari sisa anggaran yang tersedia oleh setiap rekening dalam
unit/subunit. Kedua halaman harus memiliki fitur laporan untuk melakukan print-
out data pengajuan anggaran kelompok non-rutin. Dalam metode prototype
tahapan selanjutnya adalah mulai mengembangkan sistem. Aplikasi ini dibangun
dengan bahasa vb.net sebagai front-end dan C# sebagai back-end dan
dihubungkan dengan web-service dan Json. Database yang digunakan adalah
SQL Server dan pelaporan yang menggunakan crystal report. Setelah aplikasi jadi
maka tahapan selanjutnya adalah uji coba yang dilakukan oleh user dan mendapat
masukan untuk perbaikan aplikasi sampai aplikasi sesuai dengan permintaan dan
bisa berjalan lancar. Use Case dari pengajuan anggaran dapat dilihat pada gambar
5.
Page 13
7
<<Extend>>
Bagian Keuangan
Lihat RangkumanPengajuan Anggaran Non-rutin
Pengajuan Anggarannon-rutin
Pembatalan pengajuanAnggaran non-rutin
Cetak Rangkumananggaran non-rutin
<<Extend>>
<<Include>>
<<Extend>>
Ubah
Tambah Hapus
<<Extend>> Cetak daftarpengajuan anggaran non-rutin
<<Include>>
Gambar 5. Diagram Use case pengajuan anggaran non-rutin
Terdapat 1 aktor yaitu begian keuangan di mana bagian keuangan bisa
melihat rangkuman pengajuan anggaran non-rutin. Bagian keuangan juga
memiliki kemampuan untuk membatalkan pengajuan dan mencetak rangkuman
anggaran sebagai pelaporan. Bagian keuangan juga bisa mengelola pengajuan
anggaran non-rutin serta dapat mencetak untuk ditanda tangani bagian keuangan,
pimpinan unit dan unit anggaran. Alur pengajuan anggaran non-rutin dapat dilihat
pada gambar 6.
Gambar 6. Diagram Activity Pengajuan anggaran non-rutin
Dari diagram aktivity dapat dilihat runtutan bagian keuangan ketika
mengajukan anggaran non-rutin. Pengajuan anggaran non-rutin bisa dilakukan
lebih dari 1 rekening dalam sekali pengajuan oleh unit. Pengajuan anggaran hanya
bersifat sebagai pencatatan sehingga data hanya bisa diajukan oleh bagian
Pengajuan
anggaran non-rutin
Memilih
unit/sub-unit
Tambah
pengajuan
menentukan
rekening
Menentukan jumlah
pengajuan dan keterangan
Simpan
Simpan
pengajuan
Menampilkan form
pengajuan anggaran
Menampilkan form
tambah pengajuan
Menampilkan
sisa anggaran
Simpan
temporary
Tambah data
pengajuan ?
ya
tidak
Simpan kedalam
database
SistemBagian Keuangan
Page 14
8
keuangan dan anggaran yang sudah diajukan tidak perlu diproses untuk ke tahap
perwalian anggaran seperti anggaran kelompok rutin dan discretionarry. Struktur
dan relasi database yang digunakan khusus untuk pengajuan anggaran non-rutin
dapat dilihat pada gambar 7.
Gambar 7. Struktur dan relasi database yang digunakan khusus anggaran non-rutin
Terdapat 8 tabel yang digunakan dalam pengajuan anggaran non-rutin.
Tabel yang bersifat master/ sebagai acuan seperti tabel “Tuser”, “PeriodeBuku”,
“TUnit”, “Rekening”, “MasterKelompok” dan “MasterSatuan” serta memiliki
tabel utama yaitu “AnggaranNR” dan “DetailAnggaranNR”. Setiap pengajuan
anggaran non-rutin akan memiliki 1 baris inti yang disimpan sebagai header
dalam tabel AnggaranNR. Karena setiap pengajuan anggaran non-rutin bisa
memilki lebih dari 1 item rekening pengajuan maka item-item tersebut akan
disimpan pada tabel DetailAnggaranNR. Yang bertugas untuk berhubungan
dengan database adalah back-end. Class utama pada back-end memiliki banyak
fungsi yaitu GetPeriodeAnggaranAktif(), GetPeriode AnggaranSelanjutnya(),
AmbilListComboUnit(), AmbilListComboUnitAll(), Ambil
ListComboRekening(), CariListAnggaranNonRutin(), SimpanDaftarPengajuan
AnggaranNonRutin() dan SimpanBatalDaftarPengajuanAnggaranNonRutin().
Fungsi-fungsi ini dihubungkan melalui web-service yang dikemas menggunakan
Json.
Setelah aplikasi berhasil dibuat maka selanjutnya adalah tahapan testing.
Tahapan testing ini dilakukan dengan berbagai macam metode dan banyak tester.
Testing awal dilakukan oleh internal team programmer dengan menggunakan
metode blackbox, jika inputan dan output sesuai maka aplikasi dinyatakan siap
untuk diperlihatkan ke user. Namun jika output tidak sesuai / output sesuai tetapi
membutuhkan waktu lama dan tidak efisien maka akan dilakukan uji
menggunakan metode whitebox di mana aplikasi akan dibedah dan diteliti untuk
setiap baris pengkodean agar aplikasi bekerja lebih maksimal. Testing berikutnya
dilakuklan oleh user secara langsung serta diadakan pelatihan terhadap aplikasi
Page 15
9
SIKASA baru oleh setiap unit/subunit secara berkala. Pada tahapan ini user
berhak melakukan uji coba semua fitur/fungsi yang ada pada aplikasi SIKASA
baru.
Ketika aplikasi dinyatakan siap untuk digunakan dan user sudah melakukan
persetujuan maka tahapan selanjutnya adalah implementasi. Implementasi
dilakukan dengan cara menaruh aplikasi inti dan database di ruang server.
Kemudian shortcut dari aplikasi SIKASA akan didistribusikan ke seluruh
unit/subunit untuk digunakan dalam mengakses aplikasi. Pada gambar 8 dapat
dilihat diagram deployment dari modul pengajuan anggaran berbasis desktop.
Gambar 8. diagram deployment dari modul pengajuan anggaran berbasis desktop.
Diagram deployment dapat menggambarkan tahap implementasi, pada
personal computer (PC) yang digunakan bagian keuangan hanya memiliki
shortcut yang sudah didistribusikan dan bersumber dari AppServer di mana pada
AppServer merupakan pusat aplikasi SIKASA secara utuh (front-end) dan
memiliki business layer yang berasal dari web-services di mana web-service
adalah bagian yang mampu berhubungan dengan database SIKASA.
Setelah aplikasi terpasang tahap selanjutnya adalah monitoring dan evalusei.
Monitoring dan evaluasi sangat dibutuhkan karena pengembangan SIKASA lama
ke SIKASA baru dilakukan menggunakan cara migrasi sistem cut-off. Dimana
SIKASA lama dihentikan seketika dan digantikan langsung dengan SIKASA yang
baru. Sehingga sangat memungkinkan suatu waktu terjadi error dan memerlukan
penanganan secara cepat oleh team programmer. Kemudian dari error yang
didapat dari hasil monitoring akan dilakukan evaluasi untuk perbaikan sistem.
4. Hasil dan Pembahasan
Hasil dari pengembangan sistem Prototype tahap awal adalah halaman
rangkuman anggaran non-rutin dan juga halaman pengajuan anggaran non-rutin.
Pada pengajuan anggaran non-rutin hanya memiliki fungsi tambah pengajuan,
ubah pengajuan dan hapus pengajuan yang disimpan secara temporary
menggunakan data table. Setelah penambahan pengajuan selesai dilakukan maka
bisa menekan tombol simpan yang sudah disediakan untuk menyimpan kedalam
database. Proses simpan kedalam database dilakukan dengan memberikan daftar
anggaran yang diajukan dari data table dari front-end ke back-end melalui web
service yang dikemas ke dalam Json. Sedangkan pada halaman rangkuman hanya
memiliki fungsi mengambil data pengajuan anggaran saja yang didapat dari back-
end melalui web service. Pada prototype tahap awal pelaporan berupa daftar
Web Service DatabasePC Bagian
Keuangan (Client)+ Back-end +Sql Server
App Server
(.Net, Json)
+ Front-end
(.Net, Json)+Distribusi ShortcutAplikasi
Page 16
10
pengajuan anggaran secara keseluruhan atau berdasarkan unit/subunit tertentu.
Setelah prototype tahap awal selesai dilakukan testing oleh team programmer dan
mendapatkan beberapa hasil evaluasi yaitu : Ketika melakukan penambahan
pengajuan anggaran, setelah memilih rekening yang akan diajukan nominal sisa
anggaran tetap 0. Setalah melakukan pengajuan anggaran, pada halaman
rangkuman tidak bisa melihat detail dari setiap transaski yang telah diajukan.
Dikarenakan aplikasi belum memenuhi semua kebutuhan user , maka dilakukan
prototype tahap kedua.
Prototype tahap kedua merupakan perbaikan dari hasil evaluasi prototype
tahap pertama. Dimulai dengan penyempurnaan fungsi untuk mendapatkan
nominal sisa anggaran setelah user memilih rekening yang diajukan. Kemudian
penambahan fitur untuk melihat detail dari transaksi yang sudah dilakukan dengan
menekan kolom nomor bukti transaksi pada halaman rangkuman anggaran.
Setelah perbaikan aplikasi dilakukan, testing dilakukan kembali dan mendapatkan
beberapa point evaluasi yaitu: sisa anggaran sudah secara otomatis muncul sesuai
dengan rekening yang dipilih oleh user. Detail anggaran non-rutin yang sudah
diajukan bisa tampil sesuai dengan apa yang diinputkan oleh user. Penambahan
fungsi untuk membatalkan pengajuan anggaran non-rutin pada halaman
rangkuman anggaran dengan syarat nominal anggaran yang dibatalkan tidak boleh
meliebihi sisa anggaran yang ada sesuai dengan permintaan user.
Prototype tahap tiga dilakukan untuk perbaikan berdasarkan hasil evaluasi
prototype tahap dua. Dilakukan penambahan fungsi pembatalan pengajuan
anggaran non-rutin dari back-end yang diakses melalui web-service serta dipicu
oleh tombol batal yang diletakkan pada halaman rangkuman anggaran. Hasil
evaluasi dari prototype tahap tiga ini adalah fitur pembatalan pengajuan anggaran
sudah berjalan dengan baik dilengkapi dengan form untuk menampung
keterangan/alasan user melakukan pembatalan. Pada bagian pelaporan user
meminta untuk merubah format di mana terdapat tambahan keterangan perihal
pengajuan anggaran dan disertakan kolom untuk tanda tangan bagian keuangan,
pimpinan unit anggaran dan unit anggaran untuk persetujuan atas pengajuan
anggaran non-rutin yang telah diajukan.
Prototype tahap akhir adalah perbaikan dari prototype tahap tiga di mana
dilakukan perubahan pada format pelaporan. Hasil dari evaluasi prototype tahap
akhir ini adalah pelaporan yang sesuai dengan permintaan user. Pada prototype
tahap akhir ini juga dilakukan penambahan validasi untuk melakukan checking
pada setiap inputan yang dilakukan oleh user.
Setelah prototype sudah dalam tahap akhir dan telah dilakukan test akhir
secara keseluruhan maka aplikasi bisa digunakan oleh user untuk menjalankan
proses bisnis pangajuan anggaran non-rutin. Bagian keuangan Universitas bisa
melakukan pengajuan anggaran ke dalam sistem berdasarkan hasil rapat
persetujuan pimpinan Universitas dengan Yayasan yang telah melakukan
persetujuan anggaran non-rutin. Ketika pengajuan telah dilakukan, bagian
keuangan wajib mencetak laporan untuk ditanda tangani oleh pihak terkait perihal
persetujuan sebelum dilakukan pengambilan dana anggaran yang diajukan.
Nominal dari pengajuan anggaran tidak bisa diubah karena bersifat pasti, bagian
Page 17
11
keuangan bisa melakukan pembatalan pengajuan anggaran sebelum dana
terealisasikan dengan menyertakan alasan tertentu.
Aplikasi desktop pengajuan anggaran non-rutin pada sistem informasi
keuangan dan akuntansi ini memiliki dua halaman utama sesuai dengan hasil
wawancara dengan user. Halaman rangkuman anggaran non-rutin dan juga
halaman pengajuan. Pada halaman rangkuman user dapat melihat anggaran non-
rutin yang sudah diajukan untuk periode buku yang akan datang.
Gambar 9. Tampilan rangkuman anggaran non-rutin
Tampilan rangkuman anggaran non-rutin memiliki pilihan filter berupa
tanggal transaski dan juga unit yang sifatnya optional. Filter ini digunakan ketika
user ingin melihat data anggaran non-rutin yang sudah diajukan berdasarkan
tanggal atau unit tertentu. Ketika user tidak melakukan filter maka seluruh data
pengajuan anggaran non-rutin periode buku yang akan datang akan tampil secara
keseluruhan dengan menekan tombol “Cari”. Pada bagian bawah terdapat tombol
“Batalkan Pengajuan Anggaran Non-Rutin” yang digunakan untuk membatalkan
pengajuan anggaran non-rutin secara permanen dengan cara memilih item pada
data rangkuman kemudian menekan tombol pembatalan, maka secara otomatis
data yang dipilih akan hilang dengan syarat pembatalan hanya bisa dilakukan
ketika sisa anggaran melebihi dari nominal anggaran yang dibatalkan. Ketika
syarat tidak terpenuhi maka akan muncul pesan notifikasi bahwa anggaran gagal
untuk dibatalkan. Pada halaman rangkuman user juga bisa mencetak data. Data
pada laporan akan sama serperti data yang tampil pada halaman rangkuman.
Page 18
12
Gambar 10. Tampilan laporan rangkuman anggaran non-rutin
Pada gambar 10 merupakan tampilan format dari pelaporan dari data
rangkuman anggaran non-rutin. User juga bisa melihat setiap detail pengajuan
anggaran non-rutin. Data yang tampil pada rangkuman merupakan headernya
saja. Sedangkan dalam 1 data header bisa memiliki lebih dari 1 item rekening
pengajuan anggaran non-rutin.
Gambar 11. Tampilan Detail rangkuman anggaran non-rutin
Pada gambar 11 merupakan tampilan ketika user menekan kolom nomor
bukti transaksi pada halaman rangkuman. Fitur ini ditujukan untuk melihat
kembali data yang sudah diajukan secara detail. Pada fitur ini data tidak bisa
ditambah, diubah atau dihapus. Halaman berikutnya adalah halaman pengajuan
anggaran, pengajuan anggaran dapat diakses dengan cara menekan tombol
“Pengajuan anggaran non-rutiin” pada halaman rangkuman. Halaman pengajuan
digunakan oleh bagian keuangan untuk mengajukan anggaran.
Page 19
13
Gambar 12. Tampilan halaman pengajuan anggaran non-rutin
Pada halaman pengajuan terdapat filter di mana user dapat memilih
unit/subunit mana yang akan melakukan pengajuan anggaran non-rutin.
Kemudian user bisa menekan tombol “Tambah” untuk menambah item
pengajuan.
Gambar 13. Tampilan pop-up tambah anggaran non-rutin
Pada menu tambah maka akan ada kolom yang bersifat read only seperti
tanggal transaksi yang diambil tanggal real time pada waktu melakukan
pengajuan anggaran, periode anggaran yang diambil secara otomatis dari periode
buku anggaran yang akan datang/selanjutnya dan unit/subunit yang secara
otomatis terisi berdasarkan unit/subunit yang dipilih dari halaman pengajuan
anggaran. Selanjutnya user bisa memilih rekening mana yang akan diajukan
sebagai anggaran non-rutin, kemudian secara otomatis data sisa anggaran untuk
rekening yang dipilih oleh user akan muncul. Data sisa anggaran digunakan
sebagai acuan untuk mengisikan jumlah pengajuan dan yang terakhir user bisa
Page 20
14
memberi keterangan tertentu bila diperlukan yang bersifat optional. Setelah semua
terisi maka tekan tombol simpan pada menu pop-up tambah anggaran. Maka item
yang sudah ditambahkan tadi akan masuk kedalam list pengajuan di mana masih
bersifat simpan sementara/temporary. Data yang masih berada dalam list
memungkinkan untuk diolah seperti diubah / dihapus dari list. Setelah proses
pengelolaan data selesai tekan tombol simpan yang berada pada halaman
pengajuan anggaran. Sehingga data yang sudah diajukan akan tersimpan kedalam
database. User juga bisa melakukan pelaporan pengajuan anggaran. Format
pelaporan dari pengajuan anggaran non-rutin bisa dilihat pada gambar 14.
Gambar 14. Tampilan pelaporan pengajuan anggaran non-rutin
Pada tampilan pelaporan pengajuan bagian atas kiri terdapat keterangan
yang menyertakan nomor transasksi, unit yang mengajukan dan keterangan. Pada
bagian kanan atas terdapat judul laporan, tahun anggaran, tanggal cetak, tanggal
pengajuan dan nomor bukti. Nominal jumlah total akan secara otomatis dihitung
oleh sistem. Laporan pengajuan ini dicetak juga untuk ditanda tangani bagian
keuangan, Pimpinan Unit Anggaran dan Unit anggaran.
Untuk memastikan semua fungsi berjalan dengan baik pada aplikasi desktop
pengajuan Anggaran non-rutin Sistem Informasi Keuangan dan Akuntansi Satya
Wacana dilakukan testing tahap akhir. Dalam pengujian ini menggunakan metode
pengujian black-box testing. Black-box testing adalah pengujian aspek
fundamental sistem tanpa memperhatikan struktur logika internal perangkat lunak
yang diuji. Pengujian black box merupakan metode perancangan data uji yang
didasarkan pada spesifikasi perangkat lunak. Data diuji (input), dieksekusi
(proses) pada perangkat lunak kemudian keluaran (output), dari perangkat lunak
dicek apakah telah sesuai dengan yang diharapkan atau masih perlu pebaikan [10].
Berikut adalah tabel pengujian black-box pada aplikasi desktop pengajuan
anggaran non-rutin:
No Skenario Pengujian Test Case Hasil yang diharapkan Hasil
Uji
1 Testing fungsi
GetPeriodeAnggaranA
Memanggil
fungsi ketika
Dapat mengambil periode
angaran aktif dari tabel
Valid
Page 21
15
ktif() form load periode buku
2 Testing fungsi
GetPeriodeAnggaranS
elanjutnya()
Memanggil
fungsi ketika
form load
Dapat mengambil periode
angaran aktif dari tabel
periode buku
Valid
3 Testing fungsi
AmbilListComboUnit
All()
Memanggil
fungsi ketika
form load
Dapat menampilkan daftar
semua unit kerja kedalam
combo box unit
Valid
4 Testing fungsi
CariListAnggaranNon
Rutin()
Tanpa
menggunakan
filter
Dapat menampilkan semua
data pengajuan anggaran
Valid
5 Testing fungsi
CariListAnggaranNon
Rutin()
Menggunakan
filter unit
Dapat menampilkan data
pengajuan anggaran yang
diajukan oleh unit terpilih
saja
Valid
6 Testing fungsi
CariListAnggaranNon
Rutin()
Menggunakan
filter tanggal
transaksi
Dapat menampilkan data
pengajuan anggaran yang
diajukan pada tanggal
transaski terpilih saja
Valid
7 Testing fungsi
CariListAnggaranNon
Rutin()
Menggunakan
filter unit dan
tanggal
transaksi
Dapat menampilkan data
pengajuan anggaran yang
diajukan oleh unit terpilih
dan pada tanggal transaski
terpilih saja
Valid
8 Menekan tombol print Data
rangkuman
kosong
Muncul pesan “Tidak ada
data untuk dicetak”
Valid
9 Menekan tombol print Tersedia data
rangkuman
Muncul halaman print
priview dengan data sesuai
pada halaman rangkuman
Valid
10 Menekan kolom link
No.Bukti Transaksi
Muncul halaman yang
menampilkan detail dari
transasksi terpilih
Valid
11 Menekan tombol Batal
Pengajuan Anggaran
Non Rutin
Transaksi terpilih akan
terhapus
Valid
12 Menekan tombol
Pengajuan anggaran
Non Rutin
Akan berpindah ke halaman
pengajuan
Valid
13 Menekan tombol
Selesai
Akan keluar dari modul
pengajuan anggaran non-rutin
Valid
Tabel 1. Tabel pengujian black box pada semua fungsi halaman rangkuman.
No Skenario Pengujian Test Case Hasil yang diharapkan Hasil
Uji
1 Menekan tombol
Tambah
Akan muncul halaman
tambah pengajuan
Valid
2 Testing fungsi simpan
tambah pengajuan
Tanpa
mengisikan
kolom
rekening
Muncul pesan peringatan
“Rekening belum diisi” dan
proses tambah pengajuan
gagal
Valid
Page 22
16
3 Testing fungsi simpan
tambah pengajuan
Tanpa
mengisikan
kolom Jumlah
pengajuan
Muncul pesan peringatan
“Jumlah pengajuan belum
diisi” dan proses tambah
pengajuan gagal
Valid
4 Testing fungsi simpan
tambah pengajuan
Tanpa
mengisikan
kolom
keterangan
Tambah pengajuan anggaran
berhasil dilakukan, data
disimpan kedalam datatable
Valid
5 Mengisi kolom jumlah
pengajuan
Isi dengan
huruf
Tidak akan terjadi perubahan
pada kolom jumlah pengajuan
Valid
6 Testing fungsi
GetSisaAnggaran()
setelah
memilih
rekening
Secara otomatis sisa anggaran
akan tampil pada kolom sisa
anggaran
Valid
7 Menekan tombol Reset
pada halaman tambah
pengajuan
Kolom rekening,sisa
anggaran, jumlah pengajuan
dan keterangan akan kosong
Valid
8 Menekan tambal batal
pada halaman tambah
pengajuan
Akan kembali ke halaman
pengajuan tanpa
menambahkan/ merubah data
data
Valid
9 Menekan kolom ubah
pada transaksi
pengajuan anggaran
Menampilkan halaman
tambah pengajuan anggaran
dengan kelengkapan data
terpilih
Valid
10 Menekan tombol
simpan dengan status
mengubah data
Perubahan
data pada
rekening dan
atau jumlah
pengajuan dan
atau
keterangan
Data akan disimpan ke dalam
data table, akan kembali ke
halaman pengajuan dengan
daftar data yang terbaru/
setelah perubahan dilakukan
Valid
11 Menekan kolom hapus
pada transaksi
pengajuan anggaran
Data pengajuan yang terpilih
akan dihapus dari datatable
dan daftar pengajuan
Valid
12 Testing total pengajuan Setaip ada penambahan,
perubahan dan penghapusan
data, pada kolom total akan
secara terisi dari akumulasi
kolom jumlah pengajun.
Valid
13 Testing fungsi
SimpanDaftarPengajua
n AnggaranNonRutin()
dengan menekan
tombol simpan
Daftar pengajuan yang telah
ditambahkan akan tersimpan
ke dalam database, dan akan
kembali pada halaman
rangkuman
Valid
14 Menekan tombol batal Akan kembali pada halaman
rangkuman tanpa melakukan
penambahan data apapun
Valid
Tabel 2. Tabel pengujian black box pada semua fungsi halaman Pengajuan.
Page 23
17
5. Simpulan
Berdasarkan penelitian yang telah dilakukan serta hasil pembahasan yang
dilakukan dengan judul Perancangan dan Implementai Aplikasi Desktop
Pengajuan Anggaran Sistem Informasi Keuangan dan Akuntansni Satya Wacana
(SIKASA) studi kasus: Universitas Kristen Satya Wacana Salatiga, dapat
disimpulkan sebagai berikut :
Aplikasi desktop pengajuan anggaran non-rutin SIKASA memudahkan
bagian Keuangan UKSW untuk mencatat pengajuan anggaran non-rutin ke dalam
sistem yang disimpan menggunakan database dan juga telah menggantikan cara
lama yaitu memasukan pengajuan anggaran melalui inject database secara
langsung. Dengan cara memasukan data pengajuan anggaran non-rutin melalui
sistem, maka kecil kemungkinan terjadi kesalahan input, karena sistem dilengkapi
dengan validasi dan bagian Keuangan hanya bisa mengelola pengajuan anggaran
pada periode buku yang sedang berlangsung dan periode buku yang akan datang
saja.
Setelah memasukan data pengajuan anggaran, bagian keuangan bisa dengan
mudah mencetak laporan pengajuan anggaran non-rutin untuk dimintakan tanda
tangan Bagian Keuangan, Pimpinan Unit Anggaran dan Unit Anggaran untuk
disimpan sebagai arsip anggaran non-rutin. Saat terjadi pembatalan pengajuan
anggaran oleh Pimpinan Universitas maupun Yayasan, bagian Keuangan bisa
melakukan pembatalan pada sistem pengajuan anggaran non-rutin dengan
menyertakan alasan dilakukan pembatalan.
Aplikasi SIKASA dapat dikembangkan lagi terutama pada bagian
pemanfaatan database yang perlu memanfaatkan stored procedure dan juga
trigger yang mampu memaksimalkan kecepatan dalam pengambilan data dan
eksekusi perintah sekaligus mampu dijalakan ke dalam banyak platform karena
SIKASA dirancang menggunakan platform yang berbeda-beda seperti PHP dan
.Net,
.
6. Daftar Pustaka
[1] Setiawati, Wina, 2008, “Aplikasi Laporan Keuangan Berbasis Web
Untuk Kelurahan Dukuh”, Jurusan Teknologi Informasi Universitas
Guna Darma.
[2] Ella Helmi, Israel. 2012. “Rancang Bangun Sistem Informasi
Pengelolaan Keuangan Daerah (Studi Kasus pada SKPD dinas Energi
dan Sumber Daya Mineral Kabupaten Kepulauan Sangihe)”. Tesis.
Pascasarjana Universitas Diponegoro Semarang.
[3] Hidayat. A., Sugiarto. (2012). Penerapan system informasi akuntansi
berbasis computer pada kopinspek PT. Sucofindo cabang medan.
Jurnal wira ekonomi mikroskil. Vol.2
[4] Santika Ilerning, 2016, Konsep Dasar Analisis Sistem.
http://santika.ilearning.me/2-1-teori-umum/2-1-4-konsep-dasar-analisis-
sistem/. diakses tanggal 20 oktober 2016.
Page 24
18
[5] Kumpulan Artikel Serba Guna, 2013, Pengertian Implementasi Menurut
Para Ahli. http://el-kawaqi.blogspot.co.id/2012/12/pengertian-
implementasi-menurut-para.html.diakses tanggal 3 November 2016.
[6] Adisaputro, Gunawan dan Yunita Anggraini. 2007. Anggaran Bisnis,
Cetakan Pertama, Yogyakarta: UPP STIM YKPN
[7] Klinik Akuntansi, 2016, Definisi Akuntansi Menurut Para Ahli.
http://www.kompasiana.com/klinikakuntansi/definisi-akuntansi-menurut-
para-ahli_54f79be6a33311207e8b46fe. diakses tanggal 3 November
2016.
[8] Fina Pandu Winata Dunia Info, 2013, Pengertian Web Service.
http://saptafina13.blogspot.co.id/2013/04/pengertian-web-service.html.
diakses tanggal 8 November 2016.
[9] Rekayasa Perangkat Lunak, 2014, Prototyping Model. https://
julimkirom. wordpress.com/2014/02/20/3-prototyping-model/. diakses
tanggal 11 November 2016.
[10] Suryani, Erni. 2013. ”Aplikasi Pembelajaran Bahasa Korea Dasar
Berbasis Sistem Operasi Android”. Skripsi. Fakultas Teknik dan Ilmu
Komputer, Universitas Komputer Indonesia.