How to use account_base

[Igbanam Ogbuluijah]


account_base — from man ledger — is an expression to "Return the base account, i.e. everything after the last account delimiter ':'".

How do I use this within a ledger?

Use case: I want to record tax for sales per customer.

= ^Income
    Liabilities:Tax:$account  -0.1
    $account                   0.1

2024-07-04 * Sale
    Assets    10 USD
    Income:Customer A

This results in a Liabilities:Tax:Income:Customer A account automatically created. What I would like to end up with is Liabilities:Tax:Customer A — is this possible?

Thanks

- Igbanam

[John Wiegley]

I think you would then use $account_base?

John

--

---
You received this message because you are subscribed to the Google Groups "Ledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ledger-cli/CAOmRJrdYZq_mHEO5QXZQurXTLrX6X5f6bORN1TCWZui27bZ%2BOQ%40mail.gmail.com.

[Igbanam Ogbuluijah]

If it's meant to work this way, then there may be a bug somewhere.

With

= ^Income
    Liabilities:Tax:$account_base  -0.1

    $account                   0.1

2024-07-04 * Sale
    Assets    10 USD
    Income:Customer A

the bal query yields

              10 USD  Assets
             -11 USD  Income:Customer A
               1 USD  Liabilities:Tax:$account_base
--------------------
                   0

Wrapping it in braces — i.e $(account_base) or ($account_base) doesn't help either

Is $account_base meant to work within the ledger? If so, I could open an issue on Github and look into why it isn't working as should.

Best,

Igbanam

[John Wiegley]

>>>>> "IO" == Igbanam Ogbuluijah <xigb...@gmail.com> writes:

IO> If it's meant to work this way, then there may be a bug somewhere.

Aha, the support for $account is much more hard-coded than I had realized. It
doesn’t allow any expression after a $ sign, but /only/ $account. I’ve
attached the patch you need for your situation. There should of course be a
more general solution that allows $expr or ${expr} to be evaluated at that
point.

John

[Igbanam Ogbuluijah]

Good stuff! Thanks for the pointer, John. 

I'll sit with this over the weekend and come up with a proposal on what the feature-extension should look like. If we agree on that, I'll throw up an issue on Github and try to tinker through.

Igbanam

[John Wiegley]

>>>>> Igbanam Ogbuluijah <xigb...@gmail.com> writes:

> Good stuff! Thanks for the pointer, John.
>
> I'll sit with this over the weekend and come up with a proposal on what the
> feature-extension should look like. If we agree on that, I'll throw up an
> issue on Github and try to tinker through.

OK, here’s the “right” code: it accepts $expr — where expr can be any
identifier — and evaluates this expression in the context of the account of
the posting being matched against. Thus, $account and $account_base will have
the same meaning, but now derived from actual evaluation rather than
hard-coding the implementation of those two identifiers.

The true completion of this feature would be to also support “$(expr)”, where
nested parentheses are handled correctly, so that you can say “$(foo(123))”.

John

[Igbanam Ogbuluijah]

So… I was looking to do a PR for this, and I realized this feature already exists — just under a different syntax. You were right John. What's needed here may be an update to the documentation; not a code change.

The correct way to use expressions in the auto_xact account specification — without the patches you provided — is in the ledger below

= ^Income
    Liabilities:Tax:%(tag(/Tax/))  (10/110)
    $account                       (-10/110)

2024-07-04 * Sale
    ; Tax: General

    Assets    10 USD
    Income:Customer A

I used this example to show that complex expressions also works. With this accounts yields

Assets
Income:Customer A
Liabilities:Tax:General

Thank you!

Igbanam

[John Wiegley]

>>>>> Igbanam Ogbuluijah <xigb...@gmail.com> writes:

> So… I was looking to do a PR for this, and I realized this feature already
> exists — just under a different syntax. You were right John. What's needed
> here may be an update to the documentation; not a code change.

Ah, well that shows how unfortunate a syntactic choice it was. It’s easily
changed to $( instead of %(.

John

[Martin Michlmayr]

* John Wiegley <jwie...@gmail.com> [2024-07-05 16:18]:

> > So… I was looking to do a PR for this, and I realized this feature already
> > exists — just under a different syntax. You were right John. What's needed
> > here may be an update to the documentation; not a code change.
>
> Ah, well that shows how unfortunate a syntactic choice it was. It’s easily
> changed to $( instead of %(.

Would it make sense to support both?
--
Martin Michlmayr
https://www.cyrius.com/

[Igbanam Ogbuluijah]

Disclaimer: I'm a new enthusiast; so take my thoughts with a grain of salt.

I don't think supporting both would be good for Ledger. A trend I see in the Ledger docs is "Use <thing> for whatever you want it to mean." — but <thing> has to be defined. If Ledger begins to change along the lines of "You can use <thing1> <thing2> or <thing3> to depict/achieve the same thing", it risks expanding the surface area for potential tech debt without adding any real value.

My suggestion is for Ledger to pick a direction and stick to it. Either it continues with the `%(` syntax and updates the information in the docs, or it unifies the syntax with `$(` and releases a breaking change. Either choice is fine. I think they should be mutually exclusive.

Igbanam

[John Wiegley]

>>>>> "IO" == Igbanam Ogbuluijah <xigb...@gmail.com> writes:

IO> My suggestion is for Ledger to pick a direction and stick to it. Either it
IO> continues with the `%(` syntax and updates the information in the docs, or
IO> it unifies the syntax with `$(` and releases a breaking change. Either
IO> choice is fine. I think they should be mutually exclusive.

Normally with a change like this, the path would be:

1. Support both, but clearly state that ’%(’ is deprecate in the manual.
2. After a few releases, change ’%(’ to generate a deprecation warning.
3. After a few releases more, change ’%(’ to be a parsing error, with a note
that the syntax has changed to ’$(’.

John