GNM_RCS_Other_Payments_and_Expenses_FS

• 1. .Introduction

     1. Purpose

The document GNM_RCS_Other_Payments_and_Expenses_FS.docx is the functional specification that describes what business functions RCS supports in relation to other payments and expenses made through RCS.

This document is one of a set of technical specifications that provide details of how those functions are implemented in RCS.

• 1. Scope

This document focusses on the entry of other payments and expenses in RCS and their approval.

Separate documents deal with the various reports covering these payments, and credit notes are also documented under separate cover.

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.

• 1. .Other payments + expenses

Commissions and contracts are the two types of arrangements that GNM enters into to buy content. Those arrangements define the fees payable and also the rights acquired in the content.

Some payments also need to be made that are not directly for content (or not already covered by a commission or contract) – these payments can be entered in the Other payments and expenses screen. The distinguishing feature of these payments is that they do not have rights profiles.

This screen is accessed from the menu option: Expenses → Other payments + expenses

The Oracle Form that is opened is called rcs_ecla_010_pc.fmb

The Other payments and expenses screen opens blank, and may be used to enter the details of one or more new payments; or an existing payment can be searched for to review or amend it; or payments at similar stages of processing can be queried.

Because all the details of a payment are held on one line the centre section of the screen scrolls right to left revealing more fields, as shown below (note the position of the horizontal scrollbar and the prompts above the fields in the centre of the screen):

• 1. Entering new payments

Users enter the details of new payments into the above screen.

The original design of this screen accommodated a requirement to minimize keystrokes when entering payments, as so many payments were entered. This was facilitated by (a) using field defaults wherever possible, (b) automatically launching LOVs on entry to fields (where applicable) and (c) having all the payment details on one line so that the user can see the line above at all times and use the copy record and copy fields functions where applicable.

When a payment is first saved it is allocated a unique 6-character payment reference number (PRN). This reference is prefixed with a “P” with the remaining characters generated from a database sequence ECLA_ID. The reference is generated in the same way as many others in the system and the detail of this process is described in the core technical documentation.

• 1. Finding a payment

If the user needs to find a particular payment they can do so by searching for its unique reference number, or by querying all payments for a specific payee and scrolling through the results to find the one they are looking for.

• 1. Search by PRN

The user can enter a PRN in the search box at the top of the screen and then press the Find “…PRN” button to have the details of that payment returned.

• 1. Search by Payee

By pressing the Find “…payee” button the user is presented with a list of possible payees. When they choose one from the list all of that payee’s payments are listed in the screen, and they can scroll through them in the usual way.

• 1. Viewing processing stages

The user also has the option to query lists of payments in each of the following stages of the payment processing lifecycle:

• • Show “…all”

  • Show “…unapproved”

  • Show “…unsent”

  • Show “…unpaid”

Buttons for each of these are at the top of the screen.

• 1. Payment status

The status of a payment can be displayed at any time by pressing the “Status…” button. The resulting popup window identifies who entered and last updated the payment, and shows its approval status, and the status of the payment processing. An example is shown below:

The payment status data is provided by a database function that is a common component used elsewhere in the system: payment.status

• 1. .Other payments + expenses approval

When the value of a payment is above the “self-approve” limit of the person entering it the payment will be queued for approval.

The desk head can usually approve these payments unless the values are above their approval limit.

If the value of the payment is above the desk head’s limit then the desk head still needs to approve it, but it then gets queued again for the Editors office to approve.

(If a desk doesn’t have a desk head then all the payments a desk head might have approved go straight to the Editors office for approval.)

Desk heads and Editors office users see a tally of the number of items awaiting their approval on the Welcome screen when they login. They can press a button adjacent to this figure to navigate directly to their queue, or they can access the same screen from the menu.

The menu option to access this screen is Expenses → Other payments + expenses approval

The Oracle Form that is opened is rcs_ecla_020_pc.fmb

Payments are listed in reference number order as this reflects the order in which they were entered and is therefore a reasonable proxy to put the most urgent at the top of the list.

Payments must have a net fee before they can be approved, although they may appear in the screen on the basis of a high estimate, as shown above.

The approver should check who is being paid, the value, the chart of accounts segments, and any invoice details.

Additionally if a related commission or contract had an expenses limit then the amount approved already should also be reviewed. The approver has the option to Approve or Cancel the payment by pressing a button with the corresponding label.

End of Document