Struggling to get padding working

[Sagar Shankar]

Hi all, just started using Beancount a few days back, had been using Ledger before.

I'm struggling to get a pad transaction working in my new beancount ledger.

1. create the pad transaction

2023-08-01 pad Assets:Debt:Friend Equity:Opening-Balance

2. A few transactions on this Debt account follow

2023-08-29 * "Paid to cash"
   Assets:Savings -60.45 USD
   Assets:Debt:Friend

2023-08-29 * "Paid for xyz on my behalf"
   Assets:Debt:Friend -342.56 USD

   Expenses:Something

3. Then I do a balance assertion, to update the balance to the correct amount in my other account ledger

2023-08-31 balance Assets:Debt:Friend 1000 USD

And then I get the following errors in Fava:

Unused Pad entry

Balance failed for 'Assets:Debt:Friend': expected so and so USD != accumulated XYZ USD (ABC too little)

My understanding was that the pad directive would automatically update the Assets:Debt:Friend account to match the balance assertion, by making a suitable entry towards Equity. But it doesnt seem to be working that way.

Any advice appreciated!

Thanks,

Sagar

[Daniele Nicolodi]

On 01/09/23 00:58, Sagar Shankar wrote:
> Hi all, just started using Beancount a few days back, had been using
> Ledger before.
>
> I'm struggling to get a pad transaction working in my new beancount ledger.
>
> 1. create the pad transaction
> 2023-08-01 pad Assets:Debt:Friend Equity:Opening-Balance
>
> 2. A few transactions on this Debt account follow
> 2023-08-29 * "Paid to cash"

>    Assets:Savings-60.45 USD

>    Assets:Debt:Friend
>
> 2023-08-29 * "Paid for xyz on my behalf"

>    Assets:Debt:Friend-342.56 USD

>    Expenses:Something
>
> 3. Then I do a balance assertion, to update the balance to the correct
> amount in my other account ledger

> 2023-08-31 balance Assets:Debt:Friend1000 USD

>
> And then I get the following errors in Fava:
> Unused Pad entry
> Balance failed for 'Assets:Debt:Friend': expected so and so USD !=
> accumulated XYZ USD (ABC too little)

The example above works as expected for me. Your ledger must be invalid
for some other reason. Are these the only errors you get?

Cheers,
Dan

[Sagar Shankar]

Hi Dan,

Yes these are the only errors I get. Its confusing as you said because all the declarations seem completely fine to me

Thanks

Sagar

--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/nD-1y0eLDis/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/8921f2fc-1bcf-40c9-71e5-561fc2552aa1%40grinta.net.

[Daniele Nicolodi]

On 02/09/23 01:35, Sagar Shankar wrote:
> Hi Dan,
>
> Yes these are the only errors I get. Its confusing as you said because
> all the declarations seem completely fine to me

Can you share a minimal ledger that presents the problem? The one I
reconstructed from your description works just fine.

Cheers,
Dan

[Daniele Nicolodi]

For whom is following from home, Sagar shared a minimal example with me
in a private message (I don't know why, the example does not contain any
personal information, AFAICT).

The issue is this:

2023-08-31 pad Assets:Debt:Friend Equity:Opening-Balance

2023-08-31 balance Assets:Debt:Friend 10000 PHP

The pad and balance directives have the same date. Benancount orders
balance directives before any other directive. The balance directives
are to be intended as "start of the day balance". The order in which the
directives are processed is actually the reverse of how they are
written, and thus the balance assertion fails and the pad is unused.

Moving the balance assertion to 2023-09-01 fixes the issue.

Cheers,
Dan

On 02/09/23 01:35, Sagar Shankar wrote:

> <https://groups.google.com/d/topic/beancount/nD-1y0eLDis/unsubscribe>.

> To unsubscribe from this group and all its topics, send an email to
> beancount+...@googlegroups.com

> <mailto:beancount%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/beancount/8921f2fc-1bcf-40c9-71e5-561fc2552aa1%40grinta.net <https://groups.google.com/d/msgid/beancount/8921f2fc-1bcf-40c9-71e5-561fc2552aa1%40grinta.net>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Beancount" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beancount+...@googlegroups.com
> <mailto:beancount+...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/beancount/CAAP45exFubyccKf13hsmH3J9M6E%2BXUDXKAHc047rQDdJQ%3DgE5A%40mail.gmail.com <https://groups.google.com/d/msgid/beancount/CAAP45exFubyccKf13hsmH3J9M6E%2BXUDXKAHc047rQDdJQ%3DgE5A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Sagar Shankar]

Hi Dan,

Thanks a lot, this works now! A simple line on this in the pad documentation would be great for future reference of others

Regards

Sagar

[Daniele Nicolodi]

On 06/09/23 01:27, Sagar Shankar wrote:
> Hi Dan,
>

> Thanks a lot, this works now! A simple line on this in the pad
> documentation would be great for future reference of others

The behavior is due to the balance directive being treated specially
when sorting, not to the pad directive. Ordering is relevant for how all
directives are processed. You would have observed similar issues if you
had a transaction and a balance assertion on the same day. The order in
which directives are processed is documented. I don't think adding a
note to the documentation of each directive remembering the ordering
issue would make the documentation better.

Cheers,
Dan

[Eric Altendorf]

Booking decisions and validity are also order dependent.

Given how much the current documentation emphasizes that the order of entries doesn’t matter, this is IMHO confusing for new users.

I do believe the documentation would be improved by describing (somewhere) those cases where intra-day ordering *does* matter, and referencing that caveat in the places where ordering-invariance is claimed.

Cheers,
Dan

--

You received this message because you are subscribed to the Google Groups "Beancount" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/8204877c-9fcf-e0b9-f2b3-c11cad2a7cd3%40grinta.net.

[Daniele Nicolodi]

On 06/09/23 16:54, Eric Altendorf wrote:
>
>
> On Wed, Sep 6, 2023 at 04:00 Daniele Nicolodi <dan...@grinta.net
> <mailto:dan...@grinta.net>> wrote:
>
> On 06/09/23 01:27, Sagar Shankar wrote:
> > Hi Dan,
> >
> > Thanks a lot, this works now! A simple line on this in the pad
> > documentation would be great for future reference of others
>
> The behavior is due to the balance directive being treated specially
> when sorting, not to the pad directive. Ordering is relevant for how
> all
> directives are processed. You would have observed similar issues if you
> had a transaction and a balance assertion on the same day. The order in
> which directives are processed is documented. I don't think adding a
> note to the documentation of each directive remembering the ordering
> issue would make the documentation better.
>
>
> Booking decisions and validity are also order dependent.
>
> Given how much the current documentation emphasizes that the order of
> entries doesn’t matter, this is IMHO confusing for new users.

Can you please point to where the documentation states that ordering
does not matter? Obviously, order matters in a system designed to track
the changes of quantities (the balance of accounts) over time. What the
documentation states is that the order in which the entries appear in
the ledger does not matter, unless it is required to break ordering ties
of events registered on the same date. This is precisely documented.

> I do believe the documentation would be improved by describing
> (somewhere) those cases where intra-day ordering *does* matter, and
> referencing that caveat in the places where ordering-invariance is claimed.

Ordering of transactions registered on the same day has nothing to do
with the problem discussed in this thread.

However, if you have ideas on how the documentation can be improved,
feel free to send patches. Help is always welcome.

Cheers,
Dan

[nug get]

Hi Dan

Focusing on  (a design choince?)

>>The balance directives are to be intended as "start of the day balance"

Out of curiousity, what is the motivation behind making balances "beginning-of-day-balances"?

Would there be a point to challenge this?

In my reality, bank accounts provide the daily transactions and the month-end balance (=end-of-last-day-in-the-month-balance) at the last day of the month. Hence, I have to adjust the balance date each time to the next day to avoid balance mismatch errors.

Based on this experience, for me it is intuitively clear that a balance should apply to the end of a day, and accordingly I struggled with that in the beginning.

Thanks!

Best,

nugget

[Eric Altendorf]

Where does the documentation live in github?  I can look again for the spots that I personally found confusing in the past and reevaluate them given what you've said, and if I can still think of improvements, send patches.

Thanks,

Eric

 

Cheers,
Dan

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/2f5012cb-2ddd-b30f-aa00-7b5bf035e7e8%40grinta.net.

[Martin Blais]

Docs are in Google Docs itself, just make an edit request and I'll grant

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAFXPr0tNJn9VHJyp2mu3FMjqpAivmep3TdB1JtxV%2B_SiXAxUXQ%40mail.gmail.com.