Thiết kế cơ sở dữ liệu kế toán kép


24

Tôi đang tạo phần mềm kế toán. Tôi cần phải thực thi sổ sách kế toán kép. Tôi có vấn đề cổ điển về một hàng trên mỗi giao dịch so với hai hàng.

Hãy lấy một ví dụ và xem nó sẽ được thực hiện như thế nào trong cả hai kịch bản.

Xem xét tài khoản Cashvà tài khoản Rent. Khi tôi trả tiền thuê hàng tháng, tôi chuyển 100 đô la từ Cashtài khoản của mình sang Renttài khoản của tôi .

Một hàng cho mỗi giao dịch

Trong hệ thống một hàng, giao dịch đó sẽ được lưu trữ dưới dạng:

giao dịch

 tx_id | posting_date
 1     | 23/05/2015

giao dịch_records

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

Hai hàng cho mỗi giao dịch

Trong một hệ thống hai hàng, tôi phải phản ánh cùng một bản ghi giao dịch để tạo một bản ghi ngược lại rằng một khi tôi tổng hợp cả hai, tôi sẽ nhận được số dư bằng không.

giao dịch

 tx_id | posting_date
 1     | 23/05/2015

giao dịch_records

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

Vấn đề

Trước hết tôi muốn lưu ý: lý do tôi có cả hai transactionstransaction_recordsbảng (thay vì một bảng) là để có thể xử lý các giao dịch phân tách (trường hợp tôi chuyển 100 đô la từ Cashtài khoản sang hai hoặc nhiều tài khoản khác nhau).

Lúc đầu, tôi đã cố gắng thực hiện điều này với một hàng cho mỗi giao dịch, nhưng thật khó để tính số dư tài khoản và thực sự lấy lại dữ liệu.

Tôi đang nghiêng về kịch bản thứ hai; tuy nhiên, nó cũng có một số vấn đề:

  • Làm cách nào để cập nhật một bản ghi? Giả sử tôi đã phạm sai lầm và thay vì ghi 100 đô la cho tiền thuê nhà, tôi đã ghi lại 10 đô la. Bây giờ tôi có 2 transaction_records- một cho tín dụng và một cho ghi nợ, cả hai đều có số tiền $ 10.
  • Bây giờ tôi làm hòa giải và tôi muốn sửa lỗi đánh máy này. Làm thế nào tôi có thể sửa lỗi này trong cơ sở dữ liệu? Tôi không biết kết nối giữa các bản ghi và trong trường hợp phân tách, một giao dịch có thể có nhiều hơn 2 bản ghi. Giải pháp duy nhất tôi đưa ra là thêm một số ref_idcho mỗi cặp bản ghi sẽ xác định duy nhất các bản ghi đó là "các mặt đối diện của nhau" trong bối cảnh cụ thể tx_id.

Cách tiếp cận nào tốt hơn / đơn giản hơn?


Để đơn giản hóa câu hỏi của tôi: Tôi muốn đại diện cho việc chuyển tiền từ tài khoản A sang tài khoản B. Hai kịch bản tôi đưa ra là cả hai thiết kế hợp lệ để lưu trữ giao dịch đó. Như tôi cũng đã chỉ ra cả hai đều có nhược điểm & thứ nhất (thứ nhất: dễ lưu hơn, khó lấy hơn; thứ hai thì ngược lại).

Họ có thể có những ưu / nhược điểm khác mà tôi không phát hiện ra ngay bây giờ, do đó tôi hỏi ý kiến ​​từ những người có kinh nghiệm hơn.


1
Phương pháp nào bạn đã sử dụng cuối cùng?
Johan

@johan Tôi đã chọn phương thức đầu tiên trong đó tôi có một hàng cho mỗi giao dịch. Tôi đã thêm các kích hoạt để cập nhật số dư chính xác cho từng tài khoản liên quan đến giao dịch (khi giao dịch được thêm, cập nhật hoặc xóa), vì vậy điều này giải quyết vấn đề chính của tôi với phương thức này.
Dmitry Kudryavtsev

Câu trả lời:


5

Thật vậy, lược đồ kế toán một hàng được đề xuất cho phép thực hiện kế toán nhập kép kép (để luôn chỉ định tài khoản được ghi nợ và ghi có) mà không đưa ra sự dư thừa của dữ liệu "số tiền".

Lược đồ một hàng cung cấp cho bạn một triển khai của một mục nhập kép cân bằng khi xây dựng, do đó không thể bao giờ "mất thăng bằng". Máy có thể tính toán lại các sổ cái khi đang bay.

Bạn phải chọn 2 thay vì một để lấy sổ cái.

Lưu ý, bên cạnh phân tách giao dịch, có các giao dịch khác như ngoại hối có thể kết thúc bằng 2 bản ghi thay vì 4. Tất cả phụ thuộc vào việc bạn có chuẩn hóa một chút chỉ cần nhập 4 giao dịch với mô tả tương tự.

Bạn có thể ngăn việc nhập hoặc sửa đổi bất kỳ giao dịch nào để duy trì dấu vết kiểm toán, điều này là bắt buộc nếu bạn muốn có thể kiểm toán nhật ký giao dịch.

Dường như trong luồng trên, đối với CPA, "hoàn toàn chuẩn hóa" dường như có nghĩa là các quy tắc được công nhận bởi tất cả các kế toán viên, trong khi đối với lập trình viên, nó có một ý nghĩa khác, rằng không có dữ liệu dẫn xuất hoặc dự phòng được lưu trữ.

Tất cả những gì có trong dữ liệu kế toán là một tập hợp các giao dịch cung cấp số tiền và các tài khoản mà chúng chảy và cùng với ngày của chúng, một số mô tả (và các tài liệu đính kèm khác). Sổ cái và số dư là các chế độ xem đơn giản xuất phát từ dữ liệu giao dịch này bằng cách tính tổng.


1
Tôi thích cách tiếp cận đơn giản ... "Tất cả chỉ có dữ liệu kế toán là một tập hợp các giao dịch cung cấp số tiền và các tài khoản mà chúng chảy qua, cùng với ngày của chúng, một số mô tả" Vâng. Chúng ta đừng quá phức tạp.
Charles Harmon

Tôi thích rằng bạn khuyên không nên sửa đổi hồ sơ giao dịch. Khi một bản ghi được tạo ra, nó được đúc bằng đá. Đó là lý do tại sao chúng tôi có ghi chú tín dụng và ghi nợ và các phương pháp kế toán phù hợp khác để khắc phục các lỗi đó
peter

17

Một tạp chí là một danh sách tự thời gian của tất cả các giao dịch của một loại cụ thể cho một hệ thống kế toán. Dưới đây là một bản trình bày cổ điển trên sổ cái của một Tạp chí Bán hàng (trên Tài khoản) đơn giản:

nhập mô tả hình ảnh ở đây

Lưu ý rằng mỗi dòng là một giao dịch, với Tổng số Nợ = Tổng số Tín dụng; và mọi giao dịch đều đạt ba tài khoản giống nhau. Nhật ký bán hàng bằng tiền mặt sẽ trông tương tự nhưng thay thế cột Ghi nợ khoản phải thu bằng một khoản ghi nợ tiền mặt có nhãn . Một Cash Giải ngân Tạp chí sẽ có một cột đầu tiên dán nhãn tín dụng tiền và các cột bổ sung như Accounts Payable NợChi phí nhân viên Debit .

Bài thuyết trình này là tiêu chuẩn trong hàng trăm năm cho đến khi máy tính cá nhân trở nên có giá cả phải chăng vài thập kỷ trước. Nó có một lợi thế đáng kể là dễ dàng xác minh rằng mọi giao dịch đều được cân bằng bằng cách kiểm tra từng hàng. Tương tự, trước khi đăng một trang của giao dịch đó lên Sổ cái, tổng số trang có thể được xác minh tương tự. Đó là một mô hình xử lý hàng loạt được sử dụng trong nhiều hệ thống kế toán.

Dễ dàng thấy rằng mô hình giấy này có những nhược điểm đáng kể khi được sao chép theo nghĩa đen sang một hệ thống tự động:

  1. Cấu trúc dữ liệu là một cấu trúc xoay vòng, trong khi kinh nghiệm cho thấy rằng nó đơn giản hơn nhiều (cũng mạnh mẽ hơn và dễ dàng xác minh hơn) để lập trình chống lại cấu trúc dữ liệu gấp; và
  2. Bởi vì mỗi Tạp chí chuyên biệt đánh vào một tập hợp các tài khoản khác nhau, mỗi Tạp chí như vậy sẽ phải được thiết kế và lập trình riêng, một hoạt động dễ bị lãng phí và dễ bị lỗi.

Vì những lý do này, thông thường nên sử dụng thiết kế Tạp chí chuyên ngành làm giao diện cho hệ thống kế toán, nhưng để thiết kế cấu trúc dữ liệu có thể là kho lưu trữ số cho nhiều tạp chí. Trong một RDBMS hiện đại này có lợi thế tiềm năng rằng General Ledger , và ngay cả những chuyên subledgers , có thể trở thành Indexed xem trên Journal, hoàn toàn loại bỏ các yêu cầu để mã một quá trình viết bài (bước nơi giao dịch Journal bị khóa và có tài khoản của mình tổng số được sao chép vào các sổ cái khác nhau).

Bất kể thiết kế dữ liệu nào bạn kết thúc, điều quan trọng là phải có một Mục đăng bài duy nhất cho từng loại giao dịch (tức là mỗi Tạp chí chuyên ngành trong hệ thống giấy tương đương) nơi thực hiện kiểm tra số dư.


Quan điểm của tôi là cả hai cách tiếp cận mà bạn đề xuất đều là những cơ chế không có căn cứ để ghi sổ kép. Điểm đầu tiên: Tạp chí là các bảng ghi một lần vì những lý do rất tốt. Đôi khi, hai bảng ảo Các mục nhập đang chờ xử lý và các mục đã đăng được sắp xếp chung trong một cấu trúc dữ liệu, nhưng bit IsPosted luôn chỉ ghi và hệ thống phải đảm bảo duy trì tính chất chỉ đọc của các bản ghi Entries đã đăng.

Cách kế toán đã đăng Tạp chí trong 800 năm qua là hoàn toàn bình thường . Sự khác biệt duy nhất giữa bản trình bày trên giấy và bản trình bày điện tử âm thanh là cấu trúc bảng gấp lại thuận tiện hơn trong trường hợp sau trong khi cấu trúc bảng có trục trong trường hợp trước đây, điều này có ý nghĩa nhất khi xử lý song song cao - nghĩa là nhiều nhân viên duy trì một số lượng nhỏ hoặc một số tạp chí chuyên ngành. Chỉ có Bộ điều khiển trong lịch sử mới có quyền cho Nhật ký chung.

Lưu ý cẩn thận rằng ở trên tôi đã chỉ định rằng Tạp chí Entries được chuẩn hóa hoàn toàn; Tạp chí Entries là một bản ghi theo thời gian của tất cả các giao dịch, được nhóm trong Tạp chí cụ thể cho từng loại giao dịch. Việc đăng các mục nhật ký lên Sổ cái là một nỗ lực riêng biệt và, trong khi tự mình được chuẩn hóa hoàn toàn, là một bản sao dự phòng của các mục nhật ký trong đó tất cả các giao dịch được tóm tắt (Sổ cái chung) hoặc chi tiết (Sổ cái phụ) theo tài khoản. Cả Tạp chí và Sổ cái đều sử dụng sổ sách kế toán kép một cách độc lập.

@Codism Bất kỳ hệ thống kế toán, DEB hoặc SEB, cung cấp cho bạn báo cáo tổng quát cho tất cả các tài khoản được ghi lại . Lưu ý rằng, trong nội bộ, một sổ cái phụ theo định nghĩa là một hồ sơ sổ sách kế toán đơn; phía bên kia là (các) tài khoản kiểm soát tương ứng trên Bảng cân đối kế toán. DEB đảm bảo rằng cho mỗi đô la tài sản có một kỷ lục chính xác của tuyên bố kinh doanh trên tài sản , tức là bình đẳng trong tài sản cho dù đó là một vốn nợ (hay còn gọi là trách nhiệm pháp lý) hoặc chủ sở hữu quyền sở hữu , và trong những ưu tiên của những tuyên bố nếu tổ chức trở nên mất khả năng thanh toán.


5

Tôi có thể đề nghị bạn hãy xem kho báu của phần mềm Nguồn mở ngoài khu vực này không?

Một Google " phần mềm kế toán kép nguồn mở " đưa ra một số cách điều tra đầy hứa hẹn.

Bạn có thể xem gói kế toán GNU tại đây , một vài trang web đánh giá ( 1 & 2 ) và cuối cùng là wiki phần mềm kế toán với một phần trên Phần mềm miễn phí.

Tôi chắc chắn rằng bằng cách kiểm tra một số mã nguồn và lược đồ F / LOSS, bạn có thể nhận được một số gợi ý và chỉ dẫn tốt về cách viết lược đồ và / hoặc phần mềm phù hợp với nhu cầu cụ thể của riêng bạn.


1

Tôi có một hệ thống thực hiện hai dòng và nhiều thách thức của nó hơn là có các tài khoản dòng đơn. Đầu tiên tôi đã gặp các trường hợp chỉ có một dòng bị đẩy như bên ghi nợ, dẫn đến tài khoản bị mất cân bằng. Ngay cả khi không thực hiện các kiểm soát thích hợp về cam kết và khôi phục, điều này sẽ không xảy ra trong một tài khoản dòng đơn. cuối cùng, db của bạn tăng trưởng với tốc độ tăng trưởng gấp đôi, dòng gửi thứ hai của bạn sẽ có rất nhiều thông tin trùng lặp, sự khác biệt duy nhất là tài khoản thứ hai. Sẽ khuyên giữ lại, tài khoản một dòng, đang đi đến tuyến đường đó ..

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.