Anda di halaman 1dari 68

DESAIN DATABASE MENGGUNAKAN MODEL DATA

REA

A. Pengertian Database
Pengertian database menurut James A Hall
Database adalah adanya pemahaman bahwa data perusahaan harus
menunjang kebutuhan informasi semua pengguna dalam organisasi tersebut.
Karena itu satu aspek penting dalam pemodelan data adalah membuat suatu model
yang diyakini mencerminkan realitas organisasi1.
Pengertian Database menurut Romney dan Steinbart
Menurut Romney dan Steinbart dan staibart database adalah program komputer
khusus yang mengelola dan mengendalikan data serta peralatan lainnya, yaitu
antara lain data program aplikasi.
Sedangkan Menurut kami database adalah serangkaian informasi yang
berupa data yang nantinya digunakan oleh organisasi untuk membuat model SIA
yang mencerminkan informasi yang sebenarnya dari sebuah organisasi2.
B. Proses Desain Database
Dalam sebuah sistem informasi akuntansi kita harus menyediakan database
yang handal karena hal tersebut dapat dijadikan sebagai sebuah panduan yang
penting untuk mencari informasi. Guna database yang relevan itu untuk analisis
biaya dan perencanaan pajak yang dilakukan pada sebuah organisasi. Berikut
adalah langkah-langkah untuk mendesain database seperti gambar di bawah ini :

Analisis
1 James, A. Hall. Sistem Informasi Akuntansi. Edisi Ketujuh, Jakarta: Salemba
Empat, 2010.
sistem
2 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

Pemodelan Data
terjadi di sini

Desain
konseptual

Desain fisik

model data digunakan


Implementas
i dan
konversi

disini

Operasi dan
pemeliharaa
n

Gambar : Proses Desain database

Dari gambar diatas dapat dijelaskan bahwa tahap-tahap proses desain


database dimulai dari tahap analisis sistem, dimana pada tahap ini kita mulai dari
perencanaan awal yang gunanya untuk untuk kebutuhan para pengguna (user)
untuk merancang sistem yang baru. Tahap analisis sitem mempertimbangkan
tentang kebutuhan pengguna, menjelaskan segala aspek mengenai sistem baru
yang

akan

diajukan.

Kemudian

dalam

analisis

sistem

diperlukan

informasimengenai jumlah pengguna dan volume transaksi yang diharapkan yang


dapat digukanan untuk pengambilan keputusan awal yang dapat digunakan untuk
kebutuhan perangkat, baik perangkat keras atapun perangkat lunak.

Tahap kedua yaitu desain konseptual, mengembangkan uraian penalaran


dari sistem yang diusulkan untuk menentukan berbagai alternative pemenuhan
kebutuhan pengguna sistem, mengembangkan skema logis untuk sistem yang baru
pada tingkat konseptual. Agar tujuan sistem dapat tercapai batas-batas sistem baru
harus komprehensif. Jika batas-batas terlalu luas proyek pengembangan sistem
akan menjadi sangat luas dan akibantya adalah pengimplementasian sistem baru
sangat sulit diterapkkan. Adanya tim kerja yang mendesain batas-batas sistem
dapat mengupayakan agar prosedur-prosedur sistem lamatidak terlalu banyak
yang dirubah.
Tahap ketiga yaitu, desain fisik menurut nugroho wijayanto (2001:
304) didalam bukunya Sistem informasi Akuntansi adalah penerjamahaan
persyaratan sistem informasi akuntansi ke dalam spesifikasi rinci sehingga dapat
dipergunakan untuk penyusunan kode dan pengujian program komputer 1. Pada
tahap ini kita harus membuat secara jelas mengenai desain sistem secara tertulis.
Selain itu desain fisik itu dapat diartikan sebagai penentuan fisik dari komponenkomponen sebuah sistem informasi akuntansi. Desain fisik biasanya dapat berupa
desain inputdesain file databasedesain inputdesain programdesain
Prosedur
Tahap keempat yaitu tahap implementasi dan konversi segala aktifitas yang
terkait dengan pentransferan data dari sistem yang sudah ada sebelumya ke sistem
informasi akuntansi database yang baru, dari menguji sistem baru sampai pada
melatih karyawan agar para pegawai mengerti menggunakannya. Kegiatan
konversi itu dapat diartikan sebagai perubahan dari sistem yang lama ke sistem
yang baru, biasanya konversi tersebut mencakup perangkat lunak, perangkat
keras, file data, prosedur-prosedur.

11Nugroho Wijayanto, sistem informasi akuntansi. jakarta: erlangga,


20012Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi
13. Jakarta: Salemba Empat. 2014.

Tahap kelima yaitu operasi dan pemeliharaan, salah satu cara


pengembangan sistem adalah mengoperasikan dan memelihara sistem baru.
Untuk memastikan agar sistem baru telah berjalan sesuai dengan tujuan yang
ditetapkan, tim kerja harus melakukan evaluasi. Selain itu melakukan pengawasan
terhadap kinerja sistem dan kepuasan pengguna untuk menentukan kebutuhan
untuk membuat peningkatan modifikasi sistem.
Para akuntan diharapkan agar dapat berpartisipasi dalam setiap proses
desain database dimana para akuntan tersebut dapat membatu dalam hal
pengevaluasian proyek dan mengidentifikasi kebutuhan informasi para penguna.
Selain itu para akuntan dibutuhkan untuk menguji ketepatan database yang baru.
Sehubungan dengan itu para akuntan banyak yang menjadi pengguna regular dari
database bahkan mereka memiliki tanggung jawab atas manajemennya yang di
karenakan sering berpartisipasi.
C. Pemodelan data
Pemodelan data menurut Romney dan Steinbart adalah : Proses menjelaskan
sebuah database, sehingga ia dengan jujur merepresentasikan seluruh aspek
organisasi, termasuk interaksinya dengan lingkungan eksternal1.
Pemodelan data menurut kami adalah : database yang menjelaskan seluruh aspek
baik itu secara ekplisit yang dapat menyimpan data dan selalu berhubungan
dengan aktivitas bisnis.
D. Diagram Hubungan- Entitas
Menurut Romney dan Steinbart diagram hubungan-entitas (entity-relationship- ER diagram) adalah : Sebuah teknik grafis untuk menggambarkan sebuah skema
database.

1 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

Menurut para ahli :


Brady dan Loonam (2010), diagram hubungan entitas adalah : Teknik yang
digunakan untuk memodelkan kebutuhan data dari suatu organisasi, biasanya oleh
sistem analisis dalam tahap analisis persyaratan proyek pengembangan sistem.1
Whitten and Bentley (2007 : 271), diagram hubungan entitas adalah : sebuah
diagram yang menggambarkan data dalam bentuk entitas-entitas beserta hubungan
yang terbentuk antar data tersebut.2
Diagram hubungan entitas menurut kami adalah : sebuah tehnik grafis yang tidak
hanya berkaitan dengan skema database tetapi juga menggambarkan data dalam
bentuk entitas-entitas dengan menyertakan hubungan yang terkait dengan entitas,
hubungan, dan batasan.

E. Pengertian Entitas
Entitas menurut Romney dan Steinbart adalah : apa pun mengenai apa yang
organisasi ingin kumpulkan dan simpan mengenai informasi. 3 Sedangkan entitas
menurut kami adalah segala sesuatu yang dapat digambarkan oleh data yang
memiliki hubungan antar segmen data mengenai peristiwa bisnis. Sebagai
contoh :penjualan ke pelanggan dan pengiriman dari pemasok.
Biasanya dalam sebuah database relasional tabel- tabel terpisah akan
dibuat untuk menyimpan informasi mengenai setiap entitas yang berbeda dalam
diagram E-R biasanya entitas digambarkankan sebagai segi empat.

1 Brady dan loonam 2010


2 Whitten dan Benley 2007
3 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

Berikut ini diagram E-R menurut nugroho wijayanto : 1


1 pemas

memasok

ok

baran
g

disimpan

Diagram E-R
Dari gambar diatas dapat dijelaskan bahwa simbol segi empat dapat
dikatakan sebagai entitas, dan simbol berlian dapat menunjukan hubungan.
Simbol garis yang disertai dengan angka 1 menunjukan hubungan satu dan hurum
M menunjukan hubungan banyak. Pada gambar diatas jelas bahwa setiap pemasok
dapat memasok berbagai jenis barang (hubungan 1 dan M), dan berbagai jenis
barang dapat di simpan berbagai lokasi (hubungan M dengan M).

F. Model data REA


Model data REA menurut Romney dan Steinbart adalah data yang digunakan
untuk mendesain database SIA. Ia mengandung informasi mengenai tiga jenis
entitas yang fundamental : sumber daya, peristiwa dan agen.2
Model data REA menurut James A Hall adalah sebuah framework akuntansi untuk
memodelkan resources, events, dan agents yang penting dalam suatu organisasi
dan membuat garis hubungan/keterkaitan diantara ketiganya.3
Pengertian Model data REA menurut kami adalah framework akuntansi yang
terdiri dari data yang dapat digunakan

untuk mendesain database SIA yang

mempunyai hubugan antara sumber daya, peristiwa dan agen.

1 Nugroho Wijayanto, sistem informasi akuntansi. jakarta: erlangga, 2001


2 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

3 James, A. Hall. Sistem Informasi Akuntansi. Edisi Ketujuh, Jakarta: Salemba Empat, 2010.

lokasi

G. Tiga Jenis Dasar Entitas


Sumber daya yang didapatkan dan digunakan organisasi, peristiwa (aktivitas
bisnis) yang dijalankan organisasi, serta agen yang berpartisipasi dalam peristiwa
ini adalah tiga kategori yang berbeda dalam pengklasifikasian entitas, dari
mengklasifikasikan entitas inilah yang dinamai Model data REA .
1. Sumber Daya (resources) menurut Romney dan Steinbart adalah
hal-hal yang memiliki nilai ekonomis untuk organisasi.
Sumber Daya (resources) menurut James A Hall adalah semua hal
yang memiliki nilai ekonomi terhadap perusahaan.
Sumber Daya (resources) menurut kami adalah semua hal yang
dapat memberikan nilai ekonomi baik jangka pendek maupun jangka
panjang bagi perusahaan/organisasi.
2. Peristiwa (event) menurut Romney dan Steinbart adalah berbagai
aktivitas bisnis mengenai informasi apa yang manajemen ingin
kumpulkan untuk perencanaan atau tujuan pengendalian.1
Peristiwa (event) menurut James Hall adalah fenomena yang
mempengaruhi

perubahan

(baik

peningkatan

atau

penurunan)

resources seperi disajikan dalam hubungan aliran persediaan (stock


flow).
Peristiwa (event) menurut kami adalah hal-hal yang berkaitan
dengan berbagai aktivitas bisnis yang menunjukan hubungan aliran
persediaan
manajemen

serta
untuk

tentang

informasi

melakukan

yang

perencanaan

sudah
dan

dikumpulkan
untuk

tujuan

pengendalian organisasi.
3. Agen (agents) menurut Romney dan Steinbart adalah orang dan
organisasi yang berpartisipasi dalam peristiwa dan mengenai bagi

1 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

siapa informasi diperlukan bagi perencanaan, pengendalian dan tujuan


evaluasi.1
Agen (agents) menurut James A Hall adalah orang-orang atau
department yang terlibat dalam economic events dan support events.2
Agen (agents) menurut kami adalah orang-orang yang terlibat atau
berpartisipasi dalam peristiwa ekonomi dan peristiwa pendukung
untuk tujuan perencanaan,pengendalian dan tujuan evaluasi.
Menurut james hall diagram rancangan dasar sebuah diagram REA sebagai
Berikut :
participate
External economic
agent

Stock flow
Economic
Resource

Economic
event
Internal economic
agent

Duality

participate

Gambar : Basic REA model

Economic Resource
Yang dimaksud dengan peristiwa ekonomi adalah semua hal yang
memiliki nilai ekonomi terhadap perusahaan. Secara definisi adalah semua objek
baik yang langka maupun yang masih berada dalam kendali perusahaan.sumber
daya biasanya digunakan dalam pertukaran ekonomi dengan para rekan bisnis
entah mengalami kenaikan atau penurunan akibat pertukaran tersebut.
1 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi.
Edisi 13. Jakarta: Salemba Empat. 2014.
2 James, A. Hall. Sistem Informasi Akuntansi. Edisi Ketujuh, Jakarta: Salemba Empat, 2010.

Economic Events.
Pemodelan REA mencakup dua peristiwa.. Yang dimaksud dengan
peristiwa ekonomi adalah fenomena yang mempengaruhi perubahan (baik
peningkatan atau penurunan) resources seperi disajikan dalam hubungan aliran
persediaan (stock flow) pada gambar diatas . Hal itu disebabkan oleh berbagai
macam aktivitas seperti penjualan produk ke pelanggan, penerimaan uang dari
pelanggan, dan pembelian bahan baku dari vendor. Economic events adalah
elemen sistem informasi yang sangat penting dan harus ditangkap secara terpilah
atau serinci mungkin supaya memberikan suatu database yang lengkap.
Support events mencakup pengendalian (control), perencanaan, dan
berbagai aktivitas manajemen yang terkait dengan economic events, tetapi tidak
secara langsung memberi efek perubahan resources. Contoh support events adalah
(1) menentukan ketersediaan inventori untuk pelanggan sebelum melakukan
penjualan, (2) melakukan verifikasi terhadap informasi pendukung (dengan
melakukan pencocokan tiga dokumen/three-way-match) sebelum melakukan
pembayaran ke vendor, dan (3) melaukan pengecekan kartu kredit sebelum
memproses penjualan.
Agents.
Agen ekonomi adalah orang-orang atau department yang terlibat dalam
economic events dan support events. Mereka adalah pihak-pihak baik di dalam
maupun di luar organisasi yang memegang kebijaksanaan untuk memutuskan
akan menggunakan atau menolak dalam transaksi economic resources. Masingmasing economic event terkait dengan setidaknya satu agent internal atau satu
agent eksternal yang terlibat dalam pertukaran/transaksi tersebut. Peran masingmasing agent internal dan eksternal dengab pihak luar biasanya terlihat jelas.
Contohnya, dalam transaksi penjualan, agent internal adalah para karyawan
perusahaan dan eksternal agent adalah pelanggan. Namun, untuk transaksi yang
terjadi internal dalam perusahaan, peran agent internal dan eksternal tidak begitu
terlihat jelas. Kesepakatan atau konvensi dalam pemodelan REA adalah
menganggap transaksi semacam itu adalah seperti transaksi penjualan. Contohnya,

dalam proses pemindahan produk dari work-in-process ke inventory barang jadi,


maka karyawan bagian work-in-process dianggap sebagai agent yang menjual
produk ke karyawan bagian inventory barang jadi. Jadi karyawan yang
menyerahkan kendali dan mengurangi resources (dalam hal ini karyawan bagian
work-in-process) adalah internal agent sedangkan karyawan yang baru memegang
kendali dan menambah resource (dalam hal ini adalah karyawan bagian inventory
barang jadi) adalah eksternal agent.
Agent internal dan eksternal juga terlibat dalam support events, namun
jenis pertukaran/transaksi yang terjadi adalah transaksi/pertukaran informasi dan
bukan economic resources. Contohnya, pelanggan (agent eksternal ) yang
mengecek harga produk menerima informasi dari karyawan penjualan (internal
agent), yang menyerahkan informasi. Dengan mengaitkan agents internal dengan
cara ini akan meningkatkan pengendalian dan memungkinkan organisasi menilai
berbagai tindakan yang diambil oleh para karyawannya.
Dualitas. Fitur semantik REA diturunkan dari komponen-komponen
dalam transaksi ekonomi. Dasar pemikiran dibalik transaksi ekonomi adalah
bahwa dua agents memberikan resource kepada yang lain dan dengan cara
menukar resource yang lain sebagai gantinya. Dalam realitanya, pertukaran
tersebut adalah sepasang economic events, yang disajikan melalui asosiasi
dualitas.
Sedangkan menurut kami rancangan dasar sebuah diagram REA adalah semua
peristiwa yang saling berhubungan baik itu yang berhubungan dengan agen
maupun sumber daya ekonomi yang mewakili seluruh kegiatan yang sesuai
dengan pemodelan sistem informasi akuntansi.
H. Menyusun hubungan : Rancangan REA dasar
Pola dasar entitas ditentukan oleh sumber daya, peristiwa dan agen. Fitur-fitur
esensial dasar dari pola tersebut adalah sebagai berikut :

10

1. Setiap peristiwa ditautkan ke setidaknya satu sumber daya yang ia


pengaruhi
2. Setiap peristiwa ditautkan ke setidaknya satu peristiwa lainnya
3. Setiap peristiwa ditautkan ke setidaknya dua agen yang berpartisipasi.

pelaku
Sumber
daya

Arus masuk

Menerima
sumber daya
A

pelaku

Pelaku
internal
Pelaku
eksterna
l

Dualitas ekonomi

pelaku

Sumber
daya

Pelaku
internal

Arus keluar
Memberi
sumber daya
B

pelaku
Pelaku
internal

Gambar : rancangan REA standard

Pada gambar yang berbentuk wajik diatas menunjukkan penjelasan jenis


hubungan, yang mana agen ikut serta dalam kejadian ini. Merefleksikan fakta
dimana organisasi harus menyerahkan satu sumber daya seperti kas, dan untuk
mendapatkan sumber daya lainnya seperti persediaan adalah hubungan dualisme
ekonomi diantara peristiwa mendapatkan dan peristiwa memberikan.

11

Merepresentasikan baik arus masuk dan arus keluar sumber daya merupakan
hubungan alir stok antara sebuah peristiwa dan sebuah sumber daya.

Aturan 1: Setiap Entitas Peristiwa Harus Ditautkan ke Setidaknya Satu


Entitas Sumber Daya
Wajib menghubungkan peristiwa setidaknya ke satu sumber daya yang
dipengaruhi. Seperti yang terdapat pada gambar di atas dalam beberapa peristiwa
yang dilabeli Mendapatkan Sumber Daya A, sebuah sumber daya yang
ditingkatkan kualitasnya. Seperti dalam penerimaan pembayaran dari pelanggan
yang meningkatkan jumlah kas dan penerimaan barang dari pemasok yang
meningkatkan

kualitas

persediaan

ditangan

termasuk

dari

peristiwa

mendapatkan. Dan dalam peristiwa lainnya secara lansung menurunkan kualitas


sebuah sumber daya yang dilabeli Memberikan Sumber Daya B. seperti
membayar pemasok dan menjual barang, yang menurunkan jumlah kas dan
kualitas

persediaan

ditangan

secara

berurutan

termasuk

dari

peristiwa

memberikan.
Hubungan alir stok yaitu menunjukkan baik arus masuk atau arus keluar
sumber daya dan kadang disebut juga sebagai hubungan yang memengaruhi
kualitas sumber daya. Meski demikian, kualitas sumber daya secara langsung
tidak dapat diubah oleh setiap peristiwa yang ada. Seperti pemesanan ke pemasok
yang memperlihatkan komitmen yang nanti menghasilkan pembelian persediaan
berikutnya, sama seperti permintaan dari pelanggan yang memperlihatkan
komitmen yang nantinya menunjukkan penjualan barang dimasa yang akan
datang. Tetapi dalam gambar diatas tidak terdapat peristiwa komitmen seperti itu.
Meskipun organisasi perlu melacak pengaruh dari komitmen tersebut, baik dalam
untuk tujuan perencanaan maupun dalam menyediakan jasa yang lebih baik.
Misalnya, dalam permintaan pelanggan itu dapat menurunkan kualitas yang
tersedia atas barang persediaan spesifik yang dipesannya. Para staf penjualan
harus mengetahui peristiwa ini supaya dapat merespon dengan layak pertanyaan
dari permintan pelanggan selanjutnya. Informasi mengenai pesanan/permintaan

12

pelanggan untuk merencanakan produksi mungkin yang digunakan oleh


perusahaan manufaktur.

Aturan 2: Setiap Entitas Peristiwa Harus Ditautkan ke Setidaknya Satu


Entitas Peristiwa Lainnya
Pada gambar rancangan REA standard, memperlihatkan bahwa peristiwa
Mendapatkan Sumber Daya A dihubungkan dengan peristiwa Memberi Sumber
Daya B, terdapat hubungan dualisme ekonomi yang dilabeli. Hubungan dualisme
dapat dijelaskan dengan siklus akuntansi dan biasanya beberapa peristiwa
dikaitkan dengan peristiwa yang lainnya.

Aturan 3: setiap entitas peristiwa harus ditautkan ke setidaknya dua agen


yang berpartisipasi
Untuk melacak tindakan para pegawai sebuah organisasi harus bersifat
akuntabilitas agar dapat mengetahui perilaku pegawai. Jika pertukaran dualisme
ekonomi dijalankan oleh pihak luar maka organisasi itu perlu mengawasi status
komitmen pegawainya. Seperti tampak pada gambar rancangan REA standard
yang mana sering ditautkannya entitas yang berpartisipasi. Pegawai yang
bertanggung jawab atas sumber daya adalah agen internal sedangkan pegawai
yang menerima penyimpanan atau dengan asumsi tanggung jawab adalah agen
eksternal.
Memberi
persediaan

Siklus pendapatan

Mendapatka
n kas

Menurut kami siklus pendapatan bertujuan untuk memfasilitasi pertukaran


barang dan jasa yang dimiliki oleh perusahaan dengan kas yang dimiliki oleh
konsumen

13

Siklus
Memberi kas

siklus pengeluaran

Mendapatka
n persediaan

Menurut kami pada siklus ini menggambarkan peristiwa ekonomi seperti


permintaan barang, penerimaan barang, mencatat kewajiban untuk membayar
barang dan peristiwa mendapatkan persediaan yang diminta.

Memberi kas

Siklus pengajian

Mendapatkan
waktu

Menurut kami pada siklus ini menggambarkan kerlibatan pihak manajemen


dalam melakukan pembayaran dengan cara memberi kas terhadap pegawai yang
telah meberikan waktunya untuk melakukan suatu pekerjaan.

Memberikan
kas

Siklus pembiayaan

Mendapatkan
kas

Menurut kami pada siklus ini biasanya dalam melakukan peristiwa sekonomi
biasnya pembiyaan yang dikeluarkan seperti membeli barang , dan seringkali
tujuan akhirnya adalah mendapatkan kas.

Siklus produksi
Memberi
waktu pegawai
14

Mendapatkan
persediaan

Memberi
bahan baku

Memberi
mesin dan
peralatan

Menurut kami biasanya siklus produksi memproses transaksi akuntansi


yang mencatatperistiwa ekonomi diantaranya permintaan barang dan jasa oleh
pelanggan, pengiriman barang atau jasanya, permintaan pembayaran, dan tanda
terima pembayaran. Dan akhir dari proses produksi tersebut adalah mendapatkan
persediaan yangdigunakan dalam suatu proses produksi.

I. Mengembangkan Sebuah Diagram REA


Mengembangkan sebuah diagram REA bagi satu siklus bisnis spesifik terdiri atas
tiga langkah berikut :
1. Mengidentifikasi peristiwa mengenai informasi apa yang ingin manajemen
kumpulkan.
2. Mengidentifikasi sumber daya yang dipengaruhi oleh tiap peristiwa dan
agen yang berpartisipasi dalam peristiwa tersebut.
3. Menemukan kardinalitas dari setiap hubungan.

Langkah 1 : mengidentifikasi peristiwa yang relevan


Mengidentifikasi peristiwa yang menarik bagi manajemen merupakan
siklus tunggal yang digunakan unutk menggembangkan model REA. Dalam
model REA merepresentasikan pertukaran ekonomi dasar memberi-untukmendapatkan. Mengidentifikasi peristiwa mana yang mengandung hubungan
15

dualisme ekonomi dasar memberi-untuk-mendapatkan merupakan sebuah


pemahaman yang solid atas aktivitas-aktivitas yang dijalankan dalam setiap siklus
bisnis.
Sebagai contoh siklus pendapatan, ada 4 aktivitas-aktivitas yang saling
berurutan seperti mengambil pesanan pelanggan, maksudnya adalah dia tidak
melibatkan akuisisi sumber daya dari atau provisi sumber daya ke seorang pihak
eksternal. mengisi pesananan pesanan pelanggan, pihak eksternal biasanya
menerima stok sumber daya organisasi yang memiliki nilai ekonomis yang
bertujuan untuk pengurangan sumber daya. menagih pelanggan, biasanya pada
tahap ini sering dilakukannya pertukaran informasi yang dapat mengakan
peningkatan atau penurunan kuantitas sumber daya ekonomi, dan mengumpulkan
pembayaran dari pelanggan.
Tidak ada peristiwa entri data, karena dalam model REA digunakan untuk
mendesign database pemrosesan transakasi. Apa yang dimodelkan dalam REA
adalah peristiwa bisnis (missal transaksi dan penjualan) dan fakta bahwa
manajemen ingin mengumpulkan informasi mengenai peristiwa itu, bukan entri
dari data tersebut.
Langkah 2 : mengidentifikasi sumber daya dan agen
Sumber daya yang dipengaruhi peristiwa perlu diidentifikasikan, untuk dapat
menjawab pertanyaan:

Sumber daya ekonomi apa yang dikurangi dari peristiwa


Sumber daya apa yang didapatan dari peristiwa
Sumber daya apa yang dipengaruhi sebuah peristiwa komitmen

Untuk

dapat

menjawab

pertanyaan-pertanyaan

tersebut

diperlukan

pemahaman yang baik atas siklus bisnis proses. Untuk dapat mengidentifikasi
sumber daya yang terkait dalam peristiwa, perlu juga untuk mengidentifikasi agen
yang terlibat. Setidaknya akan selalu ada satu agen internal dan dalam beberapa
kasus seorang agen eksternal yang berpartisipasi dalam setiap peristiwa.Didalam
diagram REA sering terjadi peristiwa pertukaran ekonomi yang melibatkan pihak
eksternal dan pihak internal organisasi.

16

Langkah 3 : Menentukan Kardinalitas Hubungan.


Kardinalitas menurut Romney dan Steinbart adalah menjelaskan sifat dari
sebuah hubungan database yang mengindikasikan jumlah jumlah keterjadian satu
entitas yang mungkin diasosiasikan dengan sebuah peristiwa tunggal dari entitas
lain.1
Kardinalitas menurut kami adalah : sifat hubungan antra dua entitas dengan
mengindikasikan seberapa banyak contoh dari satu entitas dapat ditautkan ke tiap
contoh spesifik dari entitas lainnya.
Terdapat empat kombinasi yang mungkin dari kardinalitas. Kardinalitas
minimum dapat bernilai 1 atau 0 tergantung apakah pada hubungan kedua entitas
adalah keharusan atau opsional. Kardinalitas maksimum dapat bernilai satu atau
banyak tergantung pada apakah tiap contoh entitas A dapat ditautkan ke
setidaknya satu contoh atau secara potensial dapat ke banyak contoh entitas B.
Diagram REA sering merepresentasikan sebuah set pada tiap- tiap entitas.
Seperti bagian atau set penjualan merepresntasikan transaksi penjualan contoh
yang lebih spesifik adalah tiap-tiap baris dalam tabel pelanggan akan menyimpan
informasi mengenai seorang pelanggan tersebut yang biasanya ada pada sebuah
database relasional.

Di bawah ini merupakan symbol dari kardnalitas :


Satu dan hanya Satu

Satu atau lebih


1 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

17

Tidak ada atau lebih

Tidak ada atau satu


Terdapat 3 (tiga) hubungan utama antara satu entitas dengan entitas lainnya.
yaitu:
Menurut Romney dan Steinbart :1

Hubungan satu-ke-satu (1:1)


Sebuah hubungan antara dua entitas saat kardanalitas maksimum untuk
tiap entitas adalah 1.

Hubungan satu ke banyak (1:N)


Sebuah hubungan antara dua entitas ketika kardanalitas maksimum bagi
satu entitas adalah satu, tetapi entitas lain memiliki kardanalitas
maksimum yang banyak.

Hubungan banyak-ke- banyak (M:N)


Sebuah hubungan antara dua entitas saat maksimum kardanalitas kedua
entitas adalah banyak.

Menurut kami :

Hubungan satu-ke Satu, suatu hubungan dimana entitas pertama hanya


mempunyai 1 hubungan pada entitas kedua

Hubungan satu-ke-banyak, suatu hubungan dimana 1 entitas pertama

bisa mempunyai banyak hubungan pada entitas kedua


Hubungan banyak-ke banyak, setiap entitas pertama dapat mempunyai
banyak hubungan pada entitas yang kedua. begitu juga sebaliknya, setiap
entitas yang kedua bisa memiliki banyak hubungan pada entitas pertama.

1 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

18

Menurut Romney dan Steinbart Sebuah diagram REA bagi satu siklus
bisnis spesifik memiliki 3 langkah seperti yang disebutkan diatas, tetapi menurut
James Hall pada pemodelan sebuah diagram REA individual memiliki 4 (empat)
langkah yaitu 1:

Identifikasi entitas-entitas event


Identifikasi entitas-entitas resource
Identifikasi entitas-entitas agent
Menentukan asosiasi dan kardinalitas antar entitas

Prosedur tersebut dilakukan pada setiap fungsi organisasi yang sedang


dimodelkan. Hasilnya adalah kumpulan dari diagram REA individu. Proses
pemodelan kemudian selesai setelah fase integrasi pandangan dimana semua
model individu disatukan ke dalam satu model global tunggal.
Menurut kami pemodelan REA baik itu bagi siklus bisnis spesifik maupun
model REA individual, yang terpenting adalah kedua-duanya berkaitan dengan
resource (sumber daya), event (peristiwa), agent (agen) dan kardanalitas dari
setiap hubungan.
Contoh Kasus
Apex Supply Company adalah grosir barang-barang listrik di pusat kota
Philadelphia yang menjual ke para pengecer listrik. Dia memiliki inventori sekitar
10.000 item. Pelanggan memesan melalui phone dan membeli secara kredit
melalui konektivitas line-of-credit yang sudah di set sebelumnya dengan Apex.
Transaksi secara umum melibatkan pelanggan yang mengontak department
customer services terlebih dahulu untuk memverifikasi ketersediaan dan
mengecek harga item yang dicari.
Bila pelanggan memutuskan untuk membeli, dia kemudian dihubungkan
ke agent/karyawan penjualan yang menangani pemesanan tersebut. Karyawan
bagian pengiriman kemudian mengirimkan barang ke pelanggan melalui jasa
pengantaran umum (common carrier). Karyawan bagian penagihan mencatat
penjualan di jurnal penjualan, menyiapkan invoice, dan mengirimkannya ke
pelanggan yang diberu waktu selama 30 hari untuk membayar.
1 James, A. Hall. Sistem Informasi Akuntansi. Edisi Ketujuh, Jakarta: Salemba Empat, 2010.

19

Karyawan bagian piutang (AR) juga menerima copy invoice tersebut dan
mencatat di ledger piutang (AR ledger). Berikutnya (dalam 30 hari) pelanggan
mengirimkan check dan remittance advice ke Apex. Karyawan bagian penerimaan
uang menerima check, mencatatnya ke dalam jurnal penerimaan uang, dan
mengupdate akun kas/uang. Remittance advice kemudian diteruskan ke karyawan
bagian piutang (AR), yang mengupdate (mengurangi) piutang pelanggan

Pemecahan Masalah yang berkaitan dengan model diagram REA individual.

Langkah 1 : identifikasi entitas-entitas event

Langkah pertama dalam mengembangkan model REA adalah melakukan


identifikasi entitas-entitas event pada fungsi yang sedang dimodelkan. Events
pada contoh siklus revenue tersebut bisa diidentifikasi melalui tindakan/aktivitas
yang memiliki nilai tambah (added-value) yang diambil oleh para karyawan Apex.
Entitas-entitas ini adalah Memverifikasi Ketersediaan (Verify Availability),
Menangani Pesanan (Take Order), Mengirim Barang (Ship Product), dan
Menerima Uang (Receive Cash). Suatu model REA setidaknya harus meliputi
dua, sumber daya ekonomi yang terdiri dari aktivitas memberi dan mendapatkan
yang

mengurangi

dan

menambah

sumber

daya

ekonomi

dalam

pertukaran/transaksi. Selain itu, mungkin saja melibatkan support events, yang


tidak mengubah sumber daya secara langsung.

Event
Order of Event
Verify avilability

Take order

20

Ship product

Receive cash

Gambar : mengidentifikasi entitas-entitas event


Verify Avalilability / Memverifikasi Ketersediaan.
Event Verify Availability / Memverifikasi Ketersediaan adalah support
event karena tidak secara langsung menambah atau mengurangi resource.
Keputusan untuk menambahkan entitas ini ke dalam model akan tergantung pada
kebutuhan manager akan informasi yang berkaitan dengan pertanyaan pelanggan.
Informasi seperti ini bisa membantu untuk menentukan item-item inventory mana
saja yang paling sering diinginkan oleh pelanggan. Mungkin saja hal itu berbeda
dengan apa yang dijual Apex ke pelanggannya.
Contohnya, analisa terhadap berbagai

pertanyaan

yang

tidak

menghasilkan pemesanan mungkin menunjukkan bahwa pelanggan hanya sedang


ingin tahu saja, dan mendapatkan harga yang lebih baik dari para pesaing Apex.
Karena itu kita akan asumsikan bahwa Verify Availability / Memverifikasi
Ketersediaan adalah aktivitas yang memiliki nilai tambah (added-value) yang
harus dimodelkan pada diagram REA.
Take Order / Menangani Pesanan.
Tergantung dengan keadaan, Take Order / Menangani Pesanan bisa
merupakan economic event atau bisa juga support event. Menangani suatu
pesanan pada umumnya hanya melibatkan komitmen pada bagian penjual untuk
menjual barang ke pelanggan. Hal ini mungkin saja bahkan melibatkan
penyesuaian (pengurangan) inventori yang tersedia untuk penjualan untuk
mencegah barang tersebut dijual atau yang telah dijanjikan ke pelanggan yang
lain. Namun, komitmen ini tidak menyebabkan pengurangan inventori secara riil
dan bukan merupakan pertukaran/transaksi ekonomi. Terlebih lagi, bila kemudian

21

klien membatalkan pesanan sebelum barang dikirim, maka tidak ada


pertukaran/transaksi ekonomi yang terjadi. Sebaliknya, bila menangani suatu
pesanan menyebabkan pembeli mengeluarkan resource untuk mendapatkan atau
membuat produk atas permintaan pelanggan, maka economic event telang
berlangsung.

Untuk

keperluan

maksud

dalam

contoh

ini,

kita

akan

mengasumsikan bahwa tidak ada efek-efek ekonomi yang diturunkan dari event
Take Order / Menangani Pesanan dan karena ini adalah dukungan even.
Ship Product / Mengirimkan Barang. Ship Product / Mengirimkan Barang
adalah economic event. ini adalah bagian give dari pertukaran/transaksi ekonomi
dan mengurangi inventory resource secara langsung.
Receive cash/ menerima uang. Serupa dengan diatas, dimana menerima uang
merupakan peristiwa ekonomi. Ini adalah bagian menerima dari pertukaran
sehingga menambah sumber daya uang.
Langkah 2 : Identifikasi entitas-entitas resource
Mengidentifikasi resources yang terkait dengan events yang sudah dipilih
untuk dimodelkan. Setiap peristiwa ekonomi

dalam satu model REA harus

dihubungkan minimal dengan satu entitas sumber daya yang nilai ekonominya
akan berkurang atau bertambah akibat peristiwa tersebut. Dukungan peristiwa
juga terkait dengan resources tetapi tidak menimbulkan perubahan nilai resource.
Ada orang yang mungkin berpendapat secara teori bahwa semua tindakan
karyawan, termasuk support events seperti Verify Availability / Memverifikasi
Ketersediaan atau Take Order / Menangani Pesanan, menggunakan resource yang
disebut Jasa Karyawan. Dalam kanyataannya, resource ini naik ketika karyawan
memberikan layanannya ke organisasi dan secara bersamaan menurun ketika
layanan tersebut diterapkan dalam kinerja pekerjaan.
Dalam situasi dimana Jasa Karyawan dilacak hingga ke aktivitas atau
produk khusus, entitas ini akan memberikan data yang bermanfaat dan seharusnya
dimasukkan ke dalam model REA. Karena kita menganggap bahwa ini bukan
kasus untuk Apex Supply, Jasa Karyawan tidak akan dimodelkan disini.

22

Dalam siklus pendapatan (revenue cycle) Apex, economic events hanya


mengubah dua resources. Event Ship Product / Mengirim Barang mengurangi
resource inventory dan event Receive Cash / Menerima Uang menambah resource
uang/cash. Support events Verify Availability / Memverifikasi Ketersediaan dan
Take Order / Menangani Pesanan juga terasosiasi dengan inventory, tetapi tidak
mengubahnya. Resource dan entitas-entitas event yang terkait disajikan

Langkah 3 : Identifikasi entitas-entitas agen

Setiap peristiwa ekonomi dalam entitas, pada diagram REA terasosiasi


minimal dengan dua entitas agent. Satu agent internal dan yang lain adalah
agent eksternal. Agent eksternal yang terkait dengan semua empat event
pada kasus Apex adalah Pelanggan. Selain itu, empat agent internal yang
terkait dengan empat event tersebut:

karyawan customer service, yang terlibat dalam event Verify Availability /


Memverifikasi Ketersediaan.

karyawan sales represtative (penjualan), yang terlibat dalam event Take


Order / Menangani Pesanan.

karyawan pengiriman (shipping clerk), yang terlibat dalam event Ship


Product / Mengirim Barang.

karyawan penerima uang/cash, yang terlibat dalam event Receive Cash /


Menerima Uang.

Langkah 4 : Menentukan asosiasi dan kardinalitas antar entitas


Asosiasi adalah sifat dasar dari hubungan antar entitas, seperti yang
disajikan oleh garis yang diberi label yang menghubungkan antar entitas tersebut.
Kardinalitas (derajat aosiasi antar entitas) menjelaskan banyaknya kejadian yang

23

mungkin terjadi dalam satu entitas yang terkait dengan satu kejadian tunggal
dalam entitas yang berhubungan tersebut. Empat bentuk dasar kardinalitas yang
mungkin ada: zero or one (0,1), one and only one (1,1), zero or many (0,M), and
one or many (1,M).

Respon to costumer
Costumer service
Verify availibility

Related to

request

costumer

Proses order
inventory

Sales
rrespresentatif

Take order

causes
reduces

ships

Shipping clerk

Ship product

receives
duality

costumer

increase
Receive cash
cash
24

Cash receipts
celrk

proceses

Dari gambar di atas kami menjelaskan proses asosiasi dan kardanalitas antar
entitas. Sebagai berikut :
Kardinalitas normal antara entitas Customer / Pelanggan dan Take Order /
Menerima Pesanan adalah 1,1 dan 0,M. Ini berarti bahwa pelanggan tertentu bisa
saja membuat pesanan sebanyak nol (zero) atau banyak (many) selama periode
penjualan dan bahwa setiap pemesanan hanya untuk satu pelanggan. Asosiasi
antar entitas ini adalah 1:M dan tidak pernah jadi 1:1 karena ini akan berarti
bahwa organisasi membatasi setiap pelanggan hanya boleh membuat satu pesanan
saja, yang berarti tidak logis. Asosiasi antar entitas event dan agents internal
mengikuti pola yang sama. Organisasi menghendaki karyawan-karyawannya
terlibat dalam banyak events, tidak hanya satu saja. Kebanyakan kardinalitas pada
gambar 10-8 mencerminkan aturan yang cukup jelas. Beberapa hal yang
memerlukan

penjelasan

lebih

lanjut

akan

disajikan

berikutnya.

Kardinalitas antara entitas-entitas Verify Availability / Menverifikasi


Ketersediaan dan Take Order / Menangani Pesanan.
Setiap kejadian dari entitas Verify Availability / Memverifikasi
Ketersediaan adalah hasil dari pertanyaan yang diajukan oleh pelanggan. Namun,
kita ketahui dari deskripsi kasus tersebut bahwa tidak semua pertanyaan berlanjut
menjadi pesanan pelanggan. Sebaliknya, kita akan menyederhanakan asumsi ini
bahwa setiap kejadian Take Order / Menangani Pesanan adalah hasil dari suatu
pertanyaan. Karena itu kardinalitas pada sisi Take Order / Menangani Pesanan dari
hubungan tersebut adalah 0,1. Sedangkan pada sisi Verify Availability /
Memverifikasi Ketersediaan adalah 1,1.

25

Kardinalitas antara entitas-entitas Take Order / Menangani Pesanan dan


Ship Product / Mengirimkan Barang.
Kardinalitas 0,1 pada sisi Ship Product / Mengirimkan Barang dari relasi
ini mencerminkan adanya selisih waktu antara pesanan ketika ditangani dengan
dikrimkan. Ketika penjualan tidak diproses dengan cepat, kita mengasumsikan
bahwa ada pesanan (kejadian Take Order / Menangani Pesanan) yang belum
dikirimkan (tidak ada kejadian Ship Product / Mengirimkan Barang). Selanjutnya,
pesanan yang dibatalkan sebelum dikirimkan tidak akan menyebabkan pencatatan
Ship Product / Mengiriman Barang.

Kardinalitas antara entitas-entitas Ship Product / Mengirimkan Barang dan


Receive Cash / Menerima Uang.
Istilah bisnis untuk perdagangan dan kebijakan pembayaran sangatlah
beragam. Banyak perusahaan yang melakukan penjualan secara kredit kepada
pelanggan seringkali menerima pembayaran parsial (sebagian-sebagian) selama
beberapa waktu. Hal ini akan menyebabkan banyak kejadian untuk penerimaan
uang/cash untuk satu kejadian pengiriman. Sebaliknya, banyak perusahaan yang
pelanggannya adalah organisasi bisnis biasanya menghendaki pembayaran penuh
ketika jatuh tempo. Namun demikian, para pelanggan bisnis bisa saja menyatukan
banyak invoice pada satu pembayaran uang/cash untuk mengurangi menuliskan
check. Karena perusahaan Apex ini adalah grosir yang melayani para pelanggan
bisnis, kita akan mengasumsikan bahwa piutang dibayarkan secara penuh (bukan
pembayaran secara parsial) dan bahwa para pelanggan Apex bisa saja membayar
untuk banyak pengiriman dengan satu kali penerimaan uang/cash saja.

Kardinalitas antara entitas-entitas Cash / Uang dan Receive Cash /


Menerima Uang.
Resource uang/cash dari organisasi terdiri dari beberapa akun yang
berbeda, seperti akun general operating, payroll imprest account, petty cash (uang

26

kecil), dan seterusnya. Semua itu disatukan ke dalam satu akun tunggal untuk
pelaporan keuangan, tetapi digunakan dan dilacak secara terpisah. Kardinalitas
yang digambarkan dalam hubungan ini menunjukkan bahwa uang/cash diterima
dari banyak pelanggan dan didepositokan menjadi satu akun.
Asosiasi many-to-many. Model pada gambar 10-8 menggambarkan tiga
contoh asosiasi M:M. Yang pertama adalah antara antitas-entitas Verify
Availability / Memverifikasi Ketersediaan dan Inventory

/ Persediaan.

Kardinalitas 1,M ada pada sisi Inventory (Persediaan) dan kardinalitas 0,M
terletak sisi Verify Availability / Memverifikasi Ketersediaan. Hal ini
menunjukkan bahwa permintaan pelanggan tertentu melibatkan satu atau banyak
item inventory (persediaan), dan setiap item mungkin telah ditanyakan sebanyak
nol (zero) atau banyak kali pada periode tersebut.
Asosiasi M:M yang kedua ada antara entitas-entitas Take Order /
Menangani Pesanan dan Inventory (Persediaan). Kardinalitas 1,M ada pada sisi
Inventory (Persediaan) dan kardinalitas 0,M pada sisi Take Order / Menangani
Pesanan. Ini berarti bahwa pesanan tertentu bisa berisi satu atau banyak item
inventory (persediaan) yang berbeda dan bahwa suatu item tertentu bisa saja tidak
pernah dipesan sama sekali (barangkali produk baru) atau mungkin telah dipesan
banyak kali selama periode tersebut.
Situasi yang mirip ada antara entitas-entitas Ship Product / Mengirimkan
Barang dan Inventory / Persediaan. Pada masing-masing kasus ini kardinalitas
atas dari M menciptakan asosiasi M:M, . Situasi ini adalah hasil dari data yang
berulang yang perlu dinormalkan sebelum mengimplementasikan model tersebut
ke database relasional. Solusinya adalah dengan membuat tiga tabel penghubung
yang berisi primary key dari tabel-tabel yang terasosiasi. Tabel-tabel penghubung
ini juga akan berisi detil-detil yang berkaitan dengan item-item yang ditanyakan,
pesanan-pesanan yang ditangani, dan barang-barang yang dikirim.

J. Makna Bisnis Kardinalitas

27

Seperti yang telah dijelaskan diatas bahwa tidaklah semaunya pilihan atas
kardinalitas tersebut, namun menunjukkan bukti nyata tentang praktik bisnis dan
organisasi yang dimodelkan. Penjelasan ini diambil selama tahap analisis sistem
dan desain konseptual database dari proses desain database.

Mengambil
Pesanan
Pelanggan

Pegawai

Pelangga
n

Persediaa
n
Penjualan

Pegawai

Kas

Menerima
Kas

Pelangga
n

Sebagian diagram REA untuk siklus pendapatan

28

Pada gambar di atas dapat kita lihat bahwa melihat apa yang diungkapkan
mengenai siklus pendapatan pada sebuah perusahaan. Pertama, mengingat apabila
seluruh agen peristiwa adalah 1:N, yaitu ciri dari sebagian besar organisasi.
Seorang agen lah yang sering berpartisipasi dalam sebuah peristiwa. Misalnya,
sebuah perusahaan yang mengharapkan semakin lama seorang pegawai untuk
mengulangi dalam menjalankan sebuah tugas tertentu. Perusahaaan juga
mengharapkan para pelanggannya agar membuat pesanan dan pembelian
berulang, sama seperti waktu mereka biasanya menempatkan pesanan dengan
pemasok yang sama. Namun, untuk tujuan akuntabilitas, biasanya peristiwa
dikaitkan kepada seorang agen internal tertentu dan seorang agen eksternal
tertentu. Dengan begitu, kardianlitas maksimum pada sisi agen atas hubungan
agen peristiwa dalam gambar diatas selalu 1. Tetapi sebuah peristiwa maksimum
pada sisi agen hubungan tersebut akan banyak.
Pada gambar tersebut juga merefleksikan proses bisnis tipikal yang diikuti
oleh sebagian besar perusahaan dalam kardinalitas minimum yang diasosiasikan
dengan hubungan agen peristiwa. Hal ini juga menunjukkan bahwa dari setiap
peristiwa harus ditautkan ke seorang agen atau dalam penjualan harus
berhubungan dengan seorang pelanggan, dan pembayaran berasal dari seorang
pelanggan. Maka kardinalitas minimum 1 pada sisi agen hubungan tersebut.
Sebaliknya, gambar tersebut menunjukkan bahwa kardinalitas minimum pada sisi
peristiwa atas hubungan agen peristiwa yaitu 0.
Beberapa alasan kenapa salah seorang agen dalam segala peristiwa tidak
perlu berpartisipasi. Perusahaan tersebut mungkin mengharapkan dalam
menyimpan informasi tentang pelanggan potensial dan mengganti pemasok yang
ia belum menjalankan urusan apapun. Didalam database

terdapat informasi

mengenai para pegawai yang baru dipekerjakan sebelum hari pertama mereka
bekerja. Lalu, terdapat perbedaan fundamental pada sifat entitas agen dan entitas
peristiwa. Perusahaan mengharuskan untuk mengurus informasi tentang agen
tanpa batasan, tapi menyimpan informasi hanya tentang peristiwa yang telah
terjadi selama tahun fiscal terkini. Jadi, entitas agen selaras dengan berkas induk,
sementara entitas peristiwa selaras dengan berkas transaksi. Isi dari entitas

29

peristiwa biasanya diarsipkan pada akhir tahun fiscal, dan ditahun berikutnya
dimulai tanpa contoh atas peristiwa tersebut.
Dalam diagram REA untuk siklus pendapatan juga menggambarkan
hubungan M:N antara sumber daya persediaan dengan berbagai peristiwa yang
memengaruhinya. Hal ini merupakan situasi tipikal bagi organisasi. Sebagian
besar

organisasi

dapat

mencari

persediaan

tersebut

dengan

sebuah

pengidentifikasi seperti nomor suku cadang, nomor barang, atau nomor stockkeeping unit (SKU) dan tidak berusaha untuk mencari setiap contoh fisik atas
produk tersebut. Ketika terjadi sebuah penjualan, sistem tersebut dapat mencatat
nomor produk yang terjual. Jika akhir pekan, para pelanggan yang berbeda dapat
memesan satu lokomotif, maka sistem tersebut dapat menghubungkan nomor
produk kepada masing-masing peristiwa penjualan yang berbeda. Maka,
kardinalitas maksimum pada sisi peristiwa atas hubungan tersebut banyak.
Tetapi, bagaimana jika perusahaan menjual barang unik atau antic dan
hanya satu-satunya? Dalam hal seperti itu persediaan barang yang langka dapat
dijual satu waktu. Yang

menyebabkan kardinalitas maksimum pada sisi

persediaan-penjualan tersebut akan 1. Kardinalitas maksimum pada sisi


persediaan atas hubungan tersebut akan tetap banyak, tetapi karena sebagian besar
perusahaan akan senang bila menjual sebanyak mugnkin satu barang satu-satunya
yang berbeda yang diinginkan pelanggan untuk membelinya.
Kini, mempertimbangkan hubungan antara peristiwa menerima kas dan
sumber day kas. Gambar diatas menggambarkan sebagai hubungan 1:N, yang
merefleksikan prakti terbaik yang diikuti oleh sebagain besar organisasi dengan
pengendalian internal terbaik. Setiap tanda penerimaan kas dari pelanggan
disetorkan dalam satu rekenign kas, biasanya akun pengecekan umum organisasi
tersebut. Lalu bendahara mentransfer uang dari rekening itu ke rekening kas
lainnya seperti penggajian, pengecekan, dan investasi. Setiap pembayaran
pelanggan harus disetorkan kedalam rekening, karena kardinalitas minimum
adalah 1 pada sisi sumber daya atas hubungan tersebut begitu juga sebaliknya.
K. Keunikan Diagram REA

30

Dalam pembahasan sebelumnya mengindikasikan bahwa setiap organisasi


memiliki diagram REA yang unik. Karena praktik bisnis berbeda antar perusahaan
begitu juga dengan kardinalitas hubungan. Kenyataannya, sebuah diagram REA
untuk sebuah organisasi harus berubah untuk merefleksikan perubahan pada
praktik bisnis. Seperti sebuah perusahaan yang memutuskan untuk memulai
membuat sebagian pengiriman untuk mengisi pesanan pelanggan. Lalu pada
gambar diagram REA untuk siklus pendapatan harus dirubah untuk menunjukkan
hubungan antar peristiwa Mengambil Pesanan Pelanggan dan Penjualan sebagai
1:N, bukan hubungan 1:1 yang digambarkan seperti diatas. Sama dengan jika
sebuah perusahaan tersebut juga memutuskan untuk mengadopsi sebuah kebijakan
penggabungan sebagai pesanan dari satu pelanggan dalam pengiriman besar,
kemudian gambar tersebut harus digabungkan untuk menggambarkan hubungan
antara dua peristiwa sebagai M:N. Kadang perbedaan dalam praktik bisnis dapat
menghasilkan entitas yang dimodelkan berbeda.
Meskipun, perkembangan diagram REA bagi siklus pendapatan sebuah
perusahaan tersebut mungkin nampaknya secara relative langsung dan intuitif,
pemodelan data yang biasanya adalah sebuah proses yang berulang serta rumit.
Maka, sering para pemodel mengembangkan sebuah diagram REA awal yang
mengembangkan pemahaman mereka atas proses bisnis organisasi, tetapi untuk
mempelajari kapan ditunjukkannya kepada para pengguna yang dikehendaki yang
mereka telah mengabaikan dimensi kunci atau salah pemahaman dalam beberapa
prosedur peroperasian. Jadi, tidak mudah untuk menghapus dan menggambarkan
ulang bagian dari diagram REA berulang kali sebelum menghasilkan sebuah
model yang dapat diterima.
Salah satu sumber umum dari salah paham adalah penggunaan
terminology yang berbeda oleh berbagai subset kelompok pengguna yang
ditunjuk. Dalam proses pemodelan data menjadi penting untuk melibatkan
pengguna sistem tersebuts sehingga terminology tersebut konsisten.

31

MENGIMPLEMENTASIKAN MODEL REA DALAM


DATABASE RELASIONAL
Pada pembahasan kali ini kami akan membahas bagaimana cara
mengimplementasikan model diagram REA ke dalam sebuah siklus database.
Pada pembahasan sebelumnya kami telah memperkenalkan permodelan data REA
dan menjelaskan bagaimana cara mengembangkan diagram REA untuk sebuah
siklus bisnis individual. Pada pembahasan ini kami akan lebih berfokus kepada
database relasional karena database relasional pada umumnya dikenal oleh
sebagian besar mahasiswa bisnis dan database relasional digunakan untuk
mendukung sistem pemrosesan transaksi yang terjadi pada perusahaan. Tetapi,
permodelan data REA tidak hanya dapat digunakan untuk mendesain database
relasional, melainkan juga dapat digunakan untuk mendesain database berorientasi
objek.
Pada pembahasan ini kami akan menjelaskan bagaimana berbagai diagram
REA, yang masing-masing dibuat secara terpisah dalam proses pemodelannya,
diintegrasikan menjadi satu model tunggal yang berskala enterprise. Bagian ini
selanjutnya menjelaskan bagaimana model enterprise diimplementasikan kedalam
database relasional dan view dari pengguna yang sudah dibuat.

A.

MENGINTEGRASIKAN DIAGRAM REA ANTARSIKLUS


Gambar di bawah ini merupakan diagram REA siklus pendapatan,

pengeluaran dan penggajian yang ditampilkan secara berturut turut. Dalam


mengintegrasikan diagram diagram yang terpisah tersebt untuk menyediakan
model keseluruhan perusahaan komprahensif tunggal perlu adanya pemahaman
tentang kardinalitas pada setiap diagram yang terpisah untuk mengungkapkan
kebijakan dan aktivitas organisasi. Seperti yang telah kami bahas sebelumnya
kardinalitas menunjukkan bagaimana perumpamaan dalam satu entitas dapat
dihubungkan ke perumpamaan tertentu dalam entitas lainnya.

32

Menurut James A Hall siklus pendapatan (2010) adalah pertukaran


langsung dari produk akhir dan jasa menjadi kas dalam satu kali transaksi antara
penjual dan pembeli.1
Sedangkan menurut Romney dan Steinbart

dan Steinbart siklus

pendapatan adalah rangkaian aktivitas bisnis yang berulang ulang dan proses
informasi yang terkait dengan menghasilkan barang dan jasa kepada konsumen
dan mengumpulkan uang pembayaran atas penjualan tersebut.2
Menurut kami siklus pendapatan adalah kegiatan atau aktivitas bisnis yang
secara berulang ulang terus berlangsung dan proses informasi yang
menyediakan produk dan jasa kepada pelanggan dan menagih kas sebagai
pembayaran dari penjualan produk dan jasa tersebut.
Menurut Romney dan Steinbart terdapat empat aktivitas bisnis dasar
dalam siklus pendapatan. Tahap pertama adalah sales order entry (penerimaan
pesanan) para pelanggan. Departemen bagian pesanan penjualan, yang
bertanggung jawab pada wakil direktur utama bagian pemasaran,
melakukan proses entri pesanan penjualan. Entri pesanan penjualan
mencakup tiga tahap yaitu mengambil pesanan dari pelanggan,
memeriksa

dan

menyetujui

kredit

pelanggan,

serta

memeriksa

ketersediaan persediaan dan juga menjawab permintaan pelanggan.


Tahap kedua adalah Shipping (pengiriman) memenuhi pesanan pelanggan dan
mengirimkan barang dagangan yang diinginkan tersebut. Proses ini terdiri dari
dua tahap yaitu mengambil serta

mengepak pesanan dan mengirim pesanan

tersebut. Tahap ketiga yaitu Billing (penagihan) melakukan penagihan dari


konsumen. Tahap terakhir yaitu Cash collections (penagihan kas) kasir memegang
bukti pembayaran konsumen dan menyimpan kas tersebut di bank yang
selanjutnya akan dilaporkan pada treasure.

1 James, A. Hall. Sistem Informasi Akuntansi. Edisi Ketujuh, Jakarta: Salemba Empat, 2010.
2 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

33

Gambar 18-1 Siklus Pendapatan (James A. Hall)3

Menurut Romney dan Steinbart dan Steinbart siklus pengeluaran adalah


seperangkat aktivitas bisnis yang berulang dan operasi pemrosesan data terkait
yang berhubungan dengan pembelian dan pembayaran untuk barang dan jasa.
Terdapat tiga aktivitas bisnis utama dalam expenditure cycle: Aktivitas pertama
dalam siklus pengeluaran adalah memesan persediaan atau perlengkapan.
Keputusan penting yang dibuat dalam langkah ini adalah mengidentifikasi apa,
kapan, dan berapa banyak yang dibeli, dan dari pemasok mana akan dibeli.
Dokumen yang dibuat dalam proses pemesanan barang adalah pesanan
pembeliaan (purchase order)2.
Aktivitas kedua dalam siklus pengeluaran adalah penerimaan dan penyimpanan
barang yang dipesan. Bagian penerimaan bertanggung jawab untuk mengecek dan
menerima kiriman dari para pemasok. Dokumen yang dibuat dalam proses

3 James, A. Hall. Sistem Informasi Akuntansi. Edisi Ketujuh, Jakarta: Salemba Empat, 2010.
2 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

34

penerimaan barang adalah laporan penerimaan barang adalah laporan penerimaan


(receiving report).
Aktivitas ketiga dalam siklus pengeluaran adalah menyetujui faktur
penjualan dari vendor untuk pembayaran. Bagian utang usaha menyetujui faktur
penjualan untuk dibayar dan kasir bertanggung jawab untuk melakukan
pembayaran.
Gambar 18-2 Siklus Pengeluaran (James A. Hall)

Pada bab ini kita akan fokus kepada siklus penggajian. Atas dasar
penggunaan waktu dan keterampilan setiap karyawan yang berada di sebuah
perusahaan sebagai gantinya setiap karyawan menerima slip gaji. Oleh karena itu,
jam kerja setiap karyawan harus dicatat dimulai dari karyawan bekerja hingga
karyawan tersebut tidak bekerja lagi diperusahaan tersebut. Setiap pekerjaan
karyawan tertentu harus dikaitkan dengan supervisornya, tapi, setiap karyawan
atau supervisor mungkin dikaitkan kepada Event yang berbeda. Slip gaji yang

35

dikeluarkan kepada seorang karyawan tertentu dan ditangadatangi oleh seorang


kasir tertentu, tetapi dengan banyaknya Event Mengeluarkan Kas yang berbeda
dari waktu ke waktu memungkinkan setiap karyawan terhubung dengan kasir
tersebut. Oleh karena itu, gambar 18-3 menggambarkan hubungan antara Agent
dan Event sebagai 1:N. Karena setiap Event harus dihubungkan ke seorang
karyawan tertentu, kardinalitas minimum pada bagian Agent hubungan tersebut
selalu 1. Dalam rangka untuk mangakomodasikan penyimpanan data terkait
dengan karyawan baru sebelum karyawan tersebut memulai pekerjaannya dan
karena entitas Event kosong pada awal setiap tahun fiskal baru, maka kardinalitas
minimum pada sisi Event hubungan tersebut selalu 0.
Gambar 18-3 Siklus Penggajian (James A. Hall)1

Gambar 18-3 menggambarkan model data untuk prosedur penggajian.


Model ini terdiri dari dua economic Events. Get Time/Mendapatkan Waktu dan
Disburse Cash/Mengeluarkan Kas. Event Get Time/Mendapatkan Waktu adalah
bagian sisi menerima dari pertukaran/transaksi ekonomi. Ini melibatkan pekerja
1 James, A. Hall. Sistem Informasi Akuntansi. Edisi Ketujuh, Jakarta: Salemba Empat, 2010.

36

(Agentt internal) yang memberikan waktunya, yang disajikan oleh resource Jasa
Karyawan. Supervisor (Agentt eksternal) mengasumsikan pengendalian resource.
Berbeda

dengan

resource

ekonomi

yang

tangible

seperti

uang

dan

inventori/persediaan, waktu tidak memiliki element aliran barang dan tidak bisa
disimpan. Event Get Time/Mendapatkan Waktu menambah jumlah waktu, dan
berbagai Event kinerja pekerjaan secara bersamaan mengurangi jumlah waktu.
Jasa karyawan dilacak secara langsung ke barang yang dihasilkan atau jasa yang
diberikan ke klien (seperti, konsultasi, jasa hukum, atau akuntansi publik), adalah
masuk akal untuk memodelkan resource semacam ini. Karena jika tidak melacak
waktu karyawan untuk aktivitas-aktivitas seperti pelanggan individu yang dilayani
atau pesanan-pesanan yang ditangani, memindahkan entitas ini ke tabel database
fisik tidak ada gunanya. Garis putus putus pada gambar 18-3 menjelaskan
entitas Resource Waktu Karyawan hampir tidak pernah diimplementasikan dalam
database yang sesungguhnya di karenakan dua Event yaitu Mendapatkan Waktu
dan Waktu yang Digunakan menangkap keseluruhan informasi mengenai waktu
Karyawan

yang

sangat

mudah

untuk

dikumpulkan

dan

diawasi.

Event Get Time/Mendapatkan Waktu menangkap instance/objek karyawan


yang memberikan waktu hariannya melalui mekanisme pencatatan waktu seperti
time-clock elektronik. Bagi karawayan yang bergaji tetap, proses pencatatan
waktu mungkin bisa secara sederhana melibatkan alur waktu. Kardinalitas nol
(zero) pada asosiasi antara entitas Get Time/Mendapatkan Waktu dan entitas
Pekerja dan entitas Supervisor mencerminkan kemungkinan bahwa beberapa
karyawan mungkin tidak mengontribusikan waktunya selama periode tersebut. Ini
terjadi contohnya adalah karyawan baru atau karyawan yang cuti karena sakit.
Event Disburse Cash/Mengeluarkan Kas adalah bagian sisi memberi
dalam pertukaran/transaksi ekonomi. Aktivitas ini meliputi membagikan
uang/cash ke karyawan (saat ini menjadi Agentt eksternal) atas jasa yang
diberikannya. Karyawan bagian payroll (Agentt internal) terlibat dalam Event ini,
yang

mengurangi

resource

uang/cash.

Aosiasi

antara

Event

Disburse

Cash/Mengeluarkan Kas dan Event Get Time/Mendapatkan Waktu mencerminkan


selisih waktu antara waktu yang diberikan karyawan dan pembayaran yang

37

diterimanya, karena mereka pada umumnya tidak dibayar harian. Pada umumnya,
karyawan bekerja selama seminggu, dua minggu, atau bahkan sebulan sebelum
dibayar. Karena itu, kardinalitas 1,M pada sisi Get Time/Mendapatkan Waktu dari
asosiasi tersebut menyiratkan bahwa setidaknya satu atau mungkin banyak
instance Get Time/Mendapatkan Waktu akan terjadi untuk setiap instance
Disburse Cash/Mengeluarkan Kas. Kardinalitas 0,1 pada sisi Disburse
Cash/Mengeluarkan Kas dari asosiasi tersebut menyiratkan bahwa pada waktu
tertentu (pertengahan minggu), instance Get Time/MendapatkanWaktu akan ada
yang belum dibayar. Namun, setiap instance Get Time/Mendapatkan Waktu hanya
dibayar sekali.

B.

ATURAN UNTUK MENGOMBINASIKAN DIAGRAM REA


Seperti yang kita lihat pada gambar 18-1, 18-2 dan 18-3, masing masing

gambar tersebut mempunyai akun yang sama, seperti Resource persediaan muncul
pada gambar 18-1 dan gambar 18-2. Event mengeluarkan kas muncul pada ketiga
diagram. Dari akun akun yang sama tersebut merupakan dasar untuk
mengombinasikan diagram REA yang menggambarkan siklus bisnis individual ke
dalam sebuah model REA tunggal, model komprehensif, dan model keseluruhan
perusahaan.
Fitur sistematik REA diturunkan dari komponen-komponen dalam
transaksi ekonomi. Dasar pemikiran dibalik transaksi ekonomi adalah bahwa dua
Agentts memberikan resource kepada yang lain dan dengan cara menukar
resource yang lain sebagai gantinya. Dalam realitanya, pertukaran tersebut adalah
sepasang economic Events, yang disajikan melalui asosiasi dualitas. Dengan kata
lain, setiap satu economic Event selalu dicerminkan oleh satu economic Event
yang terkait dalam arah yang berlawanan. Dasar model REA untuk
menggambarkan koneksi diantara dual Events tersebut: give to get (memberi
untuk menerima). Hubungan dualitas ekonomi menjelaskan sebuah Resource
diperoleh

atau

dilepas.

Walaupun

demikian

hubungan

tersebut

hanya

menyediakan satu bagian cerita saja mengenai tiap Resource. Seperti Gambar 18-

38

1 menunjukkan bahwa persediaan dikurangi (Event penjualan) dalam pertukaran


kas (Event Menerima Kas). Tetapi, gambar 18-1 tidak memunjukkan cara
persediaan tersebut diperoleh, dan juga tidak menunjukkan cara perusahaan
menggunakan kas yang mereka peroleh dari para pelanggan. Sebaliknya, Gambar
18-2 menunjukkan cara perusahaan mendapatkan persediaan (Event Menerima
Persediaan) dengan menyerahkan kas (Event Mengeluarkan Kas). Tetapi, gambar
18-2 tidak menunjukkan bagaimana cara perusahaan menggunakan persediaan
yang didapat tersebut atau cara perusahaan memperoleh kas yang digunakan
untuk membayar para pemasok.
Oleh karena itu, diagram REA untuk siklus individual hanya menyediakan
informasi parsial mengenai Resource yang dikendalikan oleh sebua organisasi.
Gambar 18-4 akan menunjukkan bagaimana tiap Resource diperoleh dan
bagaimana Resource tersebut digunakan, dengan cara menggambar ulang sebuah
diagram REA untuk menempatkan Resource umum di antara Event yang
mempengaruhinya. Dengan melakukannya, maka merefleksikan dualitas penting
lainnya yang harus digambarkan dalam sebuah model REA lengkap atas segala
perusahaan. Setiap Resource harus dihubungkan paling tidak ke satu Event yang
meningkatkan daya tersebut dan paling tidak ke satu Event yang menurunkannya.

39

Gambar 18-4 Diagram REA Trintegrasi (James a Hall)1

1 James, A. Hall. Sistem Informasi Akuntansi. Edisi Ketujuh, Jakarta: Salemba Empat, 2010.

40

Menggabungkan Entitas Event Yang Berulang


Untuk siklus bisnis individual, diagram REA mungkin mengandung
beberapa Event yang muncul pada diagram REA siklus lain. Seperti Gambar 18-2
dan gambar 18-3, kedua gambar tersebut mengantung entitas Event Mengeluarkan
Kas. Seperti pada kasus Resource, penggabungan dari berbagai Event yang sama
dapat meningkatkan hasil diagram REA komprehensif yang dapat lebih mudah
dipahami.

Oleh

Mengeluarkan

karenanya,

Kas

gambar

dihubungkan

ke

18-4
Event

menunjukkan

bahwa

Menerima

Persediaan

Event
dan

Mendapatkan Waktu.
Namun, jika diteliti lebih lanjut pada gambar 18-4 dapat mengungkapkan
perbedaan penting di antara penggabungan Event yang berulang dan
penggabungan Resource yang berulang. Penggabungan Event yang berulang
dapat mengubah kardinalitas minimum yang diasosiasikan dengan Event lain serta
berhubungan dengan Event yang digabungkan tersebut, tetapi penggabungan
Resource yang berulang tidak mempengaruhi kardinalitas. Oleh karena itu,
kardinalitas antara Event Mengeluarkan Kas dan Event lain yang terkait berbeda
pada Gambar 18-4 jika dibandingkan dengan Gambar 18-2 dan Gambar 18-3,
sebaliknya pada Gambar 18-4, kardinalitas antara Resource Persediaan dan pada
masing masing dari empat Event terkait adalah sama seperti yang digambarkan
pada Gambar 18-1 dan Gambar 18-2.
Perbedaan ini berada pada semantik yang mendasari sifat hubungan antara
entitas yang digabungkan dan entitas lainnya. Sebuah entias Resource biasanya
dikaitkan ke berbagai Event. Contohnya, barang persediaan tidak hanya
dihubungkan dengan Event Menerima Persediaan, yang diperoleh dari pemasok,
tetapi juga dihubungkan dengan Event Penjualan, ketika persediaan tersebut dijual
kepada pelanggan. Dengan kata lain, entitas Resource dihubungkan ke entitas
Event pada satu siklus bisnis dan dihubungkan ke entitas Event siklus lainnya.
Oleh karenanya, tautan tersebut mungkin, tidak satupun kardinalitas pada diagram
REA individual perlu diubah.

41

Hal ini berbeda ketika dalam penggabungan sebuah Event di antara siklus
bisnis. Event yang muncul pada kedua diagram REA siklus bisnis individual
mungkin dihubungkan ke salah satu Event yang merupakan bagian dari siklus
lain, terapi tidak dapat dihubungkan ke kedua Event tersebut. Seperti, pada
Gambar 18-4, Event Mengeluarkan Kas seperti cek atau transaksi EFT tertentu,
dapat diasosiasikan dengan penerimaan persediaan sebelumnya daari seorang
pemasok atau dengan Mendapatkan Waktu oleh seorang Karyawan, tetapi cek
yang sama tidak dapat digunakan membayar pemasok untuk penerimaan
persediaan maupun untuk membayar seorang Karyawan atas upah bekerja harian
maupun mingguan. Hal ini mengakibatkan, kardinalitas minimum yang
diasosiasikan dengan Event lain harus 0 pada diagram REA terintegrasi, dengan
mengabaikan kardinalitasnya pada tiap diagram REA siklus transaksi individual.
Untuk memahaminya, ingat bahwa minimum 1 berarti bahwa tiap contoh dari
entitas tersebut harus diasosiasikan dengan setidaknya satu contoh entitas lainnya.
Dalam hal pengeluaran kas (pencairan kas) pada Gambar 18-4, misalnya,
penggajian minimum 1 untuk Event Mendapatkan Waktu akan berarti bahwa
setiap Mengeluarkan Kas harus dihubungkan ke sebuah Event Mendapatkan
Waktu yang secara jelas tidak benar, karena mungkin melakukan pengeluaran
kas untuk membayar seorang pemasok. Untuk alasan yang sama, kardinalitas
minimum dari Event Mengeluarkan Kas ke Event Menerima Persediaan juga
harus 0.
Penggabungan dua siklus transaksi pada sebuah Event umum mungkin
juga mempengaruhi kardinalitas minimum antara Event yang digabungkan dan
Agent yang berpartisipasi dalam Event tersebut. Misalnya, seperti kardinalitas
pada Gambat 18-2, kardinalitas minimum antara Event Mengeluarkan Kas dan
entitas Pemasok adalah 1, tetapi pada Gambar 18-4 kardinalitas minimum antara
Event Mengeluarkan Kas dan entitas Pemasok sekarang adalah 0. Hal ini
dikarenakan bahwa sebuah cek (pengeluaran kas) hanya dapat dituliskan kepada
salah satunya misalnya kepada pemasok sebagai pembayaran atas persediaan atau
hanya kepada Karyawan sebagai pembayaran atas keahlian yang diberikannya
kepada perusahaan. Hal ini yang menyebabkan kardinalitas minimum antara
Event Mengeluarkan Kas dan Agent Karyawan (terbayar) juga 0. Oleh karenanya,

42

setiap Event yang digabungkan yang melibatkan Agent yang berbeda dalam setiap
siklus bisnis individual yang digabungkan, kardinalitas minimum antara Event
tersebut dan Agent Agent itu berubah dari yang biasanya yaitu 1 menjadi 0,
karena Event tersebut mungkin dihubungkan ke salah satu dari dua jenis Agent
tersebut, tetapi tidak kepada keduanya.

Menvalidasi Ketepatan Diagram REA Terintegrasi


Enam aturan yang harus dipenuhi untuk mengintegrasi Diagram REA
(Romney dan Steinbart ):1
1.
2.

Setiap Event harus ditautkan setidaknya ke satu Resource.


Setiap Event harus ditautkan ke dua Agent yang berpartisipasi dalam

3.

Event tersebut.
Setiap Event harus melibatkan Resource yang harus ditautkan ke sebuah
Event yang melibatkan perolehan Resource. (ini merefleksikan dualitas

4.

ekonomi yang mendasari pertukaran ekonomi give to get).


Setiap Resource harus ditautkan setidaknya ke satu Event yang menaikkan
Resource tersebut dan setidaknya ke satu Event yang menurunkan

5.

Resource tersebut.
Event A dapat ditautkan ke lebih dari satu Event lainnya, tetapi tidak dapat
ditautkan secara bersamaan ke seluruh Event lain tersebut, kemudian
diagram REA harus menunjukkan bahwa Event A ditautkan ke minimum 0

6.

atas masing masing dari Event lain tersebut.


Sebuah Event dapat ditautkan ke salah satu dari kelompok Agent, tetapi
tidak dapat ditautkan secara bersamaan ke seluruh Agent, kemudian
diagram REA harus menunjukkan bahwa Event tersebut ditautkan ke
minimum 0 atas masing masing dari Agent tersebut.

C.

MENGIMPLEMENTASIKAN DIAGRAM REA DALAM


DATABASE RELASIONAL

1 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

43

Sebuah diagram yang telah dikembangkan, dapat digunakan untuk


mendesain sebuah database relasional yang terstruktur dengan baik. Menurut
Romney dan Steinbart

Terdapat tiga langkah untuk mengimplementasikan

diagram REA pada database relasional yaitu:1


1.

Buatlah sebuah table untuk masing masing entitas yang berbeda dalam
diagram tersebut dan untuk setiap hubungan banyak ke banyak (many to

2.
3.

many).
Tentukan atribut tabel yang sesuai.
Gunakan kunci asing untuk mengimplementasikan hubungan satu ke
satu (one to one) dan satu ke banyak (one to many).

Menurut James A. Hall proses mengintegrasi diagram REA juga meliputi tiga
langkah dasar, yaitu :2
1.
2.
3.

Menyatukan model model individual


Mendefinisikan primary key, foriegn key, dan atribut atribut
Membuat database fisik dan membuat pandangan pengguna
Menurut

kami

isi

penjelasan

dari

langkah

langkah

dalam

mengintegrasikan diagram REA menurut Romney dan Steinbart dan menurut


James A. Hall hampir sama, walaupun langkah langkah dalam mengintegrasikan
diagram REA tersebut berbeda. Seperti pada Romney dan Steinbart menjelaskan
bahwa pada tahap 1 Romney dan Steinbart menjelaskan cara membuat tabel
untuk setiap entitas yang berbeda dan tabel hubungan M:N. Sedangkan James A.
Hall menjelaskan tabel tersebut pada langkah 2 yaitu ketika mendefinisikan
primary kery, foriegn key, dan atribut atribut dan langkah 1 menurut James A.
Hall yaitu menyatukan model model individual.
Berikut kami akan lebih menjelaskan langkah langkah dasar dalam
mengintegrasikan diagram REA menurut Romney dan Steinbart dan selanjutnya

1 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

2 James, A. Hall. Sistem Informasi Akuntansi. Edisi Ketujuh, Jakarta: Salemba Empat, 2010.

44

kami juga akan menjelaskan langkah langkah dasar dalam mengintegrasikan


diagram REA menurut James A. Hall

Menurut Romney dan Steinbart1


Langkah 1: Buat Tabel Untuk Setiap Entitas Yang Berbeda Dan Tabel
Hubungan M:N
Sebuah database relasional yang didesain dengan tepat memiliki sebuah
tabel untuk tiap tiap entitas yang berbeda dan untuk setiap hubungan banyak
ke banyak (many to many) pada sebuah diagram REA. Gambar 18-4
memiliki 13 entitas yang berbeda, tetapi satu entitas yaitu Waktu Karyawan, tidak
akan diimplementasikan dalam database tersebut karena Waktu Karyawan hanya
memiliki beberapa atribut yang relevan, dan Waktu berbeda dari persediaan kas,
Resource berwujud lainnya, dan Resource tak berwujud seperti rahasia dagang
atau bentuk lain dari kekayaan intelektual yang tidak dapat disimpan. Sisanya, dua
belas entitas yang berbeda yang diberada pada Gambar 18-4 perlu
diimplementasikan sebagai tabel database relasional. Tujuh tabel akan
merepresentasikan entitas Event yaitu: Memesan Persediaan, Menerima
Persediaan, Mengeluarkan Kas, Mendapatkan Waktu, Mengambil Pesanan
Pelanggan, Penjualan, Dan Menerima Kas. Ada dua tabel untuk entitas Resource
yaitu Persediaan dan Kas. Tiga tabel dibutuhkan untuk mengimplementasikan
entitas Agent yang berbeda yaitu Karyawan, Pelanggan, dan Pemasok (agar
mudah dibaca supervisor dilabelkan secara terpisah, tetapi supervisor juga
merupakan bagian dari Karyawan).
Pada gambar 18-4 juga menggambarkan lima hubungan M:N. Tiga dari
siklus pendapatan yaitu Mengambil Pesanan Pelanggan Persediaan, Penjualan
Persediaan, Dan Penjualan Menerima Kas. Sedangkan Dua lainnya dari siklus
pengeluaran yaitu Persediaan Memesan Persediaan Dan Persediaan Menerima
Persediaan. Agar akurat mengimplementasikan Gambar 18-4 dalam sebuah
1 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

45

database relasional, 17 tabel pada database yang disetai dengan kunci utama
(primary key), kunci asing (foreign key), dan atribut lain (Atributtes) harus
dicantumkan dalam Tabel 18-1. Penentuan primary key dan atribut berasal dari
pemahaman terhadap tujuan tabel yang dihasilkan dari analisa rinci dari
kebutuhan pengguna. Perancang database harus memilih primary key yang secara
logik dan unik mendefinisikan atribut-atribut nonkey pada tabel. Dalam beberapa
hal, hal ini dicapai dengan kode sekuensial sederhana seperti Nomor Invoice,
Nomor Check, atau Nomor Purchase Order. Pada beberapa situasi yang lain, block
codes,

group

codes,

alphabetic

codes,

dan

mnemonic

codes.

Beberapa jenis atribut tabel adalah umum bagi semua organisasi dan bisa
diturunkan dari pengertian umum. Beberapa jenis atribut lain adalah bersifat unik
terhadap aplikasi tertentu dan bisa diturunkan dari analisa rinci dan menyeluruh
terhadap pandangan pengguna. Namun, setiap atribut yang diberikan ke suatu
tabel harus muncul baik secara langsung atau tidak langsung (nilai yang sudah
diperhitungkan) pada satu atau lebih pandangan pengguna. Bila ada data yang
disimpan pada suatu tabel tidak digunakan dalam suatu dokumen, report, atau
penghitungan yang digunakan untuk laporan, maka tidak ada gunanya dan tidak
perlu menjadi bagian dari database.
Penempatan primary key dan atribut-atribut pada tabel-tabel relasional
harus selalu mengikuti aturan normalisasi. Tabel-tabel yang dinormalisasi dengan
tidak baik akan mengalami gejala-gejala operasional buruk. Nama tabel yang
terdapat pada tabel 18-1 berkaitan dengan nama entitas pada diagram REA atau
pada tabel hubungan M:N, yang merupakan rangkaian yang ditulis dengan tanda
hubung atas entitas entitas yang dilibatkan dalam hubungan tersebut. Hal ini
mempermudah untuk menverifikasi bahwa semua tabel yang dibutuhkan telah
dibuat serta mempermudah untuk menggunakan diagram REA sebagai panduan
ketika menjalankan query database.
Tabel 18-1 Nama Tabel Dan Penempatan Atribut Untuk Figur 18-4
(Romney dan Steinbart )1
Table

Kunci

Utama Kunci

46

Atribut
Asing Atribut Lain

Memesan

(Primary Key)
(Foreign Key)
(Atributtes)
Nomor pesanan Nomor pemasok, Tanggal,

Waktu,

Persediaan
Menerima

pembelian
nomor Karyawan
alasan
Nomor laporan Nomor Pemasok, Tanggal,

waktu,

Persediaan

penerimaan

nomor

nomor Karyawan, keterangan,


nomor

pesanan faktur vendor

pembelian, nomor
cek
Mengeluarkan

Nomor cek

Kas

Nomor

pemasok, Jumlah,

nomor

Karyawan tanggal

(terbayar),

deskripsi,

nomor

Karyawan
(penandatangan),
Mengambil

nomor rekening
Nomor pesanan Nomor pelanggan, Tanggal,

Pesanan

penjualan

nomor Karyawan

Nomor faktur

Nomor pelanggan, Tanggal,

waktu,

keterangan khusus

Pelanggan
Penjualan

waktu,

nomor Karyawan, faktu dikirim (Y/T)


nomor
Menerima Kas

pesanan

penjualan
Nomor pelanggan, Tanggal,

Nomor

waktu,

pengiriman uang nomor Karyawan, metode pembayaran


nomor rekening
Mendapatkan

Nomor

Waktu

waktu

kartu Nomor Karyawan, Tanggal, jam masuk,


supervisor, nomor jam keluar
cek gaji

Persediaan

Nomor produk

Deskripsi,

harga

daftar, biaya standar,


kuantitas

awal

di

1 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

47

tangan,

kuantitas

keterpersediaan
awal,

kuantitas

pemesanan
angka
Kas

ualng
Saldo

Nomor rekening

ulang,

pemesanan
awal,

jenis

rekening
Karyawan

Nomor

Nama,

tanggal

Karyawan

dipekerjakan,
tanggal lahir, tingkat

Pelanggan

Pemasok

Nomor

bayaran, jabatan
Nama, alamat*, saldo

pelanggan

rekening awal, batas

Nomor pemasok

kredit
Nama, alamat*, saldo
rekening

Memesan
Persediaan

Persediaan

peringkat kinerja
Kuantitas
yang

Nomor pesanan
pembelian,

Persediaan
Menerima

awal,

dipesan, biaya unit

nomor produk
Nomor laporan

aktual
Kuantitas

- penerima,

diterima, kondisi

Persediaan
Mengambil

nomor produk
Nomor pesanan

Kuantitas

Pesanan

penjualan,

dipesan

Pelanggan

nomor produk

Persediaan
Penjualan

- Nomor

Persediaan
Penjualan

faktur,

Kuantitas

nomor produk

dijual,

yang

yang

harga

jual

nomor

yangditerapkan

ke

pengiriman uang

faktur

Nomor

Menerima Kas

yang

aktual
Jumlah

faktur,

48

Langkah 2: Menentukan Atribut Untuk Setiap Tabel


Langkah selanjutanya adalah menentukan atribut mana saja yang akan
ditampilkan dalam tiap tabel. Untuk mengidentifikasi fakta yang perlu disertakan
dalam database tersebut, perancang database perlu mewawancarai para pengguna
dan manajemen perusahaan. Untuk membantu menentukan tabel yang digunakan
untuk menuliskan fakta fakta tersebut perancang database harus menggunakan
diagram REA, hal itu bergantung pada apakah fakta tersebut merupakan kunci
utama atau hanya atribut deskriptif.
Mengidentifikasi Kunci Utama
Setiap tabel dalam sebuah database relasional memiliki sebuah kunci
utama,

terdiri

atas

atribut

atau

kombinasi

atribut

yang

secara

unik

mengidentifikasi tiap baris dalam tabel tersebut. Perusahaan sering membuat


pengidentifikasian numerik terhadap Resource, Event, dan Agent tertentu.
Pengidentifikasi numerik ini merupakan kandidat yang baik bagi kunci utama.
Seperti tabel 18-1 yang menunjukkan nomor faktur sebagai kunci utama untuk
tabel penjualan dan nomor pelanggan sebagai kunci utama untuk tabel pelanggan.
Kunci utama sebuah tabel yang merepresentasikan sebuah entitas
merupakan atribut tunggal. Tetapi, kunci utama untuk tabel hubungan M:N selalu
terdiri atas dua atribut yang merepresentasikan kunci utama setiap entitas yang
ditautkan dalam hubungan tersebut. Misalnya, kunci utama tabel Penjualan
Persediaan terdiri atas nomor faktur (kunci utama entitas penjualan) dan nomor
produk (kunci utama entitas persediaan). Kunci utama berbagai atribut tersebut
disebut dengan kunci bersambung (concatenated keys).
Menentukan Atribut Lain Ke Tabel Yang Sesuai
Selain kunci utama, atribut tambahan juga ikut disertakan dalam setiap
tabel untuk memenuhi ketentuan pemrosesan transaksi dan kebutuhan informasi
manajemen. Atribut lain yang disertakan dalam sebuah tabel database relasional
harus berupa fakta mengenai objek yang direpresentasikan oleh kunci utama atau
kunci asing. Oleh karenanya informasi mengenai para pelanggan, seperti nama

49

dan alamat mereka, terletak pada tabel Pelanggan karena atribut tersebut
menjelaskan objek yang direpresentasikan oleh kunci utama (nomor pelanggan)
dan tabel Pelanggan, atribut tersebut bukan milik tabel Penjualan karena atribut
tersebut tidak menjelaskan beberapa properti objek yang direpresentasikan oleh
kunci utama tabel tersebut (nomor faktur).
Tabel 18-1 telah menunjukkan beberapa atribut yang telah ditentukan pada
berbagai tabel yang telah dibuat untuk mengimplementasikan Gambar 18-4 dalam
sebuah database relasional. Atribut atribut tersebut seperti tanggal setiap
penjualan dan jumlah yang dibayarkan oleh seorang pelanggan, diperlukan untuk
pemrosesan transaksi yang tepat serta lengkap, pembuatan laporan keuangan, dan
laporan manajerial. Atribut lain disimpan karena mereka memfasilitasi manajemen
yang efektif atas Resource, Event, dan Agent organisasi. Misalnya, menggunakan
data mengenai tanggal tiap transaksi penjualan terjadi untuk mendesain jadwal
kerja staf.
Pada tabel 18-1 juga ikut menyertakan atribut atribut lain dalam
beberapa tabel hubungan M:N. Untuk memahami mengapa atribut atribut
tersebut disimpan dalam tabel tertentu kita perlu untuk memeriksa kembali
penempatan atribut atribut tersebut dalam beberapa tabel M:N. Seperti pada
tabel Penjualan Menerima Kas, perusahaan memperbolehkan pelanggannya
tidak hanya membeli secara tunai tetapi pelanggan juga bisa melakukan
pembelian secara kredit dan melakukan pembayaran cicilan dengan sisa saldo
mereka. Oleh karena itu, pembayaran pelanggan mungkin perlu diterapkan ke
beberapa faktur yang berbeda (transaksi penjualan). Oleh karena itu, atribut
jumlah yang dipakai tidak dapat ditempatkan dalam tabel Menerima Kas karena
ia dapat memiliki lebih dari satu nilai (salah satunya untuk setiap faktur yang
dibayarkan) dengan demikian akan melanggar ketentuan dasar database relasional
jika setiap atribut dalam setiap baris bernilai tunggal ( yakni ketentuan bahwa
setiap tabel merupakan sebuah flat file). Selain itu juga atribut jumlah yang
dipakai tidak dapat ditempatkan dalam tabel Penjualan karena kemungkinan
pembayaran cicilan juga akan mengakibatkan atribut dapat memiliki nilai multipel
(yakni suatu entri untuk setiap pembayaran cicilan terkait dengan penjualan

50

tertentu). Oleh karena itu, analisis berdasarkan proses bisnis mengindikasikan


bahwa atribut jumlah yang diterapkan merupakan fakta mengenai pembayaran
pelanggan tertentu (pengiriman kas) dan transaksi penjualan tertentu sehingga
atribut tersebut milik tabel M:N yang menghubungkan dua Event tersebut.
Pada tabel Penjualan Persediaan, setiap tabel tersebut mengandung
informasi tentang lini baris pada faktur. Meskipun banyak pelanggan yang hanya
membeli satu dari setiap jenis produk yang dijual oleh perusahaan, beberapa
penjualan kepada para pelanggan menghasilkan kuantitas yang lebih besar.
Misalnya, sebuah toko serba ada mungkin membeli lima coar car yang identik
untuk tampilan luarnya. Akibatnya, perusahaan harus mencatat kuantitas terjual
atas setiap barang. Tetapi, setiap Event penjualan mungkin menyertakan lebih dari
satu barang persediaan. Oleh karenanya, atribut kuantitas terjual mungkin
memiliki beberapa nilai pada faktur penjualan tunggal, satu untuk masing
masing (nomor produk) barang berbeda yang dijual. Akibatnya, atribut kuantitas
terjual tidak dapat ditempatkan dalam tabel Penjualan karena dapat
mengakibatkan ada lebih dari satu nilai kuantitas terjual yang diasosiasikan
dengan sebuah faktur tertentu. Selain itu, perusahaan menghitung persediaan
berdasarkan jenis barang, jadi masing masing produk tidak diidentifikasi
spesifik melainkan diidentifikasi dengan nomor produk. Akibatnya, kuantitas
terjual tidak dapat menjadi atribut pada tabel Persediaan karena ia dapat memiliki
nilai multipel. Sebelumnya juga telah dianalisis bahwa atribut kuantitas terjual
berkaitan dengan nomor produk spesifik pada sebuah faktur penjualan spesifik
pula. Oleh karena itu, atribut kuantitas terjual milik tabel hubungan M:N yang
menghubungkan entitas persediaan dan penjualan.
Data harga dan biaya
Informasi mengenai harga dan biaya pada tabel 18-1 disimpan sebagai
atribut pada beberapa tabel yang berbeda. Misalnya, tabel persediaan menyimpan
daftar harga yang disarankan untuk barang tersebut, yaitu harga barang tersebut
tetap konstan untuk satu periode fiskal tertentu. Tabel penjualan juga menyimpan
harga penjualan aktual yang bervariasi pada tahun tersebut, hal ini terjadi sebagai
hasil promosi penjualan. Serta hal tersebut juga terjadi untuk biaya pembelian

51

standar dan aktual atas setiap barang juga disimpan dalam tabel yang berbeda.
Peranan umumnya adalah bahwa data time independent harus disimpan sebagai
atribut Resource atau Agent, sedangkan data varies across time harus disimpan
dengan entitas Event atau hubungan M:N yang menautkan sebuah Resource dan
sebuah Event.
Data Kumulatif Dan Data Dapat Dihitung
Pada tabel 18-1 tidak mengandung data kumulatif, seperti kuantitas di
tangan (quantity on hand) dalam tabel persediaan atau data dapat dihitung,
seperti jumlah total penjualan dalam tabel penjualan. Hal ini dikarenakan tidak
satu pun dari jenis item data tersebut diperlukan karena nilainya dapat diperoleh
dari atribut lain yang disimpan. Misalnya, kuantitas barang yang tersedia untuk
sebuah barang persediaan tertentu dapat dilihat dari hasil kuantitias barang yang
tersedia pada awal periode fiskal ditambah dengan kuantitas total barang yang
dibeli pada periode tersebut dikurangi dengan kuantitas barang yang terjual pada
periode tersebut. Hal ini sama juga dengan jumlah total transaksi penjualan dapat
dihitung dengan mengalikan kuantitas terjual dengan harga jual aktual atas setiap
barang terjual dan menjumlahkan hasil tersebut untuk setiap baris pada tabel
Penjualan Persediaan yang memiliki nomor faktur yang sama.

Langkah 3: Menggunakan Kunci Asing Untuk Mengimplementasikan


Hubungan 1:1 Dan 1:N
Sebuah kunci asing adalah atribut sebuah entitas dan ia juga merupakkan
kunci utama entitas lain (Romney dan Steinbart)1. Menurut Abdul Kadir kunci
asing adalah sebaranh atribut yang menunjuk kunci primer pada tabel lain.
Walaupun hubungan 1:1 dan 1:N dapat diimplementasikan sebagai tabel terpisah,
biasanya akan lebih efisien jika mengimplementasikan hubungan 1:1 dan 1:N
dengan sarana kunci asing. Misalnya, atribut nomor pelanggan mungkin muncul
di tabel Pelanggan dan Penjualan. Atribut nomor pelanggan akan menjadi kunci
1 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

52

utama pada tabel Pelanggan, sedangkan pada tabel Penjualan akan menjadi kunci
asing.
Menggunakan Kunci Asing Untuk Mengimplementasikan Hubungan 1:1
Pada sebuah database relasional, hubungan 1:1 di antara entitas dapat
diimplementasikan dengan menyertakan kunci utama entitas sebagai kunci asing
pada tabel yang merepresentasikan entitas lain. Pilihan jenis tabel untuk
menempatkan kunci asing dapat dipilih dengan sesuka hati agar desain database
dapat terstruktur dengan baik. Tetapi, analisis cermat atas kardinalitas menimum
hubungan tersebut mungkin membutuhkan jenis pendekatan yang cenderung lebih
efisien.
Hubungan 1:1 antara penjualan dan pembayaran pelanggan dapat dilihat
pada Gambar 17-7, panel A. Kardinalitas minimum untuk Event Menerima Kas
adalah mengindikasikan adanya penjualan kredit, dan kardinalitas minimum untuk
peristiwwa penjualan adalah 1, mengindikasikan bahwa pembayaran pelanggan
hanya terjadi setelah penjualan terlaksana, misalnya tidak ada setoran dimuka.
Dalam hal tersebut juga ikut menyertakan nomor faktur atau kunci utama Event
penjualan sebagai kunci asing pada Event Menerima Kas mungkin lebih efisien
karena hanya satu tabel tersebutlah yang harus diakses dan diperbarui ketika
pemrosesan tiap pembayaran pelanggan. Selain itu, hubungan 1:1 antara dua
Event yang berurutan, memasukkan kunci utama dari Event yang terjadi pertama
kali sebagai kunci asing untuk Event yang terjadi selanjutnya, mungkin akan
meningkatkan pengendalian internal karena Karyawan diberikan akses untuk
memperbarui tabel berisi data terkait Event kedua yang tidak memerlukan akses
terhadap tabel yang digunakan untuk menyimpan informasi terkait Event pertama.
Meskipun demikian, pengendalian internal yang memanfaatkan tindakan
semacam ini harus imbang terhadap peningkatan kemungkinan kesulitan
melakukan query database tersebut.
Menggunakan Kunci Asing Untuk Mengimplementasikan Hubungan 1:N
Sama seperti Hubungan 1:1, Hubungan 1:N juga harus diimplementasikan
dalam database relasional dengan menggunakan kunci asing. Terdapat satu cara

53

untuk mengimplementasikan hubungan 1:N. Kunci utama entitas yang terdapat


ditautkan ke berbagai entitas lain, harus menjadi kunci asing pada entitas lain
tersebut. Oleh karenanya, pada tabel 18-1, kunci utama tabel Personel Penjualan
dan Pelanggan disertakan sebagai kunci asing pada tabel Penjualan. Sama halnya
dengan kunci utama tabel Kas, Pelanggan, dan Kasir yang disertakan sebagai
kunci asing pada tabel Menerima Kas. Pembalikan prosedur ini akan melanggar
salah satu aturan fundamental dari desain database relasional. Misalnya,
menempatkan nomor faktur sebagai kunci asing pada tabel Pelanggan tidak akan
berhasil karena ia dapat memiliki lebih dari satu nilai yaitu seorang pelanggan
tertentu mungkin dapat memiliki beberapa faktur yang dikarenakan pelanggan
tersebut sering membeli produk perusahaan.
Hal inilah yang menyebabkan hubungan M:N harus diimplementasikan
dengan tabel terpisah. Selama masing masing entitas dapat dihubungkan ke
berbagai keterjadian entitas pada sisi lain hubungan, tidak mungkin untuk
membuat kunci utama entitas menjadi sebuah kunci asing pada entitas lain.
Hubungan M:N Event Penjualan mungkin ditautkan ke banyak barang persediaan
yang berbeda. Oleh karenanya nomor produk tidak dapat digunakan sebagai kunci
asing pada tabel Persediaan karena ini akan multinilai. Satu satunya cara untuk
menghubungkan tabel Penjualan dan Persediaan yaitu dengan membuat sebuah
tabel baru yang memiliki baris terpisah untuk masing masing kombinasi aktual
atas nomor faktur dan nomor produk. Pada tabel M:N, sebuah nomor faktur akan
muncul dalam banyak baris yang berbeda, satu untuk tiap barang berbeda yang
merupakan bagian dari transaksi penjualan. Sebaliknya, sebuah nomor produk
tertentu, akan muncul dalam banyak baris yang berbeda, sekali untuk tiap
transaksi yang berbeda. Oleh karenanya, tidak ada atribut yang dengan sendirinya
mengedentifikasi secara unik sebuah baris tertentu. Walaupun demikian, hanya
akan ada satu baris yang memiliki kombinasi nomor faktur dan nomor produk
tertentu, sehingga kedua atribut dapat berlaku sebagai kunci utama untuk tabel
M:N.
Pengecekan Kelengkapan

54

Atribut yang dimasukkan ke dalam database oleh para pengguna dan


manajemen akan menyediakan sarana untuk mengecek dan memvalidasi proses
implementasi. Setiap atribut dalam daftar tersebut harus muncul setidaknya pada
satu tabel, baik sebagai kunci utama maupun atribut lain.
Pengencekan daftar tersebut terhadap nama kolom tabel mungkin akan
mengungkapkan tidak hanya fakta bahwa atribut tertentu belum ditentukan ke
tabel yang sesuai dalam database, tetapi mungkin akan mengindikasikan
kebutuhan untuk memodifikasi diagram REA itu sendiri. Misalnya, ketika
perancang database mengencek ganda daftar atribut, ia menemukan bahwa ia
tidak memiliki tabel untuk menempatkan atribut produk yang didiskusikan pada
panggilan penjualan. Dalam situasi ini, perancang database perlu menghubungi
kembali para pengguna dan manajemen untuk memahami kembali dalam
mengumpulkan atribut tertentu tersebut. Kemudian, pihak manajemen berencana
menugaskan salah satu Karyawannya untuk menghubungi pelanggan perusahaan
untuk pengaturan display sampel. Manajemen ingin mengumpulkan informasi
mengenai demontrasi sampel tersebut untuk mengevaluasi efektivitasnya.
Dalam situasi tersebut, perancang database perlu untuk membuat entitas
Event lainnya. Kunci utama pada Event ini mungkin appoinment number.
Nomor Karyawan dan nomor pelanggan akan menjadi kunci asing pada tabel
tersebut, yang juga akan menyertakan atribut tanggal dan waktu demonstrasi
bersamaan dengan sebuah area teks kosong untuk komentar dari pelanggan.
Karena setiap demonstrasi dapat melibatkan berbagai produk perusahaan dan
setiap produk tersebut dapat didemonstrasikan dalam berbagai hubungan, maka
akan ada sebuah tabel M:N antara Event Panggilan Pelanggan dan tabel
Persediaan. Rangkaian baris dalam tabel tersebut dengan appoinment number
yang sama akan mengidentifikasi produk mana yang ditunjukkan pada beberapa
panggilan penjualan tertentu. Beberapa panggilan dari pelanggan mungkin akan
menghasilkan pesanan produk, tetapi mungkin yang lainnya tidak. Selain itu,
beberapa pesanan produk akan terjadi tidak melalui panggilan penjualan seperti,
pelanggan melihat sebuah iklan. Oleh karenanya, kardinalitas minimum adalah 0
untuk tiap sisi hubungan tersebut antara Event Panggilan Pelanggan dan

55

Mengambil Pesanan Pelanggan. Kardinalitas maksimum pada tiap sisi hubungan


tersebut adalah 1 untuk menyederhanakan pelacakan efek dari panggilan
penjualan tersebut.
Kebutuhan perancang database untuk memodifikasi diagaram REA guna
mengakomodasi fakata tambahan, tidaklah biasa. Hal ini biasanya berguna untuk
membuat tabel tabel dan menentukan atribut ke tabel tabel tersebut, bahkan
sebelum menyelesaikan secara lengkap sebuah diagram REA. Hal ini membantu
mengklarifikasi secara tepat apa yang direpresentasikan tiap entitas yaitu hal yang
sering kali dapat menyelesaikandilema terkait kardinalitas yang tepat untuk
berbagai hubungan. Perancang database tersebut database tersebut kemudian
dapat memodifikasi dan memperbaiki diagram REA tersebut untuk memasukkan
entitas dan hubungan tambahan untuk mengakomodasi fakta lain yang semestinya
ada dalam database, tetapi belum dimasukkan ke tabel tabel yang ada.
Ketika semua atribut sudah dimasukkan ke tabel tabel, ketentuan dasar
untuk mendesain databese relasional dengan baik dapat digunakan sebagai
pengecekan ketepatan akhir. Ketentuan dasar untuk mendesain database ralasional
dengan baik yaitu (Romney dan Steinbart )1:
1.
2.

Setiap kolom dalam sebuah baris harus berlainan nilainya.


Kunci utama tidak boleh bernilai nol. Kunci utama adalah atribut atau
kombinasi dari beberapa atribut yang secara unik mengidentifikasi baris
dalam suatu tabel. Agar syarat ini terwujud, kunci utama dari suatu baris
dalam sebuah hubungan tidak boleh bernilai nol. Karena nantinya tidak akan
ada jalan untuk secara unik mengidentifikasi baris tersebut dan menarik data

3.

yang disimpan dalamnya.


Kunci luar, jika tidak bernilai nol, harus memiliki nilai yang sesuai dengan

4.

nilai kunci utama di hubungan yang lain.


Seluruh atribut yang bukan merupakan kunci dalam sebuah tabel harus
mendeskripsikan objek yang diidentifikasi oleh kunci utama.
Keempat ketentuan dasari ini akan menghasilkan database yang terstruktur

dengan baik yang dapat meninimlkannya serta dapat mengendalikan pengulangan


1 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

56

data, dan data tetap konsisten. Ketentuan dasar ini dapat digunakan untuk
pengecekan ketepatan akhir:
1.
2.

Setiap tabel harus memiliki sebuah kunci utama


Antribu nonkunci lain pada setiap tabel harus berupa fakta tentang hal yang
didesain oleh kunci utama asing serta digunakan untuk menautkan tabel

3.

tersebut ke tabel lain


Setiap atribut pada setiap tabel benilai tunggal (yaitu setiap tabel merupakan
file flat).
Sel tabel tabel yang beruhubungan tercantum pada Tabel 18-1 memenuhi

tiga ketentuan di atas. Tabel tabel tersebut juga berkaitan dengan Gambar 18-4,
sehingga merefleksikan kebijakan bisnis. Keterkaitan ini juga memfasilitasi
penggunaan diagram REA untuk menjadi panduan dalam perancangan atas query
dan laporan guna memuat dan menampilkan informasi mengenai aktivitas bisnis
organisasi tersebut.

Menurut James A. Hall1


Langkah 1: Menggabungkan Model Model Individual
Dengan diagram-diagram REA individu yaitu Gambar 18-1, Gambar 18-2
dan Gambar 18-3 yang telah dibuat dan yang telah kami jelaskan, maka
selanjutnya menyatukan diagram diagram individu tersebut menjadi suatu
diagram tunggal yang berskala interprise seperti Gambar 18-4.

Dengan

membalikkan diagram diagram siklus pengeluaran seperti dipantulkan dalam


cermin, resource umum persediaan dan Uang/Cash berpusat di tengah. Keduanya
diapit oleh dua konstelasi Event, yang menambahkan dan menguranginya. Para
Agent

membentuk

konstelasi

pada

pinggiran

diagram.

Untuk menyederhanakan diagram, entitas-entitas Event, Agentt, dan


resource yang redundant disatukan menjadi satu entitas

tunggal bila

1 James, A. Hall. Sistem Informasi Akuntansi. Edisi Ketujuh, Jakarta: Salemba Empat,
2010.

57

memungkinkan. Contohnya, Event Disburse Cash / Membayar Uang, yang


merupakan

elemen

penting

pada

prosedur

Payroll

dan

Pembayaran

Pembelian/Cash disajikan hanya sekali di dalam model yang telah disatukan.


Selain itu, entitas-entitas Uang/Cash dan Inventory/Persediaan hanya disajikan
sekali saja pada diagram yang telah disatukan. Untuk mempertahankan perspektif
peranan-peranan yang dimainkan oleh para Agentt internal, mereka disajikan
sebagai entitas-entitas individu daripada disajikan secara kolektif sebagai
karyawan. Terakhir, untuk menghindari garis-garis yang menyilang pada asosiasi
antar entitas, Agentt Supplier dan Pelanggan dimunculkan lebih dari satu kali pada
diagram tersebut.

Langkah 2: Mendefinisikan Primary Key, Foreign Key, Dan Atribut


Pada langkah ini kita akan memulai mendesain tabel tabel database
relasional berdarkan model data yang sudah kita buat. Awalnya kita menentukan
dulu primary key, foreign key serta atribut atribut tabel. Satu tabel akan dibuat
untuk setiap entitas yang valid pada diagram REA yang sudah terintegrasi pada
gambar 18-4. Menurut James A. Hall, hal ini memerlukan 18 tabel, dimana ke 18
tabel tersebut akan dijelaskan sebagai berikut::

10 agent internal yang disajikan pada gambar 10-12 akan disatukan

menjadi satu tabel Employee/Karyawan.


Dua agent eksternal (Pelanggan dan Supplier) masing-masing akan

memerlukan table tersendiri.


Dua resource Inventory/Persediaan dan Uang/Cash masing-masing akan

menjadi satu tabel.


Delapan event masing-masing akan memerlukan tabel sendiri.
Lima relasi M:M yang disajikan pada diagram masing-masing akan
memerlukan tabel penghubung.

Aturan untuk primary key dan atribut


Peracang database harus memilih primary key yang secara logic dan
unique mendefinisikan atribut-atribut nonkey pada tabel. Dalam beberapa hal, hal

58

ini dicapai dengan kode sekuensial sederhana seperti Nomor Invoice, Nomor
Check, atau Nomor Purchase Order. Pada beberapa situasi yang lain, block codes,
group codes, alphabetic codes, dan mnemonic codes adalah lebih baik. Beberapa
jenis atribut tabel adalah umum bagi semua organisasi dan bisa diturunkan dari
pengertian umum. Beberapa jenis atribut lain adalah bersifat unique terhadap
aplikasi tertentu dan bisa diturunkan dari analisa rinci dan menyeluruh terhadap
pandangan pengguna. Namun, setiap atribut yang diberikan ke suatu tabel harus
muncul baik secara langsung atau tidak langsung (nilai yang sudah
diperhitungkan) pada satu atau lebih pandangan pengguna. Bila ada data yang
disimpan pada suatu tabel tidak digunakan dalam suatu dokumen, report, atau
penghitungan yang digunakan untuk laporan, maka tidak ada gunanya dan tidak
perlu menjadi bagian dari database.
Aturan untuk foreign key
Derajat asosiasi antar tabel (yaitu, 1:1, 1:M, atau M:M) menentukan
bagaimana foreign key diberikan. Berikut penjelasannya lebih lanjut
Key pada asosiasi 1:1. Dalam asosiasi 1:1, salah satu sisi dari asosiasi tersebut
pada umumnya akan memiliki kardinalitas minimum nol (zero). Ketika hal ini
terjadi, primary key dari tabel yang kardinalitasnya 1,1 sebaiknya ditanamkan
sebagai foreign key pada tabel yang kardinalitasnya 0,1. Bila aturan ini dibalik
akan menghasilkan struktur tabel dimana tabel yang kardinalitasnya 1,1 berisi
instance foreign key yang nilainya null (blank). Meskipun penghubung semacam
ini akan tetap berhasil, namun tabel seperti ini adalah desain tabel yang buruk
yang bisa menyebabkan inefisiensi dan berpotensi menyebabkan error. Namun
demikian, dengan menaati aturan tadi semua nilai foreign key pada tabel yang
kardinalitasnya 0,1 (dari asosiasi tersebut) tidak akan null. Contohnya, kita bisa
lihat

dari

tabel

10-1

bahwa

primary

key

untuk

tabel

Verify

Availability/Memverifikasi Ketersediaan (Nomor Permintaan) ditetapkan sebagai


foreign

key

ke

tabel

Take

Order/Menangani

Pesanan.

Key pada asosiasi 1:M. Dimana ada asosiasi 1:M dianatara tabel-tabel tersebut,
primary key pada sisi 1 ditanamkan pada tabel yang M. contohnya, primary key
tabel Employee (Employee Number) ditetapkan sebagai foreign key ke tabel-tabel

59

Verify

Availability,

Take

Order,

dan

Ship

Product.

Key pada asosiasi M:M. tabel-tabel pada asosiasi M:M tidak bisa menerima
foreign key yang ditanamkan dari tabel yang ter-relasi. Sebaliknya, desainer
database harus membuat tabel baru yang berfungsi sebagai penghubung yang
berisi dari kedua tabel foreign key. Dengan membuat satu tabel penghubung
diantara tabel-tabel asli, asosiasi M:M diubah menjadi dua buah asosiasi yang 1:M
(lihat gambar 10-9). Tabel penghubung sekarang bisa menerima primary key dari
tabel-tabel tersebut pada sisi 1 dari dua asosiasi baru tersebut. Proses ini
menghasilkan key komposit (key gabungan/kombinasi) yang bertindak sebagai
primary key untuk mendefinisikan atribut-atribut (bila ada) pada tabel
penghubung. Masing-masing komponen dari key komposit juga bertindak sebagai
foreign key untuk menempatkan record-record yang terkait pada tabel-tabel yang
terelasi. Lima tabel penghubung disajikan pada tabel 10-1: Inventori-Verify Link,
Inventory-Order Link, Inventory-Ship Link, Ord-Prod-Inven Link, dan Rec-ProdInven Link.

Langkah 3: Membuat Database Fisik Dan Membuat Pandangan Pengguna


Pada langkah ini James Hall menerangkan bahwa tabel tabel relasional
fisik harus sudah siap dibuat oleh perancang database dan telah diisi dengan data
(Tabel 18-1)1. Tabel-tabel resource dan agent harus diinisialiasi dengan nilai-nilai
data tertentu seperti kuantitas inventory yang tersedia, nama dan alamat
pelanggan, dan data karyawan. System yang baru akan mulai berjalan dengan
nilai-nilai awal ini untuk atribut-atribut dari tabel-tabel tersebut. Sebaliknya,
tabel-tabel events dimulai dengan data yang kosong dan akan diisi melalui
berbagai aktivitas proses transaksi aktual.
Database yang dihasilkan tersebut diharapkan dapat membantu kebutuhan
informasi para pengguna system. Hal ini termasuk kebutuhan para akuntan, para
personel operasi, dan manajemen. Reports, layar komputer, dan berbagai
1 James, A. Hall. Sistem Informasi Akuntansi. Edisi Ketujuh, Jakarta: Salemba Empat,
2010.

60

dokumen yang meliputi berbagai pandangan/tampulan diturunkan dari berbagai


perintah SQL (structured query language) yang mengakses ke berbagai tabel yang
telah dinormalisasi pada database.
Menghasilkan laporan keuangan dan berbagai laporan akuntansi yang lain.
Pada system tradisional, laporan keuangan biasanya disiapkan dari akunakun general ledger yang nilainya diturunkan dari jurnal voucher. Namun, jurnal,
ledgers, dan doublen-entry accounting, bukanlah entitas pada model REA.
Sebaliknya, mekanisme akuntansi tradisional tersebut direproduksi dari berbagai
tabel event. Untuk mengilustrasikannya, gambar dibawah ini menyajikan struktur
untuk beberapa tabel relasional pada database. Struktur tabel tersebut berkaitan
dengan tabel-tabel yang ada pada tabel 18-1, tetapi beberapa atribut tidak dipakai
untuk menyederhanakan gambar tersebut.

Tabel Menghitung Nomor Akuntansi dari Tabel REA (James A. Hall)1

1 James, A. Hall. Sistem Informasi Akuntansi. Edisi Ketujuh, Jakarta: Salemba Empat,
2010.

61

James A. Hall menjelaskan Gambar diatas tersebut menunjukkan


bagaimana angka-angka akuntansi laporan keuangan bisa dikonstruksi dari data
Event yang mendasari. Perhitungannya adalah seperti berikut:

Total Sales adalah jumlah dari atribut Invoice Amount pada tabel Ship
Product untuk semua item yang sudah dikirim pada atau sebelum tanggal
penutupan akhir tahun.
Accounnts Receivable = Total Sales dikurangi jumlah dari atribut Amount
pada tabel Receive Cash untuk semua remittance yang diterima pada atau
sebelum tanggal penutupan akhir tahun.
Cost of Goods Sold = jumlah dari Quantity yang terjual pada tabel
penghubung Inventory-Ship yang dikalikan dengan atribut Unit Cost pada
tabel Inventory.
Inventory = atribut Quantity On Hand yang dikalikan dengan atribut Unit
Cost pada tabel Inventory.

62

D.

MENGGUNAKAN DIAGRAM REA UNTUK MEMUAT


INFORMASI DARI SEBUAH DATABASE
Pada bagian sebelumnya telah dibahas bagaimana menggunakan model

data REA untuk memandu desain sebuah Sistem Informasi Akuntansi yang akan
secara efisien menyimpan informasi mengenai aktivitas bisnis sebuah organisasi.
Selanjutnya pada bagian ini kita akan merujuk pada Gambar 18-4 dan Tabel 18-1
untuk menunjukkan cara penggunaan keseluruhan diagram REA untuk
memfasilitasi pemuatan informasi guna mengevaluasi kinerja.
Sejumlah elemen yang dapat ditemukan dalam Sistem Informasi
Akuntansi tradisional, seperti jurnal, buku besar, dan informasi mengenai utang
piutang. Informasi seperti ini walaupun tidak terdapat didalam sebuah diagram
REA, informasi ini dapat diperoleh dari query yang sesuai, query ini hanya dibuat
sekali dan yang kemudian disimpan dan dapat dijalankan kapanpun diinginkan.

Menghasilkan Jurnal Dari Quety


Jurnal menyediakan sebuah daftar kejadian transaksi. Pada sebuah
database relasional didesain berdasarkan model data REA, entitas Eventa
menyimpan informasi mengenai transaksi. Oleh karenanya, informasi yang
normalnya ditemukan dalam sebuah jurnal, ia terkandung dalam tabel yang
digunakan untuk mencatat data mengenai Event. Misalnya, tabel Penjualan dan
Penjualan Persediaan mengandung tentang informasi penjualan barang tertentu
kepada pelanggan. Jadi, sebuah jurnal penjualan dapat dihasilkan dengan
menuliskan sebuah query yang merujuk pada kedua tabel untuk menghitung
jumlah penjualan yang dibuat dalam suatu periode tertentu.
Tetapi, dalam membuat jurnal penjualan tradisional tidah diharuskan untuk
membuat prosedut tersebut karena tindakan tersebut akan menghasilkan daftar
seluruh transaksi penjualan, baik penjualan secara tunai maupun penjualan secara
kredit. Walaupun demikian, jurnal penjualan tradisional hanya mencatat penjualan

63

kredit. Pada sebuah database relasional yang dibangun dalam model REA, seperti
Gambar 18-4, pembayaran pelanggan dicatat dalam tabel Event Menerima Kas.
Akibatnya, sebuah query untuk menghasilkajn sebuah jurnal penjualan tradisional
yaitu hanya pendataan penjualan yang dibuat secara kredit juga harus
menyertakan baik tabel Menerima Kas maupun Panjualan Menerima Kas.
Sebuah database yang dibangun pada model REA akan menghasilkan baris pada
tebel Penjualan untuk tiap penjualan barang ke pelanggan dan baris pada tabel
Menerima Kas untuk mencatat penerimaan pembayaran produk dari seorang
pelanggan. Untuk penjualan secara tunai, kedua baris akan memiliki nilai yang
sama pada kolom data dan nomor pelanggan. Oleh karenanya, kelogisan dari
sebuah query untuk menghasilkan sebuah jurnal penjualan tradisional akan
membatasi output untuk menampilkan hanya penjualan yang tidak ditautkan ke
Event pembayaran pelanggan terkait, dengan kata lain nomor pelanggan yang
sama muncul dalam kedua tabel, dan jumlah Event Menerima Kas sama dengan
jumlah penjualan yang terjadi pada hari yang sama dengan Event Penjualan.
Baris pada tabel Menerima kas dengan tanggal yang lebih lama dibandingkan
tanggal transaksi penjualan terkait merepresentasikan pembayaran pada penjualan
kredit. Proses yang sama dapat diikuti untuk menuliskan queri yang akan
menghasilkan jurnak khusus lainnya, seperti keseluruha pembeli kredit atau
keseluruhan pengeluaran kas yang tidak terkait dengan penggajian.
Buku besar adalah file induk yang mengandung informasi kumulatif
mengenai akun akun tertentu (Romney dan Steinbart ) 1. Pada sebuah database
relasional yang didesain berdasarkan model data REA, entitas Resource
mengandung informasi yang temuat dari satu tahun fiskal ke tahun berikutnya.
Oleh karenanya, banyak informasi mengenai aset sebuah perusahaan yang
biasanya dicatat dalam buku besar yang disimpan dalam tabel Resource pada
sebuah database relasional yang merujuk pada REA. Misalnya, setiap baris pada
tabael Resource Perlengkapan akan mengandung informasi tentang bagian
perangkat atau kelompok mesin tertentu, seperti biaya perolehan mesin, masa
manfaat mesin, metode depresiasi yang digunakan, dan nilai sisa estimasian. Hal
1 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

64

ini pun sama dengan setiap baris dalam tabel Resource Kas yang mengandung
informasi mengenai sebuah akun tertentu yang menyimpan kas dan yang memiliki
nilai yang sama dengan kas perusahaan tersebut, dan setiap baris tabel Resource
Perlengkapan menyimpan informasi mengenai barang persediaan tertentu.
Setiap akun Resource tersebut dipengaruhi oleh Event yang menaikkan
dan menurunkan. Seperti Perlengkapan dibeli dan kemudian perlengkapan
tersebut digunakan, kas diterima dan kas dikeluarkan, persediaan dibeli dan
persediaan dijual. Oleh karenanya, query untuk menampilkan saldo kumulatif
terkini untuk akun akun ini harus merujuk tidak hanya pada tabel yang sesuai
bagi

entitas

Resource

tersebut,

tetapi

juga

pada

tabel

Event

yang

mempengaruhinya. Misalnya, sebuah query untuk menampilkan saldo terkini pada


rekening bank tertentu akan merujuk tidak hanya tabel Resource Kas, untuk
mengidentifikasi nomor rekening dan saldo awal periode fiskal tertentu, tetapi
juga tabel Menerima Kas dan Mengeluarkan Kas, untuk menemukan aliran kas
masuk dan aliran kas keluar yang mempengaruhi rekenijng tersebut selama
periode fiskal terkini.

Menghasilkan Laporan Keuangan


Diagram REA yang lengkap dapat digunakan sebagai panduan penulisan
query untuk menghasilkan informasi yang akan dimasukkan ke dalam laporan
keuangan. Banyak akun akun dalam laporan keuangan, seperti Kas, Persediaan,
dan Aset Tetap, dipresentasikan sebagai Resource dalam model REA. Walaupun
demikian dalam Gambar 18-4 tidak menunjukkan sebuah entitas yang disebut
dengan Piutang maupun Utang. Dikarenakan kedua akun tersebut semata mata
merepresentasikan sebuah ketidakseimbangan antara dua Event terkait. Piutang
merepresentasikan transaksi penjualan di mana perusahaan belum menerima
pembayaran dari pelanggan dan utang merepresentasikan perusahaan belum
membayar pembelian persediaan barang dari pemasok. Oleh karenanya, piutang
maupun utang tidak perlu secara eksplisit disimpan sebagai tabel terpisah dalam

65

sebuah database REA. Klaim tersebut bahkan dapat dihasilkan pengaturan query
terhadap

tabel Agent dan Event yang relevan. Misalnya, tiga query dapat

digunakan untuk menghitung saldo akun seorang pelanggan individual ikuti


proses yang serupla, tetapi batasi query hanya ke Event Penjualan dan Menerima
Kas yang memiliki nomor pelanggan spesifik sebagai kunci asing. Pertama,
jumlahkan saldo awal total dalam setiap rekening pelanggan. Kedua, hitung
penjualan baru total periode ini dengan melakukan sebuah query terhadap
hubungan M:N Penjualan Persediaan untuk menjumlahkan kuantitas produk
yang terjual dikalikan dengan harga unit. Ketiga, tentukan kas total yang diterima
dari para pelanggan periode ini dengan menjumlahkan kolom jumlah pada tabel
Menerima Kas. Piutang total sama dengan Piutang awal (query 1) ditambah
penjualan baru (query 2) dikurangi penerimaan kas (query 3). Satu set query yang
sama akan menghasilkan Utang total. (Romney dan Steinbart)1
Membuat Laporan Manajerial
Model data REA memafasilitasi pembuatan banyaknya variasi laporan
manajerial karena ia mengintegrasikan data nonkeuangan dan keuangan. Misalnya
tabel 18-1 menunjukkan bahwa entitas Penjualan pada Gambar 18-4 menyertakan
sebuah atribut untuk mencatat waktu penjualan tersebut terjadi. Manajemen dapat
menggunakan data tersebut untuk melacak aktivitas penjualan pada kurun waktu
hari yang berbeda untuk keperluan rencana staffing yang lebih baik di perusahaan.
Atribut nonkeuangan lainnya dapat dimasukkan dalam tabel lainnya. Misalnya,
tabel pelanggan dapat dimodifikasi untuk menyertakan sebuah atribut. Jika
manajemen dapat mengumpulkan inormasi ini dari para pelanggannya, pihak
manajemen mungkin dapat lebih baik dalam menargetkan periklanannya guna
memenuhi kepentingan setiap pelanggan individu. Selain itu, Tabel 18-1 dapat
dimodifikasi dengan mudah untuk mengintegrasikan data dari Resource
Resource eksternal. Misalnya, untuk mengevaluasi dengan lebih baik atas
kelayakan kredit kepada para pelanggan, manajemen bisa saja memutuskan untuk
mengumpulkan informasi dari sebuah Agentsi pemeringkat kredit. Informasi
1 Marshall B. Romney dan Steinbart , Paul john steinbart. Sistem Informasi Akuntansi. Edisi 13.
Jakarta: Salemba Empat. 2014.

66

tersebut dapat ditambahkan ke database dengan membuat sebuah kolom tambahan


pada tabel Pelanggan untuk menyimpan peringkat kredit pelanggan tersebut.
Proses yang sama dapat digunakan untuk menyimpan informasi tentang para
pemasok yang dapat digunakan untuk proses penyelesaian vendor.

67

DAFTAR PUSTAKA
Marshall B. Romney dan Steinbart , Paul john steinbart. 2014. Sistem Informasi
Akuntansi. Edisi 13. Jakarta: Salemba Empat.
James, A. Hall. 2010. Sistem Informasi Akuntansi. Edisi Ketujuh, Jakarta:
Salemba Empat.
Nugroho Wijayanto. 2001. Sistem Informasi Akuntansi. Jakarta: Erlangga.

68