6

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.
OBrien (2005:6) mendefinisikan sistem informasi sebagai
suatu kombinasi yang terorganisasi dari manusia, perangkat keras,
perangkat lunak, jaringan komunikasi, dan sumber daya data yang
mengumpulkan, mengubah, dan menyebarluaskan informasi di dalam
suatu perusahaan.
Stair dan Reynolds (2006:4) mendefinisikan sistem informasi
sebagai sekumpulan komponen yang saling berkaitan yang berfungsi
untuk mengumpulkan, memanipulasi, menyimpan, menyebarluaskan
data dan informasi yang diperlukan serta menyediakan mekanisme
umpan balik untuk mencapai suatu tujuan tertentu.
2.1.1.2 Komponen Sistem Informasi
Satzinger, Jackson, dan Burd (2005:8) menyatakan bahwa
komponen sistem informasi dapat digambarkan sebagai berikut:

Gambar 2.1 Komponen Sistem Informasi (Satzinger, Jackson, dan

Burd)
 7

OBrien (2005:22) menyatakan bahwa suatu sistem informasi

yang dinamis akan memiliki tiga komponen dasar yang saling
berinteraksi, yaitu sebagai berikut:
a. Input
Melibatkan pengambilan elemen yang memasuki suatu sistem
untuk kemudan diproses menjadi informasi.
b. Processing
Melibatkan proses yang mengubah input menjadi output.
c. Output
Melibatkan pengalihan elemen yang diproduksi oleh proses
perubahan kepada tujuan akhirnya.
2.1.2 Perangkat Lunak
2.1.2.1 Pengertian Perangkat Lunak
Pressman (2005:36) mendefinisikan perangkat lunak sebagai:
a. Instruksi (program komputer) yang ketika dijalankan menyediakan
fitur, fungsi, dan kinerja yang diinginkan.
b. Struktur data yang memungkinkan suatu program untuk
memanipulasi informasi.
c. Dokumen yang menggambarkan operasi dan kegunaan dari suatu
program.
2.1.2.2 Karakteristik Perangkat Lunak
Pressman (2005:37) menyatakan bahwa perangkat lunak
memiliki karakteristik yang berbeda dari perangkat keras, yaitu sebagai
berikut:
a. Perangkat lunak dikembangkan atau direkayasa, bukan diproduksi
dalam pengertian klasik
Walaupun terdapat beberapa persamaan di dalam pengembangan
perangkat lunak dan perangkat keras, namun kedua aktivitas ini
pada dasarnya sangat amat berbeda. Dari kedua aktivitas tersebut,
kualitas yang tinggi dicapai melalui desain yang baik, namun fase
manufaktur untuk perangkat keras dapat menjelaskan masalah
kualitas yang tidak terdapat pada perangkat lunak. Kedua aktivitas
tersebut membutuhkan konstruksi produk, namun dengan
pendekatan yang berbeda. Biaya perangkat lunak terpusat pada
8

bidang perekayasaan. Jadi kesimpulannya, proyek perangkat lunak

tidak dapat dikelola seperti proyek pemanufakturan.
b. Perangkat lunak tidak usang atau habis terpakai
Tingkat kegagalan perangkat keras yang tinggi biasanya disebabkan
oleh kesalahan perancangan atau kesalahan pembuatan di pabrik.
Setelah diperbaiki, biasanya tingkat kegagalan akan menurun
hingga ke suatu tingkat yang stabil untuk periode waktu tertentu.
Seiring dengan berjalannya waktu, tingkat kegagalan akan
meningkat kembali akibat pengaruh lingkungan terhadap komponen
perangkat keras. Dengan kata lain, perangkat keras menjadi usang.
Sedangkan pada perangkat lunak, tingkat kegagalan yang tinggi
biasanya disebabkan oleh keadaan yang tidak diperkirakan
sebelumnya. Setelah diperbaiki, tingkat kegagalan tersebut akan
menurun hingga ke suatu tingkat yang stabil. Jadi kesimpulannya,
perangkat lunak tidak akan pernah usang atau habis terpakai.
c. Meskipun industri bergerak menuju konstruksi berbasis komponen
(component-based construction), sebagian besar perangkat lunak
masih dibangun seperti biasa (custom built)
Komponen perangkat lunak seharusnya dirancang dan
diimplementasikan sehingga dapat digunakan berulang-ulang pada
beberapa program yang berbeda. Komponen yang dapat digunakan
berulang-ulang membungkus data dan proses yang diaplikasikan
kepada data, memungkinkan perekayasa perangkat lunak untuk
menciptakan aplikasi baru dari bagian yang dapat digunakan
berulang-ulang.
2.1.2.3 Proses Perangkat Lunak
Sommerville (2011:9) menyatakan bahwa proses di dalam suatu
perangkat lunak ada empat, yaitu sebagai berikut:
a. Software specification
Di mana pelanggan dan perekayasa mendefinisikan perangkat lunak
yang akan dikembangkan dan batasan-batasan pada operasinya.
b. Software development
Di mana perangkat lunak dirancang dan diprogram.
 9

c. Software validation
Di mana perangkat lunak dicek untuk memastikan bahwa perangkat
lunak tersebut adalah apa yang dibutuhkan oleh pelanggan.
d. Software evolution
Di mana perangkat lunak dimodifikasi untuk memenuhi perubahan
kebutuhan dari pelanggan dan kebutuhan pasar.
2.1.2.4 Rekayasa Perangkat Lunak
Bauer, di dalam buku karangan Pressman (2005:53)
mendefinisikan rekayasa perangkat lunak sebagai pembentukan dan
penggunaan prinsip-prinsip rekayasa suara untuk menghasilkan
perangkat lunak yang ekonomis yang handal dan bekerja secara efisien
pada mesin nyata.
IEEE (Institute of Electrical and Electronics Engineers), di
dalam buku karangan Pressman (2005:53) mendefinisikan rekayasa
perangkat lunak sebagai suatu penerapan pendekatan sistematis,
disiplin, dan dapat diukur untuk pengembangan, operasi, dan
pemeliharaan perangkat lunak, yaitu penerapan rekayasa perangkat
lunak.
Sommerville (2011:24) mendefinisikan rekayasa perangkat
lunak sebagai disiplin rekayasa yang berkaitan dengan segala aspek
dari produksi perangkat lunak.
2.1.3 Interaksi Manusia dan Komputer
2.1.3.1 Pengertian Interaksi Manusia dan Komputer
Shneiderman dan Plaisant (2010:22) menyatakan bahwa
interaksi manusia dan komputer berkaitan dengan tampilan interface
yang digunakan oleh pengguna untuk berkomunikasi dan berinteraksi
dengan komputer.
Interaksi manusia dan komputer merupakan disiplin ilmu yang
berhubungan dengan perancangan, evaluasi, dan implementasi sistem
komputer interaktif yang diinginkan manusia. Kepentingan pengguna
harus diperhatikan di dalam membuat aplikasi komputer. Maka
diharapkan aplikasi yang dihasilkan harus seinteraktif mungkin dan
dapat digunakan dengan mudah oleh para pengguna.
10

2.1.3.2 Prinsip Perancangan Antarmuka

Shneiderman dan Plaisant (2010:74) menyatakan bahwa prinsip
perancangan antarmuka mengacu kepada delapan aturan emas atau
eight golden rules, yaitu sebagai berikut:
a. Usahakan untuk konsisten
Perancangan menu, warna, tampilan, jenis huruf pada antarmuka
harus dilakukan dengan konsisten.
b. Memenuhi kegunaan universal
Pengguna antarmuka sangat beragam, sehingga di dalam
merancang layar harus mempertimbangkan perbedaan di dalam hal
usia, hambatan fisik, dan variasi teknologi. Jadi, ada pemberian
petunjuk kepada pengguna pemula dan shortcut bagi pengguna
yang telah berpengalaman.
c. Memberikan umpan balik yang informatif
Untuk setiap aksi yang dilakukan oleh pengguna, harus diberikan
umpan balik agar tercipta suasana yang komunikatif. Pada aksi
yang bersifat kecil dan sering digunakan, respon yang diberikan
sederhana. Namun, pada aksi yang bersifat rumit dan jarang
digunakan, respon yang diberikan harus lebih rinci.
d. Merancang dialog untuk menghasilkan penutupan
Di dalam merancang komunikasi arus balik dengan pengguna,
urutan tindakan harus diatur sedemikian rupa dengan mengetahui
keadaan awal, tengah, dan tentu saja akhir.
e. Mencegah terjadinya kesalahan
Sebisa mungkin, suatu sistem dirancang untuk dapat mencegah
pengguna dari kesalahan fatal yang dapat terjadi. Sebagai contoh,
terdapat validasi pada formulir. Apabila pengguna melakukan
kesalahan, maka sistem harus menyediakan instruksi kepada
pengguna tentang bagaimana cara memperbaiki kesalahan tersebut.
f. Memungkinkan pembalikan aksi yang mudah
Ketika pengguna tidak sengaja melakukan aksi yang tidak
diinginkan dan ingin melakukan pembatalan, sistem harus
menyediakan fungsi pembatalan agar pengguna merasa nyaman dan
tidak takut di dalam mengeksplorasi sistem.
 11

g. Mendukung pusat kendali internal

Pengguna memiliki kekuasaan atas suatu sistem sehingga dapat
mengontrol program-program yang ada di dalam sistem tersebut.
h. Mengurangi beban ingatan jangka pendek
Tampilan harus dibuat sesederhana mungkin sehingga pengguna
tidak perlu banyak mengingat. Tampilan dari setiap halaman harus
diperkuat dan frekuensi perpindahan jendela harus diminimalisasi.
2.1.4 Basis Data
2.1.4.1 Pengertian Basis Data
Connoly dan Begg (2010:65) mendefinisikan basis data sebagai
sekumpulan data yang berhubungan secara logikal serta dirancang
untuk memenuhi kebutuhan informasi yang dibutuhkan suatu
organisasi.
Williams dan Sawyer (2010:164) mendefinisikan basis data
sebagai koleksi data yang disimpan secara elektronik dalam sistem
komputer.
2.1.4.2 Database Management System
Connoly dan Begg (2010:68) menyatakan bahwa terdapat
beberapa komponen Database Management System, yaitu sebagai
berikut:
a. Hardware (perangkat keras)
DBMS membutuhkan perangkat keras untuk menjalankan
aplikasinya. Perangkat keras tersebut dapat meliputi suatu PC,
mainframe atau jaringan komputer.
b. Software (perangkat lunak)
Komponen perangkat lunak itu sendiri berupa program aplikasi atau
OS (Operating System).
c. Data
Data merupakan komponen yang penting dalam DBMS dan berasal
dari sudut pandang pengguna. Data berperan sebagai penghubung
antara pengguna dan mesin.
d. Prosedur
Prosedur merupakan instruksi yang mengatur perencanaan
penggunaan basis data.
12

e. Sumber Daya Manusia

Komponen terakhir merupakan manusia yang berhubungan dengan
sistem, cakupannya adalah sebagai berikut:
1. Data Administration
Mengatur sumber daya data, meliputi perencanaan basis data,
pengembangan dan pemeliharaan standar dan desain basis data
secara logikal dan konseptual.
2. Database Administration
Mengatur realisasi fisik dari aplikasi basis data yang meliputi
desain fisik dan implementasi, keamanan dan pengawasan
performa sistem dan pengaturan ulang basis data.
3. Database Designer
Database Designer logikal mengidentifikasi data berupa entitas
dan atribut, relasi antar data dan batasan data yang disimpan,
sedangkan Database Designer fisikal yang menentukan
bagaimana desain logikal akan diimplementasikan.
4. Application Developer
Mengembangkan program aplikasi yang menyediakan
kebutuhan pengguna akhir.
5. End-User (pengguna akhir)
Pengguna akhir dapat digolongkan menjadi dua bagian, yaitu
sebagai berikut:
a. Naive Users, merupakan pengguna yang tidak perlu tahu
mengenai Database Management Lifecycle.
b. Sophisticated Users, merupakan pengguna yang perlu tahu
mengenai Database Management Lifecycle.
Pada umumnya, Database Management System memiliki
fasilitas sebagai berikut:
a. Fasilitas untuk mendefinisikan basis data dengan menggunakan
sebuah Data Definition Language (DDL). DDL mengizinkan
pengguna untuk menentukan tipe, struktur dan batasan yang dapat
disimpan ke dalam basis data tersebut.
b. Fasilitas yang dapat membantu pengguna menambah, mengubah,
menghapus dan mengambil kembali data dari basis data yang
umumnya menggunakan Data Manipulation Language (DML).
 13

Selain itu ada fasilitas yang melayani akses data yang dinamakan
query language.
c. Fasilitas untuk mengontrol basis data dengan menggunakan Data
Control Languange (DCL). Akses yang dilingkupi oleh fasilitas ini
ada beberapa, yaitu sebagai berikut:
1. Sistem keamanan yang mencegah pengguna yang tidak
memiliki wewenang untuk mengakses data.
2. Sistem yang memelihara konsistensi suatu data.
3. Sistem yang membagi akses ke dalam suatu basis data.
4. Sistem kontrol pengembalian data yang dapat mengembalikan
data kepada kondisi sebelumnya jika terjadi kegagalan
perangkat.
5. Deskripsi data yang ada dalam basis data.
Connoly dan Begg (2010:77) menyatakan bahwa terdapat
beberapa keuntungan dari penggunaan DBMS, yaitu sebagai berikut:
a. Kontrol terhadap redundansi data
Basis data berusaha menghilangkan pengulangan dengan
melakukan integrasi file sehingga berbagai copy dari data yang
sama tidak tersimpan.
b. Konsistensi data
Dengan adanya pengendalian data dengan menghilangkan
redundansi, data yang tidak konsisten data dapat dihindari. Jika data
yang terdapat di dalam sistem hanya disimpan dalam satu tempat,
maka update cukup dilakukan sekali dan nilai baru akan tersedia
bagi semua pengguna.
c. Banyaknya informasi dari data yang sama
Dengan terintegrasinya data yang terdapat dalam sistem maka
memungkinkan organisasi mendapatkan informasi tambahan yang
lebih berkualitas.
d. Pengaksesan data oleh beberapa user dalam waktu yang sama
Keuntungan ini memungkinkan setiap pengguna mendapatkan data
dari sumber yang sama berdasarkan otoritas yang mereka miliki.
14

e. Meningkatkan integritas data

Integritas mengacu pada validitas dan konsistensi data yang
tersimpan. Integritas biasanya didefinisikan sebagai batasan yang
tidak boleh dilanggar oleh sistem basis data.
f. Meningkatkan keamanan
Keamanan basis data melindungi basis data penggunaan oleh pihak
yang tidak berotoritas. Hal ini dapat dilakukan dengan pemanfaatan
sistem username dan password dalam menggunakan sistem. Akses
yang dilingkupi antara lain retrieval, insert, update dan delete data.
g. Menetapkan standarisasi dalam penyajian data
Integrasi ini didefinisikan dalam pembuatan standar yang
diperlukan dalam suatu organisasi. Hal ini berguna untuk
memfasilitasi pertukaran data antara sistem, ketetapan penamaan,
standar dokumentasi, dan prosedur pengaturan hak akses.
h. Mengurangi biaya
Biaya pengembangan dan pemeliharaan sistem yang baru
diharapkan akan menghasilkan total biaya yang lebih rendah.
i. Menyeimbangkan konflik dari kebutuhan yang ada
Setiap pengguna mempunyai kebutuhan yang berbeda-beda dengan
adanya sistem basis data akan menyediakan penggunaan terbaik
dari sumber daya bagi keseluruhan organisasi.
j. Meningkatkan aksesibilitas, produktifitas penggunanya
DBMS dapat meningkatkan aksesibilitas dan produktivitas para
penggunanya.
k. Backup dan recovery
DBMS memiliki kemampuan dalam pengelolaan data dengan
beberapa fasilitas backup dan recovery.
Connoly dan Begg (2010:77) menyatakan bahwa terdapat
beberapa kerugian dari penggunaan DBMS, yaitu sebagai berikut:
a. Kompleksitas
Dalam menjaga reliabilitas data yang terdapat dalam suatu sistem,
maka seringkali replikasi DBMS digunakan. Dengan
dijalankannnya prosedur ini maka menimbulkan berbagai macam
masalah yang kompleks dimana Database Administrator (DBA)
harus dapat menyediakan pengaksesan data yang lebih cepat,
 15

handal dan up-to-date. Jika aplikasi dalam DBMS tidak dapat

menangani hal tersebut selanjutnya akan terjadi penurunan kinerja
dari DBMS.
b. Ukuran
Dengan kompleksitas yang ada, DBMS menjadi perangkat lunak
yang sangat besar sehingga memerlukan banyak ruang hard disk
dan jumlah memory yang besar untuk dapat berjalan dengan baik.
c. Biaya
Biaya dari pembelian DBMS yang tidak murah serta terdapat
pemeliharaan tahunan membuat biaya dari DBMS menjadikan total
keseluruhannya tidak sedikit.
d. Tambahan biaya perangkat keras
Kebutuhan tempat penyimpanan bagi DBMS memerlukan
pembelian tempat penyimpanan tambahan. Kemudian untuk
mencapai hasil yang diinginkan diperlukan lagi tambahan biaya
yang lebih besar.
e. Biaya dari proses konversi
Selain kedua biaya di atas, DBMS juga memerlukan biaya dari
proses konversi yang jumlahnya juga tidak sedikit.
2.1.4.3 Fact Finding Techniques
Connoly dan Begg (2010:341) mendefinisikan fact finding
techniques sebagai suatu proses formal yang menggunakan wawancara
dan menyebarkan kuesioner untuk mengumpulkan fakta tentang sistem,
kebutuhan dan preferensi pengguna.
Terdapat beberapa teknik yang umum digunakan, yaitu sebagai
berikut:
a. Examining Documentation
Dapat berguna saat mencoba mendapatkan keuntungan dari
beberapa informasi latar belakang kemunculan basis data.
b. Interviewing
Teknik wawancara merupakan yang paling umum dalam tahapan
pencarian fakta.
c. Observing the Enterprise in Operation
Merupakan teknik memahami sistem yang memungkinkan
partisipan melihat pengguna dalam menjalankan sistem berjalan.
16

d. Research
Merupakan teknik melakukan penelitian terhadap suatu masalah
dalam suatu sistem.
e. Questionnaire
Merupakan teknik penemuan fakta dengan menyebarkan kuesioner.
2.1.4.4 Database System Development Lifecycle
Connoly dan Begg (2010:314) menyatakan bahwa aktivitas
utama yang ada di setiap langkah dalam Database System Development
Lifecycle adalah sebagai berikut:
a. Database Planning
Perencanaan basis data merupakan aktifitas merencanakan siklus
hidup aplikasi basis data untuk dapat diwujudkan secara efisien dan
efektif. Tiga hal utama yang tekait dengan proses ini adalah sebagai
berikut:
1. Mengidentifikasi rencana dari sistem yang akan dibangun.
2. Evaluasi sistem yang ada untuk menetapkan kelebihan dan
kekurangan sistem.
3. Penaksiran kesempatan IT yang dapat memberikan keuntungan
kompetitif.
Langkah penting di dalam perencanaan basis data adalah sebagai
berikut:
1. Menentukan mission statement
Mission statement merupakan tujuan utama dari sistem basis
data. Mission statement membantu menjelaskan tujuan dari
project dan memberikan arah yang jelas untuk mendapatkan
hasil yang efektif dan efisien dari system basis data yang akan
dibangun.
2. Menentukan mission objectives
Setiap mission objective menjelaskan tugas khusus yang harus
didukung oleh basis data berdasarkan apa yang telah dijabarkan
darimission statement. Sehingga basis data yang telah
memenuhi mission objective besar kemungkinan sudah
memenuhi mission statement.
 17

b. System Definition
Spesifikasi dari lingkup dari sistem basis data meliputi major user
view, user dan area aplikasi. User view menentukan data apa saja
yang boleh diakses oleh pengguna dan memastikan setiap pengguna
terlibat dalam perancangan sistem basis data.
c. Requirement Collection and Analysis
Analisa yang harus dipenuhi untuk kebutuhan sistem basis data
yang baru. Data yang dikumpulkan dapat berupa:
1. Deskripsi mengenai data.
2. Penjelasan mengenai bagaimana cara data dihasilkan.
3. Kebutuhan tambahan untuk sistem basis data yang akan
dibangun.
d. Database Design
Tahap ini merupakan proses merancang basis data yang diinginkan.
Ada dua pendekatan dalam perancangan basis data, yaitu sebagai
berikut:
1. Bottom Up Approach
Pendekatan ini dimulai dari tingkat atribut yang melalui analisis
dan penggabungan untuk kemudian dikelompokkan ke dalam
relasi yang menggambarkan tipe antar entitas. Pendekatan ini
digunakan jika basis data yang ada sederhana dan dengan
jumlah yang sedikit.
2. Top Down Approach
Pendekatan ini dimulai dari pengembangan model data yang
terdiri dari beberapa hubungan relasional dan entitas.
Pendekatan ini biasa digunakan jika basis data yang digunakan
rumit dengan jumlah atribut yang cukup banyak.
Adapun perancangan basis data dapat dibagi menjadi tiga tahapan
utama, yaitu sebagai berikut:
1. Conceptual Database Design
Proses pembangunan suatu model data yang terlepas dari
pertimbangan fisik, hanya menekankan terhadap konsep.
18

2. Logical Database Design

Proses pembangunan model data dari informasi yang diperoleh
berdasarkan penelitian tertentu tapi bebas dari hal teknikal
ataupun yang berkaitan dengan DBMS.
3. Physical Database Design
Proses pembangunan deskripsi implementasi basis data pada
secondary storage, yang menggambarkan struktur penyimpanan
dan metode akses data secara cepat.
Connoly dan Begg (2010:92) mendefinisikan Data Definition
Languange sebagai suatu bahasa yang mengizinkan pengguna
dalam menjelaskan serta memberi nama entitas, atribut dan relasi
yang dibutuhkan beserta kesatuan integritas dan keamanan.
Connoly dan Begg (2010:40) menyatakan bahwa ada beberapa jenis
syntax yang digunakan dalam perancangan hingga pengelolaan
basis data, yaitu sebagai berikut:
1. Data Definition Languange (DDL)
Merupakan bahasa yang digunakan oleh administrator basis
data dalam menjelaskan dan memberi nama suatu entitas,
atribut dan relasi data yang dibutuhkan aplikasi bersamaan
dengan penerapan integritas data.
2. Data Manipulation Languange (DML)
Merupakan bahasa yang digunakan untuk pengelolaan basis
data seperti hal menampilkan (select), menambah (insert),
mengubah data (update), menghapus data (delete).
e. DBMS Selection
Proses pemilihan DBMS yang tepat untuk mendukung sistem basis
data. Pemilihan DBMS yang baik berguna dalam memenuhi
kebutuhan organisasi di masa mendatang dan menyeimbangkan
pengeluaran yang terjadi karena pembelian produk DBMS.
Connoly dan Begg (2010:325) menyatakan bahwa tahap-tahap
dalam pemilihan DBMS adalah sebagai berikut:
1. Menentukan kerangka acuan penelitian.
2. Membatasi hanya 2 sampai 3 pilihan saja.
3. Mengevaluasi produk.
4. Merekomendasikan hasil evaluasi.
 19

f. Application Design
Connoly dan Begg (2010:329) mendefinisikan perancangan aplikasi
sebagai suatu aktivitas merancang antarmuka dan program aplikasi
yang akan menggunakan dan memproses basis data. Dalam
merancang basis data pastikan bahwa fungsionalitas yang
diutarakan dalam rancangan memenuhi kebutuhan pengguna.
g. Prototyping
Connoly dan Begg (2010:329) mendefinisikan prototyping sebagai
suatu aktivitas membangun sebuah model kerja dari aplikasi basis
data yang mengizinkan pengguna untuk visualisasi dan evaluasi
gambaran sistem secara menyeluruh.
Ada dua strategi dalam merancang prototype, yaitu sebagai berikut:
1. Requirements Prototyping
Menggunakan sebuah prototype untuk menentukan kebutuhan
sistem basis data yang diusulkan dan begitu sudah terpenuhi
prototype tidak digunakan lagi.
2. Evolutionary Prototyping
Menggunankan sebuah prototype untuk tujuan yang sama.
Begitu kebutuhan pengguna sudah terpenuhi, prototype tidak
dibuang melainkan dikembangkan menjadi aplikasi basis data
yang akan berjalan.
Beberapa tujuan pembuatan prototype adalah sebagai berikut:
1. Mengidentifikasi fitur yang ada dalam sistem yang berjalan.
2. Melakukan perbaikan terhadap fitur yang ditemukan.
3. Mengelompokkan kebutuhan pengguna.
4. Mengevaluasi kemungkina yang terjadi dari rancangan sistem
khusus.
h. Implementation
Tahap ini berfungsi dalam membuat definisi physical database dan
program aplikasi.
Implementasi basis data dapat dicapai dengan menggunakan:
1. DDL untuk membuat skema basis data dan file basis data
kosong.
2. DDL untuk membuat sudut pandang pengguna yang diinginkan.
20

3. 3GL dan 4GL untuk membuat program aplikasi basis data dan
disertakan dengan menggunakan DML.
i. Data Conversion and Loading
Tahap ini bertujuan dalam pemuatan data ke dalam sistem yang
baru sehingga memungkinkan penggabungan antara aplikasi yang
berjalan dengan basis data yang baru. DBMS memiliki utilitas
untuk memanggil file yang ada ke dalam basis data baru untuk
digunakan dalam aplikasi.
j. Testing
Tahap ini menjalankan uji coba terhadap sistem basis data apabila
ada error dan memvalidasi terhadap spesifikasi kebutuhan
pengguna.
k. Operational Maintenance
Tahap ini berfungsi melakukan pengelolaan terhadap sistem basis
data yang sudah dijalankan.
Tahapan pemeliharaan ini adalah sebagai berikut:
1. Pengawasan kinerja sistem dan pengaturan ulang basis data
akan dilakukan jika penurunan kinerja.
2. Jika diperlukan, pembaharuan sistem basis data.
2.1.4.5 Perancangan Basis Data
Connoly dan Begg (2010:320) mendefinisikan perancangan
basis data sebagai proses pembuatan desain yang membantu
menjelaskan persyaratan misi dari perusahaan dan tujuan dari
kebutuhan sistem basis data.
Tahapan perancangan basis data ada tiga, yaitu sebagai berikut:
a. Tahapan konseptual
Merupakan proses pembangunan model dari data yang digunakan
dalam perusahaan dan tidak tergantung dengan pertimbangan basis
data secara fisikal.
b. Tahapan logikal
Merupakan proses pembangunan model informasi berdasarkan
model data tertentu dan tidak tergantung pada Database
Management System dan pertimbangan fisik lainnya.
 21

c. Tahapan fisikal
Tahapan perancangan basis data fisikal merupakan suatu proses
pembuatan deskripsi tentang implementasi basis data pada
secondary storage, menggambarkan basis relasi, organisasi file dan
indeks yang digunakan untuk mencapai akses data yang efisien
serta integritas terkait dengan pengukuran keamanan.
2.1.4.6 Konsep Dasar Model ER
Connoly dan Begg (2010:371) mendefinisikan ER Modelling
sebagai pendekatan dalam merancang basis data yang dimulai dengan
mengidentifikasi data penting menjadi entitas hingga relationship antar
data harus dipresentasikan dalam model.
Beberapa konsep dasar dalam ER modeling antara lain
attribute, keys, structural constraints, relationship type.
a. Entity (Entitas)
Entitas merupakan objek-objek yang memilik property yang sama
dan diidentifikasi karena keberadaannya yang bebas (independence
existence).
Connoly dan Begg (2010:383) menyatakan bahwa terdapat dua
jenis entitas, yaitu sebagai berikut:
1. Strong Entity Types
Entitas yang keberadaannya tidak bergantung pada entitas
lainnya. Karakter dari strong entity type merupakan setiap
entitas memiliki atribut primary key yang sudah teridentifikasi.
2. Weak Entity Types
Entitas yang keberadaannya bergantung pada entitas lainnya.
Karakteristik dari weak entity merupakan entitas yang tidak
dapat diidentifikasikan dengan menggunakan atribut yang
terkait dengan entitasnya sendiri.
b. Relationship Types
Connoly dan Begg (2010:374) mendefinisikan relationship types
sebagai hubungan antar entitas dan memiliki arti tertentu.
Sedangkan relationship occurrence merupakan suatu gabungan
yang dapat diidentifikasikan secara unik berupa kejadi dari entitas
yang terkait.
22

Derajat dari tipe relasi merupakan jumlah jenis entitas yang terkait
dalam suatu hubungan. Entitas yang terkait dalam hubungan
tersebut dinamakan participant, sedangkan jumlah peserta dalam
suatu jenis relasi disebut derajat relasi.
Derajat dan tipe relasi ada beberapa, yaitu sebagai berikut:
1. Binary Relationship
Merupakan hubungan antar dua entitas.

Gambar 2.2 Contoh Binary Relationship

2. Ternary Relationship
Merupakan hubungan antar tiga entitas.

G
ambar 2.3 Contoh Ternary Relationship
3. Quarternary Relationship
 23

merupakan hubungan antar empat entitas.

Gambar 2.4 Contoh Quarternary Relationship

4. Unary Relationship
Merupakan hubungan antar satu tipe entitas dimana tipe entitas
ikut serta lebih dari satu kali dengan peranan yang berbeda, atau
disebut juga recursive relationship.

Gambar 2.5 Contoh Unary Relationship

c. Attributes
Connoly dan Begg (2010:350) mendefinisikan atribut sebagai
property dari sebuah entitas atau tipe relasi. Attribut domain
merupakan kumpulan nilai yang diperbolehkan bagi satu atau lebih
atribut.
Connoly dan Begg (2010:351) menyatakan bahwa ada beberapa
jenis atribut, yaitu sebagai berikut:
1. Simple and composite attribute
Simple attribute adalah atribut yang terdiri dari satu komponen
tunggal dan tidak dapat dibagi menjadi bagian yang lebih kecil
24

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
 25

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
26

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

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
28

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

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
30

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.

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

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

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
 33

Gambar 2.7 G/L Account Postings

Layar pengentrian data dibagi menjadi beberapa
area, yaitu sebagai berikut:
a. Work templates
Di sini, kita dapat memilih variasi layar, account
assignment template, atau held document sebagai
referensi. Held document merupakan dokumen
yang disimpan oleh pengguna tanpa melakukan
posting, dengan ide bahwa pengguna akan
melengkapi dan melakukan posting untuk
dokumen tersebut nanti.
b. Header data
Header data berlaku untuk keseluruhan
dokumen, seperti tanggal posting dan tipe
dokumen. Beberapa header data dapat berupa
format tampilan saja, atau tersembunyi dari
pengguna melalui pilihan edit.
c. Line item information
Di sini, line item untuk dokumen dimasukkan.
d. Information area
Di sini, saldo debit dan kredit ditampilkan
dengan menggunakan ikon traffic light.
34

Gambar 2.8 G/L Document Entry Enjoy Screen

Gambar 2.9 G/L Document Entry Complex First Screen

Gambar 2.10 G/L Document Entry Complex Second Screen

 35

Document type atau tipe dokumen digunakan untuk

membedakan berbagai macam dokumen akuntasi
dengan mudah. Setiap dokumen di-assign ke satu
tipe dokumen, di mana dimasukkan di dalam
document header. Nomor dokumen disediakan oleh
document number range yang di-assign ke satu atau
lebih tipe dokumen.

Gambar 2.11 Important Standard Document Types

Ada beberapa tipe dokumen standar di dalam sistem
SAP, yaitu sebagai berikut:
a. CI (Customer invoices)
b. CC (Customer credit memos)
c. CP (Customer payments)
d. GLD (G/L account documents)
e. VI (Vendor invoices)
f. VC (Vendor credit memos)
g. VP (Vendor payments)
h. VN (Vendor net invoices and credit memos)
Untuk posting pada G/L account, tipe dokumen SA
paling sering digunakan, meskipun tipe dokumen
lain juga dapat digunakan, seperti dokumen accrual
atau deferral, dokumen valuasi, dan lain-lain.
Setiap line item memiliki satu posting key. Posting
key merupakan suatu instrumen yang digunakan
untuk kontrol internal dan dimasukkan di dalam
36

layar complex posting untuk memberitahu sistem

dua hal, yaitu:
a. Tipe akun mana yang digunakan untuk
melakukan posting
b. Apakah line item tersebut merupakan posting
debit atau kredit
Di enjoy screen, kita tidak dapat menggunakan
posting key. Debit merepresentasikan posting key 40
dan kredit merepresentasikan posting key 50.
Posting key tersebut muncul di dalam dokumen dan
fungsi kontrol mereka masih tetap relevan.

Gambar 2.12 Standard Posting Keys

Di dalam sistem SAP, ada banyak posting key yang
baku. Setiap posting key digunakan untuk
melakukan posting debit atau kredit ke satu tipe
akun.
Untuk posting di dalam general ledger, kita hanya
membutuhkan dua macam posting key, yaitu:
a. 40, untuk item debit
b. 50, untuk item kredit
Balance display dan line item display disediakan
untuk menampilkan data akun. Line item display
hanya dimungkinkan untuk G/L account di mana
fungsi yang sesuai telah diaktifkan di dalam master
record.
Balance display merupakan tampilan keseluruhan
dari transaction figure yang telah disimpan dari
 37

suatu akun. Kita dapat menelusuri dari saldo menuju

daftar item yang membentuk saldo.
Dari daftar line item pertama, kita dapat menelusuri
ke dokumen yang berisi line item tersebut. Dari situ,
kita dapat melihat transaksi lengkap dengan memilih
document overview.

2.2.2.3.2 Accounts Payable

Bodnar dan Hopwood (2004:334) mendefinisikan accounts
payable atau hutang usaha sebagai tanggung jawab untuk memenuhi
pembayaran kepada vendor.
Brigham dan Houston (2006:207) mendefinisikan accounts
payable atau hutang usaha sebagai hutang yang muncul akibat
penjualan kredit dan dicatat sebagai piutang oleh pihak penjual dan
hutang oleh pihak pembeli.
2.2.2.3.2.1 Vendor Master Records
Sama seperti G/L account, vendor account juga
terdiri dari dua area, yaitu:
a. Suatu vendor account didefinisikan untuk semua
company code pada tingkat client. General data,
seperti nama dan alamat vendor, disimpan di sini.
b. Posting tidak dapat dilakukan ke akun untuk
company code hingga company code-specific setting
(pengaturan spesifik untuk company code) dibuat.
Pengaturan ini mengacu kepada company code yang
relevan dan termasuk detailnya, seperti kondisi
pembayaran yang telah disetujui atau reconciliation
account (akun rekonsiliasi).
38

Gambar 2.13 Initial Screen to Display a Vendor Master Record

Vendor account dapat dibagi ke dalam beberapa
account group sama seperti G/L account, sehingga
mereka dapat diatur dan dikelola dengan lebih
mudah. Bagaimanapun juga, account group
mengontrol tampilan layar dari semua area vendor
master record, tidak hanya company code data saja.
Akun-akun yang ada di dalam suatu account group
biasanya memiliki beberapa karakteristik yang sama.
Sebagai contoh, kita dapat memiliki satu account
group untuk vendor domestik, satu account group
untuk vendor luar negeri, satu account group untuk
vendor afiliasi, dan satu account group untuk 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
 39

Kita dapat dengan mudah membuat sebuah vendor

invoice atau credit memo dengan menggunakan
transaksi satu layar. Tipe tagihan yang dimasukkan
secara langsung di dalam accounts payable ini
merupakan miscellaneous invoice, tanpa referensi ke
purchase order. Layar pengentrian accounts payable
dibagi menjadi beberapa area, yaitu:
a. Work templates
Di sini, kita dapat memilih variasi layar, account
assignment template, atau held document sebagai
referensi.
b. Header and vendor data
Data untuk header dokumen dan vendor line
item dimasukkan di sini.

c. G/L account items

G/L line item untuk dokumen dimasukkan di
sini.
d. Information area
Saldo dokumen dan informasi mengenai vendor
ditampilkan di sini.

Gambar 2.14 Enjoy Invoice/Credit Memo Entry

Transaksi ini juga dapat digunakan untuk membuat
dokumen dengan mata uang asing. Jumlah mata
40

uang asing diterjemahkan ke dalam mata uang lokal

dengan menggunakan kurs pertukaran mata uang
yang telah ditentukan.

Gambar 2.15 Enjoy Vendor Invoice Screen

Kita dapat melakukan posting biaya dan pendapatan
di dalam controlling sebagai real posting maupun
statistical posting:
a. Kita dapat menyelesaikan real posting dengan
objek controlling lainnya
b. Statistical posting hanya digunakan untuk tujuan
informasi
Objek account assignment sendiri dapat berupa
objek real maupun statistical. Sebagai contoh,
internal order didefinisikan sebagai objek real atau
statistical ketika dibuat. Sebuah real order hanya
dapat dijalankan dengan real posting, dan statistical
order hanya dapat dijalankan dengan statistical
posting. Namun, cost center merupakan
pengecualian untuk hal ini. Cost center selalu
didefinisikan sebagai objek real, namun kita dapat
membuat real atau statistical posting ke dalam
mereka.
b. The Recurring Entry Program
 41

Kita dapat menggunakan recurring entry program

untuk melakukan posting yang dilakukan secara
berulang pada jangka waktu yang tetap, seperti
pembayaran uang sewa dan pembayaran pajak
properti. Dengan program ini, dokumen yang
diperlukan akan dihasilkan secara otomatis.
Transaksi bisnis yang berulang harus disimpan di
dalam sistem sebagai dokumen asli untuk entri
berulang agar hal ini dapat dilakukan. Setiap
dokumen asli untuk entri berulang berisi tanggal
posting pertama dan terakhir, frekuensi di mana
posting harus dilakukan, dan tanggal untuk
perencanaan posting yang akan datang.
Recurring entry program harus dimulai pada jangka
waktu yang tetap di dalam periode yang telah
ditentukan. Program tersebut memilih semua
dokumen asli untuk entri berulang yang tanggal
posting-nya telah jatuh tempo, lalu kemudian
menjalankan sesi batch input.
Ketika sesi batch input dijalankan, dokumen
akuntansi yang sesuai dengan dokumen aslinya 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
42

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.

Gambar 2.16 Print Payment Media

Pembayaran otomatis terdiri dari beberapa langkah,
yaitu:
Langkah pertama adalah mengelola parameter. Kita
menggunakan parameter untuk mendefinisikan akun
dan item mana yang perlu dimasukkan ke dalam
program pembayaran di dalam automatic payment
run.
Langkah kedua adalah proposal run. Selama
proposal run berjalan, sistem melakukan beberapa
hal, yaitu:
 43

a. Mengecek akun dan dokumen yang ditetapkan di

dalam parameter untuk item yang jatuh tempo
b. Mengelompokkan item yang jatuh tempo dan
harus dibayar
c. Metode pembayaran, house bank, dan partner
bank yang relevan
Langkah ketiga adalah mengecek dan mengedit
proposal pembayaran. Langkah ini dapat
dihilangkan, namun kita sangat disarankan untuk
mengecek bahwa data telah akurat sebelum
menjalankan program pembayaran.
Langkah keempat adalah menjalankan pembayaran.
Selama payment run, sistem melakukan beberapa
hal, yaitu:
a. Melakukan posting dokumen pembayaran
b. Mengosongkan open item
c. Menyiapkan data yang diperlukan untuk
pencetakan media 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
44

merupakan elemen organisasi yang melakukan

negosiasi kondisi pembelian dengan vendor untuk
satu atau lebih plant.
c. Purchasing Data
Agar proses pembelian digunakan di dalam
Materials Management untuk vendor, vendor master
record harus memiliki bagian ketiga, yaitu
purchasing data. Purchasing data bersifat spesifik
pada satu purchasing organization, sama seperti data
company code dari master record yang bersifat
spesifik pada satu company code. Sama seperti fakta
bahwa dimungkinkan untuk memiliki beberapa
segmen company code untuk vendor master record,
dimungkinkan juga untuk memiliki beberapa
segmen purchasing data untuk vendor master
record. Setiap segmen purchasing data menyajikan
data yang spesifik untuk satu purchasing
organization.
d. Procurement Cycle

Gambar 2.17 Procurement Cycle

Berikut ini adalah proses-proses di dalam
procurement cycle:
a. Demand determination
 45

Departemen yang bertanggung jawab dapat

mencatat kebutuhan material secara manual
melalui purchase order ke bagian pembelian.
b. Determining the source of supply
Tanggung jawab pembeli didukung oleh sistem
di dalam menentukan source of supply (supplier
yang menyediakan material yang dibutuhkan).
Salah satu kemungkinan untuk menentukan
source of supply adalah membuat query dan lalu
memasukkan quotation. Lebih lanjut, kita dapat
mengakses purchase order dan kondisi yang
telah ada di dalam sistem.
c. Supplier selection
Membandingkan harga dari quotation yang
berbeda membuat pemilihan supplier menjadi
lebih mudah. Surat penolakan dapat dikirim
secara otomatis.
d. Purchase order handling
Ketika membuat purchase order, sistem
menyediakan proses pengentrian.
e. Purchase order monitoring
Pembeli dapat mengawasi status pemrosesan dari
purchase order di dalam sistem. Sebagai contoh,
dia dapat menentukan apakah barang atau
tagihan telah diterima untuk purchase order yang
bersangkutan.
f. Goods receipt
Sistem mengecek jumlah barang yang diterima,
apakah sesuai dengan kuantitas pemesanan.
g. Invoice verification
Tagihan dari vendor dicek untuk melihat apakah
akuntansi dan isinya telah benar.
h. Payment processing
Proses pembayaran biasanya dilakukan oleh
bagian Financial Accounting.
46

e. Posting Procurement Transactions

The three-step verification (verifikasi tiga langkah)
merupakan prosedur baku untuk posting transaksi
pembelian di dalam Materials Management. Tiga
langkah tersebut adalah sebagai berikut:
a. Purchase order
Membuat purchase order di dalam Materials
Management. Tidak menghasilkan posting 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.
 47

Gambar 2.18 Purchase Order Screen

2.2.2.3.2.4 Closing Operations in Accounts Payable
a. Accounts Payable Closing Operation
Penutupan akhir tahun dapat dibagi menjadi dua
bagian utama, yaitu:
a. Persyaratan legal (prosedur yang dibutuhkan
oleh pemerintah yang berwenang)
b. Persyaratan teknikal dan organisasi (prosedur
yang secara teknikal dibutuhkan untuk mendukung
organisasi akuntansi)

Gambar 2.19 Accounts Payable closing operations

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

a. Pada awal tahun fiskal, program balance carry

forward dijalankan, memindahkan saldo dari akun
vendor ke tahun fiskal yang baru.
b. Periode posting dari tahun fiskal yang lama
diblok dan periode khusus untuk melakukan posting
penutupan dibuka.
c. Setelah itu, saldo dan vendor yang dipilih
dikonfirmasi, dokumen dengan mata uang asing
divaluasi, dan accounts payable dikelompokkan
ulang berdasarkan sisa hidup.
d. Setelah selesai, periode khusus tersebut dapat
ditutup kembali.
b. Balance Confirmations
Program untuk membuat konfirmasi saldo juga
membuat permintaan balasan untuk sejumlah
vendor, sebuah daftar rekonsiliasi, dan sebuah result
table. Konfirmasi saldo dan permintaan balasan
dikirim ke vendor, sedangkan daftar rekonsiliasi
digunakan sebagai ukuran kontrol.
Vendor mengecek informasi saldo yang mereka
terima dan mengirim balasan mereka ke departemen
kontrol pusat, yang kemudian akan membandingkan
balasan tersebut dengan daftar rekonsiliasi dan
kemudian memasukkan hasilnya ke dalam result
table.
c. Foreign Currency Valuation
Valuasi mata uang asing dibutuhkan apabila akun
vendor berisi open item dalam mata uang asing.
Jumlah mata uang asing untuk open item tersebut
diterjemahkan ke dalam mata uang lokal
berdasarkan kurs pertukaran mata uang yang valid
untuk tanggal posting.
Kurs pertukaran mungkin saja berbeda pada saat
penutupan, dan open item perlu divaluasi ulang.
Program tersebut memvaluasi open item
 49

menggunakan kurs pertukaran yang baru dan

memasukkan perbedaan valuasi di dalam line item
yang divaluasi. Hal ini juga membuat dua posting,
yaitu:
a. Debit: biaya dari valuasi mata uang asing, kredit:
akun penyesuaian neraca saldo
b. Debit: akun penyesuaian neraca saldo, kredit:
pendapatan dari valuasi mata uang asing
Valuasi tidak dapat dilakukan dengan melakukan
posting ke accounts payable, karena akun
rekonsiliasi tidak dapat di-posting secara langsung.
Untuk alasan ini, posting muncul di adjustment
account (akun penyesuaian), yang mana ditampilkan
di neraca saldo untuk akun rekonsiliasi yang
bersangkutan.
d. Regrouping Accounts Payable
Accounts payable dan accounts receivable harus
terdaftar secara terpisah di neraca saldo. Karena
dimungkinkan bagi beberapa vendor untuk memiliki
saldo debit, akun-akun ini harus diubah dengan saldo
debit sebelum membuat laporan keuangan.
Di banyak negara, juga dibutuhkan untuk
mengelompokkan accounts payable di dalam neraca
saldo berdasarkan sisa hidup mereka.
Pengelompokan ulang tersebut dijalankan
menggunakan program khusus. Pada waktu yang
sama, pengelompokan ulang ini dihilangkan pada
hari pertama di periode berikutnya, karena
pengelompokan ulang ini tidak diperlukan untuk
pemrosesan sehari-hari.
2.2.2.3.3 Accounts Receivable
Bodnar dan Hopwood (2004:295) mendefinisikan accounts
receivable atau piutang usaha sebagai uang yang terutang oleh
konsumen atas barang yang telah dijual atau jasa yang diberikan
kepadanya.
50

Horngren, Sundem, dan Stratton (2004:239) mendefinisikan

accounts receivable atau piutang usaha sebagai sejumlah uang yang
dihutangkan kepada perusahaan oleh pelanggannya sebagai hasil dari
pengiriman barang atau jasa.
2.2.2.3.3.1 Customer Master Data
Sama seperti G/L account dan akun vendor, akun
customer juga terdiri dari dua area, yaitu:
a. General data
Sebuah customer account didefinisikan untuk semua
company code pada tingkat client. General data,
seperti alamat pelanggan, disimpan di sini. General
data berlaku untuk semua company code yang
melakukan bisnis dengan pelanggan.

b. Company code segment

Posting tidak dapat dilakukan ke customer account
untuk company code hingga customer code-specific
setting (pengaturan spesifik untuk company code)
telah dibuat. Segmen company code berisi informasi
yang berarti hanya ke satu company code, seperti
aturan pembayaran yang telah disetujui.

Gambar 2.20 Company Code View of the Customer Master

Record
Sama seperti G/L account dan vendor account,
customer account disimpan di berbagai macam
 51

account group, sehingga mereka dapat diatur dan

dikelola dengan lebih mudah.
Akun-akun di account group biasanya memiliki
karakteristik yang sama. Sebagai contoh, kita dapat
memiliki satu account group untuk pelanggan
domestik, satu account group untuk pelanggan luar
negeri, satu account group untuk pelanggan afiliasi,
dan satu account group untuk one-time customer.
Account group memiliki number range yang 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
52

dimasukkan menggunakan enjoy transaction. Layar

pengentrian enjoy transaction dibagi menjadi
beberapa area, yaitu:
a. Work templates
Di sini, kita dapat memilih variasi layar, account
assignment template, atau held document sebagai
referensi.
b. Header and customer data
Header dokumen dan data customer line item
dimasukkan di sini.
c. G/L account items
Line item G/L untuk dokumen dimasukkan di sini.

d. Information area
Saldo dokumen dan informasi mengenai pelanggan
ditampilkan di sini. Information area juga berisi link
ke master data dan open item.

Gambar 2.21 Enjoy Invoice/Credit Memo Entry

Transaksi ini juga dapat digunakan untuk membuat
dokumen dengan mata uang asing. Jumlah mata
uang asing diterjemahkan ke dalam mata uang lokal
menggunakan kurs pertukaran mata uang yang telah
ditentukan.
 53

Gambar 2.22 Enjoy Customer Invoice Screen

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

b. Residual item: open invoice dibersihkan dan

open item baru (residual item) dengan jumlah
sebesar selisih pembayaran dibuat.

Gambar 2.23 Process Incoming Payment Screen

c. Dunning Functions
Sistem SAP menyediakan alat yang secara otomatis
menganalisis semua open item dan menagih semua
open item 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
 55

dimasukkan ke dalam automatic dunning.

Sedangkan, prosedur tagihan yang berlaku untuk
one-time customer dimasukkan ke dalam one-time
account.
Kita dapat menentukan sebanyak mungkin prosedur
tagihan yang berbeda. Sistem SAP menyediakan
beberapa standar untuk prosedur tagihan yang dapat
digunakan sebagai template untuk prosedur
tambahan.
Kita dapat menentukan bagaimana dunning run akan
dijalankan dengan memasukkan parameter di dalam
dunning program. Kita dapat menggunakan
parameter dari dunning run yang sudah ada sebagai
template dan mengubah tanggalnya agar memenuhi
persyaratan. Biasanya, parameter berupa company
code dan akun yang ingin dimasukkan ke dalam
dunning run.
d. Dunning Run
Selama dunning run, akun-akun dipilih dan dicek
untuk item yang telah jatuh tempo. Sistem kemudian
mengecek apakah peringatan tagihan harus dikirim
dan memilih tingkat tagihan yang sesuai. Semua data
tagihan disimpan di dalam dunning proposal.
Dunning proposal dapat diedit, dihapus, dan dibuat
ulang sesering yang kita inginkan hingga bagian
akuntansi puas dengan hasilnya.
Dunning proposal bukanlah langkah yang wajib,
oleh sebab itu, dunning proposal dapat dihilangkan.
Jika dunn print with scheduling tidak dipilih, sistem
tidak akan membuat proposal. Bahkan, sistem akan
langsung mencetak peringatan tagihan ketika
program tersebut dijalankan.
56

Gambar 2.24 Printing Dunning Notices

Langkah terakhir adalah sistem mencetak peringatan
tagihan dan melakukan update data tagihan di
master record dan dokumen, termasuk tanggal
tagihan dan tingkat tagihannya.

e. Correspondence
Correspondence yang terkait dengan bisnis 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)
 57

Korespondensi yang di-request disimpan di dalam

tabel permintaan korespondensi dan dapat dicetak
melalui program tertentu.
f. Accounts Receivable Information System
Accounts Receivable Information System
memungkinkan kita untuk menjalankan analisis
cepat dari data akuntansi yang penting, seperti:
a. Due date breakdown (rincian tanggal jatuh
tempo)
b. Customer payment history (sejarah pembayaran
dari pelanggan)
c. Currency risk for customers abroad (resiko mata
uang untuk pelanggan luar negeri)
d. Overdue items (item yang telah jatuh tempo)
e. Jumlah hari yang digunakan oleh pelanggan
untuk membayar tagihan
f. Customer cash discount history (sejarah diskon
pelanggan)

2.2.2.3.3.3 Integration with Sales Order Management

a. Sales Organizations and Distribution Channels
Sales organization bertanggung jawab atas
penjualan. Company code dapat dihubungkan ke
beberapa sales organization.
Setiap sales organization dapat menggunakan
distribution channel yang berbeda untuk menjual
barang. Prinsipnya, distribution channel dapat juga
digunakan oleh dua sales organization yang berbeda.
Kombinasi dari sales organization dan distribution
channel disebut juga dengan distribution chain.
Distribution chain menjual barang dari plant.
Division (divisi) merepresentasikan lini produk inti
dari suatu organisasi. Divisi di-assign ke distribution
58

chain. Kombinasi dari distribution chain dan divisi

disebut dengan sales area.
Perjanjian spesifik dengan pelanggan, mengenai
partial delivery (pengiriman terpisah) atau terms of
payment (aturan pembayaran), sebagai contoh, dapat
dibuat untuk setiap sales area.
b. Sales Area Data in the Customer Master
Record
Sales area (kombinasi dari sales organization,
distribution channel, 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.

Gambar 2.25 Overview of the sales process

c. Sales Process
Sales order merupakan dasar dari proses penjualan.
Ketika pelanggan telah memesan, sebuah sales
order harus dibuat pada awal proses. Sales order
dibuat pada tingkat distribution chain. Item yang
dipesan dapat dari divisi yang berbeda. Sales order
merupakan dokumen di dalam Sales Order
 59

Management dan tidak menyebabkan posting

apapun di dalam Financial Accounting. Ketika sales
order telah dimasukkan, sistem menjalankan
availability check untuk tanggal pengiriman yang
diminta.
Pada hari shipping, dokumen outbound delivery
dibuat. Penagihan untuk pengiriman dapat dilakukan
hanya pada saat barang telah dibawa keluar dari
gudang dan telah di-post sebagai goods issue. Hal ini
merupakan langkah yang terpisah di dalam proses
pengiriman.
Fungsi warehouse management digunakan untuk
picking. Sebuah transfer order harus dibuat, yang
lalu akan menghasilkan pick order. Barang yang
dipesan dibawa dari gudang dan disiapkan untuk
pengiriman.
Barang yang akan dikirim di-post sebagai goods
issue. Dokumen goods issue dibuat di Materials
Management, dan sebuah dokumen akuntansi dibuat
di Financial Accounting sehingga goods issue
tersebut di-post ke G/L account yang benar.
Dokumen akuntansi tersebut mendebitkan cost of
goods sold (biaya penjualan barang) dan
mengkreditkan inventory (persediaan).
Langkah terakhir di proses penjualan adalah billing
(penagihan). Dokumen tagihan dibuat di Sales
Order Management, dan tagihan yang dicetak
dikirim ke pelanggan. Pada waktu yang sama,
sebuah dokumen dibuat di Financial Accounting
sehingga piutang dan pendapatan dapat di-post ke
akun yang benar.
Document flow merupakan alat yang memungkinkan
kita untuk melihat dokumen-dokumen yang
berhubungan di dalam proses penjualan.
60

Gambar 2.26 Sales Order Entry Screen

2.2.2.3.3.4 Credit Management
a. Credit Control Area
Unit organisasi yang digunakan untuk mengontrol
kredit adalah credit control area. Sebuah credit
control area dapat di-assign ke company code
individu (organisasi yang bersifat desentralisasi)
maupun ke sekelompok company code (organisasi
yang bersifat sentralisasi).
Credit control area dikelola secara umum oleh
departemen kredit yang terpisah, yang dibagi
menjadi beberapa kelompok representative kredit.
Setiap group berisi beberapa representatif kredit.
b. Credit Management Master Record
Departemen kredit membuat credit management
master record yang terpisah. Hal ini merupakan
ekstensi dari customer master record. Data yang
relevan untuk manajemen kredit dapat diawasi dan
dikelola melalui credit management master record
yang terpisah.
Credit management master record terdiri dari
beberapa elemen, yaitu:
a. General data
Relevan untuk semua area kontrol kredit. General
data termasuk alamat pelanggan dan data
komunikasi, serta jumlah limit maksimum yang
diizinkan untuk seorang pelanggan.
 61

b. Credit control area data

Relevan hanya untuk area kontrol kredit yang
spesifik saja. Credit control area data termasuk limit
kredit pada tingkat area kontrol kredit, dan kategori
resiko pelanggan serta kelompok representatif kredit.
c. Overview
Overview berisi data yang paling penting dari semua
bagian.
c. Credit Control Process
Kontrol kredit dijalankan dengan langkah sebagai
berikut:
a. Ketika pesanan dibuat, dilakukan suatu cek
untuk melihat apakah limit kredit pelanggan akan
melampaui batas apabila pesanan tersebut diterima.
Jika limit kredit tidak melampaui batas, maka proses
penjualan dapat dijalankan seperti biasa.
b. Jika limit kredit melampaui batas, pesanan akan
diblok untuk pengiriman dan departemen kredit
harus menjalankan tugasnya. Representatif kredit
yang bertanggung jawab akan dinotifikasi secara
otomatis melalui remote mail, atau dapat juga
menggunakan laporan secara reguler untuk
mengecek daftar dari pesanan yang diblok.
c. Representatif kredit kemudian mengklarifikasi
situasi, dapat menggunakan sistem informasi kredit
atau dengan menghubungi pelanggan.
d. Setelah klarifikasi telah dibuat, representatif
kredit me-release pesanan, dan transaksi dapat
diproses di Sales Order Management seperti biasa.
Jika representatif kredit memutuskan untuk tidak
me-release pesanan, maka pesanan tersebut ditolak.
2.2.2.3.3.5 Closing Operations in Accounts Receivable
a. Closing Operations for Accounts Receivable
62

Gambar 2.27 Accounts Receivable closing operations

Langkah-langkah penutupan di dalam accounts
receivable adalah sebagai berikut:
a. Pada awal tahun fiskal baru, program balance
carry forward dijalankan, untuk memastikan bahwa
saldo pada akun pelanggan dipindahkan ke tahun
fiskal baru.
b. Periode posting dari tahun fiskal lama diblok dan
periode khusus untuk entri penutup dibuka.
c. Setelah itu, konfirmasi saldo dikirim dan
dievaluasi, dokumen dengan mata uang asing
divaluasi, penyesuaian nilai dijalankan untuk piutang
yang jatuh tempo, dan accounts receivable
diklasifikasi ulang ke kategori jangka pendek atau
jangka panjang untuk laporan keuangan.
d. Periode khusus tersebut kemudian dapat ditutup.
Konfirmasi saldo, valuasi mata uang asing, dan
pengelompokan ulang dijalankan sama seperti pada
accounts payable.
 63

b. Value Adjustment Parameters

Kita dapat menggunakan program valuasi untuk
menjalankan penyesuaian nilai. Fungsi program
tersebut sama seperti program dunning dan payment.
Setiap valuation run diidentifikasi dengan jelas oleh
tanggal dijalankan dan field identifikasi.
Kita dapat menentukan bagaimana cara valuasi akan
dijalankan dengan memasukkan parameter untuk
valuation run. Kita dapat menggunakan parameter
dari valuation run yang sudah ada sebagai template.
Parameter-parameter ini termasuk metode valuasi,
area valuasi, dan spesifikasi posting.
Valuation run menganalisis akun dan dokumen yang
dimasukkan di dalam parameter dan membuat
proposal valuasi, yang dapat diedit, jika diperlukan.
Valuasi tersebut dapat:
a. Dimasukkan secara manual di dalam dokumen
pada tanggal yang lebih awal (individual value
adjustment)
b. Ditentukan menggunakan value adjustment key
yang terdapat pada master record pelanggan
Langkah terakhir dari proses valuasi adalah transfer.
Dokumen G/L melakukan posting valuasi dan
dimasukkan ke dalam dokumen valuasi, sehingga
valuasi tersebut dapat ditelusuri kapan saja.
64

Gambar 2.28 Valuation Transfer

2.2.2.3.4 Asset Accounting
Di dalam asset accounting, kita mengenal istilah depresiasi.
Pujawan (2004:193) mendefinisikan depresiasi sebagai penurunan nilai
suatu properti atau aset karena waktu dan pemakaian.
Pujawan (2004:193) menyatakan bahwa depresiasi pada suatu
properti atau aset biasanya disebabkan karena satu atau lebih 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
 65

center, internal order, activity type, dan lain-lain)

dan organizational unit untuk logistik (hanya untuk
kegunaan seleksi dan pelaporan saja).
b. Asset Class
Asset class merupakan kriteria utama ketika
mendefinisikan sebuah aset. Setiap aset harus 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.
66

Transaction figure yang terpisah disimpan di setiap

area:
a. Per aset dan depreciation area
b. Untuk komponen nilai individu, seperti saldo,
depresiasi, nilai buku yang tersisa
Di dalam asset master record, data yang berbeda
untuk valuation area disimpan. Data-data tersebut
mengontol kalkulasi dari depresiasi normal dan
khusus untuk valuation area masing-masing. Kita
dapat menggunakan metode depresiasi yang berbeda
untuk prosedur bisnis yang umum dari metode
depresiasi yang diwajibkan oleh bagian pajak.
d. Account Determination
Karena depreciation area di dalam akuntansi aset
tidak muncul di general ledger, nilainya harus 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.
 67

Aset utama di-assign ke subnumber 0,

memungkinkan asset subnumber untuk di-assign
sebagaimana yang diinginkan.
Sebuah group asset memiliki master data-nya
sendiri. Beberapa aset utama dapat di-assign ke
group asset. Depresiasi dihitung pada tingkat group
asset. Hal ini penting di beberapa industri, seperti
telekomunikasi.
2.2.2.3.4.2 Standard Accounting Transactions in Asset
Accounting
a. Transaction Type
Transaction type merupakan tambahan untuk asset
posting key 70 (debit) dan 75 (kredit). Transaction
type harus dimasukkan ketika melakukan posting ke
asset account. Transaction type diperlukan untuk
asset accounting karena transaction type
menentukan tepat di mana posting untuk aset
terdaftar di asset history sheet.
Transaction type membedakan karakteristik dari
berbagai asset posting, sebagai contoh:
a. Membeli atau menjual
b. Kredit memo
c. Akuisisi dari produksi internal
d. Posting penyesuaian
e. Masa pakai habis tanpa menghasilkan keuntung
f. Depresiasi dan apresiasi
b. Asset Transactions
Transaksi aset seperti akuisisi dan retirement dapat
di-post dengan berbagai cara untuk memenuhi
kebutuhan bisnis dan organisasi dari perusahaan. Di
dalam asset accounting, kita dapat melakukan
posting dengan cara-cara berikut:
a. Tanpa vendor atau purchase order, entri
penyeimbang dibuat ke G/L clearing account
68

b. Ke vendor, namun tanpa referensi ke purchase

order
c. Melalui Materials Management menggunakan
fungsi purchase order, goods receipt, dan invoice
receipt
Ketika melakukan posting ke akun dari dua buku
pembantu, yaitu ke aset dan ke vendor, akun
rekonsiliasi dari kedua buku pembantu di-update di
general ledger.

Gambar 2.29 Document Entry Screen for Asset Acquisition

c. Assets Under Construction
Biaya untuk asset under construction dapat dikelola
dengan dua cara, yaitu:
a. Di komponen aplikasi investment management,
kita dapat membuat, melakukan posting, dan
mengelola investment order atau proyek investment
management. Pesanan dan proyek ini kemudian
dicocokkan dengan asset under construction.
Investment management menyediakan fungsi yang
luas untuk mendukung prosedur investasi.
b. Jika investment management tidak digunakan,
asset under construction dapat di-post secara
langsung di dalam asset accounting.
Ketika aset telah lengkap, maka:
a. Master data harus dibuat (jika belum ada) untuk
aset
 69

b. Nilai dari akun asset under construction harus

dilunasi ke satu atau lebih aset lengkap. Biayanya
didistribusi ke satu atau lebih aset dengan bantuan
settlement rule (aturan pembayaran).
d. Asset Explorer
Asset explorer menawarkan tampilan keseluruhan
dari akivitas untuk sebuah aset. Kita dapat melihat
transaksi yang telah di-post ke dalam aset dan juga
depresiasi yang telah direncanakan maupun yang
telah di-post untuk setiap depreciation area, periode,
maupun untuk setiap tahun fiskal. Kita dapat melihat
rincian dari transaksi akuntansi. Selain itu, kita dapat
dengan mudah berpindah untuk melihat aset lain
tanpa meninggalkan layar.

Gambar 2.30 Asset Explorer

Gambar 2.31 Asset Explorer

70

2.2.2.3.4.3 Closing Procedures in Asset Accounting

a. Asset Closing
Penutupan dapat secara kasar dibagi menjadi dua
tipe, yaitu:
a. Persyaratan legal (diwajibkan oleh pemerintah)
b. Tugas teknikal dan organisasi (langkap persiapan
yang diperlukan secara teknikal atau yang
mendukung accounting organization)
Dengan fiscal year change program, tahun baru pun
dibuka. Hal ini memungkinkan kita untuk
melakukan posting ke aset di tahun fiskal yang baru.
Year-End Closing Program mengecek apakah:
a. Depresiasi dan nilai aset di-post secara
keseluruhan
b. Aset berisi error atau tidak sempurna
Jika program tersebut tidak menemukan error,
program tersebut melakukan update tahun fiskal
yang baru ditutup untuk setiap depreciation area dan
program tersebut memblok posting di asset
accounting untuk tahun fiskal yang telah ditutup.

Gambar 2.32 Asset closing operations

 71

Langkah-langkah penutupan di dalam asset

accounting adalah sebagai berikut:
a. Pada awal tahun fiskal yang baru, penyesuaian
teknikal dilakukan, yang membandingkan
transaction figure di asset accounting dengan figure
yang berhubungan di G/L account.
b. Setelah itu, persediaan diambil dan posting
penyesuaian dibuat, apabila ada koreksi yang perlu
dilakukan.
c. Depreciation posting run melakukan posting
depresiasi ke general ledger. Karena hanya satu
depreciation area dapat melakukan posting asetnya
ke general ledger di real time, sebagai tambahan,
depreciation area yang bersangkutan di-post ke
general ledger menggunakan periodic asset account
posting program. Posting untuk depresiasi tambahan
ini diperlukan hanya di beberapa negara.
d. Sistem akan melakukan periodic posting ke
dalam akun neraca saldo, kemudian menjalankan -
year-end closing program.
e. Kita sekarang dapat membuat asset history sheet,
yang menampilkan nilai buku awal dan akhir dari
aset dan transaksi yang terkait di dalamnya.
b. Inventory
Kita dapat membuat satu atau lebih daftar persediaan
dengan sistem SAP untuk proses persediaan. Daftar
tersebut diberikan kepada para karyawan yang
melakukan tugas berkaitan dengan persediaan. Para
karyawan ini mencatat semua selisih di daftar
tersebut dan meneruskannya ke departemen
akuntansi. Para karyawan di bagian akuntansi
memasukkan koreksi yang diperlukan ke dalam
sistem.
c. Depreciation Posting Run
72

Semua depresiasi pada awalnya disimpan dalam

format nilai terencana di dalam asset accounting.
Hanya setelah depreciation posting run selesai
dijalankan, depresiasi akan di-post di asset
accounting dan di general ledger. Depresiasi di-post
ke akun depresiasi yang berhubungan di general
ledger dan ke objek management accounting yang
di-assign ke master record.
d. Asset History Sheet
Asset history sheet merupakan evaluasi yang paling
penting dan paling lengkap untuk proses penutupan.
Seperti laporan keuangan, struktur dari asset history
sheet disusun berdasarkan persyaratan spesifik untuk
setiap negara tertentu. Kita juga dapat membuat
banyak versi asset history sheet.
Setiap versi asset history sheet berisi berbagai
pengelompokan history sheet, seperti berikut:
a. Nilai buku pada awal tahun fiskal
b. Akuisisi
c. Retirement
d. Posting penyesuaian
e. Depresiasi
f. Nilai buku pada akhir tahun fiskal
2.2.2.3.5 Bank Accounting
2.2.2.3.5.1 Master Records in Bank Accounting
a. Bank Directory
Bank directory berisi alamat dan data kontrol yang
sah (misalnya swift code) dari semua bank yang
digunakan di dalam sistem SAP.
Bank directory dapat:
a. Secara otomatis diimpor, selama bank directory
tersedia di dalam disket dan program impor ada
untuk data ini
b. Dibuat secara manual
 73

Jika sebuah bank dibuat di bank directory, data

dasarnya bisa diakses, misalnya ketika memasukkan
informasi bank kedalam master record milik
customer atau vendor. Kita hanya perlu
memasukkan data negara dari bank dan bank key.
Sistem akan menemukan nama dan alamat dari bank
di dalam tabel bank directory. Jika bank belum ada
di dalam bank directory, bank bisa dimasukkan
secara langsung. Kemudian baru ditambahkan ke
dalam bank directory, jika sudah ditambahkan ke
dalam master record milik customer dan vendor.
b. Bank Accounts
House bank adalah bank di mana kita (company
code) mempunyai akun-akun. Setiap house bank
diwakili oleh account ID. ID ini adalah kode yang
dapat berjumlah hingga empat karakter, bisa berupa
angka maupun huruf. House bank ID dan account ID
dimasukkan kedalam G/L account master record, di
mana mewakili sebuah bank account di dalam
general ledger.

2.2.2.3.5.2 Business Transaction in Bank Accounting

a. Cash Journal
Sejak dirilisnya versi 4.6, SAP menyediakan cash
journal untuk menangani petty cash. Kita dapat
membuat cash 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.
74

Gambar 2.33 Cash Journal Transaction

Layar pengentrian data untuk transaksi cash journal
dibagi kedalam tiga bagian, yaitu:
a. Data selection
Di sini, periode waktu dari data dapat dipilih.
b. Balance display
Menampilkan jumlah kas masuk dan kas keluar serta
saldo awal dan saldo akhir.
c. Accounting transactions
Di sini, transaksi cash journal dapat diisi. Di sini
perbedaan dibuat antara cash payment, cash receipt,
dan check receipt. Transaksi akuntansi disimpan
secara terpisah di dalam cash journal dan ditransfer
secara periodik ke general ledger. Transaksi yang
ditransfer dapat dicetak sebagai jurnal. Tanda terima
dapat dicetak untuk setiap transaksi individu.
b. Types of Cash Journal Transactions
Tipe-tipe dari transaksi cash journal adalah sebagai
berikut:
a. Expense
b. Revenues
c. Cash transfer dari cash office ke bank
d. Cash transfer dari bank ke cash office
e. Vendor payment receipt/issue
 75

f. Customer payment receipt/issue

c. Depositing Checks
Proses depositing check adalah sebagai berikut:
a. Cek yang masuk dapat diproses secara manual
atau dengan check scanner.
b. Setelah semua cek sudah dimasukkan, daftar dari
cek yang akan dideposit tersedia di sistem dan dapat
diperbaiki bila diperlukan.
c. Daftar cek yang dideposit dapat dicetak atau
dikirim ke bank bersama dengan cek.
d. Batch input session dibuat dari daftar check
deposit dan harus diproses untuk membuat posting.
e. Posting dapat diselesaikan secara langsung,
tanpa batch input session.
d. Posting a Check Deposit
Ketika melakukan posting terhadap daftar check
deposit, dua batch input session dihasilkan, yaitu
subledger session dan bank posting session. Kedua
session ini harus diproses, untuk membuat posting
yang terasosiasi di dalam general ledger.
a. Subledger accounting session secara umum
diproses dari accounts receivable dan membersihkan
open item yang telah dibayar.
b. Bank posting session biasanya diproses oleh
departemen keuangan atau cash management.
Mereka memposting jumlah cek ke incoming check
account.
e. Lockbox
Ketika menggunakan lockbox, customer
mengirimkan informasi cek dan pembayaran mereka
langsung ke bank. Bank membayar biaya untuk
meng-input data cek yang diterima. Bank
menyimpan informasi cek dan pembayaran di dalam
file dan mengirimnya ke departemen keuangan
76

menggunakan data transfer, misalnya disket, data

line, atau EDI.
Berkas lockbox disimpan di dalam sistem SAP. Akun
cek masuk di-posting dan invoice yang telah dibayar
dibersihkan. Informasi pembayaran yang telah
selesai memungkinkan sistem SAP untuk berjalan
baik dengan clearing. Jika sistem tidak dapat
menemukan invoice untuk dibayar, informasi
pembayaran harus diproses secara manual setelah
menggunakan fungsi post processing.
f. Bank Statement
Bank menginformasikan departemen keuangan
mengenai transaksi di dalam akun bank perusahaan
menggunakan bank statement. Posting yang
disimpan di dalam bank statement harus dimasukkan
ke dalam akuntansi.
Perusahaan dapat menerima bank statement dalam
dua cara yang berbeda:
a. Dalam bentuk form: dalam kasus ini, account
statement harus dibuat secara manual di dalam
sistem SAP.
b. Dalam bentuk file: file ini disediakan baik di
dalam pembawa data ataupun diambil dari bank
menggunakan transfer program (bank-spesific).
Laporan SAP mengimpor file ini ke penyimpanan
bank sementara dari sistem SAP.
Proses selanjutnya adalah:
a. Bank statement di dalam penyimpanan bank
sementara dapat dicetak untuk tujuan dokumentasi.
b. Batch input session dibuat dari bank statement di
dalam penyimpanan bank sementara. Kita harus
menjalanakan sesi ini untuk menciptakan posting
yang dibutuhkan. Kita juga dapat melakukan posting
secara langsung (tanpa batch input).
 77

c. Kita dapat menjalankan postprocessing baik

dengan menjalankan batch input session secara
online atau menggunakan transaksi special
postprocessing jika kita melakukan posting secara
langsung.
g. Check Receipts and Issues
Penjelasan mengenai check receipt dan check issue
adalah sebagai berikut:
a. Check issue
Program pembayaran membuat cek dan melakukan
posting check issue, setiap kali open vendor item
dibersihkan. Check issue di-post ke dalam outgoing
check account yang disiapkan untuk tujuan tersebut.
Ketika ceknya telah didepositokan oleh vendor dan
bank account didebitkan, ceknya muncul di dalam
bank statement dan bank ledger accounting dari
bank statement yang fungsinya untuk melakukan
posting check issued to bank. Jika kita
menggunakan check management, posting tersebut
dibawa melalui cashed checks.
b. Check receipt
Di USA, semua posting yang diperlukan dibawa
dengan mengunakan fungsi dari lockbox. Di dalam
prosedur lain, check receipt pertama-tama akan 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
78

Program pembayaran membuat pengirimannya dan

melakukan posting ke outgoing cash account. Open
vendor item dibersihkan dalam waktu yang
bersamaan. Cash outflow muncul kemudian di dalam
bank statement dan bank ledger accounting session
membuat posting cash outflow to bank.
b. Incoming transfer
Incoming transfer muncul di bank statement. Fungsi
dari bank statement adalah melakukan posting kas
masuk, bank to incoming cash dengan
menggunakan bank ledger accounting session.
Subledger accounting session membersihkan item
yang sudah dibayar dari akun pelanggan. Fungsi
bank statement adalah untuk mendapatkan informasi
tugas dari field transfer note to payee.
 79

2.2.2.3.6 Preparing Financial Statement

2.2.2.3.6.1 Financial Closing in the General Ledger
a. General Ledger Closing

Gambar 2.34 General Ledger closing operations

Langkah-langkah penutupan di dalam general
ledger adalah sebagai berikut:
a. Pada awal tahun fiskal yang baru, program
balance carry 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
80

penyesuaian ke business area. Saldo dari business

area kemudian diatur menjadi nol.
e. Periode khusus kemudian dapat ditutup.
f. Untuk keperluan dokumentasi, balance audit
trail dapat dilakukan dan laporan keuangan dibuat.
Laporan tambahan disiapkan untuk tujuan pelaporan
yang legal.
b. Closing Cockpit
Closing Cockpit memungkinkan kita untuk membuat
antarmuka terstruktur untuk menjalankan transaksi
dan program yang merupakan bagian dari proses
yang kompleks, seperti proses penutupan.

Gambar 2.35 Closing Cockpit

Closing cockpit sangat cocok ketika:
a. Aktivitas akan muncul kembali secara periodik
b. Lebih dari satu pihak yang bertanggung jawab
dilibatkan
c. Aktivitas dilakukan di dalam proses yang
memiliki urutan kronologi tetap atau ditentukan oleh
dependensi
d. Aktivitas harus didukung oleh antarmuka untuk
semua yang terlibat
 81

e. Status dari semua aktivitas periodik harus

didokumentasi dan dibuat transparan dan tersedia
untuk semua yang terlibat
Untuk mendukung proses penutupan, closing
cockpit menawarkan pilihan-pilihan berikut:
a. Hirarki untuk menampilkan objek organisasi
yang terlibat di dalam proses penutupan
b. Template daftar tugas berdasarkan struktur
organisasi
c. Daftar tugas yang berasal dari template daftar
tugas
d. Tampilan daftar di mana semua tugas yang harus
dikelola atau dijalankan dari daftar tugas 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.
82

b. Deferral
Biaya atau pendapatan di-post di periode yang sedan
berjalan, namun transaksi bisnis yang sesungguhnya
terjadi di periode yang akan datang.
d. GR/IR Analysis
GR/IR clearing account berisi daftar dari semua
barang dan tagihan yang diterima. Jika pada akhir
periode, saldo dari akun ini tidak nol, ada dua
alasan:
a. Barang telah ditagih namun belum juga dikirim
b. Barang telah dikirim namun belum juga ditagih
Ketika tutup buku, saldo tersebut perlu dicatat
sebagai aset maupun kewajiban di dalam laporan
keuangan.
GR/IR dianalisis dengan menggunakan program
khusus. Di sini, saldo di-post ke akun barang telah
ditagih namun belum juga dikirim atau ke akun
barang telah dikirim namun belum juga ditagih.
Posting tersebut dibalik pada hari pertama di periode
berikutnya, karena melakukan posting ulang selama
bisnis sehari-hari akan menyebabkan terjadinya
kesalahan.
Posting pembersihan biasanya dilakukan dengan
menggunakan correction account. GR/IR clearing
account dan correction account-nya kadang-kadang
ditampilkan di lampiran laporan keuangan.
e. Financial Statements
Untuk membantu di dalam pembuatan laporan
keuangan, ada dua pilihan yang tersedia di dalam
sistem SAP, yaitu:
a. Menggunakan program ABAP
b. Menggunakan G/L account information system
Kedua pilihan tersebut memungkinkan kita untuk
melakukan hal-hal di bawah ini:
 83

a. Menggunakan berbagai macam versi laporan

keuangan
b. Membuat laporan keuangan keseluruhan dan
individu untuk company code
c. Membuat laporan keuangan keseluruhan dan
individu untuk business area
d. Membuat laporan keuangan dengan
menggunakan operating chart of account
e. Membuat laporan keuangan dengan
menggunakan country-specific chart of account
f. Membuat perbandingan laporan keuangan untuk
membandingkan dua tahun fiskal atau untuk
membandingkan data perencanaan dan data
sesungguhnya
2.2.2.3.6.2 Cost-of-Sales Accounting
a. Period Accounting
Dua metode dasar untuk menata laporan laba rugi
adalah:
a. Period accounting
b. Cost-of-sales accounting
Kedua metode akan menghasilkan laporan laba rugi
yang sama untuk satu periode. Metode yang
digunakan mungkin saja diwajibkan atau hanya
berdasarkan pertimbangan bisnis saja.
Di dalam period accounting, jumlah hasil untuk satu
periode dibandingkan dengan jumlah biaya untuk
periode tersebut.
Biaya keseluruhan untuk satu periode terdaftar
menurut tipe biayanya. Di sini, saldo ditambahkan di
akun biaya yang sama.
84

Gambar 2.36 Period Accounting

b. Cost-of-Sales Accounting
Pada cost-of-sales accounting, biaya barang yang
terjual dikurangi dari pendapatan untuk menghitung
keuntungan operasi. Pada period accounting, jumlah
biaya produksi dikurangi dari pendapatan.
Tidak seperti period accounting, di mana biaya
dipecah berdasarkan tipe biaya, pada cost-of-sales
accounting, biaya terdaftar berdasarkan fungsi
mereka di dalam organisasi, seperti produksi,
penjualan, administrasi, dan lain-lain. Fungsi-fungsi
tersebut direpresentasikan oleh functional area.

Gambar 2.37 Cost-of-Sales Accounting

 85

c. Derivation of Functional Area

Ketika cost-of-sales accounting dipilih, field
tambahan yaitu functional area dimasukkan ke
dalam coding block untuk akun. Entri dibuat di field
functional area melalui:
a. Entri manual pada field
b. Entri otomatis dari functional area melalui
substitusi
c. Menyalin secara otomatis functional area yang
dimasukkan ke master data dari akun laba rugi
d. Menyalin secara otomatis functional area yang
dimasukkan ke master data dari objek CO
d. Cost-of-Sales Accounting Ledger
Untuk membuat laporan keuangan berdasarkan 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.
86

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

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

2.2.4.2 Jenis-jenis Perangkat Ajar

Adeyemi (2012:270) menyatakan bahwa ada enam jenis
perangkat ajar, yaitu sebagai berikut:
a. Tutorial
Tutorial merupakan jenis perangkat ajar yang paling sering
digunakan. Tutorial menyediakan informasi serta panduan untuk
memastikan pelajar memiliki sebuah kesempatan untuk mengerti
instruksi yang terdapat di dalamnya. Tutorial yang berguna adalah
tutorial yang di dalamnya terjadi interaksi timbal balik. Aktivitas
dari tutorial mencakup presentasi dan perpanjangan dari presentasi
tersebut ke dalam bentuk presentasi yang berbeda-beda, termasuk
drill and practice dan simulation.
b. Simulation
Simulasi digunakan untuk merekayasa tempat kerja yang
sebenarnya. Keadaan yang hampir mendekati kenyataan merupakan
kunci sukses bagi simulasi, namun tiak semua elemen dari suatu
simulasi dapat menjadi kenyataan.
c. Game instructional
Permainan dapat memiliki manfaat yang besar, antara lain lebih
mudah dipahami daripada model instruksi, karena mengurangi
tekanan di antara pengajar dan pelajar. Perangkat lunak aplikasi
permainan memiliki fitur-fitur yang dapat melibatkan orang untuk
dapat mencapai skor tertentu sebagai indikator pemahamannya.
Selain itu, dapat juga dilakukan dengan mengalahkan teman
sepermainan yang biasanya disediakan di dalamnya.
d. Drill and practice
Drill and practice menyediakan kesempatan bagi para pengguna
untuk melatih kembali keahlian masing-masing, yang pada sesi
sebelumnya telah dilalui. Sangat penting untuk terus mengulang di
dalam drill and practice karena untuk dapat menguasai sesuatu
harus dilakukan sesering mungkin.
e. Discovery
Discovery menyediakan sekumpulan informasi yang besar dan
spesifik di dalam sebuah konten, serta menantang kemampuan para
individu pengguna untuk meneliti, membandingka, mengambil
 89

kesimpulan, dan mengevaluasi berdasarkan pengeksplorasian

mereka terhadap konten tersebut.
f. Problem solving
Problem solving merupakan pendekatan yang membantu individu
pengguna untuk mengembangkan keahlian dan penyusunan strategi
di dalam menyelesaikan berbagai masalah yang spesifik.
2.2.4.3 Kelebihan dan Kekurangan Computer Assisted Instruction (CAI)
Nasution (2004:110) menyatakan bahwa ada beberapa
kelebihan dari CAI, yaitu sebagai berikut:
a. CAI dapat membantu pengajar dan pelajar di dalam pelajaran.
Karena komputer itu sabar, cermat, dan mempunyai ingatan yang
sempurna, CAI sangat sesuai untuk latihan dan remedial teaching.
Tak ada pengajar yang dapat memberi latihan tanpa jemu-jemunya
seperti komputer.
b. CAI memiliki banyak kemampuan yang dapat dimanfaatkan segera
seperti membuat hitungan atau memproduksi grafik, gambaran, dan
memberikan bermacam-macam informasi yang tak mungkin
dikuasai oleh manusia manapun.
c. CAI sangat fleksibel dalam mengajar dan dapat diatur menurut
keinginan peneliti pelajaran atau penyusunan kurikulum.
d. CAI dan proses pengajaran oleh pengajar dapat saling melengkapi.
Bila komputer tidak dapat menjawab pertanyaan pelajar, dengan
sendirinya pengajar akan menjawabnya. Ada kalanya komputer
dapat memberi jawaban yang tak dapat segera dijawab oleh
pengajar.
e. Komputer dapat pula menilai hasil dari setiap pelajaran dengan
segera.
Nasution (2004:110) menyatakan bahwa ada beberapa
kekurangan dari CAI, yaitu sebagai berikut:
a. Meskipun harga perangkat keras komputer cenderung semakin
menurun, pengembangan perangkat lunaknya masih relatif mahal.
b. Untuk menggunakan komputer, diperlukan pengetahuan dan
keterampilan khusus tentang komputer.
90

c. Keragaman model komputer atau perangkat keras sering

menyebabkan program yang tersedia untuk satu model tidak
compatible dengan model lainnya.
d. Program yang tersedia saat ini belum memperhitungkan kreativitas
pelajar, sehingga hal tersebut tentu tidak akan dapat membantu
mengembangkan kreativitas siswa.
e. Komputer hanya efektif bila digunakan oleh satu orang atau
beberapa orang dalam kelompok kecil. Untuk kelompok yang lebih
besar, diperlukan tambahan peralatan lain yang mampu
memproyeksikan pesan-pesan di monitor ke layar yang lebih besar.
2.2.5 Multimedia
2.2.5.1 Definisi Multimedia
Vaughan (2011:1) mendefinisikan multimedia sebagai
kombinasi dari teks, seni, suara, animasi, dan video yang disampaikan
untuk pengguna melalui komputer atau alat elektronik lainnya.
2.2.5.2 Elemen Multimedia
Vaughan (2011:11) menyatakan bahwa ada beberapa elemen
utama di dalam multimedia, yaitu sebagai berikut:
a. Teks
Teks merupakan media paling dasar di dalam banyak sistem
multimedia. Teks di dalam bentuk kata, kalimat, dan paragraf
digunakan untuk mengkomunikasikan pikiran, ide, dan fakta pada
hampir semua aspek kehidupan.
b. Gambar
Gambar adalah representasi grafik atau visual dari beberapa
informasi yang dapat ditampilkan di layar komputer atau media
cetak. Secara umum, gambar dapat dibagi menjadi dua jenis yaitu
bitmap dan vector graphics.
Bitmap merupakan matriks sederhana dari titik-titik kecil yang
membentuk sebuah image dan ditampilkan di layar komputer.
Sedangkan vector graphics merupakan salah satu tipe gambar yang
menggunakan satuan dot.
c. Suara
Suara merupakan sesuatu yang bergetar di udara, menciptakan
gelombang tekanan. Suara dapat menyediakan kenikmatan dalam
 91

mendengarkan musik, efek suara yang menakjubkan, atau sebagai

pengatur mood.
d. Animasi
Animasi dapat membuat presentasi yang statis menjadi hidup.
Animasi merupakan perubahan visual dari waktu ke waktu dan
dapat menambah kekuatan pada proyek multimedia dan halaman
web. Salah satu bentuk animasi ialah animasi 2D.
Animasi 2D ini sederhana dan statis, tidak mengubah posisi layar.
Dalam ruang 2D, perubahan visual yang menjadikan gambar hidup
dalam aksis cartesius x dan y pada layar. Cel animation didasarkan
pada bentuk perubahan yang terjadi satu frame berikutnya. Path
animation memindahkan objek di sepanjang jalan yang telah
ditetapkan pada layar.
e. Video
Dari semua elemen multimedia, video menempatkan tuntutan
performa tertinggi dalam komputer dari segi memori dan
penyimpanannya. Video digital merupakan sarana multimedia yang
paling menarik dan merupakan alat yang ampuh untuk membawa
pengguna komputer menjadi lebih dekat dengan dunia nyata. Video
klip yang direncanakan dengan hati-hati dan digarap dengan baik
dapat membuat perbedaan dramatis dalam sebuah proyek
multimedia.
2.2.6 Instructional Design
2.2.6.1 Pengertian Instruction
Gagne, Wager, Golas, dan Keller (2005:1) mendefinisikan
instruction sebagai serangkaian event atau kejadian yang dimasukkan
ke dalam aktivitas yang memiliki tujuan dalam memfasilitasi
pembelajaran.
2.2.6.2 Pengertian Instructional Design
Gagne, Wager, Golas, dan Keller (2005:2) memberikan
beberapa asumsinya untuk menjelaskan instructional design. Mereka
berpendapat bahwa setiap perancang harus mengaplikasikan pengertian
mereka dari prinsip dan event yang dapat mempengaruhi pembelajaran
dan menentukan bagaimana struktur instructional yang baik.
92

Instructional design tersebut harus lebih bertujuan kepada

proses dalam pembelajaran daripada proses pengajaran. Instructional
design harus juga bertujuan pada intentional learning yang bekebalikan
dengan incidental learning. Hal ini mengimplikasikan bahwa tujuan
pembelajaran yang diinginkan akan mengarahkan desain dan seleksi
dari aktivitas pembelajaran.
Pada asumsi kedua, mereka mengenali bahwa pembelajaran
merupakan sebuah proses yang kompleks yang dipengaruhi oleh
banyak variabel.
Untuk penjelasan selanjutnya, mereka juga berpendapat bahwa
model instructional design bisa diaplikasikan di level mana saja.
Prinsip dari instructional design bisa digunakan oleh seorang pengajar
atau pelatih yang merencanakan sebuah pengajaran untuk aktivitas
sehari, seorang pelatih yang menyiapkan workshop selama beberapa
hari, atau pengembang sebuah kurikulum dalam merancang sebuah
kursus. Instructional design ini bisa dari keinginan sendiri atau bisa
melibatkan sebuah tim perancang, ahli dalam bidang pelajaran tertentu,
ahli evaluasi, dan personel dalam proyek yang besar.
Asumsi yang lainnya mengatakan bahwa design merupakan
sebuah proses yang berulang yang memberikan pemahaman akan
bagaimana seseorang belajar saat in yang harus melibatkan pengajar di
dalamnya untuk merancang sebuah instruction. Tetapi bahan-bahan
pengajaran dan aktivitasnya harus diuji oleh pengajar untuk mengetahui
mana yang bisa digunakan dan mana yang tidak bisa digunakan.
Lalu pada asumsi kelima mengatakan bahwa instructional
design itu sendiri merupakan sebuah proses yang mengandung
subproses yang saling berhubungan dan telah diketahui. Pada level
yang paling mudah, instructional design adalah menarik garis antara
hasil yang diharapkan, metode instruksi, dan penilaian pelajar. Namun
jika kita menginginkan sebuah tipe hasil pembelajaran yang berbeda,
makan akan menghasilkan tipe instruksi yang berbeda pula.
2.2.6.3 Fase-fase Instructional System Design
Gagne, Wager, Golas, dan Keller (2005:18) menyatakan bahwa
sebuah sistem instructional dapat didefinisikan sebagai sebuah
 93

perencanaan dari sumber daya dan prosedur yang digunakan untuk

memfasilitasi suatu pembelajaran.
Instructional system design (ISD) merupakan sebuah proses
pembuatan sistem instructional, baik secara sistematis maupun
scientific yang dapat didokumentasikan, tersedia di dalam aplikasi
yangumum dan membawa kepada outcomes yang dapat diramalkan.
ISD ini mencakup beberapa fase, yaitu analysis, design, development,
implementation, dan evaluation.
a. Analysis
Dalam proses ISD ini, analisis yang dilakukan berkaitan dengan
konsep umum tentang pemenuhan kebutuhan. Oleh karena itu,
analisis yang dilakukan dalam model ADDIE ini memenuhi tiga
analisis kebutuhan, yaitu sebagai berikut:
1. Gap analysis, merupakan analisis yang coba untuk dimengerti
oleh para perancang apakah terdapat perbedaan antara kinerja di
lapangan dengan kinerja yang ingin dicapai. Oleh karena itu,
tahap ini lebih menganalisis tentang kebutuhan yang ada dan
yang diinginkan atau biasa disebut dengan analisis kebutuhan.
Analisis kebutuhan merupakan sebuah konsep penting karena
analisis ini tidak hanya mengidentifikasikan tujuan yang
diinginkan, tetapi juga berusaha untuk mengukur keadaan saat
ini sehingga dalam perkembangannya ke depan akan bisa
mempertemukan tujuan yang sudah ditetapkan.
2. Analisis karakteristik pembelajaran, merupakan sebuah analisis
yang mengidentifikasikan kebutuhan pembelajaran seperti apa
yang dibutuhkan dalam sebuah pembelajaran.
3. Analisis kebutuhan sumber daya, merupakan analisa yang lebih
menekankan kepada kondisi dari lingkungan dan batasan dari
kondisi tersebut. Hasil dari analisis ini berupa sumber daya apa
saja yang dibutuhkan di dalam sebuah pelajaran dan apakah ada
peralatan tertentu yang diperlukan untuk mendukung
pembelajaran.
b. Design
Komponen desain di dalam ISD ini akan menghasilkan sebuah
perencanaan atau blueprint yang digunakan sebagai landasan untuk
94

mengarahkan pada proses development dari instruksi. Dalam tahap

ini, seorang instructional designer membangun sebuah perencanaan
berdasarkan kebutuhan pembelajaran dan bekerja sama dengan ahli
dalam subyek tertentu untuk mengetahui skill yang diajarkan dan
strategi untuk mengajarkan mereka.
Produk dari desain ini adalah seperangkat spesifikasi atau
perencanaan kepada para developer dalam memproduksi
instructional support material. Proses prototyping menyediakan
sebuah peluang awal untuk mendapatkan feedback dari pengguna
untuk menekankan pada fungsionalitas, feasibility, dan keberadaan
dari sebuah instruksi. Prosedur yang digunakan dalam desain ini
adalah pendekatan top-down agar dapat mentransfer tujuan mata
pelajaran ke dalam tujuan dalam level performance.
c. Development
Tahap pengembangan dalam ISD ini mengacu pada persiapan
bahan-bahan yang akan digunakan dalam kegiatan belajar
mengajar. Tahap ini bisa didekatkan melalui beberapa arah,
tergantung dari hubungan antara instructional objective, level
kedetailan dalam merancang dokumen yang menyediakan inputan
untuk pengembangan, karakteristik, serta ketetapan dalam material
yang ada dan sistem perantara yang digunakan.
d. Implementation
Tahap implementasi dalam model ADDIE ini memiliki dua tipe.
Tipe yang pertama lebih diarahkan kepada implementasi
aktivitasnya yang muncul di saat pembelajaran masih dalam tahap
pembuatan dan evaluasi. Kondisi seperti ini disebut dengan pilot
testing atau field testing. Perihal kedua mengacu lebih kepada
meluncurkan pembelajaran yang sesungguhnya setelah
pengembangan selesai dikerjakan.
e. Evaluation
Tahap evaluasi merupakan tahap yang paling akhir di dalam ISD.
Evaluasi ini dapat muncul dalam beberapa point dan dapat muncul
dalam semua tahapan proses ISD, termasuk setelah fase
pengembangan dan juga setelah produk ini selesai
diimplementasikan.
 95

2.2.7 Konsep Object-Oriented Analysis and Design (OOAD) with the Unified
Process (UP)
Satzinger, Jackson, dan Burd (2005:60) mendefinisikan object-oriented
analysis sebagai proses mendefinisikan semua objek yang melakukan
pekerjaan di dalam suatu sistem dan menunjukkan interaksi pengguna apa saja
yang dibutuhkan untuk menyelesaikan tugas di dalam sistem.
Object-oriented design merupakan proses mendefinisikan semua jenis
objek yang diperlukan untuk berkomunikasi dengan orang maupun perangkat
di dalam sistem, menunjukkan bagaimana objek berinteraksi untuk
menyelesaikan tugas di dalam sistem, dan menyempurnakan definisi dari
setiap jenis objek sehingga dapat diimplementasikan dengan lingkungan atau
bahasa tertentu.
Unified process merupakan suatu metodologi pengembangan sistem
yang berorientasi objek yang dikembangkan oleh Rational Software, bagian
dari IBM.
2.2.7.1 Object-Oriented Analysis
Analisis sistem dibagi menjadi beberapa tahapan yaitu sebagai
berikut:
a. Gather detailed information
Tahapan gather detailed information dapat dilakukan dengan dua
cara, yaitu sebagai berikut:
1. Metode survei, yaitu dengan mengadakan penelitian yang
dilakukan dengan peninjauan langsung ke perusahaan.
2. Metode wawancara, yaitu dengan mengadakan tanya jawab
dengan pemilik perusahaan dan karyawan-karyawan yang
berhubungan dengan topik yang dibahas.
b. Define functional requirements
Tahapan define functional requirements dilakukan dengan
menentukan persyaratan sistem yang mendeskripsikan aktivitas
atau proses yang harus dilakukan oleh suatu sistem.
c. Define nonfunctional requirements
Tahapan define nonfunctional requirements dilakukan dengan
menentukan karakteristik dari suatu sistem selain aktivitas yang
harus dilakukan oleh sistem itu sendiri.
96

d. Prioritize requirements
Ketika persyaratan sistem telah sepenuhnya dimengerti dan detail
model dari persyaratan sistem telah lengkap, penting rasanya untuk
menentukan functional requirements dan nonfunctional
requirements mana yang paling krusial untuk sistem. Terkadang,
user atau pengguna menyarankan fungsi sistem tambahan yang
diinginkan namun tidak diperlukan. Bagaimanapun juga, pengguna
dan system analyst harus bertanya kepada diri mereka sendiri fungsi
mana yang benar-benar penting dan fungsi mana yang penting
namun tidak begitu dibutuhkan.
e. Develop user interface dialogs
Ketika suatu sistem menggantikan sistem lama yang melakukan
pekerjaan yang sama, user atau pengguna biasanya sangat yakin
dengan persyaratan sistem dan tampilan user interface yang
diinginkan oleh sistem. Tahapan ini merupakan tahap di mana
system analyst melakukan identifikasi dan merancang dialog untuk
user interface yang dibutuhkan di dalam sistem.
f. Evaluate requirements with users
Tahapan ini merupakan tahap di mana system analyst melakukan
evaluasi persyaratan sistem yang telah dibuat bersama user atau
pengguna. Biasanya, aktivitas di dalam mengevaluasi persyaratan
sistem dengan user atau pengguna dan mendokumentasikan
persyaratan sistem tersebut terintegrasi secara total. Namun, pada
kenyataannya, user atau pengguna biasanya memiliki tanggung
jawab lain selain mengembangkan suatu sistem yang baru. Jadi,
system analyst biasanya menggunakan iterative process atau proses
iterasi untuk mendapatkan masukan pengguna. Mengevaluasi
persyaratan sistem yang telah dibuat tidak selalu merupakan
aktivitas yang didefinisikan dengan baik. Banyak alternatif muncul
untuk desain akhir dan implementasi dari suatu sistem. Jadi, sangat
penting untuk mendefinisikannya dengan perlahan-lahan lalu
mengevaluasi segala kemungkinan yang ada.
Diagram yang digunakan di dalam object-oriented analysis
adalah sebagai berikut:
 97

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

Gambar 2.38 Contoh Activity Diagram (Satzinger, Jackson, dan

Burd)
b. Use Case Diagram
Use case diagram digunakan untuk menunjukkan interaksi
pengguna (actors) dengan suatu sistem.
Actor merupakan pengguna dari suatu sistem yang secara langsung
berinteraksi dengan sistem itu sendiri.
Berikut ini adalah komponen-komponen dari suatu Use Case
Diagram:
1. System Boundary
Menggambarkan batasan antara sistem dengan actor.
2. Use case
Menggambarkan apa yang dilakukan oleh actor di dalam
sistem.
3. Actor
Menggambarkan user atau pengguna dari suatu sistem.
4. Flow
Menggambarkan hubungan antara use case dengan actor.
98

Gambar 2.39 Contoh Use Case Diagram (Satzinger, Jackson, dan

Burd)
Use case description merupakan dokumen selanjutnya yang harus
dibuat ketika use case diagram telah selesai dirancang. Use case
description merupakan deskripsi rinci dari setiap use case yang ada
di dalam use case diagram.

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

Burd)
 99

c. Statechart Diagram
Statechart diagram digunakan untuk menjelaskan behavior umum
dari semua objek yang ada di dalam class, menggambarkan daur
hidup objek dan macam-macam state serta kejadian dari objek
tersebut.
Satzinger, Jackson, dan Burd (2005:237) menyatakan bahwa 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.

Gambar 2.41 Contoh Statechart Diagram (Satzinger, Jackson, dan

Burd)
100

2.2.7.2 Object-Oriented Design

Perancangan sistem dibagi menjadi beberapa tahapan yaitu
sebagai berikut:
2.2.7.2.1 Design the support services architecture and deployment
environment
Deployment environment terdiri dari perangkat keras,
perangkat lunak, dan jaringan di mana sistem akan
dijalankan.
Single-computer architecture merupakan arsitektur yang
menggunakan sistem komputer tunggal di dalam
menjalankan semua software aplikasi yang berhubungan,
sedangkan multitier architecture merupakan arsitektur yang
mendistribusikan software aplikasi yang berhubungan atau
memproses beban di beberapa sistem komputer.
Multitier architecture dapat dibagi menjadi dua macam,
yaitu sebagai berikut:
a. Clustered architecture
Merupakan satu kelompok komputer yang memiliki tipe
dan spesifikasi yang sama yang saling berbagi
pemrosesan beban dan bertindak layaknya suatu sistem
komputer yang besar.
b. Multicomputer architecture
Merupakan satu kelompok komputer yang memiliki tipe
dan spesifikasi yang berbeda yang saling berbagi
pemrosesan beban melalui fungsi yang khusus.
Centralized architecture merupakan arsitektur yang
menempatkan semua sumber daya komputer di lokasi pusat,
sedangkan distributed architecture merupakan arsitektur
yang menyebarkan sumber daya komputer di berbagai
lokasi yang dihubungkan oleh suatu jaringan komputer.
 101

Gambar 2.42 Single-computer, Clustered, dan Multicomputer

Architectures (Satzinger, Jackson, dan Burd)
2.2.7.2.2 Design the software architecture
Software architecture dapat dibagi menjadi dua macam,
yaitu sebagai berikut:
a. Client/server architecture (two-layer architecture),
merupakan arsitektur yang terdiri dari client layer dan
server layer.

Gambar 2.43 Client/Server Architecture (Satzinger, Jackson, dan Burd)

b. Three-layer architecture, merupakan arsitektur
client/server yang membagi suatu aplikasi menjadi view
layer, business logic layer, dan data layer.
View layer merupakan layer yang menerima inputan
pengguna dan kemudian menampilkan pemrosesan
input tersebut menjadi output.
102

Business logic layer merupakan layer yang

mengimplementasi aturan dan prosedur dari business
processing.
Data layer merupakan layer yang mengatur
penyimpanan data, biasanya di satu atau lebih dari satu
database.

Gambar 2.44 Three-layer Architecture (Satzinger, Jackson, dan Burd)

2.2.7.2.3 Design the use case realizations
a. Class Diagram
Class diagram digunakan untuk menunjukkan class dari
objek tertentu di dalam suatu sistem.
Satzinger, Jackson, dan Burd (2005:185) menyatakan
bahwa class diagram memiliki tiga bagian penting, yaitu
sebagai berikut:
1. Class name
Merupakan nama dari suatu class.
2. Attribute
Merupakan atribut-atribut yang dimiliki oleh suatu
class.
3. Method (behaviour)
Menjelaskan apa saja yang bisa dilakukan oleh
objek-objek di dalam suatu class.
 103

Gambar 2.45Contoh Class

Hubungan di dalam class diagram ada tiga, yaitu
sebagai berikut:
1. Aggregation
Merupakan hubungan antara objek dengan 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
104

independen (tidak bergantung) ke class yang

dependen (bergantung).
3. Ketika suatu objek membutuhkan informasi dari
objek yang lain, maka panah navigation visibility
akan menunjuk ke arah class yang dibutuhkan.
Domain model class diagram diubah menjadi updated
design class diagram dengan menambahkan tipe data
atribut dan visibility serta menambahkan method di
dalamnya.

Gambar 2.46 Contoh Updated Design Class Diagram (Satzinger, Jackson, dan
Burd)
b. Sequence Diagram
Sequence diagram digunakan untuk menjelaskan
interaksi beberapa objek pada waktu tertentu secara
berurutan.
Satzinger, Jackson, dan Burd (2005:229) menyatakan
bahwa notasi di dalam sequence diagram adalah sebagai
berikut:
 105

1. Actor
Merupakan pengguna yang berinteraksi secara
langsung dengan sistem.
2. Input messages
Merupakan pesan input dari pengguna ke dalam
suatu sistem.
3. Output messages
Merupakan pesan output dari suatu sistem ke
pengguna, hasil dari pemrosesan input.
4. Objects
Merupakan objek-objek yang berinteraksi di dalam
sequence diagram.
5. Object lifeline
Menggambarkan urutan pesan dari atas ke bawah.
Perancangan sequence diagram dimulai dari system
sequence diagram. System sequence diagram
menggambarkan hubungan input dan output antara
actor dan sistem untuk suatu use case atau skenario.

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

Burd)
First-cut sequence diagram dikembangkan berdasarkan
system sequence diagram. First-cut sequence diagram
106

menentukan objek mana saja yang dibutuhkan untuk

menjalankan suatu use case atau skenario.
Di dalam first-cut sequence diagram, kita mengganti
:System dengan sebuah objek controller dari suatu use
case, kemudian menambah objek-objek lain yang
dibutuhkan di dalam suatu use case. Langkah
selanjutnya adalah menentukan pesan mana yang perlu
dikirimkan untuk mengumpulkan informasi yang
dibutuhkan, termasuk objek mana yang akan menjadi
source dan objek mana yang akan menjadi destination.
Gunakan activation lifelines untuk mengindikasikan
suatu objek yang sedang menjalankan suatu method.

Gambar 2.48 Contoh First-Cut Sequence Diagram (Satzinger, Jackson, dan

Burd)
Multi layer sequence diagram dikembangkan
berdasarkan first-cut sequence diagram yang telah
dibuat.
Beberapa hal yang perlu diperhatikan dalam
mengembangkan view layer sequence diagram adalah
sebagai berikut:
1. Merancang user interface untuk setiap use case.
2. Mengembangkan dialog design untuk setiap form.
 107

3. Menambahkan class window ke dalam sequence

diagram.
Beberapa hal yang perlu diperhatikan dalam
mengembangkan data access layer sequence diagram:
1. Inisialisasi domain objects dengan data dari suatu
database.
2. Buatlah query untuk database dan kirim sebuah
objek referensi.
3. Masukkan return information di dalam objek
referensi.

Gambar 2.49 Contoh Multi Layer Sequence Diagram (Satzinger, Jackson, dan Burd)
c. Communication Diagram
Communication diagram dan sequence diagram 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.
108

Untuk actor, object, dan message, communication

diagram menggunakan simbol yang sama dengan
sequence diagram, namun simbol lifeline dan activation
lifeline tidak digunakan di dalam communication
diagram. Bagaimanapun juga, sebuah simbol yang lain,
yaitu simbol link digunakan di dalam perancangan
communication diagram. Link merupakan sebuah notasi
di dalam communication diagram yang membawa
message di antara object atau di antara actor dan object.

Gambar 2.50 Contoh Communication Diagram (Satzinger, Jackson, dan Burd)

d. Package Diagram
Package diagram merupakan suatu diagram UML yang
mengizinkan perancang untuk mengasosiasikan
beberapa class dari grup yang saling berkaitan.
Salah satu pilihan adalah dengan memisahkan view
layer, domain layer, dan data access layer ke dalam
package yang berbeda.
 109

Kesimpulannya, package diagram digunakan untuk

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

Gambar 2.51 Contoh Package Diagram (Satzinger, Jackson, dan Burd)

2.2.7.2.4 Design the database
a. Object-Oriented Database
Object database management system (ODBMS)
merupakan suatu sistem manajemen database yang
menyimpan data sebagai objek atau class dengan bahasa
pemrograman berbasis objek.
Untuk membuat object database schema dari suatu class
diagram, step-step yang dibutuhkan adalah sebagai
berikut:
1. Tentukan class mana yang membutuhkan persistent
storage.
2. Representasikan persistent classes.
3. Representasikan asosiasi antara persistent classes.
4. Pilih tipe data yang sesuai dan batasan value untuk
setiap field.
110

Class dapat dibagi menjadi dua macam untuk kegunaan

data manajemen, yaitu sebagai berikut:
1. Transient class, merupakan class yang tidak perlu
menyimpan nilai atribut objek antara instantiations
dan method invocations.
2. Persistent class, merupakan class yang harus
menyimpan satu atau lebih nilai atribut objek antara
instantiations dan method invocations.
Ada 2 macam asosiasi di dalam ODBMS, yaitu sebagai
berikut:
1. One-to-many associations, dan
2. Many-to-many associations.
b. Relational Database
Relational database management system (RDBMS)
merupakan suatu sistem manajemen database yang
menyimpan data di dalam tabel.
Beberapa istilah yang terdapat di dalam relational
database management system adalah sebagai berikut:
1. Table, merupakan strukur data dua dimensi yang
terdiri dari baris dan kolom, biasanya disebut juga
dengan relation.
2. Rows, merupakan porsi dari suatu tabel yang berisi
data yang mendeskripsikan satu class, asosiasi atau
objek, biasanya disebut juga dengan tuple atau
record.
3. Attribute, merupakan kolom dari relational model
database table, biasanya disebut juga dengan field.
4. Attribute value, merupakan nilai data yang disimpan
di dalam sel tunggal di dalam relational model
database, biasanya disebut juga dengan field value
atau elemen data.
5. Key, merupakan atribut yang berisi nilai yang
bersifat unik di dalam setiap baris di dalam tabel
relational database.
 111

6. Primary key, merupakan key yang digunakan untuk

mengidentifikasi suatu baris secara unik di dalam
tabel relational database.
7. Foreign key, merupakan nilai atribut yang disimpan
di dalam suatu tabel relational database yang juga
ada sebagai primary key di tabel relational database
lainnya.
Untuk membuat relational database schema, ikuti
langkah-langkah berikut ini:
1. Buatlah tabel untuk setiap class.
2. Pilih primary key untuk setiap tabel.
3. Tambahkan foreign key untuk merepresentasikan
hubungan one-to-many.
4. Buatlah tabel baru untuk merepresentasikan
hubungan many-to-many.
5. Representasikan klasifikasi hirarki.
6. Tentukan batasan integritas referensial.
7. Evaluasi kualitas schema dan buatlah perbaikan
yang diperlukan.
8. Pilih tipe data yang sesuai dan value restrictions
untuk setiap field (jika diperlukan).
2.2.7.2.5 Design the system and user interfaces
a. System interfaces
System interfaces merupakan input dan output di dalam
suatu sistem tanpa adanya campur tangan user atau
pengguna. Dengan kata lain, system interfaces
merupakan hubungan antar sistem.
Berikut ini merupakan beberapa kategori dari system
interfaces:
1. Input dari sistem lain.
2. Input yang sangat terotomatisasi.
3. Input dari data di database eksternal.
4. Output menuju database eksternal.
5. Output dengan tanpa human computer interaction.
6. Output menuju sistem lain.
112

7. Real-time connection (baik input maupun output).

b. User Interface
User interface terdiri dari input dan output yang
melibatkan pengguna sistem secara langsung.
Ada tiga aspek yang penting di dalam perancangan user
interface, yaitu sebagai berikut:
1. Physical aspects, terdiri dari perangkat yang
disentuh oleh user, termasuk keyboard, mouse,
touch screen, atau keypad.
2. Perceptual aspects, terdiri dari semua hal yang
dilihat, didengar, atau disentuh oleh pengguna akhir
(di luar physical devices), termasuk segala hal yang
terdapat di layar monitor.
3. Conceptual aspects, terdiri dari semua hal yang
diketahui oleh pengguna di dalam menggunakan
sistem.
User-centered design merupakan koleksi teknik yang
meletakkan pengguna di tengah-tengah proses
pengembangan user interface.
Ada tiga prinsip penting user-centered design, yaitu
sebagai berikut:
1. Fokus awal pada pengguna dan pekerjaan mereka.
2. Evaluasi desain untuk memasikan kegunaan.
3. Gunakan pengembangan yang berulang.

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