Parse a single-commodity amount, applying the default commodity if there is no commodity symbol;
optionally followed by, in any order:
a Ledger-style cost, Ledger-style valuation expression, and/or Ledger-style cost basis, which is one or more of
lot cost, lot date, and/or lot note (we loosely call this triple the lot's cost basis).
The cost basis makes it a lot rather than just an amount. Both cost basis info and valuation expression
are discarded for now.
The main amount's sign is significant; here are the possibilities and their interpretation.
Also imagine an optional VALUATIONEXPR added to any of these (omitted for clarity):
@
AMT -- acquiring an amount
AMT COST -- acquiring an amount at some cost
AMT COST COSTBASIS -- acquiring a lot at some cost, saving its cost basis
AMT COSTBASIS COST -- like the above
AMT COSTBASIS -- like the above with cost same as the cost basis
AMT -- releasing an amount
AMT SELLPRICE -- releasing an amount at some selling price
AMT SELLPRICE COSTBASISSEL -- releasing a lot at some selling price, selecting it by its cost basis
AMT COSTBASISSEL SELLPRICE -- like the above
AMT COSTBASISSEL -- like the above with selling price same as the selected lot's cost basis amount
COST/SELLPRICE can be UNITAMT, TOTALAMT, () UNITAMT, or (@@) TOTALAMT. The () are ignored.
COSTBASIS is one or more of {LOTCOST}, [LOTDATE], (LOTNOTE), in any order, with LOTCOST defaulting to COST.
COSTBASISSEL is one or more of {LOTCOST}, [LOTDATE], (LOTNOTE), in any order.
{LOTCOST} can be {UNITAMT}, {{TOTALAMT}}, {=UNITAMT}, or {{=TOTALAMT}}. The = is ignored.
VALUATIONEXPR can be ((VALUE AMOUNT)) or ((VALUE FUNCTION)).
@
Ledger amount syntax is really complex.
Rule of thumb: curly braces, parentheses, and/or square brackets
in an amount means a Ledger-style cost basis is involved.
To parse an amount's numeric quantity we need to know which character
represents a decimal mark. We find it in one of three ways:
If a decimal mark has been set explicitly in the journal parse state,
we use that
Or if the journal has a commodity declaration for the amount's commodity,
we get the decimal mark from that
Otherwise we will parse any valid decimal mark appearing in the
number, as long as the number appears well formed.
(This means we handle files with any supported decimal mark without configuration,
but it also allows different decimal marks in different amounts,
which is a bit too loose. There's an open issue.)