This view aggregates rows in idvFeesMatching by client and the two postings involved. It will thus normally give the current matched position between two postings. The exception that could arise in principle is if the same combination of postings ever occurred with the two posting references swapped around. Circumstances for this to happen have arisen on user databases.
The sum of the two amounts will always be zero. Hence the 'having' condition is sufficient to select significant matching only.
Type = Base view suitable for advanced end user use
ClientObjectType | The object type of the client object that the account is for |
ClientInternalId | The internal id of the client object that the account is for |
Posting1Year | This, and the next two columns, reference the first posting that is matched (as year, period and posting number). |
Posting1Period | See Posting1Year |
Posting1 | See Posting1Year |
AmountForPosting1 | The amount to be added to the matched amount on posting 1 as a result of this matching action |
Posting2Year | This, and the next two columns, reference the SECOND posting that is matched (as year, period and posting number). |
Posting2Period | See Posting2Year |
Posting2 | See Posting2Year |
AmountForPosting2 | The amount to be added to the matched amount on posting 2 as a result of this matching action |
NumActions | The number of separate matching actions that go to make up the net matching position |