bab 4 perancangan sistem informasi akuntansi penjualan...

BAB 4

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

101

pembuatan laporan yang terkait dengan aktivitas penjualan, piutang dan penerimaan kas

secara tepat dan akurat. Sistem ini dibangun menggunakan platform PC (Personal

Computer) yang didukung oleh jaringan LAN (Local Area Network) untuk

mempermudah proses aliran data. Pengembangan sistem ini dilakukan berdasarkan

usulan perbaikan untuk mengatasi permasalahan yang ditemui pada sistem berjalan.

System definition dari sistem informasi akuntansi penjualan, piutang dan

penerimaan kas ini dapat dijelaskan dan diringkas pada tabel 4.1 kriteria FACTOR

berikut:

Tabel 4.1 System Definiton dengan kriteria FACTOR Functionality Mendukung kegiatan penjualan dan pemrosesan transaksi mulai

dari penawaran harga, penerimaan pesanan, pengiriman barang, penerimaan retur, penagihan, dan penerimaan pembayaran, serta proses pencatatan, pengendalian internal dan pembuatan laporan yang reliable terkait dengan aktivitas penjualan, piutang dan penerimaan kas.

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

102

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

103

harga, serta mencantumkan cara pembayaran, jangka waktu pembayaran dan jangka

waktu penyerahan barang.

Pada saat pembuatan Sales Contract, sistem melakukan pengecekan limit kredit

pelanggan yang tersedia. Apabila kredit tersedia tidak memenuhi untuk dilakukan

transaksi, sistem akan menolak untuk memproses Sales Contract dan memerlukan

otorisasi direktur dalam melanjutkan transaksi. Direktur juga dapat mengubah limit

kredit pelanggan agar transaksi dapat dilanjutkan.

Setelah meminta otorisasi direktur, Sales Contract dikirimkan kepada pelanggan.

Distribusi dokumen yang dibuat sebanyak 3 rangkap ini adalah sebagai berikut:

Sales Contract rangkap 1 untuk pelanggan

Sales Contract rangkap 2 untuk bagian keuangan

Sales Contract rangkap 3 untuk arsip bagian administrasi

Selanjutnya bagian administrasi membuat Delivery Order (DO) sebanyak 4

rangkap yang kemudian diserahkan ke bagian keuangan. Berdasarkan Sales Contract

dan Delivery Order yang diterima, bagian keuangan mencatat pesanan pelanggan

tersebut ke dalam invoice sebanyak 4 rangkap yang akan didistribusikan sebagai berikut:

invoice rangkap 1 untuk pelanggan (setelah melakukan pembayaran)

invoice rangkap 2 diserahkan kepada pelanggan bersamaan dengan pengiriman barang

invoice rangkap 3 untuk arsip bagian keuangan

invoice rangkap 4 untuk bagian akuntansi

Jika transaksi dilakukan secara kredit, invoice rangkap 1 akan diarsip ke dalam

arsip sementara oleh bagian keuangan. Sedangkan untuk transaksi penjualan tunai,

invoice rangkap 1 diserahkan bersamaan dengan invoice rangkap 2 dan barang pada saat

pengiriman barang.

104

Bagian keuangan meneruskan DO sebanyak 4 rangkap dan invoice rangkap 2

(beserta invoice rangkap 1 jika transaksi penjualan secara tunai) kepada bagian

perbekalan. Surat Delivery Order ini merupakan pernyataan yang digunakan sebagai

perintah pengeluran barang dari gudang. Berdarkan DO, bagian perbekalan mencatat

pengeluaran barang pada database persediaan. Dengan demikian, barang pun telah siap

untuk dikirimkan kepada pelanggan.

Pada saat penyerahan barang, bagian perbekalan melampirkan invoice rangkap 2

(beserta invoice rangkap 1 jika transaksi penjualan secara tunai) dan DO 4 rangkap

untuk ditanda-tangani pelanggan. Invoice rangkap 2 (beserta invoice rangkap 1 jika

transaksi penjualan secara tunai) dan DO rangkap 1 diserahkan kepada pelanggan

sebagai bukti bahwa barang yang dikirim telah diterima oleh pelanggan.

DO rangkap 1 untuk pelanggan

DO rangkap 2 untuk bagian keuangan

DO rangkap 3 untuk arsip bagian administrasi

DO rangkap 4 untuk bagian perbekalan

Setelah pengiriman barang selesai, bagian pengiriman mendistribusikan DO

rangkap 2 yang telah ditanda-tangani pelanggan kepada bagian keuangan sebagai

laporan pengiriman barang. Sedangkan DO rangkap 3 dikembalikan pada bagian

administrasi dan mengarsip DO rangkap 4 sebagai bukti tertulis pengeluaran barang.

Bagian keuangan mencocokkan DO rangkap 2 yang telah ditanda-tangani

pelanggan dengan invoice rangkap 3 yang ada di arsip sementara. Berdasarkan invoice

rangkap 4 yang diterima, bagian akuntansi mencatat transaksi penjualan ke dalam jurnal

penjualan dan sistem menambahkan piutang pelanggan apabila penjualan dilakukan

secara kredit. Kemudian dokumen-dokumen tersebut diarsipkan berdasarkan tanggal.

105

Prosedur Retur Penjualan

Pelanggan dapat melakukan claim terhadap barang yang rusak atau kondisi lain

yang tidak sesuai dengan pesanan. Jangka waktu pengembalian berbeda-beda tergantung

kesepakatan yang tertera dalam perjanjian dengan masing-masing pelanggan. Dalam hal

ini, pelanggan harus melampirkan barang yang di-retur dengan invoice serta DO rangkap

1 yang diterima ketika pengiriman barang.

Bagian administrasi menangani keluhan pelanggan, dan menghubungi bagian

perbekalan untuk memeriksa kondisi barang. Apabila keluhan yang ada sesuai dengan

kebijakan retur perusahaan, maka bagian administrasi akan mencatatnya ke dalam Surat

Retur (SR) sebanyak 4 rangkap sebagai berikut:

SR rangkap 1 untuk pelanggan

SR rangkap 2 untuk bagian akuntansi

SR rangkap 3 untuk bagian perbekalan

SR rangkap 4 untuk arsip bagian administrasi

Berdasarkan retur yang terjadi, bagian perbekalan menerima barang retur.

Sedangkan SR rangkap 2 yang diterima bagian akuntansi dicocokkan dengan invoice

rangkap 4 yang ada diarsip. Surat Retur ini digunakan sebagai dasar pencatatan retur

penjualan dan pengurangan piutang pelanggan.

Barang yang diretur dapat dikembalikan tanpa penukaran atau dengan penukaran

barang sejenis. Apabila atas permintaan pelanggan yang menginginkan bahwa barang

yang diretur agar ditukarkan dengan barang pengganti dengan jenis dan tipe barang yang

sama, bagian administrasi membuat Delivery Order–Retur (DO-Retur) sebanyak 4

rangkap. Surat DO-Retur diserahkan kepada bagian perbekalan untuk selanjutnya akan

dilakukan pengiriman barang seperti prosedur pengiriman standar. Berdasarkan DO-

106

Retur ini, bagian perbekalan menyiapkan sejumlah barang yang dibutuhkan kemudian

kembali melakukan pengiriman barang kepada pelanggan dan melampirkan DO-Retur

untuk ditanda-tangani pelanggan. Setelah pengiriman barang retur selesai, bagian

perbekalan mendistribusikan DO-Retur yang telah ditanda-tangani pelanggan sebagai

berikut:

DO-Retur rangkap 1 untuk pelanggan

DO-Retur rangkap 2 untuk bagian keuangan

DO-Retur rangkap 3 untuk arsip bagian administrasi

DO-Retur rangkap 4 untuk bagian perbekalan

Prosedur Penerimaan Pembayaran dari Pelanggan

Secara berkala, bagian keuangan akan memeriksa Daftar Piutang untuk

mengetahui invoice yang segera jatuh tempo. Bila terdapat piutang telah jatuh tempo

telah dibayarkan pelanggan, bagian keuangan menghubungi pelanggan dan melakukan

penagihan.

Dengan adanya konfirmasi pembayaran dari pelanggan, bagian keuangan

membuat Faktur Pajak Standard (FPS) sebanyak 3 rangkap dan Kuitansi sebanyak 3

rangkap kemudian meminta otorisasi direktur. Pelanggan yang melakukan pembayaran

dengan cara transfer, harus menyerahkan bukti transfer kepada perusahaan. Sedangkan

pembayaran yang dilakukan dengan cek atau giro, maka bagian keuangan harus

memastikan kepada pelanggan dan bank yang bersangkutan bahwa cek atau giro tersebut

dapat dicairkan pada tanggal jatuh tempo.

Ketika melakukan pembayaran, pelanggan menandatangani FPS dan Kuitansi

yang masing-masing berangkap 3. Bagian keuangan juga melampirkan invoice rangkap

107

1 kepada pelanggan, kemudian menyerahkannya beserta FPS rangkap 1 dan Kuitansi

rangkap 1 yang telah ditanda-tangani kepada pelanggan. Dokumen-dokumen yang

diterima pelanggan ini merupakan bukti pembayaran yang lengkap dan sudah lunas.

FPS rangkap 1 untuk pelanggan

FPS rangkap 2 untuk diarsip bagian keuangan

FPS rangkap 3 untuk bagian akuntansi

Kuitansi rangkap 1 untuk pelanggan

Kuitansi rangkap 2 untuk arsip bagian keuangan

Kuitansi rangkap 3 untuk bagian akuntansi

Sedangkan untuk transaksi penjualan yang dilakukan secara tunai, FPS sebanyak

2 rangkap dan Kuitansi 2 rangkap yang dibuat bagian keuangan akan didistribusikan

kepada bagian perbekalan untuk dilampirkan pada saat pengiriman barang beserta

invoice, dan DO. Bagian perbekalan menerima pembayaran dari pelanggan, kemudian

memberikan FPS rangkap 1 dan Kuitansi rangkap 1 yang sudah dicap lunas kepada

pelanggan. Untuk FPS rangkap 2 dan Kuitansi rangkap 2 yang telah ditanda-tangani

pelanggan, dikembalikan ke bagian keuangan untuk diarsip.

Berdasarkan FPS rangkap 3 dan Kuitansi rangkap 3 yang diterima, bagian

akuntansi mencatat penerimaan kas ke dalam jurnal penerimaan kas dan mengurangi

piutang pelanggan. Kemudian rangkap FPS dan rangkap Kuitansi akan diarsip permanen

berdasarkan tanggal.

Secara berkala, manajer keuangan akan melakukan penilaian pelanggan agar

sistem dapat meng-update nilai kredibilitas pelanggan. Bagi pelanggan baru, penilaian

ini tidak berlaku karena belum ada data historis pembelian yang dilakukan pelanggan.

108

Untuk menghindari pemberian kredit yang tidak potensial, pelanggan baru diwajibkan

melakukan transaksi secara tunai saja.

Penilaian pelanggan ini dapat dilakukan ketika sudah terdapat data historis

transaksi penjualan (lima transaksi pertama atau 6 bulan sejak pelanggan didaftarkan).

Penetapan kriteria yang dipakai ditentukan berdasarkan kebijakan manajemen

perusahaan dan kriteria 5 C (Character, Capacity, Capital, Collateral, dan Condition),

dimana pengukurannya menggunakan data historis penjualan per bulan, pembayaran

pelanggan, jumlah retur penjualan pelanggan, dan lama langganan. Berikut tabel yang

menunjukkan pengukuran kriteria dimaksud, dapat dilihat pada tabel 4.2:

Tabel 4.2 Kriteria penetapan limit kredit pelanggan Kriteria Grade A Grade B Grade C Grade D Grade E Bobot

Nilai transaksi per bulan > 80 juta60-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




109

Berikut adalah flowchart yang menggambarkan sistem informasi akuntansi

penjualan, piutang, dan penerimaan kas pada PT. Surya Warfa Kharisma yang

diusulkan, dapat dilihat pada gambar 4.1 sampai gambar 4.5 dan rich picture diusulkan

pada gambar 4.6:

Gambar 4.1 Flowchart Sistem Prosedur Penerimaan Pesanan

110

Gambar 4.2 Flowchart Sistem Prosedur Pengiriman Barang

111

Flowchart Prosedur Penerimaan Pembayaran dari Penjualan Kredit

Bagian AkuntansiBagian Keuangan

Kuitansi (signed)Memeriksa

Invoice jatuh

tempo

1

Membu-at FPS

dan Kuitansi

Bukti Transfer / Cek

1

Disetor ke bank

21

Meminta otorisasi direktur

1

1

2

3

Invoice

Masukan data pembayaran

Menringkas data pembayaran

Kuitansi

Cetak FPS dan Kuitansi

1

21

2

1

Membandingkan dengan invoice

Bukti Transfer / Cek

Meneri-ma Bukti Trasfer /

Cek

Melaku-kan

penagihan

Mengecek Daftar Piutang

Meringkas data piutang Invoice

1

Invoice

3

1

2

invoice

3Bukti Transfer /

Cek

1

2

22

1

3

111

33

T

1

2

pelanggan

1

Kuitansi

FPS1

2

3

1

23

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

112

Gambar 4.4 Flowchart Sistem Prosedur Retur Penjualan (tanpa penukaran)

113

Gambar 4.5 Flowchart Sistem Prosedur Retur Penjualan (dengan penukaran)

114

PelangganBaru

PelangganTetap

BagianAdministrasi

Bagian Perbekalan

Pelanggan

Bagian Administrasi

SR

Board of Directors

DO

MICROSOFT CORPORATION

invoice+

+

+

+

FormPelanggan

DO (signed)


invoice DO (signed)

DO (signed)

Bagian Keuangan

Cek

Bukti Transfer

atau

KuitansiMICROSOFT

CORPORATION

invoice

+

DO

SR

Tagih piutang FPS

1a

2

1b

3

4

5

678

9

10

11

1213a

13b

1

2a2b

12

3

SPH = Surat Penawaran HargaPO = Purchase OrderSC = Sales ContractDO = Delivery OrderInvoice = Faktur PenjualanSR = Surat ReturFPS = Faktur Pajak Standard

Bagian Perbekalan

SPH

SPH (signed)

SC

PO

SPH (signed)

SC (signed)

SC (signed)

SC(signed)

DO

DO+

+

Bagian Keuangan

Bagian Keuangan


invoice

Laporan Jurnal

Bagian Akuntansi

DO (signed)

Bagian Akuntansi

KuitansiFPS

+

Bagian Akuntansi

+


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

115

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.

116

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+ deti l SPH+ Sales Contract+ SPH

Pengiriman

+ Delivery Order+ detil DO

Pembayaran

+ detil Kuitansi+ Kuitansi

Retur

+ detil DO-Retur+ detil Surat Retur+ DO-Retur+ Surat Retur

Penjualan

+ Invoice

User

+ Bag. Admin+ Bag. Akuntansi+ Bag. Keuangan+ Karyawan+ Manajer Keuangan+ Password

pkg Barang

Barang TipeMerek

1..* 1 1..* 1

117

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. AkuntansiBag. Keuangan Manajer Keuangan

KaryawanPassword

118

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

SPHdetil SPH Sales Contract detail SC

1..* 1 0..11 1..*1

pkg Pengiriman

Deliv ery Order detil DO

1..*1

pkg Penjualan

Inv oice

119

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 Returdetil Surat Retur DO-Retur detil DO-Retur

1..* 1 1 1..* 1..*1

120

Gambar 4.16 Class Diagram sistem informasi akuntansi penjualan, piutang, dan penerimaan kas


class System

Merek

Keterangan: SPH = Surat Penawaran Harga DO = Delivery Order

Tipe

Barang

detail SPHSPH

Sales Contract Pelanggan

Inv oice

Surat Retur

Deliv ery Order - Retur

detail KuitansiKuitansi

detail Sales Contract

detail DO

detail Surat Retur

detail Deliv ery Order - Retur

Piutang

Karyawan

Bag. AdministrasiBag. KeuanganBag. AkunManajer Keuangan

DO

Password

1

1..* 1..*

1

1..*

1

1..*

1

1

1..*

1..*1

1

0..1

1..*

1

11..*

1..*1

11..*1..*1

1..* 1

1..* 1

1..*

1

1

1..*

1

1..*

1

1..*

1 1

1

1..*

10..1

1

1..*

1

1..*

121

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 Karyawan

Karyawan

- kd_karyawan: char- nama_karyawan: varchar- divisi: char- jabatan: char- user_name: char

class Password

Password

- user_name: char- user_password: char

122

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 Password

Registered Activ e/mendaftar /login

/mengubah

/logout

class Bag. Administ...

Bag. Administrasi

stm Bag. Administrasi

Activ e

/meretur/mengirim

/megontrak/menawarkan

/menawarkan

123

Tabel 4.4 Keterangan Behavioral Pattern Class Bag. Administrasi Behaviors Attributes

menawarkan no. SPH, tgl akhir berlaku, nama pelanggan, kode barang, kode tipe, kode merek, nama barang, jumlah barang, harga

mengontrak no. Sales Contract, tgl SC, no. SPH, durasi pembayaran, kode barang, jumlah, harga, kode pelanggan, status

mengirim no. DO, tgl pengiriman, no. SC, tujuan pengiriman, alamat pengiriman, kode pelanggan, kode barang, jumlah, no. DO-R

meretur no. SR, no. Invoice, kode pelanggan, kode barang, jumlah retur, tipe retur, keterangan

Bagian Keuangan

Class Bagian Keuangan merupakan kumpulan objek-objek dari user Bagian

Keuangan. Class Bagian Keuangan menggambarkan event dimana Bagian Keuangan

melakukan penjualan dan berstatus Active, kemudian melakukan pekerjaan yang

berhubungan dengan fungsinya secara berulang-ulang, dengan menjual, dan menerima

pembayaran.

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

124

Bagian Akuntansi

Class Bagian Akuntansi merupakan kumpulan objek-objek dari user Bagian

Akuntansi. Class Bagian Akuntansi menggambarkan event dimana Bagian Akuntansi

menjurnal dan berstatus Active, kemudian melakukan pekerjaan yang berhubungan

dengan fungsinya secara berulang-ulang, yaitu menjurnal.

Gambar 4.24 class Bag.Akuntansi Gambar 4.25 behavioral pattern dari class Bag.Akun

Tabel 4.6 Keterangan Behavioral Pattern Class Bag. Akuntansi


menjurnal 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 Manajer Keu...

Manajer Keuangan

stm Manajer Keuangan

Activ e

/menyetujui/menilai

/menilai

125

Tabel 4.7 Keterangan Behavioral Pattern Class Manajer Keuangan Behaviors Attributes

menilai nama pelanggan, limit kredit

menyetujui no. SC, total harga, kode pelanggan, limit kredit tersedia, status

Pelanggan

Class Pelanggan merupakan kumpulan objek-objek dari pelanggan yang sudah

terdaftar di perusahaan. Class Pelanggan menggambarkan event dimana pelanggan

didaftarkan pertama kali sebagai pelanggan baru untuk kemudian berstatus Registered.

Pelanggan berstatus Active, dapat dimulai dengan event menawarkan harga, kemudian

mengontrak, menjual, membayar, meretur, dan menilai.

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 eRegistered/menilai

/menjual

/mengontrak

/menawarkan

/meretur/membayar

/mendaftar /menawarkan_harga

126

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

127

Gambar 4.31 behavioral pattern dari class Barang

Tabel 4.9 Keterangan Behavioral Pattern Class Barang


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

128

Tabel 4.10 Keterangan Behavioral Pattern Class Tipe Behaviors Attributes

mendaftar kode tipe, nama tipe

Merek

Class Merek merupakan kumpulan dari objek-objek merek barang yang dijual di

perusahaan. Class Merek menggambarkan event dimana merek pertama kali didaftarkan

dan berstatus Active.

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

129

Gambar 4.36 class SPH

Gambar 4.37 behavioral pattern dari class SPH

Tabel 4.12 Keterangan Behavioral Pattern Class SPH


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

130

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- l imit_kredit_tersedia: long- status: boolean- subtotal: long- PPN: long- total_harga: long

131

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

132

Tabel 4.15 Keterangan Behavioral Pattern Class detail Sales Contract Behaviors Attributes

mengontrak No. SC, kode barang, jumlah barang, harga satuan mengirim No. SC, kode barang, jumlah barang, harga satuan

Delivery Order

Class Delivery Order merupakan kumpulan dari objek-objek dokumen Delivery

Order yang telah dibuat oleh perusahaan. Class Delivery Order ini menggambarkan

event mengirim barang dan berstatus Active hingga dilakukan penagihan penjualan atau

dalam hal ini membuat invoice.

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]

133

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]

134

Gambar 4.48 class Invoice

Gambar 4.49 behavioral pattern dari class Invoice

Tabel 4.18 Keterangan Behavioral Pattern Class Invoice


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

135

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

136

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

137

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 Proceed/mengirim

/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

138

DO-Retur

Class DO-Retur merupakan kumpulan objek-objek dari dokumen Delivery

Order-Retur yang telah dibuat oleh perusahaan. Class DO-Retur ini menggambarkan

event mengirim barang retur dan berstatus Active hingga barang yang dikirim telah

sampai ke pelanggan.

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

139

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

140

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

SettledReduced /membayar

/membayar

[lunas]

/meretur

/menagih

141

Tabel 4.26 Event Table sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma

Class

Pass

wor

d

Bag

ian

Adm

inis

trasi

Bag

ian

Keu

anga

n

bagi

an A

kunt

ansi

Man

ajer

Keu

anga

n

pela

ngga

n

bara

ng

tipe

mer

ek

SPH

Sale

s Con

tract

Del

iver

y O

rder

Invo

ice

Kui

tans

i

Sura

t Ret

ur

Del

iver

y O

rder

-Ret

ur

SPH

det

ail

SC d

etai

l

DO

det

ail

Kui

tans

i det

ail

SR d

etai

l

DO

-R d

etai

l

piut

ang

Event login * logout * mengubah * mendaftar + + + + + menerima + menawarkan * * * + * mengontrak * * * + + * mengirim * * * + + + * * menjual * * + + + membayar * * * + * + meretur * * * + + * + menjurnal * + + + + menilai * * menyetujui * +

142

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


Actor Bagian Administrasi

Bagian Keuangan

Bagian Akuntansi

Manajer KeuanganUse 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

√

143

4.1.3.1.2 Actors

Berikut ini adalah actor specification dari sistem informasi akuntansi penjualan,


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.

144

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:

145

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 Penjualan

Membuat Laporan Penerimaan Kas

Membuat Laporan Piutang

Membuat Laporan Retur

Membuat Laporan Analisis Umur

Piutang

Membuat Laporan Jurnal Penjualan

Membuat Laporan Jurnal Retur

Penjualan

Membuat Laporan Jurnal Penerimaan

Kas

Melakukan penilaian pelanggan

Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas


Membuat FPS

Mengotorisasi transaksi pending

Bagian Keuangan

Manajer Keuangan

Bagian Akuntansi

Keterangan: SPH = Surat Penawaran Harga FPS = Faktur Pajak Standar DO-R= Delivery Order Retur

Mengupdate Piutang

«extend»

«extend»

«extend»

146

Berikut adalah Use Case Specification dari sistem informasi akuntansi

penjualan, piutang, dan penerimaan kas PT. Surya Warfa Kharisma:

Tabel 4.32 Use Case Specification “Mendata pelanggan”

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

147

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_last_code, generate_no.SC, get_data_SPH, get_limit_kredit_tersedia,

148

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

149

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.43Use Case Specification “Membuat DO-Retur”

150

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


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


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, get_data_Surat_Retur, get_detail_Surat_Retur, remove, save, print

151

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


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


Objects Kuitansi Functions get_data_kuitansi, calculate_total, print

Tabel 4.51 Use Case Specification “Membuat laporan jurnal retur”

Membuat laporan jurnal retur


Objects Surat Retur Functions get_data_surat_retur, calculate_total，print

Tabel 4.52 Use Case Specification “Mengotorisasi transaksi pending”

Mengotorisasi transaksi pending

152

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,


Tabel 4.55 Function List sistem informasi akuntansi penjualan, piutang, dan penerimaan kas


153

Function Type Complexity

Mendata pelanggan read, compute, update medium

get_data_pelanggan read simple get_last_record read simple get_piutang read simple calculate_kredit_tersedia compute simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple go_to_last_record read simple get_to_last_code read simple generate_no.pelanggan compute simple calculate_saldo_piutang compute simple get_limit_kredit read simple calculate_lama_langganan compute simple remove update simple save update simple

Mendata barang read, compute, update medium

get_data_barang read simple get_last_record read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple go_to_last_record read simple get_tipe_barang read simple get_merek_barang read simple calculate_jumlah_tersedia compute simple remove update simple save update simple

Mendata tipe read, compute, update medium

get_data_tipe read simple get_last_record read simple get_last_code read simple generate_no.urut compute simple remove update simple

154

save update simple

Mendata merek read, compute, update medium

get_data_merek read simple get_last_record read simple get_last_code read simple generate_no.urut compute simple remove update simple save update simple

Membuat SPH read, compute, update complex

get_last_record read simple get_last_record_detail read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple go_to_last_record read simple get_last_code read simple generate_no.SPH compute simple get_tipe_barang read simple get_merek_barang read medium get_nama_barang read medium get_kode_barang read medium calculate_total_harga compute simple calculate_subtotal compute simple calculate_PPN compute simple calculate_grand_total compute simple remove update simple save update medium print read simple

Membuat Sales Contract read, compute, update complex

get_last_record read simple get_last_record_detail read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple

155

go_to_last_record read simple get_last_code read simple generate_no.SC compute simple get_data_SPH read medium get_limit_kredit_tersedia read medium get_detail_SPH read medium get_kode_barang read medium calculate_total_harga compute simple calculate_subtotal compute simple calculate_PPN compute simple calculate_grand_total compute simple generate_status read medium remove update simple save update medium print read simple

Membuat Delivery Order read, compute, update complex

get_last_record read simple get_last_record_detail read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple go_to_last_record read simple get_last_code read simple generate_no.DO compute simple get_data_SC read medium get_detail_SC read medium remove update simple save update medium print read simple

Membuat Invoice read, compute, update complex

get_last_record read simple get_record_detail read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple go_to_last_record read simple

156

get_last_code read simple generate_no.Invoice compute simple get_data_DO read medium get_data_SC read medium calculate_subtotal compute simple calculate_PPN compute simple calculate_grand_total compute simple remove update simple save update medium print read simple

Membuat Kuitansi read, compute, update complex

get_last_record read simple get_record_detail read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple go_to_last_record read simple get_last_code read simple generate_no.Kuitansi compute simple get_jumlah_pembayaran read medium get_no.Invoice read medium get_data_invoice read medium get_no.Surat_Retur read medium get_data_retur read medium calculate_tagihan compute simple calculate_total_pembayaran compute simple calculate_sisa compute simple remove update simple save update medium print read simple

Membuat Surat Retur read, compute, update complex

get_last_record read simple get_record_detail read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple

157

go_to_last_record read simple get_last_code read simple generate_no.Surat_Retur compute simple get_data_DO read medium calculate_total_harga compute simple remove update simple save update medium print read simple

Membuat DO-Retur read, compute, update complex

get_last_record read simple get_last_record_detail read simple go_to_first_record read simple go_to_previous_record read simple go_to_next_record read simple go_to_last_record read simple get_last_code read simple generate_no.DO-R compute simple get_data_Surat_Retur read medium get_detail_Surat_Retur read medium remove update simple save update medium print read simple

Membuat laporan penjualan read, compute complex get_data_invoice read medium calculate_total compute medium print read simple

Membuat laporan penerimaan kas read, compute complex get_data_kuitansi read simple get_data_detail_kuitansi read simple calculate_total compute medium print read simple

Membuat laporan piutang read, compute complex get_data_piutang read medium calculate_total compute medium print read simple

158

Membuat laporan analisis umur piutang read, compute complex

get_data_piutang read medium get_data_pembayaran read medium calculate_umur_piutang compute medium calculate_total compute medium print read simple Membuat laporan retur read, compute complex get_data_surat_retur read simple get_data_detail_surat_retur read simple calculate_total compute medium print read simple

Membuat laporan jurnal penjualan

read, compute

complex

get_data_invoive read medium calculate_total compute medium print read simple

Membuat laporan jurnal penerimaan kas read, compute complex

get_data_kuitansi read medium calculate_total compute medium print read simple

Membuat laporan jurnal retur read, compute complex get_data_surat_retur read medium calculate_total compute medium print read simple

Mengotorisasi transaksi pending read, update complex get_data_sales_contract read medium get_limit_kredit read medium get_status read medium save update medium

Melakukan penilaian pelanggan read, compute, update very complex

get_data_pelanggan read medium

159

get_saldo_piutang read medium calculate_kredit_poin compute medium calculate_nilai_kredit compute complex calculate_limit_disarankan compute simple save update medium Mengupdate piutang read, update complex get_data_piutang update medium get_data_pembayaran read medium get_data_penjualan read medium get_data_retur read medium

4.1.3.3 User Interface

Sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya

Warfa Kharisma dirancang dengan user friendly dan menggunakan Bahasa Indonesia dan

Bahasa Inggris yang umum digunakan. Berikut adalah gambaran desain user interface

sistem informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa

Kharisma.

4.1.3.3.1 Dialogue Style

Setiap user interface memiliki sejumlah windows yang dapat digunakan untuk

mendukung pencatatan transaksi penjualan, piutang, dan penerimaan kas PT. Surya

Warfa Kharisma. Selain itu, sistem ini juga menyediakan fasilitas pencetakan informasi

yang dibutuhkan oleh pihak-pihak yang berkepentingan dalam perusahaan. Untuk lebih

jelasnya, daftar windows interface dan hasil pencetakaannya dapat dilihat pada tabel

4.56 berikut.

160

Tabel 4.56 Dialogue Style User Interface Windows Printouts

Login Menu Utama File Change Password Log out Exit Master Pelanggan Barang Tipe Merek Transaction Surat Penawaran Harga Surat Penawaran Harga Sales Contract Sales Contract Delivery Order Delivery Order Invoice Invoice Kuitansi Kuitansi Surat Retur Surat Retur Delivery Order-Retur Delivery Order-Retur Transaksi Kontrak Pending Daftar Piutang Penilaian Pelanggan Report Penjualan Laporan Penjualan Penerimaan Kas Laporan Penerimaan Kas Piutang Laporan Piutang Analisis Umur Piutang Laporan Analisis Umur Piutang Retur Laporan Retur Journal Jurnal Penjualan Laporan Jurnal Penjualan Jurnal Penerimaan Kas Laporan Jurnal Penerimaan Kas Jurnal Retur Laporan Jurnal Retur

4.1.3.3.2 Navigation Diagram

161

Gambar berikut adalah Navigation Diagram yang menyediakan overview

windows user interface dan hubungan antar windows beserta penjelasan dari sistem

informasi akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa

Kharisma, dapat dilihat pada gambar 4.65.

162

Gambar 4.65 Navigation Diagram

163

4.1.3.3.3 User Interface

Gambar 4.66 Window Login

Pertama-tama setiap user harus melakukan login terlebih dahulu dengan

mengentri user name dan password yang sesuai. User menekan tombol “OK”,

kemudian sistem mengecek hak akses user berdasarkan posisinya. Bila ingin

membatalkan proses login, user dapat menekan tombol “Cancel”.

Gambar 4.67 Window Change Password

Tiap user juga dapat melakan pengubahan password nya yang

direkomendasikan oleh sistem untuk diganti setiap beberapa bulan sekali untuk alasan

keamanan. User menginput password sekarang, kemudian menginput password baru

sebanyak dua kali untuk konfirmasi. Setelah menekan tombol “OK”, sistem akan meng-

update data password baru ke dalam database.

164

Gambar 4.68 Window Main Menu

Setelah melakukan login, tampilan user adalah Main Menu dimana submenu

yang dapat diakses user berbeda-beda tergantung dari posisi jabatan user. Dalam hal ini

terdapat lima Main Menu antara lain “File”, “Master”, “Transaction”, “Report”, dan

“Journal”. Di main menu ini, pada menu File, tiap user dapat melakukan Log Out dan

Change Password.

Bagian administrasi dapat mengakses ke menu Master: Pelanggan, Barang,

Tipe, dan Merek. Selain itu bagian administrasi juga memiliki akses pada menu

Transaksi: Surat Penawaran Harga, Sales Contract, Delivery Order, Surat Retur, dan

Delivery Order-Retur.

165

Bagian keuangan memiliki hak akses pada menu Transaksi: Invoice, Kuitansi,

dan Daftar Piutang untuk mengecek piutang pelanggan yang jatuh tempo setiap harinya.

Tugas dan tanggung jawab bagian keuangan yang mencakup pembuatan laporan

memberikan akses bagian keuangan pada semua menu Report, antara lain: Laporan

Penjualan, Laporan Penerimaan Kas, Laporan Piutang, Laporan Analisis Umur Piutang,

dan Laporan Retur.

Bagian akuntansi hanya memiliki akses ke menu Journal, yang antara lain:

Laporan Jurnal Penjualan, Laporan Jurnal Penerimaan Kas, dan Laporan Jurnal Retur.

Sedangkan manajer keuangan mempunyai akses menu Transaksi yang meliputi:

Transaksi Kontrak Pending dan Penilaian Pelanggan.

Gambar 4.69 Window Master Pelanggan

166

Window ini diakses oleh bagian administrasi untuk menambahkan data

pelanggan baru ke dalam database pelanggan, sehingga pada saat mulai proses

penjualan, data pelanggan dapat tampil secara generate oleh sistem. Pendataan

pelanggan meliputi deskripsi nama, no. NPWP, alamat, kota, telp, fax, data piutang,

contact person, dan registrasi pelanggan.

Selain mendaftarkan pelanggan baru, bagian administrasi dapat meng-update

data pelanggan yang sudah ada. Dalam hal ini pemakaian fasilitas tombol navigasi First,

Previous, Next, Last, dan Search dimanfaatkan untuk mencari data pelanggan yang

diinginkan. Pencarian pelanggan yang dimaksud antara lain berdasarkan kode

pelanggan, nama pelanggan, atau kota.

Setelah melakukan penambahan atau pengubahan data pelanggan, penyimpanan

data pelanggan baru atau perubahannya dilakukan dengan menekan tombol Save. Untuk

membatalkan, dapat dilakukan dengan menekan tombol Cancel. Bila data pelanggan

perlu dihapus, dapat menekan tombol Delete.

167

Gambar 4.70 Window Master Barang

Window ini diakses oleh bagian administrasi untuk menambahkan data barang

baru yang dijual oleh perushaan. Pendataan barang ini meliputi input kode barang

dengan ketentuan tiga karakter pertama mendeskripsikan tipe barang, tiga karakter

kedua mendeskripsikan merek barang, tiga karakter selanjutnya mendeskripsikan

rincian barang dengan tipe bersangkutan, dan empat karakter angka terakhir

mendesksipsikan urutan rincian barang.

User memilih tipe barang yang akan didata, apabila tipe barang dimaksud

belum ada, perlu dilakukan penambahan tipe barang dengan menekan tombol “Add

Tipe”, yang menunjuk pada Window Master Tipe. Hal yang sama berlaku untuk

pendataan merek barang yang belum ada, dimana tombol “Add Merek” menunjuk pada

Window Master Merek.

168

Selanjutnya user menginput nama barang, pilih satuan (kilogram, meter, atau

buah), dan harga barang. Tanggal saldo awal dan saldo awal hanya dilakukan sekali

ketika proses konversi sistem lama ke sistem baru untuk mendata jumlah stok barang

terakhir sebelum sistem baru diimplementasi. Sedangkan perhitungan jumlah barang

tersedia dilakukan oleh sistem.

Selain pendataan barang baru, edit atau update data barang dilakukan dengan

menekan tombol Edit. Data barang yang akan di-edit atau di-update dapat dipilih

berdasarkan kode barang, tipe, atau merek barang. User mengentri keyword pencarian

dan menekan tombol Find. Pencarian data barang dapat juga dilakukan menggunakan

fasilitas navigasi First, Previous, Next, dan Last.

Setelah melakukan penambahan atau pengubahan data barang, penyimpanan

data barang baru atau perubahannya dilakukan dengan menekan tombol Save. Untuk

membatalkan, dapat dilakukan dengan menekan tombol Cancel. Bila data barang perlu

dihapus, user dapat menekan tombol Delete.

Gambar 4.71 Window Master Tipe

169

Window ini diakses oleh bagian administrasi yang dapat dilakukan bersamaan

ketika pendataan barang baru hasil penunjukkan tombol Add Tipe di Master Barang

atau dari Main Menu: Master Tipe. Penambahan tipe baru dilakukan dengan menekan

tombol Add, dimana nomor tipe di-generate oleh sistem, kemudian user menginput

nama tipe.

Untuk update data tipe, dilakukan dengan menekan tombol Edit. Setelah

menambah atau mengubah data tipe, penyimpanan atau perubahannya diproses dengan

menekan tombol Save. Untuk membatalkan, dilakukan dengan menekan tombol Cancel.

Bila data tipe perlu dihapus, user dapat menekan tombol Delete.

Gambar 4.72 Window Master Merek

Window ini diakses oleh bagian administrasi yang dapat dilakukan bersamaan

ketika pendataan barang baru hasil penunjukkan tombol Add Merek di Master Barang

atau dari Main Menu: Master Merek. Penambahan merek baru dilakukan dengan

menekan tombol Add, dimana nomor merek di-generate oleh system setelah user

memilih tipe yang diingnkan, kemudian user menginput nama merek.

170

Untuk update data merek, dilakukan dengan menekan tombol Edit. Setelah

menambah atau mengubah data merek, penyimpanan atau perubahannya diproses

dengan menekan tombol Save. Untuk membatalkan, dilakukan dengan menekan tombol

Cancel. Bila data merek perlu dihapus, user dapat menekan tombol Delete.

Gambar 4.73 Window Transaksi Surat Penawaran Harga

Window ini diakses oleh bagian administrasi ketika memulai proses penawaran

harga kepada pelanggan. Untuk membuat Surat Penawaran Harga baru, user menekan

tombol Add New dan memilih nama pelanggan yang akan ditawarkan. Apabila nama

pelanggan belum terdaftar, pendataan pelanggan baru dilakukan dengan menekan

tombol New yang menunjuk pada Master Pelanggan.

171

Selanjutnya, user memilih tangal akhir berlaku, dan mendata barang yang

ditawarkan. Pertama-tama, user memilih tipe barang, kemudian merek yang tampil yaitu

merek yang sesuai dengan tipe. Kemudian user memilih merek, dan nama barang yang

tampil sesuai tipe dan merek. Pemilihan barang dilanjutkan dengan memilih nama

barang, yang menghasilkan kode barang, jumlah barang tersedia, dan harga barang

standar ter-generate oleh sistem.

User mengentri jumlah pesanan dan sistem menghitung total harga, subtotal,

PPN, dan total harga. Setelah mendata penawaran, user menekan tombol Save dan

menyimpan data surat penawaran baru. Sistem juga mengecek ketersediaan barang,

apabila jumlah tidak mencukupi, status SPH yaitu pending.

Selain pendataan baru, edit atau update data SPH dilakukan dengan menekan

tombol Edit. Data SPH yang akan di-edit atau di-update dapat dipilih menggunakan

fasilitas navigasi First, Previous, Next, dan Last. Setelah melakukan penambahan atau

pengubahan data SPH, penyimpanan data SPH baru atau perubahannya dilakukan

dengan menekan tombol Save. Untuk membatalkan, dapat dilakukan dengan menekan

tombol Cancel. Bila data SPH perlu dihapus, user dapat menekan tombol Delete.

172

Gambar 4.74 Window Transaksi Sales Contract

Window ini diakses oleh bagian administrasi ketika mendata kontrak

berdasarkan pesanan pelanggan. Untuk membuat Sales Contract baru, user dapat

menekan tombol Add New dan mulai memasukkan data kontrak. Pertama, user memilih

No. SPH yang diinginkan kemudian sistem men-generate data pelanggan beserta data

penawaran bersangkutan.

User dapat mengentri durasi pembayaran, jumlah barang yang dipesan, dan

mengubah harga satuan. Kemudian sistem menghitung total harga, subtotal, PPN, dan

total harga. User harus mengecek limit kredit pelanggan terlebih dahulu dengan

menekan tombol “Cek Limit”, apabila total harga kontrak melebihi limit kredit tersedia,

status Sales Contract yaitu pending.

173

Selain pendataan baru, edit atau update data Sales Contract dilakukan dengan

menekan tombol Edit. Data Sales Contract yang akan di-edit atau di-update dapat

dipilih menggunakan fasilitas navigasi First, Previous, Next, dan Last. Setelah

melakukan penambahan atau pengubahan data Sales Contract, penyimpanan data Sales

Contract baru atau perubahannya dilakukan dengan menekan tombol Save. Untuk

membatalkan, dapat dilakukan dengan menekan tombol Cancel. Bila data Sales

Contract perlu dihapus, user dapat menekan tombol Delete.

Gambar 4.75 Window Transaksi Delivery Order

174

Window ini diakses oleh bagian administrasi ketika pengiriman barang akan

dilakukan. Untuk membuat Delivery Order baru, user dapat menekan tombol Add New

kemudian memasukkan data pengiriman. User memilih No. Sales Contract yang

diinginkan kemudian sistem men-generate data pelanggan beserta deskripsi barang yang

ada di data kontrak bersangkutan.

Selanjutnya user mengentri pihak pengiriman yang dituju dan alamatnya.

Selain itu, user dapat mengentri jumlah barang yang dikirim. Setelah mendata

pengiriman, user menekan tombol Save untuk menyimpan data pengiriman tersebut.

Selain pendataan baru, edit atau update data Delivery Order dilakukan dengan

menekan tombol Edit. Data Delivery Order yang akan di-edit atau di-update dapat

dipilih menggunakan fasilitas navigasi First, Previous, Next, dan Last. Setelah

melakukan penambahan atau pengubahan data Delivery Order, penyimpanan data

Delivery Order baru atau perubahannya dilakukan dengan menekan tombol Save. Untuk

membatalkan, dapat dilakukan dengan menekan tombol Cancel. Bila data Delivery

Order perlu dihapus, user dapat menekan tombol Delete.

175

Gambar 4.76 Window Transaksi Invoice

Window ini diakses oleh bagian keuangan untuk membuat Invoice. Ketika

membuat Invoice baru, user menekan tombol Add New kemudian memasukkan data

penjualan berdasarkan pengiriman yang dilakukan. User memilih jenis pembayaran,

apakah secara tunai atau kredit, kemudian memilih tanggal jatuh tempo pembayaran.

Selanjutnya user memilih No. Delivery Order yang diinginkan dan sistem men-

generate data pelanggan beserta deskripsi barang sesuai detail pengiriman yang ada.

Selain data Delivery Order, sistem membaca data Sales Contract terkait dan sistem

menghitung total harga, subtotal, PPN, dan total harga.

176

Selain pendataan baru, edit atau update data Invoice dilakukan dengan

menekan tombol Edit. Data Invoice yang akan di-edit atau di-update dapat dipilih

menggunakan fasilitas navigasi First, Previous, Next, dan Last. Setelah melakukan

penambahan atau pengubahan data Invoice, penyimpanan data Invoice baru atau

perubahannya dilakukan dengan menekan tombol Save. Untuk membatalkan, dapat

dilakukan dengan menekan tombol Cancel. Bila data Invoice perlu dihapus, user dapat

menekan tombol Delete.

Gambar 4.77 Window Form Print

Window ini tampil ketika user menekan tombol Print pada Winndow Invoice.

Berdasarkan data Invoice dan Faktur Pajak Standar yang sama, user dapat memilih

pencetakan surat sesuai kebutuhan.

177

Gambar 4.78 Window Transaksi Kuitansi

Window ini diakses oleh bagian keuangan ketika menerima pembayaran dari

pelanggan. Untuk membuat Kuitansi baru, user menekan tombol Add New kemudian

memasukkan data pembayaran berdasarkan penjualan yang terjadi.

User memilih No. invoice, kemudian sistem membaca tanggal jatuh tempo,

serta menghitung total invoice, total retur dan total tagihan yang terkait. Selanjutnya

user mengentri jumlah pembayaran dan sistem menghitung sisa tagihan. User juga

memilih cara pembayaran, mengentri No. Cek/giro bila ada, dan nama bank

bersangkutan.

178

Selain pendataan baru, edit atau update data Kuitansi dilakukan dengan

menekan tombol Edit. Data Kuitansi yang akan di-edit atau di-update dapat dipilih


penambahan atau pengubahan data Kuitansi, penyimpanan data Kuitansi baru atau


dilakukan dengan menekan tombol Cancel. Bila data Kuitansi perlu dihapus, user dapat

menekan tombol Delete.

Gambar 4.79 Window Transaksi Surat Retur

Window ini diakses oleh bagian administrasi ketika menerima retur dari

pelanggan. Untuk membuat Surat Retur baru, user menekan tombol Add New kemudian

memasukkan data retur yang terjadi. User memilih No. Invoice yang bersangkutan dan

sistem men-generate data pelanggan serta penjualan terkait. Selanjutnya user memilih

179

barang yang diretur, dan mengentri jumlahnya. User juga mengentri tipe retur yang

terjadi dan memberi catatan mengenai alasan retur di kolom keterangan.

Selain pendataan baru, edit atau update data Surat Retur dilakukan dengan

menekan tombol Edit. Data Surat Retur yang akan di-edit atau di-update dapat dipilih


penambahan atau pengubahan data Surat Retur, penyimpanan data Surat Retur baru atau


dilakukan dengan menekan tombol Cancel. Bila data Surat Retur perlu dihapus, user

dapat menekan tombol Delete.

Gambar 4.80 Window Transaksi Delivery Order-Retur

180

Window ini diakses oleh bagian administrasi ketika pengiriman barang retur

akan dilakukan. Untuk membuat Delivery Order-Retur baru, user dapat menekan

tombol Add New kemudian memasukkan data pengiriman. User memilih No. Surat

Retur yang diinginkan kemudian sistem men-generate data pelanggan beserta deskripsi

barang yang ada di data retur bersangkutan.

Selanjutnya user mengentri pihak pengiriman yang dituju dan alamatnya.

Selain itu, user dapat mengentri jumlah barang yang dikirim. Setelah mendata

pengiriman, user menekan tombol Save untuk menyimpan data pengiriman tersebut.

Selain pendataan baru, edit atau update data Delivery Order-Retur dilakukan

dengan menekan tombol Edit. Data Delivery Order-Retur yang akan di-edit atau di-

update dapat dipilih menggunakan fasilitas navigasi First, Previous, Next, dan Last.

Setelah melakukan penambahan atau pengubahan data Delivery Order-Retur,

penyimpanan data Delivery Order-Retur baru atau perubahannya dilakukan dengan

menekan tombol Save. Untuk membatalkan, dapat dilakukan dengan menekan tombol

Cancel. Bila data Delivery Order-Retur perlu dihapus, user dapat menekan tombol

Delete.

181

Gambar 4.81 Window Daftar Piutang Jatuh Tempo

Window ini diakses oleh bagian keuangan setiap harinya, sebagai alat bantu

user dalam memerikasa Invoice yang jatuh tempo guna melakukan penagihan. Form ini

dapat diakses dari menu utama setelah user melakukan login. User disajikan informasi

mengenai perhitungan kapan jatuh tempo oleh sistem.

Dalam window ini user tidak melakukan pendataan apapun, sehingga perintah

yang dapat dilakukan user hanya mengakses window atau keluar dengan menekan

Close.

182

Gambar 4.82 Window Transaksi Pending

Window ini diakses oleh Manajer Keuangan untuk melakukan otorisasi pada

transaksi kontrak dengan status pending. Form ini dapat diakses dari menu utama di

bagian Transaksi. User dapat melihat No. Sales Contract, tanggal, nama pelanggan

bersangkutan, limit kredit dan kredit tersedia. User dapat melakukan penilaian

pelanggan untuk melakukan pengubahan limit kredit. Setelah itu, user memilih

mengotorisasi transaksi pending, baik dengan status “Reject” atau “Proceed”. Dengan

status Sales Contract yang Proceed akan memungkinkan dilakukannya pengiriman

barang dan penjualan. Kemudian user menekan tombol Save untuk menyimpan record

dan meng-update status Sales Contract. Untuk membatalkan dapat menekan tombol

Cancel.

183

Gambar 4.83 Window Penilaian Pelanggan

Window ini diakses oleh Manajer Keuangan untuk dalam melakukan penilaian

terhadap kredibilitas pelanggan. User memilih nama pelanggan yang akan dinilai,

kemudian sistem membaca kode pelanggan, limit kredit, saldo piutang, dan kredit

tersedia.

Kemudian user mengentri nilai kriteria penilaian limit kredit pelanggan, antara

lain nilai transaksi per bulannya, ketepatan membayar, jumlah retur, dan lama

langganan. Dengan menekan tombol “Hitung Limit”, sistem melakukan kalkulasi

hingga jumlah limit kredit disarankan. Nilai jumlah limit kredit disarankan adalah

default nilai limit kredit pelanggan yang dapat diubah oleh user berwenang, dalam hal

ini manajer keuangan.

184

Setelah penilaian selesai, user menekan tombol Save untuk menyimpan record,

dan menekan tombol Cancel untuk membatalkan.

Gambar 4.84 Window Laporan Penjualan

Window ini diakes oleh bagian keuangan yang secara berkala atau sesuai

kebutuhan melakukan pencetakan Laporan Penjualan. User memilih penyusunan

laporan berdasarkan tanggal, pelanggan, atau barang. Kemudian user memilih periode

awal dan periode akhir laporan yang diinginkan. Setelah itu, user menekan tombol

Cetak untuk mencetak Laporan.

185

Gambar 4.85 Window Laporan Penerimaan Kas


kebutuhan melakukan pencetakan Laporan Penerimaan Kas. User memilih periode awal

dan periode akhir laporan yang diinginkan. Setelah itu, user menekan tombol Cetak

untuk mencetak Laporan.

Gambar 4.86 Window Laporan Piutang


kebutuhan melakukan pencetakan Laporan Piutang. User memilih periode awal dan

186

periode akhir laporan yang diinginkan. Setelah itu, user menekan tombol Cetak untuk

mencetak Laporan.

Gambar 4.87 Window Laporan Analisis Umur Piutang


kebutuhan melakukan pencetakan Laporan Analisis Umur Piutang. User memilih

periode awal dan periode akhir laporan yang diinginkan. Setelah itu, user menekan

tombol Cetak untuk mencetak Laporan.

Gambar 4.88 Window Laporan Retur Penjualan

187


kebutuhan melakukan pencetakan Laporan Retur Penjualan. User memilih periode awal



Gambar 4.89 Window Laporan Jurnal Penjualan

Window ini diakes oleh bagian akuntansi yang secara berkala atau sesuai

kebutuhan melakukan pencetakan Laporan Jurnal Penjualan. User memilih periode awal



Gambar 4.90 Window Laporan Jurnal Penerimaan Kas

188


kebutuhan melakukan pencetakan Laporan Jurnal Penerimaan Kas. User memilih

periode awal dan periode akhir laporan yang diinginkan. Setelah itu, user menekan

tombol Cetak untuk mencetak Laporan.

Gambar 4.91 Window Laporan Jurnal Retur


kebutuhan melakukan pencetakan Laporan Jurnal Retur. User memilih periode awal dan

periode akhir laporan yang diinginkan. Setelah itu, user menekan tombol Cetak untuk

mencetak Laporan.

189

SURAT PENAWARAN HARGA Kepada Yth: xxx‐50‐xxx No. SPH SPH/yyyy/mm/9999 Alamat xxxxxxxxxxxxxx Tanggal Dicetak dd/mm/yyyy Kota xxxxxxx Tanggal Akhir Berlaku dd/mm/yyyy No. Telp 9999999

Kode Barang Tipe Barang Merek Nama Barang Jumlah

PesananHarga Satuan Total Harga

xxx/xxx/xxx9999 xxxxxxxxxxx xxxxxxxxxx xxxxxxxxxxxxxxxxxxx 99 999.999.999 999.999.999

Subtotal 999.999.999 PPN 10% 99.999.999 Total Harga 999.999.999

Dibuat oleh, Disetujui oleh, Bagian Administrasi Direktur

Gambar 4.92 Rancangan Formulir Surat Penawaran Harga

190

SALES CONTRACT Kepada Yth: xxx‐50‐xxx No. Sales Contract SC/yyyy/mm/9999 Alamat xxxxxxxxxxxxxx Tanggal Dicetak dd/mm/yyyy Kota xxxxxxx No. SPH SPH/yyyy/mm/9999 No. Telp 9999999 Durasi Pembayaran 99 hari


Barang Harga Satuan Total Harga

xxx/xxx/xxx9999 xxxxxxxxx xxxxxxxx xxxxxxxxxxxxxxxx 99 999.999.999 999.999.999

Subtotal 999.999.999 PPN 10% 99.999.999 Total Harga 999.999.999 Dibuat oleh, Disetujui oleh, Bagian Administrasi Direktur

Gambar 4.93 Rancangan Formulir Sales Contract

191

DELIVERY ORDER Kepada Yth: xxx‐50‐xxx No. Delivery Order DO/yyyy/mm/9999 Alamat xxxxxxxxxxxxxxx Tanggal Dicetak dd/mm/yyyy Kota xxxxxxxxxx Tanggal Pengiriman dd/mm/yyyy No. Telp 99999999 No. Sales Contract SC/yyyy/mm/9999 Alamat Pengiriman xxxxxxxxxxxxxxx

Kode Barang Tipe Barang Merek Nama Barang Jumlah Dikirim

xxx/xxx/xxx9999 xxxxxxxxxx xxxxxxxxxx xxxxxxxxxxxxxxx 99 Diterima oleh, Dibuat oleh, Pelanggan Bagian Administrasi

Gambar 4.94 Rancangan Formulir Delivery Order

192

INVOICE

Nama Pelanggan xxx‐50‐xxx No. Invoice INV/yyyy/mm/9999 Alamat xxxxxxxxxxxxxxx Tanggal Dicetak dd/mm/yyyy Kota xxxxxxxxxx Tanggal Jatuh Tempo dd/mm/yyyy No. Telp 99999999 No. Delivery Order DO/yyyy/mm/9999

Kode Barang Tipe Barang Merek Nama Barang Jumlah Barang Harga Satuan Total Harga

xxx/xxx/xxx9999 xxxxxxxxx xxxxxxxx xxxxxxxxxxxxxxxxx 99 999.999.999 999.999.999

Subtotal 999.999.999 PPN 10% 99.999.999 Total Harga 999.999.999 Diterima oleh, Dibuat oleh, Pelanggan Bagian Keuangan

Gambar 4.95 Rancangan Formulir Invoice

193

KUITANSI

No. Kuitansi KUI/yyyy/mm/9999 Tanggal Dicetak dd/mm/yyyy Telah diterima pembayaran dari : (Nama Pelanggan) , dengan rincian sebagai berikut:

No. Invoice Total Invoice Total Retur Total Tagihan Total Bayar Sisa

INV/yyyy/mm/9999 999.999.999 999.999.999 999.999.999 999.999.999 999.999.999

Total 999.999.999 Cara Pembayaran: xxxxxxxxxx Bank xxxxxxxxxxx No. Cek/ Giro: xxxxxxxxxxxx Jumlah Pembayaran: 999.999.999 Dibuat oleh, Disetujui oleh, Bagian Keuangan Direktur

Gambar 4.96 Rancangan Formulir Kuitansi

194

SURAT RETUR Nama Pelanggan xxx‐50‐xxx No. Surat Retur SR/yyyy/mm/9999 Alamat xxxxxxxxxxxxxxx Tanggal Dicetak dd/mm/yyyy Kota xxxxxxxxxx No. Invoice INV/yyyy/mm/9999 No. Telp 99999999


Retur Harga Satuan Total Harga Keterangan

xxx/xxx/xxx9999 xxxxxxxxx xxxxxxxx xxxxxxxxxxxxxxxx 99 999.999.999 999.999.999 xxxxxxxxxxxxxxxxx

Total 999.999.999 Dibuat oleh, Bagian Administrasi

Gambar 4.97 Rancangan Formulir Surat Retur

195

DELIVERY ORDER ‐ Retur Kepada Yth: xxx‐50‐xxx No. Delivery Order DO/yyyy/mm/9999 Alamat xxxxxxxxxxxxxxx Tanggal Dicetak dd/mm/yyyy Kota xxxxxxxxxx Tanggal Pengiriman dd/mm/yyyy No. Telp 99999999 No. Surat Retur SR/yyyy/mm/9999 Alamat Pengiriman xxxxxxxxxxxxxxx


Dikirim

xxx/xxx/xxx9999 xxxxxxxxxxx xxxxxxxxx xxxxxxxxxxxxxxxxxxx 99

Diterima oleh, Dibuat oleh,

Pelanggan Bagian Administrasi

Gambar 4.98 Rancangan Formulir Delivery Order - Retur

196

LAPORAN PENJUALAN (berdasarkan tanggal) PT SURYA WARFA KHARISMA

Periode dd/mm/yyyy to dd/mm/yyyy Dicetak tanggal: dd/mm/yyyy

Tanggal Invoice No. Invoice Nama Pelanggan Total Harga dd/mm/yyyy INV/yyyy/mm/9999 xxxxxxxxxxxxxxxxxxxx 999.999.999

Total 999.999.999

Dibuat oleh, Disetujui oleh, Bagian Keuangan Direktur

Gambar 4.99 Rancangan Laporan Penjualan (berdasarkan tanggal)

197

LAPORAN PENJUALAN (berdasarkan barang) PT SURYA WARFA KHARISMA

Periode dd/mm/yyyy to dd/mm/yyyy Dicetak tanggal: dd/mm/yyyy Kode Barang xxx/xxx/xxx9999 Tipe xxxxxxxxxxxx Nama Barang xxxxxxxxxxxxxxxxxx Merek xxxxxxxxxxxx

No. Invoice Tanggal Invoice Nama Pelanggan Jumlah Barang

Harga Satuan Total Harga

INV/yyyy/mm/9999 dd/mm/yyyy xxxxxxxxxxxxxxxxxxxxxx 99 999.999.999 999.999.999

Total 999.999.999 Kode Barang xxx/xxx/xxx9999 Tipe xxxxxxxxxxxx Nama Barang xxxxxxxxxxxxxxxxxx Merek xxxxxxxxxxxx

No. Invoice Tanggal Invoice Nama Pelanggan Jumlah Barang

Harga Satuan Total Harga

INV/yyyy/mm/9999 dd/mm/yyyy xxxxxxxxxxxxxxxxxxxxxx 99 999.999.999 999.999.999

Total 999.999.999 Dibuat oleh, Disetujui oleh, Bagian Keuangan Direktur

Gambar 4.100 Rancangan Laporan Penjualan (berdasarkan barang)

198

LAPORAN PENJUALAN (berdasarkan pelanggan) PT SURYA WARFA KHARISMA

Periode dd/mm/yyyy to dd/mm/yyyy Dicetak tanggal: dd/mm/yyyy Kode Pelanggan xxx9999 Nama Pelanggan xxx‐50‐xxx

No. Invoice Tanggal Invoice Tanggal Jatuh Tempo Subtotal Harga

INV/yyyy/mm/9999 dd/mm/yyyy dd/mm/yyyy 999.999.999

Total 999.999.999 Kode Pelanggan xxx9999 Nama Pelanggan xxx‐50‐xxx



Total 999.999.999 Kode Pelanggan xxx9999 Nama Pelanggan xxx‐50‐xxx



Total 999.999.999 Dibuat oleh, Disetujui oleh, Bagian Keuangan Direktur

Gambar 4.101 Rancangan Laporan Penjualan (berdasarkan pelanggan)

199

LAPORAN PENERIMAAN KAS PT SURYA WARFA KHARISMA


No. Kuitansi Tanggal Kuitansi

Kode Pelanggan Nama Pelanggan Cara

PembayaranNo.

Dokumen Bank Jumlah Pembayaran

KUI/yyyy/mm/9999 dd/mm/yyyy xxx9999 xxx‐50‐xxx xxxxxxxxx xxxxxxxx xxxxxxx 999.999.999

Total 999.999.999


Gambar 4.102 Rancangan Laporan Penerimaan Kas

200

LAPORAN PIUTANG PT SURYA WARFA KHARISMA


No. Invoice Kode Pelanggan Nama Pelanggan Total

Invoice Total Retur Total Pembayaran Sisa Piutang

INV/yyyy/mm/9999 xxx9999 xxx‐50‐xxx 999.999.999 999.999.999 999.999.999 999.999.999

Total 999.999.999


Gambar 4.103 Rancangan Laporan Piutang

201

LAPORAN RETUR PT SURYA WARFA KHARISMA


No. SR Tgl SR Nama Pelanggan No. Invoice Total Retur Tipe

ReturKeterangan

SR/yyyy/mm/9999 dd/mm/yyyy xxx‐50‐xxx INV/yyyy/mm/9999 999.999.999 xxxxxxxxx xxxxxxxxxxxxxxxxxxx


Gambar 4.104 Rancangan Laporan Retur

202

LAPORAN ANALISIS UMUR PIUTANG PT SURYA WARFA KHARISMA

Periode dd/mm/yyyy to dd/mm/yyyy Dicetak tanggal: dd/mm/yyyy Kode Pelanggan xxx9999

Nama Pelanggan xxx‐50‐xxx

No. Invoice Tgl Invoice Tgl Jatuh Tempo Total Invoice Sisa Piutang

Piutang lewat jatuh tempo

1‐30 hari 31‐60 hari 61‐90 hari > 90 hari

INV/yyyy/mm/9999 dd/mm/yyyy dd/mm/yyyy 999.999.999 999.999.999 Total = = = = = = Kode Pelanggan xxx9999

Nama Pelanggan xxx‐50‐xxx

No. Invoice Tgl Invoice Tgl Jatuh Tempo Total Invoice Sisa Piutang

Piutang lewat jatuh tempo1‐30 hari 31‐60 hari 61‐90 hari > 90 hari

INV/yyyy/mm/9999 dd/mm/yyyy dd/mm/yyyy 999.999.999 999.999.999 Total = = = = = = Grand Total = = = = = = Dibuat oleh, Disetujui oleh,

Bagian Keuangan Direktur

Gambar 4.105 Rancangan Laporan Analisis Umur Piutang

203

LAPORAN JURNAL PENJUALAN PT SURYA WARFA KHARISMA


Tanggal (Invoice) No. Invoice Keterangan

Saldo Debit Saldo KreditDr Cr

dd/mm/yyyy INV/yyyy/mm/9999 xxxxxxxxxx 999.999.999 xxxxxxxxxx 999.999.999 dd/mm/yyyy INV/yyyy/mm/9999 xxxxxxxxxx 999.999.999 xxxxxxxxxx 999.999.999

Total = 999.999.999 999.999.999

Dibuat oleh, Disetujui oleh, Bagian Akuntansi Direktur

Gambar 4.106 Rancangan Laporan Jurnal Penjualan

204

LAPORAN JURNAL RETUR PENJUALAN PT SURYA WARFA KHARISMA


Tanggal (Retur) No. Surat Retur Keterangan

Saldo Debit Saldo Kredit Dr Cr

dd/mm/yyyy SR/yyyy/mm/9999 xxxxxxxxx 999.999.999 xxxxxxxxxx 999.999.999 dd/mm/yyyy SR/yyyy/mm/9999 xxxxxxxxx 999.999.999 xxxxxxxxxx 999.999.999

Total = 999.999.999 999.999.999


Gambar 4.107 Rancangan Laporan Jurnal Retur Penjualan

205

LAPORAN JURNAL PENERIMAAN KAS PT SURYA WARFA KHARISMA


Tanggal (Pembayaran) No. Kuitansi

KeteranganSaldo Debit Saldo Kredit

Dr Cr

dd/mm/yyyy KUI/yyyy/mm/9999 xxxxxxxxx 999.999.999 xxxxxxxxxx 999.999.999 dd/mm/yyyy KUI/yyyy/mm/9999 xxxxxxxxx 999.999.999 xxxxxxxxxx 999.999.999

Total = 999.999.999 999.999.999


Gambar 4.108 Rancangan Laporan Jurnal Penerimaan Kas

206

4.1.3.3.4 Sequence Diagram

Berikut adalah sequence diagram dari masing-masing use case sistem

informai akuntansi penjualan, piutang, dan penerimaan kas PT. Surya Warfa

Kharisma.

Gambar 4.109 Sequence Login to Main Menu

sd Login to MainMenu

User Window Login

alt

[ok]

[cancel]

Password

alt

[true]

[false]

Window MainMenu

refpilih menu Master

refpilih menu Transaksi

refpilih menu Report

refpilih menu Journal

refChange Password

alt

[File]

[Master]

[Transaksi]

[Report]

[Journal]

create()

entry_user_name

entry_password

klik_okget_validasi_user()

validasi_user

create()

pil ih_menu _change_password

pil ih menu_master

pilih_menu_transaksi

pil ih_menu_report

pil ih_menu_journal

clear_screen()

klik_cancelclear_screen()

klik_close

207

Gambar 4.110 Sequence Change Password

sd Change Password

User Window ChangePassword

Karyawan

alt

[ok]

[cancel]

alt

[true]

[false]

create()

entry_user_id

entry_current_password

entry_new_password

entry_confirm_new_password

klik_okget_data_user()

data_user

save()

close()

clear_screen()

klik_cancelclear_screen()

208

Gambar 4.111 Sequence Referensi pilih menu Master

sd pilih menu Master

User

Window MainMenu

alt Window Master

Pelanggan

refMendata pelanggan

Window MasterBarang

refMendata barang

Window Tipe

refMenambah tipe

Window Merek

refMenambah merek

pilih_menu_pelanggan

create()

pil ih_menu_barang

create()

pil ih_menu_tipe

create()

pil ih_menu_merek

create()

209

Gambar 4.112 Sequence Referensi pilih menu Transaksi

sd pilih menu Transaksi

User

Window MainMenu

alt Window SPH

refMembuat SPH

Window SalesContract

refMembuat Sales Contract

Window DeliveryOrder

refMembuat DO

Window Invoice

refMembuat Inv oice

Window Kuitansi

refMembuat Kuitansi

Window SuratRetur

refMembuat Surat Retur

Window DO-Retur

refMembuat DO-Retur

Window TrPending

Window DaftarPiutang

Window PenilaianPelanggan

refMenilai Pelanggan

pil ih_menu_SPH

create()

pil ih_menu_Sales Contract

create()

pil ih_menu_DO

create()

pil ih_menu_invoice

create()

pilih_menu_Kuitansi

create()

pil ih_menu_Surat_Retur

create()

pil ih_DO-Retur

create()

pil ih_tr_kontrak_pending

create()

pil ih_daftar_piutang

create()

pil ih_penilaian_pelanggan

create()

bab 4 perancangan sistem informasi akuntansi penjualan...

Documents