In reference to some clojure talk about re-frame

i dont see it

If you ever want to complete the rest of the zoo, the Haskell Lens operators should suffice: https://hackage.haskell.org/package/lens-5.2/docs/Control-Lens-Operators.html

That doesn’t sound quite right. You have $150 in credits and only $50 in debits. Total credits and total debits should be equal for each transaction.

Credit cash for $100 sounds right. Cash is an asset account, so credit here means you’re reducing the asset by $100.

For the other two it depends on what you’re trying to track. If you’re expecting your partner to later reimburse you their $50 share, then the third entry should be a debut of $50 of accounts receivable (AR). AR is also an asset account, so a debit here is an increase in the amount you expect to receive.

When your partner pays you back, you would add a transaction to debit cash $50 (your cash increased) and credit AR $50 (the amount you expect to receive decreased)

Thanks a lot for clarifying it. I didn't know the concept of ARs before. I'll definitely look into it.

How would you store the payee of that transaction? I'm kinda losing information about the transaction, meaning if it doesn't have the Acme restaurant name on it, right? I'm struggling with this right now, and I'm starting to feel that my struggle maybe means I'm trying to force something into a model that isn't for it.

Ultimately it depends on what you want to track. A single expense account for “Expenses” is usually too coarse-grained. You may instead choose a sub-account to track “Entertainment Expenses” or something, so that you can keep them separate from other kinds of expenses.

If you ate at Moe’s a lot and you wanted to track how much you spent specifically at Moe’s you could create a sub-account just for that.

Typically, though, that level of detail would just be on the description for the original transaction, e.g. “Lunch with Pat at Moe’s”

Ok.. I think I got it. If I had an account to track expenses at Moe's, I would end up with something like the following, right? • Credit: Cash (assets) account $100 • Debit: Moe's (expenses) account $50 • Debit: Reimbursements (AR) account $50

> Ultimately it depends on what you want to track. I want to 1) push this information to other report applications that I don't know yet what data they will require and 2) start playing with report generation on my side. I felt that double-entry bookkeeping would enforce me to have most of the information but I may be wrong here since I don't know the domain.

Does it make sense from an accounting point of view to store the payee in the transaction itself, or should it be within the posting? I feel that storing it in the memo will complicate my life in creating reports later. Credit: Cash (assets) account $100 Debit: Eating Out (expenses) account $50 Debit: Reimbursements (AR) account $50 Payee: Moe's

I don’t think there’s one “right” way to do it. There’s nothing wrong with a “Moe’s” expense account, other than that you might end up with hundreds of such accounts. Or you could, as you suggest, have a separate Payee table and link to that (although I would probably link it to the expense entry rather than to the transaction as a whole). Both approaches would be legitimate double-entry accounting.

So, to validate, that would be: • Credit: Cash (assets) account $100 • Debit: Eating Out (expenses) account $50 / payee Moe's • Debit: Reimbursements (AR) account $50 / payee Moe's

That sounds reasonable. The AR entry is between you and your partner so it’s not clear why you would link that to Moe’s, but it’s not “wrong” if you have a use for it.

Because both postings sum the total spent on Moe's. That was my rationale. Otherwise, I would have to add the payee on the credit posting. But that feels weird as well.

It sounds like you’re trying to get the double-entry effect for payee as well, but the structure you describe doesn’t do that. The trick of double-entry accounting is that the debits and credits for each transaction sum to zero, so you can’t forget to post the AR entry, for example. The way you’re linking to payee doesn’t preserve that property. If you forget to link the AR to Moe’s, the transaction still balances.

If your objective is to explicitly track how much you’ve spent on Moe’s, it sounds to me that you just want a Moe’s expense sub-account.

> Debit: Reimbursements (AR) account $50 / payee Moe's > I agree that this seems quite odd. The AR debit is a record that your partner owes you money. Moe's has already received their cash. Now you have a receivable of $50 from Judy.

@UHD67JRL4 if you're not familiar with ledger, beancount, et al. I highly recommend checking them out. Plain text accounting applications have a simple way of representing double-entry bookkeeping and their docs related to accounting and application usage will probably help (both in understanding how to model your real-world transactions and also how to potentially model the domain in code). https://plaintextaccounting.org/#accounting

Thanks a lot, @U05476190 You're right. I have many articles from Beancount bookmarked. They're great (especially this https://beancount.github.io/docs/the_double_entry_counting_method.html about the basics of double-entry accounting). Sometimes, even going through them, I still need clarification about how to solve some problems: like the payee example shared here. I was looking at Fava (UI for Beancount early today). They seem to store the payee at the transaction level. See a transaction example https://fava.pythonanywhere.com/example-beancount-file/journal/?filter=payee%3A%22%5ECafe+Modagor%24%22+payee%3A%22%5ECafe+Modagor%24%22#context-0187b90b6513a827454fc62185682e2b. It's great to have some visuals when exploring a new concept.

I explored the PTA landscape a little (as an ex-YNAB user) and remember among others reading this article that may be relevant to your OP: https://beancount.github.io/docs/sharing_expenses_with_beancount.html

ah, you linked to the same doc. Oops :)

Using the system described by that beancount article, any cash accounts are shared assets. Personal names are attached only as a reference to ease tracking investments from the primary investor of a particular cash account. At some later date, you transfer to/from personal income accounts to clear out the balances owed by/to individual investors. So something like this for your original question: --- • Fund William's cash account -Assets:Cash:William $100 -Income:Cash:William -($100) • Dinner at Acme restaurant -Assets:Cash:William -($100) -Expenses:Food $100 (note: Judy funds her $50 under-investment into your cash account, which can then be used to pay back your over-investment into that shared cash asset account.) • Clear personal balances -Assets:Cash:William $50 -Income:Judy -($50) -Assets:Cash:William -($50) -Income:Cash:William $50 --- That article also tracked credit cards separately from actual cash, which would complicate this further (since you probably used a CC to pay for a $100 dinner). But this cash-only example shows the basic idea.

I see.. helpful nullpointer exceptions... https://hg.openjdk.org/jdk/jdk/rev/e3618c902d17

Maybe a possible alternative would be to add a flag to bb to output the exception in a machine-readable way?

The test tests a human-readable error report :)

But maybe I can just choose something that's not based on an NPE

Mmm, that reminds me of a pixel-by-pixel comparison of UI screenshots during tests... Personally, a huge anti-fan of those. :D IMO you end up testing the underlying low-level functionality more than your own stuff. But maybe it's more reasonable in this case than it sounds to me, dunno.

The more annoying part is that the native image seems to still have the old error message

I know what you're talking about but I've detected important regressions before using this test, so it's worth the pain to me

ugh, with a different exception:

(mismatch
  (expected
   "Message:  class clojure.lang.Keyword cannot be cast to class clojure.lang.Associative (clojure.lang.Keyword and clojure.lang.Associative are in unnamed module of loader 'app')")
  (actual
   "Message:  clojure.lang.Keyword cannot be cast to clojure.lang.Associative"))

some regexes to the rescue...

And those messages aren't standardized, are they? I.e. they're free to improve or "improve" them how they see fit, "they" being every maintainer of every JDK that you want to be compatible with.

The helpful error messages started as an option in jdk 13 or 14 I think and then became the defaults at some point?

> not based on an NPE Does your own RuntimeException give the same output? At least you could match the class then

I've solved the issue by using a couple of regexes: https://github.com/babashka/babashka/blob/3701dc03d79df3d580b9c42b39c0d24668df154b/test/babashka/error_test.clj#L12-L14