264 pelanggan digunakan oleh bagian kredit yang ingin mengubah limit kredit pelanggan (yang jenis pelanggannya adalah wholeseller). Bagian kredit akan menekan tombol ubah limit, lalu wondow master pelanggan akan tertutup dan terbuka window baru yaitu penilaian pelanggan. Window ini akan dijelaskan pada gambar 4.106.
Gambar 4.93 Window “Barang”
User Interface ini aktif ketika bagian gudang memilih menu master barang. Bagian gudang yang ingin mendata barang baru akan menekan tombol tambah, kemudian akan memilih kategori barang dan jenis barang. Kode barang akan tergenerate, kemudian bagian gudang akan memasukkan data barang tersebut lalu menekan tombol simpan. Jika data barang ingin diubah, maka bagian gudang akan menekan tombol ubah, dan bagian yang dapat diubah adalah lokasi dan harga. Untuk data barang ingin dihapus, bagian gudang dapat menekan tombol hapus setelah memilih data yang ingin dihapus. User Interface ini juga memungkinkan pengguna untuk mencari data
265 barang yang diinginkan dengan lebih cepat. Bagian gudang akan memilih kategori kemudian jenis barang, lalu pada combobox kode barang, akan muncul kode barang apa saja yang sesuai dengan criteria tersebut, bagian gudang akan memilih kode barang tersebut dan menekan tombol cari, lalu data akan muncul pada kolom – kolom di bawahnya.
Gambar 4.94 Window “COA”
User Interface ini aktif ketika bagian akuntansi memilih menu chart of account. Bagian akuntansi yang ingin menambah data COA akan menekan tombol tambah lalu meng-entry data COA yang baru, lalu menekan tombol simpan. Untuk data COA yang ingin diubah, bagian akuntansi dapat menekan tombol ubah dan tombol hapus jika ingin menghapus data COA tersebut.
266
Gambar 4.95 Window “Kategori”
User Interface ini aktif ketika bagian gudang memilih menu kategori. Bagian gudang dapat menggunakan user interface ini untuk melihat data kategori apa saja yang dimiliki perusahaan. Selain itu, kategori barang dapat ditambah dengan cara menekan tombol tambah lalu bagian gudang akan meng-entry data dan menekan tombol simpan. Bagian gudang yang ingin mengubah data kategori barang akan terlebih dahulu memilih data yang ingin diubah lalu menekan tombol ubah kemudian menekan tombol simpan jika data telah selesai diubah atau tombol batal jika data tidak jadi diubah. Tombol hapus berfungsi untuk menghapus data kategori barang yang sudah tidak dipakai lagi oleh perusahaan.
267
Gambar 4.96 Window “Ekspedisi”
User Interface ini aktif ketika bagian gudang memilih menu master ekspedisi. Bagian gudang dapat menggunakan user interface ini untuk melihat ekspedisi apa saja yang digunakan oleh perusahaan dalam mendistribusikan barangnya. Bila bagian gudang ingin menambah data ekspedisi baru, maka bagian gudang akan menekan tombol tambah, lalu kode ekspedisi akan ter-generate, dan bagian gudang akan mengisi data mengenai ekspedisi tersebut lalu menekan tombol simpan. Data ekspedisi juga dapat diubah dengan cara menekan tombol ubah. Data ekspedisi yang dapat diubah yaitu pada alamat kantor pusat dan cabang, serta nomor telpon kantor pusat dan cabang. Jika data telah selesai diisi, maka bagian gudang dapat menekan tombol simpan atau tombol batal untuk membatalkan perubahan pada data ekspedisi.
268
Gambar 4.97 Window “Struk Pembayaran”
User Interface ini aktif ketika bagian kasir memilih menu struk pembayaran. Ketika pelanggan menyerahkan barang yang ingin dibelinya, bagian kasir akan memilih jenis kategori barang yang dibeli kemudian men-scan barcode yang tertera pada barang tersebut, dan barcode tersebut akan muncul pada kolom kode barang. Nama barang dan harga akan muncul dengan sendirinya sesuai dengan kode barang. Kemudian bagian kasir akan mengentri jumlah barang yang dibeli beserta diskonnya. Untuk barang komisi, maka bagian kasir harus mengentri nomor nota penjualan. Kemudian bagian kasir akan memilih jenis pembayaran tunai atau menggunakan kartu kredit. Untuk kartu
269 kredit, bagian kasir akan menggesek kartu pada alat yang telah disediakan lalu pada kolom nomor kartu dan atas nama akan langsung terisi sesuai dengan data pemilik kartu, lalu bagian kasir akan memilih tanggal jatuh tempo. Kolom bayar akan diisi, jika jenis pembayaran yang dipilih adalah tunai. Untuk total penjualan dan kembalian akan terhitung dengan sendirinya. Ketika bagian kasir menekan tombol cetak, maka data akan langsung tersimpan.
Gambar 4.98 Window “Surat Retur Penjualan”
User Interface ini dapat diakses oleh dua bagian yaitu bagian kasir dan bagian gudang. Untuk bagian kasir, user interface ini digunakan untuk mendata barang apa saja yang diretur oleh pelanggan toko. Retur penjualan akan diterima jika pelanggan membawa struk pembayaran, tanggal struk dengan tanggal retur tidak lebih dari dua hari, dan barang tersebut hanya dapat ditukar dengan barang sama namun dengan ukuran yang berbeda. Bagian kasir akan menekan tombol tambah lalu nomor surat retur penjualan akan ter-generate, kemudian nomor struk dan no penilaian barang akan dientri satu persatu. Tanggal struk akan muncul dengan sendirinya. Kemudian pada combobox
270 kode barang lama akan muncul kode barang apa saja yang tersimpan pada data struk pembayaran. Kemudian bagian kasir akan memilih kode barang yang ingin diretur lalu pada combobox kode barang baru akan muncul kode barang apa saja yang bias untuk dijadikan sebagai pengganti barang retur tersebut. Ukuran lama dan baru akan muncul dengan sendirinya sesuai dengan kode barang yang dipilih, lalu bagian kasir akan menekan tomnol tambah yang di sebelah kiri kemudian data pada grid akan bertambah, begitu seterusnya sampai dengan semua barang yang diretur telah dientri. Tombol hapus yang ada pada bagian bawah tombol tambah digunakan untuk menghapus data yang ada pada grid surat retur penjualan. Setelah semua data terisi dengan lengkap, maka bagian kasir akan menekan tombol simpan dan data akan tersimpan. Tombol cetak hanya dapat digunakan oleh bagian gudang yang ingin mencetak surat retur penjualan kemudian mengarsipkannya. Surat ini sebagai digunakan sebagai dasar oleh bagian gudang dalam mengeluarkan barang yang ada digudang pada transaksi retur ini.
271
Gambar 4.99 Window “Surat Pesanan Penjualan”
User Interface ini aktif ketika bagian penjualan memilh menu transaksi surat pesanan penjualan. Bagian penjualan dapat menggunakan menu ini untuk melihat pesanan penjualan yang telah dibuat sebelumnya. Bila bagian penjualan menerima pesanan pembelian dari pelanggan, maka bagian penjualan akan membuat surat pesanan penjualan dengan cara menekan tombol tambah dan nomor surat pesanan penjualan akan ter-generate dengan sendirinya. Bagian penjualan akan mengentri no PO yang diberikan oleh pelanggan lalu memilih kode pelanggan pada combobox kode pelanggan. Nama pelanggan beserta alamat akan tampil dengan sendirinya sesuai dengan kode pelanggan yang dipilih. Sebelum membuat surat ini, bagian penjualan terlebih dahulu akan mengecek saldo limit pelanggan (dengan cara menekan tombol cek limit) dan mengecek pembayaran pelanggan (dengan cara menekan tombol cek bayar). Hal ini dilakukan
272 untuk meningkatkan pengendalian agar pelanggan yang telah melewati saldo limit dan mmeiliki piutang yang lebih dari 90 hari tidak dapat melakukan penjualan. Jika pelanggan tidak memiliki piutang yang jatuh tempo lebih dari 90 hari tetapi saldo limitnya tidak mencukupi maka bagian penjualan akan memberitahukan bagian kredit untuk membuat surat persetujuan kredit yang akan dibahas pada gambar 4.108. Jika manager kredit menyetuji maka bagian penjualan akan mengentri nomor surat persetujuan kredit tersebut dan transaksi dapat dilanjutkan. Bagian penjualan akan memilih kode barang yang dipesan oleh pelanggan lalu mengisi jumlah barang yang ingin dibeli. Nama barang dan harga barang akan muncul dengan sendirinya sesuai dengan kode barang yang dipilih. Sub total, total, PPN, dan total tagihan akan terhitung dengan sendirinya. Bagian penjualan akan menekan tombol tambah pada bagian sebelah kiri bawah jika kode barang dan jumlah barang sudah benar kemudian pada grid detail akan muncul data barang yang dipilih. Begitu seterusnya sampai dengan semua barang yang dipesan pelanggan telah dicatat. Tombol hapus yang berada di bawah tombol tambah digunakan untuk menghapus data barang yang ada di grid detail. Hal ini dilakukan untuk menjaga kemungkinan terjadinya salah input data barang yang dipesan. Setelah semua data selesai dientri, maka bagian penjualan akan menekan tombol cetak. Pada saat menekan tombol cetak ini, maka data pesanan penjualan akan tersimpan pada database. Pada user interface ini juga dimungkinkan untuk bagian penjualan mencari data pesanan penjualan yang dulu dengan cara memilih nomor surat pesanan penjualan yang ada pada combobox surat pesanan penjualan, lalu menekan tombol cari. Data mengenai pesanan penjualan tersebut akan muncul pada kolom – kolom yang ada dibawahnya.
273
Gambar 4.100 Window “Surat Permintaan Barang”
User Interface ini aktif ketika bagian penjualan memilih menu transaksi surat permintaan barang. Bagian penjualan dapat menggunakan user interface ini untuk melihat data barang yang apa saja dan kepada siapa barang tersebut dikonsinyasikan. Surat permintaan barang akan dibuat setiap bulan. Bagian penjualan yang ingin membuat surat ini akan menekan tombol tambah, kemudian nomor surat permintaan barang akan ter-generate dengan sendirinya. Bagian penjualan akan mengentri kode pelanggan, kemudian nama pelanggan dan alamat pelanggan akan muncul sesuai dengan kode pelanggan tersebut. Bagian penjualan akan memilih tanggal batas ambil jika barang konsinyasi tersebut tidak laku terjual. Bagian penjualan akan memilih kode barang pada combobox kode barang kemudian mengisi jumlah barang yang ingin dikonsinyasikan. Nama barang dan harga barang akan muncul dengan sendirinya sesuai dengan kode barang yang dipilih. Total penjualan akan terhutung menggunakan sistem.
274 Setelah memilih mengisi jumlah, maka bagian penjualan akan menekan tombol tambah yang ada pada groupbox detail surat permintaan barang kemudian data barang yang telah dipilih akan masuk ke dalam grid detail. Begitu seterusnya sampai semua data selesai dientri. Setelah data seleai dientri maka bagian penjualan akan menekan tombo cetak. Pada saat menekan tombol cetak, maka data tersebut akan tersimpan dalam database.
Gambar 4.101 Window “Surat Jalan”
User Interface ini aktif ketika bagian gudang memilih menu surat jalan. Bagian gudang dapat menggunakan user interface ini untuk melihat semua surat jalan yang pernah dibuat oleh perusahaan. Ketika bagian gudang ingin membuat surat jalan yang baru, maka bagian gudang akan menekan tombol tambah lalu no surat jalan akan tergenerate dengan sendirinya. Pada combobox No SPP dan No SPB akan tertera no surat
275 yang belum dibuat surat jalannya. Satu surat jalan hanya untuk satu surat pesanan penjualan atau hanya untuk saru surat permintaan barang. Setelah bagian gudang memililh nomor surat (baik itu nomor surat pesanan penjualan maupun nomor surat permintaan barang), maka kode pelanggan, nama pelanggan, alamat pelanggan, No PO dan grid detail barang akan muncul dengan sendirinya. Khusus untuk surat permintaan barang, No Po tidak akan muncul. Setelah itu bagian gudang akan menekan tombol cetak. Pada saat menekan tombol ini, maka data mengenai surat jalan akan tersimpan ke dalam database dan meng-update status surat. Tombol batal dapat digunakan ketika bagian gudang tidak jadi membuat surat jalan.
Gambar 4.102 Window “Faktur Penjualan”
User Interface ini aktif ketika bagian akuntansi memilih menu faktur penjualan. Bagian akuntansi dapat menggunakan menu ini untuk melihat data faktur penjualan yang sudah pernah dibuat oleh perusahaan. Selain itu, bila bagian akuntansi ingin membuat
276 faktur penjualan yang baru, maka bagian akuntansi akan menekan tombol tambah, kemudian nomor faktur penjualan akan ter-generate dengan sendirinya. Bagian akuntansi akan memilih nomor surat jalan yang ada pada combobox No SJ, lalu data – data yang terkait akan muncul sesuai dengan namanya. Setelah itu bagian akuntansi menekan tombol cetak untuk mencetak faktur penjualan dan tombol batal untuk membatalkan pembuatan faktur tersebut.
User Interface ini juga memudahkan
pengguna untuk mencari data faktur yang pernah dibuat dengan memilih no faktur penjualan lalu menekan tombol cari.
Gambar 4.103 Window “Surat Tagih”
User Interface ini aktif ketika bagian keuangan memilih menu surat tagih. Bagian keuangan dapat menggunakan user interface ini untuk melihat data surat tagih yang sudah pernah dibuat dan dikirimkan ke pelanggan. Bagian keuangan dapat melihat
277 daftar tagih user interface daftar tagih yang ada pada lampiran 55. Ketika bagian keuangan ingin mencetak surat tagih yang baru, maka bagian keuangan akan menekan tombol tambah lalu memilih periode tagih, nomor surta tagih akan ter-generate langsung. Bagian keuangan akan menginput kode pelanggan. Nama dan alamat pelanggan akan langsung muncul sesuai dengan kode pelanggan. Bagian keuangan akan memilih no faktur penjualan pada combobox no faktur dan kolom total tagihan akan terisi langsung. Lalu bagian keuangan akan menekan tombol tambah yang berada disebelah kanan combobox no faktur dan data akan masuk ke dalam grid surat tagih, begitu seterusnya sampai semua data selesai dimasukkan. Setelah itu bagian keuangan akan menekan tombol cetak untuk mencetak surat tagih atau tombol batal untuk membatalkan tagihan yang ingin dibuat. Ketika menekan tombol cetak, data surat tagih akan langsung tersimpan dalam database.
278
Gambar 4.104 Window “Bukti Penerimaan Kas”
User Interface ini aktif ketika bagian keuangan memilih menu bukti penerimaan kas. Bagian keuangan dapat menggunakan user interface ini untuk melihat bukti – bukti yang telah dibuat oleh perusahaan. Ketika bagian keuangan menerima pembayaran dari pelanggan, maka bagian keuangan akan membuat bukti penerimaan kas yang baru dengan cara menekan tombol tambah, dan nomor bukti penerimaan kas akan tergenerate dengan sendirinya. Bagian keuangan akan memilih jenis bukti penerimaan kas yaitu DP, Pelunasan, atau Konsinyasi. Kemudian bagian keuangan akan mengentri no faktur yang dibayar serta oleh pelanggan yang mana, lalu memilih jenis pembayaran. Groupbox jenis pembayaran transfer akan aktif ketika jenis pembayaran transfer yang dipilih, begitu juga pada giro. Setelah mengisi data dengan lengkap, maka bagian keuangan akan menekan tombol cetak untuk mencetak bukti tersebut dan dikirimkan pada pelanggan. Ketika menekan tombol cetak, data penerimaan kas tersebut akan langsung tersimpan pada database.
279
Gambar 4.105 Window “Bukti Setor Kasir”
User Interface ini aktif ketika bagian keuangan memilih menu bukti setor kasir. User Interface ini dapat digunakan oleh bagian keuangan untuk melihat bukti – bukti yang telah dibuat selama ini dengan cara menekan tombol first, previous, next, dan end. Bagian keuangan akan mencetak bukti setor kasir setiap harinya setelah menerima uang penjualan toko dari kasir. Bagian keuangan akan menekan tombol tambah dan nomor bukti setor kasir akan ter-generate dengan sendirinya. Kemudian bagian keuangan akan memilih kode karyawan yang menyerahkan uang tersebut dan memilih nomor struk awal dan akhir yang diserahkan. Nama karyawan dan jumlah uang akan terhitung dengan sendirinya. Jumlah uang akan terhitung sesuai dengan uang tunai yang diterima. Setelah, itu bagian keuangan akan menekan tombol cetak dan data akan tersimpan langsung ke database. Tombol batal digunakan ketika bagian keuangan tidak jadi membuat bukti setor kasir.
280
Gambar 4.106 Window “Penilaian Pelanggan”
User Interface ini aktif ketika bagian kredit menekan tombol ubah limit pada window master pelanggan, dimana jenis pelanggan merupakan wholeseller. Nomor penilaian akan ter-generate langsung, kode pelanggan dan nama pelanggan juga akan langsung muncul. Data – data seperti karakter, kapasitas, capital, kolateral, kondisi, dan penjualan pertama akan dientri oleh staf bagian kredit. Grade, persentase kenaikan, dan jumlah limit akan terhitung menggunakan sistem. Kriteria – kriteria penilaian yang digunakan tercantum pada lampiran 50 .
281
Gambar 4.107 Window “Ubah Limit”
User Interface ini aktif ketika bagian kredit memilih menu ubah limit. Bagian kredit akan mengubah limit kredit pelanggan setipa enam bulan sekali. Pelanggan yang memiliki limit kredit hanyalah jenis pelanggan wholeseller. Bagian kredit akan memilih periode pengubahan limit lalu menekan tombol ubah limit. Data pelanggan yang diubah akan tampil pada grid di bagian bawah periode. Pada saat tombol ubah limit ditekan, maka saldo limit pelanggan juga akan ter-update dengan sendirinya. Untuk penentuan skor dapat dilihat pada lampiran 51.
282
Gambar 4.108 Window “Surat Persetujuan Kredit”
User Interface ini aktif ketika bagian kredit memilih menu surat persetujuan kredit. Surat persetujuan kredit dibuat apabila terdapat pelanggan yang ingin melakukan penjualan namun saldo limit kreditnya tidak mencukupi. Staf bagian kredit membuat surat persetujuan kredit dengan mengentri kode pelanggan, permohonan penjualan, dan alasan permohonan tersebut, kemudian menyimpan datanya. Setelah itu, manager bagian kredit akan memberikan persetujuan pada groupbox persetujuan (yang hanya dapat diakses oleh manager kredit) lalu mencetak dan memberikannya pada bagian penjualan. Ketika tombol cetak ditekan, maka database akan ter-update.
283
Gambar 4.109 Window “Laporan Kasir Harian”
User Interface ini aktif ketika bagian kasir memilih menu laporan kasir harian. Bagian kasir setiap harinya akan mencetak laporan kasir harian yang akan diberikan pada bagian keuangan bersama dengan struk – struk dan uang hasil penjualan toko harian. Bagian kasir akan memilih tanggal laporan lalu menekan tombol cetak. Ketika tombol cetak ditekan, database yang terkait dengan pencetakkan laporan ini akan dihasilkan.
Gambar 4.110 Window “Laporan Penilaian Pelanggan”
284 User Interface ini aktif ketika bagian kredit memilih menu laporan penilaian pelanggan. Laporan ini digunakan untuk mengetahui data mengenai pelanggan baru dan besar limit pelanggan tersebut untuk pertama kalinya. Bagian kredit akan memilih periode tanggal laporan yang digunakan kemudian menekan tombol cetak. Ketika tombol cetak ditekan, maka semua database yang terkait akan dipanggil untuk menghasilkan laporan ini. Untuk rancangan dan hasil dari laporan ini dapat dilihat pada lampiran.
Gambar 4.111 Window “Laporan Perubahan Limit”
User Interface ini aktif ketika bagian kredit memilih menu laporan perubahan limit. Laporan ini digunakan untuk mengetahui besarnya kenaikan limit dari setiap pelanggan lama. Bagian kredit akan memilih periode tanggal laporan yang digunakan kemudian menekan tombol cetak. Ketika tombol cetak ditekan, maka semua database yang terkait akan dipanggil untuk menghasilkan laporan ini. Untuk rancangan dan hasil dari laporan ini dapat dilihat pada lampiran.
285
Gambar 4.112 Window “Laporan Kredit Yang Disetujui”
User Interface ini aktif ketika bagian kredit memilih menu laporan kredit yang disetujui. Laporan ini digunakan pihak managemen untuk mengetahui berapa banyak pelanggan yang overlimit disetujui melakukan penjualan kredit. Bagian kredit akan memilih periode tanggal laporan yang digunakan kemudian menekan tombol cetak. Ketika tombol cetak ditekan, maka semua database yang terkait akan dipanggil untuk menghasilkan laporan ini. Untuk rancangan dan hasil dari laporan ini dapat dilihat pada lampiran.
286
Gambar 4.113 Window “Laporan Penjualan”
User Interface ini aktif ketika bagian akuntansi memilih menu laporan penjualan. Terdapat empat jenis laporan penjualan yang dapat dihasilkan yaitu laporan penjualan komisi (yang ditujukan pada pihak consignor dan dibuat setiap bulan), laporan penjualan kredit (untuk mengetahui total penjualan kredit perusahaan), laporan penjualan faktur jatuh tempo (untuk mengetahui piutang pelanggan yang telah jatuh tempo), dan laporan aging schedule (untuk mengetahui umur piutang setiap pelanggan, jadi dapat terlihat piutang telah jatuh tempo atau yang telah melebihi 90 hari). Bagian penjualan akan memilih periode tanggal laporan yang digunakan kemudian menekan tombol cetak. Ketika tombol cetak ditekan, maka semua database yang terkait akan dipanggil untuk menghasilkan laporan ini. Untuk rancangan dan hasil dari laporan ini dapat dilihat pada lampiran.
287
Gambar 4.114 Window “Laporan Penerimaan Kas”
User Interface ini aktif ketika bagian keuangan memilih menu laporan penerimaan kas. Terdapat tiga jenis laporan yang dapat dihasilkan yaitu laporan DP (untuk mengetahui total DP yang telah dibayarkan oleh wholeseller), laporan pelunasan (untuk mengetahui total pelunasan yang telah dibayarkan oleh wholeseller) dan laporan konsinyasi (untuk mengetahui total penerimaan kas dari penjualan konsinyasi yang telah dibayarkan oleh wholeseller). Bagian keuangan akan memilih periode tanggal laporan yang digunakan kemudian menekan tombol cetak. Ketika tombol cetak ditekan, maka semua database yang terkait akan dipanggil untuk menghasilkan laporan ini. Untuk rancangan dan hasil dari laporan ini dapat dilihat pada lampiran.
288
Gambar 4.115 Window “Jurnal”
User Interface ini aktif ketika bagian akuntansi memilih menu jurnal. Terdapat tiga jenis jurnal yang dapat dihasilkan yaitu jurnal penjualan (untuk mencatat setiap transaksi penjualan kredit perusahaan), jurnal penerimaan kas (untuk mencatat penerimaan kas yang diterima oleh perusahaan termasuk dari penjualan tunai maupun kredit), dan jurnal konsinyasi (untuk mencatat transaksi penjualan konsinyasi perusahaan seperti pada saat barang konsinyasi keluar, ketika barang tersebut tidak laku terjual sehingga harus kembali lagi, atau ketika perusahaan menerima kasil penjualan konsionyasinya). Bagian akuntansi akan memilih periode tanggal laporan yang digunakan kemudian menekan tombol cetak. Ketika tombol cetak ditekan, maka semua database yang terkait akan dipanggil untuk menghasilkan laporan ini. Untuk rancangan dan hasil dari laporan ini dapat dilihat pada lampiran. Nama – nama juranl ini bukan dimaksudkan untuk penamaan jurnal khusus.
289 4.1.3.4
The Technical Platform Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama dikembangkan menggunakan bahasa pemrograman VB.Net melalui alat Microsoft Visual Studio 2005 dan basis data dikembangkan menggunakan SQL Server 2000, semua ini didukung dengan sistem operasi Microsoft Windows Vista. User Interface yang digunakan sesuai dengan standar windows application, dan akan dioperasikan menggunakan personal computer, mouse, keyboard, dan printer.
4.1.4
Recommendations Terdapat
beberapa
hal
yang
harus
diperhatikan
dalam
pengembangan Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama, yaitu: the system’s usefulness and feasibility, strategy, dan development economy.
4.1.4.1
The System’s Usefulness and Feasibility Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas yang akan dikembangkan ini dapat membantu dan mempermudah para pengguna dalam pencatatan transaksi–transaksi penjualan, piutang, dan penerimaan kas. Selain itu, sistem ini juga dapat menghasilkan berbagai laporan yang dibutuhkan oleh managemen, seperti: laporan penjualan barang komisi, laporan penjualan kredit, laporan faktur jatuh tempo, laporan piutang yang belum dibayar, laporan penerimaan kas dp,
290 laporan penerimaan kas pelunasan, laporan penerimaan kas konsinyasi, dan laporan penilaian pelanggan. Laporan–laporan ini dapat membantu managemen dalam aktivitas pengendalian dan pengambilan keputusan yang lebih baik.
4.1.4.2
Strategy Strategi yang akan digunakan dalam pengembangan Sistem informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama adalah dengan melakukan prototyping, metode ini dapat mengkonfirmasikan kesesuaian antara kebutuhan perusahaan serta kebutuhan pengguna sistem dengan fungsionalitas sistem yang akan dibangun. Dan dalam kegiatan implementasi terutama dalam proses konversi, akan dilakukan secara pararel, sehingga pengguna dapat beradaptasi terlebih dahulu menggunakan sistem yang baru kemudian setelah semua masalah dapat teratasi, maka sistem yang lama akan dihapus. Hal ini dilakukan untuk mengurangi risiko kegagalan dalam pengimplementasian sistem baru.
4.1.4.3
Development Economy Pengembangan Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama diperkirakan membutuhkan sumber daya manusia, yaitu satu orang system analyst, satu orang programmer, satu orang database specialist, dan bila memungkinkan, ketiga peran di atas dapat dirangkap oleh satu orang. Waktu yang
291 diperlukan untuk pengembangannya kurang lebih enam bulan dan juga membutuhkan modal kurang lebih dua juta rupiah untuk membiayai sumber daya manusia dalam pengembangan sistem.
4.2
Design Document
4.2.1
The Task Berikut ini akan dijelaskan deskripsi serta quality goals dari Perancangan Sistem informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama, dimulai dengan purpose, correction to the analysis, dan quality goals.
4.2.1.1
Purpose Tujuan
dari
Pengembangan
Sistem
Informasi
Akuntansi
Penjuialan, Piutang, dan Penerimaan Kas pada CV. Dekatama adalah untuk mendukung pencatatan transaksi penjualan, piutang,
dan
penerimaan kas serta pengendalian internalnya. Penjualan pada CV. Dekatama terbagi menjadi tiga jenis yaitu penjualan tunai yang hanya ada pada toko, penjualan kredit pada wholeseller, dan penjualan konsinyasi dimana CV. Dekatama dapat bertindak sebagai consignee maupun consignor. Proses penjualan tunai dimulai dari proses pembuatan struk pembayaran, proses penanganan retur penjualan toko, seperti pembuatan surat retur penjualan, proses pembuatan laporan kasir harian, serta proses pembuatan bukti setor kasir. Sedangkan dalam proses penjualan kredit pada wholeseller, dimulai dari proses pendataan pelanggan untuk
292 menentukan limit kreditnya. Limit kredit tiap pelanggan akan mengalami perubahan setiap enam bulan sekali. Setelah itu, proses pembuatan surat pesanan penjualan, proses pembuatan surat persetujuan kredit (jika saldo limit pelanggan tidak cukup), proses pembuatan surat jalan, proses pembuatan faktur penjualan, proses pembuatan surat tagih, dan bukti penerimaan kas. Untuk jenis penjualan konsinyasi, dimana CV. Dekatama bertindak
sebagai consignor, prosesnya dimulai dari
pembuatan surat permintaan barang yang dibuat oleh bagian penjualan, kemudian proses pembuatan surat jalan oleh bagian gudang lalu proses pembuatan faktur penjualan dan bukti penerimaan kas.
4.2.1.2
Correction to The Analysis Terdapat beberapa koreksi terhadap class diagram yang terdapat pada analysis document, hal ini tercermin dalam revised class diagram. Pada bagian 4.2.4 hasil dari revised class diagram akan tergabungkan pada deskripsi model component.
4.2.1.3
Quality Goals Kualitas dari Perancangan Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama difokuskan pada beberapa aspek berikut:
Tabel 4.45 Kriteria Perancangan Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama
293 Criteria Usable Secure Efficient Correct Reliable Maintainable Testable Flexible Comprehensible Reusable Portable Interoparble
4.2.2
Very Important √
Important
Less Important
Irrelevant
Easily Fulfilled
√ √ √ √ √ √ √ √ √ √ √
Technical Platform Berikut ini akan dideskripsikan equipment, system software, system interface, dan design language pada perancangan aplikasi Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama.
4.2.2.1
Equipment Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama akan menggunakan arsitektur client/server. Setiap client akan terhubung dengan server menggunakan jaringan lokal (LAN), client sendiri akan menggunakan platform PC (Personal Computer). Berikut adalah tabel yang berisikan spesifikasi piranti keras yang dibutuhkan:
294 Tabel 4.46 Spesifikasi Piranti Keras yang Dibutuhkan Specification Processor Memory Hard disk drive Monitor Keyboard Mouse Printer Operating system
4.2.2.2
Client Core 2
Intel Duo T6500 1 GB Memory 80 GB 15” Phillips Logitec Logitec Epson Stylus C90 Microsoft Windows Vista
Server Core 2
Intel T6500 2 GB Memory 320 GB Microsoft 2000 Server
Duo
Windows Advanced
System Software Perancangan Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama akan menggunakan Microsoft Visual Studio 2005 dengan bahasa pemrograman VB.Net (Visual Basic.Net) dan menggunakan Microsoft SQL Server 2000 sebagai basis datanya.
4.2.2.3
System Interface Sistem ini membutuhkan printer yang dapat mencetak dokumen dan berbagai laporan, dimana setiap client akan memiliki satu buah printer. Sistem ini memiliki interface untuk berhubungan dengan printer sehingga printer dapat digunakan oleh para client.
295 4.2.2.4
Design Language Notasi yang digunakan untuk design document adalah UML Notation.
4.2.3
Architecture Berikut ini akan dideskripsikan komponen arsitektur, proses arsitektur, dan standar dari rancangan yang diaplikasikan pada perancangan aplikasi Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama.
4.2.3.1
Component Architecture Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama dirancang menggunakan arsitektur client/server dengan jenis distribusi centralized data, dimana pada server akan terdapat model component, dan pada client akan terdapat function component dan user interface component. Deskripsi mengenai function component akan dibahas pada bagian 4.2.4.
296
Gambar 4.116 Component Diagram Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama.
297 4.2.3.2
Process Architecture Untuk arsitektur proses pada Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama, digunakan pole distribusi centralized pattern, yaitu client memiliki komponen user interface, function, system interface, dan external device yaitu printer. Sedangkan untuk server memiliki komponen model dan system interface.
298
Gambar 4.117 Deployment Diagram Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama
299 4.2.3.3
Standards Standar perancangan yang digunakan pada Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama mengikuti standar Window Application, baik tampilan umumnya maupun pesan kesalahan. Berikut ini contoh beberapa pesan kesalahan:
Gambar 4.118 Contoh Pesan Kesalahan pada Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama
4.2.4
Components Berikut ini akan dideskripsikan model component, function component, dan user interface component dari Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama.
300 4.2.4.1
Model Component Model component pada Sistem Informasi Akunatansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama, berisikan class diagram hasil revisi dari class diagram yang ada pada analysis document.
A.
Structure Hasil analisis class diagram pada analysis document direvisi menjadi revised class diagram menggunakan metode representasi atas private events dan common events.
301
Gambar 4.119 Revised Class Diagram untuk Model Component Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama
302 B.
Classes Berikut ini akan dideskripsikan tujuan, atribut, dan operasi dari class–class yang ada pada model component.
1. Barang Tujuan: Mendata informasi mengenai barang – barang yang dijual oleh perusahaan. Atribut: kd_barang, kd_kategori, nama_barang, jenis_barang, jumlah, harga, pemilik, lokasi, ukuran, sex, warna. Operasi: Mendaftarkan barang.
2. COA Tujuan: Mendata chart of account yang digunakan oleh perusahaan Atribut: kd_COA, deskripsi. Operasi: Mendaftarkan COA.
3. Kategori Tujuan: Mendata kategori barang yang ada pada perusahaan. Atribut: kd_kategori, nama kategori. Operasi: Mendaftarkan kategori.
4. Ekspedisi Tujuan: Mendata informasi mengenai ekspedisi yang digunakan oleh perusahaan.
303 Atribut: kd_ekspedisi, nama_ekspedisi, kantor_pusat, tlp_pusat, kantor_cabang, tlp_cabang. Operasi: Mendaftarkan ekspedisi.
5. Pelanggan Tujuan: Mendata informasi mengenai pelanggan tetap perusahaan baik itu wholeseller maupun consignee dan consignor. Atribut: kd_pelanggan, nama_pelanggan, jenis_pelanggan, alamat, telpon, NPWP, no_penilaian, limit_kredit. Operasi: Mendaftarkan pelanggan.
6. Kartu Piutang Tujuan: Mendata informasi mengenai piutang pelanggan perusahaan. Atribut: tanggal, no_fakturpenjualan, no_BPK, debit, kredit. Operasi: Mendaftarkan pelanggan.
7. Karyawan Tujuan: Mendata informasi mengenai karyawan perusahaan. Atribut: kd_karyawan, nama_karyawan, alamat, telpon, jabatan, password. Operasi: Mendaftarkan karyawan
304 8. Struk Pembayaran Tujuan: Mendata informasi mengenai struk yang pernah dibuat oleh perusahaan. Atribut:
no_struk,
jenis_pembayaran,
no_kartu,
atas_nama,
tanggal_jatuh_tempo, bayar, total, kd_karyawan, tanggal. Operasi: Menerima pembayaran.
9. Surat Retur Penjualan Tujuan: Mendata informasi mengenai barang yang diretur oleh pelanggan ke perusahaan selama ini. Atribut: no_SRP, no_Struk, no_Penilaian, jumlah, tanggal. Operasi: Menerima retur.
10. Bukti Setor Kas Tujuan: Mendata informasi mengenai kas yang diserahkan oleh bagian kasir ke bagian keuangan. Atribut: no_BSK, no_struk, kd_karyawan, tanggal. Operasi: Menerima setoran.
11. Surat Pesanan Penjualan Tujuan: Mendata informasi mengenai pesanan yang telah ditangani oleh perusahaan. Atribut: no_SPP, no_PO, kd_pelanggan, kd_karyawan, total, PPN, total_tagihan, no_SPK, status.
305 Operasi: Menerima pesanan.
12. Surat Permintaan Barang Tujuan: Mendata informasi mengenai surat permintaan barang yang telah dibuat oleh perusahaan. Atribut:
no_SPB,
kd_pelanggan,
kd_karyawan,
total,
PPN,
total_tagihan. Operasi: Membuat SPB
13. Surat Jalan Tujuan: Mendata informasi mengenai surat jalan yang telah dibuat oleh perusahaan. Atribut: no_SJ, no_SPP, no_SPB, kd_karyawan, tanggal. Operasi: Membuat surat jalan.
14. Faktur Penjualan Tujuan: Mendata informasi mengenai faktur – faktur penjualan yang telah dibuat oleh perusahaan. Atribut: no_fakturpenjualan, no_SJ, kd_karyawan, tanggal. Operasi: Membuat tagihan.
15. Surat Tagih Tujuan: Mendata informasi mengenai pelanggan dan faktur – fakturnya yang belum dibayarkan.
306 Atribut: no_ST, no_BPK, kd_karyawan, tanggal. Operasi: Menagih pelanggan.
16. Bukti Penerimaan Kas Tujuan: Mendata informasi mengenai jenis – jenis penerimaan kas yang diterima oleh perusahaan beserta dengan data – data yang terkait. Atribut:
no_BPK,
no_fakturpenjualan,
jenis_pembayaran,
tujuan_bank_transfer, tanggal_transfer, jumlah_transfer, tanggal_cair, tanggal_giro,
asal_bank,
tujuan_bank_giro,
jumlah_giro,
tanggal_diterima, kd_karyawan, tanggal, jenis_penerimaan_kas. Operasi: Menerima DP, menerima pelunasan, menerima konsinyasi.
17. Penilaian Pelanggan Tujuan: Mendata limit kredit setiap pelanggan beserta saldo limitnya. Atribut: kd_limit, kd_pelanggan, karakter, kapasitas, kolateral, kondisi, frekuensi_penjualan, besar_penjualan, kd_karyawan, tanggal. Operasi: Menilai Pelanggan
18. Surat Persetujuan Kredit Tujuan: Mendata informasi mengenai pelanggan – pelanggan yang dapat melakukan pembelian namun dengan saldo limit yang tidak mecukupi dan telah disetujui oleh manager kredit.
307 Atribut:
no_SPK,
kd_pelanggan,
permohonan_limit,
alasan,
persetujuan, kd_karyawan, tanggal. Operasi: Membuat persetujuan.
4.2.4.2
Function Conponent Component pada Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama, berisikan fungsi–fungsi untuk pencetakan laporan dan perhitungan penilaian pelanggan.
A.
Structure Hasil analisis dari komponen fungsional sistem dihasilkan dengan menggunakan metode function class placement.
308
Gambar 4.120 Function Component dan Interaksinya dengan Model Component
309 B.
Classes Berikut ini dideskripsikan operasi–operasi dari class yang terdapat pada function component dengan menggunakan operation specification. 1. Pembuatan Aging Schedule Tabel 4.47 Operation Specification dari “Pembuatan Aging Schedule” Operation Name Category
Check Program Pembuatan Aging Schedule _Active _Update xPassive _Compute xRead _Signal Purpose Menghasilkan laporan analisa umur piutang dengan kisaran 0 – 30 hari, 31 – 60 hari, 61 – 90 hari, dan >90 hari. Input data Tanggal awal laporan dan tanggal akhir laporan. Conditions Data mengenai piutang pelanggan pada periode waktu tersebut telah tersedia dan valid. Effect Laporan Analisa Umur Piutang (Aging Schedule) tercetak melalui printer. Algorithm Public Shared Function GetLapAging() As clsLaporan Dim da As New SqlDataAdapter Dim SQLConn As New SqlConnection(SIAPenjualan.My.Settings.SIACon nectionString) Dim SQLComm As New SqlCommand Dim ds As New DataSet Dim dt As New clsLaporan SQLConn.Open() Try With FrmLaporanPenjualan With SQLComm .Connection = SQLConn .CommandText = "Select no_faktur, tanggal, tanggal_jatuh_tempo Where tanggal Like '" & FrmLaporanPenjualan.dtpTanggal.Value & "%'" .CommandType = CommandType.Text End With End With da.SelectCommand = SQLComm ds.Tables.Add("Test") da.Fill(ds.Tables("Test"))
310 dt.Dt = ds.Tables("Test") Catch ex As Exception MessageBox.Show(ex.Message) Finally SQLConn.Close() End Try Return dt End Function
Data structure Placement Involved object Event trigger
Datetime Pembuata Aging Schedule Faktur Penjualan, BPK-DP, dan BPK Pelunasan Laporan diperlukan oleh pihak managemen.
2. Pembuatan Laporan Komisi Tabel 4.48 Operation Specification dari “Pembuatan Laporan Komisi” Operation Name Category
Check Program Pembuatan Laporan Komisi _Active _Update xPassive _Compute xRead _Signal Purpose Menghasilkan laporan penjualan barang komisi yang ditujukan pada masing – masing consignee. Input data Tanggal awal laporan dan tanggal akhir laporan. Conditions Data mengenai struk pembayaran pada periode waktu tersebut telah tersedia dan valid. Effect Laporan Komisi tercetak melalui printer. Algorithm Public Shared Function GetLapKomisi() As clsLaporan Dim da As New SqlDataAdapter Dim SQLConn As New SqlConnection(SIAPenjualan.My.Settings.SIACon nectionString) Dim SQLComm As New SqlCommand Dim ds As New DataSet Dim dt As New clsLaporan SQLConn.Open() Try With FrmLaporanPenjualan With SQLComm
311 .Connection = SQLConn .CommandText = "Select no_struk, jenis_pembayaran, total, tanggal Where tanggal Like '" & FrmLaporanPenjualan.dtpTanggal.Value & "%'" .CommandType = CommandType.Text End With End With da.SelectCommand = SQLComm ds.Tables.Add("Test") da.Fill(ds.Tables("Test")) dt.Dt = ds.Tables("Test") Catch ex As Exception MessageBox.Show(ex.Message) Finally SQLConn.Close() End Try Return dt End Function
Data structure Placement Involved object Event trigger
Datetime Pembuatan Laporan Komisi Struk Pembayaran, Detail Struk Pembayaran Laporan diperlukan oleh pihak managemen.
3. Penghitungan Total Tabel 4.49 Operation Specification dari “Penghitungan Total” Operation Name Category
Check Program Penghitungan Total _Active xPassive
_Update _Compute xRead _Signal Purpose Menghasilkan penghitungan total penjualan pelanggan. Input data Kd_Barang, Jumlah Conditions Data barang ada dalam sistem dan rumus yang digunakan untuk menghitung total valid. Effect Total dari penjualan perpelanggan dapat diketahui beserta PPN yang dikenakan. Algorithm _jumlah = txtjumlah.Text _harga = txtharga.Text _diskon = txtdiskon.Text _subTotal = _jumlah * _harga * ((100 - _diskon) / 100)
312 With gridbarang Dim descTotal As Decimal Dim intCtr As Integer For intCtr = 0 To .Rows.Count - 1 descTotal += CDec(.Rows(intCtr).Cells(5).Value) Next Me.txttotal.Text = descTotal End With txtkdbarang.Text = "" txtjumlah.Text = "" txtdiskon.Text = ""
Data structure Placement Involved object Event trigger
Bigint Penghitungan Total SPP, Detail SPP, Barang Adanya pesanan dari pelanggan.
4. Pengubahan_Limit_Lama Tabel 4.50 Operation Specification dari “Pengubahan Limit Lama” Operation Name Category
Check Program Pengubahan_Limit_Lama xActive xUpdate _Passive xCompute xRead _Signal Purpose Limit setiap pelanggan berubah sesuai dengan kriteria yang telah ditentukan. Input data Tanggal periode perubahan limit. Conditions Data pelanggan ada dalam sistem dan rumus yang digunakan untuk menghitung limit valid. Effect Limit kredit setiap pelanggan diubah sesuai dengan syarat yang berlaku. Algorithm Public Enum TipeLaporan LapUbahLimit End Enum Public Shared Function GetDataToDB(ByVal tipe As TipeLaporan, ByVal dtTgl As DateTime) As clsLaporan Dim obj As clsLaporan = Nothing Select Case tipe Case TipeLaporan.LapKasir obj = DataAccess.GetLapUbahLimit(dtTgl) End Select Return obj End Function
313
Imports System.Data.SqlClient Imports CrystalDecisions.CrystalReports.Engine Public Class FrmLaporan Private dt As DataTable Public Sub IsiLaporanUbahLimit(ByVal dtLap As DateTime) Dim obj As SIAPenjualan.clsLaporan obj = clsLaporan.GetDataToDB(clsLaporan.TipeLaporan .LapUbahLimit, dtLap) dt = obj.Dt Dim rpt As New ReportDocument rpt.Load(System.Windows.Forms.Application.Sta rtupPath & "\Laporan\CRLapUbahLimit.rpt") rpt.SetDataSource(dt) Me.CrystalReportViewer1.ReportSource = rpt CrystalReportViewer1.Show() End Sub
Data structure Placement Involved object Event trigger
C.
Bigint Pengubahan Limit Lama Pelanggan, Penilaian Pelanggan Adanya pelanggan baru atau data telah enam bulan tidak di-update.
User Interface Component User interface component pada Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama, berisikan class window dan print dimana class–class tersebut memiliki satu objek dan mewarisi fitur umum dari user interface library.
4.2.5
Recommendations Perancangan atas aplikasi Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama terdapat beberapa hal
314 yang harus diperhatikan, yaitu: the system’s usefulness, plan for initiating use, dan implementation plan.
4.2.5.1
The System’s Usefulness Perancangan dari Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama diharapkan dapat memenuhi kriteria kualitas yang telah ditetapkan sebelumnya. Berikut ini adalah kriteria yang sangat penting dan penting:
Tabel 4.51 Evaluasi Perancangan dengan Kriteria Kualitas Criterion Usable Secure
Efficient
Correct
Reliable Maintainable
Flexible Comprehensible Reusable
System’s Usefulness Kriteria ini akan dievaluasi dengan melakukan pengujian atas versi pertama dari sistem ini. Sistem yang dirancang ini memilki internal control yang cukup baik dengan adanya pencatatan karyawan mana yang membuat serta mengubah setiap dokumen, serta adanya pembatasan akses untuk masing-masing karyawan sesuai dengan tugas dan tanggung jawabnya. Sistem ini dirancang dengan adanya fasilitas pencarian serta minimalisasi peng-input-an data yang berulang sehingga dapat mendukung efisiensi atas waktu dari sumber daya manusia yang menggunakan sistem. Sistem ini akan dipresentasikan pada pihak–pihak yang berkepentingan untuk memastikan bahwa kebutuhan telah terpenuhi. Kriteria ini ada dievaluasi dengan melakukan pengujian atas versi pertama dari sistem ini. Sistem ini dirancang dengan meminimalisasikan kebutuhan akan perawatan sistem. Namun, perawatan tetap diperlukan. Pengembangan sistem kedepannya dapat dilakukan dengan lebih mudah. Sistem ini dibuat dalam bentuk modul sehingga dapat lebih mudah dipahami. Subsistem dapat digunakan pada aplikasi lain yang
315
Interoporable
4.2.5.2
menggunakan bahasa pemrograman yang sama. Sistem diharapkan dapat diintegrasikan dengan sistem yang telah ada di perusahaan.
Plan For Initiating Use Sebelum sistem ini digunakan maka terlebih dahulu sistem harus di install. Kemudian para pengguna akan dilatih terlebih dulu agar mereka dapat terbiasa menggunakan sistem ini. Sistem ini juga akan diuji sebelum diimplementasikan pada bisnis perusahaan.
4.2.5.3
Implementation Plan Metode yang digunakan untuk mengkonversi sistem yang lama ke sistem yang baru, yaitu menggunakan metode pararel, dimana sistem lama tetap digunakan, walaupun sistem yang baru telah diterapkan. Setelah dipastikan bahwa sistem baru telah berjalan dengan baik, maka perlahan–lahan sistem yang lama akan dihilangkan. Hal ini dilakukan untuk mengirangi risiko kegagalan sistem yang baru.
Tabel 4.52 Gantt Chart Rencana Implementasi Sistem Informasi Akuntansi Penjualan, Piutang, dan Penerimaan Kas pada CV. Dekatama No
Kegiatan
Waktu
Bulan 1
2
3 4 5 6 7
1 2 3 4 1 2 3 4 Presentasi program ke 1 perusahaan Pengadaan piranti keras dan 2 piranti lunak Pemasangan piranti keras dan 3 piranti lunak
1 minggu
3 minggu
1 minggu
316 4 Peng‐install‐an sistem baru 5 Pengujian sistem baru 6 Perbaikan sistem baru Pengimplementasian sistem 7 baru 8 Pelatihan pengguna 9 Evaluasi dan revisi
1 minggu 4 minggu 2 minggu
12 minggu 4 minggu 4 minggu
