bab 3 analisa sistem informasi 3.1gambaran umum …thesis.binus.ac.id/asli/bab3/lbm2005-48-bab...
TRANSCRIPT
52
BAB 3
ANALISA SISTEM INFORMASI
3.1Gambaran Umum Perusahaan
3.1.1 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 jabatan-
jabatan 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 pengusaha-
pengusaha wanita lainnya yang berhasil membuka rumah makan sebagai usahanya.
Dari pengalaman-pengalamannya yang bermula dari pedagang ayam keliling kampung-
kampung hingga menjadi pengusaha rumah makan ayam goreng Mbok Berek Ny. Umi.
Sebelum usahanya berhasil seperti sekarang ini Ny. Umi dengan dibantu suaminya, kira-
kira 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
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 1983.
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
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.
3.1.2 Struktur Organisasi
Direktur
ManajerPersonalia
ManajerKeuangan
ManajerOperasional
Staff
KepalaAccounting Pembelian Kepala Gudang Supervisor
Restaurant
Staff Staff Staff Staff
Gambar 3.1 Struktur Oragisasi PT Noorumi Catur Manunggal (Mbok Berek)
55
3.1.3 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
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
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
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 :
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
3.2.1 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).
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.
61
3. Pembelian hanya boleh dilakukan oleh Bagian Pembelian. Bagian lain tidak dapat
melakukan pembelian kepada supplier.
3.2.2 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.
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.
63
3.3 Rich Picture Sistem yang Berjalan
Pengecekan
Staff Gudang
$$$
Manajer Pembelian
Surat Permintaan Pembelian Brg(SPPB)
Membuat
Diserahkan
Prediksipembelian masih
menggunakanteori kebiasaan,jadi sering tidak
tepat.
Suppliers
PO
MembuatMemesan
Fax / Telepon
MengirimFax
Mengirim Barang
Kepala Gudang
Gudang
$
Cabang
SPBReturCabang
Distribusi
Membuat Membuat
Mengirim
Mengirim1 2 3
4 5 67 8 9
* 8 #
Disimpan
Kurangnya pengontrolanpersediaan, sehingga
informasi dan laporan kepembelian sering
terlambat
Barang yang masukdan keluar sangatbanyak, jadi sering
tidak terdeteksipersediaan yang
sudah mencapai titikminimum
Retur Supplier
Membuat MengirimSurat Jalan & BKP
Dicatat
Membuat
Surat Jalan& BBK
Kartu Stok
Dikeluarkan
Diterima
Dicek
BTG
Membuat
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
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
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
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
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 barang-
barang 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
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
69
Pengecekan
Staff Gudang
Kepala Gudang
Gudang
$
Cabang
SPB
Nota Retur Cabang
Input Data
Disimpan
Suppliers
Mengirim Barang
Nota Retur Supplier
Mencetak Dikirim
Membuat
Membuat
Mengirim
MengirimBarang danSurat Jalan
$ $ $
Pembelian PO
1 2 3
4 5 67 8 9
* 8 #
Fax / Telepon
Surat PermintaanPembelian Barang
Mencetak Memesan
Kirim daftarPesanan
Distribusi
InformasiPersediaan
ServerDatabase
Dicek
Dikeluarkan
Diterima
Input Data
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
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 Seorang manajer yang bertanggung jawab dalam segala aktivitas yang
Domain 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
Technology
2 buah PC yang terhubung dengan LAN dan dilengkapi dengan beberapa
printer
Objects Barang dan Persediaan
Responsibility
Menghasilkan suatu informasi yang cepat dan tepat bagi pihak yang
membutuhkan serta dapat mengatasi permasalahan-permasalahan yang
timbul pada aktivitas pemesanan barang, penerimaan barang, pengeluaran
barang, retur barang, pengawasan mutu dan pengendalian stok
Tabel 3.1 Faktor Criteria
71
3.9 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.
3.10 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.
72
3.11 Problem Domain Analysis
3.11.1 Classes
Class candidate dan class dari system definition adalah sebagai berikut :
Class Candidate Class
- Manajer Pembelian
- User ID & Password
- P.O.
- Database
- Persediaan
- Kepala Gudang
- Staf Gudang
- Manajemen Accounting
- Gudang
- Surat Permintaan Pembelian Barang
- Surat Permintaan Barang
- Sales Order
- Supplier
- Barang
- Bukti Keluar Gudang
- Nota Retur Supplier
- Staf Pengiriman
- Cabang
- Supervisor Restaurant
- 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
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.
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.
3.11.2 Events
Event Candidate dan event dari system definition yang diusulkan adalah sebagai
berikut :
Event Candidate Event
- Mendaftarkan
- Menerapkan
- Mencatat
- Menggunakan
- Membuat
- Melihat
- Mengubah
- Mengakses
- Memasukkan
- Menyimpan
- Mendaftarkan
- Membuat
- Mengubah
- Mencatat
- Memasukkan
- Menyetujui
- Menghapus
- Menghitung
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 :
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.
77
Men
dafta
rkan
Mem
asuk
kan
Mem
buat
Men
ghap
us
Men
yetu
jui
Men
guba
h
Men
ghitu
ng
Men
cata
t
Persediaan √
Supplier √ √ √
Cabang √ √
PO √ √ √
CBH √ √
CBR √ √
Nota Retur
Supplier
√ √ √
Nota Retur
Cabang
√ √
Barang √ √ √ √
SPB √ √ √
SPPB √ √ √
Tabel 3.4 Event Table
3.11.3 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
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.
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.
80
+Mencatat Barang Masuk()+Mencatat Barang Keluar()
-Kode_Barang-Jumlah_Persediaan
Persediaan
+Membuat PO()+Menyetujui PO()+Memasukkan Rincian PO()
-No_PO-Tgl_Pemesanan-Tgl_Terima-No_SPPB-Kode_Supplier
PO
+Mendaftarkan Supplier()+Mengubah Identitas Supplier()+Menghapus Supplier()
-Kode_Supplier-Nama_Supplier-Alamat-No_Telp-Kode_Barang
Supplier
+Mendaftarkan Barang()+Mengubah Identitas Barang()+Menghapus Barang()+Menghitung ROP()+Menghitung EOQ()
-Kode_Barang-Group_Barang-Nama_Barang-Satuan-ROP-EOQ
Barang+Membuat Nota Retur Supplier()+menyetujui Nota retur Supplier()+Memasukkan Rincian Retur Supplier()
-No_Retur_Supplier-Tanggal-Kode_Supplier-Kode_Barang-Qty_Barang
Nota_Retur_Supplier
+Membuat Nota Retur Cabang()+Memasukkan Rincian Nota Retur Cabang()
-No_Retur_Cabang-Tanggal-Kode_Cabang-Kode_Barang-Qty_Barang
Nota Retur Cabang
+Membuat CBR()+Memasukkan Rincian CBR()
-No_CBR-Tanggal-Kd_Brg-Qty_Brg
CBR
+Mendaftarkan Cabang()+Menghapus Cabang()
-Kode_Cabang-Nama_Cabang-Alamat-No_Telp
Cabang
1
1
1
1
+Membuat SPB()+Menyetujui SPB()+Memasukkan Rincian SPB()
-No_SPB-Tanggal-Kode_Cabang-Kd_Brg-Qty_Brg
SPB
1
1
+Membuat SPPB()+Menyetujui SPPB()+Memasukkan Rincian SPPB()
-No_SPPB-Tanggal-Kd_Brg-Qty_Brg
SPPB
1..*
1
1
1
+Membuat CBH()+Memasukkan Rincian CBH()
-No_CBH-Tanggal-Kd_Barang-Qty_Brg
CBH
1
1..*
1
1..*
1
1..*
1
1..*
1..*1
1..*
11
1..*
1
1..*
1..* 1
1..*
1
1
1..*
1
1..*
1
1..*
1
1..*
1
1..*
Gambar 3.4 Class Diagram
3.11.4 Behavior
Berikut ini merupakan behavior pattern dari masing-masing class :
1. Class “Barang”
81
Terdaftar/ Mendaftarkan_Barang
Registrated/ Mengubah_Data_Barang / Dihapus
/ Mengubah_Data_Barang
Gambar 3.5 Behaviour Pattern Class Barang
2. Class “Supplier”
Terdaftar/ Mendaftarkan Supplier
/ Mengubah_Identitas_Supplier
/ Menghapus
Gambar 3.6 Behaviour Pattern Class Supplier
3. Class “Cabang”
Terdaftar/ Mendaftarkan_Cabang / Ditutup
Gambar 3.7 Behaviour Pattern Class Cabang
4. Class “Persediaan”
Registrated/ Mencatat_Begining_Inventory
/ Mencatat_Barang _Masuk
/ Mencatat_Barang_Keluar
Gambar 3.8 Behaviour Pattern Class Persediaan
82
5. Class “PO”
/ MembuatPOCreated
/ Mencatat_Rincian _PesananRegistrated
/ Mencatat_Rincian_Pesanan
Approve
/ Menyetujui
Gambar 3.9 Behaviour Pattern Class PO
6. Class “Nota Retur Supplier”
Created/ Membuat_Nota_Retur_Supplier
Registrated/ Mencatat Rincian Barang
/ Approve
Ditukar
/ Mencatat_Rincian_Barang
Gambar 3.10 Behaviour Pattern Class Nota Retur Supplier
7. Class “Nota Retur Cabang”
83
Created/ Membuat_Nota_Retur_Cabang
Registrated/ Mencatat_Rincian_Retur_Cabang
/ Mencatat_Rincian_Retur_Cabang
/ Menyetujui
Tukar
Gambar 3.11 Behaviour Pattern Class Nota Retur Cabang
8. Class “CBR”
Created/ Membuat CBR
Registrated/ Mencatat_Barang_yg_Rusak / Record
Recorded
/ Mencatat_Barang_Rusak
Gambar 3.12 Behaviour Pattern Class CBR
9. Class “CBH”
Created/ Membuat CBH
Registrated/ Mencatat_Barang_yg_Hilang / Record
Recorded
/ Mencatat_Barang_Hilang
Gambar 3.13 Behaviour Pattern Class CBH
10. Class “Surat Permintaan Barang”
84
Created/ MembuatSPB / Mencatat_Rincian_Permintaan
Registrated
Approve
/ Menyetujui
/ Mencatat_Rncian_Permintaan
Gambar 3.14 Behaviour Pattern Class SPB
11. Class “Surat Permintaan Pembelian Barang”
Created/ MembuatSPPB / Mencatat_Rincian_Permintaan
Registrated
/ Mencatat_Rincian_Permintaan
Approve
/ Menyetujui
Gambar 3.15 Behaviour Pattern Class SPPB
Dari behavior pattern diatas dapat ditentukan jenis event yang dialami masing-
masing class, yaitu event yang terjadi hanya sekali (sequnce/selection) ataupun yang
terjadi berulangkali selama lifetime-nya (iteration events). Gambar event table
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.
Men
dafta
rkan
Mem
asuk
kan
Mem
buat
Men
ghap
us
Men
yetu
jui
Men
guba
h
Men
ghitu
ng
Men
cata
t
Persediaan *
Supplier + + *
Cabang + +
PO * + +
CBH * +
CBR * +
Nota Retur
Supplier
* + +
Nota Retur
Cabang
* + +
Barang + + * *
SPB * + +
SPPB * + +
Tabel 3.5 Event Table
86
3.11.5.Usage
Purchasing and Inventory Information System
Manajer Pembelian
Membuat PO
MendaftarkanSupplier
Membuat Penerimaan Barang Masuk
MendaftarkanCabang
Menghapus DataSupplier
Membuat Pengeluaran Barang
MendaftarkanBarang
Membuat NotaRetur Supplier
Membuat SPPB
Memeriksa NotaRetur Supplier
Membuat NotaRetur Cabang
Memeriksa DaftarPersediaan
Memeriksa Barang
Memeriksa DaftarCabang
Menghapus DataBarang
Menutup Cabang
Bagian Gudang
Membuat CBR
Membuat CBH
Membuat SPB
Mengubah Identitas Barang
Memeriksa DaftarSupplier
Mengingatkanreorder barang
Menghitung ROPMenghitung EOQ
memeriksa dataPO
Menyetujui PO
Mengubah Identitas Supplier
Menyetujui NotaRetur Supplier
Menyetujui SPPB
Memeriksa NotaRetur Cabang
Memeriksa SPPB
Memeriksa CBR
Memeriksa CBH
Memeriksa Penerimaan Barang Masuk
Memeriksa Pengeluaran Barang
Kepala Gudang
(Staff Gudang)
menampilkan hasilPO
Menampilkan barangyang mencapai
ROP
Gambar 3.16 Use Case Diagram
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
88
Base Use Case untuk tiap-tiap Use Case adalah sebagai berikut :
Use Case Membuat PO
Manajer Pembelian
Membuat PO
Use Case Name Membuat PO
Unique Use Case ID UC-01
Primary Actor 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 Adanya Surat Permintaan Pembelian Barang
Flow Of Events 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
89
4. Setelah data lengkap, Manajer Pembelian akan mencetak
PO tersebut
Post Condition Adanya PO
Priority Medium
Alternative Flow and
Exceptions
Jika data yang dimasukkan tidak lengkap maka sistem akan
menampilkan pesan error
Non Behavioral
Requirements
Hanya Manajer Pembelian yang memasukkan pesanan ke dalam
sistem
Assumptions Semua data-data barang dan data-data supplier telah terdaftar ke
dalam sistem
Issues N/A
Tabel 3.9 Base Use Case Description untuk Membuat PO
Use Case Memeriksa Barang
Staff Gudang Memneriksa Barang
Kepala Gudang
Manajer Pembelian
90
Use Case Name Memeriksa Barang
Unique Use Case ID UC-02
Primary Actor 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 User telah melihat daftar barang
Priority High
Alternative Flow and
Exceptions
Jika User ingin membuat List mengenai barang, maka User dapat
memerintahkan sistem untuk mencetaknya
Non Behavioral
Requirements
N/A
Assumptions N/A
Issues N/A
Tabel 3.10 Base Use Case Description untuk Melihat Daftar Barang
91
Use Case Mendaftarkan Supplier
Manajer Pembelian
MendaftarkanSupplier
Use Case Name Mendaftarkan Supplier
Unique Use Case ID UC-03
Primary Actor Manajer Pembelian
Secondary Actor -
Brief Description Manajer Pembelian mendaftarkan supplier baru yang belum ada
di dalam database
Preconditions Adanya calon supplier yang belum terdaftar
Flow Of Events 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 Data supplier telah ada di dalam sistem
Priority Medium
Alternative Flow and
Exceptions
Jika data yang dimasukkan tidak lengkap oleh manajer
pembelian maka akan timbul pesan error
92
Non Behavioral
Requirements
Hanya Manajer Pembelian yang bisa mendaftarkan supplier
Assumptions N/A
Issues N/A
Tabel 3.11 Base Use Case Description untuk Mendaftarkan Supplier
Use Case Menghapus Data Supplier
Manajer Pembelian
Menghapus DataSupplier
Use Case Name Menghapus Data Supplier
Unique Use Case ID UC-04
Primary Actor 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
93
terhapus dan data akan ter-update.
Post Condition Data supplier telah terhapus dari sistem
Priority High
Alternative Flow and
Exceptions
Jika Manajer Pembelian belum memilih Supplier maka, data
Supplier tidak dapat dihapus
Non Behavioral
Requirements
Hanya Manajer Pembelian yang bisa menghapus supplier
Assumptions N/A
Issues N/A
Tabel 3.12 Base Use Case Description untuk Menghapus Data Supplier
Use Case Mendaftarkan Barang
MendaftarkanBarang
Manajer Pembelian
Use Case Name Mendaftarkan Barang
Unique Use Case ID UC-05
Primary Actor Manajer Pembelian
Secondary Actor -
Brief Description Manajer Pembelian mendaftarkan barang yang belum ada di
dalam database
94
Preconditions Adanya barang yang belum terdaftar
Flow Of Events 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
Jika data yang dimasukkan tidak lengkap oleh Manajer
Pembelian maka akan timbul pesan error
Non Behavioral
Requirements
Hanya Manajer Pembelian yang bisa mendaftarkan data barang
Assumptions N/A
Issues N/A
Tabel 3.13 Base Use Case Description untuk Mendaftarkan Barang
Use Case Membuat SPB
Staff Gudang
Membuat SPB
Kepala Gudang
95
Use Case Name Membuat SPB
Unique Use Case ID UC-06
Primary Actor 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 Adanya Surat Permintaan Barang dari Cabang
Flow Of Events 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 Terbuatnya SPB di dalam Sistem
Priority Medium
Alternative Flow and
Exceptions
Jika data yang dimasukkan tidak lengkap maka sistem akan
menampilkan pesan error
Non Behavioral
Requirements
Hanya Pihak Gudang yang berhak mencatat SPB ke dalam
sistem
Assumptions Semua data-data barang telah terdaftar ke dalam sistem
Issues N/A
Tabel 3.14 Base Use Case Description untuk Mencatat SPB
96
Use Case Membuat SPPB
Kepala Gudang
Membuat SPPB
Use Case Name Membuat SPPB
Unique Use Case ID UC-07
Primary Actor 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 Adanya stock minimum bahan
Flow Of Events 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 SPPB telah tercetak
Priority High
Alternative Flow
and Exceptions
Jika tidak ada warning terlebih dahulu dari sistem, maka
SPPB tidak dapat dicetak
97
Non Behavioral
Requirements
Hanya dapat dilakukan oleh kepala gudang.
Assumptions N/A
Issues N/A
Tabel 3.15 Base Use Case Description untuk Membuat SPPB
Use Case Membuat Pengeluaran Barang
Staff Gudang
Membuat Pengeluaran Barang
Kepala Gudang
Use Case Name Membuat Pengeluaran Barang
Unique Use Case ID UC-08
Primary Actor Kepala Gudang, Staff Gudang
Secondary Actor
Brief Description Pihak Gudang akan mencatat barang keluar saat barang
dikeluarkan dari gudang ke dalam sistem
Preconditions Barang dikeluarkan dari gudang
Flow Of Events 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
98
Post Condition Data barang keluar telah tersimpan di dalam database
Priority Medium
Alternative Flow and
Exceptions
Jika data yang dimasukkan tidak lengkap maka sistem akan
menampilkan pesan error
Non Behavioral
Requirements
Hanya pihak Gudang yang berhak mencatat Pengeluaran Barang
dari Gudang
Assumptions Data barang yang dikeluarkan harus telah ada di dalam sistem
Issues N/A
Tabel 3.16 Base Use Case Description untuk Mencatat Pengeluaran Barang
Use Case Membuat CBR
Kepala Gudang
Membuat CBR
Use Case Name Membuat CBR
Unique Use Case ID UC-09
Primary Actor 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
99
Preconditions Adanya barang yang tidak layak pakai
Flow Of Events 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 Catatan Barang Rusak telah dimasukkan dalam sistem
Priority Medium
Alternative Flow and
Exceptions
Jika data yang dimasukkan tidak lengkap, maka akan muncul
pesan error
Non Behavioral
Requirements
Kegiatan ini hanya dapat dilakukan Kepala Gudang.
Assumptions N/A
Issues N/A
Tabel 3.17 Base Use Case Description untuk Membuat CBR
100
Use Case Membuat CBH
Kepala Gudang
Membuat CBH
Use Case Name Membuat CBH
Unique Use Case ID UC-10
Primary Actor 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 Adanya barang yang hilang
Flow Of Events 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
101
Priority Medium
Alternative Flow and
Exceptions
Jika data yang dimasukkan tidak lengkap, maka akan muncul
pesan error
Non Behavioral
Requirements
Kegiatan ini hanya dapat dilakukan Kepala Gudang.
Assumptions N/A
Issues N/A
Tabel 3.18 Base Use Case Description untuk Membuat CBH
Use Case Membuat Nota Retur Supplier
Kepala Gudang
Membuat NotaRetur Supplier
Use Case Name Membuat Nota Retur Supplier
Unique Use Case ID UC-11
Primary Actor 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 Adanya barang yang tidak layak digunakan dari Supplier
Flow Of Events 1. Jika ada barang yang tidak layak digunakan maka Kepala
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 Nota Retur Supplier tercetak
Priority Medium
Alternative Flow and
Exceptions
Jika barang yang diterima layak digunakan maka tidak dapat
dibuat Nota Retur Supplier
Non Behavioral
Requirements
Hanya Kepala Gudang yang membuat Nota Retur Supplier
Assumptions Data Supplier harus terdaftar di dalam sistem.
Issues N/A
Tabel 3.19 Base Use Case Description untuk Membuat Nota Retur Supplier
103
Use Case Menyetujui Nota Retur Supplier
Kepala Gudang
Menyetujui NotaRetur Supplier
Use Case Name Menyetujui Nota Retur Supplier
Unique Use Case ID UC-12
Primary Actor 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 Adanya barang Nota Retur Supplier yang diterima
Flow Of Events 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
104
berubah
Post Condition Nota Retur Supplier telah disetujui
Priority Medium
Alternative Flow
and Exceptions
N/A
Non Behavioral
Requirements
Hanya Kepala Gudang yang akan melakukan persetujuan
Nota Retur Supplier
Assumptions N/A
Issues N/A
Tabel 3.20 Base Use Case Description untuk Menyetujui Nota Retur Supplier
Use Case Membuat Nota Retur Cabang
Staf Gudang Kepala Gudang
Membuat NotaRetur Cabang
Use Case Name Membuat Nota Retur Cabang
Unique Use Case ID UC-13
Primary Actor 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
105
Preconditions Adanya Nota Retur Cabang yang diterima dari Cabang
Flow Of Events 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 Medium
Alternative Flow
and Exceptions
N/A
Non Behavioral
Requirements
Hanya pihak Gudang yang membuat Nota Retur Cabang
Assumptions N/A
Issues N/A
Tabel 3.21 Base Use Case Description untuk Membuat Nota Retur Cabang
Use Case Membuat Penerimaan Barang Masuk
Staf Gudang Kepala Gudang
Membuat Penerimaan Barang Masuk
106
Use Case Name Membuat Penerimaan Barang Masuk
Unique Use Case ID UC-14
Primary Actor 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 Adanya penerimaan barang
Flow Of Events 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 Medium
Alternative Flow
and Exceptions
Jika data yang dimasukkan tidak cocok maka akan muncul
pesan error
Non Behavioral
Requirements
Hanya pihak Gudang yang berhak membuat penerimaan
barang masuk
Assumptions Semua data barang harus ada di dalam sistem
107
Issues N/A
Tabel 3.22 Base Use Case Description untuk Mencatat Penerimaan Barang Masuk
Use Case Memeriksa Daftar Persediaan
Staf Gudang Kepala Gudang
Memeriksa DaftarPersediaan
Use Case Name Memeriksa Daftar Persediaan
Unique Use Case ID UC-15
Primary Actor Kepala Gudang, Staff Gudang
Secondary Actor -
Brief Description Pihak Gudang memeriksa persediaan yang ada di dalam
database sistem untuk mengetahui data-data persediaan
Preconditions Informasi persediaan telah berada di dalam sistem
Flow Of Events 1. Pihak Gudang melihat persediaan berdasar
pengelompokan yang ada
2. Sistem Informasi akan membaca dari database sistem
seluruh informasi berdasarkan pengelompokkan yang
108
diminta oleh Kepala Gudang
3. Sistem menampilkan Persediaan
Post Condition Pihak Gudang telah memeriksa data Persediaan
Priority High
Alternative Flow
and Exceptions
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 Data Persediaan telah ada di dalam Sistem
Issues N/A
Tabel 3.23 Base Use Case Description untuk Memeriksa Data Persediaan
Use Case Mendaftarkan Cabang
Kepala Gudang
MendaftarkanCabang
Use Case Name Mendaftarkan Cabang
Unique Use Case ID UC-16
Primary Actor Kepala Gudang
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 Data Cabang telah ada di dalam sistem
Priority High
Alternative Flow
and Exceptions
Jika data yang dimasukkan tidak lengkap oleh Kepala Gudang
maka akan timbul pesan error
Non Behavioral
Requirements
Hanya Kepala Gudang yang bisa mendaftarkan Cabang
Assumptions N/A
Issues N/A
Tabel 3.24 Base Use Case Description untuk Mendaftarkan Cabang
110
Use Case Memeriksa Daftar Cabang
Staf Gudang Kepala Gudang
Memeriksa DaftarCabang
Use Case Name Memeriksa Daftar Cabang
Unique Use Case ID UC-17
Primary Actor Kepala Gudang, Staff Gudang
Secondary Actor -
Brief Description Pihak Gudang memeriksa Cabang yang ada di dalam database
sistem untuk mengetahui data-data Cabang
Preconditions Informasi Cabang telah berada di dalam sistem
Flow Of Events 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 Pihak Gudang telah melihat data Cabang
Priority High
Alternative Flow and
Exceptions
Jika pihak Gudang ingin membuat List cabang, maka pihak
Gudang dapat memerintahkan sistem untuk mencetak List
cabang
Non Behavioral
Requirements
Hanya pihak Gudang yang berhak menampilkan cabang
111
Assumptions Semua data Cabang telah terdaftar di dalam sistem
Issues N/A
Tabel 3.25 Base Use Case Description untuk Memeriksa Daftar Cabang
Use Case Menutup Cabang
Kepala Gudang
Menutup Cabang
Use Case Name Menutup Cabang
Unique Use Case ID UC-18
Primary Actor Kepala Gudang
Secondary Actor -
Brief Description Kepala Gudang menghapus cabang yang ada di dalam
database
Preconditions Adanya Cabang yang akan terhapus dari sistem
Flow Of Events 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
112
Post Condition Data Cabang telah terhapus dari sistem
Priority High
Alternative Flow
and Exceptions
Jika tidak ada Cabang yang ditutup maka data Cabang tidak
dapat terhapus dari sistem
Non Behavioral
Requirements
Hanya Kepala Gudang yang bisa menutup Cabang
Assumptions N/A
Issues N/A
Tabel 3.26 Base Use Case Description untuk Menutup Cabang
Use Case Mengubah Identitas Barang
Manajer Pembelian
Mengubah Identitas Barang
Use Case Name Mengubah Identitas Barang
Unique Use Case ID UC-19
Primary Actor 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
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 Identitas Barang telah terubah dari sistem
Priority High
Alternative Flow and
Exceptions
Jika Manajer Pembelian belum memilih Barang maka, identitas
Barang tidak dapat diubah
Non Behavioral
Requirements
Hanya Manajer Pembelian yang bisa mengubah identitas Barang
Assumptions N/A
Issues N/A
Tabel 3.27 Base Use Case Description untuk Mengubah Identitas Barang
Use Case Menghapus Data Barang
Manajer
Pembelian
MenghapusData
Barang
114
Use Case Name Menghapus Data Barang
Unique Use Case ID UC-20
Primary Actor 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 Data Barang telah terhapus dari sistem
Priority High
Alternative Flow and
Exceptions
Jika Manajer Pembelian belum memilih Barang maka, data
Barang tidak dapat dihapus
Non Behavioral
Requirements
Hanya Manajer Pembelian yang bisa menghapus Barang
Assumptions N/A
Issues N/A
Tabel 3.28 Base Use Case Description untuk Menghapus Data Barang
115
Use Case Menghitung ROP
StaffGudang
MenghitungROP
KepalaGudang
Use Case Name Menghitung ROP
Unique Use Case ID UC-21
Primary Actor 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 ROP belum terhitung
Flow Of Events 1. Sistem akan membaca jumlah demand dan lead
time
2. Sistem akan mengkalkulasi perhitungan yang
dibutuhkan
3. Hasil akan ditampilkan
Post Condition ROP telah terhitung
Priority High
Alternative Flow and N/A
116
Exceptions
Non Behavioral
Requirements
• Hanya Bagian Gudang yang akan menerima hasil
ROP
Assumptions N/A
Issues N/A
Tabel 3.29 Base Use Case Description untuk Menghitung ROP
Use Case Menghitung EOQ
StaffGudang
MenghitungEOQ
KepalaGudang
Use Case Name Menghitung EOQ
Unique Use Case ID UC-22
Primary Actor Kepala Gudang, Staff Gudang
Secondary Actor -
Brief Description EOQ akan dihitung untuk mengetahui berapa jumlah
pemesanan yang optimal, setiap periode waktu demand
117
dihitung, nilai EOQ dapat berubah disesuaikan menurut
kebutuhan
Preconditions EOQ belum terhitung
Flow Of Events 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 EOQ telah terhitung
Priority High
Alternative Flow and
Exceptions
Perhitungan EOQ dilakukan menurut waktu yang telah
disepakati perusahaan, setahun sekali
Non Behavioral
Requirements
• Hanya Bagian Gudang yang akan menerima EOQ
Assumptions Data telah ada di dalam sistem
Issues N/A
Tabel 3.30 Base Use Case Description untuk Menghitung EOQ
118
Use Case Mengingatkan Reorder Barang
Staf Gudang Kepala Gudang
MengingatkanReorder Barang
Use Case Name Mengingatkan Reorder Barang
Unique Use Case ID UC-23
Primary Actor 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 Reminder belum aktif
Flow Of Events 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 Reminder telah aktif
Priority High
Alternative Flow N/A
119
and Exceptions
Non Behavioral
Requirements
• Hanya Bagian Gudang yang akan menerima hasil tersebut
Assumptions Data telah ada di dalam sistem
Issues N/A
Tabel 3.31 Base Use Case Description untuk Mengingatkan Reorder Barang
Use Case Memeriksa Penerimaan Barang Masuk
Staf Gudang Kepala Gudang
Memeriksa Penerimaan Barang Masuk
Use Case Name Memeriksa Penerimaan Barang Masuk
Unique Use Case ID UC-24
Primary Actor 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
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 User telah memeriksa Penerimaan Barang Masuk
Priority High
Alternative Flow and
Exceptions
User dapat memerintahkan sistem untuk mencetak Penerimaan
Barang Masuk yang diperiksa
Non Behavioral
Requirements
N/A
Assumptions N/A
Issues N/A
Tabel 3.32 Base Use Case Description untuk Memeriksa Penerimaan Barang Masuk
Use Case Memeriksa Pengeluaran Barang
Staf Gudang Kepala Gudang
Memeriksa Pengeluaran Barang
121
Use Case Name Memeriksa Pengeluaran Barang
Unique Use Case ID UC-25
Primary Actor Kepala gudang, Staff Gudang
Secondary Actor -
Brief Description User memeriksa di dalam database sistem untuk mengetahui
informasi tentang Pengeluaran Barang
Preconditions Informasi Pengeluaran Barang telah berada di dalam sistem
Flow Of Events 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 User telah memeriksa Pengeluaran Barang
Priority High
Alternative Flow and
Exceptions
User dapat memerintahkan sistem untuk mencetak Pengeluaran
Barang yang diperiksa
Non Behavioral
Requirements
N/A
Assumptions N/A
Issues N/A
Tabel 3.33 Base Use Case Description untuk Memeriksa pengeluaran Barang
122
Use Case Memeriksa SPB
Staff Gudang
Menampilkan barangyang mencapai
ROP
Kepala Gudang
Use Case Name Menampilkan Barang Yang Mencapai ROP
Unique Use Case ID UC-26
Primary Actor 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 Ada Reminder ReOrder Barang
Flow Of Events 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 User melihat barang-barang apa saja yang mencapai ROP
Priority High
Alternative Flow and
Exceptions
Hanya bagian gudang yang berhak melihat barang-
barang apa saja yang mencapai titik ROP
Non Behavioral N/A
123
Requirements
Assumptions N/A
Issues N/A
Tabel 3.34 Base Use Case Description untuk Memeriksa SPB
Use Case Memeriksa SPPB
Staf Gudang Kepala Gudang
Memeriksa SPPB
Use Case Name Memeriksa SPPB
Unique Use Case ID UC-27
Primary Actor Kepala gudang, Staff Gudang
Secondary Actor -
Brief Description User memeriksa di dalam database sistem untuk mengetahui
informasi tentang SPPB
Preconditions Informasi SPPB telah berada di dalam sistem
Flow Of Events 1. User memeriksa SPPB yang diinginkan
2. Sistem Informasi akan membaca dari database sistem
seluruh informasi berdasarkan pengelompokkan yang
diminta oleh User
124
3. Sistem menampilkan SPPB yang diminta
4. Bila diperlukan maka dapat dicetak
Post Condition User telah memeriksa SPPB
Priority High
Alternative Flow and
Exceptions
User dapat memerintahkan sistem untuk mencetak SPPB yang
diperiksa
Non Behavioral
Requirements
N/A
Assumptions N/A
Issues N/A
Tabel 3.35 Base Use Case Description untuk Memeriksa SPPB
Use Case Memeriksa CBR
Staf Gudang Kepala Gudang
Memeriksa CBR
Use Case Name Memeriksa Barang
Unique Use Case ID UC-28
Primary Actor Kepala gudang, Staff Gudang
Secondary Actor -
Brief Description User memeriksa di dalam database sistem untuk mengetahui
125
informasi tentang CBR
Preconditions Informasi CBR telah berada di dalam sistem
Flow Of Events 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 User telah memeriksa CBR
Priority High
Alternative Flow and
Exceptions
User dapat memerintahkan sistem untuk mencetak CBR yang
diperiksa
Non Behavioral
Requirements
N/A
Assumptions N/A
Issues N/A
Tabel 3.36 Base Use Case Description untuk Memeriksa CBR
126
Use Case Memeriksa CBH
Staf Gudang Kepala Gudang
Memeriksa CBH
Use Case Name Memeriksa Barang
Unique Use Case ID UC-29
Primary Actor Kepala gudang, Staff Gudang
Secondary Actor -
Brief Description User memeriksa di dalam database sistem untuk mengetahui
informasi tentang CBH
Preconditions Informasi CBH telah berada di dalam sistem
Flow Of Events 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 User telah memeriksa CBH
Priority High
Alternative Flow and
Exceptions
User dapat memerintahkan sistem untuk mencetak CBH yang
diperiksa
Non Behavioral N/A
127
Requirements
Assumptions N/A
Issues N/A
Tabel 3.37 Base Use Case Description untuk Memeriksa CBH
Use Case Memeriksa Nota Retur Cabang
Staf Gudang Kepala Gudang
Memeriksa NotaRetur Cabang
Use Case Name Memeriksa Nota Retur Cabang
Unique Use Case ID UC-30
Primary Actor Kepala gudang, Staff Gudang
Secondary Actor -
Brief Description User memeriksa di dalam database sistem untuk mengetahui
informasi tentang Nota Retur Cabang
Preconditions Informasi Nota Retur Cabang telah berada di dalam sistem
Flow Of Events 1. User memeriksa Nota Retur Cabang yang diinginkan
2. Sistem Informasi akan membaca dari database sistem
seluruh informasi berdasarkan pengelompokkan yang
diminta oleh User
128
3. Sistem menampilkan Nota Retur Cabang yang diminta
4. Bila diperlukan maka dapat dicetak
Post Condition User telah memeriksa Nota Retur Cabang
Priority High
Alternative Flow and
Exceptions
User dapat memerintahkan sistem untuk mencetak Nota Retur
Supplier yang diperiksa
Non Behavioral
Requirements
N/A
Assumptions N/A
Issues N/A
Tabel 3.38 Base Use Case Description untuk Memeriksa Nota Retur Cabang
Use Case Memeriksa Nota Retur Supplier
Staf Gudang Kepala Gudang
Memeriksa NotaRetur Supplier
Use Case Name Memeriksa Nota Retur Supplier
Unique Use Case ID UC-31
Primary Actor Kepala gudang, Staff Gudang
Secondary Actor -
Brief Description User memeriksa di dalam database sistem untuk mengetahui
129
informasi tentang Nota Retur Supplier
Preconditions Informasi Nota Retur Supplier telah berada di dalam sistem
Flow Of Events 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 User telah memeriksa Nota Retur Supplier
Priority High
Alternative Flow and
Exceptions
User dapat memerintahkan sistem untuk mencetak Nota Retur
Supplier yang diperiksa
Non Behavioral
Requirements
N/A
Assumptions N/A
Issues N/A
Tabel 3.39 Base Use Case Description untuk Memeriksa Nota Retur Supplier
130
Use Case Memeriksa PO
Manajer Pembelian
Memeriksa PO
Use Case Name Memeriksa PO
Unique Use Case ID UC-32
Primary Actor Manajer Pembelian
Secondary Actor -
Brief Description Manajer Pembelian memeriksa daftar PO yang ada di dalam
database sistem untuk mengetahui informasi tentang PO
Preconditions Informasi PO telah berada di dalam sistem
Flow Of Events 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 Manajer Pembelian telah memeriksa PO
Priority High
Alternative Flow and
Exceptions
N/A
Non Behavioral N/A
131
Requirements
Assumptions N/A
Issues N/A
Tabel 3.40 Base Use Case Description untuk Memeriksa PO
Use Case Memeriksa Daftar Supplier
Manajer Pembelian
Memeriksa DaftarSupplier
Use Case Name Memeriksa Daftar Supplier
Unique Use Case ID UC-33
Primary Actor Manajer Pembelian
Secondary Actor -
Brief Description Manajer Pembelian memeriksa daftar Supplier yang ada di
dalam database sistem untuk mengetahui informasi tentang
Supplier
Preconditions Informasi Supplier telah berada di dalam sistem
Flow Of Events 1. Manajer Pembelian memeriksa Supplier berdasar
pengelompokan yang ada
132
2. 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 Manajer Pembelian telah memeriksa daftar Supplier
Priority High
Alternative Flow and
Exceptions
Jika Manajer Pembelian ingin membuat List mengenai Supplier,
maka Manajer Pembelian dapat memerintahkan sistem untuk
mencetaknya
Non Behavioral
Requirements
N/A
Assumptions N/A
Issues N/A
Tabel 3.41 Base Use Case Description untuk Memeriksa Daftar Supplier
Use Case Mengubah Identitas Supplier
Manajer Pembelian
Mengubah Identitas Supplier
133
Use Case Name Mengubah Identitas Supplier
Unique Use Case ID UC-34
Primary Actor Manajer Pembelian
Secondary Actor -
Brief Description Manajer Pembelian mengubah identitas Supplier yang ada di
dalam database
Preconditions Adanya identitas Supplier yang akan diubah
Flow Of Events 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 Identitas Supplier telah terubah di sistem
Priority High
Alternative Flow and
Exceptions
Jika Manajer Pembelian belum memilih Supplier maka, data
Supplier tidak dapat diubah
Non Behavioral
Requirements
Hanya Manajer Pembelian yang bisa mengubah identitas Barang
Assumptions N/A
Issues N/A
Tabel 3.42 Base Use Case Description untuk Mengubah Identitas Supplier
134
Use Case Menyetujui PO
Manajer Pembelian
Menyetujui PO
Use Case Name Menyetujui PO
Unique Use Case ID UC-35
Primary Actor Manajer Pembelian
Secondary Actor -
Brief Description Setelah barang diterima dan sesuai pesaanan maka Manajer
Pembelian akan menyetujui PO
Preconditions Adanya PO yang akan disetujui
Flow Of Events 1. Barang diterima oleh Pihak Gudang
2. Mencocokkan Barang
3. Setelah Barang cocok, PO disetujui
Post Condition PO yang telah disetujui dalam sistem
Priority High
Alternative Flow and
Exceptions
Jika Manajer Pembelian belum memilih Barang maka, data
Barang tidak dapat diubah
Non Behavioral
Requirements
Hanya Manajer Pembelian yang bisa menyetujui PO
135
Assumptions N/A
Issues N/A
Tabel 3.43 Base Use Case Description untuk Menyetujui PO
Use Case Menyetujui SPPB
Manajer Pembelian
Menyetujui SPPB
Use Case Name Menyetujui SPPB
Unique Use Case ID UC-36
Primary Actor Manajer Pembelian
Secondary Actor -
Brief Description Manajer Pembelian akan meyetujui SPPB yang telah dibuat
apabila PO telah terbuat
Preconditions Adanya SPPB yang akan disetujui
Flow Of Events 1. Kepala Gudang membuat SPPB
2. SPPB diserahkan ke Manajer Pembelian
3. Manajer Pembelian membuat PO
4. SPPB disetujui
136
Post Condition SPPB telah disetujui
Priority High
Alternative Flow and
Exceptions
Jika PO belum dibuat maka SPPB belum bisa disetujui
Non Behavioral
Requirements
Hanya Manajer Pembelian yang bisa menyetujui SPPB
Assumptions N/A
Issues N/A
Tabel 3.44 Base Use Case Description untuk Menyetujui SPPB
Use Case Menampilkan Hasil PO
Manajer Pembelian
menampilkan hasilPO
Use Case Name Menampilkan Hasil PO
Unique Use Case ID UC-37
Primary Actor Manajer Pembelian
Secondary Actor -
Brief Description Manajer Pembelian akan melihat hasil-hasil PO yang telah
dikonversi dari SPPB
Preconditions Adanya PO yang akan ditampilkan
Flow Of Events 1. Manajer Pembelian membuat PO
137
2. Sistem akan mengkonversikan PO
3. Manajer Pembelian melihat hasil PO
Post Condition Manajer Pembelian telah melihat PO
Priority High
Alternative Flow and
Exceptions
Jika PO belum dibuat maka hasil belum bisa ditampilkan
Non Behavioral
Requirements
Hanya Manajer Pembelian yang bisa menampilkan PO
Assumptions N/A
Issues N/A
Tabel 3.44 Base Use Case Description untuk Menyetujui SPPB
3.11.6.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
138
PO dengan membaca data barang berdasarkan supplier-supplier yang dimasukkan oleh
manajer pembelian. Sistem secara otomatis menampilkan hasil PO yang akan dicetak.
PO : Purchase OrderManajer Pembelian
Membuat PO()
Supplier Rincian Pesanan PO
Memasukkan PO Header()
SPPB
Generate PO ID()
Barang
Mengecek SPPB()
Confirm_Message()
Membaca Supplier()
Memasukkan Rincian PO() Membaca Barang()
Generate SPPB Id()
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.
139
Manajer Pembelian PO : Purchase Order Rincian Pesanan PO
Generate PO Id()
Membaca PO()
Membaca Rincian Pesanaan PO()
Confirm()
SPPB
Mengecek SPPB()
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.
140
Manajer PembelianPO : Purchase Orde
Mengecek PO()
Generate PO ID()
Rincian Pesanan P
Membaca Rincian Pesanan PO()
Ubah Status()
Confirm()
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.
141
Manajer PembelianBarang
Mendaftarkan Barang()
Identitas Barang
Memasukkan Identitas Barang()
Validasi Data Barang()Confirm()
Generate Barang Id()
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.
142
Manajer Pembelian Barang
Membaca Barang()
Identitas Barang
Merubah Identitas Barang()
Validasi data Barang()Confirm()
Generate Barang Id()Confirm()
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.
143
Manajer Pembelian
Barang
Membaca Barang()
Menghapus Barang()
Confirm()
Confirm() Generate Barang Id()
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.
144
Manajer Pembelian Barang
Membaca Barang()
Memasukkan Lead Time Barang()
Generate Barang Id()
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.
145
Manajer Pembelian Barang
Membaca Barang()
Memasukkan Biaya Pemesanan()
Generate Barang Id()
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.
146
Manajer Pembelian Supplier
Mendaftarkan Supplier()
Identitas Supplier
Memasukkan Identitas Supplier()
Validasi data Supplier()Confirm()
Generate Supplier Id()
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.
147
Manajer Pembelian
Supplier
Membaca Supplier()
Menghapus Supplier()
Confirm()
Confirm() Generate Supplier Id()
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.
148
Kepala Gudang Supplier
Membaca Supplier()
Identitas Supplier
Merubah Identitas Supplier()
Validasi data Supplier()Confirm()
Generate Supplier Id()Confirm()
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.
149
Manajer PembelianSupplier
Membaca 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 StafGudang Barang
Membaca Barang()
Gambar 3.29 Sequence diagram Melihat Daftar Barang
150
14. 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()
Validasi Data Cabang()
Confirm()
Memasukkan Data Cabang()
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.
151
Kepala Gudang Cabang
Membaca Cabang()
Generate Cabang Id()
Confirm()
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.
152
Kepala GudangNota Retur Supplier
Membuat Nota Retur Supplier()
Generate Nota Retur Suppler Id()
Supplier
Membaca Supplier()
Generate Supplier Id()Confirm()
Rincian Nota Retur Supplier
Memasukkan Rincian Nota Retur Supplier()
Barang
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.
153
Kepala GudangNota retur Supplier Rincian Nota retur Supplier
Membaca Nota Retur Supplier()
Generate Nota Retur Supplier Id()Confirm()
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.
154
Kepala Gudang CBR
Membuat CBR()
Generate CBR Id()
Rincian CBR Barang
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.
155
Kepala Gudang CBR
Membaca CBR()
Generate CBR Id()Confirm()
Rincian CBR
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.
156
Kepala Gudang CBH
Membuat CBH()
Generate CBH Id()
Rincian CBH Barang
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.
157
Kepala Gudang CBH
Membaca CBH()
Rincian CBH
Generate CBH Id()
Membaca Rincian CBH()
Confirm()
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.
158
Kepala GudangSPPB
Membuat SPPB()
Generate SPPB Id()
Rincian SPPB
Memasukkan Rincian SPPB()
Barang
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.
159
Kepala GudangSPPB
Membaca SPPB()
Generate SPPB Id()
Rincian SPPB
Membaca Rincian SPPB()
Confirm()
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.
160
Kepala GudangSPPB
Membaca SPPB()
Generate SPPB Id()
Rincian SPPB
Membaca Rincian SPPB()
Confirm()
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.
161
Kepala Gudang Nota Retur Supplier
Membaca Nota Retur Supplier()
Supplier
Mengecek Supplier()
Generate Supplier Id()Confirm()
Rincian Nota Retur Supplier
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 men-
generate 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.
162
Kepala Gudang dan Staf Gudang Persediaan
Mencatat Barang Masuk()
PO
Mengecek PO()
Generate PO Id()Confirm()
Catatan Barang Masuk
Memasukkan Header Catatan Barang Masuk()
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.
163
Kepala Gudang dan Staf GudangPersediaan
Membaca Persediaan()
Supplier
Mengecek Supplier()
Generate Supplier Id()Confirm()
Catatan Barang Masuk
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.
164
Kepala Gudang dan Staf Gudang Persediaan
Mencatat Barang Keluar()
SPB
Mengecek SPB()
Generate SPB Id()Confirm()
Catatan Barang Keluar
Memasukkan Header Catatan Barang Keluar()
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.
165
Kepala Gudang dan Staf GudangPersediaan
Membaca Persediaan()
Cabang
Mengecek Cabang()
Generate Cabang Id()Confirm()
Catatan Barang Keluar
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
166
31. 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.
167
Kepala Gudang dan Staf GudangSPB
Membuat SPB()
Memasukkan SPB Header()
Generate SPB Id()
Cabang
Membaca Cabang()
Generate Cabang Id()Confirm()
Rincian SPB
Memasukkan Rincian SPB()
Barang
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.
168
Kepala Gudang
Nota Retur Cabang
Membuat Nota Retur Cabang()
Cabang
Memasukan Nota Retur Cabang Header()
Generate Nota Retur Cabag Id()
Membaca Cabang()
Generate Cabang Id()
Confirm()
Rincian Nota Retur Cabang
Memasukkan Rincian Nota Retur Cabang()
Barang
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.
169
Kepala Gudang dan Staf Gudang
Nota Retur Cabang
Membaca Nota Retur Cabang()
Cabang
Membaca Cabang()
Generate Cabang Id()Confirm()
Rincian Nota Retur Cabang
Membaca Rincian Nota Retur Cabang()
Gambar 3.50 Sequence Diagram Memeriksa Nota Retur Cabang
3.11.7 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
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
Simple Update
Memeriksa Penerimaan
Barang Masuk
Medium Read
Membuat Pengeluaran
Barang
Simple Update
Memeriksa Pengeluaran
Barang
Medium Update
Membuat Nota Retur
Supplier
Simple Update
Merubah status Nota Retur
Supplier
Simple Update
171
Memeriksa Nota Retur
Supplier
Medium Read
Membuat SPB Simple Update
Memeriksa daftar
persediaan
Simple Update
Membuat Nota Retur
Cabang
Simple Update
Memeriksa Nota Retur
Cabang
Medium Read
Menghitung ROP Simple Compute
Menghitung EOQ Simple Compute
Mencetak Laporan
Pengeluaran Barang
Medium Read
Mencetak Laporan
Penerimaan Barang
Medium Read
Mencetak Laporan Retur
Supplier
Medium Read
Mencetak Laporan Retur
Cabang
Medium Read
Mencetak PO Medium Read
Mencetak SPPB Medium Read
Mencetak SPB Medium Read
Memberi Peringatan ROP Complex Compute
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”
173
3.11.8 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.
174
Interface
window membuat PO
Kode Supplier
OK
System
No SPPB
Simpan
Lihat Hasil
Menampilkan Hasil PO
Cetak
Melakukan Query
Mencetak PO
Confirmation window
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.
175
Interface System
window memeriksa PO
No PO
Melakukan Query
menampilkandaftar PO
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.
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.
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.
178
window memeriksa barang
interface system
memasukkan criteria
Melakukan Querymenampilkan barang yangdiplih berdasar criteria diminta
Cetak LaporanBarang
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.
179
window mendaftarkan supplier
InterfaceSystem
Nama Supplier
OK
Alamat
Kota
No Telp
Simpan DataSupplier
No. Fax
Kd Barang
Harga Barang
decline
confirmation window
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.
180
window menghapus supplierInterface
Kd Cabang
Menampilkan data supplier
Hapus
System
Menghapus DataSupplier
confirmation window
OK
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.
181
window memeriksa daftarsupplier
interface system
memasukkan criteria
Melakukan Querymenampilkan daftar supplieryang diplih berdasar criteria
diminta
Cetak LaporanDaftar 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.
182
window merubah identitassupplier
Interface
kd supplier
menampilkan data supplier
ubah menurut criteria
System
Mengubah IdentitasSupplier
confirmation window
OK
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.
183
window mendaftarkan barang
InterfaceSystem
Nama Barang
OK
confirmation windowSatuan
Gruop Barang
ROP
Simpan Data Barang
EOQ
decline
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.
184
window menghapus databarang
Interface
kd barang
menampilkan data barang
hapus
System
Menghapus DataBarang
confirmation window
OK
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.
185
window merubah identitasbarang
Interface
kd barang
menampilkan data barang
ubah menurut criteria
System
Mengubah IdentitasBarang
confirmation window
OK
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.
186
window mendaftarkan cabang
Interface System
Kd Cabang
Nama Cabang
OK
decline
Alamat
Kota
No Telp
No Fax
Simpan
Simpan Cabang
confirmation window
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.
187
window menutup cabangInterface
Kd Cabang
Menampilkan data Cabang
Hapus
System
Menghapus DataCabang
confirmation window
OK
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.
188
Interface
Windows Membuat NotaRetur Supplier
kd barang
kd supplier
Jumlah
No Nota ReturSupplier
confirm window
OK
System
Decline
Simpan Nota Retur Supplier
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.
189
Systemwindow menyetujui Nota
Retur Supplier
No NotaRetur
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.
190
Interface
window buat CBR
Kd Barang
Nm Barang
Qty
confirm window
OK
System
Decline
Simpan danCetak CBR
No 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.
191
Interface
window buat CBH
Kd Barang
Nm Barang
Qty
confirm window
OK
System
Decline
Simpan danCetak CBH
No 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.
192
Interface
window buat SPPB
Kd Barang
Nm Barang
Qty
confirm window
OK
System
Decline
Simpan danCetak SPPB
No 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.
193
window memeriksa PengeluaranBarang
interface system
Melakukan Querydecline
Cetak LaporanPengeluaran
Barang
bulan
tahunOK
confirmation window
menampilkan daftar PengeluaranBarang
menurut criteria
kd cabang
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.
194
window memeriksa PenerimaanBarang Masuk
interface system
Melakukan Querydecline
Cetak LaporanPenerimaan
Barang Masuk
bulan
tahunOK
confirmation window
menampilkan daftarPenerimaan Barang Masuk
menurut criteria
kd cabang
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.
195
window memeriksa CBR
interface system
Melakukan Querydecline
Cetak LaporanCBR
bulan
tahunOK
confirmation window
menampilkan CBRmenurut criteria
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.
196
window memeriksa SPPB
interface system
Melakukan Querydecline
Cetak LaporanSPPB
bulan
tahunOK
confirmation window
menampilkan SPPBmenurut criteria
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.
197
window memeriksa NotaRetur Cabang
interface system
Melakukan Querydecline
Cetak LaporanNota Retur
Cabang
bulan
tahunOK
confirmation window
menampilkan Nota Retur Cabang
menurut criteria
kd 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.
198
window memeriksa CBH
interface system
Melakukan Querydecline
Cetak LaporanCBH
bulan
tahun
OK
confirmation window
menampilkan daftarCBH
menurut criteria
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.
199
SystemInterface
window mengingatkan reorderbarang
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.
200
window memeriksa NotaRetur Supplier
interface system
kd supplier
Melakukan Querydecline
Cetak LaporanNota Retur
Supplier
bulan
tahun OK
confirmation window
menampilkan daftarNota Retur Supplier
menurut criteria
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.
201
Interface
window membuat penerimaanbarang masuk confirmation window
System
No PO
Simpan
OK
decline
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.
202
Interface
window membuat pengeluaranbarang confirmation window
System
No SPB
Simpan
OK
decline
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.
203
Interface
Windows Membuat NotaRetur Cabang
kd barang
Jumlah
No Nota ReturCabang
confirm window
OK
System
DeclineSimpan Nota Retur Cabang
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.
204
window menghitung ROP
masukkan lead time
masukkan jumlahpermintaan pertahun
jumlah hari kerja pertahun
Interface System
calculateROP
menampilkanROP
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.
205
window menghitung EOQ
masukkan biaya pemesanan
masukkan jumlahpermintaan pertahun
masukkan biaya penyimpananpertahun
Interface System
calculateEOQ
menampilkanEOQ
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.
206
memasukkan kriteria
Interface System
window memeriksa daftarpersediaan
Melakukan Query
menampilkan persediaan
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.
207
memasukkan kriteria
Interface System
window memeriksa daftarcabang
Melakukan Query
menampilkan daftarcabangprint
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.
208
SystemInterface
window menampilkan barangyang mencapai ROP
membuat SPPB
Membuka WindowMembuatSPPB
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.
SystemInterface
window menampilkan hasilPO
OK
Melakukan Query
menampilkan hasil PO
Gambar 3.86 Interface Menampilkan Hasil PO
209
37. 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
window membuat SPB confirmation window
System
Simpan
OK
decline
kd cabang
kd barang
Qty
Gambar 3.87 Interface Membuat SPB
Berikut adalah Navigation Diagram dari rancangan layar :
210
Menu Mendaftarkan barang
Mendaftarkanbarang
Hitung ROPBarang
Hitung EOQBarang
Tombol Hitung ROP
Tombol Ok/Keluar
Tombol HitungEOQ
Tombol Ok/Keluar
Tombol Keluar
Merubah IdentitasBarang Menu Merubah Identitas
Barang
Tombol Keluar
Menghapus BarangMenu Menghapus
Barang
Tombol Keluar
Tombol Hitung EOQ
Tombol Ok/Keluar
Tombol Hitung ROPTombol Ok/Keluar
Memeriksa BarangMenu Memeriksa Barang
Tombol Keluar Mendaftarkan Cabang
Men
u M
enda
ftark
an C
aban
g
Tom
bol K
elua
r
Men
u M
engh
apus
Cab
ang
Menghapus Cabang
Tom
bol K
elua
r
Memeriksa Cabang
Men
u M
emer
iksa
Cab
ang
Tom
bol K
elua
r
Membuat ReturCabang
Men
u M
embu
at
Ret
ur C
aban
g
Tom
bol K
elua
r
Men
u m
emer
iksa
Ret
ur
Cab
ang
Memeriksa Retur Cabang
Tom
bol K
elua
r
Men
u M
enda
ftark
an S
upplier
Tom
bol K
elua
r
Men
u M
erub
ah Id
entitas
Sup
plier
Mendaftarkan Supplier
Merubah IdentitasSupplier
Menghapus Supplier
Tom
bol K
elua
r
Menu Menghapus Supplier
Tombol Keluar
Memeriksa SupplierTombol KeluarMenu Memeriksa Supplier
Membuat Retur Supplier
Menu Membuat ReturSupplier
Tombol Keluar
Tombol Keluar
Menu Menyetujui ReturSupplier
Menyetujui Retur Supplier
Menu Memeriksa Retur Supplier
Tombol Keluar
Membuat Penerimaan Brg
Menu Membuat PenerimaanBrg
Tombol Keluar
Memeriksa Penerimaan Brg
Membuat Pengeluaran Brg
Brg Mencapai ROP
Membuat SPPB
MemeriksaPengeluaran Brg
Membuat CBRMemeriksa Persediaan Membuat SPB
Membuat PO
Menu Memeriksa Penerimaan Brg
Tombol Keluar
Tombol Keluar
Tombol K
eluar
Menu Membuat Pengeluaran Brg
Rem
inde
r ROP
Tombol Ok
Tombol Buat SPPB
Menu MemeriksaPengeluaran Brg
Tom
bol K
elua
r
Men
u M
embu
at C
BR
Tom
bol K
elua
r
Mem
buat
PO
Tom
bol K
elua
r
Tom
bol H
asil PO
Hasil PO
Menu Membuat SPB Tom
bol K
elua
r
Tom
bol K
elua
r
Gambar Navigation Diagram untuk Sistem Informasi Persediaan dan Pembelian PT Noorumi Catur Manunggal (Mbok Berek)
51
51
Berikut ini merupakan tampilan layar (user interface) dari sistem yang
diusulkan:
Gambar 3.88 Menu Window
52
52
Gambar 3.89 Menu Barang
53
53
Gambar 3.90 Window Mendaftarkan Barang
54
54
Gambar 3.91 Window Perhitungan ROP
Gambar 3.92 Window Perhitungan EOQ
55
55
Gambar 3.93 Window Konfirmasi Mendaftarkan Barang
Gambar 3.94 Window Merubah Identitas Barang
56
56
Gambar 3.95 Window Menghapus Identitas Barang
57
57
Gambar 3.96 Window Memeriksa Daftar Barang
58
58
Gambar 3.97 Window Menu Cabang
Gambar 3.98 Window Mendaftarkan Cabang
59
59
Gambar 3.99 Window Menghapus Identitas Cabang
Gambar 3.100 Window Memeriksa Cabang
60
60
Gambar 3.101 Window Membuat Nota Retur Cabang
61
61
Gambar 3.102 Window Memeriksa Nota Retur Cabang
Gambar 3.103 Window Menu Supplier
62
62
Gambar 3.104 Window Mendaftarkan Supplier
63
63
Gambar 3.105 Merubah Identitas Supplier
64
64
Gambar 3.106 Window Menghapus Identitas Supplier
65
65
Gambar 3.107 Window Memeriksa Daftar Supplier
66
66
Gambar 3.108 Membuat Nota Retur Supplier
67
67
Gambar 3.109 Window Menyetujui Nota Retur Supplier
68
68
Gambar 3.110 Window Memeriksa Nota Retur Supplier
Gambar 3.111 Window Menu Persediaan
69
69
Gambar 3.112 Window Membuat Penerimaan Barang Masuk
Gambar 3.113 Window Memeriksa Penerimaan Barang Masuk
70
70
Gambar 3.114 Window Membuat Pengeluaran Barang
71
71
Gambar 3.115 Window Konfirmasi Pengeluaran Barang Telah Selesai
Gambar 3.117 Reminder Terjadi Barang ROP
Gambar 3.118 Window Barang yang Mencapai ROP
72
72
Gambar 3.119 Membuat Surat Permohonan Pembelian Barang
Gambar 3.120 Window Memeriksa Pengeluaran Barang
73
73
Gambar 3.121 Window Membuat Catatan Barang Rusak
74
74
Gambar 3.122 Window Memeriksa Catatan Barang Rusak
Gambar 3.123 Window Membuat Catatan Barang Hilang
75
75
Gambar 3.124 Window Memeriksa Catatan Barang Hilang
76
76
Gambar 3.125 Window Memeriksa Persediaan
Gambar 3.126 Window Memeriksa Surat Permohonan Barang (SPPB)
77
77
Gambar 3.127 Window Membuat Surat Permintaan Barang (SPB)
Gambar 3.128 Window Menu Pembelian
78
78
Gambar 3.129 Window Mennyetujui Surat Permohonan Pembelian Barang
Gambar 3.130 Membuat Purchase Order (PO)
79
79
Gambar 3.134 Window Hasil PO
Gambar 3.115 Window konfirmasi pengeluaran barang telah selesai
Gambar Window massage error
80
80
Gambar 3.131 Window Menyetujui Purchase Order (PO)
Gambar 3.132 Window Memeriksa Purchase Order (PO)
81
81
Gambar 3.133 Window Validasi Data Belum Lengkap Terisi