GNM_SLM_Sales_Contracts_Definition_TS

• 1. .Introduction

     1. Purpose

The document GNM_SLM_Sales_Contracts_FS.docx is the functional specification that describes what business functions SLM supports in relation to syndication redistribution contracts.

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 redistribution contracts. The contract term sheet and the on-going contract processing are covered in separate documents.

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. .Sales contracts definition

     1. Identify the customer

New sales contracts (aka redistribution contracts) can be entered using this menu option: Syndication → Find a customer. This opens an Oracle Form named rcs_ordr_010_pc.fmb

Step 1 – Search for the customer

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

Step 2 – Identify the customer

• 1. Contract definition

Pressing the “Redistribution contracts…” button starts the entry of the contract.

This opens an Oracle Form named rcs_scon_010_pc.fmb into which the contract details are entered, as shown below:

The following document sub-sections describe each distinct grouping of data that can be defined:

• 1. Contract

This section relates to the top section of the above screen shot.

Contacts Unique reference

Upon successfully entering a request the system allocates a unique reference number which uniquely identifies this request. The reference generated takes the form NXXXXX where the XXXXX component is an alphanumeric based on a value from a database sequence named SCON_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.

Dates

The user must enter a contract start date, and optionally an end date.

Trial & Enabled

The contract must be identified as being a trial or not. It can also be marked as being disabled if it not ready for use, or is being stopped.

Description & Renewal notes

A description of the contract can be added if it is helpful.

The Renewal notes field is used as a reminder of points that need to be considered when a contract period needs to be renewed.

• 1. Duration & terms

The duration of the contract is the duration of the first period, plus any subsequent periods, as described in the next section. The contract may have an initial term, notice period and renewal term. The other data defined at the contract level is self-explanatory when looking at the screenshot below:

The “Get default” button alongside the “Agreement term…” and “Credit” fields can be pressed to reset the values in the respective field to their defaults.

The “Default” button alongside the “Body of term sheet covering letter” field can be pressed to reset the default value for that field.

• 1. Client services

A list of client services is maintained against a contract to identify how the client intends to use the content, and thereby contractually what they are allowed to do. This includes any territory, exclusivity period, and embargo restrictions, and a note of the circulation or audience numbers they have declared.

.

• 1. Contract periods & products

Each contract may have one or more contract periods. Fees are often revised on an annual basis i.e. at the end of each period, and so annual periods are most common.

Each period may have one or more products associated with it, with a fee attributed to each.

The term sheet can be generated by pressing the “Term sheet” button. This generates a PDF contract that details all of the contract clauses, client services, contacts, special terms etc. Term sheets are only generated for the first contract period. The term sheet’s clauses are based on a template term sheet that is maintained in another screen – data from the contract is merged into the template to produce a term sheet that is ready to be emailed for signature.

Invoices can be scheduled against the contract period by pressing the “Schedule” button, provided the chart of accounts details are complete and the “Allow invoices (this product)” checkbox is checked.

When the period is setup to be billed monthly invoices are generated for each month, with each product separately itemised on an invoice line. The invoices’ dates are set in accordance with whether the fees are payable in advance, in arrears, or within the period itself.

If a product is marked as an Ad share product then the invoices will be generated as estimates, and these estimates will need to have the correct fees applied before the invoice instruction can be sent to Oracle AR. (The estimates are needed to facilitate accurate accruals reporting. The actual fees are determined from data supplied by the customer.)

.

• 1. Content linked to contract periods

For some contracts it is important to keep a list of content that the client has used. This is especially applicable where the contract has usage limits, or where fees are linked to usage.

The window below shows the information that is recorded for each item of content used by the client.

• 1. Invoices

As described in an earlier section SLM can generate invoices for a contract period based on the products the client is taking, the fees agreed, and the billing terms. Each invoice line details the product and fee, the client purchase order if provided, and the chart of accounts details.

Invoices can be manually amended as required, and extra invoices can be added if appropriate.

• 1. Content linked to billing periods (invoices)

In other circumstances the customer sells on the content and GNM may then have to pay on a royalty to the original contributor. This customers report their usage at the end of each contract billing period and so their content usage is linked to the period. In this situation more information is recorded, including the end client and fee, and royalties can be entered.

• 1. Documents

The system generates term sheets to be emailed to customers for signature, as described earlier in this document. All documents generated by the system are stored against the contract, and they are also accessible from the Customer screen.

Any further documents that relate to the contract or any renewal thereof can be uploaded to the database by the user, and will be listed against the contract.

• 1. Delivery

The delivery definition of a contract is specific to the delivery of content by Fingerpost, on behalf on GNM, to the client. This could, for example, be by ftp or email. The details of the protocol used, the recipient address, the format and data to be included can all be defined in this tab, and the tab-canvas within.

These details are extracted half-hourly by a database job and made available to Fingerpost so that it always has current definitions. Much of the Fingerpost delivery is set to be transferred to Mainstream at the time of writing.

• 1. Owners

A list of contract owners is maintained against all contracts. These owners are sent email alerts in advance of a contract approaching its renewal date. A database job manages this. The renewal alerts will continue until the recipient checks the checkbox shown below to acknowledge receipt.

• 1. Alerts

Every customer contract can have nominated recipients of GNM legal notices and corrections & clarifications. It is important the customer receives these as it enables them to take down or amend content as instructed.

• 1. Contacts

A separate list of contacts can also be maintained against a contract. At least one contact must be defined in order for the contract to be emailed to the customer. Other contacts may be defined who may or may not receive a CC of the contract email.

Each contact’s role must be set from the list of values available.

In addition to client contacts internal (GNM) contacts can be defined as recipients of the emailed contract. This enables relevant GNM staff to see the actual PDF contract that was issued.

.

• 1. Technical complexities

This screen rcs_scon_010_pc.fmb presents a number of technical challenges described below:

Canvas management

There is a significant and complicated set of code that determines which window and which canvas should be displayed (and which hidden) as a result of a given user action e.g. on commit, or when navigating through the tabs, on exiting a popup window, etc.

This mainly relates to the display of the Delivery Methods tab canvas over the top of the Delivery tab of the main tab canvas in the screen.

Repurposing of this screen

This screen is repurposed for all other contract maintenance. This is described in another document, but includes queues of:

• • current contracts;

  • contracts that have not been returned;

  • contracts that need to be renewed;

  • contracts where invoice estimtes need to be updated; and

  • contracts handled by a particular person in Synidcation.

In each of these scenarios the screen is entered directly from the menu, and opens with a list of contracts (not described in this document) from which any of them can be maintained using the screens/windows that are described in this document.

End of Document