BAB 3 DESKRIPSI UMUM 3.1 Profil Perusahaan 3.1.1 Sejarah...

37

BAB 3

DESKRIPSI UMUM

3.1 Profil Perusahaan

3.1.1 Sejarah PT. Dexa Medica

PT. Dexa Medica merupakan salah satu perusahaan farmasi terbesar di

Indonesia. Bermula dari sebuah perusahaan kecil, didirikan tahun 1969 di

Palembang oleh Drs. Rudy Soetikno bersama beberapa teman, PT. Dexa

Medica kini telah menjadi pemain yang disegani di pasar farmasi Indonesia.

Drs. Rudy Soetikno adalah seorang apoteker yang pernah mengabdikan diri

di TNI Angkatan Darat dan pernah bertugas di Kesdam II/Sriwijaya. Itu

sejarah awal mengapa PT. Dexa Medica didirikan di Palembang.

Dipicu oleh pasokan obat yang langka, Rudy Soetikno seorang

apoteker muda merasa bahwa dengan latar belakang pendidikan, ia dipanggil

untuk melakukan sesuatu menanggapi hal itu. Bersama dengan beberapa

teman, ia mulai memproduksi tablet sederhana di sebuah apotek kecil yang

mereka milik bersama dengan tujuan untuk memasok obat untuk Palembang

dan sekitarnya. Hal ini menandai awal dari Dexa. Nama dexa sendiri berasal

dari kata “deca” yang berarti sepuluh di mana sepuluh merupakan nilai

tertinggi sempurna yang mungkin diraih.

Pada tahun 1975 produk PT. Dexa Medica tersedia di seluruh

Sumatera. Pada tahun 1978, PT. Dexa Medica kemudian mengambil langkah

besar dengan menembus pasar Jawa melalui Surabaya. Hal ini ternyata

menjadi pintu untuk PT. Dexa Medica mencakup pasar Indonesia di mana

38

pada tahun tersebut, produk PT. Dexa Medica mulai didistribusikan ke

seluruh wilayah Indonesia.

Pada tahun 1984, PT. Dexa Medica memindahkan kantor

pemasarannya ke Jakarta. Sejak tahun 1994, penjualan domestik PT. Dexa

Medica telah tumbuh lebih tinggi dari pertumbuhan industri farmasi di

Indonesia.

Pada tahun 2001, PT. Ferron Phar Pharmaceutical didirikan untuk

menyediakan kapasitas produksi tambahan dan pemasaran untuk mendukung

pertumbuhan yang tinggi dan untuk mengantisipasi persaingan global.

Hingga kini, PT. Dexa Medica sudah memiliki 7 anak perusahaan yang

saling mendukung dalam industri farmasi PT. Dexa Medica.

PT. Dexa Medica kini juga sudah mencakup pasar global dan memiliki

cabang di beberapa negara seperti Filipina, Kamboja, Vietnam, Myanmar,

Sri Lanka, serta Nigeria.

PT. Dexa Medica memiliki pabrik utama yang berlokasi di Jl. Letjen

Bambang Utoyo 138, Palembang 30114, Indonesia dan berkantor di gedung

Titan Center, Jl. Boulevard Bintaro Blok B7/B1 No. 05, Bintaro Jaya Sektor

7, Tangerang 15224, Indonesia yang baru didirikan oleh PT. Dexa Medica

dan ditempati sejak Agustus 2009. Sebelumnya, PT. Dexa Medica berkantor

di Graha Elnusa lantai 5, Jl. TB Simatupang kav 1B, Cilandak 12560,

Jakarta, Indonesia.

Produk farmasi yang dihasilkan oleh PT. Dexa Medica terbagi menjadi

2 kategori utama yaitu obat yang bisa dibeli bebas (over the counter) dan

39

obat yang dapat dibeli dengan resep dokter. Produk obat yang bisa dibeli

dengan bebas diantara, Lytacur, Stimuno, Toxilite dan Vitafem.

Sedangkan produk obat yang bisa dibeli dengan resep dokter terbagi

menjadi 3 kategori yaitu obat bermerek (branded medicine) seperti Rhinos®

SR dan Remopain, obat generik berlogo (OGB) seperti Tramadol dan

Metoclopramide, obat yang bersifat meningkatkan kesehatan

(nutraceuticals) seperti Resvica dan Folamil.

Dengan tim manajemen yang sangat baik dan tetap fokus pada bisnis

inti yaitu produksi dan pemasaran produk-produk farmasi yang berkualitas,

PT. Dexa Medica selalu konsisten dalam mempertahankan posisinya sebagai

salah satu pemimpin pasar yang diakui secara nasional.

3.1.2 Visi dan Misi PT. Dexa Medica

Visi

Menjadi sebuah perusahaan terkemuka yang didedikasikan untuk

memberikan nilai tambah yang signifikan bagi kepentingan pelanggan,

mitra bisnis, stakeholder, melalui operasional yang efektif, efisien dan

berkesinambungan untuk mencapai “Kesehatan untuk Semua” secara

regional, nasional, maupun global.

40

Misi

Membangun kapasitas dan kompetensi farmasi dalam meningkat-

kan kualitas sistem pelayanan melalui:

o Selalu melakukan inovasi dan perbaikan-perbaikan.

o Meningkatkan pangsa pasar.

o Terdepan dalam harga.

o Membentuk aliansi-aliansi strategis.

3.2 Struktur dan Peran Organisasi

3.2.1 Struktur Organisasi Informasi PT. Dexa Medica

Gambar 3.1 Struktur Organisasi Informasi PT. Dexa Medica

3.2.2 Peran

Struktur organisasi untuk bagian informasi pada PT. Dexa Medica

terbagi menjadi beberapa departemen yang tersusun dari beberapa bagian

dengan peranan sebagai berikut.

41

1. President Director

Mengarahkan dan mengawasi jalannya seluruh kegiatan organisasi

agar sesuai dengan visi misi yang telah ditetapkan.

Menetapkan gagasan serta kebijakan organisasi untuk jangka

waktu pendek maupun panjang.

Bertanggung jawab terhadap kegiatan organisasi yang dipimpin

secara hukum.

2. Chief Information Officer (CIO)

Bertanggung jawab akan kebutuhan teknologi informasi yang

diperlukan perusahaan.

Mengenali pengaruh teknologi informasi terhadap organisasi,

menentukan arah serta strategi teknologi informasi yang menjamin

adanya kesesuaian dengan strategi bisnis.

Mengarahkan integritas data dan informasi perusahaan serta unit

bisnis.

Mengembangkan rencana strategis dan mengimplementasikan

tujuan kebutuhan teknologi informasi perusahaan untuk

memastikan kemampuan komputer dapat responsif terhadap

kebutuhan pertumbuhan dan tujuan perusahaan.

3. Management Information System

Bagian Management Information System (MIS) berfungsi untuk

mencari dan mengumpulkan data-data yang dibutuhkan oleh organisasi

serta mengolah data-data tersebut secara efektif sehingga meng-

hasilkan informasi yang bermanfaat bagi organisasi.

42

4. IT Deployment

Menyediakan aplikasi-aplikasi bisnis maupun aplikasi untuk

customer yang diperlukan perusahaan, baik itu membeli kemudian

dikembangkan dan dikonfigurasi agar sesuai dengan kebutuhan

ataupun membangun dari awal.

5. IT System Operation

Bertanggung jawab terhadap kinerja perangkat keras di organisasi.

Menyediakan kebutuhan organisasi yang berkaitan dengan

perangkat keras.

6. System Analyst

Bertugas merancang sistem ataupun aplikasi yang diperlukan oleh

organisasi berdasarkan user requirement mulai dari menganalisa

hingga membangun sistem dari logical design hingga user

interface.

3.3 Ruang Lingkup Pekerjaan

Gambar 3.2 Perusahaan-perusahaan Dexa Group

43

Dalam menyelesaikan internship pada PT. Dexa Medica yang berlokasi di

Titan Center Jalan Boulevard Bintaro Block B7/B1 No. 05, Bintaro Jaya Sector 7,

Tangerang 15224, Indonesia Telepon: (+62-21) 7454 11, Fax. (+62-21) 7454 111,

pekerjaaan utama yang dilakukan adalah turut serta dalam proyek pembangunan

data warehouse untuk PT. Dexa Medica dan PT. Ferron Phar Pharmaceuticals di

mana keduanya merupakan perusahaan di bawah naungan Dexa Group.

Kegiatan internship pada PT. Dexa Medica dilakukan sejak 12 Juli 2010

hingga 13 September 2010. Adapun ruang lingkup pekerjaan yang dilakukan selama

internship ini terbagi menjadi 6 bagian, yaitu perancangan dan implementasi tabel

fakta deposito, valas, pajak PPh, pajak PPN, formula dan performa supplier.

3.3.1 Tabel Fakta Deposito (FACT_DEPOSITO)

Tabel fakta deposito merupakan bagian dari divisi keuangan PT. Dexa

Medica. Tabel fakta deposito tersebut memuat data-data deposito uang PT.

Dexa Medica yang ingin ditampilkan kepada user berdasarkan keputusan

perusahaan yang disesuaikan dengan kebutuhan informasi user tentang

deposito tersebut. Untuk membuat sebuah tabel fakta digunakan konsep

ETL (Extraction Transformation Loading) dengan tools Oracle Warehouse

Builder 11g R2.

Tabel fakta deposito ini dibuat pada dua data warehouse yang berbeda

yaitu dwhfpp untuk FPP dan dwhdxm untuk DXM. Untuk menyelesaikan

tabel fakta deposito pada masing-masing data warehouse, diperlukan dua

tahap proses pemetaan (mapping) pada Oracle Warehouse Builder 11g R2,

yaitu pemetaan untuk membuat tabel staging deposito (STG_FACT_DEPOSITO)

44

dan pemetaan untuk membuat tabel fakta deposito yang datanya bersumber

dari tabel staging deposito.

Sumber data untuk tabel staging deposito tersedia dalam format .xls.

Karena itu, agar data tersebut dapat diolah dengan Oracle Warehouse

Builder 11g R2, maka data tersebut harus divalidasi dan dikonversi ke dalam

bentuk text file. Setelah itu, text file tersebut akan di-import ke dalam data

warehouse dwhfpp untuk data FPP dan data warehouse dwhdxm untuk data

DXM. Text file tersebut kemudian akan dijadikan external table pada data

warehouse masing-masing. Proses pemindahan data dari bentuk asli hingga

menjadi external table dilakukan pada minggu I dan minggu II (lebih detail

mengenai timeline kegiatan ini dapat dilihat pada log book halaman 1 – 2).

External table tersebut akan menjadi sumber data pada proses

pemetaan (mapping) yang menghasilkan tabel staging deposito pada skema

dwhfpp untuk data FPP dan skema dxm_staging untuk data DXM.

Kemudian, data yang sudah tersimpan pada tabel staging deposito akan

menjadi sumber data dalam proses pemetaan yang menghasilkan tabel target

yaitu tabel fakta deposito pada skema dwhfpp untuk data FPP dan dxm_dwh

untuk data DXM. Di mana pada pemetaan ini, data dari sumber akan di-join

dengan tabel dimensi yang dibutuhkan sesuai dengan kondisi tertentu.

Analisis dan perancangan serta implementasi proses ETL hingga

menghasilkan tabel fakta deposito ini dilakukan pada minggu III hingga

minggu V (lebih detail mengenai timeline kegiatan ini dapat dilihat pada log

book halaman 3 – 5).

45

Proses penyelesaian tabel fakta deposito (FACT_DEPOSITO) akan

diuraikan dengan lebih jelas pada Bab 4.

3.3.2 Tabel Fakta Valas (FACT_VALAS)

Tabel fakta valas merupakan bagian dari divisi keuangan PT. Dexa

Medica. Tabel fakta valas tersebut memuat data-data transaksi pertukaran

mata uang PT. Dexa Medica (DXM) dan PT. Feron Phar Pharmaceuticals

(FPP) yang merupakan anak perusahaan dari Dexa Group, yang ingin

ditampilkan kepada user berdasarkan keputusan perusahaan yang

disesuaikan dengan kebutuhan user informasi tentang pertukaran mata uang.

Untuk membuat sebuah tabel fakta digunakan konsep ETL (Extraction

Transformation Loading) dengan tools Oracle Warehouse Builder 11g R2.

Tabel fakta valas ini dibuat pada dua data warehouse yang berbeda

yaitu dwhfpp untuk data dari FPP dan dwhdxm untuk data dari DXM.

Untuk menyelesaikan tabel fakta valas pada masing-masing data warehouse,

diperlukan dua tahap proses pemetaan (mapping) pada Oracle Warehouse

Builder 11g R2, yaitu pemetaan untuk membuat tabel staging valas

(STG_FACT_VALAS) dan kemudian pemetaan untuk membuat tabel fakta

valas yang datanya bersumber dari tabel staging valas.

Sumber data untuk tabel staging valas tersedia dalam format .xls.




warehouse dwhfpp untuk data dari FPP dan data warehouse dwhdxm untuk

46

data dari DXM. Text file tersebut kemudian akan dijadikan external table

pada data warehouse masing-masing. Proses pemindahan data dari bentuk

asli hingga menjadi external table dilakukan pada minggu I dan minggu II

(lebih detail mengenai timeline kegiatan ini dapat dilihat pada log book

halaman 1 – 2).


pemetaan (mapping) yang menghasilkan tabel staging valas pada skema


Kemudian, data yang sudah tersimpan pada tabel staging valas akan menjadi

sumber data dalam proses pemetaan yang menghasilkan tabel target yaitu

tabel fakta valas pada skema dwhfpp untuk data FPP dan dxm_dwh untuk

data DXM. Di mana pada pemetaan ini, data dari sumber akan di-join

dengan tabel dimensi yang dibutuhkan sesuai dengan kondisi tertentu.

Analisis dan perancangan serta implementasi proses ETL hingga

menghasilkan tabel fakta valas ini dilakukan pada minggu III hingga minggu

V (lebih detail mengenai timeline kegiatan ini dapat dilihat pada log book

halaman 3 – 5).

Proses penyelesaian tabel fakta valas (FACT_VALAS) akan diuraikan

dengan lebih jelas pada Bab 4.

3.3.3 Tabel Fakta Pajak PPh (FACT_TAX_PPH)

Tabel fakta pajak PPh merupakan bagian dari divisi keuangan PT.

Dexa Medica. Tabel fakta pajak PPh tersebut memuat data-data yang

berhubungan dengan pajak penghasilan (PPh) yang berkaitan dengan proses

47

bisnis PT. Dexa Medica (DXM) yang ingin ditampilkan kepada user

berdasarkan keputusan perusahaan yang disesuaikan dengan kebutuhan user

informasi tentang transaksi-transaksi PPh. Untuk membuat sebuah tabel

fakta digunakan konsep ETL (Extraction Transformation Loading) dengan

tools Oracle Warehouse Builder 11g R2.

Tabel fakta pajak PPh ini dibuat pada dua data warehouse yang

berbeda yaitu dwhfpp untuk data dari FPP dan dwhdxm untuk data dari

DXM. Untuk menyelesaikan tabel fakta pajak PPh pada masing-masing data

warehouse, diperlukan dua tahap proses pemetaan (mapping) pada Oracle

Warehouse Builder 11g R2, yaitu pemetaan untuk membuat tabel staging

pajak PPh (STG_FACT_TAX_PPH) dan kemudian pemetaan untuk membuat

tabel fakta pajak PPh yang datanya bersumber dari tabel staging pajak PPh.

Sumber data untuk tabel staging pajak PPh tersedia dalam format .xls.









halaman 1 – 2).


pemetaan (mapping) yang menghasilkan tabel staging pajak PPh pada skema

48


Kemudian, data yang sudah tersimpan pada tabel staging pajak PPh akan


yaitu tabel fakta pajak PPh pada skema dwhfpp untuk data FPP dan

dxm_dwh untuk data DXM. Di mana pada pemetaan ini, data dari sumber

akan di-join dengan tabel dimensi yang dibutuhkan sesuai dengan kondisi

tertentu. Analisis dan perancangan serta implementasi proses ETL hingga

menghasilkan tabel fakta pajak PPh ini dilakukan pada minggu III hingga



Proses penyelesaian tabel fakta pajak PPN (FACT_TAX_PPN) akan


3.3.4 Tabel Fakta Pajak PPN (FACT_TAX_PPN)

Tabel fakta pajak PPN merupakan bagian dari divisi keuangan PT.

Dexa Medica. Tabel fakta pajak PPN tersebut memuat data-data yang

berhubungan dengan pajak pertambahan nilai (PPN) yang berkaitan dengan

proses bisnis PT. Dexa Medica (DXM) yang ingin ditampilkan kepada user

berdasarkan keputusan perusahaan yang disesuaikan dengan kebutuhan user

informasi tentang transaksi-transaksi PPN. Untuk membuat sebuah tabel

fakta digunakan konsep ETL (Extraction Transformation Loading) dengan

tools Oracle Warehouse Builder 11g R2.

Tabel fakta pajak PPN ini dibuat pada dua data warehouse yang

berbeda yaitu dwhfpp untuk data dari FPP dan dwhdxm untuk data dari

49

DXM. Untuk menyelesaikan tabel fakta pajak PPN pada masing-masing

data warehouse, diperlukan dua tahap proses pemetaan (mapping) pada

Oracle Warehouse Builder 11g R2, yaitu pemetaan untuk membuat tabel

staging pajak PPN (STG_FACT_TAX_PPN) dan kemudian pemetaan untuk

membuat tabel fakta pajak PPN yang datanya bersumber dari tabel staging

pajak PPN.

Sumber data untuk tabel staging pajak PPN, tersedia dalam format .xls.









halaman 1 – 2).


pemetaan (mapping) yang menghasilkan tabel staging pajak PPN pada

skema dwhfpp untuk data FPP dan skema dxm_staging untuk data DXM.

Kemudian, data yang sudah tersimpan pada tabel staging pajak PPN akan


yaitu tabel fakta pajak PPN pada skema dwhfpp untuk data FPP dan

dxm_dwh untuk data DXM. Di mana pada pemetaan ini, data dari sumber

akan di-join dengan tabel dimensi yang dibutuhkan sesuai dengan kondisi

50

tertentu. Analisis dan perancangan serta implementasi proses ETL hingga

menghasilkan tabel fakta pajak PPN ini dilakukan pada minggu III hingga



Proses penyelesaian tabel fakta pajak PPN (FACT_TAX_PPN) akan


3.3.5 Tabel Fakta Formula (FACT_FORMULA)

Tabel fakta formula merupakan bagian dari Supply Chain Management

(SCM) PT. Dexa Medica. Tabel fakta formula tersebut memuat data-data

yang berhubungan dengan data dari suatu produk obat yaitu bahan baku obat

(raw material) dan barang yang dihasilkan (finished good) serta satuan

ukuran yang digunakan dalam PT. Dexa Medica (DXM) yang ingin

ditampilkan berdasarkan keputusan perusahaan yang disesuaikan dengan

kebutuhan informasi tentang formula produk obat. Untuk membuat sebuah

tabel fakta digunakan konsep ETL (Extraction Transformation Loading)

dengan tools Oracle Warehouse Builder 11g R2.

Untuk menyelesaikan tabel fakta formula, diperlukan dua tahap proses

pemetaan (mapping) pada Oracle Warehouse Builder 11g R2, yaitu

pemetaan untuk membuat tabel staging formula (STG_FACT_FORMULA)

dan kemudian pemetaan untuk membuat tabel fakta formula yang datanya

bersumber dari MV_FACT_FORMULA.

Sumber data untuk tabel staging formula berasal dari database

transaksional. Karena itu, terlebih dahulu kita perlu membangun MV

51

(Materialized View) di mana MV ini akan menampung data-data dari

database dan dapat me-refresh perubahan data setiap kurun waktu tertentu

sesuai yang ditentukan. Setelah itu, MV tersebut akan di-import ke dalam

data warehouse dwhdxm dengan Oracle Warehouse Builder 11g R2. Proses

ekstraksi data tersebut dilakukan pada minggu V (lebih detail mengenai

timeline kegiatan ini dapat dilihat pada log book halaman 5).

Materialized view tersebut akan digabung dengan tabel-tabel dimensi

yang dibutuhkan sesuai dengan kondisi tertentu dan menjadi sumber data

pada proses pemetaan (mapping) yang menghasilkan tabel staging formula

dan MV_FACT_FORMULA pada skema dxm_staging untuk data DXM.

Kemudian, data yang sudah tersimpan pada MV_FACT_FORMULA akan


yaitu tabel fakta formula pada skema dxm_dwh. Analisis dan perancangan

serta implementasi proses ETL hingga menghasilkan tabel fakta formula ini

dilakukan pada minggu V hingga minggu VII (lebih detail mengenai

timeline kegiatan ini dapat dilihat pada log book halaman 5 – 7).

Proses penyelesaian tabel fakta formula (FACT_FORMULA) akan


3.3.6 Tabel Fakta Performa Supplier (FACT_SUP_PERFORMANCE)

Tabel fakta performa supplier merupakan bagian dari Supply Chain

Management (SCM) PT. Dexa Medica. Tabel fakta performa supplier

tersebut memuat data-data yang berhubungan dengan kinerja dari supplier

meliputi ketepatan waktu pengiriman, kualitas, keadaan serta harga barang

52

yang dipesan. Data yang ingin ditampilkan berdasarkan keputusan

perusahaan yang disesuaikan dengan kebutuhan informasi untuk

memberikan penilaian kepada supplier. Untuk membuat sebuah tabel fakta

digunakan konsep ETL (Extraction Transformation Loading) dengan tools

Oracle Warehouse Builder 11g R2.

Untuk menyelesaikan tabel fakta performa supplier, diperlukan dua

tahap proses pemetaan (mapping) pada Oracle Warehouse Builder 11g R2,

yaitu pemetaan untuk membuat tabel staging performa supplier

(STG_FACT_SUP_PERFORMANCE) dan kemudian pemetaan untuk

membuat tabel fakta performa supplier yang datanya bersumber dari

MV_FACT_SUP_PERFORMANCE.

Sumber data untuk tabel staging performa supplier berasal dari

database transaksional. Karena itu, terlebih dahulu kita perlu membangun

MV (Materialized View) di mana MV ini akan menampung data-data dari

database dan dapat me-refresh perubahan data setiap kurun waktu tertentu

sesuai yang ditentukan. Setelah itu, MV tersebut akan di-import ke dalam

data warehouse dwhdxm dengan Oracle Warehouse Builder 11g R2. Proses

ekstraksi data tersebut dilakukan pada minggu V (lebih detail mengenai

timeline kegiatan ini dapat dilihat pada log book halaman 5).

Materialized view tersebut akan digabung dengan tabel-tabel dimensi

yang dibutuhkan sesuai dengan kondisi tertentu menjadi sumber data pada

proses pemetaan (mapping) yang menghasilkan tabel staging performa

supplier dan MV_FACT_SUP_PERFORMANCE pada skema dxm_staging

untuk data DXM. Kemudian, data yang sudah tersimpan pada

53

MV_FACT_SUP_PERFORMANCE akan menjadi sumber data dalam proses

pemetaan yang menghasilkan tabel target yaitu tabel fakta performa supplier

pada skema dxm_dwh. Analisis dan perancangan serta implementasi proses

ETL hingga menghasilkan tabel fakta performa supplier ini dilakukan pada

minggu V hingga minggu VII (lebih detail mengenai timeline kegiatan ini

dapat dilihat pada log book halaman 5 – 7).

Proses penyelesaian tabel fakta performa supplier (FACT_SUP_PERFORMANCE)

akan diuraikan dengan lebih jelas pada Bab 4.

Setelah menyelesaikan tabel-tabel fakta yang dijelaskan di atas, dilakukan

proses dokumentasi source to target mapping untuk setiap tabel (metadata). Di

dalam dokumentasi tersebut memuat sumber-sumber kolom untuk setiap tabel

staging dan tabel fakta serta keterangan mengenai transformasi yang dilakukan

untuk setiap tabel.

54

Gambaran ruang lingkup pekerjaan selama internship di PT. Dexa Medica

dapat dilihat pada gambar diagram berikut.

Gambar 3.3 Diagram Ruang Lingkup Internship

55

3.4 Identifikasi Masalah

Untuk mengidentifikasi masalah pada PT. Dexa Medica, maka dilakukan

wawancara dengan project manager, Ibu Junita Angdjasrin dari proyek data

warehouse di perusahaan PT. Dexa Medica. Berikut hasil wawancara tersebut.

1. Apakah masalah yang dihadapi oleh perusahaan sehingga dibangun data

warehouse dan tujuan dari penggunaan data warehouse tersebut?

Perusahaan telah memiliki data warehouse untuk divisi sale dan

marketing sejak tahun 2004. Akan tetapi seiring dengan perkembangan

perusahaan yang cukup pesat, maka jumlah data dari berbagai divisi menjadi

sangat besar baik data-data yang sedang berjalan maupun data historis. Karena

itu dibangun juga data warehouse untuk berbagai divisi termasuk finance

(keuangan) dan supply chain management (SCM).

Data–data dari data warehouse bersifat summarized sehingga

memudahkan pihak yang bersangkutan untuk menganalisa data.

2. Siapakah user yang akan menggunakan output dari data warehouse?

Fact deposito

Data-data dari fact deposito akan digunakan oleh direksi dan tim

departemen finance untuk keperluan analisa.

Fact valas

Fact valas digunakan oleh direksi dan tim departemen finance

untuk menganalisa data pembelian mata uang asing oleh perusahaan.

Fact tax PPN & PPh

Fact tax PPN dan PPH digunakan oleh tim accounting departemen

finance untuk melihat data-data pajak perusahaan.

56

Fact formula

Fact formula digunakan oleh direksi, departemen manufacturing,

pabrik dan finance untuk menganalisa formula atau resep obat yang

diproduksi perusahaan.

Fact supplier performance

Fact supplier performance digunakan oleh direksi departemen

purchasing untuk menganalisa kinerja.

3. Bagaimana proses ETL berlangsung?

Proses ETL berlangsung sejak data yang telah dipersiapkan dimasukkan

ke dalam database hingga tersimpan pada data warehouse untuk diakses oleh

user yang membutuhkan data yang bersangkutan.

Extraction

Proses ekstrak terjadi saat data yang telah dipersiapkan (data

transaksi dengan format excel menjadi text file lalu flat file ataupun

oracle form) dijadikan external table ataupun materialized view sebagai

source awal proses mapping.

Transformation

Proses transformasi terjadi saat source awal, baik berupa external

table maupun materialized view dipetakan sesuai kebutuhan user yang

telah dirancang sebelumnya pada logical design. Transformation pada

mapping ini berlangsung hingga record berada pada tabel staging fact.

57

Loading

Proses loading terjadi saat hasil transformasi pada tabel staging

fact dimuat ke tabel fact melalui mapping fact. Hasil loading inilah yang

telah siap diakses oleh user.

4. Mengapa dibuat mapping tabel staging fact terlebih dahulu sebelum mapping

tabel fact?

Pada PT. Dexa Medica, proses mapping tidak hanya terjadi sekali

melainkan dua kali yakni mapping tabel staging fact dan mapping tabel fact.

Mapping tabel staging fact terlebih dahulu sebelum mapping tabel fact

dilakukan untuk meningkatkan performa loading pada data warehouse. Data

yang telah diekstrak di-transform terlebih dahulu ke data warehouse setelah

itu dilakukan mapping lagi yang bertujuan untuk cleansing data ataupun

summarizing.

5. Kapan mulai digunakan data warehouse?

Data warehouse awalnya mulai digunakan oleh PT. Dexa Medica pada

tahun 2004 dengan SQL Server 2000.

6. Kapan data mulai disimpan pada data warehouse?

Data PT. Dexa Medica mulai disimpan pada data warehouse sejak tahun

2004 untuk divisi sales dan marketing.

7. Mengapa memilih Oracle Products?

PT. Dexa Medica beralih dari SQL Server ke Oracle karena beberapa

alasan sebagai berikut.

Oracle dapat menangani data warehouse dengan skala yang lebih besar

dari SQL Server di mana sangat dibutuhkan oleh PT. Dexa Medica

58

seiring dengan terus bertambah besarnya kebutuhan akan kapasitas

penyimpanan data perusahaan.

Perusahaan telah menerapkan sistem ERP yang compatible dengan

Oracle.

8. Apakah manfaat yang diperoleh setelah perusahaan menggunakan Oracle?

Setelah menggunakan Oracle, kapasitas data warehouse PT. Dexa

Medica menjadi lebih memadai dan performa akses menjadi lebih baik.

Berdasarkan hasil wawancara di atas serta observasi yang telah dilakukan

selama program internship pada bulan Juli – September 2010, maka dapat

disimpulkan bahwa beberapa permasalahan mengenai kebutuhan data dan informasi

PT. Dexa Medica adalah sebagai berikut.

Tidak terpenuhinya kebutuhan user bagian manajerial akan output informasi

sebagai keperluan analisa.

User belum memiliki standarisasi data yang sama.

Performa atau kinerja data warehouse yang kurang memadai.

59

3.5 Existing Condition

3.5.1 Alur Bisnis PT. Dexa Medica

PT. Dexa Medica adalah perusahaan farmasi yang kegiatan utamanya

adalah memproduksi dan mendistribusikan berbagai produk obat. Untuk

melakukan kegiatan tersebut, maka PT. Dexa Medica menjalankan kegiatan-

kegiatan bisnis lainnya. Berikut adalah sebagian dari proses kegiatan bisnis

yang dilakukan oleh PT. Dexa Medica.

3.5.1.1 Keuangan

a. Penyimpanan Deposito

Gambar 3.4 Rich Picture Penyimpanan Deposito

60

PT. Dexa Medica melakukan penyimpanan uang deposito

ke bank. Uang yang disimpan ke bank tersebut bersumber dari

kas perusahaan. Setelah penyimpanan deposito selesai, detail

deposito yang tercetak dimasukkan ke dalam database

departemen finance dalam bentuk file excel.

b. Penukaran Valuta Asing

Gambar 3.5 Rich Picture Penukaran Valuta Asing

61

PT. Dexa Medica melakukan penukaran valuta asing ke

bank. Uang yang ditukarkan ke bank tersebut bersumber dari

kas perusahaan. Setelah penukaran valas selesai, detail

penukaran valas yang tercetak dimasukkan ke dalam database

departemen finance dalam bentuk file excel.

c. Pembayaran Pajak PPh dan PPN

Gambar 3.6 Rich Picture Pembayaran PPh dan PPN

62

PT. Dexa Medica melakukan pembayaran pajak PPh dan

PPN ke bank. Uang yang digunakan untuk membayar pajak

tersebut bersumber dari kas perusahaan. Setelah pembayaran

pajak selesai, detail pembayaran pajak yang tercetak

dimasukkan ke dalam database departemen finance dalam

bentuk file excel.

3.5.1.2 Supply Chain Management (SCM)

a. Pembuatan Formula Obat

Gambar 3.7 Rich Picture Pembuatan Formula Obat

63

PT. Dexa Medica melakukan pembuatan formula obat

oleh farmacist. Farmacist kemudian meminta persediaan bahan

baku atau RM (Raw Material) dari supplier. Setelah itu, RM

disampaikan ke pabrik. Setelah proses produksi selesai, produk

jadi atau FG (Finished Good) disampaikan kepada departemen

manufacturing. Setelah itu, rincian formula obat, RM serta FG

yang telah tercatat dimasukkan ke dalam database departemen

manufacturing.

b. Pembuatan Performa Supplier

Gambar 3.8 Rich Picture Pembuatan Performa Supplier

64

PT. Dexa Medica melakukan pembuatan performa

supplier dari para supplier perusahaan. Receiver yang

menerima supply dari supplier mencatat kondisi supply untuk

dimasukkan ke dalam database departemen manufacturing.

Setelah melalui proses kalkulasi dari berbagai faktor yang

menentukan performa supplier, dihasilkan output informasi

supplier yang kemudian diserahkan kepada supplier sebagai

informasi atas layanan yang telah diberikan sebagai masukan

apakah diperlukan peningkatan kualitas dan sebagainya.

65

3.5.2 UML Diagram

3.5.2.1 Use Case Diagram

Gambar 3.9 Use Case Diagram

66

3.5.2.2 Activity Diagram

Gambar 3.10 Activity Diagram Penyimpanan Deposito

67

Gambar 3.11 Activity Diagram Penukaran Valuta Asing

68

Gambar 3.12 Activity Diagram Pembayaran

Pajak PPh dan PPN

69

Gambar 3.13 Activity Diagram Pembuatan Formula

70

Gambar 3.14 Activity Diagram Pembuatan

Performa Supplier

71

3.5.2.3 Statechart Diagram

Gambar 3.15 Statechart Diagram Penyimpanan Deposito

72

Gambar 3.16 Statechart Diagram Penukaran Valuta Asing

73

Gambar 3.17 Statechart Diagram Pembayaran

Pajak PPh dan PPN

74

Gambar 3.18 Statechart Diagram Pembuatan Formula

75

Gambar 3.19 Statechart Diagram Pembuatan

Performa Supplier

76

3.5.3 Rancangan Data Warehouse

Dalam melakukan perancangan data warehouse diperlukan beberapa

tahap untuk memperoleh rancangan data warehouse yang mempunyai

aksesibilitas dan integritas yang tinggi. Tahap-tahap perancangan data

warehouse yang digunakan pada penulisan ini adalah metodologi sembilan

tahap, yaitu:

1. Pemilihan Proses

Tahap pertama yang dilakukan adalah mengidentifikasi subjek

masalah dari data warehouse yaitu proses bisnis yang ada pada

perusahaan. Tahapan ini dilakukan agar data warehouse yang

dirancang dapat menjawab semua pertanyaan bisnis yang dibutuhkan.

Berikut ini adalah proses bisnis pada PT. Dexa Medica yang

digunakan dalam perancangan data warehouse.

a. Keuangan

Proses keuangan yang dimaksud adalah penyimpanan

deposito dan penukaran valas ke bank serta pembayaran pajak

perusahaan, baik PPh maupun PPN kepada pemerintah.

Proses penyimpanan deposito perusahaan didefinisikan

sebagai suatu proses pendataan transaksi penyimpanan deposito

perusahaan ke bank. Data yang ada meliputi nomor bilyet, nama

bank, tanggal penyimpanan, jenis mata uang dan jumlah uang

yang didepositokan.

Proses penukaran valuta asing didefinisikan sebagai suatu

proses pendataan transaksi penukaran valuta asing perusahaan.

77

Data yang ada meliputi tanggal penukaran valuta asing, nama

perusahaan Dexa Group, nama bank, jenis mata uang dan jumlah

yang ditukarkan.

Proses pembayaran pajak perusahaan kepada pemerintah

didefinisikan sebagai suatu proses pendataan transaksi

pembayaran pajak oleh perusahaan kepada pemerintah. Data yang

ada meliputi tanggal pembayaran pajak, jenis pajak, nama bank,

tanggal lapor dan nomor NTPN.

b. Supply Change Management (SCM)

Proses SCM yang dimaksud adalah pembuatan formula obat

dan performa supplier.

Proses pembuatan formula obat didefinisikan sebagai suatu

proses pendataan bahan baku yang diperlukan untuk memproduksi

obat dan produk jadi yang dihasilkan setelah produksi selesai.

Data yang ada meliputi bahan baku yang digunakan, massa dari

bahan baku, keterangan bahan baku dan produk jadi yang

dihasilkan.

Proses pembuatan performa supplier didefinisikan sebagai

suatu proses pendataan performa supplier berdasarkan kualitas

barang supplier, ketepatan waktu sesuai dengan waktu yang telah

disepakati dan tingkat harga yang bersaing. Data yang ada

meliputi tanggal transaksi, tanggal yang dijanjikan oleh supplier,

tanggal penggunaan produk, jenis produk dan keterangan produk.

78

2. Pemilihan Grain

Pada tahap kedua ini, ditentukan secara pasti apa yang

direpresentasikan oleh setiap record pada table fakta. Grain ditentukan

dari analisis keperluan bisnis dan informasi yang dibutuhkan oleh

perusahaan. Grain dari proses bisnis yang dipilih meliputi ringkasan

dari proses keuangan dan Supply Chain Management (SCM).

a. Keuangan

Penyimpanan deposito

Pada proses penyimpanan deposito, data-data yang

dapat dianalisis meliputi nominal uang yang didepositokan,

waktu deposito dan nama bank tempat penyimpanan deposito.

Analisis tersebut akan dilakukan per periode waktu dan jenis

mata uang.

Penukaran valuta asing

Pada proses penukaran valuta asing, data-data yang

dapat dianalisis meliputi nominal valuta asing yang

ditukarkan oleh perusahaan, waktu tukar, nama bank tempat

penukaran valuta asing dan jenis valuta asing yang

ditukarkan. Analisis tersebut akan dilakukan per periode

waktu dan jenis mata uang.

79

Pembayaran pajak PPh dan PPN

Pada proses pembayaran pajak PPh dan PPN oleh

perusahaan kepada pemerintah, data-data yang dapat

dianalisis meliputi waktu pembayaran, nama bank yang

digunakan untuk membayar pajak kepada pemerintah dan

nominal pajak. Analisis tersebut akan dilakukan per periode

waktu, jenis pajak dan masa pajak.

b. Supply Chain Management (SCM)

Pembuatan formula obat

Pada proses pembuatan formula obat, data-data yang

dapat dianalisis meliputi jenis dan nama dari bahan baku yang

digunakan untuk membuat obat dan produk jadi yang

dihasilkan. Analisis tersebut dilakukan per produk, per bahan

baku dan per versi.

Performa supplier

Pada proses performa supplier, data-data yang dapat

dianalisis meliputi tingkat kualitas dari barang yang

disampaikan oleh supplier, ketepatan waktu penerimaan

supply sesuai kesepakatan dan harga material yang bersaing.

Analisis tersebut dilakukan per transaksi yang diterima dan

transaksi yang dikembalikan kecuali diakibatkan oleh

administrasi.

80

3. Identifikasi Dimensi

Pada tahap ini, dilakukan penyesuaian hubungan antara dimensi

dan grain yang ditampilkan dalam bentuk matriks sebagai berikut.

a. Keuangan

Penyimpanan deposito

Tabel 3.1 Tabel Grain vs Dimensi pada

Penyimpanan Deposito

Jenis Mata

Uang Waktu

Nominal

Deposito

Placement Date - X -

Maturity Date - X -

Currency Date X - X

Penukaran valuta asing


Penukaran Valuta Asing

Jenis Mata

Uang Waktu

Nominal

Valuta Asing

Deal Date - X -

Value Date - X -

Base Currency X - X

Quote Currency X - X

Grain

Dimensi

Grain

Dimensi

81

Pembayaran pajak PPh dan PPN


Pembayaran Pajak PPh dan PPN

Jenis Pajak Masa Pajak Waktu

Tanggal Lapor - - X

Tanggal Bayar - - X

Masa Pajak X X -

b. Supply Chain Management (SCM)

Pembuatan formula obat


Pembuatan Formula Obat

Bahan Baku

yang Digunakan

Produk Jadi

yang Dihasilkan

FG Product - X

RM Poduct X -

Dimensi

Grain

Grain

Dimensi

82

Performa supplier


Pembuatan Performa Supplier

Harga

Bersaing

Kualitas

Barang

Ketepatan

Waktu

Penyampaian

Barang

Transaksi

Penerimaan

Received Date - - X X

PO Promised Date - - X X

PO Need Date - - X X

Product X - X

Supplier X X - X

Manufacturer - X - -

PO Currency X - - -

Return Reason - - - X

4. Pemilihan Fakta

Pada tahap ini, dilakukan pemilihan fakta yang akan dibuat

dalam data warehouse. Setiap fakta memiliki data yang dapat dihitung.

Berikut ini adalah fakta-fakta yang akan dibuat dalam data warehouse.

a. Fakta Deposito

Fakta deposito meliputi PLACEMENT_DATE_KEY,

MATURITY_DATE_KEY, CURRENCY_KEY, BILYET_NO (nomor

bilyet), DEPOSITO_NO (nomor deposito), BANK (nama bank

tempat penyimpanan deposito), MATURITY_FLAG (status jangka

Dimensi

Grain

83

waktu deposito), INTEREST_RATE (persentase bunga deposito)

dan JENIS (jenis deposito).

b. Fakta Valas

Fakta valas meliputi VALUE_DATE_KEY, ID_DEAL_DATE_KEY,

BASE_CURRENCY_KEY, QUOTE_CURRENCY_KEY, BANK

(nama bank tempat penukaran valuta asing), BASE_RATE (rate

tukar dasar), DEAL_RATE (rate tukar kesepakatan), HEDGING_POINTS

(titik batas) dan REFERENCE_NO (nomor referensi).

c. Fakta Pajak PPh

Fakta pajak PPh meliputi TANGGAL_BAYAR_KEY,

TANGGAL_LAPOR_KEY, PERIOD (periode waktu), TAHUN

(masa tahun pembayaran pajak), JENIS_PAJAK (jenis pajak yang

akan dibayar), TIPE (tipe pajak yang akan dibayar), MAP,

BANK_PEMBAYARAN (nama bank yang digunakan untuk

membayar pajak), NTPN_NO, STTS_NO dan NPWP.

d. Fakta Pajak PPN

Fakta pajak PPN meliputi TANGGAL_BAYAR_KEY,

TANGGAL_LAPOR_KEY, MASA_PAJAK_KEY, REVISI_NO

(nomor revisi), BANK_PEMBAYARAN (nama bank yang

digunakan untuk membayar pajak), NTPN_NO, BPS_NO,

KETERANGAN dan MAP.

84

e. Fakta Formula

Fakta formula meliputi FG_PRODUCT_KEY, RM_PRODUCT_KEY,

VERSION (versi obat yang menunjukkan apakah formula obat

tersebut sudah dipublikasikan atau belum), FG_UOM (satuan ukur

produk yang dihasilkan dengan baik), RM_UOM (satuan ukur

bahan baku obat), BATCH_SIZE (jenis ukur).

f. Fakta Performa Supplier

Fakta performa supplier meliputi TRANSACTION_DATE_KEY,

PROMISED_DATE_KEY, NEED_BY_DATE_KEY, PRODUCT_KEY,

SUPPLIER_KEY, MANUFACTURER_KEY, PO_CURRENCY_KEY,

RECEIVING_UOM (satuan ukur penerimaan), RECEIVING_NO

(nomor penerimaan), RECEIVING_LINE_NO (nomor lini

penerimaan), PO_NO (nomor pemesanan), PO_LINE_NO (nomor

lini pemesanan), LOT_NO (nomor lot barang), SUPPLIER_LOT_NO

(nomor lot supplier), RETURN_TRANSACTION_ID (nomor identifikasi

pengembalian transaksi), RECEIVED_EXCHANGE_RATE (rate

produk yang diterima dari supplier), PO_EXCHANGE_RATE (rate

produk yang dipesan dari supplier), PO_PRICE (biaya pesanan),

PROMISED_DATE_DEV_STATUS (status apakah tanggal

penyampaian sesuai perjanjian), NEED_DATE_DEV_STATUS

(status apakah tanggal penyampaian sesuai dengan kebutuhan),

PO_QTY (jumlah barang yang dipesan) dan REALIZATION_PCT.

85

5. Menyimpan Pre-kalkulasi di Tabel Fakta

Kalkulasi awal terhadap data yang dapat dihitung dilakukan

setelah tabel fakta ditentukan. Berikut ini adalah kalkulasi awal yang

ada pada tabel fakta.

a. Pre-kalkulasi Fakta Deposito

DEPOSITO_AMOUNT merupakan nominal uang yang

didepositokan ke bank.

INTEREST_AMOUNT merupakan nominal bunga deposito

dari bank.

TAX_AMOUNT merupakan nominal pajak yang dikenakan

pada penyimpanan deposito.

INTEREST_AFTER_AMOUNT merupakan total penjumlahan

dari nominal yang didepositokan dengan bunga deposito.

b. Pre-kalkulasi Fakta Valas

DEAL_AMOUNT merupakan nominal valuta asing yang

ditukarkan.

c. Pre-kalkulasi Fakta Pajak PPh

DPP.

PPH_TERUTANG merupakan pajak penghasilan yang masih

terutang dan belum dibayar.

NILAI_SSP.

86

d. Pre-kalkulasi Fakta Pajak PPN

PPN_OUT merupakan total PPN keluar.

PPN_IN merupakan total PPN masuk.

PPN_KB_PER_LB.

SSP.

SSP_KB_PER_LB.

e. Pre-kalkulasi Fakta Formula

RM_USAGE_QTY merupakan jumlah bahan baku yang

digunakan untuk pembuatan obat.

f. Pre-kalkulasi Performa Supplier

NEED_DATE_DEV merupakan waktu supply dibutuhkan.

PROMISED_DATE_DEV merupakan waktu yang dijanjikan

oleh supplier untuk mengirimkan supply.

RECEIVED_QTY merupakan jumlah kuantitas barang yang

diterima.

RECEIVED_VALUE merupakan hasil dari perkalian antara

jumlah kuantitas barang yang diterima dengan harga

pembelian.

RECEIVED_VALUE_IDR merupakan hasil perkalian antara

jumlah kuantitas barang yang diterima dengan biaya pesanan

dan rate produk yang diterima dari supplier.

RMA_QTY merupakan jumlah barang yang dikembalikan.

87

RMA_VALUE merupakan jumlah harga barang yang

dikembalikan.

RMA_VALUE_IDR merupakan jumlah harga barang yang

dikembalikan dalam Rupiah.

6. Melengkapi Tabel Dimensi

Pada tahap ini, dilakukan penambahan informasi yang bersifat

intuitif dan deksiptif pada tabel dimensi. Berikut adalah tabel dimensi

yang dilengkapi pada data warehouse.

Gambaran tabel dimensi secara garis besar

Tabel 3.6 Gambaran Tabel Dimensi

Dimensi Kolom Deskripsi

CURRENCY

COUNTRY

CURRENCY_NAME

SYMBOL

Laporan dapat dilihat

berdasarkan nama

negara, nama mata

uang dan simbol mata

uang.

PERIOD

FULL_DATE

MONTH_NAME

QUARTER_NAME

DAY_NAME

SEMESTER_NAME


berdasarkan tanggal,

nama bulan, nama

kuarter, nama hari dan

nama semester.

WEEK_OF_MONTH

WEEK_OF_YEAR

DAY_OF_WEEK

MONTHLY_EVENT


berdasarkan minggu

dari bulan, minggu

dari tahun, hari dari

minggu dan acara

bulanan.

88

MANUFACTURER MANUFACTURER_NAME

COUNTRY


berdasarkan nama

produsen dan nama

negara tempat pabrik

dioperasikan.

PRODUCT

MFG_PRODUCT_DESC

PRODUCT_TYPE

PRODUCT_NAME

PRODUCT_GROUP


berdasarkan deskripsi

produk, jenis produk,

nama produk dan

kelompok produk.

RTS_REASON RTS_REASON_DESC


berdasarkan alasan

produk dikembalikan.

SUPPLIER SUPPLIER_SITE_NAME

SUPPLIER_NAME


berdasarkan nama

tempat supplier dan

nama supplier.

Daftar tabel dimensi

a. Dimensi currency (DIM_CURRENCY)

Tabel 3.7 Tabel DIM_CURRENCY

No Kolom Tipe Data Constraint

1 CURRENCY_KEY NUMBER Primary key

2 CURRENCY_ID VARCHAR2(15) Not null

3 CURRENCY_NAME VARCHAR2(100) Not null

4 COUNTRY VARCHAR2(100) -

5 SYMBOL VARCHAR2(12) -

6 PRECISION NUMBER -

7 DESCRIPTION VARCHAR2(240) -

8 INSERTED_DATE DATE -

89

9 LAST_UPDATE_DATE DATE -

10 ROW_EFFECTIVE_DATE DATE -

11 ROW_END_DATE DATE -

12 ACTIVE_FLAG VARCHAR2(1) -

b. Dimensi manufacturer (DIM_MANUFACTURER)

Tabel 3.8 Tabel DIM_MANUFACTURER


1 MANUFACTURER_KEY NUMBER Primary key

2 MANUFACTURER_ID VARCHAR2(30) Not null

3 MANUFACTURER_NAME VARCHAR2(240) -

4 ADDRESS_LINE_1 VARCHAR2(150) -

5 ADDRESS_LINE_2 VARCHAR2(150) -

6 HISTORICAL_NAME VARCHAR2(150) -

7 ZIP_NO VARCHAR2(150) -

8 CITY VARCHAR2(150) -

9 COUNTRY VARCHAR2(150) -

10 ACTIVE_FLAG CHAR(1) -





90

c. Dimensi period (DIM_PERIOD)

Tabel 3.9 Tabel DIM_PERIOD


1 PERIOD_KEY NUMBER Primary key

2 FULL_DATE DATE -

3 YYYYMMDD NUMBER -

4 WEEK_OF_MONTH VARCHAR2(20) -

5 WEEK_OF_YEAR NUMBER -

6 MONTH_NUM NUMBER -

7 MONTH_NAME CHAR(3) -

8 MONTH_LONG_NAME VARCHAR2(15) -

9 MONTH_END_FLAG VARCHAR2(5) -

10 QUARTER_NUM NUMBER -

11 QUARTER_NAME VARCHAR2(5) -

12 SEMESTER_NUM NUMBER -

13 SEMESTER_NAME VARCHAR2(5) -

14 SEMESTER_LONG_NAME VARCHAR2(20) -

15 YEAR_NUM NUMBER -

16 FISCAL_YEAR_NUM NUMBER -

17 DAY_OF_WEEK NUMBER -

18 DAY_NAME VARCHAR2(20) -

19 HOLIDAY VARCHAR2(100) -

20 MONTHLY_EVENT_1 VARCHAR2(100) -




24 WORKING_DAY NUMBER -

25 WORKING_DAY_LEFT NUMBER -



91

d. Dimensi product (DIM_PRODUCT)

Tabel 3.10 Tabel DIM_PRODUCT


1 PRODUCT_KEY NUMBER Primary key

2 MFG_PRODUCT_ID VARCHAR2(25) -

3 MFG_PRODUCT_DESC VARCHAR2(240) -

4 PRODUCT_TYPE VARCHAR2(40) -

5 PRODUCT_SEGMENT_DESC VARCHAR2(40) -

6 PRODUCT_ID VARCHAR2(100) -

7 PRODUCT_NAME VARCHAR2(40) -

8 PRODUCT_DESC VARCHAR2(240) -

9 PRODUCT_INITIAL VARCHAR2(10) -

10 PRODUCT_GROUP_ID VARCHAR2(40) -

11 PRODUCT_GROUP_DESC VARCHAR2(240) -

12 PRODUCT_GROUP_IFOCUS_ID VARCHAR2(50) -

13 PRODUCT_GROUP_IFOCUS_DESC VARCHAR2(50) -

14 PRODUCT_GROUP_FIN_ID NUMBER -

15 PRODUCT_GROUP_FIN_DESC VARCHAR2(150) -

16 SUBLINI_ID VARCHAR2(40) -

17 SUBLINI_DESC VARCHAR2(150) -

18 LINI_DESC VARCHAR2(40) -

19 BUSINESS_TYPE VARCHAR2(150) Not null

20 BUSINESS VARCHAR2(150) Not null

21 BUSINESS_UNIT VARCHAR2(50) Not null

22 COST_CENTER VARCHAR2(50) -

23 ATC1_CODE VARCHAR2(30) -

24 ATC1_DESC VARCHAR2(150) -

92







31 SUHU VARCHAR2(240) -

32 PRODUCT_CLASS VARCHAR2(40) -

33 PRODUCT_SUB_CLASS VARCHAR2(240) -

34 PRODUCT_FOCUS VARCHAR2(10) -

35 PROMOTION_TYPE VARCHAR2(240) -

36 LIFE_SAVING_TYPE VARCHAR2(240) -

37 INJECTION_TYPE VARCHAR2(240) -

38 LIQUID_TYPE VARCHAR2(50) -

39 INDICATIONS VARCHAR2(1000) -

40 ASKES_FLAG VARCHAR2(2) -

41 HNA NUMBER -

42 HJP NUMBER -

43 HET NUMBER -

44 DPHO NUMBER -

45 REGISTRATION_NO VARCHAR2(240) -

46 DINKES_PRODUCT_ID VARCHAR2(30) -

47 LAUNCH_DATE DATE -

48 TERMINATION_DATE DATE -

49 LAUNCH_STATUS CHAR(1) -

50 LENGTH NUMBER -

51 WIDTH NUMBER -

52 HEIGHT NUMBER -

93

53 WEIGHT NUMBER -

54 SALES_UOM VARCHAR2(3) -

55 EACH_CONVERSION_RATE NUMBER -

56 NEW_PRODUCT_INDICATOR VARCHAR2(3) -

57 DISTRIBUTION_FEE NUMBER -

58 INVENTORY_LEVEL_AGREEMENT VARCHAR2(20) -


60 CONSIGNMENT_FLAG VARCHAR2(2) -

61 PM_NAME VARCHAR2(5) -

62 ALLIANCE_INDICATOR VARCHAR2(20) -

63 PRODUCTION_LINE VARCHAR2(40) -

64 DOSAGE_FORM VARCHAR2(240) -

65 PRIMARY_UOM VARCHAR2(3) -

66 SECONDARY_UOM VARCHAR2(3) -

67 SIZE VARCHAR2(40) -

68 RETEST_INTERVAL NUMBER -

69 ZAT_AKTIF VARCHAR2(240) -

70 ALIGN_PRODUCT_CLASS VARCHAR2(240) -

71 SHELF_LIFE NUMBER -

72 RAW_MATERIAL_SOURCE VARCHAR2(240) -



75 ROW_CURRENT_FLAG CHAR(1) -



94

e. Dimensi reason (DIM_RTS_REASON)

Tabel 3.11 Tabel DIM_RTS_REASON


1 RTS_REASON_KEY NUMBER Primary key

2 RTS_REASON_ID VARCHAR2(30) -

3 RTS_REASON_DESC VARCHAR2(240) -






f. Dimensi supplier (DIM_SUPPLIER)

Tabel 3.12 Tabel DIM_SUPPLIER


1 SUPPLIER_SITE_KEY NUMBER Primary key

2 SUPPLIER_SITE_ID NUMBER Not null

3 SUPPLIER_SITE_NAME VARCHAR2(15) Not null

4 SUPPLIER_ID NUMBER Not null

5 SUPPLIER_NAME VARCHAR2(240) -

6 ADDRESS VARCHAR2(722) -

7 CITY VARCHAR2(60) -

8 PROVINCE VARCHAR2(60) -

9 COUNTRY VARCHAR2(80) Not null

10 ZIP_NO VARCHAR2(20) -

11 PRIMARY_CONTACT_PERSON VARCHAR2(42) -

12 PHONE_NO VARCHAR2(50) -

95

13 FAX_NO VARCHAR2(50) -

14 SHIP_TO_LOCATION VARCHAR2(60) -

15 BILL_TO_LOCATION VARCHAR2(60) -

16 BANK_ACCOUNT_NO VARCHAR2(30) -

17 BANK_ACCOUNT_NAME VARCHAR2(80) -






7. Pemilihan Durasi Database

Pada tahap ini, dilakukan penentuan durasi database yang akan

dimasukkan ke dalam data warehouse. Hal ini dilakukan agar data

pada data warehouse yang akan dianalisis oleh user bersifat stabil atau

tidak berubah. Berdasarkan kebutuhan PT. Dexa Medica, maka data

yang akan dianalisis merupakan data dari Januari 2009 sampai dengan

November 2010.

Tabel 3.13 Tabel Durasi Database

Nama

Database

Tahun

Mulai

Range Data dalam

Data Warehouse

Jumlah

Tahun

DWHDXM 2009 2009 – 2010 1 tahun

96

8. Menelusuri Slowly Changing Dimension

Pada pengamatan terhadap perubahan dimensi secara perlahan,

terdapat 3 cara untuk melakukannya yaitu:

Tipe 1

Atribut dimensi yang berubah akan terhapus dan terisi nilai

atribut yang baru.

Tipe 2

Atribut yang berubah akan tetap tersimpan dan akan

dimasukkan suatu record baru dengan atribut yang sudah

berubah.

Tipe 3

Atribut dimensi yang telah berubah menimbulkan alternatif

sehingga nilai atribut lama dan yang baru dapat diakses secara

bersama pada dimensi yang sama.

Dalam perancangan data warehouse ini dipilih tipe kedua. Hal

ini dilakukan untuk mengetahui perubahan dimensi yang terjadi dari

data lama ke data baru.

97

9. Menentukan Prioritas dan Cara Query

Tahap ini berkaitan dengan proses ETL (Extract Transformation

Loading). ETL merupakan proses pengambilan data aplikasi legacy

dan pengintegrasian data tersebut ke dalam data warehouse.

Tabel 3.14 Tabel Proses ETL

Pelaku ETL Waktu Dilakukan Keterangan

Server Setiap akhir bulan ETL dilakukan secara

otomatis oleh server

3.5.4 Aplikasi untuk Transaksi

Aplikasi yang digunakan perusahaan dalam menangani transaksi

adalah produk Microsoft yaitu Microsoft Office Excel dan produk Oracle

dalam bentuk suite package ERP yaitu Oracle Apps (ERP atau Enterprise

Resource Planning).

Microsoft Office Excel merupakan program aplikasi lembar kerja

spreadsheet yang dibuat dan didistribusikan oleh Microsoft Corporation.

Excel digunakan dalam menangani sebagian transaksi karena memiliki

bahasa pemrograman Visual Basic for Applications (VBA), yang dapat

menambah kemampuan Excel untuk melakukan otomatisasi di dalam Excel

dan juga menambahkan fungsi-fungsi yang dapat didefinisikan oleh

pengguna (user-defined functions) untuk digunakan di dalam worksheet.

Selain itu, Excel juga dapat merekam semua yang dilakukan oleh pengguna

menjadi macro, sehingga mampu melakukan otomatisasi beberapa tugas.

98

Gambar 3.20 Tampilan Aplikasi Microsoft Office Excel

Enterprise Resource Planning (ERP) merupakan sistem aplikasi yang

mendukung perencanaan dan kontrol operasional sehari-hari yang

berhubungan dengan pengelolaan sumber daya perusahaan seperti uang,

bahan baku dan sebagainya.

ERP sebagai Oracle Apps bukanlah suatu software besar, melainkan

kumpulan software atau modul-modul yang saling terintegrasi satu sama

lainnya.

Oracle Purchasing dan Account Payables menangani vendor karena

perusahaan membeli dari para vendor dan akan membayar mereka. Oracle

Purchasing menangani semua daftar permintaan dan memesan ke vendor

sedangkan Oracle Accounts Payables menangani semua pembayaran ke para

vendor.

99

Sama halnya Oracle Inventory menangani barang-barang pada stok

gudang. Oracle Receivables dan Order Management menangani para

pelanggan. Order Management membantu dalam mengumpulkan semua

pesanan pelanggan sedangkan Oracle Receivables membantu dalam

mengumpulkan uang yang dibayarkan atas pesanan yang dikirimkan kepada

pelanggan.

Oracle Human Resources menangani gaji para karyawan. Jadi untuk

setiap fungsi tertentu, ada modul terpisah yang membantu menjalankan dan

menangani fungsi tersebut.

Gambar 3.21 Tampilan Aplikasi Oracle Apps (ERP)

Dalam skripsi internship ini, sumber data yang diperoleh dari aplikasi

Microsoft Office Excel adalah sumber data untuk fakta deposito, valas, PPh

dan PPN sedangkan sumber data yang diperoleh dari aplikasi Oracle Apps

(ERP) adalah sumber data untuk fakta formula dan performa supplier.

100

3.5.5 Output Informasi

Untuk menghasilkan output informasi berupa laporan kepada user

akhir, front-end pada MIS perusahaan menggunakan Hyperion.

Gambar 3.22 Tampilan Layar Query pada Hyperion

Mula-mula ditentukan dahulu sumber data yang akan digunakan dalam

membuat laporan. Sumber data ini terdiri dari tabel-tabel baik tabel dimensi

maupun tabel fakta serta view. Request, Sort dan Limit dapat diisi sesuai

dengan kebutuhan user dimana Request terdiri dari kolom-kolom yang akan

ditampilkan, Sort adalah kolom yang akan digunakan sebagai pengurut hasil

tampilan query dan Limit adalah pembatas data yang akan tampil dengan

menggunakan kondisi tertentu.

101

Gambar 3.23 Tampilan Layar Results pada Hyperion

Setelah sumber data pada Query ditentukan, dapat dilihat data-data

yang dihasilkan berdasarkan query yang dirancang sebelumnya. Tampilan

data ini diperiksa apakah sudah sesuai dengan kebutuhan.

102

Gambar 3.24 Tampilan Layar Pivot pada Hyperion

Pivot mengelompokkan hasil data yang ditampilkan per atribut tertentu

menjadi laporan yang lebih teringkas misalnya tampilan data per bulan, per

tahun dan sebagainya.

Gambar 3.25 Tampilan Layar Chart pada Hyperion

103

Pivot yang dihasilkan dapat ditampilkan dalam bentuk grafik untuk

mempermudah user dalam menganalisis.

Gambar 3.26 Tampilan Layar Dashboard pada Hyperion

Pivot dan grafik yang dihasilkan kemudian dijadikan laporan yang

digunakan user untuk keperluan analisis.

3.6 Usulan Pemecahan Masalah

Setelah dilakukan identifikasi masalah dan kebutuhan user akan informasi

yang sudah terintegrasi untuk mempermudah proses analisis, maka usulan yang

diberikan adalah membangun data warehouse untuk menghasilkan tabel-tabel fakta

yang diperlukan yaitu tabel fakta deposito, valas, pajak PPh, pajak PPN, formula

dan performa supplier.

104

Untuk menghasilkan tabel-tabel tersebut secara tepat dan efektif, ada beberapa

cara yang dapat dilakukan, seperti :

1. Merancang query yang berguna dalam proses mapping berdasarkan analisis

kebutuhan informasi yang akan ditampilkan kepada user.

2. Menentukan data sumber dan melakukan validasi serta konversi data tersebut

ke dalam format yang sesuai untuk selanjutnya diolah dengan OWB.

3. Melakukan pemetaan dengan konsep ETL dan cleansing data dari sumber agar

data yang ditampilkan pada tabel fakta merupakan data yang efektif dan tepat.

105

3.6.1 Rancangan Skema Bintang

a. Skema bintang deposito

Gambar 3.20 Skema Bintang FACT_DEPOSITO

Skema bintang deposito terdiri dari satu tabel fakta dan tiga tabel

dimensi. Skema bintang ini menggambarkan sebuah tabel fakta

FACT_DEPOSITO yang terhubung dengan dua tabel dimensi DIM_PERIOD

(DIM_PLACEMENT_DATE dan DIM_MATURITY_DATE) dan tabel dimensi

DIM_CURRENCY.

106

b. Skema bintang valas

Gambar 3.21 Skema Bintang FACT_VALAS

Skema bintang valas terdiri dari satu tabel fakta dan empat tabel


FACT_VALAS yang terhubung dengan dua tabel dimensi DIM_PERIOD

(DIM_PERIOD_TANGGAL_BAYAR dan DIM_PERIOD_TANGGAL_LAPOR)

dan dua tabel dimensi DIM_CURRENCY (DIM_BASE_CURRENCY dan

DIM_QUOTE_CURRENCY).

107

c. Skema bintang pajak PPh

Gambar 3.22 Skema Bintang FACT_TAX_PPH

Skema bintang pajak PPh terdiri dari satu tabel fakta dan dua tabel


FACT_TAX_PPH yang terhubung dengan dua tabel dimensi DIM_PERIOD

(DIM_ TANGGAL_BAYAR dan DIM_ TANGGAL_LAPOR).

108

d. Skema bintang pajak PPN

Gambar 3.23 Skema Bintang FACT_TAX_PPN

Skema bintang tax PPN terdiri dari satu tabel fakta dan tiga tabel


FACT_TAX_PPN yang terhubung dengan tiga tabel dimensi DIM_PERIOD

(DIM_TANGGAL_LAPOR, DIM_TANGGAL_BAYAR dan DIM_MASA_PAJAK).

109

e. Skema bintang formula

Gambar 3.24 Skema Bintang FACT_FORMULA

Skema bintang formula terdiri dari satu tabel fakta dan dua tabel


FACT_FORMULA yang terhubung dengan dua tabel dimensi DIM_PRODUCT

(DIM_FG_PRODUCT dan DIM_RM_PRODUCT).

110

f. Skema bintang performa supplier

Gambar 3.25 Skema Bintang FACT_SUPPLIER_PERFORMANCE

Skema bintang performa supplier terdiri dari satu tabel fakta dan

delapan tabel dimensi. Skema bintang ini menggambarkan sebuah tabel fakta

FACT_SUPPLIER_PERFORMANCE yang terhubung dengan tiga tabel dimensi

DIM_PERIOD (DIM_RECEIVED_DATE, DIM_PO_PROMISED_DATE dan

DIM_PO_NEED_DATE), DIM_PRODUCT, DIM_SUPPLIER, DIM_MANUFACTURER,

DIM_PO_CURRENCY dan DIM_RTS_REASON.

111

Gambar 3.26 Skema Bintang Gabungan

112

3.6.2 Rancangan Query

Setelah menentukan apa saja yang dibutuhkan untuk membuat data

warehouse menggunakan metodologi sembilan tahap, selanjutnya dibuat

rencana query. Rencana query digunakan untuk mempermudah proses

pembuatan mapping suatu fact. Berikut adalah rencana query dari setiap

tabel fakta yang telah dipilih pada tahap sebelumnya.

a. Query tabel fakta deposito (FACT_DEPOSITO)

Rancangan query untuk menghasilkan tabel fakta deposito.

Rancangan query berikut akan digunakan sebagai pedoman pada proses

mapping tabel fakta deposito.

SELECT DPST.NO_BILYET, DPST.DEPOSITO_ID, DPST.BANK,

PD.PERIOD_KEY as PLACEMENT_DATE_KEY,

MD.PERIOD_KEY as MATURITY_DATE_KEY,

DC.CURRENCY_KEY as CURRENCY_KEY,

DPST.AMOUNT, DPST.INTEREST_RATE,

DPST.INTEREST_AMOUNT, DPST.TAX,

DPST.INTEREST_AFTER_TAX,

DPST.MATURITY_FLAG, DPST.JENIS

FROM STG_FACT_TAX_DEPOSITO DPST,

DIM_PERIOD PD,

DIM_PERIOD MD,

DIM_CURRENCY DC

WHERE ( DPST.PLACEMENT_DATE = PD.FULL_DATE(+) and

DPST.MATURITY_DATE = MD.FULL_DATE(+) and

' ' || DPST.CURRENCY || ' ' LIKE DC.CURRENCY_ID(+))

and UPPER(DC.ACTIVE_FLAG) LIKE 'Y'

113

b. Query tabel fakta valas (FACT_VALAS)

Rancangan query untuk menghasilkan tabel fakta valas. Rancangan

query berikut akan digunakan sebagai pedoman pada proses mapping

tabel fakta valas.

SELECT VL.NO_BILYET,

VL.DEPOSITO_ID,

VD.PERIOD_KEY as VALUE_DATE_KEY,

DD.PERIOD_KEY as DEAL_DATE_KEY,

BC.CURRENCY_KEY as BASE_CURRENCY_KEY,

QC.CURRENCY_KEY as QUOTE_CURRENCY_KEY,

VL.BANK,

VL.BASE_RATE,

VL.DEAL_RATE,

VL.HEDGING_POINT,

VL.REFERENCE_NO,

VL.DEAL_AMOUNT

FROM STG_FACT_VALAS VL,

DIM_PERIOD VD,

DIM_PERIOD DD,

DIM_CURRENCY BC,

DIM_CURRENCY QC

WHERE ( VL.BASE_CURRENCY LIKE BC.CURRENCY_ID(+) and

VL.QUOTE_CURRENCY LIKE QC.CURRENCY_ID(+) and

VL.DEAL_DATE = DD.FULL_DATE(+) and

VL. VALUE_DATE = VD.FULL_DATE(+)) and

( UPPER(BC.ACTIVE_FLAG) LIKE 'Y' and

UPPER(QC.ACTIVE_FLAG) LIKE 'Y')

114

c. Query tabel fakta pajak PPh (FACT_TAX_PPH)

Rancangan query untuk menghasilkan tabel fakta pajak PPh.


mapping tabel fakta pajak PPh.

SELECT TPH.NO_BILYET,

TPH.DEPOSITO_ID,

TB.PERIOD_KEY as TANGGAL_BAYAR_KEY,

TL.PERIOD_KEY as TANGGAL_LAPOR_KEY,

TPH.BULAN as PERIOD,

TPH.TAHUN,

TPH.JENIS_PPH as JENIS_PAJAK,

TPH.TIPE,

TPH.MAP_PER_KJS as MAP,

TPH.NAMA_BANK as BANK_PEMBAYARAN,

TPH.NO_NTPN as NTPN_NO,

TPH.NPWP,

TPH.DPP,

PPH_TERUTANG,

NILAI_SSP

FROM STG_FACT_TAX_PPH TPH,

DIM_PERIOD TL,

DIM_PERIOD TB

WHERE TPH.TANGGAL_LAPOR = TL.FULL_DATE(+) and

TPH.TANGGAL_BAYAR = TB.FULL_DATE(+)

115

d. Query tabel fakta pajak PPN (FACT_TAX_PPN)

Rancangan query untuk menghasilkan tabel fakta pajak PPN.


mapping tabel fakta pajak PPN.

SELECT TL.PERIOD_KEY as TANGGAL_LAPOR_KEY,

TB.PERIOD_KEY as TANGGAL_BAYAR_KEY,

MP.PERIOD_KEY as MASA_PAJAK_KEY,

TXP.REVISI_NO,

TXP.BANK as BANK_PEMBAYARAN,

TXP.NTPN_SSP as NTPN_NO,

TXP.NO_BPS as BPS_NO,

TXP.KETERANGAN,

TXP.MAP_PER_KJS as MAP,

TXP.TOTAL_PPN_KELUARAN as PPN_OUT,

TXP.TOTAL_PPN_MASUKAN as PPN_IN,

TXP.PPN_KB_PER_LB as PPN_KB_PER_LB,

TXP.NILAI_SSP as SSP,

TXP.SSP_KB_PER_LB

FROM STG_FACT_TAX_PPN TXP,

DIM_PERIOD TL,

DIM_PERIOD TB,

DIM_PERIOD MP

WHERE TXP.TANGGAL_LAPOR = TL.FULL_DATE(+) and

TXP.TANGGAL_BAYAR = TB.FULL_DATE(+) and

( TXP.MASA = MP.MONTH_LONG_NAME(+) and

TXP.TAHUN = MP.YEAR_NUM(+) and

UPPER(MP.MONTH_END_FLAG) LIKE 'Y')

ftp://ftp.bank/

ftp://ftp.ntpn_ssp/

116

e. Query tabel fakta formula (FACT_FORMULA)

Rancangan query untuk menghasilkan tabel fakta formula.


mapping tabel fakta formula.

SELECT DPF.PRODUCT_KEY as FG_PRODUCT_KEY,

DPR.PRODUCT_KEY as RM_PRODUCT_KEY,

MST.FORMULA_VERS as VERSION,

MAX(MATL.QTY) as BATCH_SIZE,

MATL1.DETAIL_UOM as FG_UOM,

MATL2.DETAIL_UOM as RM_UOM,

SUM(MATL.QTY) as RM_USAGE_QTY

FROM DIM_PRODUCT DPF,

DIM_PRODUCT DPR,

MV_FM_FORM_MST_V MST,

MV_FM_MATL_DTL MATL1,

MV_FM_MATL_DTL MATL1,

MV_MTL_SYSTEM_ITEMS_B MSI1,

MV_MTL_SYSTEM_ITEMS_B MSI2,

MV_HR_ALL_ORGANIZATION_UNITS HAO

WHERE ( MSI1.INVENTORY_ITEM_ID = MATL1.INVENTORY_ITEM_ID AND

MSI2.INVENTORY_ITEM_ID = MATL2.INVENTORY_ITEM_ID AND

MST.FORMULA_ID = MATL1.FORMULA_ID AND

MST.FORMULA_ID = MATL2.FORMULA_ID AND

MATL1.LINE_TYPE = 1 AND

MATL2.LINE_TYPE = -1 AND

MST.FORMULA_STATUS = 700 AND

( MSI1.END_DATE_ACTIVE > SYSDATE OR

MSI1.END_DATE_ACTIVE IS NULL) AND

117

( MSI2.END_DATE_ACTIVE > SYSDATE OR

MSI2.END_DATE_ACTIVE IS NULL) AND

MSI1.ORGANIZATION_ID = HAO.ORGANIZATION_ID AND

MSI2.ORGANIZATION_ID = HAO.ORGANIZATION_ID AND

HAO.NAME like '%FPP Plant Cikarang%') AND

( DPF.MFG_PRODUCT_ID(+) LIKE '%' ||

MSI1.SEGMENT1 || '-' || MSI1.SEGMENT2 || '-' ||

MSI1.SEGMENT3 || '%' AND DPR.MFG_PRODUCT_ID(+)

LIKE '%' || MSI2.SEGMENT1 || '-' ||

MSI2.SEGMENT2 || '-' || MSI2.SEGMENT3 || '%') AND

( UPPER(DPF.ROW_CURRENT_FLAG) = 'Y' AND

UPPER(DPR.ROW_CURRENT_FLAG) = 'Y')

GROUP BY FG_PRODUCT_KEY, RM_PRODUCT_KEY,

VERSION, FG_UOM, RM_UOM

f. Query tabel fakta performa supplier (FACT_SUPPLIER_PERFORMANCE)

Rancangan query untuk menghasilkan tabel fakta performa

supplier. Rancangan query berikut akan digunakan sebagai pedoman pada

proses mapping tabel fakta performa supplier.

SELECT DPTD.PERIOD_KEY as TRANSACTION_DATE_KEY,

DPPD.PERIOD_KEY as PROMISED_DATE_KEY,

PNBD.PERIOD_KEY as NEED_BY_DATE_KEY,

DP.PRODUCT_KEY as PRODUCT_KEY,

DS.SUPPLIER_KEY as SUPPLIER_KEY,

DM.MANUFACTURER_KEY as MANUFACTURER_KEY,

DC.CURRENCY_KEY as PO_CURRENCY_KEY,

DRR.RTS_REASON_KEY as RETURN_REASON_KEY,

PRT.UNIT_OF_MEASURE as RECEIVING_UOM,

118

RSH.RECEIPT_NUM as RECEIVING_NO,

NVL(RSL.LINE_NUM,0) as RECEIVING_LINE_NO,

PHA.SEGMENT1 as PO_NO,

NVL(PLA.LINE_NUM,0) as PO_LINE_NO,

RLT.LOT_NUM as LOT_NO,

PRT.VENDOR_LOT_NUM as SUPPLIER_LOT_NO,

NVL(MTR.REASON_ID,0) as RETURN_TRASACTION_ID,

NVL(PRT.CURRENCY_CONVERSION_RATE,0) as

RECEIVED_EXCHANGE_RATE,

NVL(PHA.RATE,0) as PO_EXCHANGE_RATE,

NVL(PLA.UNIT_PRICE,0) as PO_PRICE,

CASE

WHEN PRT.TRANSACTION_DATE between

(PLLA.PROMISED_DATE - PLLA.DAYS_EARLY_RECEIPT_ALLOWED)

and (PLLA.PROMISED_DATE + PLLA.DAYS_LATE_RECEIPT_ALLOWED)

THEN 'Ontime'

WHEN PRT.TRANSACTION_DATE >

(PLLA.PROMISED_DATE + PLLA.DAYS_LATE_RECEIPT_ALLOWED)

THEN 'Late'

WHEN PRT.TRANSACTION_DATE <

(PLLA.PROMISED_DATE - PLLA.DAYS_EARLY_RECEIPT_ALLOWED)

THEN 'Early'

WHEN PLLA.PROMISED_DATE IS NULL THEN 'Cannot Compare'

END as PROMISED_DATE_DEV_STATUS,

CASE

WHEN PRT.TRANSACTION_DATE between

(PLLA.NEED_BY_DATE - PLLA.DAYS_EARLY_RECEIPT_ALLOWED)

and (PLLA.NEED_BY_DATE + PLLA.DAYS_LATE_RECEIPT_ALLOWED)

THEN 'Ontime'

119

WHEN PRT.TRANSACTION_DATE >

(PLLA.NEED_BY_DATE + PLLA.DAYS_LATE_RECEIPT_ALLOWED)

THEN 'Late'

WHEN PRT.TRANSACTION_DATE <

(PLLA.NEED_BY_DATE - PLLA.DAYS_EARLY_RECEIPT_ALLOWED)

THEN 'Early'

WHEN INGRP1.NEED_BY_DATE IS NULL THEN 'Cannot Compare'

END as NEED_DATE_DEV_STATUS,

NVL(PRT.QUANTITY,0) as PO_QTY,

NVL(PRT.QUANTITY,0) as RECEIVED_QTY,

NVL((PLA.UNIT_PRICE * PRT.QUANTITY),0) as RECEIVED_VALUE,

NVL(((PLA.UNIT_PRICE * PRT.QUANTITY) *

PRT.CURRENCY_CONVERSION_RATE),0) as RECEIVED_VALUE_IDR,

CASE

WHEN PRT.TRANSACTION_TYPE = 'RETURN TO VENDOR'

THEN PRT.QUANTITY

ELSE 0

END as RMA_QTY,

CASE

WHEN PRT.TRANSACTION_TYPE = 'RETURN TO VENDOR'

THEN (PLA.UNIT_PRICE * PRT.QUANTITY)

ELSE 0

END as RMA_VALUE,

CASE

WHEN PRT.TRANSACTION_TYPE ='RETURN TO VENDOR'

THEN ((PLA.UNIT_PRICE * PRT.QUANTITY) *

PRT.CURRENCY_CONVERSION_RATE)

ELSE 0

END as RMA_VALUE_IDR

120

FROM MV_PO_RCV_TRANSACTIONS PRT,

MV_PO_LINE_LOCATIONS_ALL PLLA,

MV_MTL_SYSTEM_ITEMS MSI,

MV_PO_VENDORS PV,

MV_PO_LINES_ALL PLA,

MV_PO_HEADERS_ALL PHA,

MV_INV_MTL_TRANSACTION_REASONS MTR,

MV_RCV_SHIPMENT_HEADERS RSH,

MV_PO_RCV_SHIPMENT_LINES RSL,

MV_PO_RCV_LOT_TRANSACTIONS RLT,

MV_INV_MTL_ITEM_LOCATIONS MIL,

DIM_PERIOD DPTD,

DIM_PERIOD DPPD,

DIM_PERIOD PNBD,

DIM_PRODUCT DP,

DIM_SUPPLIER DS,

DIM_MANUFACTURER DM,

DIM_CURRENCY DC,

DIM_RTS_REASON DRR

WHERE ( MSI.ORGANIZATION_ID = PRT.ORGANIZATION_ID AND

PRT.PO_LINE_LOCATION_ID = PLLA.LINE_LOCATION_ID AND

PRT.PO_LINE_ID = PLA.PO_LINE_ID AND

PRT.VENDOR_ID = PV.VENDOR_ID AND

PRT.PO_HEADER_ID = PHA.PO_HEADER_ID AND

MSI.INVENTORY_ITEM_ID = RSL.ITEM_ID AND

PRT.SHIPMENT_HEADER_ID = RSH.SHIPMENT_HEADER_ID AND

PRT.SHIPMENT_LINE_ID = RSL.SHIPMENT_LINE_ID AND

RSH.SHIPMENT_HEADER_ID = RSL.SHIPMENT_HEADER_ID AND

PRT.LOCATOR_ID = MIL.INVENTORY_LOCATION_ID(+) AND

121

RLT.TRANSACTION_ID(+) = PRT.TRANSACTION_ID AND

PRT.REASON_ID = MTR.REASON_ID(+) AND

PRT.TRANSACTION_TYPE IN('RECEIVE','RETURN TO VENDOR')) AND

to_char(PNBD.FULL_DATE,'mm/dd/yyyy') =

NVL(to_char(PRD.FULL_DATE(+),'mm/dd/yyyy'),'1/1/1900') AND

to_char(PRT.TRANSACTION_DATE,'mm/dd/yyyy')=

NVL(to_char(DPPD.FULL_DATE(+),'mm/dd/yyyy'),'1/1/1900') AND

to_char(PLA.PROMISED_DATE,'mm/dd/yyyy') =

NVL(to_char(PNBD.PERIOD_KEY(+),'mm/dd/yyyy'),'1/1/1900') AND

MSI.SEGMENT2 = DP.MFG_PRODUCT_ID(+) AND

PHA.CURRENCY_CODE = DC.CURRENCY_KEY(+) AND

PLA.ATTRIBUTE1 = DM.MANUFACTURER_KEY(+) AND

PV.VENDOR_NAME = DS.SUPPLIER(+) AND

PLLA.NEED_BY_DATE = DP.ROW_CURRENT_FLAG(+) AND

PHA.PO_CURRENCY = IN_DIM_RETURN_REASON.RTS_REASON_KEY(+)

AND UPPER(IN_DIM_PRODUCT.ROW_CURRENT_FLAG) = 'Y'

BAB 3 DESKRIPSI UMUM 3.1 Profil Perusahaan 3.1.1 Sejarah...

Documents

Transcript of BAB 3 DESKRIPSI UMUM 3.1 Profil Perusahaan 3.1.1 Sejarah...