Maintenance of Transactions

Action

Description

Archive

As a method of database maintenance, the archiving of transactions is a function that removes one or more transactions from the regular transaction catalog and moves it to the Archived Transaction Catalog. The data of the transaction is archived off either to the file system or to the database. When a transaction is archived, so are all of its associated attachments and transaction comments, regardless if the comment(s) has been suppressed.

As there are system rules to prevent the archiving of certain types of transactions until they are ‘complete’, a separate Archive Historical feature exists to archive off transactions that have the Transaction Status of Final Historical where those edits for being complete do not apply.

To facilitate more robust archiving, there is separate system processes for that action.

Unarchive

When one or more archived transactions need to be restored, this action returns the transaction to the regular transaction catalog and makes it available on all locations with transaction drill down capability.

To facilitate more robust unarchiving, there is separate system processes for that action.

Export

One or more transactions can be exported to an XML file. The export can be done with or without object attachments, and the attachments may be exported to a zip file or to a directory. When a transaction is exported, so are all of its associated attachments and transaction comments. However if the comment(s) has been suppressed, then the comment(s) is not exported with the transaction.

Import

One or more transactions can be imported from an XML file with a specific Transaction Phase based on the import mode specified in the XML file. When a transaction is imported, so are all of its associated transaction comments provided the comments do not include transaction version numbers. All comments with version numbers are ignored (not imported), so as to prevent replication of comments.

• Modification Drafts are created when the Mode is set to MOD (Modification). If new object attachments are present in the import XML file, then they are automatically imported, and if deleted object attachments are present, then they are deleted.

• Final transactions are created when the Mode is set to SE (Snapshot Entry)

• Template transactions are created when the Mode is set to TE (Template Entry)

The option exists to applying overrides at import time so that when this transaction is submitted later, overrideable errors that are encountered will be converted to warnings and the transaction can be processed successfully.

The option exists to bypassing approvals at import time so that when the transaction is submitted later, approvals are bypassed and the transaction is submitted directly to Final.

The option exists to specify a Transaction Status of Hold or Ready. A status of Hold will cause any automatic transaction processing to skip the imported transaction until that status is changed to Ready.

Transaction Custom Actions

Custom actions can be performed on one or more transactions based on the selection criteria specified to select transactions. Please note that due to the nature of this action a commit is issued after performing the action on each individual transaction.

Mark for Processing

One or more transactions can be marked for automatic system processing. This action changes the Transaction Status of the selected transactions to Ready. Please note that due to the nature of this action a commit is issued after performing the action on each individual transaction.

Hold for Processing

One or more transactions can be held from automatic system processing. This action changes the Transaction Status of the selected transactions to Held. Please note that due to the nature of this action a commit is issued after performing the action on each individual transaction.

Discard (Cancel)

One or more transactions can be discarded from the system if the Transaction Status is Draft or a Cancellation Draft created if the Transaction Status is Final. Please note that due to the nature of this action a commit is issued after performing the action on each individual transaction.

Edit

When this action is performed on one or more transactions, a modification draft version of each transaction is created from the existing final version. Please note that due to the nature of this action a commit is issued after performing the action on each individual transaction. Also, not all types of transactions allow a modification.

Deactivate

This action deactivates active transactions with a Transaction Phase of Final so that they cannot be cancelled, modified or referenced. Please note that due to the nature of this action a commit is issued after performing the action on each individual transaction.

Activate

This action activates active transactions with a Transaction Phase of Final so that they can be cancelled, modified or referenced. Please note that due to the nature of this action a commit is issued after performing the action on each individual transaction.

Validate

Submit

These actions will validate or submit one or more transactions. If the Transaction Status is not specified, only Ready transactions are validated. If the Transaction Phase is not specified, only Draft transactions are validated.

The option of trigging an exception report exists with the following formats for exception reports are supported.

• DETAILED – lists detailed information of processing of transactions including error messages

• FAILED_DOCS – list of transactions that failed processing

• PROCESSED_DOCS – list of transactions that were successful

• FAILED_LINES – transaction lines that failed processing

• DOCUMENT_STATUS - list of transactions that were successful, and details about the transaction lines and the business errors reported

Please note that due to the nature of this action a commit is issued after performing the action on each individual transaction.

Reject Pending

This action reject one or more pending transactions. If the Transaction Status of the transactions to be rejected is not specified, then by default, only Submitted transactions are selected for rejection. The Transaction Phase of transactions to be rejected can only be Pending by default. The user also has the option of specifying if an exception report must be generated while rejecting the transactions. This action would reject the transaction completely out of workflow regardless of approver, approval level or routing sequence level.

The action works only for Internal Workflow.

Approve

This action approves one or more transactions. The major use of this action is to hold all transactions that meet one or more criteria in hold for a period of time while users manually approve or reject the transactions. Then at an appointed time, all transactions have a final approval placed on them by this batch job and presumably move to a Final state. Before that time, no transactions go past a Pending state.