Desain database pembukuan entri ganda

Saya membuat perangkat lunak akuntansi. Saya perlu menegakkan pembukuan entri ganda. Saya memiliki masalah klasik satu baris per transaksi versus dua baris.

Mari kita ambil contoh dan lihat bagaimana penerapannya di kedua skenario.

Pertimbangkan akun Cashdan akun Rent. Ketika saya membayar sewa bulanan, saya mentransfer $ 100 dari Cashakun saya ke Rentakun saya .

Satu baris per Transaksi

Dalam sistem satu baris, transaksi tersebut akan disimpan sebagai:

transaksi

 tx_id | posting_date
 1     | 23/05/2015

catatan transaksi

 id | tx_id | credit_account | debit_account | amount
 1  | 1     | Cash           | Rent          | 100.00

Dua baris per Transaksi

Dalam sistem dua baris, saya harus mencerminkan catatan transaksi yang sama untuk membuat catatan yang berlawanan bahwa begitu saya jumlahkan keduanya, saya akan mendapatkan saldo nol.

transaksi

 tx_id | posting_date
 1     | 23/05/2015

catatan transaksi

id  | tx_id | type   | account | amount
1   | 1     | credit | Cash    | 100.00
2   | 1     | debit  | Rent    | 100.00

Masalah

Pertama-tama saya ingin mencatat: alasan saya memiliki keduanya transactionsdan transaction_recordstabel (bukan satu tabel) adalah untuk dapat menangani transaksi split (kasus di mana saya mentransfer $ 100 dari Cashakun ke dua atau lebih akun yang berbeda).

Awalnya saya mencoba menerapkan ini dengan satu baris per transaksi, tetapi sulit untuk menghitung saldo akun, dan untuk benar-benar mengambil data.

Saya condong ke skenario kedua; namun, ia juga memiliki beberapa masalah:

• Bagaimana cara memperbarui satu catatan? Dengan asumsi saya telah melakukan kesalahan dan bukannya mencatat $ 100 untuk sewa saya, saya telah mencatat $ 10. Saya sekarang memiliki 2 transaction_records- satu untuk kredit dan satu untuk debit, keduanya dengan jumlah $ 10.
• Sekarang saya melakukan rekonsiliasi saya dan saya ingin memperbaiki kesalahan ketik ini. Bagaimana saya memperbaikinya dalam database? Saya tidak tahu hubungan antara catatan, dan dalam hal pemisahan, satu transaksi dapat memiliki lebih dari 2 catatan. Satu-satunya solusi yang saya buat adalah dengan menambahkan beberapa ref_iduntuk setiap pasangan rekaman yang secara unik akan mengidentifikasi catatan-catatan itu sebagai "sisi yang berlawanan satu sama lain" di dalam konteks spesifik tx_id.

Pendekatan mana yang lebih baik / sederhana?

Untuk menyederhanakan pertanyaan saya: Saya ingin mewakili pergerakan dana dari akun A ke akun B. Dua skenario yang saya berikan adalah desain yang valid untuk menyimpan transaksi tersebut. Seperti yang saya tunjukkan, mereka berdua memiliki kontra & pro (pertama: lebih mudah untuk menyimpan, lebih sulit untuk mengambil; yang kedua sebaliknya).

Mereka mungkin memiliki pro / kontra lain yang tidak saya temukan saat ini, maka saya meminta pendapat dari orang yang lebih berpengalaman.

Memang, skema akuntansi baris tunggal yang diusulkan memungkinkan untuk melakukan akuntansi entri ganda yang tepat (untuk selalu menentukan akun yang didebit dan dikreditkan) tanpa memperkenalkan redundansi data "jumlah".

Skema satu baris memberi Anda implementasi entri ganda yang seimbang dengan konstruksi, sehingga tidak mungkin untuk "kehilangan keseimbangan". Mesin dapat menghitung ulang buku besar dengan cepat.

Anda harus melakukan 2 pilih daripada satu untuk mengambil buku besar.

Catatan, selain pemisahan transaksi, ada transaksi lain seperti valuta asing mungkin berakhir dengan 2 catatan, bukan 4. Itu semua tergantung jika Anda akan sedikit mendenormalkan, masukkan hanya 4 transaksi dengan deskripsi yang sama.

Anda dapat mencegah entri atau modifikasi transaksi apa pun untuk mempertahankan jejak audit, ini diperlukan jika Anda ingin dapat mengaudit log transaksi.

Tampaknya dalam utas di atas, untuk CPA, "dinormalisasi penuh" tampaknya berarti aturan yang diakui oleh semua akuntan, sedangkan untuk programmer memiliki arti yang berbeda, bahwa tidak ada data yang diperoleh atau berlebihan yang disimpan.

Semua yang ada pada data akuntansi adalah seperangkat transaksi yang memberikan jumlah dan akun dari mana dan ke mana mereka mengalir, bersama dengan tanggal mereka, beberapa deskripsi (dan lampiran lainnya). Buku besar dan saldo adalah pandangan sederhana yang berasal dari data transaksional ini dengan melakukan penjumlahan.

Sebuah Journal adalah daftar kronologis dari semua transaksi dari jenis yang ditentukan untuk sistem akuntansi. Berikut ini adalah presentasi klasik di atas buku besar Jurnal Penjualan (pada Akun) sederhana:

Perhatikan bahwa setiap baris adalah transaksi tunggal, dengan Total Debit = Total Kredit; dan bahwa setiap transaksi mencapai tiga akun yang sama. Sebuah Kas Penjualan Journal akan terlihat sama tetapi mengganti kolom Piutang Debit dengan satu label Cash Debit . Sebuah Kas Pencairan Journal akan memiliki kolom pertama berlabel Cash Kredit dan kolom tambahan seperti Hutang Debit dan Beban Karyawan Debit .

Presentasi ini adalah standar selama ratusan tahun hingga komputer pribadi menjadi terjangkau beberapa dekade yang lalu. Ini memiliki keuntungan signifikan dengan mudah memverifikasi bahwa setiap transaksi seimbang dengan hanya memeriksa setiap baris. Demikian juga, sebelum memposting halaman transaksi tersebut ke Buku Besar , total halaman dapat diverifikasi dengan cara yang sama. Itu adalah model pemrosesan batch yang digunakan dalam banyak sistem akuntansi.

Sangat mudah untuk melihat bahwa model makalah ini memiliki kerugian yang signifikan ketika secara harfiah ditranskripsi ke sistem otomatis:

1. Struktur data adalah yang berpivot, sedangkan pengalaman menunjukkan bahwa itu jauh lebih sederhana (juga lebih kuat dan lebih mudah diverifikasi) untuk diprogram terhadap struktur data yang dilipat; dan
2. Karena setiap Jurnal khusus menyentuh kumpulan akun yang berbeda, masing-masing Jurnal tersebut harus dirancang dan diprogram secara terpisah, kegiatan yang boros dan rawan kesalahan.

Untuk alasan ini pada umumnya disarankan untuk menggunakan desain Jurnal Khusus sebagai antarmuka ke sistem akuntansi, tetapi untuk merancang struktur data yang dapat menjadi repositori numerik untuk beberapa jurnal. Dalam RDBMS modern ini memiliki potensi keuntungan bahwa Buku Besar Umum , dan bahkan subledger khusus , dapat menjadi Tampilan Terindeks di Jurnal, sepenuhnya menghilangkan persyaratan untuk mengkode Proses Posting (langkah di mana transaksi Jurnal terkunci dan memiliki akunnya total ditranskripsi ke berbagai buku besar).

Apapun desain data Anda, kuncinya adalah memiliki Entri Posting tunggal untuk setiap jenis transaksi (yaitu masing-masing Jurnal khusus dalam sistem kertas yang setara) di mana pemeriksaan saldo dilakukan.

Maksud saya adalah bahwa kedua pendekatan yang Anda usulkan adalah mekanisme yang tidak sehat untuk pembukuan entri ganda. Poin pertama: Jurnal adalah tabel menulis sekali untuk alasan yang sangat bagus. Kadang-kadang dua tabel virtual Pending Entri dan Entri yang Diposting dikumpulkan dalam struktur data tunggal, tetapi bit IsPosted selalu hanya untuk menulis dan sistem harus memastikan bahwa sifat baca-saja dari catatan Entri yang Diposting dipertahankan.

Cara akuntan memposting Entri Jurnal selama 800 tahun terakhir sepenuhnya dinormalisasi . Satu-satunya perbedaan antara presentasi kertas dan presentasi elektronik suara adalah bahwa struktur tabel terlipat lebih nyaman dalam kasus yang terakhir sedangkan struktur tabel pivot di yang pertama, yang secara historis paling signifikan ketika pemrosesan paralel sangat diinginkan - yaitu masing-masing banyak pegawai memelihara satu atau beberapa jurnal khusus. Hanya Controller yang secara historis memiliki izin untuk General Journal.

Perhatikan baik-baik bahwa di atas saya tentukan bahwa Entri Jurnal sepenuhnya dinormalisasi; Entri Jurnal adalah catatan kronologis dari semua transaksi, dikelompokkan dalam Jurnal khusus untuk setiap jenis transaksi. The postingan dari entri jurnal ke Buku Besar adalah usaha terpisah dan, sementara sepenuhnya dinormalisasi sendiri, adalah salinan berlebihan dari entri jurnal di mana semua transaksi yang dirangkum (General Ledger) atau rinci (Sub Ledger) oleh akun. Baik Jurnal dan Buku Besar menerapkan pembukuan entri ganda secara independen.

@Codism Setiap sistem akuntansi, DEB atau SEB, memberi Anda pelaporan umum untuk semua akun yang direkam . Perhatikan bahwa, secara internal, sub-ledger menurut definisi merupakan catatan pembukuan entri tunggal; sisi lain adalah akun kontrol yang sesuai pada Neraca. DEB memastikan bahwa untuk setiap dolar aset ada catatan akurat klaim bisnis atas aset tersebut , yaitu ekuitas dalam aset apakah itu ekuitas utang (alias kewajiban) atau ekuitas kepemilikan , dan prioritas klaim tersebut jika organisasi menjadi bangkrut.

Bolehkah saya menyarankan Anda melihat harta karun perangkat lunak Open Source yang ada di daerah ini?

Google " perangkat lunak akuntansi entri ganda open source " memberikan beberapa jalan investigasi yang menjanjikan.

Anda dapat melihat paket akuntansi GNU di sini , beberapa situs ulasan ( 1 & 2 ) dan akhirnya wiki perangkat lunak akuntansi dengan bagian tentang Perangkat Lunak Bebas.

Saya yakin bahwa dengan memeriksa beberapa kode sumber F / LOSS dan skema, Anda mungkin mendapatkan beberapa petunjuk dan indikasi yang baik tentang cara menulis skema dan / atau perangkat lunak yang sesuai dengan kebutuhan khusus Anda.

Saya memiliki sistem yang melakukan garis ganda dan banyak tantangan daripada memiliki akun garis tunggal. Pertama saya telah menemukan contoh hanya satu baris didorong seperti sisi debit, mengakibatkan akun tidak seimbang. Bahkan jika saya tidak melakukan kontrol yang tepat untuk melakukan dan mengembalikan, ini tidak akan terjadi dalam satu baris akun. terakhir, db Anda tumbuh dalam tingkat pertumbuhan ganda, baris kedua kirim Anda akan memiliki banyak info duplikat, satu-satunya perbedaan adalah akun kedua. Akan menyarankan tetap, satu baris akun, saya pergi ke rute itu ..