• Tidak ada hasil yang ditemukan

BAB 4 ANALISIS DAN PERANCANGAN SISTEM INFORMASI AKUNTANSI PD. ARENA NUSANTARA

N/A
N/A
Protected

Academic year: 2021

Membagikan "BAB 4 ANALISIS DAN PERANCANGAN SISTEM INFORMASI AKUNTANSI PD. ARENA NUSANTARA"

Copied!
79
0
0

Teks penuh

(1)

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 (non-computerized).

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

(2)

(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 :

(3)

Functionality Mendukung pencatatan dan pengendalian kegiatan penjualan 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.

(4)

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.

(5)

98 A c c o u n t i n g B a n k $ $ A c c o u n t s R e c e i v a b l e B o a r d o f D i r e c t o r s $ V I S I O C O R P O R A T I O N F i n a n c e I n v e n t o r y P a c k a g i n g $ $$ P u r c h a s i n g S a l e s S h i p p i n g $ $ T r e a s u r e r P e l a n g g a n D P d a n a t a u P O S T P ( P e r m o h o n a n T d k D i s e t u j u i / L i m i t K r e d i t T d k C k p ) F P , S J , d a n B a r a n g F P d a n S J y g T e l a h D i o t o r i s a s i T r a n s f e r P a y m e n t C a s h P a y m e n t S O S O d a n S P K ( P e l a n g g a n B a r u ) S O d a n S P K y g T e l a h D i o t o r i s a s i S O d a n a t a u S P K ( d i t e r i m a d a n t i d a k ) S P B S P B B O M B O M d a n B a r a n g B P B B O M d a n B P B B a r r a n g S J F P d a n S J F P , S J d a n B a r a n g F P d a n S J S J y g T e l a h D i o t o r i s a s i S J y g T e l a h D i o t o r i s a s i F P y g T e l a h D i o t o r i s a s i F P y g J T d a n S T S T S T T T P T T P d a n F P U a n g ( C a s h ) , T T P ( C a s h / T r a n s f e r ) , d a n N o t a ( T r a n s f e r ) B K M B K M

(6)

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.

(7)

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.

(8)

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.

(9)

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.

(10)

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.

(11)

P e l a n g g a n P e r s e d i a a n

P i u t a n g

P e n j u a l a n

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”

(12)

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”.

(13)

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.

(14)

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”

(15)

Gambar 4.11 Statechart kelas “Surat Tolakan Pesanan”

Gambar 4.12 Statechart kelas “Surat Permintaan Barang”

(16)

Gambar 4.14 Statechart kelas “Surat Jalan”

Gambar 4.15 Statechart kelas “Tagihan”

Gambar 4.16 Statechart kelas “Persediaan”

(17)

Gambar 4.17 Statechart kelas “Back Order”

Gambar 4.18 Statechart kelas “Faktur Penjualan”

(18)

Gambar 4.20 Statechart kelas “Bukti Kas Masuk Tunai”

(19)

Gambar 4.21 Statechart kelas “Bukti Kas Masuk Transfer” Class

Event

Pelanggan Persediaan Piutang Sales Order

Surat Tolakan Pesanan Surat Permintaan Barang

Surat Ja

lan

Faktur Penjualan

Bukti Kas Masuk Tunai Bukti Kas Masuk Tran

sfer

Back Order Surat Tagihan

Bukti Penerimaan Barang

Memesan * + + Mencatat + + + * + + Add Item * * * * * * * Membuat + + + + + + Menyelesaikan Instalasi Memverifikasi * Instalasi +

Tabel 4.2 Tabel event sistem informasi penjualan kredit dan piutang dagang PD. Arena Nusantara

(20)

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. Aktor-aktor tersebut antara lain : Karyawan Divisi Penjualan, Karyawan Divisi Kredit, Karyawan Divisi Gudang, Karyawan Divisi Keuangan, Karyawan Divisi Penagihan, dan Karyawan Divisi Akuntansi.

(21)

Actors

Divisi Divisi Divisi Divisi Divisi Use Case

Penjualan Kredit Gudang Keuangan Akuntansi

Catat Terima Pesanan X

Pendataan Pelanggan X

Catat Tolakan Pesanan X

Catat Permintaan Barang X

Catat Faktur Penjualan X

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

(22)

Berikut ini adalah actor description dari sistem informasi akuntansi penjualan dan penerimaan kas PD. Arena Nusantara.

Karyawan Divisi Penjualan

Tujuan 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

Karyawan Divisi Gudang

Tujuan 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

(23)

Tabel 4.5 Spesifikasi aktor Karyawan Divisi Gudang Karyawan Divisi Kredit

Tujuan 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

Karyawan Divisi Keuangan

Tujuan 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.

(24)

Karyawan Divisi Akuntansi

Tujuan 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

(25)

Gambar 4.22 Use-case Sistem Informasi Akuntansi Penjualan Kredit dan Piutang Dagang PD. Arena Nusantara

(26)

Use case name Pendataan Pelanggan. Actor Karyawan Divisi Penjualan.

Description Menggambarkan proses pendataan pelanggan.

Normal course 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;

Object Pelanggan.

Function Add, Update.

Alternate course Jika pengisian atribut di atas tidak lengkap, maka pada saat penyimpanan data sistem akan menampilkan pesan "Data Tidak Lengkap".

Pre-condition. Terdapat pelanggan yang melakukan pemesanan, tetapi belum terdaftar dalam database perusahaan.

Post-condition Pelanggan telah tercatat dan pembuatan pesanan penjualan dapat diproses.

(27)

Use case name Catat terima pesanan. Actor Karyawan Divisi Penjualan.

Description Menggambarkan proses pembuatan dokumen sales order. Normal course 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.

Object Pelanggan, Produk, SO.

Function Add, Update, Cetak Sales Order

Alternate course Jika pengisian atribut di atas tidak lengkap, maka pada saat penyimpanan data sistem akan menampilkan pesan "Data Tidak Lengkap".

Pre-condition Terdapat pelanggan yang memesan produk, pelanggan telah menyetujui harga barang dan batasan kredit pelanggan tidak terlewati.

Past-condition Status Sales Order menjadi “Waiting”

(28)

Use case name Cek limit kredit.

Actor Karyawan Divisi Kredit

Description Menggambarkan proses pemeriksaan limit kredit pelanggan. Normal course 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 Cek saldo piutang. Actor Karyawan Divisi Kredit.

Description Menggambarkan prroses pemeriksaan saldo piutang pelanggan. Normal course 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”

(29)

Use case name Buat permohonan kredit. Actor Karyawan Divisi Kredit.

Description Menggambarkan proses pembuatan surat permohonan kredit. Normal course 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 Input kebijakan kredit. Actor Karyawan Divisi Kredit.

Description Menggambarkan proses peng-input-an limit kredit pelanggan. Normal course 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.

(30)

Use case name Catat tolakan pesanan. Actor Karyawan Divisi Penjualan.

Description Menggambarkan proses pembuatan surat tolakan pesanan. Normal course 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. Object SO, Pelanggan , Tolakan Pesanan.

Function Add, Update, Cetak surat tolakan pesanan. Alternate course -

Pre-condition Terdapat pelanggan yang memesan produk namun permohonan kreditnya ditolak atau sisa limit kredit pelanggan tidak mencukupi.

Past-condition Surat tolakan pesanan telah tercatat dan status Sales Order menjadi “cancelled”.

(31)

Use case name Catat permintaan barang. Actor Karyawan Divisi Penjualan.

Description Menggambarkan proses pembuatan surat permintaan barang. Normal course 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.

Object SO, Pelanggan, Produk, SPB.

Function Add, Update, Cetak surat permintaan barang. Alternate course -

Pre-condition Status pesanan “Waiting”. Past-condition Status pesanan “Proceed”

Tabel 4.16 Use case specification untuk “Catat Permintaan Barang”

Use case name Cek Persediaan.

Actor Karyawan Divisi Gudang.

Description Menggambarkan proses pengecekan ketersediaan persediann.. Normal course 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; Object Produk dan Persediaan;.

Function Read.

Alternate course -

Pre-condition Terdapat surat permintaan barang yang menandakan pemesanan harus segera diproses.

Past-condition Perintah pembelian telah tercatat dan surat perintah pembelian telah tercetak.

(32)

Use case name Catat perintah pembelian. Actor Karyawan Divisi Gudang.

Description Menggambarkan proses pembuatan surat perintah pembelian. Normal course 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. Object Produk, Perintah pembelian.

Function Add, Update, Cetak surat perintah pembelian. Alternate course -

Pre-condition Terdapat surat permintaan barang yang menandakan pemesanan harus segera diproses.

Past-condition Perintah pembelian telah tercatat dan surat perintah pembelian telah tercetak.

(33)

Use case name Catat penerimaan barang. Actor Karyawan Divisi Gudang.

Description Menggambarkan proses pembuatan surat penerimaan barang. Normal course 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.

(34)

Use case name Catat faktur penjualan. Actor Karyawan Divisi Penjualan.

Description Menggambarkan proses pembuatan faktur penjualan.

Normal course 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.

Object Pelanggan, Produk, Pesanan, FP. Function Add, Update, Cetak faktur penjualan. Alternate course -

Pre-condition Status pesanan “proceed”. Past-condition Status pesanan “done”.

(35)

Use case name Catat surat jalan.

Actor Karyawan Divisi Gudang.

Description Menggambarkan proses pembuatan surat jalan.

Normal course 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 Cetak surat tagihan.

Actor Karyawan Divisi Akuntansi.

Description Menggambarkan proses pembuatan surat tagihan kepada pelanggan.

Normal course 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.

Object Tagihan, Piutang, FP, Pelanggan, Produk. Function Add, Update, Cetak surat tagihan.

Alternate course

Pre-condition Adanya piutang pelanggan yang sudah akan jatuh tempo. Past-condition Surat tagihan telah tercetak dan siap dikirimkan kepada

pelanggan.

(36)

Use case name Bukti kas masuk

Actor Karyawan Divisi Keuangan

Description Menggambarkan proses pembuatan bukti kas masuk.

Normal course 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 Cetak laporan penjualan per periode. Actor Karyawan Divisi Akuntansi.

Description 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.

(37)

Use case name Cetak laporan penerimaan kas. Actor Karyawan Divisi Akuntansi.

Description Menggambarkan proses pembuatan laporan penerimaan kas. Normal course 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 Cetak laporan saldo piutang. Actor Karyawan Divisi Akuntansi.

Description Menggambarkan proses pembuatan laporan saldo piutang. Normal course 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.

(38)

Use case name Pendataan produk.

Actor Karyawan Divisi Akuntansi.

Description Menggambarkan proses pembuatan data produk yang dijual. Normal course 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 -

(39)

Berikut adalah sequence diagram dari masing-masing use case yang terdapat dalam sistem informasi akuntansi penjualan kredit dan piutang dagang PD. Arena Nusantara :

(40)
(41)
(42)
(43)
(44)

Gambar 4.28 Sequence diagram untuk use case “Cek Saldo Piutang”

(45)
(46)
(47)
(48)
(49)
(50)
(51)
(52)
(53)
(54)
(55)
(56)
(57)

4.1.3.2 Function List

Berikut adalah function list dari sistem informasi akuntansi penjualan kredit dan piutang dagan PD. Arena Nusantara :

Function Complexity Type

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

(58)

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 class-class 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 lain-lain). Untuk lebih jelasnya, daftar windows interface dan hasil pencetakkannya dapat dilihat pada table 4.29 dibawah ini.

(59)

Windows Printout 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

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

(60)

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.

(61)
(62)

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).

(63)

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 kira-kira 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

(64)

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

(65)

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.

(66)

Criterion Very Important Important Less Important Irrelevant Easily Fulfilled Usable Secure 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 :

(67)

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.

(Optional)

1.44 MB 3,5” FDD 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 Advanced Server

Microsoft Window XP Profesional 2

Tabel 4.31 Spesifikasi Peralatan untuk Sistem Informasi Akuntansi Penjualan Kredit dan Piutang Dagang PD. Arena Nusantara.

(68)

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.

(69)

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.

(70)
(71)

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.

(72)
(73)

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.:

(74)

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

Data Pertama

Data

Sebelumnya Data Selanjutnya

Data Terakhir

(75)

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 :

(76)
(77)

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 :

(78)

Criterion System Usefullness

Usable 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

(79)

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.

Gambar

Gambar 4.8  Kelas Diagram Lengkap Sistem Informasi Akuntansi Penjualan Kredit dan  Piutang Dagang PD.Arena Nusantara
Tabel 4.3 Tabel aktor sistem informasi akuntansi penjualan kredit dan piutang dagang  PD
Gambar 4.22 Use-case Sistem Informasi Akuntansi Penjualan Kredit dan Piutang  Dagang PD
Tabel 4.24  Use case specification untuk “Cetak Laporan Penjualan Per Periode”
+7

Referensi

Dokumen terkait

Dengan menggunakan akuntansi, dibangunlah sistem yang dapat mengolah data transaksi keuangan dari penjualan barang dan jasa serta pembelian.. Pencatatan transaksi

Jatuh tempo kredit Order pembelian Supplier Supplier Faktur pembelian Barang Nota retur Nota retur Surat jalan Persediaan barang Gudang Supplier Penjualan Customer Pemilik 1 Pembelian

Bagian penjualan akan mengirimkan tembusan sales order yang biasa disebut dengan packing slip sebagai dokumen perintah untuk mengirimkan barang yang diterima dari bagian gudang

- Fitur Signal Pesan antar bagian Bagian Penjualan dan Pemasaran Bagian Produksi Bagian Keuangan Bagian Pembelian Bagian Personalia Bagian Gudang Sistem - Kehilangan

Menteri Keuangan dan Akuntansi membuat surat perintah kerja yang ditujukan ke Menteri Pangan untuk memproduksi barang yang diminta dari gudang, mengisi slip

Berdasarkan surat permintaan pembelian yang diberikan oleh bagian gudang, maka bagian gudang membuat Surat Order Pembelian (SOP) sebanyak 3 lembar, SOP lembar 1 dikirim ke

Customer 1.0 Order Penjualan Kasir Arsip PO Arsip Faktur Kartu stock DPSB 2.0 Pembayaran Bagian Akunting Bagian Gudang Arsip BKS Arsip DSR 3.0 Pengiriman Bagian Pengiriman 4.0

Objects Bagian Administrasi, Bagian Keuangan, Bagian Akuntansi, Manajer Keuangan, Pelanggan, Barang, Surat Penawaran Harga, Sales Contract, Delivery Order, Invoice, Kuitansi, Surat