GNM_RCS_Contract_Renewals_TS

• 1. .Introduction

     1. Purpose

The document GNM_RCS_Contract_Management_FS.docx is the functional specification that describes what business functions RCS supports in relation to entering into contracts with contributors to procure content from them on a long-term basis.

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 renewal of editorial contracts with content suppliers, aka contributors.

Separate documents cover the entry of new contracts and their subsequent processing and also reporting on contracts.

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. .Contract renewals

Contracts for the supply of content may be open ended (i.e. have no end date) or of fixed duration (i.e. have an end date).

Those that have an end date (ideally) need to be renewed on or before the end date for the service to continue uninterrupted. RCS maintains a queue of these contracts that are coming up for renewal, so that Editorial knows to start engaging with the contributor to agree the terms of the renewal.

• 1. Timing

Contracts are considered ready for renewal if:

• • The contracts is within 14 days of its end date; or

  • The contract is more than ¾ of the way through its term.

Contracts drop off the renewal queue after 3 months if no action has been taken.

• 1. Email alerts

Contract owners can be defined against supplier contracts in the Review contracts screen. The window in which this data is maintained is shown below, and is accessed by pressing the “Owners” button in the main window.

These owners are sent email alerts to remind them that a contract needs to be renewed. These alerts are sent with increasing frequency as the end date approaches. The schedule is as follows:

90, 60, 30, 23, 16, 9, and 2 days prior to the contract end date, then 5 days after the end date, and every 7 days thereafter.

Once the user acknowledges one of these alerts, by checking the Reminder acknowledged? Checkbox above, they will not get any more alerts for this contract.

• 1. Responsibility

Contracts can be renewed by Editorial administrators, Department heads, Managing editors, and also the Rights department.

Each user can only renew contracts for Cost centres they have been granted access to.

Furthermore, they are restricted to renewing contracts whose delivery format(s) match those they deal with – although an exception is made for contracts that have no delivery formats.

• 1. Renewals queue

A queue of contracts due for renewal is maintained in RCS.

Each user may see only part of the queue i.e. just the contracts they are allowed to renew. Firstly the user will see a count on their Welcome screen dashboard, and if the value is above zero they can click the adjacent button to open up the queue. Or they can choose the menu option Contracts → Contract renewals.

In either case the screen that opens is rcs_agmt_030_pc.fmb, shown below:

This screen lists the contracts queued for renewal, in descending order of their end dates and then alphabeically on contributor name i.e. the most urgent at the top. The user can change the order of the data by clicking on the button above the columns of data on the left. Clicking the same button a second time reverses the order

The user can restrict the list of contracts shown by using the following popup search palette:

• 1. Clearing down the queue

Below is a list of the different ways the renewal queue can be cleared down:

• • If a contract is renewed by pressing the “Renew” button the new contract will have a permanent link back to the one that precedes it. This removes the old contract from the queue;

  • If a new contract is entered for a contributor, and the contract starts the day after the old one finishes then this will be deemed the renewal, and again the old contract will be removed from the queue;

  • If the user clicks the “Don’t renew” button an internal flag will be set on the contract marking it as no longer renewable, removing it from the queue;

  • Contracts queued for renewal can be terminated and this also removes them from the queue;

  • If it is agreed with the contributor that their contract will be extended rather than renewed then the contract end date can be changed accordingly. The usual renewal criteria will apply again i.e. the contract will be removed from the queue until it is ¾ of the way through its revised contract period or in the last 14 days of that new period; and

  • Finally contracts drop off the renewal queue after 3 months if no action has been taken.

• 1. Renewing a contract

A contract is renewed by pressing the “Renew” button on the above screen. This will navigate the user to the same screen where new contracts are entered, rcs_agmt_010_pc.fmb, which will be pre-populated with all existing contracts with the supplier, and a new contract with start and end dates that follow on directly from the contract period being renewed shown below the contract that is being renewed.

The workings of this screen are described in detail in the Contract processing technical specification.

End of Document