BAB 4.
PERANCANGAN
Perancangan merupakan proses yang dilakukan oleh perancang sistem untuk mengerjakan spesifikasi sistem, membuat keputusan tentang bagaimana komponen sistem diaktualisasikan. Proses ini menyangkut tujuan, fungsi dan informasi dari sistem tersebut. Perancangan yang baik harus mengetahui bagaimana cara sistem mewujudkan tujuan dari perancangan aplikasi ini.
Prosedur yang dilakukan dalam perancangan aplikasi penjualan konsinyasi ini adalah sebagai berikut:
4.1.Perancangan Algoritma
Dalam mendefinisikan algoritma, kita harus dapat mendefinisikan tiga hal utama dengan jelas, yaitu:
1. Masalah, yaitu sebuah persoalan yang ingin diselesaikan oleh sebuah algoritma.
2. Masukan, yaitu contoh data atau keadaan yang menjadi permasalahan. 3. Keluaran, yaitu bentuk akhir dari data atau keadaan setelah algoritma
diimplementasikan ke masukan. Keluaran merupakan hasil ideal yang diinginkan dan dianggap telah menyelesaikan masalah.
Perancangan algoritma membantu mengembangkan daya penalaran atau kerangka berpikir yang sistematis dalam memeahami masalah dan membuat prencanaan atau konsep pemecahan masalah yang lebih baik sehingga dapat menghasilkan perancangan yang baik pula.
Berikut adalah perancangan algoritma untuk aplikasi penjualan konsinyasi PT Retail Department Store:
Gambar 4-1Algoritma proses Aplikasi Penjualan Konsinyasi Penjelasan Algoritma proses Aplikasi Penjualan Konsinyasi:
Tabel 4-1 Proses Algoritma 1 No. Proses 1
Nama Proses Consignment Server push data Tipe Proses Drive by external system (push data)
Kegiatan Proses Point of Sales, yang akan di-generate datanya secara harian. Tabel 4-2 Proses Algoritma 2
No. Proses 2
Nama Proses Collect Sales Data
Vendor Consignment System Consignment Server
From SMTP Tidak Ya FTP Server 2. Collect Sales Data (harian) Proses Ulang? 3b. Relod Sales 3a.SALES ALL 4. Generate Proforma Send to Vendor Proforma Inquiry Mulai 1. Consignment Server Selesai
Tipe Proses Background by scheduler
Kegiatan Data point of sales hasil generate server akan diambil (collect) oleh sistem by scheduler (daily).
Tabel 4-3 Proses Algoritma 3a No. Proses 3a
Nama Proses Data sales all
Tipe Proses Background by scheduler
Kegiatan Hasil generate dari Consignment server. Tabel 4-4 Proses Algoritma 3b No. Proses 3b
Nama Proses Reload Sales Tipe Proses Online
Kegiatan Unggah Data Sales.all melalui UI kemudian jalankan Store Procedure (PL/SQL). Proses PL/SQL akan memindahkan data ke History Sales dan menghapus data yang diunggah sebelumnya. Kemudian loading ulang sales dengan menjalankan PL/SQL.
Tabel 4-5 Proses Algoritma 4 No. Proses 4
Nama Proses Generate Proforma, Send to Vendor, dan Proforma Inquiry Tipe Proses Online
Kegiatan Generate Proforma dieksekusi secara online dari web dan dijalankan pada awal periode berikutnya. Sedangkan Proforma Inquiry digunakan untuk melihat data Proforma hasil generate (read only).
4.1.1 Use Case Diagram
Use case mendeskripsikan interaksi tipikal antara para pengguna sistem dengan sistem itu sendiri, dengan memberi sebuah narasi tentang bagaimana
sistem tersebut digunakan use case Diagram menampilkan aktor mana yang menggunakan use case mana, use case mana yang memasukkan use case lain dan hubungan antara aktor dan use case.
Berikut use case diagram sistem berjalan dan use case diagram sistem usulan :
Gambar 4-2 Use Case Diagram Sistem Berjalan Penjelasan use case sistem berjalan:
a. Admin melakukan penginputan laporan penjualan secara manual ke form Microsoft Excel
b. Laporan penjualan diprint oleh Admin.
c. Setelah laporan penjualan diambil oleh pihak Vendor dan pihak Vendor menerbitkan kwitansi, Admin menerima kwitansi untuk selanjutnya diproses pembayaran.
Gambar 4-3 Use Case Diagram Sistem Usulan Penjelasan use case sistem usulan:
a. Admin mengunggah laporan penjualan ke database. b. Admin menggenerate Proforma ke sistem.
c. Untuk memastikan generate Proforma berhasil, Admin melihat hasil generate Proforma di menu Inquiry Proforma.
d. Hasil generate Proforma berupa Monthly Sales Summary diunduh dari sistem, lalu diemail manual ke pihak Vendor.
e. Admin dan manager dapat mencetak laporan penjualan. 4.1.2 Use Case scenario
Setiap Use case harus dijelaskan alur prosesnya melalui sebuah deskripsi use case atau Use Case scenario.
Use Case scenario berisi:
a. Nama use case yaitu penamaan use case yang menggunakan kata kerja.
b. Deskripsi yaitu penjelasan mengenai tujuan use case dan nilai yang akan didapatkan oleh aktor.
c. Kondisi sebelum (pre-condition) yaitu kondisi-kondisi yang perlu ada sebelum use case dilakukan.
d. Kondisi sesudah (post-condition) yaitu kondisi-kondisi yang sudah dipenuhi ketika use case sudah dilaksanakan.
e. Alur dasar (basic flow) yaitu alur yang menceritakan jika semua aksi yang dilakukan adalah benar atau proses yang harusnya terjadi.
f. Alur alternatif (alternative flow) yaitu alur yang menceritakan aksi alternatif, yang berbeda dari alur dasar.
Berdasarkan use case diagram pada gambar diatas, ilustrasi scenario per use case adalah sebagai berikut :
1. Use Case Scenario Login
Tabel 4-6 Use Case Scenario login
Use Case Login
Aktor Admin
Deskripsi Pengguna harus melakukan login terlebih dahulu Skenario Utama
Kondisi Awal Tampilan halaman depan web
Aktor Sistem
1. Menampilkan halaman depan web 2. Mengisi data login
3. Menekan tombol login 4. Proses autentikasi login 5. Menampilkan halaman home Skenario Alternatif jika data tidak ditemukan
1. Menampilkan pesan data login salah 2. Mengisi data login kembali
3. Menekan tombol login 4. Proses autentikasi login 5. Menampilkan halaman home Kondisi Akhir Menampilkan halaman home
2. Use Case Scenario Mengunggah Data Penjualan
Tabel 4-7 Use Case Scenario mengunggah data penjualan Use Case Mengunggah Data Penjualan
Aktor Admin
Deskripsi Data penjualan yang berhasil di generate dari server consignment diunggah ke database stagging.
Skenario Utama Kondisi Awal Tampilan halaman utama
Aktor Sistem
1. Menampilkan halaman utama 2. Masuk ke menu Reload Sales
3. Pilih Browse untuk mencari file penjualan
3. Cari dan pilih file dengan extension “.all”
4. Setelah pilih file klik submit untuk mengunggah data penjualan
5. Menginput data penjualan ke dalam database.
6. Menampilkan pesan “Process Loading Sales file xxxx.all tanggal dd-mmm-yyyy berhasil” Skenario Alternatif jika data tidak ditemukan
1. Menampilkan pesan “Process Loading Sales file xxxx.all tanggal dd-mmm-yyyy gagal.” 2. Jika extension file bukan xxxx.all maka akan menampilkan pesan “File yang diupload salah 3. Kembali ke halaman utama.
Kondisi Akhir Menampilkan pesan “process Loading Sales file xxxx.all tanggal dd-mmm-yyyy berhasil”
3. Use Case Scenario Meng-generate Proforma
Tabel 4-8 Use Case Scenario meng-generate Proforma Use Case Meng-generate Proforma
Aktor Admin
Deskripsi Meng-generate Proforma di dalam aplikasi Skenario Utama
Kondisi Awal Tampilan halaman utama
Aktor Sistem
1. Menampilkan halaman utama 2. Masuk ke menu Generate
Proforma
3. Menekan tombol submit 4. Pesan “Success submit generate Proforma”
Skenario Alternatif jika data tidak ditemukan
1. Menampilkan pesan “submit gagal” Kondisi Akhir Menampilkan pesan “Success submit generate Proforma”
4. Use Case Scenario Melihat Hasil Generate Proforma
Tabel 4-9 Use Case Scenario Melihat Hasil Generate Proforma Use Case Melihat Hasil Meng-generate Proforma
Aktor Admin
Deskripsi Melihat data penjualan yang berhasil di-generate Skenario Utama
Kondisi Awal Tampilan halaman utama
Aktor Sistem
1. Menampilkan halaman utama 2. Ke menu Proforma Inquiry
3. Masukkan parameter
dicari
Skenario Alternatif jika data tidak ditemukan 1. Pesan no data available in tabel Kondisi Akhir Menampilkan hasil generate Proforma yang dicari
5. Use Case Scenario Mengunduh Hasil Generate Proforma
Tabel 4-10 Use Case Scenario mengunduh hasil Generate Proforma Use Case Mengunduh Hasil generate Proforma
Aktor Admin
Deskripsi Mengunduh hasil generate Proforma berupa Monthly Sales Summary
Skenario Utama Kondisi Awal Tampilan halaman utama
Aktor Sistem
1. Menampilkan halaman utama 2. Masuk ke menu Report
3. Pilih sub-menu Monthly Sales Summary
4. Masukkan parameter
5. Klik tombol “submit” 6. Proses membuat Monthly Sales Summary dalam bentuk file .pdf
7. Unduh file Monthly Sales Summary
8. Mengunduh file Monthly Sales Summary
Skenario Alternatif jika data tidak ditemukan
1. Menampilkan pesan no data available in tabel
6. Scenario Mencetak Laporan Penjualan
Tabel 4-11Use Case Scenario Mencetak Laporan Penjualan Use Case Mencetak Laporan Penjualan
Aktor Admin dan Manager
Deskripsi Mencetak Laporan Penjualan Skenario Utama Kondisi Awal Tampilan halaman utama
Aktor Sistem
1. Menampilkan halaman utama 2. Masuk ke menu Report
3. Pilih Report Sales 4. Masukkan parameter
5. Klik tombol “submit” 6. Proses membuat Report Sales 7. Cetak Report Sales
8. Preview cetakan Report Sales Skenario Alternatif jika data tidak ditemukan
1. Menampilkan pesan “kesalahan penyebab kegagalan”
Kondisi Akhir Report Sales bisa dicetak oleh Admin dan Manager
4.1.3 Activity Diagram
Dalam beberapa hal, activity diagram memainkan peran mirip diagram alir, tetapi perbedaan prinsip antara notasi diagram alir adalah activity diagram mendukung behavior paralel. Node pada sebuah activity diagram disebut sebagai action, sehingga
diagram tersebut menampilkan sebuah activity yang tersusun dari action.
Berikut ini penjelasan dengan activity diagram untuk masing-masing Use Case scenario:
1. Activity Diagram Login
Gambar 4-4 Activity Diagram Login
2. Activity Diagram Mengunggah Data Penjualan
3. Activity Diagram Generate Proforma
Gambar 4-6 Activity Diagram Generate Proforma
4. Activity Diagram Melihat Hasil Generate Proforma
5. Activity Diagram Mengunduh Hasil Generate Proforma
6. Activity Diagram Mencetak Laporan Penjualan
Gambar 4-9 Activity Diagram Mencetak Laporan Penjualan 4.1.4 Sequence Diagram
Sequence diagram menggambarkan kelakuan objek pada use case dengan
mendeskripsikan waktu hidup objek dan message yang dikirimkan dan diterima antar objek. Sequence diagram menggambarkan interaski antar objek di dalam dan di sekitar system berupa message yang digambarkan terhadap waktu. Berikut Sequence diagram yang dapat diambil dari penggambaran skenario use case:
1. Sequence diagram Login
Interaksi antara aktor dengan use case login dijelaskan dalam Sequence diagram sebagai berikut:
Gambar 4-10 Sequence diagram Login
a. Admin mengisi data login berupa username dan password. b. Admin menekan tombol “submit login”.
c. Sistem melakukan validasi login dan mengecek kebenaran login. d. Jika data login benar maka sistem akan masuk ke halaman utama. e. Jika data login salah maka sistem akan kembali menampilkan halaman
depan.
2. Sequence diagram Mengunggah Data Penjualan
Mengunggah data penjualan yang dilakukan oleh admin bertujuan untuk mengunggah data penjualan ke database aplikasi penjualan konsinyasi. Adapun sequnce diagram dari mengunggah data penjualan sebagai berikut:
a. Admin memilih menu “Reload Sales” b. Admin mencari file dengan extension .all
c. Admin memilih file dan menekan tombol submit untuk proses input ke tabel App_Sales.
d. Sistem melakukan proses input ke database
e. Jika proses input berhasil maka akan menampilkan pesan “Process loading Sales file xxxx.all tanggal dd-mmm-yyyy berhasil”.
f. Jika proses input gagal atau extension file berbeda maka sistem akan kembali menampilkan halaman utama.
3. Sequence diagram Menggenerate Proforma
Data penjualan yang berhasil diunggah ke database akan digenerate Proforma pada menu generate Proforma, berikut Sequence diagram dari menggenerate Proforma:
Gambar 4-12 Sequence diagram Generate Proforma a. Admin memilih menu “Generate Proforma”.
b. Admin menekan tombol submit untuk menggenerate Proforma. c. Sistem melakukan proses generate Proforma.
d. Jika proses generate Proforma berhasil maka proforma akan masuk ke tabel App_Proforma.
e. Jika proses generate Proforma gagal maka sistem akan kembali menampilkan halaman utama.
4. Sequence diagram Melihat Hasil Generate Proforma
Untuk melihat apakah generate Proforma berhasil masuk ke database maka diperlukan cara untuk melihatnya, berikut sequnce diagram dari melihat hasil generate Proforma:
Gambar 4-13 Sequence diagram Melihat Hasil Generate Proforma a. Admin memilih menu “Inquiry Proforma”.
b. Admin memasukkan parameter dan menekan tombol “cari” c. Sistem melakukan proses generate Proforma.
d. Jika proses generate Proforma berhasil maka proforma akan masuk ke database.
e. Jika proses generate Proforma gagal maka sistem akan kembali menampilkan halaman utama.
5. Sequence diagram Mengunduh Hasil Generate Proforma
Untuk melihat apakah generate Proforma berhasil masuk ke database maka diperlukan cara untuk melihatnya, berikut sequnce diagram dari melihat hasil generate Proforma:
Gambar 4-14 Sequence Diagram Mengunduh Hasil Generate Proforma
6. Sequence diagram Mencetak Laporan Penjualan.
Admin dan Manager dapat mencetak laporan penjualan pada aplikasi penjualan konsinyasi.
4.1.5 Class Diagram
Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi). Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.
4.2. Perancangan Basis Data
Basis data merupakan kumpulan file-file yang mempunyai kaitan antara satu file lain dengan file lain sehingga membentuk suatu bangunan data untuk menginformasikan suatu perusahaan/instansi dalam batasan tertentu basis data merupakan salah satu komponen penting dalam sistem informasi karena basis data adalah dasar untuk menyediakan informasi bagi para pemakai.
ERD (Entity Relationship Diagram) merupakan suatu model untuk menjelaskan hubungan antar data dalam basis data berdasarkan objek-objek dasar data yang mempunyai hubungan antar relasi. ERD untuk memodelkan struktur data dan hubungan antar data, untuk menggambarkannya digunakan beberapa notasi dan simbol. Berikut skema ERD unutuk aplikasi penjualan konsinyasi pada PT Retail Department Store :
4.3.Perancangan Struktur Tabel
Perancangan struktur tabel merupakan salah satu hal yang paling utama dalam merancang sebuah aplikasi. Hal ini dikarenakan tabel-tabel tersebut digunakan dalam menyimpan data dalam aplikasi. Sehingga dalam proses pembuatannya diperlukan perancangan struktur tabel yang tepat agar tidak terjadi kesalahan yang berdampak kepada jalannya program. Berikut ini adalah struktur tabel pada aplikasi penjualan konsinyasi PT Retail Department Store :
1. Tabel App_Sales
Tabel ini berguna untuk menyimpan data barang yang berhasil terjual. Tabel 4-12Tabel App_Sales
Nama Kolom Tipe Data Keterangan
ID NUMBER (19) Primary Key
STORE_NO VARCHAR2 (5 Byte)
SALES_DATE DATE
SKU_NO VARCHAR2 (14 Byte)
DESCRIPTOR VARCHAR2 (50)
CLASS_NO VARCHAR2 (10 Byte)
QTY INTEGER
NETSALE NUMBER (12)
STAFF NUMBER (10)
NO_STAFF VARCHAR2 (40 Byte)
VIP NUMBER (10) ITEM_DISC NUMBER (10) SUPL_DISC NUMBER (10) DLR_DISC NUMBER (10) SUBDISC NUMBER (10) VCHR_CPN NUMBER (10) CRVCHR NUMBER (10) GVCHR NUMBER (10) VCHR_CHG NUMBER (10) AMT_CARD NUMBER (10)
CUST_ID VARCHAR2 (40 Byte)
TYPE_SKU VARCHAR2 (10 Byte)
BARCODE VARCHAR2 (20 Byte)
Nama Kolom Tipe Data Keterangan
STATUS VARCHAR2 (1 Byte)
KETERANGAN VARCHAR2 (50)
CS_OR_DP VARCHAR2 (2 Byte)
FILE_NAME VARCHAR2 (50) UPLOAD_DATE TIMESTAMP(6) CLASS_ID NUMBER (19) STORE_ID NUMBER (19) VENDOR_ID NUMBER (19) STAGING_ID NUMBER (19) CMC_DISC NUMBER (12) 2. Tabel App_Store
Tabel ini berguna menyimpan data store
Tabel 4-13 Tabel App_Store
Nama Kolom Tipe Data Keterangan
ID NUMBER (19) Primary Key
ADDR1 VARCHAR2 (50) ADDR2 VARCHAR2 (50) DESCRIPTION VARCHAR2 (50) NAME VARCHAR2 (50) PROFIT_STORE_CODE VARCHAR2 (50) CODE VARCHAR2 (50)
BUSINESS_UNIT VARCHAR2 (6 Byte) 3. Tabel App_Class
Tabel ini berguna menyimpan data department
Tabel 4-14 Tabel App_Class
Nama Kolom Tipe Data Keterangan
ID NUMBER (19) Primary Key
CODE VARCHAR2 (50)
NAME VARCHAR2 (50)
DEPARTMENT_ID NUMBER (19)
DESCRIPTION VARCHAR2 (50)
4. Tabel App_Vendor
Tabel ini berguna menyimpan data vendor
Tabel 4-15 Tabel App_Vendor
Nama Kolom Tipe Data Keterangan
ID NUMBER (19) Primary Key
ADDR1 VARCHAR2 (50) ADDR2 VARCHAR2 (50) ADDR3 VARCHAR2 (50) CODE VARCHAR2 (50) EMAIL VARCHAR2 (50) FAX VARCHAR2 (50) NAME VARCHAR2 (50) NPWP VARCHAR2 (50) TELP VARCHAR2 (50) PKP VARCHAR2 (1 Char) PAYDAYS NUMBER (10)
VEN_GLN VARCHAR2 (13 Byte)
5. Tabel App_Proforma
Tabel ini berguna menyimpan data proforma
Tabel 4-16 Tabel App_Proforma
Nama Kolom Tipe Data Keterangan
ID NUMBER (19) Primary Key
DESCRIPTION VARCHAR2 (50) GROSS_SALES NUMBER (19,2) MARGIN_AMT_CALC NUMBER (19,2) MARGIN_AMT_MDFY NUMBER (19,2) MARGIN_PCT_CALC NUMBER (19,2) MATCHED NUMBER (1) PAYMENT_CALC NUMBER (19,2) PAYMENT_MDFY NUMBER (19,2) POSTED NUMBER (1) PROFORMA_NO VARCHAR2 (50)
Nama Kolom Tipe Data Keterangan TOTAL_NETSALES NUMBER (19,2) USED NUMBER (1) CLASS_ID NUMBER (19) PROFORMA_PERIOD_ID NUMBER (19) STORE_ID NUMBER (19) VENDOR_ID NUMBER (19) DPP_AMT_CALC NUMBER (19,2) DPP_AMT_MDFY NUMBER (19,2) TAX_AMT_CALC NUMBER (19,2) TAX_AMT_MDFY NUMBER (19,2) PROFORMA_DATE DATE INVOICE_ID NUMBER
6. Tabel App_Proforma Period
Tabel ini berguna menyimpan data proforma period
Tabel 4-17 Tabel App_Proforma Period
Nama Kolom Tipe Data Keterangan
ID NUMBER (19) Primary Key
CODE VARCHAR2 (50)
DESCRIPTION VARCHAR2 (50)
DATE_FROM DATE
NAME VARCHAR2 (50)
STATUS VARCHAR2 (10 Char)
