The semantics of this are a little bit tricky: we want, if we come
across a transaction with exactly the given UUID, to set the
transaction's payee to be the specified one.
We need to set that payee before the first post in the transaction is
parsed, otherwise that post will inherit the wrong payee; however, we
need to do it after the transaction's tags have been parsed. The
implementation as it is in this commit is potentially a little
wasteful, if there are post-like (non-comment non-assertion) entries
in the transaction that don't successfully parse as posts.
For example, consider the following automated transaction:
= /Food/
; Next Date:: date + 10
(Expenses:Tax) 1.00
; Next Date:: date + 20
This will add a metadata field named 'Next Date' to the _matching
posting_, with a value that is 10 days later than that posting. It will
also generate a new posting for that transaction, whose amount is the
same as the matching posting. Further, it will add a 'Next Date'
metadata tag to the _generated posting_ whose value is 20 days later
than the date of the matching posting.
The payee directive allows for transformation of payee names during the
parsing of a Ledger file. This means you can record the payee name in
one form, but always have it reported in another form. The syntax is
(and will be):
payee PAYEE_NAME REGEXP
or
payee PAYEE_NAME
REGEXP1
REGEXP2
...
The account directive sets the account automatically based on the payee
iff the base account name is Unknown. For example, if you have a bunch
of transaction in Expenses:Unknown, you can assign accounts for several
automatically using:
account ACCOUNT_NAME PAYEE_REGEXP
or
account ACCOUNT_NAME
PAYEE_REGEXP1
PAYEE_REGEXP2
...
When enabled, if any accounts or commodities are seen in an uncleared
transaction, which were not seen previously in a cleared or pending
transaction or a textual directive dealing with accounts or commodities,
a warning is generated about the unknown item.
