@@ syntax in trades

[Alen Šiljak]

Could someone clarify the effects of @@ syntax in trades, compared to @ syntax? I have gone through a few documents related to trading and inventories, and none of them seem to contain the "@@" term.

The GnuCash export script spits out all trades in "100 VHY @@ 320 AUD" format. For this reason, queries and fava reports were confusing to me, since there is no cost basis nor the present/market value.

From this, I would conclude that the @@ syntax is not the same as @ one. The @ syntax adds the price - cost basis and establishes the lot. The @@ syntax does not seem to do that at all.

A potential problem in that regard will be getting the correct price due to the rounding. Looking at the GnuCash schema, the price is also not kept, similar to BeanCount. There is a Quantity (i.e. 100 units of account commodity, in this case VHY), and Value (320 units of transaction commodity, in this case AUD). This is my assumption and the whole process seems a bit convoluted.

In order to try to keep the compatibility, I will calculate the price during the export process. This will be limited to non-currency commodities only.

However, I'd like to know the effects of one vs the other approach to data export.

[Alen Šiljak]

Also, it seems that "@ 23.00 AUD" syntax is not the same as "{ 23.00 AUD}" during purchases.

Is {} the only valid syntax to be used for stock purchases, to identify a lot?

[Alen Šiljak]

It looked fairly simple initially. Now all the gritty details are popping up.

I set FIFO method to try to simplify but that raises different issues. Stock transfers, stock splits, automatic sales on stock splits, etc. all need to be adjusted manually.

It seems I will need to spend significant time adjusting the entries. After that, it will be important not to overwrite them on future exports. Here the import directives should come handy.

[Martin Michlmayr]

* Alen Šiljak <alen....@gmx.com> [2019-05-02 16:12]:

> Also, it seems that "@ 23.00 AUD" syntax is not the same as "{ 23.00
> AUD}" during purchases. Is {} the only valid syntax to be used for
> stock purchases, to identify a lot?

Yes.

ledger and beancount are different in this respect.

Everything after @ is a price. If you want to give a cost, use { }
Only the cost creates what you call a lot. BTW, beancount doesn't use
the "lot" terminology.

--
Martin Michlmayr
https://www.cyrius.com/

[Alen Šiljak]

In terms of terminology, I've seen Quicken, GnuCash, and Ledger use same terms for lots so I find it strange that Beancount would be reinventing the wheel in that respect. It could only cause confusion.

[Alen Šiljak]

I've added the {} syntax to the GnuCash export script but then ran into dozens of problems, which I'll need to resolve over the coming days.

I.e. share transfers are now wrong. These records will need to be modified manually in order to preserve the original cost and date. GnuCash has a mechanism for splitting the transactions into lots but I find it more trouble than it's worth.

Share splits also need to be adjusted manually. In GnuCash this is a simple position reduction. This will require lots of manual work in adjusting the cost for each position.

I will also need to read more about how these are done in Beancount and eventually add to the docs based on the discussions in the group.

[Martin Blais]

On Thu, May 2, 2019 at 6:28 PM Alen Šiljak <alen....@gmx.com> wrote:

Could someone clarify the effects of @@ syntax in trades, compared to @ syntax? I have gone through a few documents related to trading and inventories, and none of them seem to contain the "@@" term.

It's just a shorthand to specify the total price instead of the per unit price, when doing a price conversion.

  100 USD @@ 125 CAD

is the same as

  100 USD @ 125/100 CAD

The GnuCash export script spits out all trades in "100 VHY @@ 320 AUD" format. For this reason, queries and fava reports were confusing to me, since there is no cost basis nor the present/market value.

For cost basis you need to use the {...} syntax.

@ and @@ price conversions don't involve any cost basis.

They are two different types of things.

- Use price conversions when converting currencies

- Use cost basis when buying / selling investments

 

From this, I would conclude that the @@ syntax is not the same as @ one. The @ syntax adds the price - cost basis and establishes the lot. The @@ syntax does not seem to do that at all.

@ and @@ do almost the same thing - a price conversion.

{...} is how you attach cost basis to lots.

 

A potential problem in that regard will be getting the correct price due to the rounding. Looking at the GnuCash schema, the price is also not kept, similar to BeanCount. There is a Quantity (i.e. 100 units of account commodity, in this case VHY), and Value (320 units of transaction commodity, in this case AUD). This is my assumption and the whole process seems a bit convoluted.

In order to try to keep the compatibility, I will calculate the price during the export process. This will be limited to non-currency commodities only.

However, I'd like to know the effects of one vs the other approach to data export.

--
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 post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/82276fa7-f4f8-4683-83f5-92b93559224d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Blais]

It's not. I call them "lots" informally.  It's just terminology, there's no reinvention.

The data structure is a beancount.core.position.Position, and they are accumulated in a beancount.core.inventory.Inventory.

It could have been called a Lot too.

On Fri, May 3, 2019 at 4:27 AM Alen Šiljak <alen....@gmx.com> wrote:

In terms of terminology, I've seen Quicken, GnuCash, and Ledger use same terms for lots so I find it strange that Beancount would be reinventing the wheel in that respect. It could only cause confusion.

--
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 post to this group, send email to bean...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/5b7aa667-1ac3-4114-b4f6-51975da25a9e%40googlegroups.com.

[Martin Blais]

It's not entirely obvious to make an export with lots of cost basis, but essentially what you need to do to keep it simple is specify the cost basis when you purchase and when you sell and ideally also the date. Note that when you sell, the cost basis is the same as when you bought, it's not the price (lots of examples in docs).  Another way to do it if you have all the data in your exporter and you can pair up  buy / sell lots is to create a unique lot label and use that to identify the lots when you sell, that should work too.

Splits aren't handled implicitly. Beancount doesn't really provide any solution for this. You can either just double / halve the values on the date, or you can create a new currency to disambiguate them and make a conversion. I'm not super happy about this, but it's not a huge blocker for most people (including me). I think eventually some support for that could be added to do that better (e.g. report over time without kinks in the curves), but it's a bit of a rabbit hole.

--
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 post to this group, send email to bean...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/59bb2e86-bb11-47bc-baca-30e55dede0a3%40googlegroups.com.

[Alen Šiljak]

My real problem is that I have lots of small purchases over the years, and then one big transfer to another account. I believe most of my "sales" so far were due to funds, banks, and brokers going out of business.
So now I need to make decent adjustments to the source file to match the positions on those transfers or sales. I actually wish Beancount was already at the stage where it was bare bones flexible as ledger and all the constraints were introduced by plugins. With a default set of plugins it would be what it is today.
However, this would allow me to remove a few constraints until the source data is corrected.

Regarding the repricing, it is a rabbit hole. It would be great to have something like an effective date. For example, a stock is bought @ 10 in January and split 2:1 in July. The reports for February would still show the cost basis of 10 and the unrealised gain/loss based on February prices. But as of July it would use the new cost basis and the number of shares. However, for tax purposes, the positions still keep the January date. Perhaps this is already possible.

[Martin Blais]

On Sat, May 4, 2019 at 5:45 AM Alen Šiljak <alen....@gmx.com> wrote:

My real problem is that I have lots of small purchases over the years, and then one big transfer to another account. I believe most of my "sales" so far were due to funds, banks, and brokers going out of business.
So now I need to make decent adjustments to the source file to match the positions on those transfers or sales. I actually wish Beancount was already at the stage where it was bare bones flexible as ledger and all the constraints were introduced by plugins. With a default set of plugins it would be what it is today.
However, this would allow me to remove a few constraints until the source data is corrected.

You can achieve precisely this by setting the booking method from "STRICT" (the global default) to "NONE".

The NONE booking method disables booking constraints and devolves more or less to what Ledger does (only the total cost basis or number of units over all trades is meaningful).

You can set this per-account (see Open directive) or globally (option "booking_method").

Regarding the repricing, it is a rabbit hole. It would be great to have something like an effective date. For example, a stock is bought @ 10 in January and split 2:1 in July. The reports for February would still show the cost basis of 10 and the unrealised gain/loss based on February prices. But as of July it would use the new cost basis and the number of shares. However, for tax purposes, the positions still keep the January date. Perhaps this is already possible.

If you "close" a time period for reporting (read this intro doc to find out how I've mapped this concept to transform a stream of directives into a shortened one: https://docs.google.com/document/d/100tGcA4blh6KSXPRGCZpUlyxaRUwFHEvnz_k9DyZFn4/edit#heading=h.uqoebvl2qxjs) the February report should show the same thing regardless of what is inserted after that date.

 

--
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 post to this group, send email to bean...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/bf3d4fec-0238-47c1-913f-392c659e872f%40googlegroups.com.

[Alen Šiljak]

Wonderful! That's great news! Thanks a lot for this info. I've downloaded the PDF versions of a few documents and will read them again during the trip tonight. Will also try these options.

Other than that, is anyone aware of a Qif converter? If I proceed with Quicken transfer, I'll have to write or contribute to one.

[Martin Blais]

I keep a fork of qifparse with some bugfixes under 

https://github.com/blais/qifparse

Works well enough.

On Sat, May 4, 2019 at 10:33 AM Alen Šiljak <alen....@gmx.com> wrote:

Wonderful! That's great news! Thanks a lot for this info. I've downloaded the PDF versions of a few documents and will read them again during the trip tonight. Will also try these options.

Other than that, is anyone aware of a Qif converter? If I proceed with Quicken transfer, I'll have to write or contribute to one.

--
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 post to this group, send email to bean...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/c1f3512d-c0f0-4f43-99cc-bf0ceb2cc992%40googlegroups.com.

[Alen Šiljak]

Fantastic! Adding to

https://gitlab.com/alensiljak/pta-converters/blob/master/conversion.md

to have a look once I get to that stage.

[Alen Šiljak]

OK, got most of these sorted out.

I ran into an issue where the "option booking method" directive was in my options.bean file, which is imported into the file with only import statements.

That didn't work and it took a while to figure out that the directive is not being applied at all. I created an issue #392 (https://bitbucket.org/blais/beancount/issues/392/booking-method-not-applied-when-used-in) for that.

Fava seems to get quite confused when NONE is used with my converted file. Even though the share accounts are set to use the share as the commodity, quite a few balances are reported only in real currency (all the prices are available in price files).

The balances in shares are reported twice - once for positive and once for negative amounts.

I'm still figuring out how to show the share balance using bean-query. I get all the positions listed but I'd like to only get the total number for quick comparison of balances across applications.

Another thing I added to the todo list is bean-report ledger. If this preserves all the data, I'd opt to keep the main data file in beancount.

[Alen Šiljak]

I think I got most of the information with

bean-report book.bean holdings --by commodity

Some things look a bit weird (a few duplicate account/commodity rows, etc.) but this looks promising.