Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Transity – Plain Text Accounting

feram.io

Post reply on HN
Print view View original

101–110 of 141 posts

Re: Show HN: Transity – Plain Text Accounting

#101

Post by bestnameever »

adius wrote: post #73
madhadron wrote: post #49

There are several things wrong here: 1. The author doesn't understand bookkeeping. 2. The author doesn't somehow believes that emulated teletypes are a good substrate for building user interfaces. 3. The author has spent significant time writing a bookkeeping tool for his business instead of doing something that will move the business forward. If you're thinking about writing an open source accounting program, spend…

1. Feel free to back up your claim, otherwise I'm not sure how you come to that conclusion 2. It has a user interface … just not graphical 3. Well, I guess we just have different opinions on where forward is 4. I've been working with GnuCash, Ledger and Hledger and I've written several scripts to extend them (e.g. to support timestamps and not just dates, which shouldn't be asked too much for an accounting tool ), bu…

this just seems way more confusing to me than debits and credits.

Re: Show HN: Transity – Plain Text Accounting

#102

Post by captainmuon »

Mister_Snuggles wrote: post #33
adius wrote: post #21

Earlier quoted context omitted.

Transity isn't a single entry system. By using transactions to model financial flows it implicitly enforces that the amount is credited to the "from" account and debited to the "to" account. Therefore it's basically double entry by design. I'm really interested if someone can show me a use case where this system is less powerful / safe than a classic double entry system.

The problem is that this breaks down when faced with problems more complex than simple examples. What about cases where there are multiple "to" accounts? For example, you might go to Best Buy and purchase a computer and a video game. In this case, the "to" would be split between two separate accounts (assuming you do your books this way). This is a contrived example, but in the business world this type of transaction…

I don't know if it is implemented in this tool, but there is no reason that you could not have multiple "to" fields in a transaction.

In double bookkeeping, you must have balanced books, but you do not note which bookings occur together. The transactional scheme seems strictly superior because you automatically know which debits and credits or losses and gains go together. You automatically have balanced books. I think you sould be able to even generate double bookkeeping from transactional bookkeeping automatically.

Re: Show HN: Transity – Plain Text Accounting

#103

Post by smichael »

Jtsummers wrote: post #46
smichael wrote: post #42

Earlier quoted context omitted.

That's correct about hledger: a few reports make assumptions about the top level account names. Until the dev-droids make this customisable, account aliases can be a workaround.

Thanks for hledger. I haven't explored its capabilities fully, but I have it running on my laptop at all times (a window in my tmux config displays various reports on my accounts like current balance, uncleared balance, uncleared transactions, etc.). I find it helps me to be mindful of my money if it's only a couple keypresses away.

Same here! I keep live reports in a iterm2 hotkey window.

Re: Show HN: Transity – Plain Text Accounting

#104

Post by billfruit »

jessedhillon wrote: post #60
billfruit wrote: post #55

After trying to use GNU cash for some time, I got the feeling that a personal accounting app needs to be a web based service, to enable it to be used while on the move/travelling, because I found myself building up a huge backlog of entries to be made in to the system in these situations. After about a month of use, I gave up, since the overhead of jotting down transactions and later entering into the system. I doubt…

I work for Plaid. You can sign up and get a dev token that has sufficient permission to access your own bank accounts. Then you can download your transactions and format them for GNU Ledger or whichever other format you prefer.

Does it work for any bank in any country?

Re: Show HN: Transity – Plain Text Accounting

#105

Post by cup-of-tea »

djhworld wrote: post #70
cup-of-tea wrote: post #66

Earlier quoted context omitted.

I've written a tool that can import data from my various bank accounts and credit cards. It's semi-automatic. Uses machine learning to guess the correct account but I can quickly change it. I then put the finishing touches on by hand.

I was thinking of using ML for this approach too but tbh most of my transactions are predictable, just a simple hashmap of Payee->Account works just as well. Cleaning up the payees is the trickier part. I guess in cases like Amazon, where you might buy a plethora of things across different accounts, ML might be helpful

The payees in my case are numerous enough that a dictionary would be too much to maintain. I don't actually clean up the payees, although I have thought about it. At the moment I leave the payee string so that if I use register on my bank account, for example, it looks exactly like my bank statement. I generally don't care what shop I bought groceries at. Those payee strings also sometimes contain interesting information like the location of the shop, so I wouldn't want to lose that.

Re: Show HN: Transity – Plain Text Accounting

#106

Post by sly010 »

joyinsky wrote: post #75

Basically the problem here is that the author didn't care even a little to understand why accounting is done with a double entry system. Basically what he was trying to do here was a expense and income administrator with tags. That it's just a part of what bookkeeping and accounting is. Nice try. But you can't replace what works and what has been done for reliability and confidence since 1400 at least by the masters…

> You can't replace what works and what has been done for reliability and confidence since 1400 at least by the masters of trade.

I am not sure that is true. Isn't the world full of examples of quite the opposite? Especially because it's 1400 years old an because it was created for pen an paper work. We have computers now.

e.g. It used to be that companies have a handful of yearly profit/loss accounts and every year they "close the books" by transferring all balance to first profit/loss accounts then to equity. The financial year then starts with 0 profit an 0 loss. Afaik nobody does this anymore. Today you just keep all accounts running (don't "close them) and you generate repots by selecting a date range and let the computer calculate profits and losses for that range.

Besides, most commercial software already hides debit and credit from you. I would risk that most accountant don't know their debits and credits, it's just one of those things you learn at accounting school before you start working in the industry.

I agree one should not write an accounting system without understanding the full details and history of the domain, but I disagree that 1400 year history proves anything. In fact even after reading through the Pacioli Group article I still don't see the advantages. It's only advantage is that it makes it harder to make a mistake on paper.

Re: Show HN: Transity – Plain Text Accounting

#107

Post by callumlocke »

lquist wrote: post #26

CLI tools also have the advantage that their developers don't have to waste their time building and maintaining a useless GUI, but can instead use the time to improve the tool itself Maybe it's just me, but I stopped reading here b/c this language struck me as unnecessarily antagonistic. Just some feedback.

Stopped here also. Bad sign. Different tools for different jobs, no need to get emotional.

Re: Show HN: Transity – Plain Text Accounting

#108

Post by chris_wot »

kungtotte wrote: post #67
chris_wot wrote: post #50

Earlier quoted context omitted.

Agreed. If you haven't spent the time to understand what debits and credits are in a double-entry book keeping system, then you really shouldn't be trying to do accounting.

There's a large use case for simple personal bookkeeping that doesn't require double-entry accounting. Most people have some fixed recurring bills (insurance, rent, subscriptions, etc.), some variable recurring bills (utilities, etc.), standing payments like savings, and monthly spends like groceries. For them (myself included) something that lets you simply input recurring expenses and your income and show a running…

Which means you have to take out money from one account and transfer it into another. Which means that you need to understand that you must debit an expense as it decreases the owners equity credit balance, and then you must understand that it causes a credit on your bank account.

If you don't have this, then you won't be able to work out where you spent your $X amount of money.

Re: Show HN: Transity – Plain Text Accounting

#109

Post by Mister_Snuggles »

captainmuon wrote: post #102
Mister_Snuggles wrote: post #33

Earlier quoted context omitted.

The problem is that this breaks down when faced with problems more complex than simple examples. What about cases where there are multiple "to" accounts? For example, you might go to Best Buy and purchase a computer and a video game. In this case, the "to" would be split between two separate accounts (assuming you do your books this way). This is a contrived example, but in the business world this type of transaction…

I don't know if it is implemented in this tool, but there is no reason that you could not have multiple "to" fields in a transaction. In double bookkeeping, you must have balanced books, but you do not note which bookings occur together. The transactional scheme seems strictly superior because you automatically know which debits and credits or losses and gains go together. You automatically have balanced books. I thi…

The data model is somewhat secondary to the accounting model, however the data model has to be rich enough to support the accounting model.

In the traditional accounting model you have two major things:

1. The Ledger, which is the current state of your accounts. Generally each account is a page (or more) in the ledger which lists the debits and credits for that account.

2. The Journal Entries, which are the source documents that feed into the Ledger. Each Journal Entry groups all of the related debits and credits into one balanced entry. Since each Journal Entry is balanced, the Ledger ends up balanced.

Some software packages follow the accounting model very closely in their data model, others make some different choices. Some software, usually professional software, has a Ledger of accounts and uses Journal Entries to record activity in those accounts and requires that you run a process to post the journal entries. Professional software typically has modules for sales, purchasing, etc, that create the Journal Entries for you. Other software "fakes" some or all of the Ledger (typically the Asset/Liability accounts are in the Ledger and the Income/Expense accounts are "fake"), this type of software is usually aimed at home users. In both cases, all entries are done as a balanced journal entry with multiple lines.

Back to the accounting model:

A sale involving VAT, for example, might look like this in Journal Entry form:

    2018-06-06   Sold a haircut and shampoo to Bob
       Cash                   DR $21.00
         Haircut Sales                  CR $10.00
         Product Sales                  CR $10.00
         VAT Collected                  CR  $1.00
       Cost of Goods Sold     DR $8.00
         Inventory On Hand              CR $8.00
The first line is basically the header and it groups all of the entries related to that one sale. In this case, a customer paid cash for a product and a service. Because they bought a product, we also reduced the value of the inventory that we have on hand. And, because I'm in Canada, both of these items are eligible for VAT, so I had to record how much VAT I collected on behalf of the Government - I'll need these records later when it's time to pay up.

You can't really support that kind of entry if your data model has only one From field and only one To field - you've be creating five entries that aren't tied together. To support this, your data model needs to let you create one entry with multiple From and To fields. Once you get to this point, you're at the journal entry model that real accounting software uses.

Re: Show HN: Transity – Plain Text Accounting

#110

Post by gglitch »

maxerickson wrote: post #100
TeMPOraL wrote: post #62

Earlier quoted context omitted.

Somebody should write a proper "accounting for regular people" guide, because I too find those terms confusing - and also completely separated for any experience ever that I had with money. And it only gets worse from there, with "accounts receivable" and "accounts payable". Is that an American thing? I try not to fall into the trap of being proud of my own ignorance; but after many hours of reading introductory acco…

You'd have 5 main accounts there. Income:Job Asset:Bank1 Asset:Bank2 Expenses:whatever Liabilities:whatever And then each transaction moves the money from one account to another. Income->Asset, Asset->Expenses, etc. Value moves into the system from income, Expenses are (more or less) transactions where value moves out of the accounting system. You track your salary but probably not the hours you work and that you spe…

Thanks for this outline. I've been a happy user of Ledger for several months now, but have been stymied about how to model a scenario in which several family members pay me in advance for a bill we collectively owe that's payable in the future, and in which their payments end up in my checking account. I now see that I should have set up the future sum payment as a local, temporary liability, each family member's deposit payments to me as a local, temporary asset other than my checking account (making my local checking balance diverge from that reported by my bank -- but to my benefit!), then the future sum payment as a transfer from the local temporary asset to the local temporary liability, and bringing all accounts to their correct balances and realigning them with my bank.

So, again, thanks a lot for that last line, which helped me out.

Post reply on HN