BAB 4 PERANCANGAN SISTEM. Pengeluaran Kas diawali dengan system definition dan rich picture. System definition

Transkripsi

1 BAB 4 PERANCANGAN SISTEM 4.1 Analysis Document The Task Perancangan Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas diawali dengan system definition dan rich picture. System definition menggambarkan sistem yang diusulkan dengan menggunakan FACTOR dan gambaran dari keseluruhan sistem akan dibahas dengan menggunakan rich picture Purpose PT. Nakami Kinema Cemerlang adalah perusahaan jasa kontraktor yang bergerak dibidang pembangunan infrastruktur telekomunikasi. Perusahaan ingin membangun sistem yang dapat mendukung pencatatan transaksi dan pengendalian internal yang meliputi pembelian material kebutuhan proyek serta pembelian jasa subcontractor, pencatatan utang, serta pembayaran kepada supplier dan subcontractor. Pembelian material dan jasa dimulai dari aktivitas permintaan pembelian, permintaan penawaran harga, pemilihan supplier atau subcontractor, pesanan pembelian, aktivitas penerimaan material serta retur pembelian, dan perintah kerja kepada subcontractor. Dilanjutkan dengan pengeluaran material dari gudang ke lokasi proyek serta pengembalian material sisa proyek, pencatatan utang, permintaan pembayaran sampai pada pelunasan pembayaran material ke supplier dan pelunasan pembayaran jasa ke subcontractor, melakukan pemantauan waktu pengiriman material yang tepat sesuai dengan jadwal ke lokasi proyek. Sistem dapat melakukan update secara otomatis ke stok

2 material sehubungan dengan keluar masuk material dari gudang ke proyek maupun sebaliknya. Sistem yang dirancang juga diharapkan dapat mendukung pembuatan laporan operasional yang tepat dan akurat sehingga dapat memudahkan pihak manajemen memperoleh informasi mengenai operasional perusahaan System Definition Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas pada PT. Nakami Kinema Cemerlang ini akan dirancang dengan menggunakan arsitektur client-server. Setiap client akan terhubung dengan server melalui jaringan lokal (LAN) dengan menggunakan platform PC (Personal Computer). Tools yang digunakan dalam membangun Sistem Informasi Akuntansi ini adalah Microsoft Visual Studio 2008 dan menggunakan database SQL Server 2000 serta didukung dengan sistem operasi Microsoft Windows. Berikut adalah kriteria FACTOR dari Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas pada PT. Nakami Kinema Cemerlang yang dapat dilihat pada tabel 4.1: Tabel 4.1 System definition dengan kriteria FACTOR Functionality Sistem yang dibangun diharapkan dapat mendukung fungsionalitas proses bisnis perusahaan mulai dari fungsi permintaan pembelian, fungsi pemilihan supplier, fungsi pemesanan pembelian, fungsi penerimaan material, fungsi pengeluaran material ke lokasi proyek, fungsi pengembalian material, fungsi kesepakatan kerja, fungsi retur, fungsi kontrol budget, permintaan pembayaran, dan pembayaran atas invoice. Application Domain Staf bagian purchasing, staf bagian logistic, staf bagian budget control, staf bagian finance & accounting Condition Kondisi yang harus terpenuhi dalam pengembangan sistem yaitu perlu penyesuaian antara hardware dan software yang digunakan perusahaan saat ini dengan hardware dan software yang sesuai dengan spesifikasi kebutuhan dalam implementasi 90

3 Technology sistem yang diusulkan. Perlu dikomunikasikan mengenai masalah yang dihadapi perusahaan dengan usulan rekomendasi yang telah dibuat dalam sistem yang diusulkan sehingga staf yang berhubungan langsung dengan sistem dapat mengetahui perubahan yang dilakukan. Pelatihan bagi pengguna sistem juga diperlukan untuk mengetahui timbal balik dari pengguna terhadap user interface dan mengukur pemahaman pengguna akan sistem usulan ini. Hardware yang diperlukan dalam implementasi sistem adalah Personal Computer yang dilengkapi dengan beberapa peralatan tambahan seperti printer, scanner, fax, switch, jaringan LAN dengan pola centralized dan semua komputer akan dihubungkan dengan server. Software yang dibutuhkan adalah.net Framework 2.0, sistem operasi Microsoft Windows, database SQL Server Object Supplier, Subcontractor, Material, Service, Purchase Requisition, Request for Quotation, Purchase Order, Good Receipt, Site Delivery Order, Site Work Order, Site Material Return, Purchase Return Delivery Order, Debit Memo, Request for Payment, Budget, Bank Payment Voucher. Responsibility Context Problem Domain Tanggung jawab atas sistem secara keseluruhan adalah sebagai alat administrasi yang dapat diandalkan dalam kegiatan pencatatan transaksi serta penyediaan informasi kepada pengguna sistem maupun pihak manajemen perusahaan terhadap kegiatan-kegiatan dalam Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas. Prosedur yang diusulkan terhadap Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas pada PT. Nakami Kinema Cemerlang adalah sebagai berikut: 1) Prosedur Pembelian Sistem akan menerima Material Service Requirement (MSR) dari sistem penjualan pada saat sistem penjualan menerima proyek. MSR berisi informasi kebutuhan material dan service untuk suatu proyek per site. Sistem menerima kebutuhan material dan service dari sistem penjualan. Bagian Logistic akan membuat Purchase Requisition 91

4 92 (PR) berdasarkan MSR untuk permintaan pembelian material. PR yang telah dibuat akan tersimpan dalam database PR. Selanjutnya PR akan diotorisasi oleh Finance & Accounting Director. PR akan dicetak sebanyak tiga rangkap: Rangkap ke-1 akan diberikan kepada bagian Purchasing Rangkap ke-2 akan diberikan kepada bagian Finance & Accounting Rangkap ke-3 akan diarsip oleh bagian Logistic Bagian Purchasing yang menerima PR kemudian akan membuat Request for Quotation (RfQ) kepada supplier. Untuk permintaan pembelian service, MSR dapat diakses langsung oleh bagian Purchasing. Berdasarkan MSR, bagian Purchasing akan membuat Request for Quotation (RfQ) kepada Subcontractor. Hal ini dilakukan untuk mengumpulkan informasi harga terbaru yang diberikan baik supplier maupun subcontractor. RfQ akan dicetak sebanyak jumlah supplier atau subcontractor yang akan diminta penawaran harganya atau dikirim melalui . Ketika RfQ tersebut diterima kembali dari supplier maupun subcontractor, bagian purchasing akan memasukkan penawaran harga dari supplier atau subcontractor kemudian mengupload daftar harga tersebut ke dalam sistem. Jika dikembalikan dalam bentuk file excel melalui maka bagian Purchasing akan mengupload file tersebut ke sistem dan sistem akan membaca dan menyimpan informasi tersebut. Kemudian bagian purchasing akan melakukan pemesanan material serta service yang diperlukan dengan membuat Purchase Order (PO). PO akan dibuat berdasarkan RfQ. Bagian Purchasing akan mengisi form PO dan sistem memungkinkan untuk membandingkan sendiri harga material maupun service yang ditawarkan oleh supplier maupun subcontractor melalui RfQ. Sistem akan

5 93 memberikan alternatif keputusan berdasarkan informasi yang didapat dari supplier maupun subcontractor dari RfQ dalam memilih supplier dan subcontractor dengan harga yang termurah. Kesepakatan mengenai cara pembayaran dan waktu jatuh tempo juga ditentukan sesuai dengan hasil negosiasi. Selanjutnya PO akan dicetak sebanyak empat rangkap: Rangkap ke-1 akan diberikan kepada supplier atau subcontractor Rangkap ke-2 akan diberikan kepada bagian Budget Control Rangkap ke-3 akan diberikan kepada bagian Logistic Rangkap ke-4 akan diberikan kepada bagian Finance & Accounting PO selanjutnya akan diperiksa oleh bagian Budget Control untuk mengontrol agar pembelian yang dilakukan tidak melebihi budget yang telah ditetapkan. Sistem akan memberikan alert kepada bagian Purchasing jika pembelian sudah mendekati budget. Jika overbudget terjadi, maka PO akan diotorisasi oleh President Director. Khusus untuk pembelian service, bagian Purchasing juga akan membuat Subcon Work Order (SWO) yang isinya mengenai kesepakatan pekerjaan jasa yang akan dilakukan oleh Subcontractor beserta pembayarannya. SWO berfungsi sebagai pengenal yang akan ditunjukkan oleh subcontracotor ketika sampai di lokasi proyek. SWO ini akan dicetak sebanyak dua rangkap: Rangkap ke-1 akan diberikan kepada Subcontractor Rangkap ke-2 akan diberikan kepada Site Coordinator Setelah mengirimkan PO ke supplier, maka bagian Logistic akan menerima material beserta Surat Jalan dan memeriksa kesesuaian material dengan PO. Kemudian bagian Logistic akan mengentri data material yang diterima dari supplier pada form

6 94 Good Receipt sebagai bukti penerimaan barang. Bagian Logistic dapat membuka histori PO untuk material bersangkutan kemudian mengentri jumlah material yang diterima. Sistem akan mengupdate jumlah material ke database material secara otomatis ketika form disave. Sistem juga memungkinkan bagi bagian Logistic untuk mengkategorikan material yang diterima dari supplier per site atau lokasi proyek. Sehingga akan memudahkan bagian Logistic saat pengiriman material ke site. GR diperiksa dan diotorisasi oleh Finance & Accounting Director dan dicetak sebanyak tiga rangkap: Rangkap ke-1 akan diberikan ke bagian Purchasing Rangkap ke-2 akan diberikan ke bagian Finance & Accounting Rangkap ke-3 akan diarsip oleh bagian Logistic Bagian Purchasing juga menerima invoice atas material yang telah dikirim dari supplier. Invoice akan dicocokkan dengan GR dan PO oleh bagian Purchasing untuk memverifikasi kebenaran invoice. Bila sesuai, maka invoice dan copy Surat Jalan akan diteruskan ke bagian Finance & Accounting. Pada saat GR disave, maka sistem akan menggenerate pencatatan utang atas material ke list of Account Payable. 2) Prosedur Retur Material Jika terdapat material yang cacat atau tidak sesuai dengan spesifikasi permintaan, maka bagian Logistic akan mengkonfirmasikan kepada bagian Purchasing. Selanjutnya bagian Purchasing akan menghubungi supplier untuk konfirmasi atas retur pembelian. Retur dapat dilakukan jika ada kesepakatan dengan supplier. Retur dapat dilakukan dengan cara menukarkan dengan material yang sama, atau jika supplier tidak memiliki stok, maka dapat dilakukan dengan cara mengembalikan material tersebut dan

7 95 memotong jumlah utang ke supplier. Setelah menerima perintah retur dari bagian Purchasing, bagian Logistic akan membuat Purchase Return Delivery Order (PRDO) yang dilampirkan beserta material yang akan dikembalikan kepada supplier. Selain itu, sistem juga akan mengupdate jumlah material yang ada (Qty. On Hand) dengan mengurangi material di stok. PRDO akan dicetak sebanyak tiga rangkap: Rangkap ke-1 untuk dilampirkan bersama material yang dikembalikan kepada supplier Rangkap ke-2 akan diberikan kepada bagian Finance & Accounting Rangkap ke-3 akan diberikan kepada bagian Purchasing Namun jika kondisi kedua yang berlaku, maka bagian Purchasing akan membuat Debit Memo (DM) sebanyak tiga rangkap: Rangkap ke-1 akan diberikan kepada supplier Rangkap ke-2 akan diberikan kepada bagian Finance & Accounting Rangkap ke-3 akan diberikan kepada bagian Purchasing Selanjutnya sistem akan secara otomatis mengurangi jumlah utang ke supplier berdasarkan Debit Memo, sekaligus akan menggenerate pencatatan retur pembelian. 3) Prosedur Keluar Masuk Material Sistem akan memberikan reminder kepada bagian Logistic ketika jadwal pengiriman material ke lokasi proyek kurang dari satu hari. Hal ini dilakukan dengan tujuan agar bagian Logistic dapat menyiapkan dan mengelompokkan material yang akan dikirim ke masing-masing lokasi proyek. Bagian Logistic akan menyertakan Site Delivery Order (SDO) beserta material untuk dikirim ke lokasi. Kebutuhan material untuk tiap site dapat diakses oleh bagian Logistic melalui MSR yang diterima dari sistem

8 96 penjualan. Sistem akan secara otomatis mengurangi kuantitas material (Qty. On Hand) atas material yang dikirim ke site. SDO akan dicetak sebanyak tiga rangkap: Rangkap ke-1 akan diberikan kepada Site Coordinator sebagai tanda terima material di lokasi proyek. Rangkap ke-2 akan diberikan kepada bagian Finance & Accounting untuk mencatat jurnal pengeluaran material Rangkap ke-3 akan diarsip oleh bagian Logistic Pada saat pengerjaan proyek telah selesai, maka jika terdapat material sisa yang cukup signifikan, maka Site Coordinator akan mengembalikan material sisa tersebut ke gudang. Kemudian bagian Logistic akan mencatat penerimaan material pada form Site Material Return (SMR). Sistem juga akan mengupdate secara otomatis Qty. on Hand material yang bersangkutan. SMR akan dicetak sebanyak tiga rangkap: Rangkap ke-1 akan diberikan kepada Site Coordinator Rangkap ke-2 akan diberikan kepada Finance & Accounting Rangkap ke-3 akan diberikan kepada bagian Budget Control untuk mencatat pemakaian aktual material 4) Prosedur Pengeluaran Kas Bagian Finance & Accounting akan mendapatkan reminder untuk melakukan permintaan pembayaran atas utang berdasarkan tanggal jatuh temponya. Berdasarkan daftar utang tersebut, bagian Finance & Accounting akan membuat RfP sebanyak satu rangkap untuk diberikan kepada Cashier yang sebelumnya akan diperiksa oleh bagian Finance & Accounting Director serta diotorisasi oleh President Director. Cashier kemudian akan memproses RfP dari bagian Finance & Accounting untuk melakukan

9 97 pembayaran. Biasanya pembayaran dilakukan dengan menggunakan giro mundur. Setelah melakukan pembayaran, Cashier akan memberikan bukti pembayaran kepada supplier atau subcontractor. Copy dari bukti pembayaran tersebut juga diberikan kepada bagian Finance & Accounting membuat Bank Payment Voucher (BPV) sebanyak dua rangkap untuk diberikan cashier sebagai bukti bahwa pembayaran telah dilakukan serta mencetak Bukti Potong PPh 23 untuk pembayaran atas service subcontractor, dan rangkap kedua untuk diarsip. Ketika BPV disave, sistem akan secara otomatis mengupdate jumlah utang di List Account Payable. Cashier akan menerima kuitansi tanda pembayaran dari supplier atau subcontractor. Kuitansi tersebut kemudian akan diberikan kepada bagian Finance & Accounting untuk diarsip dan menutup PO sebagai tanda lunas. Setiap akhir bulan, bagian Finance & Accounting akan mencetak Purchase Journal Report, Purchase Return Journal Report, Cash Disbursement Journal Report, Purchasing Report, Cash Disbursement Report.

10 Gambar 4.1 Rich Picture Sistem Usulan PT Nakami Kinema Cemerlang 98

11 Application Domain Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas pada PT. Nakami Kinema Cemerlang yang dirancang diharapkan dapat mendukung tugas dan tanggung jawab karyawan dari masing-masing divisi: a) Bagian Purchasing, yaitu membuat Request for Quotation, membuat Purchase Order, membuat Subcon Work Order b) Bagian Logistic, yaitu membuat Purchase Requisition, membuat Good Receipt, membuat Site Delivery Order, membuat Site Material Return, membuat Purchase Return Delivery Order. c) Bagian Finance & Accounting, yaitu memeriksa jatuh tempo utang, membuat Request for Payment, membuat Bank Payment Voucher, membuat Purchasing Report, Purchase Journal Report, Purchase Return Journal Report, Cash Disbursement Journal Report, Cash Disbursement Report, Supplier Performance Analysis Report. d) Bagian Budget Control, yaitu membuat budget Problem Domain Analisis problem domain Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas pada PT. Nakami Kinema Cemerlang melibatkan aktivitas analisis terhadap cluster, structure, dan class Cluster Model Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang secara keseluruhan terdiri dari beberapa cluster, yaitu cluster purchasing, purchase return, cash disbursement, budget, dan material movement. Model Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan

12 Pengeluaran Kas PT. Nakami Kinema Cemerlang dapat dilihat pada gambar 4.2 dibawah ini: 100 cd Cluster Purchasi ng Purchase Return Cash Disbursement Budget Material Movement Gambar 4.2 Model Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang Structure Gambar 4.3 dibawah ini menunjukkan struktur Purchasing yang terdiri dari class Purchase Requisition (PR), Request for Quotation (RfQ), Supplier, Subcontractor, Purchase Order (PO), Good Receipt (GR), Material, Subcon Work Order (SWO), dimana memiliki hubungan asosiasi: satu PR memiliki struktur asosiasi dengan banyak RfQ, satu RfQ memiliki struktur asosiasi dengan banyak supplier dan subcontractor, banyak RfQ memiliki struktur asosiasi dengan satu PO, satu PO memiliki hubungan asosiasi dengan banyak GR, banyak GR memiliki hubungan asosiasi dengan banyak Material, satu PO memiliki hubungan asosiasi dengan satu SWO, banyak SWO berhubungan dengan banyak service.

13 101 Gambar 4.3 Struktur Purchasing Gambar 4.4 dibawah ini menunjukkan struktur Purchase Return yang hanya terdiri dari class Purchase Return Delivery Order. Gambar 4.4 Struktur Purchase Return Gambar 4.5 dibawah ini menunjukkan struktur Budget yang hanya terdiri dari class Budget.

14 102 Gambar 4.5 Struktur Budget Gambar 4.6 dibawah ini menunjukkan struktur Material Movement yang terdiri dari class Site Delivery Order (SDO) dan Site Material Return (SMR) dimana memiliki hubungan asosiasi: satu class Site Delivery Order memiliki struktur asosiasi dengan satu class Site Material Return. Gambar 4.6 Struktur Material Movement

15 103 Gambar 4.7 dibawah ini menunjukkan struktur Cash Disbursement yang terdiri dari class Request for Payment dan Bank Payment Voucher dimana memiliki hubungan asosiasi: satu class Request for Payment memiliki struktur asosiasi dengan satu class Bank Payment Voucher. Gambar 4.7 Struktur Cash Disbursement Gambar 4.8 dibawah ini menunjukkan class diagram Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang. Hubungan antara class Purchase Requisition dengan class Request for Quotation terjadi ketika bagian Purchasing akan meminta penawaran harga kepada supplier dan subcontractor berdasarkan PR dari bagian Logistic. Selanjutnya class Request for Quotation dengan class Subcontractor dan class Supplier menunjukkan penawaran RfQ akan diberikan kepada supplier atau subcontractor yang mana. Class Request for Quotation dengan class Purchase Order menunjukkan hubungan asosiasi yang terjadi ketika bagian Purchasing menerima penawaran harga dan melakukan pemesanan pembelian kepada supplier atau subcontractor. Sedangkan hubungan antara class Purchase Order dengan class Good Receipt dan class Subcon Work Order menunjukkan bahwa material telah diterima dari supplier oleh bagian Logistic dan service dengan subcontractor telah disepakati dalam kontrak oleh bagian Purchasing.

16 104 Sebelum pesanan pembelian diotorisasi, maka akan dilakukan pengecekan jumlah pesanan pembelian dengan budget yang disediakan. Hal ini ditunjukkan melalui hubungan antara class Budget dengan class Purchase Order. Hubungan antara class Good Receipt dengan class Site Delivery Order, class Site Delivery Order dengan class Site Material Return, menggambarkan kondisi yang terjadi ketika melakukan pengiriman material dari gudang ke lokasi proyek dan pengembalian material sisa dari lokasi proyek ke gudang. Sedangkan hubungan antara class Budget dengan class Site Material Return terjadi ketika pencatatan pemakaian material aktual dilakukan. Hubungan antara class Good Receipt dengan class Purchase Return Delivery Order menunjukkan hubungan asosiasi yang terjadi ketika dilakukan retur pembelian berdasarkan material yang telah diterima dari supplier. Selanjutnya, hubungan antara class Request for Payment dengan class Bank Payment Voucher, menunjukkan hubungan asosiasi ketika terjadi permintaan pembayaran oleh bagian Finance & Accounting serta pelunasan pembayaran dengan membuat Bank Payment Voucher.

17 Gambar 4.8 Class Diagram Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang 105

18 Classes Material Class Material merupakan kumpulan objek dari Material yang sudah terdaftar di perusahaan. Gambar 4.9 dibawah menggambarkan behavior pattern dan attribute dari class material. Gambar 4.9 Class Material dan Statechart Diagram Class Material Service Class Service merupakan kumpulan objek dari Service yang sudah terdaftar di perusahaan. Gambar 4.10 dibawah menggambarkan behavior pattern dan attribute dari class service. Gambar 4.10 Class Service dan Statechart Diagram Service

19 107 Supplier Class Supplier merupakan kumpulan objek dari Supplier yang sudah terdaftar di perusahaan. Gambar 4.11 dibawah menggambarkan behavior pattern dan attribute dari class supplier. Gambar 4.11 Class Supplier dan Statechart Diagram Class Supplier Subcontractor Class Subcontractor merupakan kumpulan objek dari Subcontractor yang sudah terdaftar di perusahaan. Gambar 4.12 dibawah menggambarkan behavior pattern dan attribute dari class subcontractor.

20 108 Gambar 4.12 Class Subcontractor dan Statechart Diagram Class Subcontractor Purchase Requisition Class Purchase Requisition merupakan kumpulan objek dari Purchase Requisition yang pernah dibuat oleh perusahaan. Menggambarkan event dimana bagian Logistic melakukan permintaan pembelian terhadap material atau service yang dibutuhkan. Gambar 4.13 dibawah menggambarkan behavior pattern dan attribute dari class Purchase Requisition. Gambar 4.13 Class Purchase Requisition dan Statechart Diagram Class Purchase Requisition

21 109 Request for Quotation Class Request for Quotation merupakan kumpulan objek yang pernah dibuat oleh perusahaan. Gambar 4.14 menggambarkan behavior pattern dan attribute dari class Request for Quotation. Gambar 4.14 Class Request for Quotation dan Statechart Diagram Class Request for Quotation Purchase Order Class Purchase Order merupakan kumpulan objek yang pernah dibuat oleh perusahaan. Menggambarkan event dimana bagian Purchasing melakukan pesanan pembelian kepada Supplier ataupun Subcontractor. Gambar 4.15 menggambarkan behavior pattern dan attribute dari class Purchase Order.

22 110 Gambar 4.15 Class Purchase Order dan Statechart Diagram Class Purchase Order Budget Class Budget merupakan kumpulan objek yang pernah dibuat oleh perusahaan. M enggambarkan event dimana bagian Budget Control melakukan pengawasan terhadap budget yang dikeluarkan serta melakukan update terhadap perubahan yang terjadi pada pengeluaran baik material maupun service. Gambar 4.16 menggambarkan behavior pattern dan attribute dari class Budget.

23 111 Gambar 4.16 Class Budget dan Statechart Diagram Class Budget Good Receipt Class Good Receipt merupakan kumpulan objek pernah dibuat oleh perusahaan. Menggambarkan event dimana bagian Logistic mencatat penerimaan material di gudang. Gambar 4.17 menggambarkan behavior pattern dan attribute dari class Good Receipt. Gambar 4.17 Class Good Receipt dan Statechart Diagram Class Good Receipt Site Delivery Order Class Site Delivery Order merupakan kumpulan objek yang pernah dibuat oleh perusahaan. Menggambarkan event dimana bagian Logistic mencatat pengeluaran dari

24 gudang ke lokasi proyek. Gambar 4.18 menggambarkan behavior pattern dan attribute dari class Site Delivery Order. 112 Gambar 4.18 Class Site Delivery Order dan Statechart Diagram Site Delivery Order Purchase Return Delivery Order Class Purchase Return Delivery Order merupakan kumpulan objek yang pernah dibuat oleh perusahaan. Menggambarkan event dimana bagian Logistic mencatat pengeluaran dari gudang ke lokasi proyek. Gambar 4.19 menggambarkan behavior pattern dan attribute dari class Purchase Return Delivery Order.

25 113 Gambar 4.19 Class Purchase Return Delivery Order dan Statechart Diagram Purchase Return Delivery Order Subcon Work Order Class Subcon Work Order merupakan kumpulan objek yang pernah dibuat oleh perusahaan. Menggambarkan event dimana bagian Purchasing memberikan perintah kerja kepada subcontractor, serta berperan sebagai izin masuk ke lokasi proyek. Gambar 4.20 menggambarkan behavior pattern dan attribute dari class Subcon Work Order. Gambar 4.20 Class Subcon Work Order dan Statechart Diagram Subcon Work Order

26 114 Request for Payment Class Request for Payment merupakan kumpulan objek yang pernah dibuat oleh perusahaan. Menggambarkan event dimana bagian Finance & Accounting membuat pengajuan pembayaran kepada manajer dan direktur atas transaksi-transaksi yang telah dilakukan. Gambar 4.21 menggambarkan behavior pattern dan attribute dari class Request for Payment. Gambar 4.21 Class Request for Payment dan Statechart Diagram Request for Payment Site Material Return Class Site Material Return merupakan kumpulan objek yang pernah dibuat oleh perusahaan. Menggambarkan event dimana bagian Logistic mencatat penerimaan material sisa dari lokasi proyek jika ada.gambar4.22 menggambarkan behavior pattern dan attribute dari class Site Material Return.

27 115 Gambar 4.22 Class Site Material Return dan Statechart Diagram Class Site Material Return Bank Payment Voucher Class Bank Payment Voucher merupakan kumpulan objek yang pernah dibuat oleh perusahaan. Menggambarkan event dimana Cashier mencatat pengeluaran kas atas pembayaran utang. Gambar 4.23 menggambarkan behavior pattern dan attribute dari class Bank Payment Voucher. Gambar 4.23 Class Bank Payment Voucher dan Statechart Diagram Class Bank Payment Voucher Event Tabel 4.2 dibawah ini merupakan event table dari Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang.

28 Tabel 4.2 Event Table Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang Application Domain Analisis application domain Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas pada PT. Nakami Kinema Cemerlang melibatkan aktivitas perancangan use case, function, dan interface Usage Overview Terdapat lima aktor dalam Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang, yaitu karyawan bagian Purchasing, karyawan bagian Logistic, karyawan bagian Finance & Accounting, dan karyawan bagian Budget Control dimana terdapat dua puluh lima use case yang akan digambarkan. Tabel berikut menunjukkan hubungan actor dengan use case dalam

29 117 Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang. Tabel 4.3 Actor Table Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang ACTORS USE CASE Mendata Material Baru Mendata Material Type Baru Mendata Service Baru Mendata Service Type Baru Mendata Supplier Baru Mendata Subcontractor Baru Membuat Purchase Requisition Membuat Request for Quotation Mendata Quotation from Client Membuat Purchase Order Membuat Budget Membuat Good Receipt Membuat Purchase Return Delivery Order Membuat Subcon Work Order Membuat Site Delivery Order Membuat Site Material Return Membuat Request for Payment Membuat Bank Payment Voucher Membuat List of Account Payable Membuat Purchasing Report Membuat Purchase Journal Report Membuat Purchase Return Journal Report Membuat Cash Disbursement Journal Report Membuat Cash Disbursement Report Membuat Supplier Performance Analysis Report Logistic Purchasing Finance & Accounting Budget Control

30 Actors Actor specification dari Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang adalah sebagai berikut: Tujuan Karakteristik Tabel 4.4 Actor Specification dari Karyawan Bagian Purchasing Purchasing Karyawan yang bertanggung jawab dalam kegiatan permintaan penawaran harga kepada supplier maupun subcontractor, memilih supplier maupun subcontractor yang tepat, melakukan pesanan pembelian dengan membuat Purchase Order, membuat Subcon Work Order sebagai perintah kerja bagi subcontractor untuk bekerja di lokasi proyek tertentu. Disamping itu, bagian ini juga bertanggung jawab dalam mendata supplier dan subcontractor serta melakukan update data jika terjadi perubahan. Pada akhir bulan, karyawan akan membuat laporanlaporan bulanan yang ditujukan kepada pihak manajemen perusahaan. Karyawan Purchasing harus teliti dan negosiatif dalam memilih dan menentukan supplier maupun subcontractor serta mengerti material dan service yang dibutuhkan proyek. Selain itu juga memiliki pengalaman administratif sehingga melakukan pencatatan transaksi pembelian secara tepat ke sistem. Contoh Bagian Purchasing membuat Request for Quotation berdasarkan Purchase Requisition yang diterima dari bagian Logistic dengan mengentri data transaksi permintaan penawaran harga kepada supplier dan subcontractor yang bersangkutan. Tujuan Tabel 4.5 Actor Specification dari Karyawan Bagian Logistic Logistic Karyawan yang bertanggung jawab dalam kegiatan permintaan pembelian dengan membuat Purchase Requisition, penerimaan material dari supplier, pengiriman material yang dibutuhkan ke lokasi proyek, pengembalian material sisa dan melakukan retur pembelian dengan membuat Purchase Return Delivery Order jika terjadi retur pembelian.

31 119 Karakteristik Contoh Karyawan Logistic harus mengetahui kebutuhan material dan melakukan pembelian secara tepat sehingga saat material diperlukan sudah tersedia sehingga tidak mengganggu jadwal pengerjaan proyek. Di samping itu juga harus memiliki pengetahuan mengenai material yang bersangkutan sehingga dapat membedakan kualitas dan secara teliti menghitung kuantitas material yang diterima dari supplier. Bagian Logistic menerima material dari supplier, kemudian akan membuat Good Receipt sebagai bukti penerimaan material berdasarkan Surat Jalan dari supplier. Tabel 4.6 Actor Specification dari Karyawan Bagian Finance & Accounting Finance & Accounting Tujuan Karyawan Finance & Accounting bertanggung jawab dalam pencatatan utang, permintaan pembayaran kepada supplier maupun subcontractor pada saat jatuh tempo, serta membuat laporan-laporan yang berkaitan dengan taransaksi pembelian, utang usaha, dan pengeluaran kas pada akhir periode. Karakteristik Contoh Karyawan Finance & Accounting harus teliti dalam melakukan pencatatan utang. Selain itu juga memeriksa validitas utang, waktu jatuh tempo, serta informasi lain yang berkaitan dengan diskon pembelian. Bagian Finance & Accounting mencatat utang yang terjadi dari transaksi pembelian, mencatat retur pembelian, serta pengeluaran kas ke dalam sistem sehingga dapat dihasilkan laporan yang berguna bagi pihak manajemen. Tujuan Tabel 4.7 Actor Specification dari Karyawan Bagian Budget Control Budget Control Karyawan budget Control bertanggung jawab dalam membuat Budget, mengupdate volume pemakaian material aktual dan pengeluaran biaya aktual dalam pembiayaan suatu proyek. Pada akhir proyek, karyawan bagian ini membuat laporan realisasi budget sehingga dapat diketahui harga pokok dari proyek tersebut secara keseluruhan.

32 120 Karakteristik Contoh Karyawan budget Control harus dapat mengontrol pengeluaran yang dilakukan oleh bagian purchasing dalam melakukan pembelian material dan jasa agar tidak melebihi budget yang telah direncanakan. Jika melebihi budget, maka perlu otorisasi dari manajer untuk melakukan pembelian. Disamping itu juga menjamin keakuratan data dan selalu melakukakn update atas perubahan yang terjadi. Bagian Budget Control akan membuat anggaran berdasarkan Bill of Quantity yang diterima dari sistem penjualan Use Cases Gambar 4.24 dibawah ini menunjukkan use case dari Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang.

33 Gambar 4.24 Use Case Diagram Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang 121

34 122 Berikut merupakan use case specification dari Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang, dapat dilihat pada tabel-tabel dibawah ini. Tabel 4.8 Use Case Specification untuk Mendata Material Baru Use Case Object Function Mendata Material Baru Proses ini dilakukan oleh bagian Purchasing ketika terdapat material yang belum terdaftar sebelumnya. Bagian Purchasing akan mengentri data material dan melakukan pengecekan terhadap data material, apakah sudah terdaftar di sistem atau belum. Jika belum terdaftar, maka ketika tombol Save diklik, data tersebut akan disimpan dalam database. Jika data telah tersimpan di database, maka sistem memberikan notifikasi bahwa data sudah ada di database. Material, Material Type, Supplier get(materialdata), create(),generate(materialid), save(), add(materialdata) Tabel 4.9 Use Case Specification untuk Mendata Material Type Baru Use Case Object Function Mendata Material Type Baru Proses ini dilakukan oleh bagian Purchasing ketika terdapat material type yang belum terdaftar sebelumnya. Bagian Puchasing akan menentukan ID sendiri sesuai dengan nama materialnya. Material Type get(materialtype), create(), save(), add(materialtype) Tabel 4.10 Use Case Specification untuk Mendata Service Type Baru Use Case Object Function Mendata Service Baru Proses ini dilakukan oleh bagian Purchasing ketika terdapat Service yang belum terdaftar sebelumnya. Bagian Purchasing akan mengentri data Service dan melakukan pengecekan terhadap data Service apakah sudah terdaftar atau belum. Jika belum terdaftar, maka ketika tombol Save diklik, data akan tersimpan di dalam database.jika data telah tersimpan di database, maka sistem memberikan notifikasi bahwa data sudah ada di database. Service, Service Type, Subcontractor get(servicedata), create(), generate(serviceid), save(), add(service)

35 123 Tabel 4.11 Use Case Specification untuk Mendata Service Type Baru Use Case Object Function Mendata Service Type Baru Proses ini dilakukan oleh bagian Purchasing ketika terdapat service type yang belum terdaftar sebelumnya. Bagian Puchasing akan menentukan ID sendiri sesuai dengan nama servicenya. Service Type get(servicetype), create(), save(), add(sevicetype) Tabel 4.12 Use Case Specification untuk Mendata Supplier Baru Use Case Object Function Mendata Supplier Baru Proses ini dilakukan oleh bagian Purchasing ketika terdapat Supplier yang belum terdaftar sebelumnya. Bagian Purchasing akan mengentri data Supplier dan melakukan pengecekan terhadap data Suplier apakah sudah terdaftar atau belum. Jika belum terdaftar, maka ketika tombol Save diklik, data akan tersimpan di dalam database.jika data telah tersimpan di database, maka sistem memberikan notifikasi bahwa data sudah ada di database. Supplier get(supplierdata), create(), generate(supplierid), save(), add(supplier) Tabel 4.13 Use Case Specification untuk Mendata Subcontractor Baru Use Case Object Function Mendata Subcontractor Baru Proses ini dilakukan oleh bagian Purchasing ketika terdapat Subcontractoryang belum terdaftar sebelumnya. Bagian Purchasing akan mengentri data Subcontractor dan melakukan pengecekan terhadap data Suplier apakah sudah terdaftar atau belum. Jika belum terdaftar, maka ketika tombol Save diklik, data akan tersimpan di dalam database.jika data telah tersimpan di database, maka sistem memberikan notifikasi bahwa data sudah ada di database. Subcontractor get(subcontractordata), create(), generate(subcontractorid), save(), add_subcontractor()

36 124 Tabel 4.14 Use Case Specification untuk Membuat Request for Quotation Use Case Object Function Membuat Request for Quotation Proses ini dilakukan ketika bagian Purchasing ingin mencari supplier atau subcontractor baru dengan cara memberikan permintaan penawaran harga dengan membuat Request for Quotation. Ketika form load, RfQ No akan digenerate secara otomatis.user akan memilih supplier atau subcontractor yang akan dikirimkan RfQ. Sedangkan jumlah materialnya, disesuaikan dengan jumlah material yang ada di MSR (Qty to Purchase). Jika berupa service, maka akan didefinisikan jenis servicenya. Pada saat RfQ yang telah diisi dikembalikan oleh supplier atau subcontractor, maka bagian Purchasing akan mengupdate data RfQ dengan harga yang ditawarkan. RfQ, RfQDetail, PR get(lastrfqcode), generate(rfqno), create, save(), print() Tabel 4.15 Use Case Specification untuk Membuat Quotation from Client Use Case Object Function Mendata Quotation from Client Proses ini dilakukan oleh bagian Purchasing ketika terdapat Quotation yang diterima dari supplier atau subcontractor yang belum diupload ke dalam sistem. RfQ, RfQDetail get(filecontent), save(), add() Tabel 4.16 Use Case Specification untuk Membuat Purchase Order Use Case Object Membuat Purchase Order Proses ini dilakukan ketika bagian Purchasing menerima Purchase Requisition dari bagian Logistic atau menerima Request for Quotation dari supplier atau subcontractor. Dalam membuat Purchase Order, bagian Purchasing dapat membuat keputusan dalam menentukan supplier atau subcontractor. Terdapat tiga pilihan dalam pengambilan keputusan mengenai penentuan pemilihan supplier, yaitu pemilihan supplier berdasarkan harga yang paling murah per masing-masing material, penentuan secara manual berdasarkan keputusan dari bagian Purchasing, serta penentuan harga termurah berdasarkan rata-rata harga material di satu supplier. PO, PODetail, Supplier, Subcontractor, MSR

37 125 Function get(lastpono), generate(pono), create(), calculate_subtotalpo(), calculate_grandtotalpo(), save(), print() Tabel 4.17 Use Case Specification untuk Membuat Subcon Work Order Use Case Object Function Membuat Subcon Work Order Proses ini menggambarkan kondisi dimana bagian Purchasing akan membuat Subcon Work Order berdasarkan kesepakatan Purchase Order dengan subcontractor sebagai tanda pengenal bagi subcontractor atau mandor di lokasi proyek. Subcon Work Order, Purchase Order get(lastswono), generate(swono), create(), save(), print() Tabel 4.18 Use Case Specification untuk Membuat Budget Use Case Object Function Membuat Budget Proses ini dilakukan dalam rangka mengontrol pengeluaran yang terjadi agar margin yang didapat sesuai dengan yang diharapkan.budget dibuat oleh bagian Budget Control berdasarkan data historis dari Purchase Order. Budget Control memasukkan Unit Price, sistem akan mengkalkulasi Total Price serta Amount dari keseluruhan Budget untuk suatu proyek. Jika telah melakukan pembelian material maupun service, maka dapat mengupdate qty. yang dibeli beserta harganya. Sehingga pada akhirnya dapat dikalkulasi biaya aktual suatu proyek. Budget, Purchase Order get(lastbudgetno), generate(budgetno), create(), calculate_actualbudget(), save(), print() Tabel 4.19 Use Case Specification untuk Membuat Purchase Requisition Use Case Membuat Purchase Requisition Proses ini dilakukan ketika telah diketahui jumlah material yang perlu dibeli untuk memenuhi kebutuhan proyek. Bagian Logistic membuat Purchase Requisition disaat bagian Logistic memeriksa Qty. Material On Hand(yang ada di stok) dengan Qty. Material Required(material yang dibutuhkan untuk pengerjaan proyek). Jika material on hand tidak mencukupi kebutuhan, maka atas dasar itu, sistem akan mengkalkulasi Qty. to Purchase. User masuk ke halaman Purchase Requisition, ketika form load, PRNo akan digenerate secara otomatis User memilih MSR No dimana MSR No yang muncul di form Purchase Requisition adalah MSR yang belum dibuat PR.

38 126 Object Function PR, MSR, MSRDetail, BoQPlan, ProjectSheet, get(msrno), get(lastprno), generate(prno), create() save(), print() Tabel 4.20 Use Case Specification untuk Membuat Good Receipt Use Case Object Function Membuat Good Receipt Proses ini dilakukan ketika bagian Logistic menerima material yang dikirim oleh Supplier.Good Receipt dibuat berdasarkan Surat Jalan yang diterima dari supplier. Material yang diterima akan dientri ke dalam sistem. Sistem akan memeriksa bilamana masih ada material yang dipesan tapi belum diterima. GR, PO, PR, MSR, BoQPlan, ProjectSheet, PODetail, GRDetail get(lastgrno), generate(grno), create(), save(), print() Tabel 4.21 Use Case Specification untuk Membuat Purchase Return Delivery Order Use Case Object Function Membuat Purchase Return Delivery Order Proses ini dilakukan ketika ditemukan adanya material yang cacat saat material dikirim atau ketika material yang diminta tidak sesuai dengan spesifikasinya. Bagian Logistic akan membuat Purchase Return Delivery Order berdasarkan Good Receipt. Jika material diganti dengan material yang sama, maka sistem tidak perlu mencatat material yang keluar atau masuk. Jika material yang cacat tersebut dikembalikan, maka akan mengurangi account payable kepada supplier. Purchase Return, Good Receipt get(lastprdono), generate(prdono), create(), save(), print(), Tabel 4.22 Use Case Specification untuk Membuat Site Material Return Use Case Object Function Membuat Site Material Return Proses ini terjadi pada saat proyek akan berakhir. Jika terdapat material sisa yang cukup signifikan, maka bagian Project (Sistem Penjualan) akan mengirimkan material tersebut kembali ke gudang. Bagian Logistic akan mencatat penerimaan material dengan membuat Site Material Return, serta mengupdate ke Budget berkaitan dengan penggunaan material aktual. SMR, SMRDetail, SDO, SDODetail get(lastsmrno), generate(smrno), create(), save(), print()

39 127 Tabel 4.23 Use Case Specification untuk Membuat Site Delivery Order Use Case Object Function Membuat Site Delivery Order Proses ini dilakukan ketika bagian Logistic akan mengirimkan material yang dibutuhkan ke lokasi proyek dengan menggunakan Site Delivery Order. Site Delivery Order dibuat berdasarkan Material Service Requirement dimana Material telah dibandingkan kesesuaian pengirimannya dengan permintaan kebutuhannya. SDO, MSR, BoQPlan, ProjectSheet, MSRDetail, SDODetail get(lastsdono), generate(sdono), create(), save(), print() Tabel 4.24 Use Case Specification untuk Membuat Request for Payment Use Case Object Function Membuat Request for Payment Proses ini dilakukan oleh bagian Finance & Accounting ketika telah mengetahui tanggal jatuh tempo melalui Daftar Account Payable. Pada saat jatuh tempo, bagian Finance & Accounting akan membuat Request for Payment berdasarkan Invoice dan atau tagihan yang diterima. Request for Payment get(lastrfpno), generate(rfpno), create(), calculate_totalrfp(), print(), save() Tabel 4.25 Use Case Specification untuk Membuat Bank Payment Voucher Use Case Object Function Membuat Bank Payment Voucher Proses ini dilakukan ketika Cashier telah mendapatkan otorisasi atas pembayaran melalui Request for Payment dan telah melakukan pembayaran, baik melalui transfer,giro/cek. Bank Payment Voucher berfungsi sebagai bukti pengeluaran kas. Bank Payment Voucher, Request for Payment get(lastbpvno), generate(bpvno), create(), print(), save() Tabel 4.26 Use Case Specification untuk Membuat List of Account Payable Use Case Membuat List of Account Payable Proses interaksi ini dimulai ketika bagian Finance & Accounting ingin mencetak daftar Account Payable. Bagian ini akan memilih menu Laporan, kemudian daftar Account Payable. Selanjutnya memilih tanggal awal laporan, tanggal akhir laporan serta menekan tombol view.

40 128 Object Function Account Payable get_ap(), print() Tabel 4.27 Use Case Specification untuk Membuat Purchasing Report Use Case Object Function Membuat Purchasing Report Proses interaksi ini dimulai ketika bagian Purchasing ingin mencetak Laporan Pembelian untuk pihak manajemen perusahaan. Bagian Logistic akan memilih menu Laporan, kemuian Laporan Pembelian. Selanjutnya memilih tanggal awal, tanggal akhir serta menekan tombol view. PO, PODetail get(datapo), calculate_totalpurchasing(), print() Tabel 4.28 Use Case Specification untuk Membuat Purchase Journal Report Use Case Object Function Membuat Purchase Journal Report Proses interaksi ini dimuli ketika bagian Finance & Accounting ingin mencetak Laporan Jurnal Pembelian yang ditujukan untuk pihak manajemen. Maka bagian Finance & Accounting akan memilih menu Laporan, kemudian Laporan Jurnal Pembelian. Selanjutnya memilih tanggal awal, tanggal akhir serta menekan tombol view. PO, GR, Supplier, Subcontaractor, AP get(po), get(relatedgr), calculate_total(), print() Tabel 4.29 Use Case Specification untuk Membuat Purchase Return Journal Report Use Case Object Function Membuat Purchase Return Journal Report Proses interaksi ini dimuli ketika bagian Finance & Accounting ingin mencetak Laporan Jurnal Retur Pembelian yang ditujukan untuk pihak manajemen. Maka bagian Finance & Accounting akan memilih menu Laporan, kemudian Laporan Jurnal Pengeluaran Kas. Selanjutnya memilih tanggal awal, tanggal akhir serta menekan tombol view. GR, PRDO, Supplier, AP get(gr), get(relatedprdo), calculate_totalpurchasereturn(), print()

41 129 Tabel 4.30 Use Case Specification untuk Membuat Cash Disbursement Journal Report Use Case Object Function Membuat Cash Disbursement Journal Report Proses interaksi ini dimuli ketika bagian Finance & Accounting ingin mencetak Laporan Jurnal Pengeluaran Kas yang ditujukan untuk pihak manajemen. Maka bagian Finance & Accounting akan memilih menu Laporan, kemudian Laporan Jurnal Pengeluaran Kas. Selanjutnya memilih tanggal awal, tanggal akhir serta menekan tombol view. BPV, RfP, Supplier, Subcontractor, AP get(bpv), get(relatedrfp)calculate_totalcashdisbursement(), print() Tabel 4.31 Use Case Specification untuk Membuat Cash Disbursement Report Use Case Object Function Membuat Cash Disbursement Report Proses interaksi ini dimulai ketika bagian Finance & Accounting ingin mencetak Laporan Pengeluaran Kas. Bagian Finance & Accounting akan memilih menu Laporan, kemudian Laporan Pengeluaran Kas. Selanjutnya memilih tanggal awal, tanggal akhir serta menekan tombol OK. BPV, Supplier, Subcontractor, Account Payale get(bpv), get(relatedrfp)calculate_totalcashdisbursement(), print() Tabel 4.32 Use Case Specification untuk Membuat Supplier Performance Analysis Report Use Case Object Function Membuat Supplier Performance Analysis Report Proses interaksi ini dimulai ketika bagian Purchasing ingin mencetak Laporan Anaisis Kinerja Supplier yang ditujukan untuk pihak manajemen perusahaan. Maka bagian Purchasing akan memilih menu Laporan, kemudian Laporan Analisis Kinerja Supplier. Selanjutnya memilih tanggal awal, tanggal akhir, serta menekan tombol view. Supplier, PO, Material, GR, PRDO get(supplier), get(po), get(material), get(gr), get(prdo), print() Berikut merupakan sequence diagram untuk masing-masing use case yang terdapat pada Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang.

42 Gambar 4.25 Sequence Diagram untuk Use Case Mendata Material Baru 130

43 Gambar 4.26 Sequence Diagram untuk Use Case Mendata Material Baru ( Add Material Type) 131

44 132 Staff Purchasing window: Material Type create() cmb Search Grid Material Type Material Type Loop get_materialtype() return select Search by select() input keyword find() get_detail() return return Gambar 4.27 Sequence Diagram untuk Use Case Mendata Material Baru ( Add Material Type-Search Material Type)

45 Gambar 4.28 Sequence Diagram untuk Use Case Mendata Material Baru ( Add Material Type-Navigation Button) 133

46 Gambar 4.29 Sequence Diagram untuk Use Case Mendata Material Baru ( Add UoM) 134

47 Gambar 4.30 Sequence Diagram untuk Use Case Mendata Material Baru (Search Material) 135

48 Gambar 4.31 Sequence Diagram untuk Use Case Mendata Material Baru (Navigation Button) 136

49 Gambar 4.32 Sequence Diagram untuk Use Case Mendata Service Baru 137

50 Gambar 4.33 Sequence Diagram untuk Use Case Mendata Service Baru (Add Service Type) 138

51 Gambar 4.34 Sequence Diagram untuk Use Case Mendata Service Baru (Add Service Type-Search Service Type) 139

52 Gambar 4.35 Sequence Diagram untuk Use Case Mendata Service Baru (Add Service Type-Navigation Button) 140

53 Gambar 4.36 Sequence Diagram untuk Use Case Mendata Service Baru (Search Service) 141

54 Gambar 4.37 Sequence Diagram untuk Use Case Mendata Service Baru (Navigation Button) 142

55 Gambar 4.38 Sequence Diagram untuk Use Case Mendata Supplier Baru 143

56 144 Gambar 4.39 Sequence Diagram untuk Use Case Mendata Supplier Baru (Add City) Gambar 4.40 Sequence Diagram untuk Use Case Mendata Supplier Baru (Add Bank)

57 Gambar 4.41 Sequence Diagram untuk Use Case Mendata Supplier Baru (Search Supplier) 145

58 Gambar 4.42 Sequence Diagram untuk Use Case Mendata Supplier Baru (Navigation Button) 146

59 Gambar 4.43 Sequence Diagram untuk Use Case Mendata Subcontractor Baru 147

60 148 Gambar 4.44 Sequence Diagram untuk Use Case Mendata Subcontractor Baru (Add City) Gambar 4.45 Sequence Diagram untuk Use Case Mendata Subcontractor Baru (Add City)

61 Gambar 4.46 Sequence Diagram untuk Use Case Mendata Subcontractor Baru (Search Subcontractor) 149

62 Gambar 4.47 Sequence Diagram untuk Use Case Mendata Subcontractor Baru (Navigation Button) 150

63 Gambar 4.48 Sequence Diagram untuk Use Case Membuat Purchase Requisition 151

64 Gambar 4.49 Sequence Diagram untuk Use Case Membuat Request for Quotation 152

65 Gambar 4.50 Sequence Diagram untuk Use Case Mendata Quotation from Client 153

66 Gambar 4.51 Sequence Diagram untuk Use Case Membuat Purchase Order 154

67 Gambar 4.52 Sequence Diagram untuk Use Case Membuat Purchase Order (Supplier Selection) 155

68 156 Staff Purchasing Window: Purchase Order RfQ Detail PO Detail cmb_subcontractor Opt click System [system] enable_fal se() create() Window: PO_Result_Show get_data() compare_serviceprice return calculate_subtotal() calculate_grandtotal() Alt click Save save() click Cancel [supplier] click Subcontractor enable_false() create() Wi ndow: PO_Result_Show get_data() compare_serviceprice() ret urn calculate_subtotal() calculate_grandtotal() Alt click Save save() click Cancel Gambar 4.53 Sequence Diagram untuk Use Case Membuat Purchase Order (Subcontractor Selection)

69 Gambar 4.54 Sequence Diagram untuk Use Case Membuat Purchase Order (View PO) 157

70 Gambar 4.55 Sequence Diagram untuk Use Case Membuat Good Receipt 158

71 Gambar 4.56 Sequence Diagram untuk Use Case Membuat Good Receipt (View GR) 159

72 Gambar 4.57 Sequence Diagram untuk Use Case Membuat Site Delivery Order 160

73 Gambar 4.58 Sequence Diagram untuk Use Case Membuat Site Material Return 161

74 Gambar 4.59 Sequence Diagram untuk Use Case Membuat Purchase Return Delivery Order 162

75 Gambar 4.60 Sequence Diagram untuk Use Case Membuat Debit Memo 163

76 164 Staff Finance & Accounting create select PeriodeAwal JatuhTempo Window: List of Account Payable AP select PeriodeAkhir JatuhTempo create Grid AP Loop get_ap() return return click Print create Document pr int( ) click Cancel Gambar 4.61 Sequence Diagram untuk Use Case Membuat List of Account Payable

77 Gambar 4.62 Sequence Diagram untuk Use Case Membuat Purchasing Report 165

78 Gambar 4.63 Sequence Diagram untuk Use Case Membuat Purchase Journal Report 166

79 Gambar 4.64 Sequence Diagram untuk Use Case Membuat Purchase Return Journal Report 167

80 Gambar 4.65 Sequence Diagram untuk Use Case Membuat Cash Disbursement Journal Report 168

81 169 Gambar 4.66 Sequence Diagram untuk Use Case Membuat Supplier Performance Analysis Report Function List Berikut ini merupakan function list dari Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang, dikelompokkan menurut use case. Dapat dilihat pada tabel dibawah ini: Tabel 4.33 Function List Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang Funcion Type Complexity get() read simple generateid() read simple add() update simple

82 170 save() update simple update() update simple select() read simple find() read simple print() read simple checkexist() read simple parser() read simple calculate_subtotalpo() compute medium calculate_grandtotalpo() compute medium calculate_actualbudget() compute medium enable_false() read simple compare_materialprice read, compute complex compare_serviceprice read, compute complex delete() update simple clearall() update simple calculate_totalpurchasing() compute medium calculate_totalpurchasereturn() compute medium calculate_totalcashdisbursement() compute medium User Interface Rancangan user interface dari Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas pada PT. Nakami Kinema Cemerlang menggunakan bahasa Inggris sebagai bahasa utama. Berikut gambaran dari rancangan user interface Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluran Kas PT. Nakami Kinema Cemerlang Dialogue Style Dialogue Style yang digunakan adalah menu selection dan form untuk entri data. Selain itu, sistem juga didukung dengan fasilitas pencetakan yang dikoneksikan secara langsung ke printer. Tabel 4.35 menunjukkan overview dari windows user interface dan hasil pencetakannya.

83 171 Tabel 4.34 Daftar Windows User Interface dan Printouts Windows Form Login Form Main Menu Form Change Password Form Purchase Requisition Form Request for Quotation Form Budget Form Purchase Order Form Good Receipt Form Reminder SDO Form Site Delivery Order Form Subcon Work Order Form Site Material Return Form Purchase Return Delivery Order Form Debit Memo Form Request for Payment Form Bank Payment Voucher Form List of Account Payable Form Material Data Form Material Type Form Service Data Form Service Type Form Supplier Form Subcontractor Form Purchasing Report Form Purchase Journal Report Form Purchase Return Journal Report Form Cash Disbursement Journal Report Form Cash Disbursement Report Form Supplier Performance Analysis Report Printouts Purchase Requisition Request for Quotation Budget Purchase Order Good Receipt Site Delivery Order Subcon Work Order Site Material Return Purchase Return Delivery Order Debit Memo Request for Payment Bank Payment Voucher List of Account Payable Purchasing Report Purchasing Report per Material Purchasing Report per Service Purchasing Report per Supplier Purchasing Report per Subcontractor Purchase Journal Report Purchase Return Journal Report Cash Disbursement Journal Report Cash Disbursement Report Supplier Performance Analysis Report

84 Overview Gambar 4.67 menunjukkan navigation diagram yang menggambarkan hubungan antarwindow dari Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang.

85 Gambar 4.67 Navigation Diagram Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang 173

86 Examples Gambar 4.68 Window Login Gambar 4.69 Window Main Form (File)

87 175 Gambar 4.70 Window Main Form (Master Data) Gambar 4.71 Window Main Form (Business Partner)

88 176 Gambar 4.72 Window Main Form (Transaction) Gambar 4.73 Window Main Form (Data Uploader)

89 177 Gambar 4.74 Window Main Form (Report) Gambar 4.75 Window Change Password

90 178 Gambar 4.76 Window Material Data Gambar 4.77 Window Material Type

91 179 Gambar 4.78 Window Service Data Gambar 4.79 Window Service Type

92 180 Gambar 4.80 Window Supplier Data Gambar 4.81 Window Subcontractor Data

93 181 Gambar 4.82 Window Purchase Requisition Gambar 4.83 Window Request for Quotation

94 182 Gambar 4.84 Window Quotation from Client Gambar 4.85 Window Purchase Order

95 183 Gambar 4.86 Window Purchase Order (pemilihan Supplier atau Subcontractor) Gambar 4.87 Window List of Purchase Order

96 184 Gambar 4.88 Window Detail of Purchase Order Gambar 4.89 Window Good Receipt

97 185 Gambar 4.90 Window List of Good Receipt Gambar 4.91 Window Detail of Good Receipt

98 186 Gambar 4.92 Window Subcon Work Order Gambar 4.93 Window Purchase Return Delivery Order

99 187 Gambar 4.94 Window List of Purchase Return Delivery Order Gambar 4.95 Window Detail of Purchase Return Delivery Order

100 188 Gambar 4.96 Window Debit Memo Gambar 4.97 Window Reminder Site Delivery Order

101 189 Gambar 4.98 Window Reminder Site Delivery Order Detail Gambar 4.99 Window Site Delivery Order

102 190 Gambar Window Site Material Return Gambar Window Budget

103 191 Gambar Window List of Account Payable Gambar Window Request for Payment

104 192 Gambar Window Bank Payment Voucher Gambar Window Purchasing Report

105 193 Gambar Window Purchase Journal Report Gambar Window Purchase Return Journal Report Gambar Window Cash Disbursement Journal Report

106 194 Gambar Window Cash Disbursement Report Gambar Window Supplier Performance Analysis Report

107 Technical Platform Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang akan dikembangkan untuk PC dengan menggunakan bahasa pemrograman Visual Basic 2008.net dan dioperasikan dalam lingkungan Windows yang didukung Microsoft SQL Server 2000 sebagai database engine-nya. User Interface yang digunakan sesuai dengan windows standard. Sistem dioperasikan dengan menggunakan mouse dan keyboard Recommendations The System s Usefulness and Feasibility Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas yang dikembangkan diharapkan akan membantu para pemakainya dalam mengoptimalkan fungsi pencatatan atas transaksi-transaksi yang berkaitan dengan aktivitas pembelian, utang usaha dan pengeluaran kas perusahaan. Disamping itu, sistem juga memungkinkan pembuatan laporan serta jurnal yang berkaitan dengan transaksi pembelian, utang usaha, dan pengeluaran kas yang menyediakan informasi akuntansi yang dapat mendukung pihak manajemen dalam pengambilan keputusan sehubungan dengan kelangsungan bisnis perusahaan Strategy Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas ini akan diimplementasikan secara bertahap, dimulai dengan tahap pengujian untuk mengetahui sejauh mana kapabilitas dan keandalan system yang dirancang dalam memenuhi kebutuhan pemakai di perusahaan.

108 Development Economy Sistem yang dirancang ini memerlukan sumber daya IT sebanyak satu orang software engineer, satu orang system analyst, dan satu orang database administrator. Namun, dimungkinkan juga ketiga peran tersebut dapat dirangkap menjadi satu orang. Hal ini diperlukan untuk mengembangkan sistem lebih lanjut agar system layak dioperasikan dan diimplementasi. sebagai sistem yang digunakan oleh perusahaan. Tabel 4.36 berikut adalah lampiran daftar gaji karyawan berdasarkan Indonesia Kelly Handbook 2008/2009 dengan catatan gaji yang digunakan adalah yang minimal: Tabel 4.35 Daftar gaji karyawan berdasarkan Kelly Handbook 2008/2009 Sumber Daya Jumlah Biaya per Bulan Lama pekerjaan Total Biaya Software Engineer 1 orang Rp 4,000, bulan Rp 12,000, System Analyst 1 orang Rp 4,500, bulan Rp 13,500, Database Administrator 1 orang Rp 4,000, bulan Rp 12,000, Total Rp 37,500, Design Document The Task Berikut akan dijelaskan mengenai deskripsi serta quality goals dari perancangan Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang diawali dengan purpose, corrections to analysis, dan quality goals Purpose Sistem ini dibuat dengan tujuan untuk memudahkan pencatatan transaksitransaksi pembelian, utang usaha, dan pengeluaran kas sehingga dapat mempercepat dan

109 197 mengoptimalkan kinerja karyawan sehubungan dengan pemrosesan transaksi permintaan pembelian; permintaan penawaran harga baik dari Supplier maupun Subcontractor; pesanan pembelian; pencatatan penerimaan material; penugasan kerja kepada Subcontractor; pencatatan penggunaan material dan service secara actual; penerimaan surat tagihan sampai pada pencatatan akuntansi yang berkaitan dengan pembelian, pencatatan utang serta pelunasan utang (pengeluaran kas) dan pembuatan laporan Selain itu juga mempermudah pengendalian internal perusahaan dalam hal pemrosesan transaksi serta meningkatkan akurasi dalam pencatatan transaksi Correction to the Analysis Berdasarkan hasil analisis lebih lanjut terhadap perancangan Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang, ditemukan beberapa koreksi yang perlu dilakukan sebagai kelanjutan dari analisis yang telah dilakukan. Perbaikan dilakukan dengan cara merevisi class diagram yang telah dibuat sebelumnya sehingga menghasilkan class diagram baru Quality Goals Kualitas dari hasil perancangan Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang difokuskan pada beberapa aspek berikut: a) Usable Sistem yang dibangun sangat penting agar dapat diimplementasikan oleh perusahaan dimana sesuai dengan proses bisnis yang berjalan ditambah dengan proses bisnis usulan serta struktur organisasi perusahaan. Sehingga dengan diimplementasikannya sistem ini, maka perusahaan dapat mengatasi

110 198 permasalahan yang dihadapi selama ini dan berguna dalam pencatatan dan pemrosesan transaksi sehari-hari. b) Secure Keamanan dari sistem ini sangat penting untuk menjaga agar tidak ada bagian yang dapat mengakses informasi yang bukan merupakan wewenang bagian tersebut. c) Efficient Sistem yang diimplementasikan ini penting dalam menjaga efisiensi biaya yang dikeluarkan untuk hardware dan software. d) Correct Kriteria ini sangat penting dalam sistem yang dibangun karena sistem harus dapat menjamin ketepatan dan keakuratan informasi yang dihasilkan. e) Reliable Sistem yang dibangun penting untuk dapat diandalkan dalam segi eksekusi fungsi-fungsi yang terdapat dalam sistem, sehingga pemakai tidak mengalami kendala teknis dalam memahami dan mengoperasikan sistem. f) Maintanable Sistem yang dibangun penting karena harus mudah untuk dipelihara agar biaya pemeliharaan dapat ditekan. g) Testable Biaya atas pengujian terhadap sistem sebelum sistem diimplementasikan kuran g penting untuk ditekan dikarenakan sistem yang akan diimplementasikan tidak memerlukan infrastruktur IT yang rumit, sehingga dalam pengujiannya tidak akan memakan biaya yang cukup besar.

111 199 h) Flexible Diharapkan sistem yang dibangun akan mudah untuk ditambah modul sehingga tidak memerlukan biaya yang besar. Oleh karena itu, sistem yang dibangun tingkat fleksibilitasnya penting agar mudah dalam pengembangan selanjutnya. i) Comprehensible Kriteria ini penting agar sistem mudah dipahami dan dimengerti oleh pemakai, dengan kata lain sistem lebih user friendly. j) Reusable Dalam hal ini kriteria reusable kurang penting karena sistem yang dihasilkan tidak perlu digunakan untuk membangun Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas untuk perusahaan lain. k) Portable Kurang relevan karena sistem dirancang untuk technical platform yang bersifat spesifik. l) Interoperable Kriteria ini penting karena diharapakan sistem yang dibangun dapat dengan mudah diintegrasikan dengan sistem yang sudah ada di perusahaan saat ini. Oleh karena itu penting untuk menekan biaya untuk mengintegrasikan sistem yang akan dibangun dengan sistem yang lain. Tabel 4.36 Kriteria Perancangan Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas Criterion Very Important Important Less Important Irrelevant Easy Fulfilled Usable Secure Efficient

112 200 Correct Reliable Maintanable Testable Flexible Comprehensible Reuseable Portable Interoperable Technical Platform Berikut akan dideskripsikan mengenai equipment, system software, dan system interface, dan design language pada perancangan aplikasi Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang Equipment Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang ini dirancang dan dikembangkan dengan menggunakan arsitektur client-server. Masing-masing client terhubung dengan server melalui LAN, client akan menggunakan platform untuk PC (Personal Computer), dimana antara client dan server akan dihubungkan dengan switch 8 port 10/100Mbps. Untuk keterangan lengkapnya mengenai spesifikasi hardware yang dibutuhkan dapat dilihat pada tabel 4.38 dibawah ini: Tabel 4.37 Spesifikasi hardware untuk implementasi Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang Specification Client Server Motherboard Asus P5QL-SE Asus P5QD Turbo Processor Celeron 1.80 GHz E GHz Hard Disk Drive 80 GB 200 GB NIC (LAN Card) 100 Mbps 100 Mbps Memory 512 MB DDR2 2 GB DDR2

113 201 Monitor 15" Operating System Microsoft Windows Microsoft Windows Server Others keyboard mouse printer scanner System Software Perancangan Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang berdasarkan implementasi sistem dengan menggunakan tools Microsot Visual Studio 2008 dan Microsoft SQL Server 2000 sebagai database engine-nya System Interface Sistem akan tetap memanfaatkan PC, printer dan scanner yang telah ada. Hanya saja diperlukan penambahan beberapa unit PC, printer dan scanner. Sistem harus memiliki interface untuk berhubungan dengan printer atau scanner sehingga printer atau scanner dapat digunakan oleh user Design Language Perancangan dokumen dengan menggunakan notasi UML (Unified Modelling Language) Diagram yang berorientasi objek dengan menggunakan tools Microsoft Visio 2007 sebagai alat untuk menggambarkan dokumen tersebut Architecture Berikut akan dideskripsikan arsitektur dari component, arsitektur dari proses, serta standar dari rancangan yang diimplementasikan pada Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang.

114 Component Architecture Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang dirancang dengan menggunakan arsitektur client-server dengan pola distribusi distributed presentation. Setiap client memiliki component user interface component dan function component, sedangkan server hanya memiliki model component. Gambar dibawah ini menunjukkan arsitektur dari component Sistem Informasi Akuntasi Pembelian, Utang Usaha dan Pengeluaran Kas PT. Nakami Kinema Cemerlang. Gambar Component Diagram Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang

115 Process Architecture Arsitektur proses pada Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang menggunakan pola distribusi distributed presentation, dimana client memiliki komponent user interface, function, system interface, dan memiliki external device yaitu printer dan scanner. Sedangkan untuk server, memiliki komponen model dan system interface. Gambar dibawah menunjukkan arsitektur proses pada Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang. Sedangkan Gambar dibawah ini menggambarkan arsitektur jaringan yang diusulkan. Gambar Deployment Diagram Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang

116 204 Gambar Arsitektur Jaringan Sistem Informasi Akuntansi Pembelian, Utang Usaha dan Pengeluaran Kas PT. Nakami Kinema Cemerlang Standards Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang menggunakan standar perancangan mengikuti standar Windows Application, baik tampilan, letak tombol maupun pesan kesalahan. Berikut ini contoh dari beberapa menu standar dan pesan kesalahan.

117 205 Gambar Standar tombol dan Message box yang digunakan Component Berikut akan dideskripsikan mengenai model component, function component, dan user interface component dari Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang Model Component Model component pada Sistem Informasi Akuntansi Pembelian, Utang Usaha, dan Pengeluaran Kas PT. Nakami Kinema Cemerlang terdiri dari revised class diagram yang merupakan hasil revisi terhadapa analisis pada analysis document Structure Berdasarkan hasil analisis class diagram pada analysis document akan direvisi menjadi revised class diagram dengan menggunakan metode representasi atas private events dan common events. Gambar dibawah ini merupakan hasi dari revised class diagram untuk model component.