This post is another one related to feedback to my "Real Systems Do Extracts - Part 1" post.
A reader says: "Linking of transactions is indeed a great idea i.e. linking 0100 to 220 and a 420 if it was reversed or a 200 to a 420. Fully reversed transaction may not have a financial impact and may not need to be extracted or declined transactions don't need to get extracted."
Exactly. For each entry on the tranLog we have an ‘isExtractable’ check. Essentially, the check works by ruling out items that are not extractable. Those things are:
Authorization requests that were denied (i.e., if the internalResultCode != 0 for an item on the tranLog, then the transaction isn’t extractable)
Authorizations that were approved, then subsequently reversed (i.e., if the reversal Indicator != 0 and NOT NULL for an item on the tranLog, then the transaction isn’t extractable)
The reversals themselves (if you implement the online application correctly and efficiently, everything you need to know about the final state of a transaction is incorporated in the original, making the reversals superfluous to the extract process).
Non-financial transactions (e.g., you don’t extract balance inquiries – unless there’s a fee involved – because it has no financial impact on an account).
Classes of transactions that aren’t extractable (e.g., we have an implementation where we have a class of transactions called ‘Employee Verification’ – these have no financial impact and don’t get extracted)
Comments