The Cash Receipt transaction type has unique copy forward capabilities to correct an initial transaction with a subsequent transaction in lieu of modifying the initial transaction. This feature is not applicable for every implementation, so testing it with the deposit reconciliation processes and procedures in place along with collection reporting should be done before implementing.
When a Cash Receipt transaction is copied forward to another, it performs a liquidating reference of the original receipt and uses the COA Precedence settings on Transaction Control just as the receipt does when referencing a receivable. For this reason, the second transaction is often a different transaction code from the first so that configurations can be different for referencing rules and available accounting events. At a minimum the second transaction code should always require a reference, which is something that the main Cash Receipt transaction code does not typically require.
If appending COA not originally entered, the COA Precedence of the second transaction code needs to be Additional Codes Allowed.
If removing COA originally used that should not have been, the COA Precedence needs to be None so that the unwanted COA can be cleared. This also implies the Infer Codes field on Transaction Control is set to False. If not, the cleared field will only re-infer.
If the original collection was to a holding account, the final accounting event will not need the balance sheet account. Here, the scenario has a choice of using a non-accounting event type on the referencing accounting line to only liquidate the holding account and recording the final accounting on a new line. Alternatively, the final even type and COA can be entered on the referencing accounting line. This would entail many COA differences and a COA Precedence of None and Infer Codes of False.
A further step in this scenario would be the need to reference a receivable that should have initially been referenced. This scenario necessitate the new accounting line to reference the receivable and the non-accounting event type on the accounting line referencing the initial cash receipt.
The following should be noted about the copy forward:
Users creating the second receipt must at least have view-only security access to the Transaction Department used on the first receipt.
This cloned receipt does not have to be setup on Event Type Defaults (EFDFLT) because that page is not read in a receipt to receipt reference.
Only the Open Amount from an accounting line is copied forward.
The Reference Type against the 1st cash receipt will be Partial with the system changing that to Final if the entire open amount is being reclassified. When the scenario involves reclassifying the initial amount with multiple COA combinations, the Reference Type will be partial until the final reclassification. A System Tolerance (STOL) of CR to CR transaction types with zero overage and underrate limits is strongly suggested to control what happens to the initial cash.
Deposit data is not copied nor is the Print Deposit Ticket information updated because the target receipt is not a deposit but just a reclassification so total cash between the bank and Advantage is constant.
Copy forward action 1027 copies all COA and the accounting template forward, which is used in most cases.
Copy forward action 1030 copies just as 1027 but the Accounting Template, BSA, and Sub BSA fields are not copied forward.
This action assists end users so that they do not have to clear those three fields on the second transaction. The failure to clear the Accounting Template may result in cleared COA field re-inferring. The failure to clear the BSA and Sub BSA fields will result in updates to the Balance Sheet Balance pages. Such updates are not desired when trying to liquidate the same updates made from the original transaction and when using a non-accounting event type. It is strongly recommended that the non-accounting even type prohibit the BSA field with Event Type Requirements.
Updates to Transaction Copy Forward Control from the initial records of these two actions will be necessary after one or more cloned transaction codes are setup for different reclassification needs.