Biểu diễn phương pháp ghi sổ kép bằng đồ thị có hướng
(matheusportela.com)- Dù thuật ngữ kế toán có thể xa lạ, nếu nhìn nó như một cấu trúc theo dõi tài khoản và số dư theo thời gian thì có thể hiểu ghi sổ kép như một mô hình dòng tiền
- Bảng chỉ ghi đè số dư hiện tại sẽ làm mất quá trình thay đổi, nhưng sổ cái thêm một mục mới mỗi khi phát sinh giao dịch để lưu lại lịch sử và dấu vết chỉnh sửa
- Ghi sổ đơn có thể đủ để ghi nhận biến động theo từng tài khoản, nhưng khi nhiều tài khoản cùng thay đổi thì cần nhóm các mục liên quan thành giao dịch để cho thấy nguồn đi và đích đến
- Với ghi sổ kép, ở mỗi giao dịch, số tiền đi ra và số tiền đi vào phải bằng nhau; điều kiện cân bằng này giúp phát hiện lỗi như một checksum trong kế toán thủ công
- Nếu xem tài khoản và giao dịch là các nút, còn các mục bên nợ và bên có là các cạnh có hướng, thì sổ sách sẽ trở thành một đồ thị có hướng lớn dần theo thời gian, và báo cáo tài chính cũng có thể được xem là cách trực quan hóa đồ thị đó
Mất thông tin gì khi chỉ ghi số dư
- Kế toán là việc theo dõi những đối tượng có thể đếm được theo thời gian, và ở đây tập trung vào dòng tiền
- Trong ví dụ, trạng thái ban đầu là ngày 1/1/2024 Alice có $100, Bob có $50
- Khi Alice trả Bob $20 tiền mua sách, số dư của Alice thành $80, còn Bob thành $70
- Ở đây, tài khoản (account) là nơi lưu trữ tiền, còn số dư (balance) là lượng tiền có trong tài khoản tại một thời điểm nhất định
- Nếu chỉ ghi đè số dư hiện tại, sẽ khó biết vì sao Alice lại có $80
- Là nhận $80 từ mức ban đầu $0
- Hay là tiêu $80 từ $10,000 xuống còn $9,920
- Cách chỉ giữ lại ảnh chụp số dư sẽ xóa mất quá trình biến động đã diễn ra
Sổ cái ghi sổ đơn và bản ghi bất biến
- Để giữ lại lịch sử thay đổi, mỗi khi phát sinh giao dịch thì không nên sửa giá trị cũ mà phải thêm một dòng mới
- Một mục trong sổ cái thường gồm các thông tin sau
- Description: mô tả giao dịch, đối tượng thanh toán, mã tham chiếu và các diễn giải mà con người có thể đọc được
- Date: ngày phát sinh giao dịch, cũng có thể dùng để nhóm theo kỳ như báo cáo theo tháng
- Balance: số dư tài khoản sau giao dịch; đây là thông tin trùng lặp nhưng hữu ích khi rà soát dữ liệu
- Mỗi dòng là một mục ghi (entry), và tập hợp các mục ghi của một tài khoản là sổ cái (ledger)
- Sổ cái của Alice ghi opening balance $100 vào ngày 1/1/2024, và bought book -$20 vào ngày 1/2/2024
- Sổ cái của Bob ghi opening balance $50 và sold book $20
- Cách này là hệ thống ghi sổ đơn (single-entry bookkeeping)
- Mỗi tài khoản có sổ cái riêng
- Ghi lại các mục ảnh hưởng đến từng tài khoản tại một thời điểm
- Có thể phù hợp với doanh nghiệp nhỏ hoặc tài chính cá nhân
Sổ cái hoạt động giống event sourcing
- Đặc điểm quan trọng của sổ cái là dữ liệu có tính bất biến (immutable)
- Khi một mục đã được ghi, nó không bị sửa để bảo toàn toàn bộ lịch sử
- Nếu ghi nhầm giá sách là $20 nhưng giá thực tế là $30, việc sửa dòng cũ sẽ làm mất số tiền ban đầu và cả việc đã từng chỉnh sửa
- Cách tốt hơn là thêm một mục mới để bù trừ mục cũ, rồi ghi lại mục đúng
- Hủy mục -$20 bằng một mục +$20
- Sau đó ghi mới mục -$30
- Số dư cuối cùng vẫn là $70, nhưng lỗi và lý do chỉnh sửa vẫn được giữ lại
- Cách này tương tự event sourcing trong khoa học máy tính
- Lưu lại các sự kiện phát sinh trong hệ thống
- Phát lại các sự kiện để tính ra trạng thái hiện tại
- Có thể dựng lại trạng thái tại một thời điểm bất kỳ
Khi nào cần ghi sổ kép
- Với các giao dịch mà nhiều tài khoản cùng thay đổi, chỉ dùng ghi sổ đơn sẽ khó thấy rõ mối quan hệ
- Khoản -$20 của Alice và +$20 của Bob là cùng một dòng tiền, nhưng nếu chỉ nhìn sổ cái đơn lẻ thì khó phân biệt với khả năng Bob nhận tiền từ Charlie
- Nếu nhóm các mục liên quan thành giao dịch (transaction) thì có thể thể hiện rõ chúng thuộc cùng một sự kiện
- Transaction 1: opening balance của Alice
- Transaction 2: opening balance của Bob
- Transaction 3: Alice mua sách từ Bob
- Giao dịch là tập hợp các mục liên quan ảnh hưởng đến những tài khoản khác nhau
- Ghi sổ kép liên kết các mục liên quan theo đơn vị giao dịch để có thể nhìn thấy dòng tiền giữa các tài khoản
Bên nợ, bên có và điều kiện cân bằng
- Kế toán truyền thống biểu diễn dòng tiền bằng hai cột debit và credit
- Credit: mục tiền đi ra khỏi tài khoản
- Debit: mục tiền đi vào tài khoản
- Khi Alice trả Bob $20, tài khoản của Alice được ghi $20 credit, còn tài khoản của Bob được ghi $20 debit
- Cách dùng credit/debit trên thẻ ngân hàng khác với cách dùng debit/credit trong kế toán
- Trong sổ giấy, người ta dùng dạng T-account với bên trái là debit và bên phải là credit
- Trong hệ thống máy tính, không nhất thiết phải giữ đúng hai cột đó
- Có thể dùng cột
Typevới giá trị Debit hoặc Credit và đểAmountriêng - Hoặc dùng một cột số tiền duy nhất, trong đó credit là số âm còn debit là số dương
- Có thể dùng cột
- So với thuật ngữ truyền thống, incoming money và outgoing money có thể là cách diễn đạt ít gây nhầm lẫn hơn
Giao dịch không bị giới hạn ở hai mục
- Nguyên tắc cốt lõi của ghi sổ kép là sau mỗi giao dịch, tổng tiền của toàn hệ thống không thay đổi
- Số dư của từng tài khoản có thể tăng hoặc giảm, nhưng tổng số dư của tất cả tài khoản phải giữ nguyên
- Ngay cả opening balance cũng phải có nguồn tiền đi ra từ đâu đó để cân bằng
- Trong ví dụ, thêm tài khoản Bank để ghi nhận $100 của Alice và $50 của Bob là tiền đi ra từ Bank
- Tài khoản Bank này là một dạng tài khoản tạm để giữ đúng quy tắc, trong thuật ngữ kế toán gọi là contra account
- Mọi giao dịch đều phải có tổng tiền đi ra bằng tổng tiền đi vào, và điều này hoạt động như một checksum giúp phát hiện lỗi trong kế toán thủ công
- Các giao dịch phức tạp hơn cũng có thể được mô hình hóa theo cùng nguyên tắc
- Alice trả Bob $20 và trả công ty thẻ tín dụng $2 phí ngoại tệ
- Bob nhận $20 từ Alice và trả $2 thuế bán hàng cho cơ quan thuế, cùng $1 phí cho công ty thẻ tín dụng
- Công ty thẻ tín dụng nhận $2 từ Alice và $1 từ Bob
- Cơ quan thuế nhận $2 từ Bob
- Trong trường hợp này, một Transaction 3 sẽ chứa đúng 8 mục
- “Double-entry” không có nghĩa là một giao dịch chỉ có hai mục, mà là nó có hai mặt: tiền đi ra và tiền đi vào
Xem sổ sách như một đồ thị có hướng
- Có thể xem ghi sổ kép như một mô hình đồ thị có hướng của dòng tiền
- Ánh xạ giữa kế toán và đồ thị như sau
- Tài khoản là nút của đồ thị
- Giao dịch cũng là một nút riêng
- Mục Credit là cạnh đi ra từ tài khoản tới giao dịch
- Mục Debit là cạnh đi vào từ giao dịch tới tài khoản
- Số tiền của mục là giá trị của cạnh
- Số dư tài khoản là tổng các cạnh đi vào trừ tổng các cạnh đi ra
- Transaction 1 chuyển $100 từ Bank sang Alice
- Transaction 2 chuyển $50 từ Bank sang Bob
- Transaction 3 chuyển $20 từ Alice sang Bob
- Với cách biểu diễn này, số dư của Alice là $80, còn Bob là $70
Lựa chọn mô hình hóa khi tách giao dịch phức tạp
- Nếu đưa cả phí và thuế vào cùng một giao dịch thì các cạnh của Transaction 3 sẽ trở nên nhiều và phức tạp
- Cũng có thể chia cùng dòng tiền đó thành các giao dịch nhỏ hơn
- Từ tài khoản Alice đi ra $22
- Bob nhận $19
- $3 còn lại đi đến công ty thẻ tín dụng
- $2 thuế bán hàng của Bob được xử lý ở một Transaction 4 riêng
- Dù nhóm giao dịch và mục ghi theo cách nào, số dư tài khoản cuối cùng vẫn có thể giống nhau
- Alice: $78
- Bob: $67
- Tax authority: $2
- Credit card company: $3
- Hệ thống kế toán đủ linh hoạt để đáp ứng nhiều yêu cầu khác nhau, và cách nhóm giao dịch cũng như mục ghi cần được quyết định sao cho phù hợp với doanh nghiệp
Báo cáo tài chính là cách trực quan hóa đồ thị
- Đồ thị sẽ lớn dần theo thời gian khi có thêm giao dịch mới
- Các thuộc tính cơ bản của đồ thị vẫn được giữ nguyên
- Tài khoản vẫn là các nút
- Giao dịch vẫn là các nút dùng để ép buộc dòng tiền
- Trong mỗi giao dịch, tổng tiền đi ra và tổng tiền đi vào phải bằng nhau
- Balance sheet, income statement, cash flow statement có thể được xem là các cách trực quan hóa đồ thị này
- Các phân loại như assets, liabilities, equity, income, expenses có thể được xem là nhóm nút trong đồ thị
- Nhìn từ góc độ đồ thị sẽ giúp hiểu trực quan hơn việc credit và debit làm tăng hay giảm số dư của từng nhóm phân loại như thế nào
1 bình luận
Các ý kiến trên Hacker News
Việc giải thích ghi sổ kép là “một mục cho Alice, một mục cho Bob” có vẻ là một lựa chọn kỳ lạ
Nếu có hai bên trong giao dịch thì việc nó có thể được ghi ở hai nơi là điều hiển nhiên, nhưng trọng tâm là mỗi bên của giao dịch cần hai mục. Nếu Alice mua sách từ Bob thì sẽ có bốn mục được tạo ra
Tôi hiểu đây là sự đơn giản hóa để giảng dạy, nhưng theo tôi đó là đơn giản hóa quá mức đến mức bỏ mất điểm cốt lõi
Ví dụ, khi thanh toán khoản phải trả bằng tiền mặt, có thể hình dung là gửi thông điệp đồng thời cho tác nhân Accounts Payable và tác nhân Cash; mỗi tác nhân dịch sự kiện đó thành Nợ/Có theo tính chất của mình để duy trì số dư. Theo góc nhìn này, ghi sổ kép gần với ý nghĩa rằng mỗi sự kiện phải được một số chẵn tác nhân hấp thụ đúng một lần
Nếu đang xây dựng rail thanh toán, bản thân sự kiện đó cũng có thể là một trong một cặp sự kiện được dẫn xuất từ một meta-event theo dõi ý định giao dịch. Trong kế toán, sẽ hữu ích hơn nếu xem cạnh của đồ thị không phải là tiền, mà là dữ liệu trong tầng các sự kiện dẫn xuất
Tuy vậy, bài gốc không làm rõ phép ví von này nhằm mục đích gì, và tôi lo rằng nó có thể làm tăng sự nhầm lẫn hơn là giảm bớt
Tôi không quan tâm đến sổ kế toán của Bob, mà chỉ muốn theo dõi sổ của tôi. Nếu tôi mua một cuốn sách, điều tôi muốn biết là trong sổ kế toán của tôi giao dịch này phải được ghi theo ghi sổ kép như thế nào
Hơn nữa, Bob đâu có đang làm kế toán, anh ấy đang bán sách mà ;-)
Nếu sửa bài này để giải thích đúng phần “double” thì nên làm thế nào? Liệu chỉ dùng góc nhìn của Bob hoặc Alice có đủ không?
Ví dụ, ngân hàng có thể kết luận rằng tôi có vẻ sẽ không trả được khoản vay và ghi giảm nó xuống 0 trong sổ của họ. Tôi vẫn có ý định trả nên có thể vẫn để khoản nợ trong sổ của mình. Ngân hàng tạo các mục liên quan trong hệ thống của họ và Nợ/Có khớp nhau, còn tôi không làm gì thì sổ của tôi vẫn cân bằng
Ghi sổ kép không liên quan đến chủ thể khác, mà chỉ liên quan đến sổ của chính mình
Tôi nghĩ vẻ đẹp và sức ảnh hưởng của kế toán bị đánh giá thấp
Chỉ với một số rất ít công thức, tức đẳng thức kế toán, cùng các báo cáo tài chính như báo cáo kết quả kinh doanh và bảng cân đối kế toán, ta có thể biểu diễn những gì diễn ra trong một tổ chức theo cách đại khái có thể so sánh được. Nó cũng gợi cảm giác như định lý cơ bản của giải tích hay nguyên lý trung tâm của sinh học
Kế toán cũng là nguồn gốc của toán học và chữ viết. Các nền văn minh Lưỡng Hà cổ đại ban đầu dùng “token kế toán” mô phỏng hình dạng của đối tượng để theo dõi hàng hóa, và có thể xem chúng đã phát triển thành chữ viết, chẳng hạn chữ tượng hình
Về sau, Al-Khwarizmi tạo ra Al-Jabr, tức algebra, để giải quyết luật thừa kế Hồi giáo; khi các quy tắc phân chia thừa kế trở thành phương trình, nhu cầu giải nhanh và chính xác xuất hiện. Cách giải phương trình bậc hai của Al-Khwarizmi là nguồn gốc của tên gọi “algorithm”
https://en.wikipedia.org/wiki/Accounting_identity
https://en.wikipedia.org/wiki/History_of_accounting
https://en.wikipedia.org/wiki/History_of_ancient_numeral_sys...
https://en.wikipedia.org/wiki/Al-Jabr
https://en.wikipedia.org/wiki/Al-Khwarizmi
Số âm được dùng lần đầu ở Trung Quốc khoảng thế kỷ 3, và ở châu Âu thì đến thế kỷ 16 vẫn chưa được dùng rộng rãi. Ghi sổ kép hiện đại được tạo ra ở châu Âu vào thế kỷ 14
Vì vậy, cách truyền thống tách riêng cột Nợ và cột Có, với các định nghĩa trông hơi kỳ lạ, là cách tốt nhất để vận hành chỉ bằng số dương
Có nhiều khía cạnh quan trọng của thiết kế tổ chức chỉ tương quan lỏng lẻo với báo cáo tài chính
Chỉ sau khi ghi sổ bén rễ ở mọi tầng lớp xã hội, số âm mới được chấp nhận là thực tế như số dương
Kế toán kép sẽ rất dễ hiểu nếu bỏ đi các thuật ngữ “credit” và “debit” nực cười
Cốt lõi là luôn giữ cho phương trình kế toán đúng. Công thức cơ bản là Equity = Assets - Liabilities; vì lợi nhuận rốt cuộc đi vào vốn chủ sở hữu, nên thành Equity + Income - Expenses = Assets - Liabilities. Sắp xếp lại để bỏ số âm thì thành Equity + Income + Liabilities = Assets + Expenses
Phương trình này phải luôn đúng; nếu không thì coi như tiền tự nhiên xuất hiện hoặc biến mất từ hư không. Vì vậy, nếu cộng tiền vào một tài khoản ở vế trái của phương trình, thì phải cộng cùng số tiền đó vào một tài khoản ở vế đối diện, hoặc trừ cùng số tiền đó ở cùng vế
Ví dụ, nếu bán nước chanh với giá 5 đô la, thì cộng 5 đô la vào Sales(Income) và cũng cộng 5 đô la vào Current Account(Assets)
Lý do “credit” và “debit” nực cười là vì định nghĩa của chúng bị đảo ngược tùy theo loại tài khoản, và cách dùng ngôn ngữ vô lý này là lý do chính khiến mọi người bối rối
Giảng viên lớp kế toán 100-level đã nói khá súc tích. Debit là mục ở cột bên trái, Credit là mục ở cột bên phải. Giao dịch đó có ý nghĩa gì đối với doanh nghiệp thì còn tùy vào tài khoản
Với người chưa học kế toán, cách dùng các thuật ngữ này cực kỳ gây rối, và nhiều câu trả lời cho người đang bối rối tuy đúng về mặt kỹ thuật nhưng đồng thời chẳng giúp ích mấy. Vì chúng mặc định rằng người đọc đã biết thuật ngữ
Câu hỏi “Số dư tăng lên mà tại sao tài khoản ngân hàng lại bị debited? Debit không phải là số âm sao? Có phải số dư tiền mặt đang được hiển thị là số âm không?” là một câu hỏi rất hay. Theo trực giác, direct debit là tiền bị rút ra, dùng debit card là tiêu tiền, debit nghe giống debt, nên người ta dễ nghĩ debit luôn là số âm
Cảnh mọi người như đang dùng những ngôn ngữ khác nhau cho cùng một từ vừa thú vị vừa bực bội. Đôi khi nó còn trôi sang kiểu bắt bẻ một cách diễn đạt nhỏ để chứng minh mình đúng
Vì từ góc nhìn của người chi 5 đô la cho nước chanh, họ hoàn toàn không đưa 5 đô la vào mục Sales của mình. Tôi vẫn chưa hiểu hoàn toàn sự nhầm lẫn mà bài viết và các bình luận đang nói đến chính xác là gì
credit là nguồn, debit là đích đến
Nếu lập hóa đơn cho khách hàng 10.000 euro, thì theo tỷ giá hiện tại sẽ phát sinh một cam kết trị giá 11.000 đô la. Khi đó credit 11.000 đô la vào tài khoản “Income: Customer A” là nguồn, và debit 11.000 đô la vào “Assets: Accounts Receivable”
Sau đó khách hàng trả tiền, nhưng tỷ giá biến động nên chỉ nhận được 10.500 đô la; cam kết ban đầu được ghi nhận 11.000 đô la là nguồn, vì vậy credit 11.000 đô la vào Accounts Receivable. Vì nhận được 10.500 đô la tiền mặt, debit 10.500 đô la vào cash, và để cân bằng debit với credit, debit 500 đô la vào “Expenses: Loss on Foreign Exchange”
Thông thường công ty không bị thanh lý vào mỗi ngày làm việc, vậy tại sao lại cố nhét 500 đô la đó vào một kịch bản thanh lý tức thời giả định? Chỉ cần ghi nhận theo cân bằng credit và debit là được
Có quá nhiều biểu đồ đặt biến độc lập trên trục Y
“Credit là mục tiền đi ra khỏi tài khoản, Debit là mục tiền đi vào tài khoản” không chính xác
Ý nghĩa của debit và credit thay đổi theo loại tài khoản: https://en.wikipedia.org/wiki/Debits_and_credits
Có lẽ có lý do để trở thành CPA cần nhiều hơn một môn học: https://www.accounting.com/careers/cpa/how-to-become/
Với tôi, nó trông giống một cách làm nhân đôi công việc để bắt một số lỗi nhất định vào thời con người nhập mục và tự tính toán. Bản thân điều đó thì có lý
Nhưng có lẽ vì lớn lên trong thế giới nơi máy tính làm mọi phép tính, nên nó trông như vi phạm nguyên tắc đừng lặp lại cùng một việc. Nếu ghi cùng một nội dung ở hai nơi, sớm muộn gì một trong hai cũng sai
Nếu kế toán được thiết kế trong thời hiện đại, tôi không nghĩ nó sẽ được làm như vậy. Việc tôi không phải kế toán và không hiểu không có nghĩa là hệ thống sai, nhưng sự bối rối khi nghe “credit làm giảm tài khoản tài sản” khiến tôi cảm thấy như có điều gì đó lệch lạc ở mức căn bản
Mục CR là sự gia tăng những gì công ty nợ, tức nghĩa vụ đối với chủ nợ hoặc cổ đông; còn mục DR là sự gia tăng những gì công ty có
Xem mối liên hệ với phương trình kế toán tại đây: https://news.ycombinator.com/item?id=32501707
Có vẻ có nhiều nhầm lẫn về các thuật ngữ credit/debit
Nếu muốn nghĩ đơn giản hơn theo góc nhìn hiện đại, chỉ cần nhớ rằng kế toán đã có từ lâu hơn rất nhiều so với việc sử dụng phổ biến số âm. Nếu hôm nay phát minh ra kế toán, rất có thể ta đã dùng tài khoản số dương/số âm thay vì tài khoản debit/credit
Đại số trên phép cộng bây giờ có vẻ tự nhiên với chúng ta, nhưng với một thương nhân bình thường năm 1604 thì không hề hiển nhiên, và số âm khi đó cũng không được đón nhận mấy
Điều quan trọng là giao dịch luôn có hai mặt và chúng là phép toán ngược của nhau. Rốt cuộc credit và debit là các phép toán ngược trên con số
Vì vậy có thể đặt ra quy tắc rằng nếu credit = debit thì giao dịch cân bằng. Theo cách hiện đại, cũng có thể xem là debit + credit = 0, nhưng khi hệ thống này được tạo ra, người ta không thích số âm, nên điều này giống một sự trùng hợp may mắn luôn đúng hơn là mục tiêu ban đầu
Sẽ hợp lý nếu nghĩ ngược lại, xem tiền mặt cầm trong tay là tài khoản mang tính dương nhất, tức có tính debit. Để ghi nhận chi phí, phải xử lý tài khoản tiền mặt theo chiều ngược lại nên ghi credit, và nơi tiền đi đến được ghi debit như bút toán đối ứng. Do đó tài khoản chi phí thường có số dư debit
Tiền mặt đến từ đâu? Nó đến từ doanh thu, và nếu muốn làm cho tiền mặt mang tính debit thì nguồn gốc phải mang tính credit để giao dịch không mất cân bằng. Vì vậy tài khoản doanh thu thường là tài khoản credit, tức thường có số dư âm hoặc “credit normal”
Điểm hay của hệ thống này là mọi giao dịch thường ngày đều quy về giao dịch cân bằng, và các tài khoản khả dĩ đều có tính chất số dư nhất quán, thường là credit hoặc debit. Thực sự rất tao nhã
Chỉ cần thuộc điều đó cùng phương trình kế toán là có thể suy ra số dư bình thường của mọi loại tài khoản còn lại
Khoảng một tháng trước, trên subreddit PTA tôi bắt đầu một cuộc thảo luận về việc làm cho ngữ pháp PTA trực quan hơn, và có người đề xuất dùng mũi tên để biểu thị “from”, tức tài khoản credit/số âm, và “to”, tức tài khoản debit/số dương. Con số không có dấu, cũng không dùng các thuật ngữ “credit” và “debit”, nên cảm giác trực quan hơn nhiều
https://www.reddit.com/r/plaintextaccounting/comments/1bh3x7...
Bối cảnh về số âm rất thú vị
Vẫn quá phức tạp. Bắt đầu lệch từ chỗ “hãy thêm cột Transaction vào bảng”
Không nên lưu dữ liệu tài khoản, mà nên lưu giao dịch. Tài khoản có thể tính ra từ đó. Bảng “Transactions” chỉ cần các trường Date, Amount, SourceAccount, TargetAccount, Description
Theo tôi, chính lúc đó mọi thứ mới trở nên đẹp. Cần bỏ thói quen suy nghĩ xoay quanh tài khoản chỉ vì đã quen với sao kê ngân hàng, và nghĩ theo dòng tiền
Tất nhiên như vậy quá đơn giản cho mục đích thuế. Có khi một giao dịch có nhiều nguồn hoặc nhiều đích đến, nên schema trên cần được điều chỉnh. Dù vậy, ý chính là cách tư duy phải khác
Đó là dấu hiệu cho thấy lập trình viên đã cố tỏ ra thông minh bằng cách duy trì tổng lũy kế thay vì tính từ các giao dịch gốc. Chỗ đó có rồng
Thiết kế tốt hơn là có bảng header và bảng detail
Header: TransactionID, Date, Description, các trường cần thiết như posting status hoặc reconciliation status
Detail: TransactionID, LineNumber, Account, Amount, Description, các trường cần thiết như số tham chiếu subledger
Như vậy một giao dịch có thể ảnh hưởng đến số lượng tài khoản tùy ý. Cuối cùng, giao dịch sẽ phản ánh một giao dịch kinh doanh có thể tác động đến nhiều tài khoản
Về chi tiết thì phức tạp hơn một chút, chẳng hạn đầu ra của mỗi lần chuyển phải bao gồm địa chỉ nguồn, nhưng ý tưởng là như nhau. Như đã nói ở nơi khác trong thread này, mỗi giao dịch cần có nhiều input và nhiều output
Tất cả giao dịch nằm trong một file văn bản thuần, và khi cần đánh giá thì từ đó tạo ra toàn bộ sổ cái ngay tại chỗ
Tôi không phải kế toán, nhưng trước đây đã quyết định học kế toán kép và kế toán cơ bản, và học được rất nhiều từ nhiều nơi, trong đó có các thread hay trên HN.
Bài viết này giải thích cách kế toán kép hoạt động và quá trình tôi nhận ra rằng nó là một đồ thị có hướng. Trên HN có nhiều người mê kế toán, nên nếu có chỗ nào sai, mong được phê bình hoặc góp ý chỉnh sửa.
https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
Ước gì các controller của tôi biến kết quả kinh doanh thành dạng luồng đồ họa như thế này. Đến một quy mô nào đó, kế toán trở nên khá khó, đến mức đội chính sách kế toán cần nhân sự cấp giáo sư.
Điều tôi học được từ thống kê là đồ họa rất quan trọng. Nếu dùng mức trừu tượng phù hợp, bất kỳ con số nào cũng có thể được biểu diễn thành đồ thị của các thành phần. Tôi có cảm giác như bỗng nhiên mọi thứ sáng tỏ.
Một bên là tiền đi vào hoặc đi ra, bên kia là sản phẩm hoặc dịch vụ. Đó chính là ghi sổ kép trong kế toán. Nghe có thể hiển nhiên và đơn giản, nhưng trong lĩnh vực của tôi không nhiều người hiểu điều này.
Bài viết hay, nhưng cần cẩn trọng khi định nghĩa lại những thuật ngữ đã có ý nghĩa được chấp nhận rộng rãi.
Đổi Debit/Credit thành Incoming/Outgoing trông như một loại thuật ngữ chuyên môn khác và có thể gây nhầm lẫn. Bất kỳ bookkeeper nào cũng hiểu credit cash và debit expense là gì.
Đổi chúng thành incoming/outgoing không giúp ích cho người thực sự làm việc đó, hay người phải giải thích công việc đó. Học hệ thuật ngữ đã hữu ích suốt vài trăm năm có giá trị hơn là dựa vào ẩn dụ.
Mỗi khi HN có thảo luận kiểu này, luôn có ai đó nói “rất đơn giản, credit chỉ là…”, rồi ngay lập tức có phản hồi “bạn hiểu ngược rồi, đơn giản là, credit là…”.
Tôi hoàn toàn không bận tâm nếu bỏ hẳn những thuật ngữ đó mãi mãi.
Khi tiền được credited, hoặc khi dùng credit card, ta có cảm giác tiền như xuất hiện từ đâu đó nên là điều tốt; còn debit nghe giống debt và khiến ta cảm thấy tiền của mình giảm đi nên là điều xấu.
Tôi biết thực ra tên gọi có lý do của nó, nhưng nếu một lĩnh vực cứ bám vào thuật ngữ chuyên môn phi trực giác, xung đột với mọi cách dùng mà người ngoài từng gặp, thì có lẽ nên dùng cách diễn đạt khác, ít trùng nghĩa hơn.
Nếu có thể trò chuyện bằng đúng thuật ngữ chuyên môn một cách chính xác, mức độ tin cậy sẽ tăng lên rất nhiều.
Tôi không rõ vì sao giải thích debit/credit, vốn là thuật ngữ kế toán, bằng ngôn ngữ bình dân lại trông như thuật ngữ chuyên môn. Có thể vì tôi là người bình thường.
Với người không có nền tảng kế toán, giải thích credit/debt là “tiền vào, tiền ra” trong ngữ cảnh bài viết này có vẻ đủ ổn. Ở đây định nghĩa “thật” của credit/debit có vận hành khác đi một cách có ý nghĩa không?
David P. Ellerman đưa ra một cách tiếp cận toán học với kế toán dựa trên thứ ông gọi là Pacioli group.
Phần tử tạm thời của Pacioli group có dạng x//y, trong đó x và y là các số nguyên không âm. x//y và u//v được xem là tương đương nếu tổng chéo x+v và y+u bằng nhau.
Phép toán nhóm là x//y + u//v = (x+u)//(y+v), phần tử nghịch đảo của x//y là y//x, và phần tử đơn vị là 0//0. Có thể xem thêm chi tiết, chẳng hạn trong tài liệu này: https://ellerman.org/wp-content/uploads/2012/12/DEB-Math-Mag...
Tôi có cảm giác ở đây đang bỏ lỡ điều gì đó. Việc xem lịch sử giao dịch như một đồ thị có hướng giúp ích gì?
Nó có điểm cải thiện nào so với thông lệ kế toán kép đã tồn tại hàng trăm năm không?
Với ví dụ đồ chơi chỉ vài giao dịch thì có vẻ còn chạy được, nhưng hãy tưởng tượng đồ thị sẽ trông thế nào khi giữa một cặp node có hàng chục, hàng trăm cạnh. Tôi cũng không biết các thuật toán đồ thị thông thường sẽ hữu dụng ở đâu.
Cảm giác như dùng kìm làm búa. Tất nhiên là có thể làm vậy, nhưng tại sao phải làm?
Thứ nhất, đây là một cách khác để hiểu khái niệm. Trong hầu hết trường hợp có thể không liên quan, nhưng ai biết được liệu một vấn đề kế toán khó có thể được giải bằng cách áp dụng lý thuyết đồ thị, hay ngược lại, một vấn đề lý thuyết đồ thị có thể được giải từ kế toán.
Thứ hai, đây là một cách khác để trực quan hóa luồng. Không phải ai cũng có hiểu biết tài chính hay cảm giác với con số tốt, nên thay vì đưa một bảng có các cột số và bắt họ suy luận dòng chảy từ số liệu, ta có thể biểu diễn nó theo không gian. Không phải công cụ nào cũng chỉ dành cho chuyên gia.
Xem toàn bộ lịch sử tích lũy như một đồ thị duy nhất có thể là quá mức, nhưng chỉ cần thêm bộ lọc theo ngày giao dịch cũng có thể đem lại insight mà các trực quan hóa khác bỏ sót. Nếu tham chiếu chéo với thông tin khác như vị trí, nó có thể còn hữu ích hơn.
Nó chưa xây dựng được tính chính đáng, và lời tác giả nói rằng hình thức trực quan hóa này giúp hiểu rõ hơn cũng bị suy yếu bởi lỗi phạm trù bộc lộ trong quá trình giải thích kế toán kép theo kiểu geek ngay từ đầu.
Hơn nữa, bài chỉ biểu diễn một giao dịch rất đơn giản. Tôi không biết trực quan hóa dựa trên đồ thị sẽ rút ra được những nội dung trừu tượng hơn như thế nào, chẳng hạn trường hợp khấu hao theo thuế khác với khấu hao theo kế toán, điều chỉnh lãi/lỗ ngoại hối, phân bổ franked dividends, PAYG, các khoản giữ hộ người khác, hay ghi nhận một phần doanh thu chưa thực hiện.
Kiểu như các kỹ sư muộn màng phát hiện ra những nguyên lý nền tảng vốn đã có sẵn trong lĩnh vực khác, khi phần mềm bắt đầu sao chép lĩnh vực đó.