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.

O’Brien (2005:6) mendefinisikan sistem informasi sebagai

suatu kombinasi yang terorganisasi dari manusia, perangkat keras,

perangkat lunak, jaringan komunikasi, dan sumber daya data yang

mengumpulkan, mengubah, dan menyebarluaskan informasi di dalam

suatu perusahaan.

Stair dan Reynolds (2006:4) mendefinisikan sistem informasi

sebagai sekumpulan komponen yang saling berkaitan yang berfungsi

untuk mengumpulkan, memanipulasi, menyimpan, menyebarluaskan

data dan informasi yang diperlukan serta menyediakan mekanisme

umpan balik untuk mencapai suatu tujuan tertentu.

2.1.1.2 Komponen Sistem Informasi

Satzinger, Jackson, dan Burd (2005:8) menyatakan bahwa

komponen sistem informasi dapat digambarkan sebagai berikut:

Gambar 2.1 Komponen Sistem Informasi (Satzinger, Jackson, dan

Burd)

7

O’Brien (2005:22) menyatakan bahwa suatu sistem informasi

yang dinamis akan memiliki tiga komponen dasar yang saling

berinteraksi, yaitu sebagai berikut:

a. Input

Melibatkan pengambilan elemen yang memasuki suatu sistem

untuk kemudan diproses menjadi informasi.

b. Processing

Melibatkan proses yang mengubah input menjadi output.

c. Output

Melibatkan pengalihan elemen yang diproduksi oleh proses

perubahan kepada tujuan akhirnya.

2.1.2 Perangkat Lunak

2.1.2.1 Pengertian Perangkat Lunak

Pressman (2005:36) mendefinisikan perangkat lunak sebagai:

a. Instruksi (program komputer) yang ketika dijalankan menyediakan

fitur, fungsi, dan kinerja yang diinginkan.

b. Struktur data yang memungkinkan suatu program untuk

memanipulasi informasi.

c. Dokumen yang menggambarkan operasi dan kegunaan dari suatu

program.

2.1.2.2 Karakteristik Perangkat Lunak

Pressman (2005:37) menyatakan bahwa perangkat lunak

memiliki karakteristik yang berbeda dari perangkat keras, yaitu sebagai

berikut:

a. Perangkat lunak dikembangkan atau direkayasa, bukan diproduksi

dalam pengertian klasik

Walaupun terdapat beberapa persamaan di dalam pengembangan

perangkat lunak dan perangkat keras, namun kedua aktivitas ini

pada dasarnya sangat amat berbeda. Dari kedua aktivitas tersebut,

kualitas yang tinggi dicapai melalui desain yang baik, namun fase

manufaktur untuk perangkat keras dapat menjelaskan masalah

kualitas yang tidak terdapat pada perangkat lunak. Kedua aktivitas

tersebut membutuhkan konstruksi produk, namun dengan

pendekatan yang berbeda. Biaya perangkat lunak terpusat pada

8

bidang perekayasaan. Jadi kesimpulannya, proyek perangkat lunak

tidak dapat dikelola seperti proyek pemanufakturan.

b. Perangkat lunak tidak usang atau habis terpakai

Tingkat kegagalan perangkat keras yang tinggi biasanya disebabkan

oleh kesalahan perancangan atau kesalahan pembuatan di pabrik.

Setelah diperbaiki, biasanya tingkat kegagalan akan menurun

hingga ke suatu tingkat yang stabil untuk periode waktu tertentu.

Seiring dengan berjalannya waktu, tingkat kegagalan akan

meningkat kembali akibat pengaruh lingkungan terhadap komponen

perangkat keras. Dengan kata lain, perangkat keras menjadi usang.

Sedangkan pada perangkat lunak, tingkat kegagalan yang tinggi

biasanya disebabkan oleh keadaan yang tidak diperkirakan

sebelumnya. Setelah diperbaiki, tingkat kegagalan tersebut akan

menurun hingga ke suatu tingkat yang stabil. Jadi kesimpulannya,

perangkat lunak tidak akan pernah usang atau habis terpakai.

c. Meskipun industri bergerak menuju konstruksi berbasis komponen

(component-based construction), sebagian besar perangkat lunak

masih dibangun seperti biasa (custom built)

Komponen perangkat lunak seharusnya dirancang dan

diimplementasikan sehingga dapat digunakan berulang-ulang pada

beberapa program yang berbeda. Komponen yang dapat digunakan

berulang-ulang membungkus data dan proses yang diaplikasikan

kepada data, memungkinkan perekayasa perangkat lunak untuk

menciptakan aplikasi baru dari bagian yang dapat digunakan

berulang-ulang.

2.1.2.3 Proses Perangkat Lunak

Sommerville (2011:9) menyatakan bahwa proses di dalam suatu

perangkat lunak ada empat, yaitu sebagai berikut:

a. Software specification

Di mana pelanggan dan perekayasa mendefinisikan perangkat lunak

yang akan dikembangkan dan batasan-batasan pada operasinya.

b. Software development

Di mana perangkat lunak dirancang dan diprogram.

9

c. Software validation

Di mana perangkat lunak dicek untuk memastikan bahwa perangkat

lunak tersebut adalah apa yang dibutuhkan oleh pelanggan.

d. Software evolution

Di mana perangkat lunak dimodifikasi untuk memenuhi perubahan

kebutuhan dari pelanggan dan kebutuhan pasar.

2.1.2.4 Rekayasa Perangkat Lunak

Bauer, di dalam buku karangan Pressman (2005:53)

mendefinisikan rekayasa perangkat lunak sebagai pembentukan dan

penggunaan prinsip-prinsip rekayasa suara untuk menghasilkan

perangkat lunak yang ekonomis yang handal dan bekerja secara efisien

pada mesin nyata.

IEEE (Institute of Electrical and Electronics Engineers), di

dalam buku karangan Pressman (2005:53) mendefinisikan rekayasa

perangkat lunak sebagai suatu penerapan pendekatan sistematis,

disiplin, dan dapat diukur untuk pengembangan, operasi, dan

pemeliharaan perangkat lunak, yaitu penerapan rekayasa perangkat

lunak.

Sommerville (2011:24) mendefinisikan rekayasa perangkat

lunak sebagai disiplin rekayasa yang berkaitan dengan segala aspek

dari produksi perangkat lunak.

2.1.3 Interaksi Manusia dan Komputer

2.1.3.1 Pengertian Interaksi Manusia dan Komputer

Shneiderman dan Plaisant (2010:22) menyatakan bahwa

interaksi manusia dan komputer berkaitan dengan tampilan interface

yang digunakan oleh pengguna untuk berkomunikasi dan berinteraksi

dengan komputer.

Interaksi manusia dan komputer merupakan disiplin ilmu yang

berhubungan dengan perancangan, evaluasi, dan implementasi sistem

komputer interaktif yang diinginkan manusia. Kepentingan pengguna

harus diperhatikan di dalam membuat aplikasi komputer. Maka

diharapkan aplikasi yang dihasilkan harus seinteraktif mungkin dan

dapat digunakan dengan mudah oleh para pengguna.

10

2.1.3.2 Prinsip Perancangan Antarmuka

Shneiderman dan Plaisant (2010:74) menyatakan bahwa prinsip

perancangan antarmuka mengacu kepada delapan aturan emas atau

eight golden rules, yaitu sebagai berikut:

a. Usahakan untuk konsisten

Perancangan menu, warna, tampilan, jenis huruf pada antarmuka

harus dilakukan dengan konsisten.

b. Memenuhi kegunaan universal

Pengguna antarmuka sangat beragam, sehingga di dalam

merancang layar harus mempertimbangkan perbedaan di dalam hal

usia, hambatan fisik, dan variasi teknologi. Jadi, ada pemberian

petunjuk kepada pengguna pemula dan shortcut bagi pengguna

yang telah berpengalaman.

c. Memberikan umpan balik yang informatif

Untuk setiap aksi yang dilakukan oleh pengguna, harus diberikan

umpan balik agar tercipta suasana yang komunikatif. Pada aksi

yang bersifat kecil dan sering digunakan, respon yang diberikan

sederhana. Namun, pada aksi yang bersifat rumit dan jarang

digunakan, respon yang diberikan harus lebih rinci.

d. Merancang dialog untuk menghasilkan penutupan

Di dalam merancang komunikasi arus balik dengan pengguna,

urutan tindakan harus diatur sedemikian rupa dengan mengetahui

keadaan awal, tengah, dan tentu saja akhir.

e. Mencegah terjadinya kesalahan

Sebisa mungkin, suatu sistem dirancang untuk dapat mencegah

pengguna dari kesalahan fatal yang dapat terjadi. Sebagai contoh,

terdapat validasi pada formulir. Apabila pengguna melakukan

kesalahan, maka sistem harus menyediakan instruksi kepada

pengguna tentang bagaimana cara memperbaiki kesalahan tersebut.

f. Memungkinkan pembalikan aksi yang mudah

Ketika pengguna tidak sengaja melakukan aksi yang tidak

diinginkan dan ingin melakukan pembatalan, sistem harus

menyediakan fungsi pembatalan agar pengguna merasa nyaman dan

tidak takut di dalam mengeksplorasi sistem.

11

g. Mendukung pusat kendali internal

Pengguna memiliki kekuasaan atas suatu sistem sehingga dapat

mengontrol program-program yang ada di dalam sistem tersebut.

h. Mengurangi beban ingatan jangka pendek

Tampilan harus dibuat sesederhana mungkin sehingga pengguna

tidak perlu banyak mengingat. Tampilan dari setiap halaman harus

diperkuat dan frekuensi perpindahan jendela harus diminimalisasi.

2.1.4 Basis Data

2.1.4.1 Pengertian Basis Data

Connoly dan Begg (2010:65) mendefinisikan basis data sebagai

sekumpulan data yang berhubungan secara logikal serta dirancang

untuk memenuhi kebutuhan informasi yang dibutuhkan suatu

organisasi.

Williams dan Sawyer (2010:164) mendefinisikan basis data

sebagai koleksi data yang disimpan secara elektronik dalam sistem

komputer.

2.1.4.2 Database Management System

Connoly dan Begg (2010:68) menyatakan bahwa terdapat

beberapa komponen Database Management System, yaitu sebagai

berikut:

a. Hardware (perangkat keras)

DBMS membutuhkan perangkat keras untuk menjalankan

aplikasinya. Perangkat keras tersebut dapat meliputi suatu PC,

mainframe atau jaringan komputer.

b. Software (perangkat lunak)

Komponen perangkat lunak itu sendiri berupa program aplikasi atau

OS (Operating System).

c. Data

Data merupakan komponen yang penting dalam DBMS dan berasal

dari sudut pandang pengguna. Data berperan sebagai penghubung

antara pengguna dan mesin.

d. Prosedur

Prosedur merupakan 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

merupakan hubungan antar empat

entitas.

23

Gambar 2.4 Contoh Quarternary Relationship

4. Unary Relationship

Merupakan hubungan antar satu tipe entitas dimana tipe entitas

ikut serta lebih dari satu kali dengan peranan yang berbeda, atau

disebut juga recursive relationship.

Gambar 2.5 Contoh Unary Relationship

c. Attributes

Connoly dan Begg (2010:350) mendefinisikan atribut sebagai

property dari sebuah entitas atau tipe relasi. Attribut domain

merupakan kumpulan nilai yang diperbolehkan bagi satu atau lebih

atribut.

Connoly dan Begg (2010:351) menyatakan bahwa ada beberapa

jenis atribut, yaitu sebagai berikut:

1. Simple and composite attribute

Simple attribute adalah atribut yang terdiri dari satu komponen

tunggal dan tidak dapat dibagi menjadi bagian yang lebih kecil

lagi. Sementara composite attribute adalah atribut yang terdiri

dari komponen yang memiliki keberadaan yang independent.

2. Single and multi valued attribute

Single-valued attribute adalah atribut yang mempunyai nilai

tunggal untuk suatu peristiwa. Sedangkan multi-valued attribute

mempunyai beberapa nilai untuk suatu kejadian.

3. Derived attribute

Derived attribute merupakan atribut yang memiliki nilai yang

dihasilkan dari atribut lainnya dan dapat berasal dari banyak

entitas.

4. Keys

24

Connoly dan Begg (2010:352) menyatakan bahwa ada lima

jenis keys, yaitu sebagai berikut:

a. Candidate Key

Merupakan jumlah minimal atribut yang unik

mengidentifikasikan kejadian dari tipe entitas.

b. Primary Key

Merupakan candidate key yang dipilih untuk

mengidentifikasikan kejadian secara unik.

c. Composite Key

Merupakan candidate key yang terdiri dari dua atau lebih

atribut.

d. Alternate Key

Merupakan candidate key yang tidak dipilih menjadi

primary key, biasa disebut secondary key.

e. Foreign Key

Merupakan primary key pada entitas yang digunakan entitas

lainnya Structural Constraints.

Connoly dan Begg (2010:356) menyatakan bahwa constraint

seharusnya menggambarkan batasan dari relasi tanggapan dalam

keadaan sebenarnya.

Tipe utama dari constraint disebut dengan multiplicity. Multiplicity

merupakan jumlah kejadian yang mungkin terjadi pada entitas yang

berhubungan dengan sebuah kejadian dari tipe entitas yang

tergabung dalam relationship. Multiplicity biasanya terdiri dari dua

batasan terpisah, yaitu sebagai berikut:

1. Cardinality

Menjelaskan jumlah maksimum dari kejadian yang mungkin

terjadi antar entitas yang terikat dalam relasi tersebut.

2. Participation

Menetapakan jumlah entitas yang berhubungan dalam suatu

relasi.

Relasi yang umum merupakan binary relationship, yaitu

sebagai berikut:

a. One to One (1:1)

b. One to Many (1:*)

25

c. Many to Many (*:*)

2.2 Teori-teori Khusus

2.2.1 Enterprise Resource Planning

Wijaya dan Darudiato (2009:27) mendefinisikan Enterprise Resource

Planning (ERP) sebagai konsep untuk merencanakan dan mengelola sumber

daya perusahaan, yaitu berupa paket aplikasi program terintegrasi dan multi

modul yang dirancang untuk melayani dan mendukung berbagai fungsi dalam

perusahaan, sehingga pekerjaan menjadi lebih efisien dan dapat memberikan

pelayanan lebih bagi konsumen, yang akhirnya dapat menghasilkan nilai

tambah dan memberikan keuntungan maksimal bagi semua pihak yang

berkepentingan (stakeholder) atas perusahaan.

Wijaya dan Darudiato (2009:26) menyatakan bahwa integrasi dalam

konsep sistem ERP berhubungan dengan interpretasi sebagai berikut:

a. Menghubungkan antara berbagai aliran proses bisnis.

b. Metode dan teknik berkomunikasi.

c. Keselarasan dan sinkronisasi operasi bisnis.

d. Koordinasi operasi bisnis.

Wijaya dan Darudiato (2009:28) menyatakan bahwa konsep dasar ERP

dapat diterjemahkan sebagai berikut:

a. ERP terdiri atas paket perangkat lunak komersial yang menjamin integrasi

yang mulus atas semua aliran infomasi di perusahaan, yang meliputi

keuangan, akuntansi, sumber daya manusia, rantai pasok dan informasi

konsumen.

b. Sistem ERP adalah paket sistem informasi yang dapat dikonfigurasi, yang

mengintegrasikan informasi dan proses yang berbasis infomasi di dalam

dan melintas area fungsional dalam sebuah organisasi.

c. ERP merupakan satu basis data, satu aplikasi dan satu kesatuan antarmuka

di seluruh enterprise.

2.2.2 SAP

2.2.2.1 Pengertian SAP

SAP (Systems, Applications and Products in Data Processing)

adalah suatu perangkat lunak yang dikembangkan untuk mendukung

suatu organisasi dalam menjalankan kegiatan operasionalnya secara

lebih efisien dan efektif. SAP merupakan perangkat lunak Enterprise

26

Resources Planning (ERP), yaitu suatu alat IT dan manajemen untuk

membantu perusahaan merencanakan dan melakukan berbagai aktivitas

sehari-hari.

2.2.2.2 Modul-modul SAP

SAP (Systems, Applications and Products in Data Processing)

terdiri dari sejumlah modul aplikasi yang mempunyai kemampuan

mendukung semua transaksi yang perlu dilakukan suatu perusahaan

dan tiap aplikasi bekerja secara berkaitan satu dengan yang lainnya.

Semua modul aplikasi di SAP dapat bekerja secara terintegrasi dan

terhubung yang satu dengan yang lainnya.

Modul-modul di dalam SAP adalah sebagai berikut:

a. Sales and Distribution (SD)

Membantu meningkatkan efisiensi kegiatan operasional yang

berkaitan dengan proses pengelolaan customer order (proses sales,

shipping dan billing).

b. Materials Management (MM)

Membantu menjalankan proses pembelian (procurement) dan

pengelolaan inventory.

c. Production Planning (PP)

Membantu proses perencanaan dan kontrol daripada kegiatan

produksi (manufacturing) suatu perusahaan.

d. Quality Management (QM)

Membantu mengecek kualitas proses-proses di keseluruhan rantai

logistik.

e. Plant Maintenance (PM)

Merupakan suatu solusi untuk proses administrasi dan perbaikan

sistem secara teknis.

f. Human Resources Management (HRM)

Mengintegrasikan proses-proses HR mulai dari aplikasi

pendaftaran, administrasi pegawai, manajemen waktu, pembiayaan

untuk perjalanan, sampai ke proses pembayaran gaji pegawai.

g. Financial Accounting (FI)

Mencakup standard accounting cash management (treasury),

general ledger dan konsolidasi untuk tujuan pelaporan keuangan.

27

h. Controlling (CO)

Mencakup cost accounting, mulai dari cost center accounting, cost

element accounting, dan analisa profitabilitas.

i. Asset Management (AM)

Membantu pengelolaan atas keseluruhan fixed assets, meliputi

proses traditional asset accounting dan technical assets

management, sampai ke investment controlling.

j. Project System (PS)

Mengintegrasikan keseluruhan proses perencanaan proyek,

pengerjaan dan kontrol.

2.2.2.3 Financial Accounting

Wijaya dan Darudiato (2009:65) menyatakan bahwa dalam

sistem informasi accounting, perlu diperhatikan proses transaksi dan

penyusunan laporan keuangan. Pada sistem ERP, untuk penyusunan

laporan keuangan dilakukan melalui aplikasi program General Ledger.

Sebenarnya aplikasi program ini tidak ada penginputan proses data

transaksi, kecuali memorial jurnal.

2.2.2.3.1 General Ledger Accounting

2.2.2.3.1.1 Organizational Structures for Financial

Accounting

a. Company Code

Company Code merupakan entitas akuntansi yang

independen (elemen terkecil di dalam organisasi di

mana satu set lengkap dari account dapat dibuat).

Sebagai contoh: sebuah perusahaan di dalam suatu

kelompok perusahaan. Sebuah company code

memiliki empat karakter kunci yang unik, yang

dapat berupa tulisan maupun angka.

General ledger disimpan di tingkat company code

dan digunakan untuk membuat balance sheet

(laporan neraca saldo) yang legal dan profit-and-loss

statement (laporan laba rugi) untuk company code.

b. Business Area

28

Business area merupakan bagian bisnis, atau cabang,

di mana sebuah kelompok perusahaan beroperasi.

Sebagai contohnya, business area menyediakan

tingkat evaluasi tambahan untuk bagian pelaporan.

Penggunaan business area bersifat optional (boleh

digunakan boleh juga tidak).

c. Controlling Area

Controlling area merupakan elemen organisasi yang

paling penting di dalam aplikasi controlling.

Controlling area digunakan untuk internal

accounting (akuntansi di dalam perusahaan). Sebuah

controlling area mengidentifikasi suatu struktur

organisasi di mana biaya dan pendapatan dapat

dikelola dan dialokasikan. Controlling area

merepresentasikan bagian terpisah dari cost

accounting.

Lebih dari satu company code dapat di-assign ke

satu atau lebih controlling area. Hal ini

memungkinkan pembiayaan lintas company code

antara company code yang telah di-assign.

Bagaimanapun juga, meng-assign lebih dari satu

company code ke controlling area yang sama hanya

dimungkinkan apabila semua company code yang di-

assign menggunakan operating chart of account dan

kalender fiskal yang sama.

2.2.2.3.1.2 G/L Master Records

a. Chart of Accounts

Setiap general ledger diatur berdasarkan sebuah

chart of account. Chart of account terdiri dari

definisi dari semua G/L account di dalam format

yang tersusun. Definisi tersebut terdiri dari account

number (nomor akun), account name (nama akun),

dan tipe dari G/L account, yaitu apakah akun

tersebut merupakan akun tipe P&L (laba rugi) atau

akun tipe balance sheet (neraca saldo).

29

Kita dapat mendefinisikan chart of account dengan

jumlah yang tak terbatas di dalam sistem SAP. Di

dalam sistem baku SAP, terdapat banyak country-

specific chart of account.

Untuk setiap company code, kita harus menetapkan

satu chart of account untuk general ledger. Chart of

account ini di-assign ke company code di bagian

konfigurasi dan disebut juga sebagai operating chart

of account.

Sebuah chart of account dapat digunakan oleh

beberapa company code. Hal ini berarti bahwa

general ledger dari beberapa company code tersebut

memiliki struktur yang sama.

b. Settings for Company Codes

Sebelum kita dapat menggunakan sebuah akun di

dalam company code, kita harus mengelola definisi

akun tersebut pada level chart of account. Kita dapat

membuat company code-specific setting (pengaturan

spesifik untuk company code), di mana hanya

berlaku di dalam company code saja. Contoh dari

company code-specific setting adalah

mendefinisikan mata uang di dalam akun.

Kebanyakan akun di dalam company code 1000

menggunakan mata uang EUR (Euro), sedangkan

company code 3000 menggunakan mata uang USD

(Dollar) untuk akun-akunnya. Ketika mata uang

akun merupakan mata uang lokal untuk company

code, kita dapat melakukan posting ke dalam akun

tersebut dengan menggunakan mata uang apa saja.

30

Gambar 2.6 G/L Master Record (Central View)

Account group digunakan untuk mengatur dan

mengelola G/L account yang berjumlah banyak.

Ketika sebuah G/L account baru dibuat, account

group harus ditentukan di dalamnya.

Akun dengan account group yang sama biasanya

memiliki fungsi bisnis yang sama. Account group di-

assign number range. Melalui number range

tersebut, kita dapat mengontrol nomor akun yang

mana yang diizinkan untuk account group tertentu.

Account group juga mengontrol tampilan dari

segmen company code untuk G/L account. Biasanya,

account group mengontrol field mana saja yang

dibutuhkan untuk pengisian data, field mana saja

yang boleh diisi boleh juga tidak, dan field mana saja

yang tidak perlu ditampilkan di dalam segmen

company code.

Reconciliation account atau akun rekonsiliasi

menghubungkan buku pembantu dengan general

ledger (buku besar) pada real time. Hal ini berarti

bahwa posting ke buku pembantu akan

mengakibatkan posting ke reconciliation account

31

yang berhubungan di dalam general ledger pada

waktu yang sama.

Buku pembantu, yang dihubungkan ke general

ledger melalui reconciliation account, adalah

accounts payable, accounts receivable, dan asset

ledger.

Transaction figure mendeskripsikan jumlah posting

di dalam suatu akun pada debit atau kredit. Setiap

transaction figure untuk debit dan setiap transaction

figure untuk kredit selalu disimpan untuk setiap

akun di dalam sistem SAP. Laporan keuangan untuk

company code dihitung menggunakan transaction

figure tersebut.

Jika suatu G/L account memiliki tampilan line item

yang ditandai di master record, kita dapat

menelusuri dari saldo akun menuju line item dan

kemudian ke dokumen.

Jika menggunakan business area, transaction figure

juga disimpan untuk setiap business area. Jika kita

membuat sebuah laporan keuangan untuk business

area, transaction figure untuk business area tersebut

digunakan untuk menyediakan informasi bagi

laporan keuangan.

c. Financial Statement Versions

General ledger disimpan untuk menyediakan

informasi yang dibutuhkan bagi pembuatan laporan

neraca saldo dan laporan laba rugi. Laporan-laporan

tersebut harus memenuhi persyaratan spesifik untuk

negara di mana suatu perusahaan berada.

Untuk memenuhi kebutuhan tersebut, maka berbagai

macam versi laporan keuangan harus dibuat di

dalam sistem SAP. Di dalam beberapa versi laporan

keuangan tersebut, kita mendefinisikan akun mana

yang akan tampil di line item dari laporan keuangan.

32

Banyak versi laporan keuangan dimasukkan ke

dalam sistem SAP.

Bagaimanapun juga, suatu negara harus melaporkan

laporan keuangan mereka ke pihak yang berwenang

di negara mereka menggunakan country-specific

chart of account dari negara mereka. Agar laporan

eksternal dapat berisi nomor akun yang digunakan di

negara-negara tersebut, sebuah country-specific

chart of account dibuat untuk company code yang

ada. Country-specific chart of account tersebut harus

memenuhi persyaratan dari negara di mana suatu

perusahaan berada.

Di segmen company code dari master record, setiap

G/L account harus di-assign ke sebuah akun dari

company code. Hal ini dilakukan dengan

menggunakan field alternative account number.

d. Group Chart of Accounts

Karena tidak semua company code menggunakan

operating chart of account yang sama, group chart

of account digunakan untuk tujuan konsolidasi.

Operating chart of account di-assign ke group chart

of account pada bagian konfigurasi.

Ketika operating chart of account telah di-assign ke

group chart of account, field nomor akun grup

(group account number) menjadi dibutuhkan di

segmen chart of account dari master record.

2.2.2.3.1.3 Accounting Transactions – Processing in the

General Ledger

33

Gambar 2.7 G/L Account Postings

Layar pengentrian data dibagi menjadi beberapa

area, yaitu sebagai berikut:

a. Work templates

Di sini, kita dapat memilih variasi layar, account

assignment template, atau held document sebagai

referensi. Held document merupakan dokumen

yang disimpan oleh pengguna tanpa melakukan

posting, dengan ide bahwa pengguna akan

melengkapi dan melakukan posting untuk

dokumen tersebut nanti.

b. Header data

Header data berlaku untuk keseluruhan

dokumen, seperti tanggal posting dan tipe

dokumen. Beberapa header data dapat berupa

format tampilan saja, atau tersembunyi dari

pengguna melalui pilihan edit.

c. Line item information

Di sini, line item untuk dokumen dimasukkan.

d. Information area

Di sini, saldo debit dan kredit ditampilkan

dengan menggunakan ikon traffic light.

34

Gambar 2.8 G/L Document Entry Enjoy Screen

Gambar 2.9 G/L Document Entry Complex First Screen

Gambar 2.10 G/L Document Entry Complex Second Screen

35

Document type atau tipe dokumen digunakan untuk

membedakan berbagai macam dokumen akuntasi

dengan mudah. Setiap dokumen di-assign ke satu

tipe dokumen, di mana dimasukkan di dalam

document header. Nomor dokumen disediakan oleh

document number range yang di-assign ke satu atau

lebih tipe dokumen.

Gambar 2.11 Important Standard Document Types

Ada beberapa tipe dokumen standar di dalam sistem

SAP, yaitu sebagai berikut:

a. CI (Customer invoices)

b. CC (Customer credit memos)

c. CP (Customer payments)

d. GLD (G/L account documents)

e. VI (Vendor invoices)

f. VC (Vendor credit memos)

g. VP (Vendor payments)

h. VN (Vendor net invoices and credit memos)

Untuk posting pada G/L account, tipe dokumen SA

paling sering digunakan, meskipun tipe dokumen

lain juga dapat digunakan, seperti dokumen accrual

atau deferral, dokumen valuasi, dan lain-lain.

Setiap line item memiliki satu posting key. Posting

key merupakan suatu instrumen yang digunakan

untuk kontrol internal dan dimasukkan di dalam

36

layar complex posting untuk memberitahu sistem

dua hal, yaitu:

a. Tipe akun mana yang digunakan untuk

melakukan posting

b. Apakah line item tersebut merupakan posting

debit atau kredit

Di enjoy screen, kita tidak dapat menggunakan

posting key. Debit merepresentasikan posting key 40

dan kredit merepresentasikan posting key 50.

Posting key tersebut muncul di dalam dokumen dan

fungsi kontrol mereka masih tetap relevan.

Gambar 2.12 Standard Posting Keys

Di dalam sistem SAP, ada banyak posting key yang

baku. Setiap posting key digunakan untuk

melakukan posting debit atau kredit ke satu tipe

akun.

Untuk posting di dalam general ledger, kita hanya

membutuhkan dua macam posting key, yaitu:

a. 40, untuk item debit

b. 50, untuk item kredit

Balance display dan line item display disediakan

untuk menampilkan data akun. Line item display

hanya dimungkinkan untuk G/L account di mana

fungsi yang sesuai telah diaktifkan di dalam master

record.

Balance display merupakan tampilan keseluruhan

dari transaction figure yang telah disimpan dari

37

suatu akun. Kita dapat menelusuri dari saldo menuju

daftar item yang membentuk saldo.

Dari daftar line item pertama, kita dapat menelusuri

ke dokumen yang berisi line item tersebut. Dari situ,

kita dapat melihat transaksi lengkap dengan memilih

document overview.

2.2.2.3.2 Accounts Payable

Bodnar dan Hopwood (2004:334) mendefinisikan accounts

payable atau hutang usaha sebagai tanggung jawab untuk memenuhi

pembayaran kepada vendor.

Brigham dan Houston (2006:207) mendefinisikan accounts

payable atau hutang usaha sebagai hutang yang muncul akibat

penjualan kredit dan dicatat sebagai piutang oleh pihak penjual dan

hutang oleh pihak pembeli.

2.2.2.3.2.1 Vendor Master Records

Sama seperti G/L account, vendor account juga

terdiri dari dua area, yaitu:

a. Suatu vendor account didefinisikan untuk semua

company code pada tingkat client. General data,

seperti nama dan alamat vendor, disimpan di sini.

b. Posting tidak dapat dilakukan ke akun untuk

company code hingga company code-specific setting

(pengaturan spesifik untuk company code) dibuat.

Pengaturan ini mengacu kepada company code yang

relevan dan termasuk detailnya, seperti kondisi

pembayaran yang telah disetujui atau reconciliation

account (akun rekonsiliasi).

38

Gambar 2.13 Initial Screen to Display a Vendor Master Record

Vendor account dapat dibagi ke dalam beberapa

account group sama seperti G/L account, sehingga

mereka dapat diatur dan dikelola dengan lebih

mudah. Bagaimanapun juga, account group

mengontrol tampilan layar dari semua area vendor

master record, tidak hanya company code data saja.

Akun-akun yang ada di dalam suatu account group

biasanya memiliki beberapa karakteristik yang sama.

Sebagai contoh, kita dapat memiliki satu account

group untuk vendor domestik, satu account group

untuk vendor luar negeri, satu account group untuk

vendor afiliasi, dan satu account group untuk 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)