BAB 4 PERANCANGAN SISTEM INFORMASI AKUNTANSI PENJUALAN, PIUTANG, DAN PERSEDIAAN PADA PT. NUSANTARA SURYA SAKTI 4.1. Analysis Document 4.1.1. The Task 4.1.1.1. Purpose Pengembangan Sistem Informasi Penjualan, Piutang, dan Persediaan ini bertujuan untuk mendukung pencatatan dan pengendalian internal perusahaan atas aktivitas transaksi yang melibatkan arus persediaan serta penjualan kredit dimulai dari penerimaan barang, penawaran barang dari pelanggan, perjanjian atas penjualan, penjualan barang, pengeluaran barang, pengiriman barang, sampai pada penerimaan kas. 4.1.1.2. System Definition Suatu Sistem Informasi Akuntansi yang berfokus pada penjualan kredit dan pengendalian persediaan yang dapat membuat aliran komunikasi mengenai transaksi dapat berlangsung secara lebih lancar dan akurat guna memaksimalkan kinerja tiap fungsi yang terkait di dalamnya serta sebagai salah satu alat yang dapat meningkatkan kualitas sistem pengendalian internal perusahaan serta sebagai sumber informasi yang cepat, tepat, dan mudah diperoleh oleh pimpinan bagi perbaikan kualitas pengambilan keputusan. Sistem ini menggunakan arsitektur client-server, dimana setiap client menggunakan PC Windows dan akan dihubungkan dengan server dengan
103
menggunakan LAN perusahaan, mengingat lokasi client yang berjauhan. Karakteristik lebih jelas akan Sistem Informasi Akuntansi ini dijabarkan dengan menggunakan FACTOR Criteria sebagai berikut: Tabel 4.1. Factor Criteria Functionality
Application Domain Condition
Technology Object
Responsibility
Pendukung dan pengendali dalam prosedur transaksi penjualan kredit, piutang, serta pengendalian persediaan yang akan menghasilkan informasi yang cepat, tepat, dan mudah diakses oleh pihak yang terkait. UMC Head, UMC Sales, UMC Warehouse, Mechanic, Delivery, Finance, dan Accounting. Sistem ini dihasilkan sebagai suatu usulan pemecahan masalah yang terjadi dalam perusahaan atas dasar analisis yang dilakukan pada prosedur sistem penjualan kredit dan pengendalian piutang yang selama ini diterapkan perusahaan. Beberapa Personal Computer, Jaringan LAN yang menghubungkan tiap PC dengan server, serta peralatan pendukung yaitu printer. • Karyawan; • Barang; • Pelanggan; • Penjualan; • Piutang; • Penerimaan Barang; • Pengeluaran Barang; • Pengiriman Barang; • Pembayaran; • Pengecekan Fisik Barang; Menghasilkan informasi yang akurat serta up-to-date yang akan meningkatkan kualitas pengambilan keputusan sekaligus sebagai alat pendukung sistem pengendalian internal perusahaan dan mendukung kinerja yang lebih efektif dan efisien para personil yang terkait.
104
4.1.1.3. Context
Gambar 4.1.
Rich picture dari sistem informasi akuntansi penjualan, piutang, dan persediaan yang diusulkan
Keterangan: STPB: Surat Tanda Penerimaan Barang SPK: Surat Penawaran Konsumen SPP: Surat Perjanjian Penjualan SPB: Surat Pengeluaran Barang FP: Faktur Penjualan SJ: Surat Jalan SBPK: Surat Bukti Penerimaan Kas
105
4.1.1.3.1. Problem-Domain 1.
Motor bekas yang telah ditarik oleh perusahaan pada gudang motor bekas akan dicek oleh Mechanic yang berada di bawah bagian Recondition Specialist .Suku cadang yang dilepas dari motor kemudian dikuantifikasi dan Mechanic akan membuat dan mencetak suatu Checklist yang akan diserahkan pada UMC Warehouse Staff bersamaan dengan suku cadang. Setelah dicocokkan, UMC Warehouse Staff kemudian akan membuat Surat Tanda Penerimaan Barang (STPB) berdasarkan Checklist yang diterimanya. Sistem kemudian mencetak STPB sebanyak tiga rangkap yang akan diotorisasi oleh UMC Warehouse Head. Rangkap ke-1 kemudian akan diberikan pada Recondition Specialist Head, rangkap ke-2 didistribusikan kepada Finance Department, sedangkan rangkap ke-3 akan disimpan oleh Mechanic. Adapun STPB rangkap ke-1 oleh Recondition Specialist Head akan dianalisa kecocokannya dengan jumlah pembelian suku cadang baru yang akan dipasang pada motor bekas yang akan dijual sedangkan rangkap
ke-2 akan dianalisa oleh Finance Department
kesesuaiannya dengan jumlah motor yang ditarik pada periode tertentu. Mechanic memiliki kewenangan untuk membuat item barang baru apabila item barang yang masuk belum ada pada master barang. Namun, pemutakhiran atas saldo barang tersedia baru terjadi saat STPB
106
tersimpan. Hak untuk menghapus atu mengubah transaksi yang telah diinput ada pada UMC Warehouse Head. 2.
Customer yang berniat untuk membeli suku cadang akan berhubungan langsung dengan Staff UMC Sales, yaitu Salesperson UMC, yang akan mengajak calon pembeli untuk melihat kondisi barang yang tersedia. Apabila customer tersebut ingin mengajukan penawaran, maka Salesperson akan segera mengecek status dari customer tersebut di database pelanggan. Apabila ternyata informasi mengenai customer tersebut tidak ada, maka customer akan diminta untuk mengisi formulir yang berisi data-data pelanggan. Salesperson kemudian akan mengentri informasi tersebut ke dalam database pelanggan dan Finance Department akan menganalisa serta menentukan limit kredit dari pelanggan baru. Setelah penentuan limit kredit selesai dan seluruh data pelanggan lengkap, maka pelanggan dapat mengajukan penawaran harga atas barang yang akan dibeli. Salesperson yang menangani transaksi akan mengentri informasi mengenai item, kuantitas, serta harga yang dikehendaki berikut Salesperson yang bertanggung jawab atas SPK tersebut. Salesperson akan mencetak SPK dua rangkap dimana rangkap ke-1 akan diberikan kepada pelanggan dan rangkap ke-2 akan diberikan pada UMC Sales Head untuk dianalisa. Salesperson kemudian akan mengkonfirmasi UMC Sales Head untuk akan keberadaan Surat Penawaran Harga tersebut. SPK memiliki tanggal efektif dimana SPK tersebut akan menjadi tidak valid apabila ternyata tidak ada kelanjutan
107
transaksi, dalam hal ini tidak dibuatnya Surat Perjanjian Penjualan yang dapat disebabkan oleh tidak tercapainya kesepakatan harga antara perusahaan dan pelanggan. 3.
UMC Sales Head menganalisa spesifikasi penawaran termasuk kelayakan harga atas penawaran yang diajukan pelanggan sesuai dengan keterangan singkat mengenai kondisi barang. UMC Sales Head dapat langsung menyetujui harga penawaran dari pelanggan apabila harga penawaran berada di atas harga pasar. Apabila penawaran pelanggan berada di bawah harga pasar dan dianggap tidak wajar, UMC Sales Head akan mengutus Salesperson untuk melakukan negosiasi dengan memberikan
batas
harga
penawaran
minimum
yang
disetujui.
Salesperson kemudian akan mengkonfirmasi konsumen dan membuat harga kesepakatan baru. Setelah harga yang disepakati tercapai, Salesperson akan membuat Surat Perjanjian Penjualan. Sistem kemudian akan menampilkan saldo limit kredit yang masih dimiliki oleh pelanggan. Apabila ternyata jumlah transaksi melampaui jumlah limit kredit yang tersisa, maka sistem akan menolak untuk melanjutkan transaksi dan memberikan message pada Salesperson bahwa transaksi tidak dapat diproses lebih lanjut. Namun apabila ternyata limit kredit pelanggan masih cukup, Salesperson akan membuat Surat Perjanjian Penjualan dua rangkap dan diotorisasi oleh UMC Sales Head dimana rangkap ke-1 akan diberikan kepada pelanggan dan rangkap ke-2 akan disampaikan pada kepala gudang.
108
4.
Berdasarkan
SPP
yang
diterima,
Kepala
gudang
kemudian
memerintahkan UMC Warehouse Staff untuk menyiapkan barang sesuai pada SPP dan membuat Surat Pengeluaran Barang yang akan diotorisasi oleh Kepala Gudang. Sistem kemudian mencetak Surat Pengeluaran Barang dua rangkap. SPB yang telah diotorisasi tersebut kemudian akan didistribusikan dimana rangkap ke-1 akan diberikan ke Bagian Penjualan sedangkan SPB rangkap ke-2 akan disimpan untuk menunggu diserahkan pada Bagian Pengiriman. SPB akan secara otomatis mengurangi kuantitas barang yang telah dikeluarkan dari gudang pada saldo barang tersedia. 5.
Berdasarkan SPB, Salesperson kemudian akan membuat Faktur Penjualan. Pengecekan atas limit kredit pelanggan kembali dilakukan di pada saat FP akan disimpan. Hal tersebut dilakukan dengan pertimbangan bahwa tiap pelanggan dapat memiliki lebih dari 1 SPP, dan limit kredit pelanggan baru akan berkurang saat FP tersimpan. Apabila salah satu SPP pelanggan diproses terlebih dahulu disbanding yang lain, aka nada kemungkinan bahwa piutang pelanggan akan melebihi saldo limit kredit. Sistem akan mencetak Faktur Penjualan dua rangkap yang didistribusikan pada Bagian Gudang. Bagian Gudang kemudian mendistribusikan Faktur Penjualan, SPB rangkap ke-2, dan barang
yang
bersangkutan
kepada
bagian
pengiriman.
Bagian
Pengiriman kemudian akan membuat Surat Jalan berdasarkan SPB pada tanggal tepat dimana barang tersebut didistribusikan kepada pelanggan.
109
Surat Jalan akan dicetak sebanyak dua rangkap. Pelanggan akan dimintai tanda tangan atas seluruh dokumen yang dibawa oleh Staf Pengiriman. Staf pengiriman akan menyerahkan Faktur Penjualan rangkap ke-1 yang sekaligus berfungsi sebagai Faktur Pajak Standar serta Surat Jalan rangkap ke-2 pada pelanggan. Selanjutnya, Faktur Penjualan rangkap ke-2 akan diberikan pada Finance Department 6.
Pelanggan akan membayar tagihan atas pembelian barang berdasarkan Faktur Penjualan yang telah diserahkan bersamaan dengan barang. Pelanggan dapat membayar dengan cara transfer langsung ke rekening perusahaan ataupun dengan cek/giro. Apabila dengan cara transfer, pada hari jatuh tempo atau sebelum jatuh tempo, bukti transfer akan diberikan ke Finance Department dan Finance Department kemudian akan membuat Surat Bukti Penerimaan Kas sedangkan apabila pelanggan membayar dengan cek/giro, pada saat perusahaan menerima konfirmasi bahwa cek/giro tersebut telah masuk ke rekening perusahaan maka Finance Department baru akan membuat SBPK. SBPK akan dicetak sebanyak dua rangkap. Rangkap ke-1 akan diserahkan pada pelanggan, dan rangkap ke-2 akan diberikan kepada UMC Head sebagai bukti bahwa penjualan yang dilakukan oleh UMC Sales telah diselesaikan. Setiap satu bulan sekali, guna meningkatkan pengendalian internal atas persediaan yang ada di gudang, akan dilakukan perbandingan keakuratan pencatatan yang ada pada sistem dengan jumlah aktual dari barang yang tersedia oleh UMC Warehouse Staff di bawah pengawasan
110
UMC Warehouse Head. Hasil perhitungan akan dimasukkan ke dalam sistem dengan membuat Surat Hasil Perhitungan Fisik dan diotorisasi oleh UMC Head. Selisih-selisih yang ada akan disesuaikan dalam sistem dan memutakhirkan saldo barang tersedia. 7.
Keseluruhan transaksi dapat di-edit, update, dan delete apabila transaksi tersebut belum masuk ke siklus transaksi selanjutnya dan tindakan edit, update, dan delete hanya dapat dilakukan oleh pihak dengan jabatan Head, baik UMC Sales Head maupun UMC Warehouse Head.
4.1.1.3.2. Application-Domain Perancangan Sistem Informasi Akuntansi Penjualan, Piutang, dan Persediaan ini bertujuan untuk mendukung pelaksanaan tugas dan tanggung jawab yang ditangani oleh karyawan dalam bagian-bagian UMC Sales, UMC Warehouse, Mechanic, Delivery, Finance, dan Accounting. Tugas-tugas utama application domain sistem adalah sebagai berikut: penerimaan barang, penerimaan pesanan, perjanjian penjualan, penjualan, pengeluaran barang, pengiriman barang, pencatatan bukti kas masuk, pengecekan barang, serta pencetakan laporan-laporan penjualan, piutang, analisis penerimaan kas, kartu stok, serta hasil perhitungan fisik persediaan.
111
4.1.2. The Problem Domain 4.1.2.1. Cluster Model sistem informasi akuntansi penjualan, piutang, dan persediaan PT. Nusantara Surya Sakti dapat dikelompokkan menjadi beberapa cluster, yaitu: pemesanan, penjualan, pembayaran, penerimaan barang, pengeluaran barang, pengecekan barang, karyawan, pelanggan, dan barang.
Karyawan
Pengiriman
Pemesanan
Pelanggan
Penjualan
Barang
Pembayaran
Penerimaan Barang
Pengecekan Barang
Gambar 4.2. Model Sistem Informasi Akuntansi Penjualan, Piutang, dan Persediaan 4.1.2.2. Structure Karyawan yang akan menggunakan Sistem Informasi Akuntansi Penjualan, Piutang, dan Persediaan pada PT. Nusantara Surya Sakti adalah karyawan-karyawan di bagian Mechanic, UMC Sales, UMC Warehouse, Finance, dan Delivery.
112
Gambar 4.3. Struktur dari “Karyawan” Struktur dari pemesanan terdiri dari Surat Penawaran Konsumen (SPK) seperti yang terlihat pada gambar 4.4.
Gambar 4.4. Struktur dari “Pemesanan” Struktur dari penjualan terdiri dari Surat Perjanjian Penjualan yang diasumsikan menjadi kesepakatan mengikat antara kedua belah pihak, yaitu pelanggan dan perusahaan, untuk melakukan penjualan yang akan direalisasikan dengan pengeluaran barang dan penjualan. Kedua aktivitas tersebut direpresentasikan oleh keberadaan Surat Pengeluaran Barang dan Faktur Penjualan.
Gambar 4.5. Struktur dari “Penjualan”
113
Gambar 4.6. menunjukkan struktur dari pengiriman yang ditandai dengan keberadaan dari Surat Jalan.
Gambar 4.6. Struktur dari “Pengiriman” Gambar 4.7. menunjukkan struktur dari pembayaran yang ditandai dengan keberadaan dari Surat Bukti Penerimaan Kas.
Gambar 4.7. Struktur dari “Pembayaran” Gambar 4.8. menunjukkan struktur dari pelanggan yang terdiri dari class Pelanggan.
Gambar 4.8. Struktur dari “Barang” Gambar 4.9. menunjukkan struktur dari pelanggan yang terdiri dari class Pelanggan.
114
Gambar 4.9. Struktur dari “Pelanggan” Struktur dari penerimaan barang terdiri dari Checklist, Detail Checklist, serta Surat Tanda Penerimaan Barang.
Gambar 4.10. Struktur dari “Penerimaan Barang” Gambar 4.11. menunjukkan struktur dari pengecekan barang yang ditandai dengan keberadaan class Surat Hasil Perhitungan Fisik dan detailnya sebagai surat hasil pencatatan dari pengecekan informasi barang yang ada di sistem dengan barang aktual yang tersedia.
Gambar 4.11. Struktur dari “Pengecekan Barang”
115
Class Diagram
116
4.1.2.3. Classes Berikut merupakan setiap class beserta statechart diagram yang mewakili pola behavioural dari setiap class. 1. Karyawan Class karyawan merupakan generalisasi dari class-class Mechanic, UMC Sales, UMC
Warehouse,
Finance,
dan
Delivery;
sehingga
class
karyawan
menggeneralisasikan property dan behavior-nya terhadap class-class tersebut.
Gambar 4.13. Class “Karyawan”
Gambar 4.14. Behavioural Pattern class “Karyawan”
2. Karyawan Mechanic Class karyawan Mechanic menggambarkan model keterlibatan karyawan dalam event menerima barang.
117
Gambar 4.15. Class “Mechanic”
Gambar 4.16. Behavioural Pattern class “Mechanic”
3. Karyawan UMC Sales Class karyawan UMC Sales menggambarkan model keterlibatan UMC Sales dalam event mendata pelanggan, menerima pesanan, menyetujui penjualan, serta menjual.
Gambar 4.17. Class “UMC_Sales”
Gambar 4.18. Behavioural Pattern class “UMC_Sales”
118
4. Karyawan UMC Warehouse Class karyawan UMC Warehouse menggambarkan keterlibatan UMC Warehouse dalam event menerima barang, mengeluarkan barang, serta mengecek barang.
Gambar 4.19. Class “UMC_Warehouse”
/ menerima_barang()
/ menerima_barang() Active / mengecek_barang() / mengeluarkan_barang()
Gambar 4.20. Behavioural Pattern class “UMC_Warehouse”
5. Karyawan Finance Class karyawan Finance menggambarkan keterlibatan Finance dalam event mendata pelanggan dan menerima barang.
Gambar 4.21. Class “Finance”
119
Gambar 4.22. Behavioural Pattern class “Finance”
6. Karyawan Delivery Class karyawan Delivery menggambarkan model keterlibatan bagian Delivery dalam event mengirim barang.
Gambar 4.23. Class “Delivery”
/ mengirim_barang()
/ mengirim_barang() Active
Gambar 4.24. Behavioural Pattern class “Delivery”
7. Barang Class barang menggambarkan model keterlibatan class barang dalam event menerima barang, mengeluarkan barang, serta mengecek barang.
120
Gambar 4.25. Class “Barang”
Gambar 4.26. Behavioural Pattern class “Barang”
8. Persediaan Class persediaan merupakan bentuk agregasi dari class Barang yang dibuat sebagai class bagi kumpulan objek persediaan, yaitu jumlah dan item persediaan yang fluktuatif seiring dengan keterlibatan class persediaan pada event menerima barang, mengeluarkan barang, serta mengecek barang.
Gambar 4.27. Class “Persediaan”
121
Gambar 4.28. Behavioural Pattern class “Barang”
9. Pelanggan Class pelanggan menggambarkan model keterlibatan class pelanggan dalam event
mendata pelanggan, menerima pesanan, menjual, serta menerima
pembayaran.
Gambar 4.29. Class “Pelanggan”
122
Gambar 4.30. Behavioural Pattern class “Barang”
10. Piutang Class Piutang merupakan shared aggregation dari class Pelanggan berisi kumpulan objek dari Piutang dan menggambarkan keterlibatan class Piutang dalam event menjual dan menerima pembayaran.
Gambar 4.31. Class “Piutang” / menjual()
/ menjual() Active
/ menerima_pembayaran()
Gambar 4.32. Behavioural pattern class “Piutang”
123
11. Surat Penawaran Konsumen Class Surat Penawaran Konsumen merupakan kumpulan objek dari Surat Penawaran Konsumen dan menggambarkan model keterlibatan class Surat Penawaran Konsumen dalam event menerima pesanan dan menyetujui penjualan.
Gambar 4.33. Class “Surat Penawaran Konsumen”
Gambar 4.34. Behavioural Pattern class “Surat Penawaran Konsumen”
124
12. Surat Perjanjian Penjualan Class Surat Perjanjian Penjualan merupakan kumpulan objek dari Surat Perjanjian Penjualan dan keterlibatan class Surat Perjanjian Penjualan dalam event menyetujui penjualan, menjual, dan mengeluarkan barang.
Gambar 4.35. Class “Surat Perjanjian Penjualan”
Gambar 4.36. Behavioural Pattern dari class “Surat Perjanjian Penjualan”
13. Surat Pengeluaran Barang Class Surat Pengeluaran Barang merupakan kumpulan objek dalam Surat Penawaran Barang dan menggambarkan keterlibatan class Surat Pengeluaran Barang dalam event mengeluarkan barang, menjual, serta mengirim barang.
125
Gambar 4.37. Class “Surat Pengeluaran Barang”
Gambar 4.38. Behavioural Pattern dari class “Surat Pengeluaran Barang”
14. Faktur Penjualan Class Faktur Penjualan merupakan kumpulan objek dari class Faktur Penjualan dan menggambarkan keterlibatan class Faktur Penjualan dalam event menjual, mengirim barang, serta menerima pembayaran.
Gambar 4.39. Class “Faktur Penjualan”
126
Gambar 4.40. Behavioural Pattern dari class “Faktur Penjualan”
15. Surat Jalan Class Surat Jalan merupakan kumpulan objek dari class Surat Jalan dan menggambarkan keterlibatan class Surat Jalan dalam event mengirim barang.
Gambar 4.41. Class “Surat Jalan”
Gambar 4.42. Behavioural Pattern dari class “Surat Jalan”
16. Surat Bukti Penerimaan Kas Class Surat Bukti Penerimaan Kas merupakan kumpulan objek dari class Surat Bukti Penerimaan Kas dan menggambarkan keterlibatan class Surat Bukti Penerimaan Kas dalam event menerima pembayaran.
127
Gambar 4.43. Class “Surat Bukti Penerimaan Kas”
Gambar 4.44. Behavioural Pattern dari class “Surat Bukti Penerimaan Kas”
17. Checklist Class Checklist merupakan kumpulan objek dari class Checklist
dan
menggambarkan keterlibatan class Checklist dalam event menerima barang. Checklist -Tanggal_Checklist : Date -No_Checklist : String -Kode_Karyawan : String -Kode_Barang : String -Kuantitas : Integer -Periode_Penarikan_Kendaraan : Date +menerima_barang()
Gambar 4.45. Class “Checklist”
Gambar 4.46. Behavioural Pattern dari class “Checklist”
128
18. Surat Tanda Penerimaan Barang Class Surat Tanda Penerimaan Barang merupakan kumpulan objek dari class Surat Tanda Penerimaan Barang dan menggambarkan keterlibatan class Surat Tanda Penerimaan Barang dalam event menerima barang.
Gambar 3.47. Class “Surat Tanda Penerimaan Barang”
Gambar 4.48. Behavioural Pattern dari class “Surat Tanda Penerimaan Barang”
19. Surat Hasil Perhitungan Fisik Class Surat Hasil Perhitungan Fisik merupakan kumpulan objek dari class Surat Hasil Perhitungan Fisik dan menggambarkan keterlibatan class Surat Hasil Perhitungan Fisik dalam event mengecek barang.
129
Gambar 4.49. Class “Surat Hasil Perhitungan Fisik”
Gambar 4.50. Behavioural Pattern dari class “Surat Hasil Perhitungan Fisik”
4.1.2.4. Events Berikut adalah event table dari Sistem Informasi Akuntansi Penjualan, Piutang, dan Persediaan dari PT. Nusantara Surya Sakti.
130
131
4.1.3. The Application Domain 4.1.3.1. Usage 4.1.3.1.1. Overview
Sistem informasi akuntansi penjualan, piutang, dan persediaan suku cadang motor bekas terdiri dari delapan belas use case dan terdapat tujuh actor yang akan menggunakan sistem, yaitu: UMC Head; Mechanic, UMC Sales, UMC Warehouse, Finance, Accounting, dan Delivery.
4.1.3.1.2. Actors Berikut adalah actor specification dari sistem informasi akuntansi penjualan, piutang, dan persediaan PT. Nusantara Surya Sakti. a. UMC Head ¾
Tujuan: Actor ini bertujuan untuk menangani pendataan karyawan yang melingkupi penambahan karyawan baru di departemen yang bersangkutan, perubahan informasi atas karyawan, dan penghapusan data karyawan apabila karyawan dipindahkan ke departemen lain selain UMC atau Used Motor Cycle, ataupun diberhentikan.
¾
Karakteristik: Sebagai actor yang memiliki otoritas untuk melakukan perubahan yang diperlukan pada Master Karyawan.
132
b. Mechanic ¾
Tujuan: Actor ini bertujuan untuk menangani penyerahan suku cadang
yang
masuk
ke
gudang.
Informasi
mengenai
penyerahan barang akan dimasukkan ke dalam Checklist pada sistem oleh actor ini. Karyawan Mechanic yang akan masuk ke dalam sistem harus melakukan login terlebih dahulu dan sistem akan mencatat nama karyawan yang bertugas. ¾
Karakteristik: Mechanic harus ahli dalam pemeriksaan kendaraan motor dan mengetahui kriteria kondisi suku cadang yang cocok untuk dijual secara terpisah. Actor ini juga perlu bertanggung
jawab
dan
teliti
dalam
menghitung
dan
mengelompokkan suku cadang yang akan diserahkan kepada karyawan UMC Warehouse yang dicatat pada sistem dalam Checklist. c. UMC Sales ¾
Tujuan: Actor ini bertujuan untuk menangani keseluruhan transaksi penjualan, mulai dari inisiasi penjualan yang berawal dari
penawaran
dari
pelanggan,
pembuatan
perjanjian
penjualan antara perusahaan dengan pelanggan, sampai dengan pembuatan Faktur Penjualan. Karyawan UMC Sales yang akan masuk ke dalam sistem harus melakukan login terlebih dahulu dan sistem akan mencatat nama karyawan yang bertugas.
133
¾
Karakteristik: bertanggung jawab menangani pesanan dari pelanggan, termasuk menambah dan mengedit data pelanggan, mengentri dan mencetak Surat Penawaran Konsumen, Surat Perjanjian Penjualan, dan Faktur Penjualan.
d. UMC Warehouse ¾
Tujuan: Actor ini bertujuan untuk menangani pengendalian arus masuk dan keluar barang. UMC Warehouse berperan sebagai penerima suku cadang yang masuk ke gudang dan membuat Surat Tanda Penerimaan Barang. Apabila terjadi penjualan, maka suku cadang akan disipkan dan keluar dari gudang dengan pembuatan Surat Pengeluaran Barang. Dalam meningkatkan pengendalian, maka sebulan sekali akan dilakukan stock opname oleh UMC Warehouse dan hasil perhitungan akan didokumentasikan dalam Surat Hasil Perhitungan Fisik.
¾
Karakteristik: UMC Warehouse bertanggung jawab menangani masuk-keluar, dan kecocokan kuantitas barang yang ada pada sistem dibandingkan dengan kuantitas aktual barang, dalam hal ini mencetak dan mengentri Surat Tanda Penerimaan Barang, Surat Pengeluaran Barang, dan Surat Hasil Perhitungan Fisik. Karyawan UMC Warehouse yang akan masuk ke dalam sistem harus melakukan login terlebih dahulu dan sistem akan mencatat nama karyawan yang bertugas.
134
e. Delivery ¾
Tujuan: Actor ini bertujuan untuk menangani pengiriman barang kepada pelanggan dengan membuat Surat Jalan yang akan mencatat karyawan yang bertanggung jawab dalam pengiriman barang, data pelanggan, serta prediksi tanggal tiba barang di tangan pelanggan. Karyawan Delivery yang akan masuk ke dalam sistem harus melakukan login terlebih dahulu dan sistem akan mencatat nama karyawan yang bertugas.
¾
Karakteristik: Bagian Delivery bertanggung jawab dalam pengiriman barang kepada pelanggan, dalam hal ini mencetak dan mengentri Surat Jalan.
f. Accounting ¾
Tujuan: Actor ini bertujuan dalam pembuatan laporan penjualan dan laporan piutang yang berkaitan dengan penjualan kredit yang telah dilakukan oleh perusahaan. Karyawan Accounting yang akan masuk ke dalam sistem harus melakukan login terlebih dahulu dan sistem akan mencatat nama karyawan yang bertugas.
¾
Karakteristik: Karyawan Accounting harus teliti dalam menganalisa
dan
memeriksa
laporan
penjualan
guna
memanfaatkan informasi yang dihasilkan oleh laporan dan jurnal penjualan tersebut bagi kemajuan perusahaan.
135
g. Finance ¾
Tujuan: actor ini bertujuan dalam penerimaan kas dari pelanggan yang dihasilkan dari penjualan kredit dengan pembuatan Surat Bukti Penerimaan Kas. Actor ini juga bertanggung jawab dalam pembuatan laporan yang berkaitan dengan piutang pelanggan, yaitu laporan piutang serta laporan analisis umur piutang. Karyawan Finance yang akan masuk ke dalam sistem harus melakukan login terlebih dahulu dan sistem akan mencatat nama karyawan yang bertugas.
¾
Karakteristik: karyawan Finance harus teliti dalam menangani dan menerima pembayaran dari pelanggan serta dalam menganalisa dan memeriksa laporan yang berkaitan dengan piutang guna memanfaatkan informasi yang dihasilkan oleh laporan-laporan tersebut bagi kemajuan perusahaan.
136
4.1.3.1.3. Use Case
Gambar 4.51. Use Case Diagram
137
Keterangan:
STPB: Surat Tanda Penerimaan Barang SPK: Surat Penawaran Konsumen SPP: Surat Perjanjian Penjualan SPB: Surat Pengeluaran Barang FP: Faktur Penjualan SJ: Surat Jalan SBPK: Surat Bukti Penerimaan Kas
Berikut adalah use case specification untuk sistem informasi akuntansi penjualan, piutang, dan persediaan PT. Nusantara Surya Sakti.
Tabel 4.3. Use Case Specification dari “Pandataan Karyawan” Description
Object Function
Actor dari use case ini adalah UMC Head. UMC Head akan mendata karyawan yang akan terlibat pada transaksi dalam sistem dan dapat melakukan perubahan-perubahan data tersebut sewaktu-waktu apabila diperlukan. Use case ini berakhir ketika data karyawan berhasil di-update atau disimpan. UMC Head, Karyawan, Window Master Karyawan Save, Update Karyawan
138
Tabel 4.4. Use Case Specification untuk “Pendataan Pelanggan” Description
Object
Function
Pendataan pelanggan dilakukan oleh actor UMC Sales (Salesperson) dan Bagian Finance. Ketika pelanggan menghubungi Salesperson maka ia akan mengecek keberadaan pelanggan tersebut di database pelanggan. Apabila ternyata pelanggan baru, maka Salesperson akan menginput informasi pelanggan tersebut ke database pelanggan dan bagian Finance akan melakukan analisa mengenai pelanggan tersebut lalu menginput limit kreditnya. Namun apabila pelanggan telah terdaftar, maka transaksi akan dilanjutkan. Karyawan UMC Sales, Karyawan Finance, Pelanggan, Window Master Pelanggan. Save, Update
Tabel 4.5. Use Case Specification dari “Pandataan Checklist” Description
Object Function
Actor dari use case ini adalah Mechanic sebagai penyerah barang. Mechanic akan mendaftar suku cadang yang selanjutnya akan diserahkan ke gudang.Checklist memuat informasi barang beserta spesifikasi barang yang akan diserahkan. Apabila jenis barang ternyata baru, maka Mechanic dapat menambah data barang pada database. Pada waktu tertentu, Mechanic dapat merubah spesifikasi barang pada Master Barang dan UMC Sales yang akan menganalisa dan menginput harga bagi barang tersebut. Use case ini berakhir dengan pencetakan Checklist. Mechanic, Barang, Window Checklist Save, Update barang, Print
139
Tabel 4.6. Use Case Specification dari “Pendataan STPB” Description
Object Function
Actor dari use case ini adalah UMC Warehouse. Use case ini menggambarkan pembuatan Surat Tanda Penerimaan Barang oleh UMC Warehouse. STPB dibuat berdasarkan Checklist. STPB memuat informasi penyerah barang yang ada pada Checklist dan penerima barang. Pembuatan STPB akan secara otomatis menambah jumlah barang yang tersedia di gudang. Use case ini berakhir pada saat dicetak. UMC Warehouse, Barang, Window STPB Save, Update Barang, Print
Tabel 4.7. Use Case Specification untuk “Pendataan SPK” Description
Object Function
Actor dari usecase ini adalah UMC Sales dimana Salesperson akan menginput informasi penawaran pelanggan atas barang tertentu ke dalam Surat Penawaran Konsumen pada sistem. Salesperson juga memberlakukan tanggal efektif bagi SPK tersebut dimana apabila tanggal efektif sudah tidak berlaku, maka transaksi tidak dapat dilanjutkan. Use case berakhir pada pencetakan SPK. Karyawan UMC Sales, Pelanggan, Barang, Window SPK Save, Update, Print
140
Tabel 4.8. Use Case Specification untuk “Pendataan SPP” Description
Object Function
Actor dari use case ini adalah UMC Sales dimana SPK menjadi dasar bagi pembuatan Surat Perjanjian Penjualan. SPP menggambarkan kesepakatan harga yang telah disetujui oleh pelanggan serta diotorisasi oleh UMC Sales Head yang selanjutnya akan direalisasikan menjadi penjualan. Ketika akan disimpan, sistem mengecek saldo limit kredit pelanggan, apabila saldo pelanggan ternyata tidak mencukupi maka transaksi akan dibatalkan. UMC Sales, Pelanggan, Window SPP, Barang Save, Update, Print
Tabel 4.9. Use Case Specification untuk “Pendataan SPB” Description
Object Function
Actor dari use case ini adalah UMC Warehouse. Use case ini menggambarkan proses pembuatan Surat Pengeluaran Barang dengan berdasarkan SPB. SPB akan memuat spesifikasi barang sesuai dengan yang telah ada di SPP dan informasi yang ditambahkan adalah jenis dan jumlah kemasan dari barang yang dikeluarkan. Pembuatan SPB akan otomatis mengurangi saldo kuantitas barang yang tersedia. UMC Warehouse, Pelanggan, Barang, Window SPP Save, Update Barang, Print
141
Tabel 4.10. Use Case Specification untuk “Pendataan FP” Description
Object Function
Actor dari use case adalah UMC Sales. Use case ini menggambarkan proses pembuatan faktur penjualan berdasarkan SPP. Informasi mengenai spesifikasi barang yang dijual serta harga yang telah menjadi kesepakatan akan muncul di faktur penjualan. Pembuatan FP akan otomatis menambah saldo piutang konsumen dan mengurangi saldo limit kredit. UMC Sales, Pelanggan, Barang, Window FP Save, Update Pelanggan, Print
Tabel 4.11. Use Case Specification untuk “Pendataan SJ” Description
Object Function
Actor dari use case ini adalah Delivery Dept. Use case ini menggambarkan pembuatan Surat Jalan yang didasarkan pada SPB. Pada SJ, informasi mengenai tanggal pengiriman di-generate sesuai dengan tanggal pembuatan SJ. Terdapat informasi tambahan mengenai prediksi tanggal tiba dengan mempertimbangkan sarana dan lokasi pengiriman. Use case ini berakhir pada saat dicetak. Delivery Dept, Pelanggan, Barang, Window SJ Save, Update, Print
142
Tabel 4.12. Use Case Specification dari “Pendataan SBPK” Description
Object Function
Actor dari use case ini adalah Finance Dpt. Use case ini menggambarkan proses pembuatan Surat Bukti Penerimaan Kas dari pelanggan dengan berdasarkan FP. SBPK akan dibuat ketika Finance Dpt. memperoleh bukti setoran dari pelanggan atau apabila pembayaran pelanggan menggunakan giro ketika Finance Dept. memperoleh konfirmasi tertulis baik dari pelanggan ataupun Bank bahwa giro pelanggan telah cair dan masuk ke rekening perusahaan. Use Case ini akan langsung mengurangi saldo piutang pelanggan atas pembayaran yang telah dilakukan dan akan menambah saldo limit kredit pelanggan. Use case ini berakhir pada saat pencetakan. Finance Dpt., Pelanggan, Window SBPK Save, Update pelanggan, Print
Tabel 4.13. Use Case Specification untuk “Pendataan SHPF” Description
Object Function
Actor dari use case ini adalah UMC Warehouse. Use case ini menggambarkan proses pembuatan Surat Hasil Perhitungan Fisik atas pencocokkan kuantitas barang yang ada pada sistem dengan kuantitas sebenarnya yang dilakukan secara periodik setiap bulan. SHPF memuat informasi atas barang yang hilang dan rusak yang kemudian akan disesuaikan dengan saldo akhir barang yang tersedia. Use case ini berakhir ketika dicetak. UMC Warehouse, Barang, Window SHPF Save, Update Barang, Print
143
Tabel 4.14. Use Case Specification untuk “Membuat Laporan Penjualan” Description
Object Function
Actor dari use case ini adalah Accounting Dept. Use case ini menggambarkan proses pencetakan laporan penjualan dengan spesifikasi tertentu yang dikehendaki. Spesifikasi yang dimaksud adalah ketika Accounting Dept. membuka Window Laporan Penjualan lalu ia dapat menentukan periode yang diinginkan serta laporan penjualan berdasarkan barang, pelanggan, ataupun keseluruhan. Use case ini berakhir ketika Laporan Penjualan tercetak. Accounting Dept., Barang, FP, Pelanggan, Laporan Penjualan Print
Tabel 4.15. Use Case Specification untuk “Membuat Laporan Piutang” Description
Object Function
Actor dari use case ini adalah Finance Dept. berawal ketika Bagian Finance membuka Window Laporan Piutang dan memilih laporan piutang berdasarkan pelanggan atau laporan keseluruhan piutang. Use case ini berakhir ketika laporan piutang dicetak. Finance Dept., Pelanggan, Faktur Penjualan, Laporan Piutang Print
144
Tabel 4.16. Use Case Specification untuk “Membuat Laporan Analisis Umur Piutang” Description
Object Function
Actor dari use case ini adalah Finance Dept. dimana Bagian Finance akan mengakses Window Analisis Umur Piutang dan mencetak laporan tersebut. Window akan menampilkan tanggal akses pencetakkan dan menampilkan umur piutang sampai dengan tanggal dimana laporan tersebut dicetak. Use case berakhir ketika laporan analisis umur piutang tercetak. Finance Dept, Pelanggan, Laporan Analisis Umur Piutang Print
Tabel 4.17. Use Case Specification untuk “Membuat Kartu Stok” Description
Object Function
Actor dari use case ini adalah UMC Warehouse yaitu UMC Warehouse Head yang akan mencetak Kartu Stok atau suatu laporan yang memuat mutasi atau arus masuk-keluar barang dari gudang. UMC Warehouse Head memulai use case dengan masuk ke Window Kartu Stock dan menentukan periode yang dikehendaki. Use case berakhir ketika Kartu Stok dicetak. UMC Warehouse, Barang, Kartu Stock Print
145
Tabel 4.18. Use Case Specification untuk “Membuat Laporan Hasil Perhitungan Fisik” Description
Object
Function
Actor dari use case ini adalah UMC Warehouse Head dimana UMC Warehouse Head akan mengakses Window Laporan Hasil Perhitungan Fisik dan mencetak laporan atas perhitungan fisik terhadap persediaan tersebut. Window akan menampilkan tanggal akses pencetakkan dan menampilkan Surat Hasil Perhitungan Fisik yang terdapat sampai dengan tanggal dimana laporan tersebut dicetak. Use case berakhir ketika laporan tercetak. UMC Warehouse, Barang, Surat Hasil Perhitungan Fisik, Laporan Hasil Perhitungan Fisik Print
Tabel 4.19. Use Case Specification untuk “Membuat Jurnal Penjualan” Description
Object Function
Actor dari use case ini adalah Accounting Dept. dimulai ketika Accounting Dept. masuk ke Window Jurnal Penjualan, memasukkan periode yang diinginkan, lalu mencetak Jurnal Penjualan. Use case ini berakhir ketika Jurnal Penjualan Tercetak. Accounting Dept, Jurnal Penjualan, FP Print
146
Tabel 4.20. Use Case Specification untuk “Membuat Jurnal Penerimaan Kas” Description
Object Function
Actor dari use case ini adalah Accounting Dept. dimulai ketika Accounting Dept. masuk ke Window Jurnal Penerimaan Kas, memasukkan periode yang diinginkan, lalu mencetak Jurnal Penerimaan Kas yang berupa jurnal bagi kas yang diterima dari transaksi penjualan kredit suku cadang motor. Use case ini berakhir ketika Jurnal Penerimaan Kas tercetak. Accounting Dept, Jurnal Penerimaan Kas, SBPK Print
147
Berikut adalah sequence diagram untuk masing-masing use case yang terdapat dalam Sistem Informasi Akuntansi Penjualan, Piutang, dan Persediaan pada PT. Nusantara Surya Sakti.
148
Gambar 4.52. Sequence Diagram dari “Pendataan Karyawan”
149
Gambar 4.53. Sequence Diagram dari “Pendataan Pelanggan”
150
Gambar 4.54. Sequence Diagram dari use case “Pendataan Checklist”
151
Gambar 4.55. Sequence Diagram dari use case “Pendataan Checklist” (tombol Navigasi)
152
Gambar 4.56. Sequence Diagram dari use case “Pendataan Checklist” (Searchdan Edit)
153
Mechanic create() Window_Checklist
Cbo Kode Barang()
Grid_Checklist
Detail_Checklist
Checklist
Barang
Karyawan
get_last_code() return()
generate_new_code()
set_Checklist_date() get_info() return() create()
get_code()
loop
return()
select_period()
loop
select_kode_barang() select() create() get_info_barang() loop
return() entry_qty() entry()
calculate_total_qty()
click_save() save() save() update() click_print() print() Printed_Checklist() close() click_close()
X
X
X
X
Gambar 4.57. Sequence Diagram dari use case “Pendataan Checklist” (Add New)
154
Gambar 4.58. Sequence Diagram dari use case ”Pendataan STPB”
155
Gambar 4.59. Sequence Diagram dari “Pendataan STPB” (Tombol Navigasi)
156
Gambar 4.60. Sequence Diagram dari “Pendataan STPB” (Searchdan Edit)
157
Gambar 4.61. Sequence Diagram dari “Pendataan STPB” (Add New)
158
Gambar 4.62. Sequence Diagram dari “Pendataan SPK”
159
Gambar 4.63. Sequence Diagram dari “Pendataan SPK” (Tombol Navigasi)
160
Gambar 4.64. Sequence Diagram dari “Pendataan SPK” (Searchdan Edit)
161
Gambar 4.65. Sequence Diagram dari “Pendataan SPK” (Add New)
162
Gambar 4.66. Sequence Diagram dari “Pendataan SPP”
163
Gambar 4.67. Sequence Diagram dari “Pendataan SPP” (Tombol Navigasi)
164
Gambar 4.68. Sequence Diagram dari “Pendataan SPP” (Search dan Edit)
165
UMC Sales create() Window_SPP
Cbo_No_SPK()
Grid_SPP
Detail_SPP
SPP
SPK
Detail_SPK
Karyawan
Pelanggan
get_last_code() return()
generate_new_code()
set_SPP_date() get_info() return() create()
get_code()
loop
return()
select_no_SPK() select() create() get_SPK_detail() loop
return()
get_credit_limit() get_saldo_kredit() return() select_negosiasi() enable_editing_harga()
loop
select_kode_barang() select() entry_harga_kesepakatan() entry_harga_kesepakatan()
calculate_total()
alt
select_sesuai_SPP()
reload_from_SPK_detail() click_save() hitung_saldo_limit_kredit
validasi_kecukupan_kredit() save()
save()
click_print() print()
Printed_SPP() close() click_close()
X X X
X X
Gambar 4.69. Sequence Diagram dari “Pendataan SPB” (Add New)
166
Gambar 4.70. Sequence Diagram dari “Pendataan SPB”
167
Gambar 4.71. Sequence Diagram dari “Pendataan SPB” (Tombol Navigasi)
168
Gambar 4.72. Sequence Diagram dari “Pendataan SPB” (Search dan Edit)
169
Gambar 4.73. Sequence Diagram dari “Pendataan SPB” (Add New)
170
Gambar 4.74. Sequence Diagram dari “Pendataan FP”
171
Gambar 4.75. Sequence Diagram dari “Pendataan FP” (Tombol Navigasi)
172
Gambar 4.76. Sequence Diagram dari “Pendataan FP” (Search dan Edit)
173
UMC Sales create() Window_FP
Cbo_No_SPP()
Grid_FP
FP
SPB
Pelanggan
Detail_SPP
Karyawan
get_last_code() return()
generate_new_code()
set_FP_date()
get_info() return() get_data() return
create() get_code()
loop
return()
select_no_SPB() select() create() get_SPP_detail() loop
return() get_SPB_record() return() calculate_VAT() calculate_grand_total() create() Cbo_Periode()
select_periode_pembayaran() select() set_tanggal_jatuh_tempo() input_catatan() click_save() hitung_saldo_limit_kredit validasi_kecukupan_kredit() save()
save()
click_print() print() Printed_FP()
close() click_close()
X
X
X
X
Gambar 4.77. Sequence Diagram dari “Pendataan FP” (Add New)
X
174
Gambar 4.78. Sequence Diagram dari “Pendataan SJ”
175
Gambar 4.79. Sequence Diagram dari “Pendataan SJ” (Tombol Navigasi)
