BINA NUSANTARA | Library & Knowledge Center



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:

[pic]

Gambar 2.1 Komponen Sistem Informasi (Satzinger, Jackson, dan Burd)

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

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.

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.

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 instruksi yang mengatur perencanaan penggunaan basis data.

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

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

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 besar kemungkinan sudah memenuhi mission statement.

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.

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.

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.

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.

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.

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.

[pic]

Gambar 2.2 Contoh Binary Relationship

2. Ternary Relationship

Merupakan hubungan antar tiga entitas.[pic]Gambar 2.3 Contoh Ternary Relationship

3. Quarternary Relationship

merupakan hubungan antar empat entitas.[pic]

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.

[pic]

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

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

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

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

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. Controlling area merepresentasikan bagian terpisah dari 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 di-assign 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).

Kita dapat mendefinisikan chart of account dengan jumlah yang tak terbatas di dalam sistem SAP. Di dalam sistem baku SAP, terdapat banyak country-specific 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 setting adalah mendefinisikan mata uang di dalam 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.

[pic]

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

[pic]

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.

[pic]

Gambar 2.8 G/L Document Entry Enjoy Screen

[pic]

Gambar 2.9 G/L Document Entry Complex First Screen

[pic]

Gambar 2.10 G/L Document Entry Complex Second Screen

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.

[pic]

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

[pic]

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

[pic]

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 one-time 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 in Accounts Payable

a. Invoice/Credit Memo Entry

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.

[pic]

Gambar 2.14 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 dengan menggunakan kurs pertukaran mata uang yang telah ditentukan.

[pic]

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

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 di-posting, dan tanggal untuk posting selanjutnya di-update 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

d. Automatic Payment Program Parameters

Program pembayaran dikembangkan untuk transaksi pembayaran internasional antara vendor dan customer. Program ini dapat digunakan untuk incoming payment (pembayaran masuk) atau outgoing payment (pembayaran keluar). Bagaimanapun juga, program ini lebih banyak digunakan untuk pembayaran keluar.

[pic]

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:

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 pembayaran

Langkah terakhir adalah pencetakan media 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 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

[pic]

Gambar 2.17 Procurement Cycle

Berikut ini adalah proses-proses di dalam procurement cycle:

a. Demand determination

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.

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

[pic]

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)

[pic]

Gambar 2.19 Accounts Payable closing operations

Langkah-langkah penutupan di dalam accounts payable adalah sebagai berikut:

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

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.

[pic]

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

[pic]

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.

[pic]

Gambar 2.22 Enjoy Customer Invoice Screen

b. Incoming Payments

Incoming payment (pembayaran masuk) dapat dilakukan dengan beberapa cara di perusahaan-perusahaan 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.

b. Residual item: open invoice dibersihkan dan open item baru (residual item) dengan jumlah sebesar selisih pembayaran dibuat.

[pic]

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 yang telah jatuh tempo. Sistem menentukan dunning level (tingkat 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 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 tagihan ketika program tersebut dijalankan.

[pic]

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 sehari-hari harus di-request terlebih dahulu sebelum dapat dicetak. Permintaan korespondensi dapat dilakukan dengan:

a. Otomatis, ketika transaksi khusus seperti bill of exchange charges statement (laporan biaya pertukaran) atau payment notice (peringatan pembayaran) di-post

b. Manual, dilakukan oleh bagian akuntansi

c. Menggunakan program request yang menghasilkan permintaan korespondensi dalam jumlah yang besar secara bersamaan (seperti periodic account statement, internal document, standard letter)

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 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, dan divisi) harus mendefinisikan sales area-specific 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.

[pic]

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 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 yang berhubungan di dalam proses penjualan.

[pic]

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.

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

[pic]

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.

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.

[pic]

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 faktor-faktor 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 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 di-assign 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. 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 di-post 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.

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

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.

[pic]

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

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.

[pic]

Gambar 2.30 Asset Explorer

[pic]

Gambar 2.31 Asset Explorer

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.

[pic]

Gambar 2.32 Asset closing operations

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

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

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 journal yang secara unik diidentifikasikan oleh kode sebanyak 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.

[pic]

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

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

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 di-post 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

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

2.2.2.3.6 Preparing Financial Statement

2.2.2.3.6.1 Financial Closing in the General Ledger

a. General Ledger Closing

[pic]

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 forward dijalankan. Hal ini memastikan bahwa saldo dari G/L 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 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.

[pic]

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

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

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:

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.

[pic]

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.

[pic]

Gambar 2.37 Cost-of-Sales Accounting

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

2.2.3 E-Learning

2.2.3.1 Pengertian E-Learning

Effendi dan Zhuang (2005:6) menyatakan bahwa kata e-learning 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.

2.2.3.4 Prinsip E-Learning

Clark dan Mayer (2003:51) menyatakan bahwa terdapat beberapa prinsip yang harus digunakan di dalam mengimplementasi e-learning, 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.

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

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

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 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 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 juga setelah produk ini selesai diimplementasikan.

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.

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:

a. Activity diagram

Activity diagram merupakan jenis workflow diagram yang menggambarkan aktivitas pengguna di dalam sistem secara berurutan.

[pic]

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.

[pic]

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.

[pic]

Gambar 2.40 Contoh Use Case Description (Satzinger, Jackson, dan Burd)

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

[pic]

Gambar 2.41 Contoh Statechart Diagram (Satzinger, Jackson, dan Burd)

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.

[pic]

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.

[pic]

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.

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.

[pic]

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.

[pic]

Gambar 2.45Contoh Class

Hubungan di dalam class diagram ada tiga, yaitu sebagai berikut:

1. Aggregation

Merupakan hubungan antara objek dengan bagian-bagiannya di mana bagian-bagian tersebut dapat muncul secara terpisah.

2. Association

Merupakan class yang merepresentasikan many-to-many 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 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.

[pic]

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:

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.

[pic]

Gambar 2.47 Contoh System Sequence Diagram (Satzinger, Jackson, dan Burd)

First-cut sequence diagram dikembangkan berdasarkan system sequence diagram. First-cut sequence diagram 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.

[pic]

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.

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.

[pic]

Gambar 2.49 Contoh Multi Layer Sequence Diagram (Satzinger, Jackson, dan Burd)

c. Communication Diagram

Communication diagram dan sequence diagram sama-sama adalah interaction diagram, dan mereka berisi informasi yang sama. Proses perancangan sistem menggunakan communication diagram atau sequence diagram akan menghasilkan informasi yang sama.

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.

[pic]

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.

Kesimpulannya, package diagram digunakan untuk menunjukkan komponen yang saling berkaitan. Kita menggunakan package diagram untuk mengaitkan beberapa class atau komponen sistem lainnya.

[pic]

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.

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.

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.

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.

[pic]

Gambar 2.52 Contoh User Interface (Satzinger, Jackson, dan Burd)

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download