BAB IV PERANCANGAN SISTEM Perancangan sistem adalah suatu gambaran sketsa sistem atau pengaturan dari beberapa elemen yang terpisah ke dalam kesatuan yang utuh dan berfungsi. Perancangan ini dibuat untuk ditunjukkan kepada user, programmer, atau ahli analisa atau ahli yang berhubungan dengan perancangan ini. Perancangan sistem dibuat berdasarkan masukan dari hasil analisa untuk menyelesaikan permasalahan yang ada pada tahap analisa. 4.1 Prosedur Kas Kecil yang Diusulkan Dibawah ini adalah usulan prosedur pembelian barang yang ada di Bank UOB Indonesia Capem Bintan adalah sebagai berikut : 1. Pembayaran kembali atas biaya yang telah dikeluarkan oleh Penagih dapat dilakukan dengan menyerahkan nota atau kwitansi asli kepada bagian Back Office. Nota atau kwitansi yang diserahkan haruslah nota atau kwitansi yang asli serta telah ditanda tangan oleh Pimpinan sebagai bukti bahwa biaya tersebut telah disetujui. Tujuan menggunakan nota atau kwitansi asli adalah untuk menghindari terjadinya penagihan kembali atas tagihan biaya yang sama. 55
56 2. Bagian Back Office akan mengecek kelengkapan keterangan yang ada pada nota atau kwitansi tersebut, jika ada keterangan yang tidak lengkap atau tidak jelas maka Penagih wajib melengkapinya. Tujuan melengkapi keterangan nota atau kwitansi adalah untuk memastikan biaya yang dimasukkan ke aplikasi sesuai dengan jenis biaya yang telah dikeluarkan. 3. Nota atau kwitansi yang sudah lengkap akan diinput atau dimasukan ke dalam database sesuai dengan jenis biaya yang dikeluarkan. Setiap jenis biaya memiliki kode biayanya masing masing untuk membedakan jenis biaya yang satu dengan yang lainnya dan mempermudah dalam pencarian data jenis biaya yang dimaksud. 4. Setelah nota atau kwitansi selesai diinput, maka bagian Back Office mencetak jurnal debet dan jurnal kredit. Jurnal debet merupakan jurnal untuk mendebet biaya yang dikeluarkan sedangkan jurnal kredit merupakan jurnal untuk membayaran atas biaya tersebut. 5. Jurnal debet, jurnal kredit dan nota atau kwitansi kemudian diserahkan kepada Supervisor. Jika disetujui maka jurnal debet dan jurnal kredit ditanda tangan dan jika tidak disetujui (adanya kesalahan pada jurnal) maka jurnal jurnal tersebut dikembalikan ke bagian Back Office untuk diperbaiki. 6. Setelah disetujui dan ditanda tangan oleh Supervisor maka jurnal debet, jurnal kredit dan nota atau kwitansi diteruskan ke Pimpinan. Pimpinan
57 menanda tangani jurnal debet dan jurnal kredit jika terdapat paraf pada nota atau kwitansi tersebut. 7. Jurnal debet dan jurnal kredit akan diproses lanjut oleh bagian Teller. Bila jurnal debet dan jurnal kredit sudah lengkap ditanda tangani oleh Supervisor dan Pimpinan, maka bagian Teller akan melakukan pembayaran sesuai dengan nilai yang tercantum dalam jurnal kredit dan jenis pembayarannya. Jika terdapat nomor rekening penagih maka pembayaran akan disetor atau dimasukan ke rekening penagih jika tidak pembayaran berupa tunai. 8. Untuk pembayaran berupa tunai akan diterima dan dicek kembali oleh bagian Back Office, sedangkan untuk pembayaran melalui rekening maka bagian Back Office mengfotokopikan jurnal kredit yang sudah diinput dan divalidasi sebagai bukti telah dilakukan pembayaran. 9. Nota atau kwitansi yang sudah dibayar oleh Teller oleh bagian Back Office akan diberikan stempel Paid dan tanggal pembayaran pada nota atau kwitansi yang kemudian ditanda tangan oleh Penagih bila sudah sesuai menerima pembayarannya. Untuk pembayaran melalui rekening penagih maka nota atau kwitansi diarsipkan bersama dengan fotokopi jurnal kredit yang sudah divalidasi.
58 10. Bagian Back Office mencetak laporan kas kecil sebanyak 2 (dua) rangkap dimana rangkap pertama diberikan kepada Pimpinan dan rangkap lainnya diarsipkan oleh bagian Back Office. 4.2 Flow Map yang Diusulkan Aliran dokumen (flow map) merupakan bagian aliran yang menunjukkan arus dari dokumen-dokumen termasuk tembusan-tembusannya. Adapun aliran dokumen (flow map) yang sedang Diusulkan dapat dilihat pada gambar berikut :
59 Flowmap Usulan Halaman 1/2 PENAGIH TELLER BACK OFFICE SUPERVISOR PIMPINAN Pengece kan Input Jurnal Kredit Jurnal Debet DBKasKecil Pengece kan Jurnal Cetak Jurnal Disetujui T Jurnal Kredit Jurnal Debet 1 Y TTD Jurnal Jurnal Kredit Jurnal Debet Jurnal Kredit Jurnal Debet TTD Jurnal Jurnal Kredit Jurnal Debet Jurnal Kredit Jurnal Debet Melakukan Pembayaran Pembayaran Pembayaran Pengecekan Pembayaran Sesuai T Y 2
60 Flowmap Usulan Halaman 2/2 PENAGIH TELLER BACK OFFICE SUPERVISOR PIMPINAN 2 Stempel Paid Pembayaran Pembayaran Tanda Tangan Pembayaran 1 Cetak Laporan Laporan 2 Laporan 1 Laporan 1 Gambar 4.1 Flowmap Kas Kecil yang diusulkan
61 4.3 Diagram Konteks Diagram konteks adalah diagram yang menggambarkan hubungan antara entitas eksternal dengan sistem. Dimana data yang diinputkan oleh bagian entitas eksternal akan diproses didalam sistem dan akan menghasilkan laporan yang diinginkan oleh entitas eksternal tersebut. Supervisor Jurnal Pembayaran Laporan Jurnal Penagih Data Aplikasi Petty Cash / Kas Kecil Bank UOB Indonesia Capem Bintan Data Pembukuan Pimpinan Jurnal Pembayaran Teller Gambar 4.2 Diagram Konteks
62 4.4 Data Flow Diagram Data Flow Diagram (DFD) adalah diagram yang digunakan untuk menggambarkan suatu sistem yang sudah jadi atau sistem yang baru dirancang yang akan dikembangkan secara logika, tanpa mempertimbangkan lingkungan fisik kemana data tersebut disimpan, disamping itu Data Flow Diagram (DFD) juga dapat menggambarkan arus data yang terstruktur dan jelas dari mulai pengisian data sampai dengan pengelurannya. Arus data pada Data Flow Diagram (DFD) ini dapat berupa masukan untuk sistem atau keluaran dari sistem, sehingga akan menghasilkan sebuah keluaran yang disampaikan pda pengguna atau penerima sistem.
63 Penagih Pembayaran Teller Supervisor Pembayaran Jurnal Jurnal Data 1.0* Input Data Data 2.0* Cetak Data Data T_Rincian T_Jurnal Kode Pembukuan Jurnal dan Laporan T_KodeGL Kode Pembukuan Kode Pembukuan 3.0 Input Data Pembukuan Data Pembukuan Pimpinan Gambar 4.3 DFD Level 0 Aplikasi Kas Kecil Dari DFD level 0 di atas terdapat tiga proses yang dapat dijabarkan sebagai berikut : 1. Proses 1.0 adalah proses penginputan data data tagihan yang langsung dihubungkan dengan Tabel Rincian dan Tabel Jurnal. 2. Proses 2.0 adalah proses mencetakan jurnal berdasarkan jurnal yang telah dimasukkan (jurnal debet atau kredit) dan mencetak laporan yang dihubungkan dengan Tabel Jurnal.
64 3. Proses 3.0 adalah proses yang penginputan data pembukuan yang dihubungkan dengan Tabel KodeGL. a. Level 1 Proses 1.0 Input Data Merupakan pengembangan proses 1 dari DFD level 0. Untuk lebih jelasnya dapat dilihat pada gambar berikut ini: Penagih Data Pembayaran T_KodeGL Kode Pembukuan 1.1 Input Data T_Jurnal Data Data T_Rincian Data No Batch 1.2 Hapus Data Gambar 4.4 DFD Level 1 Proses 1.0 Input Data DFD Level 1 proses 1.0 terdiri dari beberapa proses diantaranya adalah sebagai berikut :
65 1. Proses 1.1 Input Data yaitu proses penyimpanan inputan data tagihan ke dalam tabel Rincian. 2. Proses 1.2 Hapus Data yaitu proses penghapusan data tagihan yang telah dimasukkan sebelumnya ke dalam tabel Rincian. b. Level 1 Proses 2.0 Cetak Merupakan pengembangan proses 2 dari DFD level 0. Untuk lebih jelasnya dapat dilihat pada gambar berikut ini: Gambar 4.4 DFD Level 1 Proses 2.0 Cetak
66 DFD Level 1 proses 2.0 terdiri dari beberapa proses diantaranya adalah sebagai berikut : 1. Proses 2.1 mencetak Jurnal Debet dan Jurnal Kredit yang berdasarkan data tagihan yang telah diinput yang berhubungan dengan Tabel Jurnal. 2. Proses 2.2 mencetak laporan dari Tabel Jurnal. 4.5 Struktur File Didalam pembuatan program dibutuhkan suatu spesifikasi file yang dimaksudkan untuk dapat melakukan kegiatan-kegiatan dalam pengaturan dan pencarian data dan pembuatan laporan yang dapat mempermudah kerja sistem computer. Untuk itu sistem pengolahan data ini membutuhkan spesifikasi file untuk mempermudah dalam melakukan pemrograman, yang dapat dilihat dari table-tabel berikut ini : Nama Tabel : T_User Primary Key : User Tabel 4.1 Struktur File Tabel Pengguna (User) No Nama Field Tipe Ukuran Keterangan 1 User Text 20 Nama Pengguna atau User 2 Sandi Text 20 Sandi atau Password User 3 Level Text 15 Level atau tingkat User 4 Status Text 3 Status User
67 Nama Tabel : T-KodeGL Primary Key : KodeGL Tabel 4.2 Struktur File Tabel Kode Pembukuan No Nama Field Tipe Ukuran Keterangan 1 KodeGL Text 12 Kode pembukuan 2 Keterangan Text 40 Keterangan dari kode pembukuan 3 Penjelasan Text 150 Penjelasan dari kode pembukuan Nama Tabel : T_Rincian Primary Key : - Tabel 4.3 Struktur File Tabel Rincian No Nama Field Tipe Ukuran Keterangan 1 No_Batch Text 12 Nomor urut Batch 2 Tanggal Date/Time mmddyy Tanggal transaksi 3 KodeGL Text 12 Kode pembukuan Keterangan darikode pembukuan 4 Keterangan Text 40 5 Jenis_Pembyr Text 15 Jenis pembayaran Tunai atau Rekening 6 Jenis_Jurnal Text 6 Jurnal Debet atau Kredit 7 Rincian Text 50 Rincian keterangan tagihan 8 Jumlah Currency Currency Jumlah dari tagihan Nama Tabel : T_Jurnal Primary Key : - Tabel 4.4 Struktur File Tabel Jurnal No Nama Field Tipe Ukuran Keterangan 1 No_Batch Text 12 Nomor urut Batch 2 Tanggal Date/Time mmddyy Tanggal transaksi 3 KodeGL Text 12 Kode pembukuan
68 4 Keterangan Text 40 Keterangan kode pembukuan 5 Jenis_Pembyr Text 15 Jenis pembayaran Tunai atau Rekening 6 Jenis_Jurnal Text 6 Jurnal Debet atau Kredit 7 Pajak Currency Currency Pajak Service sebesar 2% 8 Total Currency Currency Total tagihan 4.6 Entity RelationShip Diagram ( ERD ) Entity RelationShip Diagram ( ERD ) atau diagram antar entitas adalah suatu diagram yang menggambarkan hubungan objek data yang disimpan yang ada dalam suatu aplikasi secara konseptual. Objek Data adalah objek yang dapat dicatat atau direkam atau segala sesuatu yang ada dan dapat dibedakan entitas dapat berupa orang, benda, tempat, peristiwa, atau konsep yang bisa diolah untuk menghasilkan informasi, rancangan diagram entitas ini dibuat menurut data yang ada sehingga dapat menjelaskan hubungan datadata. Atribut yang berhubungan dengan Aplikasi Petty Cash (Kas Kecil) Bank UOB Indonesia Capem Bintan dapat digambarkan sebagai berikut :
69 Gambar 4.6 Entity RelationShip Diagram ( ERD ) 4.7 Perancangan Antar Muka (Interface) Perancangan Interface adalah tahap dimana desain sistem yang telah dipersiapkan dan selesai ditampilkan menjadi interaksi antarmuka user atau pengguna dalam program itu sendiri. Pada tahap perancangan antarmuka diusahakan untuk mengurangi kesulitan pengunaan program agar user lebih mudah untuk memakainya. 4.7.1 Perancangan Input Rancangan input adalah rancangan dari dokumen dasar yang digunakan untuk merekap data yang digunakan. Perancangan input meliputi bentuk dokumen-dokumen input yang akan digunakan untuk menangkap data input.
70 Gambar 4.7 Form Login Gambar 4.8 Form Input Transaksi Jurnal
71 Gambar 4.9 Form Penghapusan Transaksi Jurnal Gambar 4.10 Form Input Kode Pembukuan
72 Gambar 4.11 Form Edit Kode Pembukuan Gambar 4.12 Form Input User Baru
73 Gambar 4.13 Form Edit User Baru Gambar 4.14 Form Inquiry Data
74 Gambar 4.15 Form Cetak Laporan 4.7.2 Perancangan Output Rancangan output adalah rancangan dalam bentuk laporan dari hasil pemrosesan input yang diterima dari sistem pengolahan data tersebut. Untuk menentukan rancangan keluaran diperlukan kecermatan, ketelitian dan kesabaran dengan harapan keluaran yang dihasilkan merupakan laporan-laporan yang akurat dan releven serta dapat dimengertikan oleh pemakaiannya.
75 Gambar 4.16 Laporan Pengeluaran Kas Kecil Berdasarkan Semua Transaksi Gambar 4.17 Laporan Pengeluaran Kas Kecil Berdasarkan Tanggal
76 Gambar 4.18 Laporan Pengeluaran Kas Kecil Berdasarkan Bulan 4.8 Perancangan Struktur Menu Struktur menu merupakan bentuk umum dalam suatu perancangan aplikasi yang dapat memudahkan pengguna dalam menggunakan aplikasi yang dibangun. Dengan adanya struktur menu ini, maka proses pengolahan data diharapkan lebih cepat dilakukan, sehingga keterlambatan dalam penyajian data dapat ditekan seminimal mungkin.
77 Struktur menu yang dibuatkan dalam aplikasi ini terdiri dari menu-menu dan sub menunya. Dapat dilihat dari gambar berikut : Gambar 4.19 Perancangan Struktur Menu 4.9 Perancangan Struktur Program Struktur program adalah suatu konsep pembuatan yang mempunyai fungsi untuk mengelompokkan instruksi kedalam sub program fungsional dimana setiap sub program tersebut memiliki tugas dan fungsi tertentu yang digunakan untuk mendukung dari keseluruhan program yang dibuat. Struktur program yang dibuat adalah sebagai berikut :
78 STRUKTUR PROGAM INPUT PROSES OUTPUT DATA USER INQUIRY LAPORAN DATA PEMBUKUAN VOUCER DATA TAGIHAN Gambar 4.20 Perancangan Struktur Program