Support expiry field

[tbm]

The expiry-months sort of works, but I'd like a much more accurate calculation of the expiration date.

I am thinking of creating a beancount plugin that would calculate the exact expiration date. That could calculate the exact expiry date and set the expiry metadata for the commodity, so fava_miler could make use of it.

Does that sound like a good approach to you? (If so, I can create a patch. I haven't though about the design of the beancount plugin yet, but that's a separate question)

[tbm]

I just realized there's one problem with this approach that I'm not sure how to solve.

If you set expiry-months for one commodity, and you have two accounts with that commodity (e.g. your partner and yourself) fava_miler will calculate it properly.

But setting one expiry for the commodity would be wrong. In this case, the expiry info would have to be per account and commodity, but I don't think that's possible.

I'm not sure what the right solution is.

[tbm]

Setting expiry_COMMODITY on the account metadata would work, but it's not 100% elegant (although not that ugly either).

[redstreet]

Isn't expiration for miles and points and such, commodity specific? For example, Hooli Airlines always expires in 18months from the last transaction. Your partner and yourself would use two separate accounts to track your respective miles, and each account will have separate expiry dates based on the latest transaction. That's how this plugin works already, so I may be failing to see what you're pointing at. Could you please explain?

I can see the need for expiry-days since some companies specify it in days, but that doesn't seem to be what you're asking?

[tbm]

For example, Hooli Airlines always expires in 18months from the last transaction.

The problem is that the rules can be much more complicated than this. I wanted to write a plugin that implements the exact expiration policies.

For example, BA has an expiration policy if 36 months, but transfers (you can transfer miles between BA, Iberia and Avios) do not change the expiration, so simply taking 36 months from the last transaction won't work.

Another example is that a lot of airlines and hotels have extended expiration to a certain date in the future due to COVID.

The idea was to write a plugin that knows the exact rules. My problem is that I'm not sure how to codify the calculated expiration date in order to communicate it to fava_miler. Adding to to metadata of the commodity would be one way, but this doesn't work if you have two accounts (you and partner) with the same commodity -- they may have different expiration dates.

[redstreet]

Ah, got it now, thank you for the explanation! If we make the assumptions that:

• the policy will not vary per commodity (eg: BA's policy is fixed)
• expiration dates are per account
• expiration dates are a function of transactions in a given account,

then here are some ideas:
Attaching metadata to transactions to signify that transaction should be ignored when calculating expiry. Eg:

2019-01-05 * "Transfer"
  miles_does_not_count_towards_expiry: True
  Assets:BA         -200000 BAMILE
  Assets:Iberia

A user could use a plugin to attach that metadata, or do it manually if it's simple. This solves your first problem.

The second problem is hopefully a rare exception, which can be solved by inserting a dummy (0 BAMILE) transaction at the appropriate date. Or perhaps a note transaction like so, which again, can be inserted manually or through a plugin:

2020-01-01 note Assets:BA "BA extended all mile expiry to Dec 2021 or later"
  miles_commodity: BAMILE
  miles_override_expiry_date_to: 2021-10-22  ; hard override
  miles_do_not_expire_until: 2021-12-31      ; min override instead of a hard override

These overrides would be per account, unless the metadata appeared in the commodity, where it would apply to the commodity regardless of account.

Of course, the latter option would require some changes to fava_miler, and I'd be happy to review a PR. What do you think?