Upload
nguyenbao
View
238
Download
0
Embed Size (px)
Citation preview
PENERAPAN OBJECT RELATIONAL MAPPING
PADA PENGEMBANGAN ENTERPRISE RESOURCE PLANNING
DIAN INDAH SAVITRI
DEPARTEMEN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
INSTITUT PERTANIAN BOGOR
2008
PENERAPAN OBJECT RELATIONAL MAPPING
PADA PENGEMBANGAN ENTERPRISE RESOURCE PLANNING
Skripsi
Sebagai salah satu syarat untuk memperoleh gelar Sarjana Komputer
pada Fakultas Matematika dan Ilmu Pengetahuan Alam
Institut Pertanian Bogor
Oleh :
DIAN INDAH SAVITRI
G64104035
DEPARTEMEN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
INSTITUT PERTANIAN BOGOR
2008
Judul : Object Relational Mapping pada Pengembangan Enterprise Resource
Planning
Nama : Dian Indah Savitri
NRP : G64104035
Menyetujui:
Pembimbing I, Pembimbing II,
Wisnu Ananta Kusuma, S.T., M.T. Toto Haryanto, S.Kom
NIP 132 312 485
Mengetahui:
Dekan Fakultas Matematika dan Ilmu Pengetahuan Alam
Institut Pertanian Bogor
Dr. Drh. Hasim, DEA
NIP 131 578 806
Tanggal Lulus:
iv
ABSTRAK
DIAN INDAH SAVITRI. Penerapan Object Relational Mapping pada Pengembangan Enterprise
Resource Planning. Dibimbing oleh WISNU ANANTA KUSUMA dan TOTO HARYANTO.
Enterprise Resource Planning (ERP) merupakan suatu aplikasi terintegrasi yang difokuskan
untuk mengotomasi seluruh aktivitas infrastruktur pada suatu perusahaan. Sistem ERP
menggabungkan proses bisnis antara perusahaan dan pelanggan, perusahaan dengan supplier, dan
proses perhitungan keuangan perusahaan. Semua proses bisnis yang tergabung mengakses pada
sebuah basis data yang terpusat.
Sistem manajemen basis data yang banyak digunakan pada aplikasi ERP adalah basis data
relasional, sedangkan pengembangan aplikasi skala enterprise sebagian besar menerapkan konsep
berorientasi objek. Dengan demikian terdapat ketidaksesuaian antara basisdata relasional yang
digunakan dengan aplikasi yang dikembangkan dan pendekatan berorientasi objek.
Ketidaksesuaian tersebut antara lain terkait dengan aspek granularity, subtypes, identitas, asosiasi,
dan navigasi data.
Pada penelitian ini dilakukan analisis terhadap rancangan aplikasi ERP. Ditemukan
ketidaksesuaian yang meliputi empat aspek, yaitu aspek granularity, identitas, asosiasi, dan
navigasi data. Untuk mengatasi ketidaksesuaian tersebut, diimplementasikan konsep Object
Relational Mapping (ORM). Setiap objek yang akan dipetakan menjadi tabel-tabel pada basis data
relasional dibungkus oleh suatu interface dengan menerapkan konsep design pattern. Hal tersebut
bertujuan untuk memudahkan integrasi dengan lapisan aplikasi.
Implementasi ORM ini dibagi menjadi beberapa tahapan, yaitu: pemetaan Data Transfer
Object (DTO) dengan menghilangkan paradigma ketidaksesuaian antara basis data relasional dan
pemrograman berorientasi objek, membuat fungsi-fungsi akses data dengan mengimplementasikan
DAO pattern, menyederhanakan fungsi akses data dengan memanfaatkan konsep design pattern,
membuat skema basis data, dan menyatukan lapisan persistensi dengan lapisan aplikasi.
Implementasi konsep ORM terbukti dapat menghilangkan ketidaksesuian tersebut. Selain itu
penerapan ORM yang dilengkapi dengan design pattern membuat sistem ERP menjadi lebih
terstruktur dan mudah untuk dikembangkan.
Kata kunci: Object Relational Mapping (ORM), object relational mismatch, basis data relasional,
object oriented, design pattern.
v
RIWAYAT HIDUP
Penulis dilahirkan di Tasikmalaya pada tanggal 23 Juni 1986 sebagai anak pertama dari dua
bersaudara dari pasangan Ana Suparjana dan Dedeh Juliarsih. Penulis menyelesaikan pendidikan
menengah atas di SMU Negeri 1 Tasikmalaya dan lulus pada tahun 2004.
Pada tahun yang sama penulis diterima sebagai mahasiswa Departemen Ilmu Komputer,
Fakultas Matematika dan Ilmu Pengetahuan Alam, Institut Pertanian Bogor. Penulis diterima
melalui jalur Undangan Seleksi Masuk IPB (USMI). Penulis pernah pelaksanaan kegiatan Praktek
Kerja Lapangan di PT. Sigma Karya Sempurna (Balicamp) sebagai Software Tester untuk Proyek
Panin Business Internet Banking.
Selama kuliah penulis aktif dalam beberapa kegiatan kemahasiswaan terutama di
Himpunan Mahasiswa Ilmu Komputer (Himalkom). Pada saat di Himalkom penulis bertugas
sebagai Bendahara 1. Pada tahun 2007 penulis aktif di komunitas KPLI-Bogor (Kelompok
Pengguna Linux Indonesia-Bogor) sebagai Sekretaris. Saat ini penulis aktif sebagai anggota Java
Campus Team di Departemen Ilmu Komputer.
vi
PRAKATA
Puji dan syukur penulis panjatkan kepada Allah SWT atas limpahan nikmat dan hidayah-
Nya sehingga penulis dapat menyelesaikan karya ilmiah ini. Sholawat dan salam semoga
senantiasa tercurah kepada Nabi besar Muhammad SAW, keluarganya, para sahabat, serta para
pengikutnya yang tetap istiqomah mengemban risalah-Nya.
Penulis ingin menyampaikan penghargaan dan terima kasih kepada Bapak Wisnu Ananta
Kusuma, S.T., M.T. selaku pembimbing I, yang telah meluangkan waktunya untuk membimbing
penulis, memberikan ilmu-ilmu yang berharga, serta dukungan selama penelitian ini berlangsung.
Penulis juga mengucapkan terima kasih kepada Bpk. Toto Haryanto, S.Kom. selaku pembimbing
II, yang telah membimbing penulis dan selalu memberikan semangat, serta penulis mengucapkan
terima kasih kepada Bapak Irman Hermadi, S.Kom.,M.S. yang telah bersedia menjadi penguji
dalam pelaksanaan seminar dan sidang.
Kemudian penulis ucapkan terima kasih kepada seluruh keluarga khususnya kepada kedua
orang tua dan Ulfa atas doa, dukungan, kasih sayang, dan pengorbanannya selama ini. Disamping
itu, penulis ingin mengucapkan terima kasih kepada Mas Ifnu yang selalu memberi semangat,
memberi dukungan untuk terus menyelesaikan tugas akhir, dan pengorbanan yang diberikan
selama penelitian ini berlangsung.
Penulis juga mengucapkan terima kasih kepada Halida dan Dany yang telah memberikan
banyak pengalaman berharga selaku rekan seperjuangan dalam menyelesaikan aplikasi penelitian
ini. Upacan terima kasih dari penulis teruntuk Bang Robi dan Kak Ria yang selalu memberikan
masukan dan meluangkan waktu untuk berdiskusi ERP. Kepada Dhiku dan Pak Endy, terima kasih
untuk referensi dan tutorial Java-nya.
Kemudian penulis ucapkan terima kasih kepada Dwi, Ina, Heni, Endang dan Tri yang telah
membantu selama penulisan tugas akhir dan memberi dukungan ketika seminar dan sidang. Serta
terima kasih kepada Dita, Vina, Dwi, dan teman-teman “New Arini” lainnya yang telah
memberikan wawasan dan keceriaan kepada penulis. Semua teman-teman ilkomerz’41, terima
kasih untuk canda tawa, persahabatan, dan kebersamaan selama kuliah di Ilkom IPB.
Penulis mengucapkan terima kasih kepada seluruh staf pengajar yang telah memberikan
wawasan serta ilmu yang berharga selama penulis menuntut ilmu di Departemen Ilmu Komputer.
Seluruh staf administrasi dan perpustakaan Departemen Ilmu Komputer yang selalu memberi
kemudahan dalam mengurus segala macam hal berkaitan dengan perkuliahan, serta pihak-pihak
lain yang tidak dapat disebutkan satu-persatu.
Sebagaimana manusia yang tidak luput dari kesalahan, penulis menyadari bahwa karya
ilmiah ini jauh dari sempurna. Namun penulis berharap semoga karya ilmiah ini dapat bermanfaat
bagi siapapun yang membacanya. Semoga tulisan ini dapat bermanfaat khususnya untuk penulis
pribadi, umumnya untuk semua warga Institut Pertanian Bogor.
Bogor, Juni 2008
Dian Indah Savitri
DAFTAR ISI
Halaman
DAFTAR ISI ................................................................................................................................... vii
DAFTAR GAMBAR .....................................................................................................................viii
DAFTAR LAMPIRAN ..................................................................................................................viii
PENDAHULUAN
Latar Belakang ............................................................................................................................. 1
Tujuan Penelitian ......................................................................................................................... 1
Ruang Lingkup Penelitian ........................................................................................................... 1
Manfaat Penelitian ....................................................................................................................... 1
TINJAUAN PUSTAKA
Enterprise Resource Planning ..................................................................................................... 1
Basis Data Relasional .................................................................................................................. 2
Persistent Object ......................................................................................................................... 2
Object Relational mismatch ......................................................................................................... 2
Object Relational Mapping ......................................................................................................... 3
Framework .................................................................................................................................. 3
Design pattern dan JEE pattern ................................................................................................... 3
Model View Controller ................................................................................................................ 4
Declarative Transaction .............................................................................................................. 4
Dependency Injection / Inversion of Control ............................................................................... 5
METODE PENELITIAN .................................................................................................................. 5
Kerangka Pemikiran .................................................................................................................... 5
Studi Literatur .............................................................................................................................. 5
Analisis Kebutuhan ORM ........................................................................................................... 5
Implementasi ORM dan Design Pattern .................................................................................... 5
Evaluasi ....................................................................................................................................... 5
HASIL DAN PEMBAHASAN
Analisis Kebutuhan ORM pada Sistem ERP ............................................................................... 6
1 Deskripsi Umum Aplikasi Ritel ERP ................................................................................. 6
2 Analisis Masalah Ketidaksesuaian...................................................................................... 6
a granularity ..................................................................................................................... 6
b identitas ......................................................................................................................... 6
c asosiasi .......................................................................................................................... 7
d navigasi data .................................................................................................................. 7
Implementasi ORM dan Design Pattern ..................................................................................... 7
1 Melakukan Konfigurasi Basis Data ................................................................................... 7
2 Membuat Class DTO (Data Transfer Object) ................................................................... 7
a Aspek Granularity ......................................................................................................... 8
b Aspek Identitas .............................................................................................................. 8
c Aspek Asosiasi .............................................................................................................. 8
d Aspek Navigasi data .................................................................................................... 10
3 Membuat Fungsi Akses Data. .......................................................................................... 11
4 Penyederhanaan Fungsi Akses Data ................................................................................ 12
5 Membuat Skema Basis Data. ........................................................................................... 13
6 Menyatukan Lapisan Persistensi dengan Lapisan Aplikasi ............................................ 13
Evaluasi ..................................................................................................................................... 14
viii
KESIMPULAN DAN SARAN
Kesimpulan ................................................................................................................................ 14
Saran .......................................................................................................................................... 15
DAFTAR PUSTAKA ..................................................................................................................... 15
LAMPIRAN .................................................................................................................................... 16
DAFTAR GAMBAR
Halaman
1 Mekanisme ORM. .......................................................................................................................... 3
2 Arsitektur MVC (Wahab 2007). ..................................................................................................... 4
3 Diagram Metodologi Penelitian. .................................................................................................... 5
4 Skema pembuatan DTO. ................................................................................................................ 8
5 Pemetaanf asosiasi one-to-one. ...................................................................................................... 8
6 Pemetaan asosiasi one-to-many. ..................................................................................................... 9
7 Pemetaan asosiasi many-to-many ................................................................................................. 10
DAFTAR LAMPIRAN
Halaman
Lampiran 1 Daftar Tabel ................................................................................................................. 17 Lampiran 2 Class Diagram Data Transfer Object .......................................................................... 19 Lampiran 3 ER Diagram ................................................................................................................. 26 Lampiran 4 Kamus data .................................................................................................................. 30 Lampiran 5 Teknik Inversion of Controls ....................................................................................... 46 Lampiran 6 Declarative Transaction untuk setiap modul ............................................................... 53 Lampiran 7 Contoh Kode Program ................................................................................................. 54
1
PENDAHULUAN
Latar Belakang
Enterprise Resource Planning (ERP)
merupakan suatu aplikasi terintegrasi yang
difokuskan untuk mengotomasi seluruh
aktivitas infrastruktur dalam suatu
perusahaan. Sistem ERP menggabungkan
proses bisnis antara perusahaan dan
pelanggan, perusahaan dengan supplier, dan
proses perhitungan keuangan perusahaan.
Semua proses bisnis yang tergabung
mengakses pada sebuah basis data yang
terpusat (Parr 2000).
Sebagian besar aplikasi yang berskala
enterprise dikembangkan dengan
pendekatan berorientasi objek menggunakan
three-tier-architecture yang terdiri atas
lapisan presentasi, lapisan aplikasi, dan
lapisan basis data (Rashid et al. 2002).
Sementara itu, sistem manajemen basis data
yang banyak digunakan sekarang ini adalah
basis data relasional. Dengan demikian,
terdapat ketidaksesuaian (mismatch
paradigm) antara basis data relasional yang
digunakan dan aplikasi yang dikembangkan
dengan pendekatan berorientasi objek.
Ketidaksesuaian tersebut antara lain aspek
granularity, subtypes, identitas, asosiasi,
dan navigasi data (Bauer & King 2007).
Untuk mengatasi masalah ini Nugraha
(2005) melakukan penelitian mengenai
konsep ORM (Object Relational Mapping)
yang berfungsi memetakan antara class dan
tabel. Pada prinsipnya, penelitian tersebut
menunjukan bahwa Object Relational
Mapping (ORM) adalah sebuah solusi yang
dapat menjembatani paradigma
ketidaksesuaian antara sistem basis data
relasional dan pengembangan aplikasi
berorientasi objek.
Namun demikian Nugraha (2005) hanya
membatasi penelitiannya pada aspek
pemetaan dan tidak diimplementasikan pada
aplikasi yang utuh. Pada penelitian ini,
dilakukan analisis terhadap aplikasi Ritel
ERP yang dikembangkan Ernita (2008)
untuk menunjukan adanya ketidaksesuaian
(mismatch) tersebut. Selanjutnya akan
diimplementasikan konsep ORM untuk
menghilangkan ketidaksesuaian tersebut
serta penerapan konsep design pattern yang
berfungsi dalam proses penyatuan dengan
lapisan aplikasi.
Tujuan Penelitian
Tujuan dari penelitian ini adalah:
1 Menganalisis ketidaksesuaian yang
muncul dari rancangan sistem Ritel ERP
yang dikembangkan Ernita (2008) dan
basis data relasional yang digunakan. 2 Menerapkan konsep ORM untuk
mengatasi masalah ketidaksesuaian
tersebut.
3 Memanfaatkan konsep design pattern
dalam pengaksesan basis data oleh
lapisan aplikasi.
Ruang Lingkup Penelitian
Ruang lingkup penelitian ini adalah :
1 Membangun lapisan Model untuk
aplikasi Ritel ERP dengan menerapkan
konsep ORM dengan menggunakan satu
framework yang telah ada tanpa
membandingkan dengan framework
ORM lain.
2 Menerapkan konsep ORM pada aplikasi
Ritel ERP tetapi tidak disertai konsep
untuk manajemen backup data dan
pengelolaan data yang sudah tidak
terpakai.
Manfaat Penelitian
Penelitian ini diharapkan dapat
bermanfaat dalam pemeliharaan dan
pengelolaan manajemen basis data pada
pengembangan aplikasi ERP selanjutnya.
Selain itu, penerapan ORM dapat
menghemat koneksi pada server basis data
sehingga aplikasi ERP yang dikembangkan
lebih optimal.
TINJAUAN PUSTAKA
Enterprise Resource Planning
Enterprise Resource Planning (ERP)
adalah suatu aplikasi terintegrasi yang
difokuskan untuk mengotomasi seluruh
aktivitas infrastruktur perusahaan. Aplikasi
ERP menggabungkan proses bisnis antara
perusahaan dan pelanggan, perusahaan dan
supplier, dan proses perhitungan keuangan
perusahaan. ERP mengotomasi proses bisnis
perusahaan baik dari segi produksi,
distribusi, keuangan, waktu, dan sumber
daya manusia (Parr 2000).
2
Inti modul ERP antara lain
(Rashid et al. 2002) :
Manajemen akuntasi dan keuangan.
Manajemen manufacturing dan produksi.
Manajemen transportasi, penjualan dan
distribusi.
Manajemen sumber daya manusia
Supply Chain Management (SCM).
Customer Relationship Management
(CRM).
Pengembangan aplikasi ERP
menggunakan three-tier architecture yang
terdiri atas (Rashid et al. 2002):
Lapisan presentasi berisi Graphical User
Interface (GUI) atau browser untuk data
entry atau untuk melakukan akses
terhadap fungsi sistem.
Lapisan aplikasi berisi business rules,
fungsi, logika, perlakuan program
terhadap data yang diterima/ ditransfer
dari/ke server basis data.
Lapisan basis data berisi fungsi
manajemen data transaksi termasuk di
dalamnya metadata.
Basis Data Relasional
Basis data merupakan sekumpulan data
atau entitas beserta deskripsinya yang secara
logika berelasi, dibuat untuk memenuhi
kebutuhan informasi suatu organisasi serta
dapat digunakan bersama-sama. Tujuan
utama basis data adalah mengelola dan
mengolah data yang begitu kompleks secara
mudah, cepat dan efisien untuk berbagai
kebutuhan (Connolly & Carolyn 2002).
Pada basis data relasional, relation
berarti tabel, sehingga data disimpan dalam
bentuk tabel-tabel. Relation digunakan untuk
menyimpan informasi yang ditunjukan
dalam basis data. Setiap tabel mempunyai
atribut yang mewakili nama kolom dari tabel
tersebut. Konsep relation hanya berlaku
terhadap struktur lojik tidak mencakup
struktur fisik (Connolly & Carolyn 2002).
Persistent Object
Dalam pengembangan sistem, persistent
object didefinisikan sebagai objek yang
dihasilkan dari suatu sistem dan dapat
disimpan dalam waktu yang lama bahkan
bersifat permanen (Peak & Heudecker
2006).
Persistent object bisa disimpan dalam
bentuk basis data relasional, file system
dalam harddisk, file XML, Web Service,
ODBMS (Object Data Base Management
System), dan LDAP. Media penyimpanan
persistent object yang paling banyak
digunakan dalam pengembangan perangkat
lunak adalah basis data relasional. Hal ini
disebabkan pembuatan dan pengaksesan
basis data pada sistem manajemen basis data
relasional relaif mudah (Peak & Heudecker
2006).
Persistent object memudahkan proses
penyimpanan dan pengaksesan data.
Persistent object bersifat abstrak karena
dapat menyembunyikan detail bagaimana
suatu data disimpan dan diakses, sehingga
seakan-akan prosesnya secara detail tidak
terlihat oleh objek lainnya
(Peak & Heudecker 2006).
Object Relational mismatch
Object Relational Mismatch adalah
ketidaksesuaian yang terjadi disebabkan
adanya perbedaan antara aplikasi yang
diimplementasikan dengan pendekatan
berorientasi objek dan penyimpanan data
yang menggunakan sistem basis data
relasional. Ketidaksesuaian tersebut meliputi
aspek:
1 Granularity
Ketidaksesuaian pada aspek granularity
menyangkut pada pemecahan entitas
menjadi atribut-atribut yang lebih
kompleks. Pada basis data relasional
tidak dikenal tipe data yang didefinisikan
oleh pengguna (user-defined-data-type).
Sebagai contoh class Person
mempunyai atribut address dengan
tipe data address. Pada basis data
relasional tidak mungkin mendefinisikan
kolom address dengan tipe data
address juga. Hal yang paling
mungkin dilakukan adalah memecah
address menjadi street_address,
city_address, zipCode_address
dan tetap dimasukan ke dalam tabel
Person.
2 Subtypes
Ketidaksesuaian pada aspek subtypes
adalah pembeda antara superclass dan
subclass. Pada pemrograman berorientasi
objek dikenal istilah inheritance
(pewarisan) dari class parent kepada
class child, sedangkan pada basis data
relasional tidak dikenal proses pewarisan
antar tabel.
3 Identitas Ketidaksesuaian pada aspek identitas
adalah adanya perbedaan pengenal
3
identitas antara objek dan tabel. Pada
objek terdapat dua cara untuk
membedakan objek yang satu dengan
objek lainnya, yaitu dengan
menggunakan fungsi antara lambang
sama dengan (==) dan method
equals(). Lambang sama dengan
(==)merujuk pada alamat memori yang
sama, sedangkan method equals()
merujuk pada nilai secara lojik yang
sama. Akan tetapi pada basis data yang
membedakan tabel satu dengan tabel
yang lain adalah primary key.
4 Asosiasi
Ketidaksesuaian pada aspek asosiasi
meliputi hubungan dua entitas yang
memiliki keterhubungan. Pada objek,
penghubung dua entitas tersebut dikenal
sebagai references sedangkan pada basis
data relasional dikenal dengan foreign
key. Asosiasi antarentitas terdiri atas:
one-to-one, one-to-many, dan many-to-
many.
5 Navigasi data
Ketidaksesuaian pada aspek navigasi
data meliputi proses pengaksesan suatu
objek dari objek lain. Pada basis data
relasional navigasi data dilakukan
menggunakan query join sedangkan
pada pendekatan berorientasi objek
dilakukan dengan memanggil suatu
method getter. Navigasi dibagi dua
macam berdasarkan arahnya, antara lain:
directional dan bidirectional
(Bauer & King 2007).
Object Relational Mapping
Object Relational Mapping merupakan
suatu teknik untuk memetakan dari
persistent object pada aplikasi ke dalam
tabel pada basis data secara otomatis dan
transparan. Mekanisme ORM dapat dilihat
pada Gambar 1. ORM menggunakan
metadata untuk mendeskripsikan pemetaan
antara objek dan basis data (Bauer & King
2007).
ORM berperan sebagai lapisan model
dalam MVC pattern. Model adalah sebuah
lapisan yang paling dekat dengan sumber
data, baik itu berasal dari basis data,
webservice, maupun file system. ORM
merupakan solusi yang dapat mengatasi
ketidaksesuaian yang terjadi akibat adanya
perbedaan antara aplikasi yang
diimplementasikan dengan pendekatan
berorientasi objek dan penyimpanan data
dengan menggunakan sistem basis data
relasional. Teknologi ORM ada beberapa
macam, seperti Toplink dari Oracle, Kodo
dari Bea System, dan Hibernate dari
RedHat.
Gambar 1 Mekanisme ORM
(Thamura et al. 2007).
Framework
Framework adalah aplikasi semi-
complete yang dapat digunakan untuk
membuat aplikasi lain yang lebih spesifik
(Husted 2003). Framework yang ideal
merupakan intisari dari pendekatan terbaik
dalam pengembangan perangkat lunak.
Apabila suatu aplikasi dikembangkan
menggunakan framework maka harus
mengadopsi semua mekanisme dan
ketentuan yang ditetapkan pada framework
tersebut. Suatu framework mempunyai
sekumpulan file library khusus. Alasan
pengembangan sebuah framework adalah
dimungkinkannya penggunaan kembali
perangkat lunak dalam pengembangan
selanjutnya.
Salah satu framework ORM adalah
Hibernate. Hibernate adalah salah satu ORM
framework open source yang dikembangkan
untuk menangani masalah data persistence
pada lingkungan Java. Hibernate terdiri atas
dua versi yaitu Hibernate Core dan
Hibernate Annotation. Hibernate Core
menggunakan file XML untuk melakukan
pemetaan terhadap objek-objek tabel pada
basis data, sedangkan Hibernate Annotation
menggunakan Java Annotation untuk
mapping terhadap basisdata.
Implementasi Hibernate pada kode
program Java menggunakan HQL
(Hibernate Query Language) (Bauer dan
King 2007). Sebelum melakukan query
terhadap basisdata, terdapat beberapa
konfigurasi yang harus dilakukan, antara
lain menentukan dialect (jenis DBMS) yang
digunakan, class driver, dan file koneksi.
database
Table1
Table2
Table3O
R M
apping
4
Controller
Model View
Manipulasi Interaksi
Ditampilkan
Design pattern dan JEE pattern
Design pattern adalah pola atau unsur-
unsur rancangan yang seringkali muncul
pada berbagai jenis sistem. Design pattern
merupakan katalog permasalahan yang
sering muncul beserta solusi yang sudah
teruji dalam perancangan sistem (Gamma et
al. 1995). Design pattern yang sering
dijadikan studi adalah design pattern yang
berasal dari Gang of Four (GoF) yaitu, Erich
Gamma, Richard Helm, Ralph Johnson, dan
John Vlissides.
GoF mengumpulkan pattern yang biasa
dipakai dalam membangun sebuah sistem
menjadi suatu katalog lengkap yang dapat
dipakai dalam memecahkan berbagai
masalah dalam pembangunan sebuah sistem.
Dengan mengetahui deskripsi lengkap dari
suatu permasalahan maka akan dapat dengan
mudah diketahui pattern apa yang cocok
sebagai solusi dari permasalahan tersebut
dan ketika menghadapi masalah yang sama
atau mirip maka pattern tersebut dapat
digunakan kembali (Wahab 2007).
Design pattern yang digunakan pada
penelitian ini antara lain (Gamma et al.
1995) :
a. Singleton adalah pola yang mengatur
suatu objek yang hanya mempunyai satu
instansiasi selama aplikasi berjalan.
b. Proxy adalah pola yang merancang
suatu objek untuk mewakili kontrol atau
akses objek lain dan bertindak seolah-
oleh objek tersebut melakukannya.
c. Façade adalah pola yang
menyederhanakan objek-objek yang
terlihat rumit ke dalam sebuah interface.
d. Factory method adalah pola untuk
mengenkapsulasi suatu objek dan
diinstasiasi satu kali untuk digunakan
berulang-ulang oleh objek.
Selain GoF, juga terdapat Gang of Three
(GoT) yang terdiri atas Deepak Alur, John
Crupi, dan Dan Malks. JEE pattern
sebenarnya mengacu kepada design pattern
berdasarkan GoF dan memiliki fungsi yang
sama yaitu sebagai katalog permasalahan
dan solusi yang sudah teruji dalam
pengembangan spesifik aplikasi JEE. JEE
pattern yang dipakai pada penelitian ini
adalah DTO (Data Transfer Object) dan
DAO (Data Access Object).
Data Transfer Object (DTO) pattern
adalah pola yang mengenkapsulasi bisnis
data dan mengirimkannya secara sekaligus
dalam satu waktu (Alur et al. 2003). DTO
pattern juga berfungsi sebagai jembatan
penghubung antarlapisan dalam aplikasi.
Dengan pola ini proses perpindahan data
menjadi sederhana dan terintegrasi. Data
Access Object (DAO) pattern adalah pola
yang mengenkapsulasi data akses dan
manipulasi ke dalam lapisan yang berbeda
kemudian diimplementasikan dengan
membuat sebuah objek yang bersifat abstrak
dan mengenkapsulasi seluruh akses data.
(Alur et al. 2003).
Model View Controller
Model View Controler (MVC) pattern
adalah pola yang memisahkan antara
tampilan antarmuka (View), proses bisnis
(Controller), dan objek data (Model)
(McGovern 2003). Gambar 2 menunjukan
struktur Model View Controller pattern
(Wahab 2007). Lapisan Model merupakan
proses bisnis utama. Di dalamnya terdapat
kode untuk persistensi data dan proses
bisnis. Secara singkat, Lapisan Model ini
menangani isi dari aplikasi. Di lapisan ini
diputuskan data yang akan diberikan pada
client.
Sementara itu, lapisan View menangani
masalah-masalah yang berkaitan dengan
tampilan. Lapisan ini hanya melakukan
pengaturan terhadap data agar tampilannya
sesuai dengan kebutuhan pengguna. Lapisan
terakhir adalah lapisan Controller, lapisan
ini berfungsi mengatur alur pengguna. Pada
lapisan ini dilakukan pemrosesan request
untuk menentukan proses bisnis mana yang
akan dieksekusi. Biasanya layer controller
juga digunakan untuk mengatur ijin akses.
Gambar 2 Arsitektur MVC (Wahab 2007).
Declarative Transaction
Declarative Transaction adalah suatu
teknik untuk medeklarasikan semua
transaksi dalam suatu file konfigurasi untuk
menangani semua proses transaksi tanpa
harus membuat kode-kode program untuk
menangani transaksi secara eksplisit. Selain
5
Studi literatur
Analisis
permasalahan
ketidaksesuaian
Perancangan dan
implementasi ORM
dan design pattern
evaluasi
itu mengatur rollback (method dan
exception) apabila terjadi kegagalan
transaksi (Walls & Beidenbach 2005 ).
Dependency Injection / Inversion of
Control
Dependency Injection adalah suatu
konsep yang diterapkan oleh suatu objek
untuk mendapatkan objek lain yang
dibutuhkan tanpa harus mencari dan
memasukan objek tersebut secara eksplisit
(Walls & Beidenbach 2003)
Konsep ini diterapkan dalam Spring
framework. Semua DAO yang didefinisikan
tidak harus menuliskan koneksi basis
datanya secara langsung pada masing-
masing DAO, tetapi cukup memasukkan
koneksinya menjadi suatu konstruktor atau
method setter dalam DAO
(Thamura et al. 2007).
METODE PENELITIAN
Kerangka Pemikiran
Tahap-tahap yang dilakukan pada
penelitian ini diilustrasikan pada Gambar 3.
Penelitian diawali dengan studi literatur
kemudian melakukan analisis
ketidaksesuaian (mismatch) pada aplikasi
Ritel ERP (Ernita 2008) yang memunculkan
kebutuhan ORM. Tahap selanjutnya adalah
merancang dan mengimplementasikan ORM
dan design pattern untuk mengatasi masalah
ketidaksesuian tersebut. Tahap terakhir
adalah melakukan evaluasi hasil
implementasi konsep ORM tersebut.
Gambar 3 Diagram Metodologi Penelitian.
Studi Literatur
Studi literatur diawali dengan
menganalisis ORM framework yang tersedia
di lingkungan JEE. Selain itu, dilakukan
juga studi literatur dengan menganalisis
paper yang terkait.
Analisis Permasalahan Ketidaksesuaian
Aplikasi Ritel ERP (Ernita 2008)
dikembangkan dengan pendekatan
berorientasi objek, sedangkan manajemen
basis datanya menggunakan sistem
manajemen basis data relasional. Oleh
karena itu dilakukan analisis kemungkinan
ketidaksesuaian (mismatch) yang disebabkan
perbedaan paradigma tersebut.
Perancangan dan Implementasi ORM
dan Design Pattern
Pada tahap ini, dilakukan implementasi
ORM dan design pattern untuk
menghilangkan ketidaksesuaian yang
muncul dari tahap analisis. ORM
diimplementasikan menjadi enam tahap,
antara lain:
1 Membuat konfigurasi basis data.
2 Membuat pemetaan Data Transfer
Object (DTO) dengan menghilangkan
paradigma ketidaksesuaian antara basis
data relasional dan pemrograman
berorientasi objek.
3 Membuat fungsi-fungsi akses data
sebagai implementasi dari DAO
pattern, singleton pattern, dan factory
method pattern.
4 Menyederhanakan fungsi akses data
dengan memanfaatkan konsep facade
pattern dan proxy pattern.
5 Membuat skema basis data.
6 Menyatukan lapisan persistensi dengan
lapisan aplikasi.
Evaluasi
Pada tahap evaluasi dilakukan analisis
terhadap hasil implementasi ORM untuk
mengatasi ketidaksesuaian dari rancangan
aplikasi Ritel ERP dan basis data relasional
yang digunakan. Selain itu evaluasi juga
dilakukan terhadap konsep design pattern
yang digunakan.
6
HASIL DAN PEMBAHASAN
Analisis Permasalahan Ketidaksesuaian
Untuk mendapatkan gambaran yang
lebih lengkap terhadap Ritel ERP (Ernita,
2008) yang akan dianalis, berikut ini
diuraikan deskripsi umum ERP untuk
perusahan Ritel tersebut.
1 Deskripsi Umum Aplikasi Ritel ERP
Sistem ERP Ritel yang dikembangkan
Ernita (2008) terdiri atas tiga mudul, antara
lain:
Modul pembelian (Business to Business)
Purchase Requisition (PR) yang dikirim
oleh kepala gudang kepada pihak
pengadaan barang.
Request for Quotation (RFQ) dan
Purchase Order (PO) yang dikirim oleh
bagian pengadaan kepada supplier.
Demand Order (DO) yang dikirim oleh
supplier kepada bagian pengadaan
barang.
Goods Receive yang diperiksa oleh
kepala gudang saat barang diterima.
Manajemen Inventory.
Daftar supplier.
Modul Penjualan (Business-to-Customer)
Daftar katalog yang ditampilkan kepada
pelanggan.
Submodul pemesanan (add to cart)
Konfirmasi tagihan dan pembayaran.
Pengantaran barang.
Daftar pelanggan.
Modul akuntansi
Jurnal buku besar (General Ledger)
Konfirmasi tagihan dan pembayaran.
Account Receivable (AR)
Account Payable (AP)
Manajemen kode akun.
Masing-masing modul pembangun Ritel
ERP tergabung pada satu basis data yang
terpusat.
2 Analisis Masalah Ketidaksesuaian
Aplikasi Ritel ERP membutuhkan basis
data dalam menjalankan proses bisnisnya.
Tiga modul utama pembangun aplikasi Ritel
ERP mengakses pada satu basis data yang
terpusat. Setiap modul mempunyai tabel
master untuk inisialisasi data dari
lingkungan proses bisnis aplikasi Ritel ERP
dan tabel transaksi sebagai hasil transaksi
saat menjalankan proses bisnisnya. Tabel
master dan tabel transaksi yang dirancang
untuk membangun aplikasi Ritel ERP dapat
dilihat pada Lampiran 1.
Pada penelitian ini, aplikasi Ritel ERP
dikembangkan dengan pendekatan
berorientasi objek menggunakan bahasa
pemrograman Java, sedangkan sistem
manajemen basis data yang digunakan
adalah basis data relasional. Oleh karena itu,
terdapat ketidaksesuaian (mismatch) yang
ditimbulkan pada perbedaan konsep
tersebut. Pada penelitian ini, tidak semua
aspek ketidaksesuaian ditemukan. Aspek
ketidaksesuaian yang muncul adalah aspek
granularity, identitas, asosiasi antarentitas,
dan navigasi data.
Uraian berikut memaparkan analisis
ketidaksesuaian pada aspek:
a Granularity
Ketidaksesuaian pada aspek granularity
terjadi karena pada basis data relasional
tidak mengenal user-defined-data-type atau
tipe data yang didefinisikan oleh pengguna.
Ketidaksesuaian aspek granularity yang
ditemukan pada penelitian ini terjadi saat
mendefinisikan properti address pada
entitas Supplier. atribut Address terdiri
atas street, town, state, zip_code.
Aribut address akan dipisahkan menjadi
class berbeda saat pembuatan DTO, akan
tetapi setelah dipetakan tetap masuk sebagai
proserti tabel PU_SUPPLIER.
b Identitas
Ketidaksesuaian pada aspek identitas
terkait dengan perbedaan pengenal identitas
objek dan tabel. Pada objek identitas
dibedakan menjadi nilai dan alamat
memorinya. Oleh karena itu, terdapat dua
notasi yang melambangkan kesamaan suatu
identitas, yaitu lambang sama dengan (==)
dan method equals(). Sebagai contoh
(a == b), berarti variabel a dan b
memegang alamat reference yang sama pada
memori, sedangkan (a.equals(b)),
secara lojik mempunyai nilai yang sama.
Pada basis data relasional, identitas dari
suatu tabel disebut dengan primary key.
Dengan demikian, sering kali terjadi objek
yang secara lojik sama (a.equals(b))
dan mewakili satu baris dalam tabel basis
data, tetapi objek tersebut tidak berada pada
satu lokasi alamat memori yang sama.
7
c Asosiasi
Kebanyakan entitas pada basis data
mempunyai keterhubungan dengan entitas
yang lainnya. Elemen yang menghubungkan
kedua tabel tersebut ditandai dengan foreign
key.
Elemen penghubung dua objek ditandai
dengan sebuah reference object.
Permasalahannya adalah reference object
bergantung pada arah dari asosiasinya
(direction of relationship). Apabila asosiasi
antara dua objek terjadi pada dua arah, maka
harus didefinisikan dua kali pada setiap
classnya. Akan tetapi foreign key pada tabel
relasional tidak mengenal arah dari
asosiasinya, karena asosiasi antara dua tabel
dihubungkan dengan tabel join.
Ketidaksesuaian pada aspek asosiasi
meliputi relasi one-to-one, one-to-many, dan
many-to-many. Masing-masing asosiasi
antarentitas bisa dilihat pada class diagram
dan ER diagram pada Lampiran 2 dan
Lampiran 3.
d Navigasi data
Ketidaksesuaian pada aspek navigasi
terkait dengan masalah bagaimana
mengakses suatu objek yang berasal dari
objek lain. Menurut arahnya, navigasi data
terbagi menjadi dua macam, yaitu:
unidirectional dan bidirectional. Pada
konsep pemrograman berorientasi objek
konsep arah navigas menentukan suatu
objek dapat diakses melalui objek lain,
sedangkan pada basis data relasional konsep
arah navigasi tidak mempengaruhi proses
pengaksesan data dari tabel lain.
Pada konsep pemrograman berorientasi
objek, proses akses properti objek dari objek
lain bisa langsung menggunakan method
getter. Lain halnya dengan basis data
relasional, properti yang menjadi
penghubung antara dua tabel yang berelasi
yaitu foreign key.
Perancangan dan Implementasi ORM
dan Design Pattern
Setelah ditemukan empat aspek
ketidaksesuaian tersebut diimplementasikan
ORM. Selain itu juga diterapkan design
pattern untuk menghilangkan
ketidaksesuaian yang muncul pada tahap
analisis tersebut, meliputi:
1 Melakukan Konfigurasi Basis Data
Tahap konfigurasi merupakan tahap awal
sebelum melakukan akses terhadap basis
data. Konfigurasi basis data disimpan pada
file jdbc.properties. Isi dari file
jdbc.properties adalah sebagai berikut:
1 jdbc.username=root
2 jdbc.password=admin
3 jdbc.url=jdbc:mysql://localhost:
4 3306/erp
5 jdbc.driver=com.mysql.jdbc.Driver
6 hibernate.dialect=org.hibernate.
7 dialect.MySQL5InnoDBDialect
8 hibernate.show_sql=true
9 hibernate.hbm2ddl.auto=create
10 hibernate.format_sql=true
Baris pertama sampai ke lima merupakan
properti konfigurasi koneksi basis data yang
berisi username, password, host dan port
basis data, dan library koneksi yang
digunakan.
Kode pada baris ke enam menentukan
jenis dialek SQL yang akan dipetakan. Baris
ke delapan adalah properti untuk
menampilkan hasil query yang telah diubah
ke dalam bentuk SQL. Baris ke sembilan
merupakan properti yang berfungsi
mengotomasi pembuatan basis data dari
awal sampai akhir. Dan baris ke sepuluh
untuk menghasilkan query dengan format
SQL.
2 Membuat Class DTO (Data Transfer
Object)
DTO merupakan class yang
merepresentasikan setiap tabel pada basis
data. DTO dibuat berdasarkan UML class
diagram yang telah dirancang. DTO berisi
class JavaBean yang setiap propertinya akan
merepresentasikan atribut-atribut pada tabel.
Skema proses pembuatan DTO
diilustrasikan pada Gambar 4.
8
Gambar 4 Skema Pembuatan DTO.
Ketidaksesuaian yang muncul pada tahap
analisis diatasi oleh ORM pada saat
merepresentasikan class DTO dan diakses
sebagai objek.
Uraian berikut menjelaskan
implementasi konsep ORM untuk mengatasi
ketidaksesuaian pada aspek granularity,
identitas, asosiasi, dan navigasi data.
a Aspek Granularity
Proses pemetaan untuk memecah entitas
menjadi entitas yang lebih kompleks pada
atribut address dalam entitas Supplier
menjadi satu entitas address ditulis sebagai
berikut:
- Class Supplier
1 @Entity
2 @Table(name = "PU_SUPLIER")
3 public class Supplier{ 4 @Embedded
5 private Address address = new
6 Address();
7 }
- Class Address
1 @Embeddable
2 public class Address {
3 private String street;
4 private String city;
5 private String zipCode;
6 }
Properti @Embeddable pada baris
pertama class Address mengindikasikan
bahwa class Address merupakan entitas
yang bisa dilekatkan atau dimasukan ke
dalam entitas lain. Properti @Embedded di
baris ke lima pada class Supplier
menandakan bahwa entitas Address
melekat pada entitas Supplier.
b Aspek Identitas
ORM mengatasi ketidaksesuaian pada
aspek identitas dengan menambah properti
identity pada setiap entitas atau class DTO
seperti pada potongan program berikut:
1 @Entity
2 @Table(name = "IN_ITEM")
3 public class Item{
4 @Id
5 @GeneratedValue(strategy=
6 GenerationType.AUTO)
7 @Column(name="id")
8 private Long id;
9 }
Kode pada baris pertama dan kedua
menandakan bahwa class tersebut mewakili
sebuah entitas pada basis data dengan nama
tabel IN_ITEM.
@Id pada baris ke empat merupakan
properti yang merepresentasikan primary
key, secara lojik properti @Id pada class a
berbeda dengan @Id pada class b. Dengan
demikian pengujian apakah isi class a sama
dengan class b bisa ditulis seperti berikut:
a.getid().equals(b.getId()).
Properti @GeneratedValue (strategy
= GenerationType.AUTO merupakan
pengisian id yang secara otomasi seperti
auto_increment pada tabel relasional.
c Aspek Asosiasi
Asosiasi antara dua entitas terdiri atas
one-to-one, one-to-many, dan many-to-
many. Proses pemetaan asosiasi antara dua
entitas adalah sebagai berikut:
One-to-one
Gambar 5 Pemetaan Asosiasi one-to-one.
Prod_ID Prod_name Unit
price
1 pupuk 100
2 bibit 200
public class Product{
private int id;
private String prodName;
private Double unitPrice;
//getter and setter method
}
product
PK id : int
prod_name : varchar
unit_price : longint
-id : int
-prodName : string
-unitPrice : double
Product
9
Gambar 5 merupakan ilustrasi dari class
Demand yang berasosiasi one-to-one dengan
class Order. Letak foreign key atau join
column ditambahkan pada entitas yang
mempunyai total participation pada asosiasi
yang menghubungkannya.
Pada entitas yang mempunyai asosiasi
dua arah (bidirectional) diperlukan
penambahan properti mappedBy oleh
entitas yang tidak total participation (entitas
partial participation), sedangkan pada
entitas yang mempunyai asosiasi satu arah
(unidirectional) tidak perlu menambahkan
properti mappedBy.
Proses pemetaan dua class Demand dan
class Order merupakan contoh asosiasi dua
arah (association bidirectional) dan class
Demand bersifat total participation.
Pemetaan class Demand dan class Order
dapat dituliskan sebagai berikut:
- Class Order
1 @Entity
2 @Table(name="pu_order")
3 public class Order {
4 @OneToOne (mappedBy="order")
5 private Demand demand;
6 }
- Class Demand
1 @Entity
2 @Table(name="pu_demand")
3 public class Demand {
4 @OneToOne
5 @JoinColumn (name="id_order")
6 private Order order;
7 }
Properti Join Column dimasukan pada
class Demand karena entitas Demand
mempunyai total participation. Dengan
demikian, objek Demand menentukan
asosiasi antara dua entitas tersebut.
Asosiasi one-to-one di atas disebut
biderectional karena masing-masing class
memerlukan reference yang
menghubungkannya. Baris empat dan baris
enam pada class Demand menandakan suatu
reference yang mewakili foreign key dari
entitas Order. Begitu pula pada class
Order, reference yang menghubungkannya
ditulis dengan mappedBy yang dituliskan
pada baris ke empat dan lima. Properti
mappedBy=”order” pada class Order
merujuk pada nama atribut order pada
class Demand.
One-to-many
Gambar 6 Pemetaan Asosiasi one-to-many.
Gambar 6 merupakan ilustrasi class
Requisition yang berasosiasi one-to-
many dengan class RequisitionDetail.
Jadi setiap satu objek Requisition terdiri
atas banyak objek RequisitionDetail.
Seperti halnya asosiasi one-to-one,
asosiasi one-to-many mempunyai join
column yang disimpan pada entitas yang
mempunyai total participation. Akan tetapi
pada asosiasi one-to-many, entitas yang
mempunyai total participation pasti berada
pada entitas yang berkardinalitas many.
Dengan demikian, dapat dikatakan join
column berada pada entitas dengan
kardinalitas many.
Class Requisition berasosiasi one-to-
many dengan class RequisitionDetail.
Apabila asosiasinya bidirectional, maka
dapat dikatakan class
RequisitionDetail berasosiasi many-to-
one dengan class Requisition. Proses
pemetaannya ditulis sebagai berikut:
- Class RequisitionDetail
1 @Entity
2 @Table (name="pu_req_detail")
3 Public class RequisitionDetail {
4 @ManyToOne
5 @JoinColumn (name="id_req")
6 private Requisition requisition;
7 }
- Class Requisition
1 @Entity
2 @Table(name="pu_req")
3 public class Requisition{
4 @OneToMany(mappedBy =
5 "requisition")
6 private List <RequisitionDetail>
7 reqDetail = new ArrayList
8 <RequisitionDetail> ();
9 }
Asosiasi many-to-one di atas bersifat
biderectional, sehingga properti join
10
column berada pada entitas yang
berkardinalitas many yaitu class
RequisitionDetail. Akan tetapi pada
entitas yang berkardinalitas one
ditambahkan properti mappedBy sebagai
reference.
Properti asosiasi dan reference dalam
class RequisitionDetail ditulis pada
baris empat dan baris lima. Pada class
PurchaseRequisition, reference yang
menghubungkannya ditulis dengan
mappedBy seperti pada baris empat sampai
baris delepan.
Apabila asosiasinya unidirectional,
properti mappedBy pada class
Requisition dihilangkan. Properti
mappedBy = “requisition” merujuk
kepada atribut “requisition” pada class
RequisitionDetail.
Many to many
Gambar 7 Pemetaan Asosiasi many-to-many.
Gambar 7 merupakan ilusrasi class
Group berasosiasi many-to-many dengan
class Modul. Kedua entitas yang berasosiasi
many-to-many dihubungkan oleh reference
berupa join tabel. Join tabel memiliki
dua buah atribut foreign key yang berasal
dari masing-masing entitas.
Atribut join tabel dimasukan pada
entitas yang memilki total participation
pada asosiasi tersebut. Properti mappedBy
ditambahkan kepada entitas partial
participation apabila asosiasinya dua arah
(bidirectional), sedangkan pada entitas yang
mempunyai asosiasi satu arah
(unidirectional) tidak perlu menambahkan
properti mappedBy.
Proses pemetaan asosiasi di atas
merupakan asosiasi dua arah (association
bidirectional) dan entitas Modul mempunyai
total participation. Pemetaan class Group
dan class Modul dituliskan seperti berikut:
- Class Group
1 @Entity
2 @Table(name = "ad_group")
3 public class Group {
4 @ManyToMany(mappedBy=
5 "groups")
6 private List <Modul>
7 moduls = new ArrayList
8 <Modul>();
9 }
- Class Modul
1 @Entity
2 @Table(name="ad_modul")
3 public class Modul {
4 @ManyToMany
5 @JoinTable (name =
6 "ad_modul_group",
7 joinColumns={
8 @JoinColumn(name=
9 "id_ad_modul")},
10 inverseJoinColumns={
11 @JoinColumn(name=
12 "id_ad_group")})
13 private List <Group> groups =
14 new ArrayList < Group>();
15 }
Peoperti Join table dimasukan pada
properti yang mempunyai total participation
yaitu class Modul. Objek Modul
menentukan asosiasi pada kedua entitas
tersebut.
Asosiasi many-to-many di atas bersifat
biderectional karena masing-masing class
memerlukan reference yang
menghubungkannya. Properti many-to-many
pada class Modul ditulis pada baris empat.
Kemudian reference yang
menghubungkannya berupa join table
yang terdiri atas identity dari masing-masing
entitas. Properti join table ditulis pada
baris lima sampai empat belas dalam class
Modul. Dalam class Group, reference yang
menghubungkannya ditulis pada baris empat
sampai baris delapan. Properti
mappedBy=”groups” pada class Group
merujuk pada nama atribut groups pada
class Modul.
Hasil pemetaan dari asosiasi many-to-
many antara dua class tersebut adalah dua
tabel hasil transformasi dari objek yaitu
AD_MODUL dan AD_GROUP kemudian satu
tabel asosiasi AD_MODUL_GROUP.
d Aspek Navigasi data
Pada konsep pemrograman berorientasi
objek, proses akses properti objek dari objek
11
lain bisa langsung menggunakan method
getter. Contoh:
- Class Item
1 @Entity
2 @Table(name = "IN_ITEM")
3 public class Item {
4 @ManyToOne
5 @JoinColumn(name="id_brand")
6 private Brand brand;
7 }
Class Item mempunyai variabel brand
dengan tipe data Brand seperti ditulis pada
baris ke enam. Untuk mengakses nilai
brand dengan tipe data Brand pada class
Item menggunakan method getter seperti
berikut:
invItem.getInvProdBrand.getName();
Apabila arah navigasinya unidirectional,
maka tidak terdapat properti entitas Item
pada class Brand, sehingga class Brand
tidak bisa mengakses properti entitas Item.
Tetapi apabila arah navigasinya
bidirectional, maka pada class Brand
terdapat properti entitas Item seperti
berikut:
- Class Brand
1 @Entity
2 public class Brand {
3 @OneToMany(mappedBy="brand")
4 private List <Item> item = new
5 ArrayList<Item>();
6 }
Properti mappedBy pada baris ke tiga
menandakan bahwa class tersebut
mempunyai asosiasi bidirectional. Untuk
mengakses variabel item dengan tipe data
Item dari class Brand menggunakan
method getter seperti berikut:
invProdBrand.getInItem.getName();
Basis data relasional tidak mengenal
konsep arah navigasi dalam mengakses data.
Properti yang menjadi penghubung antara
dua tabel yang berelasi yatiu foreign key.
Tabel ITEM dan BRAND mempunyai relasi
one-to-many kemudian foreign key berada
pada tabel ITEM. Selama ada foreign key
yang menghubungkan kedua tabel, proses
query yang melibatkan kedua tabel bisa
dijalankan.
Query berikut merupakan query untuk
mengakses properti item dengan
berdasarkan id_brand pada tabel ITEM.
Select * from IN_ITEM i left
outer join IN_PROD_BRAND pb on
i.id=pb.id where i.id=123
Properti left outer join menandakan
bahwa foreign key berada pada tabel ITEM.
3 Membuat Fungsi Akses Data
Pada penelitian ini, DAO pattern
digunakan untuk proses enkapsulasi fungsi
untuk mengakses data ke dalam lapisan yang
berbeda, sehingga aplikasi tidak perlu
mengetahui detail proses suatu data diakses.
DAO berisi method (fungsi) untuk
mengakses dan memanipulasi data. Pada
penerapannya, DAO dapat
diimplementasikan dengan native query atau
bahasa query basis data relasional (Structure
Query language). DAO juga dapat
diimplementasikan dengan konsep ORM
dengan menggunakan HQL (Hibernate
Query Language).
Proses pembuatan fungsi-fungsi akses
dan manipulasi data memanfaatkan konsep
design pattern, yaitu factory method dan
singleton. Sebelum melakukan akses dan
manipulasi data, terlebih dulu dibuat objek
dataSource yang berisi referensi dari
properti koneksi basis data. DataSource
memanggil referensi properti koneksi basis
data yang ada pada file konfigurasi
jdbc.properties, antara lain: username,
password, server dan port, nama url basis
data, dan jenis driver RDBMS. Objek
dataSource dan semua objek DAO hanya
diinstansiasi satu kali selama aplikasi
berjalan. Objek dataSource dimasukan ke
setiap DAO ketika DAO diinstansiasi,
sehingga proses koneksi basis data tidak
dilakukan secara berulang-ulang melainkan
cukup dipanggil apabila diperlukan.
Framework ORM yang digunakan untuk
proses pengaksesan data pada penelitian ini
adalah Hibernate. DAO diimplementasikan
menggunakan HQL (Hibernate Query
Language). DAO berisi method untuk
mengakses dan memanipulasi data seperti
create, update, delete, insert, select, dan
join.
Pada penelitian ini, proses pembuatan
objek dataSource dan proses memasukan
dataSource ke dalam semua DAO
dilakukan menggunakan Spring Framework
dengan teknik Inversion of Control (IoC).
Teknik IoC dalam pembuatan objek
12
dataSource dapat dilihat pada Lampiran
5.
Selain objek dataSource, objek yang
diperlukan untuk mengakses data
menggunakan ORM adalah objek
sessionFactory. Seperti halnya objek
dataSource, objek sessionFactory
bersifat singleton, jadi objeknya hanya
dibuat sekali sepanjang aplikasi berjalan.
Objek sessionFactory dipanggil oleh
setiap class DAO yang mengakses basis
data.
SessionFactory membuat objek
session yang diperlukan untuk proses
transaksi yang berlangsung saat mengakses
data. Session merupakan objek yang
hanya sekali pakai, digunakan untuk
melakukan transaksi basis data dan setelah
selesai transaksi, session langsung ditutup.
Siklus hidup objek session berbeda
dengan objek sessionFactory,
sessionFactory dibuat sekali sepanjang
aplikasi berjalan, sedangkan session
dibuat selama proses suatu transaksi
berlangsung. Session bertanggungjawab
selama proses transaksi, session tidak
bisa ditutup sebelum transaksi berhasil dan
session akan melakukan rollback apabila
transaksi gagal.
Pada penelitian ini, proses pembuatan
sessionFactory dan proses memasukan
objek sessionFactory ke dalam semua
DAO dilakukan menggunakan Spring
framework dengan teknik Inversion of
Control (IoC) seperti halnya pada
pembuatan dan penggunaan dataSource.
Teknik IoC untuk sessionFactory dapat
dilihat pada Lampiran 5.
Objek session dibuat oleh class
HibernateDaoSupport melalui method
getHibernateTemplate. Method
getHibernateTemplate bertujuan
membersihkan lapisan aplikasi dari kode
pengaksesan data yang berulang-ulang.
Method getHibernateTemplate
membuat kode program untuk penyimpanan
objek ke dalam basis data menjadi sebagai
berikut:
public class CartDaoHibernate extends
HibernateDaoSupport{
public void save(Cart cart) {
getHibernateTemplate().saveOr
Update(cart);
}
}
Kode program untuk pengambilan objek
dari basis data ditulis sebagai berikut:
Mengambil objek cart sesuai dengan
id tertentu
public Cart getById(Long cartId) {
Cart cart = (Cart)
getHibernateTemplate().
load(Cart. class, cartId);
getHibernateTemplate().initialize
(cart);
return cart;
}
Mengambil objek cart berdasarkan
status yang sedang aktif.
Public Cart getByStatus (String
status){
Cart cart = (Cart) getHibernate
Template.find(“from Cart c where
c.status=?”, “active”);
return cart;
}
Mengambil objek detailCart
berdasarkan cart tertentu.
Public DetailCart getByCart (Cart
Cart){
DetailCart detailCart = (Detail
Cart) getHibernateTemplate.find(“from
CartDetail cd left join fetch
cd.cart”);
return detailCart;
}
Mengambil semua objek cart.
public List<Cart> getAll() {
return getHibernateTemplate().
find("from Cart");
}
Kode program untuk menghapus objek
cart:
public void delete(Cart cart) {
getHibernateTemplate().delete
(cart);
}
4 Penyederhanaan Fungsi Akses Data
Aplikasi Ritel ERP pada penelitian ini
terdiri atas 50 class DTO yang masing-
masing mempunyai interface DAO untuk
akses dan manipulasi data seperti insert,
select, atau delete. Agar mudah diakses,
semua DAO dikumpulkan berdasarkan
submodul ERP ke dalam interface Service.
Interface Service merupakan
implementasi dari facade pattern, yaitu
menyederhanakan fungsi-fungsi yang
terlihat rumit dengan mengelompokkan
fungsi-fungsi tersebut ke dalam beberapa
interface sehingga menghasilkan fungsi
yang lebih sederhana dan mudah digunakan.
Proses penyederhanaan 50 class DTO
menghasilkan tujuh interface Service,
13
antara lain AccountPayableService,
AccountReceivableService, Admin
Service, GeneralLedgerService,
InventoryService, OrderService, dan
PurchaseService. Proses memasukan
DAO ke dalam Service menggunakan
teknik Inversion of Control oleh Spring
Framework. Teknik IoC untuk Service
dapat dilihat pada Lampiran 6.
Implementasi dari semua DAO pada
Service dituliskan sebagai berikut:
public class OrderServiceImpl
implements OrderService {
DebiturDao orderDebiturDao;
CartDao orderCartDao;
}
Objek Service adalah properti yang
akan diakses oleh lapisan aplikasi dalam
proses pengaksesan basis data. Akan tetapi,
sebelumnya dilakukan teknik Declarative
Transaction terhadap Service dengan
menerapkan konsep proxy pattern, yaitu
pola yang merancang suatu objek mewakili
kontrol atau akses objek lain bertindak
seolah-olah objek tersebut melakukannya
Declarative Transaction merupakan
suatu teknik untuk medeklarasikan semua
transaksi dalam suatu file konfigurasi untuk
menangani semua proses transaksi tanpa
harus membuat kode-kode program untuk
menangani transaksi secara eksplisit. Proses
Declarative Transaction ditulis pada file
hibernate.ctx.xml.
Proses Declarative Transaction dimulai
dengan mengatur transaksi oleh objek
session. Objek session yang digunakan
saat transaksi dikendalikan oleh class proxy
yang dihasilkan melalui teknik Declarative
Transaction. Ketika lapisan aplikasi
memanggil Service untuk mengakses basis
data, method Service tidak mengakses
basis data secara langsung. Akan tetapi
Service memanggil moduleXXXService
pada file hibernate.ctx.xml untuk
membuat class proxy yang berisi fungsi-
fungsi transaksi (begin, commit, rollback).
Fungsi-fungsi transaksi tersebut dimasukan
ke dalam Session melalui method
getHibernateTemplate, sehingga tidak
perlu menuliskan proses transaksi secara
programatik mengendalikan Session,
karena transaksi dilakukan secara deklaratif
oleh class proxy melalui method
getHibernateTemplate.
5 Membuat Skema Basis Data.
Properti <prop key = "hibernate. hbm2ddl.auto"> ${hibernate.
hbm2ddl.auto} </prop> adalah property
untuk membuat skema basis data. Variabel
${hibernate.hbm2ddl.auto} merujuk
pada properti hibernate.hbm2ddl.auto
pada file jdbc.properties. nilai
variabelnya adalah create. Ada beberapa
pilihan yang bisa digunakan untuk properti
hbm2ddl.auto, yaitu create-drop
artinya Hibernate akan membuat semua
tabel pada saat inisialisasi
sessionFactory. Begitu
sessionFactory ditutup, semua tabel
akan dihapus. Pilihan yang ke dua adalah
create artinya pada saat
sessionFactory dijalankan akan
membuat semua tabel dan pada saat
sessionFactory ditutup tabel yang
dihasilkan tidak akan dihapus.
Selain properti hbm2ddl.auto, yang
digunakan pada proses pembuatan skema
basis data adalah properti
hibernate.show_sql. Properti
hiberntae.show_sql akan menampilkan
SQL yang digunakan saat query
menggunakan HQL. Skema basis data yang
dihasilkan digambarkan pada Lampiran 6.
6 Menyatukan Lapisan Persistensi
dengan Lapisan Aplikasi
Framework yang digunakan pada lapisan
aplikasi dan presentasi adalah Java Server
Faces (JSF). JSF adalah UI (User Interface)
framework untuk aplikasi Java berbasis web
dengan konsep MVC yang mendukung user
interface berbasis komponen. Setiap action
yang dilakukan memerlukan class controller
atau backing bean. Pada class controller
biasanya dilakukan proses pengaksesan
terhadap basis data.
Class controller yang akan mengakses
atau memanipulasi data memanggil method
Service sesuai data yang diperlukan.
Misalnya jika diperlukan data Item, maka
DAO yang berisi method untuk mengakses
data Item disimpan pada ItemDao,
kemudian ItemDao dimasukan ke dalam
InventoryService. Oleh karena itu,
untuk mengakses data Item dipanggil
InventoryService. Dan terakhir
mengatur konfigurasi controller untuk JSF
pada file faces-config.xml. method
Service yang digunakan oleh controller
14
dideklarasikan pada file konfigurasi faces-
config.xml.
Contoh class controller yang mengakses
data adalah seperti berikut:
1 public class InventoryController {
2 private InventoryService
3 inventoryService;
4 private Item item;
5 @PostConstruct
6 public void initBean(){
7 }
8 public String save(){
9 item.setStatus("active");
10 InventoryService.saveItem (item);
11 return "success";}
12 }
Method initBean pada baris lima dan
enam yang dianotasi oleh
@PostConstruct, artinya method ini
dipanggil setelah constructor
ListInvController dipanggil yang
bertujuan inisialisasi data pada halaman
tampilannya. Class Controller di atas
bertugas untuk menyimpan objek item ke
dalam basis data seperti dituliskan pada
baris sepuluh
Class Controller yang telah dibuat
dideklarasikan pada file konfigurasi faces-
config.xml seperti berikut:
1 <managed-bean>
2 <managed-bean-name>
3 InventoryController
4 </managed-bean-name>
5 <managed-bean-class>
6 ilkom.erp.web.controller.
7 inventory.InventoryController
8 </managed-bean-class>
9 <managed-bean-scope>
10 Request
11 </managed-bean-scope>
12 <managed-property>
13 <property-name
14 inventoryService
15 </property-name>
16 <value>
17 #{moduleInventoryService}
18 </value>
19 </managed-property>
20 </managed-bean>
Baris ke tiga merupakan penulisan
deklarasi nama controller yang akan
dipanggil pada lapisan presentasi. Nama
controller tersebut berisi class controller
yang didefinisikan pada baris ke enam dan
baris ke tujuh. Properti yang dipunyai
controller tersebut didefinisikan pada baris
ke 12 sampai baris ke 19.
Evaluasi
Proses pemetaan menggunakan ORM
dituliskan dengan kode sederhana, hal ini
sangat membantu pihak pengembang dalam
melakukan query data. ORM menghilangkan
kode-kode exception dan native query yang
terlihat berantakan dan tidak terstruktur.
ORM mengabstraksi penggunakan
Relational Data Base Management System
(RDBMS), sehingga mendukung jenis
RDBMS manapun. Query yang digunakan
tidak menurut pada satu jenis RDBMS,
melainkan menggunakan query language
yang disediakan oleh ORM.
Pemanfaatan konsep design pattern
menghasilkan kode program yang lebih rapi
dan terstruktur, serta memudahkan untuk
proses integrasi antara lapisan basis data dan
lapisan aplikasi. Dengan penerapan konsep
design pattern, kode program aplikasi dapat
dengan mudah dipelihara untuk
pengembangan aplikasi selanjutnya.
Perbedaan fungsi akses data tanpa
menggunakan ORM, teknik Inversion of
Controls, dan teknik Declarative
Transaction, akses data menggunakan ORM
tetapi tanpa penerapan teknik Inversion of
Controls dan teknik Declarative
Transaction, dan fungsi akses data
menggunakan ORM, Inversion of Controls,
dan teknik Declarative Transaction dapat
dilihat pada Lampiran 7.
Kekurangan dari konsep ORM yang
diterapkan dalam pengembangan sistem
ERP yaitu apabila terjadi perubahan,
penambahan, dan pengurangan domain
model harus meliputi seluruh aspek dari
mulai pembuatan DTO, DAO, Service,
dan deklarasi pada file konfigurasi.
KESIMPULAN DAN SARAN
Kesimpulan
Pada penelitian ini, tidak semua aspek
ketidaksesuaian ditemukan. Aspek
ketidaksesuaian yang muncul pada
penelitian ini hanya meliputi empat aspek,
yaitu aspek granularity, identitas, navigasi
data, dan asosiasi antarentitas. Implementasi
konsep ORM terbukti dapat menghilangkan
ketidaksesuian yang muncul karena
perbedaan antara aplikasi yang dibangun
dengan pendekatan berorientasi objek dan
basis data relasional yang digunakan.
15
Penerapan ORM yang dilengkapi dengan
design pattern membuat sistem ERP
terstruktur dalam pengelolaan basis datanya.
ORM menghemat resource untuk koneksi
pada basis data serta proses konfigurasinya
mudah untuk dikelola, ORM tidak
bergantung pada jenis RDBMS apapun,
sehingga apabila terjadi perubahan atau
migrasi RDBMS tidak perlu mengubah SQL
menurut RDBMS yang digunakan.
Penerapan design pattern pada teknik
Declarative Transaction dan Inversion of
Controls dapat memudahkan proses
pengaksesan dan manipulasi pada lapisan
aplikasi (controller). Fungsi-fungsi
pengaksesan basis data dapat digunakan
berulang-ulang sehingga sistem ERP mudah
untuk dikembangkan.
Saran
Penerapan ORM lebih lanjut bisa
dilengkapi dengan melakukan proses
pengujian terhadap pengaksesan basis data
menggunakan DBUnit. Penelitian
selanjutnya bisa dilakukan dengan
mengukur waktu eksekusi antara
pengaksesan basis data menggunakan ORM
dan pengaksesan basis data tanpa
menggunakan ORM. Selain itu juga,
penelitian selanjutnya dapat dilakukan
dengan menganalisis penerapan ORM pada
framework yang berbeda (TopLink,
openJPA, atau iBatis) atau pada platform
yang berbeda (.Net).
DAFTAR PUSTAKA
Alur D, Crupi J, Malks D. 2003. Core
J2EE™ Patterns: Best Practices and
Design Strategies, Ed ke-2. United
States: Addison-Wesley.
Bauer C, King G. 2007. Java Persistence
with Hibernate. United States : Manning.
Connolly TM, Carolyn EB. 2002. Database
System: A Practical Approach To
Design, Implementation, and
Management. England: Addison-Wesley.
Ernita, H. 2008. Pengembangan Enterprise
Resource Planning Untuk Perusahaan
Ritel. Prosiding Paper Seminar Nasional
Informatika 2008 UPN Veteran
Yogyakarta. 24 Mei 2008. Buku 2:23-32.
Gamma et al. 1995. Design Patterns:
Elements of Reusable Object-Oriented
Software. United States: Addison-
Wesley.
Husted T. 2003. Struts in Action : Building
Web Application with the Leading Java
Framework. United States : Manning.
McGovern J. 2003. Java™ 2 Enterprise
Edition 1.4 Bible. Canada: Willey
Publishing.
Nugraha B. 2005. Object Relational
Mapping. [Skripsi]. Bogor: Departemen
Ilmu Komputer, Institut Pertanian Bogor.
Parr A. N. 2000. A Taxonomi of ERP
Implementation Approach. School of
Business System, Monash University.
Peak P, Heudecker N. 2006. Hibernate
Quickly. United States: Manning.
Rashid et. al. 2002. The Evolution of ERP
System: A Historical Perspective. USA:
IRM Press.
Thamura F. et al. 2007. Cara Cepat
Mengembangkan Solusi Java Enterprise
dengan Arsitektur MVC. Jakarta:
Bambumas.
Wahab H. 2007. Struts Framework dan JEE
Pattern Dalam Pengembangan Sistem
Informasi Akademik IPB. [Skripsi].
Bogor: Departemen Ilmu Komputer,
Institut Pertaniahn Bogor.
Walls C, Breidenbach R. 2005. Spring in
Action. United States: Manning.
LAMPIRAN
17
Lampiran 1 Daftar Tabel
1. Modul accountPayable
no Nama tabel keterangan
1. AP_INVOICE Tabel transaksi invoice account payable
2. AP_INVOICE_DETAIL Tabel transaksi invoice detail account payable
3. AP_PAYMENT Tabel transaksi payment account payable
4. AP_PAYMENT_DETAIL Tabel transaksi payment detail account payable
5. AP_MONTHEND Tabel transaksi month end process account payable
2. Modul accountPayment
no Nama tabel keterangan
1. AR_INVOICE Tabel transaksi invoice account receiveable
2. AR_INVOICE_DETAIL Tabel transaksi invoice detail account receiveable
3. AR_RECEIPT Tabel transaksi payment account receiveable
4. AR_RECIEPT_DETAIL Tabel transaksi payment detail account receiveable
5. AR_MONTHEND Tabel transaksi month end process account receiveable
3. Modul admin
no Nama tabel keterangan
1. AD_ACCOUNT_PERIODE Tabel master periode kode akun
2. AD_COMPANY Tabel master informasi perusahaan
3. AD_GROUP Tabel master grup (role) pegawai
4. AD_MODUL Tabel master modul untuk masing-masing role
5. AD_MODUL_PERIODE Tabel master periode modul
6. AD_PAGE Tabel master daftar halaman (screen page)
7 AD_UOM Tabel master unit of measurement (satuan pengukuran)
8. AD_UOM_CONVERTION Tabel master konversi unit pengukuran
9. AD_USER Tabel master daftar pengguna
10. AD_VEHICLE Tabel master daftar kendaraan
11. AD_GROUP_MODUL Tabel hasil asosiasi many-to-many group dan modul
4. Modul generalLedger
no Nama tabel keterangan
1. GL_JOURNAL Tabel transaksi pos jurnal
2. GL_JOURNAL_DETAIL Tabel transaksi pos jurnal detail
3. GL_MONTHEND Tabel transaksi month end process
4. GL_ACCOUNT Tabel master kode akun
5. Modul Inventory
no Nama tabel keterangan
1. IN_GOODS_RECEIVE Tabel transaksi goods receive
2. IN_GOODS_RECEIVE_DETAIL Tabel transaksi goods receive detail
3. IN_ITEM Tabel master manajemen inventory
4. IN_MONTHEND_ITEM Tabel transaksi month end process inventory
5. IN_PROD_BRAND Tabel master produc brand
6. IN_PROD_CATEGORY Tabel master product category
18
6. Modul Order
no Nama tabel keterangan
1. OR_CART Tabel transaksi add to cart
2. OR_CART_DETAIL Tabel transaksi cart detail
3. OR_DEBITUR Tabel master daftar debitur (costumer)
4. OR_DELIVERY Tabel transaksi pengantaran barang
5. OR_MONHTEND_TRX Tabel transaksi month end process
6. OR_PAYMENT_TYPE Tabel master tipe pembayaran
7. OR_SHIPPING_TYPE Tabel master tipe pengirirman barang
7. Modul Purchase
no Nama tabel keterangan
1. PU_DEMAND Tabel transaksi demand order (DO)
2. PU_DEMAND_DETAIL Tabel transaksi demand order detail
3. PU_MONTHEND_TRX Tabel transaksi month end process
4. PU_ORDER Tabel transaksi purchase order (PO)
5. PU_ORDER-DETAIL Tabel transaksi purcahse order detail
6. PU_REQUISITION Tabel transaksi purchase requisition
7. PU_REQUISITION_DETAIL Tabel transaksi purchase requisition detail
8. PU_SUPPLIER Tabel master daftar supplier
9. PU_RFQ Tabel transaksi request for quotation
10. PU_RFQ_DETAIL Tabel transaksi request for quotation detail
11. PU_RFQ_PRICE Tabel transaksi harga yang diinput supplier
12. PU_RFQ_SUPPLIER Tabel asosiasi many-to-many RFQ dan supplier
13. PU_SUPPLIER_RFQ Tabel asosiasi many-to-many supplier dan RFQ
19
Package purchase
-id : Long
-code : String
-refNO : String
-refDate : Date
-amount : Double
-accMonth : Integer
-accYear : Integer
-status : String
-createDate : Date
-updateDate
-supplier : Supplier
-demand : Demand
Invoice
Modul admin
-id : Long
-name : String
-status : String
-expiredDate : Date
-createDate : Date
-updateDate : Date
-groups : Group
Modul
-id : Long
-desc : String
-status : String
-createDate : Date
-updateDate : Date
UOM
Package inventory
-id : Long
-desc : String
-reOrderLevel : Integer
-bin : String
-qtyOnHand : Integer
-qtyOnHold : Integer
-qtyOnOrder : Integer
-qtyReORder : Integer
-initCost : Double
-lowCost : Double
-highCost : Double
-avrgCost : Double
-diffAvrgCost : Double
-closingBal : Double
-closingAvrgBal : Double
-closingDiffAvrgCost : Double
-status : String
-lastOrderDate : Date
-lastIssueDate : Date
-createDate : Date
-updateDate : Date
-lastCostFinal : Double
-latestCostInitial : Double
-latestCostSecond : Double
-sellFixPrice : Double
-sellLatestCost : Double
-sellAvrgCost : Double
-attach : Byte
-prodCat : ProdCat
-prodBrand : ProdBrand
-glAcc : Account
-uom : UOM
Item
Package
generalLedger
-id : Long
-code : String
-desc : String
-status : String
-createDate : Date
-updateDate : Date
Account
-id : Long
-name : String
-contactPerson : String
-creditTerm : String
-creditLimit : Double
-bankAccName : String
-bankAccNo : String
-status : String
-createDate : Date
-updateDate : Date
-address : Address
-glAcc
Supplier
-id : Long
-code : String
-amount : Double
-deliveryAddress : String
-deliveryDate : Date
-transDate : Date
-status : String
-accMonth : Integer
-accYear : Integer
-status : String
-order : Order
-supplier : Supplier
Demand
-demand
1
-invoice
1
-supplier
1
-invoice
*
-id : Long
-quantity : Integer
-price : Double
-status : String
-createDate : Date
-updateDate : Date
-item : Item
-uom : UOM
-invoice : Invoice
-acc : Account
-monthend
InvoiceDetail
-invoiceDetail
1
-invoice*
-invoiceDetail1
-item
1
-acc
1
-invoiceDetail 1-uom 1
-invoiceDetail
1 -id : Long
-idDoc : String
-idDocDetail : String
-docType : String
-docDate : Date
-accYear : Integer
-accMonth : Integer
-desc : String
-quantity : Integer
-price : Double
-amount : Double
-status : String
-createDate : Date
-updateDate : Date
-item : Item
-uom : UOM
-acc : Account
-modul : Modul
MonthEnd
-monthEnd
1
-modul
1
-monthEnd
1
-acc
1
-item
1
-monthEnd
1
-monthEnd
1
-uom1
-id : Long
-code : String
-amount : Double
-accYear : Integer
-accMonth : Integer
-status : String
-createDate : Date
-updateDate : Date
-supplier : Supplier
Payment
-id : Long
-amount : Double
-status : String
-createDae : Date
-updateDate : Date
-payment : Payment
-invoice : Invoice
-acc : Account
-monthEnd : MonthEnd
PaymentDetail
-payment
1-supplier *
-paymentDetail1
-payment*
-paymentDetail1
-acc
1
-monthEnd 1
-paymentDetail
*
-paymentDetail1
-invoice1
Lampiran 2 Class Diagram Data Transfer Object
a. Modul AccountPayable
20
Package order
Modul admin
-id : Long
-name : String
-status : String
-expiredDate : Date
-createDate : Date
-updateDate : Date
-groups : Group
Modul
-id : Long
-desc : String
-status : String
-createDate : Date
-updateDate : Date
UOM Package inventory
-id : Long
-desc : String
-reOrderLevel : Integer
-bin : String
-qtyOnHand : Integer
-qtyOnHold : Integer
-qtyOnOrder : Integer
-qtyReORder : Integer
-initCost : Double
-lowCost : Double
-highCost : Double
-avrgCost : Double
-diffAvrgCost : Double
-closingBal : Double
-closingAvrgBal : Double
-closingDiffAvrgCost : Double
-status : String
-lastOrderDate : Date
-lastIssueDate : Date
-createDate : Date
-updateDate : Date
-lastCostFinal : Double
-latestCostInitial : Double
-latestCostSecond : Double
-sellFixPrice : Double
-sellLatestCost : Double
-sellAvrgCost : Double
-attach : Byte
-prodCat : ProdCat
-prodBrand : ProdBrand
-glAcc : Account
-uom : UOM
ItemPackage
generalLedger
-id : Long
-code : String
-desc : String
-status : String
-createDate : Date
-updateDate : Date
Account
-id : Long
-name : String
-contactPerson : String
-address : String
-town : String
-state : String
-postCode : String
-telpNo : String
-faxNO : String
-email : String
-creditTerm : String
-creditLimit : Double
-status : String
-password : String
Debitur
-id : Long
-cartCode : String
-status : String
-refId : String
-amount : Double
-transDate : Date
-accYear : Integer
-accMonth : Integer
-status : String
-createDate : Date
-updateDate : Date
-shippingType : ShippingType
-paymentType : PaymentType
-debitur : Debitur
Cart
-id : Long
-code : String
-amount : Double
-accMonth : Integer
-accYear : Integer
-status
-createDate : Date
-updateDate : Date
-debitur : Debitur
-cart : Cart
Invoice
-cart
1
-invoice
1
-debitur1
-invoice*
-id : Long
-desc : String
-quantity : Integer
-price : Double
-status : String
-createDate : Date
-updateDate : Date
-invoice : Invoice
-item : Item
-uom : UOM
-acc : Account
InvoiceDetail
-invoice*
-invoiceDetail1
-acc
1
-invoiceDetail
1
-uom 1
-invoiceDetail
1
-item
1
-invoiceDetail
1
-id : Long
-idDoc : String
-idDocDetail : String
-docType : String
-docDate : Date
-accMonth : Integer
-accYear : Integer
-desc : String
-quantity : Integer
-price : Double
-amount : Double
-status : String
-modul : Modul
-item : Item
-uom : UOM
-acc : Account
MonthEnd
-uom
1
-monthEnd
1
-monthEnd
1
-item
1
-acc
1
-monthEnd 1
-monthEnd 1
-modul 1
-id : Long
-code
-amount : Double
-accMonth : Integer
-accYear : Integer
-status : String
-createDate : Date
-updateDate : Date
-debitur : Debitur
Receipt
-debitur 1
-receipt
*
-id : Long
-amount : Double
-status : String
-createDate : Date
-updateDate : Date
-receipt : Receipt
-invoice : Invoice
-acc : Account
ReceiptDetail
-receiptDetail1
-acc1
-receiptDetail1
-invoice1
-receiptDetail
1
-receipt
*
Lanjutan Lampiran 2 Class Diagram
b. Modul AccountReceivable
21
Package inventory
Package admin
-id : Long
-code : String
-docRefNo : String
-docRefDate : String
-docAmount : Double
-total : Double
-accMonth : Integer
-accYear : Integer
-status : String
Journal
-id : Long
-amount : Double
-desc : String
-status : String
-createDate : Date
-updateDate : Date
-account
-journal : Journal
JournalDetail-id : Long
-idDoc : Long
-idDocDetail : Long
-docType : String
-docDate : Date
-accMonth : Integer
-accYear : Integer
-desc : String
-amount : Double
-quantity : Integer
-price : Double
-status : String
-createDate : Date
-updateDate : Date
-modul : Modul
-item : Item
-accCode : Account
-uom : UOM
MonthEnd
-id : Long
-code : String
-desc : String
-status : String
-createDate : Date
-updateDate : Date
Account
-acc
1
-monthEnd
*
-journalDetail
1 -journal
*
-id : Long
-name : String
-status : String
-expiredDate : Date
-createDate : Date
-updateDate : Date
-groups : Group
Modul
-id : Long
-desc : String
-status : String
-createDate : Date
-updateDate : Date
UOM
-uom
1 -monthEnd
1
-modul1
-monthEnd
1
-id : Long
-desc : String
-reOrderLevel : Integer
-bin : String
-qtyOnHand : Integer
-qtyOnHold : Integer
-qtyOnOrder : Integer
-qtyReORder : Integer
-initCost : Double
-lowCost : Double
-highCost : Double
-avrgCost : Double
-diffAvrgCost : Double
-closingBal : Double
-closingAvrgBal : Double
-closingDiffAvrgCost : Double
-status : String
-lastOrderDate : Date
-lastIssueDate : Date
-createDate : Date
-updateDate : Date
-lastCostFinal : Double
-latestCostInitial : Double
-latestCostSecond : Double
-sellFixPrice : Double
-sellLatestCost : Double
-sellAvrgCost : Double
-attach : Byte
-prodCat : ProdCat
-prodBrand : ProdBrand
-glAcc : Account
-uom : UOM
Item
-monthEnd
1
-item
1
Lanjutan Lampiran 2 Class Diagram
c. Modul GeneralLedger
22
Package
generalLedger
-id : Long
-accYear : Integer
-maxPeriode : Integer
-status : String
-createDate : Date
-updateDate : Date
AccPeriode
-id : Long
-companyName : String
-address : String
-city : String
-state : String
-postCode : String
-telpNo : String
-faxNo : String
-status : String
-createDate : Date
-updateDate : Date
Company
-id : Long
-desc : String
-status : String
-createDate : Date
-updateDate : Date
-moduls : Modul
Group
-id : Long
-name : String
-status : String
-expiredDate : Date
-createDate : Date
-updateDate : Date
-groups : Group
Modul
-id : Long
-inAccMonth : Integer
-inAccYear : Integer
-puAccMonth : Integer
-puAccYear : Integer
-orAccMonth : Integer
-orAccYear : Integer
-arAccMonth : Integer
-arAccYear : Integer
-apAccMonth : Integer
-apAccYear : Integer
-glAccMonth : Integer
-glAccYear : Integer
-createDate : Date
-updateDate : Date
ModulPeriode
-id : Long
-desc : String
-status : String
-createDate : Date
-updateDate : Date
UOM
-id : Long
-rate : Integer
-status : String
-createDate : Date
-updateDate : Date
-uomTo : UOM
-uomFrom : UOM
UOMConvertion
-id : Long
-name : String
-password : String
-email : String
-employeId : String
-role : String
-status : String
-createDate : Date
-updateDate : Date
-groups : Group
User
-id : Long
-desc : String
-type : String
-load : Integer
-driver : String
-model : String
-capacity : Integer
-status : String
-createDate : Date
-updateDate : Date
-uom : UOM
-acc : Account
Vehicle
-id : Long
-name : String
-url : String
-desc : String
-status : String
-createDate : Date
-updateDate : Date
-modul : Modul
Page
-user
*
-groups
1
-uomConverttion 1
-uom *-moduls*
-groups*
-modul
1
-page
*
-uom *
-vehicle 1
-id : Long
-code : String
-desc : String
-status : String
-createDate : Date
-updateDate : Date
Account
-vehicle
1
-acc
*
Lanjutan Lampiran 2 Class Diagram
d. Modul Admin
23
Package
generalLedger
Package admin
-id : Long
-desc : String
-status : String
-createDate : Date
-updateDate : Date
ProdBrand
-id : Long
-desc : String
-status : String
-createDate : Date
-updateDate : Date
ProdCat
-id : Long
-desc : String
-reOrderLevel : Integer
-bin : String
-qtyOnHand : Integer
-qtyOnHold : Integer
-qtyOnOrder : Integer
-qtyReORder : Integer
-initCost : Double
-lowCost : Double
-highCost : Double
-avrgCost : Double
-diffAvrgCost : Double
-closingBal : Double
-closingAvrgBal : Double
-closingDiffAvrgCost : Double
-status : String
-lastOrderDate : Date
-lastIssueDate : Date
-createDate : Date
-updateDate : Date
-lastCostFinal : Double
-latestCostInitial : Double
-latestCostSecond : Double
-sellFixPrice : Double
-sellLatestCost : Double
-sellAvrgCost : Double
-attach : Byte
-prodCat : ProdCat
-prodBrand : ProdBrand
-glAcc : Account
-uom : UOM
Item
-id : Long
-desc : String
-status : String
-createDate : Date
-updateDate : Date
UOM
-id : Long
-code : String
-desc : String
-status : String
-createDate : Date
-updateDate : Date
Account
-item
1
-prodBrand
*
-item
1
-prodCat
*
-uom
1
-item
1
-account
1
-item
1
-id : Long
-transDate : Date
-status : String
-createDate : Date
-updateDate : Date
-deliveryDate : Date
-supplier
-demand
GoodsReceive
-id : Long
-quantity : Integer
-price : Double
-status : String
-createDate : Date
-updateDate : Date
-item : Item
-uom : UOM
-goodsReceive : GoodsReceive
GoodsReceiveDetail
-detail1
-goodReceive
*
-uom 1
-goodReceiveDetail 1 -goodsReceiveDetail1
-uom
1
-id : Long
-accMonth : Integer
-accYear : Integer
-quantity : Integer
-avrgCost : Double
-amount : Double
-status : String
-createDate : Date
-updateDate : Date
-item : Item
MonthEndItem
-monthEnd
1
-item
1
Lanjutan Lampiran 2 Class Diagram
e. Modul Inventory
24
-id : Long
-name : String
-contactPerson : String
-address : String
-town : String
-state : String
-postCode : String
-telpNo : String
-faxNO : String
-email : String
-creditTerm : String
-creditLimit : Double
-status : String
-password : String
Debitur -id : Long
-cartCode : String
-status : String
-refId : String
-amount : Double
-transDate : Date
-accYear : Integer
-accMonth : Integer
-status : String
-createDate : Date
-updateDate : Date
-shippingType : ShippingType
-paymentType : PaymentType
-debitur : Debitur
Cart
-id : Long
-price : Double
-quantity : Integer
-status : String
-createDate : Date
-updateDate : Date
-item : Item
-uom : UOM
-acc : Account
-cart : Cart
CartDetail
Package
generalLedger
-id : Long
-code : String
-desc : String
-status : String
-createDate : Date
-updateDate : Date
Account
Package inventory
-id : Long
-desc : String
-reOrderLevel : Integer
-bin : String
-qtyOnHand : Integer
-qtyOnHold : Integer
-qtyOnOrder : Integer
-qtyReORder : Integer
-initCost : Double
-lowCost : Double
-highCost : Double
-avrgCost : Double
-diffAvrgCost : Double
-closingBal : Double
-closingAvrgBal : Double
-closingDiffAvrgCost : Double
-status : String
-lastOrderDate : Date
-lastIssueDate : Date
-createDate : Date
-updateDate : Date
-lastCostFinal : Double
-latestCostInitial : Double
-latestCostSecond : Double
-sellFixPrice : Double
-sellLatestCost : Double
-sellAvrgCost : Double
-attach : Byte
-prodCat : ProdCat
-prodBrand : ProdBrand
-glAcc : Account
-uom : UOM
Item
Modul admin
-id : Long
-name : String
-status : String
-expiredDate : Date
-createDate : Date
-updateDate : Date
-groups : Group
Modul
-id : Long
-desc : String
-status : String
-createDate : Date
-updateDate : Date
UOM
-id : Long
-deliveryDate : Date
-driver : String
-load : Integer
-createDate : Date
-updateDate : Date
-vehicle : Vehicle
-debitur : Debitur
-uom : UOM
Delivery
-id : Long
-desc : String
-type : String
-load : Integer
-driver : String
-model : String
-capacity : Integer
-status : String
-createDate : Date
-updateDate : Date
-uom : UOM
-acc : Account
Vehicle
-id : Long
-desc : String
-createDate : Date
-updateDate : Date
PaymentType
-id : Long
-idDoc : Long
-idDocDetail : Long
-docType : String
-docDate : Date
-accMonth : Integer
-accYear : Integer
-desc : String
-amount : Double
-quantity : Integer
-price : Double
-status : String
-createDate : Date
-updateDate : Date
-modul : Modul
-item : Item
-accCode : Account
-uom : UOM
MonthEnd-id : Long
-desc : String
-createDate : Date
-updateDate : Date
ShippingType
-cart
1
-shipping
1
-payment1
-cart*
-cart
1
-debitur
*
-cart *
-cartDetail
1
-uom
1
-cartDeail
1
-item
1-cartDetail1
-acc
1
-cartDetail
1
-debitur 1
-delivery
1
-acc1
-vehicle
1
-uom
1
-monthend
1
-acc
1
-monthend
1
-item1
-monthend
1
-modul1
-monthend
1
Lanjutan Lampiran 2 Class Diagram
f. Modul Order
25
Modul admin
-id : Long
-name : String
-contactPerson : String
-creditTerm : String
-creditLimit : Double
-bankAccName : String
-bankAccNo : String
-status : String
-createDate : Date
-updateDate : Date
-address : Address
-glAcc
Supplier
-address : String
-town : String
-state : String
-postCode : String
-telpNo : String
-faxNo : String
-email : String
Address-address1
-supplier
1
-id : Long
-code : String
-transDate : Date
-status : String
-createDate : Date
-updateDate : Date
-accYear : Integer
-accMonth : Integer
Requisition
Package inventory
-id : Long
-desc : String
-reOrderLevel : Integer
-bin : String
-qtyOnHand : Integer
-qtyOnHold : Integer
-qtyOnOrder : Integer
-qtyReORder : Integer
-initCost : Double
-lowCost : Double
-highCost : Double
-avrgCost : Double
-diffAvrgCost : Double
-closingBal : Double
-closingAvrgBal : Double
-closingDiffAvrgCost : Double
-status : String
-lastOrderDate : Date
-lastIssueDate : Date
-createDate : Date
-updateDate : Date
-lastCostFinal : Double
-latestCostInitial : Double
-latestCostSecond : Double
-sellFixPrice : Double
-sellLatestCost : Double
-sellAvrgCost : Double
-attach : Byte
-prodCat : ProdCat
-prodBrand : ProdBrand
-glAcc : Account
-uom : UOM
Item
-id : Long
-quantity : Integer
-createDate : Date
-updateDate : Date
-item : Item
-uom : UOM
-requisition : Requisition
RequisitionDetail
Package
generalLedger
-id : Long
-code : String
-desc : String
-status : String
-createDate : Date
-updateDate : Date
Account
-id : Long
-name : String
-status : String
-expiredDate : Date
-createDate : Date
-updateDate : Date
-groups : Group
Modul
-id : Long
-desc : String
-status : String
-createDate : Date
-updateDate : Date
UOM
-reqDetail1
-requisition*
-item
1-reqDEtail
1
-uom
1
-eqDetail
1
-id : Long
-code : String
-amount : Double
-status : String
-supplier : Supplier
-supplierPrice : Supplier
-selectedSupplier : Supplier
-requisition : Requisition
-deliveryDate : String
-accMonth : Integer
-accYear : Integer
-createDate : Date
-updateDate : Date
RFQ
-id : Long
-quantity : Integer
-price : Double
-status : String
-createDate : Date
-updateDate : Date
-item : Item
-uom : UOM
-rfq : RFQ
RFQDetail
-rfqDetail*
-rfq1
-item
1
-rfqDetail
1
-uom1
-reqDetail
1
-id : Long
-price : Double
-deliveryDate : String
-rfqDetail : RFQDetail
-supplier : Supplier
Price
-price
1
-rfqDetail
*
-id : Long
-code : String
-amount : Double
-deliveryAddress : String
-deliveryDate : Date
-transDate : Date
-status : String
-accYear : Integer
-accMonth : Integer
-createDate : Date
-updateDate : Date
-rfq : RFQ
-supplier : Supplier
Order
-rfq 1-order*
-supplier1
-order*
-id : Long
-code : String
-amount : Double
-deliveryAddress : String
-deliveryDate : Date
-transDate : Date
-status : String
-accMonth : Integer
-accYear : Integer
-status : String
-order : Order
-supplier : Supplier
Demand
-supplier
1
-demand
*
-order 1
-demand
1
-id : Long
-quantity : Integer
-price : Double
-status : String
-createDate : Date
-item : Item
-uom : UOM
DemandDetail
-demandDetail1
-demand*
-id : Long
-quantity : Integer
-price : Double
-status : String
-createDate : Date
-updateDate : Date
-item : Item
-uom : UOM
-order : Order
OrderDetail
-order*
-orderDetail 1
-item 1
-orderDetail*
-uom1
-orderDetail*
-item
1
-demandDetail 1
-uom
1
-demandDetail
*
-id : Long
-idDoc : Long
-idDocDetail : Long
-docType : String
-docDate : Date
-accMonth : Integer
-accYear : Integer
-desc : String
-amount : Double
-quantity : Integer
-price : Double
-status : String
-createDate : Date
-updateDate : Date
-modul : Modul
-item : Item
-accCode : Account
-uom : UOM
MonthEnd
-modul
1
-monthEnd
1
-uom
1
-monthEnd 1
-item 1
-monthEnd 1
-account
1
-monthEnd
1
Lanjutan Lampiran 2 Class Diagram
g. Modul Purchase
26
AD_USER
PK UserID
FK1 GroupCode
AD_ACC_PERIODE
PK accPeriodCode
AD_COMPANY
PK CompCode
AD_GROUP
PK GroupCode
AD_MODULE_GROUP
FK1 GroupCode
FK2 ModuleCode
AD_MODULE
PK ModuleCode
AD_MODUL_PERIOD
PK modulPeriodCode
AD_PAGE
PK PageCode
FK1 ModuleCode
AD_UOM
PK UOMCode
AD_UOMCONVERTION
PK UOMFrom
PK UOMTo
FK1 UOMCode
AD_VEHICLE
PK VehicleCode
FK1 UOMCode
FK2 AccCode
Modul
generalLedger
GL_ACCOUNT2
PK AccCode
1…*
1
1…*
1…*
1
1
1…*
1
1
1
1
1
1
1
GL_JOURNAL
PK JournalCode
GL_JOURNAL_DETAIL
PK JournalDetailCode
FK1 JournalCode
FK2 AccCode
GL_MONTHEND
PK monthEndCode
FK1 ModuleCode
FK2 UOMCode
FK3 AccCode
FK4 ItemCode
GL_ACCOUNT
PK AccCodeModul admin
AD_MODULE
PK ModuleCode
AD_UOM
PK UOMCode
Modul inventory
IN_ITEM
PK ItemCode
ProdCatCode
ProdBrandCode
1…*
1
1
1
1
1
1
11
1
1
1
Lampiran 3 ER Diagram
a. Modul admin
b. Modul general Ledger
27
Modul purchase
Modul adminIN_PROD_BRAND
PK ProdBrandCode
IN_PROD_CAT
PK ProdCatCode
IN_ITEM
PK ItemCode
FK1 ProdBrandCode
FK2 ProdCatCode
FK3 AccCode
FK4 UOMCode
IN_GOODS_RECEIVE
PK GoodReceiveCode
FK1 DemandCode
FK2 SupplierCode
IN_GOODS_RECEIVE_DETAIL
PK GdRcvDetailCode
FK1 GoodReceiveCode
FK2 ItemCode
FK3 UOMCode
AD_UOM
PK UOMCode
PU_DEMAND
PK DemandCode
OrderCode
SupplierCode
PU_SUPPLIER
PK SupplierCode
AccCode
IN_MONTHEND_ITEM
PK monthItemEndCode
Modul
generalLedger
GL_ACCOUNT3
PK AccCode
1
1..*
1
1..*
1
1
1
1
1
1
1
1
1
1
1
1 1
1..*
1
Modul admin
OR_PAYMENT_TYPE
PK paymentTypeCode
OR_MONTHENDTRX
PK monthEndCode
FK1 ModuleCode
FK2 AccCode
FK3 UOMCode
FK4 ItemCode
OR_CART
PK CartCode
FK1 paymentTypeCode
FK2 shippingTypeCode
FK3 DebiturCode
OR_CART_DETAIL
PK CartDetailCode
FK1 CartCode
FK2 ItemCode
FK3 UOMCode
FK4 AccCode
OR_DELIVERY
PK DeliveryCode
FK1 VehicleCode
FK2 UOMCode
FK3 DebiturCode
OR_SHIPPING_TYPE
PK shippingTypeCode
OR_DEBITUR
PK DebiturCode
FK1 AccCode
Modul
generalLedger
GL_ACCOUNT
PK AccCode
Modul inventory
IN_ITEM
PK ItemCode
ProdCatCode
ProdBrandCode
AD_UOM
PK UOMCode
AD_MODULE
PK ModuleCode
AD_VEHICLE
PK VehicleCode
1..*
1
1
1
1
1
1..*
1
1
1
1
1
11
1
1
1
1
1
1
11111
1
1
1
1
1
1
1
1
c. Modul inventory
d. Modul order
28
PU_SUPPLIER
PK SupplierCode
FK1 AccCode
PU_REQUISITION
PK requisitionCode
PU_REQUISITION_DETAIL
PK reqDetailCode
FK1 requisitionCode
FK2 UOMCode
FK3 ItemCode
PU_RFQ
PK RFQCode
FK1 SupplierCode
FK2 requisitionCode
PU_RFQ_PRICE
PK priceCode
FK1 RFQCode
FK2 SupplierCode
PU_RFQ_DETAIL
PK RFQDetailCode
FK1 ItemCode
FK2 UOMCode
FK3 RFQCode
PU_RFQ_SUPPLIER
FK1 RFQCode
FK2 SupplierCode
PU_SUPPLIER_RFQ
FK1 RFQCode
FK2 SupplierCode
PU_MONTHENDTRX
PK monthEndCode
FK1 ItemCode
FK2 UOMCode
FK3 ModuleCode
PU_ORDER
PK OrderCode
FK1 RFQCode
FK2 SupplierCode
PU_ORDER_DETAIL
PK OrderDetailCode
FK1 OrderCode
FK2 ItemCode
FK3 UOMCode
PU_DEMAND
PK DemandCode
FK1 OrderCode
FK2 SupplierCode
PU_DEMAND_DETAIL
PK DemmandDetailCOde
FK1 UOMCode
FK2 ItemCode
FK3 DemandCode
Modul admin
AD_MODULE
PK ModuleCode
Modul
inventory
IN_ITEM
PK ItemCode
ProdCatCode
ProdBrandCode
AD_UOM
PK UOMCode
Modul
generalLedger
GL_ACCOUNT
PK AccCode
1..*
1
1
1…
*
1…
*
1…
*
1
1
1
1
1
1
1
1..*
1
1
1
1
1
1..*
1
1
1
1..*
1
1
1..*
1
1..*
1
1
1
1
1
1
1
1…
*
1
1..*
1
1
1
1
1…
*
1
1
1
1
1
1
1
1
e. Modul purchase
29
Modul order
AR_RECEIPT
PK ARRcptCode
FK1 DebiturCode
AR_RCPT_DETAIL
PK ARRcptDetailCode
FK1 ARRcptCode
FK2 ARInvoiceCode
FK3 AccCode
AR_INVOICE
PK ARInvoiceCode
FK1 DebiturCode
FK2 CartCode
AR_INV_DETAIL
PK ARInvDetailCode
FK1 ARInvoiceCode
FK2 ItemCode
FK3 UOMCode
FK4 AccCode
AR_MONTHEND
PK monthEndCode
FK1 ModuleCode
FK2 AccCode
FK3 ItemCode
FK4 UOMCode
Modul
generalLedgerGL_ACCOUNT
PK AccCode
Modul admin
AD_MODULE
PK ModuleCode
AD_UOM
PK UOMCode
Modul inventory
IN_ITEM
PK ItemCode
ProdCatCode
ProdBrandCode
OR_CART
PK CartCode
paymentTypeCode
shippingTypeCode
DebiturCode
OR_DEBITUR
PK DebiturCode
1..*
1
1..*
1
1..*
1
1 1
11
1..*
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
f. Modul account receivable
30
AP_INVOICE
PK APInvoiceCode
FK1 DemandCode
FK2 SupplierCode
AP_INV_DETAIL
PK APInvDetailCode
FK1 APInvoiceCode
FK2 ItemCode
FK3 AccCode
FK4 UOMCode
FK5 monthEndCode
AP_MONTHEND
PK monthEndCode
FK1 AccCode
FK2 ItemCode
FK3 UOMCode
FK4 ModuleCode
AP_PAYMENT
PK APPaymentCode
FK1 SupplierCode
AP_PAYMENT_DETAIL
PK APPayDetailCode
FK1 APPaymentCode
FK2 APInvoiceCode
FK3 monthEndCode
FK4 AccCode
Modul purchase
PU_DEMAND
PK DemandCode
OrderCode
SupplierCode
PU_SUPPLIER
PK SupplierCode
AccCode
Modul admin
AD_MODULE
PK ModuleCode
AD_UOM
PK UOMCode
Modul inventory
IN_ITEM
PK ItemCode
ProdCatCode
ProdBrandCode
Modul
generalLedger
GL_ACCOUNT
PK AccCode
1
1..*
1
1
1
1
1
1
1
1
1
1
1..*1
1
1 1
1
1
1
1
1
1
1
1..*
11
1 1
1
1
1
g. Modul account payable
Lampiran 4 Kamus data
a. Modul admin
Nama tabel: AD_USER
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel user
2 user_name VARCHAR(255) yes, unique nama user
3 user_email VARCHAR(255) yes, unique alamat email
4 user_pswd VARCHAR(255) yes password user
5 employee_id VARCHAR(255) id staff/pegewai
6 create_date DATETIME tanggal tabel dibuat
7 update_date DATETIME tanggal tabel terakhir diupdate
31
Nama tabel : AD_COMPANY
Nama tabel : AD_GROUP
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel group
2 group_desc VARCHAR(255) yes deskripsi untuk setiap group
3 group_status VARCHAR(255) yes status tabel ("active", "inactive")
4 create_date DATETIME tanggal tabel dibuat
5 update_date DATETIME tanggal tabel terakhir diupdate
Nama tabel : AD_VEHICLE
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel vehicle
2 vehicle_desc VARCHAR(255) yes deskripsi dari kendaraan
3 vehicle_status VARCHAR(255) yes status tabel ("active", "inactive")
4 create_date DATETIME tanggal tabel dibuat
5 update_date DATETIME tanggal tabel terakhir diupdate
6 vehicle_type_code VARCHAR(255) tipe kendaraan
7 capacity INTEGER yes kapasitas muatan kendaraan
8 model VARCHAR(255) model kendaraan
9 id_ad_uom BIGINT(20) yes satuan unit yang dipakai
10 id_gl_acc BIGINT(20) yes kode akun untuk setiap kendaraan
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel company
2 company_name VARCHAR(255) yes nama perusahaan
3 address VARCHAR(255) yes alamat perusahaan
4 post_code VARCHAR(255) kode pos
5 state VARCHAR(255) provinsi
6 city VARCHAR(255) kota
7 telp_no VARCHAR(255) nomor telpon
8 fax_no VARCHAR(255) nomor faximile
9 company_status VARCHAR(255) yes status tabel ("active", "inactive")
10 create_date DATETIME tanggal tabel dibuat
11 update_date DATETIME tanggal tabel terakhir diupdate
32
Nama tabel : AD_MODUL
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel modul
2 modul_name VARCHAR(255) yes deskripsi untuk setiap modul
3 modul_status VARCHAR(255) yes status tabel ("active", inactive)
4 create_date DATETIME tanggal tabel dibuat
5 update_date DATETIME tanggal tabel terakhir diupdate
6 expire_date DATETIME tanggal batas update modul
Nama tabel : AD_UOM
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel UOM
2 uom_desc VARCHAR(255) yes deskripsi dari setiap UOM
3 uom_status VARCHAR(255) yes status tabel ("active", "inactive")
5 create_date DATETIME tanggal tabel terakhir diupdate
6 update_date DATETIME tanggal batas update modul
Nama tabel : AD_UOMCONVERTION
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel UOMCONVERTER
2 id_uom_from BIGINT(20) yes satuan awal
3 id_uom_to BIGINT(20) yes satuan hasil
4 rate INTEGER yes perhitungan konversi
5 status VARCHAR(255) yes status tabel
6 create_date DATETIME tanggal tabel terakhir diupdate
7 update_date DATETIME tanggal batas update modul
Nama Tabel : GROUP_MODULE
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id_ad_group BIGINT(20) yes FK dari tabel AD_GROUP
2 id_ad_modul BIGINT(20) yes FK dari tabel AD_MODULE
Nama tabel : AD_ACC_PERIODE
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel ad_acc_periode
2 max_periode BIGINT{20) yes max periode kode akun
3 status VARCHAR(255) yes status tabel
4 create_date DATETIME tanggal tabel terakhir diupdate
5 update_date DATETIME tanggal batas update modul
33
Nama tabel : AD_PAGE
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel ad_page
2 name VARCHAR(255) yes nama page
3 desc VARCHAR(255) yes deskripsi
4 url VARCHAR(255) yes alamat url nya
5 id_ad_modul BIGINT(20) yes FK dari ad_modul
6 status VARCHAR(255) yes status tabel ("active", "inactive")
7 create_date DATETIME tanggal tabel terakhir diupdate
8 update_date DATETIME tanggal batas update modul
Nama tabel : AD_MODULE_PERIODE
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk modul peroide (month end process)
2 in_acc_month INTEGER yes tutup buku inventory tiap bulan
3 in_acc_year INTEGER yes tutup buku inventory tiap tahun
4 pu_acc_month INTEGER yes tutup buku pembelian tiap bulan
5 pu_acc_year INTEGER yes tutup buku pembelian tiap tahun
6 or_acc_month INTEGER yes tutup buku penjualan tiap bulan
7 or_acc_year INTEGER yes tutup buku penjualan tiap tahun
8 ar_acc_month INTEGER yes tutup buku account receivable tiap bulan
9 ar_acc_year INTEGER yes tutup buku account receivable tiap tahun
10 ap_acc_month INTEGER yes tutup buku account payable tiap bulan
11 ap_acc_year INTEGER yes tutup buku account payable tiap tahun
12 gl_acc_month INTEGER yes tutup buku general ledger tiap bulan
13 gl_acc_year INTEGER yes tutup buku general ledger tiap tahun
b. Modul General Ledger
Nama tabel: GL_ACCOUNT
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id dari tabel GL_ACC
2 acc_desc VARCHAR(255) yes deskripsi dari kode akun
3 acc_status VARCHAR(255) yes status ("active", "inactive")
4 create_date DATETIME tanggal tabel dibuat
5 update_date DATETIME tanggal tabel terakhir diupdate
Nama tabel : GL_JOURNAL
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel GL_JOURNAL
2 journal_code VARCHAR(255) yes code tiap jurnal
34
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
3 journal_desc VARCHAR(255) yes deskripsi dari setiap kode jurnal
4 doc_ref_no VARCHAR(255) no dokumen referensi
5 doc_ref_date DATETIME tanggal dokumen referensi
6 doc_amount DOUBLE total amount yang ada pada dokumen
7 total DOUBLE yes total amount yang dimasukan ke journal
8 acc_month INTEGER yes tutup buku jurnal setiap bulan
9 acc_year INTEGER yes tutup buku jurnal setiap tahun
10 status VARCHAR(255) status tabel ("active", "inactive")
11 create_date DATETIME tanggal tabel terakhir diupdate
12 update_date DATETIME tanggal batas update modul
Nama tabel : GL_JOURNAL_DETAIL
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk jornal detail
2 id_journal BIGINT(20) yes FK dari tabel GL_journal
3 amount DOUBLE yes total amount
4 id_gl_account BIGINT(20) yes FK dari tabel GL_acoount
5 line_desc VARCHAR(255)
6 status VARCHAR(255) yes status tabel ("active", "inactive")
7 create_date DATETIME tanggal tabel terakhir diupdate
8 update_date DATETIME tanggal batas update modul
Nama tabel : GL_JOURNAL_MONTHEND
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel GL_month_end
2 id_doc VARCHAR(255) yes id setiap dokumen yang masuk
3 doc_type VARCHAR(255) tipe dari setiap dokumen
4 doc_date DATETIME yes tanggal dokumen
5 acc_month INTEGER yes tutup buku proses month end setiap bulan
6 acc_year INTEGER yes tutup buku proses month end setiap year
7 month_end_desc VARCHAR(255) deskripsi dari monthend
8 quantity INTEGER yes banyaknya barang yang direkap
9 price DOUBLE yes harga tiap item
10 amount DOUBLE yes total amount
11 id_ad_modul BIGINT(20) yes FK dari tabel ad_modul
12 id_gl_acc BIGINT(20) yes FK dari tabel gl_acc untuk kode akun
13 id_in_item BIGINT(20) yes FK darI tabel in_item untuk item
14 id_ad_uom BIGINT(20) yes FK dari tabel ad_uom untuk satuan tiap unit
15 create_date DATETIME tanggal tabel terakhir diupdate
16 update_date DATETIME tanggal batas update modul
35
c. Modul Purhcase
Nama tabel : PU_SUPPLIER
Nama tabel : PU_REQUISITION
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id tabel pu_requisition
2 PR_code VARCHAR(255) yes kode setiap transaksi RFQ
3 transaction_code DATETIME yes tanggal transaksi RFQ
4 status VARCHAR(255) yes status transaksi ("draft", "sent")
5 create_date DATETIME tanggal tabel terakhir diupdate
6 update_date DATETIME tanggal batas update modul
7 acc_year INTEGER tutup buku transaksi PR setiap bulan
8 acc_month INTEGER tutup buku transaksi PR setiap year
Nama tabel : PU_REQUISITION_DETAIL
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id tabel pu_requisition detail
2 id_in_item BIGINT(20) yes item yang masukan
3 quantity INTEGER yes banyaknya item
4 id_ad_uom BIGINT(20) yes satuan unit
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 Id BIGINT(20) yes id untuk tabel PU_SUPPLIER
2 sup_name VARCHAR(255) yes nama supplier
3 cont_person VARCHAR(255) yes kontak yang bisa dihubungi
4 address_street VARCHAR(255) jalan
5 address_town VARCHAR(255) kota
6 address_state VARCHAR(255) provinsi
7 address_post_code VARCHAR(255) kode pos
8 telp_no VARCHAR(255) nomor telpon
9 fax_no VARCHAR(255) nomor faximile
10 mobile_no VARCHAR(255) nomor handphone
11 email VARCHAR(255) yes alamat email
12 credit_term VARCHAR(255)
setalah barang diterima atau setelah tagihan
diterima
13 credit_limit DOUBLE batas maksimal kredit
14 bank_acc_name VARCHAR(255) yes nama bank
15 bank_acc_no VARCHAR(255) yes no rekening bank
16 sup_status VARCHAR(255) yes status ("active", "inactive")
17 create_date DATETIME tanggal tabel dibuat
18 update_date DATETIME tanggal tabel terakhir diupdate
19 id_ad_user BIGINT(20) yes fk dari tabel user
20 id_gl_account BIGINT(20) yes fk dari tabel general ledger
36
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
5 id_pu_requisition BIGINT(20) yes FK dari tabel pu_requisition
6 status VARCHAR(255) yes status tabel
7 create_date DATETIME tanggal tabel terakhir diupdate
8 update_date DATETIME tanggal batas update modul
Nama tabel : PU_RFQ
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id tabel pu_requisition
2 RFQ_code VARCHAR(255) yes kode setiap transaksi PR
3 transaction_code DATETIME yes tanggal transaksi PR
4 amount DOUBLE yes total transaksi
5 id_pu_supplier BIGINT(20) yes daftar supplier yang dikirim RFQ
6 delivery_date DATETIME yes tanggal pengiriman barang
7 id_pu_requisition BIGINT(20) yes FK dari tabel pu_requisition
8 status VARCHAR(255) yes status transaksi ("draft", "sent")
9 create_date DATETIME tanggal tabel terakhir diupdate
10 update_date DATETIME tanggal batas update modul
11 acc_year INTEGER tutup buku transaksi RFQ setiap bulan
12 acc_month INTEGER tutup buku transaksi RFQ setiap tahun
Nama tabel : PU_RFQ_DETAIL
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id tabel pu_rfq_detail
2 id_in_item BIGINT(20) yes item yang masukan
3 quantity INTEGER yes banyaknya item
4 price DOUBLE yes harga per item
5 id_ad_uom BIGINT(20) yes satuan unit
6 id_pu_rfq BIGINT(20) yes FK dari tabel pu_rfq
7 status VARCHAR(255) yes status tabel
8 create_date DATETIME tanggal tabel terakhir diupdate
9 update_date DATETIME tanggal batas update modul
Nama tabel : PU_SUPPLIER_SENT_RFQ
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 rfq_id BIGINT(20) yes FK dari tabel pu_rfq
2 supplier_id BIGINT(20) yes FK dari tabel pu_supplier
37
Nama tabel : PU_SUPPLIER_SEND_PRICE
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 rfq_id BIGINT(20) yes FK dari tabel pu_rfq
2 supplier_id BIGINT(20) yes FK dari tabel pu_supplier
Nama tabel : PU_RFQ_PRICE
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel pu_rfq_price
2 price DOUBLE yes harga penawaran dari tiap-tiap supplier
3 delivery_date DATETIME tanggal pengiriman barang
4 id_pu_supplier BIGINT(20) yes FK dari tabel pu_supplier
Nama tabel : PU_ORDER
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel pu_rfq_price
2 price DOUBLE yes harga penawaran dari tiap-tiap supplier
3 delivery_date DATETIME tanggal pengiriman barang
4 id_pu_supplier BIGINT(20) yes FK dari tabel pu_supplier
Nama tabel : PU_ORDER_DETAIL
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id tabel pu_order_detail
2 id_in_item BIGINT(20) yes item yang masukan
3 quantity INTEGER yes banyaknya item
4 price DOUBLE yes harga per item
5 id_ad_uom BIGINT(20) yes satuan unit
6 id_pu_PO BIGINT(20) yes FK dari tabel pu_order
7 status VARCHAR(255) yes status tabel
8 create_date DATETIME tanggal tabel terakhir diupdate
9 update_date DATETIME tanggal batas update modul
Nama tabel : PU_DEMAND
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id tabel pu_requisition
2 DO_code VARCHAR(255) yes kode setiap transaksi DO
3 transaction_code DATETIME yes tanggal transaksi DO
4 amount DOUBLE yes total transaksi
5 id_pu_supplier BIGINT(20) yes FK dari tabel pu_supplier
6 delivery_address VARCHAR(255) yes alamat pengiriman barang
7 delivery_date DATETIME yes tanggal pengiriman barang
8 id_pu_order BIGINT(20) yes FK dari tabel pu_order
38
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
9 status VARCHAR(255) yes status transaksi ("draft", "sent")
10 create_date DATETIME tanggal tabel terakhir diupdate
11 update_date DATETIME tanggal batas update modul
12 acc_year INTEGER tutup buku transaksi DO setiap bulan
13 acc_month INTEGER tutup buku transaksi DO setiap year
Nama tabel : PU_DEMAND_DETAIL
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id tabel pu_demand_detail
2 id_in_item BIGINT(20) yes item yang masukan
3 quantity INTEGER yes banyaknya item
4 price DOUBLE yes harga per item
5 id_ad_uom BIGINT(20) yes satuan unit
6 id_pu_DO BIGINT(20) yes FK dari tabel pu_demand
7 status VARCHAR(255) yes status tabel
8 create_date DATETIME tanggal tabel terakhir diupdate
9 update_date DATETIME tanggal batas update modul
Nama tabel : PU_MONTHEND_TRX
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel PU_month_end
2 id_doc VARCHAR(255) yes id setiap dokumen yang masuk
3 doc_type VARCHAR(255) tipe dari setiap dokumen
4 doc_date DATETIME yes tanggal dokumen
5 acc_month INTEGER yes tutup buku proses monthend setiap bulan
6 acc_year INTEGER yes tutup buku proses monthend setiap tahun
7 month_end_desc VARCHAR(255) deskripsi dari monthend
8 quantity INTEGER yes banyaknya barang yang direkap
9 price DOUBLE yes harga tiap item
10 amount DOUBLE yes total amount
11 id_ad_modul BIGINT(20) yes FK dari tabel ad_modul
12 id_gl_acc BIGINT(20) yes FK dari tabel gl_acc untuk kode akun
13 id_in_item BIGINT(20) yes FK darI tabel in_item untuk item
14 id_ad_uom BIGINT(20) yes FK dari tabel ad_uom satuan tiap unit
15 create_date DATETIME tanggal tabel terakhir diupdate
16 update_date DATETIME tanggal batas update modul
39
d. Modul Inventory
Nama tabel : IN_ITEM
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) YES
id inventory yang terdaftar pada tabel
in_item
2 item_desc VARCHAR(255) yes
deskripsi dari item yang terdaftar
pada tabel in_item
3 bin VARCHAR(255) lokasi penempatan di gudang
4 qty_on_hand INTEGER Yes
jumlah stok barang yang ada di
gudang dan tidak sedang dipesan
5 qty_on_order INTEGER
jumlah stok barang yang sudah
terjual
6 qty_on_hold INTEGER jumlah barang yang sudah dipesan
7 qty_re_order INTEGER Yes
jumlah barang yang harus dipesan
jika mencapai batas minimal
8 init_cost DOUBLE Yes
harga awal pembelian pertama (dari
PO id= 1)
9 high_cost DOUBLE harga pembelian tertinggi
10 low_cost DOUBLE harga pembelian terendah
11 average_cost DOUBLE harga pembelian rata-rata
12 diff_avrg_cost DOUBLE selisih harga pembelian rata-rata
13 closing_bal DOUBLE harga tutup buku pada akhir bulan
14 closing_avrg_cost DOUBLE
harga rata-rata saat tutup buku pada
akhir bulan
15 closing_diff_avrg_cost DOUBLE
selisih harga rata-rata saat tutup buku
pada akhir bulan
16 sell_fix_price DOUBLE harga penjualan fix
17 sell_latest_cost DOUBLE persentasi dari harga jual terakhir
18 sell_avrg_cost DOUBLE persentasi dari harga jual rata-rata
19 last_order_date DATETIME tanggal penjualan terakhir
20 last_issue_date DATETIME tanggal pembelian terakhir
21 create_date DATETIME tanggal tabel dibuat
22 update_date DATETIME tanggal terakhir melakukan update
23 latest_cost_final DOUBLE harga pembelian terakhir
24 latest_cost_second DOUBLE harga pembeliah 2 kali sebelumnya
25 latest_cost_init DOUBLE harga pembelian 1 kali sebelumnya
26 attach LONGBLOB foto
27 id_ad_warehouse BIGINT(20) Yes fk dari tabel warehouse
28 id_in_prod_brand BIGINT(20) Yes fk dari tabel prod_brand
29 id_in_prod_cat BIGINT(20) Yes fk dari tabel prod_cat
30 id_gl_acc BIGINT(20) Yes fk dari tabel general_ledger
31 id_ad_user BIGINT(20) Yes fk dari user
32 id_ad_uom BIGINT(20) Yes
fk tabel uom, satuan untuk harga beli
yang masuk ke gudang
33 in_status VARCHAR(255) Yes status tabel ("active", "inactive")
40
Nama tabel : IN_PROD_BRAND
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT yes
(PK) id untuk tabel
IN_PROD_BRAND
2 brand_desc VARCHAR(255) yes deskripsi dari brand produk
3 brand_status VARCHAR(255) yes status brand produk
4 create_date DATETIME tanggal tabel dibuat
5 update_date DATETIME tanggal tabel terakhir diupdate
Nama tabel : IN_PROD_CAT
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT yes id untuk tabel IN_PROD_CAT
2 prod_cat_desc VARCHAR(255) yes deskripsi dari kategori produk
3 prod_cat_status VARCHAR(255) yes status kategori produk
4 create_date DATETIME tanggal tabel dibuat
5 update_date DATETIME tanggal tabel terakhir diupdate
Nama tabel : IN_GOODS_RECEIVE
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id tabel pu_requisition
2 gooods_receive_code VARCHAR(255) yes kode setiap transaksi goods receive
3 transaction_code DATETIME yes tanggal transaksi goods receive
5 id_pu_supplier BIGINT(20) yes FK dari tabel pu_supplier
6 delivery_address VARCHAR(255) yes alamat pengiriman barang
7 delivery_date DATETIME yes tanggal pengiriman barang
8 id_pu_Rfq BIGINT(20) yes FK dari tabel pu_rfq
9 status VARCHAR(255) yes status transaksi ("draft", "sent")
10 create_date DATETIME tanggal tabel terakhir diupdate
11 update_date DATETIME tanggal batas update modul
12 acc_year INTEGER tutup buku transaksi DO setiap bulan
13 acc_month INTEGER tutup buku transaksi DO setiap tahun
Nama tabel : IN_GOODS_RECEIVE_DETAIL
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id tabel pu_goods_receive_detail
2 id_in_item BIGINT(20) yes item yang masukan
3 quantity INTEGER yes banyaknya item
4 id_ad_uom BIGINT(20) yes satuan unit
5 id_in_goods_receive BIGINT(20) yes FK dari tabel pu_demand
6 status VARCHAR(255) yes status tabel
7 create_date DATETIME tanggal tabel terakhir diupdate
8 update_date DATETIME tanggal batas update modul
41
Nama tabel : IN_MONTHEND_ITEM
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id_in_item BIGINT(20) yes id untuk tabel in_monthend_item
2 acc_month INTEGER yes tutup buku inventory item setiap bulan
3 acc_year INTEGER yes tutup buku inventory item setiap tahun
4 quantity INTEGER yes banyak nya barang / item
5 avrg_cost DOUBLE yes harga rata-rata per item
6 amount DOUBLE yes total amount
7 status VARCHAR(255) yes status tabel
8 create_date DATETIME tanggal tabel terakhir diupdate
9 update_date DATETIME tanggal batas update modul
e. Modul Order
Nama tabel : OR_SHIPPING_TYPE
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT Yes autoincrement
2 description VARCHAR Yes jenis pengirimannya
3 create_date DATETIME tanggal tabel terakhir diupdate
4 update_date DATETIME tanggal batas update modul
Nama tabel : OR_PAYMENT_TYPE
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT Yes autoincrement
2 description VARCHAR yes jenis pembayaran
3 create_date DATETIME tanggal tabel terakhir diupdate
4 update_date DATETIME tanggal batas update modul
Nama tabel : OR_CART
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) Yes id untuk tabel or_cart
2 cart_code VARCHAR(255) yes kode penjualan
3 Shipping_type_id VARCHAR(255) yes Tipe pengiriman barang
4 id_or_debitur BIGINT(20) yes identitas yang pembeli
5 payment_type_id BIGINT(20) yes Tipe pembayaran
6 status VARCHAR(255) yes status transaksi cart("sent","draft","cancel")
7 reference_id VARCHAR(255) yes reference id untuk konfirmasi pembayaran
8 create_date DATETIME tanggal tabel terakhir diupdate
9 update_date DATETIME tanggal batas update modul
10 amount DOUBLE yes total amount transaksi
42
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
11 id_ad_user BIGINT(20) yes fk dari tabel user
12 acc_month INTEGER yes tutup buku transaksi penjualan setiap bulan
13 acc_year INTEGER yes tutup buku transaksi penjualan setiap tahun
Nama tabel : OR_CART_DETAIL
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id yes id untuk tabel or_cart_detail
3 Id_ tem VARCHAR(255) yes Item yang dibeli apa
4 Price DOUBLE yes Harga barang peritem
5 uom_id BIGINT(20) yes unit satuan per item
6 Quantity INTEGER yes Jumlah barang yang dibeli
4 id_gl_account BIGINT(20) yes FK dari tabel GL_acoount
8 create_date DATETIME tanggal tabel terakhir diupdate
9 update_date DATETIME tanggal batas update modul
Nama tabel : OR_DELIVERY
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 ID BIGINT(20) yes id untuk tabel or_delivery
2 delivery_date DATETIME yes tangggal pengiriman barang
3 reference_id VARCHAR(255) yes reference_id pembelian barang
4 id_ad_vehicle BIGINT(20) yes jenis angkutan yang digunakan
5 id_ad_uom BIGINT(20) yes satuan untuk muatan
6 load INTEGER yes muatan dari kendaraan pengangkut
7 id_or_debitur BIGINT(20) yes FK dari tabel or_debitur
8 driver VARCHAR(255) yes nama supir
9 create_date DATETIME tanggal tabel terakhir diupdate
10 update_date DATETIME tanggal batas update modul
Nama tabel : OR_MONTHEND_TRX
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel PU_month_end
2 id_doc VARCHAR(255) yes id setiap dokumen yang masuk
3 doc_type VARCHAR(255) tipe dari setiap dokumen
4 doc_date DATETIME yes tanggal dokumen
5 acc_month INTEGER yes tutup buku proses month end setiap bulan
6 acc_year INTEGER yes tutup buku proses month end setiap tahun
7 monthend_desc VARCHAR(255) deskripsi dari monthend
8 quantity INTEGER yes banyaknya barang yang direkap
9 price DOUBLE yes harga tiap item
10 amount DOUBLE yes total amount
11 id_ad_modul BIGINT(20) yes FK dari tabel ad_modul
43
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
12 id_gl_acc BIGINT(20) yes FK dari tabel gl_acc untuk kode akun
13 id_in_item BIGINT(20) yes FK darI tabel in_item untuk item
14 id_ad_uom BIGINT(20) yes FK dari tabel ad_uom untuk satuan tiap unit
15 status VARCHAR(255) yes status transaksi
16 create_date DATETIME tanggal tabel terakhir diupdate
17 update_date DATETIME tanggal batas update modul
f. Modul Account Payable
Nama tabel : AP_INVOICE
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel ap_invoice
2 invoice_code VARCHAR(255) yes kode transaksi invoice
3 inv_ref_code VARCHAR(255) yes kode referensi
4 inv_ref_date VARCHAR(255) yes tanggal referensi
5 amount DOUBLE yes total amount tagihan
6 id_pu_demand BIGINT(20) yes FK dari tabel pu_demand
7 id_pu_supplier BIGINT(20) yes FK dari tabel pu_supplier
8 acc_month INTEGER tutup buku proses month end setiap bulan
9 acc_year INTEGER tutup buku proses month end setiap tahun
10 status VARCHAR(255) yes status transaksi ("sent","draft","cancel")
11 create_date DATETIME tanggal tabel terakhir diupdate
12 update_date DATETIME tanggal batas update modul
Nama tabel : AP_INVOICE_DETAIL
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel ap_invoice_detail
2 id_ap_invoice BIGINT(20) yes Fk dari tabel ap_invoice
3 id_in_item BIGINT(20) yes FK dari tabel in_item
4 id_gl_acc BIGINT(20) yes FK dari tabel gl_acc
5 quantity INTEGER yes banyaknya barang
6 id_ad_uom DOUBLE yes FK dari tabel ad_uom
7 price DOUBLE yes harga satuan per item
8 status VARCHAR(255) yes status tabel ("active","inactive")
9 create_date DATETIME tanggal tabel terakhir diupdate
10 update_date DATETIME tanggal batas update modul
Nama tabel : AP_MONTHEND
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel AP_month_end
2 id_doc VARCHAR(255) yes id setiap dokumen yang masuk
44
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
3 doc_type VARCHAR(255) tipe dari setiap dokumen
4 doc_date DATETIME yes tanggal dokumen
5 acc_month INTEGER yes tutup buku proses month end setiap bulan
6 acc_year INTEGER yes tutup buku proses month end setiap tahun
7 month_end_desc VARCHAR(255) deskripsi dari monthend
8 quantity INTEGER yes banyaknya barang yang direkap
9 price DOUBLE yes harga tiap item
10 amount DOUBLE yes total amount
11 id_ad_modul BIGINT(20) yes FK dari tabel ad_modul
12 id_gl_acc BIGINT(20) yes FK dari tabel gl_acc untuk kode akun
13 id_in_item BIGINT(20) yes FK darI tabel in_item untuk item
14 id_ad_uom BIGINT(20) yes FK dari tabel ad_uom satuan tiap unit
15 status VARCHAR(255) yes status transaksi
16 create_date DATETIME tanggal tabel terakhir diupdate
17 update_date DATETIME tanggal batas update modul
Nama tabel : AP_PAYMENT
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) Yes id untuk tabel ap_payment
2 payment_code VARCHAR(255) yes kode transaksi payment
3 inv_ref_code VARCHAR(255) yes kode referensi
4 inv_ref_date VARCHAR(255) yes tanggal referensi
5 amount DOUBLE yes total amount pembayaran
6 id_pu_supplier BIGINT(20) yes FK dari tabel pu_supplier
7 acc_month INTEGER tutup buku proses month end setiap bulan
8 acc_year INTEGER tutup buku proses month end setiap tahun
9 status VARCHAR(255) yes status transaksi ("sent","draft","cancel")
10 create_date DATETIME tanggal tabel terakhir diupdate
11 update_date DATETIME tanggal batas update modul
Nama tabel : AP_PAYMENT_DETAIL
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel ap_invoice_detail
2 id_ap_payment BIGINT(20) yes Fk dari tabel ap_payment
3 id_in_item BIGINT(20) yes FK dari tabel in_item
4 id_gl_acc BIGINT(20) yes FK dari tabel gl_acc
5 id_ap_invoice BIGINT(20) yes Fk dari tabel ap_invoice
6 id_month_end BIGINT(20) yes FK dari tabel month_end
7 status VARCHAR(255) yes status tabel ("active","inactive")
8 create_date DATETIME tanggal tabel terakhir diupdate
9 update_date DATETIME tanggal batas update modul
45
g. Modul Account Receivable
Nama tabel : AR_INVOICE
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel ap_invoice
2 invoice_code VARCHAR(255) Yes kode transaksi invoice
3 amount DOUBLE yes total amount tagihan
4 id_or_debitur BIGINT(20) yes FK dari tabel or_debitur
5 id_or_cart BIGINT(20) FK dari tabel or_cart
6 acc_month INTEGER tutup buku proses month end setiap bulan
7 acc_year INTEGER tutup buku proses month end setiap tahun
8 status VARCHAR(255) yes status transaksi ("sent","draft","cancel")
9 create_date DATETIME tanggal tabel terakhir diupdate
10 update_date DATETIME tanggal batas update modul
Nama tabel : AR_INVOICE_DETAIL
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel ar_invoice_detail
2 id_ar_invoice BIGINT(20) yes Fk dari tabel ar_invoice
3 id_in_item BIGINT(20) yes FK dari tabel in_item
4 id_gl_acc BIGINT(20) yes FK dari tabel gl_acc
5 quantity INTEGER yes banyaknya barang
6 id_ad_uom DOUBLE yes FK dari tabel ad_uom
7 price DOUBLE yes harga satuan per item
8 status VARCHAR(255) yes status tabel ("active","inactive")
9 create_date DATETIME tanggal tabel terakhir diupdate
10 update_date DATETIME tanggal batas update modul
Nama tabel : AR_MONTHEND
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel Ar_month_end
2 id_doc VARCHAR(255) yes id setiap dokumen yang masuk
3 doc_type VARCHAR(255) tipe dari setiap dokumen
4 doc_date DATETIME yes tanggal dokumen
5 acc_month INTEGER yes tutup buku proses monthend setiap bulan
6 acc_year INTEGER yes tutup buku proses monthend setiap tahun
7 month_end_desc VARCHAR(255) deskripsi dari monthend
8 quantity INTEGER yes banyaknya barang yang direkap
9 price DOUBLE yes harga tiap item
10 amount DOUBLE yes total amount
11 id_ad_modul BIGINT(20) yes FK dari tabel ad_modul
12 id_gl_acc BIGINT(20) yes FK dari tabel gl_acc untuk kode akun
46
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
13 id_in_item BIGINT(20) yes FK darI tabel in_item untuk item
14 id_ad_uom BIGINT(20) yes FK dari tabel ad_uom satuan tiap unit
15 status VARCHAR(255) yes status transaksi
16 create_date DATETIME tanggal tabel terakhir diupdate
17 update_date DATETIME tanggal batas update modul
Nama tabel : AR_RECEIPT
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) Yes id untuk tabel ap_payment
2 payment_code VARCHAR(255) yes kode transaksi payment
3 id_or_debitur BIGINT(20) yes FK dari tabel or_debitur
4 amount DOUBLE yes total amount pembayaran
5 acc_month INTEGER tutup buku proses month end setiap bulan
6 acc_year INTEGER tutup buku proses month end setiap tahun
7 status VARCHAR(255) yes status transaksi ("sent","draft","cancel")
8 create_date DATETIME tanggal tabel terakhir diupdate
9 update_date DATETIME tanggal batas update modul
Nama tabel : AR_RECEIPT_DETAIL
NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION
1 id BIGINT(20) yes id untuk tabel ar_invoice_detail
2 id_ar_receipt BIGINT(20) yes Fk dari tabel ar_receipt
3 id_in_item BIGINT(20) yes FK dari tabel in_item
4 id_gl_acc BIGINT(20) yes FK dari tabel gl_acc
5 id_ar_invoice BIGINT(20) yes Fk dari tabel ar_invoice
6 status VARCHAR(255) yes status tabel ("active","inactive")
7 create_date DATETIME tanggal tabel terakhir diupdate
8 update_date DATETIME tanggal batas update modul
Lampiran 5 Teknik Inversion of Controls pada pembuatan objek dataSource dan
sessionFactory dan dimasukan ke semua DAO untuk melakukan akses data
a. membuat dataSource dari properi basis data
<bean
id="dataSource"
class="org.springframework.jdbc.datasource.
DriverManagerDataSource">
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
<property name="url" value="${jdbc.url}"/>
<property name="driverClassName" value="${jdbc.driver}"/>
</bean>
47
b. membuat sessionFactory dari dataSource dan DTO
<bean
id="sessionFactory"
class="org.springframework.orm.hibernate3.annotation.
AnnotationSessionFactoryBean">
<property name="dataSource" ref="dataSource"/>
<property name="annotatedClasses">
<list>
<!-- inventory -->
<value>ilkom.erp.inventory.InventoryItem</value>
<value>ilkom.erp.inventory.InventoryProductBrand</value>
<value>ilkom.erp.inventory.InventoryProductCategory</value>
<value>ilkom.erp.inventory.InventoryGoodReceive</value>
<value>ilkom.erp.inventory.InventoryGoodReceiveDetail</value>
<value>ilkom.erp.inventory.InventoryMonthenditem</value>
<!-- purchase -->
<value>ilkom.erp.purchase.PurchaseSupplier</value>
<value>ilkom.erp.purchase.PurchaseRequisition</value>
<value>ilkom.erp.purchase.PurchaseRequisitionDetail</value>
<value>ilkom.erp.purchase.PurchaseSupplyRFQ</value>
<value>ilkom.erp.purchase.PurchaseSupplyRFQDetail</value>
<value>ilkom.erp.purchase.PurchaseRFQPrice</value>
<value>ilkom.erp.purchase.PurchaseDemand</value>
<value>ilkom.erp.purchase.PurchaseDemandDetail</value>
<value>ilkom.erp.purchase.PurchaseOrder</value>
<value>ilkom.erp.purchase.PurchaseOrderDetail</value>
<value>ilkom.erp.purchase.PurchaseMonthendtrx</value>
<!--generalledger-->
<value>ilkom.erp.generalLedger.GeneralLedgerAccount</value>
<value>ilkom.erp.generalLedger.GLJournal</value>
<value>ilkom.erp.generalLedger.GLJournalDetail</value>
<value>ilkom.erp.generalLedger.GLMonthEnd</value>
<!-- order -->
<value>ilkom.erp.order.OrderDebitur</value>
<value>ilkom.erp.order.OrderCart</value>
<value>ilkom.erp.order.OrderCartDetail</value>
<value>ilkom.erp.order.OrderShippingType</value>
<value>ilkom.erp.order.OrderPaymentType</value>
<value>ilkom.erp.order.OrderDelivery</value>
<value>ilkom.erp.order.OrderMonthendtrx</value>
<!-- admin -->
<value>ilkom.erp.admin.AdminAccPeriod</value>
<value>ilkom.erp.admin.AdminCompany</value>
<value>ilkom.erp.admin.AdminGroup</value>
<value>ilkom.erp.admin.AdminModul</value>
<value>ilkom.erp.admin.AdminUOM</value>
<value>ilkom.erp.admin.AdminUOMConvertion</value>
<value>ilkom.erp.admin.AdminUser</value>
<value>ilkom.erp.admin.AdminVehicle</value>
<value>ilkom.erp.admin.AdminPage</value>
<value>ilkom.erp.admin.AdminModulPeriod</value>
<!--accountReceivable-->
<value>ilkom.erp.accountReceivable.AccountReceivableInvoice</value>
<value>ilkom.erp.accountReceivable.AccountReceivableInvoiceDetail</value>
<value>ilkom.erp.accountReceivable.AccountReceivableReceipt</value>
<value>ilkom.erp.accountReceivable.AccountReceivableReceiptDetail</value>
<value>ilkom.erp.accountReceivable.AccountReceivableMonthEnd</value>
<!—accountPayable-->
<value>ilkom.erp.accountPayable.AccountPayableInvoice</value>
<value>ilkom.erp.accountPayable.AccountPayableInvoiceDetail</value>
<value>ilkom.erp.accountPayable.AccountPayablePayment</value>
<value>ilkom.erp.accountPayable.AccountPayablePaymentDetail</value>
<value>ilkom.erp.accountPayable.AccountPayableMonthEnd</value>
</list>
</property>
48
c. memasukan objek sessionFactory ke semua DAO
<!—inventoryDao-->
<bean
id="inventoryItemDao" class="ilkom.erp.inventory.dao.hibernate.
InventoryItemDaoHibernate">
property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="inventoryProductBrandDao" class="ilkom.erp.inventory.dao.hibernate.
InventoryProductBrandDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="inventoryProductCategoryDao" class="ilkom.erp.inventory.dao.hibernate.
InventoryProductCategoryDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="inventoryGoodReceiveDao" class="ilkom.erp.inventory.dao.hibernate.
InventoryGoodReceiveDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="inventoryGoodReceiveDetailDao" class="ilkom.erp.inventory.dao.hibernate.
InventoryGoodReceiveDetailDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="inventoryMonthenditemDao" class="ilkom.erp.inventory.dao.hibernate.
InventoryMonthenditemDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<!-- purchase dao -->
<bean
id="purchaseSupplierDao" class="ilkom.erp.purchase.dao.hibernate.
PurchaseSupplierDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="purchaseRequisitionDao" class="ilkom.erp.purchase.dao.hibernate.
PurchaseRequisitionDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="purchaseRequisitionDetailDao" class="ilkom.erp.purchase.dao.hibernate.
PurchaseRequisitionDetailDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="purchaseSupplyRFQDao" class="ilkom.erp.purchase.dao.hibernate.
PurchaseSupplyRFQDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="purchaseSupplyRFQDetailDao" class="ilkom.erp.purchase.dao.hibernate.
PurchaseSupplyRFQDetailDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="purchaseDemandDao" class="ilkom.erp.purchase.dao.hibernate.
PurchaseDemandDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="purchaseDemandDetailDao" class="ilkom.erp.purchase.dao.hibernate.
PurchaseDemandDetailDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="purchaseOrderDao" class="ilkom.erp.purchase.dao.hibernate.
PurchaseOrderDaoHibernate">
49
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="purchaseOrderDetailDao" class="ilkom.erp.purchase.dao.hibernate.
PurchaseOrderDetailDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="purchaseMonthendtrxDao" class="ilkom.erp.purchase.dao.hibernate.
PurchaseMonthendtrxDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<!-- general ledger dao -->
<bean
id="generalLedgerDao" class="ilkom.erp.generalLedger.dao.hibernate.
GeneralLedgerDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="gLJournalDao" class="ilkom.erp.generalLedger.dao.hibernate.
GLJournalDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="gLJournalDetailDao" class="ilkom.erp.generalLedger.dao.hibernate.
GLJournalDetailDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="gLMonthEndDao" class="ilkom.erp.generalLedger.dao.hibernate.
GLMonthEndDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<!-- order -->
<bean
id="orderDebiturDao" class="ilkom.erp.order.dao.hibernate.
OrderDebiturDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="orderCartDao" class="ilkom.erp.order.dao.hibernate.
OrderCartDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="orderCartDetailDao" class="ilkom.erp.order.dao.hibernate.
OrderCartDetailDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="orderShippingTypeDao" class="ilkom.erp.order.dao.hibernate.
OrderShippingTypeDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="orderPaymentTypeDao" class="ilkom.erp.order.dao.hibernate.
OrderPaymentTypeDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="orderDeliveryDao" class="ilkom.erp.order.dao.hibernate.
OrderDeliveryDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="orderMonthendtrxDao" class="ilkom.erp.order.dao.hibernate.
OrderMonthendtrxDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<!-- admin -->
<bean
id="adminAccPeriodDao" class="ilkom.erp.admin.dao.hibernate.
AdminAccPeriodDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
50
<bean
id="adminCompanyDao" class="ilkom.erp.admin.dao.hibernate.
AdminCompanyDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="adminGroupDao" class="ilkom.erp.admin.dao.hibernate.
AdminGroupDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="adminModulDao" class="ilkom.erp.admin.dao.hibernate.
AdminModulDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="adminUOMConvertionDao" class="ilkom.erp.admin.dao.hibernate.
AdminUOMConvertionDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="adminUOMDao" class="ilkom.erp.admin.dao.hibernate.
AdminUOMDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="adminUserDao" class="ilkom.erp.admin.dao.hibernate.
AdminUserDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="adminVehicleDao" class="ilkom.erp.admin.dao.hibernate.
AdminVehicleDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="adminPageDao" class="ilkom.erp.admin.dao.hibernate.
AdminPageDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="adminModulPeriodDao" class="ilkom.erp.admin.dao.hibernate.
AdminModulPeriodDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<!-- accountReceivable -->
<bean
id="accountReceivableInvoiceDao" class="ilkom.erp.accountReceivable.dao.hibernate.
AccountReceivableInvoiceDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="accountReceivableInvoiceDetailDao"
class="ilkom.erp.accountReceivable.dao.hibernate.
AccountReceivableInvoiceDetailDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="accountReceivableReceiptDao" class="ilkom.erp.accountReceivable.dao.hibernate.
AccountReceivableReceiptDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="accountReceivableReceiptDetailDao"
class="ilkom.erp.accountReceivable.dao.hibernate.
AccountReceivableReceiptDetailDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="accountReceivableMonthEndDao"
class="ilkom.erp.accountReceivable.dao.hibernate.
AccountReceivableMonthEndDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
51
<!--accountPayable -->
<bean
id="accountPayableInvoiceDao" class="ilkom.erp.accountPayable.dao.hibernate.
AccountPayableInvoiceDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="accountPayableInvoiceDetailDao" class="ilkom.erp.accountPayable.dao.hibernate.
AccountPayableInvoiceDetailDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="accountPayablePaymentDao" class="ilkom.erp.accountPayable.dao.hibernate.
AccountPayablePaymentDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="accountPayablePaymentDetailDao" class="ilkom.erp.accountPayable.dao.hibernate.
AccountPayablePaymentDetailDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
<bean
id="accountPayableMonthEndDao" class="ilkom.erp.accountPayable.dao.hibernate.
AccountPayableMonthEndDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/></bean>
d. memasukan semua DAO ke dalam masing-masng Service sesuai dengan submodulnya
<bean
id="inventoryService" class="ilkom.erp.service.impl.InventoryServiceImpl">
<property
name="inventoryItemDao"
ref="inventoryItemDao"/>
<property
name="inventoryProductBrandDao"
ref="inventoryProductBrandDao"/>
<property
name="inventoryProductCategoryDao"
ref="inventoryProductCategoryDao"/>
<property
name="inventoryGoodReceiveDao"
ref="inventoryGoodReceiveDao"/>
<property
name="inventoryGoodReceiveDetailDao" ref="inventoryGoodReceiveDetailDao"/>
<property
name="inventoryMonthenditemDao"
ref="inventoryMonthenditemDao"/>
</bean>
<!-- purchase -->
<bean
id="purchaseService" class="ilkom.erp.service.impl.PurchaseServiceImpl">
<property
name="purchaseSupplierDao"
ref="purchaseSupplierDao"/>
<property
name="purchaseRequisitionDao"
ref="purchaseRequisitionDao"/>
<property
name="purchaseRequisitionDetailDao" ref="purchaseRequisitionDetailDao"/>
<property
name="purchaseSupplyRFQDao"
ref="purchaseSupplyRFQDao"/>
<property
name="purchaseSupplyRFQDetailDao" ref="purchaseSupplyRFQDetailDao"/>
<property
name="purchaseDemandDao"
ref="purchaseDemandDao"/>
52
<property
name="purchaseDemandDetailDao"
ref="purchaseDemandDetailDao"/>
<property
name="purchaseOrderDao"
ref="purchaseOrderDao"/>
<property
name="purchaseOrderDetailDao"
ref="purchaseOrderDetailDao"/>
<property
name="purchaseMonthendtrxDao"
ref="purchaseMonthendtrxDao"/>
<property
name="inventoryItemDao"
ref="inventoryItemDao"/>
</bean>
<!-- general ledger -->
<bean
id="generalLedgerService" class="ilkom.erp.service.impl.GeneralLedgerServiceImpl">
<property name="generalLedgerDao" ref="generalLedgerDao"/>
<property name="GLJournalDao" ref="gLJournalDao"/>
<property name="GLJournalDetailDao" ref="gLJournalDetailDao"/>
<property name="GLMonthEndDao" ref="gLMonthEndDao"/>
</bean>
<!-- order -->
<bean
id="orderService" class="ilkom.erp.service.impl.OrderServiceImpl">
<property name="orderDebiturDao" ref="orderDebiturDao"/>
<property name="orderCartDao" ref="orderCartDao"/>
<property name="orderCartDetailDao" ref="orderCartDetailDao"/>
<property name="orderShippingTypeDao" ref="orderShippingTypeDao"/>
<property name="orderPaymentTypeDao" ref="orderPaymentTypeDao"/>
<property name="orderDeliveryDao" ref="orderDeliveryDao"/>
<property name="orderMonthendtrxDao" ref="orderMonthendtrxDao"/>
</bean>
<!-- admin -->
<bean
id="adminService" class="ilkom.erp.service.impl.AdminServiceImpl">
<property name="adminAccPeriodDao" ref="adminAccPeriodDao" />
<property name="adminCompanyDao" ref="adminCompanyDao"/>
<property name="adminGroupDao" ref="adminGroupDao"/>
<property name="adminModulDao" ref="adminModulDao"/>
<property
name="adminUOMConvertionDao"
ref="adminUOMConvertionDao"/>
<property name="adminUOMDao" ref="adminUOMDao"/>
<property name="adminUserDao" ref="adminUserDao"/>
<property name="adminVehicleDao" ref="adminVehicleDao"/>
<property name="adminPageDao" ref="adminPageDao"/>
<property name="adminModulPeriodDao" ref="adminModulPeriodDao"/>
</bean>
<!-- accountReceivable -->
<bean
id="accountReceivableService"
class="ilkom.erp.service.impl.AccountReceivableServiceImpl">
<property
name="accountReceivableInvoiceDao" ref="accountReceivableInvoiceDao"/>
<property
name="accountReceivableInvoiceDetailDao" ref="accountReceivableInvoiceDetailDao"/>
<property
name="accountReceivableReceiptDao" ref="accountReceivableReceiptDao"/>
<property
name="accountReceivableReceiptDetailDao" ref="accountReceivableReceiptDetailDao"/>
<property
name="accountReceivableMonthEndDao" ref="accountReceivableMonthEndDao"/>
</bean>
<!-- accountPayable -->
<bean
53
id="accountPayableService"
class="ilkom.erp.service.impl.AccountPayableServiceImpl">
<property
name="accountPayableInvoiceDao"
ref="accountPayableInvoiceDao"/>
<property
name="accountPayableInvoiceDetailDao" ref="accountPayableInvoiceDetailDao"/>
<property
name="accountPayablePaymentDao"
ref="accountPayablePaymentDao"/>
<property
name="accountPayablePaymentDetailDao" ref="accountPayablePaymentDetailDao"/>
<property
name="accountPayableMonthEndDao"
ref="accountPayableMonthEndDao"/>
</bean>
Lampiran 6 Declarative Transaction untuk setiap modul
<!—Inventory-->
<bean
id="moduleInventoryService" class="org.springframework.transaction.interceptor.
TransactionProxyFactoryBean">
<property name="target" ref="inventoryService"/>
<property name="transactionManager" ref="hibernateTransactionManager"/>
<property name="transactionAttributes">
<props>
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
<!-- purchase -->
<bean
id="modulePurchaseService" class="org.springframework.transaction.interceptor.
TransactionProxyFactoryBean">
<property name="target" ref="purchaseService"/>
<property name="transactionManager" ref="hibernateTransactionManager"/>
<property name="transactionAttributes">
<props>
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
<!-- general ledger -->
<bean
id="moduleGeneralLedgerService"
class="org.springframework.transaction.interceptor.
TransactionProxyFactoryBean">
<property name="target" ref="generalLedgerService"/>
<property name="transactionManager" ref="hibernateTransactionManager"/>
<property name="transactionAttributes">
<props>
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
<!-- order -->
<bean
id="moduleOrderService" class="org.springframework.transaction.interceptor.
TransactionProxyFactoryBean">
<property name="target" ref="orderService"/>
<property name="transactionManager" ref="hibernateTransactionManager"/>
<property name="transactionAttributes">
<props>
54
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
<!-- admin -->
<bean
id="moduleAdminService" class="org.springframework.transaction.interceptor.
TransactionProxyFactoryBean">
<property name="target" ref="adminService"/>
<property name="transactionManager" ref="hibernateTransactionManager"/>
<property name="transactionAttributes">
<props>
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
<!-- accountReceivable -->
<bean
id="moduleAccountReceivableService"
class="org.springframework.transaction.interceptor.
TransactionProxyFactoryBean">
<property name="target" ref="accountReceivableService"/>
<property name="transactionManager" ref="hibernateTransactionManager"/>
<property name="transactionAttributes">
<props>
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
<!-- accountPayable -->
<bean
id="moduleAccountPayableService"
class="org.springframework.transaction.interceptor.
TransactionProxyFactoryBean">
<property name="target" ref="accountPayableService"/>
<property name="transactionManager" ref="hibernateTransactionManager"/>
<property name="transactionAttributes">
<props>
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
Lampiran 7 contoh kode program
a. tanpa menggunakan ORM
public class UserDaoSql92 implements UserDao {
private DataSource dataSource;
private PreparedStatement insertStatement;
private PreparedStatement updateStatement;
private PreparedStatement deleteStatement;
public UserDaoSql92(DataSource dataSource) throws DaoException {
try {
this.dataSource = dataSource;
java.sql.Connection conn = this.dataSource.getConnection();
insertStatement = conn.prepareStatement
("insert into USER(user_name, password, email ) values (?, ? ,?)");
55
updateStatement = conn.prepareStatement
("update USER set (user_name=?, password=?, email=? )");
deleteStatement = conn.prepareStatement("delete USER where user_id=?");
} catch (SQLException ex) {
Logger.getLogger("global").log(Level.SEVERE, null, ex);
}
}
public void create(User user) throws DaoException {
if (user == null) {
throw new struts.dao.exception.DaoException("insert null user");
} else {
User usr = getById(user.getUserId());
if (user.getUserId() != 0 && usr != null) {
throw new DuplicateNameException();
} else {
try {
insertStatement.setString(1, user.getUserName());
insertStatement.setString(2, user.getPassword());
insertStatement.setString(3, user.getEmail());
insertStatement.executeUpdate()
} catch (SQLException ex) {
Logger.getLogger("global").log(Level.SEVERE, null, ex);
}
}
b. Dengan ORM tanpa Declarative Transaction dan Inversion of Controls
public class UserDaoHibernate{
public void insert (User user){
Configuration cfg = new Configuration();
SessionFactory factory = cfg.configure().buildSessionFactory();
Session session = factory.openSession();
User user= new User();
user.setName("Dianis");
user.setEmail("[email protected]");
user.setPassword("rahasia")
session.save(user);
session.flush();
session.close();
}
public void update (Long userId){
Configuration cfg = new Configuration();
SessionFactory factory = cfg.configure().buildSessionFactory();
Session session = factory.openSession();
Transaction transaction = session.beginTransaction();
Long userId = 1l;
USer user= (User) session.load(User.class, userId);
System.out.println(user.getName());
user.setName("indah");
session.update(user);
transaction.commit();
session.close();
}
public void delete(Long userId){
Configuration cfg = new Configuration();
SessionFactory factory = cfg.configure().buildSessionFactory();
Session session = factory.openSession();
Transaction transaction = session.beginTransaction();
Long userId = 1l;
user user = (user) session.load(user.class, userId);
System.out.println(user.getName());
session.delete(user);
transaction.commit();
session.close();
}
}
56
c. Dengan ORM, Declarative Transaction, dan Inversion of Controls
public class UserDaoHibernate extends HibernateDaoSupport implements UserDao {
public void save(User user) {
getHibernateTemplate().saveOrUpdate(user);
}
public void delete(User user) {
getHibernateTemplate().delete(user);
}
}