Mengimplementasikan Model REA dalam Data Base Relasional

Halimatus Syadiah 216200010, Bapak Segi Tabah Hermansyah, SE., M.Ak.,

Ak, CA

Program Studi Akuntansi, Fakultas Ekonomi Universitas Putra Indonesia

Alamat Koresponden: halimatussyadiah0209@gmail.com

Abstrak

Jurnal ini mengulas tentang Mengintegrasikan Diagram REA Antarsiklus, menjelaskan

Aturan untuk Mengombinasikan Diagram REA, Menggabungkan Entitas Sumber Daya
yang Berulang, Menggabungkan Entitas Peristiwa yang Berulang, Memvalidasi ketepatan
Diagram REA Terintegrasi, Mengimplementasi Diagram REA dalam Database Relasional,
Langkah 1 : Buat Tabel untuk setiap Entitas yang berbeda dan Tabel hubungan M:N,
Langkah 2 : Menentukan Atribut untuk setiap Tabel, Langkah 3 : Menggunakan kunci asing
untuk mengimplementasikan hubungan 1: 1dan 1: N, Pengecekan Kelengkapan,
Menggunakan Diagram REA untuk memuat Informasi dari sebuah Database, Membuat
Jurnal dan Buku Besar, Menghasilkan Jurnal dari Query, Menghasilkan Laporan
Keuangan, Membuat Laporan Manajerial.

KATA KUNCI: Model REA, Database Relasional

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 yangdikembangkan untuk siklus bisnis tunggal ke dalam sebuah model data
tunggal, komprehensif, dan seluruh-perusahaan. Kemudian, menjelaskan cara
mengimplementasikan model data hasildalam sebuah database relasional. Selanjutnya,
mendeskripsikan cara menggunakan diagramREA untuk melakukan query database
guna menghasilkan laporan keuangan tradisional serta berbagai laporan manajemen.

Metode Penelitian

Metode penilaian yang penulis lakukan yaitu dengan cara metode pengumpulan data
dari beberapa sumber baik itu dari buku ataupun dari internet.

Pembahasan

A. MENGINTEGRASIKAN DIAGRAM REA ANTARSIKLUS

Figur 181, 182, 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.

Kardinalitas adalah: Menunjukkan jumlah maksimum entitas yang dapat berelasi

dengan entitas pada himpunan entitas yang lain. Kardinalitas merujuk kepada hubungan
maksimum yang terjadi dari himpunan entitas yang satu ke himpunan entitas yang lain dan
begitu juga sebaliknya.
 B. ATURAN UNTUK MENGOMBINASI 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-ger").
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.

Figur 18-1

Siklus Pendapatan Fred’s trans shop

 Sebuah slip gaji juga diterbitkan keseorang pegawai tertentu dan ditandatangani
olehseorang kasir tertentu, tetapi setiap pegawai dan kasir mungkin terhubung dengan
banyak peristiwa mengeluarkan kas 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 menyediakan dasar untuk mengombinasikan diagram REA yang
menggambarkan siklus bisnis individual kedalam sebuah model REA tunggal, model
komprehensif, dan model keseluruhanperusahaan. 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.

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

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 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 berbagaiatribut 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. 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 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 setiap barang
terjual dan menjumlahkan hasil tersebut untuk setiap baris pada tabel PenjualanPersediaan
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 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 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 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.

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 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. Query adalah
perintah yang digunakan untuk mendapatkan informasi dalam database dengan
tujuan untuk melakukan tugas tertentu.

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

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

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

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

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.

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

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.

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

Jadi dari jurnal ini dibahas tentang mengimplementasikan model REA dalam data
base relasional, cukup rumit tetapi accounting nantinya saat pembuatan sistem
informasi akuntansi harus ikut dalam pembuatan sistem ini, agar nantinya
departemen IT tau apa saja didalam elemen-elemen database yang akan dibuat apa
saja, query yang harus dibuat apa saja, sehingga Diagram REA ini akan membentuk
suatu sisitem informasi akuntansi yang berguna untuk accounting.