BAB 4 PERANCANGAN SISTEM INFORMASI AKUNTANSI PENJUALAN PADA PT. ELEMATEC INDONESIA

Transkripsi

1 BAB 4 PERANCANGAN SISTEM INFORMASI AKUNTANSI PENJUALAN PADA PT. ELEMATEC INDONESIA 4.1 Business Modeling Prosedur Sistem Penjualan, Piutang dan Penerimaan Kas atas Penagihan Piutang yang Diusulkan pada PT Elematec Indonesia Prosedur Pemesanan dan Pengiriman Bagian Penjualan menerima penawaran harga dari pelanggan atas barang yang dipesan via telepon atau . Bagian Penjualan akan membuat Surat Penawaran harga untuk barang yang akan diorder oleh pelanggan. SHP berfungsi untuk menampung data penjualan yang belum disetujui oleh Bagian Penjualan. Jika SPH sudah disetujui oleh Bagian Penjualan, maka akan membuat SO (Order Penjualan). Jika pelanggan baru, maka bagian penjualan menyimpan data pelanggan berupa Id pelanggan, nama pelanggan, alamat, nomor telepon, , dan no NPWP. Jika pelanggan lama, bagian penjualan melihat arsip pelanggan untuk melihat pesanan sebelumnya telah dibayar lunas atau belum. Ketika penawaran telah disepakati dan disetujui, Bagian penjualan membuat SO (Order Penjualan) 2 rangkap berdasarkan SPH pelanggan kemudian mengirim SO rangkap 1 ke pelanggan menggunakan fax atau dengan tujuan mendapatkan konfirmasi dari pelanggan berdasarkan barang yang dipesan. SO rangkap 2 diberikan ke Bagian finance. Jika Limit kredit pelanggan tidak mencukupi, maka akan diberi peringatan berupa pop up dialog yang memberitahukan Bagian Penjualan bahwa pelanggan tidak bisa membeli barang lebih dari ketentuan limit kredit. Sedangkan untuk pelanggan baru maka pelanggan akan mengisi form limit kredit untuk pelanggan baru berdasarkan analisis 5C. Setelah konfirmasi oleh pelanggan dan menerima SO, Bagian penjualan mengirim SO ke Bagian finance. Bila barang tersedia, maka Bagian penjualan mengirim SO ke Bagian gudang dan kemudian Bagian gudang menyiapkan dan mengirim barang ke pelanggan. Bagian gudang akan membuat DN (Surat Jalan), DN akan dikirimkan ke Bagian Akuntansi. Bagian akuntansi akan mencetak Faktur Penjualan sebanyak 2 rangkap : a. Rangkap pertama akan diberikan kepada Pelanggan 41

2 42 b. Rangkap kedua untuk diarsip oleh Bagian Akuntansi DN dan Faktur Penjualan akan dibawa oleh Bagian gudang bersama dengan pengiriman barang, dan akan diotorisasi oleh Pelanggan kemudian Faktur Penjualan rangkap kedua diberikan ke Bagian Akuntansi. Bagian gudang hanya bertugas mengirimkan barang yang tersedia di stok gudang. Bila barang tidak cukup atau tersedia, Bagian Penjualan mengirim PO dan melakukan penawaran harga kepada supplier. Apabila supplier dan Bagian penjualan telah menyepakati harga barang, Supplier membuat Supplier invoice dan mengirim barang. Setelah barang telah diterima Bagian gudang, bagian gudang mengecek supplier invoice dan mencocokan jumlah barang serta otorisasi supplier invoice. Bagian penjualan akan memberikan data SO Pelanggan berisi sisa barang yang masih belum dikirim ke Bagian Gudang, Bagian gudang akan membuat Surat Jalan (DN) kedua untuk Pelanggan berisi barang yang pending dan mengirim DN ke Bagian akuntansi untuk mencetak Faktur Penjualan ke Pelanggan sebanyak 2 rangkap : a. Rangkap pertama untuk diberikan kepada Pelanggan b. Rangkap kedua untuk diarsip oleh Bagian Finance Sementara itu Bagian Akuntansi akan membuat faktur pajak berdasarkan Faktur Penjualan dari Bagian Finance. Barang akan dikirimkan kepada pelanggan bersama dengan Faktur Penjualan, DN, dan Faktur Pajak kedua oleh Bagian Gudang dan dokumen juga akan diotorisasi oleh pelanggan.

3 43 Prosedur Pemesanan dan Pengiriman Barang akan dimodelkan sebagai berikut : Gambar 4.1 Detailed Activity Diagram Untuk Prosedur Pemesanan

4 Prosedur Penagihan Piutang Ketika piutang telah jatuh tempo, berdasarkan Faktur Penjualan maka Bagian finance terlebih dahulu mengecek kebenaran tagihan Pelanggan setelah itu bagian finance akan membuat Bon tagihan. Jika setelah 30 hari Pelanggan tidak membayar tagihan maka Bagian finance akan memberikan Denda berupa Persentase bunga sebesar atas keterlambatan pembayaran. Bila Pelanggan sudah melakukan pembayaran melalui bank, Bagian Akuntansi menerima konfirmasi pembayaran dari pelanggan kemudian melakukan pengecekan ke bank, jika pembayaran dilakukan melalui transfer, pelanggan harus menyerahkan Bukti Transfer dari Bank dan mencocokan jumlahnya dengan invoice dari Bagian finance. Jika terdapat kecocokan, Bagian Akuntansi mencatat transaksi tersebut ke dalam jurnal penerimaan kas dan piutang serta mencatat dan mengurangi jumlah piutang sesuai dengan jumlah pembayaran dan Bagian Finance membuat Kwitansi untuk pelanggan sebagai tanda bukti pelunasan penjualan kredit.

5 45 Prosedur Penagihan Piutang dimodelkan sebagai berikut : Gambar 4.2 Detailed Activity Diagram untuk Prosedur Penagihan

6 Prosedur Retur Penjualan Pengembalian barang yang rusak diterima dalam masa waktu maksimal 15 hari setelah barang diterima oleh Pelanggan. Barang yang dapat diretur adalah barang yang mengalami kerusakan yang disebabkan oleh pengiriman atau dari gudang. Ketika melakukan retur, Pelanggan akan mengantarkan barang yang ingin diretur serta memberikan Faktur Penjualan ke Bagian penjualan. Barang yang diterima akan dicek kondisinya, jenis barang serta apakah tanggal masih belum melebihi 15 hari setelah barang diterima Pelanggan. Berdasarkan Faktur Penjualan maka Bagian penjualan akan membuat Nota Retur Penjualan sebanyak 4 rangkap. Nota Retur Penjualan didistribusikan kepada: a. Rangkap pertama diserahkan ke Bagian akuntansi b. Rangkap kedua diserahkan ke Pelanggan c. Rangkap ketiga diserahkan ke Bagian Gudang d. Rangkap keempat diarsip oleh Bagian penjualan. Bagian Penjualan akan memesan kembali barang ke supplier berdasarkan jumlah barang di Nota Retur Penjualan, Supplier akan mengirim barang ke bagian gudang dan mencetak supplier invoice. Bagian Gudang akan mengirim barang ke Pelanggan dengan membawa Nota retur penjualan untuk diotorisasi oleh Pelanggan. Setiap akhir bulan, Bagian penjualan akan membuat Laporan penjualan per pelanggan, Laporan penjualan per periode, Laporan barang terlaris dan Laporan Retur Penjualan. Bagian finance akan membuat Laporan piutang per pelanggan dan Laporan piutang per periode. Sedangkan Bagian Akuntansi akan membuat Laporan Penerimaan kas per periode dan jurnal

7 47 Prosedur Retur Penjualan dimodelkan sebagai berikut : Gambar 4.3 Detailed Activity Diagram untuk Prosedur Retur Penjualan

8 Penentuan Limit Kredit a. Pelanggan Baru Penentuan limit kredit untuk setiap Pelanggan baru akan ditentukan berdasarkan kriteria 5C (Character, Capacity, Capital, Collateral, dan Conditions), dengan syarat penjualan tunai sebesar Rp ,00 untuk pelanggan yang ingin mengajukan permohnan kredit dimana syarat ini tidak bersifat baku karena masih dapat disesuaikan dengan perubahan kebijakan perusahaan nantinya. Kriteria dan penilaian yang akan digambarkan pada tabel 4.1. Bagian Kreditur akan mencari informasi untuk melakukan penilaian dengan melakukan wawancara langsung dengan Pelanggan serta melakukan survey tempat usaha Pelanggan. Bagian Kreditur akan memberikan nilai pada masing-masing kriteria berdasarkan pengamatannya. Kemudian total nilai tersebut akan dihitung rataratanya. Hasil yang diperoleh adalah nilai bagi Pelanggan tersebut. Jumlah limit kredit yang berikan kepada Pelanggan berdasarkan nilai rata-rata yang diperoleh. Tabel 4.1 Nilai yang Ditempatkan untuk Setiap Kriteria 5C Kriteria Keterangan Nilai Apakah data yang pelanggan berikan dapat dipercaya kelengkapannya dan kebenarannya? Daftar pertanyaan: 1. Apakah pelanggan pernah menjalankan usaha lain sebelumnya? 2. Apakah pelanggan telah menjalani usaha selama lebih dari 5 tahun? Character 3. Apakah pelanggan tidak pernah memiliki catatan kriminal di kepolisian? 4. Apakah pelanggan selalu melunasi piutangnya pada bank atau lembaga keuangan lainnya tepat waktu? Penilaian: Semua jawaban sesuai kriteria 5

9 49 Capacity Capital 3 jawaban sesuai kriteria 4 2 jawaban sesuai kriteria 3 1 jawaban sesuai kriteria 2 Tidak ada jawaban sesuai criteria 1 Apakah hasil usaha yang akan diperoleh pelanggan mampu untuk melunasi kewajibannya tepat waktu? Daftar pertanyaan: 1. Apakah Penjualan pelanggan dalam bentuk tunai lebih banyak dari kredit? 2. Apakah pelanggan umumnya memiliki order setiap hari? 3. Apakah pelanggan memiliki usaha lain selain industri elektronik? 4. Apakah pelanggan selalu mengontrol dan mengelola usahanya secara disiplin setiap hari? Penilaian: Semua jawaban sesuai kriteria 5 3 jawaban sesuai kriteria 4 2 jawaban sesuai kriteria 3 1 jawaban sesuai kriteria 2 Tidak ada jawaban sesuai criteria 1 Apakah kondisi kekayaan yang dimiliki oleh pelanggan layak dan sesuai dengan jumlah kredit yang disepakati? Daftar pertanyaan: 1. Apakah tempat usaha yang dimiliki pelanggan merupakan milik sendiri 2. Apakah pelanggan memiliki tingkat utang yang melebihi modal? 3. Apakah aset yang dimiliki oleh pelanggan berasal dari akumulasi keuntungan pelanggan ataukah modal sendiri?

10 50 Collateral Condition 4. Apakah pelanggan memiliki lebih dari satu tempat usaha? Penilaian: Semua jawaban sesuai kriteria 3 jawaban sesuai kriteria 2 jawaban sesuai kriteria 1 jawaban sesuai kriteria Tidak ada jawaban sesuai criteria Apakah jaminan yang diberikan oleh pelanggan bisa memenuhi kewajibannya? Daftar pertanyaan: 1. Apakah pelanggan memiliki harta yang bisa dijadikan sebagai jaminan? 2. Apakah jaminan yang diberikan oleh pelanggan merupakan jaminan dengan nilai ekonomis yang tinggi? 3. Apakah harta dari pelanggan memiliki likuiditas yang baik? 4. Apakah pelanggan memiliki harta yang lain yang bisa dijadikan subtitusi? Penilaian: Semua jawaban sesuai kriteria 5 3 jawaban sesuai kriteria 4 2 jawaban sesuai kriteria 3 1 jawaban sesuai kriteria 2 Tidak ada jawaban sesuai kriteria 1 Apakah usaha elektronik pelanggan termasuk yang berkembang diantara kompetitor wilayahnya? Sangat Berkembang 5 Cukup Berkembang 4 Biasa Saja 3 Tidak Berkembang 2 Sangat Tidak Berkembang 1

11 51 Tabel 4.2 Limit kredit awal berdasarkan nilai rata-rata yang diperoleh Rata-rata Score Limit Kredit Awal 0<1 Rp ,00 1<2 Rp ,00 2<3 Rp ,00 3<4 Rp , Rp ,00 b. Pelanggan Lama 1) Untuk Pelanggan lama, kriteria limit kredit ditentukan dari besarnya nominal penjualan Pelanggan selama 1 (satu) tahun terakhir. 2) Berdasarkan nilai yang diperoleh, akan menghasilkan persentase kenaikan limit kredit Pelanggan dari total limit kredit sebelumnya. 3) Pengubahan limit kredit Pelanggan lama akan dilakukan setiap setahun sekali. Untuk kriteria penilaian tidak bersifat baku karena masih dapat disesuaikan dengan kebijakan perusahaan nantinya Tabel 4.3 Penentuan limit kredit untuk pelanggan lama Kriteria (X) Skor Jumlah Nominal Transaksi per bulan(juta) > X X < 100 < 50 Jumlah Keterlambatan 0 <5 5 X < Pembayaran (Per Transaksi) Jumlah Transaksi per bulan >10 5 X 10 2 X < 5 < 2 Saldo Piutang (Juta) <50 50 X < X 150 >150 Lamanya Menjadi Pelanggan (Tahun) >10 5 X 10 1 X < 5 < 1

12 52 Tabel 4.4 Persentase Kenaikan Limit Kredit Berdasarkan Penilaian Pelanggan Lama Total Skor Persentase Kenaikan dari Limit Kredit Sebelumnya (X) <20 0 % 20 X < 40 5 % 40 X < % 60 X < % 80 X % Identifikasi Usecase dan Permodelannya Model yang digunakan untuk mengidentifikasi events yang terjadi pada sebuah proses bisnis pada sistem adalah event table dan juga usecase. Dalam mendeskripsikan kegiatan dapat mempengaruhi sebuah sistem dan memerlukan sebuah usecase. Sebuah guidelines berupa event table di awal yang digunakan untuk menentukan usecase apa yang nantinya akan dihasilkan Event Table Event table digunakan untuk melihat events apa saja yang harus direspon oleh sistem dan juga untuk melihat bagaimana sistem merespon events tersebut. Berikut ini merupakan event table dari rancangan sistem informasi siklus penjualan yang diusulkan Adalah sebagai berikut : Tabel 4.5 Event Table Sistem yang direkomendasikan Event Trigger Source Usecase Response Destination Melakukan Menawaran Bagian Membuat Surat Pelanggan Penawaran Harga harga yang akan dipesan Penjualan Surat Penawaran Harga Penawaran harga Mengetahui Identitas Pelanggan Melakukan Inquiry Database Mengecek Data Pelanggan Data Pelanggan Bagian Penjualan

13 53 Mendaftar Mendaftar Pelanggan Melakukan Data Bagian Menjadi Pelanggan Pendaftaran Pelanggan Penjualan Pelanggan Baru perusahaan Melakukan SPH telah Bagian Membuat Order Bagian Order Barang diterima Penjualan Order Penjualan Gudang Penjualan Barang ingin Adanya barang Bagian Membuat Surat Jalan Pelanggan dikirim yang tersedia Gudang Surat Jalan Membuat Telah dibuatnya Bagian Membuat Faktur Pelanggan Faktur untuk Surat Jalan Penjualan Faktur Penjualan pelanggan Penjualan Menghitung Telah dibuatnya Bagian Membuat Faktur Pajak Pelanggan Pajak Faktur Akuntansi Faktur berdasarkan Penjualan Pajak faktur Muncul Pop up Pelanggan Database Melakukan Konfirmasi Pelanggan Tempo belum Konfirmasi pembayaran melakukan pembayaran Pelanggan Menerima Bukti Pelanggan Membuat Kwitansi Pelanggan Membayar Transfer apabila Kwitansi Tagihan pelanggan telah membayar Melakukan Mengakui Bagian Melakukan General Bagian Setoran Masuk piutang yang Finance Setoran Lednger Akuntansi telah dibayar Masuk Pelanggan Menerima Pelanggan Membuat Nota Retur Pelanggan ingin Barang yang Nota Retur Penjualan mengembalikan rusak atau cacat Penjualan barang Melaporkan Melaporkan Bagian Membuat Laporan - hasil penjualan hasil penjualan Akuntansi Laporan Penjualan Penjualan

14 54 Melaporkan Melaporkan Bagian Membuat Laporan - barang retur banyak barang Akuntansi Laporan Retur yang di retur Retur Penjualan Penjualan Melaporkan Melaporkan Bagian Membuat Laporan - Tanggal Jatuh umur piutang Akuntansi Laporan Piutang Tempo Piutang serta banyak Piutang piutang Melaporkan Melaporkan Bagian Membuat Jurnal Umum - dalam bentuk Akhir Bulan Akuntansi Jurnal jurnal

15 Requirement Discipline Usecase Berikut ini merupakan usecase dari rancangan sistem informasi yang diusulkan berdasarkan event table yang sudah dibuat sebelumnya. Usecase ini menjelaskan urutan aktivitas apa saja yang dapat dilakukan oleh sistem disertai dengan fungsi pengguna yang mempunyai otorisasi terhadap aktivitas tersebut. Gambar 4.4 Usecase Sistem Informasi Akuntansi Penjualan PT Elematec Indonesia

16 Usecase description Berikut ini merupakan usecase description dari usecase yang telah dibuat. Usecase desription sendiri digunakan untuk menjelaskan lebih detail mengenai proses dari sebuah usecase. Tabel 4.6 Usecase Description Melakukan Pendaftaran Usecase Name : Melakukan Pendaftaran Scenario : Menambah daftar Pelanggan Triggering event : Pelanggan ingin melakukan pemesanan barang Brief description : Ketika Pelanggan ingin melakukan pemesanan barang maka harus melakukan pendaftaran Actor : Bagian Penjualan Related usecase : Stakeholder : Bagian Penjualan Preconditions : Pelanggan Baru ada Form Pendaftaran Tersedia Pastconditions : Pelanggan telah terdaftar Flow events : Actor System 1. Bagian Penjualan Mengakses 2.1 Menampilkan form Program PT Elematec 2. Membuka menu pendaftaran pendaftaran 4.1 Save Identitas Pelanggan 3. Mengisi form pendaftaran 4. Men-submit form pendaftaran Exception conditions :

17 57 Usecase Name : Tabel 4.7 Usecase Description Membuat Surat Penawaran Harga Membuat Surat Penawaran Harga Scenario : Menerima list barang yang akan dipesan Triggering event : Pelanggan ingin membeli barang di Elematec Brief description : Ketika Pelanggan ingin memesan barang, maka Pelanggan mengirim list barang yang ingin dipesan dan melakukan penawaran harga kepada bagian penjualan Actor : Bagian Penjualan Related usecase : Stakeholder : Bagian Penjualan Preconditions : Pelanggan menyetujui penawaran harga Pastconditions : Membuat surat penawaran harga Flow events : Actor System 1. Membuka Form SPH 1. Menampilkan menu SPH 2. Menginput list barang yang akan 2. New Entry Barang yang dipesan oleh Pelanggan 3. Submit Barang 4. Mencetak SPH dipesan. 3. Save SPH 4. Print SPH Exception conditions :

18 58 Usecase Name : Tabel 4.8 Usecase Description Mengecek Data Pelanggan Mengecek Data Pelanggan Scenario : Mengecek data Pelanggan baru atau lama Triggering event : Pelanggan ingin memesan barang Brief description : Pelanggan menanyakan barang yang ingin dipesan maka bagian penjualan mengecek data Pelanggan Actor : Bagian Penjualan Related usecase : Stakeholder : Preconditions : Pelanggan ingin memesan barang Pastconditions : Update data Pelanggan Flow events : Actor System 1. Bagian Penjualan memasukan 1.1 Mengecek data Pelanggan nama_pelanggan 2.1 Menampilkan data 2. Verifikasi Pelanggan Pelanggan Exception conditions : 1.2 Jika tidak ada maka diberikan form pendaftaran

19 59 Usecase Name : Scenario : Tabel 4.9 Usecase Description Menginput Data Pelanggan Menginput Data Pelanggan Menginput data Pelanggan dari form pendaftaran yang telah diisi Pelanggan Triggering event : Brief description : Pelanggan telah mengisi form pendaftaran Ketika Pelanggan memberikan form pendaftaran maka bagian Penjualan menginput data Pelanggan Actor : Bagian Penjualan Related usecase : Stakeholder : Preconditions : Pastconditions : Pelanggan yang terotorisasi Membuat registrasi Pelanggan Flow events : Actor System 1. Membuka menu Pelanggan 2. Bagian penjualan mengentry data Pelanggan 3. Bagian penjualan Mensubmit 1.1 Menampilkan Menu master Pelanggan 2.1 Membuat Registrasi member 3.1 Save Data Pelanggan yang data Pelanggan yang telah telah dimasukkan dimasukkan Exception conditions : 2.2 Member yang sudah terdaftar tidak perlu lagi membuat registrasi member

20 60 Usecase Name : Tabel 4.10 Usecase Description Membuat Order Penjualan Membuat Order Penjualan Scenario : Bagian Penjualan membuat Order Penjualan Triggering event : Karena bagian penjualan telah menerima PO dari Pelanggan Brief description : Setelah Menerima Purchase order atas pemesanan barang dari Pelanggan maka bagian penjualan membuat Order Penjualan Actor : Bagian Penjualan Related usecase : Stakeholder : Bagian Penjualan Preconditions : Disetujuinya penawaran harga Pelanggan mencukupi limit kredit Pastconditions : Tercetaknya Order Penjualan Flow events : Actor System 1. Bagian Penjualan Membuka 1.1 Menampilkan Tr_Order Tr_Order Penjualan 2. Membuat Order Penjualan Baru 3. Mencetak Order Penjualan Penjualan 2.1 Membuat Order Baru 3.1 Print Order Penjualan Exception conditions :

21 61 Usecase Name : Tabel 4.11 Usecase Description Membuat Surat Jalan Membuat Surat Jalan Scenario : Membuat Surat Jalan untuk mengantarkan barang Triggering event : Bagian Gudang ingin mengantarkan Barang Brief description : Ketika Barang telah tersedia di gudang dan siap untuk diantarkan maka sebelum mengantarkan barang bagian Gudang harus membuat Surat Jalan. Actor : Bagian Gudang Related usecase : Stakeholder : Bagian Gudang Preconditions : Barang Tersedia Pastconditions : Tercetaknya Surat Jalan Flow events : Actor System 1. Membuka menu Surat Jalan 1.1 Menampilkan Menu Surat 2. Memasukkan Nama barang Jalan beserta Jumlah Barang 3. Mencetak Surat Jalan 2.1 Mengentry Nama Barang beserta jumlahnya 3.1 Print Surat Jalan Exception conditions :

22 62 Usecase Name : Scenario : Triggering event : Brief description : Actor : Tabel 4.12 Usecase Description Membuat Faktur Penjualan Membuat Faktur Penjualan PT Elematec mengirim barang kepada Pelanggan PT Elematec Mengakui piutang dan melakukan pengiriman Barang Ketika PT Elematec mengirim barang maka dibuatkan Faktur Penjualan untuk Pelanggan dan bagian akuntansi dalam pengakuan piutang Bagian Penjualan Related usecase : Stakeholder : Preconditions : Pastconditions : Bagian Penjualan Tersedianya surat jalan Tercetak Faktur Penjualan Flow events : Actor System 1. Bagian Gudang telah menerima 2.1 Menampilkan Tr_Faktur barang yang dipesan kepada Penjualan supplier 2. Bagian penjualan otorisasi barang 3. Mengirim Barang Exception conditions :

23 63 Usecase Name : Scenario : Triggering event : Brief description : Tabel 4.13 Usecase Description Membuat Faktur Pajak Membuat Faktur Pajak Bagian Akuntansi membuat pajak atas barang yang akan dijual Terjualnya Barang dagangan Setelah dicocokkan dengan surat jalan dan Faktur Penjualan maka bagian akuntansi membuat faktur pajak untuk barang yang dijual Actor : Bagian Penjualan Related usecase : Stakeholder : Preconditions : Pastconditions : Bagian Penjualan Verifikasi surat jalan dan invoice Tercetaknya Faktur Pajak Flow events : Actor System 1. Membuka menu Faktur Pajak 2. Mengentry Harga barang 3. Menghitung pajak yang dibayar 4. Mencetak Faktur Pajak 1.1 Menampilkan menu faktur pajak 2.1 Memasukkan list barang dan harga barang 3.1 Compute Pajak yang dibayar 4.1 Print Faktur Pajak Exception conditions :

24 64 Usecase Name : Tabel 4.14 Usecase Description Membuat Nota Retur Penjualan Membuat Nota Retur Penjualan Scenario : Triggering event : Brief description : Pelanggan Mengembalikan Barang yang rusak Pelanggan Membawa Surat Jalan serta barang yang ingin diretur Ketika Pelanggan Membawa barang yang rusak maka mengecek dan mengotorisasi FPK dan Surat Jalan Actor : Bagian Penjualan Related usecase : Stakeholder : Preconditions : Pastconditions : Cocoknya data Pelanggan yang ingin menukar barang Bisa atau Tidaknya barang Tercetaknya Nota Retur Penjualan Flow events : Actor System 1. Membuka Menu Nota Retur Penjualan 1.1 Menampilkan Database Nota Retur Penjualan 2. Mengecek/verifikasi barang 2.1 Membuka menu Faktur 3. Membuat Nota Retur Baru Penjualan 4. Mencetak Nota Retur Penjualan 3.1 Membuat Nota Retur Penjualan 4.1 Print Nota Retur penjualan Exception conditions : 2.2 Jika tidak Benar maka retur Barang Ditolak

25 65 Usecase Name : Tabel 4.15 Usecase Description Melakukan Konfirmasi Piutang Melakukan Konfirmasi Piutang Scenario : Triggering event : Brief description : Melakukan Konfirmasi Jatuh tempo piutang terhadap pelanggan Munculnya Message box piutang yang telah jatuh tempo Ketika bagian finance menemukan tagihan Pelanggan yang telah jatuh tempo dan belum melakukan pembayaran Actor : Bagian Finance Related usecase : Stakeholder : Preconditions : Pastconditions : Pembayaran telah jatuh tempo Mengonfirmasi pelanggan Flow events : Actor System 1. Muncul message box 1.1 Menampilkan Menu Faktur Penjualan 3.1 Menghitung Tagihan 4.1 Print bon tagihan Exception conditions :

26 66 Usecase Name : Scenario : Tabel 4.16 Usecase Description Melakukan Setoran Masuk Melakukan Setoran Masuk Mengurangi Piutang Triggering event : Brief description : Menerima Bukti Transfer pembayaran Ketika menerima bukti transfer pembayaran maka Piutang akan berkurang dan diakui sebagai pendapatan. Actor : Bagian Akuntansi Related usecase : Stakeholder : Preconditions : Pastconditions : Menerima Kwitansi Mengakui Piutang sebagai pendapatan Membuat Penjurnalan Flow events : Actor System 1. Membuka menu Setoran Masuk 2. Menjurnal Piutang 1.1 Menampilkan menu Setoran Masuk 2.1 Menghitung jumlah piutang yang diakui menjadi pendapatan Exception conditions :

27 67 Usecase Name : Tabel 4.17 Usecase Description Membuat Kwitansi Membuat Kwitansi Scenario : Membuat bukti Pelanggan telah melakukan pembayaran Triggering event : Pembayaran telah dilakukan Brief description : Ketika Pelanggan telah melakukan pembayaran dan konfirmasi maka bagian akuntansi membuat Kwitansi Actor : Bagian Akuntansi Related usecase : Stakeholder : Bagian Akuntansi Preconditions : Pelanggan telah melakukan pembayaran Pastconditions : Mencetak kwitansi Flow events : Actor System 1. Membuka menu Kwitansi 2. Memasukan jumlah uang yang dibayar 1.1 Menampilkan menu Kwitansi 2.1 Menentry jumlah uang 3.1 Print Kwitansi 3. Mencetak Kwitansi Exception conditions :

28 68 Usecase Name : Tabel 4.18 Usecase Description Membuat Laporan Penjualan Membuat Laporan Penjualan Scenario : Triggering event : Brief description : Membuat Laporan penjualan akhir bulan Bila Bagian Finance ingin pengambilan keputusan Ketika Bagian Finance ingin melihat laporan penjualan pada periode tertentu maka bagian akuntansi membuat laporan Actor : Bagian Akuntansi Related usecase : Stakeholder : Preconditions : Pastconditions : Bagian Finance Pihak management membutuhkan laporan Mencetak laporan Flow events : Actor System 1. Membuka menu laporan 2. Memilih jenis laporan 1.1 Menampilkan menu laporan penjualan 3. Memasukkan Periode laporan 3.1 Input Periode Tanggal 4. Cetak Laporan laporan yang akan dilaporkan 4.1 Print Out laporan penjualan Exception conditions :

29 69 Usecase Name : Tabel 4.19 Usecase Description Membuat Laporan Retur Penjualan Membuat Laporan Retur Penjualan Scenario : Triggering event : Brief description : Membuat Laporan Penerimaan kas per periode Bila Bagian Finance ingin pengambilan keputusan Ketika Bagian Finance ingin melihat laporan penjualan pada periode tertentu maka bagian akuntansi membuat laporan Actor : Bagian Akuntansi Related usecase : Stakeholder : Preconditions : Pastconditions : Bagian Finance Pihak management membutuhkan laporan Mencetak laporan Flow events : System System 1.1 Menampilkan menu laporan penerimaan kas 1.1 Menampilkan menu laporan penerimaan kas 3.1 Input Periode Tanggal laporan 3.1 Input Periode Tanggal yang akan dilaporkan 4.1 Print Out laporan penerimaan kas laporan yang akan dilaporkan 4.1 Print Out laporan penerimaan kas Exception conditions :

30 70 Usecase Name : Tabel 4.20 Usecase Description Membuat Laporan Analisis Putang Membuat Laporan Analisis Piutang Scenario : Membuat Laporan Umur Piutang Pelanggan Triggering event : Bila Bagian Finance ingin pengambilan keputusan Brief description : Ketika Bagian Finance ingin melihat laporan penjualan pada periode tertentu maka bagian akuntansi membuat laporan Actor : Bagian Akuntansi Related usecase : Stakeholder : Bagian Finance Preconditions : Pihak management memerlukan laporan penjualan Pastconditions : Mencetak laporan penjualan Flow events : System System 1.1 Menampilkan menu laporan Analisis umur piutang 1.1 Menampilkan menu laporan analisis umur piutang 3.1 Input Periode Tanggal 3.1 Input Periode Tanggal laporan yang akan dilaporkan 4.1 Print Out laporan penjualan laporan yang akan dilaporkan 4.1 Print Out laporan Analisis Umur piutang Exception conditions :

31 71 Usecase Name : Tabel 4.21 Usecase Description Membuat Jurnal Membuat Jurnal Scenario : Membuat Jurnal pada penjualan barang Triggering event : Bila Ingin Mengecek Jejak Audt Brief description : Ketika Bagian Finance ingin melihat Jurnal pada periode tertentu maka bagian akuntansi membuat Jurnal Actor : Bagian Akuntansi Related usecase : Stakeholder : Bagian Akuntansi Preconditions : Bagian Akuntansi melakukan pencatatan Pastconditions : Membuat penjurnalan Flow events : System System 1.1 Menampilkan menu laporan Analisis umur Jurnal 1.1 Menampilkan menu laporan analisis umur piutang 2.1 Memilih Periode 2.1 Memasukkan Periode tanggal yang ingin dilihat Exception conditions :

32 System Sequence Diagram System Sequence Diagram merupakan model yang dibuat berdasarkan use case yang ada, yang memodelkan interaksi antara user dan sistem, dimana ketika user memberikan input ke dalam sistem, maka sistem akan mengeluarkan output yang sesuai dengan apa yang di-input user. Gambar 4.5 Sequence Login Karyawan Gambar 4.6 Sequence Registrasi Pelanggan

33 73 Gambar 4.7 Sequence Membuat SPH Gambar 4.8 Sequence Membuat Order Penjualan

34 74 Gambar 4.9 Sequence Membuat Surat Jalan Gambar 4.10 Sequence Membuat Faktur Penjualan

35 75 Gambar 4.11 Sequence Membuat Faktur Pajak Gambar 4.12 Sequence Membuat Kwitansi

36 76 Gambar 4.13 Sequence Melakukan Setoran Masuk Gambar 4.14 Sequence Membuat Nota Retur Penjualan

37 77 Gambar 4.15 Sequence Melihat Laporan Penjualan Gambar 4.16 Sequence Melihat Laporan umur Piutang

38 78 Gambar 4.17 Sequence Melihat Laporan Retur Penjualan Gambar 4.18 Sequence Melihat Jurnal

39 Gambar 4.19 Sequence Mengecek Data Pelanggan 79

40 Domain Class Diagram Response yang mempunyai output dari aktivitas pada event table dan memenuhi 3 kriteria penentuan class perlu dimodelkan dengan menggunakan domain class diagram. Berikut ini domain class diagram yang merupakan kumpulan class yang terbentuk pada sistem informasi akuntansi : Gambar 4.20 Domain Class Diagram

41 Statechart Diagram Pola prilaku dari masing-masing class dengan atributnya dapat dimodelkan dengan menggunakan Statechart Diagram. Statechart Diagram dari masing-masing class yang terbentuk pada sistem informasi akuntansi penjualan adalah sebagai berikut:

42 82 Gambar 4.21 Statechart Classes 4.3 Design Discipline Bila requirement discipline fokus kepada apa yang sistem harus lakukan, design discipline berorientasi pada bagaimana sistem akan dibuat. Design discipline melanjutkan modeling proses dari requirement dengan cara membuat model baru, memperluas atau mengkaji ulang model dari proses bisnis dari requirement discipline First Cut Class Diagram Pengembangan dengan memperluas domain model class diagram digambarkan dengan menggunakan first-cut class diagram. Permodelan first-cut class diagram pada sistem informasi akuntansi siklus penjualan dimodelkan sebagai berikut :

43 Gambar 4.22 First Cut Class Diagram 83

44 Completed 3- Layer Design Sequence Completed Three-Layer Design Sequence Diagram digunakan untuk menjelaskan secara lebih detail mengenai interaksi antara user dan sistem dengan mengikutsertakan data access layer pada sequence diagram. Hal ini bertujuan untuk menggambarkan hubungan antara user dengan sistem dan sistem dengan sistem. Gambar 4.23 Login Karyawan

45 Gambar 4.24 Membuat Surat Penawaran Harga 85

46 86 Gambar 4.25 Membuat Order Penjualan

47 Gambar 4.26 Membuat Surat Jalan 87

48 88 Gambar 4.27 Membuat Faktur Penjualan

49 Gambar 4.28 Membuat Faktur Pajak 89

50 90 Gambar 4.29 Membuat Kwitansi

51 Gambar 4.30 Melakukan Setoran Masuk 91

52 92 Gambar 4.31 Membuat Nota Retur Penjualan

53 Gambar 4.32 Melihat Order Penjualan 93

54 94 Gambar 4.33 Melihat Surat Jalan

55 Gambar 4.34 Melihat Faktur Penjualan 95

56 96 Gambar 4.35 Melihat Data Kwitansi

57 Gambar 4.36 Melihat Retur Penjualan 97

58 98 ambar 4.37 Melihat SPH G

59 Gambar 4.38 Membuat Laporan Penjualan 99

60 100 Gambar 4.39 Membuat Laporan Piutang

61 101 Gambar 4.40 Membuat Laporan Retur Updated Class Diagram Dari design class diagram dapat dikembangkan dengan menggunakan beberapa layer, dan beberapa class harus lebih dispesifikasikan dari three-layer sequence diagram yang dinamakan updated design class diagram. Permodelan updated design class diagram sistem informasi akuntansi siklus pendapatan pada sebagai berikut :

62 102 Gambar 4.41 Updated Class Diagram

63 Package Diagram Package diagram adalah final model yang digunakan untuk mendokumentasikan subsystem yang menunjukkan class mana yang bekerja sama sebagai suatu subsystem, dibuat berdasarkan updated class diagram Gambar 4.42 Package Diagram

64 UI Story Board Gambar 4.43 UI Story Board form login Gambar 4.44 UI Story Board Form Master

65 Gambar 4.45 UI Story Board Form transaksi 105

66 106 Gambar 4.46 UI Story Board form Limit Kredit

67 Gambar 4.47 UI Story Board Lihat Transaksi 107

68 Design The User-Interface 1. Rancangan Layar Menu Utama File Gambar 4.48 Rancangan Layar Menu Utama File Main form berisi menu bar yang terdiri dari File, Master, Transaksi, Laporan, dan Lihat Transaksi. Menu File terdiri dari Login, Logout dan Exit. 2. Rancangan Layar Menu Utama Master Gambar 4.49 Rancangan Layar Menu Utama Master Menu Master terdiri dari Barang, Karyawan, dan Pelanggan.

69 Rancangan Layar Menu Utama Transaksi Gambar 4.50 Rancangan Layar Menu Utama Transaksi Menu Transaksi terdiri dari Surat Penawaran Harga, Order Penjualan, Faktur Penjualan, Surat Jalan, Faktur Pajak, Retur Penjualan, Kwitansi, Setoran Masuk. 4. Rancangan Layar Menu Utama Laporan Gambar 4.51 Rancangan Layar Menu Utama Laporan Menu Lihat Transaksi terdiri dari Lihat SPH, Lihat Order, Lihat Surat Jalan, Lihat Faktur Penjualan, Lihat Kwitansi, Lihat Retur Penjualan. Sedangkan Menu Laporan digunakan untuk melihat Laporan Penjualan,Piutang dan Retur Penjualan

70 Rancangan Layar Form Login Gambar 4.52 Rancangan Layar Form Login Form Login terdiri dari Username dan Password. Username dan Password yang dimasukkan harus sesuai dengan data yang ada di database Karyawan. Masing-masing karyawan hanya bisa mengakses form-form tertentu sesuai Jabatan. 6. Rancangan Layar Form Barang Gambar 4.53 Rancangan Layar Form Barang

71 111 Gambar 4.53 menunjukkan form barang. Form Barang terdiri dari ID Barang, Nama Barang, Jumlah Barang, Harga Satuan. Pada form ini, user dapat mencari data Barang melalui Cari Berdasarkan dengan pilihan ID Barang, Nama Barang, Jumlah Barang, Harga Satuan. Kemudian user bisa mengetikkan pencariannya pada textbox yang disediakan dan mengklik tombol Cari, maka pencarian data Barang akan ditampilkan di grid view 7. Rancangan Layar Form Karyawan Gambar 4.54 Rancangan Layar Form Karyawan Gambar 4.54 Menunjukan form karyawan. Form ini berisi data-data karyawan yang terdiri dari Id Karyawan, Nama Karyawan, Jabatan (terdiri atas Penjualan, Accounting, Gudang, Finance), Gaji, Username, Password, Alamat, No. Telepon.

72 112 Disini user juga dapat melakukan pencarian dengan memilih pilihan pada Cari Berdasarkan yang berisi Id Karyawan, Nama Karyawan, Jabatan (terdiri atas Penjualan, Accounting, Gudang, Finance), Gaji, Username, Password, Alamat, No. Telepon. Setelah itu, user bisa mengetikkan pencariannya pada textbox yang disediakan dan mengklik tombol Cari, maka pencarian data Karyawan akan ditampilkan di grid view. Tombol Tambah berfungsi untuk menambah data Kayawan ke dalam grid view. Tombol Edit berfungsi untuk mengubah data Karyawan.Tombol Simpan berfungsi untuk menyimpan data Karyawan ke dalam database Karyawan. Dan tombol Batal digunakan apabila batal menyimpan data. 8. Rancangan Layar Form Pelanggan Gambar 4.55 Rancangan Layar Form Pelanggan

73 113 Gambar 4.55 menunjukkan Form Pelanggan yang berisi data-data pelanggan dimana terdiri dari Id Pelanggan, Nama Pelanggan, Alamat Perusahaan, No. Telp Perusahaan, No. NPWP, serta Limit Kredit. Pada form Pelanggan ini user juga dapat melakukan pencarian dengan memilih pilihan yang ada pada Cari Berdasarkan yang berisi Id Pelanggan, Nama Pelanggan, Alamat Perusahaan, No. Telp Perusahaan, No. NPWP, serta Limit Kredit. Setelah itu, user bisa mengetikkan pencariannya pada textbox yang disediakan dan mengklik tombol Cari, maka pencarian data Pelanggan akan ditampilkan di grid view. a. Tombol Tambah berfungsi untuk menambah data Pelanggan ke dalam grid view. b. Tombol Edit berfungsi untuk mengubah data Pelanggan. c. Tombol Simpan berfungsi untuk menyimpan data Pelanggan ke dalam database Pelanggan. Sedangkan tombol Batal digunakan apabila batal menyimpan data. 9. Rancangan Layar Form Surat Penawaran Harga Gambar 4.56 Rancangan Layar Form Surat Penawaran Harga

74 114 Gambar 4.56 menunjukkan Form Surat Penawaran Harga yang berisi data-data keterangan untuk menawar harga barang dimana terdiri dari Kode SPH, Tanggal SPH, Id karyawan, nama karyawan, Grupbox data barang (Id barang, Nama barang,harga satuan dan jumlah barang), Grupbox data pelanggan (Id pelanggan, Nama pelanggan, No tlp dan alamat). Pada form SPH ini terdapat tombol Tambah yang berfungsi bagi user untuk melihat data barang yang telah diinput. Pada datagridview berisi Id Barang, Nama Barang, Harga satuan, jumlah barang, total harga dan Grand total. Tombol Simpan berfungsi untuk menyimpan data ke database Tr_SPH, tombol Ubah berfungsi untuk mengubah penginputan data yang salah dan Tombol Batal untuk membatalkan transaksi. 10. Rancangan Layar Form Order Penjualan Gambar 4.57 Rancangan Layar Form Order Penjualan Gambar 4.57 menunjukkan Form Surat Penawaran Harga yang berisi data-data keterangan untuk menawar harga barang dimana terdiri dari Kode SPH, Tanggal SPH, Id karyawan, nama karyawan, Grupbox data barang (Id barang, Nama barang,harga

75 115 satuan dan jumlah barang), Grupbox data pelanggan (Id pelanggan, Nama pelanggan, No tlp dan alamat). Tombol Simpan berfungsi untuk menyimpan data ke database Tr_Order Penjualan, tombol Ubah berfungsi untuk mengubah penginputan data yang salah dan Tombol Batal untuk membatalkan transaksi. Jika Pada Saat Order Penjualan tidak mencukupi akan muncul messagebox seperti pada gambar 4.58 Gambar 4.58 MessageBox Warning Limit Kredit tidak mencukupi

76 Rancangan Layar Form Surat Jalan Gambar 4.59 Rancangan Layar Form Surat Jalan Gambar 4.59 menunjukkan Form Surat Jalan yang berisi data-data keterangan untuk menawar harga barang dimana terdiri dari Kode Surat Jalan, Tanggal Surat Jalan, Id karyawan, nama karyawan, Grupbox data pelanggan (Id pelanggan, Nama pelanggan, No tlp dan alamat), Griedview data Barang (Id barang, Nama barang, Harga satuan, Jumlah Barang, dan Total). Tombol Simpan berfungsi untuk menyimpan data ke database Tr_Surat jalan, tombol Ubah berfungsi untuk mengubah penginputan data yang salah dan Tombol Batal untuk membatalkan transaksi.

77 Rancangan Layar Form Faktur Penjualan Gambar 4.60 Rancangan Layar Form Faktur Penjualan Gambar 4.60 menunjukkan Rancangan Layar Form invoice yang berisi Tanggal Invoice, Tanggal Jatuh Tempo, Kode Invoice, Status, grid view Barang yang Dibeli, grid view Barang yang Diretur, Sub Total, Jumlah PPN, serta Grand Total. Status berisi Open dan Closed. Open apabila pelanggan belum melunasi pembayaran untuk Invoice yang bersangkutan. Sedangkan Status akan berubah Closed apabila pelanggan telah melunasi pembayaran untuk Invoice yang bersangkutan. Data pada Grid view untuk Barang yang Diretur akan muncul apabila telah melakukan transaksi pada Nota Retur Penjualan. Tombol Simpan berfungsi untuk menyimpan transaksi Invoice ke dalam database. Sedangkan tombol Batal digunakan apabila batal melakukan transaksi. Tombol Cetak digunakan untuk mencetak Form Invoice. Tombol Tambah berfungsi untuk membuat form baru untuk Invoice. Dan tombol Ubah berfungsi untuk mengubah data transaksi Invoice.

78 Rancangan Layar Form Faktur Pajak Gambar 4.61 Rancangan Layar Form Faktur Pajak Gambar 4.61 menunjukkan Form Faktur Pajak yang berisi data-data keterangan Perusahaan kena pajak dimana terdiri dari tanggal, Kode Faktur pajak, kode faktur penjualan, tanggal faktur penjualan, Grupbox Pengusaha Kena pajak (Nama Perusahaan, alamat,npwp), Grupbox pembeli BKP/ Penerima JKP (Nama Perusahaan, alamat, NPWP). Datagridview untuk melihat transaksi barang yang dikenakan pajak (id barang, nama barang, jumlah barang, harga satuan, total). Tombol Simpan berfungsi untuk menyimpan data ke database Tr_Faktur Pajak, tombol Ubah berfungsi untuk mengubah penginputan data yang salah dan Tombol Batal untuk membatalkan transaksi.

79 Rancangan Layar Form Nota Retur Penjualan Gambar 4.62 Rancangan Layar Form Nota Retur Penjualan Gambar 4.62 menunjukkan Form Nota Retur Penjualan yang berisi data-data keterangan retur penjualan terdiri dari tanggal retur, Kode retur penjualan, kode faktur penjualan, Datagridview barang yang dibeli (id barang, nama barang, jumlah barang, harga satuan, total, total pajak). Datagridview barang diretur berisi (id barang, nama barang, harga, jumlah retur, combobox Keterangan = barang cacat, barang salah kirim, barang lama pengiriman), pajak, keterangan pada form berisi mengenai informasi cacatan mengenai barang yang diretur. Tombol Simpan berfungsi untuk menyimpan data ke database Tr_Nota Retur Penjualan, tombol Ubah berfungsi untuk mengubah penginputan data yang salah dan Tombol Batal untuk membatalkan transaksi.

80 Rancangan Layar Form Kwitansi Pembayaran Gambar 4.63 Rancangan Layar Form Kwitansi Gambar 4.63 merupakan Rancangan Layar Form Nota Pembayaran yang berisi Tanggal Pembayaran, Id Karyawan, Nama Karyawan, Kode Kwitansi, Id Pelanggan, grid view data Invoice, grid view Jenis Pembayaran, dan Jumlah Bayar. Kode Pelanggan bisa dilihat dari Form Tabel Lihat Pelanggan seperti yang ditunjukkan Gambar Ketika memilih data Pelanggan akan muncul data Nama Pelanggan, Alamat Pelanggan, Nama Bank, dan Nominal. Selain itu juga akan muncul grid view yang berisi Kode Invoice, Tanggal Invoice, Tgl Jatuh Tempo, dan Jumlah, dimana bisa dipilih dengan mencentang pada kolom Pilih. Dan juga ada grid view yang berisi Jenis Pembayaran, Nama Bank, Tanggal Penerimaan, Nominal. Jenis Pembayaran terdiri dari Giro, Transfer, dan Tunai. Tombol Simpan berfungsi untuk menyimpan transaksi Nota Pembayaran ke dalam database. Sedangkan tombol Batal digunakan apabila batal melakukan transaksi. Tombol Ubah berfungsi untuk mengubah data transaksi Nota Pembayaran.. Tombol Tambah berfungsi untuk membuat form baru untuk Nota Pembayaran. Dan tombol Cetak digunakan untuk mencetak Form Nota Pembayaran.

81 Rancangan Layar Setoran Masuk Gambar 4.64 Rancangan Layar Form Setoran Masuk Gambar 4.64 menunjukkan Form Setoran Masuk yang berisi data-data keterangan untuk menawar harga barang dimana terdiri dari Kode Setoran Masuk, Tanggal Setoran Masuk, Id karyawan, nama karyawan,no Rek, Bank, Grupbox data pelanggan (Id pelanggan, Nama pelanggan, No tlp dan alamat),griedview berisi Kd Kwitansi,Tanggal BP,Tanggal Penerimaan, Tanggal Jatuh Tempo, Jumlah, Status dan griedview berisi Id Kwitansi, Tanggal BP,Tanggal Penerimaan, Tanggal Jatuh Tempo, Jumlah, Keterangan. Tombol Simpan berfungsi untuk menyimpan data ke database Tr_Setoran Masuk, tombol Ubah berfungsi untuk mengubah penginputan data yang salah dan Tombol Batal untuk membatalkan transaksi

82 Rancangan Layar Form Limit Kredit untuk Pelanggan Baru Gambar 4.65 Rancangan Layar Form LimitKredit Pelanggan Baru Rancangan Layar Form Limit Kredit untuk Pelanggan Baru terdiri atas Tanggal, Kode Limit Kredit, Kode Pelanggan (dimana akan menampilkan Nama dan Alamat), Score untuk masing-masing Kriteria, Total Score, dan Limit Kredit. Tombol Simpan berfungsi untuk menyimpan Form Limit Kredit

83 Rancangan Layar Form Limit Kredit untuk Pelanggan Lama Gambar 4.66 Rancangan Layar Form Limit Kredit untuk Pelanggan Lama Gambar 4.66 berisi Tanggal, Kode Limit Kredit, Kode Pelanggan (menampilkan Nama, Alamat, dan Limit Kredit), Score, Total Transaksi, dan Limit Kredit. Tombol Simpan berfungsi untuk menyimpan Form Limit Kredit

84 124 Gambar 4.67 Message Box Print Transaksi Setiap Form yang sudah di setujui akan muncul message box seperti gambar 4.66 untuk menanyakan mencetak transaksi tersebut. 19. Rancangan Layar Form Melihat Laporan Gambar 4.68 Rancangan Layar Form Melihat Laporan Gambar 4.68 menunjukkan Form Melihat Laporan yang berisi data-data Laporan Perusahaan dimana terdiri dari Laporan Penjualan, Laporan Penjualan Barang yang sering beli, Laporan Barang yang jarang beli, Laporan penjualan pelanggan yang sering beli, Laporan Penjualan Pelanggan yang Jarang Beli, Laporan Piutang, Laporan Piutang Tidak Tepat Waktu, Laporan Piutang Tepat Waktu, Laporan analisis Umur Piutang, Laporan Retur Penjualan, Laporan Retur Penjualan berdasarkan grafik. Kemudian setiap laporan harus dipilih tanggal nya antara tanggal pertama sampai tanggal yang ingin disajikan. Dengan menekan tombol Tampilkan maka laporan yang dipilih berdasar tanggal akan ditampilkan.

85 Rancangan Layar Form Melihat Surat Penawaran Harga Gambar 4.69 Rancangan Layar Form Melihat SPH Gambar 4.69 menunjukkan Form Untuk Melihat SPH. Textbox kategori digunakan untuk mencari kategori berdasarkan kolom dan Pencarian digunakan untuk mencari langsung berdasarkan data yang ingin dicari. Setelah diisi semua maka akan ditekan tombol cari untuk menampilkan Form SPH yang dicari. 21. Rancangan Layar Form Melihat Order Penjualan Gambar 4.70 Rancangan Layar Form Melihat Order Penjualan Gambar 4.70 menunjukkan Form Untuk Melihat Order Penjualan. Textbox kategori digunakan untuk mencari kategori berdasarkan kolom dan Pencarian digunakan untuk mencari langsung berdasarkan data yang ingin dicari. Setelah diisi

86 126 semua maka akan ditekan tombol cari untuk menampilkan Form Order Penjualan yang dicari. 22. Rancangan Layar Form Melihat Surat Jalan Gambar 4.71 Rancangan Layar Form Melihat Surat Jalan Gambar 4.71 menunjukkan Form Untuk Melihat Surat Jalan. Textbox kategori digunakan untuk mencari kategori berdasarkan kolom dan Pencarian digunakan untuk mencari langsung berdasarkan data yang ingin dicari. Setelah diisi semua maka akan ditekan tombol cari untuk menampilkan Form Surat Jalan yang dicari 23. Rancangan Layar Form Melihat Faktur Penjualan Gambar 4.72 Rancangan Layar Form Melihat Faktur Penjualan Gambar 4.72 menunjukkan Form Untuk Melihat Faktur Penjualan. Textbox kategori digunakan untuk mencari kategori berdasarkan kolom dan Pencarian digunakan untuk mencari langsung berdasarkan data yang ingin dicari. Setelah diisi semua maka akan ditekan tombol cari untuk menampilkan Form Faktur Penjualan yang dicari.

87 Rancangan Layar Form Melihat Faktur Pajak Gambar 4.73 Rancangan Layar Form Melihat Faktur Pajak Gambar 4.73 menunjukkan Form Untuk Melihat Faktur Pajak. Textbox kategori digunakan untuk mencari kategori berdasarkan kolom dan Pencarian digunakan untuk mencari langsung berdasarkan data yang ingin dicari. Setelah diisi semua maka akan ditekan tombol cari untuk menampilkan Form Faktur Pajak yang dicari 25. Rancangan Layar Form Melihat Kwitansi Gambar 4.74 Rancangan Layar Form Melihat Kwitansi Gambar 4.74 menunjukkan Form Untuk Melihat Kwitansi. Textbox kategori digunakan untuk mencari kategori berdasarkan kolom dan Pencarian digunakan untuk mencari langsung berdasarkan data yang ingin dicari. Setelah diisi semua maka akan ditekan tombol cari untuk menampilkan Form Kwitansi yang dicari

88 Rancangan Layar Form Melihat Jurnal Gambar 4.75 Rancangan Layar Form Melihat Jurnal Gambar 4.75 menunjukkan Form Untuk Melihat Jurnal. Textbox dari dan sampai digunakan untuk mencari langsung berdasarkan range tanggal yang ingin dicari. Setelah diisi semua maka akan ditekan tombol cari untuk menampilkan Form Jurnal yang dicari berdasarkan emua transaksi yang telah terjadi berdasarkan periode yang telah ditentukan oleh user

89 Designing System Output 1. Rancangan Formulir Order Penjualan PT ELEMATEC INDONESIA Dea Towet 1 6th Floor Suite 604 Kawasan Mega Kuningan. Jalan Mega Kuningan Barat Kav. E4-3 no 1-2 Jakarta Selatan tel : Fax: Kode Order Penjualan : SO999 Tanggal Order Penjualan: dd/mm/yyyy Nama User : xxxxxxxxxx Nama Pelanggan : xxxxxxxxxxxxxxxxxxxxxxxxx ORDER PENJUALAN Kode Barang Nama Barang Jumlah Pemesanan BR999 Xxxxxxxxxxx 99 BR999 Xxxxxxxxxxx 99 BR999 Xxxxxxxxxxx 99 BR999 Xxxxxxxxxxx 99 BR999 Xxxxxxxxxxx 99 Total 99 Gambar 4.76 Rancangan Formulir Order Penjualan

90 Rancangan Formulir Surat Jalan Kode Order Penjualan : Tanggal Order Penjualan: PT ELEMATEC INDONESIA Dea Towet 1 6th Floor Suite 604 Kawasan Mega Kuningan. Jalan Mega Kuningan Barat Kav. E4-3 no 1-2 Jakarta Selatan tel : Fax: SO999 dd/mm/yyyy Nama User : xxxxxxxxxx Nama Pelanggan : xxxxxxxxxxxxxxxxxxxxxxxxx Alamat Pengiriman : xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxx xxxxxxxxxxx SURAT JALAN Kode Barang Nama Barang Jumlah Barang BR999 xxxxxxxxxxx 99 BR999 xxxxxxxxxxx 99 BR999 xxxxxxxxxxx 99 BR999 xxxxxxxxxxx 99 BR999 xxxxxxxxxxx 99 Penerima Pengirim ( ) ( ) Gambar 4.77 Rancangan Formulir Surat Jalan

91 Rancangan Formulir Invoice PT ELEMATEC INDONESIA Dea Towet 16th Floor Suite 604 Kawasan Mega Kuningan. Jalan Mega Kuningan Barat Kav. E4-3 no 1-2 Jakarta Selatan tel : Fax: Kode Invoice : FP999 Tanggal Invoice : dd/mm/yyyy Tanggal Jatuh Tempo : dd/mm/yyyy Kode Order Penjualan : SO999 Nama User : xxxxxxxxxx Nama Pelanggan : xxxxxxxxxx INVOICE Kode Barang Nama Barang Jumlah Unit Harga Satuan Total BR999 xxxxxxxxxxx 99 Rp Rp BR999 xxxxxxxxxxx 99 Rp Rp BR999 xxxxxxxxxxx 99 Rp Rp BR999 xxxxxxxxxxx 99 Rp Rp BR999 xxxxxxxxxxx 99 Rp Rp Subtotal Rp Potongan 99% Uang Muka Rp PPN 10% Rp Grand Total Rp Penerima Mengetahui ( ) ( ) Gambar 4.78 Rancangan Formulir Invoice

92 Rancangan Formulir Faktur Pajak PT ELEMATEC INDONESIA Dea Towet 16th Floor Suite 604 Kawasan Mega Kuningan. Jalan Mega Kuningan Barat Kav. Kode Faktur Pajak : FK999 E4-3 no 1-2 Jakarta Selatan tel : Fax: Tanggal Faktur : dd/mm/yyyy Kode Invoice : FP999 Nama User : xxxxxxxxxx Pengusaha Kena Pajak : xxxxxxxxxxxxxx NPWP : xxxxxxxxxxxxx Nama Pelanggan : xxxxxxxxxxxxxxx NPWP : xxxxxxxxxxxxx FAKTUR PAJAK Kode Barang Nama Barang Jumlah Unit Harga Satuan Total BR999 xxxxxxxxxxx 99 Rp Rp BR999 xxxxxxxxxxx 99 Rp Rp BR999 xxxxxxxxxxx 99 Rp Rp BR999 xxxxxxxxxxx 99 Rp Rp BR999 xxxxxxxxxxx 99 Rp Rp SubTotal Rp Potongan 99% Uang Muka Rp DPP Rp PPN 10% Rp Penerima Mengetahui ( ) ( ) Gambar 4.79 Rancangan Formulir Faktur Pajak

93 Rancangan Formulir Nota Retur Penjualan PT ELEMATEC INDONESIA Dea Towet 16th Floor Suite 604 Kawasan Mega Kuningan. Jalan Mega Kuningan Barat Kav. E4-3 no 1-2 Jakarta Selatan tel : Fax: Kode Retur Penjualan : RP999 Tanggal Surat Jalan : dd/mm/yyyy Kode Invoice : FP999 Nama User : xxxxxxxxxx Nama Pelanggan : xxxxxxxxxxxxxxxxxxxxxxxxx RETUR Kode Barang Nama Barang Keterangan Retur Jumlah Total Retur BR999 xxxxxxxxxxx xxxxxxxxxxxxxx 99 RP BR999 xxxxxxxxxxx xxxxxxxxxxxxxx 99 RP Total 99 RP Pembatalan PPN RP Grand Total RP Penerima Mengetahui ( ) ( ) Gambar 4.80 Rancangan Formulir Nota Retur Penjualan

94 Rancangan Formulir Kwitansi PT ELEMATEC INDONESIA Dea Towet 1 6th Floor Suite 604 Kawasan Mega Kuningan. Jalan Mega Kuningan Barat Kav. E4-3 no 1-2 Jakarta Selatan tel : Fax: KWITANSI Tanggal Pembayaran: dd/mm/yyyy Kode Pembayaran : BP999 Kode Pelanggan : PL999 Nama Pelanggan : xxxxxxxxxxx Alamat Pelanggan : xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxx Untuk Pembayaran : FP999 Rp FP999 Rp Jenis Pembayaran : xxxxxxxxx Rp xxxxxxxxx Rp Jumlah Pembayaran : Rp Mengetahui ( ) Gambar 4.81 Rancangan Formulir Kwitansi