Modulehledger-lib-1.52.4GHC2021
Hledger.Data.Transaction
A Transaction represents a movement of some commodity(ies) between two or more accounts. It consists of multiple account Postings which balance to zero, a date, and optional extras like description, cleared status, and tags.
Contents
Synopsis
- value nulltransaction
- value transaction
- value txnTieKnot
- value txnUntieKnot
- value hasRealPostings
- value realPostings
- value assignmentPostings
- value virtualPostings
- value balancedVirtualPostings
- value transactionsPostings
- value transactionTransformPostings
- value transactionApplyValuation
- value transactionToCost
- value transactionInferEquityPostings
- value transactionTagCostsAndEquityAndMaybeInferCosts
- value transactionApplyAliases
- value transactionMapPostings
- value transactionMapPostingAmounts
- value transactionAmounts
- value transactionCommodityStyles
- value transactionCommodityStylesWith
- value transactionNegate
- value partitionAndCheckConversionPostings
- value transactionAddTags
- value transactionAddHiddenAndMaybeVisibleTag
- data TransactionBalancingPrecision
- value payeeAndNoteFromDescription
- value payeeAndNoteFromDescription'
- value transactionDate2
- value transactionDateOrDate2
- value transactionPayee
- value transactionNote
- value showTransaction
- value showTransactionOneLineAmounts
- value showTransactionLineFirstPart
- value transactionFile
- value annotateErrorWithTransaction
- value tests_Transaction
- Packagehledger-lib-1.52.4
- Exports38
- LanguageGHC2021
- LicenceGPL-3.0-or-later
- SourceTransaction.hs
Transaction
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.
operations
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.
helpers
How to determine the precision used for checking that transactions are balanced. See #2402.
Constructors
TBPOldLegacy behaviour, as in hledger <1.50, included to ease upgrades. use precision inferred from the whole journal, overridable by commodity directive or -c. Display precision is also transaction balancing precision; increasing it can break journal reading. Some valid journals are rejected until commodity directives are added. Small unbalanced remainders can be hidden, and in accounts that are never reconciled, can accumulate over time.
TBPExactSimpler, more robust behaviour, as in Ledger: use precision inferred from the transaction. Display precision and transaction balancing precision are independent; display precision never affects journal reading. Valid journals from ledger or beancount are accepted without needing commodity directives. Every imbalance in a transaction is visibly accounted for in that transaction's journal entry.
Instances6Bounded, Enum, Eq, Ord, Read, Show
Bounded TransactionBalancingPrecisionDefined in hledger-lib-1.52.4 · Hledger.Data.TransactionEnum TransactionBalancingPrecisionDefined in hledger-lib-1.52.4 · Hledger.Data.TransactionEq TransactionBalancingPrecisionDefined in hledger-lib-1.52.4 · Hledger.Data.TransactionOrd TransactionBalancingPrecisionDefined in hledger-lib-1.52.4 · Hledger.Data.TransactionRead TransactionBalancingPrecisionDefined in hledger-lib-1.52.4 · Hledger.Data.TransactionShow TransactionBalancingPrecisionDefined in hledger-lib-1.52.4 · Hledger.Data.Transaction
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.
date operations
transaction description parts
rendering
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.