Dari seorang penerjemah : selama bekerja di fintech Nigeria saya harus membuat satu sistem pembayaran dari awal. Pada saat itu, saya tidak benar-benar mengerti apa-apa tentang akuntansi, bagaimana lebih baik menyimpan pembayaran dan saldo. Tetapi ada kecurigaan bahwa opsi primitif dengan satu digit saldo di akun pengguna terlalu sederhana untuk dibenarkan.
Artikel ini membantu saya memahami dan menghindari banyak masalah dalam hal ini. Pada saat yang sama, informasi tentang topik "bagaimana membuat sistem pembayaran Anda sendiri" cukup kecil, dan tidak mudah bagi seorang programmer untuk memahami buku-buku tentang akuntansi (dan sangat membosankan). Saya berharap materi ini akan bermanfaat bagi mereka yang hanya akan melakukan sesuatu seperti ini.
Segera saya minta maaf atas kemungkinan ketidakakuratan dalam hal keuangan berbahasa Rusia - saya masih seorang programmer, bukan seorang akuntan, dan saya tidak akrab dengan terminologi Rusia di bidang ini.
Pendahuluan
Banyak sistem komputer yang menggunakan basis data relasional menyimpan beberapa jenis informasi keuangan tentang saldo dan transaksi. Selain itu, desain dan pengembangan database seperti itu sering menimbulkan pertanyaan tentang bagaimana menyimpan informasi ini. Biasanya pilihannya adalah antara "rekaman sederhana" yang murah dan "rekaman ganda" yang lebih rumit.
Luca Pacioli, penulis buku tertua (abad ke-15) yang masih hidup yang menjelaskan prinsip-prinsip entri ganda
Dalam sistem "catatan sederhana", nilai numerik direkam hanya sekali. Dalam sistem entri ganda, setiap nilai dicatat dua kali sebagai kredit (nilai positif) dan sebagai debit (nilai negatif). Ada seperangkat aturan yang menentukan hubungan antara nilai-nilai ini. Aturan-aturan ini akan dengan mudah dijelaskan kepada Anda oleh akuntan berpengalaman mana pun, meskipun ia mungkin tidak membayangkan bagaimana mereka dapat diwakili dalam database relasional.
Aturan dasarnya adalah sebagai berikut:
- Setiap entri dalam sistem harus seimbang, mis. jumlah semua nilai dalam satu operasi harus memberikan nol.
- Jumlah semua nilai dalam keseluruhan sistem pada waktu tertentu harus memberikan nol (aturan yang disebut "saldo percobaan").
- Nilai yang sudah dimasukkan ke dalam basis data tidak dapat diedit atau dihapus. Jika diperlukan koreksi, operasi pertama-tama harus dibatalkan oleh operasi lain dengan tanda yang berlawanan, dan kemudian diulangi dengan nilai yang benar. Ini memungkinkan Anda untuk menerapkan jejak audit yang andal (log lengkap dari semua transaksi, seringkali diperlukan selama inspeksi).
Penerapan Pembukuan Berganda
Pada awal proyek, harga rendah dari rekaman sederhana selalu menggoda, dan biaya implementasi dan kompleksitas dari perekaman ganda penuh tampaknya tidak perlu. Namun, dalam kenyataannya, sering menggunakan rekaman sederhana adalah tabungan yang salah.
Jika informasi akuntansi dalam sistem TI hanya menyalin catatan kertas yang ada disimpan di luar database yang sedang dikembangkan, maka catatan sederhana masih memiliki hak untuk hidup. Namun, jika setidaknya salah satu fakta tentang sistem yang tercantum di bawah ini benar, maka entri ganda harus digunakan sejak awal:
- Jika pernah audit informasi akuntansi diperlukan
- Jika informasi dalam sistem adalah satu-satunya sumber informasi tentang properti
- Jika informasi menyangkut benda bernilai tinggi
- Jika sistem ini direncanakan akan dikembangkan secara serius di masa depan
Contoh entri ganda
Gagasan kunci dari double-entry adalah keberadaan akun "buku kas" khusus ( sekitar. Terjemahan: Saya tidak menemukan cara untuk menyebutnya dalam bahasa Rusia, adakah yang bisa memberi tahu saya? ). Akun ini berisi catatan yang dibuat ketika barang berharga (seperti uang) disimpan atau ditarik dari sistem akuntansi kami. Dengan demikian, saldo saat ini dari akun ini mencerminkan jumlah total nilai dalam sistem.
Berikut ini adalah contoh sederhana dengan dua akun, "buku kas" dan "Smith."
(a) £ 300 dimasukkan ke dalam sistem dan disetorkan ke akun Smith. Pinjaman sebesar £ 300 dibuat di akun Smith (kredit di sebelah kanan, debit di sebelah kiri). Untuk meratakan jumlah ini, debit sebesar £ 300 dibuat di akun buku kas.
(B) Smith kemudian menyimpulkan £ 50 dari sistem. Kami membuat debit untuk jumlah ini di akun Smith dan kredit di buku kas.
(c) Tambahkan akun Pattel lain dan transfer 100 £ kepadanya dari Smith. Untuk melakukan ini, kita perlu membuat debit untuk jumlah ini dengan Smith dan pinjaman dengan Pattel.
(d) Sebagai sentuhan akhir, biarkan Pattel sekarang menarik £ 60 dari sistem. Kami membuat debit di akunnya dan kredit di buku Cash.
Sebagai hasil dari semua operasi ini, kita dapat menghitung bahwa total saldo Smith adalah 150 £, Pattela 40 £, dan dalam Buku Tunai -190 £, jumlah negatif dari saldo semua akun lainnya. Berdasarkan aturan dan operasi sederhana ini di masa mendatang, Anda dapat membangun sistem kontrol nilai yang sangat komprehensif.
Model data
Struktur model data sederhana yang dapat digunakan untuk mewakili semua informasi ini:
Tabel POSTING berisi entri ganda sendiri. Menyimpan semua angka dalam satu tabel sangat menyederhanakan semua perhitungan. Penghitung yang meningkat secara monoton harus digunakan sebagai kunci utama. Nilai harus masuk berturut-turut, dalam hal ini, dengan angka Anda selalu dapat memastikan bahwa tidak ada catatan yang telah dihapus. Tabel BATCH dan JURNAL digunakan untuk mengontrol dan memasukkan data ke dalam tabel POSTING ini.
Setiap entri dalam tabel JURNAL mewakili transaksi (dari perspektif bisnis) yang menghasilkan entri ganda. Transaksi semacam itu adalah unit kerja yang selesai atau proses bisnis. Entah semua catatan POSTING yang terkait dengan catatan JURNAL harus diselesaikan dengan sukses, atau tidak satupun. Jumlah semua catatan POSTING dalam satu transaksi harus nol. Setiap operasi transfer dari contoh di atas diwakili oleh entri di tabel JURNAL
Entri dalam tabel BATCH dibuat untuk kenyamanan entri data. Ini digunakan untuk mengelompokkan catatan JURNAL ke dalam paket yang mudah digunakan, misalnya, serangkaian cek untuk masuk ke sistem, semacam proses bisnis global, seperti membebankan bunga kepada semua pengguna sekaligus, dll.
Tabel ACCOUNT menyimpan data pada pemilik nilai dalam sistem.
Tabel ASSET TYPE berisi informasi tentang jenis nilai yang digunakan dalam sistem. Dengan menambahkan jenis nilai ke kunci utama dari tabel POSTING, Anda dapat membuat sistem yang beroperasi pada beberapa jenis nilai sekaligus (misalnya, memproses beberapa mata uang).
Berikut ini cara database tersebut mencari contoh di atas dalam bentuk yang paling sederhana:
Saldo kolom Jumlah dalam tabel POSTING selalu nol setelah penyelesaian transaksi dari JURNAL (perangkat lunak harus memastikan bahwa tidak ada catatan transaksi tidak lengkap dalam database).
Jumlah operasi untuk akun Buku Kas memberikan -190, yang sama dengan jumlah saldo Smith dan Pattel dengan tanda kebalikannya.
Untuk menunjukkan operasi multi-mata uang, jenis nilai baru telah ditambahkan. Jika Smith ingin menukar 20 pound untuk dolar pada tingkat 1 untuk 1,5, transaksi akan dilakukan melalui Buku Kas dengan cara ini:
Periode penagihan
Model yang kami peroleh tampak hebat, tetapi dalam kenyataannya akan pecah dengan sangat cepat di bawah beban tinggi karena fakta bahwa kami tidak dapat menghapus apa pun dan dipaksa untuk terus-menerus menceritakan peningkatan jumlah catatan dalam POSTING.
Sebagian besar sistem akuntansi memiliki konsep periode penagihan - biasanya sebulan, tiga bulan, atau setahun. Periode seperti itu menunjukkan titik yang nyaman untuk membagi aliran data. Biasanya titik yang nyaman adalah akhir tahun, kalender atau keuangan.
Kami dapat menambahkan kolom dengan indikator periode ke tabel POSTING dan ke kunci utamanya, memecah data menjadi kelompok-kelompok yang dapat diproses secara mandiri. Jika dalam contoh di atas beberapa catatan jatuh pada periode penagihan baru, saldo akun akan diteruskan sebagai berikut.
Pertama, saldo periode sebelumnya akan dihapus.
Dan kemudian mereka akan dipindahkan ke periode baru
Setelah waktu tertentu, semua catatan pada periode TAHUN 1 dapat dikirim ke arsip dan dihapus dari sistem tanpa kehilangan integritasnya.
Agregasi transaksi
Beberapa operasi dalam sistem akuntansi dapat memengaruhi banyak, atau bahkan semua, pengguna sekaligus. Misalnya, pembayaran bunga untuk semua pengguna dalam bentuk bagian dari saldo mereka saat ini.
Operasi tersebut dapat diproses sebagai bagian dari satu transaksi tunggal dalam tabel JURNAL dan Anda dapat menggabungkan semua operasi dengan Buku Kas ke dalam satu catatan umum dalam tabel POSTING (alih-alih membuat operasi terpisah untuk setiap akun). Ini akan memungkinkan Anda untuk mematuhi semua aturan akuntansi di atas dan pada saat yang sama mengurangi separuh jumlah catatan dalam database. Dengan menggunakan pendekatan ini, akhir tahun dalam database akan terlihat seperti ini:
Pemrosesan batch
Pemrosesan batch sering digunakan untuk menyederhanakan entri data ke dalam sistem akuntansi.
Secara historis, pemrosesan cek telah bekerja seperti ini. Akuntan itu diberi paket sepuluh cek, jumlah paket dan jumlah total semua cek. Pada tahap pertama, cek dimasukkan ke dalam sistem dalam bentuk entri "tidak sah". Dalam hal ini, melalui tabel BATCH, jumlah dan jumlah totalnya diperiksa, dan hanya jika mereka cocok dengan nilai yang benar pengguna diizinkan untuk melakukan paket. Setelah ini selesai, paket dikirim ke karyawan lain yang memeriksa validitasnya dan kemudian "memberi wewenang" jika semuanya dimasukkan dengan benar.
Proses ini disebut "pembuat / pemeriksa" dan dapat digunakan untuk memasukkan data yang relevan ke dalam sistem.
Dalam hal ini, catatan "tidak sah" dalam tabel terpisah dari set utama catatan ganda dalam tabel POSTING akan benar. Anda juga dapat memiliki sejumlah tabel tersebut untuk berbagai proses bisnis. Sebagai contoh, dalam kasus cek di mana uang dimasukkan atau ditarik dari sistem, akuntan hanya perlu memeriksa satu akun. Sejak yang kedua, Buku Tunai, dalam operasi seperti itu selalu tersirat secara implisit. Dalam hal ini, dalam tabel PERIKSA, hanya satu kolom dengan akun yang dapat ditiadakan, sedangkan dalam tabel FUND TRANSFER hipotetis, dua kolom akan diperlukan: "pengirim" dan "penerima".
Di sinilah kesalahpahaman dasar tentang prinsip-prinsip rekaman ganda muncul. Kebanyakan orang dalam kehidupan biasa hanya menemukan buku-buku akuntansi kertas sederhana. Dalam buku kertas semacam itu, misalnya, untuk menghitung keuangan klub minat tertentu, Anda hanya perlu satu entri untuk setiap operasi. Namun, itu masih memiliki entri ganda implisit, karena selalu ada akun Buku Kas implisit (dalam hal ini, ini adalah klub), karena semua arus kas selalu berupa input (pembayaran biaya oleh peserta) atau penarikan uang dari sistem (pengeluaran klub).
Alasan kedua untuk kesalahpahaman adalah bahwa dalam laporan akun pribadi, uang yang disimpan dalam akun akan dianggap sebagai "pinjaman", karena seseorang pada dasarnya meminjamkan ke bank yang menerima uangnya. Meskipun jika orang ini menyimpan buku besarnya, entri ini akan dicatat di dalamnya sebagai "debit" - karena bank berutang uang ini kepada kliennya. Uang ini ditarik dari "sistem pembayaran" pengguna dan dimasukkan ke dalam sistem bank.
Arsitektur Perangkat Lunak
Perangkat lunak yang mengimplementasikan sistem akuntansi double-entry seperti itu paling baik dikembangkan menggunakan OOP dan pendekatan berjenjang. Levelnya adalah sebagai berikut:
- Antarmuka eksternal
- Logika bisnis
- Bekerja dengan DB
Tentu saja, arsitektur sistem akan tergantung pada apa tepatnya yang harus dilakukan sistem ini, namun, kita dapat mengasumsikan kehadiran modul berikut di dalamnya:
PostEntry: modul yang mengontrol penciptaan entri ganda dalam tabel POSTING. Dia bertanggung jawab untuk memasukkan catatan, menetapkan ID dan stempel waktu. Modul tidak dapat menghapus atau mengubah catatan dan tidak ada modul lain yang menghapus atau memodifikasi catatan ini, kecuali untuk penghapusan catatan arsip lama untuk periode penagihan yang sudah tidak relevan. Tabel POSTING harus hanya-baca untuk semua modul lainnya.
MakeDeposit, MakeWithdrawal, MakeTransfer: modul-modul ini menerapkan logika bisnis dasar untuk operasi transfer dana. Mereka akan menggunakan modul PostEntry untuk memasukkan hasilnya ke dalam database.
ChequeEntry dan ChequeAuthorisation, ReceiveBACS ( catatan: BACS adalah sistem pembayaran antar bank ): modul-modul ini akan menghubungkan sistem dengan dunia luar dan menyediakan antarmuka tingkat tinggi. Mereka akan menggunakan modul lapisan bisnis untuk melakukan fungsinya. Dalam hal ini, Anda dapat menjamin pemrosesan yang benar terlepas dari metode entri data, karena baik ChequeEntry dan ReceiveBACS akan bekerja melalui MakeDeposit yang sama
Metodologi ini untuk memisahkan lapisan dapat diterapkan pada tingkat yang lebih besar atau lebih kecil, tergantung pada kompleksitas sistem dan kemurnian yang diinginkan menggunakan prinsip-prinsip desain objek. Pada saat yang sama, mungkin masuk akal, misalnya, untuk mengizinkan modul pembuatan laporan (misalnya TestTrialBalance) untuk secara langsung mengakses database dari tingkat antarmuka - alih-alih membuat modul perantara pada lapisan bisnis dan basis data.
Neraca percobaan
"Neraca percobaan" - cara utama untuk memverifikasi integritas sistem akuntansi. Jika semua entri dimasukkan ke dalam sistem sesuai dengan aturan entri ganda dan tidak ada kesalahan, maka jumlah semua entri harus nol. Kemungkinan beberapa kesalahan terpisah akan bertambah dan memberikan total nol pada basis yang tidak valid biasanya sangat kecil sehingga diabaikan.
Cara terbaik untuk memeriksa adalah gerakan yang konsisten dari tingkat atas ke bawah. Cek masuk akal dalam urutan ini:
- Jumlah dari semua nilai di kolom POSTING.Amount
Jika kesalahan ditemukan (nilainya tidak nol), maka: - Jumlah semua nilai POSTING. Jumlah, tetapi dihitung secara terpisah untuk berbagai jenis nilai dan periode penyelesaian
Pada tahap ini, itu harus menjadi lebih jelas di bagian mana dari sistem terjadi kesalahan. - Memeriksa masing-masing operasi dalam tabel JURNAL. Karena jumlah semua POSTING. Akun dalam setiap transaksi dari tabel JURNAL juga harus memberikan nol, maka Anda dapat melacak transaksi bermasalah yang spesifik.
Jenis posting JURNAL
Tabel JURNAL berisi representasi sederhana dari entitas, yang bagaimanapun sering terbukti lebih kompleks dan terlibat dalam berbagai hubungan.
Terkadang masuk akal untuk membagi satu tabel menjadi beberapa tabel. Misalnya, pada MATERIALIZED dan DEMATERIALIZED, yang mungkin memiliki kumpulan kolom yang berbeda, misalnya, entitas material mungkin memerlukan data di lokasi mereka saat ini.
Atau, dalam satu tabel, subtipe nilai yang berbeda, seperti mata uang atau sekuritas, dapat disimpan, setiap subtipe dapat memiliki set properti dan atributnya sendiri.
Entitas yang memiliki sub- dan supertipe dapat diorganisasikan dalam database dengan satu dari empat cara (ini adalah situasi yang cukup standar untuk database apa pun):
- Satu tabel besar umum dengan banyak kolom opsional untuk atribut subtipe
- Tabel terpisah untuk setiap subtipe, dengan duplikasi semua kolom umum
- Pisahkan entitas sehingga supertipe disimpan dalam tabel terpisah dan bergabung dengan tabel lain yang hanya berisi kolom subtipe-spesifik
- Sama seperti pada 3, tetapi dengan duplikasi kolom supertipe dalam tabel subtipe
Masing-masing dari empat opsi memiliki pro dan kontra. Dari sudut pandang entri-ganda, penting untuk memiliki tabel bersama untuk entri POSTING. Opsi 1 lebih cocok untuk sistem akuntansi sederhana (seperti dalam contoh dalam artikel ini, di mana satu-satunya perbedaan dalam jenis nilai ditentukan oleh kolom JURNAL. Jenis). Opsi 3 mungkin lebih cocok untuk sistem kompleks yang bekerja dengan berbagai nilai yang sangat berbeda.