RANCANG BANGUN APLIKASI ACCOUNT PAYABLE, ACCOUNT RECEIVABLE, DAN FIXED ASSET BERORIENTASI SOAD PADA PLATFORM JAVA

RANCANG BANGUN APLIKASI ACCOUNT PAYABLE, ACCOUNT RECEIVABLE, DAN FIXED ASSET BERORIENTASI SOAD PADA PLATFORM JAVA Tommy Adhyasa S.1, Riyanarto Sarno2, Dwi Sunaryono3 1,2,3

Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember Sukolilo Surabaya Email : [email protected], [email protected], [email protected] 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.

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

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 1

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

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

2.2 Account Receivable Account Receivable (Piutang Dagang) adalah jumlah uang yang harus dibayarkan 2

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

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.

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.

3

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 subbisnis. Hal ini juga menunjukkan hubungan fungsional dari proses bisnis dan proses subbisnis. 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.

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.

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

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 4

sampai bagaimana servis aplikasi.

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.

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.

Internal Service Software Component

Business ServiceBusiness Process Functional Domain

<< Service Layer >> << Component Layer >>

<< Business Layer >>

analysis Fixed Asset

«<< Functional Domain >>» 5. Fixed Asset

«<< Business Process >>» 5.1 Fixed Asset Register

4. IMPLEMENTASI Berikut adalah pembahasan mengenai implementasi aplikasi yang penulis bangun.

«<< Business Service>>» 5.1.1 ProvidingFixedAssetAdditional

5.1.1.1 ProvideFixedAssetAdditionalData

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.

5.1.1.2 Cr eateFAAdditionalTransaction 5.1.1.3 ProvideUpdateFAAdditonalStatus

Component Diagram::Fixed Asset Register

Gambar 1 Mapping Domain Fungsi Account Payable

•

•

menghasilkan

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

5

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.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.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 : class dataaccess T CrudManagerDAO + + + + + +

create(Object) : boolean retrieve(Object) : List retrieveCount(Object) : int retrieveDataByID(Object, String, long) : T update(Object) : boolean delete(Object) : boolean

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.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 masingmasing per sub proses bisnisnya. Berikut adalah fitur-fitur dari aplikasi Account Receivable :

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

«<>» + APAdjustmentASL() : void

Gambar 3 Class Diagram APAdjustmentASL

6

•

•

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.

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.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/AP2CASAService1/casaPort1?wsdl.

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 CreatePurchaseDownPaymentInvoiceTransaction(Date, String, String, BigDecimal, BigDecimal, String, String, String, String) : String GetPurchaseDPInvoiceByStatus(String, String) : APPurchaseDPInvoiceDTO[] GetPurchaseDPInvoiceByStatusAndNumber(String, String, String) : APPurchaseDPInvoiceDTO[] RetrieveAllPurchaseDPInvoiceDTOData(String, String) : APPurchaseDPInvoiceDTO[] UpdateAPStatusForPurchaseDP(String, String, String) : Boolean

Gambar 4 Class Diagram APPurchaseDPInvoiceWS

7

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.

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/FAAccCASAService1/casaPort1?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/AR2CASAService1/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/ARAccumulationCASAService1/casaPort 1?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. 1.

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

Test Case Name Nilai Receiving Number benar

Test Case

Expected Result

Status

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.

8

Tabel 2 Uji Coba Halaman UI-ARI.dp-invoice-entry No. 1.

Test Case Name Nilai Sales Order Number benar

Test Case Sales Order = “so.270620 11.002”

Expected Result Success get sales order data from sales service

branch ID = “SBY”

Status OK

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

Berikut adalah uji coba salah satu fitur pada aplikasi Fixed Asset yang ditunjukkan pada tabel 3.

1.

Test Case Name Nilai “Receiving Number” benar

Test Case Receiving Number = “RC.000009”

Expected Result Success get recceiving data from inventory service

Test Case

Expected Result

Status

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 3 Uji Coba Halaman UI-FAR.additionalEntry No.

Test Case Name Test get Sales DP data

Status

Tabel 6 Uji Coba Web Service ProvideFixedAssetAdditionalData

OK No. 1.

Test Case Name Test ambil additional data FA berdasark an ID FA.

Test Case

Expected Result

Status

ID FA = “81”, branch ID = “SBY”

“FAAD.030 711.00001”

OK

5.2 Uji Coba Web Service Berikut adalah uji coba salah satu web service pada aplikasi Account Payable yang ditunjukkan pada tabel 4.

5.3 Uji Coba Orkestrasi Berikut adalah uji coba salah satu orkestrasi pada aplikasi Account Payable yang ditunjukkan pada tabel 7.

Tabel 4 Uji Coba Web Service ProvidePurchaseDownPaymentInvoiceData

Tabel 7 Uji Coba Orkestrasi create invoice without manager approval

No. 1.

Test Case Name DP invoice number benar

Test Case DP invoice number = “APDP.0307 11.00001”,

Expected Result “APDP.03 0711.0000 1”

Test Case Name Expected Result

Status OK

9

Test create invoice without manager approval <SOAP-ENV:Envelope xmlns:SOAPENV="http://schemas.xmlsoap.org/soap/envelo

pe/"

Name Expected Result

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

approval <SOAP-ENV:Envelope xmlns:SOAPENV="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> true

Status

Berikut adalah uji coba salah satu orkestrasi pada aplikasi Account Receivable yang ditunjukkan pada tabel 8.

Status

Tabel 8 Uji Coba Orkestrasi create invoice without manager approval. Test Case Name Expected Result

Test create invoice without manager approval

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

<SOAP-ENV:Envelope xmlns:SOAPENV="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> true

Status

Berikut adalah uji coba salah satu orkestrasi pada aplikasi Fixed Asset yang ditunjukkan pada tabel 9.

7. DAFTAR PUSTAKA

Tabel 9 Uji Coba Orkestrasi create invoice without manager approval Test Case

[1] Arinta, R. (2011). CV-LV-PV. Surabaya, Indonesia.

Test create invoice without manager

10

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

11