New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusing interaction of balance assignments, inference, and txn modifiers #908

Closed
jkr opened this Issue Oct 17, 2018 · 11 comments

Comments

Projects
None yet
3 participants
@jkr
Contributor

jkr commented Oct 17, 2018

This might not be a bug -- it's the result of the order of operations. But if we decided it's working as intended it should probably be documented and trigger a warning, since it produces different results from ledger-cli. Consider the following journal, with an automated transaction to supply money from a budget envelope for payment from checking:

= ^expenses:foo
    budget:available   *-1
    assets:checking     *1

; 1. put some money in our budget

2018/10/17 * INITIAL
    budget:available   $100
    equity:opening

; $ hledger bal --auto
;                 $100  budget:available
;                $-100  equity:opening
; --------------------
;                    0


; 2. pay an expense. The automated transaction modifier will take
; money from the budget to pay it from checking.

2018/10/17 * SOME EXPENSE
    expenses:foo                                 $50
    assets:checking

;  $ hledger bal --auto
;                  $50  budget:available
;                $-100  equity:opening
;                  $50  expenses:foo
; --------------------
;                    0

; 3. move the remaining money in the available envelope to another
; envelope. Zero it out.

2018/10/17 * ASSERT
    budget:other
    budget:available                              =$0

; $ hledger bal --auto
; hledger: balance assertion error in "/home/jkr/practice/hledger/mwe_h.ledger" (line 37, column 51):
; in transaction:
; 2018/10/17 * ASSERT
;     budget:other                $100
;     budget:available     = $0
; after posting:
;     budget:available    $-100
; balance assertion details:
; date:       2018/10/17
; account:    budget:available
; commodity:  $
; calculated: $-50
; asserted:   0 (difference: +$50)

The issue here is that on the first run, before the transaction modifier is applied, hledger goes through and figures out the inferred amount from the balance assertion in the final transaction. So it figures out the amount to satisfy the assertion without any automated transactions applied. Note that it doesn't check assertions at the pre-modifier stage, so the following (assertion, but not assignment) works as expected:

= ^expenses:foo
    budget:available   *-1
    assets:checking     *1

; 1. put some money in our budget

2018/10/17 * INITIAL
    budget:available   $100
    equity:opening

; $ hledger bal --auto
;                 $100  budget:available
;                $-100  equity:opening
; --------------------
;                    0


; 2. pay an expense. The automated transaction modifier will take
; money from the budget to pay it from checking.

2018/10/17 * SOME EXPENSE
    expenses:foo                                 $50
    assets:checking

;  $ hledger bal --auto
;                  $50  budget:available
;                $-100  equity:opening
;                  $50  expenses:foo
; --------------------
;                    0

; 3. move the remaining money in the available envelope to another
; envelope. Zero it out.

2018/10/17 * ASSERT
    budget:other
    budget:available                              $-50=$0

; $ hledger bal --auto
;                  $50  budget:other
;                $-100  equity:opening
;                  $50  expenses:foo
; --------------------
;                    0

What this does mean is that you can't have two different running totals, both asserted correct, depending on whether you have transaction modifiers or not. Given that hledger does the whole journal and not txn-by-txn in parse order, I don't know if this is a problem that can be easily solved (though I'm sure there is a way). Perhaps it's enough to trigger a warning or error if (a) --auto is on AND (b) the txn modifier list is non-null AND (c) a balance assignment is discovered?

By the way, ledger-cli gets this wrong too: even if --actual is specified, it always infers from assertions as if automated transactions were applied.

@jkr

This comment has been minimized.

Contributor

jkr commented Oct 17, 2018

The more I think of it, the more it seems like there's no way to avoid counter-intuitive and unintended (even if somehow "correct") behavior with both balance assignments and transaction modifiers. So, the proposal would probably be to error out if auto_ is on, jtxnModifiers is non-null, and a balance assignment is found.

Would the same be true for periodic transactions/--forecast? I don't use it, but I imagine so.

@jkr jkr changed the title from Confusing interaction of inference, assertions, and txn modifiers to Confusing interaction of balance assignments, inference, and txn modifiers Oct 17, 2018

@jkr

This comment has been minimized.

Contributor

jkr commented Oct 17, 2018

The alternative would be, instead of applying all transaction modifiers at once in a map over the whole journal, moving it inside a transaction-level function.

@adept

This comment has been minimized.

Collaborator

adept commented Oct 17, 2018

@simonmichael

This comment has been minimized.

Owner

simonmichael commented Oct 17, 2018

Balance assignments create these kind of "impossible" situations, and we already give one "sorry not supported" error in some case. It's probably ok to add another one here (especially if we can be precise and fail only when there's a modifier affecting the account with the balance assignment). Caveat: I may be missing some details here.

@simonmichael

This comment has been minimized.

Owner

simonmichael commented Oct 17, 2018

The existing case: "postings may not have both a custom date and a balance assignment." (Journal.hs).

@simonmichael

This comment has been minimized.

Owner

simonmichael commented Oct 17, 2018

And/or, ensure balance assignment docs explain this situation.

@simonmichael simonmichael added the docs label Oct 17, 2018

@jkr

This comment has been minimized.

Contributor

jkr commented Oct 17, 2018

(especially if we can be precise and fail only when there's a modifier affecting the account with the balance assignment).

I'll give this a try.

@jkr

This comment has been minimized.

Contributor

jkr commented Oct 17, 2018

@adept

it makes sense to do them first and infer balances after.

See #893 -- the problem was that they couldn't be applied to transactions with inferred amounts (i.e., most basic two-posting transactions).

@adept

This comment has been minimized.

Collaborator

adept commented Oct 17, 2018

Ah, I see. Fair point. I wonder how much over-the-top would be to have two kinds of --auto postings: one that is applied before and one that is applied after balance inference? (and would this even solve the problem?)

@simonmichael

This comment has been minimized.

Owner

simonmichael commented Oct 18, 2018

Cf discussion on PR #912.

@simonmichael

This comment has been minimized.

Owner

simonmichael commented Dec 2, 2018

Resolved by disallowing transaction modifiers + balance assignments on the same account, #912.

@simonmichael simonmichael added the A BUG label Dec 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment