BAB 4 RANCANGAN SISTEM YANG DIUSULKAN. berjalan di PT PPLi maka dibutuhkan sebuah sistem baru berbasis web yang

Transkripsi

1 BAB 4 RANCANGAN SISTEM YANG DIUSULKAN 4.1 Usulan Prosedur yang Baru Setelah dilakukan analisis terhadap prosedur pengadaan barang yang sedang berjalan di PT PPLi maka dibutuhkan sebuah sistem baru berbasis web yang terintegrasi. Sistem yang diusulkan diharapkan mampu menangani prosedur pengadaan barang dengan cepat dan real-time serta mampu mengatasi masalahmasalah yang terjadi dalam proses pengadaan barang terutama proses persetujuan pengadaan barang yang dapat dilakukan melalui . Dengan sistem yang diusulkan ini, seluruh karyawan dapat mengajukan barang yang dibutuhkan melalui web dan dapat melihat status dari permintaan barang yang diajukan. Permintaan pengadaan barang yang diajukan secara otomatis akan diteruskan ke karyawan yang berwenang memberikan persetujuan agar dapat diproses lebih lanjut. Proses persetujuan tersebut dalam dilakukan secara langsung melalui web atau melalui bila karyawan yang dimintai persetujuan tersebut sedang berada di luar kantor. 4.2 Perancangan Proses Perancangan proses yang diterapkan untuk sistem pengadaan barang yang diusulkan pada PT PPLi menggunakan use case diagram, activity diagram, dan sequence diagram. 62

2 Use case diagram Berikut adalah use case diagram yang digunakan untuk sistem pengadaan barang pada PT PPLi: Gambar 4.1 Use case diagram sistem pengadaan barang pada PT PPLi

3 Use case specification Use case specification yang diterapkan pada sistem pengadaan barang pada PPLi, yaitu : 1. Use case specification Request PR Requestor merupakan pelaku yang terlibat melakukan permintaan pengadaan barang. Pada proses ini requestor akan memasukkan nama project, jika ada project yang mempengaruhi pembuatan Purchase Requisition (PR) yang diminta. Selain itu requestor juga akan memasukkan nama barang yang akan diminta serta sejumlah kebutuhan-kebutuhan lainnya. Tabel 4.1 Use Case Specification Request PR Pelaku Deskripsi Tujuan Bidang khas suatu event Requestor Requestor melakukan permintaan pengadaan barang Requestor mendapat barang setelah disetujui oleh pihak-pihak yang berwenang dan terlibat. Kegiatan Requestor Respon Sistem 1. Membuka halaman PR 2. Sistem respon dengan menampilkan halaman PR 3. Requestor menambahkan project 4. Sistem menampilkan pop-up yang terlibat dalam PR daftar project 5. Requestor menambahkan barang 6. Sistem menampilkan pop-up yang diminta dalam PR daftar barang 7. Requestor mengisi data-data lain 8. Sistem menyimpan data PR sesuai dengan kebutuhan, kemudian dan mengirim notifikasi menekan tombol process ke Department Head untuk memeriksa kembali PR

4 65 2. Use case specification Acknowledge PR Setelah requestor melakukan permintaan pengadaan barang maka Departement Head dari requestor tersebut akan melakukan persetujuan untuk PR. Tabel 4.2 Use Case Specification Acknowledge PR Pelaku Deskripsi Tujuan Bidang khas suatu event Department Head Department Head melakukan persetujuan terhadap permintaan barang pada departemen tempat dia bekerja Menyetujui PR agar dapat dilanjutkan ke tahap berikutnya Kegiatan Department Head Respon Sistem 1. Membuka halaman PR 2. Sistem merespon dengan mengembalikan halaman PR 3. Department Head menentukan 4. Sistem menyimpan status status persetujuan untuk PR persetujuan untuk PR. Jika disetujui maka sistem akan mengirim notifikasi ke Purchasing Department 3. Use case specification Verify PR Setelah PR disetujui oleh Department Head maka akan dilanjutkan dengan persetujuan dari Purchasing Department. Pada proses ini, Purchasing Department juga menentukan apakah PR ini harus disetujui lagi oleh Related Department atau tidak.

5 66 Tabel 4.3 Use Case Specification Verify PR Pelaku Deskripsi Tujuan Bidang khas suatu event Purchasing Department Purchasing Department melakukan verifikasi terhadap permintaan barang dan menentukan apakah permintaan tersebut harus diverifikasi lagi oleh Related Department Memverifikasi PR agar dapat dilanjutkan ke tahap berikutnya Kegiatan Purchasing Department Respon Sistem 1. Membuka halaman PR 2. Sistem merespon dengan menampilkan halaman PR 3. Purchasing Department memilih 4. Sistem menampilkan form apakah PR perlu diverifikasi oleh verifikasi oleh Related Related Department Department 5. Purchasing Department menentukan status persetujuan untuk PR 6. Sistem menyimpan status persetujuan untuk PR. Jika disetujui, maka sistem akan mengirim notifikasi ke Related Department. Jika diamend maka sistem akan mengirim notifikasi ke Department Head untuk memeriksa kembali PR tersebut. 4. Use case specification Insert Quotation Purchasing Department akan memasukkan data-data penawaran (quotation) yang diberikan oleh supplier. Tabel 4.4 Use Case Specification Insert Quotation Pelaku Deskripsi Tujuan Bidang khas suatu event Purchasing Department Purchasing Department memasukkan data-data penawaran dari supplier Penawaran dari supplier dapat dilihat oleh pihak yang berwenang dan pemilihan supplier dapat dilakukan Kegiatan Purchasing Department Respon Sistem 1. Membuka halaman PR 2. Sistem merespon dengan menampilkan halaman PR 3. Purchasing Department 4. Sistem menampilkan pop-up menambahkan quotation Add Quotation 5. Purchasing Department 6. Sistem menyimpan data memasukkan data-data quotation yang quotation. diberikan oleh supplier

6 67 5. Use case specification Verify PR by Related Department (Optional) Setelah PR disetujui oleh Purchasing Department dan memerlukan persetujuan dari Related Department maka akan dilanjutkan dengan persetujuan dari Related Department. Tabel 4.5 Use Case Specification Verify PR by Related Department (Optional) Pelaku Deskripsi Tujuan Bidang khas suatu event Related Department Related Department melakukan verifikasi bahwa barang yang diminta dapat diteruskan Memverifikasi PR agar dapat dilanjutkan ke tahap berikutnya Kegiatan Related Department Respon Sistem 1. Membuka halaman PR 2. Sistem merespon dengan menampilkan halaman PR 3. Related Department menentukan 4. Sistem menyimpan status status persetujuan untuk PR persetujuan untuk PR. Jika disetujui maka sistem akan mengirim notifikasi ke Department Head. 6. Use case specification Select Recommended Quotation Setelah Purchasing Department memasukkan quotation yang diterima dari supplier maka Department Head akan memilih quotation yang direkomendasikan untuk PR.

7 68 Tabel 4.6 Use Case Specification Select Recommended Quotation Pelaku Deskripsi Tujuan Bidang khas suatu event Department Head Pemilihan quotation yang direkomendasikan untuk PR Department Head dapat merekomendasikan quotation untuk PR Kegiatan Department Head Respon Sistem 1. Membuka halaman PR 2. Sistem merespon dengan menampilkan halaman PR 3. Department Head memilih 4. Sistem menyimpan hasil quotation yang direkomendasikan pemilihan quotation dan untuk PR beserta dengan status status persetujuannya. Jika persetujuannya disetujui maka sistem akan mengirim notifikasi ke Finance Controller. 7. Use case specification Approve PR (Level 1) Setelah Department Head melakukan persetujuan dengan memilih quotation yang direkomendasikan, maka Finance Controller akan menentukan quotation yang dipilih untuk PR. Tabel 4.7 Use Case Specification Approve PR (Level 1) Pelaku Deskripsi Tujuan Bidang khas suatu event Finance Controller Penentuan quotation yang dipilih untuk PR Finance Controller dapat menentukan quotation yang dipilih untuk PR Kegiatan Finance Controller Respond Sistem 1. Membuka halaman PR 2. Sistem merespon dengan menampilkan halaman PR 3. Finance Controller menentukan 4. Sistem menyimpan hasil quotation yang dipilih untuk PR pemilihan quotation dan beserta dengan status status persetujuannya. Jika persetujuannya disetujui maka sistem akan mengirim notifikasi ke General Manager. Jika di-amend maka sistem akan mengirim notifikasi ke Department Head untuk memeriksa kembali PR tersebut.

8 69 8. Use case specification Approve PR (Level 2) Setelah Finance Controller menentukan quotation yang dipilih maka General Manager akan melakukan persetujuan untuk PR. Tabel 4.8 Use Case Specification Approve PR (Level 2) Pelaku Deskripsi Tujuan Bidang khas suatu event General Manager Persetujuan PR pada tingkat General Manager General Manager dapat melakukan persetujuan untuk PR Kegiatan General Manager Respond Sistem 1. Membuka halaman PR 2. Sistem merespon dengan menampilkan halaman PR 3. General Manager menentukan 4. Sistem menyimpan status status persetujuan untuk PR persetujuan untuk PR. Jika disetujui maka sistem akan mengirim notifikasi ke President Director. Jika di-amend maka sistem akan mengirim notifikasi ke Department Head untuk memeriksa kembali PR tersebut. 9. Use case specification Approve PR (Level 3) Setelah PR disetujui oleh General Manager maka akan dilanjutkan dengan persetujuan dari President Director.

9 70 Tabel 4.9 Use Case Specification Approve PR (Level 3) Pelaku Deskripsi Tujuan Bidang khas suatu event President Director Persetujuan PR pada tingkat President Director President Director dapat melakukan persetujuan untuk PR Kegiatan President Director Respond Sistem 1. Membuka halaman PR 2. Sistem merespon dengan menampilkan halaman PR 3. President Director menentukan 4. Sistem menyimpan status status persetujuan untuk PR persetujuan untuk PR. Jika disetujui maka sistem akan melakukan pengecekan jumlah total biaya yang dikeluarkan untuk PR apakah perlu disetujui oleh CEO atau tidak. Jika perlu persetujuan dari CEO maka sistem akan mengirim notifikasi ke CEO. Jika memerlukan persetujuan dari CEO maka status dari PR akan diubah menjadi Approved dan mengirimkan notifikasi ke Purchasing Department. Jika PR di-amend maka sistem akan mengirim notifikasi e- mail ke Department Head untuk memeriksa kembali PR tersebut. 10. Use case specification Approve PR (Level 4) PR yang membutuhkan biaya yang sangat besar harus mendapatkan persetujuan dari CEO.

10 71 Tabel 4.10 Use Case Specification Approve PR (Level 4) Pelaku Deskripsi Tujuan Bidang khas suatu event CEO Persetujuan PR pada tingkat CEO CEO dapat melakukan persetujuan untuk PR Kegiatan CEO Respon Sistem 1. Membuka halaman PR 2. Sistem merespon dengan menampilkan halaman PR 3. CEO menentukan status 4. Sistem menyimpan status persetujuan untuk PR persetujuan untuk PR. Jika disetujui maka maka status dari PR akan diubah menjadi Approved dan mengirimkan notifikasi ke Purchasing Department. Jika di-amend maka sistem akan mengirim notifikasi ke Department Head untuk memeriksa kembali PR tersebut. 11. Use case specification Finalize Approved PR PR yang telah selesai disetujui dapat diproses lebih lanjut untuk dibuatkan Purchase Order (PO). Tabel 4.11 Use Case Specification Finalize Approved PR Pelaku Deskripsi Tujuan Bidang khas suatu event Purchasing Department Pengubahan status PR yang telah disetujui Purchasing Department dapat mengubah status PR yang telah disetujui untuk dibuatkan PO Kegiatan Purchasing Department Respon Sistem 1. Membuka halaman PR yang telah 2. Sistem merespon dengan disetujui menampilkan halaman PR 3. Purchasing Deparment menekan tombol Create PO yang telah disetujui 4. Sistem akan mengubah status PR menjadi PO Created.

11 Use case specification Process Setiap 2 menit Timer akan memicu engine untuk berjalan dan memproses e- mail yang ada dengan melakukan parsing lalu mengecek tersebut. Hal tersebut akan diteruskan dengan pemrosesan data yang diterima ke database. Tabel 4.12 Use Case Specification Process Pelaku Deskripsi Tujuan Bidang khas suatu event Timer Timer memproses yang ada di mail server melalui perantara Microsoft Office Outlook 2003 Memproses agar dapat melakukan persetujuan dan melanjutkan ke tahap berikutnya Kegiatan Timer Respon Sistem 1. Timer memicu engine berjalan 2. Sistem mengambil data dari Outlook yang telah terintegrasi dengan mail server lalu dilakukan pemecahan data yang diterima (parsing). Setelah dilakukan pengecekan terhadap data yang telah di-parse, dan apabila hasil parse sesuai maka sistem akan menyimpan perubahan data ke database lalu akan mengirim notifikasi selanjutnya. Namun apabila hasil parse tidak sesuai maka sistem akan mengirim notifikasi yang menginformasikan kesalahan dan meminta user untuk mengirim kembali dalam format yang benar.

12 Activity Diagram Activity Diagram yang diusulkan pada sistem pengadaan barangan pada PPLi, yaitu : 1. Activity Diagram Request PR Proses ini terjadi pada saat requestor ingin melakukan permintaan pengadaan barang. Requestor akan membuka halaman PR dan sistem akan menampilkan tampilan dari halaman PR tersebut. Requestor akan memasukkan data project apabila ada project yang menyebabkan dibuatnya PR tersebut, dan akan memasukkan barang-barang yang akan diminta. Setelah requestor menekan tombol Process, maka sistem akan menyimpan data tersebut ke database. Gambar 4.2 Activity Diagram Request PR

13 74 2. Activity Diagram Acknowledge PR Proses ini terjadi saat Department Head ingin membuka halaman PR untuk PR yang ingin ditentukan persetujuannya. Department Head dapat menetukan status persetujuan dan komentar untuk PR tersebut. Jika disetujui, maka sistem akan mengatur agar PR diteruskan ke Purchasing Department untuk disetujui dan notifikasi akan dikirimkan. Status persetujuan yang dipilih akan di-update ke database. Gambar 4.3 Activity Diagram Acknowledge PR

14 75 3. Activity Diagram Verify PR Proses ini terjadi saat Purchasing Department ingin membuka halaman PR untuk PR yang ingin ditentukan persetujuannya. Purchasing Department akan menentukan apakah PR perlu disetujui terlebih dahulu oleh Related Department, selain itu Purchasing Department juga akan menetukan status approval dan memberikan komentar atas PR tersebut. Jika disetujui dan diperlukan persetujuan dari Related Department maka sistem akan mengatur agar PR diteruskan ke Related Department untuk disetujui, jika disetujui dan tidak diperlukan persetujuan dari Related Department maka sistem akan mengatur agar PR diteruskan ke Finance Controller untuk disetujui. Lalu notifikasi akan dikirimkan sesuai dengan hasil verifikasi dari Purchasing Department. Jika di-amend, maka PR akan dikembalikan ke Department Head untuk diperiksa kembali berupa notifikasi . Status persetujuan yang dipilih akan di-update ke database.

15 76 Gambar 4.4 Activity Diagram Verify PR 4. Activity Diagram Insert Quotation Proses ini dilakukan oleh Purchasing Department untuk memasukkan datadata penawaran (quotation) dari supplier. Pada proses ini Purchasing Department akan membuka halaman PR lalu sistem akan mengembalikan tampilan halaman yang diminta. Purchasing Department lalu akan

16 77 memasukkan data-data dari quotation yang didapat dari supplier. Setelah Purchasing Department menekan tombol Submit, maka sistem akan menyimpan data tersebut ke database. Gambar 4.5 Activity Diagram Insert Quotation 5. Activity Diagram Verify PR by Related Department (Optional) Proses ini terjadi saat Related Department ingin membuka halaman PR untuk PR yang ingin ditentukan persetujuannya. Related Department dapat menentukan status persetujuan dan komentar untuk PR tersebut. Jika disetujui, maka sistem akan mengatur agar PR dikembalikan ke Department Head untuk dilakukan pemilihan supplier dan notifikasi akan dikirimkan. Status persetujuan yang dipilih akan di-update ke database.

17 78 Gambar 4.6 Activity Diagram Verify PR by Related Department (Optional) 6. Activity Diagram Select Recommended Quotation Proses ini terjadi pada saat Department Head ingin membuka halaman PR untuk PR yang ingin ditentukan persetujuan dan quotation yang direkomendasikan. Department Head dapat memilih quotation yang direkomendasikan untuk PR tersebut dan menentukan status persetujuan beserta dengan komentarnya. Jika disetujui, maka PR akan diteruskan ke Finance Controller untuk disetujui dan mengirim notifikasi . Status persetujuan yang dipilih akan di-update ke database.

18 79 Gambar 4.7 Activity Diagram Select Recommended Quotation 7. Activity Diagram Approve PR (Level 1) Proses ini terjadi pada saat Finance Controller ingin membuka halaman PR untuk PR yang ingin ditentukan persetujuan dan quotation yang terpilih. Finance Controller dapat memilih quotation yang terpilih untuk PR tersebut dan menentukan status persetujuan beserta dengan komentarnya. Jika disetujui, maka PR akan diteruskan ke General Manager untuk disetujui dan mengirim notifikasi . Jika di-amend maka PR akan dikembalikan ke Department Head untuk diperiksa kembali dan mengirim

19 80 notifikasi . Status persetujuan yang dipilih akan di-update ke database. Gambar 4.8 Activity Diagram Approve PR (Level 1) 8. Activity Diagram Approve PR (Level 2) Proses ini terjadi pada saat General Manger ingin membuka halaman PR untuk PR yang ingin ditentukan persetujuannya. General Manager dapat menentukan status persetujuan dan komentar untuk PR tersebut. Jika disetujui, maka PR akan diteruskan ke President Director untuk disetujui

20 81 dan mengirim notifikasi . Jika di-amend maka PR akan dikembalikan ke Department Head untuk diperiksa kembali dan mengirim notifikasi e- mail. Status persetujuan yang dipilih akan di-update ke database. Gambar 4.9 Activity Diagram Approve PR (Level 2) 9. Activity Diagram Approve PR (Level 3) Proses ini terjadi pada saat President Director ingin membuka halaman PR untuk PR yang ingin ditentukan persetujuannya. President Director dapat menentukan status persetujuan dan komentar untuk PR tersebut. Jika disetujui, maka sistem akan melakukan pengecekan pada total biaya dari

21 82 quotation yang dipilih apakah PR tersebut membutuhkan persetujuan dari CEO atau tidak. Jika membutuhkan persetujuan dari CEO, maka PR akan diteruskan ke CEO untuk disetujui dan mengirim notifikasi . Jika tidak maka status PR akan di-update menjadi Approved. Jika status persetujuan yang dipilih adalah amend maka PR akan dikembalikan ke Department Head untuk diperiksa kembali dan mengirim notifikasi . Status persetujuan yang dipilih akan di-update ke database. Gambar 4.10 Activity Diagram Approve PR (Level 3)

22 Activity Diagram Approve PR (Level 4) Proses ini terjadi pada saat CEO ingin membuka halaman PR untuk PR yang ingin ditentukan persetujuannya. CEO dapat menentukan status persetujuan dan komentar untuk PR tersebut. Jika disetujui, maka status PR akan di-update menjadi Approved dan mengirim notifikasi ke Purchasing Department. Jika di-amend maka PR akan dikembalikan ke Department Head untuk diperiksa kembali dan mengirim notifikasi . Status persetujuan yang dipilih akan di-update ke database. CEO Sistem membuka halaman PR menampilkan halaman PR memilih status persetujuan memeriksa status persetujuan Reject Approve update status PR Amend mengembalikan PR ke Department Head mengirim notifikasi update status persetujuan Gambar 4.11 Activity Diagram Approve PR (Level 4)

23 Activity Diagram Finalize Approved PR Proses ini terjadi pada saat Purchasing Department ingin membuka halaman PR untuk PR yang telah disetujui untuk diubah statusnya. Purchasing Department dapat mengklik tombol Create PO untuk mengubah status PR menjadi PO Created. Gambar 4.12 Activity Diagram Finalize Approved PR 12. Activity Diagram Process Proses ini terjadi setiap 2 menit, dimana Timer akan memicu engine untuk berjalan. Engine yang berjalan akan mengambil data yang belum dibaca dari Microsoft Office Outlook yang telah diitegrasikan dengan e- mail server yang dimiliki perusahaan. Setelah data diambil, maka akan dilakukan parsing untuk pengambilan informasi dari yang diterima. Setelah dilakukan parsing, akan dilakukan pemeriksaan apakah format e- mail telah benar dan sesuai. Bila tidak sesuai, maka dikirimkan notifikasi

24 85 pemberitahuan kesalahan lewat . Jika benar maka akan dilakukan perubahan pada database dan pengecekan Approval terhadap proses persetujuan yang ada pada perusahaan. Jika Approval tersebut masih membutuhkan persetujuan dari pihak berikutnya, maka akan ditambahkan lagi data Approval ke database lalu notifikasi dikirimkan kembali pada pihak yang terlibat pada proses persetujuan berikutnya. Gambar 4.13 Activity Diagram Process

25 Sequence Diagram Sequence Diagram yang diusulkan pada sistem pengadaan barang pada PPLi, yaitu : 1. Sequence Diagram Request PR Pada saat requestor ingin melakukan permintaan pengadaan barang, create() akan menampilkan halaman PR. Apabila PR ini dibuat karena ada project yang terlibat, choose_project() dilakukan bila requestor akan menginput data project. Pada saat memilih project, maka open() akan menampilkan pop-up project. get_data_project() akan mengambil seluruh data project dan result() akan mengembalikan hasilnya ke pop-up project. Lalu result() akan mengembalikan hasil pemilihan di pop-up project ke tampilan pada halaman PR. Setelah menentukan project yang terlibat, maka requestor juga akan memilih barang-barang yang diperlukan, chose_item() akan menampilkan pop-up barang. get_data_item() akan mengambil seluruh data barang dan result() akan mengembalikan hasilnya ke pop-up barang. Apabila seluruh data telah dimasukkan dengan tepat, maka insert_pr() akan memasukkan seluruh data ke database. Lalu result() akan mengembalikan hasil ke halaman PR.

26 87 Gambar 4.14 Sequence Diagram Request PR 2. Sequence Diagram Acknowledge PR Pada saat Department Head ingin melakukan acknowledge terhadap PR maka create() akan menampilkan halaman PR. get_data_pr() akan mengambil data PR yang ada di dalam database kemudian result() akan mengembalikan data PR tersebut ke halaman PR. Department Head lalu dapat menentukan status persetujuan (choose_status_approval()). Bila Department Head mengklik tombol Submit maka click_submit() akan memproses PR tersebut dan update_approval() akan mengubah status persetujuan sesuai dengan yang dipilih. Bila PR disetujui maka

27 88 insert_approval() akan membuat approval baru untuk Purchasing Department dan send_mail() akan mengirim notifikasi . update_track_no_and_status_pr() akan meng-update data track_no dan PR dari status persetujuan yang dipilih lalu result() akan menampilkan hasil perubahannya pada halaman PR. Gambar 4.15 Sequence Diagram Acknowledge PR

28 89 3. Sequence Diagram Verify PR Pada saat Purchasing Department ingin melakukan verifikasi terhadap PR maka create() akan menampilkan halaman PR. get_data_pr() akan mengambil data PR yang ada di dalam database kemudian result() akan mengembalikan data PR tersebut ke halaman PR. Purchasing Department akan menentukan apakah diperlukan verifikasi dari Related Department. Apabila diperlukan verifikasi dari Related Department, maka verify_pr() akan melakukan get_data_relateddepartment() yang akan diambil dari datadata karyawan yang merupakan Related Department yang dipilih. Dan result() akan mengembalikan tampilan dari data-data karyawan yang masuk kedalam Related Department. Purchasing Department lalu dapat menentukan status persetujuan (choose_status_approval()). Bila Department Head mengklik tombol Submit maka click_submit() akan memproses PR tersebut dan update_approval() akan mengubah status persetujuan sesuai dengan yang dipilih. Bila PR disetujui dan diperlukan verifikasi oleh Related Department maka insert_approval() akan membuat approval baru untuk Related Department dan send_mail() akan mengirim notifikasi . Bila PR disetujui dan tidak diperlukan verifikasi oleh Related Department maka insert_approval() akan membuat approval baru untuk Finance Controller dan send_mail() akan mengirim notifikasi , lalu PR akan dikembalikan ke Department Head untuk dimintai Recommended Quotation. Bila PR diamend maka insert_approval() akan membuat approval baru untuk Department Head untuk memeriksa kembali PR tersebut dan send_mail()

29 90 akan mengirim notifikasi . update_track_no_and_status_pr() akan meng-update data track_no dan PR dari status persetujuan yang dipilih lalu result() akan menampilkan hasil perubahannya pada halaman PR. Gambar 4.16 Sequence Diagram Verify PR

30 91 4. Sequence Diagram Insert Quotation Pada saat Purchasing Department melakukan Insert Quotation, create() akan menampilkan halaman PR. get_data_pr() akan mengambil data PR yang ada di dalam database kemudian result() akan mengembalikan data PR tersebut ke halaman PR. insert_data_quotation() digunakan untuk memasukkan data-data dari quotation yang diberikan oleh supplier. open() akan menampilkan pop-up quotation, get_data_supplier() akan mengambil data dari database kemudian result() akan mengembelikan hasil ke pop-up quotation. Setelah pop-up diisi, maka result() akan mengembalikan hasil ke halaman PR. insert_quotation() akan memasukkan data quotation ke dalam database. lalu result() akan menampilkan hasil perubahannya pada halaman PR.

31 92 Purchasing Department Halaman PR pop-up Quotation Supplier PR Quotation create() get_data_pr() result() insert_data_quotation() open() get_data_supplier() result() result() insert_quotation() result() Gambar 4.17 Sequence Diagram Insert Quotation 5. Sequence Diagram Verify PR by Related Department (Optional) Pada saat Related Department ingin melakukan verifikasi terhadap PR maka create() akan menampilkan halaman PR. get_data_pr() akan mengambil data PR yang ada di dalam database kemudian result() akan mengembalikan data PR tersebut ke halaman PR. Department Head lalu dapat menentukan status persetujuan (choose_status_approval()). Bila Department Head mengklik tombol Submit maka click_submit() akan memproses PR tersebut dan update_approval() akan mengubah status persetujuan sesuai dengan yang dipilih. Bila PR disetujui maka insert_approval() akan membuat

32 93 approval baru untuk Purchasing Department dan send_mail() akan mengirim notifikasi . update_track_no_and_status_pr() akan mengupdate data track_no dan PR dari status persetujuan yang dipilih lalu result() akan menampilkan hasil perubahannya pada halaman PR. Gambar 4.18 Sequence Diagram Verify PR by Related Department (Optional) 6. Sequence Diagram Select Recommended Quotation Pada saat Department Head ingin menentukan persetujuan dan quotation yang direkomendasikan maka create() akan menampilkan halaman_pr. Get_data_PR() akan mengambil data PR yang ada di dalam database

33 94 kemudian result() akan mengembalikan data PR tersebut ke dalam halaman_pr. Department Head dapat memilih quotation untuk dijadikan rekomendasi (choose_recommended_quotation()) dan menentukan status persetujuan (choose_status_approval()). Bila Department Head mengklik tombol Submit maka click_submit() akan memproses PR tersebut dan update_approval() akan mengubah status persetujuan sesuai dengan yang dipilih. Bila PR disetujui maka insert_approval() akan membuat approval baru untuk Finance Controller dan send_mail() akan mengirim notifikasi e- mail. update_pr() akan meng-update data PR dari status persetujuan yang dipilih lalu result() akan menampilkan hasil perubahannya pada halaman_pr.

34 95 Gambar 4.19 Sequence Diagram Select Recommended Quotation 7. Sequence Diagram Approve PR (Level 1) Pada saat Finance Controller ingin menentukan persetujuan dan quotation yang dipilih maka create() akan menampilkan halaman_pr. Get_data_PR() akan mengambil data PR yang ada di dalam database kemudian result() akan mengembalikan data PR tersebut ke dalam halaman_pr. Finance Controller dapat memilih quotation yang terpilih (choose_selected_quotation()) dan

35 96 menentukan status persetujuan (choose_status_approval()). Bila Finance Controller mengklik tombol Submit maka click_submit() akan memproses PR tersebut dan update_approval() akan mengubah status persetujuan sesuai dengan yang dipilih. Bila PR disetujui maka insert_approval() akan membuat approval baru untuk General Manager dan send_mail() akan mengirim notifikasi . Bila PR di-amend maka insert_approval() akan membuat approval baru untuk Department Head untuk memeriksa kembali PR tersebut dan send_mail() akan mengirim notifikasi . Update_PR() akan meng-update data PR dari status persetujuan yang dipilih lalu result() akan menampilkan hasil perubahannya pada halaman_pr.

36 97 Halaman_PR Approval PR Finance Controller create() get_data_pr() result() choose_selected_quotation() choose_status_approval() click_submit() update_approval() If (approved or amended) insert_approval() send_ () update_pr() result() Gambar 4.20 Sequence Diagram Approve PR (Level 1) 8. Sequence Diagram Approve PR (Level 2) Pada saat General Manager ingin menentukan persetujuan dari PR maka create() akan menampilkan halaman_pr. Get_data_PR() akan mengambil data PR yang ada di dalam database kemudian result() akan mengembalikan data PR tersebut ke dalam halaman_pr. General Manager dapat menentukan status persetujuan (choose_status_approval()). Bila General

37 98 Manager mengklik tombol Submit maka click_submit() akan memproses PR tersebut dan update_approval() akan mengubah status persetujuan sesuai dengan yang dipilih. Bila PR disetujui maka insert_approval() akan membuat approval baru untuk President Director dan send_mail() akan mengirim notifikasi . Bila PR di-amend maka insert_approval() akan membuat approval baru untuk Department Head untuk memeriksa kembali PR tersebut dan send_mail() akan mengirim notifikasi . update_track_no_and_status_pr() akan meng-update track_no dan status PR dari status persetujuan yang dipilih lalu result() akan menampilkan hasil perubahannya pada halaman_pr.

38 99 Gambar 4.21 Sequence Diagram Approve PR (Level 2) 9. Sequence Diagram Approve PR (Level 3) Pada saat President Director ingin menentukan persetujuan dari PR maka create() akan menampilkan halaman_pr. Get_data_PR() akan mengambil data PR yang ada di dalam database kemudian result() akan mengembalikan data PR tersebut ke dalam halaman_pr. President Director dapat menentukan status persetujuan (choose_status_approval()). Bila President

39 100 Director mengklik tombol Submit maka click_submit() akan memproses PR tersebut dan update_approval() akan mengubah status persetujuan sesuai dengan yang dipilih. Bila PR disetujui maka check_total_cost() akan memeriksa jumlah total biaya yang diperlukan untuk PR tersebut. Bila PR tersebut membutuhkan persetujuan dari CEO maka insert_approval() akan membuat approval baru untuk CEO dan send_mail() akan mengirim notifikasi . Bila PR di-amend maka insert_approval() akan membuat approval baru untuk Department Head untuk memeriksa kembali PR tersebut dan send_mail() akan mengirim notifikasi . update_track_no_and_status_pr() akan meng-update track_no dan status PR dari status persetujuan yang dipilih lalu result() akan menampilkan hasil perubahannya pada halaman_pr.

40 101 Gambar 4.22 Sequence Diagram Approve PR (Level 3) 10. Sequence Diagram Approve PR (Level 4) Pada saat CEO ingin menentukan persetujuan dari PR maka create() akan menampilkan halaman_pr. Get_data_PR() akan mengambil data PR yang ada di dalam database kemudian result() akan mengembalikan data PR tersebut ke dalam halaman_pr. CEO dapat menentukan status persetujuan (choose_status_approval()). Bila CEO mengklik tombol

41 102 Submit maka click_submit() akan memproses PR tersebut dan update_approval() akan mengubah status persetujuan sesuai dengan yang dipilih. Bila PR disetujui maka send_mail() akan mengirim notifikasi e- mail ke Purchasing Department. Bila PR di-amend maka insert_approval() akan membuat approval baru untuk Department Head untuk memeriksa kembali PR tersebut dan send_mail() akan mengirim notifikasi . update_track_no_and_status_pr() akan meng-update track_no dan status PR dari status persetujuan yang dipilih lalu result() akan menampilkan hasil perubahannya pada halaman_pr.

42 103 Gambar 4.23 Sequence Diagram Approve PR (Level 4) 11. Sequence Diagram Finalize Approved PR Pada saat Purchasing Department ingin memproses PR yang telah selesai disetujui maka create() akan menampilkan halaman_pr. get_data_pr() akan mengambil data PR yang ada di dalam database kemudian result() akan mengembalikan data PR tersebut ke dalam halaman_pr. Bila Purchasing Department mengklik tombol Create PO maka click_create_po() akan

43 104 memproses PR tersebut dan update_status_pr() akan mengubah status PR menjadi PO Created lalu result() akan menampilkan hasil perubahannya pada halaman_pr. Gambar 4.24 Sequence Diagram Finalize Approve PR 12. Sequence Diagram Process Setiap 2 menit Timer dengan trigger() akan memicu engine untuk berjalan. read_unread_ () akan membaca yang belum dibaca di server melalui Microsoft Office Outlook kemudian result() akan mengembalikan yang ada. Setelah diterima, maka parsing() akan mengambil data yang diinginkan dari yang diterima. Setelah itu get_data_approval() akan mengambil data Approval untuk mengecek apakah

44 105 Approval ID yang dikirim melalui ada pada database kemudian result() akan mengembalikan hasilnya. Jika tidak ada pada database atau formatnya salah, maka send_notification() akan mengirimkan yang memberitahukan kesalahan yang terjadi. Apabila tidak terdapat kesalahan maka get_data_pr() akan mengambil data PR dari database dan result() akan mengembalikan hasilnya. check_approval() akan memeriksa keadaan dan proses yang harus dijalankan pada Approval tersebut. update_approval() akan mengubah Status Approval dan Comment pada Approval tersebut dan update_pr() akan mengubah Track yang merupakan keadaan PR saat ini. Apabila PR memerlukan persetujuan dari pihak berikutnya, get_data_employee() akan mengambil data karyawan yang terlibat pada proses berikutnya dari database lalu result() akan mengembalikan hasilnya. insert_new_approval() akan memasukkan persetujuan baru yang harus disetujui oleh pihak yang terlibat berikutnya. send_notification() akan mengirimkan notifikasi ke karyawan yang terlibat pada proses persetujuan berikutnya.

45 106 Timer Engine Outlook PR Approval Employee trigger() read_unread_ () result() parsing() get_data_approval() result() If not exists/ wrong format send_notification() get_data_pr() result() check_approval() update_pr() update_approval() get_data_employee() If (need next Approval) insert_new_approval() result() send_notification() Gambar 4.25 Sequence Diagram Process

46 Perancangan Basis Data Perancangan basis data untuk sistem pengadaan barang yang diusulkan pada PT PPLi menggunakan 3 tahap, antara lain: 1. Perancangan basis data konseptual (conceptual database design) 2. Perancangan basis data logikal (logical database design) 3. Perancangan basis data fisikal (physical database design) Perancangan Basis Data Konseptual Perancangan basis data konseptual merupakan proses membangun model informasi yang digunakan dalam sebuah perusahaan, terbebas dari semua pertimbangan fisik. Langkah-langkah dalam perancangan basis data konseptual meliputi: 1. Mengidentifikasi tipe entity 2. Mengidentifikasi tipe relationship 3. Mengidentifikasi dan menghubungkan atribut dengan entity atau tipe relationship 4. Menentukan domain atribut 5. Menentukan atribut candidate key dan primary key 6. Mempertimbangkan konsep pemodelan enhanced (optional)

47 Memeriksa model dari redundansi 8. Validasi model konseptual lokal terhadap transaksi user 9. Meninjau ulang model data konseptual terhadap user Mengidentifikasi Tipe Entity Berdasarkan hasil pemeriksaaan spesifikasi kebutuhan perusahaan maka dapat diidentifikasi tipe-tipe entity yang utama dibutuhkan oleh PT PPLi dengan rincian sebagai berikut: Tabel 4.13 Tipe entity Nama Entity Deskripsi Alias Occurance Employee Department Position Secara umum menjelaskan mengenai semua karyawan yang bekerja pada perusahaan Secara umum menjelaskan mengenai semua departemen yang ada di perusahaan Secara umum menjelaskan mengenai semua posisi karyawan yang ada di dalam departemen perusahaan Karyawan Departemen Jabatan Setiap karyawan bekerja pada 1 departemen tertentu dan menempati 1 posisi tertentu di bawah departemen tersebut. Terdapat beberapa karyawan yang membawahi karyawan lain. Setiap karyawan dapat membuat permintaan pembelian barang yang diajukan kepada kepala departemen masing-masing dan karyawan yang berwenang dapat menyetujui atau menolak permintaan pembelian barang tersebut Setiap departemen mengurusi bagiannya masing-masing dan bertanggung jawab terhadap pekerjaannya Setiap posisi mendeskripsikan kedudukan dari tiap karyawan yang bekerja di perusahaan

48 109 Nama Entity Deskripsi Alias Occurance Approval PR Item Quotation Supplier Project Secara umum menjelaskan mengenai persetujuan dari PR Secara umum menjelaskan mengenai surat permintaan pembelian barang Secara umum menjelaskan mengenai semua barang yang akan dipakai pada proses bisnis perusahaan Secara umum menjelaskan deskripsi dan harga barang dari supplier Secara umum menjelaskan mengenai semua supplier yang bertransaksi dengan perusahaan Secara umum menjelaskan project yang terlibat dalam pembuatan purchase requisition Persetujuan Purchase Requisition (Permintaan Pembelian) Barang Quotation Pemasok Project Merupakan identitas seleksi dari PR yang diajukan dan diseleksi oleh karyawan yang berwenang Setiap PR berisi daftar barang yang akan dibeli. PR harus disetujui oleh karyawan yang berwenang untuk dapat diproses. Setiap barang yang dibutuhkan oleh karyawan Setiap quotation berasal dari satu supplier Setiap pemasok menawarkan barang dengan kualitas atau harga yang berbeda Setiap project yang membutuhkan barangbarang tertentu Mengidentifikasi Tipe Relationship Tujuan dari langkah ini adalah mengidentifikasikan semua relationship penting di antara tipe entity yang telah diidentifikasi sebelumnya. Berikut adalah tipe relationship yang diidentifikasikan dari semua entity yang ada: Tabel 4.14 Tipe relationship Nama Entity Multiplicity Relationship Nama Entity Multiplicity Employee 1..1 requests PR 0..* 1..* has Position creates Approval 0..* 0..1 supervises Employee 0..* Department 1..1 has Employee 1..* PR 1..1 has Approval 1..* 1..* has Item 1..5

49 110 Nama Entity Multiplicity Relationship Nama Entity Multiplicity 1..1 has Quotation * created for Project 0..1 Quotation 1..* has Item 1..* Supplier 1..1 sends Quotation 1..* 1..* supplies Item 1..* Gambar 4.26 Diagram ER menunjukkan entity dan tipe relationship Mengidentifikasi dan Menghubungkan Atribut dengan Entity atau Tipe Relationship Berikut adalah atribut-atribut yang berhubungan dengan entity atau tipe relationship yang ada:

50 111 Tabel 4.15 Identifikasi atribut dengan entity Nama Entity Atribut Deskripsi Panjang dan Tipe Data Employee EmployeeID Secara unik VARCHAR mengidentifikasi (10) seorang karyawan dari perusahaan FirstName Nama depan dari VARCHAR karyawan (20) LastName Nama belakang dari VARCHAR karyawan (20) Title Kata sapaan dari VARCHAR karyawaan (10) Employee Alamat yang VARCHAR digunakan oleh (30) karyawan WinUser Username yang digunakan oleh karyawan untuk login ke Windows Department DepartmentID Secara unik mengidentifikasi sebuah departemen yang ada di perusahaan DepartmentName Nama departemen yang ada di perusahaan Position PositionID Secara unik mengidentifikasi jabatan seorang karyawan di perusahaan PositionName Nama jabatan dari seorang karyawan Approval ApprovalID Secara unik mengidentifikasi persetujuan yang dilakukan oleh karyawan yang berwenang memberikan persetujuan StatusApp Status dari persetujuan yang dilakukan oleh karyawan VARCHAR (25) VARCHAR (10) VARCHAR (30) VARCHAR (10) VARCHAR (30) UNIQUEIDE NTIFIER VARCHAR (10) Null Yes Comment Komentar dari VARCHAR Yes Multi- Valued

51 112 Nama Entity Atribut Deskripsi Panjang dan Tipe Data Null karyawan yang (50) memberikan persetujuan DateApp Tanggal dari DATETIME persetujuan yang dilakukan INT IDENTITY PR PRID Secara unik menjelaskan purchase requsition yang dibuat oleh karyawan DatePR RefPO CostCenter Acct RefWO te VerifiedRelDept SelectedQuotation RecommendedQuot ation Tanggal pembuatan purchase requisition mor dari purchase order yang menjadi referensi dari purchase requsition Deskripsi dari cost center mor account atau rekening Nama work order yang terlibat dalam pembuatan purchase requisition Deskripsi dari nomor Catatan untuk purchase requisition tersebut Status kebutuhan verifikasi dari Related Department Quotation yang dipilih untuk purchase requisition Quotation yang direkomendasikan oleh Department Head untuk purchase requisition DATETIME VARCHAR (50) VARCHAR (50) VARCHAR (50) VARCHAR (50) VARCHAR (50) VARCHAR (50) VARCHAR (5) VARCHAR (10) VARCHAR (10) Yes Yes Yes Yes Yes Yes Track Menerangkan INT Multi- Valued

52 113 Nama Entity Atribut Deskripsi Panjang dan Tipe Data keberadaan proses purchase requisition StatusPR Status dari VARCHAR purchase (20) requisition Item ItemID Secara unik menjelaskan barang-barang yang ada VARCHAR (10) Part mor part dari sebuah barang VARCHAR (10) ItemName Nama dari barang VARCHAR (30) Description Deskripsi dari VARCHAR barang yang (50) diminta oleh karyawan Quotation QuotationID Secara unik menjelaskan quotation yang diterima dari supplier TermOfPayment PathAttachment Cara pembayaran digunakan oleh supplier Lokasi tempat disimpannya attachment FileAttachment Nama file dari attachment Supplier SupplierID Secara unik menjelaskan supplier yang digunakan oleh perusahaan CompanyName SupplierPhone ContactPersonName ContactPerson ContactPersonPhone Nama dari perusahaan supplier mor telepon dari supplier Nama dari contact person supplier Alamat dari contact person supplier mor telepon dari contact person VARCHAR (10) VARCHAR (50) VARCHAR (50) VARCHAR (30) VARCHAR (10) VARCHAR (30) VARCHAR (50) VARCHAR (30) VARCHAR (30) VARCHAR (50) Null Yes Yes Multi- Valued Yes Yes Yes Yes Yes

53 114 Nama Entity Atribut Deskripsi Panjang dan Tipe Data supplier ContactPersonExt Extension dari VARCHAR contact person (25) supplier ContactPersonHP mor handphone dari contact person supplier Project ProjectID Secara unik menjelaskan project yang terlibat dalam pembuatan purchase requisition VARCHAR (50) VARCHAR (10) ProjectName Nama dari project VARCHAR (50) Location Tempat lokasi VARCHAR pengerjaan dari (30) project Duration Lamanya durasi dari project VARCHAR (20) Null Yes Yes Multi- Valued Yes Yes Menentukan Domain Atribut Domain atribut merupakan batasan nilai yang valid bagi atribut. Berikut adalah domain atribut yang terdapat pada setiap entity: Tabel 4.16 Identifikasi domain atribut Nama Entity Atribut Deskripsi Domain Atribut Employee EmployeeID Secara unik mengidentifikasi seorang karyawan dari perusahaan String dengan panjang karakter 10, harus diawali dengan EMP dan diikuti dengan angka dari 0-9 sebanyak 7 digit. Format: EMP[0-9][0-9][0-9][0-9][0-9][0-9][0-9] FirstName Nama depan dari karyawan String dengan panjang karakter maksimal 20 LastName Nama belakang dari String dengan panjang Title karyawan Kata sapaan dari karyawaan karakter maksimal 20 String dengan panjang karakter maksimal 10

54 115 Nama Entity Atribut Deskripsi Domain Atribut Employee Alamat yang digunakan oleh karyawan String dengan panjang karakter maksimal 30. Harus mengandung WinUser Username yang digunakan oleh karyawan untuk login ke Windows Department DepartmentID Secara unik mengidentifikasi sebuah departemen yang ada di perusahaan DepartmentName Nama departemen yang ada di perusahaan Position PositionID Secara unik mengidentifikasi jabatan seorang karyawan di perusahaan PositionName Nama jabatan dari seorang karyawan Approval ApprovalID Secara unik mengidentifikasi persetujuan yang dilakukan oleh karyawan yang berwenang memberikan persetujuan StatusApp Status dari persetujuan yang dilakukan oleh karyawan Comment Komentar dari karyawan yang memberikan persetujuan DateApp Tanggal dari persetujuan yang dilakukan PR PRID Secara unik menjelaskan purchase requisition yang dibuat oleh dan. String dengan panjang karakter maksimal 25 String dengan panjang karakter 10, harus diawali dengan DEP dan diikuti dengan angka dari 0-9 sebanyak 7 digit. Format: DEP[0-9][0-9][0-9][0-9][0-9][0-9][0-9] String dengan panjang karakter maksimal 30 String dengan panjang karakter 10, harus diawali dengan POS dan diikuti dengan angka dari 0-9 sebanyak 7 digit. Format: POS[0-9][0-9][0-9][0-9][0-9][0-9][0-9] String dengan panjang karakter maksimal 30 Berupa kode unik dari hasil generate tipe data UNIQUEIDENTIFIER String dengan panjang karakter maksimal 10. Status persetujuan terdiri dari: pending, approve, amend dan reject String dengan panjang karakter 50 Tanggal dengan format ddmm-yyyy Angka yang selalu bertambah (INT IDENTITY)

55 116 Nama Entity Atribut Deskripsi Domain Atribut karyawan DatePR Tanggal pembuatan purchase requisition Tanggal dengan format ddmm-yyyy RefPO mor dari purchase order yang menjadi String dengan panjang karakter 50 referensi dari purchase requsition CostCenter Deskripsi dari cost center String dengan panjang karakter 50 Acct mor account atau String dengan panjang RefWO rekening Nama work order yang terlibat dalam pembuatan purchase requisition karakter 50 String dengan panjang karakter 50 Deskripsi dari nomor String dengan panjang karakter maksimal 50 te Catatan untuk purchase requisition tersebut String dengan panjang karakter maksimal 50 VerifiedRelDept Status kebutuhan verifikasi dari Related Department SelectedQuotation RecommendedQuot ation Track Quotation yang dipilih untuk purchase requisition Quotation yang direkomendasikan oleh Department Head untuk purchase requisition Menerangkan keberadaan proses purchase requisition String dengan panjang karakter maksimal 5. Status kebutuhan verifikasi dari Related Department terdiri dari: -, yes dan no String dengan panjang karakter maksimal 10. Status quotation yang dipilih berisi - atau QuotationID String dengan panjang karakter maksimal 10. Status quotation yang dipilih berisi - atau QuotationID Angka antara 1-11 yang merepresentasikan nomor untuk status proses purchase requisition 1 berada di user, purchase order baru dibuat 2 berada di user, dikembalikan oleh Purchasing Department 3 berada di Department Head untuk diacknowledge 4 berada di Purchasing Department

56 117 Nama Entity Atribut Deskripsi Domain Atribut 5 berada di Related Department 6 berada di Department Head agar dapat dipilih recommended quotation 7 berada di Department Head dikarenakan purchase request berubah status menjadi amend 8 berada di Finance Controller 9 berada di General Manager 10 berada di President Director 11 berada di CEO StatusPR Status dari purchase requisition Item ItemID Secara unik menjelaskan barang-barang yang ada String dengan panjang karakter maksimal 20. Status purchase requisition terdiri dari: pending, on process, approved, PO created dan rejected String dengan panjang karakter 10, harus diawali dengan ITM dan diikuti dengan angka dari 0-9 sebanyak 7 digit. Format: ITM[0-9][0-9][0-9][0-9][0-9][0-9][0-9] Part mor part dari sebuah barang String dengan panjang karakter maksimal 10 ItemName Nama dari barang String dengan panjang karakter maksimal 30 Description Deskripsi dari barang yang diminta oleh karyawan String dengan panjang karakter maksimal 50 Quotation QuotationID Secara unik menjelaskan quotation yang diterima dari supplier String dengan panjang karakter 10, harus diawali dengan QUO dan diikuti dengan angka dari 0-9 sebanyak 7 digit. Format: QUO[0-9][0-9][0-9][0-9][0-9][0-9][0-9] TermOfPayment Cara pembayaran digunakan oleh supplier String dengan panjang karakter maksimal 50 PathAttachment Lokasi tempat String dengan panjang

57 118 Nama Entity Atribut Deskripsi Domain Atribut disimpannya attachment karakter 50 FileAttachment Nama file dari String dengan panjang attachment karakter 30 Supplier SupplierID Secara unik menjelaskan supplier yang yang digunakan oleh perusahaan String dengan panjang karakter 10, harus diawali dengan SUP dan diikuti dengan angka dari 0-9 sebanyak 7 digit. Format: SUP[0-9][0-9][0-9][0-9][0-9][0-9][0-9] CompanyName Nama dari perusahaan supplier String dengan panjang karakter maksimal 30 SupplierPhone mor telepon dari supplier String dengan panjang karakter maksimal 50 ContactPersonNam Nama dari contact String dengan panjang e ContactPersonEmai l person supplier Alamat dari contact person supplier ContactPersonPhon e mor telepon dari contact person supplier ContactPersonExt Extension dari contact person supplier ContactPersonHP mor handphone dari contact person supplier Project ProjectID Secara unik menjelaskan project yang terlibat dalam pembuatan purchase requisition karakter maksimal 30 String dengan panjang karakter maksimal 30. Harus mengandung dan. String dengan panjang karakter maksimal 50 String dengan panjang karakter maksimal 25 String dengan panjang karakter maksimal 50 String dengan panjang karakter maksimal 10, harus diawali dengan PRO dan diikuti dengan angka dari 0-9 sebanyak 7 digit. Format: PRO[0-9][0-9][0-9][0-9][0-9][0-9][0-9] ProjectName Nama dari project String dengan panjang Location Duration Tempat lokasi pengerjaan dari project Lamanya durasi dari project karakter maksimal 50 String dengan panjang karakter maksimal 30 String dengan panjang karakter maksimal 20

58 Menentukan Atribut Candidate Key dan Primary Key Berikut adalah atribut-atribut yang menjadi candidate key dari semua atribut yang ada serta atribut yang menjadi primary key dan alternate key dari kumpulan atribut candidate key tersebut: Tabel 4.17 Candidate key dan primary key dari entity Nama Entity Candidate Key Primary Key Alternate Key Employee EmployeeID Employee EmployeeID Employee WinUser WinUser Department DepartmentID DepartmentID DepartmentName DepartmentName Position PositionID PositionID PositionName PositionName Approval ApprovalID ApprovalID - PR PRID PRID - Item ItemID ItemID ItemName ItemName Quotation QuotationID QuotationID - Supplier SupplierID SupplierID CompanyName CompanyName Project ProjectID ProjectID Gambar 4.27 Diagram ER dengan primary key

59 Mempertimbangkan Konsep Pemodelan Enhanced Pada tahap ini terdapat entity dengan konsep pemodelan enhanced yaitu spesialisasi pada entity Employee dalam relationship supervises. Gambar 4.28 Diagram ER dengan konsep pemodelan enhanced Memeriksa Model dari Redundansi Pada tahap ini tidak ditemukan adanya redundansi pada model data setelah dilakukan pemeriksaan terhadap relationship one-to-one (1:1) dan relationship yang redundan Validasi Model Konseptual Lokal terhadap Transaksi User Tahap ini bertujuan untuk memastikan model data konseptual mendukung semua transaksi yang akan dilakukan. Transaksi yang ada antara lain:

60 121 Data Entry, Update, Delete - Menambah, mengubah, menghapus data Employee - Menambah, mengubah, menghapus data Position - Menambah, mengubah, menghapus data Department - Menambah, mengubah, menghapus data Item - Menambah, mengubah, menghapus data Supplier - Menambah, mengubah, menghapus data Project - Menambah, mengubah, menghapus data PR - Menambah, mengubah data Approval - Menambah, mengubah, menghapus data Quotation Data Query a. Melihat PR yang diajukan oleh Employee b. Melihat Department dari Employee c. Melihat Position dari Employee d. Melihat Supervisor dari Employee e. Melihat Project yang dimiliki PR f. Melihat Item yang terdapat di PR

61 122 g. Melihat Supplier yang dapat menyediakan Item h. Melihat Quotation yang dimiliki oleh PR i. Melihat Item yang terdapat di Quotation j. Melihat Supplier yang terdapat di Quotation k. Melihat Approval yang dimiliki oleh PR l. Melihat Approval yang dilakukan oleh Employee Gambar 4.29 Model konseptual yang mendukung transaksi user Meninjau Ulang Model Data Konseptual terhadap User Langkah selanjutnya yang dilakukan sebelum menyelesaikan tahap perancangan basis data konseptual adalah meninjau ulang model data

62 123 konseptual lokal dengan user. Model data konseptual yang dibuat sudah sesuai dan dapat memenuhi semua transaksi yang ada Model Data Web Konseptual Gambar 4.30 Model data web konseptual (ER)

63 124 PPLi Gambar 4.31 Model data web konseptual (ER) dengan link dan concept box dari PPLi Perancangan Basis Data Logikal Tahap selanjutnya dalam perancangan basis data adalah merancang basis data logikal. Perancangan basis data logikal merupakan proses pembuatan sebuah model dari informasi yang digunakan perusahaan dalam sebuah model data spesifik dan terbebas dari DBMS tertentu serta pertimbangan fisik lainnya.

64 125 Langkah-langkah dalam perancangan basis data logikal meliputi: 1. Membangun dan memvalidasi model data logikal lokal untuk setiap view a. Menghilangkan fitur yang tidak kompatibel dengan model relasional (optional) b. Menurunkan relasi untuk model data logikal lokal c. Memvalidasi relasi menggunakan normalisasi d. Memvalidasi relasi terhadap transaksi user e. Mendefinisikan integrity constraints f. Meninjau ulang model data logikal lokal dengan user. 2. Membangun dan memvalidasi model data logikal global Menghilangkan Fitur yang Tidak Kompatibel dengan Model Relasional Tujuan dari langkah ini adalah menyaring atau memperhalus model data konseptual lokal dengan menghilangkan fitur yang tidak kompatibel dengan model relasional. 1. Menghilangkan tipe relationship binary many-to-many (*:*) Setiap relationship many-to-many (*:*) yang terdapat pada model data konseptual harus dihilangkan dengan membuat intermediate entity.

65 126 Relationship many-to-many antara entity PR dengan Item Gambar 4.32 Relationship many-to-many antara entity PR dengan Item Gambar 4.33 Relationship antara entity PR dan Item setelah decomposing Relationship many-to-many antara entity Supplier dengan Item Gambar 4.34 Relationship many-to-many antara entity Supplier dengan Item

66 127 Gambar 4.35 Relationship antara entity Supplier dan Item setelah decomposing Relationship many-to-many antara entity Quotation dengan Item Gambar 4.36 Relationship many-to-many antara entity Quotation dengan Item Gambar 4.37 Relationship antara entity Quotation dengan Item setelah decomposing 2. Menghilangkan tipe relationship rekursif many-to-many (*:*) Pada tahap ini tidak ditemukan tipe relationship rekursif many-tomany pada model data konseptual.

67 Menghilangkan tipe relationship kompleks Pada tahap ini tidak ditemukan tipe relationship kompleks pada model data konseptual. 4. Menghilangkan atribut multi-value Menghilangkan atribut multi-value pada entity Supplier Gambar 4.38 Entity Supplier dengan atribut multi-value Gambar 4.39 Entity Supplier setelah decomposing dengan memunculkan entity ContactPerson

68 129 Menghilangkan atribut multi-value pada entity Quotation Gambar 4.40 Entity Quotation dengan atribut multi-value Gambar 4.41 Entity Quotation setelah decomposing dengan memunculkan entity QuotationAttachment Menurunkan Relasi untuk Model Data Logikal Lokal Tujuan langkah ini adalah membuat model data logikal lokal untuk merepresentasikan entities, relationships dan atribut-atribut yang telah didefinisikan sebelumnya. Dalam langkah ini primary key dan foreign key ditentukan dari relasi yang ada. Relasi yang ada diturunkan dengan langkah sebagai berikut: 1. Strong entity type Strong entity type merupakan sebuah tipe entity yang keberadaannya tidak bergantung dengan tipe entity yang lain.

69 130 Tabel 4.18 Strong entity type Employee (EmployeeID, FirstName, LastName, Title, Employee , WinUser) Primary Key EmployeeID Department (DepartmentID, DepartmentName) Primary Key DepartmentID Position (PositionID, PositionName) Primary Key PositionID PR (PRID, DatePR, RefPO, CostCenter, Acct, RefWO,, te, VerifiedRelDept, SelectedQuotation, RecommendedQuotation, Track, StatusPR) Primary Key PRID Item (ItemID, Part, ItemName, Description) Primary Key ItemID Supplier (SupplierID, CompanyName, SupplierPhone) Primary Key SupplierID Approval (ApprovalID, StatusApp, Comment, DateApp) Primary Key ApprovalID Quotation (QuotationID, TermOfPayment) Primary Key QuotationID Project (ProjectID, ProjectName, Location, Duration) Primary Key ProjectID 2. Weak entity type Weak entity type sebuah tipe entity yang keberadaannya bergantung dengan tipe entity yang lain. Tabel 4.19 Weak entity type PRDetail (Description, UOMName, UnitQty, Budgeted, DeliveryDate) Primary Key untuk saat ini tidak ada QuotationDetail (CurrencyName, UnitCost, TotalCost, Description, DeliveryDate) Primary Key untuk saat ini tidak ada ItemSupplier ( ) Primary Key untuk saat ini tidak ada ContactPerson (ContactPersonName, ContactPerson , ContactPersonPhone, ContactPersonExt, ContactPersonHP) Primary Key untuk saat ini tidak ada QuoatationAttactment (PathAttachment, FileAttachment) Primary Key untuk saat ini tidak ada

70 Tipe relationship binary one-to-many (1:*) Untuk setiap relationship binary 1:*, entity yang berada pada one side dari relationship ditunjuk sebagai entity induk dan entity yang berada pada many side ditunjuk sebagai entity anak. Atribut primary key dari entity induk ditempatkan ke dalam relasi entity anak sebagai foreign key. Relationship one-to-many antara entity Position dengan Employee Entity Position sebagai entity induk dan entity Employee sebagai entity anak sehingga primary key entity Position dimasukkan ke dalam entity Employee sebagai foreign key.

71 132 Relationship one-to-many antara entity Department dengan Employee Entity Department sebagai entity induk dan entity Employee sebagai entity anak sehingga primary key entity Department dimasukkan ke dalam entity Employee sebagai foreign key. Relationship one-to-many antara entity Employee dengan Approval Entity Employee sebagai entity induk dan entity Approval sebagai entity anak sehingga primary key entity Employee dimasukkan ke dalam entity Approval sebagai foreign key.

72 133 Relationship one-to-many antara entity Employee dengan PR Entity Employee sebagai entity induk dan entity PR sebagai entity anak sehingga primary key entity Employee dimasukkan ke dalam entity PR sebagai foreign key. Relationship one-to-many antara Project dengan PR Entity Project sebagai entity induk dan entity PR sebagai entity anak sehingga primary key entity Project dimasukkan ke dalam entity PR sebagai foreign key.

73 134 Relationship one-to-many antara entity PR dengan Quotation Entity PR sebagai entity induk dan entity Quotation sebagai entity anak sehingga primary key entity PR dimasukkan ke dalam entity Quotation sebagai foreign key. Menempatkan PRID ke dalam Quotation untuk model relationship 1:* Has PR (PRID, EmployeeID, ProjectID, DatePR, RefPO, CostCenter, Acct, RefWO,, te, VerifiedRelDept, SelectedQuotation, RecommendedQuotation, Track, StatusPR) Primary Key PRID Foreign Key EmployeeID references Employee (EmployeeID) Foreign Key ProjectID references Project (ProjectID) Quotation (QuotationID, PRID, TermOfPayment, PathAttachment, FileAttachment) Primary Key QuotationID Foreign Key PRID references PR (PRID) Relationship one-to-many antara entity Supplier dengan Quotation Entity Supplier sebagai entity induk dan entity Quotation sebagai entity anak sehingga primary key entity Supplier dimasukkan ke dalam entity Quotation sebagai foreign key.

74 135 Relationship one-to-many antara entity PR dengan Approval Entity PR sebagai entity induk dan entity Approval sebagai entity anak sehingga primary key entity PR dimasukkan ke dalam entity Approval sebagai foreign key. 4. Tipe relationship binary one-to-one (1:1) Pada tahap ini tidak ditemukan adanya tipe relationship binary oneto-one (1:1) pada model data yang telah didefinisikan sebelumnya. 5. Tipe relationship rekursif one-to-one (1:1) Pada tahap ini tidak ditemukan adanya tipe relationship rekursif oneto-one (1:1) pada model data yang telah didefinisikan sebelumnya. 6. Tipe relationship superclass/subclass Pada tahap ini ditemukan adanya tipe relationship superclass/subclass pada model yang telah didefinisikan sebelumnya, yaitu pada entity Employee dan entity Supervisor. Karena superclass

75 136 Employee hanya memiliki satu subclass yaitu Supervisor maka tidak ada disjoint constraint. Dalam hal ini, sebagaimana terdapat lebih banyak Employee daripada Supervisor maka relationship ini dapat direpresentasikan sebagai sebuah relasi tunggal. 7. Tipe relationship binary many-to-many (*:*) Untuk setiap relationship binary *:* dibuat sebuah relasi untuk merepresentasikan relationship dan memasukkan atribut yang merupakan bagian dari relationship. Primary key dari entity yang saling berpartisipasi dalam relationship tersebut dimasukkan ke dalam relasi baru dan berlaku sebagai foreign key. Foreign key tersebut juga akan menjadi primary key dari relasi yang baru.

76 137 Relationship many-to-many antara entity PR dengan Item Primary key dari entity PR dan entity Item dimasukkan ke dalam entity baru yaitu PRDetail sebagai composite primary key. PR (PRID, EmployeeID, ProjectID, DatePR, RefPO, CostCenter, Acct, RefWO,, te, VerifiedRelDept, SelectedQuotation, RecommendedQuotation, Track, StatusPR) Primary Key PRID Foreign Key EmployeeID references Employee (EmployeeID) Foreign Key ProjectID references Project (ProjectID) Item (ItemID, Part, ItemName, Description) Primary Key ItemID PRDetail (PRID, ItemID, Description, UOMName, UnitQty, Budgeted, DeliveryDate) Primary Key PRID, ItemID Foreign Key PRID references PR (PRID) Foreign Key ItemID references Item (ItemID) Relationship many-to-many antara entity Item dengan Supplier Primary key dari entity Item dan entity Supplier dimasukkan ke dalam entity baru yaitu ItemSupplier sebagai composite primary key.

77 138 Relationship many-to-many antara entity Quotation dengan Item Primary key dari entity Quotation dan entity Item dimasukkan ke dalam entity baru yaitu QuotationDetail sebagai composite primary key. 8. Tipe relationship kompleks Pada tahap ini tidak ditemukan adanya tipe relationship kompleks pada model data yang telah didefinisikan sebelumnya. 9. Atribut multi-value Pembuatan relasi pada entity yang memiliki atribut multi-value adalah dengan cara memasukkan primary key dari entity tersebut ke dalam entity baru sebagai foreign key. Entity baru tersebut berisikan atribut yang multi-value.

78 139 Atribut multi-value pada entity Supplier Atribut multi-value pada entity Quotation Berikut adalah dokumentasi hasil relasi antara atribut primary key dan foreign key pada model data logikal lokal: Tabel 4.20 Dokumentasi hasil relasi antara atribut primary key dan foreign key Employee Department Position Approval Employee (EmployeeID, DepartmentID, PositionID, SupervisorEmployeeID, FirstName, LastName, Title, Employee , WinUser) Primary Key EmployeeID Foreign Key DepartmentID references Department (DepartmentID) Foreign Key PositionID references Position (PositionID) Foreign Key SupervisorEmployeeID references Employee (EmployeeID) Department (DepartmentID, DepartmentName) Primary Key DepartmentID Position (PositionID, PositionName) Primary Key PositionID Approval (ApprovalID, PRID, EmployeeID, StatusApp, Comment, DateApp) Primary Key ApprovalID Foreign Key PRID references PR (PRID)