Guardian News & Media
GNM RCS
Transaction list
Technical specification
Prepared by O3 Team Limited
Authors Nigel Robson
Creation date 24/10/2013
Document Ref. GNM_RCS_Transaction_List_TS.docx
Version draft for review
.Introduction
Purpose
The document GNM_RCS_Financial_Reporting_FS.docx is the functional specification that describes what business functions RCS supports in relation to financial reporting.
This document is one of a set of technical specifications that provide details of how those functions are implemented in RCS.
Scope
This document focusses on the transactions list in RCS. Separate documents deal with all other aspects of financial reporting in RCS, including accruals & prepayments reporting, spend analysis, and the delayed payments report.
This document is intended as a high-level technical document outlining how the relevant business functions are implemented in terms of software modules.
Importantly, this document does not aim to provide the level of detail that would be required in a programming specification in areas such as program structure, detailed business rules, data integrity, validation, locking considerations, data security, and calls to/from other software modules, performance considerations, and so forth.
For details of program logic and coding, the reader should refer to the program files themselves.
.Transaction list
The transactions list is not strictly a report in the traditional sense, but it is a view-only screen that lists all of the scheduled transactions for a given payee. It is the only place such a list can be produced in RCS.
The screen is access from this menu option: Finance → Transactions list…
This menu option opens screen rcs_stra_010_pc.fmb.
When the screen opens the user is prompted to choose the payee they wish to review by choosing their name from a list of values. The screen then opens with the payee’s transactions listed in ID order, most recent first.
Reordering the data
The user can click on the buttons at the top of each column to order by that column. Clicking the same button again reverses the order. This is all managed programmatically.
Period start and end dates
Every payment has a period start date and a period end date. These dates reflect the period covered by the payment. This is often a month or a quarter for contract payments. The payment scheduled date may be before during or after this period depending on the payment terms agreed with the contributor i.e. advance, arrears or a specified day.
The period start and end dates are used in the accruals reporting the calculate the proportion of a fee that may need to be accrued. (Accruals reporting is the subject of a separate document in this set.)
Payment status
The bottom right corner of the screen displays the payment status, including the reason for delay where applicable. This status is the same as payment statuses elsewhere in the system: it is generated from the database packaged procedure payment.status
Chart of accounts
The Chart of accounts coding for each payment is available in the popup window shown below:
This window can be left open whilst the user scrolls through the transaction behind, or it can be minimized.
Cancel
Payments can be cancelled in this screen by checking the Cancel checkbox. The detailed process of cancelling payment instruction, especially if they have been sent to Oracle, is described in the relevant interface document.
Hold
Payments can be put on hold in this screen by checking the Hold checkbox. This just delays payment processing until such time as the checkbox is unchecked. If a payment instruction has already been sent to Oracle it can no longer be put on hold.
Make legacy
The “Make legacy” button at the bottom of the screen can be used to indicate that a payment was a legacy payment i.e. it was paid in another system. This is itself something of a legacy feature: it was useful in the early days of RCS for contracts that were defined part way through their duration. The contract’s transactions would be scheduled for the period of the contract, and then those that had already been paid were marked as legacy payments.
The internal representation of a legacy payment in the SCHEDULED_TRANSACTIONS table is any payment that has a lowercase transaction type code. Uppercase transaction type codes are processed as normal.
Find new
Finally, once a payee’s transactions have been viewed another payee’s transactions can be viewed by pressing the “Find new” button at the top of the screen and choosing a payee from the list of values displayed.
End of Document
<enter keywords here>
Keywords (or tags) are important to provide accurate search results. They are vital if you have attached rather than pasted content to this page.