GNM_RCS_Contract_Processing_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 entry of new contracts, and subsequent processing of them.

Separate documents cover the renewal process and 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. .Creating a contract

New contacts can be entered using this menu option: Contracts → New contracts. This opens an Oracle Form named rcs_comm_070_pc.fmb (the same one used to initiate new commissions)

Step 1 – Search for the contributor

Enter the search criteria in the above screen and press the “Find…” button.

Step 2 – Identify the contributor

The user must highlight the contributor they want to contract with from the search results.

Pressing the Create a new …“Contract” button initiates the contract entry process:

Step 3 – “Enter new” or “Copy existing” contract

The user can choose whether they want to base the contract on an existing contract or start afresh:

Step 4a – Enter new

If the user chooses to enter a new contract they will be asked to choose the primary content format, and whether it is for new content or stock, as they enter the new contracts screen

Step 4b – Copy existing

If they choose to copy an existing contract they are asked to select the contract type & subtype:

Then they are presented with a list of contributors with current contracts of that type.

Step 5 – Contracts screen

At this point the contracts screen will be open. This is Oracle Form rcs_agmt_010_pc.fmb

The screen is pre-populated if the user chose to copy a contract, and has a new contract reference allocated. Otherwise the screen fields are largely blank awaiting entry.

NB The above view of a contracts screen is a little different if the contracts is linked to one of more blogs published on the website, as follows:

Step 6 – enter the contracts details

The user can now amend the details shown on screen, or enter new details, in these main areas:

• 1. Contract details

     1. Unique reference

Upon successfully entering a contract, or copying an existing contract, the system allocates an agreement reference number (ARN) which uniquely identifies this contributor agreement. The ARN generated takes the form AXXXXX where the XXXXX component is an alphanumeric based on a value from a database sequence named AGMT_ID. The generation of unique reference numbers across the system is described in the core technical documentation as the method is common to all automatically generated 6-letter references.

• 1. Contribution

The editor records the details of the contribution as this represents what the contributor has agreed to deliver, as follows:

• • the Contribution text field is entered;

  • the frequency of delivery;

  • when it is due; and

  • any creative contributor details can also be added i.e. where the name of the contributor or contributors that will appear with the content is different to the supplier’s name, as follows:

• 1. Chart of Accounts

Chart of accounts entries can be entered against the contract and these will become the defaults used for any subsequent payment instructions.

The standard layout and processing for chart of accounts fields is used, and so is not documented further in this specification.

• 1. Fees & Chart of accounts

Fees are entered by pressing the “Fees etc” button. For a new contract for imagery the following window appears:

The user can enter a standard monthly service fee, the currency, and the usual recipient of fees.

For space rate contracts (i.e. pay as you go contracts) image area bands can be entered with fees alongside. A wire fee applicable to each image use can also be entered:

For non-image contracts, such as text, the Fees window allows the user to mark the contract as a lineage contract, in which case they also enter the lineage rate per 1000 words:

If the fee is based on a gross amount, rather than either lineage or space rates, then the details of those fees should be entered using the fields on the right of the above screen. For lienage and space rate contracts those fields are not displayed.

For Gross fee contracts the fee can be split across different Chart of Account combinations using the screen below:

The lower half of the screen shows the fee split for the previous contract with this supplier.

The user can use the “Generate trx for next period” button to create a set of payment instructions for the next chronological period for the contract (i.e. the next month or quarter).

• 1. Revenue periods and products

If the supplier is linked to a customer then fees may be recoverable under the contract. This processing is very similar to the processing documented for the syndication redistribution contracts.

Revenue period must be defined in the window below, and products applicable to those periods.

• 1. Invoices

Invoice can be created for the Revenure periods and products described above. The invoices may be generated usingv the “Schedule£ button shown above, or manually entered in the tab shown below:

• 1. Transactions

When a gross fee contract has been finalised RCS has a facility to schedule all of the payment instructions that need to be sent to Oracle AP over the course of the contract term. The facility is invoked by pressing the “Schedule trx…” button, provided the contract has been approved. This facility is only available to RCS Administrators.

Once the transactions have been scheduled they can be viewed and potentially amended by clicking on the “Transactions” tab which should now be enabled:

• 1. Owners

Each contract can have one or more owner – people who have a financial (or other) interest in the contract or its renewal. The owners are maintained in the Owners tab:

RCS also issues emails to the contract owners, if they have been identified as recipients of these emails. This is done by checking the Performance alerts? Checkbox in the Contract owners popup window, which is accessible by pressing the “Fees etc” button in the main window.

• 1. Rights

The rights applicable to all contractual relationships with contributors are quite complex. To save users from having to enter this mass of data it gets automatically created when the contract is first saved and can then be modified by the user. Pressing the Rights button displays the rights:

The detailed workings of the Rights model are not documented here as it is common to both Commissions and Contracts. It is documented in a separate Rights document.

• 1. Matching rules

Rules can be defined to determine which published content can be matched to a contract. Lists of departments are pre-populated for each publication and the user ticks those that apply.

• 1. Monitoring & stats

Contracts are monitored to ensure the volume of content delivered meets expectations.

• 1. Monitoring

Pressing the “Monitoring” button displays the Contract monitoring window.

Reporting facilities are provided in Business Objects and are outside the scope of this document.

• 1. Stats

Pressing the “Stats” button in the main Window invokes a calculation that quickly counts how much has been published against the contract and displays it on screen. For example:

• 1. .Reviewing & processing

Contracts can be reviewed and edited in the following ways:

• • Review contracts screen (which shows contracts for a specific contributor);

  • Contract approvals;

  • Contracts under rights review;

  • Contracts not received; and

  • Current contracts.

• 1. Review contracts

The screen is accessed from menu option Contracts → Review contracts. It opens an Oracle Form named rcs_agmt_010_pc.fmb

This screen is the same one used to enter the contract. Upon choosing this screen the user is presented with a list of contributors with whom GNM has one or more contracts. They choose the contributor they are interested in and the screen opens with their contracts displayed, most recent first.

Features of this screen (not already explained earlier in this document) often used subsequent to the initial entry of the contract are described below:

• 1. Other payments

Expenses and other payments can be added to a contract in this screen by pressing the “Other costs” button. Because the same facility is available for Commissions the subject of expenses is explained in separate documentation rather than being repeated in both the commissions and contracts documents.

• 1. Content

Content can be matched to approved contracts using the matching screens which are documented separately.

When reviewing a contract the user can view the content already matched to it by pressing the “Content” button. This invokes the Content History screen for the current contract. The workings of this screen are documented in the relevant Content-related documentation.

• 1. Spikes

Where content has been delivered but has not been published it can be added to a list of spiked content. This is useful when measuring contract performance. The popup widow used is below:

• 1. Periods and products

If the Supplier is linked to Customer then it is possible to add some redistribution features to the contract. This mimics the facilities available for redistribution contracts in SLM.

Periods can be defined, and for each period the product(s) that the contract party is redistributing.

The “Renew” button, when pressed, creates a new period based on the latest period, and attaches the relevant products.

Once the period and product data has been defined the user can press the “Schedule” to schedule the invoices that need to be issued to the Customer for the highlighted period.

• 1. Invoices

These invoices can be seen on the next canvas tab:

.

• 1. .Contract approvals

This screen is accessed from menu option Contracts → Contract approvals. It opens an Oracle Form named rcs_agmt_020_pc.fmb

The features of this screen are largely a subset of those available in the Review contracts screen, and from a technical perspective many are sub-classed.

That aside, the Approve and Cancel buttons perform the functions one would expect.

Users who are authorised to approve contracts also have a count of contracts requiring approval on their Welcome screen dashboard.

• 1. .Contracts under Rights review

This screen is accessed from menu option Contracts → Contract under Rights review. It opens an Oracle Form named rcs_agmt_050_pc.fmb

The features of this screen are largely a subset of those available in the Review contacts screen, and from a technical perspective many are sub-classed.

This screen exists as a queue of contracts requiring approval by the Rights department.

Rights department users have a count of contracts requiring rights approval on their Welcome screen dashboard.

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

• 1. .Contracts not received

The screen is accessed from menu option Contracts → Contracts not received. It opens an Oracle Form named rcs_agmt_040_pc.fmb

The features of this screen are largely a subset of those available in the Review contacts screen, and from a technical perspective many are sub-classed.

This screen exists as a queue of contracts whose paperwork should be chased up by the Rights department.

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

• 1. .Current contracts

This screen is accessed from menu option Contracts → Current contracts. It opens an Oracle Form named rcs_agmt_050_pc.fmb

This Oracle Form is the same one that is used for the Contracts under Rights review, it just runs with a different query, and so has the same features and search palette.

• 1. .Term sheets

RCS will issue a term sheet to the contributor when the contract has been finalised and approved, and the Issue paperwork? checkbox ticked. A preview of the term sheet can be generated by pressing the Term sheet button in the Review contracts screen.

• 1. Term sheet production

If the contributor has an email address then the term sheet is produced as a PDF report on the application server by an Oracle Report (named rcs_agmt_010.rdf). The creation of the report is triggered by a database job that polls for contract term sheets that need to be issued.

The design solution behind this is called “Event driven publishing” and is common to a number of areas of the system. It is documented in a separate core Technical Reference manual, and so is not further documented here.

• 1. Term sheet archives

Term sheets produced in batch are filed into year and month folders and compressed into zip archives on the server. This is done via a Windows script run from a Command Window.

In recent times all term sheets produced in batch have been saved to the database against the contract record. Details of this document storage solution are the subject of a separate Technical Reference manual as the technique is again one that is repeated across the system.

• 1. Term sheet content

The report producing the term sheets contains a lot of complex processing. The report queries a view called CONTRACT_TERM_SHEETS. Using a view is beneficial as it means some changes to the report can be made by simply changing the view.

In some aspects the term sheet can be thought of as a mail merge document, with name and address, and contract data being queried and then presented in the report’s layout fields.

Where data needs to be merged into sentences hidden fields are used that source the data from the relevant query group. These fields are then referenced in the visible boiler plate text.

In other parts of the report different paragraphs are used depending on whether the recipient of the report is the contributor or their agent. In some cases this is achieved by having format triggers on Frames or Fields which determine which Frames or Fields to hide and which to show. In other cases Formula columns are defined in the report Data Model in which a PL/SQL function returns the data required based on the data queried for the contract being processed. The formula column is then set as the source of a Field in the layout.

• 1. Manual print & send

Where a contributor does not have an email address the contract term sheep needs to be printed manually and posted. The facility to print the term sheets is available from menu option Rights → Contracts to issue.

• 1. .Termination & cancellation

Contracts can be cancelled – usually because they were entered in error – by pressing the “Cancel” button in the Review contracts screen. No fees are payable when a contract is cancelled.

Contracts can be terminated early, in accordance with their terms, by pressing the “Terminate” button. The contract is given a termination date, which the user can change. Payments cease after the termination date, and content published after that date is not generally matched to the contract.

• 1. .Audit controls

     1. Created & last modified audit

All contract records are stamped with the username of the user who entered the data, and the date and time it was saved.

Thereafter, whenever contract data is changed the record is stamped with the username of the user who changed the data, and the date and time the changes was saved.

The same applies to all subordinate data recorded against the contract, including fees, matching rules, rights, and creative contributors and so on.

• 1. Change history

A change history is kept of all changes to important contract data. The old and new values are stored, along with the username of the user who changed the data, and the date and time the change occurred. This is NOT visible to the users.

This data is useful as an audit trail and for reverting incorrect changes to the data.

End of Document