BAB 3 ANALISA SISTEM INFORMASI. dikelola secara perseorangan pula, yang didirikan oleh Ny. Umi yang dibantu oleh

Transkripsi

1 52 BAB 3 ANALISA SISTEM INFORMASI 3.1Gambaran Umum Perusahaan Sejarah Singkat Perusahaan Rumah makan ini merupakan perusahaan yang berbentuk perseorangan yang dikelola secara perseorangan pula, yang didirikan oleh Ny. Umi yang dibantu oleh suaminya Bapak Noersalim, SH. Rumah makan ini terletak di jalan Prof. Supomo, SH.14 Tebet Jakarta Selatan, yang mana lokasi tersebut sekaligus sebagai tempat tinggal keluarga dan para karyawannya. Dewasa ini pengusaha wanita terbuka lebar kesempatan untuk menduduki jabatanjabatan tertentu yang dulunya merupakan hak dan monopoli kaum pria saja, dimana akibat tersebut wanita selalu dituntut untuk tampil secara memadai. Dan Ny. Umi tergolong wanita karier yang mampu menempatkan dirinya sejajar dengan pengusahapengusaha wanita lainnya yang berhasil membuka rumah makan sebagai usahanya. Dari pengalaman-pengalamannya yang bermula dari pedagang ayam keliling kampungkampung hingga menjadi pengusaha rumah makan ayam goreng Mbok Berek Ny. Umi. Sebelum usahanya berhasil seperti sekarang ini Ny. Umi dengan dibantu suaminya, kirakira pada tahun 1970 membuka usahanya di Jalan Pegangsaaan Timur Jakarta. Namun tidak mencapai target penjualan yang diinginkan, hal ini tentu merugikan maka usaha tersebut dihentikan dan hanya bertahan satu tahun. Setelah macet tiga tahun, pada tahun 1974 mencoba lagi membuka usahanya dengan menyewa sebuah tempat yang berukuran kecil di Jalan Tanjung Karang. Di tempat ini nasibnya masih sama dan hanya mampu bertahan satu tahun saja. Pada tahun 1975 Ny. Umi

2 53 memindahkan lokasi usahanya yaitu di Jalan Prof. Supomo SH. Tebet Jakarta Selatan daerah yang dianggap cukup strategis dari minat para konsumen/pemakai jasa. Ayam gorengnya semakin lama memikat lidah konsumen di Jakarta. Dan menyadari ayam gorengnya semakin dibutuhkan konsumen maka sebelum kontrakannya habis Ny. Umi membuka tempat usahanya yamg lebih baik dengan membangun sebuah rumah makan yang agak luas atas pinjaman dari bank, juga di Jalan Prof. Supomo SH. 14 Tebet pada tanggal 30 Januari Keputusan perluasan usaha rumah makan tersebut didasarkan atas beberapa pertimbangan yang mapan, antara lain: a. Pada waktu itu belum adanya rumah makan ayam goreng Mbok Berek di kawasan Jakarta b. Untuk dapat mempertahankan menu rasa ayam gorengnya yang khas ayam kampung Mbok Berek yaitu memilih ayam kampung yang masih perawan dan belum pernah bertelur. c. Mengingat kemajuan jaman, perubahan pandangan mengenai menu masakan yang sesuai dengan selera lidah konsumen. Perjalanan memperkenalkan ayam goreng Mbok Berek dimulai dari Mbok Berek yang berasal dari desa Candi Sari Yogyakarta. Karena keahliannya dalam memasak dan mengolah ayam bukan dari pendidikan formal atau pengalaman, tetapi adanya wangsit dari orang tua yang memakai jubah ungu (Weling Simbah Wulung). Meskipun sumber resep dari satu orang tetapi rasanya belum tentu sama. Dan resep bumbu ayam goreng ini adalah hak patent tidak bisa dijiplak dan hanya diwariskan secara turun menurun. Dengan didasari perjuangan yang keras ternyata rumah makan ini menjadi suatu usaha yang mengagumkan, yang dapat terlihat dengan bertambahnya konsumen yang

3 54 datang meskipun hambatan tak urung menghampirinya dan juga mampu bersaing serta berkembang diantara rumah makan yang ada dan sejenis. Bahkan rumah makan ini mampu mengembangkan sayapnya mendirikan rumah makan sejenis dibeberapa tempat atau cabang-cabangnya Struktur Organisasi Direktur Manajer Personalia Manajer Keuangan Manajer Operasional Kepala Accounting Pembelian Kepala Gudang Supervisor Restaurant Staff Staff Staff Staff Staff Gambar 3.1 Struktur Oragisasi PT Noorumi Catur Manunggal (Mbok Berek)

4 Tugas Dan Wewenang Secara garis besar uraian tugas dan tanggung jawab dari masing masing bagian adalah sebagai berikut : Direktur Merupakan pimpinan tertinggi dalam menentukan kebijaksanaan perusahaan dan pengambilan keputusan. Tugas dan Tanggung Jawab : Mengawasi pekerjaan dari operation maupun kantor pusat agar tetap dilaksanakan sesuai dengan prosedur atau ketentuan perusahaan Menerima laporan keuangan tahunan perusahaan Memimpin rapat-rapat perusahaan secara keseluruhan Mempertimbangkan dan mengambil keputusan atas unsur-unsur investasi Manajer Personalia Tugas dan Tanggung Jawab : Membuat perhitungan pembayaran gaji berdasar kartu absen Attendance Form, Form Small Wares Report, Daftar Pinjaman serta membuat dan menyimpan slip gaji dan salary secapitulation Membuat permintaan data gaji Menerima laporan prestasi karyawan dari pihak operation dan pihak head office Membuat laporan perhitungan iuran dan tunjangan jamsostek dan biaya pengobatan

5 56 Manajer Keuangan Tugas dan Tanggung Jawab : Membuat dan menyimpan Bank Receipt Voucher Menerima, menyimpan dan menyerahkan Instruction For Opening L/C dan Quatitation Meng-update buku pengeluaran giro, buku bank, general sales book Menerima dan menyimpan formulir tagihan dan faktur pajak Mengeluarkan cheque atau giro Membuat atau menyimpan bank position report dan memo bukti pencairan giro dan memo bukti penerimaan giro Kepala Accounting Tugas dan tanggung jawab : Menerima dan menyerahkan Supporting Document dan Voucher pembayaran Mengatur dan menyetujui pembayaran berdasarkan dana yang tersedia serta menentukan jatuh temponya giro/cheque tersebut Pada tanggal jatuh tempo menentukan Account Bank untuk pendepositoan giro/cheque Mengkoordinir dan mengawasi keakuratan data akuntansi Membuat laporan tahunan yang diserahkan Direktur Mengontrol agar divisinya mengikuti prosedur dan ketentuan atau peraturan yang telah ditetapkan oleh perusahaan

6 57 Pembelian Tugas dan Tanggung Jawab : Bertanggung jawab atas pembelian barang kepada supplier Memeriksa setiap bukti-bukti pembelian dan dicocokkan dengan bukti pembayaran Membuat setiap PR (Purchasing Requisition), PO (Purchase Order), WSO (Weekly Standing Order), ROG (Receipt of Goods), L/C. Manajer Operasional Yang mengendalikan jalannya seluruh aktivitas operasi perusahaan untuk mencapai tujuan perusahaan yang telah ditetapkan. Tugas dan Tanggung Jawab : Mengawasi pelaksanaan kerja dan operasional masing-masing restaurant termasuk mengontrol penyimpangan-penyimpangan prosedur kerja yang telah ditentukan yang mungkin dilakukan karyawan atau manager restaurant Menerima laporan operasional budget, operasional expenses, laporan pemakaian barang, dan mencek apakah sesuai dengan penjualan Membuat dan melaksanakan rencana perjalanan ke restaurant-restaurant yang menjadi tanggung jawab dan membantu memecahkan masalah hambatan pekerjaan yang sedang dihadapi bawahannya Mengontrol agar divisinya mengikuti peraturan dan prosedur yang telah ditetapkan perusahaan Mengadakan spot-check keuangan restaurant (brankas dan register) Membuat area manager unit assesment setiap kali kunjungan ke restaurant

7 58 Memberikan surat peringatan bagi manager restaurant dan assistant manager restaurant atas dasar-dasar penyimpangan yang terjadi sejauh menyangkut kegiatan operasi restaurant Supervisor Restaurant Merupakan bagian tertinggi dalam bagian restaurant. Supervisor restaurant bertanggung jawab atas kelancaran kegiatan operasional restaurant secara keseluruhan, dengan tugas-tugas sebagai berikut : Menyusun rencana kegiatan yang dapat meningkatkan kerja sama dan saling menghormati antar sesama karyawan. Mengatur jadwal cuti, off dan pergantian tugas karyawan restaurant. Menerima laporan absensi karyawan dan membuat laporan kondite karyawan. Merencanakan dan mengontrol pemakaian barang (in & out) dengan inventory menyeluruh baik barang ataupun uang. Mengontrol pemakaian peralatan, standar karyawan dan membuat laporan administrasi yang berupa Petty Cash, modal restaurant, inventory, laporan waste penggunaan barang-barang dan lain-lain. Bertanggung jawab atas masalah di bidang kepegawaian (penerimaan dan pemecatan karyawan) Kepala Gudang Merupakan jabatan tertinggi dalam bagian gudang. Kepala Gudang bertanggung jawab atas kelancaran kegiatan operasional gudang secara keseluruhan, dengan tugas dan tanggung jawab sebagai berikut :

8 59 Bertanggung jawab atas proses keluar masuknya barang di gudang. Membuat Laporan mengenai persediaan Bertanggung jawab untuk mengendalikan persediaan dalam pengawasan mutu dan pengendalian stok barang di gudang Melakukan Persetujuan penukaran barang 3.2 Prosedur Sistem yang Sedang Berjalan Prosedur Pembelian Dan Penerimaan Bahan yang Diterapkan Pada PT Noorumi Catur Manunggal (Mbok Berek) Prosedur pembelian bahan yang diterapkan pada PT Noorumi Catur Manunggal (Mbok Berek) adalah sebagai berikut : 1. Berdasarkan ramalan penjualan (sales forecast), Manajer Pembelian membuat rencana produksi dan daftar kebutuhan bahan untuk produksi. Jika bahan yang ada di gudang tidak mencukupi, maka manajer pembelian melakukan pembelian. 2. Bagian pembelian membuat surat permintaan penawaran harga untuk mendapatkan penawaran harga yang bersaing dari berbagai supplier dan syarat pembayaran yang diinginkan. 3. Berdasarkan surat penawaran harga dari berbagai supplier, bagian pembelian memilih supplier yang menawarkan harga yang paling menguntungkan dari syarat pembayaran yang diinginkan. 4. Bagian pembelian membuat PO (Purchase Order) empat rangkap yang akan didistribusikan kepada : a. Rangkap ke-1 diberikan kepada supplier sebagai order pembelian resmi yang dikeluarkan oleh PT Noorumi Catur Manunggal (Mbok Berek).

9 60 b. Rangkap ke-2 didistribusikan kepada bagian Accounting. c. Rangkap ke-3 disimpan oleh bagian pembelian, sebagai arsip. d. Rangkap ke-4 didistribusikan kepada bagian gudang. 5. Bagian gudang menerima barang (bahan) dan copy surat jalan dari supplier, kemudian memeriksa barang dan mencocokkan copy surat jalan dengan kuantitas barang (bahan) yang diterima dari supplier dengan PO yang diterima dari bagian pembelian. Setelah semuanya cocok, bagian gudang membuat BTG (Bukti Terima Gudang) tiga rangkap, yang didistribusikan kepada : a. Rangkap ke-1 didistribusikan kepada supplier melalui bagian Accounting. b. Rangkap ke-2 didistribusikan kepada bagian Accounting. c. Rangkap ke-3 disimpan oleh bagian pembelian beserta copy surat jalan, sebagai arsip. Bagian gudang mencatat kuantitas barang yang diterima ke dalam kartu gudang dan melakukan penyimpanan barang. 6. Bagian accounting mencocokkan PO dengan copy surat jalan, kemudian mencatat transaksi pembelian tersebut dalam Bukti Terima Gudang (BTG) untuk pencatatan hutang, dan memasukkan data kedalam komputer. Kebijakan pembelian yang telah ditetapkan dan diterapkan pada PT Noorumi Catur Manunggal (Mbok Berek) adalah : 1. Pembelian tidak didasarkan Reorder Point, melainkan berdasarkan atas laporan stock dari Bagian Gudang. 2. Penentuan kuantitas pembelian tidak ditetapkan berdasarkan EOQ, melainkan berdasarkan atas daftar kebutuhan bahan yang dibuat sendiri oleh Manajer Pembelian.

10 61 3. Pembelian hanya boleh dilakukan oleh Bagian Pembelian. Bagian lain tidak dapat melakukan pembelian kepada supplier Prosedur Pengelolaan Persediaan yang Diterapkan di Bagian Gudang Pusat PT Noorumi Catur Manunggal (Mbok Berek) Adapun prosedur pengelolaan persediaan yang diterapkan di Bagian Gudang Pusat PT Noorumi Catur Manunggal (Mbok Berek) adalah sebagai berikut : 1. Bagian Cabang mengirimkan surat permintaan barang (bahan) kepada Bagian Gudang Pusat. 2. Berdasarkan bukti permintaan barang tersebut, Bagian Gudang Pusat membuat Bukti Barang Keluar (bahan) sebanyak 3 (tiga) rangkap, yang didistribusikan kepada : a. Rangkap ke-1 didistribusikan kepada Bagian Cabang beserta barang. b. Rangkap ke-2 didistribusikan kepada Bagian Accounting. c. Rangkap ke-3 disimpan oleh Bagian Gudang Pusat sebagai arsip. 3. Bagian Gudang Pusat mencatat mutasi persediaan barang ke dalam Kartu Stock. 4. Apabila pada saat pemakaian terdapat barang yang kualitasnya sudah tidak layak untuk dipakai, maka sesuai dengan perjanjian dengan supplier Bagian Gudang Pusat akan mengeluarkan Retur Barang supplier sebanyak 3 (tiga) rangkap, yang didistribusikan kepada : a. Rangkap ke-1 didistribusikan kepada supplier sebagai retur resmi yang dikeluarkan oleh PT Noorumi Catur Manunggal (Mbok Berek). b. Rangkap ke-2 didistribusikan kepada Bagian Accounting. c. Rangkap ke-3 disimpan oleh Bagian Gudang sebagai Arsip.

11 62 5. Apabila pada saat pemakaian barang di Bagian Cabang terdapat barang yang kualitasnya sudah menurun (hampir kadarluasa), maka Bagian Cabang akan mengeluarkan retur barang cabang sebanyak 2 (dua) rangkap, yang akan didistribusikan kepada : a. Rangkap ke-1 didistribusikan kepada Bagian Gudang Pusat sebagai bukti retur barang beserta barang. b. Rangkap ke-2 disimpan oleh Bagian Cabang sebagai arsip. Kebijakan yang telah ditetapkan dan diterapkan pada PT Noorumi Catur Manunggal dalam pengelolaan persediaan bahan baku adalah sebagai berikut : 1. Ijin masuk ke dalam gudang hanya dibatasi kepada Kepala Gudang dan karyawan Bagian Gudang, serta orang-orang dengan kepentingan khusus yang telah mendapat otorisasi dari pejabat yang berwenang untuk masuk ke gudang. 2. Setiap pembelian dan pemakaian bahan baku akan dicatat ke dalam kartu stock, sehingga terlihat bertambah dan berkurangnya persediaan bahan baku yang dimiliki perusahaan setiap saat. 3. Untuk metode penilaian atas persediaan digunakan metode FIFO (First In First Out), dimana barang yang pertama kali dibeli, digunakan sebagai dasar untuk menentukan barang yang dipakai pertama kali. 4. Stock Opname dilakukan sebanyak dua kali dalam setahun.

12 * 8 # Rich Picture Sistem yang Berjalan $ Membuat Cabang Membuat Prediksi pembelian masih menggunakan teori kebiasaan, jadi sering tidak tepat. Barang yang masuk dan keluar sangat banyak, jadi sering tidak terdeteksi persediaan yang sudah mencapai titik minimum Retur Cabang Mengirim Dicek Distribusi Surat Jalan & BBK SPB Mengirim $$$ Manajer Pembelian Surat Permintaan Pembelian Brg (SPPB) Membuat Diserahkan Membuat Mengirim Barang PO Memesan Fax / Telepon Mengirim Fax Dicatat Gudang Kartu Stok Kepala Gudang Membuat Dikeluarkan Surat Jalan & BKP Disimpan Diterima Pengecekan Membuat BTG Membuat Retur Supplier Kurangnya pengontrolan persediaan, sehingga informasi dan laporan ke pembelian sering terlambat Mengirim Suppliers Staff Gudang Gambar 3.2 Rich Picture Sistem yang Berjalan 3.4 Permasalah yang Dihadapi Dari hasil survey dan wawancara yang telah dilakukan, terdapat beberapa permasalahan dengan masih diterapkannya sistem secara manual, yaitu : 1. Sering terjadi kekosongan barang di gudang pada saat cabang meminta barang. Penyebabnya adalah karena sistem pengelolaan persediaan yang sedang berjalan saat ini masih manual. Sedangkan barang yang masuk dan keluar setiap harinya sangat banyak. Sehingga besar kemungkinan terjadi kesalahan pencatatan dan tidak terdeteksinya persediaan barang yang sudah mencapai titik minimum, yang

13 64 mengakibatkan informasi dihasilkan dari Gudang ke pihak Pembelian yang sering terlambat dan tidak akurat. 2. Terjadi adanya pengeluaran materi yang tidak semestinya, dikarenakan terbuangnya barang-barang yang telah kadarluasa akibat penumpukan barang di gudang, yang disebabkan kurangnya pengelolaan informasi yang terarah dan benar diantara bagian Pembelian dan Gudang. Sehingga dalam menentukan kuantitas barang yang akan dibeli, bagian Pembelian hanya menggunakan teori kebiasaan saja. 3.5 Pemecahan Masalah Untuk mengatasi permasalahan yang ada pada sistem berjalan, ditawarkan suatu pembaharuan sistem. Pembaharuan sistem yang dimaksud adalah dengan mengubah sistem berjalan di Bagian Pembelian dan Persediaan, yang semula diterapkan secara manual, menjadi semi terkomputerisasi. Sistem informasi Pembelian dan Persediaan yang akan dirancang memiliki keunggulan sebagai berikut : 1. Apabila persediaan telah mencapai titik pemesanan kembali (reorder point) maka akan ada fitur Reminder sistem yang akan terus aktif di bagian Gudang. Setelah pihak gudang mengakses reminder tersebut, maka sistem akan menampilkan daftar barang-barang yang mencapai ROP, sehingga kepala gudang harus membuat Surat Permintaan Pembelian Barang (SPPB) kemudian mencetaknya. Manajer Pembelian akan membuat PO berdasarkan SPPB yang diberikan oleh bagian gudang. Manajer Pembelian menentukan Supplier mana yang akan di pilih untuk memasokkan barang. Selain itu, adanya suatu fasilitas bagi staff gudang dalam memasukkan data untuk

14 65 setiap barang yang masuk dan keluar, sehingga memudahkan dan mempercepat proses dalam mencari informasi pada saat dibutuhkan. 2. Manajer Pembelian dapat melakukan proses perhitungan dalam menentukan kuantitas barang yang akan dibeli dengan menggunakan metode EOQ, sehingga pemesanan persediaan barang dapat dideteksi agar tidak terjadi kekosongan atau kelebihan stok 3.6 System Definition yang Diusulkan System definition yang diusulkan pada PT Noorumi Catur Manunggal dimulai pada saat manajer pembelian mendaftarkan barang. Pada saat mendaftarkan barang tersebut, manajer pembelian akan memasukkan identitas-identitas barang serta melakukan perhitungan ROP dan EOQ. Apabila terjadi peningkatan atau penurunan tingkat permintaan, maka manajer pembelian dapat merubah identitas barang dengan melakukan perhitungan ROP dan EOQ sesuai dengan keadaan yang sedang dihadapi. Manajer pembelian juga bertugas untuk mendaftarkan supplier-supplier yang dijadikan pemasok barang. Apabila terjadi perubahan identitas supplier (misalnya : perubahan no telp, alamat, dll) maka manajer pembelian dapat melakukan perubahan terhadap data supplier tersebut. Dan apabila terdapat data supplier yang sudah tidak diperlukan lagi, maka manajer pembelian dapat menghapusnya. Kepala gudang akan mendaftarkan data cabang-cabang yang akan menggunakan barang-barang yang terdapat di gudang pusat. Dan apabila data cabang tersebut sudah tidak diperlukan lagi, maka dapat dihapus. Terdapat suatu reminder yang aktif di pihak gudang pada saat terdapat barang yang mencapai Reorder Point (ROP). Setelah kepala gudang mengaksesnya maka, sistem

15 66 akan menampilkan barang-barang yang mencapai ROP. Kemudian kepala gudang diminta untuk membuat Surat Permohonan Pembelian Barang (SPPB) yang akan diberikan kepada pihak pembelian. Setelah SPPB tersebut dicetak dan diberikan pada manajer pembelian, maka manajer pembelian akan meng-approve SPPB tersebut dan kemudian membuat Purchase Order (PO) berdasarkan SPPB yang diterima dari pihak gudang. Manajer pembelian akan memilih supplier sesuai dengan barang yang di supply oleh masing-masing supplier. Setelah selesai maka sistem akan menampilkan hasil PO yang akan dicetak dan dikirim kepada supplier. Manajer pembelian akan mencetak dan mengirim PO kepada supplier. Supplier akan mengirimkan barang yang dipesan Manajer Pembelian..Saat pihak gudang menerima barang dari supplier, maka pihak gudang akan memeriksa kuantitas serta kondisi fisik barang dan mencocokkan barang yang diterima tersebut dengan PO yang dibuat oleh manajer pembelian. Setelah semuanya cocok, maka pihak gudang akan meminta persetujuan kepada manajer pembelian sebelum mencatat barang yang masuk tersebut ke dalam sistem. Setelah manajer pembelian merubah status PO tersebut menjadi approve, maka pihak gudang akan mencatat barang masuk ke dalam sistem. Bagian Gudang bertanggung jawab untuk menyimpan dan mengatur letak pada rak-rak barang (bahan) agar sesuai dengan prinsip FIFO. Untuk memenuhi kebutuhan setiap harinya, pihak cabang mengirimkan Surat Permintaan Barang (SPB) kepada gudang pusat. Pihak gudang pusat akan mencatat SPB yang diberikan pihak cabang tersebut ke dalam sistem. Berdasarkan SPB tersebut maka pihak gudang pusat akan membuat catatan barang keluar sebagai bukti terjadi pengeluaran barang. Pada saat pencatatan barang keluar tersebut, maka secara otomatis status SPB yang bersangkutan berubah menjadi approve. Kemudian pihak gudang akan

16 67 mengeluarkan barang-barang yang diminta dan menandatangani SPB yang dibawa pihak cabang tersebut, untuk dikirimkan ke pihak cabang. Setelah selesai mencatat seluruh pengeluaran barang berdasarkan SPB dari tiap cabang, maka sistem akan melakukan perhitungan terhadap jumlah persediaan yang ada di gudang. Apabila terdapat barangbarang yang telah mencapai ROP, maka secara otomatis sistem akan menampilkan reminder bahwa terjadi ROP. Maka pihak gudang diminta untuk segera membuat SPPB pada pihak pembelian. Kepala Gudang akan melakukan pengecekan secara berkala terhadap kualitas dan kuantitas persediaan di gudang. Apabila pada saat pemakaian terdapat barang yang kualitasnya tidak sesuai dengan standar kualitas yang ditentukan, maka Kepala Gudang akan membuat dan mencetak Nota Retur kepada supplier yang dikirim melalui fax. Setelah itu, supplier mengirimkan barang untuk ditukar dengan barang yang akan diretur. Pihak gudang akan memeriksa kualitas dan kuantitas barang yang dikirmkan oleh supplier tersebut dengan mencocokkan dengan Nota Retur Supplier yang telah dibuat. Apabila semuanya telah cocok maka kepala gudang akan merubah status nota retur supplier tersebut menjadi approve. Apabila di pihak cabang terdapat barang-barang yang hampir mencapai titik kadarluasa, maka pihak cabang akan mengeluarkan retur barang cabang untuk mengembalikan barang barang tersebut kepada gudang pusat. Setelah retur dan barang - barang tersebut diterima Kepala/ Staf Gudang pusat maka sebelumnya dilakukan pemeriksaan terlebih dahulu. Apabila barang yang dikirim tersebut belum mencapai titik kadarluasa, maka gudang pusat akan mencatat nota retur cabang tersebut kedalam sistem. Kemudian gudang pusat akan menukar dengan barang yang baru dan kemudian dikirim kembali ke pihak cabang. Kemudian pihak gudang pusat akan mengatur letak

17 68 barang hasil retur cabang tersebut agar menjadi barang yang harus dipakai pertama. Namun apabila barang yang dikirim tersebut sudah kadarluasa maka hal ini dianggap sebagai pengeluaran dari pihak cabang, dan tidak dilakukan penukaran barang. Penukaran barang ini terjadi di gudang pusat karena perputaran persediaan di gudang pusat dianggap lebih cepat dibandingkan pihak cabang. Namun apabila terdapat barang yang dinyatakan rusak karena sudah kadarluasa, ataupun hilang karena sebab-sebab tertentu (misalnya : dicuri, dsb), maka kepala gudang akan mencatat data-data tersebut ke dalam Catatan Barang Rusak atau Catatan Barang Hilang dan akan dilaporkan ke manajer operasional setiap bulannya. Setiap bulan manajer pembelian dan kepala gudang akan mencetak laporan- laporan yang berhubungan dengan pembelian barang dan persediaan. Laporan laporan tersebut akan diserahkan kepada manajer keuangan dan manajer operasional untuk dievaluasi dan dijadikan bahan dalam pengambilan keputusan. 3.7 Rich Picture Sistem yang Diusulkan

18 $ $ $ * 8 # 69 Database Server Informasi Persediaan Pembelian Surat Permintaan Pembelian Barang Mencetak PO Memesan Fax / Telepon Kirim daftar Pesanan Dicek Mengirim Barang Gudang Dikeluarkan Disimpan Input Data Diterima Kepala Gudang Mencetak Dikirim Nota Retur Supplier Mengirim Suppliers Pengecekan Mengirim Barang dan Surat Jalan SPB Staff Gudang Distribusi Membuat Input Data Nota Retur Cabang Membuat $ Cabang Gambar 3.3 Rich Picture Sistem yang diusulkan 3.8 FACTOR Criteria Suatu sistem semi terkomputerisasi yang dapat mendukung kegiatan operasional Persediaan dan Pembelian sehari-hari khususnya pemesanan barang, penerimaan persediaan, pengeluaran barang, pengawasan mutu, retur barang dan pengendalian stok. Sistem akan menangani masalah pembelian dan persediaan di gudang. Sistem terutama harus dapat menghasilkan informasi yang cepat dan tepat dari data-data yang di-input sehingga dapat membantu pihak yang membutuhkan. Sistem ini akan diimplementasikan pada 2 buah PC (Personal Computer) yang terhubung dalam jaringan LAN (Local Area Network) dan digunakan oleh user sistem 1 orang manajer Pembelian, 1 kepala gudang

19 70 dan 2 orang staf gudang. Sistem ini juga membutuhkan faximile dan beberapa printer untuk mencetak berbagai surat dan laporan yang dibutuhkan. Functionality Mendukung kegiatan operasional Pembelian dan Persediaan khususnya pemesanan barang, penerimaan dan pengeluaran barang, retur barang, pengawasan mutu dan pengendalian stok Application Domain Seorang manajer yang bertanggung jawab dalam segala aktivitas yang berkaitan dengan system, yaitu pemesanan barang, penerimaan barang, pengeluaran barang, retur barang, pengawasan mutu dan pengendalian stok Conditions Sistem dikembangkan sesuai dengan kebutuhan perusahaan untuk menangani aktivitas pemesanan barang, penerimaan barang, pengeluaran barang, retur barang, pengawasan mutu dan pengendalian stok 2 buah PC yang terhubung dengan LAN dan dilengkapi dengan beberapa Technology Objects printer Barang dan Persediaan Menghasilkan suatu informasi yang cepat dan tepat bagi pihak yang membutuhkan serta dapat mengatasi permasalahan-permasalahan yang Responsibility timbul pada aktivitas pemesanan barang, penerimaan barang, pengeluaran barang, retur barang, pengawasan mutu dan pengendalian stok Tabel 3.1 Faktor Criteria

20 Problem Domain Sistem mempunyai sasaran dan bertujuan untuk mengelola informasi tentang aktivitas persediaan barang yaitu pemesanan barang, penerimaan dan pengeluaran barang, pengawasan mutu, retur barang dan pengendalian stok. Pembelian dimulai dari pengiriman PO ke supplier dan diakhiri dengan terpenuhinya permintaan barang yang diminta. Pengelolaan persediaan bertanggung jawab untuk memenuhi kebutuhan cabang sesuai permintaan Application Domain Sistem harus dapat membantu user sistem - Manajer Pembelian dan Kepala Gudang dan 2 Staf Gudang untuk mengelola informasi informasi yang berkaitan dengan persediaan barang di gudang. Manajer Pembelian bertanggung jawab untuk memenuhi permintaan barang dari gudang, melakukan pemesanan kepada supplier, membuat PO. Kepala gudang bertanggung jawab untuk mengelola persediaan di gudang, memenuhi kebutuhan cabang, membuat nota retur ke supplier, mencatat nota retur cabang dan menjaga kualitas, mutu, dan kuantitas persediaan. Kepala Gudang dapat mengakses seluruh data persediaan. Sedangkan Staf Gudang bertanggung jawab untuk meng-input dan mengelola data-data persediaan, tanpa dapat merubah data-data tersebut. Manajer Operasional melakukan pengecekan terhadap kesesuaian data pembelian dan persediaan di gudang pada saat dilakukan physical check. Sistem ini dapat menghasilkan surat dan laporan yang dibutuhkan. Sistem juga dilengkapi dengan fasilitas pencarian informasi yang berkaitan dengan persediaan dan fasilitas reminder sistem. Adanya tampilan menu memudahkan user sistem dalam menggunakan sistem ini.

21 Problem Domain Analysis Classes Class candidate dan class dari system definition adalah sebagai berikut : Class Candidate - Manajer Pembelian - User ID & Password - P.O. - Database - Persediaan - Kepala Gudang - Staf Gudang - Manajemen Accounting - Gudang - Surat Permintaan Pembelian Barang - Surat Permintaan Barang Class - Barang - Persediaan - P.O. - Nota Retur Supplier - Nota Retur Cabang - Supplier - Cabang - Surat Permintaan Pembelian Barang - Surat Permintaan Barang - Catatan Barang Rusak - Catatan Barang Hilang - Sales Order - Supplier - Barang - Bukti Keluar Gudang - Nota Retur Supplier - Staf Pengiriman - Cabang - Supervisor Restaurant

22 73 - Nota Retur Cabang - Laporan Persediaan - Catatan Barang Hilang - Catatan Barang Rusak - Hak Akses - Informasi - Sistem Tabel 3.2 Class Candidate dan Class Beberapa Class Candidate di atas yang akan menjadi class akan dijelaskan berikut ini : Barang : Barang dalam hal ini adalah berisi daftar semua bahan persediaan yang terdapat di gudang dan akan dijadikan class. Persediaan : Persediaan berisi informasi tentang barang-barang yang masuk dan keluar dari gudang persediaan (berkaitan dengan fitur Reminder ). Persediaan merupakan target utama dari sistem, sehingga harus dipantau dan dimonitor. P.O. : Purchase Order merupakan surat berisi pesanan kepada supplier yang dan akan menjadi class. Nota Retur Supplier : Retur ini berisi daftar barang yang akan ditukar kepada pemasok dan akan menjadi class. Nota Retur Cabang : Retur ini berisi daftar barang yang akan ditukar oleh pihak cabang dan akan dijadikan class Supplier : Berisi informasi tentang semua supplier yang dijadikan pemasok barang. Cabang : Berisi informasi tentang semua cabang yang akan memakai barang.

23 74 SPPB : Surat Permohonan Pembelian Barang berisi informasi tentang semua barang yang telah mencapai titik ROP dan perlu dilakukan pembelian barang. SPB : Surat Permintaan Barang berisi informasi tentang barang-barang yang diperlukan pihak cabang yang diberikan ke pihak gudang pusat. CBR : Catatan Barang Rusak Berisi informasi tentang barang-barang yang rusak, yang disebabkan oleh kadarluasa, rusak pada saaat pengiriman, dll. CBH : Catatan Barang Hilang berisi informasi tentang barang-barang yang hilang karena dicuri Events berikut : Event Candidate dan event dari system definition yang diusulkan adalah sebagai Event Candidate - Mendaftarkan - Menerapkan - Mencatat - Menggunakan - Membuat - Melihat - Mengubah - Mengakses Event - Mendaftarkan - Membuat - Mengubah - Mencatat - Memasukkan - Menyetujui - Menghapus - Menghitung - Memasukkan - Menyimpan

24 75 - Melihat - Menambah - Menghubungkan - Memilih - Menghitung - Mencetak - Mengirim - Memesan - Memeriksa - Mencocokkan - Mengatur - Mengecek - Menukar - Mengeluarkan - Memberikan - Menandatangani - Menyetujui - Mengembalikan - Mengontrol - Menghapus Tabel 3.3 Event Candidate dan Event Beberapa event candidate tersebut dapat menjadi event, akan dijelaskan di bawah ini :

25 76 Mendaftarkan : Event ini terjadi timbul pada saat sebuah object yang ada dalam sebuah class akan didaftarkan ke dalam sistem. Mengubah : Event ini terjadi pada saat akan mengubah identitas pada class barang, supplier. Membuat : Event ini terjadi pada saat akan membuat PO, Nota Retur Supplier, SPPB, Nota Retur Cabang, dan SPB. Memasukkan : Event ini ada saat user meng-input data-data ke dalam sistem. Menghitung : Event ini akan dilakukan class barang pada saat melakukan perhitungan ROP dan EOQ. Mencatat : Event ini timbul pada saat mencatat barang masuk dan barang keluar dari class persediaan. Menghapus : Event ini timbul pada saat akan menghapus data barang, supplier dan cabang. Menyetujui : Class user melakukan event ini saat akan melakukan persetujuan terhadap surat yang dibutuhkan untuk pemasukan dan pengeluaran barang dari gudang.

26 77 Mendaftarkan Memasukkan Membuat Menghapus Menyetujui Mengubah Menghitung Mencatat Persediaan Supplier Cabang PO CBH CBR Nota Retur Supplier Nota Retur Cabang Barang SPB SPPB Tabel 3.4 Event Table Structures Class barang mempunyai hubungan aggregasi dengan class persediaan. Karena apabila terjadi perubahan object pada class barang, maka object pada class persediaan akan berubah juga. Satu barang terdiri dari satu sampai banyak persediaan. Tipe hubungan aggregasi antara class barang dan class persediaan adalah Container-Content

27 78 karena apabila terjadi penambahan atau pengurangan kuantitas dari class persediaan, tidak akan merubah object pada class barang. Class barang mempunyai hubungan asosiasi dengan class Purchase Order (PO), Nota Retur Supplier, Nota Retur Cabang, Surat Permintaan Pembelian Barang (SPPB), Surat Permintaan Barang (SPB), Supplier, Catatan Barang Rusak (CBH), dan Catatan Barang Hilang (CBH). Suatu barang mempunyai hubungan satu sampai banyak dengan class-class tersebut. Misalnya satu class PO dapat mengakses satu sampai banyak barang. Class persediaan mempunyai hubungan asosiasi dengan class Purchase Order (PO), Nota Retur Supplier, Nota Retur Cabang, Surat Permintaan Barang (SPB), Catatan Barang Rusak (CBH), dan Catatan Barang Hilang (CBH). Suatu persediaan mempunyai hubungan satu sampai banyak dengan class-class tersebut. Misalnya satu class PO dapat mengakses satu sampai banyak persediaan. Karena dalam sebuah PO terdapat satu atau banyak persediaan. Class PO mempunyai hubungan asosiasi dengan class Supplier dan class SPPB. Satu class PO mempunyai hubungan dengan satu supplier. Karena satu PO ditujukan untuk satu supplier. Saat terjadi ROP maka reminder akan aktif dan kepala gudang akan membuat SPPB. Berdasarkan SPPB tersebut maka manajer pembelian membuat PO. satu SPPB mempunyai hubungan satu sampai banyak PO. Karena setiap jenis barang yang diminta pada sebuah SPPB berasal dari supplier yang berbeda-beda. Sehingga satu SPPB dapat menghasilkan satu atau beberapa PO. Class Nota Retur Cabang mempunyai hubungan asosiasi dengan class Cabang. Satu Nota Retur Cabang mempunyai hubungan dengan satu Cabang. Karena satu Nota Retur Cabang ditujukan untuk satu Cabang.

28 79 Class Nota Retur Supplier mempunyai hubungan asosiasi dengan class Supplier. Satu Nota Retur Supplier mempunyai hubungan dengan satu Supplier. Karena satu Nota Retur Supplier ditujukan untuk satu Supplier. Class Surat Surat Permintaan Barang (SPB) mempunyai hubungan asosiasi dengan class Cabang. Satu (SPB) mempunyai hubungan dengan satu Cabang. Karena satu (SPB) ditujukan untuk satu Cabang.

29 PO -No_PO -Tgl_Pemesanan -Tgl_Terima -No_SPPB -Kode_Supplier +Membuat PO() +Menyetujui PO() +Memasukkan Rincian PO() 1 1 Nota Retur Cabang -No_Retur_Cabang -Tanggal -Kode_Cabang -Kode_Barang -Qty_Barang +Membuat Nota Retur Cabang() +Memasukkan Rincian Nota Retur Cabang() * 1 Supplier -Kode_Supplier -Nama_Supplier -Alamat -No_Telp -Kode_Barang +Mendaftarkan Supplier() +Mengubah Identitas Supplier() +Menghapus Supplier() 1 1 Nota_Retur_Supplier -No_Retur_Supplier -Tanggal -Kode_Supplier -Kode_Barang -Qty_Barang +Membuat Nota Retur Supplier() +menyetujui Nota retur Supplier() +Memasukkan Rincian Retur Supplier() 1 CBR -No_CBR -Tanggal -Kd_Brg -Qty_Brg +Membuat CBR() +Memasukkan Rincian CBR() SPPB -No_SPPB -Tanggal -Kd_Brg -Qty_Brg +Membuat SPPB() +Menyetujui SPPB() +Memasukkan Rincian SPPB() * 1..* 1..* 1..* 1..* Barang -Kode_Barang -Group_Barang -Nama_Barang -Satuan -ROP -EOQ +Mendaftarkan Barang() +Mengubah Identitas Barang() +Menghapus Barang() +Menghitung ROP() +Menghitung EOQ() 1 1..* 1..* 1..* 1 Cabang -Kode_Cabang -Nama_Cabang -Alamat -No_Telp +Mendaftarkan Cabang() +Menghapus Cabang() 1 CBH -No_CBH -Tanggal -Kd_Barang -Qty_Brg +Membuat CBH() +Memasukkan Rincian CBH() * 1..* * 1..* Persediaan -Kode_Barang -Jumlah_Persediaan +Mencatat Barang Masuk() +Mencatat Barang Keluar() 1..* 1 SPB -No_SPB -Tanggal -Kode_Cabang -Kd_Brg -Qty_Brg +Membuat SPB() +Menyetujui SPB() +Memasukkan Rincian SPB() 1..* 1..* Gambar 3.4 Class Diagram Behavior Berikut ini merupakan behavior pattern dari masing-masing class : 1. Class Barang

30 81 / Mengubah_Data_Barang / Mendaftarkan_Barang Terdaftar / Mengubah_Data_Barang / Dihapus Registrated Gambar 3.5 Behaviour Pattern Class Barang 2. Class Supplier / Mengubah_Identitas_Supplier / Mendaftarkan Supplier Terdaftar / Menghapus Gambar 3.6 Behaviour Pattern Class Supplier 3. Class Cabang / Mendaftarkan_Cabang / Ditutup Terdaftar Gambar 3.7 Behaviour Pattern Class Cabang 4. Class Persediaan / Mencatat_Barang _Masuk / Mencatat_Begining_Inventory Registrated / Mencatat_Barang_Keluar Gambar 3.8 Behaviour Pattern Class Persediaan

31 82 5. Class PO / Mencatat_Rincian_Pesanan / MembuatPO Created / Mencatat_Rincian _Pesanan Registrated / Menyetujui Approve Gambar 3.9 Behaviour Pattern Class PO 6. Class Nota Retur Supplier / Mencatat_Rincian_Barang / Membuat_Nota_Retur_Supplier Created / Mencatat Rincian Barang Registrated / Approve Ditukar Gambar 3.10 Behaviour Pattern Class Nota Retur Supplier 7. Class Nota Retur Cabang

32 83 / Mencatat_Rincian_Retur_Cabang / Membuat_Nota_Retur_Cabang Created / Mencatat_Rincian_Retur_Cabang Registrated / Menyetujui Tukar Gambar 3.11 Behaviour Pattern Class Nota Retur Cabang 8. Class CBR / Mencatat_Barang_Rusak / Membuat CBR Created / Mencatat_Barang_yg_Rusak / Record Registrated Recorded Gambar 3.12 Behaviour Pattern Class CBR 9. Class CBH / Mencatat_Barang_Hilang / Membuat CBH Created / Mencatat_Barang_yg_Hilang / Record Registrated Recorded Gambar 3.13 Behaviour Pattern Class CBH 10. Class Surat Permintaan Barang

33 84 / Mencatat_Rncian_Permintaan / MembuatSPB / Mencatat_Rincian_Permintaan Created Registrated / Menyetujui Approve Gambar 3.14 Behaviour Pattern Class SPB 11. Class Surat Permintaan Pembelian Barang / Mencatat_Rincian_Permintaan / MembuatSPPB / Mencatat_Rincian_Permintaan Created Registrated / Menyetujui Approve Gambar 3.15 Behaviour Pattern Class SPPB Dari behavior pattern diatas dapat ditentukan jenis event yang dialami masingmasing class, yaitu event yang terjadi hanya sekali (sequnce/selection) ataupun yang terjadi berulangkali selama lifetime-nya (iteration events). Gambar event table

34 85 dibawah ini akan menjelaskan jenis event dari masing-masing class. Lambang * menandakan bahwa event tersebut terjadi berulang-ulang kali pada class bersangkutan. Sedangkan lambang + menandakan bahwa event tersebut hanya terjadi sekali dalam lifetime-nya. Mendaftarkan Memasukkan Membuat Menghapus Menyetujui Mengubah Menghitung Mencatat Persediaan * Supplier + + * Cabang + + PO * + + CBH * + CBR * + Nota Retur Supplier Nota Retur Cabang * + + * + + Barang + + * * SPB * + + SPPB * + + Tabel 3.5 Event Table

35 Usage Purchasing and Inventory Information System Mendaftarkan Cabang Menutup Cabang Menyetujui Nota Retur Supplier Membuat Nota Retur Supplier Memeriksa Pengelua ran Barang Membuat CBR Memeriksa Penerimaa n Barang Masuk Membuat CBH Membuat SPPB Memeriksa CBR Memeriksa SPPB Kepala Gudang Memeriksa Nota Retur Cabang Memeriksa CBH Mengingatkan reorder barang Bagian Gudang (Staff Gudang) Membuat Penerimaan Barang Masuk Memeriksa Nota Retur Supplier Membuat Pengeluara n Barang Menghitung EOQ Menghitung ROP Mendaftarkan Supplier Membuat Nota Retur Cabang Memeriksa Daftar Cabang Memeriksa Daftar Persediaan Memeriksa Barang Menghapus Data Supplier Memeriksa Daftar Supplier Mengubah Identitas Supplier Membuat SPB Mendaftarkan Barang Menampilkan barang yang mencapai ROP Menghapus Data Barang Manajer Pembelian Mengubah Identitas Barang Membuat PO memeriksa data PO Menyetujui PO Menyetujui SPPB menampilkan hasil PO Gambar 3.16 Use Case Diagram

36 87 Actor Actor-actor yang berhubungan dengan sistem secara langsung adalah Manajer Pembelian, Manajer Accounting, Kepala Gudang, Staff Gudang yang akan dijelaskan pada tabel-tabel berikut ini : Actor Specification Actor Name : Manajer Pembelian Abstract : Description : Seseorang yang memiliki fungsi untuk melakukan pembelian, mengirim pesanan, persetujuan atas surat jalan dari supplier dengan pesanan, mendaftarkan dan menghapus barang dan cabang ke dalam sistem. Tabel 3.6 Actor Spesification untuk Manajer Pembelian Actor Specification Actor Name : Kepala Gudang Abstract : Description : Seseorang yang memiliki fungsi untuk mengawasi lalu lintas barang ke dan dari gudang, mengatur penempatan, mengawasi persediaan barang, membuat Catatan Barang Rusak, Catatan Barang Hilang, membuat Surat Permintaan Pembelian Barang, membuat Retur Barang ke Supplier. Tabel 3.7 Actor Spesification untuk Kepala Gudang Actor Specification Actor Name : Staff Gudang Abstract : Description : Seseorang yang memiliki fungsi untuk memasukkan data ke dalam sistem, melakukan pengangkatan barang, penempatan barang, dan pengaturan barang. Tabel 3.8 Actor Spesification untuk Staff Gudang

37 88 Base Use Case untuk tiap-tiap Use Case adalah sebagai berikut : Use Case Membuat PO Membuat PO Manajer Pembelian Use Case Name Unique Use Case ID Primary Actor Membuat PO UC-01 Manajer Pembelian Secondary Actor - Brief Description Manajer Pembelian menerima surat permohonan pembelian barang dari pihak Gudang, kemudian Manajer Pembelian menyesuaikan barang yang akan dibeli dengan dari supplier mana barang itu dapat dibeli untuk membuat surat PO. PO tersebut akan dikirimkan kepada Supplier. Preconditions Flow Of Events Adanya Surat Permintaan Pembelian Barang 1. Manajer Pembelian membuat PO sesuai dengan SPPB dari pihak gudang 2. Manajer Pembelian menyesuaikan data permintaan barang yang akan di pesan dengan dari supplier mana barang itu dapat dibeli. 3. Sistem memvalidasi kelengkapan data yang dimasukkan oleh Manajer Pembelian

38 89 4. Setelah data lengkap, Manajer Pembelian akan mencetak PO tersebut Post Condition Priority Alternative Flow and Exceptions Non Behavioral Requirements Assumptions Adanya PO Medium Jika data yang dimasukkan tidak lengkap maka sistem akan menampilkan pesan error Hanya Manajer Pembelian yang memasukkan pesanan ke dalam sistem Semua data-data barang dan data-data supplier telah terdaftar ke dalam sistem Issues N/A Use Case Memeriksa Barang Tabel 3.9 Base Use Case Description untuk Membuat PO Staff Gudang Memneriksa Barang Manajer Pembelian Kepala Gudang

39 90 Use Case Name Unique Use Case ID Primary Actor Memeriksa Barang UC-02 User (Manajer Pembelian, Kepala gudang, Staff Gudang) Secondary Actor - Brief Description User memeriksa barang yang ada di dalam database sistem untuk mengetahui informasi tentang barang Preconditions Informasi barang telah berada di dalam sistem Flow Of Events 1. User memeriksa barang berdasar pengelompokan yang ada 2. Sistem Informasi akan membaca dari database sistem seluruh informasi berdasarkan pengelompokkan yang diminta oleh User 3. Sistem menampilkan daftar Barang 4. Bila diperlukan maka daftar barang dapat dicetak Post Condition Priority Alternative Flow and Exceptions Non Behavioral User telah melihat daftar barang High Jika User ingin membuat List mengenai barang, maka User dapat memerintahkan sistem untuk mencetaknya N/A Requirements Assumptions Issues N/A N/A Tabel 3.10 Base Use Case Description untuk Melihat Daftar Barang

40 91 Use Case Mendaftarkan Supplier Mendaftarkan Supplier Manajer Pembelian Use Case Name Unique Use Case ID Primary Actor Mendaftarkan Supplier UC-03 Manajer Pembelian Secondary Actor - Brief Description Manajer Pembelian mendaftarkan supplier baru yang belum ada di dalam database Preconditions Flow Of Events Adanya calon supplier yang belum terdaftar 1. Manajer Pembelian memasukkan data calon supplier tersebut ke dalam sistem 2. Sistem memvalidasi kelengkapan data yang dimasukkan 3. Jika data yang dimasukkan telah lengkap maka sistem akan mengkonfirmasi dan menyimpan data ke dalam database sistem Post Condition Priority Alternative Flow and Exceptions Data supplier telah ada di dalam sistem Medium Jika data yang dimasukkan tidak lengkap oleh manajer pembelian maka akan timbul pesan error

41 92 Non Behavioral Hanya Manajer Pembelian yang bisa mendaftarkan supplier Requirements Assumptions Issues N/A N/A Tabel 3.11 Base Use Case Description untuk Mendaftarkan Supplier Use Case Menghapus Data Supplier Menghapus Data Supplier Manajer Pembelian Use Case Name Unique Use Case ID Primary Actor Menghapus Data Supplier UC-04 Manajer Pembelian Secondary Actor - Brief Description Manajer Pembelian Menghapus data supplier yang ada di dalam database Preconditions Adanya supplier yang akan dihapus Flow Of Events 1. Manajer Pembelian memilih data supplier yang akan dihapus 2. Manajer Pembelian menghapus data Supplier 3. Sistem akan mengkonfirmasi data supplier yang akan dihapus dan kemudian data supplier tersebut akan

42 93 terhapus dan data akan ter-update. Post Condition Priority Alternative Flow and Exceptions Non Behavioral Data supplier telah terhapus dari sistem High Jika Manajer Pembelian belum memilih Supplier maka, data Supplier tidak dapat dihapus Hanya Manajer Pembelian yang bisa menghapus supplier Requirements Assumptions Issues N/A N/A Tabel 3.12 Base Use Case Description untuk Menghapus Data Supplier Use Case Mendaftarkan Barang Mendaftarkan Barang Manajer Pembelian Use Case Name Unique Use Case ID Primary Actor Mendaftarkan Barang UC-05 Manajer Pembelian Secondary Actor - Brief Description Manajer Pembelian mendaftarkan barang yang belum ada di dalam database

43 94 Preconditions Flow Of Events Adanya barang yang belum terdaftar 1. Manajer Pembelian mendaftarkan data barang tersebut ke dalam sistem 2. Sistem mevalidasi kelengkapan data yang dimasukkan 3. Jika data yang dimasukkan telah lengkap maka sistem akan menyimpan data ke dalam database sistem Post Condition Data supplier telah ada di dalam sistem Priority Alternative Flow and Exceptions Non Behavioral Jika data yang dimasukkan tidak lengkap oleh Manajer Pembelian maka akan timbul pesan error Hanya Manajer Pembelian yang bisa mendaftarkan data barang Requirements Assumptions Issues N/A N/A Tabel 3.13 Base Use Case Description untuk Mendaftarkan Barang Use Case Membuat SPB Membuat SPB Staff Gudang Kepala Gudang

44 95 Use Case Name Unique Use Case ID Primary Actor Membuat SPB UC-06 Kepala Gudang, Staff Gudang Secondary Actor - Brief Description Pihak Gudang menerima permintaan barang dari pihak Cabang, kemudian Pihak Gudang mencatat barang apa saja yang diminta untuk dijadikan dasar pengeluaran barang. Preconditions Flow Of Events Adanya Surat Permintaan Barang dari Cabang 1. Cabang mengirim SPB yang berisi daftar barang yang dibutuhkan cabang 2. Pihak Gudang menerima SPB 3. Pihak Gudang mencatat SPB ke dalam sistem Post Condition Priority Alternative Flow and Exceptions Non Behavioral Requirements Assumptions Issues Terbuatnya SPB di dalam Sistem Medium Jika data yang dimasukkan tidak lengkap maka sistem akan menampilkan pesan error Hanya Pihak Gudang yang berhak mencatat SPB ke dalam sistem Semua data-data barang telah terdaftar ke dalam sistem N/A Tabel 3.14 Base Use Case Description untuk Mencatat SPB

45 96 Use Case Membuat SPPB Membuat SPPB Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Membuat SPPB UC-07 Kepala Gudang Secondary Actor Brief Description Saat barang memasuki stock minimum, pihak gudang akan menerima warning dari sistem, kemudian Kepala Gudang akan membuat Surat Permintaan Barang untuk diberikan ke Manajer Pembelian untuk dijadikan dasar pemesanan barang. Preconditions Flow Of Events Adanya stock minimum bahan 1. Adanya warning dari sistem bahwa stock barang telah memasuki minimum 2. Sistem akan menkonfirmasi terlebih dahulu, sebelum SPPB dicetak. 3. SPPB diserahkan ke bagian pembelian Post Condition Priority Alternative Flow and Exceptions SPPB telah tercetak High Jika tidak ada warning terlebih dahulu dari sistem, maka SPPB tidak dapat dicetak

46 97 Non Behavioral Hanya dapat dilakukan oleh kepala gudang. Requirements Assumptions Issues N/A N/A Tabel 3.15 Base Use Case Description untuk Membuat SPPB Use Case Membuat Pengeluaran Barang Membuat Pengeluara n Barang Staff Gudang Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Membuat Pengeluaran Barang UC-08 Kepala Gudang, Staff Gudang Secondary Actor Brief Description Pihak Gudang akan mencatat barang keluar saat barang dikeluarkan dari gudang ke dalam sistem Preconditions Flow Of Events Barang dikeluarkan dari gudang 1. Pihak Gudang mengeluarkan barang dari gudang 2. Pihak Gudang memasukkan data barang yang keluar ke dalam sistem 3. Sistem memvalidasi kelengkapan data 4. Sistem akan menyimpan data yang dimasukkan

47 98 Post Condition Priority Alternative Flow and Exceptions Non Behavioral Requirements Assumptions Issues Data barang keluar telah tersimpan di dalam database Medium Jika data yang dimasukkan tidak lengkap maka sistem akan menampilkan pesan error Hanya pihak Gudang yang berhak mencatat Pengeluaran Barang dari Gudang Data barang yang dikeluarkan harus telah ada di dalam sistem N/A Tabel 3.16 Base Use Case Description untuk Mencatat Pengeluaran Barang Use Case Membuat CBR Membuat CBR Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Membuat CBR UC-09 Kepala Gudang Secondary Actor Brief Description Saat ada pemeriksaan fisik, pihak gudang menemukan barang yang tidak layak pakai karena rusak, kadaluarsa dan lain-lain. Maka Pihak Gudang memasukkan data barang tersebut ke dalam sistem dan mencetak CBR

48 99 Preconditions Flow Of Events Adanya barang yang tidak layak pakai 1. Saat pemeriksaan ditemukan barang tidak layak pakai maka kepala gudang akan membuat CBR 2. Kepala gudang akan membaca daftar barang 3. Kepala Gudang akan memasukkan kode barang yang dianggap rusak ke dalam rincian barang rusak 4. Sistem akan memvalidasi kelengkapan data CBR 5. Setelah di konfirmasi CBR dapat dicetak 6. Data persediaan secara otomatis akan di berkurang dengan adanya CBR Post Condition Priority Alternative Flow and Exceptions Non Behavioral Catatan Barang Rusak telah dimasukkan dalam sistem Medium Jika data yang dimasukkan tidak lengkap, maka akan muncul pesan error Kegiatan ini hanya dapat dilakukan Kepala Gudang. Requirements Assumptions Issues N/A N/A Tabel 3.17 Base Use Case Description untuk Membuat CBR

49 100 Use Case Membuat CBH Membuat CBH Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Membuat CBH UC-10 Kepala Gudang Secondary Actor Brief Description Saat ada pemeriksaan fisik, pihak gudang menemukan barang yang hilang. Maka Kepala Gudang memasukkan data barang tersebut ke dalam sistem dan mencetak CBH Preconditions Flow Of Events Adanya barang yang hilang 1. Saat pemeriksaan ditemukan barang tidak layak pakai maka kepala gudang akan membuat CBH 2. Kepala gudang akan membaca daftar barang 3. Kepala Gudang akan memasukkan kode barang yang dianggap rusak ke dalam rincian barang hilang 4. Sistem akan memvalidasi kelengkapan data CBH 5. Setelah di konfirmasi CBH dapat dicetak 6. Data persediaan secara otomatis akan di berkurang dengan adanya CBH Post Condition Catatan Barang Hilang telah dimasukkan dalam sistem

50 101 Priority Alternative Flow and Exceptions Non Behavioral Medium Jika data yang dimasukkan tidak lengkap, maka akan muncul pesan error Kegiatan ini hanya dapat dilakukan Kepala Gudang. Requirements Assumptions Issues N/A N/A Tabel 3.18 Base Use Case Description untuk Membuat CBH Use Case Membuat Nota Retur Supplier Membuat Nota Retur Supplier Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Membuat Nota Retur Supplier UC-11 Kepala Gudang Secondary Actor - Brief Description Ketika ada barang yang diterima dari supplier rusak atau tidak layak digunakan maka akan dibuat Nota Retur Supplier untuk penukaran barang dari Gudang ke Supplier Preconditions Flow Of Events Adanya barang yang tidak layak digunakan dari Supplier 1. Jika ada barang yang tidak layak digunakan maka Kepala

51 102 Gudang akan membuat Nota Retur Supplier 2. Kepala Gudang akan membaca daftar barang untuk memasukkan kode barang yang akan di retur. 3. Data Nota Retur Supplier akan divalidasi 4. Setelah dikonfirmasi data nota retur supplier akan dicetak 5. Nota Retur Supplier akan dikirim ke supplier 6. Data Persediaan akan berkurang secara otomatis dengan adanya barang yang di retur ke supplier Post Condition Priority Alternative Flow and Exceptions Non Behavioral Nota Retur Supplier tercetak Medium Jika barang yang diterima layak digunakan maka tidak dapat dibuat Nota Retur Supplier Hanya Kepala Gudang yang membuat Nota Retur Supplier Requirements Assumptions Issues Data Supplier harus terdaftar di dalam sistem. N/A Tabel 3.19 Base Use Case Description untuk Membuat Nota Retur Supplier

52 103 Use Case Menyetujui Nota Retur Supplier Menyetujui Nota Retur Supplier Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Menyetujui Nota Retur Supplier UC-12 Kepala Gudang Secondary Actor Brief Description Saat barang retur datang dari supplier pihak gudang kembali memeriksa keadaan barang tersebut dan memasukkan data barang yang telah ditukar tersebut ke dalam sistem Preconditions Flow Of Events Adanya barang Nota Retur Supplier yang diterima 1. Pihak gudang menerima barang retur dari supplier 2. Pihak gudang memeriksa barang yang diterima tersebut dengan mencocokkan data yang ada di nota retur supplier, dengan cara memasukkan kode nota retur supplier 3. Setelah semua cocok maka Kepala Gudang akan menyetujui Nota Retur Supplier dan sistem akan mengkonfirmasi terlebih dahulu sebelum statusnya berubah menjadi approve 4. Dengan demikian data persediaan otomatis akan

53 104 berubah Post Condition Priority Alternative Flow Nota Retur Supplier telah disetujui Medium N/A and Exceptions Non Behavioral Requirements Assumptions Issues Hanya Kepala Gudang yang akan melakukan persetujuan Nota Retur Supplier N/A N/A Tabel 3.20 Base Use Case Description untuk Menyetujui Nota Retur Supplier Use Case Membuat Nota Retur Cabang Membuat Nota Retur Cabang Staf Gudang Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Membuat Nota Retur Cabang UC-13 Kepala Gudang, Staff Gudang Secondary Actor Brief Description Saat barang retur datang dari cabang pihak gudang kembali memeriksa keadaan barang tersebut dan memasukkan data barang yang akan ditukar tersebut ke dalam sistem

54 105 Preconditions Flow Of Events Adanya Nota Retur Cabang yang diterima dari Cabang 1. Pihak gudang menerima Nota Retur Cabang dari Cabang 2. Pihak gudang memeriksa barang yang akan di-retur tersebut 3. Jika layak, pihak gudang akan mencatat data barang tersebut ke dalam sistem Post Condition Nota Retur Cabangtelah terbuat di dalam sistem dan mengeluarkan barang yang di-retur Priority Alternative Flow Medium N/A and Exceptions Non Behavioral Hanya pihak Gudang yang membuat Nota Retur Cabang Requirements Assumptions Issues N/A N/A Tabel 3.21 Base Use Case Description untuk Membuat Nota Retur Cabang Use Case Membuat Penerimaan Barang Masuk Membuat Penerimaan Barang Masuk Staf Gudang Kepala Gudang

55 106 Use Case Name Unique Use Case ID Primary Actor Membuat Penerimaan Barang Masuk UC-14 Kepala Gudang, Staf Gudang Secondary Actor Brief Description Saat barang datang dari Supplier beserta Surat Jalan, pihak gudang memeriksa keadaan barang tersebut dan mencocokkan Surat Jalan dan barang dengan PO kemudian memasukkannya ke dalam sistem Preconditions Flow Of Events Adanya penerimaan barang 1. Menerima Barang dan Surat Jalan dari Supplier 2. Memeriksa barang 3. Mencocokkan dengan PO 4. Memasukkan data baramg masuk sesuai dengan PO 5. Sistem akan mengkonfirmasi terlebih dahulu. 6. Data persediaan akan ter-update Post Condition Data penerimaan barang masuk telah tersimpan di dalam sistem Priority Alternative Flow and Exceptions Non Behavioral Requirements Assumptions Medium Jika data yang dimasukkan tidak cocok maka akan muncul pesan error Hanya pihak Gudang yang berhak membuat penerimaan barang masuk Semua data barang harus ada di dalam sistem

56 107 Issues N/A Tabel 3.22 Base Use Case Description untuk Mencatat Penerimaan Barang Masuk Use Case Memeriksa Daftar Persediaan Memeriksa Daftar Persediaan Staf Gudang Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Memeriksa Daftar Persediaan UC-15 Kepala Gudang, Staff Gudang Secondary Actor - Brief Description Pihak Gudang memeriksa persediaan yang ada di dalam database sistem untuk mengetahui data-data persediaan Preconditions Flow Of Events Informasi persediaan telah berada di dalam sistem 1. Pihak Gudang melihat persediaan berdasar pengelompokan yang ada 2. Sistem Informasi akan membaca dari database sistem seluruh informasi berdasarkan pengelompokkan yang

57 108 diminta oleh Kepala Gudang 3. Sistem menampilkan Persediaan Post Condition Priority Alternative Flow and Exceptions Pihak Gudang telah memeriksa data Persediaan High Jika pihak Gudang ingin membuat laporan persediaan, maka pihak Gudang dapat memerintahkan sistem untuk mencetak laporan. Non Behavioral Requirements Hanya pihak Gudang yang berhak memeriksa List persediaan Hanya pihak Gudang yang berhak dan berkewajiban membuat dan mencetak laporan mengenai Peersediaan Assumptions Issues Data Persediaan telah ada di dalam Sistem N/A Tabel 3.23 Base Use Case Description untuk Memeriksa Data Persediaan Use Case Mendaftarkan Cabang Mendaftarkan Cabang Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Mendaftarkan Cabang UC-16 Kepala Gudang

58 109 Secondary Actor - Brief Description Kepala Gudang mendaftarkan cabang baru yang belum ada di dalam database Preconditions Adanya calon Cabang yang belum terdaftar Flow Of Events 1. Kepala Gudang memasukkan data Cabang tersebut ke dalam sistem 2. Sistem mevalidasi kelengkapan data yang dimasukkan 3. Jika data yang dimasukkan telah lengkap maka sistem akan menyimpan data ke dalam database sistem Post Condition Priority Alternative Flow and Exceptions Non Behavioral Data Cabang telah ada di dalam sistem High Jika data yang dimasukkan tidak lengkap oleh Kepala Gudang maka akan timbul pesan error Hanya Kepala Gudang yang bisa mendaftarkan Cabang Requirements Assumptions Issues N/A N/A Tabel 3.24 Base Use Case Description untuk Mendaftarkan Cabang

59 110 Use Case Memeriksa Daftar Cabang Memeriksa Daftar Cabang Staf Gudang Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Memeriksa Daftar Cabang UC-17 Kepala Gudang, Staff Gudang Secondary Actor - Brief Description Pihak Gudang memeriksa Cabang yang ada di dalam database sistem untuk mengetahui data-data Cabang Preconditions Flow Of Events Informasi Cabang telah berada di dalam sistem 1. Pihak Gudang memeriksa Cabang 2. Sistem Informasi akan membaca dari database sistem seluruh informasi yang diminta oleh Manajer Pembelian 3. Sistem menampilkan Cabang Post Condition Priority Alternative Flow and Exceptions Pihak Gudang telah melihat data Cabang High Jika pihak Gudang ingin membuat List cabang, maka pihak Gudang dapat memerintahkan sistem untuk mencetak List cabang Non Behavioral Hanya pihak Gudang yang berhak menampilkan cabang Requirements

60 111 Assumptions Issues Semua data Cabang telah terdaftar di dalam sistem N/A Tabel 3.25 Base Use Case Description untuk Memeriksa Daftar Cabang Use Case Menutup Cabang Menutup Cabang Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Menutup Cabang UC-18 Kepala Gudang Secondary Actor - Brief Description Kepala Gudang menghapus cabang yang ada di dalam database Preconditions Flow Of Events Adanya Cabang yang akan terhapus dari sistem 1. Kepala Gudang memasukkan data Cabang tersebut ke dalam sistem 2. Sistem mevalidasi kelengkapan data yang dimasukkan 3. Kepala Gudang memilih data cabang yang akan dihapus 4. Data Cabang terhapus dari Sisitem

61 112 Post Condition Priority Alternative Flow and Exceptions Non Behavioral Data Cabang telah terhapus dari sistem High Jika tidak ada Cabang yang ditutup maka data Cabang tidak dapat terhapus dari sistem Hanya Kepala Gudang yang bisa menutup Cabang Requirements Assumptions Issues N/A N/A Tabel 3.26 Base Use Case Description untuk Menutup Cabang Use Case Mengubah Identitas Barang Mengubah Identitas Barang Manajer Pembelian Use Case Name Unique Use Case ID Primary Actor Mengubah Identitas Barang UC-19 Manajer Pembelian Secondary Actor - Brief Description Manajer Pembelian mengubah identitasbarang yang ada di dalam database Preconditions Adanya barang yang akan diubah Flow Of Events 1. Manajer Pembelian membaca dan memilih data

62 113 Barang yang akan diubah 2. Manajer Pembelian mengubah identitas Barang 3. Sistem akan mengkonfirmasi perubahan yang telah dibuat 4. Sistem akan meng-update perubahan data barang tersebut Post Condition Priority Alternative Flow and Exceptions Non Behavioral Identitas Barang telah terubah dari sistem High Jika Manajer Pembelian belum memilih Barang maka, identitas Barang tidak dapat diubah Hanya Manajer Pembelian yang bisa mengubah identitas Barang Requirements Assumptions Issues N/A N/A Tabel 3.27 Base Use Case Description untuk Mengubah Identitas Barang Use Case Menghapus Data Barang Menghapus Data Barang Manajer Pembelian

63 114 Use Case Name Unique Use Case ID Primary Actor Menghapus Data Barang UC-20 Manajer Pembelian Secondary Actor - Brief Description Manajer Pembelian menghapus data barang yang ada di dalam database Preconditions Adanya barang yang akan dihapus Flow Of Events 1. Manajer Pembelian membaca dan memilih data Barang yang akan dihapus 2. Manajer Pembelian menghapus data Barang 3. Sistem akan mengkonfirmasi data barang yang akan dihapus 4. Sistem akan meng-update data barang yang telah dihapus tersebut. Post Condition Priority Alternative Flow and Exceptions Non Behavioral Data Barang telah terhapus dari sistem High Jika Manajer Pembelian belum memilih Barang maka, data Barang tidak dapat dihapus Hanya Manajer Pembelian yang bisa menghapus Barang Requirements Assumptions Issues N/A N/A Tabel 3.28 Base Use Case Description untuk Menghapus Data Barang

64 115 Use Case Menghitung ROP Menghitung ROP Kepala Gudang Staff Gudang Use Case Name Unique Use Case ID Primary Actor Menghitung ROP UC-21 Kepala Gudang, Staff Gudang Secondary Actor - Brief Description ROP akan dihitung untuk mengetahui berapa reorder point untuk kembali memesan barang. Setiap periode waktu ROP dihitung, nilai ROP akan berubah Preconditions Flow Of Events ROP belum terhitung 1. Sistem akan membaca jumlah demand dan lead time 2. Sistem akan mengkalkulasi perhitungan yang dibutuhkan 3. Hasil akan ditampilkan Post Condition Priority Alternative Flow and ROP telah terhitung High N/A

65 116 Exceptions Non Behavioral Requirements Hanya Bagian Gudang yang akan menerima hasil ROP Assumptions Issues N/A N/A Tabel 3.29 Base Use Case Description untuk Menghitung ROP Use Case Menghitung EOQ Menghitung EOQ Kepala Gudang Staff Gudang Use Case Name Unique Use Case ID Primary Actor Menghitung EOQ UC-22 Kepala Gudang, Staff Gudang Secondary Actor - Brief Description EOQ akan dihitung untuk mengetahui berapa jumlah pemesanan yang optimal, setiap periode waktu demand

66 117 dihitung, nilai EOQ dapat berubah disesuaikan menurut kebutuhan Preconditions Flow Of Events EOQ belum terhitung 1. Sistem akan mengeluarkan reminder sebagai peringatan untuk pembelian barang 2. Bagian Gudang akan menerima reminder 3. Bagian Gudang akan meminta sistem untuk melakukan EOQ Post Condition Priority Alternative Flow and Exceptions Non Behavioral EOQ telah terhitung High Perhitungan EOQ dilakukan menurut waktu yang telah disepakati perusahaan, setahun sekali Hanya Bagian Gudang yang akan menerima EOQ Requirements Assumptions Issues Data telah ada di dalam sistem N/A Tabel 3.30 Base Use Case Description untuk Menghitung EOQ

67 118 Use Case Mengingatkan Reorder Barang Mengingatkan Reorder Barang Staf Gudang Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Mengingatkan Reorder Barang UC-23 Kepala Gudang, Staff Gudang Secondary Actor - Brief Description Peringatan akan muncul apabila stok di gudang telah mencapai titik pemesanan kembali yang akan terjadi karena pemakaian barang. Preconditions Flow Of Events Reminder belum aktif 1. Gudang akan mengeluarkan barang dan mencatatnya ke dalam sistem 2. Saat barang berada pada stok minimum, Reminder akan aktif 3. Bagian Gudang akan menerima Reminder sebagai pengingat untuk melakukan permohonan pembelian barang Post Condition Priority Alternative Flow Reminder telah aktif High N/A

68 119 and Exceptions Non Behavioral Hanya Bagian Gudang yang akan menerima hasil tersebut Requirements Assumptions Issues Data telah ada di dalam sistem N/A Tabel 3.31 Base Use Case Description untuk Mengingatkan Reorder Barang Use Case Memeriksa Penerimaan Barang Masuk Memeriksa Penerimaa n Barang Masuk Staf Gudang Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Memeriksa Penerimaan Barang Masuk UC-24 Kepala gudang, Staff Gudang Secondary Actor - Brief Description User memeriksa di dalam database sistem untuk mengetahui informasi tentang Penerimaan Barang Masuk Preconditions Informasi Penerimaan Barang Masuk telah berada di dalam sistem

69 120 Flow Of Events 1. User memeriksa Penerimaan Barang Masuk yang diinginkan 2. Sistem Informasi akan membaca dari database sistem seluruh informasi berdasarkan pengelompokkan yang diminta oleh User 3. Sistem menampilkan Penerimaan Barang Masuk yang diminta 4. Bila diperlukan maka dapat dicetak Post Condition Priority Alternative Flow and Exceptions Non Behavioral User telah memeriksa Penerimaan Barang Masuk High User dapat memerintahkan sistem untuk mencetak Penerimaan Barang Masuk yang diperiksa N/A Requirements Assumptions Issues N/A N/A Tabel 3.32 Base Use Case Description untuk Memeriksa Penerimaan Barang Masuk Use Case Memeriksa Pengeluaran Barang Memeriksa Pengelua ran Barang Staf Gudang Kepala Gudang

70 121 Use Case Name Unique Use Case ID Primary Actor Memeriksa Pengeluaran Barang UC-25 Kepala gudang, Staff Gudang Secondary Actor - Brief Description User memeriksa di dalam database sistem untuk mengetahui informasi tentang Pengeluaran Barang Preconditions Flow Of Events Informasi Pengeluaran Barang telah berada di dalam sistem 1. User memeriksa Pengeluaran Barang yang diinginkan 2. Sistem Informasi akan membaca dari database sistem seluruh informasi berdasarkan pengelompokkan yang diminta oleh User 3. Sistem menampilkan Pengeluaran Barang yang diminta 4. Bila diperlukan maka dapat dicetak Post Condition Priority Alternative Flow and Exceptions Non Behavioral User telah memeriksa Pengeluaran Barang High User dapat memerintahkan sistem untuk mencetak Pengeluaran Barang yang diperiksa N/A Requirements Assumptions Issues N/A N/A Tabel 3.33 Base Use Case Description untuk Memeriksa pengeluaran Barang

71 122 Use Case Memeriksa SPB Menampilkan barang yang mencapai ROP Kepala Gudang Staff Gudang Use Case Name Unique Use Case ID Primary Actor Menampilkan Barang Yang Mencapai ROP UC-26 Kepala gudang, Staff Gudang Secondary Actor - Brief Description Setelah menerima Reminder dari sistem maka User akan melihat barang apa saja yang telah mencapai titik ROP Preconditions Flow Of Events Ada Reminder ReOrder Barang 1. User menerima Reminder 2. User ingin melihat barang apa saja yang sudah mencapai ROP 3. Sistem menampilkan barang-barang yang telah mencapai ROP Post Condition Priority Alternative Flow and Exceptions Non Behavioral User melihat barang-barang apa saja yang mencapai ROP High Hanya bagian gudang yang berhak melihat barangbarang apa saja yang mencapai titik ROP N/A

72 123 Requirements Assumptions Issues N/A N/A Tabel 3.34 Base Use Case Description untuk Memeriksa SPB Use Case Memeriksa SPPB Memeriksa SPPB Staf Gudang Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Memeriksa SPPB UC-27 Kepala gudang, Staff Gudang Secondary Actor - Brief Description User memeriksa di dalam database sistem untuk mengetahui informasi tentang SPPB Preconditions Flow Of Events Informasi SPPB telah berada di dalam sistem 1. User memeriksa SPPB yang diinginkan 2. Sistem Informasi akan membaca dari database sistem seluruh informasi berdasarkan pengelompokkan yang diminta oleh User

73 Sistem menampilkan SPPB yang diminta 4. Bila diperlukan maka dapat dicetak Post Condition Priority Alternative Flow and Exceptions Non Behavioral User telah memeriksa SPPB High User dapat memerintahkan sistem untuk mencetak SPPB yang diperiksa N/A Requirements Assumptions Issues N/A N/A Tabel 3.35 Base Use Case Description untuk Memeriksa SPPB Use Case Memeriksa CBR Memeriksa CBR Staf Gudang Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Memeriksa Barang UC-28 Kepala gudang, Staff Gudang Secondary Actor - Brief Description User memeriksa di dalam database sistem untuk mengetahui

74 125 informasi tentang CBR Preconditions Flow Of Events Informasi CBR telah berada di dalam sistem 1. User memeriksa CBR yang diinginkan 2. Sistem Informasi akan membaca dari database sistem seluruh informasi berdasarkan pengelompokkan yang diminta oleh User 3. Sistem menampilkan CBR yang diminta 4. Bila diperlukan maka dapat dicetak Post Condition Priority Alternative Flow and Exceptions Non Behavioral User telah memeriksa CBR High User dapat memerintahkan sistem untuk mencetak CBR yang diperiksa N/A Requirements Assumptions Issues N/A N/A Tabel 3.36 Base Use Case Description untuk Memeriksa CBR

75 126 Use Case Memeriksa CBH Memeriksa CBH Staf Gudang Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Memeriksa Barang UC-29 Kepala gudang, Staff Gudang Secondary Actor - Brief Description User memeriksa di dalam database sistem untuk mengetahui informasi tentang CBH Preconditions Flow Of Events Informasi CBH telah berada di dalam sistem 1. User memeriksa CBH yang diinginkan 2. Sistem Informasi akan membaca dari database sistem seluruh informasi berdasarkan pengelompokkan yang diminta oleh User 3. Sistem menampilkan CBH yang diminta 4. Bila diperlukan maka dapat dicetak Post Condition Priority Alternative Flow and Exceptions Non Behavioral User telah memeriksa CBH High User dapat memerintahkan sistem untuk mencetak CBH yang diperiksa N/A

76 127 Requirements Assumptions Issues N/A N/A Tabel 3.37 Base Use Case Description untuk Memeriksa CBH Use Case Memeriksa Nota Retur Cabang Memeriksa Nota Retur Cabang Staf Gudang Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Memeriksa Nota Retur Cabang UC-30 Kepala gudang, Staff Gudang Secondary Actor - Brief Description User memeriksa di dalam database sistem untuk mengetahui informasi tentang Nota Retur Cabang Preconditions Flow Of Events Informasi Nota Retur Cabang telah berada di dalam sistem 1. User memeriksa Nota Retur Cabang yang diinginkan 2. Sistem Informasi akan membaca dari database sistem seluruh informasi berdasarkan pengelompokkan yang diminta oleh User

77 Sistem menampilkan Nota Retur Cabang yang diminta 4. Bila diperlukan maka dapat dicetak Post Condition Priority Alternative Flow and Exceptions Non Behavioral User telah memeriksa Nota Retur Cabang High User dapat memerintahkan sistem untuk mencetak Nota Retur Supplier yang diperiksa N/A Requirements Assumptions Issues N/A N/A Tabel 3.38 Base Use Case Description untuk Memeriksa Nota Retur Cabang Use Case Memeriksa Nota Retur Supplier Memeriksa Nota Retur Supplier Staf Gudang Kepala Gudang Use Case Name Unique Use Case ID Primary Actor Memeriksa Nota Retur Supplier UC-31 Kepala gudang, Staff Gudang Secondary Actor - Brief Description User memeriksa di dalam database sistem untuk mengetahui

78 129 informasi tentang Nota Retur Supplier Preconditions Flow Of Events Informasi Nota Retur Supplier telah berada di dalam sistem 1. User memeriksa Nota Retur Supplier berdasar pengelompokan yang ada 2.Sistem Informasi akan membaca dari database sistem seluruh informasi berdasarkan pengelompokkan yang diminta oleh User 3. Sistem menampilkan Nota Retur Supplier yang diminta 4. Bila diperlukan maka Nota Retur Supplier yang diminta dapat dicetak Post Condition Priority Alternative Flow and Exceptions Non Behavioral User telah memeriksa Nota Retur Supplier High User dapat memerintahkan sistem untuk mencetak Nota Retur Supplier yang diperiksa N/A Requirements Assumptions Issues N/A N/A Tabel 3.39 Base Use Case Description untuk Memeriksa Nota Retur Supplier

79 130 Use Case Memeriksa PO Memeriksa PO Manajer Pembelian Use Case Name Unique Use Case ID Primary Actor Memeriksa PO UC-32 Manajer Pembelian Secondary Actor - Brief Description Manajer Pembelian memeriksa daftar PO yang ada di dalam database sistem untuk mengetahui informasi tentang PO Preconditions Flow Of Events Informasi PO telah berada di dalam sistem 1. Manajer memeriksa PO berdasar yang diinginkan 2. Sistem Informasi akan membaca dari database sistem seluruh informasi berdasarkan pengelompokkan yang diminta oleh Manajer Pembelian 3. Sistem menampilkan PO yang diminta Post Condition Priority Alternative Flow and Manajer Pembelian telah memeriksa PO High N/A Exceptions Non Behavioral N/A

80 131 Requirements Assumptions Issues N/A N/A Tabel 3.40 Base Use Case Description untuk Memeriksa PO Use Case Memeriksa Daftar Supplier Memeriksa Daftar Supplier Manajer Pembelian Use Case Name Unique Use Case ID Primary Actor Memeriksa Daftar Supplier UC-33 Manajer Pembelian Secondary Actor - Brief Description Manajer Pembelian memeriksa daftar Supplier yang ada di dalam database sistem untuk mengetahui informasi tentang Supplier Preconditions Flow Of Events Informasi Supplier telah berada di dalam sistem 1. Manajer Pembelian memeriksa Supplier berdasar pengelompokan yang ada

81 Sistem Informasi akan membaca dari database sistem seluruh informasi berdasarkan pengelompokkan yang diminta oleh User 3. Sistem menampilkan daftar Supplier 4. Bila diperlukan maka daftar Supplier dapat dicetak Post Condition Priority Alternative Flow and Exceptions Manajer Pembelian telah memeriksa daftar Supplier High Jika Manajer Pembelian ingin membuat List mengenai Supplier, maka Manajer Pembelian dapat memerintahkan sistem untuk mencetaknya Non Behavioral N/A Requirements Assumptions Issues N/A N/A Tabel 3.41 Base Use Case Description untuk Memeriksa Daftar Supplier Use Case Mengubah Identitas Supplier Mengubah Identitas Supplier Manajer Pembelian

82 133 Use Case Name Unique Use Case ID Primary Actor Mengubah Identitas Supplier UC-34 Manajer Pembelian Secondary Actor - Brief Description Manajer Pembelian mengubah identitas Supplier yang ada di dalam database Preconditions Flow Of Events Adanya identitas Supplier yang akan diubah 1. Manajer Pembelian membaca dan memilih data Supplier yang akan diubah 2. Manajer Pembelian mengubah identitas Supplier 3. Sistem akan mengkonfirmasi perubahan yang telah dibuat 4. Sistem akan meng-update perubahan data Supplier tersebut Post Condition Priority Alternative Flow and Exceptions Non Behavioral Identitas Supplier telah terubah di sistem High Jika Manajer Pembelian belum memilih Supplier maka, data Supplier tidak dapat diubah Hanya Manajer Pembelian yang bisa mengubah identitas Barang Requirements Assumptions Issues N/A N/A Tabel 3.42 Base Use Case Description untuk Mengubah Identitas Supplier

83 134 Use Case Menyetujui PO Menyetujui PO Manajer Pembelian Use Case Name Unique Use Case ID Primary Actor Menyetujui PO UC-35 Manajer Pembelian Secondary Actor - Brief Description Setelah barang diterima dan sesuai pesaanan maka Manajer Pembelian akan menyetujui PO Preconditions Flow Of Events Adanya PO yang akan disetujui 1. Barang diterima oleh Pihak Gudang 2. Mencocokkan Barang 3. Setelah Barang cocok, PO disetujui Post Condition Priority Alternative Flow and Exceptions Non Behavioral PO yang telah disetujui dalam sistem High Jika Manajer Pembelian belum memilih Barang maka, data Barang tidak dapat diubah Hanya Manajer Pembelian yang bisa menyetujui PO Requirements

84 135 Assumptions Issues N/A N/A Tabel 3.43 Base Use Case Description untuk Menyetujui PO Use Case Menyetujui SPPB Menyetujui SPPB Manajer Pembelian Use Case Name Unique Use Case ID Primary Actor Menyetujui SPPB UC-36 Manajer Pembelian Secondary Actor - Brief Description Manajer Pembelian akan meyetujui SPPB yang telah dibuat apabila PO telah terbuat Preconditions Flow Of Events Adanya SPPB yang akan disetujui 1. Kepala Gudang membuat SPPB 2. SPPB diserahkan ke Manajer Pembelian 3. Manajer Pembelian membuat PO 4. SPPB disetujui

85 136 Post Condition Priority Alternative Flow and SPPB telah disetujui High Jika PO belum dibuat maka SPPB belum bisa disetujui Exceptions Non Behavioral Hanya Manajer Pembelian yang bisa menyetujui SPPB Requirements Assumptions Issues N/A N/A Tabel 3.44 Base Use Case Description untuk Menyetujui SPPB Use Case Menampilkan Hasil PO menampilkan hasil PO Manajer Pembelian Use Case Name Unique Use Case ID Primary Actor Menampilkan Hasil PO UC-37 Manajer Pembelian Secondary Actor - Brief Description Manajer Pembelian akan melihat hasil-hasil PO yang telah dikonversi dari SPPB Preconditions Flow Of Events Adanya PO yang akan ditampilkan 1. Manajer Pembelian membuat PO

86 Sistem akan mengkonversikan PO 3. Manajer Pembelian melihat hasil PO Post Condition Priority Alternative Flow and Manajer Pembelian telah melihat PO High Jika PO belum dibuat maka hasil belum bisa ditampilkan Exceptions Non Behavioral Hanya Manajer Pembelian yang bisa menampilkan PO Requirements Assumptions Issues N/A N/A Tabel 3.44 Base Use Case Description untuk Menyetujui SPPB Sequence Diagram Urutan hubungan antara objek-objek yang berada di dalam Use Case digambarkan dalam sequence diagram berikut ini : 1. Sequence diagram Membuat PO Sequence diagram Membuat PO dimulai saat manajer pembelian membuat PO. Setelah itu Kode PO akan di generate. Kemudian manajer pembelian memasukkan Header PO. Manajer Pembelian akan mengecek SPPB yang diberikan oleh pihak gudang dengan memasukkan kode SPPB. Setelah dikonfirmasi, maka kemudian Manajer pembelian akan membaca supplier dan memasukkan kode supplier sesuai dengan barang yang disupply oleh sebuah supplier. Sistem akan memasukkan Rincian pesanan

87 138 PO dengan membaca data barang berdasarkan supplier-supplier yang dimasukkan oleh manajer pembelian. Sistem secara otomatis menampilkan hasil PO yang akan dicetak. Manajer Pembelian PO : Purchase Order SPPB Supplier Rincian Pesanan PO Barang Membuat PO() Generate PO ID() Memasukkan PO Header() Confirm_Message() Mengecek SPPB() Membaca Supplier() Generate SPPB Id() Memasukkan Rincian PO() Membaca Barang() Confirm() Gambar 3.17 Sequence diagram Membuat PO 2. Sequence diagram Memeriksa PO Sequence diagram Memeriksa PO dimulai dengan membaca PO. Manajer Pembelian men-generate kode PO. Setelah sistem mengkonfirmasi bahwa kode PO yang dimasukkan terdaftar. Kemudian berdasarkan kode PO tersebut sistem membaca kode SPPB yang terdapat pada PO tersebut. Setelah itu sistem akan menampilkan PO berserta rincian pesanan PO.

88 139 Manajer Pembelian PO : Purchase Order SPPB Rincian Pesanan PO Membaca PO() Confirm() Generate PO Id() Mengecek SPPB() Membaca Rincian Pesanaan PO() Gambar 3.18 Sequence diagram Memeriksa PO 3. Sequence diagram Menyetujui PO Sequence diagram Menyetujui PO dimulai dengan membaca PO kemudian membaca rincian PO. Setelah menerima catatan barang masuk dari pihak gudang, maka Manajer Pembelian akan mengubah ststus PO menjadi approve.

89 140 Manajer Pembelian PO : Purchase Orde Rincian Pesanan P Mengecek PO() Confirm() Generate PO ID() Membaca Rincian Pesanan PO() Ubah Status() Gambar 3.19 Sequence diagram Menyetujui PO 4. Sequence diagram Mendaftarkan Barang Sequnce diagram Mendaftarkan Barang dimulai dengan mendaftarkan suatu jenis barang baru. Sistem secara otomatis akan men-generate kode barang. Manajer pembelian akan memasukkan rincian identitas barang. Sistem akan memvalidasi kelengkapan data barang yang dimasukkan. Kemudian sistem akan mengkonfirmasi terlebih dahulu sebelum data barang tersebut disimpan.

90 141 Manajer Pembelian Barang Identitas Barang Mendaftarkan Barang() Generate Barang Id() Memasukkan Identitas Barang() Confirm() Validasi Data Barang() Gambar 3.20 Sequence diagram Mendaftarkan Barang 5. Sequence diagram Mengubah Barang Sequence diagram Mengubah Barang dimulai dengan membaca data barang yang ada dengan meng-generate kode barang yang terdaftar, kemudian mengubah data identitas barang yang diinginkan. Setelah itu sistem akan menampilkan hasil perubahan data barang tersebut. Setelah dikonfirmasi, maka sistem akan mengupdate data rincian barang tersebut.

91 142 Manajer Pembelian Membaca Barang() Barang Identitas Barang Confirm() Generate Barang Id() Merubah Identitas Barang() Confirm() Validasi data Barang() Gambar 3.21 Sequence diagram Mengubah Barang 6. Sequence diagram Menghapus Barang Sequence diagram Menghapus Barang dimulai dengan membaca data barang yang ada dengan menggenerate kode barang yang terdaftar, kemudian menghapus data barang yang dinginkan. Setelah itu sistem akan mengkonfirmasi data barang yang akan dihapus, setelah itu barang akan terhapus.

92 143 Manajer Pembelian Barang Membaca Barang() Confirm() Generate Barang Id() Menghapus Barang() Confirm() Gambar 3.22 Sequence diagram Menghapus Data Barang 7. Sequence diagram Menghitung ROP Sequence diagram Menghitung ROP dimulai dengan membaca barang, kemudian manajer pembelian akan memasukkan lead time pesanan, jumlah permintaan per tahun, dan jumlah hari kerja per tahun. Setelah itu sistem akan menghitung dan menampilkan hasil ROP.

93 144 Manajer Pembelian Barang Membaca Barang() Generate Barang Id() Memasukkan Lead Time Barang() Memasukkan Permintaan Barang per Tahun() Memasukkan Jumlah Hari Kerja per Tahun() Calculate ROP() Gambar 3.23 Sequence diagram Menghitung ROP 8. Sequence diagram Menghitung EOQ Sequence diagram Menghitung EOQ dimulai dengan membaca barang, kemudian manajer pembelian akan memasukkan jumlah permintaan per tahun, biaya pemesanan, dan biaya penyimpanan per tahun. Setelah itu sitem akan menghitung dan menampilkan hasil EOQ.

94 145 Manajer Pembelian Barang Membaca Barang() Generate Barang Id() Memasukkan Biaya Pemesanan() Memasukkan Permintaan Barang per Tahun() Biaya Penyimpanan per tahun() Calculate EOQ() Gambar 3.24 Sequence Diagram Menghitung EOQ 9. Sequence diagram Mendaftarkan Supplier Sequnce diagram Mendaftarkan Supplier dimulai dengan mendaftarkan suatu supplier baru. Sistem akan memvalidasi kelengkapan data supplier. Sebelum data supplier baru disimpan, sistem akan mengkonfirmasi terlebih dahulu.

95 146 Manajer Pembelian Mendaftarkan Supplier() Supplier Identitas Supplier Generate Supplier Id() Memasukkan Identitas Supplier() Confirm() Validasi data Supplier() Gambar 3.25 Sequence diagram Mendaftarkan Supplier 10. Sequence diagram Menghapus Supplier Sequence diagram Menghapus Supplier dimulai dengan membaca data supplier yang ada kemudian meng-generate kode supplier, kemudian menghapus data supplier yang diinginkan. Sebelum dihapus maka sistem akan mengkonfirmasi terlebih dahulu, setelah dihapus, data supplier akan terhapus.

96 147 Manajer Pembelian Supplier Membaca Supplier() Confirm() Generate Supplier Id() Menghapus Supplier() Confirm() Gambar 3.26 Sequence diagram Menghapus Supplier 11. Sequence Diagram Merubah Identitas Supplier Sequence Diagram Merubah Identitas Supplier dimulai dengan membaca supplier dan kemudian meng-generate kode supplier. Kemudian merubah identitas supplier. Setelah itu sistem akan mengkonfirmasi perubahan identitas supplier tersebut.

97 148 Kepala Gudang Membaca Supplier() Supplier Identitas Supplier Confirm() Generate Supplier Id() Merubah Identitas Supplier() Confirm() Validasi data Supplier() Gambar 3.27 Sequence Diagram Merubah Identitas Supplier 12. Sequence Diagram Memeriksa Daftar Supplier Sequence Diagram Memeriksa Daftar Supplier dimulai dengan membaca supplier. Setelah manajer pembelian memiilih kode supplier yang akan diperiksa, maka sistem akan menampilkan seluruh identitas supplier yang akan diperiksa tersebut.

98 149 Manajer Pembelian Membaca Supplier() Supplier Identitas Supplier Generate Supplier Id() Membaca Identitas Supplier() Gambar 3.28 Sequence Diagram Memeriksa Daftar Supplier 13. Sequence Diagram Melihat Daftar Barang Sequence diagram Melihat Daftar Barang dimulai dengan memilih kelompok barang yang ingin ditampilkan. Sistem akan menampilkan kelompok daftar barang yang dipilih tersebut. Apabila diperlukan, daftar barang tersebut dapat dicetak. Manajer Pembelian, Kepala Gudang, dan Staf Gudang Barang Membaca Barang() Gambar 3.29 Sequence diagram Melihat Daftar Barang

99 Sequence Diagram Mendaftarkan Cabang Sequnce diagram Mendaftarkan Cabang dimulai dengan mendaftarkan suatu cabang baru dengan meng-generate kode cabang. Sistem akan memvalidasi kelengkapan data cabang. Sebelum data cabang baru disimpan, sistem akan mengkonfirmasi terlebih dahulu. Kepala Gudang Cabang Mendaftarkan Cabang() Generate Cabang Id() Memasukkan Data Cabang() Validasi Data Cabang() Confirm() Gambar 3.30 Sequence diagram Mencdaftarkan Cabang 15. Sequence Diagram Menutup Cabang Sequence diagram Menutup Cabang dimulai dengan membaca data cabang yang ada, kemudian meng-generate kode cabang yang akan dihapus. Sebelum dihapus maka sistem akan mengkonfirmasi terlebih dahulu, setelah itu data cabang akan dihapus.

100 151 Kepala Gudang Cabang Membaca Cabang() Confirm() Generate Cabang Id() Menghapus Cabang() Confirm() Gambar 3.31 Sequence diagram Menutup Cabang 16. Sequence Diagram Membuat Nota Retur Supplier Sequence Diagram Membuat Nota Retur Supplier dimulai dengan membuat Nota Retur Supplier. Kemudian sistem akan secara otomatis men- generate kode nota retur supplier. Setelah sistem membaca supplier untuk men-generate kode supplier yang akan diretur. Setelah sistem bahwa mengkonfirmasi kode supplier yang dipilih terdaftar, maka kemudian kepala gudang memasukkan rincian nota retur supplier dengan membaca data barang yang ada. Sistem akan mengkonfirmasi terlebih dahulu sebelum data disimpan.

101 152 Kepala Gudang Nota Retur Supplier Supplier Rincian Nota Retur Supplier Barang Membuat Nota Retur Supplier() Generate Nota Retur Suppler Id() Membaca Supplier() Confirm() Generate Supplier Id() Memasukkan Rincian Nota Retur Supplier() Membaca Barang() Confirm() Gambar 3.32 Sequence Diagram Membuat Nota Retur Supplier 17. Sequence Diagram Menyetujui Nota Retur Supplier Sequence Diagram Menyetujui Nota Retur Supplier dimulai dengan membaca nota retur supplier kemudian Kepala Gudang akan men-generate kode nota retur supplier yang akan disetujui. Setelah sistem mengkonfirmasi bahwa kode nota retur supplier tersebut terdaftar, maka kemudian Kepala Gudang akan membaca rincian nota retur supplier. Setelah selesai maka statusnya akan dirubah menjadi approve.

102 153 Kepala Gudang Nota retur Supplier Rincian Nota retur Supplier Membaca Nota Retur Supplier() Confirm() Generate Nota Retur Supplier Id() Membaca rincian Nota Retur Supplier() Ubah Status() Gambar 3.33 Sequence Diagram Menyetujui Nota Retur Supplier 18. Sequence Diagram Membuat CBR Sequence Diagram Membuat CBR dimulai dengan membuat CBR. Kemudian sistem secara otomatis akan men-generate kode CBR. Setelah itu kepala gudang akan memasukkan rincian CBR dengan membaca data barang. Setelah selesai, maka sistem akan mengkonfirmasi terlebih dahulu sebelum data disimpan.

103 154 Kepala Gudang CBR Rincian CBR Barang Membuat CBR() Generate CBR Id() Memasukkan Rincian CBR() Membaca Barang() Confirm() Gambar 3.34 Sequence Diagram Membuat CBR 19. Sequence Diagram Memeriksa CBR Sequence Diagram Memeriksa CBR dimulai dengan membaca CBR. Kepala gudang akan men-generate kode CBR. Setelah sistem mengkonfirmasi bahwa kode CBR yang dimasukkan terdaftar, maka CBR akan ditampilkan. Setelah itu kepala gudang dapat membaca rincian CBR.

104 155 Kepala Gudang Membaca CBR() CBR Rincian CBR Confirm() Generate CBR Id() Membaca Rincian CBR() Gambar 3.35 Sequence Diagram Memeriksa CBR 20. Sequence Diagram Membuat CBH Sequence Diagram Membuat CBH dimulai dengan membuat CBH. Kemudian sistem secara otomatis akan men-generate kode CBH. Setelah itu kepala gudang akan memasukkan rincian CBH dengan membaca data barang. Setelah selesai, maka sistem akan mengkonfirmasi terlebih dahulu sebelum data disimpan.

105 156 Kepala Gudang CBH Rincian CBH Barang Membuat CBH() Generate CBH Id() Memasukkan Rincian CBH() Membaca Barang() Confirm() Gambar 3.36 Sequence Diagram Membuat CBH 21. Sequence Diagram Memeriksa CBH Sequence Diagram Memeriksa CBH dimulai dengan membaca CBH. Kepala gudang akan men-generate kode CBH. Setelah sistem mengkonfirmasi bahwa kode CBH yang dimasukkan terdaftar, maka CBH akan ditampilkan. Setelah itu kepala gudang dapat membaca rincian CBH.

106 157 Kepala Gudang Membaca CBH() CBH Rincian CBH Confirm() Generate CBH Id() Membaca Rincian CBH() Gambar 3.37 Sequence Diagram Memeriksa CBH 22. Sequence Diagram Membuat SPPB Sequence Diagram Membuat SPPB dimulai dengan membuat SPPB. Kemudian sistem akan secara otomatis men-generate kode SPPB. Setelah itu sistem akan memasukkan rincian barang yang telah mencapai ROP ke dalam rincian SPPB. Sistem akan mengkonfirmasi terlebih dahulu sebelum data disimpan ataupun dicetak.

107 158 Kepala Gudang SPPB Rincian SPPB Barang Membuat SPPB() Generate SPPB Id() Memasukkan Rincian SPPB() Membaca Barang ROP() Confirm() Gambar 3.38 Sequence Diagram Membuat SPPB 23. Sequence Diagram Memeriksa SPPB Sequence Diagram Memeriksa SPPB dimulai dengan membaca SPPB. Setelah kepala gudang men-generate kode SPPB yang akan diperiksa, maka kemudian sistem akan mengkonfirmasi bahwa kode SPPB yang dimasukkan terdaftar. Setelah itu kepala gudang dapat membaca rincian SPPB tersebut.

108 159 Kepala Gudang Membaca SPPB() SPPB Rincian SPPB Confirm() Generate SPPB Id() Membaca Rincian SPPB() Gambar 3.39 Sequence Diagram Memeriksa SPPB 24. Sequence Diagram Menyetujui SPPB Sequence Diagram Menyetujui SPPB dimulai dengan membaca SPPB. Setelah itu kepala gudang men-generate kode SPPB yang akan disetujui. Setelah itu sistem akan mengkonfirmasi bahwa kode SPPB yang dimasukkan tersebut terdaftar. Setelah itu kepala gudang dapat membaca rincian SPPB. Setelah selesai kepala gudang akan merubah status SPPB tersebut menjadi approve.

109 160 Kepala Gudang Membaca SPPB() SPPB Rincian SPPB Confirm() Generate SPPB Id() Membaca Rincian SPPB() Ubah Status() Gambar 3.40 Sequence Diagram Menyetujui SPPB 25. Sequence Diagram Memeriksa Nota Retur Supplier Sequence Diagram Memeriksa Nota Retur Supplier dimulai dengan membaca nota retur supplier. Kemudian kepala gudang akan men-generate kode supplier yang akan diperiksa nota returnya. Sistem akan mengkonfirmasi bahwa kode supplier yang dimasukkan terdaftar. Setelah itu sistem akan menampilkan rincian nota retur supplier berdasarkan kode supplier tersebut.

110 161 Kepala Gudang Nota Retur Supplier Supplier Rincian Nota Retur Supplier Membaca Nota Retur Supplier() Mengecek Supplier() Confirm() Generate Supplier Id() Membaca Rincian Nota retur Supplier() Gambar3.41 Sequence Diagram Memeriksa Nota Retur Supplier 26. Sequence Diagram Membuat Penerimaan Barang Masuk Sequence Diagram Membuat Penerimaan Barang Masuk dimulai dengan mencatat barang masuk. Kemudian memasukkan header catatan barang masuk dengan mengenerate kode PO guna mencockkan data yang diterima dengan yang dipesan oleh pihak pembelian. Setelah itu sistem akan secara otomatis menampilkan rincian pesanan PO dan memasukkannnya kedalam catatan barang masuk. Setelah itu sistem akan mengkonfirmasi terlebih dahulu sebelum data disimpan.

111 162 Kepala Gudang dan Staf Gudang Persediaan PO Catatan Barang Masuk Mencatat Barang Masuk() Memasukkan Header Catatan Barang Masuk() Mengecek PO() Confirm() Generate PO Id() Memasukkan rincian Catatan Barang Masuk() Confirm() Gambar 3.42 Sequence Diagram Membuat Penerimaan Barang Masuk 27. Sequence Diagram Memeriksa Penerimaan Barang Masuk Sequence Diagram Memeriksa Penerimaan Barang Masuk dimulai dengan membaca persediaan. Setelah itu kepala gudang akan men-generate kode supplier yang akan diperiksa penerimaan barang masuknya. Sistem akan mengkonfirmasi bahwa kode supplier yang dipilih terdaftar. Setelah itu sistem akan menampilkan catatan barang masuk berdasarkan kode suplier tersebut.

112 163 Kepala Gudang dan Staf Gudang Persediaan Supplier Catatan Barang Masuk Membaca Persediaan() Mengecek Supplier() Confirm() Generate Supplier Id() Membaca Catatan Barang Masuk() Gambar 3.43 Sequence Diagram Memeriksa Penerimaan Barang Masuk 28. Sequence Diagram Membuat Pengeluaran Barang Sequence Diagram Membuat Membuat Pengeluaran Barang dimulai dengan mencatat barang keluar. Kemudian memasukkan header catatan barang keluar dengan men-generate kode SPB guna mencocokkan data yang dikeluarkan dengan yang diminta oleh pihak cabang. Setelah itu sistem akan secara otomatis menampilkan rincian permintaan SPB dan memasukkannnya kedalam catatan barang keluar. Setelah itu sistem akan mengkonfirmasi terlebih dahulu sebelum data disimpan.

113 164 Kepala Gudang dan Staf Gudang Persediaan SPB Catatan Barang Keluar Mencatat Barang Keluar() Memasukkan Header Catatan Barang Keluar() Mengecek SPB() Confirm() Generate SPB Id() Memasukkan rincian Catatan Barang Keluar() Confirm() Gambar 3.44 Sequence Diagram Membuat Pengeluaran Barang 29. Sequence Diagram Memeriksa Pengeluaran Barang Sequence Diagram Memeriksa Pengeluaran Barang dimulai dengan membaca persediaan. Setelah itu kepala gudang akan men-generate kode cabang yang akan diperiksa pengeluaran barangnya. Sistem akan mengkonfirmasi bahwa kode cabang yang dipilih terdaftar. Setelah itu sistem akan menampilkan catatan barang keluar berdasarkan kode cabang tersebut.

114 165 Kepala Gudang dan Staf Gudang Persediaan Cabang Catatan Barang Keluar Membaca Persediaan() Mengecek Cabang() Confirm() Generate Cabang Id() Membaca Catatan Barang Keluar() Gambar 3.45 Sequence Diagram Memeriksa Pengeluaran Barang 30. Sequence Diagram Melihat Data Persediaan Sequence Diagram Melihat Data Persediaan dimulai dengan memilih kelompok data persediaan. Kemudian sistem akan menampillkan data kelompok persediaan yang diinginkan.. Kepala Gudang dan Staf Gudang Persediaan Membaca Persediaan() Gambar 3.46 Sequence Diagram Melihat Daftar Persediaan

115 Sequence Diagram Melihat Daftar Cabang Sequence Diagram Melihat Daftar Cabang dimulai dengan membaca daftar cabang. Kemudian sistem akan menampilkan daftar cabang yang ada Kepala Gudang dan Staf Gudang Cabang Membaca Cabang() Gambar 3.47 Sequence Diagram Melihat Daftar Cabang 32. Sequence Diagram Membuat SPB Sequence Diagram Membuat SPB dimulai dengan membuat SPB. Setelah itu sistem secara otomatis akan men-generate kode SPB. User akan men-generate kode cabang yang meminta pengeluaran barang. Sistem akan mengkonfirmasi bahwa kode cabang yang dipilih terdaftar. Kemudian user akan memasukkan rincian barang yang diminta ke dalam rincian SPB dengan membaca daftar barang. Setelah selesai sistem akan mengkonfirmasi terlebih dahulu sebelum menyimpan data tersebut.

116 167 Kepala Gudang dan Staf Gudang SPB Cabang Rincian SPB Barang Membuat SPB() Generate SPB Id() Memasukkan SPB Header() Membaca Cabang() Confirm() Generate Cabang Id() Memasukkan Rincian SPB() Membaca Barang() Confirm() Gambar 3.48 Sequence Diagram Membuat SPB 33. Sequence Diagram Membuat Nota Retur Cabang Sequence Diagram Membuat Nota Retur Cabang dimulai dengan membuat nota retur cabang. Sistem secara otomatis akan men-generate kode nota retur cabang. Lalu kemudian, kepala gudang men-generate kode cabang yang meretur barang. Setelah sistem mengkonfirmasi bahwa kode cabang yang dipilih terdaftar, maka kemudian kepala gudang akan memasukkan rincian barang ke dalam rincian nota retur cabang dengan membaca daftar barang. Setelah selesai sistem akan mengkonfirmasi terlebih dahulu sebelum menuimpan data tersebut.

117 168 Kepala Gudang Nota Retur Cabang Cabang Rincian Nota Retur Cabang Barang Membuat Nota Retur Cabang() Generate Nota Retur Cabag Id() Memasukan Nota Retur Cabang Header() Membaca Cabang() Generate Cabang Id() Confirm() Memasukkan Rincian Nota Retur Cabang() Membaca Barang() Confirm() Gambar 3.49 Sequence Diagram Membuat Nota Retur Cabang 34. Sequence Diagram Memeriksa Nota Retur Cabang Sequence Diagram Memeriksa Nota Retur Cabang dimulai dengan membaca nota retur cabang. Setelah itu user men-generate kode cabang yang akan diperiksa nota retur cabangnya. Sistem akan mengkonfirmasi bahwa kode nota retur cabang yang dipilih terdaftar. Setelah itu sistem akan menampilkan rincian nota retur cabang berdasarkan kode cabang tersebut.

118 169 Kepala Gudang dan Staf Gudang Membaca Nota Retur Cabang() Nota Retur Cabang Cabang Rincian Nota Retur Cabang Membaca Cabang() Confirm() Generate Cabang Id() Membaca Rincian Nota Retur Cabang() Gambar 3.50 Sequence Diagram Memeriksa Nota Retur Cabang Function Function yang terdapat pada sistem adalah sebagai berikut : Function Complexity Operation Mendaftarkan data barang Simple Update, Compute Menghapus data barang Simple Update Memeriksa barang Simple Read Merubah Identitas Barang Simple Update Mendaftarkan Cabang Simple Update

119 170 Menutup Cabang Simple Update Memeriksa Cabang Simple Read Mendaftarkan supplier Simple Update Menghapus data supplier Simple Update Mengubah Identitas supplier Simple Update Memeriksa data supplier Simple Read Membuat PO Medium Update Merubah status PO Medium Update Memeriksa PO Medium Read Menampilkan Hasil PO Medium Read Membuat Penerimaan Barang Masuk Memeriksa Penerimaan Barang Masuk Membuat Pengeluaran Barang Memeriksa Pengeluaran Barang Membuat Nota Retur Supplier Merubah status Nota Retur Supplier Simple Medium Simple Medium Simple Simple Update Read Update Update Update Update

120 171 Memeriksa Nota Retur Supplier Medium Read Membuat SPB Simple Update Memeriksa daftar persediaan Membuat Nota Retur Cabang Memeriksa Nota Retur Cabang Simple Simple Medium Update Update Read Menghitung ROP Simple Compute Menghitung EOQ Simple Compute Mencetak Laporan Pengeluaran Barang Mencetak Laporan Penerimaan Barang Mencetak Laporan Retur Supplier Mencetak Laporan Retur Cabang Medium Medium Medium Medium Read Read Read Read Mencetak PO Medium Read Mencetak SPPB Medium Read Mencetak SPB Medium Read Memberi Peringatan ROP Complex Compute

121 172 Menampilkan Barang ROP Simple Read Membuat SPPB Simple Update Menyetujui SPPB Simple Update Memeriksa SPPB Medium Read Tabel 3.46 Function List Memberi Peringatan ROP Membaca Persediaan Membaca Catatan Barang Keluar Membaca Jumlah Persediaan Membaca Barang Membaca ROP Barang Jika Jumlah Persediaan = ROP Tampilkan Reminder Barang Tampilkan daftar barang yang ROP Tampilkan Membuat SPPB Jika Jumlah Persediaan!= ROP Membaca Jumlah Persediaan Tabel 3.47 Algorithmic Specification untuk Fucntion Memberi Peringatan ROP

122 Interface Determine User Interface Element 1. Membuat PO Aktivitas ini dimulai dari masukkan No. SPPB, kemudian memilih Supplier-supplier yang akan memasok barang yang akan dibeli Setelah memasukkan pesanan, maka user akan mencetak PO dan akan menuju Confirmation Window yang merupakan window konfirmasi untuk kepastian data yang dimasukkan. Setelah menyetujui maka data-data pesanan telah disimpan dalam sistem.

123 174 Interface System window membuat PO No SPPB Kode Supplier Lihat Hasil Menampilkan Hasil PO Melakukan Query Cetak Simpan Confirmation window Mencetak PO OK Menyimpan PO Gambar 3.51 Interface Membuat PO 2. Memeriksa PO Kegiatan dimulai dengan memasukkan criteria yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan criteria yang dimasukkan dan kemudian menampilkan barang sesuai criteria. Pada saat berada pada window Memeriksa PO, hasil PO berdasar criteria yang diminta dapat dicetak.

124 175 Interface System window memeriksa PO No PO Melakukan Query menampilkan daftar PO print Mencetak Daftar PO Gambar 3.52 Interface Memeriksa PO 3. Menyetujui PO Kegiatan dimulai dengan membuka form menyetujui PO dahulu untuk mengubah status not approved menjadi approved. Setelah itu data yang telah disetujui tersebut langsung disimpan di dalam database.

125 176 Interface System window menyetujui PO No PO Melakukan Query menampilkan PO pilih approve Mengubah Status PO Gambar 3.53 Interface Menyetujui PO 4. Menyetujui SPPB Kegiatan dimulai dengan membuka form menyetujui PO dahulu untuk mengubah status not approved menjadi approved. Setelah itu data yang telah disetujui tersebut langsung disimpan di dalam database.

126 177 Interface System window menyetujui SPPB No SPPB Melakukan Query menampilkan SPPB pilih approve Mengubah Status SPPB Gambar 3.54 Interface Menyetujui SPPB 5. Memeriksa Barang Kegiatan dimulai dengan memasukkan Criteria yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan barang sesuai Criteria. Pada saat berada pada window melihat data barang, hasil Criteria dapat dicetak.

127 178 interface system window memeriksa barang memasukkan criteria menampilkan barang yang diplih berdasar criteria diminta Melakukan Query print Cetak Laporan Barang Gambar 3.55 Interface Memeriksa Barang 6. Mendaftarkan Supplier Aktivitas ini dimulai dari memasukkan data-data sesuai dengan yang terdapat pada Window Mendaftarkan Supplier. Setelah itu akan menuju Accept Window yang merupakan window konfirmasi untuk kepastian data yang dimasukkan. Setelah menyetujui maka data-data pesanan telah disimpan dalam sistem. Akan tetapi apabila tidak menyetujui, pesan kesalahan akan muncul.

128 179 Interface System window mendaftarkan supplier Nama Supplier Alamat Kota No Telp No. Fax Kd Barang confirmation window Harga Barang OK decline Simpan Data Supplier Gambar 3.56 Interface Mendaftarkan Supplier 7. Menghapus Data Supplier Kegiatan dimulai dengan memasukkan Kode Supplier yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan supplier sesuai Criteria. Setelah muncul data lengkap supplier, dipilih Hapus dan data supplier terhapus dari sistem.

129 180 Interface window menghapus supplier System Kd Cabang Menampilkan data supplier confirmation window Hapus OK Menghapus Data Supplier Gambar 3.57 Interface Menghapus Supplier 8. Memeriksa Daftar Supplier Kegiatan dimulai dengan memasukkan Criteria yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan Supplier sesuai Criteria. Pada saat berada pada window Memeriksa Daftar Supplier, hasil Criteria dapat dicetak.

130 181 interface system window memeriksa daftar supplier memasukkan criteria menampilkan daftar supplier yang diplih berdasar criteria diminta Melakukan Query print Cetak Laporan Daftar Supplier Gambar 3.58 Interface Memeriksa Daftar Supplier 9. Merubah Identitas Supplier Kegiatan dimulai dengan memasukkan Kode Supplier yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan supplier sesuai Criteria. Setelah muncul data lengkap supplier, dipilih Ubah dan identitas Supplier dapat diubah kemudian disimpan dalam sistem kembali.

131 182 Interface window merubah identitas supplier System kd supplier menampilkan data supplier confirmation window ubah menurut criteria OK Mengubah Identitas Supplier Gambar 3.59 Interface Merubah Identitas Supplier 10. Mendaftarkan Barang Aktivitas ini dimulai dari memasukkan data-data sesuai dengan yang terdapat pada Window Mendaftarkan Barang. Setelah itu akan menuju Accept Window yang merupakan window konfirmasi untuk kepastian data yang dimasukkan. Setelah menyetujui maka data-data Barang telah disimpan dalam sistem. Akan tetapi apabila tidak menyetujui, pesan kesalahan akan muncul.

132 183 Interface System window mendaftarkan barang Nama Barang Satuan confirmation window Gruop Barang ROP EOQ OK decline Simpan Data Barang Gambar 3.60 Interface Mendaftarkan Barang 11. Menghapus Data Barang Kegiatan dimulai dengan memasukkan Kode Barang yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan supplier sesuai Criteria. Setelah muncul data lengkap Barang, diplih Hapus dan data Barang terhapus dari sistem.

133 184 Interface window menghapus data barang System kd barang menampilkan data barang confirmation window hapus OK Menghapus Data Barang Gambar 3.61 Interface Menghapus Data Barang 12. Merubah Identitas Barang Kegiatan dimulai dengan memasukkan Kode Barang yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan Barang sesuai Criteria. Setelah muncul data Barang, plih Ubah dan data Barang terubah di sistem.

134 185 Interface window merubah identitas barang System kd barang menampilkan data barang confirmation window ubah menurut criteria OK Mengubah Identitas Barang Gambar 3.62 Interface Merubah Identitas Barang 13. Mendaftarkan Cabang Aktivitas ini dimulai dari memasukkan data-data sesuai dengan yang terdapat pada Window Mendaftarkan Cabang. Setelah itu akan menuju Accept Window yang merupakan window konfirmasi untuk kepastian data yang dimasukkan. Setelah menyetujui maka data-data Cabang telah disimpan dalam sistem. Akan tetapi apabila tidak menyetujui, pesan kesalahan akan muncul.

135 186 Interface System window mendaftarkan cabang Kd Cabang Nama Cabang Alamat Kota No Telp No Fax confirmation window Simpan OK decline Simpan Cabang Gambar 3.63 Interface Mendaftarkan Cabang 14. Menutup Cabang Kegiatan dimulai dengan memasukkan Kode Cabang yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan Cabang sesuai Criteria. Setelah muncul data lengkap Cabang, diplih Hapus dan data Cabang terhapus dari sistem.

136 187 Interface window menutup cabang System Kd Cabang Menampilkan data Cabang confirmation window Hapus OK Menghapus Data Cabang Gambar 3.64 Interface Menutup Cabang 15. Membuat Nota Retur Supplier Aktivitas ini dimulai dari masukkan data-data yang berkaitan dengan Nota Retur Supplier. Setelah memasukkan data-data, maka akan menuju Confirmation Window yang merupakan window konfirmasi untuk kepastian data yang dimasukkan. Setelah menyetujui maka data-data retur telah disimpan dalam sistem dan dicetak. Akan tetapi apabila tidak menyetujui, pesan kesalahan akan muncul.

137 188 Interface System Windows Membuat Nota Retur Supplier confirm window No Nota Retur Supplier kd supplier kd barang Jumlah OK Decline Simpan Nota Retur Supplier print Cetak Nota Retur Supplier Gambar 3.65 Interface Membuat Nota Retur Supplier 16. Menyetujui Nota Retur Supplier Kegiatan dimulai dengan membuka form menyetujui Nota Retur Supplier dahulu untuk mengubah status not approved menjadi approved. Setelah itu data yang telah disetujui tersebut langsung disimpan di dalam database.

138 189 window menyetujui Nota Retur Supplier System No Nota Retur Supplier Melakukan Query menampilkan Nota Retur Supplier pilih approve Gambar 3.66 Interface Menyetujui Nota Retur Supplier 17. Membuat CBR Aktivitas ini dimulai dari masukkan data-data yang berkaitan dengan CBR. Setelah memasukkan data-data, maka akan menuju Accept Window yang merupakan window konfirmasi untuk kepastian data yang dimasukkan. Setelah menyetujui maka data-data CBR telah disimpan dalam sistem dan dicetak. Akan tetapi apabila tidak menyetujui pesan kesalahan akan muncul.

139 190 Interface System window buat CBR confirm window No CBR Kd Barang Nm Barang Qty OK Decline Simpan dan Cetak CBR Gambar 3.17 Interface Membuat CBR 18. Membuat CBH Aktivitas ini dimulai dari masukkan data-data yang berkaitan dengan CBH. Setelah memasukkan data-data, maka akan menuju Confirmation Window yang merupakan window konfirmasi untuk kepastian data yang dimasukkan. Setelah menyetujui maka data-data CBH telah disimpan dalam sistem dan dicetak. Akan tetapi apabila tidak menyetujui pesan kesalahan akan muncul.

140 191 Interface System window buat CBH confirm window No CBH Kd Barang Nm Barang Qty OK Decline Simpan dan Cetak CBH Gambar 3.68 Interface Membuat CBH 19. Membuat SPPB Aktivitas ini dimulai dari masukkan data-data yang berkaitan dengan SPPB. Setelah memasukkan permintaan, maka akan menuju Confirmation Window yang merupakan window konfirmasi untuk kepastian data yang dimasukkan. Setelah menyetujui maka data-data permintaan telah disimpan dalam sistem dan dicetak. Akan tetapi apabila tidak menyetujui pesan kesalahan akan muncul.

141 192 Interface System window buat SPPB confirm window No SPPB Kd Barang Nm Barang Qty OK Decline Simpan dan Cetak SPPB Gambar 3.69 Interface Membuat SPPB 20. Memeriksa Pengeluaran Barang Kegiatan dimulai dengan memasukkan Criteria yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan barang sesuai Criteria. Pada saat berada pada window Memeriksa Pengeluaran Barang, hasil Criteria dapat dicetak.

142 193 interface window memeriksa Pengeluaran Barang system kd cabang bulan confirmation window tahun OK decline Melakukan Query menampilkan daftar Pengeluaran Barang menurut criteria print Cetak Laporan Pengeluaran Barang Gambar 3.70 Interface Memeriksa Pengeluaran Barang 21. Memeriksa Penerimaan Barang Masuk Kegiatan dimulai dengan memasukkan Criteria yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan barang sesuai Criteria. Pada saat berada pada window Memeriksa Penerimaan Barang Masuk, hasil Criteria dapat dicetak.

143 194 interface window memeriksa Penerimaan Barang Masuk system kd cabang bulan confirmation window tahun OK decline Melakukan Query menampilkan daftar Penerimaan Barang Masuk menurut criteria print Cetak Laporan Penerimaan Barang Masuk Gambar 3.71 Interface Memeriksa Penerimaan Barang Masuk 22. Memeriksa CBR Kegiatan dimulai dengan memasukkan Criteria yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan CBR sesuai Criteria. Pada saat berada pada window Memeriksa CBR, hasil Criteria dapat dicetak.

144 195 interface system window memeriksa CBR bulan confirmation window tahun OK decline Melakukan Query menampilkan CBR menurut criteria print Cetak Laporan CBR Gambar 3.72 Interface Memeriksa CBR 23. Memeriksa SPPB Kegiatan dimulai dengan memasukkan Criteria yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan SPPB sesuai Criteria. Pada saat berada pada window Memeriksa SPPB, hasil Criteria dapat dicetak.

145 196 interface system window memeriksa SPPB bulan confirmation window tahun OK decline Melakukan Query menampilkan SPPB menurut criteria print Cetak Laporan SPPB Gambar 3.73 Interface Memeriksa SPPB 24. Memeriksa Nota Retur Cabang Kegiatan dimulai dengan memasukkan Criteria yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan Nota Retur Cabang sesuai Criteria. Pada saat berada pada window Memeriksa Nota Retur Cabang, hasil Criteria dapat dicetak.

146 197 interface window memeriksa Nota Retur Cabang system kd cabang bulan confirmation window tahun OK decline Melakukan Query menampilkan Nota Retur Cabang menurut criteria print Cetak Laporan Nota Retur Cabang Gambar 3.74 Interface Memeriksa Nota Retur Cabang 25. Memeriksa CBH Kegiatan dimulai dengan memasukkan Criteria yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan CBH sesuai Criteria. Pada saat berada pada window Memeriksa CBH, hasil Criteria dapat dicetak.

147 198 interface system window memeriksa CBH bulan confirmation window tahun OK decline Melakukan Query menampilkan daftar CBH menurut criteria print Cetak Laporan CBH Gambar 3.75 Interface Memeriksa CBH 26. Mengingatkan ReOrder Barang Ketika Sistem mendeteksi bahwa barang telah mencapai ROP maka sistem akan mengingatkan user untuk melakukan pembelian barang melalui window Reminder.

148 199 Interface System window mengingatkan reorder barang OK Gambar 3.76 Interface Mengingatkan Reorder Barang 27. Memeriksa Nota Retur Supplier Kegiatan dimulai dengan memasukkan Criteria yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan barang sesuai Criteria. Pada saat berada pada window Memeriksa Pengeluaran Barang, hasil Criteria dapat dicetak.

149 200 interface window memeriksa Nota Retur Supplier system kd supplier confirmation window bulan tahun OK decline Melakukan Query menampilkan daftar Nota Retur Supplier menurut criteria print Cetak Laporan Nota Retur Supplier Gambar 3.77 Interface Memeriksa Nota Retur Supplier 28. Membuat Penerimaan Barang Masuk Aktivitas ini dimulai dari memasukkan data-data yang berkaitan dengan Mencatat Penerimaan Barang Masuk. Setelah itu, maka akan menuju Accept Window yang merupakan window konfirmasi untuk kepastian data yang dimasukkan. Setelah menyetujui maka data-data tersebut telah disimpan di dalam sistem. Akan tetapi apabila tidak menyetujui maka pesan kesalahan akan ditampilkan.

150 201 Interface System window membuat penerimaan barang masuk confirmation window No PO OK decline Simpan Gambar 3.78 Interface Membuat Penerimaan Barang Masuk 29. Membuat Pengeluaran Barang Aktivitas ini dimulai dari memasukkan data-data yang berkaitan dengan Mencatat Pengeluaran Barang. Setelah itu, maka akan menuju Accept Window yang merupakan window konfirmasi untuk kepastian data yang dimasukkan. Setelah menyetujui maka data-data tersebut telah disimpan di dalam sistem. Akan tetapi apabila tidak menyetujui maka pesan kesalahan akan ditampilkan.

151 202 Interface System window membuat pengeluaran barang confirmation window No SPB OK decline Simpan Gambar 3.79 Interface Membuat Pengeluaran Barang 30. Membuat Nota Retur Cabang Aktivitas ini dimulai dari memasukkan data-data yang berkaitan dengan Membuat Nota Retur Cabang. Setelah itu, maka akan menuju Accept Window yang merupakan window konfirmasi untuk kepastian data yang dimasukkan. Setelah menyetujui maka data-data tersebut telah disimpan di dalam sistem. Akan tetapi apabila tidak menyetujui maka pesan kesalahan akan ditampilkan.

152 203 Interface System Windows Membuat Nota Retur Cabang confirm window No Nota Retur Cabang kd barang Jumlah OK Decline Simpan Nota Retur Cabang print Cetak Nota Retur Cabang Gambar 3.80 Interface Membuat Nota Retur Cabang 31. Menghitung ROP Aktivitas dimulai saat pertama kali mendaftarkan barang dan yang kedua adalah saat merubah identitas barang. Pada kedua form tersebut dapat dimunculkan window menghitung ROP. Dengan memasukkan variabel yang akan dihitung untuk menghasilkan ROP. Dan ini akan menjadi attribut dari form Barang.

153 204 Interface System window menghitung ROP masukkan lead time masukkan jumlah permintaan pertahun jumlah hari kerja pertahun calculate ROP menampilkan ROP Gambar 3.81 Interface Menghitung ROP 32. Menghitung EOQ Aktivitas dimulai saat pertama kali mendaftarkan barang dan yang kedua adalah saat merubah identitas barang. Pada kedua form tersebut dapat dimunculkan window menghitung EOQ. Dengan memasukkan variabel yang akan dihitung untuk menghasilkan EOQ. Dan ini akan menjadi attribut dari form Barang.

154 205 Interface System window menghitung EOQ masukkan biaya pemesanan masukkan jumlah permintaan pertahun masukkan biaya penyimpanan pertahun calculate EOQ menampilkan EOQ Gambar 3.82 Interface Menghitung EOQ 33. Memeriksa Daftar Persediaan Kegiatan dimulai dengan memasukkan Criteria yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan persediaan sesuai Criteria. Pada saat berada pada window melihat daftar persediaan, hasil Criteria dapat dicetak.

155 206 Interface System window memeriksa daftar persediaan memasukkan kriteria Melakukan Query menampilkan persediaan print Mencetak Daftar Persediaan Gambar 3.83 Interface Memeriksa Daftar Persediaan 34. Memeriksa Daftar Cabang Kegiatan dimulai dengan memasukkan Criteria yang diinginkan dan setelah itu sistem akan melakukan query sesuai dengan Criteria yang dimasukkan dan kemudian menampilkan Cabang sesuai Criteria. Pada saat berada pada window Melihat Daftar Cabang, hasil Criteria dapat dicetak.

156 207 Interface System window memeriksa daftar cabang memasukkan kriteria Melakukan Query menampilkan daftar cabang print Mencetak Daftar Cabang Gambar 3.84 Interface Memeriksa Daftar Cabang 35. Menampilkan Barang yang Mencapai ROP Kegiatan dimulai dengan adanya Reminder ReOrder barang yang akan mengawali window ini.

157 208 Interface System window menampilkan barang yang mencapai ROP membuat SPPB Membuka Window MembuatSPPB Gambar 3.85 Interface Menampilkan barang Mencapai ROP 36. Menampilkan Hasil PO Kegiatan ini terjadi setelah layar membuat PO selesai mengkonversikan PO yang dimulai dengan tombol menampilkan hasil PO. Interface System window menampilkan hasil PO OK Melakukan Query menampilkan hasil PO Gambar 3.86 Interface Menampilkan Hasil PO

158 Membuat SPB Aktivitas ini dimulai dari memasukkan data-data yang berkaitan dengan Membuat SPB. Setelah itu, maka akan menuju Accept Window yang merupakan window konfirmasi untuk kepastian data yang dimasukkan. Setelah menyetujui maka data-data tersebut telah disimpan di dalam sistem. Akan tetapi apabila tidak menyetujui maka pesan kesalahan akan ditampilkan. Interface System window membuat SPB confirmation window kd cabang kd barang Qty OK decline Simpan Gambar 3.87 Interface Membuat SPB Berikut adalah Navigation Diagram dari rancangan layar :

159 210 Membuat SPPB Hasil PO Membuat Pengeluaran Brg Tombol Keluar Menu Membuat Pengeluaran Brg Memeriksa Penerimaan Brg Menu Memeriksa Penerimaan Brg Tombol Keluar Membuat Penerimaan Brg Tombol Keluar Menu Membuat Penerimaan Brg Hitung ROP Barang Mendaftarkan Tombol Hitung ROP barang Menu Mendaftarkan barang Tombol Ok/Keluar Tombol Keluar Hitung EOQ Tombol Hitung Barang EOQ Merubah Identitas Barang Tombol Ok/Keluar Menu Merubah Identitas Barang Tombol Keluar Tombol Hitung EOQ Tombol Ok/Keluar Tombol Buat SPPB Brg Mencapai ROP Memeriksa Pengeluaran Brg Tombol Ok Reminder ROP Tombol Keluar Menu Memeriksa Pengeluaran Brg Tombol Keluar Membuat CBR Menu Membuat CBR Tombol Keluar Tombol Hasil PO Membuat PO Membuat PO Tombol Keluar Memeriksa Persediaan Membuat SPB Tombol Keluar Menu Membuat SPB Tombol Keluar Tombol Keluar Menu Memeriksa Retur Supplier Menyetujui Retur Supplier Tombol Keluar Menu Menyetujui Retur Supplier Membuat Retur Supplier Tombol Keluar Menu Membuat Retur Supplier Memeriksa Supplier Tombol Keluar Menu Memeriksa Supplier Tombol Keluar Menghapus Supplier Menu Menghapus Supplier Tombol Hitung ROP Tombol Ok/Keluar Menu Menghapus Menghapus Barang Barang Tombol Keluar Memeriksa Barang Menu Memeriksa Barang Menu Mendaftarkan Cabang Tombol Keluar Menu Menghapus Cabang Tombol Keluar Menghapus Cabang Menu Memeriksa Cabang Tombol Keluar Menu Membuat Retur Cabang Tombol Keluar Membuat Retur Cabang Menu memeriksa Retur Cabang Tombol Keluar Menu Mendaftarkan Supplier Tombol Keluar Menu Merubah Identitas Supplier Tombol Keluar Merubah Identitas Supplier Tombol Keluar Mendaftarkan Cabang Memeriksa Cabang Memeriksa Retur Cabang Mendaftarkan Supplier Gambar Navigation Diagram untuk Sistem Informasi Persediaan dan Pembelian PT Noorumi Catur Manunggal (Mbok Berek)

160 51 diusulkan: Berikut ini merupakan tampilan layar (user interface) dari sistem yang Gambar 3.88 Menu Window 51

161 52 Gambar 3.89 Menu Barang 52

162 53 Gambar 3.90 Window Mendaftarkan Barang 53

163 54 Gambar 3.91 Window Perhitungan ROP Gambar 3.92 Window Perhitungan EOQ 54

164 55 Gambar 3.93 Window Konfirmasi Mendaftarkan Barang Gambar 3.94 Window Merubah Identitas Barang 55

165 56 Gambar 3.95 Window Menghapus Identitas Barang 56

166 57 Gambar 3.96 Window Memeriksa Daftar Barang 57

167 58 Gambar 3.97 Window Menu Cabang Gambar 3.98 Window Mendaftarkan Cabang 58

168 59 Gambar 3.99 Window Menghapus Identitas Cabang Gambar Window Memeriksa Cabang 59

169 60 Gambar Window Membuat Nota Retur Cabang 60

170 61 Gambar Window Memeriksa Nota Retur Cabang Gambar Window Menu Supplier 61

171 62 Gambar Window Mendaftarkan Supplier 62

172 63 Gambar Merubah Identitas Supplier 63

173 64 Gambar Window Menghapus Identitas Supplier 64

174 65 Gambar Window Memeriksa Daftar Supplier 65

175 66 Gambar Membuat Nota Retur Supplier 66

176 67 Gambar Window Menyetujui Nota Retur Supplier 67

177 68 Gambar Window Memeriksa Nota Retur Supplier Gambar Window Menu Persediaan 68

178 69 Gambar Window Membuat Penerimaan Barang Masuk Gambar Window Memeriksa Penerimaan Barang Masuk 69

179 70 Gambar Window Membuat Pengeluaran Barang 70

180 71 Gambar Window Konfirmasi Pengeluaran Barang Telah Selesai Gambar Reminder Terjadi Barang ROP Gambar Window Barang yang Mencapai ROP 71

181 72 Gambar Membuat Surat Permohonan Pembelian Barang Gambar Window Memeriksa Pengeluaran Barang 72

182 73 Gambar Window Membuat Catatan Barang Rusak 73

183 74 Gambar Window Memeriksa Catatan Barang Rusak Gambar Window Membuat Catatan Barang Hilang 74

184 75 Gambar Window Memeriksa Catatan Barang Hilang 75

185 76 Gambar Window Memeriksa Persediaan Gambar Window Memeriksa Surat Permohonan Barang (SPPB) 76

186 77 Gambar Window Membuat Surat Permintaan Barang (SPB) Gambar Window Menu Pembelian 77

187 78 Gambar Window Mennyetujui Surat Permohonan Pembelian Barang Gambar Membuat Purchase Order (PO) 78

188 79 Gambar Window Hasil PO Gambar Window konfirmasi pengeluaran barang telah selesai Gambar Window massage error 79

189 80 Gambar Window Menyetujui Purchase Order (PO) Gambar Window Memeriksa Purchase Order (PO) 80

190 81 Gambar Window Validasi Data Belum Lengkap Terisi 81