BAB 2 LANDASAN TEORI
2.1
Teori-teori Umum 2.1.1
Sistem Informasi 2.1.1.1 Pengertian Sistem Informasi Satzinger, Jackson, dan Burd (2005:7) mendefinisikan sistem informasi sebagai sekumpulan komponen yang saling berkaitan yang mengumpulkan, memproses, menyimpan, dan menyediakan hasil informasi yang dibutuhkan untuk menyelesaikan tugas-tugas bisnis tertentu. O’Brien (2005:6) mendefinisikan sistem informasi sebagai suatu kombinasi yang terorganisasi dari manusia, perangkat keras, perangkat lunak, jaringan komunikasi, dan sumber daya data yang mengumpulkan, mengubah, dan menyebarluaskan informasi di dalam suatu perusahaan. Stair dan Reynolds (2006:4) mendefinisikan sistem informasi sebagai sekumpulan komponen yang saling berkaitan yang berfungsi untuk mengumpulkan, memanipulasi, menyimpan, menyebarluaskan data dan informasi yang diperlukan serta menyediakan mekanisme umpan balik untuk mencapai suatu tujuan tertentu. 2.1.1.2 Komponen Sistem Informasi Satzinger, Jackson, dan Burd (2005:8) menyatakan bahwa komponen sistem informasi dapat digambarkan sebagai berikut:
Gambar 2.1 Komponen Sistem Informasi (Satzinger, Jackson, dan Burd) 6
7 O’Brien (2005:22) menyatakan bahwa suatu sistem informasi yang dinamis akan memiliki tiga komponen dasar yang saling berinteraksi, yaitu sebagai berikut: a. Input Melibatkan pengambilan elemen yang memasuki suatu sistem untuk kemudan diproses menjadi informasi. b. Processing Melibatkan proses yang mengubah input menjadi output. c. Output Melibatkan pengalihan elemen yang diproduksi oleh proses perubahan kepada tujuan akhirnya. 2.1.2 Perangkat Lunak 2.1.2.1 Pengertian Perangkat Lunak Pressman (2005:36) mendefinisikan perangkat lunak sebagai: a. Instruksi (program komputer) yang ketika dijalankan menyediakan fitur, fungsi, dan kinerja yang diinginkan. b. Struktur
data
yang
memungkinkan
suatu
program
untuk
memanipulasi informasi. c. Dokumen yang menggambarkan operasi dan kegunaan dari suatu program. 2.1.2.2 Karakteristik Perangkat Lunak Pressman (2005:37) menyatakan bahwa perangkat lunak memiliki karakteristik yang berbeda dari perangkat keras, yaitu sebagai berikut: a. Perangkat lunak dikembangkan atau direkayasa, bukan diproduksi dalam pengertian klasik Walaupun terdapat beberapa persamaan di dalam pengembangan perangkat lunak dan perangkat keras, namun kedua aktivitas ini pada dasarnya sangat amat berbeda. Dari kedua aktivitas tersebut, kualitas yang tinggi dicapai melalui desain yang baik, namun fase manufaktur untuk perangkat keras dapat menjelaskan masalah kualitas yang tidak terdapat pada perangkat lunak. Kedua aktivitas tersebut
membutuhkan
konstruksi
produk,
namun
dengan
pendekatan yang berbeda. Biaya perangkat lunak terpusat pada
8 bidang perekayasaan. Jadi kesimpulannya, proyek perangkat lunak tidak dapat dikelola seperti proyek pemanufakturan. b. Perangkat lunak tidak usang atau habis terpakai Tingkat kegagalan perangkat keras yang tinggi biasanya disebabkan oleh kesalahan perancangan atau kesalahan pembuatan di pabrik. Setelah diperbaiki, biasanya tingkat kegagalan akan menurun hingga ke suatu tingkat yang stabil untuk periode waktu tertentu. Seiring dengan berjalannya waktu, tingkat kegagalan akan meningkat kembali akibat pengaruh lingkungan terhadap komponen perangkat keras. Dengan kata lain, perangkat keras menjadi usang. Sedangkan pada perangkat lunak, tingkat kegagalan yang tinggi biasanya disebabkan oleh keadaan yang tidak diperkirakan sebelumnya. Setelah diperbaiki, tingkat kegagalan tersebut akan menurun hingga ke suatu tingkat yang stabil. Jadi kesimpulannya, perangkat lunak tidak akan pernah usang atau habis terpakai. c. Meskipun industri bergerak menuju konstruksi berbasis komponen (component-based construction), sebagian besar perangkat lunak masih dibangun seperti biasa (custom built) Komponen
perangkat
lunak
seharusnya
dirancang
dan
diimplementasikan sehingga dapat digunakan berulang-ulang pada beberapa program yang berbeda. Komponen yang dapat digunakan berulang-ulang membungkus data dan proses yang diaplikasikan kepada data, memungkinkan perekayasa perangkat lunak untuk menciptakan aplikasi baru dari bagian yang dapat digunakan berulang-ulang. 2.1.2.3 Proses Perangkat Lunak Sommerville (2011:9) menyatakan bahwa proses di dalam suatu perangkat lunak ada empat, yaitu sebagai berikut: a. Software specification Di mana pelanggan dan perekayasa mendefinisikan perangkat lunak yang akan dikembangkan dan batasan-batasan pada operasinya. b. Software development Di mana perangkat lunak dirancang dan diprogram.
9 c. Software validation Di mana perangkat lunak dicek untuk memastikan bahwa perangkat lunak tersebut adalah apa yang dibutuhkan oleh pelanggan. d. Software evolution Di mana perangkat lunak dimodifikasi untuk memenuhi perubahan kebutuhan dari pelanggan dan kebutuhan pasar. 2.1.2.4 Rekayasa Perangkat Lunak Bauer,
di
dalam
buku
karangan
Pressman
(2005:53)
mendefinisikan rekayasa perangkat lunak sebagai pembentukan dan penggunaan prinsip-prinsip rekayasa suara untuk menghasilkan perangkat lunak yang ekonomis yang handal dan bekerja secara efisien pada mesin nyata. IEEE (Institute of Electrical and Electronics Engineers), di dalam buku karangan Pressman (2005:53) mendefinisikan rekayasa perangkat lunak sebagai suatu penerapan pendekatan sistematis, disiplin, dan dapat diukur untuk pengembangan, operasi, dan pemeliharaan perangkat lunak, yaitu penerapan rekayasa perangkat lunak. Sommerville (2011:24) mendefinisikan rekayasa perangkat lunak sebagai disiplin rekayasa yang berkaitan dengan segala aspek dari produksi perangkat lunak. 2.1.3 Interaksi Manusia dan Komputer 2.1.3.1 Pengertian Interaksi Manusia dan Komputer Shneiderman dan Plaisant (2010:22) menyatakan bahwa interaksi manusia dan komputer berkaitan dengan tampilan interface yang digunakan oleh pengguna untuk berkomunikasi dan berinteraksi dengan komputer. Interaksi manusia dan komputer merupakan disiplin ilmu yang berhubungan dengan perancangan, evaluasi, dan implementasi sistem komputer interaktif yang diinginkan manusia. Kepentingan pengguna harus diperhatikan di dalam membuat aplikasi komputer. Maka diharapkan aplikasi yang dihasilkan harus seinteraktif mungkin dan dapat digunakan dengan mudah oleh para pengguna.
10 2.1.3.2 Prinsip Perancangan Antarmuka Shneiderman dan Plaisant (2010:74) menyatakan bahwa prinsip perancangan antarmuka mengacu kepada delapan aturan emas atau eight golden rules, yaitu sebagai berikut: a. Usahakan untuk konsisten Perancangan menu, warna, tampilan, jenis huruf pada antarmuka harus dilakukan dengan konsisten. b. Memenuhi kegunaan universal Pengguna
antarmuka
sangat
beragam,
sehingga
di
dalam
merancang layar harus mempertimbangkan perbedaan di dalam hal usia, hambatan fisik, dan variasi teknologi. Jadi, ada pemberian petunjuk kepada pengguna pemula dan shortcut bagi pengguna yang telah berpengalaman. c. Memberikan umpan balik yang informatif Untuk setiap aksi yang dilakukan oleh pengguna, harus diberikan umpan balik agar tercipta suasana yang komunikatif. Pada aksi yang bersifat kecil dan sering digunakan, respon yang diberikan sederhana. Namun, pada aksi yang bersifat rumit dan jarang digunakan, respon yang diberikan harus lebih rinci. d. Merancang dialog untuk menghasilkan penutupan Di dalam merancang komunikasi arus balik dengan pengguna, urutan tindakan harus diatur sedemikian rupa dengan mengetahui keadaan awal, tengah, dan tentu saja akhir. e. Mencegah terjadinya kesalahan Sebisa mungkin, suatu sistem dirancang untuk dapat mencegah pengguna dari kesalahan fatal yang dapat terjadi. Sebagai contoh, terdapat validasi pada formulir. Apabila pengguna melakukan kesalahan, maka sistem harus menyediakan instruksi kepada pengguna tentang bagaimana cara memperbaiki kesalahan tersebut. f. Memungkinkan pembalikan aksi yang mudah Ketika pengguna tidak sengaja melakukan aksi yang tidak diinginkan dan ingin melakukan pembatalan, sistem harus menyediakan fungsi pembatalan agar pengguna merasa nyaman dan tidak takut di dalam mengeksplorasi sistem.
11 g. Mendukung pusat kendali internal Pengguna memiliki kekuasaan atas suatu sistem sehingga dapat mengontrol program-program yang ada di dalam sistem tersebut. h. Mengurangi beban ingatan jangka pendek Tampilan harus dibuat sesederhana mungkin sehingga pengguna tidak perlu banyak mengingat. Tampilan dari setiap halaman harus diperkuat dan frekuensi perpindahan jendela harus diminimalisasi. 2.1.4 Basis Data 2.1.4.1 Pengertian Basis Data Connoly dan Begg (2010:65) mendefinisikan basis data sebagai sekumpulan data yang berhubungan secara logikal serta dirancang untuk memenuhi kebutuhan informasi yang dibutuhkan suatu organisasi. Williams dan Sawyer (2010:164) mendefinisikan basis data sebagai koleksi data yang disimpan secara elektronik dalam sistem komputer. 2.1.4.2 Database Management System Connoly dan Begg (2010:68) menyatakan bahwa terdapat beberapa komponen Database Management System, yaitu sebagai berikut: a. Hardware (perangkat keras) DBMS
membutuhkan
perangkat
keras
untuk
menjalankan
aplikasinya. Perangkat keras tersebut dapat meliputi suatu PC, mainframe atau jaringan komputer. b. Software (perangkat lunak) Komponen perangkat lunak itu sendiri berupa program aplikasi atau OS (Operating System). c. Data Data merupakan komponen yang penting dalam DBMS dan berasal dari sudut pandang pengguna. Data berperan sebagai penghubung antara pengguna dan mesin. d. Prosedur Prosedur
merupakan
penggunaan basis data.
instruksi
yang
mengatur
perencanaan
12 e. Sumber Daya Manusia Komponen terakhir merupakan manusia yang berhubungan dengan sistem, cakupannya adalah sebagai berikut: 1. Data Administration Mengatur sumber daya data, meliputi perencanaan basis data, pengembangan dan pemeliharaan standar dan desain basis data secara logikal dan konseptual. 2. Database Administration Mengatur realisasi fisik dari aplikasi basis data yang meliputi desain fisik dan implementasi, keamanan dan pengawasan performa sistem dan pengaturan ulang basis data. 3. Database Designer Database Designer logikal mengidentifikasi data berupa entitas dan atribut, relasi antar data dan batasan data yang disimpan, sedangkan Database Designer fisikal yang menentukan bagaimana desain logikal akan diimplementasikan. 4. Application Developer Mengembangkan
program
aplikasi
yang
menyediakan
kebutuhan pengguna akhir. 5. End-User (pengguna akhir) Pengguna akhir dapat digolongkan menjadi dua bagian, yaitu sebagai berikut: a. Naive Users, merupakan pengguna yang tidak perlu tahu mengenai Database Management Lifecycle. b. Sophisticated Users, merupakan pengguna yang perlu tahu mengenai Database Management Lifecycle. Pada umumnya, Database Management System memiliki fasilitas sebagai berikut: a. Fasilitas untuk mendefinisikan basis data dengan menggunakan sebuah Data Definition Language (DDL). DDL mengizinkan pengguna untuk menentukan tipe, struktur dan batasan yang dapat disimpan ke dalam basis data tersebut. b. Fasilitas yang dapat membantu pengguna menambah, mengubah, menghapus dan mengambil kembali data dari basis data yang umumnya menggunakan Data Manipulation Language (DML).
13 Selain itu ada fasilitas yang melayani akses data yang dinamakan query language. c. Fasilitas untuk mengontrol basis data dengan menggunakan Data Control Languange (DCL). Akses yang dilingkupi oleh fasilitas ini ada beberapa, yaitu sebagai berikut: 1. Sistem keamanan yang mencegah pengguna yang tidak memiliki wewenang untuk mengakses data. 2. Sistem yang memelihara konsistensi suatu data. 3. Sistem yang membagi akses ke dalam suatu basis data. 4. Sistem kontrol pengembalian data yang dapat mengembalikan data kepada kondisi sebelumnya jika terjadi kegagalan perangkat. 5. Deskripsi data yang ada dalam basis data. Connoly dan Begg (2010:77) menyatakan bahwa terdapat beberapa keuntungan dari penggunaan DBMS, yaitu sebagai berikut: a. Kontrol terhadap redundansi data Basis
data
berusaha
menghilangkan
pengulangan
dengan
melakukan integrasi file sehingga berbagai copy dari data yang sama tidak tersimpan. b. Konsistensi data Dengan
adanya
pengendalian
data
dengan
menghilangkan
redundansi, data yang tidak konsisten data dapat dihindari. Jika data yang terdapat di dalam sistem hanya disimpan dalam satu tempat, maka update cukup dilakukan sekali dan nilai baru akan tersedia bagi semua pengguna. c. Banyaknya informasi dari data yang sama Dengan terintegrasinya data yang terdapat dalam sistem maka memungkinkan organisasi mendapatkan informasi tambahan yang lebih berkualitas. d. Pengaksesan data oleh beberapa user dalam waktu yang sama Keuntungan ini memungkinkan setiap pengguna mendapatkan data dari sumber yang sama berdasarkan otoritas yang mereka miliki.
14 e. Meningkatkan integritas data Integritas mengacu pada validitas dan konsistensi data yang tersimpan. Integritas biasanya didefinisikan sebagai batasan yang tidak boleh dilanggar oleh sistem basis data. f. Meningkatkan keamanan Keamanan basis data melindungi basis data penggunaan oleh pihak yang tidak berotoritas. Hal ini dapat dilakukan dengan pemanfaatan sistem username dan password dalam menggunakan sistem. Akses yang dilingkupi antara lain retrieval, insert, update dan delete data. g. Menetapkan standarisasi dalam penyajian data Integrasi ini didefinisikan dalam pembuatan standar yang diperlukan dalam suatu organisasi. Hal ini berguna untuk memfasilitasi pertukaran data antara sistem, ketetapan penamaan, standar dokumentasi, dan prosedur pengaturan hak akses. h. Mengurangi biaya Biaya pengembangan dan pemeliharaan sistem yang baru diharapkan akan menghasilkan total biaya yang lebih rendah. i. Menyeimbangkan konflik dari kebutuhan yang ada Setiap pengguna mempunyai kebutuhan yang berbeda-beda dengan adanya sistem basis data akan menyediakan penggunaan terbaik dari sumber daya bagi keseluruhan organisasi. j. Meningkatkan aksesibilitas, produktifitas penggunanya DBMS dapat meningkatkan aksesibilitas dan produktivitas para penggunanya. k. Backup dan recovery DBMS memiliki kemampuan dalam pengelolaan data dengan beberapa fasilitas backup dan recovery. Connoly dan Begg (2010:77) menyatakan bahwa terdapat beberapa kerugian dari penggunaan DBMS, yaitu sebagai berikut: a. Kompleksitas Dalam menjaga reliabilitas data yang terdapat dalam suatu sistem, maka
seringkali
replikasi
DBMS
digunakan.
Dengan
dijalankannnya prosedur ini maka menimbulkan berbagai macam masalah yang kompleks dimana Database Administrator (DBA) harus dapat menyediakan pengaksesan data yang lebih cepat,
15 handal dan up-to-date. Jika aplikasi dalam DBMS tidak dapat menangani hal tersebut selanjutnya akan terjadi penurunan kinerja dari DBMS. b. Ukuran Dengan kompleksitas yang ada, DBMS menjadi perangkat lunak yang sangat besar sehingga memerlukan banyak ruang hard disk dan jumlah memory yang besar untuk dapat berjalan dengan baik. c. Biaya Biaya dari pembelian DBMS yang tidak murah serta terdapat pemeliharaan tahunan membuat biaya dari DBMS menjadikan total keseluruhannya tidak sedikit. d. Tambahan biaya perangkat keras Kebutuhan
tempat
penyimpanan
bagi
DBMS
memerlukan
pembelian tempat penyimpanan tambahan. Kemudian untuk mencapai hasil yang diinginkan diperlukan lagi tambahan biaya yang lebih besar. e. Biaya dari proses konversi Selain kedua biaya di atas, DBMS juga memerlukan biaya dari proses konversi yang jumlahnya juga tidak sedikit. 2.1.4.3 Fact Finding Techniques Connoly dan Begg (2010:341) mendefinisikan fact finding techniques sebagai suatu proses formal yang menggunakan wawancara dan menyebarkan kuesioner untuk mengumpulkan fakta tentang sistem, kebutuhan dan preferensi pengguna. Terdapat beberapa teknik yang umum digunakan, yaitu sebagai berikut: a. Examining Documentation Dapat berguna saat mencoba mendapatkan keuntungan dari beberapa informasi latar belakang kemunculan basis data. b. Interviewing Teknik wawancara merupakan yang paling umum dalam tahapan pencarian fakta. c. Observing the Enterprise in Operation Merupakan
teknik
memahami
sistem
yang
memungkinkan
partisipan melihat pengguna dalam menjalankan sistem berjalan.
16 d. Research Merupakan teknik melakukan penelitian terhadap suatu masalah dalam suatu sistem. e. Questionnaire Merupakan teknik penemuan fakta dengan menyebarkan kuesioner. 2.1.4.4 Database System Development Lifecycle Connoly dan Begg (2010:314) menyatakan bahwa aktivitas utama yang ada di setiap langkah dalam Database System Development Lifecycle adalah sebagai berikut: a. Database Planning Perencanaan basis data merupakan aktifitas merencanakan siklus hidup aplikasi basis data untuk dapat diwujudkan secara efisien dan efektif. Tiga hal utama yang tekait dengan proses ini adalah sebagai berikut: 1. Mengidentifikasi rencana dari sistem yang akan dibangun. 2. Evaluasi sistem yang ada untuk menetapkan kelebihan dan kekurangan sistem. 3. Penaksiran kesempatan IT yang dapat memberikan keuntungan kompetitif. Langkah penting di dalam perencanaan basis data adalah sebagai berikut: 1. Menentukan mission statement Mission statement merupakan tujuan utama dari sistem basis data. Mission statement membantu menjelaskan tujuan dari project dan memberikan arah yang jelas untuk mendapatkan hasil yang efektif dan efisien dari system basis data yang akan dibangun. 2. Menentukan mission objectives Setiap mission objective menjelaskan tugas khusus yang harus didukung oleh basis data berdasarkan apa yang telah dijabarkan darimission statement. Sehingga basis data yang telah memenuhi mission
objective
memenuhi mission statement.
besar kemungkinan
sudah
17 b. System Definition Spesifikasi dari lingkup dari sistem basis data meliputi major user view, user dan area aplikasi. User view menentukan data apa saja yang boleh diakses oleh pengguna dan memastikan setiap pengguna terlibat dalam perancangan sistem basis data. c. Requirement Collection and Analysis Analisa yang harus dipenuhi untuk kebutuhan sistem basis data yang baru. Data yang dikumpulkan dapat berupa: 1. Deskripsi mengenai data. 2. Penjelasan mengenai bagaimana cara data dihasilkan. 3. Kebutuhan tambahan untuk sistem basis data yang akan dibangun. d. Database Design Tahap ini merupakan proses merancang basis data yang diinginkan. Ada dua pendekatan dalam perancangan basis data, yaitu sebagai berikut: 1. Bottom Up Approach Pendekatan ini dimulai dari tingkat atribut yang melalui analisis dan penggabungan untuk kemudian dikelompokkan ke dalam relasi yang menggambarkan tipe antar entitas. Pendekatan ini digunakan jika basis data yang ada sederhana dan dengan jumlah yang sedikit. 2. Top Down Approach Pendekatan ini dimulai dari pengembangan model data yang terdiri
dari
beberapa
hubungan
relasional
dan
entitas.
Pendekatan ini biasa digunakan jika basis data yang digunakan rumit dengan jumlah atribut yang cukup banyak. Adapun perancangan basis data dapat dibagi menjadi tiga tahapan utama, yaitu sebagai berikut: 1. Conceptual Database Design Proses pembangunan suatu model data yang terlepas dari pertimbangan fisik, hanya menekankan terhadap konsep.
18 2. Logical Database Design Proses pembangunan model data dari informasi yang diperoleh berdasarkan penelitian tertentu tapi bebas dari hal teknikal ataupun yang berkaitan dengan DBMS. 3. Physical Database Design Proses pembangunan deskripsi implementasi basis data pada secondary storage, yang menggambarkan struktur penyimpanan dan metode akses data secara cepat. Connoly dan Begg (2010:92) mendefinisikan Data Definition Languange sebagai suatu bahasa yang mengizinkan pengguna dalam menjelaskan serta memberi nama entitas, atribut dan relasi yang dibutuhkan beserta kesatuan integritas dan keamanan. Connoly dan Begg (2010:40) menyatakan bahwa ada beberapa jenis syntax yang digunakan dalam perancangan hingga pengelolaan basis data, yaitu sebagai berikut: 1. Data Definition Languange (DDL) Merupakan bahasa yang digunakan oleh administrator basis data dalam menjelaskan dan memberi nama suatu entitas, atribut dan relasi data yang dibutuhkan aplikasi bersamaan dengan penerapan integritas data. 2. Data Manipulation Languange (DML) Merupakan bahasa yang digunakan untuk pengelolaan basis data seperti hal menampilkan (select), menambah (insert), mengubah data (update), menghapus data (delete). e. DBMS Selection Proses pemilihan DBMS yang tepat untuk mendukung sistem basis data. Pemilihan DBMS yang baik berguna dalam memenuhi kebutuhan organisasi di masa mendatang dan menyeimbangkan pengeluaran yang terjadi karena pembelian produk DBMS. Connoly dan Begg (2010:325) menyatakan bahwa tahap-tahap dalam pemilihan DBMS adalah sebagai berikut: 1. Menentukan kerangka acuan penelitian. 2. Membatasi hanya 2 sampai 3 pilihan saja. 3. Mengevaluasi produk. 4. Merekomendasikan hasil evaluasi.
19 f. Application Design Connoly dan Begg (2010:329) mendefinisikan perancangan aplikasi sebagai suatu aktivitas merancang antarmuka dan program aplikasi yang akan menggunakan dan memproses basis data. Dalam merancang basis data pastikan bahwa fungsionalitas yang diutarakan dalam rancangan memenuhi kebutuhan pengguna. g. Prototyping Connoly dan Begg (2010:329) mendefinisikan prototyping sebagai suatu aktivitas membangun sebuah model kerja dari aplikasi basis data yang mengizinkan pengguna untuk visualisasi dan evaluasi gambaran sistem secara menyeluruh. Ada dua strategi dalam merancang prototype, yaitu sebagai berikut: 1. Requirements Prototyping Menggunakan sebuah prototype untuk menentukan kebutuhan sistem basis data yang diusulkan dan begitu sudah terpenuhi prototype tidak digunakan lagi. 2. Evolutionary Prototyping Menggunankan sebuah prototype untuk tujuan yang sama. Begitu kebutuhan pengguna sudah terpenuhi, prototype tidak dibuang melainkan dikembangkan menjadi aplikasi basis data yang akan berjalan. Beberapa tujuan pembuatan prototype adalah sebagai berikut: 1. Mengidentifikasi fitur yang ada dalam sistem yang berjalan. 2. Melakukan perbaikan terhadap fitur yang ditemukan. 3. Mengelompokkan kebutuhan pengguna. 4. Mengevaluasi kemungkina yang terjadi dari rancangan sistem khusus. h. Implementation Tahap ini berfungsi dalam membuat definisi physical database dan program aplikasi. Implementasi basis data dapat dicapai dengan menggunakan: 1. DDL untuk membuat skema basis data dan file basis data kosong. 2. DDL untuk membuat sudut pandang pengguna yang diinginkan.
20 3. 3GL dan 4GL untuk membuat program aplikasi basis data dan disertakan dengan menggunakan DML. i. Data Conversion and Loading Tahap ini bertujuan dalam pemuatan data ke dalam sistem yang baru sehingga memungkinkan penggabungan antara aplikasi yang berjalan dengan basis data yang baru. DBMS memiliki utilitas untuk memanggil file yang ada ke dalam basis data baru untuk digunakan dalam aplikasi. j. Testing Tahap ini menjalankan uji coba terhadap sistem basis data apabila ada error dan memvalidasi terhadap spesifikasi kebutuhan pengguna. k. Operational Maintenance Tahap ini berfungsi melakukan pengelolaan terhadap sistem basis data yang sudah dijalankan. Tahapan pemeliharaan ini adalah sebagai berikut: 1. Pengawasan kinerja sistem dan pengaturan ulang basis data akan dilakukan jika penurunan kinerja. 2. Jika diperlukan, pembaharuan sistem basis data. 2.1.4.5 Perancangan Basis Data Connoly dan Begg (2010:320) mendefinisikan perancangan basis data sebagai proses pembuatan desain yang membantu menjelaskan persyaratan misi dari perusahaan dan tujuan dari kebutuhan sistem basis data. Tahapan perancangan basis data ada tiga, yaitu sebagai berikut: a. Tahapan konseptual Merupakan proses pembangunan model dari data yang digunakan dalam perusahaan dan tidak tergantung dengan pertimbangan basis data secara fisikal. b. Tahapan logikal Merupakan proses pembangunan model informasi berdasarkan model data tertentu dan tidak tergantung pada Database Management System dan pertimbangan fisik lainnya.
21 c. Tahapan fisikal Tahapan perancangan basis data fisikal merupakan suatu proses pembuatan deskripsi tentang implementasi basis data pada secondary storage, menggambarkan basis relasi, organisasi file dan indeks yang digunakan untuk mencapai akses data yang efisien serta integritas terkait dengan pengukuran keamanan. 2.1.4.6 Konsep Dasar Model ER Connoly dan Begg (2010:371) mendefinisikan ER Modelling sebagai pendekatan dalam merancang basis data yang dimulai dengan mengidentifikasi data penting menjadi entitas hingga relationship antar data harus dipresentasikan dalam model. Beberapa konsep dasar dalam ER modeling antara lain attribute, keys, structural constraints, relationship type. a. Entity (Entitas) Entitas merupakan objek-objek yang memilik property yang sama dan diidentifikasi karena keberadaannya yang bebas (independence existence). Connoly dan Begg (2010:383) menyatakan bahwa terdapat dua jenis entitas, yaitu sebagai berikut: 1. Strong Entity Types Entitas yang keberadaannya tidak bergantung pada entitas lainnya. Karakter dari strong entity type merupakan setiap entitas memiliki atribut primary key yang sudah teridentifikasi. 2. Weak Entity Types Entitas yang keberadaannya bergantung pada entitas lainnya. Karakteristik dari weak entity merupakan entitas yang tidak dapat diidentifikasikan dengan menggunakan atribut yang terkait dengan entitasnya sendiri. b. Relationship Types Connoly dan Begg (2010:374) mendefinisikan relationship types sebagai hubungan antar entitas dan memiliki arti tertentu. Sedangkan relationship occurrence merupakan suatu gabungan yang dapat diidentifikasikan secara unik berupa kejadi dari entitas yang terkait.
22 Derajat dari tipe relasi merupakan jumlah jenis entitas yang terkait dalam suatu hubungan. Entitas yang terkait dalam hubungan tersebut dinamakan participant, sedangkan jumlah peserta dalam suatu jenis relasi disebut derajat relasi. Derajat dan tipe relasi ada beberapa, yaitu sebagai berikut: 1. Binary Relationship Merupakan hubungan antar dua entitas.
Gambar 2.2 Contoh Binary Relationship 2. Ternary Relationship Merupakan hubungan antar tiga entitas.
G ambar 2.3 Contoh Ternary Relationship 3. Quarternary Relationship merupakan hubungan antar empat
entitas.
23 Gambar 2.4 Contoh Quarternary Relationship 4. Unary Relationship Merupakan hubungan antar satu tipe entitas dimana tipe entitas ikut serta lebih dari satu kali dengan peranan yang berbeda, atau disebut juga recursive relationship.
Gambar 2.5 Contoh Unary Relationship c. Attributes Connoly dan Begg (2010:350) mendefinisikan atribut sebagai property dari sebuah entitas atau tipe relasi. Attribut domain merupakan kumpulan nilai yang diperbolehkan bagi satu atau lebih atribut. Connoly dan Begg (2010:351) menyatakan bahwa ada beberapa jenis atribut, yaitu sebagai berikut: 1. Simple and composite attribute Simple attribute adalah atribut yang terdiri dari satu komponen tunggal dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi. Sementara composite attribute adalah atribut yang terdiri dari komponen yang memiliki keberadaan yang independent. 2. Single and multi valued attribute Single-valued attribute adalah atribut yang mempunyai nilai tunggal untuk suatu peristiwa. Sedangkan multi-valued attribute mempunyai beberapa nilai untuk suatu kejadian. 3. Derived attribute Derived attribute merupakan atribut yang memiliki nilai yang dihasilkan dari atribut lainnya dan dapat berasal dari banyak entitas. 4. Keys
24 Connoly dan Begg (2010:352) menyatakan bahwa ada lima jenis keys, yaitu sebagai berikut: a. Candidate Key Merupakan
jumlah
minimal
atribut
yang
unik
mengidentifikasikan kejadian dari tipe entitas. b. Primary Key Merupakan
candidate
key
yang
dipilih
untuk
mengidentifikasikan kejadian secara unik. c. Composite Key Merupakan candidate key yang terdiri dari dua atau lebih atribut. d. Alternate Key Merupakan candidate key yang tidak dipilih menjadi primary key, biasa disebut secondary key. e. Foreign Key Merupakan primary key pada entitas yang digunakan entitas lainnya Structural Constraints. Connoly dan Begg (2010:356) menyatakan bahwa constraint seharusnya menggambarkan batasan dari relasi tanggapan dalam keadaan sebenarnya. Tipe utama dari constraint disebut dengan multiplicity. Multiplicity merupakan jumlah kejadian yang mungkin terjadi pada entitas yang berhubungan dengan sebuah kejadian dari tipe entitas yang tergabung dalam relationship. Multiplicity biasanya terdiri dari dua batasan terpisah, yaitu sebagai berikut: 1. Cardinality Menjelaskan jumlah maksimum dari kejadian yang mungkin terjadi antar entitas yang terikat dalam relasi tersebut. 2. Participation Menetapakan jumlah entitas yang berhubungan dalam suatu relasi. Relasi yang umum merupakan binary relationship, yaitu sebagai berikut: a. One to One (1:1) b. One to Many (1:*)
25 c. Many to Many (*:*)
2.2
Teori-teori Khusus 2.2.1 Enterprise Resource Planning Wijaya dan Darudiato (2009:27) mendefinisikan Enterprise Resource Planning (ERP) sebagai konsep untuk merencanakan dan mengelola sumber daya perusahaan, yaitu berupa paket aplikasi program terintegrasi dan multi modul yang dirancang untuk melayani dan mendukung berbagai fungsi dalam perusahaan, sehingga pekerjaan menjadi lebih efisien dan dapat memberikan pelayanan lebih bagi konsumen, yang akhirnya dapat menghasilkan nilai tambah dan memberikan keuntungan maksimal bagi semua pihak yang berkepentingan (stakeholder) atas perusahaan. Wijaya dan Darudiato (2009:26) menyatakan bahwa integrasi dalam konsep sistem ERP berhubungan dengan interpretasi sebagai berikut: a. Menghubungkan antara berbagai aliran proses bisnis. b. Metode dan teknik berkomunikasi. c. Keselarasan dan sinkronisasi operasi bisnis. d. Koordinasi operasi bisnis. Wijaya dan Darudiato (2009:28) menyatakan bahwa konsep dasar ERP dapat diterjemahkan sebagai berikut: a. ERP terdiri atas paket perangkat lunak komersial yang menjamin integrasi yang mulus atas semua aliran infomasi di perusahaan, yang meliputi keuangan, akuntansi, sumber daya manusia, rantai pasok dan informasi konsumen. b. Sistem ERP adalah paket sistem informasi yang dapat dikonfigurasi, yang mengintegrasikan informasi dan proses yang berbasis infomasi di dalam dan melintas area fungsional dalam sebuah organisasi. c. ERP merupakan satu basis data, satu aplikasi dan satu kesatuan antarmuka di seluruh enterprise. 2.2.2 SAP 2.2.2.1 Pengertian SAP SAP (Systems, Applications and Products in Data Processing) adalah suatu perangkat lunak yang dikembangkan untuk mendukung suatu organisasi dalam menjalankan kegiatan operasionalnya secara lebih efisien dan efektif. SAP merupakan perangkat lunak Enterprise
26 Resources Planning (ERP), yaitu suatu alat IT dan manajemen untuk membantu perusahaan merencanakan dan melakukan berbagai aktivitas sehari-hari. 2.2.2.2 Modul-modul SAP SAP (Systems, Applications and Products in Data Processing) terdiri dari sejumlah modul aplikasi yang mempunyai kemampuan mendukung semua transaksi yang perlu dilakukan suatu perusahaan dan tiap aplikasi bekerja secara berkaitan satu dengan yang lainnya. Semua modul aplikasi di SAP dapat bekerja secara terintegrasi dan terhubung yang satu dengan yang lainnya. Modul-modul di dalam SAP adalah sebagai berikut: a. Sales and Distribution (SD) Membantu meningkatkan efisiensi kegiatan operasional yang berkaitan dengan proses pengelolaan customer order (proses sales, shipping dan billing). b. Materials Management (MM) Membantu menjalankan proses pembelian (procurement) dan pengelolaan inventory. c. Production Planning (PP) Membantu proses perencanaan dan kontrol daripada kegiatan produksi (manufacturing) suatu perusahaan. d. Quality Management (QM) Membantu mengecek kualitas proses-proses di keseluruhan rantai logistik. e. Plant Maintenance (PM) Merupakan suatu solusi untuk proses administrasi dan perbaikan sistem secara teknis. f. Human Resources Management (HRM) Mengintegrasikan
proses-proses
HR
mulai
dari
aplikasi
pendaftaran, administrasi pegawai, manajemen waktu, pembiayaan untuk perjalanan, sampai ke proses pembayaran gaji pegawai. g. Financial Accounting (FI) Mencakup standard accounting cash management (treasury), general ledger dan konsolidasi untuk tujuan pelaporan keuangan.
27
h. Controlling (CO) Mencakup cost accounting, mulai dari cost center accounting, cost element accounting, dan analisa profitabilitas. i. Asset Management (AM) Membantu pengelolaan atas keseluruhan fixed assets, meliputi proses
traditional
asset
accounting
dan
technical
assets
management, sampai ke investment controlling. j. Project System (PS) Mengintegrasikan
keseluruhan
proses
perencanaan
proyek,
pengerjaan dan kontrol. 2.2.2.3 Financial Accounting Wijaya dan Darudiato (2009:65) menyatakan bahwa dalam sistem informasi accounting, perlu diperhatikan proses transaksi dan penyusunan laporan keuangan. Pada sistem ERP, untuk penyusunan laporan keuangan dilakukan melalui aplikasi program General Ledger. Sebenarnya aplikasi program ini tidak ada penginputan proses data transaksi, kecuali memorial jurnal. 2.2.2.3.1 General Ledger Accounting 2.2.2.3.1.1 Organizational
Structures
for
Financial
Accounting a. Company Code Company Code merupakan entitas akuntansi yang independen (elemen terkecil di dalam organisasi di mana satu set lengkap dari account dapat dibuat). Sebagai contoh: sebuah perusahaan di dalam suatu kelompok
perusahaan.
Sebuah
company
code
memiliki empat karakter kunci yang unik, yang dapat berupa tulisan maupun angka. General ledger disimpan di tingkat company code dan digunakan untuk membuat balance sheet (laporan neraca saldo) yang legal dan profit-and-loss statement (laporan laba rugi) untuk company code. b. Business Area
28 Business area merupakan bagian bisnis, atau cabang, di mana sebuah kelompok perusahaan beroperasi. Sebagai contohnya, business area menyediakan tingkat evaluasi tambahan untuk bagian pelaporan. Penggunaan business area bersifat optional (boleh digunakan boleh juga tidak). c. Controlling Area Controlling area merupakan elemen organisasi yang paling penting di dalam aplikasi controlling. Controlling
area
digunakan
untuk
internal
accounting (akuntansi di dalam perusahaan). Sebuah controlling area mengidentifikasi suatu struktur organisasi di mana biaya dan pendapatan dapat dikelola
dan
dialokasikan.
merepresentasikan
bagian
Controlling terpisah
dari
area cost
accounting. Lebih dari satu company code dapat di-assign ke satu
atau
lebih
controlling
area.
Hal
ini
memungkinkan pembiayaan lintas company code antara
company
code
yang
telah
di-assign.
Bagaimanapun juga, meng-assign lebih dari satu company code ke controlling area yang sama hanya dimungkinkan apabila semua company code yang diassign menggunakan operating chart of account dan kalender fiskal yang sama. 2.2.2.3.1.2 G/L Master Records a. Chart of Accounts Setiap general ledger diatur berdasarkan sebuah chart of account. Chart of account terdiri dari definisi dari semua G/L account di dalam format yang tersusun. Definisi tersebut terdiri dari account number (nomor akun), account name (nama akun), dan tipe dari G/L account, yaitu apakah akun tersebut merupakan akun tipe P&L (laba rugi) atau akun tipe balance sheet (neraca saldo).
29 Kita dapat mendefinisikan chart of account dengan jumlah yang tak terbatas di dalam sistem SAP. Di dalam sistem baku SAP, terdapat banyak countryspecific chart of account. Untuk setiap company code, kita harus menetapkan satu chart of account untuk general ledger. Chart of account ini di-assign ke company code di bagian konfigurasi dan disebut juga sebagai operating chart of account. Sebuah chart of account dapat digunakan oleh beberapa company code. Hal ini berarti bahwa general ledger dari beberapa company code tersebut memiliki struktur yang sama. b. Settings for Company Codes Sebelum kita dapat menggunakan sebuah akun di dalam company code, kita harus mengelola definisi akun tersebut pada level chart of account. Kita dapat membuat company code-specific setting (pengaturan spesifik untuk company code), di mana hanya berlaku di dalam company code saja. Contoh dari company
code-specific
mendefinisikan
mata
uang
setting di
dalam
adalah akun.
Kebanyakan akun di dalam company code 1000 menggunakan mata uang EUR (Euro), sedangkan company code 3000 menggunakan mata uang USD (Dollar) untuk akun-akunnya. Ketika mata uang akun merupakan mata uang lokal untuk company code, kita dapat melakukan posting ke dalam akun tersebut dengan menggunakan mata uang apa saja.
30
Gambar 2.6 G/L Master Record (Central View) Account group digunakan untuk mengatur dan mengelola G/L account yang berjumlah banyak. Ketika sebuah G/L account baru dibuat, account group harus ditentukan di dalamnya. Akun dengan account group yang sama biasanya memiliki fungsi bisnis yang sama. Account group diassign number range. Melalui number range tersebut, kita dapat mengontrol nomor akun yang mana yang diizinkan untuk account group tertentu. Account group juga mengontrol tampilan dari segmen company code untuk G/L account. Biasanya, account group mengontrol field mana saja yang dibutuhkan untuk pengisian data, field mana saja yang boleh diisi boleh juga tidak, dan field mana saja yang tidak perlu ditampilkan di dalam segmen company code. Reconciliation
account
atau
akun
rekonsiliasi
menghubungkan buku pembantu dengan general ledger (buku besar) pada real time. Hal ini berarti bahwa
posting
ke
buku
pembantu
akan
mengakibatkan posting ke reconciliation account
31 yang berhubungan di dalam general ledger pada waktu yang sama. Buku pembantu, yang dihubungkan ke general ledger
melalui
reconciliation
account,
adalah
accounts payable, accounts receivable, dan asset ledger. Transaction figure mendeskripsikan jumlah posting di dalam suatu akun pada debit atau kredit. Setiap transaction figure untuk debit dan setiap transaction figure untuk kredit selalu disimpan untuk setiap akun di dalam sistem SAP. Laporan keuangan untuk company code dihitung menggunakan transaction figure tersebut. Jika suatu G/L account memiliki tampilan line item yang
ditandai
di
master
record,
kita
dapat
menelusuri dari saldo akun menuju line item dan kemudian ke dokumen. Jika menggunakan business area, transaction figure juga disimpan untuk setiap business area. Jika kita membuat sebuah laporan keuangan untuk business area, transaction figure untuk business area tersebut digunakan untuk menyediakan informasi bagi laporan keuangan. c. Financial Statement Versions General
ledger
disimpan
untuk
menyediakan
informasi yang dibutuhkan bagi pembuatan laporan neraca saldo dan laporan laba rugi. Laporan-laporan tersebut harus memenuhi persyaratan spesifik untuk negara di mana suatu perusahaan berada. Untuk memenuhi kebutuhan tersebut, maka berbagai macam versi laporan keuangan harus dibuat di dalam sistem SAP. Di dalam beberapa versi laporan keuangan tersebut, kita mendefinisikan akun mana yang akan tampil di line item dari laporan keuangan.
32 Banyak versi laporan keuangan dimasukkan ke dalam sistem SAP. Bagaimanapun juga, suatu negara harus melaporkan laporan keuangan mereka ke pihak yang berwenang di negara mereka menggunakan country-specific chart of account dari negara mereka. Agar laporan eksternal dapat berisi nomor akun yang digunakan di negara-negara
tersebut, sebuah country-specific
chart of account dibuat untuk company code yang ada. Country-specific chart of account tersebut harus memenuhi persyaratan dari negara di mana suatu perusahaan berada. Di segmen company code dari master record, setiap G/L account harus di-assign ke sebuah akun dari company
code.
Hal
ini
dilakukan
dengan
menggunakan field alternative account number. d. Group Chart of Accounts Karena tidak semua company code menggunakan operating chart of account yang sama, group chart of account digunakan untuk tujuan konsolidasi. Operating chart of account di-assign ke group chart of account pada bagian konfigurasi. Ketika operating chart of account telah di-assign ke group chart of account, field nomor akun grup (group account number) menjadi dibutuhkan di segmen chart of account dari master record. 2.2.2.3.1.3 Accounting Transactions – Processing in the General Ledger
33
Gambar 2.7 G/L Account Postings Layar pengentrian data dibagi menjadi beberapa area, yaitu sebagai berikut: a. Work templates Di sini, kita dapat memilih variasi layar, account assignment template, atau held document sebagai referensi. Held document merupakan dokumen yang disimpan oleh pengguna tanpa melakukan posting, dengan ide bahwa pengguna akan melengkapi
dan
melakukan
posting
untuk
dokumen tersebut nanti. b. Header data Header
data
berlaku
untuk
keseluruhan
dokumen, seperti tanggal posting dan tipe dokumen. Beberapa header data dapat berupa format tampilan saja, atau tersembunyi dari pengguna melalui pilihan edit. c. Line item information Di sini, line item untuk dokumen dimasukkan. d. Information area Di sini, saldo debit dan kredit ditampilkan dengan menggunakan ikon traffic light.
34
Gambar 2.8 G/L Document Entry Enjoy Screen
Gambar 2.9 G/L Document Entry Complex First Screen
Gambar 2.10 G/L Document Entry Complex Second Screen
35 Document type atau tipe dokumen digunakan untuk membedakan berbagai macam dokumen akuntasi dengan mudah. Setiap dokumen di-assign ke satu tipe dokumen, di mana dimasukkan di dalam document header. Nomor dokumen disediakan oleh document number range yang di-assign ke satu atau lebih tipe dokumen.
Gambar 2.11 Important Standard Document Types Ada beberapa tipe dokumen standar di dalam sistem SAP, yaitu sebagai berikut: a. CI (Customer invoices) b. CC (Customer credit memos) c. CP (Customer payments) d. GLD (G/L account documents) e. VI (Vendor invoices) f. VC (Vendor credit memos) g. VP (Vendor payments) h. VN (Vendor net invoices and credit memos) Untuk posting pada G/L account, tipe dokumen SA paling sering digunakan, meskipun tipe dokumen lain juga dapat digunakan, seperti dokumen accrual atau deferral, dokumen valuasi, dan lain-lain. Setiap line item memiliki satu posting key. Posting key merupakan suatu instrumen yang digunakan untuk kontrol internal dan dimasukkan di dalam
36 layar complex posting untuk memberitahu sistem dua hal, yaitu: a. Tipe
akun
mana
yang
digunakan
untuk
melakukan posting b. Apakah line item tersebut merupakan posting debit atau kredit Di enjoy screen, kita tidak dapat menggunakan posting key. Debit merepresentasikan posting key 40 dan kredit merepresentasikan posting key 50. Posting key tersebut muncul di dalam dokumen dan fungsi kontrol mereka masih tetap relevan.
Gambar 2.12 Standard Posting Keys Di dalam sistem SAP, ada banyak posting key yang baku.
Setiap
posting
key
digunakan
untuk
melakukan posting debit atau kredit ke satu tipe akun. Untuk posting di dalam general ledger, kita hanya membutuhkan dua macam posting key, yaitu: a. 40, untuk item debit b. 50, untuk item kredit Balance display dan line item display disediakan untuk menampilkan data akun. Line item display hanya dimungkinkan untuk G/L account di mana fungsi yang sesuai telah diaktifkan di dalam master record. Balance display merupakan tampilan keseluruhan dari transaction figure yang telah disimpan dari
37 suatu akun. Kita dapat menelusuri dari saldo menuju daftar item yang membentuk saldo. Dari daftar line item pertama, kita dapat menelusuri ke dokumen yang berisi line item tersebut. Dari situ, kita dapat melihat transaksi lengkap dengan memilih document overview.
2.2.2.3.2 Accounts Payable Bodnar dan Hopwood (2004:334) mendefinisikan accounts payable atau hutang usaha sebagai tanggung jawab untuk memenuhi pembayaran kepada vendor. Brigham dan Houston (2006:207) mendefinisikan accounts payable atau hutang usaha sebagai hutang yang muncul akibat penjualan kredit dan dicatat sebagai piutang oleh pihak penjual dan hutang oleh pihak pembeli. 2.2.2.3.2.1 Vendor Master Records Sama seperti G/L account, vendor account juga terdiri dari dua area, yaitu: a. Suatu vendor account didefinisikan untuk semua company code pada tingkat client. General data, seperti nama dan alamat vendor, disimpan di sini. b. Posting tidak dapat dilakukan ke akun untuk company code hingga company code-specific setting (pengaturan spesifik untuk company code) dibuat. Pengaturan ini mengacu kepada company code yang relevan dan termasuk detailnya, seperti kondisi pembayaran yang telah disetujui atau reconciliation account (akun rekonsiliasi).
38
Gambar 2.13 Initial Screen to Display a Vendor Master Record Vendor account dapat dibagi ke dalam beberapa account group sama seperti G/L account, sehingga mereka dapat diatur dan dikelola dengan lebih mudah.
Bagaimanapun
juga,
account
group
mengontrol tampilan layar dari semua area vendor master record, tidak hanya company code data saja. Akun-akun yang ada di dalam suatu account group biasanya memiliki beberapa karakteristik yang sama. Sebagai contoh, kita dapat memiliki satu account group untuk vendor domestik, satu account group untuk vendor luar negeri, satu account group untuk vendor afiliasi, dan satu account group untuk onetime vendor. Number range di-assign ke account group. Number range tersebut biasanya bersifat internal, di mana sistem akan otomatis meng-assign nomor ketika kita menyimpan vendor master record. Bagaimanapun juga, beberapa number range bersifat eksternal. Dengan adanya number range eksternal, kita memasukkan nomor vendor secara manual ketika membuat vendor master record. 2.2.2.3.2.2 Daily
Accounting
Transactions
Payable a. Invoice/Credit Memo Entry
in
Accounts
39 Kita dapat dengan mudah membuat sebuah vendor invoice atau credit memo dengan menggunakan transaksi satu layar. Tipe tagihan yang dimasukkan secara langsung di dalam accounts payable ini merupakan miscellaneous invoice, tanpa referensi ke purchase order. Layar pengentrian accounts payable dibagi menjadi beberapa area, yaitu: a. Work templates Di sini, kita dapat memilih variasi layar, account assignment template, atau held document sebagai referensi. b. Header and vendor data Data untuk header dokumen dan vendor line item dimasukkan di sini.
c. G/L account items G/L line item untuk dokumen dimasukkan di sini. d. Information area Saldo dokumen dan informasi mengenai vendor ditampilkan di sini.
Gambar 2.14 Enjoy Invoice/Credit Memo Entry Transaksi ini juga dapat digunakan untuk membuat dokumen dengan mata uang asing. Jumlah mata
40 uang asing diterjemahkan ke dalam mata uang lokal dengan menggunakan kurs pertukaran mata uang yang telah ditentukan.
Gambar 2.15 Enjoy Vendor Invoice Screen Kita dapat melakukan posting biaya dan pendapatan di dalam controlling sebagai real posting maupun statistical posting: a. Kita dapat menyelesaikan real posting dengan objek controlling lainnya b. Statistical posting hanya digunakan untuk tujuan informasi Objek account assignment sendiri dapat berupa objek real maupun statistical. Sebagai contoh, internal order didefinisikan sebagai objek real atau statistical ketika dibuat. Sebuah real order hanya dapat dijalankan dengan real posting, dan statistical order hanya dapat dijalankan dengan statistical posting.
Namun,
cost
center
merupakan
pengecualian untuk hal ini. Cost center selalu didefinisikan sebagai objek real, namun kita dapat membuat real atau statistical posting ke dalam mereka. b. The Recurring Entry Program
41 Kita dapat menggunakan recurring entry program untuk melakukan posting yang dilakukan secara berulang pada jangka waktu yang tetap, seperti pembayaran uang sewa dan pembayaran pajak properti. Dengan program ini, dokumen yang diperlukan akan dihasilkan secara otomatis. Transaksi bisnis yang berulang harus disimpan di dalam sistem sebagai dokumen asli untuk entri berulang agar hal ini dapat dilakukan. Setiap dokumen asli untuk entri berulang berisi tanggal posting pertama dan terakhir, frekuensi di mana posting
harus
dilakukan,
dan
tanggal
untuk
perencanaan posting yang akan datang. Recurring entry program harus dimulai pada jangka waktu yang tetap di dalam periode yang telah ditentukan.
Program
tersebut
memilih
semua
dokumen asli untuk entri berulang yang tanggal posting-nya telah jatuh tempo, lalu kemudian menjalankan sesi batch input. Ketika sesi batch input dijalankan, dokumen akuntansi yang sesuai dengan dokumen aslinya diposting, dan tanggal untuk posting selanjutnya diupdate di dalam dokumen asli untuk entri berulang. c. Elements of the Payment Transaction Transaksi pembayaran dapat dilakukan secara manual maupun otomatis menggunakan program pembayaran. Semua
transaksi
pembayaran
berisi
beberapa
elemen, yaitu: a. Memilih metode pembayaran dan bank yang akan digunakan b. Memilih item untuk pembayaran c. Menghitung jumlah pembayaran d. Melakukan posting dokumen pembayaran e. Mencetak media pembayaran
42 d. Automatic Payment Program Parameters Program pembayaran dikembangkan untuk transaksi pembayaran
internasional
antara
vendor
dan
customer. Program ini dapat digunakan untuk incoming outgoing
payment
(pembayaran
payment
masuk)
(pembayaran
atau
keluar).
Bagaimanapun juga, program ini lebih banyak digunakan untuk pembayaran keluar.
Gambar 2.16 Print Payment Media Pembayaran otomatis terdiri dari beberapa langkah, yaitu: Langkah pertama adalah mengelola parameter. Kita menggunakan parameter untuk mendefinisikan akun dan item mana yang perlu dimasukkan ke dalam program pembayaran di dalam automatic payment run. Langkah kedua adalah proposal run. Selama proposal run berjalan, sistem melakukan beberapa hal, yaitu:
43 a. Mengecek akun dan dokumen yang ditetapkan di dalam parameter untuk item yang jatuh tempo b. Mengelompokkan item yang jatuh tempo dan harus dibayar c. Metode pembayaran, house bank, dan partner bank yang relevan Langkah ketiga adalah mengecek dan mengedit proposal
pembayaran.
Langkah
ini
dapat
dihilangkan, namun kita sangat disarankan untuk mengecek
bahwa
data
telah
akurat
sebelum
menjalankan program pembayaran. Langkah keempat adalah menjalankan pembayaran. Selama payment run, sistem melakukan beberapa hal, yaitu: a. Melakukan posting dokumen pembayaran b. Mengosongkan open item c. Menyiapkan
data
yang
diperlukan
untuk
pencetakan
media
pencetakan media pembayaran Langkah
terakhir
adalah
pembayaran, contoh dari media pembayaran dapat berupa cek. 2.2.2.3.2.3 Integration with Materials Management a. Plant Objek pusat dari suatu organisasi mengenai logistik adalah plant. Sebuah plant merupakan area atau cabang operasi di dalam perusahaan. Plant dapat berupa gudang pengiriman pusat, kantol penjualan daerah, fasilitas pabrik, kantor pusat perusahaan, atau pabrik maintenance. Plant harus di-assign ke satu company code. Bagaimanapun juga, satu atau lebih plant dapat di-assign ke company code yang sama. b. Purchasing Organization Pembelian bahan baku untuk plant dilakukan oleh purchasing organization. Purchasing organization
44 merupakan elemen organisasi yang melakukan negosiasi kondisi pembelian dengan vendor untuk satu atau lebih plant. c. Purchasing Data Agar
proses
pembelian
digunakan
di
dalam
Materials Management untuk vendor, vendor master record
harus
memiliki
bagian
ketiga,
yaitu
purchasing data. Purchasing data bersifat spesifik pada satu purchasing organization, sama seperti data company code dari master record yang bersifat spesifik pada satu company code. Sama seperti fakta bahwa dimungkinkan untuk memiliki beberapa segmen company code untuk vendor master record, dimungkinkan
juga
untuk
memiliki
beberapa
segmen purchasing data untuk vendor master record. Setiap segmen purchasing data menyajikan data
yang
spesifik
untuk
satu
purchasing
organization. d. Procurement Cycle
Gambar 2.17 Procurement Cycle Berikut
ini
adalah
proses-proses
procurement cycle: a. Demand determination
di
dalam
45 Departemen yang bertanggung jawab dapat mencatat kebutuhan material secara manual melalui purchase order ke bagian pembelian. b. Determining the source of supply Tanggung jawab pembeli didukung oleh sistem di dalam menentukan source of supply (supplier yang menyediakan material yang dibutuhkan). Salah satu kemungkinan untuk menentukan source of supply adalah membuat query dan lalu memasukkan quotation. Lebih lanjut, kita dapat mengakses purchase order dan kondisi yang telah ada di dalam sistem. c. Supplier selection Membandingkan harga dari quotation yang berbeda membuat pemilihan supplier menjadi lebih mudah. Surat penolakan dapat dikirim secara otomatis. d. Purchase order handling Ketika
membuat
purchase
order,
sistem
menyediakan proses pengentrian. e. Purchase order monitoring Pembeli dapat mengawasi status pemrosesan dari purchase order di dalam sistem. Sebagai contoh, dia dapat menentukan apakah barang atau tagihan telah diterima untuk purchase order yang bersangkutan. f. Goods receipt Sistem mengecek jumlah barang yang diterima, apakah sesuai dengan kuantitas pemesanan. g. Invoice verification Tagihan dari vendor dicek untuk melihat apakah akuntansi dan isinya telah benar. h. Payment processing Proses pembayaran biasanya dilakukan oleh bagian Financial Accounting.
46 e. Posting Procurement Transactions The three-step verification (verifikasi tiga langkah) merupakan prosedur baku untuk posting transaksi pembelian di dalam Materials Management. Tiga langkah tersebut adalah sebagai berikut: a. Purchase order Membuat purchase order di dalam Materials Management. Tidak menghasilkan posting apaapa di dalam Financial Accounting.
b. Goods receipt Untuk melakukan update atas persediaan atau barang yang dapat dikonsumsi, menghasilkan dokumen
material
di
dalam
Materials
Management. Pada waktu yang sama, membuat sebuah dokumen di dalam Financial Accounting yang melakukan posting nilai dari barang ke merchandise account sebagai debit dan goods receipt/invoice receipt ke clearing account sebagai kredit di dalam general ledger. c. Invoice verification Melakukan posting tagihan vendor di dalam Materials Management menggunakan invoice verification (verifikasi tagihan). Hal ini secara otomatis akan menghasilkan dokumen di dalam Financial
Accounting.
Dokumen
akuntansi
tersebut berisi jumlah tagihan yang di-posting ke GR/IR account sebagai debit dan akun vendor sebagai kredit.
47
Gambar 2.18 Purchase Order Screen 2.2.2.3.2.4 Closing Operations in Accounts Payable a. Accounts Payable Closing Operation Penutupan akhir tahun dapat dibagi menjadi dua bagian utama, yaitu: a. Persyaratan legal (prosedur yang dibutuhkan oleh pemerintah yang berwenang) b. Persyaratan teknikal dan organisasi (prosedur yang secara teknikal dibutuhkan untuk mendukung organisasi akuntansi)
Gambar 2.19 Accounts Payable closing operations Langkah-langkah penutupan di dalam accounts payable adalah sebagai berikut:
48 a. Pada awal tahun fiskal, program balance carry forward dijalankan, memindahkan saldo dari akun vendor ke tahun fiskal yang baru. b. Periode posting dari tahun fiskal yang lama diblok dan periode khusus untuk melakukan posting penutupan dibuka. c. Setelah itu, saldo dan vendor yang dipilih dikonfirmasi, dokumen dengan mata uang asing divaluasi, dan accounts payable dikelompokkan ulang berdasarkan sisa hidup. d. Setelah selesai, periode khusus tersebut dapat ditutup kembali. b. Balance Confirmations Program untuk membuat konfirmasi saldo juga membuat
permintaan
balasan
untuk
sejumlah
vendor, sebuah daftar rekonsiliasi, dan sebuah result table. Konfirmasi saldo dan permintaan balasan dikirim ke vendor, sedangkan daftar rekonsiliasi digunakan sebagai ukuran kontrol. Vendor mengecek informasi saldo yang mereka terima dan mengirim balasan mereka ke departemen kontrol pusat, yang kemudian akan membandingkan balasan tersebut dengan daftar rekonsiliasi dan kemudian memasukkan hasilnya ke dalam result table. c. Foreign Currency Valuation Valuasi mata uang asing dibutuhkan apabila akun vendor berisi open item dalam mata uang asing. Jumlah mata uang asing untuk open item tersebut diterjemahkan
ke
dalam
mata
uang
lokal
berdasarkan kurs pertukaran mata uang yang valid untuk tanggal posting. Kurs pertukaran mungkin saja berbeda pada saat penutupan, dan open item perlu divaluasi ulang. Program
tersebut
memvaluasi
open
item
49 menggunakan kurs pertukaran yang baru dan memasukkan perbedaan valuasi di dalam line item yang divaluasi. Hal ini juga membuat dua posting, yaitu: a. Debit: biaya dari valuasi mata uang asing, kredit: akun penyesuaian neraca saldo b. Debit: akun penyesuaian neraca saldo, kredit: pendapatan dari valuasi mata uang asing Valuasi tidak dapat dilakukan dengan melakukan posting
ke
accounts
payable,
karena
akun
rekonsiliasi tidak dapat di-posting secara langsung. Untuk alasan ini, posting muncul di adjustment account (akun penyesuaian), yang mana ditampilkan di neraca saldo untuk akun rekonsiliasi yang bersangkutan. d. Regrouping Accounts Payable Accounts payable dan accounts receivable harus terdaftar secara terpisah di neraca saldo. Karena dimungkinkan bagi beberapa vendor untuk memiliki saldo debit, akun-akun ini harus diubah dengan saldo debit sebelum membuat laporan keuangan. Di
banyak
negara,
juga
dibutuhkan
untuk
mengelompokkan accounts payable di dalam neraca saldo berdasarkan sisa hidup mereka. Pengelompokan
ulang
tersebut
dijalankan
menggunakan program khusus. Pada waktu yang sama, pengelompokan ulang ini dihilangkan pada hari
pertama
di
periode
berikutnya,
karena
pengelompokan ulang ini tidak diperlukan untuk pemrosesan sehari-hari. 2.2.2.3.3 Accounts Receivable Bodnar dan Hopwood (2004:295) mendefinisikan accounts receivable atau piutang usaha sebagai uang yang terutang oleh konsumen atas barang yang telah dijual atau jasa yang diberikan kepadanya.
50 Horngren, Sundem, dan Stratton (2004:239) mendefinisikan accounts receivable atau piutang usaha sebagai sejumlah uang yang dihutangkan kepada perusahaan oleh pelanggannya sebagai hasil dari pengiriman barang atau jasa. 2.2.2.3.3.1 Customer Master Data Sama seperti G/L account dan akun vendor, akun customer juga terdiri dari dua area, yaitu: a. General data Sebuah customer account didefinisikan untuk semua company code pada tingkat client. General data, seperti alamat pelanggan, disimpan di sini. General data berlaku untuk semua company code yang melakukan bisnis dengan pelanggan.
b. Company code segment Posting tidak dapat dilakukan ke customer account untuk company code hingga customer code-specific setting (pengaturan spesifik untuk company code) telah dibuat. Segmen company code berisi informasi yang berarti hanya ke satu company code, seperti aturan pembayaran yang telah disetujui.
Gambar 2.20 Company Code View of the Customer Master Record Sama seperti G/L account dan vendor account, customer account disimpan di berbagai macam
51 account group, sehingga mereka dapat diatur dan dikelola dengan lebih mudah. Akun-akun di account group biasanya memiliki karakteristik yang sama. Sebagai contoh, kita dapat memiliki satu account group untuk pelanggan domestik, satu account group untuk pelanggan luar negeri, satu account group untuk pelanggan afiliasi, dan satu account group untuk one-time customer. Account group memiliki number range yang diassign ke mereka. Ada dua tipe number range, yaitu: a. Internal:
tidak
perlu
memasukkan
nomor
pelanggan ketika membuat customer master record. Bahkan, sistem sendiri yang meng-assign nomor pelanggan dari number range yang telah di-assign ke account group ketika customer master record baru dibuat. b. Eksternal: memasukkan nomor pelanggan secara manual ketika membuat customer master record. Nomor pelanggan tersebut dapat berupa angka maupun huruf, jika number range mengizinkan hal itu terjadi. Account group menentukan tampilan dari semua bagian dari customer master record. Dengan kata lain, mereka menentukan field mana saja yang optional (boleh diisi boleh tidak), field mana saja yang wajib untuk diisi, field mana saja yang perlu ditampilkan atau disembunyikan. 2.2.2.3.3.2 Daily
Accounting
Transactions
in
Accounts
Receivable a. Invoice/Credit Memo Entry Hampir semua tagihan dan kredit memo dari pelanggan mencapai accounts receivable melalui integrasi dengan Sales Order Management. Pada kasus-kasus yang terkecuali, jika tidak ada referensi ke sales order, tagihan dan kredit memo tetap dapat
52 dimasukkan menggunakan enjoy transaction. Layar pengentrian
enjoy
transaction
dibagi
menjadi
beberapa area, yaitu: a. Work templates Di sini, kita dapat memilih variasi layar, account assignment template, atau held document sebagai referensi. b. Header and customer data Header dokumen dan data customer line item dimasukkan di sini. c. G/L account items Line item G/L untuk dokumen dimasukkan di sini.
d. Information area Saldo dokumen dan informasi mengenai pelanggan ditampilkan di sini. Information area juga berisi link ke master data dan open item.
Gambar 2.21 Enjoy Invoice/Credit Memo Entry Transaksi ini juga dapat digunakan untuk membuat dokumen dengan mata uang asing. Jumlah mata uang asing diterjemahkan ke dalam mata uang lokal menggunakan kurs pertukaran mata uang yang telah ditentukan.
53
Gambar 2.22 Enjoy Customer Invoice Screen b. Incoming Payments Incoming payment (pembayaran masuk) dapat dilakukan dengan beberapa cara di perusahaanperusahaan yang berbeda. Beberapa hal yang penting mengenai incoming payment adalah sebagai berikut: a. Item akan dibersihkan jika pelanggan melakukan pembayaran open item sesuai dengan jumlahnya atau sesuai dengan diskon yang telah disetujui. b. Jika selisih pembayaran yang kecil muncul, selisih pembayaran tersebut dapat dihilangkan secara otomatis.
Jumlah
maksimum
untuk
selisih
pembayaran yang kecil untuk dihilangkan dapat ditentukan di pengaturan toleransi. c. Jika selisih pembayaran di luar batas toleransi, maka hal ini harus diurus secara manual. Ada
dua
metode
posting
terhadap
selisih
pembayaran di luar batas toleransi tersebut, yaitu: a. Partial payment: item yang dibayar sebagian tersebut tidak dibersihkan. Sebuah open item yang baru dengan jumlah yang dibayar dibuat di sisi kredit. Entri kredit ini muncul di atas open item yang telah dibayar dan menunjukkan bahwa open item hanya dibayar sebagian.
54 b. Residual item: open invoice dibersihkan dan open item baru (residual item) dengan jumlah sebesar selisih pembayaran dibuat.
Gambar 2.23 Process Incoming Payment Screen
c. Dunning Functions Sistem SAP menyediakan alat yang secara otomatis menganalisis semua open item dan menagih semua open
item
menentukan
yang
telah
dunning
jatuh
level
tempo.
(tingkat
Sistem tagihan)
berdasarkan jumlah hari sejak open item tersebut jatuh tempo. Tingkat tagihan menentukan biaya tagihan mana yang akan digunakan dan juga teks tagihan mana yang akan dipilih. Dunning history menyimpan data mengenai peringatan tagihan mana saja yang telah dikeluarkan. Kita dapat menjalankan automatic dunning (tagihan otomatis) untuk satu akun dan menghasilkan peringatan tagihan individual, atau kita juga dapat menjalankan dunning program untuk membuat tagihan secara otomatis ke sejumlah akun yang dipilih. Dunning dikontrol oleh suatu dunning procedure (prosedur tagihan). Prosedur tagihan harus ada di setiap akun pelanggan atau vendor yang ingin
55 dimasukkan
ke
dalam
automatic
dunning.
Sedangkan, prosedur tagihan yang berlaku untuk one-time customer dimasukkan ke dalam one-time account. Kita dapat menentukan sebanyak mungkin prosedur tagihan yang berbeda. Sistem SAP menyediakan beberapa standar untuk prosedur tagihan yang dapat digunakan
sebagai
template
untuk
prosedur
tambahan. Kita dapat menentukan bagaimana dunning run akan dijalankan dengan memasukkan parameter di dalam dunning
program.
Kita
dapat
menggunakan
parameter dari dunning run yang sudah ada sebagai template dan mengubah tanggalnya agar memenuhi persyaratan. Biasanya, parameter berupa company code dan akun yang ingin dimasukkan ke dalam dunning run. d. Dunning Run Selama dunning run, akun-akun dipilih dan dicek untuk item yang telah jatuh tempo. Sistem kemudian mengecek apakah peringatan tagihan harus dikirim dan memilih tingkat tagihan yang sesuai. Semua data tagihan disimpan di dalam dunning proposal. Dunning proposal dapat diedit, dihapus, dan dibuat ulang sesering yang kita inginkan hingga bagian akuntansi puas dengan hasilnya. Dunning proposal bukanlah langkah yang wajib, oleh sebab itu, dunning proposal dapat dihilangkan. Jika dunn print with scheduling tidak dipilih, sistem tidak akan membuat proposal. Bahkan, sistem akan langsung
mencetak
peringatan
program tersebut dijalankan.
tagihan
ketika
56
Gambar 2.24 Printing Dunning Notices Langkah terakhir adalah sistem mencetak peringatan tagihan dan melakukan update data tagihan di master record dan dokumen, termasuk tanggal tagihan dan tingkat tagihannya.
e. Correspondence Correspondence yang terkait dengan bisnis seharihari harus di-request terlebih dahulu sebelum dapat dicetak. Permintaan korespondensi dapat dilakukan dengan: a. Otomatis, ketika transaksi khusus seperti bill of exchange
charges
pertukaran)
atau
statement payment
(laporan
notice
biaya
(peringatan
pembayaran) di-post b. Manual, dilakukan oleh bagian akuntansi c. Menggunakan menghasilkan
program
permintaan
request
yang
korespondensi dalam
jumlah yang besar secara bersamaan (seperti periodic account statement, internal document, standard letter)
57 Korespondensi yang di-request disimpan di dalam tabel permintaan korespondensi dan dapat dicetak melalui program tertentu. f. Accounts Receivable Information System Accounts
Receivable
Information
System
memungkinkan kita untuk menjalankan analisis cepat dari data akuntansi yang penting, seperti: a. Due date breakdown (rincian tanggal jatuh tempo) b. Customer payment history (sejarah pembayaran dari pelanggan) c. Currency risk for customers abroad (resiko mata uang untuk pelanggan luar negeri) d. Overdue items (item yang telah jatuh tempo) e. Jumlah hari yang digunakan oleh pelanggan untuk membayar tagihan f. Customer cash discount history (sejarah diskon pelanggan)
2.2.2.3.3.3 Integration with Sales Order Management a. Sales Organizations and Distribution Channels Sales
organization
bertanggung
jawab
atas
penjualan. Company code dapat dihubungkan ke beberapa sales organization. Setiap sales organization dapat menggunakan distribution channel yang berbeda untuk menjual barang. Prinsipnya, distribution channel dapat juga digunakan oleh dua sales organization yang berbeda. Kombinasi dari sales organization dan distribution channel disebut juga dengan distribution chain. Distribution chain menjual barang dari plant. Division (divisi) merepresentasikan lini produk inti dari suatu organisasi. Divisi di-assign ke distribution
58 chain. Kombinasi dari distribution chain dan divisi disebut dengan sales area. Perjanjian spesifik dengan pelanggan, mengenai partial delivery (pengiriman terpisah) atau terms of payment (aturan pembayaran), sebagai contoh, dapat dibuat untuk setiap sales area. b. Sales Area Data in the Customer Master Record Sales area (kombinasi dari sales organization, distribution
channel,
mendefinisikan
dan
sales
divisi)
area-specific
harus setting
(pengaturan spesifik untuk sales area) untuk seorang pelanggan sebelum dapat memulai bisnis dengan pelanggan tersebut. Pengaturan tersebut dapat berupa kondisi khusus dan aturan pembayaran yang telah disepakati pelanggan dengan sales area.
Gambar 2.25 Overview of the sales process c. Sales Process Sales order merupakan dasar dari proses penjualan. Ketika pelanggan telah memesan, sebuah sales order harus dibuat pada awal proses. Sales order dibuat pada tingkat distribution chain. Item yang dipesan dapat dari divisi yang berbeda. Sales order merupakan
dokumen
di
dalam
Sales
Order
59 Management
dan
tidak
menyebabkan
posting
apapun di dalam Financial Accounting. Ketika sales order
telah
dimasukkan,
sistem
menjalankan
availability check untuk tanggal pengiriman yang diminta. Pada hari shipping, dokumen outbound delivery dibuat. Penagihan untuk pengiriman dapat dilakukan hanya pada saat barang telah dibawa keluar dari gudang dan telah di-post sebagai goods issue. Hal ini merupakan langkah yang terpisah di dalam proses pengiriman. Fungsi warehouse management digunakan untuk picking. Sebuah transfer order harus dibuat, yang lalu akan menghasilkan pick order. Barang yang dipesan dibawa dari gudang dan disiapkan untuk pengiriman. Barang yang akan dikirim di-post sebagai goods issue. Dokumen goods issue dibuat di Materials Management, dan sebuah dokumen akuntansi dibuat di Financial Accounting sehingga goods issue tersebut di-post ke G/L account yang benar. Dokumen akuntansi tersebut mendebitkan cost of goods
sold
(biaya
penjualan
barang)
dan
mengkreditkan inventory (persediaan). Langkah terakhir di proses penjualan adalah billing (penagihan). Dokumen tagihan dibuat di Sales Order Management, dan tagihan yang dicetak dikirim ke pelanggan. Pada waktu yang sama, sebuah dokumen dibuat di Financial Accounting sehingga piutang dan pendapatan dapat di-post ke akun yang benar. Document flow merupakan alat yang memungkinkan kita
untuk
melihat
dokumen-dokumen
berhubungan di dalam proses penjualan.
yang
60
Gambar 2.26 Sales Order Entry Screen 2.2.2.3.3.4 Credit Management a. Credit Control Area Unit organisasi yang digunakan untuk mengontrol kredit adalah credit control area. Sebuah credit control area dapat di-assign ke company code individu (organisasi yang bersifat desentralisasi) maupun ke sekelompok company code (organisasi yang bersifat sentralisasi). Credit control area dikelola secara umum oleh departemen kredit yang terpisah, yang dibagi menjadi beberapa kelompok representative kredit. Setiap group berisi beberapa representatif kredit. b. Credit Management Master Record Departemen kredit membuat credit management master record yang terpisah. Hal ini merupakan ekstensi dari customer master record. Data yang relevan untuk manajemen kredit dapat diawasi dan dikelola melalui credit management master record yang terpisah. Credit management master record terdiri dari beberapa elemen, yaitu: a. General data Relevan untuk semua area kontrol kredit. General data
termasuk
alamat
pelanggan
dan
data
komunikasi, serta jumlah limit maksimum yang diizinkan untuk seorang pelanggan.
61 b. Credit control area data Relevan hanya untuk area kontrol kredit yang spesifik saja. Credit control area data termasuk limit kredit pada tingkat area kontrol kredit, dan kategori resiko pelanggan serta kelompok representatif kredit. c. Overview Overview berisi data yang paling penting dari semua bagian. c. Credit Control Process Kontrol kredit dijalankan dengan langkah sebagai berikut: a. Ketika pesanan dibuat, dilakukan suatu cek untuk melihat apakah limit kredit pelanggan akan melampaui batas apabila pesanan tersebut diterima. Jika limit kredit tidak melampaui batas, maka proses penjualan dapat dijalankan seperti biasa. b. Jika limit kredit melampaui batas, pesanan akan diblok untuk pengiriman dan departemen kredit harus menjalankan tugasnya. Representatif kredit yang bertanggung jawab akan dinotifikasi secara otomatis melalui remote mail, atau dapat juga menggunakan
laporan
secara
reguler
untuk
mengecek daftar dari pesanan yang diblok. c. Representatif kredit kemudian mengklarifikasi situasi, dapat menggunakan sistem informasi kredit atau dengan menghubungi pelanggan. d. Setelah klarifikasi telah dibuat, representatif kredit me-release pesanan, dan transaksi dapat diproses di Sales Order Management seperti biasa. Jika representatif kredit memutuskan untuk tidak me-release pesanan, maka pesanan tersebut ditolak. 2.2.2.3.3.5 Closing Operations in Accounts Receivable a. Closing Operations for Accounts Receivable
62
Gambar 2.27 Accounts Receivable closing operations Langkah-langkah penutupan di dalam accounts receivable adalah sebagai berikut: a. Pada awal tahun fiskal baru, program balance carry forward dijalankan, untuk memastikan bahwa saldo pada akun pelanggan dipindahkan ke tahun fiskal baru. b. Periode posting dari tahun fiskal lama diblok dan periode khusus untuk entri penutup dibuka. c. Setelah itu, konfirmasi saldo dikirim dan dievaluasi, dokumen dengan mata uang asing divaluasi, penyesuaian nilai dijalankan untuk piutang yang
jatuh
tempo,
dan
accounts
receivable
diklasifikasi ulang ke kategori jangka pendek atau jangka panjang untuk laporan keuangan. d. Periode khusus tersebut kemudian dapat ditutup. Konfirmasi saldo, valuasi mata uang asing, dan pengelompokan ulang dijalankan sama seperti pada accounts payable.
63 b. Value Adjustment Parameters Kita dapat menggunakan program valuasi untuk menjalankan penyesuaian nilai. Fungsi program tersebut sama seperti program dunning dan payment. Setiap valuation run diidentifikasi dengan jelas oleh tanggal dijalankan dan field identifikasi. Kita dapat menentukan bagaimana cara valuasi akan dijalankan dengan memasukkan parameter untuk valuation run. Kita dapat menggunakan parameter dari valuation run yang sudah ada sebagai template. Parameter-parameter ini termasuk metode valuasi, area valuasi, dan spesifikasi posting. Valuation run menganalisis akun dan dokumen yang dimasukkan di dalam parameter dan membuat proposal valuasi, yang dapat diedit, jika diperlukan. Valuasi tersebut dapat: a. Dimasukkan secara manual di dalam dokumen pada tanggal yang lebih awal (individual value adjustment) b. Ditentukan menggunakan value adjustment key yang terdapat pada master record pelanggan Langkah terakhir dari proses valuasi adalah transfer. Dokumen G/L melakukan posting valuasi dan dimasukkan ke dalam dokumen valuasi, sehingga valuasi tersebut dapat ditelusuri kapan saja.
64
Gambar 2.28 Valuation Transfer 2.2.2.3.4
Asset Accounting
Di dalam asset accounting, kita mengenal istilah depresiasi. Pujawan (2004:193) mendefinisikan depresiasi sebagai penurunan nilai suatu properti atau aset karena waktu dan pemakaian. Pujawan (2004:193) menyatakan bahwa depresiasi pada suatu properti atau aset biasanya disebabkan karena satu atau lebih faktorfaktor berikut: a. Kerusakan fisik akibat pemakaian dari alat atau properti tersebut b. Kebutuhan produksi atau jasa yang lebih baru dan lebih besar c. Penurunan kebutuhan produksi atau jasa d. Properti atau aset tersebut menjadi usang karena adanya perkembangan teknologi e. Penemuan fasilitas-fasilitas yang bisa menghasilkan produk yang lebih baik dengan ongkos yang lebih rendah dan tingkat keselamatan yang lebih memadai 2.2.2.3.4.1 Master Records in Asset Accounting a. Assets Setiap aset merupakan milik company code dan business area. Semua posting yang dibuat untuk aset (akuisisi, depresiasi, dan lain-lain) di-post ke dalam company code dan business area yang berhubungan. Sebagai tambahan, kita dapat meng-assign aset ke berbagai objek Management Accounting (cost
65 center, internal order, activity type, dan lain-lain) dan organizational unit untuk logistik (hanya untuk kegunaan seleksi dan pelaporan saja). b. Asset Class Asset class merupakan kriteria utama ketika mendefinisikan sebuah aset. Setiap aset harus diassign ke satu asset class. Di dalam asset class, kita dapat mendefinisikan parameter kontrol yang pasti dan nilai default untuk depresiasi dan master data lainnya. Asset class sama seperti account group, bahwa asset class juga menentukan tampilan layar dari asset master record dan memiliki number range. Aset yang tidak muncul di line item yang sama pada neraca saldo biasanya di-assign ke asset class yang berbeda. Sebagai tambahan, paling tidak terdapat satu asset class khusus untuk assets under construction dan satu juga untuk aset yang bernilai rendah, biasanya: a. 4000 untuk assets under construction b. 5000 untuk aset yang bernilai rendah c. Asset Valuation Biasanya, saldo dan transaksi aset perlu divaluasi secara berbeda untuk beberapa tujuan tertentu. Sebagai contoh, kita dapat menggunakan metode valuasi yang berbeda untuk: a. Laporan
keuangan
berdasarkan
kebutuhan
wilayah b. Laporan keuangan untuk tujuan pajak c. Controlling d. Pelaporan keuangan paralel untuk kelompok laporan keuangan e. Replacement value Untuk menyimpan lebih dari satu dasar valuasi, depreciation area disimpan di dalam sistem SAP.
66 Transaction figure yang terpisah disimpan di setiap area: a. Per aset dan depreciation area b. Untuk komponen nilai individu, seperti saldo, depresiasi, nilai buku yang tersisa Di dalam asset master record, data yang berbeda untuk valuation area disimpan. Data-data tersebut mengontol kalkulasi dari depresiasi normal dan khusus untuk valuation area masing-masing. Kita dapat menggunakan metode depresiasi yang berbeda untuk prosedur bisnis yang umum dari metode depresiasi yang diwajibkan oleh bagian pajak. d. Account Determination Karena depreciation area di dalam akuntansi aset tidak muncul di general ledger, nilainya harus dipost ke beberapa G/L account di dalam general ledger. G/L account kemudian digunakan di dalam berbagai macam versi laporan keuangan. G/L account berikut ini digunakan di berbagai macam versi laporan keuangan: a. Akun neraca saldo, yang mencatat penyesuaian ke dalam nilai aset b. Akun depresiasi untuk depresiasi dan apresiasi Penugasan dari G/L account ke valuation area yang berbeda disimpan di satu account assignment key. Account assignment key ini dimasukkan di dalam asset class dan muncul sebagai nilai standar pada asset master record. Aset dari asset class yang sama memiliki account assignment key yang sama, dengan kata lain, nilai mereka di-post ke dalam akun rekonsiliasi yang sama. e. Group Assets and Subnumbers Untuk tujuan pelaporan, komponen dari suatu aset dapat disimpan di dalam asset subnumbers, dan aset dapat dikombinasikan ke dalam group asset.
67 Aset
utama
di-assign
ke
subnumber
0,
memungkinkan asset subnumber untuk di-assign sebagaimana yang diinginkan. Sebuah group asset memiliki master data-nya sendiri. Beberapa aset utama dapat di-assign ke group asset. Depresiasi dihitung pada tingkat group asset. Hal ini penting di beberapa industri, seperti telekomunikasi. 2.2.2.3.4.2 Standard
Accounting
Transactions
in
Asset
Accounting a. Transaction Type Transaction type merupakan tambahan untuk asset posting key 70 (debit) dan 75 (kredit). Transaction type harus dimasukkan ketika melakukan posting ke asset account. Transaction type diperlukan untuk asset
accounting
karena
transaction
type
menentukan tepat di mana posting untuk aset terdaftar di asset history sheet. Transaction type membedakan karakteristik dari berbagai asset posting, sebagai contoh: a. Membeli atau menjual b. Kredit memo c. Akuisisi dari produksi internal d. Posting penyesuaian e. Masa pakai habis tanpa menghasilkan keuntung f. Depresiasi dan apresiasi b. Asset Transactions Transaksi aset seperti akuisisi dan retirement dapat di-post dengan berbagai cara untuk memenuhi kebutuhan bisnis dan organisasi dari perusahaan. Di dalam asset accounting, kita dapat melakukan posting dengan cara-cara berikut: a. Tanpa vendor atau purchase order, entri penyeimbang dibuat ke G/L clearing account
68 b. Ke vendor, namun tanpa referensi ke purchase order c. Melalui Materials Management menggunakan fungsi purchase order, goods receipt, dan invoice receipt Ketika melakukan posting ke akun dari dua buku pembantu, yaitu ke aset dan ke vendor, akun rekonsiliasi dari kedua buku pembantu di-update di general ledger.
Gambar 2.29 Document Entry Screen for Asset Acquisition c. Assets Under Construction Biaya untuk asset under construction dapat dikelola dengan dua cara, yaitu: a. Di komponen aplikasi investment management, kita dapat membuat, melakukan posting, dan mengelola investment order atau proyek investment management. Pesanan dan proyek ini kemudian dicocokkan
dengan
asset
under
construction.
Investment management menyediakan fungsi yang luas untuk mendukung prosedur investasi. b. Jika investment management tidak digunakan, asset under construction dapat di-post secara langsung di dalam asset accounting. Ketika aset telah lengkap, maka: a. Master data harus dibuat (jika belum ada) untuk aset
69 b. Nilai dari akun asset under construction harus dilunasi ke satu atau lebih aset lengkap. Biayanya didistribusi ke satu atau lebih aset dengan bantuan settlement rule (aturan pembayaran). d. Asset Explorer Asset explorer menawarkan tampilan keseluruhan dari akivitas untuk sebuah aset. Kita dapat melihat transaksi yang telah di-post ke dalam aset dan juga depresiasi yang telah direncanakan maupun yang telah di-post untuk setiap depreciation area, periode, maupun untuk setiap tahun fiskal. Kita dapat melihat rincian dari transaksi akuntansi. Selain itu, kita dapat dengan mudah berpindah untuk melihat aset lain tanpa meninggalkan layar.
Gambar 2.30 Asset Explorer
Gambar 2.31 Asset Explorer
70 2.2.2.3.4.3 Closing Procedures in Asset Accounting a. Asset Closing Penutupan dapat secara kasar dibagi menjadi dua tipe, yaitu: a. Persyaratan legal (diwajibkan oleh pemerintah) b. Tugas teknikal dan organisasi (langkap persiapan yang
diperlukan
secara
teknikal
atau
yang
mendukung accounting organization) Dengan fiscal year change program, tahun baru pun dibuka.
Hal
ini
memungkinkan
kita
untuk
melakukan posting ke aset di tahun fiskal yang baru. Year-End Closing Program mengecek apakah: a. Depresiasi
dan
nilai
aset
di-post
secara
keseluruhan b. Aset berisi error atau tidak sempurna Jika program tersebut tidak menemukan error, program tersebut melakukan update tahun fiskal yang baru ditutup untuk setiap depreciation area dan program
tersebut
memblok
posting
di
asset
accounting untuk tahun fiskal yang telah ditutup.
Gambar 2.32 Asset closing operations
71 Langkah-langkah
penutupan
di
dalam
asset
accounting adalah sebagai berikut: a. Pada awal tahun fiskal yang baru, penyesuaian teknikal
dilakukan,
yang
membandingkan
transaction figure di asset accounting dengan figure yang berhubungan di G/L account. b. Setelah itu, persediaan diambil dan posting penyesuaian dibuat, apabila ada koreksi yang perlu dilakukan. c. Depreciation posting run melakukan posting depresiasi ke general ledger. Karena hanya satu depreciation area dapat melakukan posting asetnya ke general ledger di real time, sebagai tambahan, depreciation area yang bersangkutan di-post ke general ledger menggunakan periodic asset account posting program. Posting untuk depresiasi tambahan ini diperlukan hanya di beberapa negara. d. Sistem akan melakukan periodic posting ke dalam akun neraca saldo, kemudian menjalankan year-end closing program. e. Kita sekarang dapat membuat asset history sheet, yang menampilkan nilai buku awal dan akhir dari aset dan transaksi yang terkait di dalamnya. b. Inventory Kita dapat membuat satu atau lebih daftar persediaan dengan sistem SAP untuk proses persediaan. Daftar tersebut diberikan kepada para karyawan yang melakukan tugas berkaitan dengan persediaan. Para karyawan ini mencatat semua selisih di daftar tersebut
dan
meneruskannya
ke
departemen
akuntansi. Para karyawan di bagian akuntansi memasukkan koreksi yang diperlukan ke dalam sistem. c. Depreciation Posting Run
72 Semua depresiasi pada awalnya disimpan dalam format nilai terencana di dalam asset accounting. Hanya setelah depreciation posting run selesai dijalankan,
depresiasi
akan
di-post
di
asset
accounting dan di general ledger. Depresiasi di-post ke akun depresiasi yang berhubungan di general ledger dan ke objek management accounting yang di-assign ke master record. d. Asset History Sheet Asset history sheet merupakan evaluasi yang paling penting dan paling lengkap untuk proses penutupan. Seperti laporan keuangan, struktur dari asset history sheet disusun berdasarkan persyaratan spesifik untuk setiap negara tertentu. Kita juga dapat membuat banyak versi asset history sheet. Setiap versi asset history sheet berisi berbagai pengelompokan history sheet, seperti berikut: a. Nilai buku pada awal tahun fiskal b. Akuisisi c. Retirement d. Posting penyesuaian e. Depresiasi f. Nilai buku pada akhir tahun fiskal 2.2.2.3.5
Bank Accounting
2.2.2.3.5.1 Master Records in Bank Accounting a. Bank Directory Bank directory berisi alamat dan data kontrol yang sah (misalnya swift code) dari semua bank yang digunakan di dalam sistem SAP. Bank directory dapat: a. Secara otomatis diimpor, selama bank directory tersedia di dalam disket dan program impor ada untuk data ini b. Dibuat secara manual
73 Jika sebuah bank dibuat di bank directory, data dasarnya bisa diakses, misalnya ketika memasukkan informasi bank kedalam master record milik customer
atau
vendor.
Kita
hanya
perlu
memasukkan data negara dari bank dan bank key. Sistem akan menemukan nama dan alamat dari bank di dalam tabel bank directory. Jika bank belum ada di dalam bank directory, bank bisa dimasukkan secara langsung. Kemudian baru ditambahkan ke dalam bank directory, jika sudah ditambahkan ke dalam master record milik customer dan vendor. b. Bank Accounts House bank adalah bank di mana kita (company code) mempunyai akun-akun. Setiap house bank diwakili oleh account ID. ID ini adalah kode yang dapat berjumlah hingga empat karakter, bisa berupa angka maupun huruf. House bank ID dan account ID dimasukkan kedalam G/L account master record, di mana mewakili sebuah bank account di dalam general ledger.
2.2.2.3.5.2 Business Transaction in Bank Accounting a. Cash Journal Sejak dirilisnya versi 4.6, SAP menyediakan cash journal untuk menangani petty cash. Kita dapat membuat
cash
diidentifikasikan
journal oleh
yang
kode
secara
sebanyak
unik empat
karakter. Setiap cash journal harus di-assign ke satu G/L account di mana mewakili akun jurnal petty cash di dalam general ledger. Transaksi cash disimpan secara terpisah ke dalam cash journal ditransfer secara periodik (misalnya: harian) ke general ledger.
74
Gambar 2.33 Cash Journal Transaction Layar pengentrian data untuk transaksi cash journal dibagi kedalam tiga bagian, yaitu: a. Data selection Di sini, periode waktu dari data dapat dipilih. b. Balance display Menampilkan jumlah kas masuk dan kas keluar serta saldo awal dan saldo akhir. c. Accounting transactions Di sini, transaksi cash journal dapat diisi. Di sini perbedaan dibuat antara cash payment, cash receipt, dan check receipt. Transaksi akuntansi disimpan secara terpisah di dalam cash journal dan ditransfer secara periodik ke general ledger. Transaksi yang ditransfer dapat dicetak sebagai jurnal. Tanda terima dapat dicetak untuk setiap transaksi individu. b. Types of Cash Journal Transactions Tipe-tipe dari transaksi cash journal adalah sebagai berikut: a. Expense b. Revenues c. Cash transfer dari cash office ke bank d. Cash transfer dari bank ke cash office e. Vendor payment receipt/issue
75 f. Customer payment receipt/issue c. Depositing Checks Proses depositing check adalah sebagai berikut: a. Cek yang masuk dapat diproses secara manual atau dengan check scanner. b. Setelah semua cek sudah dimasukkan, daftar dari cek yang akan dideposit tersedia di sistem dan dapat diperbaiki bila diperlukan. c. Daftar cek yang dideposit dapat dicetak atau dikirim ke bank bersama dengan cek. d. Batch input session dibuat dari daftar check deposit dan harus diproses untuk membuat posting. e. Posting dapat diselesaikan secara langsung, tanpa batch input session. d. Posting a Check Deposit Ketika melakukan posting terhadap daftar check deposit, dua batch input session dihasilkan, yaitu subledger session dan bank posting session. Kedua session ini harus diproses, untuk membuat posting yang terasosiasi di dalam general ledger. a. Subledger accounting session secara umum diproses dari accounts receivable dan membersihkan open item yang telah dibayar. b. Bank posting session biasanya diproses oleh departemen keuangan atau cash management. Mereka memposting jumlah cek ke incoming check account. e. Lockbox Ketika
menggunakan
lockbox,
customer
mengirimkan informasi cek dan pembayaran mereka langsung ke bank. Bank membayar biaya untuk meng-input
data
cek
yang
diterima.
Bank
menyimpan informasi cek dan pembayaran di dalam file dan mengirimnya ke departemen keuangan
76 menggunakan data transfer, misalnya disket, data line, atau EDI. Berkas lockbox disimpan di dalam sistem SAP. Akun cek masuk di-posting dan invoice yang telah dibayar dibersihkan. Informasi pembayaran yang telah selesai memungkinkan sistem SAP untuk berjalan baik dengan clearing. Jika sistem tidak dapat menemukan invoice untuk dibayar, informasi pembayaran harus diproses secara manual setelah menggunakan fungsi post processing. f. Bank Statement Bank
menginformasikan
departemen
keuangan
mengenai transaksi di dalam akun bank perusahaan menggunakan
bank
statement.
Posting
yang
disimpan di dalam bank statement harus dimasukkan ke dalam akuntansi. Perusahaan dapat menerima bank statement dalam dua cara yang berbeda: a. Dalam bentuk form: dalam kasus ini, account statement harus dibuat secara manual di dalam sistem SAP. b. Dalam bentuk file: file ini disediakan baik di dalam pembawa data ataupun diambil dari bank menggunakan transfer program (bank-spesific). Laporan SAP mengimpor file ini ke penyimpanan bank sementara dari sistem SAP. Proses selanjutnya adalah: a. Bank statement di dalam penyimpanan bank sementara dapat dicetak untuk tujuan dokumentasi. b. Batch input session dibuat dari bank statement di dalam penyimpanan bank sementara. Kita harus menjalanakan sesi ini untuk menciptakan posting yang dibutuhkan. Kita juga dapat melakukan posting secara langsung (tanpa batch input).
77 c. Kita dapat menjalankan postprocessing baik dengan menjalankan batch input session secara online
atau
menggunakan
transaksi
special
postprocessing jika kita melakukan posting secara langsung. g. Check Receipts and Issues Penjelasan mengenai check receipt dan check issue adalah sebagai berikut: a. Check issue Program pembayaran membuat cek dan melakukan posting check issue, setiap kali open vendor item dibersihkan. Check issue di-post ke dalam outgoing check account yang disiapkan untuk tujuan tersebut. Ketika ceknya telah didepositokan oleh vendor dan bank account didebitkan, ceknya muncul di dalam bank statement dan bank ledger accounting dari bank statement yang fungsinya untuk melakukan posting
“check
issued
to
bank”.
Jika
kita
menggunakan check management, posting tersebut dibawa melalui cashed checks. b. Check receipt Di USA, semua posting yang diperlukan dibawa dengan mengunakan fungsi dari lockbox. Di dalam prosedur lain, check receipt pertama-tama akan dipost ke incoming check account dan membersihkan open item. Di tahap kedua, bank ledger accounting session melakukan posting kas masuk dengan menggunakan “bank to incoming cash”. h. Transfers Di beberapa negara, transfer digunakan secara rutin. Sedangkan, di negara-negara lain, sangat jarang digunakan. Ada dua program yang dapat digunakan, yaitu: a. Outgoing transfer
78 Program pembayaran membuat pengirimannya dan melakukan posting ke outgoing cash account. Open vendor
item
dibersihkan
dalam
waktu
yang
bersamaan. Cash outflow muncul kemudian di dalam bank statement dan bank ledger accounting session membuat posting “cash outflow to bank”. b. Incoming transfer Incoming transfer muncul di bank statement. Fungsi dari bank statement adalah melakukan posting kas masuk,
“bank
to
incoming
cash”
dengan
menggunakan bank ledger accounting session. Subledger accounting session membersihkan item yang sudah dibayar dari akun pelanggan. Fungsi bank statement adalah untuk mendapatkan informasi tugas dari field transfer “note to payee”.
79
2.2.2.3.6 Preparing Financial Statement 2.2.2.3.6.1 Financial Closing in the General Ledger a. General Ledger Closing
Gambar 2.34 General Ledger closing operations Langkah-langkah penutupan di dalam general ledger adalah sebagai berikut: a. Pada awal tahun fiskal yang baru, program balance
carry
memastikan
forward
bahwa
dijalankan.
saldo
dari
G/L
Hal
ini
account
dipindahkan ke tahun fiskal yang baru. b. Periode posting dari tahun fiskal lama diblok dan periode
khusus
untuk
entri
penutup
dibuka.
Penyesuaian teknikal antara transaction figure dan dokumen memastikan bahwa dokumen di-post tanpa satupun kesalahan teknikal. c. Dokumen dengan mata uang asing kemudian dievaluasi, dokumen accrual atau deferral di-post dan GR/IR clearing account dianalisis. Selanjutnya, akun yang bersangkutan di-update. d. Jika kita ingin membuat laporan keuangan untuk business
area,
kita
harus
membuat
posting
80 penyesuaian ke business area. Saldo dari business area kemudian diatur menjadi nol. e. Periode khusus kemudian dapat ditutup. f. Untuk keperluan dokumentasi, balance audit trail dapat dilakukan dan laporan keuangan dibuat. Laporan tambahan disiapkan untuk tujuan pelaporan yang legal. b. Closing Cockpit Closing Cockpit memungkinkan kita untuk membuat antarmuka terstruktur untuk menjalankan transaksi dan program yang merupakan bagian dari proses yang kompleks, seperti proses penutupan.
Gambar 2.35 Closing Cockpit Closing cockpit sangat cocok ketika: a. Aktivitas akan muncul kembali secara periodik b. Lebih dari satu pihak yang bertanggung jawab dilibatkan c. Aktivitas dilakukan di dalam proses yang memiliki urutan kronologi tetap atau ditentukan oleh dependensi d. Aktivitas harus didukung oleh antarmuka untuk semua yang terlibat
81 e. Status dari semua aktivitas periodik harus didokumentasi dan dibuat transparan dan tersedia untuk semua yang terlibat Untuk mendukung proses penutupan, closing cockpit menawarkan pilihan-pilihan berikut: a. Hirarki untuk menampilkan objek organisasi yang terlibat di dalam proses penutupan b. Template daftar tugas berdasarkan struktur organisasi c. Daftar tugas yang berasal dari template daftar tugas d. Tampilan daftar di mana semua tugas yang harus dikelola atau dijalankan dari daftar tugas masingmasing dibuat menjadi tersedia untuk pemrosesan atau untuk pengawasan kemajuan tugas e. Informasi rinci mengenai pengaturan teknikal dari tugas serta untuk menganalisis background program f. Dependensi untuk menampilkan kondisi yang merepresentasikan prasyarat untuk memproses tugas individu c. Accrual Engine Pendapatan dan biaya, yang di-post di dalam periode posting yang spesifik, seringkali berasal dari periode yang berbeda. Ada dua metode di dalam sistem untuk posting seperti ini, yaitu: a. Accrual Biaya atau pendapatan adalah milik periode yang sedang berjalan, namun tidak di-post hingga periode nanti, karena tagihannya belum dikirim atau belum diterima.
82 b. Deferral Biaya atau pendapatan di-post di periode yang sedan berjalan, namun transaksi bisnis yang sesungguhnya terjadi di periode yang akan datang. d. GR/IR Analysis GR/IR clearing account berisi daftar dari semua barang dan tagihan yang diterima. Jika pada akhir periode, saldo dari akun ini tidak nol, ada dua alasan: a. Barang telah ditagih namun belum juga dikirim b. Barang telah dikirim namun belum juga ditagih Ketika tutup buku, saldo tersebut perlu dicatat sebagai aset maupun kewajiban di dalam laporan keuangan. GR/IR dianalisis dengan menggunakan program khusus. Di sini, saldo di-post ke akun barang telah ditagih namun belum juga dikirim atau ke akun barang telah dikirim namun belum juga ditagih. Posting tersebut dibalik pada hari pertama di periode berikutnya, karena melakukan posting ulang selama bisnis sehari-hari akan menyebabkan terjadinya kesalahan. Posting pembersihan biasanya dilakukan dengan menggunakan correction account. GR/IR clearing account dan correction account-nya kadang-kadang ditampilkan di lampiran laporan keuangan. e. Financial Statements Untuk membantu di dalam pembuatan laporan keuangan, ada dua pilihan yang tersedia di dalam sistem SAP, yaitu: a. Menggunakan program ABAP b. Menggunakan G/L account information system Kedua pilihan tersebut memungkinkan kita untuk melakukan hal-hal di bawah ini:
83 a. Menggunakan berbagai macam versi laporan keuangan b. Membuat laporan keuangan keseluruhan dan individu untuk company code c. Membuat laporan keuangan keseluruhan dan individu untuk business area d. Membuat
laporan
keuangan
dengan
menggunakan operating chart of account e. Membuat
laporan
keuangan
dengan
menggunakan country-specific chart of account f. Membuat perbandingan laporan keuangan untuk membandingkan dua tahun fiskal atau untuk membandingkan
data
perencanaan
dan
data
sesungguhnya 2.2.2.3.6.2 Cost-of-Sales Accounting a. Period Accounting Dua metode dasar untuk menata laporan laba rugi adalah: a. Period accounting b. Cost-of-sales accounting Kedua metode akan menghasilkan laporan laba rugi yang sama untuk satu periode. Metode yang digunakan mungkin saja diwajibkan atau hanya berdasarkan pertimbangan bisnis saja. Di dalam period accounting, jumlah hasil untuk satu periode dibandingkan dengan jumlah biaya untuk periode tersebut. Biaya keseluruhan untuk satu periode terdaftar menurut tipe biayanya. Di sini, saldo ditambahkan di akun biaya yang sama.
84
Gambar 2.36 Period Accounting b. Cost-of-Sales Accounting Pada cost-of-sales accounting, biaya barang yang terjual dikurangi dari pendapatan untuk menghitung keuntungan operasi. Pada period accounting, jumlah biaya produksi dikurangi dari pendapatan. Tidak seperti period accounting, di mana biaya dipecah berdasarkan tipe biaya, pada cost-of-sales accounting, biaya terdaftar berdasarkan fungsi mereka di dalam organisasi, seperti produksi, penjualan, administrasi, dan lain-lain. Fungsi-fungsi tersebut direpresentasikan oleh functional area.
Gambar 2.37 Cost-of-Sales Accounting
85 c. Derivation of Functional Area Ketika
cost-of-sales
accounting
dipilih,
field
tambahan yaitu functional area dimasukkan ke dalam coding block untuk akun. Entri dibuat di field functional area melalui: a. Entri manual pada field b. Entri otomatis dari functional area melalui substitusi c. Menyalin secara otomatis functional area yang dimasukkan ke master data dari akun laba rugi d. Menyalin secara otomatis functional area yang dimasukkan ke master data dari objek CO d. Cost-of-Sales Accounting Ledger Untuk membuat laporan keuangan berdasarkan costof-sales accounting, sistem SAP membutuhkan transaction figure untuk functional area. Pada general ledger yang standar, transaction figure hanya disimpan untuk company code dan business area
saja.
Untuk
alasan
inilah,
cost-of-sales
accounting
ledger
harus
digunakan
sehingga
transaction figure untuk functional area dapat disimpan juga. Menggunakan laporan keuangan khusus, transaction figure tersebut dapat diakses dan laporan laba rugi dapat dibuat berdasarkan cost-of-sales accounting. Jika tambahan transaction figure untuk field account assignment baru maupun yang sudah ada harus dikelola,
hal
ini
dapat
dilakukan
dengan
menggunakan special ledger. Metode berikut ini disediakan untuk mengelola transaction figure tambahan: a. Memperluas coding block. b. Menggunakan customer-defined ledger yang berisi transaction figure tambahan.
86 2.2.3
E-Learning 2.2.3.1 Pengertian E-Learning Effendi dan Zhuang (2005:6) menyatakan bahwa kata elearning sering diartikan sebagai semua kegiatan pendidikan atau pembelajaran yang menggunakan media komputer dan atau internet. Jadi, e-learning mengacu pada semua aktivitas pelatihan yang menggunakan media elektronik atau teknologi informasi. Piskurich (2003:1) menyatakan bahwa e-learning berkaitan dengan teknologi dan komputer, sehingga e-learning disimpulkan sebagai pembelajaran yang menggunakan jaringan komputer atau web sebagai perantara. 2.2.3.2 Konten E-Learning Clark dan Mayer (2003:15) menyatakan bahwa e-learning memiliki lima kategori konten, yaitu sebagai berikut: a. Fact, data yang spesifik dan unik. b. Concept, sebuah kategorisasi dari pengetahuan. c. Process, cara kerja dari aktivitas. d. Procedure, tugas yang ditampilkan dalam bentuk step by step. e. Principle, tugas yang ditampilkan dengan mengadopsi pedoman. 2.2.3.3 Tipe E-Learning Effendi dan Zhuang (2005:8) menyatakan bahwa ada dua tipe di dalam e-learning, yaitu sebagai berikut: a. Synchronous Training, merupakan tipe pelatihan di mana proses pembelajaran terjadi pada saat yang sama ketika kegiatan belajar mengajar berlangsung antara pengajar dan mahasiswa. Tipe pelatihan ini sifatnya mirip pelatihan di ruang kelas, namun ruang kelasnya bersifat maya dan peserta tersebar di mana-mana dan terhubung melalui internet. b. Asynchronous
Training, merupakan tipe pelatihan yang terjad
tidak pada waktu yang bersamaan. Traine dapat mengambil pelatihan pada waktu yang berbeda dengan waktu pelatihan. Biasanya paket pelatihan ini berbentuk bacaan, animasi, simulasi, atau latihan beserta jawabannya.
87 2.2.3.4 Prinsip E-Learning Clark dan Mayer (2003:51) menyatakan bahwa terdapat beberapa prinsip yang harus digunakan di dalam mengimplementasi elearning, yaitu sebagai berikut: a. Prinsip multimedia, menggunakan lebih banyak kata-kata dan grafik daripada kata-kata saja. b. Prinsip contiguity, menempatkan teks dan grafik di layar yang berdekatan satu sama lain. c. Prinsip modality, menampilkan kata-kata dalam suara daripada teks di layar. d. Prinsip
redudancy,
menampilkan
penggunaan
suara
untuk
penjelasan kata-kata, biasanya lebih baik untuk menjelaskan grafik. e. Prinsip
coherency,
menambahkan
bahan-bahan
yang
menyenangkan atau menghilangkan hal-hal yang tidak diperlukan. f. Prinsip personalization, penggunaan gaya percakapan dan pelatih virtual. 2.2.4 Perangkat Ajar 2.2.4.1 Pengertian Computer Assisted Instruction (CAI) Adeyemi
(2012:270)
mendefinisikan
Computer
Assisted
Instruction (CAI) sebagai suatu teknik pembelajaran secara pribadi, baik
melalui
online
maupun
offline,
yang
bertujuan
untuk
mengikutsertakan para pengguna agar dapat ikut berinteraksi dengan materi instruksional yang sudah diprogram dengan baik. CAI menggunakan kombinasi dari beberapa macam elemen multimedia, seperti teks, grafik, suara, dan video di dalam meningkatkan efisiensi proses pembelajaran. Sejalan dengan komputer, para pengguna bisa dibantu untuk makin berkembang di dalam area kurikulum yang ada. Pada dasarnya, CAI merujuk kepada penggunaan komputer sebagai media perantara untuk memanfaatkan instruksi-instruksi materi yang ada. Program CAI biasanya menggunakan tutorial, drill and practice, simulation, dan pendekatan secara problem solving untuk mempresentasikan topik-topik yang ada dan CAI merupakan solusi yang terbaik untuk mengetes sejauh mana pemahaman yang telah dicapai oleh setiap individu pengguna.
88 2.2.4.2 Jenis-jenis Perangkat Ajar Adeyemi (2012:270) menyatakan bahwa ada enam jenis perangkat ajar, yaitu sebagai berikut: a. Tutorial Tutorial merupakan jenis perangkat ajar yang paling sering digunakan. Tutorial menyediakan informasi serta panduan untuk memastikan pelajar memiliki sebuah kesempatan untuk mengerti instruksi yang terdapat di dalamnya. Tutorial yang berguna adalah tutorial yang di dalamnya terjadi interaksi timbal balik. Aktivitas dari tutorial mencakup presentasi dan perpanjangan dari presentasi tersebut ke dalam bentuk presentasi yang berbeda-beda, termasuk drill and practice dan simulation. b. Simulation Simulasi digunakan untuk merekayasa
tempat kerja yang
sebenarnya. Keadaan yang hampir mendekati kenyataan merupakan kunci sukses bagi simulasi, namun tiak semua elemen dari suatu simulasi dapat menjadi kenyataan. c. Game instructional Permainan dapat memiliki manfaat yang besar, antara lain lebih mudah dipahami daripada model instruksi, karena mengurangi tekanan di antara pengajar dan pelajar. Perangkat lunak aplikasi permainan memiliki fitur-fitur yang dapat melibatkan orang untuk dapat mencapai skor tertentu sebagai indikator pemahamannya. Selain itu, dapat juga dilakukan dengan mengalahkan teman sepermainan yang biasanya disediakan di dalamnya. d. Drill and practice Drill and practice menyediakan kesempatan bagi para pengguna untuk melatih kembali keahlian masing-masing, yang pada sesi sebelumnya telah dilalui. Sangat penting untuk terus mengulang di dalam drill and practice karena untuk dapat menguasai sesuatu harus dilakukan sesering mungkin. e. Discovery Discovery menyediakan sekumpulan informasi yang besar dan spesifik di dalam sebuah konten, serta menantang kemampuan para individu pengguna untuk meneliti, membandingka, mengambil
89 kesimpulan, dan mengevaluasi berdasarkan pengeksplorasian mereka terhadap konten tersebut. f. Problem solving Problem solving merupakan pendekatan yang membantu individu pengguna untuk mengembangkan keahlian dan penyusunan strategi di dalam menyelesaikan berbagai masalah yang spesifik. 2.2.4.3 Kelebihan dan Kekurangan Computer Assisted Instruction (CAI) Nasution
(2004:110)
menyatakan
bahwa
ada
beberapa
kelebihan dari CAI, yaitu sebagai berikut: a. CAI dapat membantu pengajar dan pelajar di dalam pelajaran. Karena komputer itu “sabar, cermat, dan mempunyai ingatan yang sempurna”, CAI sangat sesuai untuk latihan dan remedial teaching. Tak ada pengajar yang dapat memberi latihan tanpa jemu-jemunya seperti komputer. b. CAI memiliki banyak kemampuan yang dapat dimanfaatkan segera seperti membuat hitungan atau memproduksi grafik, gambaran, dan memberikan bermacam-macam informasi yang tak mungkin dikuasai oleh manusia manapun. c. CAI sangat fleksibel dalam mengajar dan dapat diatur menurut keinginan peneliti pelajaran atau penyusunan kurikulum. d. CAI dan proses pengajaran oleh pengajar dapat saling melengkapi. Bila komputer tidak dapat menjawab pertanyaan pelajar, dengan sendirinya pengajar akan menjawabnya. Ada kalanya komputer dapat memberi jawaban yang tak dapat segera dijawab oleh pengajar. e. Komputer dapat pula menilai hasil dari setiap pelajaran dengan segera. Nasution
(2004:110)
menyatakan
bahwa
ada
beberapa
kekurangan dari CAI, yaitu sebagai berikut: a. Meskipun harga perangkat keras komputer cenderung semakin menurun, pengembangan perangkat lunaknya masih relatif mahal. b. Untuk menggunakan komputer, diperlukan pengetahuan dan keterampilan khusus tentang komputer.
90 c. Keragaman
model
komputer
atau
perangkat
keras
sering
menyebabkan program yang tersedia untuk satu model tidak compatible dengan model lainnya. d. Program yang tersedia saat ini belum memperhitungkan kreativitas pelajar, sehingga hal tersebut tentu tidak akan dapat membantu mengembangkan kreativitas siswa. e. Komputer hanya efektif bila digunakan oleh satu orang atau beberapa orang dalam kelompok kecil. Untuk kelompok yang lebih besar,
diperlukan
tambahan
peralatan
lain
yang
mampu
memproyeksikan pesan-pesan di monitor ke layar yang lebih besar. 2.2.5
Multimedia 2.2.5.1 Definisi Multimedia Vaughan
(2011:1)
mendefinisikan
multimedia
sebagai
kombinasi dari teks, seni, suara, animasi, dan video yang disampaikan untuk pengguna melalui komputer atau alat elektronik lainnya. 2.2.5.2 Elemen Multimedia Vaughan (2011:11) menyatakan bahwa ada beberapa elemen utama di dalam multimedia, yaitu sebagai berikut: a. Teks Teks merupakan media paling dasar di dalam banyak sistem multimedia. Teks di dalam bentuk kata, kalimat, dan paragraf digunakan untuk mengkomunikasikan pikiran, ide, dan fakta pada hampir semua aspek kehidupan. b. Gambar Gambar adalah representasi grafik atau visual dari beberapa informasi yang dapat ditampilkan di layar komputer atau media cetak. Secara umum, gambar dapat dibagi menjadi dua jenis yaitu bitmap dan vector graphics. Bitmap merupakan matriks sederhana dari titik-titik kecil yang membentuk sebuah image dan ditampilkan di layar komputer. Sedangkan vector graphics merupakan salah satu tipe gambar yang menggunakan satuan dot. c. Suara Suara merupakan sesuatu yang bergetar di udara, menciptakan gelombang tekanan. Suara dapat menyediakan kenikmatan dalam
91 mendengarkan musik, efek suara yang menakjubkan, atau sebagai pengatur mood. d. Animasi Animasi dapat membuat presentasi yang statis menjadi hidup. Animasi merupakan perubahan visual dari waktu ke waktu dan dapat menambah kekuatan pada proyek multimedia dan halaman web. Salah satu bentuk animasi ialah animasi 2D. Animasi 2D ini sederhana dan statis, tidak mengubah posisi layar. Dalam ruang 2D, perubahan visual yang menjadikan gambar hidup dalam aksis cartesius x dan y pada layar. Cel animation didasarkan pada bentuk perubahan yang terjadi satu frame berikutnya. Path animation memindahkan objek di sepanjang jalan yang telah ditetapkan pada layar. e. Video Dari semua elemen multimedia, video menempatkan tuntutan performa tertinggi dalam komputer dari segi memori dan penyimpanannya. Video digital merupakan sarana multimedia yang paling menarik dan merupakan alat yang ampuh untuk membawa pengguna komputer menjadi lebih dekat dengan dunia nyata. Video klip yang direncanakan dengan hati-hati dan digarap dengan baik dapat membuat perbedaan dramatis dalam sebuah proyek multimedia. 2.2.6 Instructional Design 2.2.6.1 Pengertian Instruction Gagne, Wager, Golas, dan Keller (2005:1) mendefinisikan instruction sebagai serangkaian event atau kejadian yang dimasukkan ke dalam aktivitas yang memiliki tujuan dalam memfasilitasi pembelajaran. 2.2.6.2 Pengertian Instructional Design Gagne, Wager, Golas, dan Keller (2005:2) memberikan beberapa asumsinya untuk menjelaskan instructional design. Mereka berpendapat bahwa setiap perancang harus mengaplikasikan pengertian mereka dari prinsip dan event yang dapat mempengaruhi pembelajaran dan menentukan bagaimana struktur instructional yang baik.
92 Instructional design tersebut harus lebih bertujuan kepada proses dalam pembelajaran daripada proses pengajaran. Instructional design harus juga bertujuan pada intentional learning yang bekebalikan dengan incidental learning. Hal ini mengimplikasikan bahwa tujuan pembelajaran yang diinginkan akan mengarahkan desain dan seleksi dari aktivitas pembelajaran. Pada asumsi kedua, mereka mengenali bahwa pembelajaran merupakan sebuah proses yang kompleks yang dipengaruhi oleh banyak variabel. Untuk penjelasan selanjutnya, mereka juga berpendapat bahwa model instructional design bisa diaplikasikan di level mana saja. Prinsip dari instructional design bisa digunakan oleh seorang pengajar atau pelatih yang merencanakan sebuah pengajaran untuk aktivitas sehari, seorang pelatih yang menyiapkan workshop selama beberapa hari, atau pengembang sebuah kurikulum dalam merancang sebuah kursus. Instructional design ini bisa dari keinginan sendiri atau bisa melibatkan sebuah tim perancang, ahli dalam bidang pelajaran tertentu, ahli evaluasi, dan personel dalam proyek yang besar. Asumsi yang lainnya mengatakan bahwa design merupakan sebuah proses yang berulang yang memberikan pemahaman akan bagaimana seseorang belajar saat in yang harus melibatkan pengajar di dalamnya untuk merancang sebuah instruction. Tetapi bahan-bahan pengajaran dan aktivitasnya harus diuji oleh pengajar untuk mengetahui mana yang bisa digunakan dan mana yang tidak bisa digunakan. Lalu pada asumsi kelima mengatakan bahwa instructional design itu sendiri merupakan sebuah proses yang mengandung subproses yang saling berhubungan dan telah diketahui. Pada level yang paling mudah, instructional design adalah menarik garis antara hasil yang diharapkan, metode instruksi, dan penilaian pelajar. Namun jika kita menginginkan sebuah tipe hasil pembelajaran yang berbeda, makan akan menghasilkan tipe instruksi yang berbeda pula. 2.2.6.3 Fase-fase Instructional System Design Gagne, Wager, Golas, dan Keller (2005:18) menyatakan bahwa sebuah sistem instructional dapat didefinisikan sebagai sebuah
93 perencanaan dari sumber daya dan prosedur yang digunakan untuk memfasilitasi suatu pembelajaran. Instructional system design (ISD) merupakan sebuah proses pembuatan sistem instructional, baik secara sistematis maupun scientific yang dapat didokumentasikan, tersedia di dalam aplikasi yangumum dan membawa kepada outcomes yang dapat diramalkan. ISD ini mencakup beberapa fase, yaitu analysis, design, development, implementation, dan evaluation. a. Analysis Dalam proses ISD ini, analisis yang dilakukan berkaitan dengan konsep umum tentang pemenuhan kebutuhan. Oleh karena itu, analisis yang dilakukan dalam model ADDIE ini memenuhi tiga analisis kebutuhan, yaitu sebagai berikut: 1. Gap analysis, merupakan analisis yang coba untuk dimengerti oleh para perancang apakah terdapat perbedaan antara kinerja di lapangan dengan kinerja yang ingin dicapai. Oleh karena itu, tahap ini lebih menganalisis tentang kebutuhan yang ada dan yang diinginkan atau biasa disebut dengan analisis kebutuhan. Analisis kebutuhan merupakan sebuah konsep penting karena analisis ini tidak hanya mengidentifikasikan tujuan yang diinginkan, tetapi juga berusaha untuk mengukur keadaan saat ini sehingga dalam perkembangannya ke depan akan bisa mempertemukan tujuan yang sudah ditetapkan. 2. Analisis karakteristik pembelajaran, merupakan sebuah analisis yang mengidentifikasikan kebutuhan pembelajaran seperti apa yang dibutuhkan dalam sebuah pembelajaran. 3. Analisis kebutuhan sumber daya, merupakan analisa yang lebih menekankan kepada kondisi dari lingkungan dan batasan dari kondisi tersebut. Hasil dari analisis ini berupa sumber daya apa saja yang dibutuhkan di dalam sebuah pelajaran dan apakah ada peralatan
tertentu
yang
diperlukan
untuk
mendukung
pembelajaran. b. Design Komponen desain di dalam ISD ini akan menghasilkan sebuah perencanaan atau blueprint yang digunakan sebagai landasan untuk
94 mengarahkan pada proses development dari instruksi. Dalam tahap ini, seorang instructional designer membangun sebuah perencanaan berdasarkan kebutuhan pembelajaran dan bekerja sama dengan ahli dalam subyek tertentu untuk mengetahui skill yang diajarkan dan strategi untuk mengajarkan mereka. Produk dari desain ini adalah seperangkat spesifikasi atau perencanaan
kepada
para
developer
dalam
memproduksi
instructional support material. Proses prototyping menyediakan sebuah peluang awal untuk mendapatkan feedback dari pengguna untuk menekankan pada fungsionalitas, feasibility, dan keberadaan dari sebuah instruksi. Prosedur yang digunakan dalam desain ini adalah pendekatan “top-down” agar dapat mentransfer tujuan mata pelajaran ke dalam tujuan dalam level performance. c. Development Tahap pengembangan dalam ISD ini mengacu pada persiapan bahan-bahan yang akan digunakan dalam kegiatan belajar mengajar. Tahap ini bisa didekatkan melalui beberapa arah, tergantung dari hubungan antara instructional objective, level kedetailan dalam merancang dokumen yang menyediakan inputan untuk pengembangan, karakteristik, serta ketetapan dalam material yang ada dan sistem perantara yang digunakan. d. Implementation Tahap implementasi dalam model ADDIE ini memiliki dua tipe. Tipe
yang
pertama
lebih
diarahkan
kepada
implementasi
aktivitasnya yang muncul di saat pembelajaran masih dalam tahap pembuatan dan evaluasi. Kondisi seperti ini disebut dengan pilot testing atau field testing. Perihal kedua mengacu lebih kepada meluncurkan
pembelajaran
yang
sesungguhnya
setelah
pengembangan selesai dikerjakan. e. Evaluation Tahap evaluasi merupakan tahap yang paling akhir di dalam ISD. Evaluasi ini dapat muncul dalam beberapa point dan dapat muncul dalam semua tahapan proses ISD, termasuk setelah fase pengembangan
dan
diimplementasikan.
juga
setelah
produk
ini
selesai
95 2.2.7 Konsep Object-Oriented Analysis and Design (OOAD) with the Unified Process (UP) Satzinger, Jackson, dan Burd (2005:60) mendefinisikan object-oriented analysis sebagai proses mendefinisikan semua objek yang melakukan pekerjaan di dalam suatu sistem dan menunjukkan interaksi pengguna apa saja yang dibutuhkan untuk menyelesaikan tugas di dalam sistem. Object-oriented design merupakan proses mendefinisikan semua jenis objek yang diperlukan untuk berkomunikasi dengan orang maupun perangkat di dalam sistem, menunjukkan bagaimana objek berinteraksi untuk menyelesaikan tugas di dalam sistem, dan menyempurnakan definisi dari setiap jenis objek sehingga dapat diimplementasikan dengan lingkungan atau bahasa tertentu. Unified process merupakan suatu metodologi pengembangan sistem yang berorientasi objek yang dikembangkan oleh Rational Software, bagian dari IBM. 2.2.7.1 Object-Oriented Analysis Analisis sistem dibagi menjadi beberapa tahapan yaitu sebagai berikut: a. Gather detailed information Tahapan gather detailed information dapat dilakukan dengan dua cara, yaitu sebagai berikut: 1. Metode survei, yaitu dengan mengadakan penelitian yang dilakukan dengan peninjauan langsung ke perusahaan. 2. Metode wawancara, yaitu dengan mengadakan tanya jawab dengan pemilik perusahaan dan karyawan-karyawan yang berhubungan dengan topik yang dibahas. b. Define functional requirements Tahapan
define
functional
requirements
dilakukan
dengan
menentukan persyaratan sistem yang mendeskripsikan aktivitas atau proses yang harus dilakukan oleh suatu sistem. c. Define nonfunctional requirements Tahapan define nonfunctional requirements dilakukan dengan menentukan karakteristik dari suatu sistem selain aktivitas yang harus dilakukan oleh sistem itu sendiri.
96 d. Prioritize requirements Ketika persyaratan sistem telah sepenuhnya dimengerti dan detail model dari persyaratan sistem telah lengkap, penting rasanya untuk menentukan
functional
requirements
dan
nonfunctional
requirements mana yang paling krusial untuk sistem. Terkadang, user atau pengguna menyarankan fungsi sistem tambahan yang diinginkan namun tidak diperlukan. Bagaimanapun juga, pengguna dan system analyst harus bertanya kepada diri mereka sendiri fungsi mana yang benar-benar penting dan fungsi mana yang penting namun tidak begitu dibutuhkan. e. Develop user interface dialogs Ketika suatu sistem menggantikan sistem lama yang melakukan pekerjaan yang sama, user atau pengguna biasanya sangat yakin dengan persyaratan sistem dan tampilan user interface yang diinginkan oleh sistem. Tahapan ini merupakan tahap di mana system analyst melakukan identifikasi dan merancang dialog untuk user interface yang dibutuhkan di dalam sistem. f. Evaluate requirements with users Tahapan ini merupakan tahap di mana system analyst melakukan evaluasi persyaratan sistem yang telah dibuat bersama user atau pengguna. Biasanya, aktivitas di dalam mengevaluasi persyaratan sistem dengan user atau pengguna dan mendokumentasikan persyaratan sistem tersebut terintegrasi secara total. Namun, pada kenyataannya, user atau pengguna biasanya memiliki tanggung jawab lain selain mengembangkan suatu sistem yang baru. Jadi, system analyst biasanya menggunakan iterative process atau proses iterasi untuk mendapatkan masukan pengguna. Mengevaluasi persyaratan sistem yang telah dibuat tidak selalu merupakan aktivitas yang didefinisikan dengan baik. Banyak alternatif muncul untuk desain akhir dan implementasi dari suatu sistem. Jadi, sangat penting untuk mendefinisikannya dengan perlahan-lahan lalu mengevaluasi segala kemungkinan yang ada. Diagram yang digunakan di dalam object-oriented analysis adalah sebagai berikut:
97 a. Activity diagram Activity diagram merupakan jenis workflow diagram yang menggambarkan aktivitas pengguna di dalam sistem secara berurutan.
Gambar 2.38 Contoh Activity Diagram (Satzinger, Jackson, dan Burd) b. Use Case Diagram Use case diagram digunakan untuk menunjukkan interaksi pengguna (actors) dengan suatu sistem. Actor merupakan pengguna dari suatu sistem yang secara langsung berinteraksi dengan sistem itu sendiri. Berikut ini adalah komponen-komponen dari suatu Use Case Diagram: 1. System Boundary Menggambarkan batasan antara sistem dengan actor. 2. Use case Menggambarkan apa yang dilakukan oleh actor di dalam sistem. 3. Actor Menggambarkan user atau pengguna dari suatu sistem. 4. Flow Menggambarkan hubungan antara use case dengan actor.
98
Gambar 2.39 Contoh Use Case Diagram (Satzinger, Jackson, dan Burd) Use case description merupakan dokumen selanjutnya yang harus dibuat ketika use case diagram telah selesai dirancang. Use case description merupakan deskripsi rinci dari setiap use case yang ada di dalam use case diagram.
Gambar 2.40 Contoh Use Case Description (Satzinger, Jackson, dan Burd)
99 c. Statechart Diagram Statechart diagram digunakan untuk menjelaskan behavior umum dari semua objek yang ada di dalam class, menggambarkan daur hidup objek dan macam-macam state serta kejadian dari objek tersebut. Satzinger, Jackson, dan Burd (2005:237) menyatakan bahwa notasinotasi yang ada di dalam statechart diagram adalah sebagai berikut: 1. Beginning pseudostate Merupakan notasi yang menandakan awal dari suatu statechart diagram. 2. State Merupakan notasi yang menunjukkan keadaan dari suatu objek. 3. Transition Merupakan notasi yang memindahkan objek dari state asal menuju state tujuan. 4. Transition name Merupakan notasi yang menjelaskan nama dari suatu transition. 5. Ending pseudostate Merupakan notasi yang menandakan akhir dari suatu statechart diagram.
Gambar 2.41 Contoh Statechart Diagram (Satzinger, Jackson, dan Burd)
100 2.2.7.2 Object-Oriented Design Perancangan sistem dibagi menjadi beberapa tahapan yaitu sebagai berikut: 2.2.7.2.1
Design the support services architecture and deployment environment Deployment environment terdiri dari perangkat keras, perangkat lunak, dan jaringan di mana sistem akan dijalankan. Single-computer architecture merupakan arsitektur yang menggunakan
sistem
komputer
tunggal
di
dalam
menjalankan semua software aplikasi yang berhubungan, sedangkan multitier architecture merupakan arsitektur yang mendistribusikan software aplikasi yang berhubungan atau memproses beban di beberapa sistem komputer. Multitier architecture dapat dibagi menjadi dua macam, yaitu sebagai berikut: a. Clustered architecture Merupakan satu kelompok komputer yang memiliki tipe dan spesifikasi yang sama yang saling berbagi pemrosesan beban dan bertindak layaknya suatu sistem komputer yang besar. b. Multicomputer architecture Merupakan satu kelompok komputer yang memiliki tipe dan spesifikasi yang berbeda yang saling berbagi pemrosesan beban melalui fungsi yang khusus. Centralized
architecture
merupakan
arsitektur
yang
menempatkan semua sumber daya komputer di lokasi pusat, sedangkan distributed architecture merupakan arsitektur yang menyebarkan sumber daya komputer di berbagai lokasi yang dihubungkan oleh suatu jaringan komputer.
101
Gambar 2.42 Single-computer, Clustered, dan Multicomputer Architectures (Satzinger, Jackson, dan Burd) 2.2.7.2.2 Design the software architecture Software architecture dapat dibagi menjadi dua macam, yaitu sebagai berikut: a. Client/server
architecture
(two-layer
architecture),
merupakan arsitektur yang terdiri dari client layer dan server layer.
Gambar 2.43 Client/Server Architecture (Satzinger, Jackson, dan Burd) b. Three-layer
architecture,
merupakan
arsitektur
client/server yang membagi suatu aplikasi menjadi view layer, business logic layer, dan data layer. View layer merupakan layer yang menerima inputan pengguna dan kemudian menampilkan pemrosesan input tersebut menjadi output.
102 Business
logic
layer
merupakan
layer
yang
mengimplementasi aturan dan prosedur dari business processing. Data
layer
merupakan
layer
yang
mengatur
penyimpanan data, biasanya di satu atau lebih dari satu database.
Gambar 2.44 Three-layer Architecture (Satzinger, Jackson, dan Burd) 2.2.7.2.3
Design the use case realizations a. Class Diagram Class diagram digunakan untuk menunjukkan class dari objek tertentu di dalam suatu sistem. Satzinger, Jackson, dan Burd (2005:185) menyatakan bahwa class diagram memiliki tiga bagian penting, yaitu sebagai berikut: 1. Class name Merupakan nama dari suatu class. 2. Attribute Merupakan atribut-atribut yang dimiliki oleh suatu class. 3. Method (behaviour) Menjelaskan apa saja yang bisa dilakukan oleh objek-objek di dalam suatu class.
103
Gambar 2.45Contoh Class Hubungan di dalam class diagram ada tiga, yaitu sebagai berikut: 1. Aggregation Merupakan hubungan antara objek dengan bagianbagiannya di mana bagian-bagian tersebut dapat muncul secara terpisah. 2. Association Merupakan class yang merepresentasikan many-tomany relationship antara dua class lainnya. 3. Generalization Merupakan suatu super class yang menjelaskan properties umum kepada kelas-kelas khusus yang disebut dengan subclass. First-cut design class diagram dikembangkan dengan dua langkah, yaitu sebagai berikut: 1. Menambahkan
tipe
atribut
dan
initial
value
information. 2. Menambahkan panah navigation visibility. Berikut adalah pedoman di dalam menambahkan panah navigation visibility: 1. Hubungan one-to-many biasanya dinavigasikan dari class superior ke class subordinate. 2. Hubungan mandatory, di mana objek dari suatu class tidak bakal ada tanpa ada objek dari class yang lain,
biasanya
dinavigasikan
dari class yang
104 independen (tidak bergantung) ke class yang dependen (bergantung). 3. Ketika suatu objek membutuhkan informasi dari objek yang lain, maka panah navigation visibility akan menunjuk ke arah class yang dibutuhkan. Domain model class diagram diubah menjadi updated design class diagram dengan menambahkan tipe data atribut dan visibility serta menambahkan method di dalamnya.
Gambar 2.46 Contoh Updated Design Class Diagram (Satzinger, Jackson, dan Burd) b. Sequence Diagram Sequence
diagram
digunakan
untuk
menjelaskan
interaksi beberapa objek pada waktu tertentu secara berurutan. Satzinger, Jackson, dan Burd (2005:229) menyatakan bahwa notasi di dalam sequence diagram adalah sebagai berikut:
105 1. Actor Merupakan pengguna yang berinteraksi secara langsung dengan sistem. 2. Input messages Merupakan pesan input dari pengguna ke dalam suatu sistem. 3. Output messages Merupakan pesan output dari suatu sistem ke pengguna, hasil dari pemrosesan input. 4. Objects Merupakan objek-objek yang berinteraksi di dalam sequence diagram. 5. Object lifeline Menggambarkan urutan pesan dari atas ke bawah. Perancangan sequence diagram dimulai dari system sequence
diagram.
System
sequence
diagram
menggambarkan hubungan input dan output antara actor dan sistem untuk suatu use case atau skenario.
Gambar 2.47 Contoh System Sequence Diagram (Satzinger, Jackson, dan Burd) First-cut sequence diagram dikembangkan berdasarkan system sequence diagram. First-cut sequence diagram
106 menentukan objek mana saja yang dibutuhkan untuk menjalankan suatu use case atau skenario. Di dalam first-cut sequence diagram, kita mengganti :System dengan sebuah objek controller dari suatu use case, kemudian menambah objek-objek lain yang dibutuhkan
di
dalam
suatu
use
case.
Langkah
selanjutnya adalah menentukan pesan mana yang perlu dikirimkan
untuk
mengumpulkan
informasi
yang
dibutuhkan, termasuk objek mana yang akan menjadi source dan objek mana yang akan menjadi destination. Gunakan activation lifelines untuk mengindikasikan suatu objek yang sedang menjalankan suatu method.
Gambar 2.48 Contoh First-Cut Sequence Diagram (Satzinger, Jackson, dan Burd) Multi
layer
sequence
diagram
dikembangkan
berdasarkan first-cut sequence diagram yang telah dibuat. Beberapa
hal
yang
perlu
diperhatikan
dalam
mengembangkan view layer sequence diagram adalah sebagai berikut: 1. Merancang user interface untuk setiap use case. 2. Mengembangkan dialog design untuk setiap form.
107 3. Menambahkan class window ke dalam sequence diagram. Beberapa
hal
yang
perlu
diperhatikan
dalam
mengembangkan data access layer sequence diagram: 1. Inisialisasi domain objects dengan data dari suatu database. 2. Buatlah query untuk database dan kirim sebuah objek referensi. 3. Masukkan return information di dalam objek referensi.
Gambar 2.49 Contoh Multi Layer Sequence Diagram (Satzinger, Jackson, dan Burd) c. Communication Diagram Communication diagram dan sequence diagram samasama adalah interaction diagram, dan mereka berisi informasi yang sama. Proses perancangan sistem menggunakan communication diagram atau sequence diagram akan menghasilkan informasi yang sama.
108 Untuk actor, object, dan message, communication diagram menggunakan simbol yang sama dengan sequence diagram, namun simbol lifeline dan activation lifeline tidak digunakan di dalam communication diagram. Bagaimanapun juga, sebuah simbol yang lain, yaitu simbol link digunakan di dalam perancangan communication diagram. Link merupakan sebuah notasi di dalam communication diagram yang membawa message di antara object atau di antara actor dan object.
Gambar 2.50 Contoh Communication Diagram (Satzinger, Jackson, dan Burd) d. Package Diagram Package diagram merupakan suatu diagram UML yang mengizinkan
perancang
untuk
mengasosiasikan
beberapa class dari grup yang saling berkaitan. Salah satu pilihan adalah dengan memisahkan view layer, domain layer, dan data access layer ke dalam package yang berbeda.
109 Kesimpulannya, package diagram digunakan untuk menunjukkan komponen yang saling berkaitan. Kita menggunakan package diagram untuk mengaitkan beberapa class atau komponen sistem lainnya.
Gambar 2.51 Contoh Package Diagram (Satzinger, Jackson, dan Burd) 2.2.7.2.4 Design the database a. Object-Oriented Database Object
database
management
system
(ODBMS)
merupakan suatu sistem manajemen database yang menyimpan data sebagai objek atau class dengan bahasa pemrograman berbasis objek. Untuk membuat object database schema dari suatu class diagram, step-step yang dibutuhkan adalah sebagai berikut: 1. Tentukan class mana yang membutuhkan persistent storage. 2. Representasikan persistent classes. 3. Representasikan asosiasi antara persistent classes. 4. Pilih tipe data yang sesuai dan batasan value untuk setiap field.
110 Class dapat dibagi menjadi dua macam untuk kegunaan data manajemen, yaitu sebagai berikut: 1. Transient class, merupakan class yang tidak perlu menyimpan nilai atribut objek antara instantiations dan method invocations. 2. Persistent class, merupakan class yang harus menyimpan satu atau lebih nilai atribut objek antara instantiations dan method invocations. Ada 2 macam asosiasi di dalam ODBMS, yaitu sebagai berikut: 1. One-to-many associations, dan 2. Many-to-many associations. b. Relational Database Relational database management system (RDBMS) merupakan suatu sistem manajemen database yang menyimpan data di dalam tabel. Beberapa istilah yang terdapat di dalam relational database management system adalah sebagai berikut: 1. Table, merupakan strukur data dua dimensi yang terdiri dari baris dan kolom, biasanya disebut juga dengan relation. 2. Rows, merupakan porsi dari suatu tabel yang berisi data yang mendeskripsikan satu class, asosiasi atau objek, biasanya disebut juga dengan tuple atau record. 3. Attribute, merupakan kolom dari relational model database table, biasanya disebut juga dengan field. 4. Attribute value, merupakan nilai data yang disimpan di dalam sel tunggal di dalam relational model database, biasanya disebut juga dengan field value atau elemen data. 5. Key, merupakan atribut yang berisi nilai yang bersifat unik di dalam setiap baris di dalam tabel relational database.
111 6. Primary key, merupakan key yang digunakan untuk mengidentifikasi suatu baris secara unik di dalam tabel relational database. 7. Foreign key, merupakan nilai atribut yang disimpan di dalam suatu tabel relational database yang juga ada sebagai primary key di tabel relational database lainnya. Untuk membuat relational database schema, ikuti langkah-langkah berikut ini: 1. Buatlah tabel untuk setiap class. 2. Pilih primary key untuk setiap tabel. 3. Tambahkan foreign key untuk merepresentasikan hubungan one-to-many. 4. Buatlah
tabel
baru
untuk
merepresentasikan
hubungan many-to-many. 5. Representasikan klasifikasi hirarki. 6. Tentukan batasan integritas referensial. 7. Evaluasi kualitas schema dan buatlah perbaikan yang diperlukan. 8. Pilih tipe data yang sesuai dan value restrictions untuk setiap field (jika diperlukan). 2.2.7.2.5 Design the system and user interfaces a. System interfaces System interfaces merupakan input dan output di dalam suatu sistem tanpa adanya campur tangan user atau pengguna.
Dengan
kata
lain,
system
interfaces
merupakan hubungan antar sistem. Berikut ini merupakan beberapa kategori dari system interfaces: 1. Input dari sistem lain. 2. Input yang sangat terotomatisasi. 3. Input dari data di database eksternal. 4. Output menuju database eksternal. 5. Output dengan tanpa human computer interaction. 6. Output menuju sistem lain.
112 7. Real-time connection (baik input maupun output). b. User Interface User interface terdiri dari input dan output yang melibatkan pengguna sistem secara langsung. Ada tiga aspek yang penting di dalam perancangan user interface, yaitu sebagai berikut: 1. Physical aspects, terdiri dari perangkat yang disentuh oleh user, termasuk keyboard, mouse, touch screen, atau keypad. 2. Perceptual aspects, terdiri dari semua hal yang dilihat, didengar, atau disentuh oleh pengguna akhir (di luar physical devices), termasuk segala hal yang terdapat di layar monitor. 3. Conceptual aspects, terdiri dari semua hal yang diketahui oleh pengguna di dalam menggunakan sistem. User-centered design merupakan koleksi teknik yang meletakkan
pengguna
di
tengah-tengah
proses
pengembangan user interface. Ada tiga prinsip penting user-centered design, yaitu sebagai berikut: 1. Fokus awal pada pengguna dan pekerjaan mereka. 2. Evaluasi desain untuk memasikan kegunaan. 3. Gunakan pengembangan yang berulang.
Gambar 2.52 Contoh User Interface (Satzinger, Jackson, dan Burd)
