Kelompok 15 - BAB 18 (Mengimplementasi Model REA Dalam Database Relasional) [PDF]

Citation preview

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







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



Sebuah slip gaji juga diterbitkan keseorang pegawai tertentu dan ditandatangani oleh seorang kasir tertentu, tetapi setiap pegawai dan kasir mungkin terhubung dengan banyak 4



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 menyediakan dasar untuk mengombinasikan diagram REA yang menggambarkan siklus bisnis



5



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.



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



Memesan persediaan



Nomor



Nomor



Atribut Lain



pesanan Nomor pemasok, nomor Tanggal,



pembelian Menerima persediaan



Kunci Asing



pegawai



alasan



laporan Nomor pemasok, nomor Tanggal, 10



waktu,



waktu,



penerimaan



pegawai, nomor pesanan keterangan, pembelian, nomor cek



Mengeluarkan kas



Nomor cek



faktur vendor



Nomor pemasok, nomor Jumlah, pegawai



nomor



deskripsi,



(terbayar), tanggal



nomor



pegawai



(penandatangan), nomor rekening Mengambil



pesanan Nomor



pesanan Nomor



pelanggan, Tanggal,



pelanggan



penjualan



nomor pegawai



Penjualan



Nomor faktur



Nomor



waktu,



keterangan khusus



pelanggan, Tanggal,



waktu,



nomor pegawai, nomor faktur dikirim pesanan penjualan Menerima kas



Waktu pengerjaan



Nomor



Nomor



pengiriman uang



nomor pegawai



Nomor



kartu Nomor



waktu



pelanggan, Tanggal,



waktu,



metode pembayaran pegawai, Tanggal,



jam



supervisor, nomor cek masuk, jam keluar gaji



deskripsi,



harga



daftar,



biaya



standar,



kuantitas



awal



ditangan,



kuantitas keterpersediaan awal,



kuantitas



pemesanan angka



ulang,



pemesanan



ulang Kas



Nomor rekening



-



Saldo



awal,



jenis



rekening Pegawai



Nomor pegawai



-



Nama,



tanggal



dipekerjakan, tanggal lahir, tingkat 11



bayaran, jabatan Nomor pelanggan



Pelanggan



-



Nama, alamat, saldo rekening awal, batas kredit



Nomor pemasok



Pemasok



-



Nama, alamat, saldo rekening



awal,



peringkat kinerja Memesan persediaan- Nomor persediaan



pesanan -



yang



pembelian, nomor



dipesan, biaya unit



produk



actual



Menerima persediaan- Nomor



laporan -



penerima, nomor



persediaan



Kuantitas



Kuantitas



yang



diterima, kondisi



produk Mengambil



pesanan Nomor



pelanggan-persediaan



pesanan -



penjualan, nomor



Kuantitas



yang



dipesan



produk Penjualan-persediaan



Nomor



faktur, -



nomor produk



Kuantitas dijual,



harga



yang jual



actual Penjualan-menerima



Nomor



kas



nomor



faktur, -



Jumlah



yang



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



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



anomaly update, insert, dan delete. Untuk



tidak ditemukan masalah



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



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 giveto-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-danpelaporan.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-18melaksanakan-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-dalamperancangan-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-SIAKELOMPOK-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-bentukbuku-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/vbehaviorurldefaultvmlo_59.html 40