BAB 3 ANALISIS SISTEM YANG BERJALAN

(1)

ANALISIS SISTEM YANG BERJALAN

3.1 Gambaran Umum Perusahaan 3.1.1 Sejarah Perusahaan

PT. Metro Batavia mulai beroperasi pada tanggal 5 Juni 2002 dengan nama dagang Batavia-Air. Kantor Pusat PT. Metro Batavia terletak di Jl. Ir H Juanda, Jakarta Pusat. Berkapasitas tiga lantai dan ada kurang lebih 200 karyawan yang bekerja di kantor tersebut setiap harinya.

Tokoh berdirinya perusahaan ini adalah Bapak Yudiawan Tansari. Selaku Presiden Direktur beliau memulai Batavia Air dengan satu buah pesawat Fokker F28 dan dua buah Boeing 737-200. “Trust Us to Fly”, telah menjadi slogan yang meng-inspirasi para Pilot, Pramugari, dan tenaga-tenaga profesional di Batavia Air dalam memberikan pelayanan yang terbaik bagi pelanggannya.

Saat ini dengan 24 armada pesawat yang terdiri dari jenis pesawat Boeing 737-200, 737-300, 737-400, dan Airbus A318, A320. Batavia Air mengoperasikan 98 penerbangan setiap harinya dan melayani 24 kota tujuan di Indonesia, serta Guangzhou-Cina dan Kuching-Malaysia.

(2)

3.1.2 Struktur Organisasi Perusahaan

(3)

Gambar 3.2 Struktur Organisasi Purchasing Logistik

3.1.3 Tugas dan Tanggung Jawab Staff Purchasing Logistik 1. Purchase Coordinator

• Tugas Purchase Coordinator adalah menerima material request dari divisi Logistik dan membuat Request for Quotation yang akan dikirimkan ke Supplier untuk mendapatkan Quotation. Setelah Quotation dikumpulkan maka akan dijadikan tabulasi sebagai bahan keputusan untuk

Purchasing Manager menentukan Purchase Order dari

Quotation tersebut. 2. Repair Coordinator

• Tugas dari Repair Coordinator adalah membuat Work Order untuk perbaikan suatu spare part pesawat. Repair Coordinator menerima daftar suatu barang yang perlu untuk diperbaiki dari Planning Staff.

(4)

3. Purchasing Manager

• Mengkoordinasi dan mengawasi permintaan pengadaan barang dari inventory apakah barang tersebut layak untuk dibeli atau sesuai dengan budget perusahaan.

3.2 Fase Inception

3.2.1 Latar Belakang Masalah

Departemen Inventory mengirimkan Informasi Permintaan Material Yang harus dibeli (Material Request For Purchase) ke Departemen Purchasing, Staff Purchasing akan memasukan informasi tersebut kedalam Daftar Permintaan (Material Request For Purchase List). Daftar Permintaan tersebut dimasukan dan di atur secara manual kedalam table elektronik (Microsoft Excel). Daftar Permintaan tersebut di prioritaskan berdasarkan kepentingannya. Atribut kepentingan dari permintaan tersebut adalah kategori dari part (Part Category) tersebut, saat Open DMI berlaku, kuantitas dan harga. Kategori part juga menentukan lamanya barang tersebut harus di sediakan setelah waktu

Open DMI berlaku. Ada 4 kategori part yaitu A, B, C, D dan E yang menentukan lama waktu pengadaan setelah tanggal Open DMI berlaku. Kategori A harus di sediakan dalam waktu 1 hari, kategori B harus di sediakan dalam waktu 3 hari, kategori C sediakan dalam waktu 3 bulan, kategori D harus di sediakan dalam waktu 6 bulan keatas.

(5)

Setelah informasi Permintaan Material tersebut berserta atribut prioritasnya di masukan, maka data-data tersebut di analisa prioritasnya untuk menentukan jadwal dan perencanaan mengenai pembelian dari Permintaan Pembelian. Hasil perkiraan dan analisis tersebut akan digunakan untuk membuat suatu Tender tertutup. Tender dimulai ketika

Purchasing Coordinator Staff mengirimkan Request for Quotation atau permintaan harga atas suatu barang yang dibutuhkan. Request for Quotation tersebut akan dikirimkan kepada setiap Supplier yang merupakan perusahaan resmi yang memproduksi atau pihak penjualan terdekat. Setelah para Supplier menerima Request for Quotation maka setiap Supplier tersebut akan mengirimkan harga berupa penawaran harga (Quotation). Quotation merupakan penawaran harga atas suatu

Request for Quotation. Didalam Quotation terdapat informasi mengenai penawaran harga(Quoted Price), kuantitas barang yang dapat disediakan (Quantity), kondisi barang (Part Condition), dan lama pengadaan barang (Lead Time) atas barang yang tertera di Request for Quotation. Untuk harga barang ada tiga kemungkinan tipe harga yang berikan oleh

Supplier yaitu:

• Outright Price, merupakan harga barang untuk barang baru tanpa pertukaran dengan barang yang lama.

(6)

• Exchange Price, merupakan harga barang jika menukarkan dengan barang yang lama dengan tambahan ongkos perbaikan. Ongkos perbaikan biasanya diketahui setelah perbaikan dilaukan oleh Supplier.

• Flatrate Price, merupakan harga barang jika menukarkan dengan barang yang lama tanpa adanya tambahan ongkos perbaikan. Jika ongkos perbaikan yang dilakukan oleh

Supplier ternyata Beyond Economical Range maka akan dikenakan ongkos sesuai ongkos perbaikan.

Quotation tersebut akan diubah kedalam bentuk laporan sebagai bahan pengambilan keputusan atas suatu tender bagi Purchasing Manager. Laporan tersebut di buat dalam bentuk tabulasi dengan kolom berisi part atau material untuk setiap permintaan pembelian dan baris berisi Supplier, pertemuan antara baris dan kolom berisi harga, kuantitas, lama ketersediaan barang, dan pengiriman barang. Tabulasi tersebut akan di cetak dan di berikan kepada Purchasing Manager. Purchasing Manager tersebut akan menentukan Quotation manakah yang layak untuk untuk dibuat Purchase Order. Purchase Order merupakan suatu bentuk keputusan untuk suatu Tender.

Purchase Order adalah permintaan pembelian yang di terbitkan oleh Departemen Purchasing kepada Supplier. Setelah Purchase Order

di terima oleh Supplier, maka Supplier mengirimkan balasan permintaan pembayaran sementara yang berupa Proforma Invoice melalui email

(7)

sebelum invoice yang asli tersebut dikirim. Setelah pembayaran selesai di lakukan, prosedur pengiriman di lakukan oleh Supplier.

Prosedur pengadaan barang tersebut yaitu supplier mengirimkan

Packing List dan Airway Bill. Packing List adalah dokumen yang berisi daftar barang yang dikirim. Dan Airway Bill adalah dokumen pengiriman barang dari jasa pengiriman yang di gunakan oleh Supplier tersebut.

3.2.2 Permasalahan Dalam Sistem Yang Berjalan

Dari latar belakang masalah tersebut didapat beberapa masalah yang terjadi ketika sistem tender dijalankan tanpa bantuan komputerisasi. Beberapa hal masalah terjadi akibat kesalahan manusia karena prosedur

Procurement masih dilakukan secara manual.

Masalah-masalah yang dihadapi dalam sistem Tender, yaitu:

1. Supplier merasa memonopoli aktivitas procurement akibat suasana Tender yang tertutup. Akibatnya harga barang yang ditawarkan oleh Supplier menjadi lebih mahal.

2. Adanya manipulasi laporan Quotation ditabulasi oleh

Staff Purchasing Coordinator, akibat tabulasi masih di kerjakan secara manual oleh Purchasing Coordinator Staff.

3. Sering terjadinya kelebihan pembayaran Invoice.

4. Masalah yang ditemukan adalah informasi yang masih diolah secara manual menggunakan lembar kerja.

(8)

5. Sukar sekali untuk melihat laporan dan sejarah pembelian (procurement history) akibat data dan informasi masih di atur secara manual.

3.2.3 Perumusan Masalah

Setelah Material Request for Purchase di terima dari bagian inventori, dapat memasukan secara manual. MaterialRequest for Purchase yang telah dimasukan akan di.

Sistem yang baru akan berjalan secara Online di internet .

Supplier harus terlebih dahulu melakukan pendaftaran untuk melakukan transaksi seperti pengajuan Quotation, Invoice, Packing List dan Airway Bill di sistem eProcurement. Request for Quotation yang di setujui untuk dijadikan tenderakan diterbitkan secara Online dan setiap Supplier yang terdaftar berhak mengajukan penawaran untuk tender tersebut. Setelah

Tender ditutup, maka Purchasing Manager akan mengambil keputusan untuk membuat Purchase Order dari Quotation yang telah di tentukan.

Purchase Order yang dikeluarkan akan dikirimkan ke Supplier,

dan dapat diakses melalui website. Supplier dapat mengirimkan

Proforma Invoice melalui website dengan mengupload softcopy dan menyertakan jumlah harga dari Invoice tersebut. Setelah prosedur pembayaran dilakukan oleh pihak Finance, maka Supplier memasukan informasi Packing List dan Airway Bill kedalam sistem.

(9)

3.2.4 Business Modeling

Business modeling merupakan kegiatan untuk mendapatkan pemahaman atas system yang sedang berjalan saat ini. Artifak yang dapat diperoleh antara lain business glossary, business rules, business actors. Business use-cases, dan business use-case model.

A. Mencari Instilah-istilah Umum Bisnis

Untuk lebih mengerti sistem yang akan dibuat, maka dilakukan aktivitas mencari istilah-istilah bisnis umum yang digunakan dalam sistem Tender. Aktivitas ini akan menghasilkan artifak Business Glossary.

Business Glossary: • Material Request

Merupakan permintaan kepada pihak Inventory untuk mendapatkan Material atau Part yang di butuhkan untuk proses produksi.

• Material Request For Purchase

Merupakan permintaan pembelian dan pengadaan dari pihak inventory.

• Request For Quotation

Merupakan permintaan Quotation atau penawaran harga kepada Supplier.

(10)

• Quotation

Merupakan penawaran harga yang diberikan oleh

Supplier kepada Purchasing Coordinator atas balasan dari Request For Quotation.

• Exchange Price

Meupakan informasi harga untuk suatu material atau barang jika di tukar. Harga yang Exchange yang tertera di

Quotation tidak termasuk harga perbaikan material ayng ditukarkan.

• Outright Price

Merupakan informasi harga untuk suatu material yang ditawarkan.

• Flat rate Price

Merupakan harga barang pertukaran Part yang ditawarkan oleh Supplier tanpa memberikan ongkos perbaikan dari Part yang akan ditukarkan. Jika ternyata ongkos perbaikan yang di tukarkan mencapai Beyond Economical Range, maka pihak pembeli harus mengganti ongkos perbaikan.

(11)

• Beyond Economical Range

Suatu kondisi dimana ongkos perbaikan suatu Part telah melebihi harga pembelian atau pengadaan dari Part

tersebut.

• Part Material Alternate (PMA)

Merupakan suatu Part yang berbeda Partnumber tetapi dapat menggantikan fungsional dari Part yang sebelumnya. Biasanya PMA dapat terjadi karena Vendor

dari Part tersebut mengeluarkan versi terbaru atau Vendor

yang berbeda mengeluarkan Part yang mempunyai fungsi yang sama.

• Higher Next Partnumber (HNA)

Merupakan versi terbaru dari suatu Part yang menggantikan Part versi lama.

• Illustrated Part Catalog (IPC)

Merupakan data Part yang diberikan Vendor kepada Perusahaan untuk mengetahui, spesifikasi spesifik dari seluruh Part yang disediakan oleh Vendor tersebut.

B. Memelihara Aturan Bisnis

Aturan bisnis dari sistem peminatan yang berjalan adalah sebagai berikut:

(12)

1. Permintaan Pembelian Barang dari Inventory kepada Purchasing

a. Material Request yang diterima dari bagian Teknik akan di tampung didalam inventory. Pengalokasian barang akan dilakukan dan jika barang tersebut tidak ada, maka akan dimasukan ke dalam Material Request For Purchase.

b. Material Request For Purchase akan di kirimkan ke bagian Purchasing untuk melakukan prosedur pengadaan barang.

2. Permintaan Barang kepada Supplier

a. Material Request For Purchase yang diterima akan langsung dibuatkan Request For Quotation yang akan langsung diterbitkan kedalam tender b. Material Request for Quotation yang telah di

masukan kedalam tender dapat di ubah kembali dengan mengirimkan notifikasi kepada para Supplier yang telah mengirimkan Quotation untuk Request For Quotation tersebut.

3. Aktivitas penawaran harga di Tender

a. Tender yang telah diterbitkan mempunya masa waktu yaitu Tender Start Date dan Tender Expire Date.

(13)

b. Supplier yang terdaftar dapat mengirimkan

Request For Quotation yang telah di issued

melalui Tender.

c. Tender tidak harus mempunyai pemenang

Tender. Jika hal itu terjadi dan barang yang harus diadakan sangat penting, maka Tender dapat di perpanjang.

d. Supplier dapat mengubah Quotation sebelum masa Tender berakhir.

4. Perintah Pembelian

a. Pembelian dilakukan berdasarkan Quotation yang menang dalam suatu tender.

b. Pembelian dilakukan dengan mengirimkan Purchase Order kepada Supplier tertentu.

5. Konfirmasi Pembayaran

a. Supplier yang telah terpilih Quotation-nya dapat langsung memasukan informasi Invoice kedalam sistem

b. Purchasing Manager dapat melihat dan mengecek isi dari Invoice yang diberikan Supplier, apakah sudah sesuai dengan Quotation dan Purchase Order yang terkait. Purchasing Manager berhak memutuskan apakah Invoice tersebut layak dibayarkan oleh Divisi Finance.

(14)

c. Purchasing Manager memberi perintah pembayaran atas Invoice kepada Divisi Finance.

6. Konfirmasi Pengiriman Barang

Supplier dapat mengirimkan Informasi barang yang akan dikirim berupa Packing List dan informasi pengiriman dari suatu barang berupa Airway Bill.

3.2.5 Use Case

Aktor pada Use case ini didapatkan dari hasil pengamatan yang dilakukan. Dari hasil pengamatan yang di lakukan dapat disimpulkan bahwa hanya tiga aktor yang berperan penting untuk pengadaan barang di Divisi Purchasing. Kriteria-kriteria yang terpenting untuk menjadi aktor di Use Case diagram adalah:

• Hanya memasukan informasi kedalam sistem. • Hanya menerima informasi dari sistem

• Dapat memasukan dan menerima informasi dari dan ke sistem

A. Pencarian Aktor

Dari kriteria-kriteria tersebut di temukan bahwa ada tiga aktor yang dapat di identifikasi:

• Purchasing Manager

Seseorang yang mengepalai divisi Purchasing

bertanggung jawab dan mengawasi aktivitas yang terjadi di divisi Purchasing.

(15)

• Supplier Representative

Seseorang representative dari Supplier tertentu yang terdaftar untuk melakukan transaksi penawaran untuk pengadaan barang

• Purchasing Coordinator Staff

Staff dari divisi Purchasing yang bertanggung jawab atas keseluruhan transaksi untuk pengadaan barang bagi inventori. Dimulai dari permintaan barang sampai pembayaran.

(16)

B. Pencarian Use Case

Dari hasil pengamatan ditemukan Use Case yang didapat dari actor-aktor yang mempunyai keperluan didalam sistem. Berikut kebutuhan-kebutuhan dari aktor yang harus dipenuhi oleh sistem:

• Purchasing staff Coordinator perlu menggunakan sistem untuk memasukan informasi Material Request For Purchase dan juga dapat mensurvey Supplier yang Pra-Registrasi

• Setelah Informasi Material Request for Purchase

dimasukan, sistem harus menyediakan hasil analisis untuk

Purchasing Staff Coordinator. Purchasing Staff Coordinator bertanggung jawab atas kesesuaian hasil analisis informasi Material Request For Purchase.

• Purchasing Staff Coordinator bertanggung jawab atas kesesuaian data dari informasi Material Request For Purchase, Request for Quotation, dan Tender.

• Purchasing Manager dapat menyetujui dan menolak hasil survey dari Supplier Pra-Registrasi, melihat dan menyetujui Material Request for Purchase Information yang di buat oleh Purchasing Staff Coordinator untuk dimasukan ke tender atau tidak.

(17)

• Purchasing Manager harus dapat melihat hasil tender

yang telah habis masanya untuk menentukan hasil tender

dan menyetujui Quotation untuk mengeluarkan Purchase Order untuk Quotation tersebut.

• Supplier Representative perlu untuk mendaftarkan dirinya kedalam sistem. Setelah terdaftar kedalam sistem, Supplier harus dapat memilih tender, melihat Request for Quotation yang terdaftar di tender, dan memasukan informasi Quotation.

• Supplier dapat memasukan informasi Invoice, Packing List dan Airway Bill kedalam sistem

• Sistem dapat memberikan notifikasi atas status Quotation

dan mendapatkan Purchase Order untuk Quotation di tender yang menang.

Dari kebutuhan-kebutuhan tersebut, berikut Use Case yang teridentifikasi:

1. Pre-Registrasi Supplier 2. LogIn Staff

3. LogIn Supplier Representative 4. Survey Pre-Registrasi Supplier

5. Memasukan Informasi Material Request For Purchase

6. Mengatur Kesesuaian Informasi Material Request For Purchase

(18)

7. Mengatur Kesesuaian Tender 8. Membuat Penawaran Ke Tender

9. Mendapatkan Purchase Order untuk Tender yang dimenangkan

10. Memasukan Informasi Invoice 11. Mengatur Kesesuaian Invoice

12. Memasukan Informasi Packing List dan Airway Bill

13. Mengatur Kesesuaian Informasi Packing List dan Airway Bill

(19)

C. Perincian Use Case

• Use Case Pre-Registrasi Supplier

Use Case ini dimulai oleh pengunjung website eProcurement. Dan menyediakan kemampuan untuk Visitor untuk melakukan Pre-Registrasi Supplier.

Syarat Awal Tidak ada Use Case yang harus dijalankan sebelum

Use Case ini dimulai.

Alur Utama Sistem akan menampilkan Terms and Agreement, yang harus di setujui. Setelah itu sistem akan menampilkan form Pre-Registrasi Supplier. Setelah calon Supplier Representative mengisi form Pre-Registrasi Supplier, maka calon Supplier Representative akan diberikan pilihan aktivitas yaitu: SUBMIT, atau CANCEL.

• Jika aktivitas yang terpilih adalah SUBMIT,

maka informasi yang dimasukan user akan dimasukan kedalam sistem, dan Use Case

berakhir

• Jika akitifitas yang terpilih adalah CANCEL, maka calon Supplier Representative akan dialihkan ke Halaman Utama, dan Use Case

berakhir

(20)

• Use Case LogIn Staff

Use Case ini dimulai oleh Purchasing Staff Coordinator atau Purchasing Manager, yang menyediakan kemampuan kepada sistem untuk mengenali Staff yang akan masuk kedalam sistem dan memberikan privilege yang sesuai.

Syarat Awal Tidak ada Use Case yang perlu dilakukan

Alur Utama Sistem akan menampilkan Form Login Staff yang berisi field NIP dan Password yang harus diisi.

Staff dapat mengisi field tersebut dan memberikan pilihan LOGIN. Ketika Staff meilih pilhan LOGIN maka sistem akan memastikan apakah NIP dan

Password yang diberikan sesuai.

• Jika sesuai, maka menu yang sesuai dengan

privilege akan dibuka dan Use Case berakhir. • Jika tidak sesuai, maka sistem akan

menampilkan pesan kesalahan ‘Invalid NIP or Password’ dan Use Case kembali dilanjutkan Tabel 3.2 Alur Kejadian Use Case LogIn Staff

(21)

• Use Case LogIn Supplier Representative

Use Case ini dimulai oleh Supplier Representative, yang menyediakan kemampuan kepada sistem untuk mengenali

Supplier Representative yang akan melakukan transaksi didalam sistem.

Syarat Awal Tidak ada Use Case yang perlu dilakukan

Alur Utama Sistem akan menampilkan Form Login Supplier Representative yang berisi field Username dan

Password yang harus diisi.

• Jika sesuai, maka menu yang sesuai dengan

privilege akan dibuka dan Use Case berakhir. • Jika tidak sesuai, maka sistem akan

menampilkan pesan kesalahan ‘Invalid Username or Password’ dan Use Case

kembali dilanjutkan

(22)

• Use Case Survey Pre-Registrasi Supplier

Use Case ini dimulai oleh Purchasing Staff Coordinator, yang menyediakan kemampuan untuk melihat profil, menyetujui dan menolak Perusahaan dan Representative yang baru saja melakukan aktivitas Pre-Registrasi

Syarat Awal Use Case LogIn Staff harus dilakukan terlebih dahulu sebelum Use Case ini dimulai

Alur Utama Sistem akan menampilkan daftar Supplier atau

Supplier Representative yang telah melakukan Pre-Registrasi dan menampilkan detilnya. Sistem akan memberikan pilihan kepada Purchasing Coordinator Staff yang di inginkan yaitu: APPROVE, REJECT, REFRESH, atau EXIT.

• Jika akitivitas yang dipilih adalah APPROVE, S-1: Alur Sub Menyetujui Pre-Registrasi dilakukan.

• Jika aktivitas yang dipilih adalah REJECT, S-2: Alur Sub Menolak Pre-Registrasi Dilakukan.

• Jika aktivitas yang dipilih adalah REFRESH: Sistem akan me-refresh daftar, dan use case

kembali dilanjutkan.

• Jika aktivitas yang dipilih adalah EXIT: Use Case Berakhir.

Alur Sub S-1: Menyetujui Pre-Registrasi

Sistem akan mengubah status Supplier dan

Supplier Representative menjadi

REGISTERED, me-refresh daftar Supplier dan

Use Case terus berlanjut. S-2: Menolak Pre-Registrasi

Sistem akan mengubah status Supplier dan Supplier Representative menjadi REJECTED, me-refresh daftar Supplier dan Use Case terus berlanjut.

(23)

• Use Case Memasukan Informasi Material Request For

Purchase

Use Case ini dimulai oleh Purchasing Coordinator Staff dan memberi kemampuan untuk memasukan informasi Material Request For Purchase kedalam sistem.

Syarat Awal Use Case LogIn Staff harus dilakukan sebelum

Use Case ini dimulai

Alur Utama Sistem akan menampilkan form yang berisi

field-field yang diperlukan untuk informasi membuat Material Request For Purchase.

Purchasing Coordinator Staff akan mengisi form tersebut. Sistem akan memberikan pilihan kepada Purchasing Coordinator Staff untuk, SUBMIT atau EXIT:

• Jika aktivitas yang dipilih adalah SUBMIT, maka sistem akan memasukan informasi kedalam database dan membersihkan field form tersebut dan Use Case terus berlanjut.

• Jika aktivitas yang dipilih adalah EXIT, maka Use Case berakhir.

Table 3.5 Alur Kejadian Memasukan Informasi Material Request For Purchase

(24)

• Use Case Mengatur Kesesuaian Informasi Material Request For Purchase

Use Case ini dimulai oleh Supplier Representative, dan menyediakan kemampuan untuk mengatur kesesuaian informasi

Material Request For Purchase yang telah dimasukan sebelumnya, membuat Request For Quotation dan memasukannya kedalam Tender.

Syarat Awal Use CaseLogIn Staff harus dilakukan terlebih dahulu sebelum Use Case ini dilakukan.

Alur Utama Sistem akan menampilkan daftar dari Material Request For Purchase yang telah dimasukan sebelumnya. Ketika Purchasing Coordinator

memilih salah satu dari Material Request For Purchase sistem akan menampilkan detil dari

Material Requesti beserta statusnya. Jika status NEWLY ADDED maka Material Request For Purchase dapat diatur kesesuaiannya dan sistem akan memberikan aktivitas pilihan yaitu: CREATE RFQ, UPDATE, DELETE, REFRESH, dan EXIT. Jika status ON TENDER maka Material Request For Purchase tidak dapat diatur kesesuaiannya dan aktivitas pilihan yang tersedia hanya REFRESH dan EXIT.

• Jika aktivitas yang dipilih adalah CREATE RFQ, S-1: Alur sub Membuat Request For Quotation dilakukan.

• Jika aktivitas yang dipilih adalah UPDATE, S-2: Alur sub mengubah

Material Request for Purchase dilakukan. • Jika aktivitas yang dipilih adalah

DELETE, S-3: Alur Sub menghapus

Material Request For Purchase dilakukan • Jika aktivitas yang dipilih adalah

REFRESH: Maka sistem akan me-refresh

daftar Material Request For Purchase dan

Use Case dilanjutkan

• Jika aktivitas yang dipilih adalah EXIT: Maka Use Case berakhir

(25)

Alur Sub S-1 Membuat Request For Quotation

Sistem membuat Request For Quotation, memasukannya kedalam Tender dan mengubah status Material Request For Purchase menjadi ON TENDER dan Use Case dilanjutkan

S-2: Mengubah Material Request For Purchase

Sistem akan mengubah Material Request For Purchase, me-refresh daftar dan Use Case dilanjutkan

S-3: Menghapus Material Request For Purchase

Sistem akan menghapus Material Request For Purchase, me-refresh daftar dan Use Case dilanjutkan

Table 3.6 Alur Kejadian Use Case Mengatur Kesesuaian Informasi Material Request For Purchase

(26)

• Use Case Mengatur Kesesuaian Tender

Use Case ini dimulai oleh Purchasing Manager, dan memberikan kemampuan melihat keadaan Tender dan mengatur kesesuaian

Tender.

Syarat Awal Use CaseLogIn Staff harus dilakukan terlebih dahulu sebelum Use Case ini dilakukan.

Alur Utama Sistem akan menampilkan Tender yang sedang dalam baik OPEN maupun CLOSED. Jika

Tender ada dalam status OPEN, maka pilihan aktivitas yang diberikan adalah CLOSE TENDER, REFRESH, dan EXIT. Jika Tender

ada dalam status CLOSE, maka pilihan aktivitas yang diberikan adalah EXTEND, REFRESH, dan EXIT.

• Jika aktivitas yang dipilih adalah CLOSE TENDER, S-1: Alur Sub Menutup Tender

dilakukan

• Jika aktivitas yang dipilih adalah EXTEND, S-2: Alur Sub Perpanjang

Tender dilakukan

• Jika aktivitas yang dipilih adalah REFRESH, sistem akan me-refresh daftar

Tender dan Use Case dilanjutkan

• Jika aktivitas yang dipilih adalah EXIT, maka Use Case berakhir

Alur Sub S-1 Menutup Tender

Sistem akan mengubah status Tender

menjadi CLOSED, me-refresh daftar

Tender dan Use Case dilanjutkan S-2: Perpanjang Tender

Sistem akan menampilkan dialog perpanjang waktu yang memungkinkan

Purchase Coordinator Staff untuk memperpanjang waktu Tender ke waktu yang di inginkan, me-refresh Tender, dan

Use Case dilanjutkan.

(27)

• Use Case Membuat Penawaran Ke Tender

Use Case ini dimulai oleh Supplier Representative, dan menyediakan kemampuan untuk memberikan penawaran ke

Tender yaitu berupa Quotation.

Syarat Awal Use Case LogIn Supplier Represetntative harus dilakukan sebelum Use Case ini dilakukan. Alur Utama Sistem akan menampilkan daftar dari Supplier

yang telah melakukan Pre-Registrasi. Ketika User menunjuk kepada salah satu Supplier yang telah terdaftar tersebut, User dapat melihat rincian dari Profil Perusahaan dan Representative Supplier. Sistem akan memberikan pilihan aktifitas kepada User yaitu: ACCEPT, REJECT, atau EXIT.

• Jika aktivitas yang terpilih adalah ACCEPT,

S-1: Alur Sub Penerimaan Pre-Registrasi akan di lakukan

• Jika akitifitas yang terpilih adalah REJECT, S-2: Alur Penolakan Pre-Registrasi akan dilakukan.

• Jika aktifitas yang terpilih adalah EXIT, maka Use Case Berakhir.

Alur Sub S-1: Penerimaan Pre-Registrasi

Sistem akan me-refresh table daftar Pre-Registrasi Supplier

S-2: Penolakan Pre-Registrasi

Sistem akan me-refresh table daftar Pre-Registrasi Supplier

(28)

• Use Case Mendapatkan Purchase Order untuk Tender yang

dimenangkan

Use Case ini dimulai oleh Supplier Representative, dan memberikan kemampuan untuk Supplier Representative

menyetujui Purchase Order dan mengambil dokumen Purchase Order atau menolak Purchase Order

Syarat Awal Use Case LogIn Supplier Representative harus dilakukan terlebih dahulu sebelum Use Case ini dimulai.

Alur Utama Sistem akan menampilkan daftar Purchase Order, dan User dapat memilih salah satu

Purchase Order dari daftar tersebut. Sistem akan memberikan pilihan aktivitas yaitu:

REJECT, ACCEPT, atau BACK.

• Jika aktivitas yang dipilih adalah REJECT:

S-1, Maka alur sub Penolakan Purchase Order akan dilakukan

• Jika aktifitas yang dipilih adalah ACCEPT: S-2, Maka alur sub Penerimaan Purchase Order dilakukan.

• Jika aktifitas yang dipilih adalah BACK: (S-3), Maka User akan di alihkan ke halaman daftar Purchase Order dan Use Case terus berlangsung.

Alur Sub S-1: Penolakan Purchase Order

Sistem akan menampilkan konfirmasi untuk penolakan, jika yang dipilih adalah ‘Yes’ maka sistem akan menghapus dokumen Purchase Order. Jika yang dipilih adalah ‘No’ maka sistem akan mengalihkan User kehalaman daftar

Purchase Order

S-2: Penerimaan Purchase Order

Sistem akan mengirimkan dokumen

Purchase Order ke User.

Tabel 3.9 Alur Kejadian Use Case Mendapatkan Purchase Order Untuk Tender Yang dimenangkan

(29)

• Use Case Memasukan Informasi Invoice

Use Case ini dimulai oleh Supplier Representative, dan memberikan kemampuan kepada Supplier Representative

memasukan informasi Invoice untuk Purchase Order yang telah disetujui.

Syarat Awal Use Case LogIn Supplier Representative harus dilakukan terlebih dahulu sebelum Use Case ini dilakukan

Alur Utama Sistem akan menampilkan daftar dari Purchase Order yang valid. Sistem akan menampilkan form Invoice dan memberikan fitur untuk meng-Upload file Invoice kedalam sistem.

Sistem akan memberikan pilihan kepada User

yaitu, SUBMIT, atau EXIT.

• Jika aktivitas yang dipilih adalah SUBMIT, maka sistem akan emasukan Informasi Invoice.

(30)

• Use Case Mengatur Kesesuaian Invoice

Use Case ini dimulai oleh Supplier Representative, dan memberikan kemampuan untuk Supplier Representative untuk mengatur kesesuaian informasi Invoice

Alur Utama Sistem akan menampilkan daftar dari Purchase Order yang valid. Sistem akan menampilkan form Invoice dan memberikan fitur untuk meng-Upload file Invoice kedalam sistem.

Sistem akan memberikan pilihan kepada User

yaitu, SUBMIT, atau EXIT.

• Jika aktivitas yang dipilih adalah SUBMIT, maka sistem akan emasukan Informasi Invoice.

(31)

• Use Case Memasukan Informasi Packing List dan Airway Bill Use case ini dimulai oleh Supplier Representative, dan memberikan kemampuan untuk memasukan informasi Packing List dan Airway Bill

Alur Utama Sistem akan menampilkan daftar dari Invoice

yang valid. Supplier Representative dapat memasukan melihat detil dari Invoice. Sistem akan memberikan pilihan aktivitas untuk SUBMIT PACKING LIST, SUBMIT AIRWAY BILL, dan BACK.

• Jika aktivitas yang dipilih adalah SUBMIT PACKING LIST: S-1, Maka Alur Sub Memasukan Informasi Packing List

dilakukan.

• Jika aktivitas yang dipilih adalahSUBMIT AIRWAY BILL, Maka Alur Sub Memasukan Informasi Airway Bill

dilakukan

• Jika aktivitas yang dipilih adalah BACK: Maka Use Case berakhir

Alur Sub S-1: Memasukan Informasi Packing List

Sistem akan menyediakan field untuk

memasukan path dari dokumen Packing List, No Packing List dan Exp. Date. Use Case dilanjutkan

S-2: Memasukan Informasi Boarding List

Sistem akan menyediakan field untuk

memasukan path dari dokumen Packing List, No Boarding List dan Exp. Date.Use Case dilanjutkan

Tabel 3.12 Alur Kejadian Use Case Memasukan Informasi Packing List Dan Airway Bill

(32)

• Use Case Mengatur Kesesuaian Informasi Packing List dan Airway Bill

Use Case dimulai dari Supplier Representative, dan memberikan kemampuan untuk mengatur kesesuaian informasi Packing List

dan Airway Bill.

Alur Utama Form untuk mengatur kesesuaian Packing List

dan Airway Bill dapat ditemukan di daftar

Invoice dan daftar Airway Bill dan Packing List. Jika Supplier Representative hanya mengetahui No Invoice, maka dapat digunakan daftar Invoice. Jika hanya No Packing List dan

Airway Bill yang diketahui maka dapat digunakan daftar Packing List dan Airway Bill. Supplier Representative dapat mengubah atribut dari Airway Bill dan Packing List.

Tabel 3.13 Alur Kejadian Mengatur Kesesuaian Informasi Packing List dan Airway Bill

(33)

3.2.6 Activity Diagram

Berikut ini adalah Activity Diagram untuk Use Case diagram yang bersangkutan. Aktivitas-aktivitas penting yang dapat di indentifikasi adalah:

• Aktivitas registrasi Supplier

Aktivitas ini dimulai ketika Supplier mengisi form Pre-Registrasi. Supplier yang belum terdaftar dapat mengunjungi website eProcurement dan menuju ke halaman Registrasi untuk mengisi form Pre-Registrasi. Setelah Supplier mengisi form Pre-Registrasi, sistem akan memasukan informasi tersebut kedalam database. Aplikasi akan membaca dan menampilkannya ke modul Survey Pre-Registrasi. Purchasing Coordinator Staff akan melihat profil Perusahaan Supplier dan

Supplier Representative dan melakukan pengesahaan atas Pre-Registrasi. Jika Supplier tersebut disetujui maka sistem akan mengirimkan email notifikasi persetujuan kepada Supplier. Dan jika tidak disetujui maka sistem akan mengirimkan email penolakan kepada Supplier.

(34)

(35)

• Aktivitas pembuatan Tender.

Aktivitas ini dimulai ketika Purchasing Coordinator Staff

memasukan informasi Material Request for Purchase.

Sistem akan memasukannya kedalam database dan membuat analisi sederhana. Purchasing Coordinator Staff

dapat memilah hasil analisis yang nantinya akan di cek oleh Purchasing Manager. Jika disetujui maka Request for Quotation akan dibuat dan akan dipublikasikan melalui Tender. Jika tidak maka akan dihapus dari daftar.

(36)

• Aktivitas pembuatan Quotation.

Aktivitas ini dimulai ketika Supplier Representative

memilih Tender dan memasukan informasi Quotation.

Kemudian sistem secara otomatis akan mebuat Quotation

(37)

• Aktivitas pembuatan Purchase Order.

Aktivitas ini dimulai ketika Purchasing Manager

mengevaluasi Tender dan menutup tender. Kemudian sistem akan menampilkan Quotation yang tersedia. Purchasing Manager dapat memilih quotation dan membuat Purchase Order untuk Quotation tersebut. Kemudian sistem akan mengirimkan Purchase Order kepada Supplier melalui email. Dan membuat notifikasi di website eProcurement.

Gambar 3.8 Activity Diagram Untuk Aktivitas Pembuatan Purchase Order

(38)

• Aktivitas memasukan informasi Invoice.

memilih Purchase Order dan melihat detil dari Purchase Order. Sistem akan memberikan pilihan kepada Supplier Representative untuk segera memasukan informasi

Invoice. Sistem akan menampilkan form yang diperlukan untuk informasi Invoice. Sistem juga akan meng-upload file Invoice.

Gambar 3.9 Activity Diagram Untuk Aktivitas Memasukan Informasi Invoice

(39)

• Aktivitas memasukan informasi Packing List dan

Airway Bill.

memilih Invoice dan melihat detil dari Invoice. Sistem akan memberikan pilihan untuk segera memasukan informasi Packing List dan Airway Bill. Sistem akan menampilkan form yang diperlukan untuk informasi

Packing List dan Airway Bill. Kemudian sistem akan memasukan informasi dan mengupload file Packing List

dan Airway Bill kedalam sistem

Gambar 3.10 Activity Diagram Untuk Aktivitas memasukan informasi Packing List dan Airway Bill.

(40)

3.2.7 Perancangan Database

Database yang dirancang ini merupakan data yang terlibat selama proses procurement berlangsung. Data-data tersebut didapat dari informasi yang dihasilkan dari proses procurement atau yang diperlukan untuk melakukan proses procurement. Informasi – informasi tersebut biasanya berupa dokumen, form, atau email. Form-form tersebut dikumpulkan, dianalisis, dan dinormaliasai, untuk menjadi suatu tabel – tabel logika di Sistem Database Relasional. Setiap tabel mempunyai ID kode panggil aplikasi yang akan digunakan oleh Java Persistence API

(41)

3.2.7.1 Tabel AAT

Tabel AAT adalah table yang memuat informasi Aircraft Airworthiness Tag. Yang merupakan dokumen sertifikat yang menyatakan kesahan dan kelayakan dari suatu part untuk dipakai selama operasional, berisi informasi mengenai kondisi dari part. Didalam AAT ada lima atribut yang penting: Tagnumber yang merupakan nomor unik dari suatu dokumen AAT, Tagdate yang merupakan tanggal dokumen AAT tersebut dikeluarkan, Tag Tracebility yang merupakan informasi pemakai part tersebut, dan Tag Approval yang merupakan informasi organisasi yang mengesahkan dokumen AAT tersebut.

Nama Field Tipe Data Panjang Keterangan

IDAAT NUMBER Id Aat kode panggil

untuk aplikasi

TAGNUMBER VARCHAR 20 No Tag

TAGDATE DATE Tanggal Aat

TAGTRACEBILITY VARCHAR 40 Pemakai terakhir part IDTAGAPPROVAL NUMBER Foreign Key ke table

Mstagapproval Tabel 3.14 Tabel AAT

(42)

3.2.7.2 Tabel AIRWAY_BILL

Tabel AIRWAY_BILL adalah table yang memuat informasi surat jalan dari suatu part yang diterima oleh pihak

Purchasing ketika Supplier telah melakukan pengiriman. Didalam AIRWAY_BILL ada lima atribut yang penting: NOAIRWAYBILL merupakan nomor unik dari suatu dokumen

Airway Bill, ISSUEDDATE merupakan tanggal dokumen Airway Bill tersebut dikeluarkan, NOINVOICE merupakan no referensi ke table invoice yang bersangkutan.

IDAIRWAYBILL NUMBER Id AirwayBill kode panggil untuk aplikasi NOAIRWAYBILL VARCHAR 20 No AirwayBill

ISSUEDDATE DATE Tanggal pemasukan

dokumen Airway Bill

IDINVOICE NUMBER Foreign Key ke tabel Invoice

STATUS NUMBER Status dari Airway

Bill, ‘0’ untuk New, ‘1’ untuk Valid, dan ‘2’ untuk Fraud

(43)

3.2.7.3 Tabel CURRENCY

Tabel CURRENCY adalah table yang memuat informasi mata uang asing yang didukung oleh system e-Procurement. Didalam CURRENCY ada dua atribut penting, yaitu: SYMBOL merupakan symbol dari mata uang asing, dan DETAIL merupakan keterangan dari mata uang asing.

IDCURRENCY NUMBER Id Currency

SYMBOL VARCHAR 5 Symbol dari mata

uang, contoh: ‘USD’ untuk US Dollar

DETAIL VARCHAR 30 Keterangan dari

Currency

(44)

3.2.7.4 Tabel DTLMATERIALREQUESTFORPURCHASE

Tabel DTLMATERIALREQUESTFORPURCHASE adalah tabel yang memuat informasidetil dari permintaan barang. Didalam DTLMATERIALREQUESTFORPURCHASE ada

tujuh atribut penting, yaitu:

IDMATERIALREQUESTFORPURCHASE merupakan referensi

ke header MATERIALREQUESTFORPURCHASE,

IDPARTCATALOG merupakan referensi ke PARTCATALOG, QUANTITY merupakan jumlah permintaan barang, REMARKS berisi keterangan tambahan untuk permintaan tersebut, ACREG merupakan no registrasi pesawat dimana permintaan barang tersebut diperuntukan, OPENDMIDATE adalah tanggal berlakunya OPENDMI, dan DUEDMIDATE adalah tanggal berakhirnya DMIDATE

(45)

Nama Field Tipe Data Panjang Keterangan IDDTLMATERIAL RFP NUMBER Id DtlMaterialRequest ForPurchase IDMATERIALREQ UESTFORPURCH ASE

NUMBER Foreign Key ke

tabel

MaterialRequestFor Purchase

IDPARTCATALO G

NUMBER Foreign Key ke

tabel Partcatalog

QUANTITY NUMBER Jumlah permintaan

barang

REMARKS NUMBER Pesan atau

keterangan permintaan

ACREG VARCHAR 10 No Registrasi

pesawat

OPENDMIDATE DATE Waktu Mulai DMI

DUEDMIDATE DATE Waktu Terakhir

DMI Tabel 3. 17 Tabel DtlMaterialRequestForPurchase

(46)

3.2.7.5 Tabel DTLQUOTATION

Tabel DTLQUOTATION adalah table yang memuat informasi detil dari quotation header. Di dalam DTLQUOTATION terdapat lima atribut penting: IDQUOTATION merupakan referensi kode header quotation, LISTPRICE merupakan harga yang ditawarkan supplier untuk suatu part, DISC merupakan diskon harga yang diberikan

supplier dalam persen, TYPEOFPRICE jenis harga yang diberikan oleh supplier, dan CURRENCY merupakan mata uang yang berlaku untuk harga di quotation.

(47)

Nama Field Tipe Data Panj ang Keterangan IDDTLQUOTATIO N

NUMBER Id DTLQUOTAITON kode panggil untuk aplikasi

IDQUOTATION NUMBER Foreign Key ke tabel MaterialRequestForPurchas e

LISTPRICE NUMBER Jumlah permintaan barang

DISC NUMBER Pesan atau keterangan

permintaan TYPEOFPRICE VARCHA

R

9 Tipe harga yang

ditawarkan. Kemungkinan: “OUTRIGHT”,

“EXCHANGE”, dan “FLATRATE”

CURRENCY NUMBER Mata uang yang dipakai. Foreign Key ke tabel Currency

(48)

3.2.7.6 Tabel DTLTENDER

Tabel DTLTENDER adalah tabel logika dari aplikasi untuk menampung quotation untuk setiap tender yang bersangkutan. Di dalam DTLTENDER ada dua atribut penting, yaitu: IDTENDER merupakan kode panggil ke tabel TENDER yang bersangkutan dengan TENDER, dan IDQUOTATION merupakan kode panggil untuk QUOTATION yang bersangkutan.

IDDTLTENDER NUMBER Id DtlTender kode

panggil aplikasi

IDTENDER NUMBER Foreign Key ke tabel

Tender

IDQUOTATION NUMBER Foreign Key ke tabel

Quotation

(49)

3.2.7.7 Tabel Invoice

Tabel INVOICE adalah tabel yang menampung informasi invoice dan file invoice. Di dalam DTLTENDER ada tujuh atribut penting, yaitu: NOINVOICE merupakan no invoice, INVOICEFILEPATH merupakan direktori fisik dari file invoice, IDPO merupakan PO yang berhubungan dengan INVOICE, EXPDATE merupakan tanggal berakhirnya masa INVOICE, TOTALVALUE merupakan nilai pembayaran yang harus dibayar, APPROVEDBY merupakan user yang menyetujui INVOICE tersebut dapat dibayar, INVOICESTATUS merupakan status dari INVOICE, dan ISSUEDDATE merupakan tanggal mulai berlakunya INVOICE.

(50)

IDINVOICE NUMBER Id Invoice kode panggil aplikasi NOINVOICE VARCHA R 20 No Terbit Invoice INVOICEFILEPA TH VARCHA R

50 Path File dari fileInvoice

IDPO NUMBER

EXPDATE NUMBER Tanggal terakhir masa berlaku Invoice

TOTALVALUE NUMBER Total nilai Invoice

APPROVEDBY NUMBER Staff yang memeriksa dan menyetujui Invoice. Foreign Key ke tabel Msstaff

INVOICESTATUS NUMBER Status dari Invoice, ada tiga kemungkinan: ‘0’ untuk ‘New’, ‘1’ untuk ‘Paid’, dan ‘2’ untuk ‘Fraud’

ISSUEDDATE DATE Tanggal diberlakukannya

Invoice

(51)

3.2.7.8 Tabel Material Request for Purchase

Tabel MATERIALREQUESTFORPURCHASE adalah header dari permintaan barang yang harus dilakukan pembelian. Di dalam tabel MATERIALREQUESTFORPURHASE ada lima atribut penting, yaitu: REQUESTDATE merupakan tanggal permintaan, REQUESTBY merupakan pihak yang melakukan

permintaan, NOMATERIALREQUESTFORPURCHASE merupakan nomor fisik dari permintaan barang, dan STATUS

(52)

Nama Field Tipe Data Panjang Keterangan IDMATERIALREQUE

STFORPURCHASE

NUMBER Id Material Request For Purchase

REQUESTDATE DATE 20 Tanggal permintaan

barang untuk pembelian

REQUESTBY NUMBER Yang meminta

barang, Foreign Key

ke tabel Msstaff NOMATERIALREQU ESTFORPURCHASE VARCHA R 20 No Material Request For Purchase

STATUS NUMBER Status dari material

request ‘0’ untuk ‘NEW’, ‘1’ untuk ‘NOT ON TENDER’, dan ‘2’ untuk ‘ON TENDER’

(53)

3.2.7.9 Tabel MsCountry

Tabel MSCOUNTRY adalah tabel yang menampung daftar Negara yang didukung oleh aplikasi. Di dalam tabel MSCOUNTRY ada dua atribut penting, yaitu: CODE merupakan kode inisial dari suatu Negara, dan NAME merupakan nama dari suatu Negara.

IDCOUNTRY NUMBER Id MsCountry

CODE VARCHAR 3 Kode dari negara,

contoh: ‘US’ untuk ‘United State’

NAME DATE Nama dari negara

(54)

3.2.7.10 Tabel MsInvoiceAddress

Tabel MSINVOICEADDRESS adalah tabel yang menampung daftar alamat tujuan pengiriman INVOICE. Di dalam tabel MSINVOICEADDRESS ada lima atribut penting, yaitu: COMPANYNAME merupakan nama perusahaan tujuan INVOICE, ADDRESS merupakan alamat jalan, CITY merupakan kota dari alamat, STATE merupakan Negara bagian atau provinsi, IDCOUNTRY merupakan Negara yang referensi ke tabel MSCOUNTRY, dan ZIPCODE merupakan kodepos.

IDINVOICEADDRESS NUMBER Id

MsInvoiceAddress

COMPANYNAME VARCHAR 30 Nama perusahaan

penerima Invoice

ADDRESS VARCHAR 50 Alamat

CITY VARCHAR 20 Kota

STATE VARCHAR 20 Negara Bagian

IDCOUNTRY NUMBER Negara, Foreign

Key ke tabel MsCountry

ZIPCODE VARCHAR 5 Kode Pos

(55)

3.2.7.11 Tabel MsPartCategory

Tabel MSPARTCATEGORY adalah tabel yang menampung informasi kategori yang mungkin terjadi untuk suatu part. Di dalam tabel MSPARTCATEGORY ada dua atribut penting, yaitu: PARTCATEGORY kategori dari suatu part, dan PROCUREMENTLONGTERM merupakan lama toleransi pengadaan barang setelah OPENDMIDATE berlaku (dalam hari). Nama Field Tipe Data Panjang Keterangan

IDPARTCATEGORY NUMBER Id

MsPartcategory

PARTCATEGORY CHAR 1 Kategori dari

part, ada 3 kemungkinan, A, B, C, dan D PROCUREMENTLONGTERM NUMBER Toleransi

waktu pengadaan

barang yang diberikan

(56)

3.2.7.12 Tabel MsPartCondition

Tabel MSPARTCONDITION adalah tabel yang menampung daftar alamat tujuan pengiriman INVOICE. Di dalam tabel MSINVOICEADDRESS ada lima atribut penting, yaitu: COMPANYNAME merupakan nama perusahaan tujuan INVOICE, ADDRESS merupakan alamat jalan, CITY merupakan kota dari alamat, STATE merupakan Negara bagian atau provinsi, IDCOUNTRY merupakan Negara yang referensi ke tabel MSCOUNTRY, dan ZIPCODE merupakan kodepos.

IDPARTCONDITION NUMBER Id MsPartcondition PARTCONDITION VARCHAR 2 Kode kondisi part

DESCRIPTION VARCHAR 40 Keterangan Kondisi Tabel 3. 25 Tabel MsPartCondition

(57)

3.2.7.13 Tabel MsPartKeyword

Tabel MSPARTKEYWORD adalah tabel yang menampung informasi kata kunci dari suatu part. Di dalam tabel MSPARTKEYOWRD ada dua atribut penting, yaitu: PARTKEYWORD merupakan keyword dari suatu part, dan DESCRIPTIOn yang merupakan keterangan detil dari suatu

keyword part

IDPARTKEYWORD NUMBER Id MsPartkeyword PARTKEYWORD VARCHAR 40 Keyword dari part DESCRIPTION VARCHAR 40 Keterangan part

(58)

3.2.7.14 Tabel MsReference

Tabel MSREFERENCE adalah tabel yang menampung informasi referensi katalog dari suatu part. Di dalam tabel MSREFERENCE ada tiga atribut penting, yaitu: REFERENCETYPE yang merupakan tipe referensi dari suatu part, REFERENCES merupakan vendor dari suatu part, dan REFERENCENUMBER yang merupakan nomer referensi di katalog referensi

IDREFERENCE NUMBER Id MsReference

REFERENCETYPE VARCHAR 20 Tipe dari reference

REFERENCES VARCHAR 40 Perusahaab

pembuat part

REFERENCENUMBER VARCHAR 40 No IPC

(59)

3.2.7.15 Tabel MsShippingAddress

Tabel MSSHIPPINGADDRESS adalah tabel yang menampung daftar alamat tujuan pengiriman suatu barang. Di dalam tabel MSSHIPPINGADDRESS ada 5 atribut penting, yaitu: COMPANYNAME merupakan nama perusahaan tujuan INVOICE, ADDRESS merupakan alamat jalan, CITY merupakan kota dari alamat, STATE merupakan Negara bagian atau provinsi, IDCOUNTRY merupakan Negara yang referensi ke tabel MSCOUNTRY, dan ZIPCODE merupakan kodepos. Nama Field Tipe Data Panjang Keterangan IDSHIPPINGADDRESS NUMBER Id

MsInvoiceAddress

COMPANYNAME VARCHAR 30 Nama perusahaan

penerima

penerima barang

ADDRESS VARCHAR 50 Alamat

IDCOUNTRY NUMBER Negara, Foreign

Key ke tabel MsCountry

ZIPCODE VARCHAR 10 Kode Pos

(60)

3.2.7.16 Tabel MsStaff

Tabel MSSTAFF adalah tabel yang menampung daftar karyawan. Di dalam tabel MSSTAFF ada 5 atribut penting, yaitu: NIP merupakan Nomor Induk Karyawan ayng diberikan oleh divisi HRD, NAME merupakan nama lengkap karyawan, POSITION merupakan posisi dan jabatan karyawan di divisi tertentu, DIVISION merupakan divisi dari suatu karyawan, dan PASSWORD merupakan kata kunci untuk masuk ke aplikasi. Nama Field Tipe Data Panjang Keterangan

IDSTAFF NUMBER Id Msstaff

NIP VARCHAR 8 No Induk Pegawai

NAME VARCHAR 30 Nama pegawai

POSITION VARCHAR 12 Posisi pegawai

DIVISION VARCHAR 12 Divisi dari pegawai

PASSWORD VARCHAR 20 Kata sandipegawai

(61)

3.2.7.17 Tabel MsTagApproval

Tabel MSTAGAPPROVAL adalah tabel yang menampung informasi dari suatu organisasi yang berhak mengesahkan AAT. Di dalam tabel MSTAGAPPROVAL terdapat TAGAPPROVAL dimana ada dua organisasi besar yaitu FAA-8130 dan JAA-8130

IDTAGAPPROVAL NUMBER Id MstagApproval

TAGAPPROVAL VARCHAR 10 Pengakuan tag

biasanya dari FAA-8130 atau JAA-FAA-8130 Tabel 3.30 Tabel MsTagApproval

(62)

3.2.7.18 Tabel PackingList

Tabel PACKINGLIST adalah tabel yang menampung informasi paket pengirimanpart dari suatu supplier. Di dalam tabel PACKINGLIST ada empat atribut penting, yaitu: NOPACKINGLIST merupakan no fisik dari dokumen PACKINGLIST, ISSUEDDATE merupakan tanggal penerbitan dokumen Packinglist, IDINVOICE merupakan referensi ke data

Invoice yang berkaitan dengan Packinglist, dan STATUS merupakan status dari INVOICE tersebut. Ada 3 kemungkinan status untuk suatu Packinglist yaitu: NEW, VALID, dan FRAUD.

Nama Field Tipe Data Panjang Keterangan IDPACKINGLIST NUMBER Id PackingList

NOPACKINGLIST VARCHAR 20 No Tag

ISSUEDDATE DATE Tanggal berlakunya

dokumen Packinglist

IDINVOICE NUMBER Foreign Key ke table

Invoice

STATUS NUMBER Status dari Packinglist. ‘0’ untuk ‘New’, ‘1’

untuk ‘Valid’, dan ‘2’ untuk ‘Fraud’

(63)

3.2.7.19 Tabel PartCatalog

Tabel PARCATALOG adalah tabel yang menampung informasi catalog dari part. Di dalam tabel PARTCATALOG ada delapan atribut penting, yaitu: PARTNUMBER merupakan nomor fisik dari suatu part yang diberikan oleh vendor, IDPARTKEYWORD merupakan referensi Part Keyword untuk suatu part,

IDPARTCATEGORY merupakan referensi kategori dari suatu part, IDREFERENCETYPE merupakan referensi tipe dari suatu referensi IPC, UNITOFMEASUREMENT merupakan satuan yang berlaku untuk part, SHELFTIME merupakan lama penyimpanan part yang dianjurkan, ALTERNATEFLAG merupakan penanda jika suatu part adalah alternate, dan TYPEOFPART merupakan tipe dari part. Untuk tipe dari suatu part ada tiga kemungkinan yaitu: CHEMICAL, ROTABLE, dan CONSUMABLE.

(64)

IDPARTCATALOG NUMBER Id Aat

PARTNUMBER VARCHAR 20 No part

IDPARTKEYWORD NUMBER Foreign Key ke

table

Mspartkeyword

IDPARTCATEGORY VARCHAR 40 Pemakai terakhir part

IDREFERENCETYPE NUMBER Foreign Key ke table

MsreferenceType UNITOFMEASUREMENT VARCHAR 3 Satuan

SHELFTIME NUMBER Max lama

penyimpanan yang dianjurkan, dalam hari

ALTERNATEFLAG NUMBER Flag dari

alternate

TYPEOFPART VARCHAR 30 Tipe part

(65)

3.2.7.20 PO

Tabel PO adalah tabel yang menampung informasi Purchase Order. Di dalam tabel PO ada delapan atribut penting, yaitu: NOPO merupakan nomor publikasi dari suatu Purchase Order,

IDDTLQUOTATION merupakan referensi quotation yang merupakan dasar suatu Purchase Order diterbitkan, ISSUEDDATE merupakan tanggal mulai berlakunya suatu

Purchase Order, IDINVOICEADDRESS merupakan referensi alamat pengiriman Invoice, IDSHIPPINGADDRESS merupakan referensi alamat pengiriman barang, PAYMENTMETHOD merupakan metode pembayaran yang berlaku untuk suatu

Purchase Order, dan SPECIALINSTRUCTION merupakan instruksi atau perintah khusus jika ada. Untuk PAYMENTMETHOD ada tiga kemungkinan yaitu CASH, CREDIT CARD, B/G, dan CHEQUE

(66)

IDPO NUMBER Id PO

NOPO VARCHAR 20 No Purchase Order

IDDTLQUOTATION NUMBER Foreign Key ke

table DtlQuotation

ISSUEDDATE DATE 40 Tanggal berlaku PO

EXPDATE NUMBER Tanggal

berakhirnya PO IDINVOICEADDRESS NUMBER Foreign Key ke

table

MsInvoiceAddress IDSHIPPNGADDRESS NUMBER Foreign Key ke

table

MsShippingAddress

PAYMENTMETHOD VARCHAR 30 Metode

pembayaran yang diinginkan

SPECIALINSTRUCTION VARCHAR 50 Instuksi khusus Tabel 3. 33 Tabel PO

(67)

3.2.7.21 Tabel Quotation

Tabel QUOTATION adalah tabel informasi quotation. Di dalam tabel QUOTATION terdapat 12 atribut penting yaitu: NOQUOTATION merupakan nomor publikasi quotation, IDRFQ merupakan referensi Request For Quotation sebagai dasar untuk menerbitkan Quotation, ISSUEDDATE merupakan tanggal mulai berlakunya Quotation, EXPDATE merupakan tanggal habis masa berlakunya Quotation, MISCCHARGE merupakan harga lain-lain yang ditambahkan, SHIPPINGCHARGE merupakan ongkos pengiriman yang ditambahkan, STATUS merupakan status Quotation, IDQUOTEDPART merupakan referensi part yang masuk kedalam Quotation, LEADTIME merupakan jangka waktu ketersediaan barang (dalam hari), IDSUPPLIER merupakan referensi Supplier yang menerbitkan Quotation,

QUANTITY meruapakan kuantitas yang dapat disediakan oleh

Supplier, dan IDCURRENCY merupakan mata uang yang berlaku untuk Quotation.

Nama Field Tipe Data Panjang Keterangan IDQUOTATION NUMBER Id Quotation NOQUOTATION VARCHAR 20 No Quotation

IDRFQ NUMBER Foreign Key ke table

Rfq

(68)

Quotation

EXPDATE DATE Tanggal berakhirnya

Quotation

MISCCHARGE NUMBER Ongkos lain-lain

SHIPPINGCHARG E

NUMBER Ongkos pengiriman

STATUS NUMBER Status Quotation

IDQUOTEDPART NUMBER Foreign Key ke table Mstagapproval

QuotedPart

LEADTIME NUMBER Lama waktu stock

barang. Dalam hari IDSUPPLIER NUMBER Foreign Key ke table

Suppliercompany QUANTITY NUMBER Kuantitas yang tersedia IDCURRENCY NUMBER Foreign Key ke table

Currency

(69)

3.2.7.22 Tabel Quoted Part

Tabel QUOTEDPART adalah tabel yang informasi part yang ada didalam Quotation. Di dalam tabel QUOTEDPART terdapat lima atribut penting, yaitu: SERIALNUMBER merupakan Serial Number dari part, IDPARTCATALOG merupakan referensi part catalog untuk part tersebut, IDAAT merupakan referensi Aircraft Airworthiness Tag untuk part tersebut, IDPARTCONDITION merupakan referensi kondisi dari part, ALTERNATEFLAG merupakan penanda apakah part tersebut Alternate.

IDQUOTEDPART NUMBER Id Quotedpart

SERIALNUMBER VARCHAR 50 Serialnumber dari part yang ditawarkan IDPARTCATALOG NUMBER Foreign Keyke table

Partcatalog

IDAAT NUMBER Foreign Keyke table

Aat

IDPARTCONDITION NUMBER Foreign Keyke table MsPartcondition ALTERNATEFLAG NUMBER Flag untuk alternate

(70)

3.2.7.23 RFQ

Tabel RFQ adalah tabel yang menampung informasi

Request for Quotation yang merupakan permintaan Quotation

kepada Supplier. Di dalam tabel RFQ terdapat lima atribut penting, yaitu: NORFQ merupakan nomor publikasi dari Request

for Quotation, IDMATERIALREQUESTFORPURCHASE

merupakan referensi Material Request for Purchase sebagai dasar untuk pembuat Request forQuotation, ISSUEDDATE merupakan tanggal mulai berlakunya Request for Quotation, EXPDATE merupakan tanggal berakhirnya Request for Quotation, RFQSTATUS merupakan status dari suatu Request for Quotation.

IDRFQ NUMBER Id Rfq

NORFQ VARCHAR 20 No Request For

Quotation

IDMATERIALR EQUESTFORPU RCHASE

NUMBER Foreign Key ke table DtlMaterialRequestForPu rchase

ISSUEDDATE DATE 40 Tanggal berlakunya Rfq

EXPDATE DATE Tanggal berakhirnya

masa berlaku Rfq RFQSTATUS NUMBER Status dari Rfq

(71)

3.2.7.24 Tabel SupplierCompany

Tabel SUPPLIERCOMPANY adalah tabel yang menampung informasi perusahaan Supplieri yang terdaftar. Di dalam tabel SUPPLIERCOMPANY ada 13 atribut penting, yaitu: COMPANYNAME meruapakan nama resmi perusahaan,

ADDRESSLINE1 merupakan alamat baris pertama, ADDRESSLINE2 merupakan alamat baris kedua, CITY merupakan kota perusahaan, STATE merupakan Negara bagian atau provinsi perusahaan, IDCOUNTRY merupakan referensi Negara perusahaan , ZIPCODE merupakan kodepos, PHONE merupakan nomor telepon perusahaan, WEBSITE meruapakan alamat website persuahaan, REGISTERDATE merupakan tanggal daftar perusahaan di sistem eProcurement,

SURVEYEDDATE merupakan tanggal perusahaan tersebut di survey oleh Purchasing Coordinator Staff, dan SURVEYEDBY merupakan Purchasing Coordinator Staff yang mensurvey.

IDSUPPLIERCOMPANY NUMBER Id

Suppliercompany COMPANYNAME VARCHAR 50 Nama

perusahaan Supplier

(72)

ADDRESSLINE2 VARCHAR 50 Alamat2

IDCOUNTRY NUMBER Foreign Key ke

table MsCountry

ZIPCODE VARCHAR 5 Kodepos

PHONE VARCHAR 30 Nomer telephone

FAX VARCHAR 30 Nomer fax

WEBSITE VARCHAR 50 Alamat Website

REGISTERDATE DATE Tanggal daftar

SURVEYEDBY NUMBER Yang mensurvey,

Foreign Key ke table Msstaff

SURVEYEDDATE DATE Tanggal survey

(73)

3.2.7.25 Tabel SupplierNotification

Tabel SUPPLIERNOTIFICATION adalah tabel yang dipakai oleh aplikasi untuk menyimpan informasi notifikasi ke Supplier Representative ketika masuk ke website eProcurement. Di dalam tabel SUPPLIERNOTIFICATION ada tiga atribut penting, yaitu: IDSUPPLIERREORESENTATIVE merupakan referensi

Supplier Representative untuk suatu notifikasi, TOTALPO merupakan jumlah total Purchase Order baru, dan TOTALINVOICE meruapakan jumlah Invoice baru .

Nama Field Tipe Data Panjang Keterangan IDSUPPLIERNOTIFI CATION NUMBER Id SupplierNotification IDSUPPLIERREPRES ENTATIVE

VARCHAR 20 Foreign Key ke table Supplierrepresentative

TOTALPO NUMBER Notifikasi jumlah PO

yang baru masuk

TOTALINVOICE NUMBER Notifikasi jumlah

Invoiceyang baru

masuk Tabel 3. 38 Tabel SupplierNotification

(74)

3.2.7.26 SupplierRepresentative

Tabel SUPPLIERREPRESENTATIVE adalah tabel yang menampung informasi representative dari suatu supplier. Di dalam tabel SUPPLIERREPRESENTATIVE ada 8 atribut penting, yaitu: IDSUPPLIER merupakan Foreign Key ke tabel SUPPLIER sebagai referensi, NAME merupakan nama dari

Supplier Representative, PHONE merupakan nomor telepon dari

Supplier Representative dengan format internasional, FAX meruapakan nomor fax dari Supplier Representative dengan format internasional, EMAIL merupakan alamat email dari

Supplier Representative, MOBILE meruapakan nomor telepon genggam dari Supplier Representative, USERNAME merupakan

Username ketika akan login ke website eProcurement, dan PASSWORD merupakan kata kunci untuk masuk ke website eProcurement.

(75)

Nama Field Tipe Data Panjang Keterangan IDSUPPLIERREP

RESENTATIVE

NUMBER Id Supplier Representative kode panggil aplikasi

IDSUPPLIER VARCHAR 20 Foreign Key ke tabel Supplier

NAME DATE Nama

PHONE VARCHAR 40 No telephone

FAX NUMBER No fax

EMAIL VARCHAR 50 Alamat surat elektronik MOBILE VARCHAR 30 No telephone mobile

USERNAME VARCHAR 20 Nama pengguna

PASSWORD VARCHAR 20 Kata sandi

(76)

3.2.7.27 Tabel Tender

Tabel TENDER adalah tabel yang menampung informasi mengenai Tender yang telah dipublikasi di website eProcurement. Di dalam tabel TENDER ada tiga atribut penting, yaitu: NOTENDER merupakan nomor publikasi dari suatu

Tender, IDRFQ merupakan referensi Request for Quotation

untuk Tender, dan TENDERSTATUS merupakan status dari suatu tender. Ada tiga kemungkinan status dari suatu Tender yaitu: OPEN, CLOSED, dan ERROR.

IDTENDER NUMBER Id Tender

NOTENDER VARCHAR 30 No Tender

IDRFQ NUMBER Foreign Key ke table

Rfq

TENDERSTATUS VARCHAR 6 Status untuk Tender