| Anchor | ||||
|---|---|---|---|---|
|
...
Flagged position rules, also called pending trade rules, specify the criteria that the system uses to assign a pending status to transactions that require evaluation prior to processing. You define a set of flagged position rules to provide the criteria that the system uses to identify pending transactions. You can create flagged position rules at the entity, asset, message type, and event type level, using combinations of these criteria to create a rule. Multi-leg swap contracts, corporate actions, and interportfolio transfers are ineligible for pending transaction activity. You can also add flagged position rules for use in reporting alone.
Eagle provides two methods for adding flagged position rules. You can use the Add Flagged Position Rules - Held Positions Only option to create rules that mark individual positions as eligible for pending transaction activity. You can also use the Add Flagged Position Rules option to define flagged position rules based on general criteria that do not consider actual holdings.
...
When the system receives a transaction from an upstream system for an entity that is eligible for pending transaction activity, if the transaction: ■ Meets
- Meets the criteria specified in a flagged position rule and passes the Message Center panel edits that validate the transaction data, the system sets the transaction's Pending Trade Flag field (tag 3695) to Y, assigns the transaction's Pending Trade Status field (tag 3720) a value of Pending, and routes the transaction to the PENDING_TRADES table in the TRADES database for further evaluation. If you evaluate the transaction and it qualifies for processing, you can release it for processing by the STAR accounting engine. Or if the transaction does not qualify for processing, you can update the transaction with a Hold status, making it ineligible for processing by the STAR accounting engine. If the transaction is not released successfully, the system sends the failed transaction to the Workflow Manager repair queue. After you repair the failed transaction, you can submit it to the STAR accounting engine as part of normal STAR processing.
...
- Meets the criteria specified in a flagged position rule but does not pass the Message Center panel edits that validate the transaction data, the system sends the transaction to the Workflow Manager repair queue with a rejection status of Not Processed. After you repair the transaction, the system routes the transaction to the PENDING_TRADES table for further evaluation before it is processed in the STAR accounting engine.
...
- Does not meet the criteria specified in a flagged position rule, no pending transaction activity occurs. If the transaction passes the Message Center panel checks that validate the transaction data, the system routes the transaction directly to the STAR accounting engine for processing. Otherwise, it routes the transaction to the Workflow Manager repair queue as part of normal STAR processing.
...
- Is already identified as eligible for pending transaction processing because the incoming transaction's Pending Trade Flag field (tag 3695) has a value of Y, the system does not apply flagged positions rules and routes the transaction to the PENDING_TRADES table in the TRADES database for further evaluation. If the incoming transaction's Pending Trade Status field (tag 3720) has a value equal to a custom status code value, the system applies the custom status. Otherwise, if no status is provided on the incoming transaction, the system sets the status to Pending.
When the system processes a pending transaction, it assigns the entity's controlling basis to the transaction first, and then creates corresponding transactions for each additional accounting basis. If no controlling basis exists for the entity, it processes the entity's primary basis first.
If you track pending transaction activity, be aware that when you use the system to manually cancel a transaction for an entity eligible for pending trade activity, the system applies a pending status to that transaction so that you can evaluate the transaction. Specifically, if you process a transaction in the STAR accounting engine, and then use the system to manually cancel the trade, the system inserts a copy of the original transaction into the PENDING_TRADES table, sets the transaction's Pending Trade Flag field (tag 3695) to Y, and applies a pending status to the transaction. When you evaluate the pending transaction again after the cancellation, the pending transaction reflects values for the entity's controlling basis if one exists. Otherwise, it reflects the entity's primary basis. If you cancelled the transaction in error, this process enables you to evaluate the transaction and release it to the STAR accounting engine for processing, if appropriate. This process applies only to transactions manually cancelled using the Cancel Trade panel. It does not apply to transactions cancelled due to rollback and replay activity. And it does not apply to transactions associated with the Cancel Trades message stream.
You can evaluate pending transactions to determine if they qualify for release to the STAR accounting engine for processing. If a transaction does not quality for release to the STAR accounting engine, you can update the transaction to assign it a Hold status. If it does qualify, you can release it. The system provides two methods for releasing pending transactions.
- You can use the Update and Release - Transaction Level option to update and release individual transactions in a single step.
- You can use the Release - Position Level option to release groups of transactions.
If you need to update transactions prior to release, you can use the Update Transactions option. You can also list and manually delete transactions associated with pending transaction activity. In addition, you can create purge rules to purge data in the Pending Trades tables.