MAKALAH

SISTEM INFORMASI AKUNTANSI (BAB 18)

“MENGIMPLEMENTASIKAN MODEL REA DALAM

DATABASE RELASIONAL”

DISUSUN OLEH :

1. MUHAMMAD FARID ARYTAMA ( 1901036133 )

2. MARIA RETNO ARISTA ( 1901036137 )
3. YESI SEPTIANA ( 1901036138 )

UNIVERSITAS MULAWARMAN

FAKULTAS EKONOMI DAN BISNIS

2020
 KATA PENGANTAR

Puji syukur kehadirat Tuhan Yang Maha Esa karena telah memberikan kesempatan pada kami
untuk menyelesaikan makalah ini. Atas rahmat dan hidayah-Nya lah kami dapat menyelesaikan
makalah yang berjudul Mengimplementasikan Model REA Dalam Database Relasional tepat
waktu. Makalah ini disusun guna memenuhi tugas Bapak Indra Suyoto Kurniawan, SE., M.SA.,
AK pada Sistem Informasi Akuntansi. Selain itu, kami juga berharap agar makalah ini dapat
menambah wawasan bagi pembaca.

Kami mengucapkan terima kasih sebesar-besarnya kepada Bapak Indra Suyoto Kurniawan, SE.,
M.SA., selaku dosen mata kuliah Sistem Informasi Akuntansi. Tugas yang telah diberikan ini
dapat menambah pengetahuan dan wawasan terkait bidang yang kami tekuni. Kami juga
mengucapkan terima kasih pada semua pihak yang telah membantu proses penyusunan makalah
ini.

Kami menyadari makalah ini masih jauh dari kata sempurna. Oleh karena itu, kritik dan saran
yang membangun akan kami terima demi kesempurnaan makalah ini.

Samarinda, 06 November 2020

Kelompok 15

ii
 DAFTAR ISI

Kata Pengantar....................................................................................................ii

Daftar Isi.............................................................................................................iii

Bab 18 Mengimplementasikan Model REA dalam Database Relasional

Pendahuluan........................................................................................................1

A. Mengintegrasikan Diagram REA Antarsiklus...........................................2

B. Aturan untuk Mengombinasikan Diagram REA.......................................3
 Menggabungkan Entitas Sumber Daya yang Berulang..................................................6
 Menggabungkan Entitas Peristiwa yang Berulang.........................................................7
 Memvalidasi ketepatan Diagram REA Terintegrasi.......................................................9
C. Mengimplementasi Diagram REA dalam Database Relasional..............10
 Langkah 1 : Buat Tabel untuk setiap Entitas yang berbeda dan Tabel hubungan M:N13
 Langkah 2 : Menentukan Atribut untuk setiap Tabel....................................................13
 Langkah 3 : Menggunakan kunci asing untuk mengimplementasikan hubungan 1: 1
dan 1: N.........................................................................................................................17
 Pengecekan Kelengkapan..............................................................................................19
D. Menggunakan Diagram REA untuk memuat Informasi dari
sebuah Database..........................................................................................21
 Membuat Jurnal dan Buku Besar..................................................................................22
 Menghasilkan Jurnal dari Query.................................................................................28
 Menghasilkan Laporan Keuangan.................................................................................30
 Membuat Laporan Manajerial.......................................................................................35

Ringkasan dan Kesimpulan kasus...................................................................39

Daftar Pustaka...................................................................................................40

iii
PENDAHULUAN

Bab ini menunjukkan cara mengimplementasikan diagram REA dalam sebuah database. Fokus
pada pemrosesan transaksi dan cenderung familier untuk sebagian besar mahasiswa bisnis.
Namun, permodelan data REA tidak hanya untuk penggunaan dalam mendesain database
relasional, tetapi juga dapat digunakan untuk mendesain database berorientasi objek.

Dimulai dengan menunjukkan cara mengintegrasikan diagram REA terpisah yang

dikembangkan untuk siklus bisnis tunggal ke dalam sebuah model data tunggal, komprehensif,
dan seluruh-perusahaan. Kemudian, menjelaskan cara mengimplementasikan model data hasil
dalam sebuah database relasional. Selanjutnya, mendeskripsikan cara menggunakan diagram
REA untuk melakukan query database guna menghasilkan laporan keuangan tradisional serta
berbagai laporan manajemen.

1
A. MENGINTEGRASIKAN DIAGRAM REA ANTARSIKLUS
Figur 18 – 1, 18 – 2, dan 18 – 3 menyajikan diagram REA siklus pendapatan, pengeluaran,
dan penggajian Fred’s Train Shop secara berurutan. Diagram-diagram yang terpisah ini harus
diintegrasikan untuk menyediakan model keseluruhan-keseluruhan komprehensif tunggal atas
organisasi tersebut. dalam melakukannya, perlu pemahaman tentang kardinalitas dalam tiap
diagram terpisah yang mengungkapkan kebijakan dan aktivitas organisasi tersebut.
Figur 18 – 3 menggambarkan porsi penggajian atas aktivitas siklus SDM/ penggajian Fred’s
Train Shop. Pertukaran ekonomi dasar melibatkan pemerolehan penggunaan waktu dan
keterampilan tiap pegawai dalam pertukaran dengan pegawai menerima sebuah slip gaji.
Seperti kebanyakan bisnis kecil, Fred’s Train Shop menggunakan jam waktu elektronik untuk
mencatat waktu pengerjaan masing-masing pegawai setiap harinya. Oleh karena itu, setiap
peristiwa waktu pengerjaan mencatat waktu seorang pegawai mulai dan mengakhiri pekerjaan
pada satu hari tertentu. Setiap peristiwa semacam itu harus ditautkan keseorang pegawai
tertentu dan supervisornya. Namun, setiap pegawai atau supervisor mungkin ditautkan
kebanyak peristiwa berbeda.

FIGUR 18 – 1 Siklus pendapatan Fred’s Train Shop

2
B. ATURAN UNTUK MENGOMBINASIKAN DIAGRAM REA
Beberapa aturan yang digunakan untuk mengombinasikan diagram REA:
 Menggabungkan entitas sumber daya yang berulang.
 Menggabungkan entitas peristiwa yang berulang.
 Memvalidasi ketepatan diagram REA terintegrasi.

Diagram REA terintegrasi harus memenuhi enam aturan berikut:

1) Setiap peristiwa harus ditautkan setidaknya ke satu sumber daya.

2) Setiap peristiwa harus ditautkan ke dua agen yang berpartisipasi dalam peristiwa
tersebut.
3) Setiap peristiwa harus melibatkan pelepasan sumber daya yang harus ditautkan ke
sebuah peristiwa yang melibatkan perolehan sumber daya. (Ini merefleksikan dualitas
ekonomi yang mendasari pertukaran ekonomi "give-to-get").
4) Setiap sumber daya harus ditautkan setidaknya ke satu peristiwa yang menaikkan
sumber daya tersebut dan setidakny ke satu peristiwa yang menurunkan sumber daya
tersebut.
5) Peristiwa A dapat ditautkan ke lebih dari satu peristiwa lainnya, tetapi tidak dapat
ditautkan secara bersamaan ke seluruh peristiwa lain tersebut, kemudian diagram
REA harus menunjukkan bahwa peristiwa A ditautkan ke minimum 0 atas masing-
masing dari peristiwa lain tersebut.
6) Sebuah peristiwa dapat ditautkan ke salah satu dari sekelompok agen, tetapi tidak
dapat ditautkan secara bersamaan ke seluruh agen, kemudian diagram REA harus
menunjukkan bahwa peristiwa tersebut ditautkan ke minimum 0 atas masing-masing
dari agen tersebut.

3
FIGUR 18 – 2 Siklus pengeluaran Fred’s Train Shop

FIGUR 18 – 3 Siklus penggajian Fred’s Train Shop

4
 Sebuah slip gaji juga diterbitkan keseorang pegawai tertentu dan ditandatangani oleh
seorang kasir tertentu, tetapi setiap pegawai dan kasir mungkin terhubung dengan banyak
peristiwa mengeluarkan khas yang berbeda dari waktu ke waktu. Oleh karna itu, figur 18
menggambarkan antara agen dan peristiwa sebagai 1 : N. Kardinalitas pada sisi agen hubungan
tersebut selalu 1, karna setiap peristiwa harus dihubungkan ke seorang pegawai tertentu.
Kardinalitas minimum pada sisi peristiwa hubungan tersebut selalu 0, dalam rangka untuk
mengakomodasi penyimpanan data terkait pegawai baru sebelum ia mulai bekerja dan karna
entitas peristtiwa kosong pada awal setiap tahun fisikal baru.

Hubungan antara peristiwa waktu pengerjaan dan mengeluarkan kas merefleksikan

pertukaran ekonomi dasar dari waktu pengerjaan seorang pegawai dan pembayarannya. Figur 18
– 3 menunjukkan bahwa hubungan antara kedua peristiwa tersebut adalah 1 : N. Hal tersebut
karna seperti kebanyakan bisnis, Fred’s Train Shop membayar pegawai secara periodik, tetapi
mencatat waktu pengerjaannya harian. Oleh karna itu, setiap peristiwa mengeluarkan kas
ditautkan ke banyak peristiwa waktu pengerjaan harian.

Entitas waktu pegawai memerlukan beberapa penjelasan. Ini mempresentasikan fakta

bahwa sumber daya yang diperoleh oleh peristiwa waktu pegawai adalah penggunaan
keterampilan dan pengetahuan pegawai untuk periode waktu tertentu. Waktu berbeda dari
persediaan kas, sumber daya berwujud lainnya, dan sumber daya tak berwujud seperti rahasia
dagang atau bentuk lain dari kekayaan intelektual dalam hal tidak dapat disimpan. Setiap
organisasi perlu mengawasi seberapa banyak waktu pengerjaan setiap pegawai untuk
menghitung penggajiannya. Peristiwa waktu pengerjaan merupakan contoh dari sebuah peristiwa
sumber daya “ mendapatkan “, menyediakan tujuan ini.

Pada akhirnya kardinalitas hubungan antara peristiwa mengeluarkan kas dan sumber daya
kas identik dengan siklus pengeluaran ( figur 18 – 2). Setiap cek atau transer dana elektronik
harus ditautkan setidaknya kesatu akun kas dan dapat ditautkan ke hanya satu akun kas.
Sementara akun kas yang sama mungkin ditautkan ke banyak peristiwa mengeluarkan kas.

Figur 18 – 1, 18 – 2, dan 18 – 3 masing-masing mengandung beberapa entitas yang sama.

Sebagai contoh, sumber daya persediaan muncul baik pada figur 18 – 1 maupun figur 18 – 2.
Peristiwa mengeluarkan kas muncul baik pada figur 18 – 2 maupun 18 – 3. Kedua agen baik
pegawai maupun sumber dayakas muncul pada ketiga diagram. Perulangan seperti itu

5
menyediakan dasar untuk mengombinasikan diagram REA yang menggambarkan siklus bisnis
individual kedalam sebuah model REA tunggal, model komprehensif, dan model keseluruhan-
perusahaan.

Figur 18-4 menunjukkan model semacam itu bagi Fred’s Train Shop. Perhatikan bahwa
diagram terintegrasi menggabungkan berbagai salinan entitas sumber daya dan peristiwa tetapi ia
menyimpan berbagai salinan entitas agen. Ini memaksimalkan terbatasan diagram REA
komprehensif dengan menghindari kebutuhan untuk memiliki garis hubungan melintas satu sama
lain.

MENGGABUNGKAN ENTITAS SUMBER DAYA YANG BERULANG

Diagram REA untuk siklus bisnis individual terbentuk disekitar pertukaran ekonomi give-to-get
dasar. Hubungan dualitas ekonomi tersebut menjelaskan mengapa sebuah sumber daya diperoleh
atau dilepas. Meski demikian, hubungan tersebut hanya menyediakan satu bagian cerita saja
mengenai tiap aumber daya. Sebagai contoh, figur 18-1 menunjukkan bahwa persediaan
dikurangi (peristiwa penjualan) dalam pertukaran kas ( peristiwa menerima kas ). Namun figur
18-1 tidak menunjukkan cara persediaan itu awalnya diperoleh. Ia juga tidak menunjukkan cara
organisasi menggunakan kas yang ia terima dari para pelanggan. Sebaliknya figur 18-2
menunjukkan cara persediaan didapatkan (peristiwa menerima persediaan) dengan menyerahkan
kas (peristiwa mengeluarkan kas). Namun figur 18-2 tidak menunjukan hal yang dilakukan
organisasi dengan persediaan tersebut atau cara organisasi memperoleh kas yang digunakannya
untuk membayar para pemasok.

Oleh karna itu, diagram REA untuk siklus bisnis individual hanya menyediakan informasi parsial
mengenai sumber daya yang dikendalikan oleh sebuah organisasi.

6
FIGUR 18-4 Diagram REA terintegrasi untuk Fred’s Trans Shop

Gambar lengkap tersebut akan menunjukkan bagaimana tiap sumber daya diperoleh dan
bagaimana ia digunakan. Seperti yang ditunjukkan pada figur 18-4, hal tersebut dapat dilakukan
dengan menggambarkan ulang sebuah diagram REA untuk menempatkan sumber daya umum
diantra peristiwa yang memengaruhinya. Dengan melakukannya, maka merefleksikan dualitas
penting lainnya yang harus digambarkan dalam sebuah model REA lengkap atas segala
organisasi. Setiap sumber daya harus dihubungkan setidaknya ke satu peristiwa yang
meningkatkan sumber daya tersbut dan setidaknya kesatu peristiwa yang menurunkannya.

MENGGABUNGKAN ENTITAS PERISTIWA YANG BERULANG

Diagram REA untuk siklus bisnis individual mungkin mengandung beberapa peristiwa
yang juga muncul pada diagram REA siklus lain. sebagai contoh, figur 18-2, dan 18-3 keduanya
mengandung entitas peristiwa mengeluarkan kas. Seperti pada kasus sumber daya,

7
penggabungan berbagai peristiwa yang sama dapat meningkatkan hasil diagram REA
komprehensif yang lebih muda dipahami. Oleh karna itu figur 18-4 menunjukkan bahwa
peristiwa mengeluarkan kas dihubungkan ke peristiwa menerima persediaan dan waktu
pengerjaan. Namun, pemeriksaan yang teliti atas figur 18-4 dapat mengungkapkan perbedaan
penting diantara penggabungan peristiwa yang berulang dan penggabungan sumber daya yang
berulang. Penggabungan sumber daya yang berulang tidak memengaruhi kardinalitas, tetapi
penggabungan peristiwa yang berulang dapat mengubah kardinalitas minimum yang
diasosiasikan dengan peristiwa lain serta berhubungan dengan peristiwa yang digabungkan
tersebut. oleh karnanya pada figur 18-4, kardinalitas antara sumber daya persediaan dan pada
masing-masing dari 4 peristiwa terkait adalah sama seperti yang digambarkan pada figur 18-1
dan 18-2. Sebaliknya kardinalitas antara peristiwa antara peristiwa mengeluarkan kas dan
peristiwa lain yang ia tautkan berbeda pada figur 4 jika dibandingkan dengan figur 18-2 dan 18-
3.

Alasan perbedaan ini berada pada semantik yang mendasari sifat hubungan antara entitas
yang digabungkan dan entitas lainnya. Contoh dari sebuah entitas sumber daya adalah biasanya
ia dikaitkan ke berbagai peristiwa. Sebagai contoh barang persediaan tertentu yang diangkut oleh
Fred’s dapat dihubungkan tidak hanya ke peristiwa menerima persediaan, ketika diperoleh dari
pemasok, tetapi juga ke peristiwa penjualan, ketika dijual ke pelanggan. Dengan kata lain, entitas
sumber daya ditautkan ke entitas peristiwa pada satu siklus bisnis dan ditautkan ke entitas
peristiwa pada siklus lainnya. Oleh karna kedua tautan tersebut mungkin, tidak satupun
kardinalitas pada diagram REA individual perlu diubah.

Situasi tersebut berbeda ketika dalam penggabungan sebuah peristiwa diantara siklus
bisnis. Peristiwa yang muncul pada kedua diagram REA siklus bisnis individual mungkin
dihubungkan kesalah satu peristiwa yang merupakan bagian dari satu siklus bisnis ataupun
kesebuah peristiwa yang merupakan bagian dari siklus lain, tetapi tidak dapat ditautkan kedua
peristiwa tersebut. sebagai contoh, pada figur 18-4, peristiwa mengeluarkan kas tertentu
( misalnya sebuah cek atau transaksi EFT tertentu) dapat diasosiasikan dengan penerimaan
persediaan sebelumnya dari seorang pemasok atau dengan waktu pengerjaan oleh seorang
pegawai, tetapi cek yang sama ( atau transaksi EFT ) tidak dapat digunakan baik itu untuk
membayar seorang pemasok untuk penerimaan persediaan maupun untuk membayar seorang

8
pegawai atas upah kerja minggu sebelumnya. Akibatnya, kardinalitas minimum yang
diasosiasikan pada peristiwa lain harus diasosiasikan dengan setidaknya 1 contoh entitas lain.
dalam hal pengeluaran kas (pencairan kas) pada figur 18-4, sebagai contoh, penggajian minimum
1 untuk peristiwa waktu pengerjaan akan berarti bahwa setiap mengeluarkan kas harus ditautkan
kesebuah peristiwa waktu pengerjaan—yang secara jelas tidak benar, karna fred mungkin
melakukan pengeluaran kas untuk membayar seorang pemasok. Untuk alasan yang serupa,
kardinalitas minimum dari peristiwa mengeluarkan kas ke peristiwa menerima persediaan juga
harus 0.

Penggabungan dua siklus transaksi pada sebuah peristiwa umum mungkin juga
memengaruhi kardinalitas minimum antara peristiwa yang digabungkan dan agen yang
berpartisipasi dalam peristiwa tersebut. sebagai contoh dalam figur 18-4 kardinalitas minimum
antara peristiwa mengeluarkan kas dan entitas pemasok sekarang adalah 0; bukannya 1, seperti
kardinalitas pada figur 18-2. Alasannya adalah bahwa sebuah cek tertentu (pengeluaran kas)
mungkin dituliskan salah satunya ke seorang pemasok sebagai terbayar atau ke seorang pegawai
sebagai terbayar, tetapi cek yang sama tidak dapat ditulis kedua agen secara bersamaan. Itulah
mengapa kardinalitas miinimum antara peristiwa mengeluarkan kas dan agen pegawai (terbayar)
juga 0, oleh karna itu kapanpun sebuah peristiwa yang digabungkan melibbatkan agen yang
berbeda dalam setiap siklus busnis individual yang digabungkan, kardinalitas minimum antara
peristiwa tersebut dan agen-agen itu berubah dari yang biasanya 1 menjadi 0, karna peristiwa
tersebut mungkin sekarang ditautkan salah satu dari dua jenis agen tersebut, tetapi tidak
keduanya.

MEMVALIDASI KETEPATAN DIAGRAM REA TERINTEGRASI

Tergambar secara tepat bahwa diagram REA terintegrasi harus memenuhi enam aturan ini.

1. Setiap peristiwa harus ditautkan setidaknya ke satu sumber daya

2. Setiap peristiwa harus ditautkan ke dua agen yang berpartisipasi dalam peristiwa tersebut.
3. Setiap peristiwa harus melibatkan pelepasan sumber daya yang harus ditautkan kesebuah
peristiwa yang melibatkan perolehan sumber daya.

9
 4. Setiap sumber daya setidaknya ditautkan ke satu peristiwa lainnya, tetapi tidak dapat
ditautkan secara bersamaan keseluruh peristiwa lain tersebut.
5. Sebuah peristiwa dapat ditautkan kesalah satu dari sekelompok agen, tetapi tidak dapat
ditautkan secara bersamaan keseluruh peristiwa lain tersebut, kemudian diagram REA
harus menunjukkan bahwa peristiwa A ditautkan keminimum 0 atas masing-masing dari
peristiwa lain tersebut.
6. Sebuah peristiwa dapat ditautkan kesalah satu dari sekelompok agen, tetapi tidak dapat
ditautkan secara bersamaan keseluruh agen, kemudian diagram REA harus menunjukkan
bahwa peristiwa tersebut diautkan keminimum 0 atas masing-masing dari peristiwa
tersebut.

Enam aturan tersebut dapat digunakan tidak hanya untuk mengembangkan sebuah
diagram REA terintegrasi, tetapi juga sebagai gambar cek untuk memvalidasi ketepatan dari
sebuah diagram REA yang terlengkapi. Secata teknis figur 18-4 tidak lengkap karna aturan 4
tidak terpenuhi untuk sumber daya waktu pegawai.

C. MENGIMPLEMENTASI DIAGRAM REA DALAM DATABASE RELASIONAL

Ada tiga langkah untuk mengimplementasikan diagram REA pada database

relasional, sebagai berikut:

1. Buatlah sebuah table untuk masing-masing entitas yang berbeda dalam diagram tersebut
dan untuk setiap hubungan banyak-ke-banyak (many-to-many);
2. Tentukan atribut table yang sesuai; dan
3. Gunakan kunci asing untuk mengimplementasikan hubungan satu-ke-satu (one-to-one) dan
satu-ke-banyak (one-to-many).

TABEL: 18-1 Nama Tabel dan Penempatan Atribut untuk Figur 18-4

Tabel Kunci Utama Kunci Asing Atribut Lain

Memesan persediaan Nomor pesanan Nomor pemasok, nomor Tanggal, waktu,
pembelian pegawai alasan
Menerima persediaan Nomor laporan Nomor pemasok, nomor Tanggal, waktu,
penerimaan pegawai, nomor pesanan keterangan, nomor

10
 pembelian, nomor cek faktur vendor
Mengeluarkan kas Nomor cek Nomor pemasok, nomor Jumlah, deskripsi,
pegawai (terbayar), tanggal
nomor pegawai
(penandatangan), nomor
rekening
Mengambil pesanan Nomor pesanan Nomor pelanggan, Tanggal, waktu,
pelanggan penjualan nomor pegawai keterangan khusus
Penjualan Nomor faktur Nomor pelanggan, Tanggal, waktu,
nomor pegawai, nomor faktur dikirim
pesanan penjualan
Menerima kas Nomor Nomor pelanggan, Tanggal, waktu,
pengiriman uang nomor pegawai metode pembayaran
Waktu pengerjaan Nomor kartu Nomor pegawai, Tanggal, jam
waktu supervisor, nomor cek masuk, jam keluar
gaji deskripsi, harga
daftar, biaya
standar, kuantitas
awal ditangan,
kuantitas
keterpersediaan
awal, kuantitas
pemesanan ulang,
angka pemesanan
ulang
Kas Nomor rekening - Saldo awal, jenis
rekening
Pegawai Nomor pegawai - Nama, tanggal
dipekerjakan,
tanggal lahir, tingkat
bayaran, jabatan
Pelanggan Nomor pelanggan - Nama, alamat, saldo
rekening awal, batas
kredit

11
Pemasok Nomor pemasok - Nama, alamat, saldo
rekening awal,
peringkat kinerja
Memesan persediaan- Nomor pesanan - Kuantitas yang
persediaan pembelian, nomor dipesan, biaya unit
produk actual
Menerima persediaan- Nomor laporan - Kuantitas yang
persediaan penerima, nomor diterima, kondisi
produk
Mengambil pesanan Nomor pesanan - Kuantitas yang
pelanggan-persediaan penjualan, nomor dipesan
produk
Penjualan-persediaan Nomor faktur, - Kuantitas yang
nomor produk dijual, harga jual
actual
Penjualan-menerima Nomor faktur, - Jumlah yang
kas nomor diterapkan ke faktur
pengiriman uang

Ingat bahwa meskipun diagram REA untuk organisasi yang berbeda mungkin menyertakan
entitas yang sama, perbedaan dalam kebijakan bisnis kemungkinan akan menghasilkan
perbedaan dalam kardinalitas hubungan. Sebagai contoh, diagram REA untuk suatu organisasi
lain mungkin menunjukkan sebuah hubungan 1:1 antara peristiwa Penjualan dan Menerima Kas,
sementara diagram REA untuk organisasi lain mungkin memiliki model pasangan peristiwa
sama seperti yang dilibatkan dalam sebuah hubungan M:N. Oleh karenanya, desain sebuah
database (jumlah tabel, penempatan atribut) adalah spesifik bagi organisasi yang sedang
dimodelkan.

12
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. Figur 18-4 memiliki 13 entitas yang berbeda, tetapi seperti yang sebelumnya
dibahas, satu Waktu Pegawai, tidak akan diimplementasikan dalam database tersebut. Dua belas
entitas berbeda sisanya yang digambarkan pada Figur 18-4 perlu diimplementasikan sebagai
tabel database relasional. Tujuh tabel akan mempresentasikan entitas peristiwa: Memesan
Persediaan, Menerima Persediaan, Mengeluarkan Kas, Waktu Pengerjaan, Mengambil Pesanan
Pelanggan, Penjualan, dan Menerima Kas. Ada dua tabel untuk entitas sumber daya: Persediaan
dan Kas. Tiga tabel dibutuhkan untuk mengimplementasikan entitas agen yang berbeda:
Pegawai, Pelanggan, dan Pemasok (supervisor dilabelkan secara terpisah agar diagram lebih
mudah dibaca, tetapi dirinya sendiri juga merupakan bagian dari pegawai).

Figur 18-4 juga menggambarkan lima hubungan M:N. Tiga dari siklus pendapatan:
Mengambil Pesanan Pelanggan-Persediaan, Penjualan-Persediaan, dan Penjualan-Menerima Kas.
Dua lainnya dari siklus pengeluaran: Persediaan-Memesan Persediaan dan Persediaan-Menerima
Persediaan. Oleh karena itu, 17 tabel yang dicantumkan dalam Tabel 18-1 harus dibuat agar
secara akurat mengimplementasikan Figur 18-4 dalam sebuah database relasional. Perhatikan
bahwa nama tabel yang disarankan pada Tabel 18-1 berkaitan dengan nama entitas pada diagram
REA atau pada kasus tabel hubungan M:N, mereka merupakan rangkaian yang ditulis dengan
tanda hubung atas entitas-entitas yang dilibatkan dalam hubungan tersebut. Hal tersebut
mempermudahkan untuk memverifikasi bahwa seluruh tabel yang diperlukan telah dibuat dan
juga mempermudah untuk menggunakan diagram REA sebagai panduan ketika menjalankan
query database.

LANGKAH 2: MENENTUKAN ATRIBUT UNTUK SETIAP TABEL

Untuk menentukan atribut mana yang harus disertakan dalam tiap tabel perancang database
perlu mewawancarai para pengguna dan manajemen untuk mengidentifikasi fakta yang perlu
disertakan dalam database tersebut. Perancang database harus menggunakan diagram REA

13
untuk membantu menentukan tabel yang digunakan untuk menuliskan fakta-fakta tersebut,
bergantung pada apakah fakta tersebut merupakan kunci utama atau hanya atribut deskriptif.

Mengindentifikasi Kunci Utama, setiap tabel dalam sebuah database relasional memiliki
sebuah kunci utama, terdiri atas atribut atau kombinasi atribut yang secara untuk
mengidentifikasi tiap baris dalam tabel tersebut. Perusahaan sering membuat pengidentifikasi
numerik terhadap sumber daya, peristiwa, dana gen tertentu. Pengidentifikasi numerik ini
merupakan kandidat yang baik bagi kjunci utama. Sebagai contoh, Tabel 18-1 menunjukkan
bahwa Fred’s Train Shop menggunakan nomor faktur sebagai kunci utama tabel penjualan dan
nomor pelanggan sebagai kunci utama tabel pelanggan.

Biasanya, kunci utama sebuah tabel yang mempresentasikan sebuah entitas merupakan
atribut tanggal. Namun, kunci utama untuk tabel hubungan M:N selalu terdiri atas dua atribut
yang mempresentasikan kunci utama setiap entitas yang ditautkan dalam hubungan tersebut.
Sebagai contoh, 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, atribut tambahan selain kunci utama
disertakan dalam setiap tabel untuk memenuhi ketentuan pemrosesan transaksi dan kebutuhan
informasi manajemen. Atribut lain yang disertakan dalam sebuah tabel database rasional harus
berupa fakta mengenai objek yang direpresentasikan oleh kunci utama atau kunci asing. Oleh
karena itu. Informasi mengenai para pelanggan, seperti nama dan alamat mereka, terletak pada
tabel Pelanggan karena atribut tersebut menjelaskan objek yang direpresentasikan oleh kunci
utama (nomor pelanggan) dari tabel Pelanggan, aribut tersebut bukan milik tabel Penjualan
karena atribut tersebut tidak menjelaskan beberapa properti objek yang direpresentasikan oleh
kunci utama tabel tersebut (nomor faktur).

Tebel 18-1 menunjukkan beberapa atribut yang telah ditentukan Paul Stone ke berbagai
tabel yang telah ia buat untuk mengimplementasikan Figur 18-4 dalam sebuah database
relasional. Beberapa dari 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 sumber daya, peristiwa, dan agen organisasi.

14
Sebagai contoh, Fred dapat menggunakan data mengenai tanggal tiap transaksi penjualan terjadi
untuk mendesain jadwal kerja staf.

Tabel 18-1 juga menyertakan atribut-atribut lain dalam beberapa tabel hubungan M:N.
Mari kita periksa penempatan atribut-atribut tersebut dalam beberapa tabel M:N untuk
memahami mengapa mereka harus disimpan dalam tabel-tabel tertentu. Pahamilah terlebih
dahulu tabel Penjualan, Menerima Kas. Ingat bahwa Fred’s Train Shop mengizinkan
pelanggannya untuk melakukan berbagai pembelian dengan kredit dan melakukan pembayaran
cicilan dengan sisa saldo mereka. Oleh karena itu, suatu 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 satu entri untuk setiap pembayaran cicilan terkait dengan penjualan 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 ia milik tabel M:N yang menghubungkan dua peristiwa tersebut.

Sekarang, mari periksa tabel Penjualan-Persediaan. Setiap baris dalam tabel ini
mengandung informasi tentang lini baris pada faktur. Meskipun banyak pelanggan Fred’s Train
Shop hanya membeli satu dari setiap jenis produk yang ia jual, beberapa penjualan ke para
pelanggan menghasilkan kuantitas yang lebih besar. Sebagai contoh, sebuah toko serba ada
mugkin membeli lima coal car (nomor produk 31125) yang identik untuk tampilan luarnya.
Akibatnya, Fred’s Train Shop harus mencatat kuantitas yang terjual atas setiap barang. Namun,
setiap peristiwa penjualan mungkin menyertakan lebih dari satu barang persediaan. Oleh karena
itu, 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 diassosiasikan dengan sebuah nomor faktur

15
tertentu. Selain itu, ingat bahwa Fred’s Train Shop, seperti kebanyakan toko eceran, ia melacak
persediaan berdasarkan jenis barang, masing-masing diidentifikasikan dengan nomor produk,
bukan dengan identifikasi spesifik. Oleh karena itu, sebuah barang tertentu, seperti lokomotif
diesel oranye dengan nomor produk 14887, mungkin terjual sebagai bagian dari berbagai
transaksi penjualan yang berbeda. Akibatnya, “kuantitas terjual” tidak dapat menjadi atribut pada
tabel Persediaan karena ia dapat memiliki nilai multipel. Analisis sebelumnya juga memperjelas
bahwa atribut “kuantitas terjual” berkaitan dengan nomor produk spesifik pada sebuah faktur
penjualan spesifik pula. Oleh karenanya, ia milik tabel hubungan M:N yang menghubungkan
entitas persediaan dan penjualan.

Data Harga dan Biaya, pada Tabel 18-1 perhatikanlah bahwa informasi mengenai harga dan
biaya disimpan sebagai atribut pada beberapa tabel berbeda. Sebagai contoh, tabel Persediaan
menyimpan daftar harga yang disarankan untuk barang tersebut, yaitu secara umum tetap
konstan pada satu periode fiskal tertentu. Tabel Penjualan menyimpan harga penjualan aktual,
yang bervariasi selama tahun tersebut, hal tersebut sebagai hasil promosi penjualan. Begitu pula
dengan biaya pembelian standar dan aktual atas setiap barang yang juga disimpan dalam tabel
yang berbeda. Peranan umumnya adalah bahwa data time-independent harus disimpan sebagai
atribut sumber daya atau agen, sedangkan data varies across time harus disimpan dengan entitas
peristiwa atau hubungan M:N yang menautkan sebuah sumber daya dan sebuah peristiwa.

Data Kumulatif dan Data Dapat Dihitung, perhatikanlah bahwa 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. Alasannya adalah tak satu
pun dari jenis item data tersebut diperlukan karena nilainya dapat diperoleh dari atribut lain yang
disimpan. Sebagai contoh, kuantitas di tangan untuk sebuah barang persediaan tertentu, sama
dengan kuantitas di tangan pada awal periode fiskal terkini (sebuah atribut tabel Persediaan)
ditambah kuantitas total yang dibeli pada periode saat ini (yang dihitung sendiri dengan
menjumlahkan atribut kuantitas yang diterima dalam tabel Persediaan-Menerima Persediaan)
dikurangi kuantitas terjual total (yang dihitung dengan menjumlahkan atribut kuantitas terjual
pada tabel Penjualan-Persediaan) pada periode saat ini. Sama halnya, jumlah total transaksi
penjualan dapat dihitung dengan mengalikan kuantitas terjual dengan harga jual aktual atas

16
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

Meskipun hubungan 1:1 dan 1:N juga dapat diimplementasikan sebagai tabel terpisah, biasanya
lebih efisien jika mengimplementasikan mereka dengan sarana kunci asing. Ingatlah bahwa
sebuah kunci asing adalah atribut sebuah entitas dan ia juga merupakan kunci utama entitas lain.
Sebagai contoh, atribut “nomor pelanggan” mungkin muncul baik di tabel Pelanggan dan
Penjualan. Ia akan menjadi kunci utama tabel Pelanggan, tetapi kunci asing di tabel Penjualan.

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 mempresentasikan entitas
lain. Untuk tujuan mendesain database terstruktur dengan baik, pilihan jenis tabel untuk
menempatkan kunci asing dapat dipilih dengan sesuka hati. Namun, analisis cermat atas
kardinalitas minimum hubungan tersebut mungkin membutuhkan jenis pendekatan yang
cenderung lebih efisien.

Kardinalitas minimum untuk peristiwa Menerima Kas adalah 0, mengindikasikan adanya

penjualan kredit, dan kardinalitas minimum untuk peristiwa Penjualan adalah 1,
mengindikasikan bahwa pembayaran pelanggan hanya terjadi setelah penjualan terlaksana
(misalnya, tidak ada setoran di muka). Dalam kasus tersebut, menyertakan nomor faktur (kunci
utama peristiwa penjualan) sebagai kunci asing pada peristiwa 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 peristiwa berurutan,
memasukkan kunci utama dari peristiwa yang terjadi pertama kali sebagai kunci asing untuk
peristiwa yang terjadi selanjutnya, mungkin akan meningkatkan pengendalian internal karena
pegawai diberikan akses untuk memperbarui tabel berisi data terkait peristiwa kedua yang tidak
memerlukan akses terhadap tabel yang digunakan untuk menyimpan informasi terkait peristiwa

17
pertama. Meski 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, seperti halnya

hubungan 1:1, hubungan 1:N juga harus diimplementasikan dalam database relasional dengan
menggunakan kunci asing. Hanya ada satu cara untuk melakukannya: Kunci utama entitas yang
dapat ditautkan ke berbagai entitas lain, harus menjadi sebuah kunci asing pada entitas lain
tersebut. Oleh karena itu, pada Tabel 18-1, kunci utama tabel Personal Penjualan dan Pelanggan
disertakan sebagai kunci asing pada tabel Penjualan. Begitu pula 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.
Sebagai contoh, menempatkan nomor faktur sebagai kunci asing pada tabel Pelanggan tidak akan
berhasil karena ia dapat memiliki lebih dari satu nilai (yaitu seorang pelanggan tertentu
kemungkinan dapat diasosiasikan dengan berbagai nomor faktur karena partisipasinya pada
banyak transaksi penjualan).

Mengapa hubungan M:N harus diimplementasikan dengan tabel terpisah? Selama

masing-masing entitas dapat ditautkan ke berbagai keterjadian entitas pada sisi lain hubungan,
tidak mungkin untuk membuat kunci utama entitas menjadi sebuah kunci asing pada suatu
entitas lain. Hubungan M:N antara peristiwa Penjualan dan sumber daya Persediaan. Setiap
peristiwa Penjualan mungkin ditautkan ke banyak barang persediaan yang berbeda. Oleh karena
itu, nomor produk tidak dapat digunakan sebagai kunci asing pada tabel Penjualan karena akan
memiliki banyak nilai. Sebaliknya, tiap produk mungkin dilibatkan dalam banyak transaksi
penjualan yang berbeda. Oleh karena itu, nomor faktur tidak dapat digunakan sebagai kunci
asing pada tabel Persediaan karena ini akan multinilai. Dengan demikian, 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. Perhatikan bahwa pada tabel M:N, sebuah nomor faktur tertentu (misalnya,
787923) akan muncul dalam banyak baris yang berbeda, satu untuk tiap barang berbeda yang
merupakan bagian dari transaksi penjualan. Sebaliknya, sebuah nomor produk tertentu
(misalnya, 12345) akan muncul dalam banyak baris yang berbeda, sekali untuk tiap transaksi
penjualan yang berbeda. Oleh karena itu, tidak ada atribut yang dengan sendirinya

18
mengidentifikasikan secara untuk sebuah baris tertentu. Meski demikian, hanya akan ada satu
baris yang memiliki kombinasi nomor faktur dan nomor produk tertentu (misalnya, nomor faktur
787923 dan nomor produk 12345), sehingga kedua atribut dapat berlaku sebagai kunci utama
untuk tabel M:N.

PENGECEKKAN KELENGKAPAN

Daftar atribut yang ingin disertakan oleh para pengguna dan manajemen ke dalam database 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.”

Pengecekkan daftar tertentu tersebut terhadap nama kolom tabel mungkin akan
mengungkap tidak hanya fakta bahwa atribut tertentu belum ditentukan ke tabel yang sesuai
dalam database, tetapi mungkin mengindikasikan kebutuhan untuk memodifikasi diagram REA
itu sendiri. Sebagai contoh, ketika Paul Stone mengecek-ganda daftra atribut yang dikehendaki,
ia menemukan bahwa ia tidak memiliki tabel untuk menempatkan atribut “produk yang
didiskusikan pada panggilan penjualan.” Dalam situasi semacam itu, perancang database perlu
menghubungi kembali para pengguna dan manajemen untuk memahami tujuan dalam
mengumpulkan atribut tertentu tersebut. Pada kasus ini, Fred menjelaskan bahwa ia berencana
menugaskan salah satu pegawainya untuk menghubungi pelanggan perusahaan untuk pengaturan
display sampel. Fred ingin mengumpulkan informasi mengenal demonstrasi tersebut untuk
mengevaluasi efektivitasnya.

Paul menyadari bahwa hal tersebut mengharuskannya untuk membuat entitas peristiwa
lainnya. Panggilan Pelanggan, yang akan ditautkan ke kedua tabel agen Pelanggan dan Pegawai,
tabel Persediaan, dan tabel Mengambil Pesanan Pelanggan. Kunci utama peristiwa ini mungkin
“appointment number.” Nomor pegawai 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. Oleh karena tiap demonstrasi dapat melibatkan
berbagai barang dan setiap barang dapat didemonstrasikan dalam berbagai hubungan, akan ada
sebuah tabel M:N antara peristiwa Panggilan Pelanggan dan tabel Persediaan. Rangkaian baris

19
dalam tabel tersebut dengan appointment number yang sama akan mengidentifikasi produk mana
yang ditunjukkan pada beberapa panggilan penjualan tertentu. Beberapa panggilan akan
menghasilkan pesanan, tetapi yang lain tidak. Selain itu, beberapa pesanan akan terjadi tanpa
adanya panggilan penjualan (misalnya, karena pelanggan melihat sebuah iklan). Oleh karena itu,
kardinalitas minimum adalah 0 untuk tiap sisi hubungan tersebut antara peristiwa Panggilan
Pelanggan dan Mengambil Pesanan Pelanggan. Kardinalitas maksimum pada tiap sisi hubungan
tersebut adalah 1 untuk menyederhanakan pelacakan efek dari panggilan penjualan tersebut.

Kebutuhan Paul untuk memodifikasi diagram REA-nya guna mengakomodasi fakta

tambahan, tidaklah biasa. Memang, ini biasanya berguna untuk membuat tabel-tabel dan
menentukan atribut ke tabel-tabel tersebut, bahkan sebelum menyelesaikan secara lengkap
sebuah diagram REA. Hal tersebut membantu mengklarifikasi secara tepa tapa yang
direpresentasikan tiap entitas yaitu hal yang sering kali dapat menyelesaikan dilemma terkait
kardinalitas yang tepat untuk berbagai hubungan. Perancang 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 sebuah atribut telah dimasukkan ke tabel-tabel ketentuan dasar untuk mendesain
database relasional yang terstruktur dengan baik yaitu dapat digunakan sebagai pengecekan
ketepatan akhir:

1. Setiap tabel harus memiliki sebuah kunci utama .

2. Atribut nonkunci lain pada setiap tabel harus berupa fakta tentang hal yang didesain oleh
kunci utama atau kunci asing serta digunakan untuk menautkan tabel tersebut ke tabel
lain.
3. Setiap atribut pada setiap tabel bernilai tunggal (yaitu setiap tabel merupakan flat file).

Perhatikan bagaimana set tabel-tabel yang berhubungan yang dicantumkan dalam Tabel 18-1,
memenuhi tiga ketentuan dasar di atas. Terlebih lagi, tabel tersebut juga berkaitan dengan Figur
18-4, sehingga merefleksikan kebijakan bisnis Fred’s Train Shop. 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.

20
D. MENGGUNAKAN DIAGRAM REA UNTUK MEMUAT INFORMASI
DARI SEBUAH DATABASE
Sejauh ini kita telah menunjukkan bagaimana menggunakan model data REA untuk memandu
desain sebuah sia yang akan secara efisien menyimpan informasi mengenai aktivitas bisnis
sebuah organisasi. Pada bagian ini, kita merujuk pada figur 18-4 dan tabel 18-1 untuk
menunjukkan cara penggunaan keseluruhan diagram rea untuk memfasilitasi pemuatan
informasi guna mengevaluasi kinerja.
Untuk mendesain SIA yang dapat berfungsi untuk Perusahaan, perancang database harus
mengembangkan diagram REA untuk siklus tambahan seperti informasi dan kemudian
memadukan diagram-diagram tersebut. Diagram REA digunakan sebagai dokumentasi
pelengkap, yang berguna untuk mendokumentasi pembentukan advanced SIA.
Diagram REA menyediakan dua informasi database SIA, yang tidak ditunjukkan oleh
bentuk dokumentasi lain.
Menyusun Diagram REA diperlukan informasi tentang: resource, event, agent dan
kebijaksanaan perusahaan. Informasi tersebut dapat diperoleh dengan mewawancarai pihak
manajemen. Karena aktivitas perencanaan, pengawasan, dan pengevaluasian yang ditangani
manajemen untuk setiap perusahaan berbeda. Untuk menggambarkan Diagram REA, kertas
dibagi tiga kolom, satu kolom untuk setiap entity. Gunakan kolom kiri untuk resource
(sumber daya) adalah hal-hal yang memiliki nilai eknomi bagi organisasi, kolom tengah untuk
event (kegiatan) yaitu berbagai aktivitas bisnis yang informasinya ingin dikumpulkan
perusahaan untuk tujuan perencanaan dan pengendalian, dan kolom kanan untuk agent
(pelaku) yaitu orang-orang dan organisasi yang terlibat dalam kegiatan yang informasinya
ingin didapatkan untuk tujuan perencanaan, pengendalian, dan evaluasi. Penggambaran event
sebaiknya diurutkan dari atas ke bawah berdasarkan urutan aktivitas.
Setelah Diagram REA selesai disusun, Diagram REA dapat digunakan untuk
merancang struktur database relasional yang baik. Struktur database relasional
yang baik memenuhi aturan normalisasi, sehingga tidak ditemukan masalah
anomaly update, insert, dan delete. Untuk mengimplementasikan diagram REA
kedalam database relasional. Informasi yang disajikan oleh diagram REA adalah
relationship antara data dan praktek bisnis perusahaan. Diagram REA secara tegas
menggambarkan relationship antara bermacam-macam data item yang disimpan

21
dalam database akuntansi. Cardinality diagram REA menyajikan informasi yang
berguna untuk menggambarkan prinsip dan kebijaksanaan perusahaan yang
dimodelkan. Menaksirkan dengan benar cardinality diagram REA membutuhkan
pemahaman secara tepat yang menunjukkan kejadian setiap entity. Setiap kejadian
dari entity agent menunjukkan orang atau organisasi tertentu. Hal yang sama setiap
kejadian suatu entity event menunjukkan aktivitas atau transaksi bisnis spesifik.

MEMBUAT JURNAL DAN BUKU BESAR

Kemungkinan dapat terjadi bahwa sejumlah elemen yang ditemukan dalam sia tradisional,
seperti jurnal, buku besar, dan informasi mengenai utang-piutang, hilang. Kita akan lihat
informasi semacam itu, meskipun tidak secara eksplisit direpresentasikan sebagai entitas
dalam sebuah diagram REA, ia dapat diperoleh melalui query yang sesuai. Query tersebut
hanya dibuat sekali dan kemudian disimpan serta dijalankan kembali kapanpun diinginkan.
Proses pembuatan jurnal merupakan proses transaksi keuangan suatu badan usaha yang
dicatat berdasarkan dokumen-dokumen pembukuan yang bertujuan untuk pendataan. Jurnal
dikenal juga sebagai buku pemasukan utama karena menjadi tempat terjadinya pencatatan
transaksi pertama atau penyesuaian pemasukan transaksi- transaksi. Jadi, jurnal
adalah suatu buku atau catatan transaksi-transaksi keuangan yang secara kronologis
dan sistematis digunakan dengan menuliskan akun yang harus didebit dan dikredit.
Dalam hal ini, artinya sumber pencatatan ke dalam jurnal adalah bukti, serta pencatatan
transaksi dilakukan secara berurutan sesuai tanggal terjadinya transaksi. Sistematis
artinya pencatatan yang dilakukan dengan mengikuti aturan mendebit dan mengkredit
akun. Selain itu, setiap transaksi dicatat secara berpasangan ke dalam debit dan kredit
(double entry accounting), dan jumlah debit dengan jumlah kredit harus sama/seimbang.
Semua transaksi bisnis akan dicatat dalam jurnal denganmenggunakan metode pembukuan
double-entry atau single-entry. Dan selanjutnya Laporan keuangan yang berperan sangat
penting bagi perkembangan sebuah bisnis. Dengan adanya laporan keuangan, kondisi
finansial perusahaan dapat dilihat  dan dipantau pada periode tertentu. Dari pantauan kondisi
finansial ini akan dapat dilakukan evaluasi, selanjutnya adalah pengambilan keputusan yang
berhubungan dengan strategis maupun operasional perusahaan. Laporan keuangan wajib
dibuat oleh perusahaan baik skala kecil maupun skala besar. 

22
 Buku Besar (General Ledger) merupakan salah satu bagian dari Siklus Akuntansi. Secara
teknis, Buku Besar adalah buku yang berisi kumpulan data transaksi historis yang termuat
di Jurnal Umum dan Jurnal Khusus. Salah satu laporan keuangan sederhana yang tidak boleh
dilupakan oleh seorang pemilik bisnis adalah buku besar. Buku besar adalah alat yang
digunakan untuk mencatat perubahan-perubahan yang terjadi pada suatu akun yang
disebabkan karena adanya transaksi keuangan. Buku ini berisi tentang perkiraan-perkiraan
yang mengikhtisarkan pengaruh adanya transaksi keuangan terhadap perubahan sejumlah
akun seperti aktiva, kewajiban dan modal perusahaan. Penting diingat bahwa banyaknya
jumlah perkiraan buku besar yang dibutuhkan/dicatat perusahaan berbeda-beda, karena
tergantung kepada kekayaan dan keuangan perusahaan, jenis kegiatan, volume transaksi dan
informasi yang diinginkan perusahaan. Data dalam buku besar akuntansi belum terperinci
karena akun pada buku besar terkadang tidak mencerminkan data secara rinci, seperti
rekening utang, piutang, dan persediaan barang dagang. Untuk melihat rekening-rekening
tersebut diperlukan rekening lain yang dikelompokkan dalam suatu buku atau kumpulan
kartu-kartu yang disebut buku besar pembantu atau subsidiary ledger. Dengan begitu maka
ada buku besar pembantu utang, buku besar pembantu piutang, dan buku besar pembantu
barang dagang. Jumlah perkiraan buku besar yang dibutuhkan oleh perusahaan tentu saja
berbeda-beda. Hal ini disebabkan karena beberapa faktor yang meliputi jenis kegiatan,
keuangan dan kekayaan perusahaan, informasi yang diperlukan perusahaan, serta volume
transaksi.
Dalam buku besar, akun-akunnya digolongkan dalam akun ril atau real account dan
juga nominal account atau akun nominal. Akun ril merupakan akun yang ada pada neraca
seperti hutang, aktiva, modal, dan kewajiban. Sedangkan akun nominal merupakan akun yang
ada pada laporan laba rugi seperti akun beban dan pendapatan. Buku Besar menampilkan
riwayat transaksi dan saldo keuangan pada suatu periode akuntansi. Pada akhir periode, Buku
Besar berfungsi sebagai sumber data untuk membuat Laporan Keuangan perusahaan. Dalam
sebuah perusahaan harus memiliki buku besar, karena fungsinya sangat penting. Buku besar
berfungsi untuk meringkas semua data transaksi yang sudah tertulis di dalam jurnal umum.
Selain itu digunakan sebagai alat yang menggolongkan data keuangan, dari yang jumlahnya
besar sampai kecil. Jadi Anda tahu ada perbedaan atau tidak dari semua data keuangan yang
masuk. Semua data yang sudah ditulis di jurnal, harus dicatat atau digolongkan lagi dalam

23
 buku besar untuk menyeimbangkan jumlah akun yang ada di kolom debit dan kredit dan juga
sebagai bahan informasi ketika menyusun laporan keuangan. Bisa dikatakan buku besar
memiliki fungsi yang sangat krusial dalam penyusunan laporan keuangan perusahaan. 
Fungsi utama buku besar dan pelaporan adalah untuk mengumpulkan dan mengatur data
dari sumber-sumber sebagai berikut.
1. Menyediakan informasi mengenai transaksi reguler. (Hanya arus data utama dari setiap
subsistem yang digambarkan, untuk menjaga agar figur menjadi rapi).
2. Bendahara menyediakan informasi mengenai aktivitas pendanaan dan investasi, seperti
penerbitan atau penyelesaian instrumen utang dan ekuitas dan pembelian serta penjualan
sekuritas investasi.
3. Departemen anggaran menyediakan nomor anggaran.
4. Kontrolir menyediakan jurnal penyesuaian.

Berikut ini menunjukkan jenis model suatu buku besar dari pelaporan online:

24
Database terpusat harus diatur menggunakan cara yang memungkinkan tercapainya berbagai
kebutuhan informasi, baik pengguna internal maupun eksternal. Para manajer membutuhkan
informasi yang detail dan tepat waktu mengenai hasil operasi pada area tanggung jawab
tertentunya. Para investor dan kreditur mengharapkan laporan keuangan periodik dan pembaruan
tepat waktu untuk membantu mereka dalam menilai kinerja organisasi. Berbagai badan
pemerintah juga meminta persyaratan informasi yang spesifik. Untuk memenuhi berbagai
kebutuhan ini, sistem buku besar dan pelaporan tidak hanya menghasilkan laporan periodik,
tetapi juga mendukung pertanyaan secara online.

Permintaan data dapat digunakan untuk menghasilkan jurnal dan buku besar serta menyiapkan
laporan manajerial dan menghasilkan informasi laporan keuangan lainnya dari database
relasional yang dibuat dengan menggunakan model REA.

Operasi pemrosesan informasi yang dilibatkan dalam memperbarui buku besar dan menyiapkan
laporan yang merangkun hasil dari aktivitas sebuah organisasi.

Berikut diagram konteks sistem buku besar dan pelaporan :

25
Berikut menunjukkan diagram arus data level 0 siklus buku besar dan pelaporan :

Seluruh akivitas buku besar dan pelaporan bergantung pada database terintegrasi. Ancaman
utama adalah data buku besar yang tidak tepat atau tidak valid. Hal ini dapat menyebabkan para
manajer membuat keputusan yang keliru. Untuk menanggulangi ancaman atas data buku besar
yang tidak tepat atau tidak valid adalah menggunakan berbagai pengendalian integritas
pemrosesan untuk meminimalkan risiko kesalahan input data ketika bendahara dan kontrolir
membuat entri jurnal langsung. Ancaman umum kedua dalam sistem buku besar dan pelaporan
adalah pengungkapan informasi keuangan yang tidak diotorisasi. Ancaman umum ketiga dalam
siklus buku besar umum dan pelaporan berkaitan dengan hilangnya atau penghancuran data
indur.

26
Pada pandangan pertama, mungkin tampak bahwa sejumlah elemen yang ditemukan dalam SIA
tradisional, seperti jurnal, buku besar, dan informasi tentang piutang dan hutang, hilang. Kita
akan melihat bahwa informasi tersebut, meskipun tidak secara eksplisit direpresentasikan sebagai
entitas dalam Diagram REA, dapat diperoleh melalui permintaan appropriate. Pertanyaan-
pertanyaan ini hanya perlu dibuat sekali dan kemudian dapat disimpan dan jalankan kembali
kapan pun diinginkan.

Permintaan data (queries) dapat digunakan untuk menghasilkan jurnal dan buku besar dari
database relasional yang dibuat dengan menggunakan model REA.informasi biasanya ditemukan
dalam jurnal yang disimpan dalam table-tabel yang digunakan untuk mencatat data mengenai
kegiatan.

Jurnal memberikan daftar transaksi secara kronologis. Dalam basis data relasional yang
dirancang sesuai dengan model data REA, entitas yang cerdas menyimpan informasi tentang
transaksi. Dengan demikian, informasi yang biasanya ditemukan dalam sebuah jurnal terkandung
dalam tabel yang digunakan untuk merekam data tentang mata-mata.

Contohnya, jurnal penjualan dapat dihasilkan dengan cara menulis permintaan (query) yang
menampillkan entri (entry) yang sesuai dalam tabel penjualan selama periode tertentu.
Permintaan dapat ditulis untuk menampilkan setiap entri dalam tabel penjualan, menghasilkan
daftar semua kegiatan penjualan, baik yang penjualan secara kredit maupun secara tunai.

27
Akan tetapi, secara tradisional, jurnal penjualan digunakan untuk mencatat semua penjualan
secara kredit. Oleh sebab itu, permintaan untuk menghasilkan jurnal penjualan secara kredit akan
harus mencakup tabel penerimaan penjualan dan tunai (kas). Logika dari permintaan akan
rnencakup pembatasan hasil sehingga hanya menampilkan penjualan yang tidak berhubungan
dengan kegiatan pembayaran pelanggan yang terjadi pada hari yang sama dengan penjualan.
Proses yang sama dapat diikuti untuk menghasilkan jurnal kegiatan seperti pembelian atau
pernbayaran.

MENGHASILKAN JURNAL DARI QUERY

Jurnal menyediakan sebuah daftar kronologis transaksi. Pada sebuah database relasional yang
didesain Berdasarkan model data REA, entitas peristiwa yang menyimpan informasi mengenai
transaksi. Oleh karena itu, informasi yang normalnya ditemukan dalam sebuah jurnal, ia
terkadang dalam tabel yang digunakan untuk mencatat data mengenai peristiwa. Sebagai contoh,
tabel penjualan dan penjualan-persediaan mengandung informasi tentang sebuah transaksi
penjualan tertentu. Maka, sebuah jurnal penjualan dapat dihasilkan dengan menuliskan sebuah
query yang merujuk pada kedua tabel untuk menghitung jumlah penjualan yang dibuat dalam
suatu periode tertentu.

Namun, melakukan prosedur tersebut tidak mengharuskan membuat jurnal penjualan tradisional
karena tindakan tersebut akan menghasilkan daftar seluruh transaksi penjualan, termasuk
penjualan kredit dan tunai. Meskipun demikian, secara tradisional, jurnal penjualan mencatat
hanya penjualan kredit. Pada sebuah database relasional yang dibangun dalam model REA.
Salah satunya seperti Figur 18-4, pembayaran pelanggan dicatat dalam tabel peristiwa Menerima
Kas. Akibatnya sebuah query untuk menghasilkan sebuah jurnal penjualan tradisional (yaitu
hanya pendataan penjualan yang dibuat secara kredit) juga harus menyertakan baik tabel
Menerima Kas maupun Penjualan-Menerima Kas. Sebuah database yang dibangun pada model
REA akan menghasilkan baris pada tabel Penjualan untuk tiap penjualan barang ke pelanggan
dan baris pada tabel Menerima Kas untuk mencatat penerimaan pembayaran dari seorang
pelanggan. Untuk penjualan tunai, kedua baris akan memiliki nilai yang sama pada kolom data
dan nomor pelanggannya. Oleh karena itu, kelogisan dari sebuah query untuk menghasilkan
sebuah jurnal penjualan tradisional akan membatasi output untuk menampilkan hanya penjualan

28
yang tidak ditempatkan ke peristiwa pembayaran pelanggan terkait (dengan kata lain, nomor
pelanggan yang sama muncul dalam kedua tabel dan jumlah peristiwa menerima kas sama
dengan jumlah penjualan) yang terjadi pada hari yang sama dengan peristiwa penjualan. (Baris
pada tabel menerima kas dengan tanggal yang lebih lama dibandingkan tanggal transaksi
penjualan terkait mempresentasikan pembayaran pada penjualan kredit.) Proses yang serupa
dapat diikuti guna menuliskan query untuk menghasilkan jurnal khusus lainnya, seperti
keseluruhan pembelian kredit atau keseluruhan pengeluaran kas yang tidak terkait dengan
penggajian.

Buku besar adalah file induk yang mengandung informasi komulatif mengenai akun-akun
tertentu. Dalam sebuah database relasional yang didesain berdasarkan model data REA, entitas
sumber daya mengandung informasi permanen yang termuat dari 1 tahun fiskal ke tahun
berikutnya. Oleh karena itu, banyak informasi mengenai aset sebuah organisasi yang biasanya
dicatat dalam buku besar yang disimpan dalam tabel sumber daya pada sebuah database
relasional yang merujuk pada REA. Sebagai contoh, setiap baris pada tabel sumber daya
perlengkapan akan mengandung informasi tentang bagian perangkat atau kelompok mesin
tertentu, seperti biaya perolehan, masa manfaat, metode depresiasi, dan nilai sisa estimasian.
Begitu pula dengan setiap baris dalam sumber daya kas yang mengandung informasi mengenai
sebuah akun tertentu yang menyimpan kas dan yang memiliki nilai yang sama dengan kas
organisasi tersebut, dan setiap baris dalam tabel sumber daya perlengkapan menyimpan
informasi mengenai barang persediaan tertentu.

Masing-masing akun sumber daya ini dipengaruhi oleh peristiwa yang menaikkan dan
menurunkan: perlengkapan dibeli dan digunakan; kas diterima dan dikeluarkan; persediaan dibeli
dan dijual. Oleh karena itu query untuk menampilkan saldo komulatif terkini untuk akun-akun
ini harus merujuk tidak hanya pada tabel yang sesuai bagi entitas sumber daya tersebut, tetapi
juga tabel peristiwa yang mempengaruhinya. Sebagai contoh, sebuah query untuk menampilkan
saldo terkini pada rekening bank tertentu akan merujuk tidak hanya tabel sumber daya kas, untuk
mengidentifikasikan nomor rekening dan saldo awal periode fiskal tertentu, tetapi juga tabel
menerima kas dan mengeluarkan kas, untuk menemukan aliran masuk dan aliran keluar yang
mempengaruhi rekening tersebut selama periode fiskal terkini.

29
MENGHASILKAN LAPORAN KEUANGAN

Sebuah diagram REA yang lengkap dapat juga digunakan sebagai panduan penulisan query
untuk menghasilkan informasi yang akan dimasukkan dalam laporan keuangan. Banyak akun-
akun laporan keuangan seperti kas persediaan dan aset tetap direpresentasikan sebagai sumber
daya dalam model REA. Meski demikian, sebuah pengecualian pentingnya adalah klaim: Figur
18-4 tidak menyertakan sebuah entitas yang disebut piutang maupun utang. Seperti yang
dijelaskan pada bab 17, alasannya yaitu kedua Akun tersebut semata-mata mempresentasikan
sebuah ketidakseimbangan antara dua peristiwa terkait piutang mempresentasikan taksasi
penjualan di mana pembayaran pelanggan belum diterima dan merepresentasikan transaksi
penjualan di mana pembayaran pelanggan belum diterima dan utang mempresentasikan
pembelian dari para pemasok yang belum dibayarkan. Oleh karena itu, tidak satupun dari piutang
maupun utang yang perlu secara eksplisit disimpan sebagai tabel terpisah dalam sebuah database
REA. Klaim tersebut bahkan dapat dihasilkan dari pengaturan query terhadap tabel agen dan
peristiwa yang relevan. Sebagai contoh, tiga query dapat digunakan untuk menghitung piutang
total. 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 serupa akan menghasilkan utang total.

Laporan keuangan adalah untuk menyediakan informasi keuangan mengenai suatu badan usaha
yang akan dipergunakan oleh pihak-pihak yang berkepentingan sebagai bahan pertimbangan di
dalam pengambilan keputusan-keputusan ekonomi. Laporan keuangan bagi pihak manajemen
perusahaan berfungsi sebagai laporan pertanggung jawaban keuangan pada pemilik modal. Bagi
pemilik modal, laporan keuangan berfungsi untuk megevaluasi kinerja manajer perusahaan
selama satu periode. Dengan adanya laporan keuangan ini, manajer perusahaan akan bekerja
semaksimal mungkin agar kinerjanya dinilai baik.

30
Pada akhir periode, perusahaan akan membuat laporan keuangan. Akhir periode bisa tiap akhir
bulan atau tiap akhir tahun. Laporan keuangan untuk disampaikan kepada pihak luar perusahaan
umumnya dibuat tiap akhir tahun.

Pihak luar perusahaan antara lain:

a) Investor
b) Karyawan
c) Pemberi Pinjaman
d) Pemasok dan Kreditor usaha lainnya
e) Pelanggan
f) Pemerintah
g) Masyarakat

Laporan keuangan memuat informasi yang bersifat keuangan seperti jumlah aktiva, jumlah
kewajiban, jumlah modal, jumlah pendapatan, jumlah biaya dan arus kas. Informasi yang bersifat
keuangan diambil dari ringkasan transaksi yang terjadi selama satu periode.

Tujuan laporan keuangan digolongkan sebagai berikut :

1. Tujuan khusus
Tujuan khusus dari laporan keuangan adalah menyajikan laporan posisi keuangan, hasil
usaha dan perubahan posisi keuangan lainnya secara wajar dan sesuai dengan GAAP.
2. Tujuan umum
Adapun tujuan umum dari laporan keuangan disebutkan sebagai berikut :
 Memberikan informasi yang terpercaya tentang sumber-sumber ekonomi dan
kewajiban perusahaan.
 Memberikan informasi yang terpercaya tentang sumber kekayaan bersih yang
berasal dari kegiatan usaha dalam mencari laba.
 Memberikan informasi keuangan yang dapat digunakan untuk menaksir potensi
perusahaan dalam menghasilkan laba.
 Memeberikan informasi yang diperlukan lainnya tentang perubahan harta dan
kewajiban.
 Mengungkapkan informasi relevan lainnya yang dibutuhkan para pemakai laporan.

31
 3. Tujuan kualitatif
Adapun tujuan kualitatif yang dirumuskan APB Statements No. 4 adalah sebagai berikut :
 Relevance yaitu memilih informasi yang benar-benar dapat membantu pemakai
laporan dalam proses pengambilan keputusan.
 Understandability yaitu informasi yang dipilih untuk disajikan bukan saja yang
penting tetapi juga harus informasi yang dimengerti para pemakainya.
 Verifiability hasil akuntansi itu harus dapat diperiksa oleh pihak lain yang akan
menghasilkan pendapat yang sama. Dengan kata lain ukurannya harus ada.
 Neutrality yaitu laporan akuntansi itu netral terhadap pihak-pihak yang
berkepentingan. Informasi dimaksudkan untuk pihak umum bukan pihak-pihak
tertentu saja.
 Timeliness yaitu laporan akuntansi hanya bermanfaat untuk pengambilan keputusan
apabila diserahkan pada saat yang tepat.
 Comparability yaitu informasi akuntansi harus dapat saling dibandingkan artinya
akuntansi harus memiliki prinsip yang sama baik untuk suatu perusahaan maupun
perusahaan lain.
 Completeness yaitu informasi akuntansi yang dilaporkan harus mencakup semua
kebutuhan yang layak dari para pemakai.

Jenis Laporan Keuangan

Setelah transaksi yang terjadi didalam perusahaan dicatat dalam persamaan dasar akuntansi,
kemudian ringkasan transaksi tersebut dilaporkan kepada pihak luar perusahaan yang
memerlukannya. Laporan keuangan menurut Pernyataan Standar Laporan Keuangan No. 1
Tahun 2002 (PSAK No 1 Tahun 2002) terdiri dari:

a. Neraca.
b. Laporan Laba-Rugi.
c. Laporan perubahan ekuitas
d. Laporan arus kas
e. Catatan atas laporan keuangan.

32
Komponen - komponen Laporan Keuangan

a. Neraca
Dalam sistem tatabuku dobel yang mula-mula diajarkan oleh pendeta Italia Paciollo pada
tahun 1494, neraca itu asal mulanya hanya dipergunakan untuk menyatakan bahwa
pembukuan perusahaan telah “ditutup” dan membuktikan bahwa ada keseimbangan
antara debit dan kredit[5]. Baru pada akhir abad ke 18, orang mulai menyusun suatu
neraca berdasarkan urutan-urutan yang kita kenal sekarang. Lazimnya aktiva dan pasiva
disusun berdasarkan urutan menurut likwiditas, artinya disusun menurut kemungkinan
untuk mentransformasikan aktiva-aktiva tersebut menjadi uang tunai.
Daftar yang memuat informasi secara terperinci semua aktiva, kewajiban perusahaan
serta modal pemilik pada waktu tertentu disebut neraca (balance sheet). Waktu tertentu
bisa akhir bulan, akhir triwulan, akhir tahun dan waktu tertentu lainnya.
Bentuk neraca ada dua bentuk yaitu bentuk skontro (account form) dan bentuk laporan
(report form). Dalam neraca bentuk skontro, Aktiva disajikan disebelah kiri sedangkan
kewajiban dan modal disajikan disebelah kanan. Dalam neraca bentuk laporan, Aktiva
disajikan paling atas sedangkan kewajiban dan modal disajikan bawahannya.
Komponen-komponen neraca dapat digolongkan sebagai berikut :
i. Aktiva (Asset)
Committee on Terminology (1953 hlm. 26) mendefinsikan aktiva adalah “Sesuatu
yang disajikan di saldo debet yang akan dipindahkan setelah tutup buku sesuai
dengan prinsip akuntansi (bukan karena saldo negatif yang akan dinilai sebagai
utang), saldo debet ini merupakan hak milik atau nilai yang dibeli atau
pengeluaran yang dibuat untuk mendapatkan kekayaan di masa yang akan
datang”. Aktiva dibagi menjadi dua kelompok yaitu aktiva lancar dan aktiva tetap.
Pengelompokkan aktiva ke dalam aktiva lancar dan aktiva tetap di atur dalam
Pernyataan Standar Akuntansi Keuangan No. 1 tahun 2002 (PSAK No. 1 tahun
2002).
Aktiva Lancar (Current Assets) adalah aktiva yang secara normal
ditranformasikan menjadi kas dalam jangka waktu setahun atau sebelum
berakhirnya siklus produksi (jika siklus ini melebihi jangka waktu setahun). Yang
termasuk kedalam aktiva lancar antara lain kas, piutang usaha, wesel tagih,

33
 persediaan barang, suplai toko, suplai kantor, biaya dibayar dimuka, pendapatan
yang akan diterima, investasi jangka pendek. Sedangkan, Aktiva Tetap (Fixed
Assets) adalah aktiva yang dipergunakan dalam perusahaan dan mempunyai
kegunaan yang melebihi satu masa pembukuan. Yang termasuk kedalam aktiva
tetap antara lain peralatan, kendaraan, bangunan/gedung dan tanah.

ii. Kewajiban (Liabilities)

Definisi dari entity theory yaitu “Kewajiban adalah saldo kredit atau jumlah yang
harus dipindahkan dari saat tutup buku ke periode tahun berikutnya berdasarkan
pencatatanyang sesuai dengan prinsip akuntansi (saldo kredit bukan akibat saldo
negatif aktiva”.
Kewajiban dibagi menjadi dua kelompok yaitu kewajiban jangka pendek dan
kewajiban jangka panjang. Pengelompokkan kewajiban jangka panjang diatur
dalam Pernyataan Standar Akuntansi Keuangan No. 1 tahun 2002 (PSAK No. 1
tahun 2002). Kewajiban Jangka Pendek adalah kewajiban-kewajiban yang akan
jatuh tempo dalam satu tahun atau dalam siklus kegiatan normal perusahaan.
Kewajiban/hutang lancar meliputi hutang dagang, hutang wesel, hutang bank,
hutang gaji, bunga dan lain-lain. Yang termasuk kedalam kelompok kewajiban
jangka pendek antara lain utang usaha, wesel bayar, semua pendapatan yang
diterima dimuka, semua biaya yang belum dibayar dan kewajiban jangka panjang
yang akan jatuh tempo dua belas bulan setelah tanggal neraca. Sedangkan,
Kewjiban Jangka Panjang adalah hutang yang jatuh temponya lebih dari satu
tahun digolongkan ke dalam kewajiban jangka panjang. Contohnya adalah hutang
obligasi, hutang bank dan lain-lain. Yang termasuk kedalam kelompok kewajiban
jangka panjang antara lain hutang hipotek dan pinjaman obligasi.

iii. Modal (Equity)

Modal (equity) adalah “suatu hak yang tersisa atas aktiva suatu lembaga (entity)
setelah dikurangi kewajibannya”. Dalam perusahaan equity adalah modal pemilik.
Definisi ini cenderung menganut propriety theory.

34
Laporan keuangan dibuat semata untuk mengetahui kondisi finansial perusahaan. Sehingga pihak
atasan bisa mengevaluasi dengan tepat jika kondisi keuangan usaha mengalami masalah. Maka
dari itu laporan ini harus dibuat dengan tepat dan cermat. Karena ini berupa laporan tentu ada
pertanggungjawaban yang diserahkan secara mutlak kepada operator keuangan. Dia yang harus
mempresentasikan laporan yang telah dibuatnya dengan detail di depan atasan. Biasanya ini
dilakukan pada saat evaluasi. Jika melihat dari penjelasan di atas tentu bisa ditarik kesimpulan
kalau pengertian laporan keuangan adalah berkas yang berisi data transaksi keuangan perusahaan
pada periode tertentu. Yang mana berkas tersebut harus dilaporkan dan dipertanggungjawabkan
sebagai pembahasan evaluasi untuk perkembangan usaha ke depan.

Sebagian besar perusahaan melakukan "tutup buku" untuk membuat laporan keuangan baik
secara bulanan maupun tahunan. Entri jurnal penutup membuat nol seluruh akun pendapatan dan
biaya dalam neraca saldo disesuaikan dan memindahkan pendapatan (atas rugi) bersih pada laba
ditahan.

Dengan model REA , perusahaan membuat laporan keuangan langsung dari basis data kegiatan
langsung Sebuah diagram REA yang dapat juga digunakan sebagai panduan penulisan query
untuk menghasilka informasi yang akan dimasukkan dalam laporan keuangan. Diagram REA
yang lengkap juga dapat digunakan untuk memandu penulisan antrian untuk menghasilkan
informasi yang akan dimasukkan dalam laporan keuangan. Banyak laporan keuangan, seperti
Kas, Inventaris, dan Aset Tetap, direpresentasikan sebagai sumber daya dalam model
REA. Meskipun demikian, ada pengecualian penting yaitu tidak menyertakan sebuah entitas
piutang maupun utang.

MEMBUAT LAPORAN MANAJERIAL

Model data REA memfasilitasi pembuatan banyaknya variasi laporan manajerial karena ia
mengintegrasikan data non keuangan dan keuangan. Sebagai contoh, Tabel 18-1 menunjukkan
bahwa entitas penjualan pada Figur 18-4 menyertakan sebuah atribut untuk mencatat waktu
penjualan tersebut terjadi. Fred dapat menggunakan data tersebut untuk melacak aktivitas
penjualan pada kurun waktu hari yang berbeda untuk keperluan rencana staffing yang lebih baik
di Train Shop. Atribut non keuangan lainnya dapat dimasukkan dalam tabel lainnya. Sebagai

35
contoh, tabel pelanggan dapat dimodifikasi untuk menyertakan sebuah atribut yang
mengidentifikasi, apakah seorang pelanggan memiliki train layout dalam ruangan atau luar
ruangan. Jika Fred dapat mengumpulkan informasi ini dari para pelanggannya, ia 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 sumber-sumber eksternal. Sebagai contoh, untuk mengevaluasi dengan lebih baik atas
kelayakan kredit para pelanggan bisnis, Fred bisa jadi memutuskan untuk mengumpulkan
informasi dari sebuah agensi pemeringkat kredit, seperti Dun dan bradstreet. Informasi tersebut
dapat ditambahkan ke database dengan membuat sebuah kolom tambahan pada tabel pelanggan
untuk menyimpan peringkat kredit pelanggan tersebut. Proses yang serupa dapat digunakan
untuk menyimpan informasi tentang para pemasok yang dapat digunakan untuk proses
penyeleksian vendor.

Laporan adalah suatu dokumen sebagai hasil serangkaian kegiatan mencari dan menyajikan
informasi mengenai suatu hal tertentu. Sedangkan laporan manajerial adalah sejenis laporan yang
bertalian dengan urusan tertentu dalam lingkungan suatu organisasi formal yang dibuat untuk
keperluan pimpinan organisasi untuk membuat keputusan dan selanjutnya melakukan Tindakan.

Secara terperinci Laporan manajerial mempunyai peranan sebagai berikut :

 Bagi organisasi laporan manajerial memberikan gambaran menyeluruh bagi
perkembangan organisasi serta kelebihan dan kekurangannya.
 Bagi pelaksanaan tugas, laporan manajerial dapat menunjukkan sesuatu yang perlu
disempurnakan untuk kegiatan organisasi.
 Bagi manajer, laporan manajerial dapat menyediakan berbagai data untuk membuat
keputusan dan tindakan selanjutnya yang jitu.
 Bagi petugas organisasi sbg pelaksana, laporan manajerial dapat menjadi sarana untuk
menyampaikan ksimpulan penting dan menyampaikan gagasan baru kepada atasannya.
Fungsi dari Laporan adalah sebagai berikut :
 Sebagai sarana komunikasi vertical
 Sebagai alat pertanggung jawaban
 Memberikan informasi penting
 Sebagai bahan untuk pengambilan keputusan

36
Syarat atau kualitas yang harus dipenuhi sebuah laporan manajerial, yaitu:
 Kecermatan (accuracy).
Laporan manajerial digunakan pimpinan untuk mengambil keputusan. Oleh karena itu,
laporan harus cermat dan sesuai kondisi lapangan.
 Ketepatan waktu (timeliness).
Faktor waktu merupakan hal penting dalam pengambilan keputusan. Nilai kepentingan
laporan akan merosot karena laporan tidak selesai tepat waktu.
 Kecukupan (adequacy).
Faktor ini berkaitan dengan cakupan masalah dalam laporan. Cakupan masalah kurang
mencukupi, maka pemecahan masalah tidak akan tepat.
 Kesederhanaan (simplicity).
Laporan dapat menyederhanakan permasalahan dan pemecahannya, dengan bahasa yang
mudah dimengerti sehingga tidak terjadi kesalahan penafsiran dengan tujuan laporan.
 Kejelasan (clarity).
Penggunaan bahasa yang jelas dan tepat sehingga memudahkan manajer untuk mengerti
tujuan laporan sehingga memudahkan pula untuk pengambilan keputusan.

Laporan ini sangat penting bagi pegawai administrasi. Pegawai administrasi harus mengetahui
dan memahami hal yang berkaitan dengan penyusunan laporan. Laporan yang memiliki fungsi:
komunikasi,  pertanggungjawaban,  informasi,  pengawasan, dan pengambilan keputusan dalam
kehidupan organisasi.

Aktivitas keuangan dalam sistem buku besar dan pelaporan menghasilkan berbagai laporan
manajerial. Contoh laporan pengendalian buku besar termasuk (1) daftar voucher jurnal
berdasarkan urutan nomor, nomor akun, atau tanggal, dan (2) daftar saldo akun buku besar.
Laporan-laporan ini digunakan untuk memverifikasi akurasi proses memasukkannya ke buku
besar. Beberapa anggaran dibuat untuk perencanaan dan pengevaluasian kinerja. Anggaran
operasional memperlihatkan pendataan dan pengeluaran yang direncanakan untuk setiap unit
organisasi. Anggaran pengeluaran modal memperlihatkan perkiraan aliran masuk dan keluar kas
untuk setiap proyek. Anggaran arus kas membandingkan perkiraan aliran kas masuk dari
kegiatan operasi dengan perkiraan pengeluaran, dan digunakan untuk menetapkan kebutuhan
peminjaman.

37
Laporan anggaran dan kinerja harus dikembangkan atas dasar akuntansi pertanggungjawaban.
Akuntansi pertanggungjawaban melaporkan hasil keuangan atas dasar tanggung jawab
manajerial di dalam organisasi. Hasilnya adalah serangkaian laporan berkaitan, yang merinci
kinerja keseluruhan organisasi berdasarkan subunit tertentu. Ingatlah bahwa setiap laporan
mencerminkan biaya aktual dan penyimpangan dari anggaran untuk bulan sekarang, dan awal
tahun hingga hari ini, tetapi hanya untuk bagian-bagian yang berada dalam kendali awal tahun
hingga hari ini, tetapi hanya untuk bagian-bagian yang berada dalam kendali manajer sub unit
tersebut. Ingatlah juga bahwa sifat dari laporan adalah: Total biaya setiap sub unit ditampilkan
sebagai satu bagian dalam laporan berikutnya yang lebih tinggi tingkatnya.

Model data REA memfasilitasi pembuatan banyaknya variasi laporan manajerial karena ia
mengintegrasikan data nonkeuangan dan keuangan. Atribut non-keuanganlainnya dapat
dimasukkan dalam tabel lainnya.

38
RINGKASAN DAN KESIMPULAN KASUS

Diagram REA untuk siklus bisnis individual menggambarkan hubungan dualitas ekonomi give-
to-get dasar, biasanya hanya menyediakan sebuah pandangan parsial atas sumber daya , dan
menunjukkan cara sumber daya diperoleh atau cara sumber daya digunakan, tetapi tidak
keduanya. Oleh karena itu, diagram REA siklus bisnis individual perlu dikombinasikan agar
menyediakan sebuah model data keseluruhan-perusahaan. Ini biasanya dilakukan dengan
menggabungkan entitas sumber daya dan peristiwa yang muncul dalam dua atau lebih diagram
REA individual. Menggabungkan dua atau lebih diagram REA yang mengandung entitas sumber
daya yang sama tidak memerlukan segala perubahan apa pun terhadap pasangan kardinalitas
dalam diagram individual. Namun, menggabungkan dua atau lebih diagram yang mengandung
sebuah entitas peristiwa umum sering kali perlu pengubahan kardinalitas minimum terkait
dengan peristiwa lain menjadi 0, dengan tujuan untuk merefleksikan fakta bahwa peristiwa yang
digabungkan tersebut mungkin terhubung ke salah satu dari beberapa peristiwa yang berbeda,
tetapi tidak untuk seluruhnya secara bersamaan. Kardinalitas minimum yang dikaitkan dengan
agen yang berpartisipasi dalam penggabungan peristiwa tersebut mungkin juga harus diubah
menjadi 0. Sebuah model data yang didokumentasikan pada sebuah diagram REA dapat
diimplementasikan dalam sebuah database relasional dengan tiga langkah. Pertama, buatlah
tabel untuk seluruh entitas khusus dan hubungan M:N dalam diagram REA tersebut. Kedua,
tentukan kunci utama dan atribut nonkunci untuk masing-masing tabel. Ketiga, gunakan kunci
asing untuk mengimplementasikan hubungan 1:1 dan 1:N.

Paul Stone mengikuti langkah-langkah tersebut untuk mengimplementasikan sebuah SIA

database bagi Fred’s Train Shop berdasarkan Figur 18-4. Mulanya, ia membuat tabel terpisah
untuk masing-masing 12 entitas yang berbeda dan 5 hubungan M:N dalam gambar tersebut.
Kemudian, Paul mengidentifikasikan kunci-kunci utama untuk masing-masing tabel dan
menggunakan beberapa dari kunci tersebut sebagai kunci asing untuk mengimplementasikan
hubungan 1:1 dan 1:N pada Figur 18-4. Ia kemudian menetapkan atribut-atribut sisanya yang
Fred inginkan untuk mengawasi tabel yang sesuai. Paul kemudian mendemonstrasikan betapa
mudahnya membuat query untuk memuat satu variasi laporan manajerial dan laporan keuangan
dari DBMS terkait. Fred cukup terkesan dan segera mulai menggunakan sistem baru tersebut
untuk menyediakan informasi mendetail mengenai aktivitas bisnis Fred’s Train Shop.

39
 DAFTAR PUSTAKA

Romney, Marshall B. dan Steinbart, Paul John. 2017. Sistem Informasi Akuntansi Bab 18.
Jakarta:Salemba Empat - Cetakan Keenam.

Friska Ayu Kurnianingtyas. (2018, 11 Desember ). Bab 18 Mengimplementasikan Model Rea

Dalam Database Relasional. Diakses pada 06 November 2020, dari
http://friskaayuk.blogspot.com/2018/12/bab-18-mengimplementasikan-model-rea.html

Tricahyaayu.(2013, 10 November).Menyusun Diagram Rea. Diakses pada 04 November 2020,

dari https://tricahyaayu.wordpress.com/2013/11/10/menyusun-diagram-rea/
Ilham Aditya .(2019. 09 Januari). Sistem Buku Besar Dan Pelaporan. Diakses pada 04 November
2020,dari http://ilhamadityagnw.blogspot.com/2019/01/bab-16-sistem-buku-besar-dan-
pelaporan.html?m=1

Chairiah Ulfah .( 2018, 10 Desember).Melaksanakan Model Rea Dalam Database Relasional.

Diakses pada 04 November 2020, dari http://chairiahulfah.blogspot.com/2018/12/bab-18-
melaksanakan-model-rea-dalam.html?m=1

Oviliani Yenty.( 2001, 01 mei).Pendekatan Model Rea Dalamperancangan Database Sistem

Informasiakuntansi Siklus Pendapatan. Diakses pada 04 November 2020, dari
https://media.neliti.com/media/publications/73936-ID-pendekatan-model-rea-dalam-
perancangan-d.pdf

Rahma_moosangf.( 2019, 04 Agustus). Makalah Sia Kelompok 2 - Jurnal.Docx. Diakses Pada

04 November 2020, Dari Https://Www.Coursehero.Com/File/52004819/MAKALAH-SIA-
KELOMPOK-2-Jurnaldocx/

Dina Amalia.(2019, 28 Maret). Pengertian, Fungsi, dan Bentuk Buku Besar Akuntansi Diakses
Pada 04 November 2020, Dari https://www.jurnal.id/id/blog/2017-pengertian-fungsi-dan-bentuk-
buku-besar-akuntansi/

Edudetik.(2014, 08 Mei). Makalah Laporan Keuangan Lengkap. Pada 04 November 2020, Dari
https://www.edudetik.com/2014/05/makalah-laporan-keuangan-lengkap.html

Neri Andhani dan Roshy Fitra Caesarini(2017, 01 Oktober). Makalah Laporan Manajerial. Pada
04 November 2020, Dari http://roshyftrc.blogspot.com/2017/10/v-
behaviorurldefaultvmlo_59.html

40