BAB 4 PERANCANGAN SISTEM INFORMASI AKUNTANSI PENJUALAN, PIUTANG, DAN PENERIMAAN KAS PT. SURYA WARFA KHARISMA

Transkripsi

1 BAB 4 PERANCANGAN SISTEM INFORMASI AKUNTANSI PENJUALAN, PIUTANG, DAN PENERIMAAN KAS PT. SURYA WARFA KHARISMA 4.1 Analysis Document The Task Purpose Sistem informasi akuntansi penjualan, piutang dan penerimaan kas yang dikembangkan secara keseluruhan guna membantu dan memudahkan PT. Surya Warfa Kharisma dalam mengintegrasikan data-data dan informasi yang dibutuhkan untuk melakukan proses operasi penjualannya yang dimulai dengan penawaran harga, penerimaan pesanan, pengiriman barang, pencatatan penjualan, penerimaan retur, penagihan, dan penerimaan pembayaran serta data-data yang diperlukan bagi proses penjualan termasuk di dalamnya penilaian terhadap kredibilitas pelanggan. Sistem ini juga memudahkan PT. Surya Warfa Kharisma dalam penyusunan dan pembuatan laporan dengan lebih mudah atas data dan informasi terintegrasi tersebut secara akurat System Definition Sistem informasi akuntansi penjualan, piutang, dan penerimaan kas ini dirancang untuk membantu pemrosesan transaksi bisnis PT. Surya Warfa Kharisma yang berhubungan dengan kegiatan operasional penjualan, piutang, dan penerimaan kas sehari-hari. Selain itu, perancangan sistem ini digunakan untuk mendukung proses

2 101 pembuatan laporan yang terkait dengan aktivitas penjualan, piutang dan penerimaan kas secara tepat dan akurat. Sistem ini dibangun menggunakan platform PC (Personal Computer) yang didukung oleh jaringan LAN (Local Area Network) untuk mempermudah proses aliran data. Pengembangan sistem ini dilakukan berdasarkan usulan perbaikan untuk mengatasi permasalahan yang ditemui pada sistem berjalan. System definition dari sistem informasi akuntansi penjualan, piutang dan penerimaan kas ini dapat dijelaskan dan diringkas pada tabel 4.1 kriteria FACTOR berikut: Tabel 4.1 System Definiton dengan kriteria FACTOR Functionality Mendukung kegiatan penjualan dan pemrosesan transaksi mulai dari penawaran harga, penerimaan pesanan, pengiriman barang, penerimaan retur, penagihan, dan penerimaan pembayaran, serta proses pencatatan, pengendalian internal dan pembuatan laporan yang reliable terkait dengan aktivitas penjualan, piutang dan penerimaan kas. Application Karyawan Bagian Administrasi (Penjualan), Bagian Gudang, Domain Bagian Keuangan, Bagian Akuntansi, Manajer Administrasi (Penjualan), dan Manajer Keuangan. Conditions Sistem ini dikembangkan berdasarkan usulan untuk mengatasi permasalahan yang ditemui guna menangani kebutuhan sistem informasi akuntansi penjualan, piutang, dan penerimaan kas pada PT. Surya Warfa Kharisma dimana aplikasinya dijalankan oleh user yang terkait dan berwenang. Technology Menggunakan beberapa PC (Personal Computer) yang terhubung dengan jaringan LAN (Local Area Network) ditambah device umum lainnya seperti printer dan fax. Objects Bagian Administrasi, Bagian Keuangan, Bagian Akuntansi, Manajer Keuangan, Pelanggan, Barang, Surat Penawaran Harga, Sales Contract, Delivery Order, Invoice, Kuitansi, Surat Retur. Responsibility Menghasilkan informasi yang cepat, tepat dan akurat agar dapat membantu pihak manajemen dalam mengambil keputusan yang tepat serta mengatasi permasalahan yang ada.

3 Context Problem Domain Prosedur yang diusulkan terhadap sistem informasi akuntansi penjualan, piutang dan penerimaan kas pada PT. Surya Warfa Kharisma adalah sebagai berikut: Prosedur Penjualan diusulkan: Kegiatan penjualan berawal ketika bagian administrasi menerima permintaan penawaran harga dari klien atau calon pelanggan, baik yang datang langsung, melalui telepon atau fax. Bagian administrasi melakukan pengecekan terhadap status pelanggan, apabila pelanggan baru maka bagian administrasi perlu mendata pelanggan dan mencatatnya ke dalam database pelanggan untuk disimpan sebagai arsip. Jika barang dan jumlah yang diinginkan pelanggan tersedia, maka bagian administrasi membuat Surat Penawaran Harga yang didasarkan atas daftar harga barang standar yang ada di database barang. Setelah diotorisasi direktur, bagian administrasi mendistribusikan Surat Penawaran Harga (SPH) sebagai berikut: SPH rangkap 1 dikirimkan kepada pelanggan SPH rangkap 2 untuk arsip bagian administrasi Dalam melakukan kesepakatan harga, biasanya calon pembeli akan melakukan penawaran harga. Pelanggan menghubungi perusahaan, untuk melakukan negosiasi harga yang telah diberikan perusahaan. Setelah terjadi kesepakatan harga, pelanggan akan mengirimkan Surat Pemesanan Barang atau Purchase Order kepada perusahaan yang menyatakan bahwa pelanggan setuju untuk membeli sejumlah barang tertentu dengan harga yang telah disepakati. Berdasarkan Purchase Order yang diterima, bagian administrasi membuat Sales Contract antara dua pihak yang melampirkan kesepakatan

4 103 harga, serta mencantumkan cara pembayaran, jangka waktu pembayaran dan jangka waktu penyerahan barang. Pada saat pembuatan Sales Contract, sistem melakukan pengecekan limit kredit pelanggan yang tersedia. Apabila kredit tersedia tidak memenuhi untuk dilakukan transaksi, sistem akan menolak untuk memproses Sales Contract dan memerlukan otorisasi direktur dalam melanjutkan transaksi. Direktur juga dapat mengubah limit kredit pelanggan agar transaksi dapat dilanjutkan. Setelah meminta otorisasi direktur, Sales Contract dikirimkan kepada pelanggan. Distribusi dokumen yang dibuat sebanyak 3 rangkap ini adalah sebagai berikut: Sales Contract rangkap 1 untuk pelanggan Sales Contract rangkap 2 untuk bagian keuangan Sales Contract rangkap 3 untuk arsip bagian administrasi Selanjutnya bagian administrasi membuat Delivery Order (DO) sebanyak 4 rangkap yang kemudian diserahkan ke bagian keuangan. Berdasarkan Sales Contract dan Delivery Order yang diterima, bagian keuangan mencatat pesanan pelanggan tersebut ke dalam invoice sebanyak 4 rangkap yang akan didistribusikan sebagai berikut: invoice rangkap 1 untuk pelanggan (setelah melakukan pembayaran) invoice rangkap 2 diserahkan kepada pelanggan bersamaan dengan pengiriman barang invoice rangkap 3 untuk arsip bagian keuangan invoice rangkap 4 untuk bagian akuntansi Jika transaksi dilakukan secara kredit, invoice rangkap 1 akan diarsip ke dalam arsip sementara oleh bagian keuangan. Sedangkan untuk transaksi penjualan tunai, invoice rangkap 1 diserahkan bersamaan dengan invoice rangkap 2 dan barang pada saat pengiriman barang.

5 104 Bagian keuangan meneruskan DO sebanyak 4 rangkap dan invoice rangkap 2 (beserta invoice rangkap 1 jika transaksi penjualan secara tunai) kepada bagian perbekalan. Surat Delivery Order ini merupakan pernyataan yang digunakan sebagai perintah pengeluran barang dari gudang. Berdarkan DO, bagian perbekalan mencatat pengeluaran barang pada database persediaan. Dengan demikian, barang pun telah siap untuk dikirimkan kepada pelanggan. Pada saat penyerahan barang, bagian perbekalan melampirkan invoice rangkap 2 (beserta invoice rangkap 1 jika transaksi penjualan secara tunai) dan DO 4 rangkap untuk ditanda-tangani pelanggan. Invoice rangkap 2 (beserta invoice rangkap 1 jika transaksi penjualan secara tunai) dan DO rangkap 1 diserahkan kepada pelanggan sebagai bukti bahwa barang yang dikirim telah diterima oleh pelanggan. DO rangkap 1 untuk pelanggan DO rangkap 2 untuk bagian keuangan DO rangkap 3 untuk arsip bagian administrasi DO rangkap 4 untuk bagian perbekalan Setelah pengiriman barang selesai, bagian pengiriman mendistribusikan DO rangkap 2 yang telah ditanda-tangani pelanggan kepada bagian keuangan sebagai laporan pengiriman barang. Sedangkan DO rangkap 3 dikembalikan pada bagian administrasi dan mengarsip DO rangkap 4 sebagai bukti tertulis pengeluaran barang. Bagian keuangan mencocokkan DO rangkap 2 yang telah ditanda-tangani pelanggan dengan invoice rangkap 3 yang ada di arsip sementara. Berdasarkan invoice rangkap 4 yang diterima, bagian akuntansi mencatat transaksi penjualan ke dalam jurnal penjualan dan sistem menambahkan piutang pelanggan apabila penjualan dilakukan secara kredit. Kemudian dokumen-dokumen tersebut diarsipkan berdasarkan tanggal.

6 105 Prosedur Retur Penjualan Pelanggan dapat melakukan claim terhadap barang yang rusak atau kondisi lain yang tidak sesuai dengan pesanan. Jangka waktu pengembalian berbeda-beda tergantung kesepakatan yang tertera dalam perjanjian dengan masing-masing pelanggan. Dalam hal ini, pelanggan harus melampirkan barang yang di-retur dengan invoice serta DO rangkap 1 yang diterima ketika pengiriman barang. Bagian administrasi menangani keluhan pelanggan, dan menghubungi bagian perbekalan untuk memeriksa kondisi barang. Apabila keluhan yang ada sesuai dengan kebijakan retur perusahaan, maka bagian administrasi akan mencatatnya ke dalam Surat Retur (SR) sebanyak 4 rangkap sebagai berikut: SR rangkap 1 untuk pelanggan SR rangkap 2 untuk bagian akuntansi SR rangkap 3 untuk bagian perbekalan SR rangkap 4 untuk arsip bagian administrasi Berdasarkan retur yang terjadi, bagian perbekalan menerima barang retur. Sedangkan SR rangkap 2 yang diterima bagian akuntansi dicocokkan dengan invoice rangkap 4 yang ada diarsip. Surat Retur ini digunakan sebagai dasar pencatatan retur penjualan dan pengurangan piutang pelanggan. Barang yang diretur dapat dikembalikan tanpa penukaran atau dengan penukaran barang sejenis. Apabila atas permintaan pelanggan yang menginginkan bahwa barang yang diretur agar ditukarkan dengan barang pengganti dengan jenis dan tipe barang yang sama, bagian administrasi membuat Delivery Order Retur (DO-Retur) sebanyak 4 rangkap. Surat DO-Retur diserahkan kepada bagian perbekalan untuk selanjutnya akan dilakukan pengiriman barang seperti prosedur pengiriman standar. Berdasarkan DO-

7 106 Retur ini, bagian perbekalan menyiapkan sejumlah barang yang dibutuhkan kemudian kembali melakukan pengiriman barang kepada pelanggan dan melampirkan DO-Retur untuk ditanda-tangani pelanggan. Setelah pengiriman barang retur selesai, bagian perbekalan mendistribusikan DO-Retur yang telah ditanda-tangani pelanggan sebagai berikut: DO-Retur rangkap 1 untuk pelanggan DO-Retur rangkap 2 untuk bagian keuangan DO-Retur rangkap 3 untuk arsip bagian administrasi DO-Retur rangkap 4 untuk bagian perbekalan Prosedur Penerimaan Pembayaran dari Pelanggan Secara berkala, bagian keuangan akan memeriksa Daftar Piutang untuk mengetahui invoice yang segera jatuh tempo. Bila terdapat piutang telah jatuh tempo telah dibayarkan pelanggan, bagian keuangan menghubungi pelanggan dan melakukan penagihan. Dengan adanya konfirmasi pembayaran dari pelanggan, bagian keuangan membuat Faktur Pajak Standard (FPS) sebanyak 3 rangkap dan Kuitansi sebanyak 3 rangkap kemudian meminta otorisasi direktur. Pelanggan yang melakukan pembayaran dengan cara transfer, harus menyerahkan bukti transfer kepada perusahaan. Sedangkan pembayaran yang dilakukan dengan cek atau giro, maka bagian keuangan harus memastikan kepada pelanggan dan bank yang bersangkutan bahwa cek atau giro tersebut dapat dicairkan pada tanggal jatuh tempo. Ketika melakukan pembayaran, pelanggan menandatangani FPS dan Kuitansi yang masing-masing berangkap 3. Bagian keuangan juga melampirkan invoice rangkap

8 107 1 kepada pelanggan, kemudian menyerahkannya beserta FPS rangkap 1 dan Kuitansi rangkap 1 yang telah ditanda-tangani kepada pelanggan. Dokumen-dokumen yang diterima pelanggan ini merupakan bukti pembayaran yang lengkap dan sudah lunas. FPS rangkap 1 untuk pelanggan FPS rangkap 2 untuk diarsip bagian keuangan FPS rangkap 3 untuk bagian akuntansi Kuitansi rangkap 1 untuk pelanggan Kuitansi rangkap 2 untuk arsip bagian keuangan Kuitansi rangkap 3 untuk bagian akuntansi Sedangkan untuk transaksi penjualan yang dilakukan secara tunai, FPS sebanyak 2 rangkap dan Kuitansi 2 rangkap yang dibuat bagian keuangan akan didistribusikan kepada bagian perbekalan untuk dilampirkan pada saat pengiriman barang beserta invoice, dan DO. Bagian perbekalan menerima pembayaran dari pelanggan, kemudian memberikan FPS rangkap 1 dan Kuitansi rangkap 1 yang sudah dicap lunas kepada pelanggan. Untuk FPS rangkap 2 dan Kuitansi rangkap 2 yang telah ditanda-tangani pelanggan, dikembalikan ke bagian keuangan untuk diarsip. Berdasarkan FPS rangkap 3 dan Kuitansi rangkap 3 yang diterima, bagian akuntansi mencatat penerimaan kas ke dalam jurnal penerimaan kas dan mengurangi piutang pelanggan. Kemudian rangkap FPS dan rangkap Kuitansi akan diarsip permanen berdasarkan tanggal. Secara berkala, manajer keuangan akan melakukan penilaian pelanggan agar sistem dapat meng-update nilai kredibilitas pelanggan. Bagi pelanggan baru, penilaian ini tidak berlaku karena belum ada data historis pembelian yang dilakukan pelanggan.

9 108 Untuk menghindari pemberian kredit yang tidak potensial, pelanggan baru diwajibkan melakukan transaksi secara tunai saja. Penilaian pelanggan ini dapat dilakukan ketika sudah terdapat data historis transaksi penjualan (lima transaksi pertama atau 6 bulan sejak pelanggan didaftarkan). Penetapan kriteria yang dipakai ditentukan berdasarkan kebijakan manajemen perusahaan dan kriteria 5 C (Character, Capacity, Capital, Collateral, dan Condition), dimana pengukurannya menggunakan data historis penjualan per bulan, pembayaran pelanggan, jumlah retur penjualan pelanggan, dan lama langganan. Berikut tabel yang menunjukkan pengukuran kriteria dimaksud, dapat dilihat pada tabel 4.2: Tabel 4.2 Kriteria penetapan limit kredit pelanggan Kriteria Grade A Grade B Grade C Grade D Grade E Bobot Nilai transaksi per bulan > 80 juta 40 juta juta juta juta > 120 Ketepatan membayar 30 hari hari hari hari hari Jumlah retur per bulan 0% 1-5 % 6-10 % 10-14% > 14% 15 > Lama langganan 15 tahun tahun tahun tahun tahun Pertama-tama pelanggan dikategorikan ke beberapa grade, yaitu Grade A yang memiliki 5 poin, Grade B dengan 4 poin, Grade C dengan 3 poin, Grade D dengan 2 poin, dan Grade E dengan 1 poin. Kemudian poin atas grade dikalikan dengan bobot masing-masing kriteria yang menghasilkan range nilai dengan jumlah limit kredit disarankan sebagai berikut: Kredit poin: poin = limit kredit disarankan Rp poin = limit kredit disarankan Rp poin = limit kredit disarankan Rp poin = limit kredit disarankan Rp

10 109 Berikut adalah flowchart yang menggambarkan sistem informasi akuntansi penjualan, piutang, dan penerimaan kas pada PT. Surya Warfa Kharisma yang diusulkan, dapat dilihat pada gambar 4.1 sampai gambar 4.5 dan rich picture diusulkan pada gambar 4.6: Gambar 4.1 Flowchart Sistem Prosedur Penerimaan Pesanan

11 Gambar 4.2 Flowchart Sistem Prosedur Pengiriman Barang 110

12 111 Flowchart Prosedur Penerimaan Pembayaran dari Penjualan Kredit Bagian Keuangan Bagian Akuntansi invoice Memerik sa Invoice jatuh tempo Mengecek Daftar Piutang 3 Kuitansi (signed) 3 FPS (signed) Membuat laporan jurnal Pelanggan Membuat FPS dan Kuitansi Masukan data pembayaran 1 Kuitansi (signed) FPS (signed) invoice 2 3 Meringkas data piutang Invoice Menringkas data pembayaran 3 Memasukkan tanggal pelanggan Melakukan penagih an Barang Kuitansi T Meringkas data penerimaan kas Kuitansi Menerima Bukti Trasfer / Cek Cetak FPS dan Kuitansi Jurnal Bukti Transfer / Cek 3 Bukti Transfer / Cek 3 1 Kuitansi (signed) 3 Invoice Disetor ke bank FPS (signed) Laporan Jurnal Penerimaan Kas Memban dingkan dengan invoice Kuitansi FPS T Invoice 1 3 Bukti Transfer / Cek Meminta otorisasi direktur selesai 2 1 Keterangan: FPS = Faktur Pajak Standar Gambar 4.3 Flowchart Sistem Prosedur Penerimaan Pembayaran dari Penjualan Kredit

13 Gambar 4.4 Flowchart Sistem Prosedur Retur Penjualan (tanpa penukaran) 112

14 Gambar 4.5 Flowchart Sistem Prosedur Retur Penjualan (dengan penukaran) 113

15 MICROSOFT CORPORATION MICROSOFT CORPORATION MICROSOFT CORPORATION MICROSOFT CORPORATION MICROSOFT CORPORATION 114 Pelanggan Baru 1a Form Pelanggan Membuat SPH, SC, DO SPH = Surat Penawaran Harga PO = Purchase Order SC = Sales Contract DO = Delivery Order Invoice = Faktur Penjualan SR = Surat Retur FPS = Faktur Pajak Standard Bagian Akuntansi + FPS Kuitansi Cek Membuat Kuitansi 4 Pelanggan Tetap 8 1b 4 5 PO SC (signed) SPH (signed) Bagian Administrasi SC (signed) + DO (signed) invoice 13b + DO Bagian Perbekalan 13a DO (signed) 13c DO (signed) invoice + DO + Bukti Transfer 2 atau 1 Tagih piutang 3 Bagian Keuangan FPS + + Kuitansi invoice SC (signed) SC SPH (signed) SPH Membuat Invoice DO 10 Bagian Keuangan 14 invoice Bagian Akuntansi DO (signed) DO + 2a 1 Pelanggan + invoice Membuat SR 2b Laporan Bulanan SR + Bagian Administrasi 2c SR SR Board of Directors Laporan Jurnal Bagian Perbekalan Bagian Akuntansi Bagian Keuangan Gambar 4.6 Rich Picture sistem yang diusulkan

16 Application Domain Sistem yang diusulkan ditujukan untuk mendukung tugas dan tanggung jawab karyawan-karyawan Bagian Administrasi (Penjualan), Bagian Gudang, Bagian Keuangan, Bagian Akuntansi, Manajer Administrasi (Penjualan), dan Manajer Keuangan. Tugas-tugas utama dalam application domain yaitu melakukan penawaran harga, penerimaan pesanan, pengiriman barang, penerimaan retur, penagihan, penerimaan pembayaran, serta pencetakan laporan penjualan, pencetakan laporan piutang, pencetakan laporan penerimaan kas, pencetakan laporan analisis umur piutang, pencetakan laporan retur, pencetakan laporan jurnal penjualan, pencetakan laporan jurnal penerimaan kas, dan pencetakan laporan jurnal retur Problem Domain Cluster Model sistem informasi akuntansi penjualan, piutang, dan penerimaan kas pada PT. Surya Warfa Kharisma secara keseluruhan terdiri dari delapan cluster yaitu: Barang, Pelanggan, Pemesanan, User, Pengiriman, Penjualan, Pembayaran, dan Retur. Berikut adalah gambaran model sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma, dapat dilihat pada gambar 4.7.

17 116 pkg Cluster User Barang + Barang + Merek + Tipe Pelanggan + Pelanggan + Piutang + Bag. Admin + Bag. Akuntansi + Bag. Keuangan + Karyawan + Manajer Keuangan + Password Pemesanan + detail SC + detil SPH + Sales Contract + SPH Pengiriman + Delivery Order + detil DO Penjualan + Invoice Pembayaran + detil Kuitansi + Kuitansi Retur + detil DO-Retur + detil Surat Retur + DO-Retur + Surat Retur Gambar 4.7 Model sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma Structure Gambar berikut menunjukkan struktur Barang yang merupakan aggregation share bertingkat dari Merek dan Tipe. Tipe mempunyai hubungan aggregation share satu sampai banyak kepada Merek, dan Merek mempunyai hubungan aggregation share satu sampai banyak kepada Barang. pkg Barang Barang Merek Tipe 1..* 1 1..* 1 Gambar 4.8 Struktur Barang Gambar berikut menunjukkan struktur Pelanggan yang memiliki hubungan aggregation share dengan Piutang, dimana Pelanggan dapat memiliki satu sampai banyak Piutang.

18 117 pkg Pelanggan Pelanggan Piutang 1 1..* Gambar 4.9 Struktur Pelanggan Gambar berikut menunjukkan struktur User yang memiliki hubungan generalization dengan Bagian Admin, Bagian Keuangan, Bagian Akuntansi, dan Manajer Keuangan. pkg User Password Karyaw an Bag. Admin Bag. Keuangan Bag. Akuntansi Manajer Keuangan Gambar 4.10 Struktur User Gambar berikut menunjukkan struktur Pemesanan, dimana SPH mempunyai hubungan aggregation composite dengan detil SPH, dan SPH dapat memiliki satu sampai banyak detil SPH. Dalam gambar berikut juga menunjukkan hubungan association antara Sales Contract Sales Contract dengan SPH, dimana SPH dapat memiliki nol sampai satu Sales Contract. Selain itu, Sales Contract mempunyai hubungan aggregation composite dengan detil Sales Contract, dan Sales Contract dapat memiliki satu sampai banyak detil Sales Contract.

19 118 pkg Pemesanan SPH detil SPH Sales Contract detail SC 1..* * Gambar 4.11 Struktur Pemesanan Gambar berikut menunjukkan struktur Pengiriman, dimana Delivery Order mempunyai hubungan aggregation composite dengan detil Delivery Order, dimana Delivery Order dapat memiliki satu sampai banyak detil Delivery Order. pkg Pengiriman Delivery Order detil DO 1 1..* Gambar 4.12 Struktur Pengiriman Gambar berikut menunjukkan struktur Penjualan, yang merupakan struktur tunggal dan hanya terdiri dari Invoice tanpa pola hubungan. pkg Penjualan Invoice Gambar 4.13 Struktur Penjualan Gambar berikut menunjukkan struktur Pembayaran, dimana Kuitansi mempunyai hubungan aggregation composite dengan detil Kuitansi, dimana Kuitansi dapat memiliki satu sampai banyak detil Kuitansi.

20 119 pkg Pembayaran Kuitansi detil Kuitansi 1 1..* Gambar 4.14 Struktur Pembayaran Gambar berikut menunjukkan struktur Retur yang terdiri dari Surat Retur, detil Surat Retur, DO-Retur, dan detil DO-Retur. Surat Retur mempunyai hubungan aggregation composite dengan detil Surat Retur, dimana Surat Retur dapat memiliki satu sampai banyak detil Surat Retur. Surat Retur juga mempunyai hubungan association dengan DO-Retur dimana Surat Retur dapat memiliki satu sampai banyak DO-Retur, dan DO-Retur mempunyai hubungan aggregation composite dengan detil DO-Retur, dimana DO-Retur dapat memiliki satu sampai banyak detil DO-Retur. pkg Retur detil Surat Retur Surat Retur DO-Retur detil DO-Retur 1..* * 1 1..* Gambar 4.15 Struktur Retur

21 120 class System Keterangan: SPH = Surat Penawaran Harga DO = Delivery Order Password Karyaw an Tipe Merek * 1 1..* Manajer Keuangan Bag. Akun Bag. Keuangan Bag. Administrasi Barang * 1..* 1..* Kuitansi detail Kuitansi Invoice SPH detail SPH 1 1..* 1..* * 1..* * 1..* 1..* detail Surat Retur Surat Retur DO Sales Contract Pelanggan 1..* * * 1..* 1..* 1..* 1..* detail Delivery Order - Retur 1..* 1 Deliv ery Order - Retur detail DO detail Sales Contract Piutang Gambar 4.16 Class Diagram sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma

22 Classes Karyawan Class Karyawan merupakan kumpulan dari objek-objek karyawan dan merupakan actor dan sebagai user dalam sistem yang memiliki hak akses otorisasi yang berbeda. Class karyawan menggambarkan event dimana karyawan pertama kali didaftarkan, dan berstatus Active hingga karyawan tidak lagi bekerja di perusahaan. class Karyawan Karyaw an - kd_karyawan: char - nama_karyawan: varchar - divisi: char - jabatan: char - user_name: char Gambar 4.17 class Karyawan Password Class Password merupakan kumpulan dari objek-objek passsword dari user yang digunakan untuk membatasi hak akses user yang berbeda-beda terhadap sistem. Class password menggambarkan event dimana password pertama kali didaftarkan, kemudian melakukan login dan berstatus Active, mengubah password yang dapat dilakukan berulang-ulang hingga user logout dari sistem. class Password Password - user_name: char - user_password: char Gambar 4.18 class Password

23 122 stm Password /mengubah /mendaftar Registered /login Activ e /logout Gambar 4.19 behavioral pattern dari class Password Tabel 4.3 Keterangan Behavioral Pattern Class Password Behaviors Attributes mendaftar user_name, password login user_name, password logout user_name, password mengubah user_name, password Bagian Administrasi Class Bagian Administrasi merupakan kumpulan objek-objek dari user Bagian Administrasi. Class Bagian Administrasi menggambarkan event dimana Bagian Administrasi menawarkan harga kepada pelanggan dan berstatus Active, kemudian melakukan pekerjaan yang berhubungan dengan fungsinya secara berulang-ulang, dengan menawarkan, mengontrak, mengirim barang, dan meretur. class Bag. Administ... Bag. Administrasi Gambar 4.20 class Bag. Administrasi stm Bag. Administrasi /menawarkan /megontrak /menawarkan Activ e /mengirim /meretur Gambar 4.21 behavioral pattern dari class Bag. Administrasi

24 123 Tabel 4.4 Keterangan Behavioral Pattern Class Bag. Administrasi Behaviors Attributes menawarkan no. SPH, tgl akhir berlaku, nama pelanggan, kode barang, kode tipe, kode merek, nama barang, jumlah barang, harga mengontrak no. Sales Contract, tgl SC, no. SPH, durasi pembayaran, kode barang, jumlah, harga, kode pelanggan, status mengirim no. DO, tgl pengiriman, no. SC, tujuan pengiriman, alamat pengiriman, kode pelanggan, kode barang, jumlah, no. DO-R meretur no. SR, no. Invoice, kode pelanggan, kode barang, jumlah retur, tipe retur, keterangan Bagian Keuangan Class Bagian Keuangan merupakan kumpulan objek-objek dari user Bagian Keuangan. Class Bagian Keuangan menggambarkan event dimana Bagian Keuangan melakukan penjualan dan berstatus Active, kemudian melakukan pekerjaan yang berhubungan dengan fungsinya secara berulang-ulang, dengan menjual, dan menerima pembayaran. class Bag. Keuangan stm Bag. Keuangan Bag. Keuangan /menjual /membayar /menjual Activ e Gambar 4.22 class Bag. Keu Gambar 4.23 behavioral pattern dari class Bag. Keu Tabel 4.5 Keterangan Behavioral Pattern Class Bag. Keuangan menjual membayar Behaviors Attributes no. Invoice, jenis pembayaran, tgl jatuh tempo, no. DO, kode pelanggan no. Kuitansi, tgl bayar, no. Invoice, kode pelanggan, no. SR, cara pembayaran, no. cek/giro, bank, jumlah pembayaran

25 124 Bagian Akuntansi Class Bagian Akuntansi merupakan kumpulan objek-objek dari user Bagian Akuntansi. Class Bagian Akuntansi menggambarkan event dimana Bagian Akuntansi menjurnal dan berstatus Active, kemudian melakukan pekerjaan yang berhubungan dengan fungsinya secara berulang-ulang, yaitu menjurnal. class Bag. Akuntansi stm Bag. Akuntansi Bag. Akuntansi /menjurnal /menjurnal Activ e Gambar 4.24 class Bag.Akuntansi Gambar 4.25 behavioral pattern dari class Bag.Akun Tabel 4.6 Keterangan Behavioral Pattern Class Bag. Akuntansi menjurnal Behaviors Attributes kd_pelanggan, no. tnvoice, tgl_invoice, total_invoice, no. kuitansi, tgl_kuitansi, total_kuitansi, tgl_retur, no. Surat Retur, total_retur, saldo_piutang. Manajer Keuangan Class Manajer Keuangan merupakan kumpulan objek-objek dari user Manajer Keuangan. Class Manajer Keuangan menggambarkan event dimana Manajer Keuangan melakukan penilaian terhadap pelanggan dan berstatus Active, kemudian melakukan pekerjaan yang berhubungan dengan fungsinya secara berulang-ulang, yaitu menilai dan mengotorisasi transaksi pending. class Manajer Keu... Manajer Keuangan stm Manajer Keuangan /menilai /menilai Activ e /menyetujui Gambar 4.26 class Manajer Keu. Gambar 4.27 behavioral pattern dari class Manajer Keu.

26 125 Tabel 4.7 Keterangan Behavioral Pattern Class Manajer Keuangan Behaviors Attributes menilai nama pelanggan, limit kredit menyetujui no. SC, total harga, kode pelanggan, limit kredit tersedia, status Pelanggan Class Pelanggan merupakan kumpulan objek-objek dari pelanggan yang sudah terdaftar di perusahaan. Class Pelanggan menggambarkan event dimana pelanggan didaftarkan pertama kali sebagai pelanggan baru untuk kemudian berstatus Registered. Pelanggan berstatus Active, dapat dimulai dengan event menawarkan harga, kemudian mengontrak, menjual, membayar, meretur, dan menilai. class Pelanggan Pelanggan - kode_pelanggan: char - nama_pelanggan: varchar - no.npwp: char - alamat: varchar - kota: char - no_telp: char - fax: char - tgl_saldo_awal: date - saldo_piutang_awal: long - saldo_piutang: long - limit_kredit: long - contact_person: varchar - varchar - mobille_no: char - tgl_daftar: date - lama_langganan: int Gambar 4.28 class Pelanggan stm Pelanggan /mengontrak /menawarkan /menjual /mendaftar Registered /menawarkan_harga Activ e /menilai /membayar /meretur Gambar 4.29 behavioral pattern dari class Pelanggan

27 126 Tabel 4.8 Keterangan Behavioral Pattern Class Pelanggan Behaviors Attributes kode pelanggan, nama pelanggan, no. NPWP, alamat, kota, mendaftar no. Telp, fax, tgl saldo awal, saldo piutang awal, saldo piutang, limit kredit, kredit tersedia, contact person, , mobile no., tgl daftar, lama langganan menawarkan no. SPH, tgl akhir berlaku, kode pelanggan, kode barang, kode tipe, kode merek, nama barang, jumlah barang, harga mengontrak no. Sales contract, tgl SC, durasi pembayaran, kode barang, jumlah, total harga menjual no. Invoice, jenis pembayaran, tgl jatuh tempo, no, DO, kode pelanggan, total invoice membayar no. Kuitansi, tgl pembayaran, no. Invoice, kode pelanggan, cara pembayaran, no. Cek/ giro, bank, jumlah pembayaran no. Surat retur, tgl retur, no, invoice, kode pelanggan, tipe meretur barang, merek barang, nama barang, jumlah retur, total retur, tipe retur, keterangan menilai nama pelanggan, limit kredit Barang Class Barang merupakan kumpulan dari objek-objek barang yang dijual di perusahaan. Class Barang menggambarkan event dimana barang diterima dan berstatus Available dan ketika berstatus Active, barang dapat dilakukan event menawarkan, mengontrak, mengirim barang, dan meretur. class Barang Barang - kode_barang: char - kd_tipe: char - kd_merek: char - nama_barang: varchar - satuan: char - harga: long - tgl_saldo_awal: date - saldo awal: long - jumlah_tersedia: int Gambar 4.30 class Barang

28 127 stm Barang /menawarkan /mengontrak /menerima Available /menawarkan Activ e [barang_habis] [barang_baru] /mendaftar /mengirim /meretur Pending Gambar 4.31 behavioral pattern dari class Barang Tabel 4.9 Keterangan Behavioral Pattern Class Barang Behaviors Attributes mendaftar kode barang, kode tipe, kode merek, nama barang, satuan, harga barang, tgl saldo awal, saldo awal, jumlah tersedia menerima kode barang, kode tipe, merek barang, nama barang, jumlah tersedia menawarkan no. SPH, kode barang, kode tipe, kode merek, nama barang, harga barang, jumlah tersedia mengontrak no. SC, kode barang, kode tipe, kode merek, nama barang, harga barang, jumlah tersedia mengirim no. DO, kode barang, kode tipe, kode merek, nama barang, harga barang, jumlah tersedia, no. DO-R meretur no. SR, kode barang, kode tipe, kode merek, nama barang, harga barang, jumlah tersedia Tipe Class Tipe merupakan kumpulan dari objek-objek tipe barang yang dijual di perusahaan. Class Tipe menggambarkan event dimana tipe pertama kali didaftarkan dan berstatus Active. class Tipe Tipe stm Tipe - kd_tipe: char - nama_tipe: char /mendaftar Activ e Gambar 4.32 class Tipe Gambar 4.33 behavioral pattern dari class Tipe

29 128 Tabel 4.10 Keterangan Behavioral Pattern Class Tipe Behaviors Attributes mendaftar kode tipe, nama tipe Merek Class Merek merupakan kumpulan dari objek-objek merek barang yang dijual di perusahaan. Class Merek menggambarkan event dimana merek pertama kali didaftarkan dan berstatus Active. class Merek Merek stm Merek - kd_merek: char - nama_merek: char - kd_tipe: char /mendaftar Activ e Gambar 4.34 class Tipe Gambar 4.35 behavioral pattern dari class Tipe Tabel 4.11 Keterangan Behavioral Pattern Class Tipe Behaviors Attributes mendaftar kode merek, nama merek, kode tipe SPH (Surat Penawaran Harga) Class SPH merupakan kumpulan dari objek-objek dokumen penawaran harga yang telah dibuat oleh perusahaan untuk pelanggan. Class SPH menggambarkan event dimana SPH pertama kali yaitu menawarkan harga dan berstatus Waiting hingga barang tersedia, kemudian SPH akan berstatus Active ketika event menerima kontrak, dan status Active akan selesai apabila SPH ditolak pelanggan atau masa berlaku SPH lewat tanggal akhir berlaku.

30 129 class SPH SPH - no.sph: char - tgl_akhir_berlaku: date - nama_pelanggan: varchar - subtotal: long - PPN: long - total_harga: long Gambar 4.36 class SPH stm SPH Proceed [barang_tidak_tersedia] [barang_tersedia] /menawarkan Waiting /mengontrak [lewat_tgl_akhir_berlaku] Activ e [menolak] Gambar 4.37 behavioral pattern dari class SPH Tabel 4.12 Keterangan Behavioral Pattern Class SPH Behaviors Attributes no. SPH, tgl akhir berlaku, nama pelanggan, subtotal, menawarkan PPN, total harga mengontrak no. SPH, nama pelanggan, subtotal, PPN, total harga Detail SPH Gambar berikut menunjukkan class detail SPH dan behavioral pattern-nya. class detail SPH detail SPH - no.sph: char - kode_barang: char - tipe_barang: char - merek: char - nama_barang: varchar - jumlah_tersedia: int - jumlah_pesan: int - harga_barang: long Gambar 4.38 class detail SPH

31 130 stm detil SPH Proceed [barang_tidak_tersedia] [barang_tersedia] /menawarkan Waiting [menolak] Gambar 4.39 behavioral pattern dari class detail SPH Tabel 4.13 Keterangan Behavioral Pattern Class detail SPH Behaviors Attributes menawarkan no. SPH, kode barang, tipe barang, merek, nama barang, jumlah tersedia, jumlah pesan, harga barang Sales Contract Class Sales Contract merupakan kumpulan objek-objek dari dokumen kontrak penjualan yang telah dibuat oleh perusahaan. Class Sales Contract ini menggambarkan event mengontrak yang pertama kali dengan status Waiting hingga kredit pelanggan memenuhi/ mencukupi untuk melakukan transaksi kontrak. Kemudian status Sales Contract menjadi Active ketika dilakukan hingga event mengirim barang. class System Sales Contract - no.sc: char - no.sph: char - durasi_pembayaran: int - kode_pelanggan: char - limit_kredit_tersedia: long - status: boolean - subtotal: long - PPN: long - total_harga: long Gambar 4.40 class Sales Contract

32 131 stm Sales Contract /mengontrak Waiting /mengirim [kredit_tidak_memenuhi] [kredit_memenuhi] Pending Gambar 4.41 behavioral pattern dari class Sales Contract Tabel 4.14 Keterangan Behavioral Pattern Class Sales Contract Behaviors Attributes mengontrak no. SC, no. SPH, durasi pembayaran, kode pelanggan, limit kredit tersedia, status, subtotal, PPN, total harga mengirim no. SC, durasi pembayaran, kode pelanggan pattern-nya. Detail Sales Contract Gambar berikut menunjukkan class detail Sales Contract dan behavioral class detail Sales Contract detail Sales Contract - no.salescontract: char - kode_barang: char - jumlah_barang: int - harga_satuan: long Gambar 4.42 class detail Sales Contract stm detil SC /mengontrak Waiting /mengirim Gambar 4.43 behavioral pattern dari class detail Sales Contract

33 132 Tabel 4.15 Keterangan Behavioral Pattern Class detail Sales Contract Behaviors Attributes mengontrak No. SC, kode barang, jumlah barang, harga satuan mengirim No. SC, kode barang, jumlah barang, harga satuan Delivery Order Class Delivery Order merupakan kumpulan dari objek-objek dokumen Delivery Order yang telah dibuat oleh perusahaan. Class Delivery Order ini menggambarkan event mengirim barang dan berstatus Active hingga dilakukan penagihan penjualan atau dalam hal ini membuat invoice. class DO DO - no.do: char - tgl_pengiriman: date - no.sc: char - tujuan_pengiriman: varchar - alamat_pengiriman: varchar - kode_pelanggan: char Gambar 4.44 class Delivery Order stm DO /mengirim Activ e /menagih /meretur [tercatat] Returned Gambar 4.45 behavioral pattern dari class Delivery Order Tabel 4.16 Keterangan Behavioral Pattern Class Delivery Order Behaviors Attributes mengirim no. DO, kode barang, jumlah dikirim menagih no. DO, kode barang, jumlah dikirim meretur no. DO, kode barang, jumlah retur

34 133 pattern-nya. Detail DO Gambar berikut menunjukkan class detail Delivery Order dan behavioral class detail DO detail DO - no.do: char - kode_barang: char - jumlah_dikirim: int Gambar 4.46 class detail Delivery Order stm detil DO /mengirim_barang Activ e /meretur Returned [tercatat] Gambar 4.47 behavioral pattern dari class detail Delivery Order Tabel 4.17 Keterangan Behavioral Pattern Class detail Delivery Order Behaviors Attributes mengirim no. DO, kode barang, jumlah dikirim meretur no. DO, kode barang, jumlah retur Invoice Class Invoice merupakan kumpulan dari objek-objek dokumen Invoice yang telah dibuat oleh perusahaan. Class Invoice ini menggambarkan event yang dimulai dari menagih dan berstatus Active, kemudian setelah event membayar yang juga dapat dilakukan berkali-kali, Invoice akan berstatus Paid hingga dilakukan pembayaran lunas oleh pelanggan.

35 134 class Invoice Invoice - no.invoice: char - jenis_pembayaran: boolean - tgl_jatuh_tempo: date - no.do: char - kode_pelanggan: char - subtotal: long - PPN: long - total_harga: long Gambar 4.48 class Invoice stm Invoice /membayar /menagih Activ e /membayar Paid /menjurnal Gambar 4.49 behavioral pattern dari class Invoice Behaviors menagih membayar menjurnal Tabel 4.18 Keterangan Behavioral Pattern Class Invoice Attributes no. Invoice, jenis pembayaran, tgl jatuh tempo, no. DO, kode pelanggan, subtotal, PPN, total harga no. Invoice, jenis pembayaran, tgl jatuh tempo, kode pelanggan, total harga no. Invoice, kode pelanggan, tgl invoice, total invoice Kuitansi Class Kuitansi merupakan kumpulan dari objek-objek dokumen kuitansi yang telah dibuat oleh perusahaan sebagai bukti pembayaran yang telah dilakukan pelanggan. Class Kuitansi ini menggambarkan event menerima pembayaran dan berstatus Active, dimana event menrima pembayaran dapat dilakukan berkali-kali dan selesai ketika transaksi pembayaran dicatat di jurnal.

36 135 class Kuitansi Kuitansi - no.kuitansi: char - tgl_bayar: date - no.invoice: char - kdoe_pelanggan: char - no.sr: char - cara_pembayaran: char - no.cek/giro: char - bank: char - jumlah_pembayaran: long Gambar 4.50 class Kuitansi stm Kuitansi /membayar /membayar Activ e /menjurnal Gambar 4.51 behavioral pattern dari class Kuitansi Behaviors menerima pembayaran menjurnal Tabel 4.19 Keterangan Behavioral Pattern Class Kuitansi Attributes no. Kuitansi, tgl bayar, no. Invoice, kode pelanggan, no. SR, cara pembayaran, no. cek/giro, bank, jumlah pembayaran no. Kuitansi kode pelanggan, tgl bayar total bayar Detail Kuitansi Gambar berikut menunjukkan class detail Kuitansi dan behavioral pattern-nya. class detail Kuitansi detail Kuitansi - no.kuitansi: char - no.invoice: char - total_invoice: long - no.sr: char - total_retur: long - total_tagihan: long - total_bayar: long - si sa: l ong Gambar 4.52 class detail Kuitansi

37 136 stm detail Kuitansi /membayar /membayar Activ e Gambar 4.53 behavioral pattern dari class detail Kuitansi Tabel 4.20 Keterangan Behavioral Pattern Class detail Kuitansi Behaviors Attributes membayar no. Kuitansi, no. Invoice, total invoice, no. SR, total retur, total tagihan, total bayar, sisa Surat Retur Class Surat Retur merupakan kumpulan dari objek-objek dokumen Surat Retur yang telah dibuat oleh perusahaan. Class Surat Retur ini menggambarkan event yang pertama kali yaitu menerima retur dengan status Active, dan berakhir ketika tipe retur mengurangi puitang dicatat di jurnal. Apabila pelanggan menginginkan untuk tukar barang, dilakukan event mengirim barang retur dan status menjadi Proceed hingga barang terkirim. class Surat Retur Surat Retur - no.sr: char - no.invoice: char - kode_pelanggan: char - jumlah_retur: int - tipe_retur: char - keterangan: varchar Gambar 4.54 class Surat Retur

38 137 stm Surat Retur /meretur Activ e /mengirim Proceed /menjurnal Gambar 4.55 behavioral pattern dari class Surat Retur Tabel 4.21 Keterangan Behavioral Pattern Class Surat Retur Behaviors Attributes meretur no. SR, no. Invoice, kode pelanggan, jumlah retur, tipe retur, keterangan mengirim no. SR, kode pelanggan, jumlah retur, tipe retur menjurnal no. SR, kode pelanggan, tgl retur, total retur Detail Surat Retur Gambar berikut menunjukkan class detail Surat Retur dan behavioral pattern. class detail Surat Retur detail Surat Retur - no.sr: char - kode_barang: char - jumlah_retur: int - harga_satuan: long - total_harga: long - tipe_retur: char - keterangan: varchar stm detil Surat Retur /meretur Activ e Gambar 4.56 class detail Surat Retur Gambar 4.57 behavioral pattern dari class detail SR Tabel 4.22 Keterangan Behavioral Pattern Class detail Surat Retur Behaviors Attributes meretur no. SR, kode barang, jumlah retur, harga satuan, total harga, tipe retur, keterangan

39 138 DO-Retur Class DO-Retur merupakan kumpulan objek-objek dari dokumen Delivery Order-Retur yang telah dibuat oleh perusahaan. Class DO-Retur ini menggambarkan event mengirim barang retur dan berstatus Active hingga barang yang dikirim telah sampai ke pelanggan. class Delivery Order - Retur Delivery Order - Retur - no.do-r: char - tgl_pengiriman: date - no.sr: char - tujuan_pengiriman: varchar - alamat_pengiriman: varchar - kode_pelanggan: char Gambar 4.58 class DO-Retur stm Deliv ery Order - Retur /mengirim Activ e [terkirim] Send Gambar 4.59 behavioral pattern dari class DO-Retur Tabel 4.23 Keterangan Behavioral Pattern Class DO-Retur Behaviors Attributes mengirim no. DO-R, tgl pengiriman, no. SR, tujuan pengiriman, alamat pengiriman, kode pelanggan Detail DO-Retur Gambar berikut menunjukkan class detail DO-Retur dan behavioral pattern-nya. class detail Delivery Ord... detail Delivery Order - Retur - no.do: char - kode_barang: char - jumlah_dikirim: int Gambar 4.60 class detail DO-Retur

40 139 stm detail DO-R /mengirim Activ e Gambar 4.61 behavioral pattern dari class detail DO-Retur Tabel 4.24 Keterangan Behavioral Pattern Class detail DO-Retur Behaviors Attributes mengirim no. DO, kode barang, jumlah dikirim Piutang Class Piutang merupakan kumpulan dari objek-objek Piutang masing-masing pelanggan yang ada dimiliki perusahaan. Class Piutang ini menggambarkan event melakukan penjualan yang pertama kali membuat status piutang menjadi Active dan dapat berubah menjadi Reduced apabila terdapat event menerima retur. Setelah event menerima pembayaran, dimana pembayaran ini dapat dilakukan berkali-kali, maka status berubah menjadi Settled, dan dapat berakhir apabila pelanggan telah melunasi saldo piutangnya. class Piutang Piutang - no.invoice: char - tgl_invoice: date - no.kuitansi: char - tgl_kuitansi: date - no.sr: char - tgl_retur: int - kode_pelanggan: char - saldo_piutang: long Gambar 4.62 class Piutang

41 140 stm Piutang /menagih Activ e /meretur /membayar Reduced /membayar Settled [lunas] Gambar 4.63 behavioral pattern dari class Piutang Tabel 4.25 Keterangan Behavioral Pattern Class Piutang Behaviors Attributes menagih no. Invoice, total invoice, tgl invoice, kode pelanggan, saldo piutang membayar no. Kuitansi, total pembayaran, tgl bayar, kode pelanggan, saldo piutang meretur no. SR, total retur, tgl retur kode pelanggan, saldo piutang menjurnal kode pelanggan, tgl jurnal, saldo piutang Events Berikut merupakan event table dari sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma:

42 141 Tabel 4.26 Event Table sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma Class Password Bagian Administrasi Bagian Keuangan bagian Akuntansi Manajer Keuangan pelanggan barang tipe merek SPH Event login * logout * mengubah * mendaftar menerima + menawarkan * * * + * mengontrak * * * + + * mengirim * * * * * menjual * * membayar * * * + * + meretur * * * + + * + menjurnal * menilai * * menyetujui * + Sales Contract Delivery Order Invoice Kuitansi Surat Retur Delivery Order-Retur SPH detail SC detail DO detail Kuitansi detail SR detail DO-R detail piutang

43 Application Domain Usage Actor Table Terdapat 4 actor dalam sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma, yaitu: Bagian Administrasi, Bagian Keuangan, Bagian Akuntansi, dan Manajer Keuangan. Tabel 4.27 Actor Table sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma Actor Use Case mendata pelanggan mendata barang mendata tipe mendata merek membuat SPH membuat Sales Contract membuat Delivery Order membuat Invoice membuat Kuitansi membuat Faktur Pajak Standar membuar Surat Retur membuat DO-Retur membuat laporan penjualan membuat laporan penerimaan kas membuat laporan piutang membuat laporan analisis umur piutang membuat laporan retur membuat laporan jurnal penjualan membuat laporan jurnal penerimaan kas membuat laporan jurnal retur mengupdate piutang melakukan penilaian pelanggan mengotorisasi transaksi pending Bagian Administrasi Bagian Keuangan Bagian Akuntansi Manajer Keuangan

44 Actors Berikut ini adalah actor specification dari sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma: Tujuan Karakteristik Contoh Tabel 4.28 Actor Specification dari karyawan Bagian Administrasi Bagian Administrasi Karyawan ini bertanggung jawab dalam kegiatan penawaran harga kepada pelanggan, menangani kontrak penjualan, membuat surat Delivery Order sebagai perintah pengiriman barang kepada bagian perbekalan (gudang), menerima retur, dan membuat surat Delivery Order-Retur yang digunakan sebagai dasar pengiriman barang retur. Karyawan bagian ini juga bertanggung jawab mendata pelanggan baru, barang, tipe, dan merek barang yang dijual oleh perusahaan. Karyawan ini harus memiliki kemampuan berkomunikasi pada pelanggan dengan baik, terutama dalam menawarkan harga dan menerima kontrak penjualan, memiliki pengetahuan mengenai barang dengan baik, dan memiliki pengalaman administratif lainnya yang mendukung proses penjualan. Bagian administrasi membuat SPH berdasarkan permintaan pelanggan, membuat Sales Contract, membuat DO, membuat Surat Retur, membuat DO-Retur dan mendistribusikannya ke bagian terkait. Tujuan Karakteristik Contoh Tabel 4.29 Actor Specification dari karyawan Bagian Keuangan Bagian Keuangan Karyawan ini bertanggung jawab dalam kegiatan pencatatan penjualan, penerimaan pembayaran dari pelanggan, dan dalam pembuatan laporan terkait. Selain itu bagian keuangan bertanggung jawab untuk memantau piutang pelanggan yang akan jatuh tempo dan terlambat. Karyawan ini harus memiliki ketelitian yang baik dalam mengatur arus kas, beritikad baik dan jujur, serta memiliki pengalaman administratif keuangan yang bagus. Bagian keuangan membuat invoice, mencatat pembayaran pelanggan dalam Kuitansi, membuat laporan bulanan, melakukan penagihan dan mengingatkan pelanggan atas piutangnya yang terlambat bayar.

45 144 Tujuan Karakteristik Contoh Tujuan Karakteristik Contoh Tabel 4.30 Actor Specification dari karyawan Bagian Akuntansi Bagian Akuntansi Karyawan ini bertanggung jawab dalam pencatatan akuntansi dan membuat laporan jurnal penjualan, laporan jurnal penerimaan kas, dan laporan jurnal retur. Karyawan ini harus memiliki latar belakang pendidikan di bidang akuntansi dan teliti dalam menjalankan tugasnya, serta berpengalaman di bidangnya. Bagian Akuntansi membuat laporan jurnal penjualan, laporan jurnal penerimaan kas, laporan jurnal retur penjualan yang dilakukan setiap bulannya. Tabel 4.31 Actor Specification dari Manajer Keuangan Manajer Keuangan Karyawan ini bertanggung jawab dalam melakukan penilaian terhadap pelanggan, menentukan limit kredit pelanggan, dan membuat keputusan otorisasi transaksi pelanggan yang melebihi limit. Karyawan ini harus memiliki kemampuan analisis kredibilitas, bersifat objektif, dan dapat mengambil keputusan yang tepat bagi kesehatan keuangan perusahaan. Manajer Keuangan menentukan jumlah limit kredit yang dimiliki pelanggan, dan melakukan otorisasi limit kreditnya Use Cases Berikut ini digambarkan use case diagram dari sistem informasi akuntansi penjualan, piutang, dan penerimaan kas pada PT. Surya Warfa Kharisma:

46 145 uc Use Cases Model Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas PT. Surya Warfa Kharisma Mendata Pelanggan Membuat Inv oice «extend» Mendata Tipe Membuat FPS «extend» Mendata Barang «extend» Membuat Kuitansi Mendata Merek Membuat Laporan Penj ualan Bagian Keuangan Membuat SPH Membuat Laporan Penerimaan Kas Bagian Administrasi Membuat Sales Contract Membuat Laporan Piutang Membuat Deliv ery Order Membuat Laporan Analisis Umur Piutang Membuat Surat Retur Membuat Laporan Retur Membuat DO-Retur Mengupdate Piutang Mengotorisasi transaksi pending Membuat Laporan Jurnal Penjualan Manajer Keuangan Melakukan penilaian pelanggan Membuat Laporan Jurnal Penerimaan Kas Bagian Akuntansi Keterangan: SPH = Surat Penawaran Harga FPS = Faktur Pajak Standar DO-R= Delivery Order Retur Membuat Laporan Jurnal Retur Penj ualan Gambar 4.64 Use Case Diagram dari Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada PT. Surya Warfa Kharisma

47 146 Berikut adalah Use Case Specification dari sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma: Tabel 4.32 Use Case Specification Mendata pelanggan Use Case Objects Functions Mendata pelanggan Kegiatan ini dilakukan oleh bagian administrasi ketika dalam proses penjualan, pelanggan yang bersangkutan adalah pelanggan baru yang belum pernah didata oleh perusahaan. Bagian administrasi akan menginput data-data mengenai pelanggan ke dalam master pelanggan kemudian menyimpannya. Pelanggan get_data_pelanggan, get_last_record, get_piutang, calculate_kredit_tersedia, go_to_first_record, go_to_previous_record, go_to_next_record, go_to_last_record, get_to_last_code, generate_no.pelanggan, calculate_saldo_piutang, get_limit_kredit, calculate_lama_langganan, remove, save Use Case Objects Functions Tabel 4.33 Use Case Specification Mendata barang Mendata barang Kegiatan ini dilakukan oleh bagian administrasi ketika terdapat barang baru sebagai barang yang dijual perusahaan. Bagian administrasi akan menginput data-data mengenai deskripsi barang secara lengkap kemudian menyimpan data barang baru tersebut ke dalam master barang. Barang, Tipe, Merek get_data_barang, get_last_record, go_to_first_record, go_to_previous_record, go_to_next_record, go_to_last_record, get_tipe_barang, get_merek_barang, calculate_jumlah_tersedia, remove, save Use Case Objects Functions Tabel 4.34 Use Case Specification Mendata tipe Mendata tipe Kegiatan ini dilakukan oleh bagian adminstrasi ketika dalam pendataan barang, perusahaan memutuskan penambahan tipe barang baru yang akan dijual di perusahaan. Bagian administrasi menginput data tipe barang baru ke dalam master tipe kemudian menyimpannya dan mengupdate tipe barang dalan master barang. Barang, Tipe get_data_tipe, get_last_record, get_last_code, generate_kode_tipe, remove, save

48 147 Use Case Objects Functions Tabel 4.35 Use Case Specification Mendata merek Mendata merek Kegiatan ini dilakukan oleh bagian adminstrasi ketika dalam pendataan barang, perusahaan memutuskan penambahan merek barang baru yang akan dijual di perusahaan. Bagian administrasi menginput data merek barang baru ke dalam master tipe kemudian menyimpannya dan mengupdate merek barang dalan master barang. Barang, Merek, Tipe get_data_merek, get_kode_tipe, get_last_record, get_last_code, generate_kode_merek, remove, save Use Case Objects Functions Tabel 4.36 Use Case Specification Membuat SPH Membuat SPH Kegiatan ini dilakukan oleh bagian administrasi dalam rangka memberikan penawaran harga kepada pelanggan. Bagian administrasi mengecek ketersediaan barang atas pesanan pelanggan, apabila tersedia maka bagian administrasi mendata barang-barang yang akan ditawarkan kepada pelanggan. Sistem mengecek ketersediaan barang dan apabila jumlah yang dipesan melebihi ketersediaan barang, sistem akan memberikan informasi bahwa ketersediaan barang tidak mencukupi dan SPH tidak dapat diproses. SPH, detil SPH, pelanggan, barang, tipe, merek get_last_record, get_last_record_detail, go_to_first_record, go_to_previous_record, go_to_next_record, go_to_last_record, get_data_pelanggan, get_last_code, generate_no.sph, get_tipe_barang, get_merek_barang, get_nama_barang, get_kode_barang, calculate_total_harga, calculate_subtotal, calculate_ppn, calculate_grand_total, remove, save, print Use Case Objects Functions Tabel 4.37Use Case Specification Membuat Sales Contract Membuat Sales Contract Kegiatan ini dilakukan oleh bagian administrasi yang dimulai ketika perusahaan menerima kontrak penjualan. Bagian administrasi menginput data term penjualan yang akan dilakukan dan memasukkan data SPH yang terkait. Sistem akan mengecek limit kredit pelanggan, dan apabila total kontrak melebihi dari kredit tersedia maka sistem akan mengenerate status Sales Contract menjadi pending. Untuk itu, diperlukan otorisasi oleh Manajer Keuangan untuk memproses transaksi pending. Bila limit kredit memenuhi maka kontrak dapat dilanjutkan. Sales Contract, detail Sales Contract, SPH, detail SPH, pelanggan, barang, tipe, merek get_last_record, get_last_record_detail, go_to_first_record, go_to_previous_record, go_to_next_record, go_to_last_record, get_last_code, generate_no.sc, get_data_sph, get_limit_kredit_tersedia,

49 148 get_detail_sph, get_kode_barang, calculate_total_harga, calculate_subtotal, calculate_ppn, calculate_grand_total, generate_status, remove, save, print Use Case Objects Functions Tabel 4.38 Use Case Specification Membuat Delivery Order Membuat Delivery Order Kegiatan ini dilakukan oleh bagian administrasi yang diproses setelah Sales Contract disetujui. Pembuatan DO ini dapat dilakukan berkali-kali sesuai kesepakatan dengan pelanggan terhadap pengiriman barang. Bagian administrasi memasukkan data Sales Contract terkait, dan menyesuaikan jumlah barang yang akan dikirim dengan kesepakatan/ permintaan pelanggan. DO, detil DO, SC, SPH, pelanggan, detil SPH, barang, tipe, merek get_last_record, get_last_record_detail, go_to_first_record, go_to_previous_record, go_to_next_record, go_to_last_record, get_data_pelanggan, get_last_code, generate_no.do, get_data_sc, get_detail_sc, remove, save, print Use Case Objects Functions Tabel 4.39 Use Case Specification Membuat Invoice Membuat Invoice Kegiatan ini dilakukan oleh bagian keuangan setelah menerima DO dari bagian administrasi. Bagian keuangan memilih jenis pembayaran yang akan dilakukan pelanggan, yaitu secara tunai atau kredit. Kemudian bagian keuangan memasukkan data invoice dengan memilih DO yang bersangkutan. Sistem secara otomatis akan menghitung subtotal, PPN, dan total harga. Invoice, DO, detil DO, SC, SPH, pelanggan, detil SPH, barang, tipe, merek get_last_record, get_invoice_record_detail, go_to_first_record, go_to_previous_record, go_to_next_record, go_to_last_record, get_data_pelanggan, get_last_code, generate_no.invoice, get_data_do, get_data_sc, calculate_subtotal, calculate_ppn, calculate_grand_total, remove, save, print Use Case Objects Tabel 4.40 Use Case Specification Membuat Faktur Pajak Standar Membuat Faktur Pajak Standar Kegiatan ini dilakukan oleh bagian keuangan yang dapat dilakukan bersamaan dengan pembuatan invoice. Setelah data-data invoice terisi, bagian keuangan dapat memilih cetak invoice atau dan cetak Faktur Pajak Standar. Invoice, DO, detil DO, SC, SPH, pelanggan, detil SPH, barang, tipe, merek

50 149 Functions Use Case Objects Functions get_data_invoice, get_invoice_record_detail, get_data_pelanggan Tabel 4.41 Use Case Specification Membuat Kuitansi Membuat Kuitansi Kegiatan ini dilakukan oleh bagian keuangan ketika menerima pembayaran dari pelanggan. Bagian keuangan menginput data-data pembayaran, meliputi tanggal bayar, cara pembayaran, no. Cek/giro, nama bank, dan jumlah pembayaran. Kemudian bagian keuangan memilih invoice yang akan dibayar, dan sistem akan melakukan perhitungan besarnya sisa tagihan atas invoice dikurangi retur penjualan (bila ada). Kuitansi, detail Kuitansi, Invoice, Surat Retur, DO, SC, SPH, pelanggan get_last_record, get_record_detail, go_to_first_record, go_to_previous_record, go_to_next_record, go_to_last_record, get_data_pelanggan, get_last_code, generate_no.kuitansi, get_jumlah_pembayaran, get_no.invoice, get_data_invoice, get_no.surat_retur, get_data_retur, calculate_tagihan, calculate_total_pembayaran, calculate_sisa, remove, save, print Use Case Objects Functions Tabel 4.42 Use Case Specification Membuar Surat Retur Membuar Surat Retur Kegiatan ini dilakukan oleh bagian administrasi yang dimulai ketika menerima retur dari pelanggan. Bagian administrasi memasukkan data invoice terkait, dan memilih barang yang di-retur, menginput jumlah retur, tipe retur, dan alasan retur barang. Pelanggan dapat memilih untuk melakukan retur dengan tukar barang atau tidak, yang berarti bagi bagian administrasi untuk mendata tipe retur dengan kurangi piutang. Surat Retur, detail Surat Retur, DO, detail DO, SC, SPH, pelanggan, detil SPH, barang, tipe, merek get_last_record, get_record_detail, go_to_first_record, go_to_previous_record, go_to_next_record, go_to_last_record, get_data_pelanggan, get_last_code, generate_no.surat_retur, calculate_total_harga, remove, save, print Tabel 4.43Use Case Specification Membuat DO-Retur

51 150 Use Case Objects Functions Tabel 4.44 Use Case Specification Membuat laporan penjualan Membuat laporan penjualan Kegiatan ini dilakukan oleh bagian keuangan secara berkala atau sewaktu-waktu bila dibutuhkan oleh pihak manajemen. Bagian keuangan memilih jenis sorting laporan penjualan, berdasarkan tanggal, berdasarkan pelanggan, atau berdasarkan barang. Selanjutnya pilih periode awal dan periode akhir, kemudian cetak. Invoice get_data_invoice, get_invoice_record_detail, calculate_total, print Tabel 4.45 Use Case Specification Membuat laporan penerimaan kas Membuat laporan penerimaan kas Kegiatan ini dilakukan oleh bagian keuangan secara berkala atau Use Case sewaktu-waktu bila dibutuhkan oleh pihak manajemen. Bagian keuangan memilih periode awal dan periode akhir, kemudian cetak. Objects Kuitansi Functions get_data_kuitansi, calculate_total, print Use Case Objects Functions Tabel 4.46 Use Case Specification Membuat laporan piutang Membuat laporan piutang Kegiatan ini dilakukan oleh bagian keuangan secara berkala atau sewaktu-waktu bila dibutuhkan oleh pihak manajemen. Bagian keuangan memilih periode awal dan periode akhir, kemudian cetak. Invoice, Surat Retur, Kuitansi get_data_pelanggan, get_data_piutang, calculate_total, print Tabel 4.47 Use Case Specification Membuat laporan analisis umur piutang Membuat laporan analisis umur piutang Kegiatan ini dilakukan oleh bagian keuangan secara berkala atau Use Case sewaktu-waktu bila dibutuhkan oleh pihak manajemen. Bagian keuangan memilih periode awal dan periode akhir, kemudian cetak. Objects Invoice, Kuitansi, Pelanggan Use Case Objects Functions Membuat DO-Retur Kegiatan ini dilakukan oleh bagian administrasi ketika penerimaan retur disertai dengan tukar barang. Bagian administrasi memasukkan data barang dan mencocokkan jumlah barang yang akan dikirim dengan memilih Surat Retur terkait, kemudian menginput tujuan dan alamat pengiriman. DO-Retur, detail DO-Retur, Surat Retur, detail Surat Retur, DO, SC, SPH, detil SPH, barang, tipe, merek get_last_record, get_last_record_detail, go_to_first_record, go_to_previous_record, go_to_next_record, go_to_last_record, get_nama_pelanggan, get_last_code, generate_no.do-r, get_data_surat_retur, get_detail_surat_retur, remove, save, print

52 151 Functions get_data_piutang, get_data_pembayaran, calculate_umur_piutang, calculate_total, print Use Case Objects Functions Tabel 4.48 Use Case Specification Membuat laporan retur Membuat laporan retur Kegiatan ini dilakukan oleh bagian keuangan secara berkala atau sewaktuwaktu bila dibutuhkan oleh pihak manajemen. Bagian keuangan memilih periode awal dan periode akhir, kemudian cetak. Surat Retur get_data_surat_retur, get_data_detail_surat_retur, calculate_total, print Tabel 4.49 Use Case Specification Membuat laporan jurnal penjualan Membuat laporan jurnal penjualan Kegiatan ini dilakukan oleh bagian akuntansi secara berkala atau Use Case sewaktu-waktu bila dibutuhkan oleh pihak manajemen. Bagian akuntansi memilih periode awal dan periode akhir, kemudian cetak. Objects Surat Retur Functions get_data_invoive,calculate_total,print Tabel 4.50 Use Case Specification Membuat laporan jurnal penerimaan kas Membuat laporan jurnal penerimaan kas Kegiatan ini dilakukan oleh bagian akuntansi secara berkala atau Use Case sewaktu-waktu bila dibutuhkan oleh pihak manajemen. Bagian akuntansi memilih periode awal dan periode akhir, kemudian cetak. Objects Kuitansi Functions get_data_kuitansi, calculate_total, print Use Case Objects Functions Tabel 4.51 Use Case Specification Membuat laporan jurnal retur Membuat laporan jurnal retur Kegiatan ini dilakukan oleh bagian akuntansi secara berkala atau sewaktu-waktu bila dibutuhkan oleh pihak manajemen. Bagian akuntansi memilih periode awal dan periode akhir, kemudian cetak. Surat Retur get_data_surat_retur, calculate_total,print Tabel 4.52 Use Case Specification Mengotorisasi transaksi pending Mengotorisasi transaksi pending

53 152 Use Case Objects Functions Kegiatan ini dilakukan oleh manajer keuangan, yang memeriksa limit kredit pelanggan dan kredit tersedia berserta total harga kontrak. Setelah meng-update limit kredit pelanggan, manajer keuangan dapat mengubah status Sales Contract yang pending menjadi proceed. Sales Contract, Pelanggan get_data_sales_contract,get_limit_kredit,get_status,save Use Case Objects Functions Tabel 4.53 Use Case Specification Mengupdate Piutang Mengupdate Piutang Kegiatan ini dilakukan oleh bagian akuntansi untuk mengupdate saldo piutang pelanggan setiap terjadinya transaksi yang mempengaruhi saldo piutang, transaksi yang dimaksud yaitu ketika terjadi penjualan kredit, penerimaan pembayaran atas penjualan kredit. dan penerimaan retur dengan tipe tanpa penukaran barang sehingga perlu mengurangi saldo piutang pelanggan Piutang, Invoice, Kuitansi, Surat Retur get_data_piutang, get_data_penjualan, get_data_pembayaran, get_data_retur Tabel 4.54 Use Case Specification Melakukan penilaian pelanggan Melakukan penilaian pelanggan Kegiatan ini dilakukan oleh manajer keuangan secara berkala, dimana kredibilitas pelanggan dinilai berdasarkan data historis transaksi mereka. Sistem akan menghitung jumlah limit kredit disarankan berdasarkan Use Case masing-masing kriteria penilaian yaitu nilai transaksi per bulan, ketepatan membayar, jumlah retur per bulan, dan lama langganan. Manajer dapat menyetujui limit kredit seperti disarankan sistem atau input sendiri. Objects Pelanggan Functions get_data_pelanggan,get_saldo_piutang,calculate_kredit_poin, calculate_nilai_kredit,calculate_limit_disarankan,save Functions Berikut ini merupakan Function List dari sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma: Tabel 4.55 Function List sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma

54 153 Function Type Complexity Mendata pelanggan read, compute, update medium get_data_pelanggan read simple get_last_record read simple get_piutang read simple calculate_kredit_tersedia compute simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple go_to_last_record read simple get_to_last_code read simple generate_no.pelanggan compute simple calculate_saldo_piutang compute simple get_limit_kredit read simple calculate_lama_langganan compute simple remove update simple save update simple Mendata barang read, compute, update medium get_data_barang read simple get_last_record read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple go_to_last_record read simple get_tipe_barang read simple get_merek_barang read simple calculate_jumlah_tersedia compute simple remove update simple save update simple Mendata tipe read, compute, update medium get_data_tipe read simple get_last_record read simple get_last_code read simple generate_no.urut compute simple remove update simple

55 154 save update simple Mendata merek read, compute, update medium get_data_merek read simple get_last_record read simple get_last_code read simple generate_no.urut compute simple remove update simple save update simple Membuat SPH read, compute, update complex get_last_record read simple get_last_record_detail read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple go_to_last_record read simple get_last_code read simple generate_no.sph compute simple get_tipe_barang read simple get_merek_barang read medium get_nama_barang read medium get_kode_barang read medium calculate_total_harga compute simple calculate_subtotal compute simple calculate_ppn compute simple calculate_grand_total compute simple remove update simple save update medium print read simple Membuat Sales Contract read, compute, update complex get_last_record read simple get_last_record_detail read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple

56 155 go_to_last_record read simple get_last_code read simple generate_no.sc compute simple get_data_sph read medium get_limit_kredit_tersedia read medium get_detail_sph read medium get_kode_barang read medium calculate_total_harga compute simple calculate_subtotal compute simple calculate_ppn compute simple calculate_grand_total compute simple generate_status read medium remove update simple save update medium print read simple Membuat Delivery Order read, compute, update complex get_last_record read simple get_last_record_detail read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple go_to_last_record read simple get_last_code read simple generate_no.do compute simple get_data_sc read medium get_detail_sc read medium remove update simple save update medium print read simple Membuat Invoice read, compute, update complex get_last_record read simple get_record_detail read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple go_to_last_record read simple

57 156 get_last_code read simple generate_no.invoice compute simple get_data_do read medium get_data_sc read medium calculate_subtotal compute simple calculate_ppn compute simple calculate_grand_total compute simple remove update simple save update medium print read simple Membuat Kuitansi read, compute, update complex get_last_record read simple get_record_detail read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple go_to_last_record read simple get_last_code read simple generate_no.kuitansi compute simple get_jumlah_pembayaran read medium get_no.invoice read medium get_data_invoice read medium get_no.surat_retur read medium get_data_retur read medium calculate_tagihan compute simple calculate_total_pembayaran compute simple calculate_sisa compute simple remove update simple save update medium print read simple Membuat Surat Retur read, compute, update complex get_last_record read simple get_record_detail read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple

58 157 go_to_last_record read simple get_last_code read simple generate_no.surat_retur compute simple get_data_do read medium calculate_total_harga compute simple remove update simple save update medium print read simple Membuat DO-Retur read, compute, update complex get_last_record read simple get_last_record_detail read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple go_to_last_record read simple get_last_code read simple generate_no.do-r compute simple get_data_surat_retur read medium get_detail_surat_retur read medium remove update simple save update medium print read simple Membuat laporan penjualan read, compute complex get_data_invoice read medium calculate_total compute medium print read simple Membuat laporan penerimaan kas read, compute complex get_data_kuitansi read simple get_data_detail_kuitansi read simple calculate_total compute medium print read simple Membuat laporan piutang read, compute complex get_data_piutang read medium calculate_total compute medium print read simple

59 158 Membuat laporan analisis umur piutang read, compute complex get_data_piutang read medium get_data_pembayaran read medium calculate_umur_piutang compute medium calculate_total compute medium print read simple Membuat laporan retur read, compute complex get_data_surat_retur read simple get_data_detail_surat_retur read simple calculate_total compute medium print read simple Membuat laporan jurnal penjualan read, compute complex get_data_invoive read medium calculate_total compute medium print read simple Membuat laporan jurnal penerimaan kas read, compute complex get_data_kuitansi read medium calculate_total compute medium print read simple Membuat laporan jurnal retur read, compute complex get_data_surat_retur read medium calculate_total compute medium print read simple Mengotorisasi transaksi pending read, update complex get_data_sales_contract read medium get_limit_kredit read medium get_status read medium save update medium Melakukan penilaian pelanggan read, compute, update very complex get_data_pelanggan read medium

60 159 get_saldo_piutang read medium calculate_kredit_poin compute medium calculate_nilai_kredit compute complex calculate_limit_disarankan compute simple save update medium Mengupdate piutang read, update complex get_data_piutang update medium get_data_pembayaran read medium get_data_penjualan read medium get_data_retur read medium User Interface Sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma dirancang dengan user friendly dan menggunakan Bahasa Indonesia dan Bahasa Inggris yang umum digunakan. Berikut adalah gambaran desain user interface sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma Dialogue Style Setiap user interface memiliki sejumlah windows yang dapat digunakan untuk mendukung pencatatan transaksi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma. Selain itu, sistem ini juga menyediakan fasilitas pencetakan informasi yang dibutuhkan oleh pihak-pihak yang berkepentingan dalam perusahaan. Untuk lebih jelasnya, daftar windows interface dan hasil pencetakaannya dapat dilihat pada tabel 4.56 berikut.

61 160 Tabel 4.56 Dialogue Style User Interface Windows Printouts Login Menu Utama File Change Password Log out Exit Master Pelanggan Barang Tipe Merek Transaction Surat Penawaran Harga Surat Penawaran Harga Sales Contract Sales Contract Delivery Order Delivery Order Invoice Invoice Kuitansi Kuitansi Surat Retur Surat Retur Delivery Order-Retur Delivery Order-Retur Transaksi Kontrak Pending Daftar Piutang Penilaian Pelanggan Report Penjualan Laporan Penjualan Penerimaan Kas Laporan Penerimaan Kas Piutang Laporan Piutang Analisis Umur Piutang Laporan Analisis Umur Piutang Retur Laporan Retur Journal Jurnal Penjualan Laporan Jurnal Penjualan Jurnal Penerimaan Kas Laporan Jurnal Penerimaan Kas Jurnal Retur Laporan Jurnal Retur Navigation Diagram

62 161 Gambar berikut adalah Navigation Diagram yang menyediakan overview windows user interface dan hubungan antar windows beserta penjelasan dari sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma, dapat dilihat pada gambar 4.65.

63 Gambar 4.65 Navigation Diagram 162

64 User Interface Gambar 4.66 Window Login Pertama-tama setiap user harus melakukan login terlebih dahulu dengan mengentri user name dan password yang sesuai. User menekan tombol OK, kemudian sistem mengecek hak akses user berdasarkan posisinya. Bila ingin membatalkan proses login, user dapat menekan tombol Cancel. Gambar 4.67 Window Change Password Tiap user juga dapat melakan pengubahan password nya yang direkomendasikan oleh sistem untuk diganti setiap beberapa bulan sekali untuk alasan keamanan. User menginput password sekarang, kemudian menginput password baru sebanyak dua kali untuk konfirmasi. Setelah menekan tombol OK, sistem akan mengupdate data password baru ke dalam database.

65 164 Gambar 4.68 Window Main Menu Setelah melakukan login, tampilan user adalah Main Menu dimana submenu yang dapat diakses user berbeda-beda tergantung dari posisi jabatan user. Dalam hal ini terdapat lima Main Menu antara lain File, Master, Transaction, Report, dan Journal. Di main menu ini, pada menu File, tiap user dapat melakukan Log Out dan Change Password. Bagian administrasi dapat mengakses ke menu Master: Pelanggan, Barang, Tipe, dan Merek. Selain itu bagian administrasi juga memiliki akses pada menu Transaksi: Surat Penawaran Harga, Sales Contract, Delivery Order, Surat Retur, dan Delivery Order-Retur.

66 165 Bagian keuangan memiliki hak akses pada menu Transaksi: Invoice, Kuitansi, dan Daftar Piutang untuk mengecek piutang pelanggan yang jatuh tempo setiap harinya. Tugas dan tanggung jawab bagian keuangan yang mencakup pembuatan laporan memberikan akses bagian keuangan pada semua menu Report, antara lain: Laporan Penjualan, Laporan Penerimaan Kas, Laporan Piutang, Laporan Analisis Umur Piutang, dan Laporan Retur. Bagian akuntansi hanya memiliki akses ke menu Journal, yang antara lain: Laporan Jurnal Penjualan, Laporan Jurnal Penerimaan Kas, dan Laporan Jurnal Retur. Sedangkan manajer keuangan mempunyai akses menu Transaksi yang meliputi: Transaksi Kontrak Pending dan Penilaian Pelanggan. Gambar 4.69 Window Master Pelanggan

67 166 Window ini diakses oleh bagian administrasi untuk menambahkan data pelanggan baru ke dalam database pelanggan, sehingga pada saat mulai proses penjualan, data pelanggan dapat tampil secara generate oleh sistem. Pendataan pelanggan meliputi deskripsi nama, no. NPWP, alamat, kota, telp, fax, data piutang, contact person, dan registrasi pelanggan. Selain mendaftarkan pelanggan baru, bagian administrasi dapat meng-update data pelanggan yang sudah ada. Dalam hal ini pemakaian fasilitas tombol navigasi First, Previous, Next, Last, dan Search dimanfaatkan untuk mencari data pelanggan yang diinginkan. Pencarian pelanggan yang dimaksud antara lain berdasarkan kode pelanggan, nama pelanggan, atau kota. Setelah melakukan penambahan atau pengubahan data pelanggan, penyimpanan data pelanggan baru atau perubahannya dilakukan dengan menekan tombol Save. Untuk membatalkan, dapat dilakukan dengan menekan tombol Cancel. Bila data pelanggan perlu dihapus, dapat menekan tombol Delete.

68 167 Gambar 4.70 Window Master Barang Window ini diakses oleh bagian administrasi untuk menambahkan data barang baru yang dijual oleh perushaan. Pendataan barang ini meliputi input kode barang dengan ketentuan tiga karakter pertama mendeskripsikan tipe barang, tiga karakter kedua mendeskripsikan merek barang, tiga karakter selanjutnya mendeskripsikan rincian barang dengan tipe bersangkutan, dan empat karakter angka terakhir mendesksipsikan urutan rincian barang. User memilih tipe barang yang akan didata, apabila tipe barang dimaksud belum ada, perlu dilakukan penambahan tipe barang dengan menekan tombol Add Tipe, yang menunjuk pada Window Master Tipe. Hal yang sama berlaku untuk pendataan merek barang yang belum ada, dimana tombol Add Merek menunjuk pada Window Master Merek.

69 168 Selanjutnya user menginput nama barang, pilih satuan (kilogram, meter, atau buah), dan harga barang. Tanggal saldo awal dan saldo awal hanya dilakukan sekali ketika proses konversi sistem lama ke sistem baru untuk mendata jumlah stok barang terakhir sebelum sistem baru diimplementasi. Sedangkan perhitungan jumlah barang tersedia dilakukan oleh sistem. Selain pendataan barang baru, edit atau update data barang dilakukan dengan menekan tombol Edit. Data barang yang akan di-edit atau di-update dapat dipilih berdasarkan kode barang, tipe, atau merek barang. User mengentri keyword pencarian dan menekan tombol Find. Pencarian data barang dapat juga dilakukan menggunakan fasilitas navigasi First, Previous, Next, dan Last. Setelah melakukan penambahan atau pengubahan data barang, penyimpanan data barang baru atau perubahannya dilakukan dengan menekan tombol Save. Untuk membatalkan, dapat dilakukan dengan menekan tombol Cancel. Bila data barang perlu dihapus, user dapat menekan tombol Delete. Gambar 4.71 Window Master Tipe

70 169 Window ini diakses oleh bagian administrasi yang dapat dilakukan bersamaan ketika pendataan barang baru hasil penunjukkan tombol Add Tipe di Master Barang atau dari Main Menu: Master Tipe. Penambahan tipe baru dilakukan dengan menekan tombol Add, dimana nomor tipe di-generate oleh sistem, kemudian user menginput nama tipe. Untuk update data tipe, dilakukan dengan menekan tombol Edit. Setelah menambah atau mengubah data tipe, penyimpanan atau perubahannya diproses dengan menekan tombol Save. Untuk membatalkan, dilakukan dengan menekan tombol Cancel. Bila data tipe perlu dihapus, user dapat menekan tombol Delete. Gambar 4.72 Window Master Merek Window ini diakses oleh bagian administrasi yang dapat dilakukan bersamaan ketika pendataan barang baru hasil penunjukkan tombol Add Merek di Master Barang atau dari Main Menu: Master Merek. Penambahan merek baru dilakukan dengan menekan tombol Add, dimana nomor merek di-generate oleh system setelah user memilih tipe yang diingnkan, kemudian user menginput nama merek.

71 170 Untuk update data merek, dilakukan dengan menekan tombol Edit. Setelah menambah atau mengubah data merek, penyimpanan atau perubahannya diproses dengan menekan tombol Save. Untuk membatalkan, dilakukan dengan menekan tombol Cancel. Bila data merek perlu dihapus, user dapat menekan tombol Delete. Gambar 4.73 Window Transaksi Surat Penawaran Harga Window ini diakses oleh bagian administrasi ketika memulai proses penawaran harga kepada pelanggan. Untuk membuat Surat Penawaran Harga baru, user menekan tombol Add New dan memilih nama pelanggan yang akan ditawarkan. Apabila nama pelanggan belum terdaftar, pendataan pelanggan baru dilakukan dengan menekan tombol New yang menunjuk pada Master Pelanggan.

72 171 Selanjutnya, user memilih tangal akhir berlaku, dan mendata barang yang ditawarkan. Pertama-tama, user memilih tipe barang, kemudian merek yang tampil yaitu merek yang sesuai dengan tipe. Kemudian user memilih merek, dan nama barang yang tampil sesuai tipe dan merek. Pemilihan barang dilanjutkan dengan memilih nama barang, yang menghasilkan kode barang, jumlah barang tersedia, dan harga barang standar ter-generate oleh sistem. User mengentri jumlah pesanan dan sistem menghitung total harga, subtotal, PPN, dan total harga. Setelah mendata penawaran, user menekan tombol Save dan menyimpan data surat penawaran baru. Sistem juga mengecek ketersediaan barang, apabila jumlah tidak mencukupi, status SPH yaitu pending. Selain pendataan baru, edit atau update data SPH dilakukan dengan menekan tombol Edit. Data SPH yang akan di-edit atau di-update dapat dipilih menggunakan fasilitas navigasi First, Previous, Next, dan Last. Setelah melakukan penambahan atau pengubahan data SPH, penyimpanan data SPH baru atau perubahannya dilakukan dengan menekan tombol Save. Untuk membatalkan, dapat dilakukan dengan menekan tombol Cancel. Bila data SPH perlu dihapus, user dapat menekan tombol Delete.

73 172 Gambar 4.74 Window Transaksi Sales Contract Window ini diakses oleh bagian administrasi ketika mendata kontrak berdasarkan pesanan pelanggan. Untuk membuat Sales Contract baru, user dapat menekan tombol Add New dan mulai memasukkan data kontrak. Pertama, user memilih No. SPH yang diinginkan kemudian sistem men-generate data pelanggan beserta data penawaran bersangkutan. User dapat mengentri durasi pembayaran, jumlah barang yang dipesan, dan mengubah harga satuan. Kemudian sistem menghitung total harga, subtotal, PPN, dan total harga. User harus mengecek limit kredit pelanggan terlebih dahulu dengan menekan tombol Cek Limit, apabila total harga kontrak melebihi limit kredit tersedia, status Sales Contract yaitu pending.

74 173 Selain pendataan baru, edit atau update data Sales Contract dilakukan dengan menekan tombol Edit. Data Sales Contract yang akan di-edit atau di-update dapat dipilih menggunakan fasilitas navigasi First, Previous, Next, dan Last. Setelah melakukan penambahan atau pengubahan data Sales Contract, penyimpanan data Sales Contract baru atau perubahannya dilakukan dengan menekan tombol Save. Untuk membatalkan, dapat dilakukan dengan menekan tombol Cancel. Bila data Sales Contract perlu dihapus, user dapat menekan tombol Delete. Gambar 4.75 Window Transaksi Delivery Order

75 174 Window ini diakses oleh bagian administrasi ketika pengiriman barang akan dilakukan. Untuk membuat Delivery Order baru, user dapat menekan tombol Add New kemudian memasukkan data pengiriman. User memilih No. Sales Contract yang diinginkan kemudian sistem men-generate data pelanggan beserta deskripsi barang yang ada di data kontrak bersangkutan. Selanjutnya user mengentri pihak pengiriman yang dituju dan alamatnya. Selain itu, user dapat mengentri jumlah barang yang dikirim. Setelah mendata pengiriman, user menekan tombol Save untuk menyimpan data pengiriman tersebut. Selain pendataan baru, edit atau update data Delivery Order dilakukan dengan menekan tombol Edit. Data Delivery Order yang akan di-edit atau di-update dapat dipilih menggunakan fasilitas navigasi First, Previous, Next, dan Last. Setelah melakukan penambahan atau pengubahan data Delivery Order, penyimpanan data Delivery Order baru atau perubahannya dilakukan dengan menekan tombol Save. Untuk membatalkan, dapat dilakukan dengan menekan tombol Cancel. Bila data Delivery Order perlu dihapus, user dapat menekan tombol Delete.

76 175 Gambar 4.76 Window Transaksi Invoice Window ini diakses oleh bagian keuangan untuk membuat Invoice. Ketika membuat Invoice baru, user menekan tombol Add New kemudian memasukkan data penjualan berdasarkan pengiriman yang dilakukan. User memilih jenis pembayaran, apakah secara tunai atau kredit, kemudian memilih tanggal jatuh tempo pembayaran. Selanjutnya user memilih No. Delivery Order yang diinginkan dan sistem mengenerate data pelanggan beserta deskripsi barang sesuai detail pengiriman yang ada. Selain data Delivery Order, sistem membaca data Sales Contract terkait dan sistem menghitung total harga, subtotal, PPN, dan total harga.

77 176 Selain pendataan baru, edit atau update data Invoice dilakukan dengan menekan tombol Edit. Data Invoice yang akan di-edit atau di-update dapat dipilih menggunakan fasilitas navigasi First, Previous, Next, dan Last. Setelah melakukan penambahan atau pengubahan data Invoice, penyimpanan data Invoice baru atau perubahannya dilakukan dengan menekan tombol Save. Untuk membatalkan, dapat dilakukan dengan menekan tombol Cancel. Bila data Invoice perlu dihapus, user dapat menekan tombol Delete. Gambar 4.77 Window Form Print Window ini tampil ketika user menekan tombol Print pada Winndow Invoice. Berdasarkan data Invoice dan Faktur Pajak Standar yang sama, user dapat memilih pencetakan surat sesuai kebutuhan.

78 177 Gambar 4.78 Window Transaksi Kuitansi Window ini diakses oleh bagian keuangan ketika menerima pembayaran dari pelanggan. Untuk membuat Kuitansi baru, user menekan tombol Add New kemudian memasukkan data pembayaran berdasarkan penjualan yang terjadi. User memilih No. invoice, kemudian sistem membaca tanggal jatuh tempo, serta menghitung total invoice, total retur dan total tagihan yang terkait. Selanjutnya user mengentri jumlah pembayaran dan sistem menghitung sisa tagihan. User juga memilih cara pembayaran, mengentri No. Cek/giro bila ada, dan nama bank bersangkutan.

79 178 Selain pendataan baru, edit atau update data Kuitansi dilakukan dengan menekan tombol Edit. Data Kuitansi yang akan di-edit atau di-update dapat dipilih menggunakan fasilitas navigasi First, Previous, Next, dan Last. Setelah melakukan penambahan atau pengubahan data Kuitansi, penyimpanan data Kuitansi baru atau perubahannya dilakukan dengan menekan tombol Save. Untuk membatalkan, dapat dilakukan dengan menekan tombol Cancel. Bila data Kuitansi perlu dihapus, user dapat menekan tombol Delete. Gambar 4.79 Window Transaksi Surat Retur Window ini diakses oleh bagian administrasi ketika menerima retur dari pelanggan. Untuk membuat Surat Retur baru, user menekan tombol Add New kemudian memasukkan data retur yang terjadi. User memilih No. Invoice yang bersangkutan dan sistem men-generate data pelanggan serta penjualan terkait. Selanjutnya user memilih

80 179 barang yang diretur, dan mengentri jumlahnya. User juga mengentri tipe retur yang terjadi dan memberi catatan mengenai alasan retur di kolom keterangan. Selain pendataan baru, edit atau update data Surat Retur dilakukan dengan menekan tombol Edit. Data Surat Retur yang akan di-edit atau di-update dapat dipilih menggunakan fasilitas navigasi First, Previous, Next, dan Last. Setelah melakukan penambahan atau pengubahan data Surat Retur, penyimpanan data Surat Retur baru atau perubahannya dilakukan dengan menekan tombol Save. Untuk membatalkan, dapat dilakukan dengan menekan tombol Cancel. Bila data Surat Retur perlu dihapus, user dapat menekan tombol Delete. Gambar 4.80 Window Transaksi Delivery Order-Retur

81 180 Window ini diakses oleh bagian administrasi ketika pengiriman barang retur akan dilakukan. Untuk membuat Delivery Order-Retur baru, user dapat menekan tombol Add New kemudian memasukkan data pengiriman. User memilih No. Surat Retur yang diinginkan kemudian sistem men-generate data pelanggan beserta deskripsi barang yang ada di data retur bersangkutan. Selanjutnya user mengentri pihak pengiriman yang dituju dan alamatnya. Selain itu, user dapat mengentri jumlah barang yang dikirim. Setelah mendata pengiriman, user menekan tombol Save untuk menyimpan data pengiriman tersebut. Selain pendataan baru, edit atau update data Delivery Order-Retur dilakukan dengan menekan tombol Edit. Data Delivery Order-Retur yang akan di-edit atau diupdate dapat dipilih menggunakan fasilitas navigasi First, Previous, Next, dan Last. Setelah melakukan penambahan atau pengubahan data Delivery Order-Retur, penyimpanan data Delivery Order-Retur baru atau perubahannya dilakukan dengan menekan tombol Save. Untuk membatalkan, dapat dilakukan dengan menekan tombol Cancel. Bila data Delivery Order-Retur perlu dihapus, user dapat menekan tombol Delete.

82 181 Gambar 4.81 Window Daftar Piutang Jatuh Tempo Window ini diakses oleh bagian keuangan setiap harinya, sebagai alat bantu user dalam memerikasa Invoice yang jatuh tempo guna melakukan penagihan. Form ini dapat diakses dari menu utama setelah user melakukan login. User disajikan informasi mengenai perhitungan kapan jatuh tempo oleh sistem. Dalam window ini user tidak melakukan pendataan apapun, sehingga perintah yang dapat dilakukan user hanya mengakses window atau keluar dengan menekan Close.

83 182 Gambar 4.82 Window Transaksi Pending Window ini diakses oleh Manajer Keuangan untuk melakukan otorisasi pada transaksi kontrak dengan status pending. Form ini dapat diakses dari menu utama di bagian Transaksi. User dapat melihat No. Sales Contract, tanggal, nama pelanggan bersangkutan, limit kredit dan kredit tersedia. User dapat melakukan penilaian pelanggan untuk melakukan pengubahan limit kredit. Setelah itu, user memilih mengotorisasi transaksi pending, baik dengan status Reject atau Proceed. Dengan status Sales Contract yang Proceed akan memungkinkan dilakukannya pengiriman barang dan penjualan. Kemudian user menekan tombol Save untuk menyimpan record dan meng-update status Sales Contract. Untuk membatalkan dapat menekan tombol Cancel.

84 183 Gambar 4.83 Window Penilaian Pelanggan Window ini diakses oleh Manajer Keuangan untuk dalam melakukan penilaian terhadap kredibilitas pelanggan. User memilih nama pelanggan yang akan dinilai, kemudian sistem membaca kode pelanggan, limit kredit, saldo piutang, dan kredit tersedia. Kemudian user mengentri nilai kriteria penilaian limit kredit pelanggan, antara lain nilai transaksi per bulannya, ketepatan membayar, jumlah retur, dan lama langganan. Dengan menekan tombol Hitung Limit, sistem melakukan kalkulasi hingga jumlah limit kredit disarankan. Nilai jumlah limit kredit disarankan adalah default nilai limit kredit pelanggan yang dapat diubah oleh user berwenang, dalam hal ini manajer keuangan.

85 184 Setelah penilaian selesai, user menekan tombol Save untuk menyimpan record, dan menekan tombol Cancel untuk membatalkan. Gambar 4.84 Window Laporan Penjualan Window ini diakes oleh bagian keuangan yang secara berkala atau sesuai kebutuhan melakukan pencetakan Laporan Penjualan. User memilih penyusunan laporan berdasarkan tanggal, pelanggan, atau barang. Kemudian user memilih periode awal dan periode akhir laporan yang diinginkan. Setelah itu, user menekan tombol Cetak untuk mencetak Laporan.

86 185 Gambar 4.85 Window Laporan Penerimaan Kas Window ini diakes oleh bagian keuangan yang secara berkala atau sesuai kebutuhan melakukan pencetakan Laporan Penerimaan Kas. User memilih periode awal dan periode akhir laporan yang diinginkan. Setelah itu, user menekan tombol Cetak untuk mencetak Laporan. Gambar 4.86 Window Laporan Piutang Window ini diakes oleh bagian keuangan yang secara berkala atau sesuai kebutuhan melakukan pencetakan Laporan Piutang. User memilih periode awal dan

87 186 periode akhir laporan yang diinginkan. Setelah itu, user menekan tombol Cetak untuk mencetak Laporan. Gambar 4.87 Window Laporan Analisis Umur Piutang Window ini diakes oleh bagian keuangan yang secara berkala atau sesuai kebutuhan melakukan pencetakan Laporan Analisis Umur Piutang. User memilih periode awal dan periode akhir laporan yang diinginkan. Setelah itu, user menekan tombol Cetak untuk mencetak Laporan. Gambar 4.88 Window Laporan Retur Penjualan

88 187 Window ini diakes oleh bagian keuangan yang secara berkala atau sesuai kebutuhan melakukan pencetakan Laporan Retur Penjualan. User memilih periode awal dan periode akhir laporan yang diinginkan. Setelah itu, user menekan tombol Cetak untuk mencetak Laporan. Gambar 4.89 Window Laporan Jurnal Penjualan Window ini diakes oleh bagian akuntansi yang secara berkala atau sesuai kebutuhan melakukan pencetakan Laporan Jurnal Penjualan. User memilih periode awal dan periode akhir laporan yang diinginkan. Setelah itu, user menekan tombol Cetak untuk mencetak Laporan. Gambar 4.90 Window Laporan Jurnal Penerimaan Kas

89 188 Window ini diakes oleh bagian akuntansi yang secara berkala atau sesuai kebutuhan melakukan pencetakan Laporan Jurnal Penerimaan Kas. User memilih periode awal dan periode akhir laporan yang diinginkan. Setelah itu, user menekan tombol Cetak untuk mencetak Laporan. Gambar 4.91 Window Laporan Jurnal Retur Window ini diakes oleh bagian akuntansi yang secara berkala atau sesuai kebutuhan melakukan pencetakan Laporan Jurnal Retur. User memilih periode awal dan periode akhir laporan yang diinginkan. Setelah itu, user menekan tombol Cetak untuk mencetak Laporan.