PERANCANGAN SISTEM INFORMASI AKUNTANSI
PENJUALAN, PIUTANG, DAN PENERIMAAN KAS
PT. SURYA WARFA KHARISMA
4.1 Analysis Document 4.1.1 The Task 4.1.1.1 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.
4.1.1.2 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
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 Domain
Karyawan Bagian Administrasi (Penjualan), Bagian Gudang, 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.
4.1.1.3 Context
4.1.1.3.1 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
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.
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.
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-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
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.
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 60-80
juta 40-60 juta 20-40 juta 0-20 juta 40 Ketepatan membayar 1-30 hari 31-60 hari 61-90 hari 91-120 hari > 120 hari 30 Jumlah retur per bulan 0% 1-5 % 6-10 % 10-14% > 14% 15 Lama langganan > 8 tahun 6-8 tahun 4-6 tahun 2-4 tahun 0-2 tahun 15 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:
100 – 200 poin = limit kredit disarankan Rp. 20.000.000 201 – 300 poin = limit kredit disarankan Rp. 50.000.000 301 – 400 poin = limit kredit disarankan Rp. 70.000.000 401 – 500 poin = limit kredit disarankan Rp. 100.000.000
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:
Flowchart Prosedur Penerimaan Pembayaran dari Penjualan Kredit Bagian Akuntansi Bagian Keuangan Kuitansi (signed) Memerik sa Invoice jatuh tempo 1 Membu-at FPS dan Kuitansi Bukti Transfer / Cek 1 Disetor ke bank 2 1 Meminta otorisasi direktur 1 1 2 3 Invoice Masukan data pembayaran Menringkas data pembayaran Kuitansi Cetak FPS dan Kuitansi 1 2 1 2 1 Memban dingkan dengan invoice Bukti Transfer / Cek Meneri-ma Bukti Trasfer / Cek Melaku-kan penagih an Mengecek Daftar Piutang Meringkas data piutang Invoice 1 Invoice 3 1 2 invoice 3 Bukti Transfer / Cek 1 2 22 1 3 1 11 3 3 T 1 2 pelanggan 1 Kuitansi FPS 1 2 3 1 2 3 3 FPS (signed) invoice 3 1 1 2 3 3 3 Kuitansi (signed) FPS (signed) 3 3 Membu-at laporan jurnal Jurnal T Memasukkan tanggal Meringkas data penerimaan kas selesai Kuitansi Kuitansi (signed) FPS (signed) 3 3 Laporan Jurnal Penerimaan Kas Keterangan: FPS = Faktur Pajak Standar Barang
Pelang-gan
Gambar 4.3 Flowchart Sistem Prosedur Penerimaan Pembayaran dari Penjualan Kredit
Gambar 4.5 Flowchart Sistem Prosedur Retur Penjualan (dengan penukaran)
Pelanggan Baru
Pelanggan
Tetap AdministrasiBagian
Bagian Perbekalan Pelanggan Bagian Administrasi SR Board of Directors DO MICROSOFT CORPORATION invoice + + + + Form Pelanggan DO (signed) MICROSOFT CORPORATION invoice DO (signed) DO (signed) Bagian Keuangan Cek Bukti Transfer atau Kuitansi MICROSOFT CORPORATION invoice + DO SR Tagih piutang FPS 1a 2 1b 3 4 5 6 7 8 9 10 11 12 13a 13b 1 2a 2b 1 2 3 SPH = Surat Penawaran Harga
PO = Purchase Order SC = Sales Contract DO = Delivery Order Invoice = Faktur Penjualan SR = Surat Retur FPS = Faktur Pajak Standard
Bagian Perbekalan SPH SPH (signed) SC PO SPH (signed) SC (signed) SC (signed) SC (signed) DO DO + + Bagian Keuangan Bagian Keuangan MICROSOFT CORPORATION invoice Laporan Jurnal Bagian Akuntansi DO (signed) Bagian Akuntansi Kuitansi FPS + Bagian Akuntansi + MICROSOFT CORPORATION invoice + SR 4 2c 13c 14 Membuat SPH, SC, DO Membuat Invoice Laporan Bulanan Membuat SR Membuat Kuitansi Gambar 4.6 Rich Picture sistem yang diusulkan
4.1.1.3.2 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.
4.1.2 Problem Domain 4.1.2.1 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.
Gambar 4.7 Model sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma
4.1.2.2 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.
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. pkg Cluster Barang + Barang + Merek + Tipe Pelanggan + Pelanggan + Piutang Pemesanan + detail SC + detil SPH + Sales Contract + SPH Pengiriman + Delivery Order + detil DO Pembayaran + detil Kuitansi + Kuitansi Retur + detil DO-Retur + detil Surat Retur + DO-Retur + Surat Retur Penj ualan + Invoice User + Bag. Admin + Bag. Akuntansi + Bag. Keuangan + Karyawan + Manajer Keuangan + Password pkg Barang
Barang Merek Tipe
Gambar 4.9 Struktur Pelanggan
Gambar berikut menunjukkan struktur User yang memiliki hubungan generalization dengan Bagian Admin, Bagian Keuangan, Bagian Akuntansi, dan 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.
pkg Pelanggan
Pelanggan Piutang
1..* 1
pkg User
Bag. Admin Bag. Keuangan Bag. Akuntansi Manaj er
Keuangan Karyaw an
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.
Gambar 4.12 Struktur Pengiriman
Gambar berikut menunjukkan struktur Penjualan, yang merupakan struktur tunggal dan hanya terdiri dari Invoice tanpa pola hubungan.
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.
pkg Pemesanan
SPH
detil SPH Sales Contract detail SC
1..* 1 1 0..1 1 1..*
pkg Pengiriman
Deliv ery Order detil DO
1..* 1
pkg Penj ualan
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.
Gambar 4.15 Struktur Retur
pkg Pembayaran
Kuitansi detil Kuitansi
1..* 1
pkg Retur
Surat Retur
detil Surat Retur DO-Retur detil DO-Retur
Gambar 4.16 Class Diagram sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma
class System
Merek Keterangan:
SPH = Surat Penawaran Harga DO = Delivery Order
Tipe
Barang
detail SPH SPH
Sales Contract Pelanggan Inv oice
Surat Retur
Deliv ery Order - Retur detail Kuitansi Kuitansi detail Sales Contract detail DO
detail Surat Retur
detail Deliv ery
Order - Retur Piutang
Karyaw an Bag. Administrasi Bag. Keuangan Bag. Akun Manaj er Keuangan DO Passw ord 1 1..* 1..* 1 1..* 1 1..* 1 1 1..* 1..* 1 1 0..1 1..* 1 1 1..* 1..* 1 1 1..* 1..* 1 1..* 1 1..* 1 1..* 1 1 1..* 1 1..* 1 1..* 1 1 1 1..* 1 0..1 1 1..* 1 1..*
4.1.2.3 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.
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.
Gambar 4.18 class Password
class Karyaw an Karyaw an - kd_karyawan: char - nama_karyawan: varchar - divisi: char - jabatan: char - user_name: char
class Passw ord
Passw ord
- user_name: char
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.
Gambar 4.20 class Bag. Administrasi
Gambar 4.21 behavioral pattern dari class Bag. Administrasi
stm Passw ord
Registered Activ e
/mendaftar /login
/mengubah
/logout
class Bag. Administ...
Bag. Administrasi stm Bag. Administrasi Activ e /meretur /mengirim /megontrak /menawarkan /menawarkan
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.
Gambar 4.22 class Bag. Keu Gambar 4.23 behavioral pattern dari class Bag. Keu
Tabel 4.5 Keterangan Behavioral Pattern Class Bag. Keuangan
Behaviors Attributes menjual no. Invoice, jenis pembayaran, tgl jatuh tempo, no. DO, kode
pelanggan
membayar no. Kuitansi, tgl bayar, no. Invoice, kode pelanggan, no. SR, cara pembayaran, no. cek/giro, bank, jumlah pembayaran
class Bag. Keuangan
Bag. Keuangan stm Bag. Keuangan Activ e /membayar /menjual /menjual
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.
Gambar 4.24 class Bag.Akuntansi Gambar 4.25 behavioral pattern dari class Bag.Akun Tabel 4.6 Keterangan Behavioral Pattern Class Bag. Akuntansi
Behaviors Attributes menjurnal
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.
Gambar 4.26 class Manajer Keu. Gambar 4.27 behavioral pattern dari class Manajer Keu.
class Bag. Akuntansi
Bag. Akuntansi
stm Bag. Akuntansi
Activ e /menjurnal
/menjurnal
class Manaj er Keu...
Manaj er Keuangan stm Manaj er Keuangan Activ e /menyetujui /menilai /menilai
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.
Gambar 4.28 class Pelanggan
Gambar 4.29 behavioral pattern dari class Pelanggan
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 - email: varchar - mobille_no: char - tgl_daftar: date - lama_langganan: int stm Pelanggan Activ e Registered /menilai /menjual /mengontrak /menawarkan /meretur /membayar /mendaftar /menawarkan_harga
Tabel 4.8 Keterangan Behavioral Pattern Class Pelanggan
Behaviors Attributes
mendaftar
kode pelanggan, nama pelanggan, no. NPWP, alamat, kota, no. Telp, fax, tgl saldo awal, saldo piutang awal, saldo piutang, limit kredit, kredit tersedia, contact person, email, 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 meretur
no. Surat retur, tgl retur, no, invoice, kode pelanggan, tipe 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.
Gambar 4.30 class Barang
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.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.
Gambar 4.32 class Tipe Gambar 4.33 behavioral pattern dari class Tipe
stm Barang Activ e Av ailable Pending /meretur /mengirim /mengontrak /menawarkan [barang_habis] /menerima /mendaftar /menawarkan [barang_baru] class Tipe Tipe - kd_tipe: char - nama_tipe: char stm Tipe Activ e /mendaftar
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.
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. class Merek Merek - kd_merek: char - nama_merek: char - kd_tipe: char stm Merek Activ e /mendaftar
Gambar 4.36 class SPH
Gambar 4.37 behavioral pattern dari class SPH Tabel 4.12 Keterangan Behavioral Pattern Class SPH
Behaviors Attributes menawarkan no. SPH, tgl akhir berlaku, nama pelanggan, subtotal,
PPN, total harga
mengontrak no. SPH, nama pelanggan, subtotal, PPN, total harga
Detail SPH
Gambar berikut menunjukkan class detail SPH dan behavioral pattern-nya.
Gambar 4.38 class detail SPH
class SPH SPH - no.SPH: char - tgl_akhir_berlaku: date - nama_pelanggan: varchar - subtotal: long - PPN: long - total_harga: long stm SPH Waiting Activ e Proceed [barang_tidak_tersedia] /mengontrak [menolak] /menawarkan [barang_tersedia] [lewat_tgl_akhir_berlaku] 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.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.
Gambar 4.40 class Sales Contract
stm detil SPH Waiting Proceed [barang_tidak_tersedia] [menolak] /menawarkan [barang_tersedia] 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.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
Detail Sales Contract
Gambar berikut menunjukkan class detail Sales Contract dan behavioral pattern-nya.
Gambar 4.42 class detail Sales Contract
Gambar 4.43 behavioral pattern dari class detail Sales Contract
stm Sales Contract Waiting Pending [kredit_memenuhi] [kredit_tidak_memenuhi] /mengontrak /mengirim
class detail Sales Contract
detail Sales Contract
- no.SalesContract: char - kode_barang: char - jumlah_barang: int - harga_satuan: long stm detil SC Waiting /mengirim /mengontrak
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.
Gambar 4.44 class Delivery Order
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
class DO DO - no.DO: char - tgl_pengiriman: date - no.SC: char - tujuan_pengiriman: varchar - alamat_pengiriman: varchar - kode_pelanggan: char stm DO Activ e Returned /menagih /mengirim /meretur [tercatat]
Detail DO
Gambar berikut menunjukkan class detail Delivery Order dan behavioral pattern-nya.
Gambar 4.46 class detail Delivery Order
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. class detail DO detail DO - no.DO: char - kode_barang: char - jumlah_dikirim: int stm detil DO Activ e Returned /mengirim_barang /meretur [tercatat]
Gambar 4.48 class Invoice
Gambar 4.49 behavioral pattern dari class Invoice Tabel 4.18 Keterangan Behavioral Pattern Class Invoice
Behaviors Attributes menagih
no. Invoice, jenis pembayaran, tgl jatuh tempo, no. DO, kode pelanggan, subtotal, PPN, total harga
membayar
no. Invoice, jenis pembayaran, tgl jatuh tempo, kode pelanggan, total harga
menjurnal 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.
class Inv oice
Inv oice - no.Invoice: char - jenis_pembayaran: boolean - tgl_jatuh_tempo: date - no.DO: char - kode_pelanggan: char - subtotal: long - PPN: long - total_harga: long stm Inv oice Activ e Paid /membayar /menjurnal /membayar /menagih
Gambar 4.50 class Kuitansi
Gambar 4.51 behavioral pattern dari class Kuitansi
Tabel 4.19 Keterangan Behavioral Pattern Class Kuitansi
Behaviors Attributes menerima
pembayaran
no. Kuitansi, tgl bayar, no. Invoice, kode pelanggan, no. SR, cara pembayaran, no. cek/giro, bank, jumlah pembayaran
menjurnal no. Kuitansi kode pelanggan, tgl bayar total bayar
Detail Kuitansi
Gambar berikut menunjukkan class detail Kuitansi dan behavioral pattern-nya.
Gambar 4.52 class detail Kuitansi
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 stm Kuitansi Activ e /menjurnal /membayar /membayar
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 - sisa: long
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.
Gambar 4.54 class Surat Retur
stm detail Kuitansi
Activ e /membayar
/membayar
class Surat Retur
Surat Retur - no.SR: char - no.Invoice: char - kode_pelanggan: char - jumlah_retur: int - tipe_retur: char - keterangan: varchar
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.
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
stm Surat Retur
Activ e /mengirim Proceed
/menjurnal /meretur
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
Activ e /meretur
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.
Gambar 4.58 class DO-Retur
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.
Gambar 4.60 class detail DO-Retur
class Deliv ery Order - Retur
Deliv ery Order - Retur
- no.DO-R: char - tgl_pengiriman: date - no.SR: char - tujuan_pengiriman: varchar - alamat_pengiriman: varchar - kode_pelanggan: char
stm Deliv ery Order - Retur
Activ e Send
/mengirim [terkirim]
class detail Deliv ery Ord...
detail Deliv ery Order - Retur
- no.DO: char - kode_barang: char - jumlah_dikirim: int
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.
Gambar 4.62 class Piutang
stm detail DO-R Activ e /mengirim 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.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
4.1.2.4 Events
Berikut merupakan event table dari sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma:
stm Piutang Activ e Settled Reduced /membayar /membayar [lunas] /meretur /menagih
Tabel 4.26 Event Table sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma
Class
Passwor
d
Bagian Administrasi Bagian Keuangan bagian Akuntansi Manajer Keuangan pelangga
n
b
arang
tipe mere
k
SPH Sales Contract Delivery Orde
r
Invoice Kuitansi Surat Retu
r
Delivery Orde
r-Retu
r
SPH detail SC detail DO detail Kuitansi d
etail
SR detail DO-R detail piutang
Event login * logout * mengubah * mendaftar + + + + + menerima + menawarkan * * * + * mengontrak * * * + + * mengirim * * * + + + * * menjual * * + + + membayar * * * + * + meretur * * * + + * + menjurnal * + + + + menilai * * menyetujui * +
4.1.3 Application Domain 4.1.3.1 Usage
4.1.3.1.1 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 Bagian Administrasi Bagian Keuangan Bagian Akuntansi Manajer Keuangan 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 √
4.1.3.1.2 Actors
Berikut ini adalah actor specification dari sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma:
Tabel 4.28 Actor Specification dari karyawan Bagian Administrasi Bagian Administrasi
Tujuan
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.
Karakteristik
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.
Contoh
Bagian administrasi membuat SPH berdasarkan permintaan pelanggan, membuat Sales Contract, membuat DO, membuat Surat Retur, membuat DO-Retur dan mendistribusikannya ke bagian terkait.
Tabel 4.29 Actor Specification dari karyawan Bagian Keuangan Bagian Keuangan
Tujuan
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.
Karakteristik
Karyawan ini harus memiliki ketelitian yang baik dalam mengatur arus kas, beritikad baik dan jujur, serta memiliki pengalaman administratif keuangan yang bagus.
Contoh
Bagian keuangan membuat invoice, mencatat pembayaran pelanggan dalam Kuitansi, membuat laporan bulanan, melakukan penagihan dan mengingatkan pelanggan atas piutangnya yang terlambat bayar.
Tabel 4.30 Actor Specification dari karyawan Bagian Akuntansi Bagian Akuntansi
Tujuan
Karyawan ini bertanggung jawab dalam pencatatan akuntansi dan membuat laporan jurnal penjualan, laporan jurnal penerimaan kas, dan laporan jurnal retur.
Karakteristik
Karyawan ini harus memiliki latar belakang pendidikan di bidang akuntansi dan teliti dalam menjalankan tugasnya, serta berpengalaman di bidangnya.
Contoh
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
Tujuan
Karyawan ini bertanggung jawab dalam melakukan penilaian terhadap pelanggan, menentukan limit kredit pelanggan, dan membuat keputusan otorisasi transaksi pelanggan yang melebihi limit.
Karakteristik
Karyawan ini harus memiliki kemampuan analisis kredibilitas, bersifat objektif, dan dapat mengambil keputusan yang tepat bagi kesehatan keuangan perusahaan.
Contoh Manajer Keuangan menentukan jumlah limit kredit yang dimiliki pelanggan, dan melakukan otorisasi limit kreditnya.
4.1.3.1.3 Use Cases
Berikut ini digambarkan use case diagram dari sistem informasi akuntansi penjualan, piutang, dan penerimaan kas pada PT. Surya Warfa Kharisma:
Gambar 4.64 Use Case Diagram dari Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada PT. Surya Warfa Kharisma
uc Use Cases Model
Mendata Pelanggan Bagian Administrasi Membuat SPH Mendata Barang Mendata Tipe Mendata Merek Membuat Sales Contract
Membuat Deliv ery Order
Membuat Inv oice
Membuat Kuitansi
Membuat Surat Retur
Membuat DO-Retur Membuat Laporan Penj ualan Membuat Laporan Penerimaan Kas Membuat Laporan Piutang Membuat Laporan Retur Membuat Laporan Analisis Umur Piutang Membuat Laporan Jurnal Penj ualan
Membuat Laporan Jurnal Retur Penj ualan Membuat Laporan Jurnal Penerimaan Kas Melakukan penilaian pelanggan
Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas
PT. Surya Warfa Kharisma
Membuat FPS Mengotorisasi transaksi pending Bagian Keuangan Manaj er Keuangan Bagian Akuntansi Keterangan:
SPH = Surat Penawaran Harga FPS = Faktur Pajak Standar DO-R= Delivery Order Retur
Mengupdate Piutang «extend»
«extend»
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”
Tabel 4.33 Use Case Specification “Mendata barang” Mendata barang
Use Case
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. Objects Barang, Tipe, Merek
Functions
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
Tabel 4.34 Use Case Specification “Mendata tipe” Mendata tipe
Use Case
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.
Objects Barang, Tipe
Functions get_data_tipe, get_last_record, get_last_code, generate_kode_tipe, remove, save
Mendata pelanggan
Use Case
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.
Objects Pelanggan
Functions
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
Tabel 4.35 Use Case Specification “Mendata merek” Mendata merek
Use Case
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.
Objects Barang, Merek, Tipe
Functions get_data_merek, get_kode_tipe, get_last_record, get_last_code, generate_kode_merek, remove, save
Tabel 4.36 Use Case Specification “Membuat SPH” Membuat SPH
Use Case
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.
Objects SPH, detil SPH, pelanggan, barang, tipe, merek
Functions
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
Tabel 4.37Use Case Specification “Membuat Sales Contract” Membuat Sales Contract
Use Case
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 men-generate status Sales Contract menjadi pending. Untuk itu, diperlukan otorisasi oleh Manajer Keuangan untuk memproses transaksi pending. Bila limit kredit memenuhi maka kontrak dapat dilanjutkan.
Objects Sales Contract, detail Sales Contract, SPH, detail SPH, pelanggan, barang, tipe, merek
Functions
get_last_record, get_last_record_detail, go_to_first_record, go_to_previous_record, go_to_next_record, go_to_last_record,
get_detail_SPH, get_kode_barang, calculate_total_harga, calculate_subtotal, calculate_PPN, calculate_grand_total, generate_status, remove, save, print
Tabel 4.38 Use Case Specification “Membuat Delivery Order” Membuat Delivery Order
Use Case
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.
Objects DO, detil DO, SC, SPH, pelanggan, detil SPH, barang, tipe, merek
Functions
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
Tabel 4.39 Use Case Specification “Membuat Invoice” Membuat Invoice
Use Case
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.
Objects Invoice, DO, detil DO, SC, SPH, pelanggan, detil SPH, barang, tipe, merek
Functions
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
Tabel 4.40 Use Case Specification “Membuat Faktur Pajak Standar” Membuat Faktur Pajak Standar
Use Case
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.
Objects Invoice, DO, detil DO, SC, SPH, pelanggan, detil SPH, barang, tipe, merek
Functions get_data_invoice, get_invoice_record_detail, get_data_pelanggan Tabel 4.41 Use Case Specification “Membuat Kuitansi”
Membuat Kuitansi
Use Case
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).
Objects Kuitansi, detail Kuitansi, Invoice, Surat Retur, DO, SC, SPH, pelanggan
Functions
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
Tabel 4.42 Use Case Specification “Membuar Surat Retur” Membuar Surat Retur
Use Case
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.
Objects Surat Retur, detail Surat Retur, DO, detail DO, SC, SPH, pelanggan, detil SPH, barang, tipe, merek
Functions
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.44 Use Case Specification “Membuat laporan penjualan” Membuat laporan penjualan
Use Case
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.
Objects Invoice
Functions get_data_invoice, get_invoice_record_detail, calculate_total, print
Tabel 4.45 Use Case Specification “Membuat laporan penerimaan kas” Membuat laporan penerimaan kas
Use Case
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.
Objects Kuitansi
Functions get_data_kuitansi, calculate_total, print
Tabel 4.46 Use Case Specification “Membuat laporan piutang” Membuat laporan piutang
Use Case
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.
Objects Invoice, Surat Retur, Kuitansi
Functions 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
Use Case
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.
Objects Invoice, Kuitansi, Pelanggan
Membuat DO-Retur
Use Case
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.
Objects DO-Retur, detail DO-Retur, Surat Retur, detail Surat Retur, DO, SC, SPH, detil SPH, barang, tipe, merek
Functions
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,
Functions get_data_piutang, get_data_pembayaran, calculate_umur_piutang, calculate_total, print
Tabel 4.48 Use Case Specification “Membuat laporan retur” Membuat laporan retur
Use Case
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.
Objects Surat Retur
Functions 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 Use Case
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.
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
Use Case
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.
Objects Kuitansi
Functions get_data_kuitansi, calculate_total, print
Tabel 4.51 Use Case Specification “Membuat laporan jurnal retur” Membuat laporan jurnal retur
Use Case
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.
Objects Surat Retur
Functions get_data_surat_retur, calculate_total，print
Tabel 4.52 Use Case Specification “Mengotorisasi transaksi pending” Mengotorisasi transaksi pending
Use Case
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.
Objects Sales Contract, Pelanggan
Functions get_data_sales_contract，get_limit_kredit，get_status，save
Tabel 4.53 Use Case Specification “Mengupdate Piutang” Mengupdate Piutang
Use Case
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
Objects Piutang, Invoice, Kuitansi, Surat Retur
Functions get_data_piutang, get_data_penjualan, get_data_pembayaran, get_data_retur
Tabel 4.54 Use Case Specification “Melakukan penilaian pelanggan” Melakukan penilaian pelanggan
Use Case
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 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
4.1.3.2 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
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
