1
RANCANG BANGUN APLIKASI ACCOUNT PAYABLE,
ACCOUNT RECEIVABLE, DAN FIXED ASSET
BERORIENTASI SOAD PADA PLATFORM JAVA
Tommy Adhyasa S.
1, Riyanarto Sarno
2, Dwi Sunaryono
31,2,3
Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember Sukolilo Surabaya
Email : jokerextreme@gmail.com1, riyanarto@its-sby.edu2, dwi@its-sby.edu3
ABSTRAK
Kondisi dunia bisnis saat ini telah berkembang menjadi semakin kompleks, semakin kompetitif, bergerak dengan cepat serta semakin sulit untuk diprediksi sehingga perusahaan perlu memadukan bisnis dan sumber daya IT yang dimiliki agar dapat secara fleksibel mengakomodasi adanya perubahan untuk kemudian dilakukan adaptasi secara cepat dan tepat.
SOAD (Service Oriented Analysis and Design) merupakan sebuah pendekatan baru yang berevolusi dari penggabungan rekayasa perangkat lunak berbasis objek dan komponen dan memberikan panduan untuk merancang, membangun, agregasi, dan penyebaran aplikasi seperti layanan web yang dibangun dengan teknologi yang dapat mencakup SOAP, WSDL atau UDDI. SOAD adalah sebuah metode pengembangan perangkat lunak yang dirancang khusus untuk Service Oriented Architecture (SOA).
Pada tugas akhir penulis akan membangun sebuah perangkat lunak sistem ERP yang khusus menangani domain fungsi Account Payable, Account Receivable dan Fixed Asset dengan menggunakan metode SOAD. Dengan digunakannya SOAD sebagai metode perancangan aplikasi berbasiskan SOA, diharapkan aplikasi ini akan memecahkan masalah perusahaan besar dimana kebutuhan pasar dan pola persaingan yang berubah dengan cepat, kecenderungan untuk merger atau kerjasama antara bisnis yang juga semakin meningkat menjadi kebutuhan yang sangat penting.
Kata kunci : SOAD, Web Service, Account Payable, Account Receivable, Fixed Asset, Enterprise
Resource Planning.
1. PENDAHULUAN
Kondisi dunia bisnis saat ini telah berkembang menjadi semakin kompleks, semakin kompetitif, bergerak dengan cepat serta semakin sulit untuk diprediksi. Agar dapat bersaing dan sukses, perusahaan perlu memadukan bisnis dan sumber daya IT yang dimiliki agar dapat secara fleksibel mengakomodasi adanya perubahan untuk kemudian dilakukan adaptasi terhadap perubahan tersebut secara cepat dan tepat.
Berbagai tantangan bisnis yang ada menuntut perusahaan untuk memiliki kemampuan respons yang cepat dan fleksibel terhadap setiap peluang, ancaman dari luar, tuntutan pelanggan, langkah-langkah kompetitor, maupun perubahan regulasi. Untuk mewujudkan hal tersebut diperlukan adanya mekanisme untuk dapat memberikan informasi yang tepat pada saat yang tepat dan diberikan kepada orang yang tepat pula
sehingga pada akhirnya dapat membantu pengambilan keputusan bisnis yang lebih baik dengan lebih cepat. Untuk dapat menghasilkan informasi tersebut diperlukan dukungan infrastruktur perusahaan yang terintegrasi, yang mampu memanfaatkan sumber daya IT yang telah ada yang juga dapat dengan mudah ditambahkan fitur dan fungsionalitas baru. Infrastruktur tersebut haruslah fleksibel dan tangkas agar dapat menyesuaikan diri terhadap perubahan yang terjadi baik pada sisi bisnis maupun IT.
SOAD (Service Oriented Analysis and Design) merupakan sebuah pendekatan baru yang berevolusi dari penggabungan rekayasa perangkat lunak berbasis objek dan komponen. SOAD memberikan panduan untuk merancang, membangun, agregasi, dan penyebaran aplikasi seperti layanan web yang dibangun dengan teknologi yang dapat mencakup SOAP, WSDL atau UDDI [2]. SOAD adalah sebuah bidang yang muncul
2 yang berhubungan dengan identifikasi dan membangun service berdasarkan kebutuhan bisnis yang ada. SOAD adalah sebuah metode atau pendekatan pengembangan perangkat lunak yang dirancang khusus untuk Service Oriented Architecture (SOA).
SOA adalah konsep pengembangan perangkat lunak yang melakukan partisi sistemnya menjadi beberapa servis yang berdiri secara independen [4]. SOA digunakan dalam perancangan servis karena dapat menyatukan serbagai sistem yang memiliki platform berbeda dan tahan terhadap perubahan. Dengan mengorganisasikan TI perusahaan lebih pada service dibanding pada aplikasi, SOA memberikan beberapa keuntungan kunci berikut:
• Meningkatkan produktifitas, agility (kelincahan), dan kecepatan baik bagi Bisnis maupun TI.
• Menjadikan TI bisa memberikan layanan yang lebih cepat dan lebih sejalan dengan bisnis.
• Menjadikan Bisnis lebih cepat merespon dan memberikan pengalaman pemakai yang lebih optimal.
Pada tugas akhir penulis akan membangun sebuah perangkat lunak sistem manajemen akutansi yang khusus menangani domain fungsi Account Payable, Account Receivable dan Fixed Asset dengan menggunakan metode SOAD. Dengan digunakannya SOAD, diharapkan aplikasi ini akan memecahkan masalah perusahaan besar dimana kebutuhan pasar dan pola persaingan yang berubah dengan cepat, kecenderungan untuk merger atau kerjasama antara bisnis yang juga semakin meningkat menjadi kebutuhan yang sangat penting.
2. KAJIAN PUSTAKA
Pada bab ini akan dibahas mengenai dasar teori yang digunakan dalam Tugas Akhir ini. 2.1 Account Payable
Account Payable (Hutang Dagang) adalah sebuah berkas atau akun pada sub-ledger yang mencatat jumlah yang harus dibayarkan oleh seseorang atau perusahaan kepada pemasok tetapi belum terbayarkan (masih merupakan suatu bentuk hutang). Bila sebuah faktur diterima oleh sebuah perusahaan dari pemasok tertentu, faktur tersebut akan
ditambahkan ke berkas hutang dagang, dan kemudian nantinya akan dihapus ketika telah dibayarkan. Dengan demikian, hutang dagang adalah suatu bentuk kredit yang pemasok tawarkan kepada pelanggan dalam penggunaan barang atau jasa mereka dengan memperbolehkan pelanggan tersebut untuk membayar setelah barang atau jasa itu diterima atau digunakan.
Domain fungsi Account Payable terbagi menjadi 2 proses bisnis antara lain Account Payable Invoicing dan Account Payable Adjustment yang akan dibahas lebih mendetail pada sub sub bab 2.1.1 dan 2.1.2
2.1.1 Account Payable Invoicing
Proses bisnis Account Payable Invoicing bertanggung jawab dalam proses pencatatan dan pembuatan tagihan yang nantinya akan diberikan pada domain fungsi Cash and Bank.
Proses bisnis ini memiliki empat buah sub bisnis proses antara lain :
1. Purchase Down Payment Invoice - adalah sebuah proses untuk mencatat faktur pembelian barang dengan uang muka yang diterbitkan oleh pemasok. 2. Purchase Invoice - adalah sebuah
proses untuk mencatat faktur pembelian barang yang diterbitkan oleh pemasok.
3. Purchase Return Invoice - adalah sebuah proses untuk mencatat faktur pengembalian barang yang diterbitkan oleh pemasok.
4. Payroll Invoice - adalah sebuah proses untuk mencatat pembayaran gaji suatu perusahaan dalam suatu bulan tertentu.
2.1.2 Account Payable Adjustment
Account Payable Adjustment merupakan proses penyesuaian hutang dengan menambah atau mengurangi hutang perusahaan terhadap pemasok selain melalui proses Purchase Invoice. Pada proses bisnis Account Payable Adjustment, terdapat dua sub proses bisnis yang sekaligus merepresentasikan jenis penyesuaian hutang pada aplikasi yang penulis bangun, yaitu Account Payable Credit Adjustment dan Account Payable Debit Adjustment.
2.2 Account Receivable
Account Receivable (Piutang Dagang) adalah jumlah uang yang harus dibayarkan
3 oleh pelanggan kepada sebuah perusahaan karena membeli barang atau jasa secara kredit yang nantinya akan ditampilkan sebagai aktiva. Domain fungsi Account Receivable terbagi menjadi 2 proses bisnis antara lain Account Receivable Invoicing dan Account Receivable Adjustment yang akan dibahas lebih mendetail pada sub sub bab 2.2.1 dan 2.2.2.
2.2.1 Account Receivable Invoicing
Proses bisnis Account Receivable Invoicing bertanggung jawab dalam proses pencatatan dan pembuatan tagihan yang nantinya akan diberikan pada domain fungsi Cash and Bank.
Proses bisnis ini memiliki tiga buah sub bisnis proses antara lain :
1. Sales Down Payment Invoice - adalah sebuah proses untuk mencatat dan menerbitkan sales dp invoice kepada pelanggan. Proses ini diawali ketika terdapat pelanggan yang melakukan pemesanan barang dengan disertai oleh uang muka.
2. Sales Invoice - adalah sebuah proses untuk mencatat dan menerbitkan sales invoice kepada pelanggan. Proses ini diawali ketika terdapat pelanggan yang melakukan pemesanan terhadap 3. Sales Return Invoice - adalah sebuah
proses untuk mencatat sales return notes dan menerbitkan sales credit notes kepada pelanggan. Proses ini dilakukan bila terdapat pengembalian barang oleh pelanggan yang diakibatkan kerusakan barang, kualitas yang buruk dan lain sebagainya.
2.2.2 Account Receivable Adjustment
Account Receivable Adjustment merupakan proses penyesuaian piutang dengan menambah atau mengurangi piutang perusahaan terhadap pelanggan selain melalui proses Sales Invoice.
Pada proses bisnis Account Receivable Adjustment, terdapat dua sub proses bisnis yang sekaligus merepresentasikan jenis penyesuaian hutang pada aplikasi yang penulis bangun, yaitu Account Receivable Credit Adjustment dan Account Receivable Debit Adjustment.
2.3 Fixed Asset
Setiap perusahaan pasti memiliki aset (aktiva) yang digunakan untuk mendukung kegiatan usahanya. Aktiva tetap (Fixed Asset) merupakan istilah yang digunakan untuk menyatakan sebuah aset atau properti perusahaan yang tidak dapat dengan mudah dikonversikan menjadi uang tunai [3].
Domain fungsi Fixed Asset terbagi menjadi 2 proses bisnis antara lain Fixed Asset Register dan Fixed Asset Management yang akan dibahas lebih mendetail pada sub sub bab 2.3.1 dan 2.3.2.
2.3.1 Fixed Asset Register
Proses bisnis Fixed Asset Register bertanggung jawab dalam proses pencatatan penambahan aktiva tetap perusahaan. Pencatatan dimulai sejak proses penerimaan barang dari domain fungsi Inventory hingga nantinya akan ditaruh di gudang. Proses bisnis ini hanya memiliki satu buah sub bisnis proses yang bernama Fixed Asset Additional.
2.3.2 Fixed Asset Management
Proses bisnis Fixed Asset Management bertanggung jawab dalam segala transaksi atau aktivitas yang melibatkan aktiva tetap perusahaan. Aktivitas-aktivitas tersebut pada aplikasi ini akan diwakili sebagai sub bisnis proses dari proses bisnis Fixed Asset Management. Sub bisnis proses yang terdapat pada proses bisnis ini FA Transfer, FA Depreciation, FA Maintenance, FA Stoke Take, FA Revaluation dan FA Disposal.
Proses bisnis Fixed Asset Management pada aplikasi Fixed Asset yang penulis bangun, memiliki beberapa sub bisnis proses, yaitu :
1. Fixed Asset Transfer - adalah proses pencatatan pemindahan aktiva tetap dari suatu lokasi ke lokasi lainnya.
2. Fixed Asset Depreciation - adalah proses penyusutan nilai harga dari aktiva tetap yang dilakukan ke harta yang berstatus “Active” (umur aset masih belum habis). 3. Fixed Asset StokeTake - adalah proses
untuk memastikan bahwa keadaan aktiva tetap yang berada pada suatu perusahaan masih sesuai dengan keadaan nyatanya atau tidak.
4. Fixed Asset Revaluation - adalah proses penilaian kembali nilai perolehan dari aktiva tetap karena tidak mencerminkan dengan keadaan harta yang sebenarnya.
4 5. Fixed Asset Maintenance - adalah proses
pencatatan data pemeliharaan aktiva tetap. 6. Fixed Asset Disposal - adalah proses penghapusan aktiva tetap perusahaan yang dikarenakan aktiva tetap tersebut hilang, rusak, atau tidak dapat digunakan kembali.
2.3 Service Oriented Analysis and
Design (SOAD)
SOAD memberikan panduan untuk merancang, membangun, agregasi, dan penyebaran aplikasi seperti layanan web yang dibangun dengan teknologi yang dapat mencakup SOAP, WSDL atau UDDI . SOAD adalah sebuah bidang yang muncul yang berhubungan dengan identifikasi dan membangun service berdasarkan kebutuhan bisnis yang ada. Titik awal dalam SOAD adalah pemodelan bisnis proses. SOAD meliputi seluruh rentang mulai dari analisis proses bisnis sampai ke desain Teknilogi Informasi dan implementasinya.
Karena SOA membagi fungsi-fungsi menjadi unit-unit yang berbeda (service), yang dapat didistribusikan, dikomposisikan serta digunakan kembali membentuk sebuah servis yang lain dalam mengotomasikan aplikasi bisnis, mada tentunya servis harus didesain sedemikian rupa sehingga memenuhi tujuan yang diinginkan. Dalam mendesain sebuah servis dengan orientasi SOA, diperlukan sebuah tahapan yang mencakup proses analisis kebutuhan dan perancangan desain sistem yang menjadi dasar arsitektur sebuah sistem, hal ini dapat diatasi dengan menggunakan SOAD. Perancangan SOAD dilakukan secara top-down, yaitu dengan menganalisa dan mengelompokkan kebutuhan bisnis kemudian menerjemahkannya menjadi servis yang akhirnya akan didefinisikan komponen pendukung servis untuk nantinya digunakan pada sistem.
3. ANALISIS PERANGKAT LUNAK
Karena aplikasi yang akan penulis bangun merupakan aplikasi yang terintegrasi dengan domain fungsi lainnya, maka penulis menggunakan pendekatan SOAD. Pendekatan SOAD dipilih penulis dalam perancangan aplikasi ini karena memberikan kemudahan dalam integrasi dan dapat mengurangi redudansi data.
SOAD akan diidentifikasikan dengan menggunakan pola top down dan akan dibagi
menjadi tiga bagian. Berikut adalah pembagian view tersebut :
1. Conceptual View, berisikan gambaran umum dari proses bisnis yang ada dalam sistem yang akan dibangun, memudahkan pihak manajemen untuk mendefinisikan bisnis proses yang secara mudah dapat dimengerti oleh orang yang tidak terlalu paham akan aplikasi. Conceptual view menjelaskan mengenai pembagian sistem ERP ke dalam domain fungsi, proses bisnis dan proses sub-bisnis. Hal ini juga menunjukkan hubungan fungsional dari proses bisnis dan proses sub-bisnis. Berikut ini merupakan komponen dari conceptual view antara lain [1]:
• Integration of Functional Domain - diagram ini memberikan informasi domain fungsi yang menjadi objek studi kasus. Di dalam diagram ini ditunjukkan hubungan antar domain fungsi yang melibatkan proses bisnis dan proses sub-bisnisnya. Bagian ini dimiliki oleh domain fungsi OCS. • Stakeholder diagram - siapa saja
yang terlibat dalam domain fungsi tersebut.
• Functional Domain Workflow Diagram - diagram yang memberikan informasi apa saja yang dilakukan dalam setiap proses bisnis secara umum. Pada diagram ini digambarkan inputan, aktivitas dan deliverable dari sebuah proses bisnis yang ada. Gambar 2 menunjukkan contoh workflow diagram dari domain fungsi Account Payable.
2. Logical view, menggambarkan komunikasi antara conceptual view dan physical view. Bisnis proses yang telah didefinisikan di conceptual view dianalisis lebih dalam untuk memperoleh output bagi programmer. Berikut ini merupakan komponen dari logical view antara lain:
• Business layer, service layer dan
component layer, merupakan bagian
yang menggambarkan pemecahan masalah menggunakan SOAD. Business layer terdiri dari domain fungsi, proses bisnis, dan servis bisnis. Service layer menggambarkan software service layer dan yang terdiri dari software service dan internal service. Software service kemudian
5 diimplementasikan menjadi web service dalam desain PV. Web service digunakan untuk berkomunikasi antara branch dengan head office atau head office dengan head office lainnya. Internal service diimplementasikan sebagai method dalam application service layer yang digunakan untuk berkomunikasi dengan domain fungsi lain dalam 1 branch, dan dari branch ke branch lainnya. Component layer menggambarkan software component yang terdiri dari class yang beragregate untuk mendukung terbentuknya web service. Gambar 1 menunjukkan contoh mapping dari domain fungsi Account Payable.
Gambar 1 Mapping Domain Fungsi Account Payable
• Matrix of the business services versus
the business entities - merupakan
mapping antara business service dan business entities dan antara software service dengan software entities • Business service activity diagram -
Diagram ini memberikan informasi apa saja servis bisnis, servis aplikasi, proses internal, entitas aplikasi yang terjadi dalam tiap proses bisnis, di dalam diagram ini ditunjukkan urutan aktivitas yang terjadi mulai dari perolehan input untuk transaksi
sampai bagaimana menghasilkan servis aplikasi.
3. Physical view, merupakan implementasi dari conceptual view. Berikut adalah komponen dari physical view
• Web Service Layer, yang menggambarkan web service apa saja yang di-publish, tiap web service terdiri dari operasi yang bisa digunakan.
• Presentation Layer, menggambarkan desain user interface.
• Application Service Layer, layer ini berisi implementasi logika bisnis dari suatu aplikasi sebagai suatu method.
• Domain Model Layer,
menggambarkan class yang digunakan oleh aplikasi dalam class diagram. • Data Access Layer, layer ini
bertanggungjawab untuk hubungan langsung dengan database. Pada bagian ini seluruh koneksi database akan diimplementasikan.
4. IMPLEMENTASI
Berikut adalah pembahasan mengenai
implementasi
aplikasi
yang
penulis
bangun.
4.1 Implementasi Pemetaan Tabel dari
Database ke class
Langkah yang dibutuhkan untuk mengimplementasikan pemetaan tabel dari database kedalam class adalah:
• Membuat koneksi antara netbeans dengan database yang akan digunakan untuk menyimpan data.
• Membuat configuration hibernate yang menyatakan hubungan antara package bersangkutan dengan database yang akan menjadi referensi penyimpanan data.
• Membuat file helper file yang berfungsi untuk penginisialisasian SessionFactory untuk proses transaksi dari atau kedalam database.
• Membuat reverse engineering file yang menyatakan tabel mana sajakah yang akan digunakan dalam aplikasi. • Menggenerate mapping file dan POJO
sesuai dengan nama tabel yang telah dipilih pada file hibernate.reveng.xml. analysis Fixed Asset
< < B u s in e s s L a y e r > > < < C o m p o n e n t L a y e r > > F u n c ti o n a l D o m a in < < S e rv ic e L a y e r > > S o ft w a re C o m p o n e n t In te rn a l S e rv ic e B u s in e s s S e rv ic e B u s in e s s P ro c e s s «<< Functional Domain >>» 5. Fixed Asset «<< Business Process >>» 5.1 Fixed Asset Register
«<< Business Service>>» 5.1.1 ProvidingFixedAssetAdditional
5.1.1.1 ProvideFixedAssetAdditionalData
Component Diagram::Fixed Asset Register
5.1.1.2 Cr eateFAAdditionalTransaction
6 Pemetaan tabel ke class dengan menggunakan Hibernate akan dibagi menjadi 2 bagian, yaitu file POJO yang merepresentasikan class dan file berekstensikan hbm.xml yang menyatakan mapping class ke tabel.
4.3 Implementasi Komponen Data Access
Layer
Data Access Layer merupakan layer yang berfungsi untuk melakukan segala transaksi yang dibutuhkan aplikasi ke database. Layer ini dimplementasikan ke dalam package yang berakhiran .dataaccess. Gambar 4.12 menunjukkan class diagram dari CrudMana-gerDAO :
Gambar 2 Class CrudManagerDAO
4.4 Implementasi Komponen Application
Service Layer
Application Service Layer merupakan layer yang berada diantara presentation layer dengan data access layer. Layer ini berperan dalam melakukan proses bisnis pada aplikasi untuk menjamin integritas dari aplikasi. Gambar 3 menunjukkan contoh Class Diagram implementasi dari sub bisnis proses AP Adjustment pada Application Service Layer.
4.5 Implementasi Komponen User Interface Web
Bagian ini akan menjelaskan tampilan dari web Account Payable, Account Receivable dan Fixed Asset.
4.5.1 Implementasi User Interface Web Account Payable
Aplikasi Account Payable memiliki fitur yang disesuaikan dengan proses bisnis yang terdapat pada domain fungsi Account Payable, yaitu AP Invoicing dan AP Adjustment kemudian dibagi lagi masing-masing per sub proses bisnisnya. Berikut adalah fitur-fitur dari aplikasi Account Payable :
• AP Invoicing
Proses bisnis AP Invoicing memiliki 4 fitur, antara lain Purchase DP Invoice, Purchase Invoice, Purchase Return Invoice dan Payroll Invoice.
• AP Adjustment
Proses bisnis AP Adjustment hanya akan memiliki 1 fitur yang mewakili proses bisnis untuk kedua sub bisnis prosesnya yaitu AP Adjustment.
4.5.2 Implementasi User Interface Web Account Receivable
Aplikasi Account Receivable memiliki fitur yang disesuaikan dengan proses bisnis yang terdapat pada domain fungsi Account Receivable, yaitu AR Invoicing dan AR Adjustment kemudian dibagi lagi masing-masing per sub proses bisnisnya. Berikut adalah fitur-fitur dari aplikasi Account Receivable :
Gambar 3 Class Diagram APAdjustmentASL class dataaccess T CrudManagerDAO + create(Object) : boolean + retrieve(Object) : List + retrieveCount(Object) : int
+ retrieveDataByID(Object, String, long) : T + update(Object) : boolean
+ delete(Object) : boolean
class Business Logic
APAdj ustmentASL
+ CreateAPAdjustmentID(DateTime) : String + DeleteAPAdjustmentData(String) : boolean
+ GetAPAdjustmentDataNotApproved(DateT ime, DateTime, String) : List<AP_AdjustmentDTO> + PostAccountPayableCreditAdjustmentJournal(DateT ime, DateT ime) : APCreditAdjustmentJournalDTO + PostAccountPayableDebitAdjustmentJournal(DateT ime, DateT ime) : APDebitAdjustmentJournalDT O + RetrieveAllAPAdjustmentData() : List<AP_AdjustmentDTO>
+ RetrieveAllAPAdjustmentDataByDate(DateT ime, DateTime, String) : List<AP_AdjustmentDTO> + RetrieveAPAdjustmentDataByID(String) : AP_AdjustmentDTO
+ SaveAPAdjustmentData(String, String, DateT ime, boolean, decimal, boolean) : boolean + UpdateAPAdjustmentData(String, String, DateT ime, boolean, decimal, boolean) : boolean + UpdateApprovalStatus(String) : boolean
«<<constructor>>»
7 • AR Invoicing
Proses Bisnis AR Invoicing memiliki 4 fitur, antara lain Sales DP Invoice, Sales Invoice, dan Sales Return Invoice.
• AR Adjustment
Proses bisnis AR Adjustment hanya akan memiliki 1 fitur yang mewakili proses bisnis untuk kedua sub bisnis prosesnya yaitu AR Adjustment.
4.5.3 Implementasi User Interface Web Fixed Asset
Aplikasi Fixed Asset memiliki fitur yang disesuaikan dengan proses bisnis yang terdapat pada domain fungsi Fixed Asset, yaitu FA Register dan FA Management kemudian dibagi lagi masing-masing per sub proses bisnisnya. Berikut adalah fitur-fitur dari aplikasi Fixed Asset :
• FA Register
Proses Bisnis FA Register hanya memiliki 1 fitur yaitu FA Additional. • FA Management
Proses Bisnis FA Management memiliki 6 fitur, antara lain FA Transfer, FA Depreciation, FA Maintenance, FA Revaluation, FA Stoke Take dan FA Disposal.
• Management Master Table
Merupakan fitur yang digunakan untuk memasukkan data master domain fungsi . Management Master Table memiliki 2 fitur, antara lain Fiscal Management untuk penanganan data master fiscal dan Type Management untuk penanganan data master type.
4.6 Implementasi Komponen Web Service Web Service akan diimplementasikan pada package berakhiran .webservice dan nantinya akan dipublish pada server glashfish beralamatkan http://10.151.31.3:4848 untuk berikutnya akan digunakan oleh domain fungsi lain atau dikonsumsi pribadi untuk keperluan pembuatan report dan orkestrasi. Gambar 4 menunjukkan contoh implementasi class diagram web service dari sub bisnis proses Purchase DP Invoice pada aplikasi Account Payable.
4.7 Implementasi Orkestrasi
Bagian ini akan menjelaskan implementasi orkestrasi web service dari domain fungsi Account Payable, Account Receivable dan Fixed Asset. Implementasi orkestrasi akan menggunakan IDE Netbeans 6.7.1 dengan glashfish ESB 2.2.
4.7.1 Implementasi Web Service Domain Fungsi Account Payable
Implementasi orkestrasi web service pada domain fungsi Account Payable akan dibagi menjadi dua kasus, yaitu kasus create invoice without manager approval dan invoice accumulation. Berikut adalah penjelasan dari masing-masing kasus tersebut :
1. Create invoice without manager approval – merupakan implementasi yang dilakukan ketika perusahaan tidak memiliki manager perusahaan. Purchase DP, Purchase Invoice, Purchase Return dan AP Adjustment akan dilakukan bersamaan sekaligus. Pengguna dapat mengakses wsdl orkestrasi ini pada alamat http://10.151.33.116:9098/AP2CASA-Service1/casaPort1?wsdl.
Gambar 4 Class Diagram APPurchaseDPInvoiceWS
class dataaccess
w ebserv ice::APPurchaseDPInv oiceWS
+ ProvidePurchaseDownPaymentInvoiceData(String, String) : APPurchaseDPInvoiceDTO
+ ProvidePurchaseDownPaymentInvoiceDataByReceivingNumber(String, String) : APPurchaseDPInvoiceDTO + ProvideUpdatePurchaseDPInvoiceStatus(String, String) : Boolean
+ ProvidePurchaseDownPaymentInvoiceList(String, String) : APPurchaseDPInvoiceDTO[]
+ ProvidePurchaseDownPaymentInvoiceTransaction(Date, String, String, BigDecimal, BigDecimal, String, String, String, String) : Boolean + CreatePurchaseDownPaymentInvoiceT ransaction(Date, String, String, BigDecimal, BigDecimal, String, String, String, String) : String + GetPurchaseDPInvoiceByStatus(String, String) : APPurchaseDPInvoiceDT O[]
+ GetPurchaseDPInvoiceByStatusAndNumber(String, String, String) : APPurchaseDPInvoiceDTO[] + RetrieveAllPurchaseDPInvoiceDT OData(String, String) : APPurchaseDPInvoiceDTO[]
8 2. Invoice Accumulation – merupakan
implementasi yang dilakukan untuk melihat data invoice lengkap dengan segala detail perhitungannya. Hal ini dilakukan karena proses invoicing terjadi tidak selalu disaat yang bersamaan. Pengguna dapat mengakses wsdl orkestrasi ini pada alamat http://10.151.33.116:9098/-APAccumulationCASAService1/casa Port1?wsdl.
4.7.2 Implementasi Web Service Domain Fungsi Account Receivable
Implementasi orkestrasi web service pada domain fungsi Account Receivable akan dibagi menjadi dua kasus, yaitu kasus create invoice without manager approval dan invoice accumulation. Berikut adalah penjelasan dari masing-masing kasus tersebut :
1. Create invoice without manager approval – merupakan implementasi yang dilakukan ketika perusahaan tidak memiliki manager perusahaan. Sales DP, Sales Invoice dan AR Adjustment akan dilakukan bersamaan sekaligus. Pengguna dapat mengakses wsdl orkestrasi ini pada alamat http://10.151.33.116:9098/AR2CASA-Service1/casaPort1?wsdl.
2. Invoice Accumulation – merupakan implementasi yang dilakukan untuk melihat data invoice lengkap dengan segala detail perhitungannya. Hal ini dilakukan karena proses invoicing terjadi tidak selalu disaat yang bersamaan. Pengguna dapat mengakses wsdl orkestrasi ini pada alamat http://10.151.33.116:9098/AR-AccumulationCASAService1/casaPort 1?wsdl.
4.7.3 Implementasi Web Service Domain Fungsi Fixed Asset
Implementasi orkestrasi web service pada domain fungsi Fixed Asset akan dibagi menjadi dua kasus, yaitu kasus create additional data without manager approval dan fixed asset history. Berikut adalah penjelasan dari masing-masing kasus tersebut :
1. Create additional data without manager approval – merupakan implementasi yang dilakukan ketika perusahaan tidak memiliki manager perusahaan. FA Additional, FA
Transfer dan FA Depreciation akan dilakukan bersamaan sekaligus ketika ada asset baru yang masuk. Pengguna dapat mengakses wsdl orkestrasi ini pada alamat http://10.151.33.116:-9098/FA2CASAService1/casaPort1?w sdl.
2. Fixed Asset history – merupakan implementasi yang dilakukan untuk melihat data history asset lengkap dengan segala detail perhitungan nilainya. Pengguna dapat mengakses wsdl orkestrasi ini pada alamat http://10.151.33.116:9098/FAAccCA-SAService1/casaPort1?wsdl.
5. UJI COBA DAN EVALUASI
Berikut adalah uji coba dan evaluasi dari perangkat lunak yang penulis bangun. 5.1 Uji Coba Aplikasi
Berikut adalah uji coba salah satu fitur pada aplikasi Account Payable yang ditunjukkan pada tabel 1.
Tabel 1 Uji Coba Halaman UI-API.dp-invoice-entry
No. Test Case Name
Test Case Expected Result Status
1. Nilai Receiving Number benar Receiving Number = “RC.000002” Success get receiving data from inventory service OK
Berikut adalah uji coba salah satu fitur pada aplikasi Account Receivable yang ditunjukkan pada tabel 2.
9
Tabel 2 Uji Coba Halaman UI-ARI.dp-invoice-entry
No. Test Case Name
Test Case Expected
Result Status 1. Nilai Sales Order Number benar Sales Order = “so.270620 11.002” Success get sales order data from sales service OK
Berikut adalah uji coba salah satu fitur pada aplikasi Fixed Asset yang ditunjukkan pada tabel 3.
Tabel 3 Uji Coba Halaman UI-FAR.additionalEntry
No. Test Case Name
Test Case Expected
Result Status 1. Nilai “Receiving Number” benar Receiving Number = “RC.000009” Success get recceiving data from inventory service OK
5.2 Uji Coba Web Service
Berikut adalah uji coba salah satu web service pada aplikasi Account Payable yang ditunjukkan pada tabel 4.
Tabel 4 Uji Coba Web Service ProvidePurchaseDown-PaymentInvoiceData
No. Test Case Name
Test Case Expected
Result Status 1. DP invoice number benar DP invoice number = “APDP.0307 11.00001”, “APDP.03 0711.0000 1” OK branch ID = “SBY”
Berikut adalah uji coba salah satu web service pada aplikasi Account Receivable yang ditunjukkan pada tabel 5.
Tabel 5 Uji Coba Web Service ProvideSalesDownPaymentInvoiceData
No. Test Case Name
Test Case Expected
Result Status 1. Test get Sales DP data DP invoice number = “ARDP.06011 1.00001”, branch ID = “SBY” “ARDP.060 111.00001” OK
Berikut adalah uji coba salah satu web service pada aplikasi Fixed Asset yang ditunjukkan pada tabel 6.
Tabel 6 Uji Coba Web Service ProvideFixedAssetAdditionalData
No. Test Case Name
Test Case Expected
Result Status 1. Test ambil additional data FA berdasark an ID FA. ID FA = “81”, branch ID = “SBY” “FAAD.030 711.00001” OK
5.3 Uji Coba Orkestrasi
Berikut adalah uji coba salah satu orkestrasi pada aplikasi Account Payable yang ditunjukkan pada tabel 7.
Tabel 7 Uji Coba Orkestrasi create invoice without
manager approval
Test Case Name
Test create invoice without manager approval Expected Result <?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelo
10 pe/" xmlns:xsi="http://www.w3.org/2001/XMLSchem a-instance" xsi:schemaLocation="http://schemas.xmlsoap.or g/soap/envelope/ http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <OrchestrationControllerResponse xmlns="http://webservice.accountpayable/" xmlns:msgns="http://webservice.accountpayabl eTrigger/"> <return xmlns="">true</return> </OrchestrationControllerResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Status
Berikut adalah uji coba salah satu orkestrasi pada aplikasi Account Receivable yang ditunjukkan pada tabel 8.
Tabel 8 Uji Coba Orkestrasi create invoice without
manager approval.
Test Case Name
Test create invoice without manager approval Expected Result <?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelo pe/" xmlns:xsi="http://www.w3.org/2001/XMLSchem a-instance" xsi:schemaLocation="http://schemas.xmlsoap.or g/soap/envelope/ http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <OrchestrationControllerResponse xmlns="http://webservice.accountreceivable/" xmlns:msgns="http://webservice.accountreceiva bleTrigger/"> <return xmlns="">true</return> </OrchestrationControllerResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Status
Berikut adalah uji coba salah satu orkestrasi pada aplikasi Fixed Asset yang ditunjukkan pada tabel 9.
Tabel 9 Uji Coba Orkestrasi create invoice without
manager approval
Test Case Test create invoice without manager
Name approval Expected Result <?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelo pe/" xmlns:xsi="http://www.w3.org/2001/XMLSchem a-instance" xsi:schemaLocation="http://schemas.xmlsoap.or g/soap/envelope/ http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <OrchestrationControllerResponse xmlns="http://webservice.accountreceivable/" xmlns:msgns="http://webservice.accountreceiva bleTrigger/"> <return xmlns="">true</return> </OrchestrationControllerResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Status
6. KESIMPULAN
Berikut adalah kesimpulan yang didapat dari pengerjaan tugas akhir ini :
• Orkestrasi web service dapat diimplementasikan pada aplikasi dengan menggunakan glassfish ESB 2.1 dengan tujuan agar aplikasi dapat dikustomisasi sesuai kebutuhan pengguna.
• Implementasi aplikasi dari masing-masing domain dapat berjalan dengan baik, hal ini dapat dilihat pada bagian uji coba dan evaluasi. Sehingga dapat disimpulkan aplikasi dapat menggantikan proses pengolahan data manual dan sebagai penyedia informasi terkait Account Payable, Account Receivable dan Fixed Asset sebagai usaha peningkatan kinerja perusahaan.
• SOAD dapat diimplementasikan dalam pembuatan aplikasi Account Payable, Account Receivable dan Fixed Asset dan berdasarkan uji coba dapat dijalankan dengan baik.
7. DAFTAR PUSTAKA
[1] Arinta, R. (2011). CV-LV-PV. Surabaya, Indonesia.
11 [2] Erl, T. (2004, September 3). Introduction to Web Services Technologies: SOA, SOAP, WSDL and UDDI. Dipetik December 29, 2010, dari http://www.informit.com: http://www.informit.com/articles/article.aspx? p=336265
[3] Oktavianty, I. (2010). SERVICE ORIENTED ANALYSIS AND DESIGN (SOAD) UNTUK PERANGKAT LUNAK
ACCOUNT PAYABLE, ACCOUNT
RECEIVABLE DAN FIXED ASSET DAN
PEMBANGUNAN PROTOTIPENYA.
Surabaya: ITS.
[4] Rama, R. (2011, January 14). Apa Itu SOA. Dipetik February 20, 2011, dari http://rendrarama.wordpress.com/:
http://rendrarama.wordpress.com/2011/01/14/a pa-itu-soa/
