Make a simple transaction with the given date and postings.

Ensure a transaction's postings refer back to it, so that eg relatedPostings works right.

Ensure a transaction's postings do not refer back to it, so that eg recursiveSize and GHCI's :sprint work right.

Apply a transform function to this transaction's amounts.

Apply a specified valuation to this transaction's amounts, using the provided price oracle, commodity styles, and reference dates. See amountApplyValuation.

Maybe convert this Transactions amounts to cost.

For any costs in this Transaction which don't have associated equity conversion postings, generate and add those.

Find, associate, and tag the corresponding equity conversion postings and costful or potentially costful postings in this transaction. With a true addcosts argument, also generate and add any equivalent costs that are missing. The (previously detected) names of all equity conversion accounts should be provided.

For every pair of adjacent conversion postings, this first searches for a posting with equivalent cost (1). If no such posting is found, it then searches the costless postings, for one matching one of the conversion amounts (2). If either of these found a candidate posting, it is tagged with costPostingTagName. Then if in addcosts mode, if a costless posting was found, a cost equivalent to the conversion amounts is added to it.

The name reflects the complexity of this and its helpers; clarification is ongoing.

Apply some account aliases to all posting account names in the transaction, as described by accountNameApplyAliases. This can fail due to a bad replacement pattern in a regular expression alias.

Apply a transformation to a transaction's postings.

Apply a transformation to a transaction's posting amounts.

All posting amounts from this transaction, in order.

Get the canonical amount styles inferred from this transaction's amounts.

Like transactionCommodityStyles, but attach a particular rounding strategy to the styles, affecting how they will affect display precisions when applied.

Flip the sign of this transaction's posting amounts (and balance assertion amounts).

Add tags to a transaction, discarding any for which it already has a value. Note this does not add tags to the transaction's comment.

Add the given hidden tag to a transaction; and with a true argument, also add the equivalent visible tag to the transaction's tags and comment fields. If the transaction already has these tags (with any value), do nothing.

How to determine the precision used for checking that transactions are balanced. See #2402.

Parse a transaction's description into payee and note (aka narration) fields, assuming a convention of separating these with | (like Beancount). Ie, everything up to the first | is the payee, everything after it is the note. When there's no |, payee == note == description.

Like payeeAndNoteFromDescription, but if there's no | then payee is empty.

Render a journal transaction as text similar to the style of Ledger's print command.

Adapted from Ledger 2.x and 3.x standard format:

yyyy-mm-dd[ *][ CODE] description.........          [  ; comment...............]
    account name 1.....................  ...$amount1[  ; comment...............]
    account name 2.....................  ..$-amount1[  ; comment...............]

pcodewidth    = no limit -- 10          -- mimicking ledger layout.
pdescwidth    = no limit -- 20          -- I don't remember what these mean,
pacctwidth    = 35 minimum, no maximum  -- they were important at the time.
pamtwidth     = 11
pcommentwidth = no limit -- 22

The output will be parseable journal syntax. To facilitate this, postings with explicit multi-commodity amounts are displayed as multiple similar postings, one per commodity. (Normally does not happen with this function).

Like showTransaction, but explicit multi-commodity amounts are shown on one line, comma-separated. In this case the output will not be parseable journal syntax.

The file path from which this transaction was parsed.