BAB 3 ANALISA SISTEM INFORMASI 3.1Gambaran Umum …thesis.binus.ac.id/Asli/Bab3/LBM2005-48-Bab...

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


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


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


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.


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


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


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


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


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



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


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


Use Case Name Menghapus Data Supplier



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


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



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


akan menyimpan data ke dalam database sistem

Post Condition Data supplier telah ada di dalam sistem

Priority


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


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


Exceptions



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


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



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


Exceptions



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



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


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



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


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



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


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



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



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


Membuat Penerimaan Barang Masuk

106

Use Case Name Membuat Penerimaan Barang Masuk


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


Memeriksa DaftarPersediaan

Use Case Name Memeriksa Daftar Persediaan



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



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



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


Memeriksa DaftarCabang

Use Case Name Memeriksa Daftar Cabang



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


seluruh informasi yang diminta oleh Manajer Pembelian

3. Sistem menampilkan Cabang

Post Condition Pihak Gudang telah melihat data Cabang

Priority High


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



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


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



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


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



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


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



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



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


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


MengingatkanReorder Barang

Use Case Name Mengingatkan Reorder Barang



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


Memeriksa Penerimaan Barang Masuk

Use Case Name Memeriksa Penerimaan Barang Masuk


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



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


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


Memeriksa Pengeluaran Barang

121

Use Case Name Memeriksa Pengeluaran Barang



Secondary Actor -


informasi tentang Pengeluaran Barang

Preconditions Informasi Pengeluaran Barang telah berada di dalam sistem

Flow Of Events 1. User memeriksa Pengeluaran Barang yang diinginkan



diminta oleh User

3. Sistem menampilkan Pengeluaran Barang yang diminta


Post Condition User telah memeriksa Pengeluaran Barang

Priority High


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



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


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


Memeriksa SPPB

Use Case Name Memeriksa SPPB



Secondary Actor -


informasi tentang SPPB

Preconditions Informasi SPPB telah berada di dalam sistem

Flow Of Events 1. User memeriksa SPPB yang diinginkan



diminta oleh User

124

3. Sistem menampilkan SPPB yang diminta


Post Condition User telah memeriksa SPPB

Priority High


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


Memeriksa CBR




Secondary Actor -


125

informasi tentang CBR

Preconditions Informasi CBR telah berada di dalam sistem

Flow Of Events 1. User memeriksa CBR yang diinginkan



diminta oleh User

3. Sistem menampilkan CBR yang diminta


Post Condition User telah memeriksa CBR

Priority High


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


Memeriksa CBH




Secondary Actor -


informasi tentang CBH

Preconditions Informasi CBH telah berada di dalam sistem

Flow Of Events 1. User memeriksa CBH yang diinginkan



diminta oleh User

3. Sistem menampilkan CBH yang diminta


Post Condition User telah memeriksa CBH

Priority High


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


Memeriksa NotaRetur Cabang

Use Case Name Memeriksa Nota Retur Cabang



Secondary Actor -


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



diminta oleh User

128

3. Sistem menampilkan Nota Retur Cabang yang diminta


Post Condition User telah memeriksa Nota Retur Cabang

Priority High


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


Memeriksa NotaRetur Supplier

Use Case Name Memeriksa Nota Retur Supplier



Secondary Actor -


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


2.Sistem Informasi akan membaca dari database sistem


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


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



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



diminta oleh Manajer Pembelian

3. Sistem menampilkan PO yang diminta

Post Condition Manajer Pembelian telah memeriksa PO

Priority High


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



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


132



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


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



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


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



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


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



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


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



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


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


Membaca Barang()

Memasukkan Lead Time Barang()


Memasukkan Permintaan Barang per Tahun()

Memasukkan Jumlah Hari Kerja per Tahun()

Calculate ROP()

Gambar 3.23 Sequence diagram Menghitung ROP

8. Sequence diagram Menghitung EOQ

Sequence diagram Menghitung EOQ dimulai dengan membaca barang, kemudian

manajer pembelian akan memasukkan jumlah permintaan per tahun, biaya pemesanan,

dan biaya penyimpanan per tahun. Setelah itu sitem akan menghitung dan menampilkan

hasil EOQ.

145


Membaca Barang()

Memasukkan Biaya Pemesanan()


Memasukkan Permintaan Barang per Tahun()

Biaya Penyimpanan per tahun()

Calculate EOQ()

Gambar 3.24 Sequence Diagram Menghitung EOQ

9. Sequence diagram Mendaftarkan Supplier

Sequnce diagram Mendaftarkan Supplier dimulai dengan mendaftarkan suatu

supplier baru. Sistem akan memvalidasi kelengkapan data supplier. Sebelum data

supplier baru disimpan, sistem akan mengkonfirmasi terlebih dahulu.

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()


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()


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()


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()


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


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


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


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()


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()


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


Nota Retur Cabang

Membaca Nota Retur Cabang()

Cabang

Membaca Cabang()


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

print

Mencetak Daftar PO

Gambar 3.52 Interface Memeriksa PO

3. Menyetujui PO

Kegiatan dimulai dengan membuka form menyetujui PO dahulu untuk

mengubah status not approved menjadi approved. Setelah itu data yang telah

disetujui tersebut langsung disimpan di dalam database.

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

print

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


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


confirmation window

OK

Gambar 3.57 Interface Menghapus Supplier

8. Memeriksa Daftar Supplier



dimasukkan dan kemudian menampilkan Supplier sesuai Criteria. Pada saat

berada pada window Memeriksa Daftar Supplier, hasil Criteria dapat dicetak.

181

window memeriksa daftarsupplier

print

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



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


terdapat pada Window Mendaftarkan Barang. Setelah itu akan menuju Accept


dimasukkan. Setelah menyetujui maka data-data Barang telah disimpan dalam


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



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


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


terdapat pada Window Mendaftarkan Cabang. Setelah itu akan menuju Accept


dimasukkan. Setelah menyetujui maka data-data Cabang telah disimpan dalam


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


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


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

print

Cetak Nota Retur Supplier

Gambar 3.65 Interface Membuat Nota Retur Supplier

16. Menyetujui Nota Retur Supplier

Kegiatan dimulai dengan membuka form menyetujui Nota Retur Supplier

dahulu untuk mengubah status not approved menjadi approved. Setelah itu data

yang telah disetujui tersebut langsung disimpan di dalam database.

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


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




berada pada window Memeriksa Pengeluaran Barang, hasil Criteria dapat

dicetak.

193

window memeriksa PengeluaranBarang

print

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




berada pada window Memeriksa Penerimaan Barang Masuk, hasil Criteria dapat

dicetak.

194

window memeriksa PenerimaanBarang Masuk

print

interface system


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



dimasukkan dan kemudian menampilkan CBR sesuai Criteria. Pada saat berada

pada window Memeriksa CBR, hasil Criteria dapat dicetak.

195

window memeriksa CBR

print

interface system


Cetak LaporanCBR

bulan

tahunOK

confirmation window

menampilkan CBRmenurut criteria

Gambar 3.72 Interface Memeriksa CBR

23. Memeriksa SPPB



dimasukkan dan kemudian menampilkan SPPB sesuai Criteria. Pada saat berada

pada window Memeriksa SPPB, hasil Criteria dapat dicetak.

196

window memeriksa SPPB

print

interface system


Cetak LaporanSPPB

bulan

tahunOK

confirmation window

menampilkan SPPBmenurut criteria

Gambar 3.73 Interface Memeriksa SPPB

24. Memeriksa Nota Retur Cabang



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

print

interface system


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



dimasukkan dan kemudian menampilkan CBH sesuai Criteria. Pada saat berada

pada window Memeriksa CBH, hasil Criteria dapat dicetak.

198

window memeriksa CBH

print

interface system


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




berada pada window Memeriksa Pengeluaran Barang, hasil Criteria dapat

dicetak.

200

window memeriksa NotaRetur Supplier

print

interface system

kd supplier


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


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


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


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

print

Cetak Nota Retur Cabang

Gambar 3.80 Interface Membuat Nota Retur Cabang

31. Menghitung ROP

Aktivitas dimulai saat pertama kali mendaftarkan barang dan yang kedua

adalah saat merubah identitas barang. Pada kedua form tersebut dapat

dimunculkan window menghitung ROP. Dengan memasukkan variabel yang

akan dihitung untuk menghasilkan ROP. Dan ini akan menjadi attribut dari form

Barang.

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



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

print

Mencetak Daftar Persediaan

Gambar 3.83 Interface Memeriksa Daftar Persediaan

34. Memeriksa Daftar Cabang



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


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

BAB 3 ANALISA SISTEM INFORMASI 3.1Gambaran Umum …thesis.binus.ac.id/Asli/Bab3/LBM2005-48-Bab...

Documents

Transcript of BAB 3 ANALISA SISTEM INFORMASI 3.1Gambaran Umum …thesis.binus.ac.id/Asli/Bab3/LBM2005-48-Bab...