BAB 4 ANALISIS DAN PERANCANGAN SISTEM INFORMASI AKUNTANSI PD. ARENA NUSANTARA
4.1 Analysis Document 4.1.1 The Task 4.1.1.1 Purpose Pengembangan sistem akuntansi penjualan kredit dan piutang dagang pada perusahaan ini dilakukan unuk mendukung pencatatan dan pengendalian internal atas transaksi harian penjualan kredit dan piutang dagangnya yang sampai sekarang, mulai dari kegiatan penerimaan pesanan dari pelanggan, permintaan barang, pengiriman barang, penyiapan tagihan, dan sampai pencatatan pembayaran tagihan masih dilakukan secara tradisional (noncomputerized).
4.1.1.2 System definition Sistem informasi akuntansi penjualan kredit dan piutang dagang yang digunakan pada PD. Arena Nusantara sebagai alat bantu untuk menangani pencatatan aktivitas harian perusahaan yang berhubungan dengan penjualan kredit dan piutang dagang. Sistem ini menggunakan arsitektur client-server. Dimana setiap client dan server menggunakan PC biasa berbasis windows dan client akan terhubung pada server dengan menggunakan jaringan seperti LAN
95 (Local Area Network). Pengembangan dilakukan berdasarkan usulan perbaikan dari permasalahan yang diytemui dalam aktivitas berjalan perusahaan. Untuk lebih jelasnya, system definition dari sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara dapat dilihat pada gambar berikut :
96 Mendukung pencatatan dan pengendalian kegiatan penjualan
Functionality
kredit dan piutang dagang sehingga dapat menghasilkan informasi penjualan kredit dan piutang dagang yang reliable dan up-to-date. Application Domain
Direktur dan karyawan-karyawan pada Divisi Penjualan, Divisi Pembelian, Divisi Gudang, Divisi Akuntansi dan Keuangan, Bagian Pengiriman yang akan berinterksi dengan sistem informasi akuntansi penjualan kredit dan piutang dagang.
Condition
Sistem informasi akuntansi penjualan kredit dan piutang dagang ini dapat dikembangkan berdasarkan usulan untuk mengatasi permasalahan yang ditemukan dalam aktivitas penjualan kredit dan piutang dagang perusahaan.
Technology
Menggunakan beberapa Personal Computer (PC) dengan penambahan beberapa peralatan umum lainnya seperti printer, dll. PC akan terhubung pada server dengan menggunakan jaringan komputer lokal LAN dengan pola centralized system.
Object
Karyawan, pelanggan, persediaan, penjualan, piutang dagang, penerimaan pembayaran.
Responsibility
Alat administrasi yang efisien dan dapat diandalkan dalam pencatatan dan penyediaan informasi-informsi hasil dari transaksi harian penjualan kredit dan piutang dagang. Tabel 4.1 System Definition dengan kriteria FACTOR
97 4.1.1.3 Context Problem domain analysis Pada gambar 4.1 dapat dilihat gambaran rich picture yang diusulkan pada sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara.
K o n f ir m a s i
$ T ra n s fe r P a y m e n t T T P dan F P B ank B K M
S T
C ash P aym ent $
$
T re a s u re r T T P S T F P yg JT dan S T V IS IO C O R P O R A T IO N
S T P ( P e r m o h o n a n T d k D is e tu ju i/ L im it K r e d it T d k C k p )
$
U a n g (C a s h ), T T P (C a s h /T ra n s fe r), d a n N o ta (T ra n s fe r)
B K M
F in a n c e P e la n g g a n $ A c c o u n tin g
$ A c c o u n ts R e c e iv a b le
D P d a n a ta u P O F P d a n S J y g T e la h D io t o r is a s i S P B
S O
d a n S P K y g T e la h D io t o r is a s i
d a n S P K ( P e la n g g a n B a r u )
B O M
dan B P B
S O
S O
S J y g T e la h D io t o r is a s i
d a n a t a u S P K ( d it e r im a d a n t id a k )
S a le s F P dan S J
S P B
$
S J
F P y g T e la h D io to r is a s i
B o a r d o f D ir e c t o r s
$
S O
F P , S J , d a n B a ra n g
F P dan S J
$
S J y g T e la h D io t o r is a s i
B O M
S h ip p in g
B a rra n g In v e n to ry
P u r c h a s in g
F P , S J d a n B a ra n g
B P B P a c k a g in g B O M
d a n B a ra n g
98
99 Divisi Penjualan menerima pesanan dari pelanggan melalui sales, telepon, faksimili ataupun pelanggan yang langsung datang memesan di kantor. Permintaan dari pelanggan yang berupa Purchase Order (PO) kemudian akan dicek terlebih dahulu apakah pelanggan itu merupakan pelanggan lama atau pelanggan baru. Jika merupakan pelanggan baru, maka pelanggan akan dimintakan datanya untuk dimasukkan ke file pelanggan. PO baik dari pelanggan lama maupun pelanggan baru akan dimasukkan ke file pesanan Sales Order (SO) kemudian akan dicetak untuk diberikan kepada Divisi Kredit. Pada saat itu, status SO akan menjadi “waiting”. Berdasarkan SO yang diperoleh dari Divisi Penjualan, Divisi Kredit akan melakukan pengecekan kembali apakah pelanggan itu merupakan pelanggan lama atau pelanggan baru. Jika merupakan pelanggan baru, maka Divisi Kredit akan membuat Surat Permohonan Kredit (SPK) yang kemudian akan diserahkan kepada pimipinan atau Direktur. Setelah Direktur memberikan persetujuan atas limit kredit dan diskon yang dapat diberikan kepada pelanggan, maka Divisi Kredit akan meng-update limit kredit dan diskon pada file pelanggan sebelum SO dikembalikan ke Divisi Penjualan untuk diproses lebih lanjut. Tetapi jika persetujuan kredit ditolak, maka SO akan langsung diberikan kepada Divisi Penjualan untuk dibuatkan Surat Tolakan Pesanan (STP). SPK tetap disimpan oleh Divisi Kredit. Jika merupakan pelanggan lama maka Divisi Kredit akan langsung mengecek limit kredit dari pelanggan untuk mengetahui apakah status kreditnya dapat diterima atau ditolak. Jika status kreditnya dapat diterima, SO akan diberikan kepada Divisi Penjualan untuk diproses lebih lanjut. Tetapi jika status kreditnya ditolak, SO tersebut tetap akan diberikan kepada Divisi Penjualan untuk dibuatkan STP.
100 Pada Divisi Penjualan, SO yang ditolak akan dibuatkan STP untuk kemudian diteruskan kepada pelanggan, sedangkan status SO itu menjadi “cancelled”. Jika SO diterima maka Divisi Penjualan akan mencetak Surat Permintaan Barang yang kemudian akan diberikan kepada Divisi Gudang dan Divisi Akuntansi. Sementara SO akan tetap disimpan oleh Divisi Penjualan. Kemudian Divisi Gudang akan mengecek ketersediaan produk yang diminta berdasarkan SPB itu. Jika jumlah persediaaan tidak mencukupi untuk memenuhi pesanan maka Divisi Gudang akan mencetak Surat Perintah Pembelian yang kemudian diteruskan ke Divisi Pembelian dan Divisi Akuntansi. Setelah menerima barang dari Divisi Pembelian, Divisi Gudang akan melakukan pemeriksaaan dan pencocokan terhadap barang yang diterima dan kemudian akan mencetak Bukti Penerimaan Barang (BPB) lalu melakukan pencatatan pada Kartu Gudang. BPB itu kemudian akan diserahkan kepada Divisi Pembelian dan Divisi Akuntansi untuk dilakukan pengecekan terhadap persediaan yang masuk dengan membandingkan BPB itu dengan SPP yang diberikan. Divisi Gudang juga menyimpan copy dari BPB yang diserahkannya itu. Selanjutnya setelah barang yang dibutuhkan telah tersedia, Divisi Gudang akan mencetak Surat Jalan dan mencatat ke Kartu Gudang. Jika jumlah persediaan mencukupi untuk memenuhi pesanan maka Divisi Gudang akan langsung mencetak Surat Jalan (SJ) dan mencatat pada Kartu Gudang. Surat Jalan itu akan diberikan kepada Divisi Penjualan untuk diproses lebih lanjut. Sedangkan SPB tetap disimpan oleh Divisi Gudang.
101 Setelah menerima Surat Jalan dari Divisi Gudang, Divisi Penjualan akan membuat Faktur Penjualan (FP) dan pada saat itu jumlah persediaan akan ter-update dan status pesanan akan berubah menjadi “done”. Faktur Penjualan dan Surat Jalan akan diserahkan kepada Divisi Pengiriman dan Divisi Akuntansi. Salah satu FP itu tetap disimpan oleh Divisi Penjualan. Berdasarkan FP dan SJ yang diterima dari Divisi Penjualan, Divisi Pengiriman akan mengambil barang di gudang dan mengirimkannya kepada pelanggan. Dan berdasarkan FP, SJ dan SPB, Divisi Akuntansi akan melakukan pengecekan terhadap persediaan yang keluar. Oleh Divisi Pengiriman, salah satu SJ akan ditempelkan pada kotak barang sebagai packing slip. Sedangkan SJ yang lainnya beserta FP akan diberikan kepada pelanggan untuk dimintai tanda tangannya. Satu dari FP itu akan diberikan kepada pelanggan, sedangkan FP yang lainnya akan diberikan kepada Divisi Akuntansi. Lalu SJ akan diberikan kepada Divisi Gudang dan Divisi Penjualan. Oleh Divisi Gudang, SJ yang diberikan akan digunakan untuk mengetahui bahwa barang sudah dikirimkan dengan cara membandingkan dengan SPB yang diterima dari Divisi Penjualan. Sedangkan oleh Divisi Penjualan, SJ yang diterima dari Divisi Pengiriman akan digunakan untuk memastikan bahwa pesanan telah terpenuhi dengan membandingkan FP yang diterbitkan. Sistem penagihan dimulai oleh Divisi Akuntansi yang memeriksa piutang yang akan jatuh tempo dalam waktu kurang lebih dua minggu pada file piutang setiap harinya. Setelah mengetahui piutang-piutang mana yang akan jatuh tempo, Divisi Akuntansi akan menyiapkan FP dan membuat Surat Tagihan (ST) untuk piutang yang akan jatuh tempo itu.
102 FP dan ST itu akan diserahkan kepada Divisi Penagihan untuk dikirimkan kepada pelanggan dan juga kepada Divisi Keuangan sedangkan FP tetap disimpan oleh Divisi Penagihan. Divisi Akuntansi memegang satu copy dari ST itu. Oleh Divisi Keuangan, ST itu akan digunakan sebagai landasan untuk membuat Tanda Terima Pembayaran (TTP) secara manual. Kemudian TTP tersebut akan diberikan kepada Divisi Penagihan sedangkan ST tetap disimpan oleh Divisi Keuangan. Berdasarkan TTP dan FP yang diterima dari Divisi Keuangan maka Divisi Penagihan akan melakukan penagihan piutang kepada pelanggan. Pembayaran dapat dilakukan dengan dua cara, yaitu secara tunai dan transfer. Jika pembayaran secara tunai, Divisi Penagihan akan mengambil pembayaran langsung kepada pelanggan, sedangkan jika pembayaran secara transfer Divisi Penagihan akan menghubungi bank untuk mengecek apakah ada setoran masuk. Jika setoran masih belum masuk maka Divisi Penagihan akan menghubungi pelanggan via telepon. Jika pembayaran telah diterima, TTP dan FP akan diberikan kepada pelanggan, sedangkan TTP lainnya, uang atau pun bukti transfer akan diberikan kepada Divisi Keuangan. Berdasarkan data-data itu, Divisi Keuangan akan memasukkan data pembayaran pelanggan kemudian mencetak Bukti Kas Masuk (BKM). Beberapa BKM akan diberikan kepada Divisi Penagihan sebagai bukti bahwa pembayaran pelanggan telah diproses oleh kasir, sedangkan BKM lainnya, ST dan TTP akan disimpan oleh Divisi Keuangan. Divisi Penagihan akan memberikan salah satu BKM kepada Divisi Akuntansi untuk dibandingkan dengan ST guna memastikan pelunasan terhadap pesanan dan siklus penjualan telah berakhir.
103 Application domain Sistem yang dituju dapat mendukung tugas-tugas yang ditangani oleh karyawan divisi penjualan, karyawan divisi kredit, karyawan divisi gudang, karyawan divisi keuangan, karyawan divisi penagihan, karyawan divisi akuntansi dan direktur. Tugas-tugas utama dari application domain system adalah : pendataan pelanggan, terima pesanan, tolakan pesanan, permintaan barang, faktur penjualan, cek limit kredit, input limit kredit, cek piutang, permohonan kredit, bukti kas masuk, tagihan, laporan penjualan periode, laporan piutang, laporan penerimaan kas, dan laporan analisis umur piutang.
4.1.2 The Problem Domain 4.1.2.1 Clusters Model sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara secara keseluruhan terdiri dari beberapa cluster yaitu pelanggan, persediaan, penjualan, piutang. Berikut adalah gambaran model dari sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara.
104
P e r s e d ia a n
P iu t a n g
P e n ju a la n
P e la n g g a n
Gambar 4.2 Model sistem informasi akuntansi penjualan kredit dan piutang dagang.
4.1.2.2 Structure Seperti yang terlihat pada Gambar 4.3, setiap persediaan dalam sistem informasi akuntansi penjualan kredit dan penerimaan kas PD. Arena Nusantara memiliki banyak Back Order.
Gambar 4.3 Struktur dari “Persediaan” Pada Gambar 4.4, dapat diketahui bahwa pelanggan tidak memiliki struktur generalisasi ataupun agregasi.
Gambar 4.4 Struktur dari “Pelanggan”
105 Pada Gambar 4.5 terlihat bahwa penjualan pada sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara terdiri
Gambar 4.5 Struktur dari “Penjualan” Pada Gambar 4.6, dapat diketahui bahwa piutang tidak memiliki struktur generalisasi ataupun agregasi.
Gambar 4.6 Struktur dari Piutang Pada Gambar 4.7, dapat dilihat satu-satunya kelas yang memiliki hubungan genralisasi dengan kelas lainnya yaitu pada kelas “Kas Masuk”.
Gambar 4.7 Struktur dari “Bukti Kas”
106 Pada Gambar 4.8, dapat dilihat secara jelas dan lengkap bagaimana kelas-kelas yang membentuk sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara yang diusulkan dapat saling berhubungan.
Gambar 4.8 Kelas Diagram Lengkap Sistem Informasi Akuntansi Penjualan Kredit dan Piutang Dagang PD.Arena Nusantara.
107 4.1.2.3 Classes Setiap kelas-kelas diatas memiliki pola behavioural tersendiri. Berikut ini merupakan
statechart
diagram yang
menunjukkan pola behavioural atas kelas-kelas yang diwakilinya.
Gambar 4.9 Statechart kelas “Pelanggan”
Gambar 4.10 Statechart kelas “Sales Order”
108
Gambar 4.11 Statechart kelas “Surat Tolakan Pesanan”
Gambar 4.12 Statechart kelas “Surat Permintaan Barang”
Gambar 4.13 Statechart kelas “Piutang”
109
Gambar 4.14 Statechart kelas “Surat Jalan”
Gambar 4.15 Statechart kelas “Tagihan”
Gambar 4.16 Statechart kelas “Persediaan”
110
Gambar 4.17 Statechart kelas “Back Order”
Gambar 4.18 Statechart kelas “Faktur Penjualan”
Gambar 4.19 Statechart kelas “Bukti Penerimaan Barang”
111
Gambar 4.20 Statechart kelas “Bukti Kas Masuk Tunai”
112 Gambar 4.21 Statechart kelas “Bukti Kas Masuk Transfer”
+
*
Event Memesan * + + Mencatat + + + * + * * * * * * Add Item Membuat + + + + + + Menyelesaikan Instalasi Memverifikasi Instalasi Tabel 4.2 Tabel event sistem informasi penjualan kredit dan piutang dagang PD. Arena Nusantara
Bukti Penerimaan Barang
Surat Tagihan
Back Order
Bukti Kas Masuk Transfer
Bukti Kas Masuk Tunai
Faktur Penjualan
Surat Jalan
Surat Permintaan Barang
Surat Tolakan Pesanan
Sales Order
Piutang
Persediaan
Pelanggan
Class
+ *
113
4.1.3 The Application Domain 4.1.3.1 Usage Overview Terdapat enam aktor dalam sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara. Aktoraktor tersebut antara lain : Karyawan Divisi Penjualan, Karyawan Divisi Kredit, Karyawan Divisi Gudang, Karyawan Divisi Keuangan, Karyawan Divisi Penagihan, dan Karyawan Divisi Akuntansi. Use case tersebut antara lain :
114
Use Case
Divisi Divisi Penjualan Kredit X X X X X
Actors Divisi Divisi Gudang Keuangan
Divisi Akuntansi
Catat Terima Pesanan Pendataan Pelanggan Catat Tolakan Pesanan Catat Permintaan Barang Catat Faktur Penjualan Catat Perintah Pembelian X Catat Surat Jalan X Catat Penerimaan Barang X Cek Persediaan X Cek Limit Kredit X Cek Saldo Piutang X Input Kebijakan Kredit X Buat Permohonan Kredit X Bukti Kas Masuk X Cetak Surat Tagihan X Pendataan Produk X Cetak Laporan Penjualan Per Periode X Cetak Laporan Saldo Piutang X Cetak Laporan Penerimaan Kas X Tabel 4.3 Tabel aktor sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara
115
Berikut ini adalah actor description dari sistem informasi akuntansi penjualan dan penerimaan kas PD. Arena Nusantara.
Tujuan
Karyawan Divisi Penjualan Karyawan yang bertanggung jawab dalam menangani transaksi dari pelanggan, tolakan pesanan, permintaan barang, faktur penjualan
Karakteristik
Pada saat karyawan divisi penjualan menggunakan sistem untuk mencatat permintaan barang, sistem akan mencatat nama karyawan tersebut pada formulir hasil transaksi.
Contoh
Karyawan divisi penjualan A menangani pesanan yang datang dari pelanggan dengan membuat sales order, maka sistem akan mencatat nama dari karyawan divisi penjualan yang menangani sales order tersebut Tabel 4.4 Spesifikasi aktor Karyawan Divisi Penjualan
Tujuan
Karyawan Divisi Gudang Karyawan yang bertanggung jawab dalam menangani perintah pembelian, surat jalan, penerimaan barang, cek persediaan
Karakteristik
Pada saat karyawan divisi gudang menggunakan sistem untuk mencatat perintah pembelian, sistem akan mencatat nama karyawan tersebut pada perintah pembelian.
Contoh
Karyawan divisi gudang B mencatat perintah pembelian, maka sistem akan mencatat nama dari karyawan divisi gudang B pada perintah pembelian tersebut
116 Tabel 4.5 Spesifikasi aktor Karyawan Divisi Gudang
Tujuan
Karyawan Divisi Kredit Karyawan yang bertanggung jawab dalam menangani cek limit kredit, saldo piutang, input kebijakan kredit, permohonan kredit
Karakteristik
Pada saat karyawan divisi gudang menggunakan sistem untuk membuat permohonan kredit, sistem akan mencatat nama karyawan tersebut pada permohonan kredit.
Contoh
Karyawan divisi kredit C membuat permohonan kredit, maka sistem akan mencatat nama dari karyawan divisi kredit C pada permohonan kredit tersebut. Tabel 4.6 Spesifikasi aktor Karyawan Divisi Kredit
Tujuan
Karyawan Divisi Keuangan Karyawan yang bertanggung jawab dalam menangani bukti kas masuk.
Karakteristik
Pada saat karyawan divisi keuangan menggunakan sistem untuk membuat bukti kas masuk, sistem akan mencatat nama karyawan tersebut pada bukti kas masuk.
Contoh
Karyawan divisi keuangan D mencatat bukti kas masuk, maka sistem akan mencatat nama dari karyawan divisi keuangan D pada bukti kas masuk tersebut. Tabel 4.7 Spesifikasi aktor Karyawan Divisi Keuangan
117
Tujuan
Karyawan Divisi Akuntansi Karyawan yang bertanggung jawab dalam menangani laporan penjualan, laporan penerimaan kas, laporan piutang, laporan analisis piutang.
Karakteristik
Pada saat karyawan divisi akuntansi menggunakan sistem untuk membuat pendataan produk, sistem akan mencatat nama karyawan tersebut pada pendataan produk.
Contoh
Karyawan divisi akuntansi E membuat pendataan produk, maka sistem akan mencatat nama dari karyawan divisi akuntnasi E pada pendataan produk tersebut Tabel 4.8 Spesifikasi aktor Karyawan Divisi Akuntansi
118
Gambar 4.22 Use-case Sistem Informasi Akuntansi Penjualan Kredit dan Piutang Dagang PD. Arena Nusantara
119 Pendataan Pelanggan. Karyawan Divisi Penjualan. Menggambarkan proses pendataan pelanggan. 1. Use case dimulai pada saat karyawan divisi penjualan memilih form master pelanggan dari menu; 2. Sistem menampilkan form master pelanggan; 3. Karyawan divisi penjualan memilih tombol tambah; 4. Sistem menampilkan kode pelanggan pre-numberred, tetapi jumlah limit kredit dan diskon masih bernilai nol; 5. Karyawan divisi penjualan memasukkan nama pelanggan, alamat pelanggan, no. telepon, serta no. fax; 6. Karyawan divisi penjualan memilih tombol simpan; 7. Sistem akan menambahkan record pelanggan ke database pelanggan; Pelanggan. Object Add, Update. Function Jika pengisian atribut di atas tidak lengkap, maka pada saat Alternate course penyimpanan data sistem akan menampilkan pesan "Data Tidak Lengkap". Terdapat pelanggan yang melakukan pemesanan, tetapi belum Pre-condition. terdaftar dalam database perusahaan. Pelanggan telah tercatat dan pembuatan pesanan penjualan dapat Post-condition diproses. Tabel 4.9 Use case specification untuk “Pendataan Pelanggan”
Use case name Actor Description Normal course
120 Catat terima pesanan. Karyawan Divisi Penjualan. Menggambarkan proses pembuatan dokumen sales order. 1. Use case dimulai pada saat karyawan divisi penjualan memilih form pesanan dari menu; 2. Sistem menampilkan form pesanan; 3. Sistem menampilkan No. SO pre-numberred, tanggal, dan karyawan yang login; 4. Karyawan divisi penjualan memilih kode pelanggan yang ditamplikan dalam combo box; 5. Sistem menampilkan nama pelanggan; 6. Karyawan divisi penjualan memasukkan Reff No, lalu kode barang yang dipesan pelanggan; 7. Sistem menampilkan nama barang dan harga satuan; 8. Karyawan divisi penjualan memasukkan jumlah yang dipesan; 9. Sistem melakukan perkalian antara kuantitas yang dipesan dengan harga satuan; 10. Karyawan divisi penjualan memilih tombol simpan; 11. Sistem akan menyimpan record sales order ke database sales order. Pelanggan, Produk, SO. Object Add, Update, Cetak Sales Order Function Jika pengisian atribut di atas tidak lengkap, maka pada saat Alternate course penyimpanan data sistem akan menampilkan pesan "Data Tidak Lengkap". Terdapat pelanggan yang memesan produk, pelanggan telah Pre-condition menyetujui harga barang dan batasan kredit pelanggan tidak terlewati. Status Sales Order menjadi “Waiting” Past-condition Tabel 4.10 Use case specification untuk “Catat Terima Pesanan”
Use case name Actor Description Normal course
121 Use case name Actor Description Normal course
Cek limit kredit. Karyawan Divisi Kredit Menggambarkan proses pemeriksaan limit kredit pelanggan. 1. Use case dimulai pada saat karyawan divisi kredit memilih form cek limit kredit dari menu; 2. Sistem menampilkan form cek limit kredit; 3. Karyawan divisi kredit memilih kode pelanggan yang ditampilkan dalam combo box; 4. Sistem menampilkan nama pelanggan, dan limit kreditnya; Object Pelanggan, Piutang. Function Read Alternate course Pre-condition Dibutuhkan persetujuan untuk memproses pesanan dari pelanggan. Past-condition Pesanan pelanggan diterima atau ditolak. Tabel 4.11 Use case specification untuk “Cek Limit Kredit”
Use case name Actor Description Normal course
Cek saldo piutang. Karyawan Divisi Kredit. Menggambarkan prroses pemeriksaan saldo piutang pelanggan. 1. Use case dimulai pada saat karyawan divisi kredit memilih form cek saldo piutang dari menu; 2. Sistem menampilkan form cek saldo piutang; 3. Karyawan divisi kredit memilih kode pelanggan yang ditampilkan dalam combo box; 4. Sistem menampilkan nama pelanggan, No. FP, tanggal jatuh tempo, saldo piutang dan status piutang. Object Pelanggan, Piutang. Function Read. Alternate course Pre-condition Past-condition Karyawan divisi kredit rekapitulasi piutang pelanggan. Tabel 4.12 Use case specification untuk “Cek Saldo Piutang”
122 Use case name Actor Description Normal course
Buat permohonan kredit. Karyawan Divisi Kredit. Menggambarkan proses pembuatan surat permohonan kredit. 1. Use case dimulai pada saat karyawan divisi kredit memilih form cetak surat permohonan kredit dari menu; 2. Sistem menampilkian form cetak surat permohonan kredit; 3. Karyawan divisi kredit memilih no. SO yang ditampilkan dalam combo box; 4. Karyawan divisi kredit memilih tombol cetak; 5. Sistem akan mencetak surat permohonan kredit. Object SO, Pelanggan, Produk. Function Cetak surat permohonan kredit. Alternate course Pre-condition Terdapat pelanggan baru yang ingin melakukan pemesanan barang. Past-condition Surat permohonan kredit telah dicetak dan siap diberikan kepada direktur. Tabel 4.13 Use case specification untuk “Buat Permohonan Kredit” Use case name Actor Description Normal course
Input kebijakan kredit. Karyawan Divisi Kredit. Menggambarkan proses peng-input-an limit kredit pelanggan. 1. Use case dimulai pada saat karyawan divisi kredit memilih form input kebijakan kredit dari menu; 2. Sistem menampilkan form input kebijakan kredit ; 3. Karyawan divisi kredit memilih kode pelanggan yang ditampilkan dalam combo box; 4. Sistem menampilkan nama pelanggan; 5. Karyawan divisi kredit memilih tombol ubah; 6. Karyawan divisi kredit memasukkan limit kredit yang diperkenankan dan diskon yang disetujui Direktur; 7. Karyawan divisi kredit memilih tombol simpan; 8. Sistem akan mengubah record pelanggan dalam database. Object Pelanggan. Function Update. Alternate course Pre-condition Past-condition Limit kredit dan diskon yang dapat diberikan ke pelanggan baru telah disetujui direktur. Tabel 4.14 Use case specification untuk “Input Kebijakan Kredit”
123 Catat tolakan pesanan. Karyawan Divisi Penjualan. Menggambarkan proses pembuatan surat tolakan pesanan. 1. Use case dimulai pada saat karyawan divisi penjualan memilih form cetak surat tolakan pesanan dari menu; 2. Sistem menampilkan form cetak surat tolakan pesanan; 4. Sistem menampilkan No. STP pre-numberred; 5. Karyawan divisi penjualan memilih No. SO yang ditampilkan pada combo box; 6. Karyawan divisi penjualan memasukkan alasan mengapa pesanan ditolak; 7. Karyawan divisi penjualan memilih tombol simpan; 8. Sistem akan menambahkan record tolakan pesanan ke database; 9. Karyawan divisi penjualan memilih tombol cetak; 10. Sistem akan mencetak surat tolakan pesanan. SO, Pelanggan , Tolakan Pesanan. Object Add, Update, Cetak surat tolakan pesanan. Function Alternate course Terdapat pelanggan yang memesan produk namun permohonan Pre-condition kreditnya ditolak atau sisa limit kredit pelanggan tidak mencukupi. Surat tolakan pesanan telah tercatat dan status Sales Order Past-condition menjadi “cancelled”. Tabel 4.15 Use case specification untuk “Catat Tolakan Pesanan”
Use case name Actor Description Normal course
124 Catat permintaan barang. Karyawan Divisi Penjualan. Menggambarkan proses pembuatan surat permintaan barang. 1. Use case dimulai saat karyawan divisi penjualan memilih form cetak surat permintaan barang dari menu; 2. Sistem menampilkan form cetak surat permintaan barang; 3. Sistem menampilkan No. SPB pre-numberred; 5. Karyawan divisi penjualan memilih No. SO yang ditampilkan pada combo box; 6. Karyawan divisi penjualan memilih tombol simpan; 7. Sistem akan menambahkan record permintaan barang ke database; 8. Karyawan divisi penjualan memilih tombol cetak; 9. Sistem mencetak surat permintaan barang. SO, Pelanggan, Produk, SPB. Object Add, Update, Cetak surat permintaan barang. Function Alternate course Status pesanan “Waiting”. Pre-condition Status pesanan “Proceed” Past-condition Tabel 4.16 Use case specification untuk “Catat Permintaan Barang”
Use case name Actor Description Normal course
Cek Persediaan. Karyawan Divisi Gudang. Menggambarkan proses pengecekan ketersediaan persediann.. 1. Use case dimulai pada saat karyawan divisi gudang memilih form cek persediaan dari menu; 2. Sistem menampilkan form cek persediaan; 3. Karyawan divisi gudang memasukkan kode produk yang ingin dicek ketersediaannya; 5. Sistem menampilkan nama barang dan jumlahnya; Produk dan Persediaan;. Object Read. Function Alternate course Terdapat surat permintaan barang yang menandakan pemesanan Pre-condition harus segera diproses. Perintah pembelian telah tercatat dan surat perintah pembelian Past-condition telah tercetak. Tabel 4.17 Use case specification untuk “Cek Persediaan”
Use case name Actor Description Normal course
125 Catat perintah pembelian. Karyawan Divisi Gudang. Menggambarkan proses pembuatan surat perintah pembelian. 1. Use case dimulai pada saat karyawan divisi gudang memilih form cetak surat perintah pembelian dari menu; 2. Sistem menampilkan form transaksi cetak surat perintah pembelian; 3. Sistem akan menampilkan No. SPP pre-numberred dan tanggal SPP; 4. Karyawan divisi gudang memasukkan kode barang yang dibutuhkan; 5. Sistem menampilkan nama barang; 6. Karyawan divisi gudang memasukkan jumlah barang yang ingin dipesan; 7. Sistem menampilkan kode produk, nama barang, dan kuantitas yang dipesan. 7. Karyawan divisi gudang memilih tombol simpan; 8. Sistem akan menambahkan record perintah pembelian pesanan ke database; 9. Karyawan divisi gudang memilih tombol cetak; 10. Sistem mencetak surat perintah pembelian. Produk, Perintah pembelian. Object Add, Update, Cetak surat perintah pembelian. Function Alternate course Terdapat surat permintaan barang yang menandakan pemesanan Pre-condition harus segera diproses. Perintah pembelian telah tercatat dan surat perintah pembelian Past-condition telah tercetak. Tabel 4.18 Use case specification untuk “Catat Perintah Pembelian”
Use case name Actor Description Normal course
126 Use case name Actor Description Normal course
Catat penerimaan barang. Karyawan Divisi Gudang. Menggambarkan proses pembuatan surat penerimaan barang. 1. Use case dimulai pada saat karyawan divisi gudang memilih form peneriman barang dari menu; 2. Sistem menampilkan form penerimaan barang; 3. Sistem menampilkan No. SPB pre-numberred, karyawan yang login, dan tanggal SPB; 4. Karyawan divisi gudang memilih kode produk; 5. Sistem menampilkan nama barang; 6. Karyawan divisi gudang memasukkan kuantias barang yang diterima; 7. Sistem menampilkan kode produk, nama barang dan kuantitas yang diterima; 8. Karyawan divisi gudang memilih tombol simpan; 9. Sistem menambahkan record penerimaan barang ke database; 10. Karyawan divisi gudang memilih tombol cetak; 11. Sistem akan mencetak penerimaan barang. Object Produk, Persediaan, BPB. Function Add, Update, Cetak Bukti Penerimaan Barang. Alternate course Pre-condition Barang yang dipesan telah tiba ke gudang. Past-condition Bukti penerimaan barng telah tercetak. Tabel 4.19 Use case specification untuk “Catat Penerimaan Barang”
127 Catat faktur penjualan. Karyawan Divisi Penjualan. Menggambarkan proses pembuatan faktur penjualan. 1. Karyawan divisi penjualan memilih form faktur penjualan dari menu; 2. Sistem menampilkan form faktur penjualan; 3. Sistem menampilkan No. FP pre-numberred, tanggal FP, karyawan yang login, dan tanggal JT (30hari setelah tanggal FP); 4. Karyawan divisi penjualan memilih No. SO yang ditampilkan dalam combo box; 5. Sistem menampilkan kode pelanggan, nama pelanggan, kode barang, jenis barang dan kuantitas barang; 6. Sistem melakukan perhitungan untuk subtotal, diskon, dan grand total pemesanan tersebut; 7. Karyawan divisi penjualan memilih tombol simpan; 8. Sistem menambahkan record faktur penjualan ke database FP; 9. Karyawan divisi penjualan memilih tombol cetak; 10. Sistem mencetak faktur penjualan. Pelanggan, Produk, Pesanan, FP. Object Add, Update, Cetak faktur penjualan. Function Alternate course Status pesanan “proceed”. Pre-condition Status pesanan “done”. Past-condition Tabel 4.20 Use case specification untuk “Catat Faktur Penjualan”
Use case name Actor Description Normal course
128 Use case name Actor Description Normal course
Catat surat jalan. Karyawan Divisi Gudang. Menggambarkan proses pembuatan surat jalan. 1. Use case dimulai pada saat karyawan divisi gudang memilih form surat jalan dari menu; 2. Sistem menampilkan form surat jalan; 3. Sistem menampilkan No. SJ pre-numberred; 4. Karyawan divisi gudang memilih No. SO yang ditampilkan dalam combo box; 5. Karyawan divisi penjualan memilih tombol simpan; 6. Sistem menambahkan record surat jalan ke database; 7. Karyawan divisi gudang memilih tombol cetak; 8. Sistem akan mencetak surat jalan. Object SO, Pelanggan, Produk, Surat Jalan. Function Add, Update, Cetak surat jalan. Alternate course Pre-condition Past-condition Surat jalan telah tercetak. Tabel 4.21 Use case specification untuk “Catat Surat Jalan” Use case name Actor Description Normal course
Object Function Alternate course Pre-condition Past-condition
Cetak surat tagihan. Karyawan Divisi Akuntansi. Menggambarkan proses pembuatan surat tagihan kepada pelanggan. 1. Use case dimulai pada saat karyawan divisi penagihan memilih form surat tagihan dari menu; 2. Sistem menampilkan form surat tagihan; 3. Sistem menampilkan No. ST prenumberred, dan tanggal 4. Karyawan divisi penagihan memilih No. FP ditampilkan dalam combo box; 5. Sistem menampilkan kode pelanggan, nama pelanggan, tanggal FP, tanggal jatuh tempo, dan nilai tagihan; 5. Karyawan divisi penagihan memilih tombol simpan; 6. Sistem akan menambahkan record tagihan ke database; 7. Karyawan divisi penagihan memilih tombol cetak; 8. Sistem akan mencetak surat tagihan. Tagihan, Piutang, FP, Pelanggan, Produk. Add, Update, Cetak surat tagihan.
Adanya piutang pelanggan yang sudah akan jatuh tempo. Surat tagihan telah tercetak dan siap dikirimkan kepada pelanggan. Tabel 4.22 Use case specification untuk “Surat Tagihan”
129 Use case name Actor Description Normal course
Bukti kas masuk Karyawan Divisi Keuangan Menggambarkan proses pembuatan bukti kas masuk. 1. Use case dimulai pada saat karyawan divisi keuangan memilih form bukti kas masuk dari menu; 2. Sistem menampilkan form bukti kas masuk; 3. Sistem menampilkan No BKM pre-numberred, tanggal, dan karyawan yang login 4. Karyawan divisi keuangan memilih No.FP yang ditampilkan dalam combo box; 5. Sistem menampilkan nilai FP; 6. Karyawan divisi keuangan memasukkan jumlah pembayaran dan cara pembayaran; 7. Karyawan divisi keuangan memilih tombol cetak. 8. Sistem akan menambahkan record ke database dan melakukan pencetakkan bukti kas masuk. Object FP, Produk, Pelanggan. Function Add, Update, Cetak Alternate course Pre-condition Past-condition Piutang dan sisa limit kredit pelanggan terte-update. Tabel 4.23 Use case specification untuk “Bukti Kas Masuk” Use case name Actor Description
Cetak laporan penjualan per periode. Karyawan Divisi Akuntansi. Menggambarkan proses pembuatan laporan penjualan per periode. Normal course 1. Use case dimulai pada saat karyawan divisi akuntansi memilih form laporan penjualan per periode dari menu; 2. Sistem menampilkan form laporan penjualan per periode; 3. Karyawan divisi akuntansi memilih periode laporan yang ingin dicetak; 4. Karyawan divisi akuntansi memilih tombol cetak; 5. Sistem akan melakukan pencetakan. Object FP, Produk, Pelanggan. Function Cetak laporan penjualan per periode. Alternate course Jika periode yang dipilih tidak benar, maka akan keluar pesan "Input Periode Salah". Pre-condition Past-condition Laporan penjualan per periode telah tercetak. Tabel 4.24 Use case specification untuk “Cetak Laporan Penjualan Per Periode”
130 Use case name Actor Description Normal course
Cetak laporan penerimaan kas. Karyawan Divisi Akuntansi. Menggambarkan proses pembuatan laporan penerimaan kas. 1. Use case dimulai pada saat karyawan divisi akuntansi memilih transaksi form penerimaan kas dari menu; 2. Sistem menampilkan form laporan penerimaan kas; 3. Karyawan divisi akuntansi memilih periode laporan yang ingin dicetak; 4. Karyawan divisi akuntansi memilih tombol cetak; 5. Sistem akan melakukan pencetakan Object Kas masuk. Function Cetak laporan penerimaan kas. Alternate course Jika periode yang dipilih tidak benar, maka akan keluar pesan " Input Periode Salah". Pre-condition Past-condition Laporan penerimaan kas telah tercetak. Tabel 4.25 Use case specification untuk “Cetak Laporan Penerimaan Kas” Use case name Actor Description Normal course
Cetak laporan saldo piutang. Karyawan Divisi Akuntansi. Menggambarkan proses pembuatan laporan saldo piutang. 1. Use case dimulai pada saat karyawan divisi akuntansi memilih form laporan saldo piutang dari menu; 2. Sistem menampilkan form laporan saldo piutang; 3. Karyawan divisi akuntansi memilih periode laporan yang ingin dicetak; 4. Karyawan divisi akuntansi memilih tombol cetak; 5. Sistem akan melakukan pencetakan. Object FP, piutang, pelanggan. Function Cetak.laporan saldo piutang. Alternate course Jika periode yang dipilih tidak benar, maka akan keluar pesan "Input Periode Salah". Pre-condition Past-condition Laporan saldo piutang telah tercetak. Tabel 4.26 Use case specification untuk “Cetak Laporan Saldo Piutang”
131 Use case name Actor Description Normal course
Pendataan produk. Karyawan Divisi Akuntansi. Menggambarkan proses pembuatan data produk yang dijual. 1. Use case dimulai pada saat karyawan divisi akuntansi memilih form produk; 2. Sistem menampilkan form produk; 3. Karyawan divisi akuntansi memilih tombol tambah; 4. Sistem menampilkan no produk pre-numberred; 5. Karyawan divisi akuntansi memasukkan nama produk dan harga jual; 6. Karyawan divisi akuntansi memilih tombol simpan; 7. Sistem menambahkan record produk ke dalam database; Object Produk. Function Add. Alternate course Jika data yang dimasukkan tidak lengkap, maka akan muncul pesan “Data Tidak Lengkap”. Pre-condition Past-condition Tabel 4.27 Use case specification untuk “Pendataan Produk”
132 Berikut adalah sequence diagram dari masing-masing use case yang terdapat dalam sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara :
Gambar 4.23 Sequence diagram untuk use case “Pendataan Pelanggan”
133
Gambar 4.24 Sequence diagram untuk use case “Pendataan Produk”
134
Gambar 4.25 Sequence diagram untuk use case “Catat Terima Pesanan”
135
Gambar 4.26 Sequence diagram untuk use case “Cek Limit Kredit”
136
Gambar 4.27 Sequence diagram untuk use case “Input Kebijakan Kredit”
137
Gambar 4.28 Sequence diagram untuk use case “Cek Saldo Piutang”
Gambar 4.29 Sequence diagram untuk use case “Buat Permohonan Kredit”
138
Gambar 4.30 Sequence diagram untuk use case “Catat Tolakan Pesanan”
139
Gambar 4.31 Sequence diagram untuk use case “Catat Permintaan Barang”
140
Gambar 4.32 Sequence diagram untuk use case “Cek Persediaan”
141
Gambar 4.33 Sequence diagram untuk use case “Catat Penerimaan Barang”
142
Gambar 4.34 Suquence diagram untuk use case “Catat Perintah Pembelian”
143
Gambar 4.35 Sequence diagram untuk use case “Catat Faktur Penjualan”
144
Gambar 4.36 Sequence diagram untuk use case “Catat Surat Jalan”
145
Gambar 4.37 Sequence diagram untuk use case “Buat Surat Tagihan”
146
Gambar 4.38 Sequence diagram untuk use case “Buki Kas Masuk”
147
Gambar 4.39 Sequence diagram untuk use case “Cetak Laporan Penjualan Per Periode”
148
Gambar 4.40 Sequence diagram untuk use case “Cetak Laporan Saldo Piutang”
149
Gambar 4.41 Sequence diagram untuk use case “Cetak Laporan Penerimaan Kas”
150 4.1.3.2 Function List Berikut adalah function list dari sistem informasi akuntansi penjualan kredit dan piutang dagan PD. Arena Nusantara : Function
Type
Complexity
Add, Update Pelanggan
Simple
Update, Read
Add, Update Sales Order
Medium
Update, Read
Add, Update Tolakan Pesanan
Medium
Update, Read
Add, Update Permintaa Barang
Medium
Update, Read
Add, Update Perintah Pembelian
Medium
Update, Read
Add, Update Bukti Penerimaan Barang
Medium
Update, Read
Add, Update Faktur Penjualan
Medium
Update, Read
Add, Update, Surat Jalan
Medium
Update, Read
Add, Update Surat Tagihan
Medium
Update, Read
Add, Update Bukti Kas Masuk
Medium
Update, Read
Cetak Sales Order
Medium
Read
Cetak Surat Permohonan Kredit
Medium
Read
Cetak Surat Tolakan Pesanan
Medium
Read
Cetak Surat Permintaan Barang
Medium
Read
Cetak Surat Perintah Pembelian
Medium
Read
Cetak Bukti Penerimaan Barang
Medium
Read
Cetak Faktur Penjualan
Medium
Read
Cetak Surat Jalan
Medium
Read
Cetak Surat Tagihan
Medium
Read
Cetak Bukti Kas Masuk
Medium
Read
Cetak Laporang Penjualan Per Periode
Medium
Read
Cetak Laporan Penerimaan Kas
Medium
Read
Cetak Laporan Saldo Piutang
Medium
Read
Cetak Laporan Analisis Umur Piutang
Complex
Compute, Read
Tabel 4.28 Function list lengkap sistem informasi akuntansi penjualan kredit dan piutang dagang PD.Arena Nusantara
151 4.1.3.3 User Interface Bahasa indonesia adalah bahasa yang digunakan sebagai acuan dari sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara, namun istilah-istilah bahasa inggris juga banyak digunakan dalam rancangan antar muka sistem informasi akunatansi penjualan kredit dan piutang dagang PD. Arena Nusantara. Dialogue style Setiap user interface memiliki windows untuk setiap classclass penting dalam system, dan setiap window mendukung pencatatan transaksi penjualan kredit dan piutang dagang PD. Arena Nusantara. Sistem juga menyediakan fasilitas pencetakan, yang dapat digunakan untuk memberitahukan perkembangan transaksi penjualan kredit dan piutang dagang perusahaan kepada seluruh pihak yang terlibat dalam kegiatan tersebut (misal : pelanggan, karywan, dan lainlain). Untuk lebih jelasnya, daftar windows interface dan hasil pencetakkannya dapat dilihat pada table 4.29 dibawah ini.
152 Windows Login Logout Master Karyawan Pelanggan Produk Transaksi Sales O/rder Surat Tolakan Pesanan Surat Permintaan Barang Faktur Penjualan Cek Limit Kredit Cek Saldo Piutang Input Kebijakan Kredit Permohonan Kredit Surat Perintah Pembelian Penerimaan Barang Surat Jalan Bukti Kas Masuk Surat Tagihan Laporan Laporan Penjualan Laporan Penerimaan Kas Laporan Saldo Piutang
Printout
Sales Order Surat Tolakan Pesanan Surat Permintaan Barang Faktur Penjualan
Surat Permohonan Kredit Surat Perintah Pembelian Bukti Penerimaan Barang Surat Jalan Bukti Kas Masuk Surat Tagihan Laporan Penjualan Per Periode Laporan Penerimaan Kas Laporan Saldo Piutang
Tabel 4.29 Windows interface dan hasil cetakan sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara
153
Overview Gambar 4.42 berikut adalah navigation diagram yang menyediakan window-window user interface dan hubungan antar window-window user interface tersebut. Window didesain serupa dengan bentuk window yang terdapat dalam navigation diagram, dan semua function penting dapat diaktivasi secara langsung oleh windows.
154
Gambar 4.42 Navigation Diagram
155 4.1.3.4 The technical platform Sistem informasi penjualan kredit dan piutang dagang PD. Arena Nusantara dikembangkan untuk PC dengan menggunakan bahasa pemprograman yang berorientasi objek yaitu Visual Basic 6.0.NET dan menggunakan Microsoff Accsess 2000 sebagai database engine yang memiliki kemampuan (Object Relationship database Management System). User interface yang digunakan sesuai dengan standar windows. Sistem akan dioperasikan dengan mengunakan mouse dan keyboard.
4.1.4 Recommendations 4.1.4.1 The System’s Usefulness and Feasibility Sistem yang dibuat dapat membantu dan mempermudah pengguna dalam pencatatan transaksi penjualan kredit dan piutang dagang. Selain itu sistem juga dapat menghasilkan laporan-laporan mengenai transaksi harian penjualan kredit dan piutang dagang yang dilakukan selama periode tertentu dengan tujuan untuk mengontrol transaksi-transakasi tersebut. Dan yang terakhir yaitu sistem daoat membuat perusahaan lebih efisien terutama dalam penggunaan kertas. Hasil pencatatan transaksi akan disimpan ke dalam komputer, sementara untuk back-up data dapat digunakan media compact disc (CD).
156 4.1.4.2 Strategy Sistem
yang
dibuat
sebaiknya
dicoba
untuk
diimplementasikan terlebih dahulu kepada karyawan tingkat junior, selain itu juga diimplementasikan kepada karyawan yang lebih senior. Apabila mereka mampu menggunakan sistem yang dibuat, maka sistem tersebut sesuai dengan kebutuhan pengguna.
4.1.4.3 Development Economy Pengembangan sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara memerlukan waktu kirakira 8 (delapan) bulan dengan menggunakan sumber daya sebagai berikut : a.
2 (dua) orang system analyst;
b.
4 (empat) orang programmer;
c.
1(satu) orang GUI designner;
d.
1 (satu) orang telecommunication specialist; dan
e.
database specialist. Total biaya yang dibutuhkan untuk pengembangan sistem
kira-kira US$ 6.000,-++ (Enam Ribu US Dollar). Harga termasuk hardware dan software serta tidak termasuk PPN 10%.
157 4.2 Design Document 4.2.1 The Task 4.2.1.1 Purpose Sistem
dibuat
agar
dapat
meringankan
pekerjaan
administratif penjualan kredit dan piutang dagang PD. Arena Nusantara dengan mempermudah pencatatan transaksi pesanan dari pelanggan, pemintaan barang, pengiriman, penyiapan penagihan, pencatatan penerimaan piutang, dan mempermudah pengendalian transaksi-transaksi penjualan kredit dan piutang dagang. Sistem tidak digunakan untuk pengambilan keputusan yang berhubungan dengan penjualan kredit dan piutang dagang.
4.2.1.2 Correction to The Analysis Beberapa perbaikan dilakukan terhadap analisis perancangan sistem informasi akuntansi penjualan kredit dan piutang dagang PD.
Arena
Nusantara.
Perbaikan-perbaikan
tersebut
adalah
penyesuaian beberapa model asosiasi dan perincian beberapa atribut.
4.2.1.3 Quality Goal Perancangan kriteria sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara terutama ditekankan pada kriteria eficient dan reliable. Sistem yang efisien baik dalam hal waktu maupun sumber daya diperlukan karena sistem akan digunakan dalam pencatatan transaksi penjualan kredit dan piutang dagang sehari-hari perusahaan. Sistem yang reliable atau dapat
158 diandalkan diperlukan untuk mempertahankan keutuhan data agar sistem dapat menghasilkan laporan yang dapat diandalkan. Penekanan juga diberikan pada kriteria secure agar sistm dapat aman dari serangan yang datang dari pihak luar atau pengguna internal yang tidak memliki otorisasi, kriteria useable agar sistem dapat diterapkan pada saat implementasi, correct dimana sistem yang dirancang
sesuai
dengan
kebutuhan
PD.
Arena
Nusantara,
comprehensible agar sistem dapat dengan mudah dimengerti oleh pengguna dan reuebale yang memungkinkan subsitem dari sistem informasi akuntansi penjualan kredit dan piutang dagang yang dirancang dapat digunakan pada sistem yang lain. Karakteristik
maintainable
dan
testable
mendapatkan
prioritas yang rendah, sementara karakteristik flexible, portable, interoperable merupakan karakteristik yang tidak memiliki relevansi atau hubungan dengan sistem informasi akuntansi penjualan kredit dan piutang dagang yang diusulkan.
159 Criterion
Very Important
Important
Usable
√
Secure
√
Less Important
Irrelevant
Easily Fulfilled
√
Efficient
√
Correct √
Reliable Maintainable
√
Testable
√ √
Flexible Comprehensivable
√
Reusanle
√
Portable
√
Interoperable
√
Tabel 4.30 Kriteria Sistem Informasi Akuntansi Penjualan Kredit dan Piutang Dagang
4.2.2 Technical Platform 4.2.2.1 Equipment Sistem ini didesain dan dikembangkan untuk PC, dimana antara client dan server akan terhubung dengan menggunakan switch 16 port. Untuk lebih jelasnya, spesifikasi perangkat keras yang akan digunakan untuk PC dapat dilihat pada tabel berikut ini :
160 Spesification
Server
Client
Processor
AMD Athlon 64 X2/FX
AMD Athlon 64
Mother Board
GA-K8NXP-SLI 939
GA-K8N Pro-SLI 939
Memory
1024MB, DDR 2-400. VisiPro
512 MB, DDR 2-400
Hard Disk Drive
160 GB, 7200 RPM. Maxtor
80 GB, 7200 RPM. Maxtor
Floppy Disk
1.44 MB 3,5” FDD Panasonic. 1.44
MB
3,5”
FDD
(Optional)
Panasonic. (Optional)
CD-ROM
DVD-RW ASUS Black
CD-RW ASUS Black
Monitor
Maxvision X7 Umax LCD
Maxvision X5 Umax LCD
Keyboard dan Mouse KeyMax 901 Umax
Logitech Std
NIC
100 mbps (Onboard)
100 mbps (Onboard)
Sound Card
Onboard
Onboard
Graphic Card
GV-3D1
N/A
Printer
Epson R210
HP Deskjet 3744
Operating System
Microsoft
Windows
2000 Microsoft
Advanced Server
Window
XP
Profesional 2
Tabel 4.31 Spesifikasi Peralatan untuk Sistem Informasi Akuntansi Penjualan Kredit dan Piutang Dagang PD. Arena Nusantara.
161 4.2.2.2 System Software Desain sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara berdasarkan implementasi sistem pada Visual Basic, menggunakan database Microsoft Accsess dan dapat dikembangkan dengan menggunakan Microsoft SQL Server 2000 Enterprise Edition. Sistem ini memiliki library dengan class-class uintuk mengangani elemen standard user interface.
4.2.2.3 Systems Interface Selain PC, sistem juga membutuhkan printer yang dapat mencatak pad format A4 atau surat. Untuk masing-masing client karyawan akan dilengkapi dengan printer HP Deskjet 3744, sedangkan untuk client kepala divisi yang akan menggunakan sistem akan dilengkapi dengan Epson R210. Sistem operasi juga harus sesuai (compatible) dengan interface printer.
4.2.2.4 Design Language Perancangan dokumen dengan menggunakan notasi UML (Unified Modelling Language) diagram yang berorientasi objek dengan menggunakan Microsoft Visio 2003.
162 4.2.3 Architecture 4.2.3.1 Component Architecture Sistem informasi akuntasni penjualan kredit dan piutang dagang PD. Arena Nusantara menggunakan arsitektur client-server dengan bentuk distributed functionally dimana pada client terdapat komponen user interface dan function, sedangkan pada server terdapat komponen function dan komponen model. Gambar berikut ini menunjukkan arsitektur sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara.
163
Gambar 4.43 Component Diagram
164 4.2.3.2 Process Architecture Deployment diagram dirancang dengan menggunakan centralized pattern dimana pada client terdapat komponen user interface, function sedangkan pada server terdapat komponen model. Semua data yang diinput melalui komponen user interface client akan diproses oleh client itu sendiri melalui komponen function pada client, kemudian server akan menampung segala input dari client untuk dibaca dan diproses melalui komponen function dan model yang ada pada server.
165
Gambar 4.44 Deployment Diagram
166
Gambar 4.45 Arsitektur Jaringan
4.2.3.3 Standard Perancangan window dan pesan kesalahan sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara mengikuti standard window. Untuk lebih jelasnya beberapa contoh pesan kesalahan dan menu standard, dapat dilihat pada gambar berikut ini.:
167
Data Pertama
Data Sebelumnya
Data Selanjutnya
Data Terakhir
Gambar 4.46 Contoh Gambar “Error Message”
4.2.4 Model Component Komponen model menyatakan kebutuhan function dan kebutuhan model. Terdapat satu komponen function dalam perancangan sistem informasi akuntansi penjualan kredit dan piutang dagang PT. Arena Nusantara, yaitu function analisis umur piutang, sedangkan seluruh function yang lainnya akan diimplementasikan dalam operasi dalam komponen model
168 4.2.4.1
Structure Beberapa perubahan yang dilakukan terhadap analisis sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara. Seperti yang terlihat pada Tabel 4.2, beberapa event dinyatakan dengan pemilihan antara alternatif yaitu iterasi “add persediaan”, sedangkan event-event yang lainnya cukup dinyatakan pada kelas-kelas yang telah ada. Berikut adalah gambar revised class diagram :
169
Gambar 4.47 Revised class
170 4.2.5 User Interface Component 4.2.5.1 Structure Setiap window dan hasil cetak akan diimplementasikan menjadi sebuah kelas dengan satu objek. Setiap kelas window dan cetak mewarisi karakteristik umum dari library user interface. Pada saat sistem dijalankan, kelas “control” menghasilkan objek dimana control diberikan. Objek control menangani menu utama dan mendelegasikan control ke objek user interface lainnya.
4.2.6 Recommendation 4.2.6.1 The System Usefullness Perancangan sistem informasi akuntansi penjualan kredit dan piutang dagang harus memenuhi kriteria yang utama dengan catatan sebagai berikut :
171 Criterion Usable
System Usefullness Sistem dapat dengan mudah diadaptasikan pada lingkungan PD. Arena Nusantara.
Secure
Sistem dapat menjamin keamanan data-data yang disimpan dalam server dari akses yang tidak ter-otorisasi baik dari dalam perusahaan (karyawan) ataupun dari luar perusahaan (pesaing).
Efficient
Sistem harus efisien mendukung pencatatan dan pengendalian proses bisnis penjualan kredit dan piutang dagang.
Correct
Sistem dapat digunakan untuk mendukung administrasi proses bisnis penjualan kredit dan piutang dagang PD. Arena Nusantara.
Reliable
Sistem menghasilkan informasi yang dapat diandalkan yang akan diguanakan oleh setiap kepala divisi yang terlibat dalam sistem akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara guna mengawasi proses bisnis dan sumber daya yang terpengaruh oleh adanya proses bisnis tersebut.
Comprehensible Sistem dapat dengan mudah dipahami oleh semua pengguna yang akan berinteraksi dengan sistem. Reusable
Subsistem yang dirancang, dapat dengan mudah digunakan untuk perancangan sistem informasi akuntansi lainnya.
Tabel 4.32 Kriteria Sistem Informasi Akuntansi Penjualan Kredit dan Piutang Dagang PD. Arena Nusantara
172 4.2.6.2 Plan for Initiating User Pelatihan dan instalasi sistem informasi akuntansi penjualan kredit dan piutang kredit PD. Arena Nusantara akan dilakukan oleh 4 (empat) orang programmer secara bergantian pada tahap implementasi dan pengantaran. Seluruh karyawan yang akan menggunakan sistem wajib mengikuti pelatihan yang akan diadakan selama 45 menit per hari selama 10 hari kerja berturut-turut dan wajib memberikan saran dan tanggapan mereka mengenai sistem yang baru tersebut.
4.2.6.3 Implementation Plan Sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara direncanakan akan dikonversi dengan menggunakan metode paralel selama 3 bulan. Hal ini dimaksudkan untuk mengurangi resiko yang mungkin terjadi pada saat sistem yang lama dikonversi ke sistem yang baru seperti perbedaan hasil, sistem tidak dapat berjalan dengan baik.