SISTEM INFORMASI SUB TRANSAKSI PENGELUARAN
KEUANGAN DAERAH BERBASIS WEB
DENGAN JSP DAN MYSQL
(STUDI KASUS DI KABUPATEN REMBANG)SKRIPSI
Diajukan Untuk Memenuhi Syarat Memperoleh Gelar Sarjana Teknik Program Studi Teknik Informatika
oleh:
Jati Ayu Susiloningsih
NIM : 045314067
JURUSAN TEKNIK INFORMATIKA
FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS SANATA DHARMA
YOGYAKARTA
( A CASE STUDY IN KABUPATEN REMBANG)
A THESIS
Presented as Partial Fulfillment of the Requirements To Obtain Informatics Engineering Degree In Informatics Engineering Department
by:
Jati Ayu Susiloningsih
NIM : 045314067
INFORMATICS ENGINEERING STUDY PROGRAM
INFORMATICS ENGINEERING DEPARTMENT FACULTY
OF SAINS AND TECHNOLOGY
SANATA DHARMA UNIVERSITY
YOGYAKARTA
2008
MOTTO
Nasib bukanlah soal kebetulan. Tetapi soal pilihan.
Nasib bukanlah sesuatu yang ditunggu. Tetapi adalah
sesuatu yang harus dicapai.
By Wiiliam Jennings Bryan
Raihlah bulan, dan kemungkinan terburuk yang
mungkin terjadi adalah anda akan mendarat diantara
bintang-bintang
By: Tonny Orlando
Besemangatlah dan bertekatlah untuk berhasil...!
pencatatan keuangan dapat lebih mudah karena dapat dilakukan dimanapun, data yang disimpan juga akan lebih akurat serta konsisten serta penyajian laporan akan lebih mudah.
Sistem ini mampu menangani pengelolaan keuangan keuangan daerah yaitu pada bagian transaksi pengeluaran, meliputi proses pengajuan pencairan dengan SPP(Surat Permohonan Pencairan), SPM(Surat Perintah Membayar), dan SP2D(Surat Perintah Pencairan Dana), proses pencairan, hingga proses pembelanjaan.
Data-data yang digunakan dalam pengembangan sistem diperoleh dari hasil wawancara dengan pihak-pihak yang berwenang langsung dalam pengelolaan keuangan daerah di Kabupaten Rembang, serta mengambil contoh-contoh dokumen yang terkait.
Sistem informasi keuangan daerah ini diimplementasikan dengan JSP dan database Mysql. Dalam implementasi, yang diutamakan adalah pada sisi back end
sistem. Sistem dilengkapi dengan menejemen transaksi dan concurrency control, untuk mencegah masalah-masalah yang mungkin tumbul karena akses yang
concurrent.
Hasil yang diperoleh, ada sembilan level pengguna sistem. Masing-masing dikelompokkan berdasarkan tugas dan wewenangnya dalam pengelolaan keuangan daerah.
ABSTRACT
The purpose of this paper is to build a web-based financial information system. So with this system we expect a more easily money data recording because it can be done everywhere, the data that has been saved will be more accurate and consistence then the report will be more easily presented.
This system is able to handle territory financial management i.e. in the department of expenditure transaction, which include the process of disbursement submission with SPP (Disbursement Application), SPM (Payment Warrant) and SP2D (Fund Disbursement Warrant), Disbursement process up to Financing Process.
The data used for the system development was gained from interviews with those who have the direct authority in the territorial finances management in Rembang Regency, and took the example of interrelated documents.
The territorial finances system is implemented by JSP and Mysql database. In the implementation, the most important priority is in the back end system side. The system is complemented by transactional management and concurrency control, in order to prevent any possible problems raised because of the concurrent access.
The result which is gained, there are nine levels of system users. Each of which is grouped based on the task and their own authority in the territorial finances management.
menyelesaikan skripsi ini dengan judul “SISTEM INFORMASI SUB TRANSAKSI PENGELUARAN KEUANGAN DAERAH BERBASIS WEB DENGAN JSP DAN MYSQL (STUDI KASUS DI KABUPATEN REMBANG)”.
Dorongan serta nasihat dari berbagai pihak sangat membantu sampai tersusunnya skripsi ini. Untuk itu, saya ingin mengucapkan terima kasih kepada : 1. Bapak dan Mama yang sepenuhnya memberi dukungan moral, spiritual dan
finansial dalam penyusunan skripsi.
2. Romo Ir. Greg. Heliarko SJ, S.S., B.S.T., M.A., M.Sc. selaku Dekan Fakultas Sains dan Teknologi Universitas Sanata Dharma Yogyakarta.
3. Bapak Puspaningtyas Sanjoyo Adi, S.T., M..T. selaku Ketua Jurusan Teknik Informatika Fakultas Sains dan Teknologi Universitas Sanata Dharma Yogyakarta.
4. Ibu Agnes Maria Polina, S.Kom., M.Sc., selaku Dosen Pembimbing Akademik Angkatan 2004 Jurusan Teknik Informatika Fakultas Sains dan Teknologi Universitas Sanata Dharma Yogyakarta.
5. Bapak JB Budi Darmawan, ST.,MSc selaku Dosen Pembimbing pertama dan Bapak Agung Hernawan, ST selaku Dosen Pembimbing kedua Skripsi. Terimakasih telah membimbing dan menyediakan waktu dalam memberikan pengarahan selama penulisan skripsi ini.
6. Bapak Suciptono, SE selaku Kepala Bagian Keuangan Kabupaten Rembang. 7. Ibu Hari Susilowati, SE selaku Ka.Sub.Bag Pembukuan dan Verifikasi
Bagian Keuangan Sekretaris Daerah Kabupaten Rembang.
8. Bapak Feri Sumadi, SE selaku Ka.Sub.Bag Anggaran Sekretaris Daerah Kabupaten Rembang.
9. Bapak Ir. Hari Susanto M.Si selaku kepala Dinas Bapeda Kabupaten Rembang beserta staff.
10. Sarmila teman sahabatku, terimakasih canda, tawa dan tangis dalam persahabatan kita.
11. EM Tanto Nugroho, terimakasih atas doa dan dukungan yang diberikan sepenuhnya.
12. Teman-teman seperjuangan di Teknik Informatika 2004: Agnes, Hielda, Tri, Alde, Deni, Timus, Jimmy dan yang lain. Terimakasih atas dukungan selama penyelesaian skripsi ini serta pertemanan yang terjalin selama masa kuliah.
13. Tastiti Community mbak Lia, mbak Retno, Deni, Intan, Tiwi, Wuri, Maria dan semuanya yang telah memberi dukungan dan doa kepada penulis dalam menyelesaikan skripsi ini.
Akhirnya skripsi ini terselesaikan, disadari bahwa skripsi ini jauh dari sempurna. Untuk itu penulis dengan rendah hati mengharapkan kritik dan saran yang dapat memberikan kesempurnaan pada penulisan skripsi ini. Akhir kata, semoga skripsi ini dapat bermanfaat bagi penulis, juga pihak yang membutuhkan.
Yogyakarta, 30 September 2008 Penulis
HALAMAN JUDUL ... ii
HALAMAN PERSETUJUAN PEMBIMBING... iii
HALAMAN PENGESAHAN... iv
MOTTO ... v
INTISARI ... vi
ABSTRACT ... vii
KATA PENGANTAR... viii
HALAMAN KEASLIAN KARYA... x
LEMBAR PERNYATAAN... xi
DAFTAR ISI ... xii
DAFTAR GAMBAR... xxii
DAFTAR TABEL... xxix
DAFTAR LISTING... xxxiv
DAFTAR LAMPIRAN... xxxv
BAB I PENDAHULUAN... 1
1.1. Latar Belakang Masalah ... 1
1.2. Rumusan Masalah ... 2
1.3. Batasan Masalah ... 2
1.4. Tujuan Penelitian ... 3
1.5. Manfaat Penelitian ... 3
1.6. Metodologi Penelitian ... 3
1.6.1. Analisis Sistem... 3
1.6.2. Desain Sistem... 4
1.6.3. Implementasi Sistem ... 4
1.6.4. Testing ... 4
1.7. Sistematika Penulisan ... 5
BAB II LANDASAN TEORI... 6
2.1. Definisi Sistem Informasi Keuangan ... 6
2.2. Pengelolaan Keuangan Daerah ... 7
2.2.1. Definisi Sistem Informasi Keuangan Daerah ... 7
2.2.2. Struktur Organisasi Pengelolaan Keuangan Daerah... 7
2.3.Diagram Alur Sistem ... 8
2.4.Proses Pengembangan Sistem... 10
2.4.1. Analisis Sistem ... 10
2.4.2. Desain Sistem ... 12
2.4.3. Pemodelan Persyaratan... 13
2.4.3.1. Use Case Diagram... 13
2.4.4. Pemodelan Proses ... 14
2.4.4.1. Context Data Flow Diagram ... 14
2.4.4.2. DAD ... 14
2.4.5. Desain Database ... 16
2.4.5.1. E-R Diagram ... 16
2.5.Aplikasi Web ... 18
2.6.Servlet ... 19
2.8.1. Concurrency Control... 28
2.8.2. Metode Locking... 31
2.8.3. Concurrency Control dengan Teknik Two Phase Locking... 31
BAB III ANALISA DAN DESAIN SISTEM ... 32
3.1. Analisa Sistem ... 32
3.1.1.Struktur Organisasi Pengelola Keuangan Daerah di Kebupaten Rembang ... 32
3.1.2.Gambaran Umum Sistem Penatausahaan Keuangan Daerah... 34
3.1.2.1. Penatausahaan Penerimaan Keuangan Daerah... 36
3.1.2.1.1. Pertanggungjawaban Bendahara Penerimaan ... 38
3.1.2.1.2. Pertanggungjawaban Bendahara Penerimaan Pembantu ... 41
3.1.2.2. (DPA)-SKPD dan Anggaran Kas... 43
3.1.2.2.1. Penyusunan (DPA)-SKPD ... 44
3.1.2.2.2. Pengesahan (DPA)-SKPD... 47
3.1.2.3. Penatausahaan Pengeluaran Keuangan Daerah... 48
3.1.2.3.1. Anggaran Kas... 48
3.1.2.3.2. Pembuatan SPD... 52
3.1.2.3.3. Pengajuan SPP dan Penerbitan SPM ... 54
3.1.2.3.4. Penerbitan SP2D ... 58
3.1.2.3.5. Pelaksanaan Belanja Unutk Penggunaan UP ... 59
3.1.2.3.6.Pertanggungjawaban Pengeluaran Bendahara Pengeluaran Pembantu
... 63
3.1.2.3.7. Pertanggungjawaban Pengeluran Bendahara Pengeluaran ... 65
3.1.2.4. Sistem Akuntansi Pemerintah Daerah... 67
3.1.3.Menentukan Tujuan Perbaikan Sistem ... 69
3.2. Diagram Aliran Sistem ... 70
3.3. Analisis Persyaratan... 75
3.3.1.Use Case Diagram Sistem Informasi Keuangan Daerah... 75
3.3.2.Diagram Use Case Sistem Pengeluaran Anggaran Daerah... 77
3.3.2.1. Diagram Use Case Login ... 78
3.3.2.2. Package Pengelolaan Anggaran... 79
3.3.2.3. Package Pengelolaan SPD ... 80
3.3.2.4. Diagram Use Case Pengelolaan Dokumen Pengajuan dan Pengajuan SPP ... 81
3.3.2.5. Diagram Use Case SPM dan Penerbitan SP2D ... 82
3.3.2.6. Diagram Use Case NPD dan Pembelanjaan ... 83
3.3.2.7. Diagram Use Case Pelaporan... 84
3.3.3.Use Case Narrative... 84
3.4. Pemodelan dan Analisis Data ... 98
3.4.1. Diagram Konteks Sistem Penatausahaan Pengeluaran Daerah... 98
3.5. Pemodelan Proses ... 100
3.5.1. Diagram Berjenjang untuk sistem penatausahaan pengeluaran ... 100
3.5.2.Diagram Aliran Data ... 101
3.5.2.4. DAD proses 4 level 1 ... 104
3.5.2.5. DAD proses 5 level 1 ... 105
3.5.2.6. DAD proses 6 level 1 ... 106
3.5.2.7. DAD proses 7 level 1 ... 106
3.5.2.8. DAD proses 8 level 1 ... 106
3.5.2.9. DAD proses 9 level 1 ... 107
3.5.2.10.DAD proses 10 level 1 ... 107
3.5.2.11.DAD proses 11... 107
3.5.2.12.DAD proses 12 level 1 ... 108
3.5.2.13.DAD proses 13 level 1 ... 108
3.5.2.14.DAD proses 14 level 1 ... 108
3.5.2.15.DAD proses 15 level 1 ... 109
3.5.2.16.DAD proses 16... 110
3.5.2.17.DAD proses 2 level 2 ... 111
3.5.2.18.DAD proses 3 level 2 ... 112
3.5.2.19.DAD proses 5 level 2 ... 113
3.6. Perancangan Arsitektur Sistem ... 114
3.7. Perancangan Database ... 116
3.7.1. ER Diagram Konseptual ... 116
3.7.2. ER Diagram Logical ... 117
3.7.3.Tabel-tabel yang diperlukan... 118
3.7.3.1. tabel t_akun ... 118
3.7.3.2. tabel t_belanja ... 118
3.7.3.3. tabel t_pos_belanja... 118
3.7.3.4. tabel t_group_rekening ... 119
3.7.3.5. tabel t_rekening... 119
3.7.3.6. tabel t_urusan ... 119
3.7.3.7. tabel t_bidang ... 120
3.7.3.8. tabel t_SKPD... 120
3.7.3.9. tabel t_program ... 120
3.7.3.10.tabel t_kegiatan ... 121
3.7.3.11.tabel t_dpa ... 121
3.7.3.12.tabel t_sub_dpa ... 122
3.7.3.13.tabel history_edit_sub_dpa ... 123
3.7.3.14.tabel t_anggaran ... 124
3.7.3.15.tabel t_rincian_anggaran ... 124
3.7.3.16.tabel t_pegawai ... 124
3.7.3.17.tabel t_user ... 125
3.7.3.18.tabel t_pejabat ... 125
3.7.3.19.tabel t_pengunjung ... 126
3.7.3.20.tabel t_SPD ... 126
3.7.3.21.tabel t_tanggungJawabSPP ... 127
3.7.3.22.tabel t_kas_daerah... 127
3.7.3.26.tabel t_pihak3 ... 128
3.7.3.27.tabel d_rincian_anggaran_diajukan ... 129
3.7.3.28.tabel d_spp ... 129
3.7.3.29.tabel d_spm ... 130
3.7.3.30.tabel d_SP2D... 130
3.7.3.31.tabel tr_bukti_belanja... 131
3.7.3.32.tabel tr_rincian_bukti ... 132
3.8. Desain Input Output... 133
3.8.1.Desain Form Login ... 133
3.8.2.Form Cover DPA ... 133
3.8.3.Form Pilih Cover DPA... 133
3.8.4.Desain Form Insert data DPA ... 133
3.8.5.Desain Form Insert SPD... 134
3.8.6.Desain Form Insert Rincian Anggaran... 135
3.8.7.Desain Form DPA SKPD Baru ... 135
3.8.8.Desain Form Edit DPA ... 136
3.8.9.Desain Form Edit Rincian Anggaran ... 136
3.8.10.Desain Form Insert NPD... 137
3.8.11.Desain Form Insert SPD... 137
3.8.12.Desain Form Edit SPD ... 138
3.8.13.Desain Form Buat SPP Baru ... 138
3.8.14.Desain Form Insert Pengajuan Anggaran ... 139
3.8.15.Desain Form Insert Penganjuan Rincian Anggaran ... 139
3.8.16.Desain Form Antri Persetujuan SPP ... 140
3.8.17.Desain Form Detail SPP ... 140
3.8.18.Desain Form Antrian Verifikasi SPP ... 141
3.8.19.Desain Angtrian Pembuatan SPM... 141
3.8.20.Desain Form Penerbitan SPM... 142
3.8.21.Desain Form Insert Potongan SPM... 142
3.8.22.Desain Form Detail SPM ... 143
3.8.23.Form Daftar SPM... 143
3.8.24.Form Antrian Verifikasi SPM... 143
3.8.25.Desain Form Antrian Penerbitan SP2D ... 144
3.8.26.Desain Form Pencairan SP2D... 144
3.8.27.Desain Form Pembuatan NPD ... 144
3.8.28.Desain Antrian Persetujuan NPD... 145
3.8.29.Desain Form Antrian Verifikasi NPD... 145
3.8.30.Desain Form Pembuatan Bukti Pembelanjaan... 145
3.8.31.Desain Form Rincian Pembelanjaan ... 146
3.9. Teknik Pemrograman... 147
3.9.1.Diagran Class ... 148
3.10. Testing... 150
BAB IV IMPLEMENTASI DAN ANALISA HASIL... 151
4.1.2.1. Form Login ... 154
4.1.2.2. Halaman Indeks... 160
4.1.2.3. Pengelolaan Anggaran ... 162
4.1.2.3.1. Form Insert Cover DPA ... 162
4.1.2.3.2. Edit Cover DPA ... 163
4.1.2.3.3. Form Insert DPA SKPD... 163
4.1.2.3.4. Form Insert Detail DPA SKPD ... 165
4.1.2.3.5. Form Insert Detail Anggaran DPA SKPD ... 168
4.1.2.3.6. Form Insert Rincian DPA SKPD ... 169
4.1.2.3.7. Form DPA SKPD Baru ... 171
4.1.2.3.8. Daftar DPA SKPD ... 172
4.1.2.3.9. View Detail Data DPA SKPD ... 173
4.1.2.3.10.Form Edit DPA SKPD ... 174
4.1.2.3.11.Edit Rincian Anggaran DPA SKPD... 175
4.1.2.3.12.Pembuatan SPD... 176
4.1.2.3.13.Daftar SPD ... 178
4.1.2.3.14.Edit SPD... 178
4.1.2.4. Pembuatan Dokumen Pengajuan ... 179
4.1.2.4.1. Pembuatan SPP ... 179
4.1.2.4.2. Insert Pengajuan Anggaran ... 180
4.1.2.4.3. Insert Rincian Anggaran Diajukan... 181
4.1.2.4.4. Dokumen SPP ... 182
4.1.2.4.5. Verifkasi I SPP... 185
4.1.2.4.6. Verifikasi II SPP ... 186
4.1.2.4.7. Penerbitan SPM... 188
4.1.2.4.8. Verifakasi SPM ... 192
4.1.2.4.9. Penerbitan SP2D ... 193
4.1.2.4.10.Pencairan Anggaran ... 195
4.1.2.4.10.1.Pencairan ... 195
4.1.2.4.10.2.Penerbitan NPD... 196
4.1.2.4.10.3.Verifikasi I NPD ... 198
4.1.2.4.10.4.Verifikasi II NPD ... 198
4.1.2.4.10.5.Pembelanjaan ... 199
4.2. Pemodelan Class ... 200
4.3. Pengaturan Transaksi ... 204
4.4. Analisa Hasil... 209
4.4.1.Kelebihan Sistem ... 210
4.4.2.Kekurangan Sistem ... 210
BAB V KESIMPULAN DAN SARAN... 211
5.1. Kesimpulan ... 211
5.2. Saran ... 212
DAFTAR PUSTAKA ... 213
LAMPIRAN ... 214
2.2 Garis besar arsitektur pemakaian JSP 21 2.3 Three tier JDBC pada aplikasi internet 25
2.4 Diagram status transaksi 26
2.5 Taksonomi Mekanisme Kontrol Konkurensi 30 3.1 Struktur organisasi pengelolaan keuangan daerah
kabupaten Rembang
34
3.2 Prosedur pengelolaan keuangan daerah 36
3.3 Flowchart penerimaan daerah 39
3.4 Flowchart pembuatan SPJ penerimaan 41
3.5 Flowchart pembuatan SPJ penerimaan pembantu 44 3.6 Flowchart penyiapan rancangan DPA-SKPD 47
3.7 Flowchart pengesahan DPA-SKPD 49
3.8 Flowchart penyiapan anggaran kas 51
3.9 Flowchart penyiapan surat penyediaan dana 53 3.10 Flowchart Pengajuan SPP dan penerbitan SPM 56
3.11 Flochart penerbitan SP2D 58
3.12 Flowchart pelaksanaan belanja 60
3.13 Flowchart pembuatan SPJ pengeluaran pembantu 63
3.14 Flowchart pembuatan SPJ pengeluaran bendahara 65
pengeluaran
3.15 Flowchart akuntansi SKPD 68
3.16 Diagram alur sistem 70
3.17 Diagram alur sistem (lanjutan 1) 71
3.18 Diagram alur sistem (lanjutan 2) 72
3.19 Diagram usecase sistem informasi keuangan daerah 75 3.20 Diagram usecase pengeluaran anggaran daerah 75
3.21 Diagram usecase login 78
3.22 Diagram usecase package pengelolaan anggaran 79 3.23 Diagram usecase package pengelolaan SPD 80 3.24 Diagram usecase pengelolaan dokumen pengajuan dan
pengajuan SPP
81
3.25 Diagram usecase penerbitan SPM dan penerbitan SP2D 82 3.26 Diagram usecase penerbitan NPD dan pembelanjaan 83
3.27 Diagram usecase pelaporan 84
3.28 Diagram konteks sistem penatausahaan pengeluaran daerah 98
3.29 Diagram berjenjang sistem informasi keuangan daerah (transaksi pengeluaran)
100
3.30 DAD proses 1 101
3.31 DAD proses 2 102
3.32 DAD proses 3 103
3.33 DAD proses 4 104
3.37 DAD proses 8 106
3.38 DAD proses 9P 106
3.39 DAD proses 10 107
3.40 DAD proses 11P 107
3.41 DAD proses 12 level 1 108
3.42 DAD proses 13 level 1 108
3.43 DAD proses 14 level 1 108
3.44 DAD proses 15 level 1 109
3.45 DAD proses 16P 110
3.46 DAD proses 2.1 111
3.47 DAD proses 2.2 111
3.48 DAD proses 2.3 112
3.49 DAD proses 3.1 112
3.50 DAD proses 3.2 112
3.51 DAD proses 3.3 113
3.52 DAD proses 5.1 113
3.53 DAD proses 5.2 113
3.54 DAD proses 5.3 114
3.54 Perancangan arsitektur sistem 114
3.56 ER Diagram konseptual sistem 116
3.57 ER diagram konseptual user 116
3.58 ER diagram logical 117
3.59 Desain form login 133
3.60 Desain form Cover DPA 133
3.61 Desain form pilih cover DPA 133
3.62 Desain form insert detail DPA 134
3.63 Desain form insert SPD 134
3.64 Desain form insert rincian anggaran 135
3.65 Desain form DPA SKPD baru 135
3.66 Desain form edit DPA 136
3.67 Desain form edit rincian anggaran 136
3.68 Desain form insert NPD 137
3.69 Desain form insert SPD 137
3.70 Desain form edit SPD 138
3.71 Desain form buat SPP baru 138
3.72 Desain form insert pengajuan anggaran 139 3.73 Desain form insert pengajuan rincian anggaran 139
3.74 Desain form antri persetujuan SPP 140
3.75 Desain form detail SPP 140
3.76 Desain form antrian ACC SPP 141
3.77 Desain form antrian pembuatan SPM 141
3.81 Desain form daftar SPM 143
3.82 Desain form antrian verifikasi SPM 143
3.83 Desain form antrian penerbitan SP2D 144
3.84 Desain form pencairan SP2D 144
3.85 Desain form pembuatan NPD 144
3.86 Desain form antrian persetujuan NPD 145
3.87 Desain form antrian verifikasi NPD 145
3.88 Desain Form Pembuatan Bukti pembelanjaan 145
3.89 Desain Form Insert Rincian Pembelanjaan 146
3.90 Diagram class 1 148
3.91 Diagram class 2 149
4.1 Peta web
151
4.2 Peta web (lanjutan 1)
152
4.3 Peta wen (lanjutan 2)
153
4.4 Form login
154 4.5 Indeks Ka Sub Bag Anggaran
160
4.6 Form Insert Cover DPA
162
4.7 Form pilih cover DPA SKPD
163 4.8 Form Insert Detail Sub DPA
165
4.9 Form Insert Anggaran
168 4.10 Form Insert Rincian Anggaran
169 4.15 Form edit rincian anggaran
175 4.21 Form insert pengajuan anggaran
180 4.22 Form insert rincian anggaran diajukan
181
4.23 Surat pengantar SPP
182
4.24 Ringkasan SPP
183
4.25 Rincian penggunaan dana
184
4.26 Register SPP
185 4.27 Form antrian persetujuan SPP
185 4.28 Form detail verifikasi I SPP
186
4.29 Form antri ACC SPP
186
4.30 Form verifikasi I SPP
187
189
4.34 Form data rincian SPM
189 4.38 Form antrian verifikasi SPM
192 4.39 Form antrian pembuatan SP2D
193
4.40 Register SP2D
194
4.41 Form Pencairan SP2D
195
4.42 Form pembuatan NPD
196
4.43 Dokumen NPD
197 4.44 Form antrian verifikasi I NPD
198
4.45 Form antrian ACC NPD
198 4.46 Form pembuatan bukti pembelanjaan
199 4.47 Form insert rincian belanja
199
4.48 Struktur table d_spp
201
4.49 Diagram class SPP
201 4.50 Diagram class DBConnection
202 4.51 Diagram class SppDAOInterface
203 4.52 Diagram Class sppDAOImplement
203
DAFTAR TABEL
Tabel Keterangan Halaman
2.1 Simbol diagram alur sistem 8
2.2 Simbol Use case 13
2.3 Simbol konteks data flow diagram 14
2.4 Simbol diagram aliran data 15
2.5 Simbol ER diagram 16
2.6 Daftar Variable terdefinisi dalam JSP 19
2.7 Methode pada variable request yang diwariskan dari servlet
request
21
2.8 Penjelasan status transaksi 26
2.9 Lost update problem 27
2.10 Uncomitted dependency 28
2.11 Inconsistent analisis problem 29
3.1 Tujuan perbaikan sistem 69
3.2 Penjelasan usecase login 84
3.3 Penjelasan usecase insert cover DPA 85
3.4 Penjelasan usecase update data cover DPA 85
3.5 Penjelasan usecase delete cover DPA 85
3.6 Penjelasan usecase insert DPA 85
3.7 Penjelasan usecase update data DPA 86
3.8 Penjelasan usecase delete DPA 86
3.12 Penjelasan usecase insert data rincian anggaran 87
3.13 Penjelasan usecase update data rincian anggaran 87 3.14 Penjelasan usecase delete rincian anggaran 87
3.15 Penjelasan usecase insert SPD 88
3.16 Penjelasan usecase update data SPD 88
3.17 Penjelasan usecase delete data SPD 88
3.18 Penjelasan usecase insert dokumen pengajuan 88 3.19 Penjelasan usecase update data dokumen pengajuan 89
3.20 Penjelasan usecase delete dokumen pengajuan 89 3.21 Penjelasan usecase insert pengajuan anggaran 89 3.22 Penjelasan usecase update data pengajuan anggaran 90 3.23 Penjelasan usecase delete pengajuan anggaran 90 3.24 Penjelasan usecase insert rincian anggaran diajukan 90 3.25 Penjelasan usecase update data rincian anggaran diajukan 91 3.26 Penjelasan usecase delete rincian anggaran diajukan 91
3.27 Penjelasan usecase insert SPP 91
3.28 Penjelasan usecase delete SPP 92
3.29 Penjelasan usecase verifikasi I SPP 92
3.30 Penjelasan usecase verifikasi II SPP 92
3.31 Penjelasan usecase insert SPM 92
3.32 Penjelasan usecase delete SPM 93
3.33 Penjelasan usecase verifikasi SPM 93
3.34 Penjelasan usecase insert SP2D 93
3.35 Penjelasan usecase delete SP2D 94
3.36 Penjelasan usecase pencairan 94
3.37 Penjelasan usecase penerbitan NPD 94
3.38 Penjelasan usecase delete NPD 95
3.39 Penjelasan usecase verifikasi I NPD 95
3.40 Penjelasan usecase verifikasi II NPD 95
3.41 Penjelasan usecase pembelanjaan 95
3.42 Penjelasan usecase pembatalan pembelanjaan 96 3.43 Penjelasan usecase melihat data anggaran 96 3.44 Penjelasan usecase melihat data buku besar 96 3.45 Penjelasan usecase pelaporan anggaran 97
3.46 Daftar entitas 99
3.47 Penjelasan tabel t_akun 118
3.48 Penjelasan table t_belanja 118
3.49 Penjelasan table t_pos_belanja 118
3.50 Penjelasan table t_group_rekening 119
3.51 Penjelasan table t_rekening 119
3.52 Penjelasan table t_urusan 119
3.56 Penjelasan table t_kegiatan 121
3.57 Penjelasan table t_dpa 121
3.58 Penjelasan table t_sub_dpa 122
3.59 Penjelasan table history_edit_sub_dpa 123
3.60 Penjelasan table t_anggaran 124
3.61 Penjelasan table t_rincian_anggaran 124
3.62 Penjelasan table t_pegawai 124
3.63 Penjelasan table t_user 125
3.64 Penjelasan table t_pejabat 125
3.65 Penjelasan table t_pengunjung 126
3.66 Penjelasan table t_spd 126
3.67 Penjelasan table t_tanggungjawab_spd 127
3.68 Penjelasan table t_kas_daerah 127
3.69 Penjelasan table status_acc 127
3.70 Penjelasan table d_pengajuan 128
3.71 Penjelasan table d_pengajuan_anggaran 128
3.72 Penjelasan table t_pihak_3 128
3.73 Penjelasan table d_rincian_anggaran_diajukan 129
3.74 Penjelasan table d_spp 129
3.75 Penjelasan table d_spm 130
3.76 Penjelasan table d_SP2D 130
3.77 Penjelasan table tr_pencairan 131
3.78 Penjelasan table tr_bukti_belanja 131
3.79 Penjelasan table tr_rincian_bukti 132
4.1 Daftar Store procedure dengan metode transaksi 2PL 207
155 4.2 UserDAOImplement.java
157 4.3 Store procedure sp_login
158 4.4 Store procedure get_level
159 4.5 validasi
161 4.6 Store procedure edit_rincianAnggaran
205
DAFTAR LAMPIRAN
Nomor Keterangan
1 Pengantar Proposal Penelitian Fakultas Sains dan Teknologi Universitas Sanata Dharma Yogyakarta
2 Surat ijin penelitian/survey Kantor KESBANG DAN LINMAS Rembang 3 Cover DPA (Dokumen Pelaksanaan Anggaran)
4 DPA SKPD (Dokumen Pelaksanaan Anggaran Satuan Kerja Perangkat Daerah)
5 SP2D (Surat Perintah Pencaran Dana) 6 SPM (Surat Permintaan Pembayaran) 7 Surat Keterangan Pengajuan SPP-TU 8 Surat Pernyataan Pengajuan SPP-TU
9 Penelitian Kelengkapan Dokumen SPP 10 Surat Pengantar SPP
11 Ringkasan SPP-TU 12 Rincian SPP-GU 13 Nota Pencairan Dana 14 Surat bukti Penerimaan
1.1. Latar Belakang Masalah
Keuangan daerah merupakan hak dan kewajiban daerah yang dapat dinilai dengan uang termasuk di dalamnya segala bentuk kekayaan yang berhubungan dengan hak dan kewajiban daerah. Sedangkan pengelolaan keuangan daerah adalah keseluruhan kegiatan yang meliputi perencanaan, pelaksanaan, penatausahaan, pelaporan, pertanggungjawaban dan pengawasan keuangan daerah. Penatausahaan keuangan daerah yang merupakan bagian dari pengelolaan keuangan daerah memegang peran penting dalam proses pengelolaan keuangan daerah secara keseluruhan.
Kabupaten Rembang sampai saat ini melaksanakan pengelolaan keuangan secara manual. Setiap proses dilakukan dengan menggunakan catatan-catatan dan dokumen-dokumen. Semua data tersimpan dalam bentuk dokumen, sehingga dalam melakukan sebuah transaksi, harus membuka beberapa dokumen lain yang terkait. Proses perhitungan juga dilakukan secara manual, jadi kesalahan dalam perhitungan sering terjadi. Sehingga laporan yang dihasilkan kurang dapat terjamin keakuratannya serta membutuhkan waktu yang cukup lama untuk melakukan sebuah proses yang berkaitan dengan pengelolaan keuangan.
Dari kondisi sistem pengelolaan keuangan yang demikian, pemerintah sendiri merasa perlu untuk menerapkan sebuah aplikasi yang mampu menangani pengelolaan keuangan daerah.
2
1.2. Rumusan Masalah
Dari latar belakang masalah di atas dapat dirumuskan permasalahan sebagai berikut :
bagaimana menganalisa, merancang dan kemudian membangun sistem informasi keuangan daerah dalam sebuah program aplikasi berbasis web yang mampu menangani transaksi, menyimpan dan menyajikan data yang akurat?
1.3. Batasan Masalah
Dalam aplikasi sistem informasi keuangan daerah yang akan dibuat nanti akan diberi beberapa batasan antara lain:
1. Aplikasi yang dibuat hanya menangani penatausahaan pengeluaran yang terjadi di kabupaten Rembang melalui SPP-LS, SPP-TU, SPP-GU, dan SPP-UP.
2. Aplikasi akan dibuat berdasarkan hasil study kasus di Kabupaten Rembang Jawa Tengah.
3. Aplikasi yang akan dibuat merupakan aplikasi sistem informasi berbasis web, yang dibangun dengan JSP (Java Server Pages) dan database menggunakan mysql.
1.4. Tujuan Penelitian
Adapun tujuan pembuatan skripsi adalah untuk membangun sebuah sistem informasi keuangan daerah khususnya penatausahaan pengeluran yang berbasis web dengan teknologi java server pages dan menerapkan manajemen transaksi menggunakan database mySql.
1.5. Manfaat Penelitian
Penelitian ini dilakukan dengan harapan dapat memberikan manfaat sebagai berikut:
1. Membantu pemerintah Kabupaten Rembang dalam melakukan pengelolaan keuangan daerah dengan sebuah aplikasi yang berbasis web. 2. Memudahkan penyajian data yang diperlukan dengan cepat dan akurat 3. Membantu mendokumentasikan setiap transaksi dengan baik, sehingga
kebocoran keuangan dapat diminimalkan.
1.6.Metodologi Penelitian
Metode pengembangan perangkat lunak yang digunakan adalah terstruktur (Whitten, 2004).
1.6.1. Analisis Sistem 1) Wawancara
4
kemudian penulis malakukan pengamatan langsung di lapangan dengan mengambil contoh-contoh dokumen.
2) Study pustaka
Study pustaka mengenai peraturan perundangan yang berlaku mengenai sistem keuangan daerah. Serta mengenai java server pages dan database mysql.
3) Pemodelan Persyaratan
Pemodelan persyaratan sistem dilakukan dengan menggunakan menggunakan Use Case.
4) Pemodelan Proses
Proses dimodelkan dengan diagram aliran data. 1.6.2. Desain Sistem
1) Desain arsitektur sistem
2) Desain database dengan menggunakan Entitas Relasional Diagram 3) Desain Input output
1.6.3. Implementasi sistem
Penulisan kode program sesuai dengan desain yang telah dilakukan pada tahap sebelumnya
1.6.4. Testing
1.7. Sistematika Penulisan
Sistematika penulisan skripsi nanti adalah sebagai berikut: BAB I : PENDAHULUAN
Menguraikan tentang latar belakang masalah, rumusan masalah, batasan masalah, tujuan penelitian, dan metodologi yang akan digunakan dalam penyusunan skripsi.
BAB II : LANDASAN TEORI
Berisi teori-teori yang akan dijadikan landasan dalam penyusunan skripsi. BAB III : ANALISA DAN DESAIN SISTEM
Berisi analisa kebutuhan sistem dan desain sistem yang akan diimplementasikan sebagai aplikasi sistem informasi keuangan daerah dalam skripsi.
BAB IV : IMPLEMENTASI SISTEM ANALISA HASIL
Berisi pengimplementasian desain sistem yang telah dibuat pada bab sebelumnya serta berisi analisa aplikasi yang telah berhasil dibuat.
BAB V : KESIMPULAN DAN SARAN
BAB II
LANDASAN TEORI
2.1. Definisi Sistem Informasi Keuangan
Jogiyanto memberikan definisi sistem dengan dua macam pendekatan. Yaitu pendekatan prosedur dan pendekatan komponen. Dengan pendekatan prosedur, sistem dapat didefinisikan sebagai kumpulan dari prosedur-prosedur yang mempunyai satu tujuan tertetu. Sistem ini didefinisikan sebagai kumpulan prosedur-prosedur penerimaan kas, pengeluaran kas, penjualan, pembelian dan buku besar. Dengan pendekatan komponen, sistem dapat didefinisikan sebagai kumpulan dari komponen yang saling berhubungan satu dengan yang lainnya membentuk suatu kesatuan untuk mencapau tujuan tertentu(Jogiyanto, 2005: 34).
Sehubungan dengan penggunaan teknologi dalam sistem, jogiyanto memberikan definisi untuk sistem informasi sebagai berikut: “sistem informasi disebut juga sistem teknologi informasi, yaitu sistem yang menggunakan teknologi
informasi” (Jogiyanto, 2005: 4).
Dalam fungsi-fungsi organisasi, sistem informasi dikelompokkan menjadi lima macam. Salah satunya sistem informasi yang mendukung manajer keuangan mengatur keuangan bisnis serta alokasi dan kontrol dalam terhadap sumber daya keuangan. “Sistem informasi keuangan merupakan sistem informasi untuk
mendukung kegiatan-kegiatan manajer di fungsi keuangan”(Jogiyanto, 2005:257).
2.2. Pengelolaan Keuangan Daerah
2.2.1. Definisi Sistem Informasi Kuangan Daerah
Dalam Peraturan Pemerintah no 56 tahun 2005 tentang Sistem Informasi Keuangan Daerah, disebutkan definsi sebagai berikut:
Bab I Ketentuan Umum
(15) Sistem Informasi Keuangan Daerah selanjutnya disingkat SIKD
adalah suatu sistem yang mendokumentasikan, mengadministrasikan, serta mengolah data pengelolaan keuangan daerah dan data terkait lainnya menjadi informasi yang disajikan kepada masyarakat dan sebagai bahan pengambilan keputusan dalam rangka perencanaan, pelaksanaan, dan pelaporan pertanggungjawaban pemerintah daerah
(16) Informasi Keuangan Daerah adalah segala informasi yang
berkaitan dengan keuangan daerah yang diperlukan dalam rangka penyelenggaraan Sistem Informasi Keuangan Daerah.
2.2.2. Struktur Organisasi Pengelolaan Keuangan Daerah
Struktur organisasi pengelolaan keuangan daerah ditunjukkan pada gambar 2.1 berikut ini:
Kepala Daerah
Sekretaris Daerah
SKPKD/Satuan Kerja Pengelola Keuangan Daerah
BUD/Bendahara Umum Daerah
SKPD/Satuan Kerja Perangkat Daerah Kas Umum Daerah
Bendahara Penerimaan
Bendahara
Pengeluaran Kuasa Pengguna Pengguna Anggaran Pengguna Barang Anggaran
Pejabat Pelaksana Teknis Kegiatan Koordinator Pengelola
keuangan daerah
Pejabat Pengelola Keuangan Daerah
Tempat penyimpanan
uang daerah Bertindak sebagai bendahara umum daerah
Perangkat daerah selaku pengguna anggaran/barang
Unit kerja-unit Kerja
8
Kepala daerah selaku pemegang kekuasaan pengelola keuangan daerahmelimpahkan sebagian atau seluruh kekuasaanya kepada sekretaris daerah selaku koordinator pengelola keuangan daerah, kepala SKPKD (Satuan Kerja Pengelola Keuangan Daerah) selaku PPKD (Pejabat Pengelola Keuangan Daerah) dan kepada SKPD(Satuan Kerja Perangkat Daerah) selaku pejabat pengguna anggaran/ barang. Pelimpahan kekuasaan ini ditetapkan dengan keputusan kepala daerah berdasarkan prinsip pemisahan kewenangan antara yang memerintahkan, menguji, dan menerima serta mengeluarkan uang (Bastian, 2006: 72).
2.3. Diagram Alur Sistem
Diagram alur sistem menggambarkan arus data dalam sistem (jogianto, 1999). Simbol-simbol yang digunakan dalam diagram alur sistem akan dijelaskan dalam tabel 2.1 berikut:
Tabel 2. 1 Simbol diaram alur sistem
Document symbol
Menunjukkan dokumen yang digunakan untuk input dan output baik secara manual, mekanik maupun komputerisasi.
Manual action symbol
Process symbol
Menunjukkan kegiatan proses operasi program computer.
Keyboard (terminal)
symbol
Input/output yang menggunakan online keyboard
Flow lines symbol
Menunjukkan arus dari proses
Connector symbol
Digunakan untuk penghubung ke halaman yang masih samma atau ke halaman yang lain.
Display symbol
Output yang ditampilkan di layar monitor.
Hard disk storage symbol
10
2.4. Proses Pengembangan Sistem
Proses pengembangan sistem adalah satu set aktifitas, metode, praktik terbaik, barang siap dikirim, dan peralatan terotomasi yang digunakan para
stakeholder untuk mengembangkan dan secara berkesinambungan memperbaiki
sistem informasi dan perangkat lunak (Whitten, 2004).
2.4.1.Analisis Sistem
Analisis sistem adalah sebuah teknik pemecahan masalah yang menguraikan sebuah sistem menjadi bagian-bagian komponen dengan tujuan mempelajari seberapa bagus bagian-bagian tersebut bekerja dan berinteraksi untuk meraih tujuan mereka.
Secara mendasar, analisis sistem adalah mengenai pemecahan masalah. Ada banyak pendekatan untuk analisis sistem. Pendekatan analisis sistem yang sering digunakan antaran lain:
• Analisis terstruktur (Structure analysis)
• Teknik informasi (Information engineering)
• Discovery prototyping
• Analisis beriorientasi objek
lunak. Analisis ini disebut process-center karena penekanan teknik ini adalah blok pembangunan proses dalam kerangka kerja sistem informasi anda.
Analisis terstruktur sederhana dalam konsep. Para analis sistem menggambar serangkaian model proses yang disebut diagram aliran data (data flow) yang mengilustrasikan proses-proses yang ada dan atau diusukan dalam sebuah sistem yang bersama dengan input, output dan file mereka. Model-model tersebut menunjukkan aliran data di antara dan melalui proses-proses dan menunjukkan tempat-tempat data disimpan. Pada akhirnya model-model proses ini berperan sebagai cetak biru bagi proses-proses bisnis untuk diimplementasikan dan perangkat lunak untuk dibeli atau dikonstruksi.
Requirement discovery (penemuan persyaratan) adalah proses yang
digunakan oleh para analis sistem, identifikasi atau ekstraksi masalah-masalah sistem dan persyaratan-persyaratan solusi dari komunitas pengguna. Dua metode penemuan persyaratan ada dua macam yaitu teknik penemuan fakta (finding fact) dan perencanaan persyaratan gabungan.
Penemuan fakta adalah proses pengumpulan informasi mengenai masalah, kesempatan, persyaratan solusi, dan prioritas sistem. Istilah ini sering disebut juga pengumpulan informasi (Information Gathering).
Tenik penemuan fakta antara lain:
• Pengambilan contoh (sampling) dokumentasi, laporan, formulir,
file database dan memo yang ada.
• Melakukan penelitian pada buku-buku yang relevan,
12
• Mengobservasi kerja sistem dan lingkungan kerja
• Menyebarkan kuisioner dan mensurvei komunitas menejeman dan
pengguna.
• Mewawancarai para menejer, pengguna dan staff teknis yang tepat.
Analisis masalah terdiri atas beberapa fase:
• Fase definisi lingkup
• Fase analisis masalah
• Fase analisis persyaratan
• Fase desain logis
• Fase analisis keputusan
2.4.2.Desain Sistem
Desain sistem adalah Spesifikasi solusi berbasis computer yang terinci. Macam-macam pendekatan desain sistem antara lain :
• Desain terstruktur modern
• Teknik informasi
• Prototiping
• JAD (Joint Application Development)
• RAD (Rapid Application Development)
• Desain beriorientasi objek.
sebuah program computer yang lebih mudah untuk diimplementasikan dan dipelihara (diubah).
Tahapan dari desain sistem antara lain: 1. Arsitektur dan pemodelan aplikasi 2. desain database
3. desain dan prototyping output 4. desain dan prototyping input 5. desain antarmuka pengguna
2.4.3. Pemodelan Persyaratan 2.4.3.1.Use Case Diagram
Use Case Diagram digunakan untuk menggambarkan fungsi sistem yang
terdapat dalam bisnis even, siapa yang melakukan kejadian dan bagaimana sistem memberikan respon terhadap kejadian (Whitten, 2004).
Simbol dasar Use Case Diagram dijelaskan dalam tabel 2.2 berikut:
Tabel 2. 2 Simbol use case
Simbol Use case
Urutan langkah-langkah yang secara tindakan saling terkait (skenario), baik terotomasi mapun secara manual, untuk tujuan melengkapi satu tugas bisnis tunggal
Simbol aktor
14
2.4.4. Pemodelan Proses
2.4.4.1.Context Data Flow Diagram
Context data flow diagram adalah Model proses untuk
mendokumentasikan lingkup sistem (Whitten, 2004). Simbol yang digunakan dalam context data flow diagram dijelaskan dalam tabel 2.3 berikut:
Tabel 2. 3 Simbol Context Data Flow Diagaram
Agen eksternal
Orang, unit organisasi, sistem atau organisasi luar yang berinteraksi dengan sistem.
Id proses Nama proses
Kerja yang dilakukan oleh sistem sebagai respon terhadap aliran data masuk atau kondisi.
2.4.4.2.Diagram Aliran Data (DAD)
DAD merupakan alat yang digunakan pada metodologi penegembangan sistem yang terstruktur (Structured Analysis and Design). Simbol yang digunakan dalam DAD dijelaskan dalam tabel 2.4:
Tabel 2. 4 Simbol DAD
Agen eksternal
Orang, unit organisasi, sistem atau organisasi luar yang berinteraksi dengan sistem.
Id proses Nama proses
Kerja yang dilakukan oleh sistem sebagai respon terhadap aliran data masuk atau kondisi.
Penyimpanan data yang ditujukan untuk penggunaan selanjutnya.
16
2.4.5.Desain Database
2.4.5.1.Entity Relationship (E-R Diagram)
Mangacu pada teory dari atzeni, Entity-Relationship adalah model data
conceptual , yang menggambarkan data requirement pada sebuah aplikasi dengan
cara yang mudah dipahami. Daftar symbol ER Diagram disajikan pada tabel 2.5 berikut:
Tabel 2. 5 Simbol ER
Graphical Representation Construct
Entity
Relationship
Simple atribut
Composite atribut
Cardinality of a
Cardinality of an atribut
External identifier
Generalization
subset
2.5. Aplikasi Web
Aplikasi web adalah suatu aplikasi yang dapat membentuk halaman-halaman web berdasarkan permintaan pemakai. Aplikasi web merupakan salah satu contoh aplikasi klien/server. Klien mewakili computer yang digunakan oleh seorang pemakai yang henadak menggunakan aplikasi, sedangkan server mewakili computer yang menyediakan layanan aplikasi. Dalam konteks ini, klien dan server berhubungan dengan internet maupun intranet .
Ciri khas lain pada penggunaan aplikasi web, pamakai menggunakan perangkat lunak yang dinamakan web browser atau sering disebut browser saja (misalnya Netscape Communicator, Internet Explorer, dan Mozilla) untuk mengakses aplikasi web.
Komputer yang bertindak sebagai server umunya amenyediakan database
server, selain web server yang ditujukan untuk melayani permintaan pemakai
18
2.6. Servlet
Sebuah servlet berfungsi untuk memperluas fungsionalitas sebuah server (server web, server aplikasi, server HTTP). Servlet adalah program java yang diintegrasikan di dalam web server untuk melakukan fungsi-fungsi server side. Fungsi server side ini dijalankan untuk menanggapi permintaan dari client (berupa web browser).
2.6.1. JSP (Java Server Pages)
JSP merupakan perluasan dari teknologi servlet. Tujuan dari JSP adalah untuk lebih menyederhanakan penulisan servlet. JSP sendiri pada akhirnya, sebelum dijalankan oleh server, akan dikompilasi terlebih dahulu menjadi servlet, meskipun proses ini tidak akan terlihat oleh kita. JSP dan servlet dapat dipakai bersama-sama dalam sebuah aplikasi web.
JSP lebih menitikberatkan pada aspek prsentasi ketimbang aspek aplikasi. Untuk JSP, kode java dan HTML digabungkan dalam satu file, yaitu file yang memeiliki ekstensi “.jsp”. dalam JSP layer presentasi boleh dikatakan terpisah dari logika aplikasi atau logika bisnis. (Kadir, 2004)
JSP menyediakan sejumlah objek yang dikenal dengan sebutan objek
Tabel 2. 6 daftar variable terdefinisi dalam JSP
Objek Keterangan
request Variable ini berhubungan dengan objek permintaan HTTP(HTTPSevletRequest). Valiabel ini memungkinkan pengaksesan seperti parameter-parameter permintaan, tipe permintaan (GET atau POST), dan judul HTTP.
response Variable ini berhubungan dengan objek tanggapan terhadap klien (HTTPServletRespons). Antara lain dapat digunakan untuk menciptakan cookie.
out Variable ini digunakan untuk mengirimkan keluaran ke klien (merujuk ke objek Printer writer, yang terdapat di pada paket javax.servlet.jsp.JspWriter). variable ini sudah biasa digunakan, dalam bentuk out.println() atau out.print().
session Variable ini digunakan untuk menangani sesi. Merupakan variable yang merujuk ke objek HTTPSession.
application Servlet context
config Merupakan variable yang merujuk ke objek SevletConfig untuk halaman sekarang
pageContext Menyimpan informasi tentang objek halaman sekarang PageContext.
20
Pada prinsipnya pemakaian JSP mirip seperti pemakaian servlet. Secara garis besar JSP dipakai sebagai berikut:
1. Client mengirimkan request HTTP kepada JSP-container (atau
disebut juga JSP engine).
2. JSP-container menentukan class yang mengimplementasikan
halaman JSP, yang dituju oleh request. (Class ini disebut JSP page implementation class).
3. JSP-container kemudian memanggil salah satu method dari class
implementasi tersebut untuk menangani request secara dinamis dan menghasilkan response yang berupa content halaman HTML.
output halaman HTML diserahkan kepada JSP-container untuk dikirimkan
sebagai response kepada client. (Wijono,2006)
Garis besar arsitektur pemakaian JSP dijelaskan dalam gambar 2.2 berikut.
Database Web-browser
(client) Web-browser HTTP-request
HTTP-response
JSP page implementasi class
JSP JavaBeans
HTTP request
HTTP respons
JDBC. EJB (..)
JSP-container
Kode JSP pada dasarnya adalah kode HTML yang dilengkapi dengan tag-tag JSP. Pada tag-tag-tag-tag inilah program menyisipkan kode dalam bahasa java.
Contoh kode JSP:
<HTML> <HEAD>
<TITLE>latihan HTML</TITLE> </HEAD>
<BODY> <%
Out.print(“Selamat Belanjar JSP”); %>
</BODY> </HTML>
Beberapa method yang ada pada variable request yang diwariskan dari servlet disebutkan dalam tabel 2.8 berikut.
Tabel 2. 7 Metode pada variable request yang diwariskan dari ServletRequest
Metode Keterangan getParameter(String
nama)
Memperoleh nilai parameter nama dnegan hasil bertipe string. Kalau parameter nama tidak tersedia, maka hasilnya berupa null. getParameterNames() Menghasilkan suatu enumeration yang berisi nama-nama
parameter yang terdapat dalam permintaan
getRemoteAddr() Mengsilkan suatu String yang menyatakan alamat IP klien yang mengirimkan permintaan.
Contoh penggunaan variable response unutk melakukan pengalihan ke URL yang lain disajikan dalam listing berikut
Nama file Redirect.jsp
<%
22
Sintaks tersebut akan membuat dokumen Request.jsp dijalankan, menggantikan Redirect.jsp.
Statement untuk menciptakan session:
session=request.getSession(true);
Statement untuk membentuk sesi:
setAtribut(String name, object nilai);
Statement untuk membaca data sesi:
getAtribut(String name);
statement untuk menghapus data sesi:
session.removeAttribut(String name);
(Kadir, 2004) 2.7. JDBC
JDBC merupakan bagian teknologi java, tepatnya bagian dari teknologi J2EE yang ditujukan untuk pengolahan database sehingga JDBC sering disebut java API untuk akses data.
Ada tiga macam statement dalam JDBC, yaitu:
1 Statement: Tipe statement untuk menjalankan perintah SQL biasa ke database. Tipe statement ini tidak dapat menerima parameter tetapi hanya menggunakan static SQL
2 PreparedStatement: Tipe statement ini untuk menjalankan perintah SQL yang telah terkompilasi, baik dengan atau tanpa input parameter. Tipe ini lebih cepat daripada statement biasa yang menggunakan perintah SQL yang secara berulang-ulang.
Pada dasarnya pemrograman database akan melibatkan unsur-unsur berikut:
1 Loading dan setting driver JDBC (class DriverManager). 2 Mendirikan koneksi database (interface Connection). 3 Membuat objek SQL-statement (interface statement). 4 Mengeksekusi SQL-statement
5 Menerima resultset sebagai data hasil eksekusi SQL-statement (Interface ResulSet).
6 Menampilkan data result-set (dalam pemrograman web, data akan ditampilkan dalam halaman web yang akan dikirimkan kepada client). Class java.sql.DriverManager dipakai untuk loading dan mengatur JDBC serta untuk mendirikan koneksi ke database. Ketika DriverManager membentuk koneksi dengan memakai method getConnection(), method ini akan mengemballikan objek connection.
Interface java.sql.Statement dipakai untuk menangani dan mengeksekusi
SQL-statement. Objek statement dapat dibuat dari objek Connection dengan
memekai method Connection.createStatement().
Resultset merupakan data tabel yang ada di dalam database. Jika kita menginginkan SQL-statement tertentu (perintah SELECT) ke database maka hasilnya berupa resultset, yaitu baris-baris data hasil query. Interface java.sql.ResulSet mengontrol letak kursor yang menunjukkan baris (record) yang sedang aktif di dalam tabel database.
24
JDBC dapat menggunakan arsitektur three-tier. Model three-tier untuk
JDBC dapat dijabarkan sebagai berikut:
a. Client tier
Client tier bertanggung jawab untuk representasi data, menerima input dari pengguna maupun event, dan mengontrol serta mengatur user interface.
b. Middle tier (Application—server tier)
Tier ini bertanggung jawab untuk implementasi ke client tier aturan bisnis (business rules) yang tersedia. Aturan bisnis ini menciptakan objek bisnis
(business object). Contohnya adalah IBM WebSphere, BEA WebLogic
Server, dan Oracle Application.
c. Data-server tier
Tier ini bertanggung jawab untuk penyimpanan data dan mengatur
ketersediaan aplikasi data. Biasanya data-server tier ini terdiri atas dari satu atau lebih server database relasional (misalnya Oracle atau MySQL) dan biasanya terdiri atas:
i. Tabel/view/trigger database
Digunakan secara utama untuk menyimpan data
ii. Stored Procedure
Digunakan untuk mengeksekusi database pada server-side.
iii. File server
Digunakan untuk menyimpan file-file berukuran sangat besar, misalnya gambar, file PDF, dan teks.
digambarkan oleh Parsian (2005) seperti pada gambar 2.3 berikut :
Gambar 2. 3 Tree tier JDBC pada aplikasi internet
2.8. Pengaturan Transaksi
Transaksi adalah sebuah aksi atau potongan aksi, yang dibawa oleh single user atau program aplikasi, yang membaca atau mengupdate isi database.
Untuk menjamin integritas data, suatu berbasis basis data harus menjaga agar sifat ACID dipenuhi oleh transaksi. sifat ACID meliputi:
1) Atomicity: Dalam setiap transaki, hanya ada 2 pilihan yaitu keduanya dilakukan dengan benar atau tidak dikerjakan sama sekali.
2) Consistency: Eksekusi transaksi dalam isolasi menjamin konsistensi basis data. Isolasi artinya tidak ada transaksi lain yang dieksekusi bersamaan.
26
transaksi Ti dan Tj, jika dilihat dari sisi Ti ada dua kemungkinan yang harus dipilih salah satu:
a) Tj harus selesai dieksekusi dulu sebelum Ti dieksekusi atau b) Tj dieksekusi setelah Ti selesai dieksekusi.
4) Durability: Setelah transaksi berhasil dieksekusi dengan lengkap, perubahan yang dikenakan terhadap basis data bersifat tetap, meskipun misalnya ada kegagalan sistem.
Status transaksi dijelaskan pada gambar 2.4 berikut:
Gambar 2. 4 Digram status transaksi
Penjelasan status transaksi diuraikan dalam tabel 2.8 berikut ini:
Tabel 2. 8 Penjelasan status transaksi
Status Keterangan active Keadaan awal; transaksi berada dalam keadaan ini
selama eksekusiberjalan
Partially committed Setelahstatemen terakhirdieksekusi
aborted Setelah transaksi rolled back dan basis data telah
dikembalikan ke keadaan sebelumtransaksi
Transaksi dikatakan committed jika sudah masuk committed state. Transaksi dikatakan aborted jika sudah masuk aborted state. Jika tidak committed atau aborted maka dikatakan terminated.
Jika transaksi memasuki failed state, maka transaksi harus rolled back. Maka transaksi akan masuk pada aborted state. Jika masuk aborted state, terdapat dua pilihan:
• Transaksi dapat di-restart sebagai transaksi baru
• Transaksi dapat di-kill
2.8.1.Concurrency Control
Concurrency control adalah proses pengaturan operasi yang simultan
dalam database tanpa mengganggu satu sama lain.
Masalah-masalah yang sering muncul dari transaksi yang concurrent antara lain:
1) Lost update problem
Contoh kasus lost update problem disajikan pada tabel 2.10
Tabel 2. 9 Lost update problem
time T1 T2 balx
t 1 Begin_transaction 100
t 2 Begin_transaction Read(balx) 100
t 3 Read(balx) balx= balx + 100 100
t 4 balx = balx - 10 Write (balx) 200
t 5 Write (balx) committed 90
t 6 committed 90
28
sama. Kedua transaksi ini dijalankan secara bersamaan yang menghasilkan ketidakkonsistenan data dengan nilai akhir account balx = 90. Jika kedua transaksi ini dieksekusi secara serial (satu setelah yang lain tanpa operasi yang tumpang tindih) akan menjaga konsistensi data dengan nilai akhir account balx = 190 mengabaikan transaksi yang mana yang dieksekusi lebih dulu.
2) Uncommitted Dependency
Contoh kasus uncommitted dependency disajikan dalam tabel 2.11 berikut:
Tabel 2.10 Uncommitted dependency
time T3 T4 balx
t 1 Begin_transaction 100
t 2 Read(balx) 100
t 3 balx= balx + 100 100
t 4 Begin_transaction Write (balx) 200
t 5 Read(balx) … 200
t 6 balx = balx - 10 rollback 200
t 7 Write (balx) 190
t 8 committed 190
3) Inconsistent Analysis Problem
Contoh kasus inconsistent analysis problem disajikan pada tabel 2.12 berikut:
Tabel 2. 11 Inconsistent analysis problem
time T5 T6 balx baly balz sum
t 1 Begin_transaction 100 50 25
t 2 Begin_transaction Sum=0 100 50 25 0
t 3 Read(balx) Read(balx) 100 50 25 0
t 4 balx = balx - 10 Sum=sum+ balx 100 50 25 100
t 5 Write (balx ) Read(baly) 90 50 25 100
t 6 Read(balz) Sum=sum+ baly 90 50 25 150
t 7 Balz = balz + 10 90 50 25 150
t 8 Write (balz ) 90 50 35 150
t 9 committed Read(balz) 90 50 35 150
t 10 Sum=sum+ balz 90 50 35 185
t 11 committed 90 50 35 185
Pada Tabel 2.12, transaksi penjumlahan transaksi T6 dieksekusi secara bersamaan dengan transaksi T5. Transaksi T6 melakukan penjumlahan nilai balx (100), baly (50), dan balz (25). Sementara itu pada saat yang bersamaan transaksi T5 telah mentransfer 10 dari balx ke balz, sehingga T6 akan menghasilkan nilai salah (lebih besar 10 dari yang seharusnya).
Metode locking adalah sebuah prosedur untuk mengotrol pengaksesan data secara concurrent. Ketika kebuah transaksi mengakses database, sebuah
lock dapat menolak akses pada transaksi lain untuk mencegah hasil yang salah. Permasalahan lost update problem ini dapat dicegah menggunakan teknik phase locking (2PL). Sebuah transaksi mengikuti protokol two-phase locking jika semua operasi locking mendahului operasi unlocking yang pertama dalam transaksi tersebut.
30
2.8.2.Metode Locking
Salah satu cara untuk menjamin terjadi serialisasi adalah dengan menerapkan protocol penguncian (locking protocol) pada tiap data yang akan diakses. Ada dua macam cara untuk melakukan penguncian pada data:
1. Shared. Jika sebuah transaksi Ti melakukan shared-mode lock pada data Q, maka transaksi tersebut dapat melakukan operasi read pada Q tetapi tidak dapat melakukan operasi write pada Q.
2. Exclusive. Jika sebuah transaksi Ti melakukan exclusive-mode lock pada data Q, maka transaksi tersebut dapat melakukan read dan write pada Q.
(Connolly, 2005).
2.8.3.Concurrency Contol dengan Teknik Two Phase Locking
Gambar 2. 5 Taksonomi Mekanisme Kontrol Konkurensi
Metode optimistic : Menunda sinkronisasi dari transaksi hingga selesai. Pendekatan locking
Sinkronisasi dari transaksi dicapai dengan lock fisik atau logika pada beberapa bagian dari database. Ukuran bagian ini (disebut locking granularity) menjadi hal yang penting.
¾ Centralized locking
Satu site dibuat menjadi site utama dimana tabel yang terkunci/ lock untuk semua database disimpan dan diberikan tanggungjawab untuk membuka locking.
¾ Primary copy locking
Satu kopi untuk setiap unit lock dibuat sebagai kopi utama dan kopian ini harus dilock untuk tujuan pengaksesan unit tertentu. Misalnya jika unit x direplikasi ke site 1, 2 dan 3, salah satu site dipilih sebagai site utama untuk x. Semua transaksi yang mengakses x terkunci di site 1 sebelum dapat mengakses kopi x. jika database tidak terreplikasi mekanisme locking kopi utama mendistribusikan tanggungjawab manajemen lock diantara sejumlah site.
¾ Decentralized locking
Tugas manajemen locking dibagi ke seluruh site dalam jaringan. Eksekusi sebuah transaksi melibatkan partisipasi dan koordinasi dari para penjadual di lebih dari satu site.
32
Urutan ini dimaintain dengan menugaskan timestamp ke transaksi dan item data yang disimpan di database. Algoritma ini disebut TO dasar, TO multiversion, atau TO conservative.
Hybrid
Beberapa locking-based dan timestamp yang digunakan bersama. LOCKING-BASED CC
Ide utamanya adalah untuk memastikan data dapat dibagi dengan operasi konflik yang diakses oleh satu operasi pada satu saat “Lock” untuk setiap unit lock.
Locking terjadi di transaksi sebelum diakses dan direset di akhir penggunaan. Unit lock tidak dapat diakses dengan sebuah operasi jika sudah dilock sebelumnya oleh yang lain.
Permintaan lock oleh sebuah transaksi diberikan jika lock yang terhubung tidak ditahan oleh transaksi lainnya (M8-DBMS).
Untuk mengatasi masalah concurrency di mysql dapat menerapkan teknik two-phase locking. Protokol ini terdiri dari dua fase, yaitu:
1. Growing phase. Fase dimana sebuah transaksi hanya boleh melakukan penguncian pada data. Pada fase ini, transaksi tidak boleh melakukan pembebasan pada data lain.
Dalam Two- phase – locking protocol banyak dipergunakan untuk menjaga sifat serializable dari suatu penjadwalan, namun protokol ini belum dapat menjamin bahwa tidak akan terjadi deadlock karena masih ada transaksi yang berada dalam status menunggu (Connolly, 2005).
Langkah penerapan teknik two-phase locking dalam mySql: 1. tingkat isolasi serializable.
2. Autocommit dibuat disable.
34 BAB III
ANALISIS DAN DESAIN SISTEM 3.1. Analisis Sistem
3.1.1. Struktur Organisasi Pengelola Keuangan Daerah di Kabupaten Rembang
Struktur Organisasi Pengelola Keuangan Daerah di Kabupaten Rembang ditujunkkan pada gambar 3.1 berikut
Kepala Daerah
Sekretaris Daerah
SKPKD/Satuan Kerja Pengelola Keuangan Daerah
BUD/Bendahara Umum Daerah
SKPD/Satuan Kerja Perangkat Daerah Kas Umum Daerah
Bendahara Penerimaan
Bendahara
Pengeluaran Kuasa Pengguna Pengguna Anggaran Pengguna Barang Anggaran
Pejabat Pelaksana Teknis Kegiatan Koordinator Pengelola
keuangan daerah
Pejabat Pengelola Keuangan Daerah
Tempat penyimpanan
uang daerah Bertindak sebagai bendahara umum daerah
Perangkat daerah selaku pengguna anggaran/barang
Unit kerja-unit Kerja Bendahara
Gambar 3. 1 Strutur Organisasi pengelolaan keuangan daerah di Kabupaten Rembang
Penjelasan Struktur Organisasi
Kabupaten Rembang, Kepala Bagian Keuangan Sekretariat Daerah Kabupaten Rembang, dan Kepala Bagian Kekayaan Daerah Sekretariat Daerah Kabupaten Rembang. Kepala Bagian Keuangan Sekretariat Daerah Kabupaten Rembang memliki tiga staff pembantu yaitu Kepala Sub Bagian Anggaran, Kepala Sub Bagian Perbendaharaan, dan Kepala Sub bagian Verifikasi.
Masing-masing PPTK memeliki tugas dan kewenangan. Tugas dan kewenangannya mencakup seluruh penatausahaan keuangan yang terjadi di kabupaten Rembang.
Dalam SKPD, pejabat yang berwenang dan bertanggungjawab menangani penatausahaan antara lain: Pengguna Anggaran/Pengguna Barang, Kuasa Pengguna Anggaran/ Kuasa Pengguna Barang, Pejabat Penatausahaan Keuangan SKPD(PPK SKPD), Pejabat Pelaksana Teknis Kegiatan (PPTK), Bendahara Penerimaan, Bendahara Pengeluaran, Bendahara Penerimaan Pembantu, Bendahara Pengeluaran Pembantu, Bendahara Pengeluaran Gaji, dan Bendahara Barang.
Pengguna Anggaran adalah Kepala SKPD. Pengguna Anggaran Bertanggungjawab penuh atas penatahusahaan yang terjadi pada SKPD yang dipimpinnya.
36
3.1.2. Gambaran Umum Sistem Penatausahaan Keuangan Daerah
Secara garis besar, sistem informasi keuangan daerah disajikan dengan gambar 3.2 berikut ini:
Pengelolaan Keuangan Daerah
Akun
erah Penatausahaan Penerimaan Keuangan daerah Surat Ketetapan Pajak
Daerah (SKP-daerah)/ Surat Ketetapan
Retribusi (SKR) STS
Pertanggungjawaban penerimaan
Surat Pengesahan Surat Pertanggungjawaban
Rancangan Dokumen Pelaksanaan Anggaran Satuan Kerja Perangkat Daerah (DPA-SKPD)
Penyusunan DPA-SKPD dan Anggaran kas Rancangan
Anggaran Kas SKPD
Pengesahan SPJ pengeluaran laporan keuangan
SKPD
Gambar 3. 2 Prosedur Pengelolaan Keuangan Daerah
Penjelasan sistem penatausahaan keuangan daerah:
penyusunan dokumen pelaksanaan anggaran satuan kerja, penatausahaan pengeluaran keuangan daerah, dan akuntansi satuan kerja perangkat daerah.
Fungsi penatausahaan penerimaan daerah, dimulai dari penerbitan Surat ketetapan pajak dan surat ketetapan retribusi daerah (SKP/ SKR daerah) kemudian berdasarkan data dari SKP/SKR tersebut dibuat Surat Tanda Setor (STS).
STS dan data SKP/SKR menjadi dasar dalam proses pembuatan pertanggungjawaban penerimaan. Surat pertanggungjawaban penerimaan kemudian disahkan dan diterbitkan surat pengesahan SPJ penerimaan. SPJ penerimaan menjadi dasar bagi proses pembuatan laporan keuangan daerah pada fungsi akuntansi satuan kerja perangkat daerah.
Fungsi penyusunan dokumen pelaksanaan anggaran satuan kerja dimulai dari rancangan anggaran DPA SKPD yang diajukan oleh masing-masing SKPD dan rancangan anggaran kas SKPD. Dua macam dokumen tersebut kemudian menjadi dasar proses penyusunan DPA SKPD dan anggaran kas. Dari proses penyusunan DPA SKPD dan anggaran kas dihasilkan DPA SKPD dan anggaran kas yang menjadi dasar bagi fungsi penatausahaan pengeluaran keuangan daerah.
38
3.1.2.1.Penatausahaan Penerimaan Keuangan Daerah
Semua penerimaan daerah dalam rangka pelaksanaan urusan pemerintahan daerah dikelola dalam APBD. Setiap Satuan Kerja Perangkat Daerah (SKPD) yang mempunyai tugas memungut atau menerima pendapatan daerah wajib melaksanakan pemungutan dan atau penerimaan berdasarkan ketentuan yang ditetapkan dalam peraturan perundang-undangan.
Prosedur penerimaan yang dilakukan oleh bendahara maupun bendahara penerimaan pembantu adalah sama, disajikan dalam gambar 3.3 berikut ini:
Pelaksanaan penerimaan daerah
Bendahara Umum Daerah (BUD) Bendahara penerimaan pembantu/
Bendahara penerimaan
SKP daerah/SKR SKP daerah/SKR
uang uang
verifikasi
Surat tanda bukti pembayaran/bukti lain yang sah
sts
uang
Surat tanda bukti pembayaran/bukti
lain yang sah sts
uang mbar 3. 3 flowchart penerimaan daerah
Penjelasan gambar 3.3 adalah sebagai berikut:
40
2) wajib pajak/retribusi membayarkan uang kepada bendahara penerimaan/bendahara penerimaan pembantu sejumlah yang tertera pada Surat Ketetapan Pajak (SKP) daerah/ Surat Ketetapan Retribusi (SKR).
3) bendahara penerimaan/bendahara penerimaan pembantu memverifikasi uang yang diterima dengan SKP daerah/ SKR dari pengguna anggaran.
4) jika sesuai maka bendahara penerimaan/bendahara penerimaan pembantu membuat dokumen Surat Tanda Setor (STS) dan surat tanda bukti pembayaran lainnya yang sah.
5) bendahara penerimaan/ bendahara penerimaan pembantu menyerahkan surat tanda bukti pembayaran/bukti lain yang dah kepada wajib pajak/retribusi dan STS beserta uang kepada bank.
6) bank mengortorisasi STS dan menerbitkan nota kredit. Bank mengembalikan STS bendahara penerimaan/bendahara penerimaan pembantu. Nota kredit disampaikan kepada Bendahara Umum Daerah(BUD).
3.1.2.1.1. Pertanggungjawaban Bendahara Penerimaan
Prosedur pertanggungjawaban bendahara penerimaan disajikan dengan gambar 3.4 berikut:
Spj penerimaan
Skp daerah, skr, dan Surat tanda bukti pembayaran/ bukti lain yang sah
BKU penerimaan
Buku rekapitulasi penerimaan
Buku rekapitulasi
Spj evaluasi, dan
analisis
Surat pengesahan Spj
penerimaan
Surat pengesahan Spj
penerimaan
Surat pengesahan
SPJ penerimaan
Gambar 3. 4 flowchart pembuatan SPJ penerimaan
42
1) berdasarkan dokumen Surat Ketetapan Pajak (SKP), Surat Tanda Setor (STS), dan surat tanda bukti pembayaran atau bukti lain yang sah, bendahara penerimaan melakukan penatausahaan penerimaan.
2) dari proses penatausahaan penerimaan, bendahara penerimaan akan menghasilkan dokumen sebagai berikut:
a. Buku Kas Umum(BKU) penerimaan
b. Buku Kas Umum(BKU) pembantu (rincian objek penerimaan) c. Buku rekapitulasi penerimaan harian
3) berdasarkan ketiga dokumen tadi ditambah dokumen Surat Pertanggungjawaban (SPJ) penerimaan pembantu, bendahara penerimaan membuat SPJ penerimaan. Lampiran SPJ penerimaan:
a. BKU
b. Buku pembantu per rincian objek c. Buku rekapitulasi penerimaan harian d. Bukti penerimaan lain yang sah
4) bendahara penerimaan menyerahkan SPJ penerimaan kepada Pejabat Pengelola Keuangan Satuan Kerja Perangkat Daerah(PPK-SKPD)
5) PPK-SKPD menyerahkan SPJ penerimaan kepada pengguna anggaran
6) setelah diotorisasi, pengguna anggaran menyerahkan SPJ penerimaan kepada BUD
7) dalam rangka rekonsiliasi penerimaan, BUD memverifikasi, mengevaluasi, dan menganalisis SPJ penerimaan.
