PENERAPAN OBJECT RELATIONAL MAPPING PADA PENGEMBANGAN ENTERPRISE RESOURCE PLANNING DIAN INDAH SAVITRI

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. NIP 132 312 485

Toto Haryanto, S.Kom

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 hidayahNya 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

Tujuan Penelitian Tujuan dari penelitian ini adalah:

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.

1

2

3

Menganalisis ketidaksesuaian yang muncul dari rancangan sistem Ritel ERP yang dikembangkan Ernita (2008) dan basis data relasional yang digunakan. Menerapkan konsep ORM untuk mengatasi masalah ketidaksesuaian tersebut. Memanfaatkan konsep design pattern dalam pengaksesan basis data oleh lapisan aplikasi.

Ruang Lingkup Penelitian Ruang lingkup penelitian ini adalah : 1

2

Membangun lapisan Model untuk aplikasi Ritel ERP dengan menerapkan konsep ORM dengan menggunakan satu framework yang telah ada tanpa membandingkan dengan framework ORM lain. 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. fungsi  Lapisan basis data berisi 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

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-tomany. 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. Table1

Table3

OR Mapping

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.

Table2

database

Gambar 1 Mekanisme ORM (Thamura et al. 2007). Framework Framework adalah aplikasi semicomplete 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.

4

Design pattern dan JEE pattern Design pattern adalah pola atau unsurunsur 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 seolaholeh 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. Controller

Manipulasi

Model

Interaksi

Ditampilkan

View

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

itu mengatur rollback (method dan exception) apabila terjadi kegagalan transaksi (Walls & Beidenbach 2005 ). Dependency Control

Injection

/

Inversion

of

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 masingmasing 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. Studi literatur

Analisis permasalahan ketidaksesuaian

Perancangan dan implementasi ORM dan design pattern

evaluasi

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 2

3

4

5 6

Membuat konfigurasi basis data. Membuat pemetaan Data Transfer Object (DTO) dengan menghilangkan paradigma ketidaksesuaian antara basis data relasional dan pemrograman berorientasi objek. Membuat fungsi-fungsi akses data sebagai implementasi dari DAO pattern, singleton pattern, dan factory method pattern. Menyederhanakan fungsi akses data dengan memanfaatkan konsep facade pattern dan proxy pattern. Membuat skema basis data. 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

1 Melakukan Konfigurasi Basis Data

Kebanyakan entitas pada basis data mempunyai keterhubungan dengan entitas yang lainnya. Elemen yang menghubungkan kedua tabel tersebut ditandai dengan foreign key.

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:

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.

1 2 3 4 5 6 7 8 9 10

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:

jdbc.username=root jdbc.password=admin jdbc.url=jdbc:mysql://localhost: 3306/erp jdbc.driver=com.mysql.jdbc.Driver hibernate.dialect=org.hibernate. dialect.MySQL5InnoDBDialect hibernate.show_sql=true hibernate.hbm2ddl.auto=create 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

Product -id : int -prodName : string -unitPrice : double

public class private private private //getter and }

Product{ int id; String prodName; Double unitPrice; setter method

product PK

id : int prod_name : varchar unit_price : longint

Prod_ID

Prod_name

Unit price

1

pupuk

100

2

bibit

200

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 2 3 4 5 6 7

@Entity @Table(name = "PU_SUPLIER") public class Supplier{ @Embedded private Address address = new Address(); }

-

Class Address

1 2 3 4 5 6

@Embeddable public class Address { private String street; private String city; private String zipCode; }

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 2 3 4 5 6 7 8 9

@Entity @Table(name = "IN_ITEM") public class Item{ @Id @GeneratedValue(strategy= GenerationType.AUTO) @Column(name="id") private Long id; }

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-tomany. Proses pemetaan asosiasi antara dua entitas adalah sebagai berikut:  One-to-one

Gambar 5 Pemetaan Asosiasi one-to-one.

9

Gambar 5 merupakan ilustrasi dari class

 One-to-many

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 2 3 4 5 6

@Entity @Table(name="pu_order") public class Order { @OneToOne (mappedBy="order") private Demand demand; }

-

Class Demand

1 2 3 4 5 6 7

@Entity @Table(name="pu_demand") public class Demand { @OneToOne @JoinColumn (name="id_order") private Order order; }

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.

Gambar 6 Pemetaan Asosiasi one-to-many. Gambar 6 merupakan ilustrasi class yang berasosiasi one-tomany dengan class RequisitionDetail. Jadi setiap satu objek Requisition terdiri atas banyak objek RequisitionDetail.

Requisition

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-tomany dengan class RequisitionDetail. Apabila asosiasinya bidirectional, maka dapat dikatakan class RequisitionDetail berasosiasi many-toone dengan class Requisition. Proses pemetaannya ditulis sebagai berikut:

- Class RequisitionDetail 1 2 3 4 5 6 7

@Entity @Table (name="pu_req_detail") Public class RequisitionDetail { @ManyToOne @JoinColumn (name="id_req") private Requisition requisition; }

-

Class Requisition

1 2 3 4 5 6 7 8 9

@Entity @Table(name="pu_req") public class Requisition{ @OneToMany(mappedBy = "requisition") private List reqDetail = new ArrayList (); }

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

-

Class Group

1 2 3 4 5 6 7 8 9

@Entity @Table(name = "ad_group") public class Group { @ManyToMany(mappedBy= "groups") private List <Modul> moduls = new ArrayList <Modul>(); }

- Class Modul 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

@Entity @Table(name="ad_modul") public class Modul { @ManyToMany @JoinTable (name = "ad_modul_group", joinColumns={ @JoinColumn(name= "id_ad_modul")}, inverseJoinColumns={ @JoinColumn(name= "id_ad_group")}) private List groups = new ArrayList < Group>(); }

Peoperti Join table dimasukan pada properti yang mempunyai total participation yaitu class Modul. Objek Modul menentukan asosiasi pada kedua entitas tersebut. 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:

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-tomany 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 2 3 4 5 6 7

@Entity @Table(name = "IN_ITEM") public class Item { @ManyToOne @JoinColumn(name="id_brand") private Brand brand; }

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 2 3 4 5 6

@Entity public class Brand { @OneToMany(mappedBy="brand") private List item = new ArrayList(); }

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. membuat objek SessionFactory 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. session dibuat oleh class HibernateDaoSupport melalui method getHibernateTemplate. Method getHibernateTemplate bertujuan

Objek

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 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 masingmasing 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

lain AccountPayableService, AccountReceivableService, Admin GeneralLedgerService, Service, InventoryService, OrderService, dan PurchaseService. Proses memasukan DAO ke dalam Service menggunakan antara

5 Membuat Skema Basis Data.

teknik Inversion of Control oleh Spring Framework. Teknik IoC untuk Service dapat dilihat pada Lampiran 6.

Properti <prop key = "hibernate. hbm2ddl.auto"> ${hibernate. hbm2ddl.auto} 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

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 fungsifungsi 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.

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 dengan Lapisan Aplikasi

Persistensi

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 facesconfig.xml. Contoh class controller yang mengakses data adalah seperti berikut: 1 2 3 4 5 6 7 8 9 10 11 12

public class InventoryController { private InventoryService inventoryService; private Item item; @PostConstruct public void initBean(){ } public String save(){ item.setStatus("active"); InventoryService.saveItem (item); return "success";} }

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 facesconfig.xml seperti berikut: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

<managed-bean> <managed-bean-name> InventoryController <managed-bean-class> ilkom.erp.web.controller. inventory.InventoryController <managed-bean-scope> Request <managed-property> <property-name inventoryService #{moduleInventoryService}

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.

Gamma et al. 1995. Design Patterns: Elements of Reusable Object-Oriented Software. United States: AddisonWesley. 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.

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).

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.

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.

LAMPIRAN

17

Lampiran 1 Daftar Tabel 1. Modul accountPayable no 1. 2. 3. 4. 5.

Nama tabel AP_INVOICE AP_INVOICE_DETAIL AP_PAYMENT AP_PAYMENT_DETAIL AP_MONTHEND

keterangan Tabel transaksi invoice account payable Tabel transaksi invoice detail account payable Tabel transaksi payment account payable Tabel transaksi payment detail account payable Tabel transaksi month end process account payable

2. Modul accountPayment no Nama tabel 1. AR_INVOICE 2. AR_INVOICE_DETAIL 3. AR_RECEIPT 4. AR_RECIEPT_DETAIL 5. AR_MONTHEND

keterangan Tabel transaksi invoice account receiveable Tabel transaksi invoice detail account receiveable Tabel transaksi payment account receiveable Tabel transaksi payment detail account receiveable Tabel transaksi month end process account receiveable

3. Modul admin no Nama tabel 1. AD_ACCOUNT_PERIODE 2. AD_COMPANY 3. AD_GROUP 4. AD_MODUL 5. AD_MODUL_PERIODE 6. AD_PAGE 7 AD_UOM 8. AD_UOM_CONVERTION 9. AD_USER 10. AD_VEHICLE 11. AD_GROUP_MODUL 4. Modul generalLedger no Nama tabel 1. GL_JOURNAL 2. GL_JOURNAL_DETAIL 3. GL_MONTHEND 4. GL_ACCOUNT

keterangan Tabel master periode kode akun Tabel master informasi perusahaan Tabel master grup (role) pegawai Tabel master modul untuk masing-masing role Tabel master periode modul Tabel master daftar halaman (screen page) Tabel master unit of measurement (satuan pengukuran) Tabel master konversi unit pengukuran Tabel master daftar pengguna Tabel master daftar kendaraan Tabel hasil asosiasi many-to-many group dan modul

keterangan Tabel transaksi pos jurnal Tabel transaksi pos jurnal detail Tabel transaksi month end process Tabel master kode akun

5. Modul Inventory no Nama tabel 1. IN_GOODS_RECEIVE 2. IN_GOODS_RECEIVE_DETAIL 3. IN_ITEM 4. IN_MONTHEND_ITEM 5. IN_PROD_BRAND 6. IN_PROD_CATEGORY

keterangan Tabel transaksi goods receive Tabel transaksi goods receive detail Tabel master manajemen inventory Tabel transaksi month end process inventory Tabel master produc brand Tabel master product category

18

6. Modul Order no Nama tabel 1. OR_CART 2. OR_CART_DETAIL 3. OR_DEBITUR 4. OR_DELIVERY 5. OR_MONHTEND_TRX 6. OR_PAYMENT_TYPE 7. OR_SHIPPING_TYPE

keterangan Tabel transaksi add to cart Tabel transaksi cart detail Tabel master daftar debitur (costumer) Tabel transaksi pengantaran barang Tabel transaksi month end process Tabel master tipe pembayaran Tabel master tipe pengirirman barang

7. Modul Purchase no Nama tabel 1. PU_DEMAND 2. PU_DEMAND_DETAIL 3. PU_MONTHEND_TRX 4. PU_ORDER 5. PU_ORDER-DETAIL 6. PU_REQUISITION 7. PU_REQUISITION_DETAIL 8. PU_SUPPLIER 9. PU_RFQ 10. PU_RFQ_DETAIL 11. PU_RFQ_PRICE 12. PU_RFQ_SUPPLIER 13. PU_SUPPLIER_RFQ

keterangan Tabel transaksi demand order (DO) Tabel transaksi demand order detail Tabel transaksi month end process Tabel transaksi purchase order (PO) Tabel transaksi purcahse order detail Tabel transaksi purchase requisition Tabel transaksi purchase requisition detail Tabel master daftar supplier Tabel transaksi request for quotation Tabel transaksi request for quotation detail Tabel transaksi harga yang diinput supplier Tabel asosiasi many-to-many RFQ dan supplier Tabel asosiasi many-to-many supplier dan RFQ

19

Lampiran 2 Class Diagram Data Transfer Object a. Modul AccountPayable

Package inventory

Modul admin

Item UOM -id : Long -desc : String -status : String -createDate : Date -updateDate : Date

-id : Long MonthEnd -desc : String -id : Long -reOrderLevel : Integer -idDoc : String -bin : String -paymentDetail 1 -idDocDetail : String -qtyOnHand : Integer -docType : String -qtyOnHold : Integer -docDate : Date -qtyOnOrder : Integer * -acc -accYear : Integer -qtyReORder : Integer -accMonth : Integer -initCost : Double -modul -desc : String -lowCost : Double -quantity : Integer -highCost : Double -price : Double -avrgCost : Double 1 -amount : Double -diffAvrgCost : Double -status : String -closingBal : Double -createDate : Date 1 -closingAvrgBal : Double -updateDate : Date -closingDiffAvrgCost : Double -item : Item -status : String -uom : UOM -item -lastOrderDate : Date -acc : Account -lastIssueDate : Date -modul : Modul -createDate : Date -updateDate : Date -lastCostFinal : Double -latestCostInitial : Double Package 1 -latestCostSecond : Double -uom 1 -sellFixPrice : Double generalLedger -sellLatestCost : Double -monthEnd Account -sellAvrgCost : Double -attach : Byte -id : Long -prodCat : ProdCat -code : String -prodBrand : ProdBrand -desc : String -glAcc : Account -status : String -uom : UOM -createDate : Date -updateDate : Date

1 -monthEnd -invoiceDetail 1

Modul -id : Long -name : String -status : String -expiredDate : Date -createDate : Date -updateDate : Date -groups : Group

-monthEnd

1

Invoice

1

-demand

-id : Long -code : String -refNO : String -refDate : Date -amount : Double -accMonth : Integer -accYear : Integer -status : String -createDate : Date -updateDate -supplier : Supplier -demand : Demand

-invoiceDetail

1 -supplier

1

1

-invoice

1

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

-id : Long -name : String -contactPerson : String -creditTerm : String -creditLimit : Double -bankAccName : String -bankAccNo : String -status : String -createDate : Date -updateDate : Date -address : Address -glAcc

*

1

-invoiceDetail -invoice

1 1

InvoiceDetail

-paymentDetail

Package purchase Demand

*

1

-invoiceDetail -uom

1

-monthEnd

-item

1 -invoice

-id : Long -quantity : Integer -price : Double -status : String -createDate : Date -updateDate : Date -item : Item -uom : UOM -invoice : Invoice -acc : Account -monthend

-acc Payment 1

-id : Long -code : String -amount : Double -accYear : Integer -accMonth : Integer -status : String -createDate : Date -updateDate : Date -supplier : Supplier

-payment 1 1

-invoice 1 -supplier * * -payment

-paymentDetail

PaymentDetail -monthEnd

-id : Long 1 -amount : Double -status : String -createDae : Date -updateDate : Date -payment : Payment -invoice : Invoice -acc : Account -monthEnd : MonthEnd

1

-acc

-paymentDetail

20

Lanjutan Lampiran 2 Class Diagram b. Modul AccountReceivable -uom

1

Modul admin

-invoiceDetail

1 Modul -id : Long -name : String -status : String -expiredDate : Date -createDate : Date -updateDate : Date -groups : Group

-modul -monthEnd

1 1

MonthEnd 1

-uom

-item

-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

-acc

*

1

Receipt

-id : Long -desc : String -quantity : Integer -item -price : Double -status : String -createDate : Date -updateDate : Date -invoiceDetail -acc -invoice : Invoice 1 -item : Item 1 -uom : UOM 1 -acc : Account -invoiceDetail

-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

*

Account -id : Long -code : String -desc : String -status : String -createDate : Date -updateDate : Date

-invoice 1 -monthEnd -invoiceDetail

1

Invoice

1

-cart

1

1

-receiptDetail -debitur

Package order Debitur

Cart

-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

-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

1

-invoice

1

-receiptDetail

1 -invoice

-acc

ReceiptDetail

*

-receiptDetail 1

-id : Long -code : String -amount : Double -accMonth : Integer -accYear : Integer -status -createDate : Date -updateDate : Date -debitur : Debitur -cart : Cart

-receipt

1

Package generalLedger

-invoice

1

*

-id : Long -code -amount : Double -accMonth : Integer -accYear : Integer -status : String -createDate : Date -updateDate : Date -debitur : Debitur

1

1

-receipt

-debitur

1

Item

-id : Long -desc : String -status : String -createDate : Date -updateDate : Date

-monthEnd

InvoiceDetail

Package inventory

1

UOM

-id : Long -amount : Double -status : String -createDate : Date -updateDate : Date -receipt : Receipt -invoice : Invoice -acc : Account

21

Lanjutan Lampiran 2 Class Diagram c. Modul GeneralLedger Journal -id : Long -code : String -docRefNo : String -docRefDate : String -docAmount : Double -total : Double -accMonth : Integer -accYear : Integer -status : String

MonthEnd JournalDetail

-journalDetail

1

-journal

*

-id : Long -amount : Double -desc : String -status : String -createDate : Date -updateDate : Date -account -journal : Journal

-item

Package inventory 1 Item -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

-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

Account -acc

-monthEnd

*

1

Package admin

-uom

UOM 1

-monthEnd

1 1


-modul

-monthEnd

1

-id : Long -code : String -desc : String -status : String -createDate : Date -updateDate : Date

Modul -monthEnd

1

-id : Long -name : String -status : String -expiredDate : Date -createDate : Date -updateDate : Date -groups : Group

22

Lanjutan Lampiran 2 Class Diagram d. Modul Admin

Company

User

UOMConvertion

-id : Long -companyName : String -address : String -city : String -state : String -postCode : String -telpNo : String -faxNo : String -status : String -createDate : Date -updateDate : Date

-id : Long -name : String -password : String -email : String -employeId : String -role : String -status : String -createDate : Date -updateDate : Date -groups : Group

-id : Long -rate : Integer -status : String -createDate : Date -updateDate : Date -uomTo : UOM -uomFrom : UOM

Group -id : Long -desc : String -status : String -createDate : Date -updateDate : Date -moduls : Modul

*

-moduls

*

-groups

-user

*

-groups

1

Page

Modul AccPeriode -id : Long -accYear : Integer -maxPeriode : Integer -status : String -createDate : Date -updateDate : Date


-modul

1

-page

*

-uom

*

-uomConverttion

1

-id : Long -name : String -url : String -desc : String -status : String -createDate : Date -updateDate : Date -modul : Modul

UOM -id : Long -desc : String -status : String -createDate : Date -updateDate : Date

ModulPeriode -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


1

-uom

*

Vehicle


-vehicle

-vehicle

1

-acc

*

-id : Long -desc : String -type : String -load : Integer -driver : String -model : String -capacity : Integer -status : String -createDate : Date -updateDate : Date -uom : UOM -acc : Account

23

Lanjutan Lampiran 2 Class Diagram e. Modul Inventory

MonthEndItem Item ProdBrand -id : Long -desc : String -status : String -createDate : Date -updateDate : Date

-item

-prodBrand

1

*

ProdCat -id : Long -desc : String -status : String -createDate : Date -updateDate : Date

-item

-prodCat

1

*

GoodsReceive -id : Long -transDate : Date -status : String -createDate : Date -updateDate : Date -deliveryDate : Date -supplier -demand

1


-goodReceiveDetail

1

-uom

1

-id : Long -accMonth : Integer -accYear : Integer -quantity : Integer -avrgCost : Double -amount : Double -status : String -createDate : Date -updateDate : Date -item : Item

-item

1 -monthEnd

1

Package generalLedger Account -account -item 1 1

Package admin

-uom

UOM

1 -item

1


1

-detail GoodsReceiveDetail

-goodReceive

*

-id : Long -quantity : Integer -price : Double -status : String -createDate : Date -updateDate : Date -item : Item -uom : UOM -goodsReceive : GoodsReceive


1

-uom

-goodsReceiveDetail

24

Lanjutan Lampiran 2 Class Diagram f. Modul Order

Cart Debitur -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

-cart

-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

-debitur -cart * 1 -cartDetail 1 1 -delivery

1

-payment

*

-cart

CartDetail

1

-uom

-shipping

1

1

-id : Long -desc : String -createDate : Date -updateDate : Date

MonthEnd

1


-acc 1

*

-id : Long -price : Double -quantity : Integer -status : String -createDate : Date -updateDate : Date -item : Item -uom : UOM -acc : Account -cart : Cart

ShippingType -cart

-acc

-cartDetail

1

PaymentType -id : Long -desc : String -createDate : Date -updateDate : Date

1


-uom -monthend

1

1 1

-debitur

-acc

-cartDetail

-id : Long -deliveryDate : Date -driver : String -load : Integer -createDate : Date -updateDate : Date -vehicle : Vehicle -debitur : Debitur -uom : UOM

Item

UOM -cartDeail

1


Modul -id : Long -name : String -status : String -expiredDate : Date -createDate : Date -updateDate : Date -groups : Group

1 -monthend

1 -monthend


-modul 1

Delivery

Package inventory

Modul admin

-item 1

-item

1

1

-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

1

-monthend

Vehicle -vehicle

1

-id : Long -desc : String -type : String -load : Integer -driver : String -model : String -capacity : Integer -status : String -createDate : Date -updateDate : Date -uom : UOM -acc : Account

25

Lanjutan Lampiran 2 Class Diagram g. Modul Purchase

* Requisition

-item

-id : Long -code : String -transDate : Date -status : String -createDate : Date -updateDate : Date -accYear : Integer -accMonth : Integer

1

RFQ

1 *

RequisitionDetail -id : Long -quantity : Integer -createDate : Date -updateDate : Date -item : Item -uom : UOM -requisition : Requisition

1

-order

-item

-orderDetail

1 -uom

11

-supplier

*

-order -reqDEtail

Supplier

-demand

Demand -id : Long -code : String -amount : Double -deliveryAddress : String -deliveryDate : Date -transDate : Date -status : String -accMonth : Integer -accYear : Integer -status : String -order : Order -supplier : Supplier

-supplier

*

1

1 1

Address

1

-demandDetail

*

-demand

DemandDetail

-address : String -town : String -state : String -postCode : String -telpNo : String -faxNo : String -email : String

-orderDetail

Item

1

-id : Long -name : String -contactPerson : String -creditTerm : String -creditLimit : Double -bankAccName : String -bankAccNo : String -status : String -createDate : Date -updateDate : Date -address : Address -glAcc

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

Package inventory

-uom

1

-id : Long -quantity : Integer -price : Double -status : String -createDate : Date -item : Item -uom : UOM

*

-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

-id : Long -quantity : Integer -price : Double -status : String -createDate : Date -updateDate : Date -item : Item -uom : UOM -order : Order -demand

-requisition

-order

-order

1

Order

OrderDetail

-reqDetail

*

-rfq

1


*

-rfqDetail

1

-rfq

RFQDetail -id : Long -quantity : Integer 1 -price : Double 1 -status : String -rfqDetail -createDate : Date -updateDate : Date -item -item : Item -uom : UOM -rfq : RFQ

1

-uom

-monthEnd -demandDetail 1

-supplier

*

Price

1

-id : Long -price : Double -deliveryDate : String -rfqDetail : RFQDetail -supplier : Supplier

-orderDetail

Modul admin -eqDetail -item

*

MonthEnd -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

UOM

-demandDetail 1

1

1


1

-reqDetail

-uom -monthEnd 1 -monthEnd -modul 1 1 -account 1

1

-address

-item -uom 1

-price

1 Modul


Package generalLedger Account

-monthEnd

1


*

-rfqDetail

26

Lampiran 3 ER Diagram a. Modul admin AD_UOM AD_COMPANY

AD_MODUL_PERIOD

AD_USER PK

PK

CompCode

PK

modulPeriodCode

PK

UOMCode

UserID

1 FK1

GroupCode

1

1…*

1 AD_UOMCONVERTION

1 AD_ACC_PERIODE AD_GROUP PK

AD_PAGE

accPeriodCode PK

GroupCode PK

PageCode

FK1

ModuleCode

1…*

PK PK

UOMFrom UOMTo

FK1

UOMCode

1…*

AD_VEHICLE

1

PK

VehicleCode

FK1 FK2

UOMCode AccCode

1 AD_MODULE_GROUP

1 AD_MODULE

1 FK1 FK2

PK

GroupCode ModuleCode

1

ModuleCode

1…* 1

Modul generalLedger GL_ACCOUNT2 PK

b. Modul general Ledger GL_ACCOUNT

Modul admin

PK

1

AccCode

1 AD_MODULE PK

ModuleCode

1

1

1

JournalDetailCode

FK1 FK2

JournalCode AccCode

1…*

1

1

GL_MONTHEND

AD_UOM

1 PK

GL_JOURNAL_DETAIL PK

UOMCode

1

PK

monthEndCode

FK1 FK2 FK3 FK4

ModuleCode UOMCode AccCode ItemCode

1 1

Modul inventory IN_ITEM PK

ItemCode ProdCatCode ProdBrandCode

GL_JOURNAL PK

JournalCode

AccCode

27

c. Modul inventory IN_PROD_BRAND PK

1

ProdBrandCode

Modul admin

1..* IN_ITEM

1..* IN_PROD_CAT PK

ProdCatCode

IN_GOODS_RECEIVE_DETAIL

PK

ItemCode

FK1 FK2 FK3 FK4

ProdBrandCode ProdCatCode AccCode UOMCode

1

1

1

1 1

PK

GdRcvDetailCode

FK1 FK2 FK3

GoodReceiveCode ItemCode 1 UOMCode

1

AD_UOM

1 PK

1

1..* IN_MONTHEND_ITEM

1

Modul purchase

PK

monthItemEndCode

IN_GOODS_RECEIVE

1

PU_DEMAND PK

DemandCode

1

PK

GoodReceiveCode

FK1 FK2

DemandCode SupplierCode

OrderCode SupplierCode

Modul generalLedger

1 1

PU_SUPPLIER PK

UOMCode

GL_ACCOUNT3

1

PK

AccCode

SupplierCode AccCode

d. Modul order OR_PAYMENT_TYPE PK

OR_SHIPPING_TYPE

paymentTypeCode

PK

shippingTypeCode

1

1 1

1 OR_CART

1..*

OR_MONTHENDTRX PK

monthEndCode

FK1 FK2 FK3 FK4

ModuleCode AccCode UOMCode ItemCode

PK

CartCode

FK1 FK2 FK3

paymentTypeCode shippingTypeCode DebiturCode

OR_DEBITUR

1 PK

DebiturCode

FK1

AccCode

1

1

1

1

Modul generalLedger 1

1..*

1

1

GL_ACCOUNT PK

OR_CART_DETAIL

1

PK

CartDetailCode

FK1 FK2 FK3 FK4

CartCode ItemCode UOMCode AccCode

1

1

Modul inventory 1

IN_ITEM

1

PK

1


1 1

Modul admin AD_MODULE PK

AD_VEHICLE

1

1

ModuleCode

PK

VehicleCode

PK

1

UOMCode

1 1

1

OR_DELIVERY

1

AD_UOM

PK

DeliveryCode

FK1 FK2 FK3

VehicleCode UOMCode DebiturCode

AccCode

28

e. Modul purchase

Modul inventory PU_RFQ_DETAIL

PU_RFQ_PRICE PK

RFQDetailCode

FK1 FK2

RFQCode SupplierCode

FK1 FK2 FK3

ItemCode UOMCode RFQCode

1..*

1 PK

1

PU_RFQ

1

PU_RFQ_SUPPLIER

1

Modul admin

FK1 FK2

SupplierCode requisitionCode

1

1

1..*

1

DemmandDetailCOde

FK1 FK2 FK3

UOMCode ItemCode DemandCode

1

1

PK

OrderDetailCode

FK1 FK2 FK3

OrderCode ItemCode UOMCode

AD_UOM

1 1

1

PU_DEMAND

1 PK

1

FK1 FK2

OrderCode RFQCode SupplierCode

1

PU_SUPPLIER

1

1

PK

SupplierCode

FK1

AccCode

DemandCode

FK1 FK2


PU_MONTHENDTRX

1 1

PK

1

1…*

1…*

AccCode

1…*

1…*

GL_ACCOUNT PK

1

PU_ORDER

1

PK

monthEndCode

FK1 FK2 FK3

ItemCode UOMCode ModuleCode

PK

UOMCode

1

1

1..*

Modul generalLedger

ModuleCode

1 1

1

PK

1…*


AD_MODULE

PK

PU_ORDER_DETAIL

FK1 FK2

requisitionCode

1

1

1

PU_SUPPLIER_RFQ

requisitionCode UOMCode ItemCode

PU_DEMAND_DETAIL

RFQCode


FK1 FK2 FK3

PK

1

PK

1..* FK1 FK2

reqDetailCode

1 1

1

1

ProdCatCode ProdBrandCode

1

1..*

1

ItemCode

PK

1..*

priceCode

PU_REQUISITION

1

IN_ITEM

1

PK

1..*

PU_REQUISITION_DETAIL

1

29

f. Modul account receivable 1

Modul generalLedger

1 AR_INVOICE

AR_RECEIPT

PK

ARInvoiceCode

FK1 FK2

DebiturCode CartCode

GL_ACCOUNT PK

AccCode

1 1

PK

ARRcptCode

FK1

DebiturCode

1..*

1..*

1

1

1

1

1

1

1..*

AR_RCPT_DETAIL

1

Modul order 1

OR_CART

1..*

OR_DEBITUR PK FK1 FK2 FK3

ARRcptDetailCode

PK

ARRcptCode ARInvoiceCode AccCode

CartCode PK

paymentTypeCode shippingTypeCode DebiturCode 1

Modul inventory

Modul admin

1

1

AD_UOM AD_MODULE

IN_ITEM

PK

UOMCode PK

PK

1

ModuleCode


1

1

1 1 1

1

AR_MONTHEND PK

monthEndCode

FK1 FK2 FK3 FK4

ModuleCode AccCode ItemCode UOMCode

1

DebiturCode

AR_INV_DETAIL

1

PK

ARInvDetailCode

1

FK1 FK2 FK3 FK4

ARInvoiceCode ItemCode UOMCode AccCode

30

g. Modul account payable

Modul inventory IN_ITEM

Modul admin

PK


AD_UOM

1 PK

1

UOMCode

Modul purchase

1

1

PU_DEMAND

1 PK

DemandCode

AD_MODULE PK

1


ModuleCode

PU_SUPPLIER

1 PK

AP_MONTHEND PK

monthEndCode

FK1 FK2 FK3 FK4

AccCode ItemCode UOMCode ModuleCode

1

SupplierCode

1 AccCode

1

1

1

Modul generalLedger

1

GL_ACCOUNT PK

1

1

1

AP_INV_DETAIL

1..*

1

AccCode

1

1

PK

APInvDetailCode

FK1 FK2 FK3 FK4 FK5

APInvoiceCode ItemCode AccCode UOMCode monthEndCode

1

1 AP_PAYMENT PK

APPaymentCode

FK1

SupplierCode

1..*

1..* 1 1 AP_PAYMENT_DETAIL

1 1

1

1

1

AP_INVOICE PK

APInvoiceCode

FK1 FK2

DemandCode SupplierCode

PK

APPayDetailCode

FK1 FK2 FK3 FK4

APPaymentCode APInvoiceCode monthEndCode AccCode

1

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 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)

9

company_status

VARCHAR(255)

10

create_date

DATETIME


11

update_date

DATETIME


nomor faximile yes

status tabel ("active", "inactive")

 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


4

create_date

DATETIME


5

update_date

DATETIME


 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


4

create_date

DATETIME


5

update_date

DATETIME


6

vehicle_type_code

VARCHAR(255)

tipe kendaraan

7

capacity

INTEGER

8

model

VARCHAR(255)

9

id_ad_uom

BIGINT(20)

yes

satuan unit yang dipakai

id_gl_acc

BIGINT(20)

yes

kode akun untuk setiap kendaraan

10

yes

kapasitas muatan kendaraan model kendaraan

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


5

update_date

DATETIME


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


5

create_date

DATETIME


6

update_date

DATETIME


 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


7

update_date

DATETIME


 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


5

update_date

DATETIME


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


7

create_date

DATETIME


8

update_date

DATETIME


 Nama tabel : AD_MODULE_PERIODE NO

DATA TYPE

MANDATORY

1

id

COLUMN NAME

BIGINT(20)

yes

id untuk modul peroide (month end process)

DESCRIPTION

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


5

update_date

DATETIME


 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 yes

DESCRIPTION

3

journal_desc

VARCHAR(255)

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

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)


11

create_date

DATETIME


12

update_date

DATETIME


total amount yang ada pada dokumen

 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


7

create_date

DATETIME


8

update_date

DATETIME


 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)

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)

8

quantity

INTEGER

yes

banyaknya barang yang direkap

9

tipe dari setiap dokumen

deskripsi dari monthend

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


16

update_date

DATETIME


35

c. Modul Purhcase  Nama tabel : PU_SUPPLIER 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)

12

credit_term

VARCHAR(255)

alamat email 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


18

update_date

DATETIME


19

id_ad_user

BIGINT(20)

yes

fk dari tabel user

20

id_gl_account

BIGINT(20)

yes

fk dari tabel general ledger

yes

 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


6

update_date

DATETIME


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

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


8

update_date

DATETIME


 Nama tabel : PU_RFQ NO

COLUMN NAME

DATA TYPE

MANDATORY

DESCRIPTION

1

id

BIGINT(20)

yes


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


9

create_date

DATETIME


10

update_date

DATETIME


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


9

update_date

DATETIME


 Nama tabel : PU_SUPPLIER_SENT_RFQ NO

COLUMN NAME

DATA TYPE

MANDATORY

DESCRIPTION

1

rfq_id

BIGINT(20)

yes


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


2

supplier_id

BIGINT(20)

yes


 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

4

id_pu_supplier

BIGINT(20)

tanggal pengiriman barang yes


 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

4

id_pu_supplier

BIGINT(20)

tanggal pengiriman barang yes


 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


9

update_date

DATETIME


 Nama tabel : PU_DEMAND NO

COLUMN NAME

DATA TYPE

MANDATORY

DESCRIPTION

1

id

BIGINT(20)

yes


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


6

delivery_address

VARCHAR(255)

yes

alamat pengiriman barang

7

delivery_date

DATETIME

yes


8

id_pu_order

BIGINT(20)

yes

FK dari tabel pu_order

38

NO 9

COLUMN NAME

DATA TYPE

MANDATORY yes

DESCRIPTION

status

VARCHAR(255)


10

create_date

DATETIME


11

update_date

DATETIME


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


9

update_date

DATETIME


 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


3

doc_type

VARCHAR(255)

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)

8

quantity

INTEGER

yes


9

price

DOUBLE

yes

harga tiap item

10

amount

DOUBLE

yes

total amount

11

id_ad_modul

BIGINT(20)

yes


12

id_gl_acc

BIGINT(20)

yes


13

id_in_item

BIGINT(20)

yes


14

id_ad_uom

BIGINT(20)

yes

FK dari tabel ad_uom satuan tiap unit

15

create_date

DATETIME


16

update_date

DATETIME




39

d. Modul Inventory  Nama tabel : IN_ITEM NO

COLUMN NAME

DATA TYPE

MANDATORY

1

id

BIGINT(20)

YES

2

item_desc

VARCHAR(255)

yes

3

bin

VARCHAR(255)

4

qty_on_hand

INTEGER

5

qty_on_order

INTEGER

6

qty_on_hold

INTEGER

7

qty_re_order

8

DESCRIPTION id inventory yang terdaftar pada tabel in_item deskripsi dari item yang terdaftar pada tabel in_item

Yes

lokasi penempatan di gudang jumlah stok barang yang ada di gudang dan tidak sedang dipesan jumlah stok barang yang sudah terjual

INTEGER

Yes

init_cost

DOUBLE

Yes

jumlah barang yang sudah dipesan jumlah barang yang harus dipesan jika mencapai batas minimal 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

14

closing_avrg_cost

DOUBLE

15

closing_diff_avrg_cost

DOUBLE

harga tutup buku pada akhir bulan harga rata-rata saat tutup buku pada akhir bulan 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


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

32

id_ad_uom

BIGINT(20)

Yes

fk dari user fk tabel uom, satuan untuk harga beli yang masuk ke gudang

33

in_status

VARCHAR(255)

Yes


40

 Nama tabel : IN_PROD_BRAND NO

COLUMN NAME

DATA TYPE

MANDATORY

1

id

BIGINT

yes

DESCRIPTION (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


5

update_date

DATETIME


 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


5

update_date

DATETIME


 Nama tabel : IN_GOODS_RECEIVE NO

COLUMN NAME

DATA TYPE

MANDATORY

DESCRIPTION

1

id

BIGINT(20)

yes


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


6

delivery_address

VARCHAR(255)

yes

alamat pengiriman barang

7

delivery_date

DATETIME

yes


8

id_pu_Rfq

BIGINT(20)

yes


9

status

VARCHAR(255)

yes


10

create_date

DATETIME


11

update_date

DATETIME


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


6

status

VARCHAR(255)

yes

status tabel

7

create_date

DATETIME


8

update_date

DATETIME


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


9

update_date

DATETIME


e. Modul Order  Nama tabel : OR_SHIPPING_TYPE NO

DATA TYPE

MANDATORY

1

id

COLUMN NAME

BIGINT

Yes

autoincrement

DESCRIPTION

2

description

VARCHAR

Yes

jenis pengirimannya

3

create_date

DATETIME


4

update_date

DATETIME


 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


4

update_date

DATETIME


 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


9

update_date

DATETIME


amount

DOUBLE

10

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

1

id

3

Id_ tem

4

DATA TYPE

MANDATORY

DESCRIPTION

yes

id untuk tabel or_cart_detail

VARCHAR(255)

yes

Item yang dibeli apa

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


9

update_date

DATETIME


 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


10

update_date

DATETIME


 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


3

doc_type

VARCHAR(255)

4

doc_date

DATETIME

yes

tanggal dokumen

5

acc_month

INTEGER

yes


6

acc_year

INTEGER

yes

tutup buku proses month end setiap tahun

7

monthend_desc

VARCHAR(255)

8

quantity

INTEGER

yes


9

price

DOUBLE

yes

harga tiap item

10

amount

DOUBLE

yes

total amount

11

id_ad_modul

BIGINT(20)

yes




43

NO

COLUMN NAME

DATA TYPE

MANDATORY

DESCRIPTION

12

id_gl_acc

BIGINT(20)

yes


13

id_in_item

BIGINT(20)

yes


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


17

update_date

DATETIME


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


7

id_pu_supplier

BIGINT(20)

yes


8

acc_month

INTEGER


9

acc_year

INTEGER


10

status

VARCHAR(255)

11

create_date

DATETIME


12

update_date

DATETIME


yes

status transaksi ("sent","draft","cancel")

 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


10

update_date

DATETIME


 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


44

NO

COLUMN NAME

DATA TYPE

MANDATORY

DESCRIPTION

3

doc_type

VARCHAR(255)


4

doc_date

DATETIME

yes

tanggal dokumen

5

acc_month

INTEGER

yes


6

acc_year

INTEGER

yes


7

month_end_desc

VARCHAR(255)

8

quantity

INTEGER

yes


9

price

DOUBLE

yes

harga tiap item

10

amount

DOUBLE

yes

total amount

11

id_ad_modul

BIGINT(20)

yes


12

id_gl_acc

BIGINT(20)

yes


13

id_in_item

BIGINT(20)

yes


14

id_ad_uom

BIGINT(20)

yes


15

status

VARCHAR(255)

yes

status transaksi

16

create_date

DATETIME


17

update_date

DATETIME



 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


7

acc_month

INTEGER


8

acc_year

INTEGER


9

status

VARCHAR(255)

10

create_date

DATETIME


11

update_date

DATETIME


yes


 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


4

id_gl_acc

BIGINT(20)

yes


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


8

create_date

DATETIME


9

update_date

DATETIME


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


5

id_or_cart

BIGINT(20)

FK dari tabel or_cart

6

acc_month

INTEGER


7

acc_year

INTEGER


8

status

VARCHAR(255)

9

create_date

DATETIME


10

update_date

DATETIME


yes


 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


4

id_gl_acc

BIGINT(20)

yes


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


9

create_date

DATETIME


10

update_date

DATETIME


 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


3

doc_type

VARCHAR(255)

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)

8

quantity

INTEGER

yes


9



price

DOUBLE

yes

harga tiap item

10

amount

DOUBLE

yes

total amount

11

id_ad_modul

BIGINT(20)

yes


12

id_gl_acc

BIGINT(20)

yes


46

NO

COLUMN NAME

DATA TYPE

MANDATORY

DESCRIPTION

13

id_in_item

BIGINT(20)

yes


14

id_ad_uom

BIGINT(20)

yes


15

status

VARCHAR(255)

yes

status transaksi

16

create_date

DATETIME


17

update_date

DATETIME


 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


4

amount

DOUBLE

yes

total amount pembayaran

5

acc_month

INTEGER

6

acc_year

INTEGER

7

status

VARCHAR(255)

8

create_date

DATETIME


9

update_date

DATETIME


tutup buku proses month end setiap bulan tutup buku proses month end setiap tahun yes


 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


4

id_gl_acc

BIGINT(20)

yes


5

id_ar_invoice

BIGINT(20)

yes

Fk dari tabel ar_invoice

6

status

VARCHAR(255)

yes


7

create_date

DATETIME


8

update_date

DATETIME


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

<property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> <property name="url" value="${jdbc.url}"/> <property name="driverClassName" value="${jdbc.driver}"/>

47

b.

membuat sessionFactory dari dataSource dan DTO

<property name="dataSource" ref="dataSource"/> <property name="annotatedClasses"> <list> ilkom.erp.inventory.InventoryItem ilkom.erp.inventory.InventoryProductBrand ilkom.erp.inventory.InventoryProductCategory ilkom.erp.inventory.InventoryGoodReceive ilkom.erp.inventory.InventoryGoodReceiveDetail ilkom.erp.inventory.InventoryMonthenditem ilkom.erp.purchase.PurchaseSupplier ilkom.erp.purchase.PurchaseRequisition ilkom.erp.purchase.PurchaseRequisitionDetail ilkom.erp.purchase.PurchaseSupplyRFQ ilkom.erp.purchase.PurchaseSupplyRFQDetail ilkom.erp.purchase.PurchaseRFQPrice ilkom.erp.purchase.PurchaseDemand ilkom.erp.purchase.PurchaseDemandDetail ilkom.erp.purchase.PurchaseOrder ilkom.erp.purchase.PurchaseOrderDetail ilkom.erp.purchase.PurchaseMonthendtrx ilkom.erp.generalLedger.GeneralLedgerAccount ilkom.erp.generalLedger.GLJournal ilkom.erp.generalLedger.GLJournalDetail ilkom.erp.generalLedger.GLMonthEnd ilkom.erp.order.OrderDebitur ilkom.erp.order.OrderCart ilkom.erp.order.OrderCartDetail ilkom.erp.order.OrderShippingType ilkom.erp.order.OrderPaymentType ilkom.erp.order.OrderDelivery ilkom.erp.order.OrderMonthendtrx ilkom.erp.admin.AdminAccPeriod ilkom.erp.admin.AdminCompany ilkom.erp.admin.AdminGroup ilkom.erp.admin.AdminModul ilkom.erp.admin.AdminUOM ilkom.erp.admin.AdminUOMConvertion ilkom.erp.admin.AdminUser ilkom.erp.admin.AdminVehicle ilkom.erp.admin.AdminPage ilkom.erp.admin.AdminModulPeriod ilkom.erp.accountReceivable.AccountReceivableInvoice ilkom.erp.accountReceivable.AccountReceivableInvoiceDetail ilkom.erp.accountReceivable.AccountReceivableReceipt ilkom.erp.accountReceivable.AccountReceivableReceiptDetail ilkom.erp.accountReceivable.AccountReceivableMonthEnd ilkom.erp.accountPayable.AccountPayableInvoice ilkom.erp.accountPayable.AccountPayableInvoiceDetail ilkom.erp.accountPayable.AccountPayablePayment ilkom.erp.accountPayable.AccountPayablePaymentDetail ilkom.erp.accountPayable.AccountPayableMonthEnd

48

c.

memasukan objek sessionFactory ke semua DAO

property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/>

49

<property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/>

50

<property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/>

51

<property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/> <property name="sessionFactory" ref="sessionFactory"/>

d.

memasukan semua DAO ke dalam masing-masng Service sesuai dengan submodulnya

<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"/>

<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"/> <property name="generalLedgerDao" ref="generalLedgerDao"/> <property name="GLJournalDao" ref="gLJournalDao"/> <property name="GLJournalDetailDao" ref="gLJournalDetailDao"/> <property name="GLMonthEndDao" ref="gLMonthEndDao"/> <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"/> <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"/> <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"/>
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"/>

Lampiran 6 Declarative Transaction untuk setiap modul <property name="target" ref="inventoryService"/> <property name="transactionManager" ref="hibernateTransactionManager"/> <property name="transactionAttributes"> <props> <prop key="*">PROPAGATION_REQUIRED,readOnly <prop key="save*">PROPAGATION_REQUIRED <prop key="delete*">PROPAGATION_REQUIRED <property name="target" ref="purchaseService"/> <property name="transactionManager" ref="hibernateTransactionManager"/> <property name="transactionAttributes"> <props> <prop key="*">PROPAGATION_REQUIRED,readOnly <prop key="save*">PROPAGATION_REQUIRED <prop key="delete*">PROPAGATION_REQUIRED <property name="target" ref="generalLedgerService"/> <property name="transactionManager" ref="hibernateTransactionManager"/> <property name="transactionAttributes"> <props> <prop key="*">PROPAGATION_REQUIRED,readOnly <prop key="save*">PROPAGATION_REQUIRED <prop key="delete*">PROPAGATION_REQUIRED <property name="target" ref="orderService"/> <property name="transactionManager" ref="hibernateTransactionManager"/> <property name="transactionAttributes"> <props>

54

<prop key="*">PROPAGATION_REQUIRED,readOnly <prop key="save*">PROPAGATION_REQUIRED <prop key="delete*">PROPAGATION_REQUIRED <property name="target" ref="adminService"/> <property name="transactionManager" ref="hibernateTransactionManager"/> <property name="transactionAttributes"> <props> <prop key="*">PROPAGATION_REQUIRED,readOnly <prop key="save*">PROPAGATION_REQUIRED <prop key="delete*">PROPAGATION_REQUIRED <property name="target" ref="accountReceivableService"/> <property name="transactionManager" ref="hibernateTransactionManager"/> <property name="transactionAttributes"> <props> <prop key="*">PROPAGATION_REQUIRED,readOnly <prop key="save*">PROPAGATION_REQUIRED <prop key="delete*">PROPAGATION_REQUIRED <property name="target" ref="accountPayableService"/> <property name="transactionManager" ref="hibernateTransactionManager"/> <property name="transactionAttributes"> <props> <prop key="*">PROPAGATION_REQUIRED,readOnly <prop key="save*">PROPAGATION_REQUIRED <prop key="delete*">PROPAGATION_REQUIRED

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); } }

PENERAPAN OBJECT RELATIONAL MAPPING PADA PENGEMBANGAN ENTERPRISE RESOURCE PLANNING DIAN INDAH SAVITRI

Recommend Documents