GNM_RCS_Contributor_Management_FS

.

• 1. Introduction

     1. Purpose

GNM needs to manage the rights in all content that it publishes, to ensure no contractual restrictions are ever breached and to maximise the repurposing and syndication of that content. RCS is the system that facilitates this requirement, through management of contributor data, contractual relationships with said contributors and by issuing payment instructions for the delivered content, along with associated expenses any royalties due.

This document provides a functional overview of the business functions the RCS system supports in relation to the management of supplier data. For the most part this is contributor data, including staff and non-staff, but some non-contributor data is also managed.

• 1. Scope

This document is intended as a high-level document outlining the main processing involved. It is not a detailed functional specification from which the system could have originally been developed.

Separate Technical specifications document the implementation of these functions.

• 1. Specification

     1. Suppliers

GNM engages with many parties (contributors) who supply content directly for publication, and also with parties (agents) who represent other content producers.

GNM also employs staff who produce content, on either a full-time or part-time basis.

Additionally GNM engages with non-contributing suppliers (NCS) for various editorial costs such as travel. With the exception of a small number of charities these are rarely relevant in RCS now, as such payments are processed in other systems. However, contributors occasionally ask that their fees be paid directly to charity.

The NCS data remains as an audit trail of historic payments that have been made to these suppliers via RCS in years gone by.

In some scenarios an Organisation (supplier) may need to be linked to a Customer, provided they are both the same contracting party. This occurs for organisation with whom a supply contract is agreed that requires payment to made by GNM for content, and also redistribution terms are agreed for which fees need to be received by GNM.

• 1. Contact details vs. Financial details

The contact details of all non-staff suppliers are recorded in RCS in order that Editorial staff can easily contact the suppliers to engage them to supply content, and discuss any matters arising. These contact details are automatically passed on to the Oracle Accounts Payable system as and when a payment becomes due. More details about contributors are recorded in RCS, such as their occupation and skills, as this is useful to Editorial staff.

Staff details are also recorded in RCS: these details are manually synchronised with data in the Oracle HR system by means of a monthly Starters and Leavers report. Personal details of staff are not recorded in RCS: the GNM office contact details are used instead. A list of staff is required in RCS so that staff content (in which GNM owns the copyright) can be easily identified by matching the name published alongside the content with the staffer’s name. Staff may also be commissioned to do extra work outside of their normal contractual obligations, which needs to be paid separately, and this is also managed in RCS.

Additional financial data for each supplier is gathered in the Oracle Accounts Payables system for non-staff, and Oracle Payroll system for staff. This financial data is owned by those systems e.g. VAT numbers, bank account details, IRS Form 1099 information, etc.

• 1. Maintaining supplier data

Processes are required to ensure the supplier contact data is kept up to date. Contributors may advise GNM about changes to their contact details, and these changes are applied in RCS.

RCS also issues an automatic email to each contributor each year advising them of the contact details held, and asking them to reply if any corrections are required.

• 1. Locking key data

Contributor names are visible but locked so that only RCS Administrators can change them. This is because there is a danger of one contributor’s details being overwritten with another by less experienced users of the system. All name changes are processed centrally by the RCS Administrator.

• 1. Confidentiality

Some contributors require their contact details to be held confidentially with very few people able to see them. This is because they insist on anonymity, and that their anonymity be protected. As such the name and contact details of a few contributors is masked from most users of RCS.

• 1. De-duplication

It is very important form both an audit perspective and a data management perspective that each supplier only exist once in RCS. Consequently RCS must warn users if it appears that they are entering the details of an existing contributor. If the user chooses to continue then the record created must be queued up for review, alongside the contributor(s) is considered to be a potential duplicate of.

RCS determines potential duplicate if two or more contributors have:

• • The same contact name or the same company name

  • The same address

  • The same UK postcode

  • The same VAT number

  • The same email address

  • The same phone / mobile / fax / ISDN number

• 1. Merges

From time to time contributors defined in RCS need to be merged. This may reflect an actual merger of, say, two picture libraries, or it may be to combine the records of two supplier records that are identified as being duplicates of each other.

If Oracle has already been sent details of the affected contributors then an instruction is sent to request that the same “merge” be applied in Oracle.

• 1. Data ownership

RCS always remains the owner of all contributor “contact” data, and so this data should not be updated in Oracle AP. Changes made in RCS are synchronised in Oracle, but changes inadvertently made to contact data in Oracle are not reflected in RCS.

Oracle owns the financial data relating to a payee, and there is no need for that data to exist in RCS. However Oracle AP does share some information which RCS does need:

• • whether a contributor has supplied their bank account, but not the actual account details, as this determines whether a payment instruction can be sent to Oracle;

  • whether a supplier is self-bill or not, as this determines the payment process in Oracle, and consequently helps Editorial answer queries from contributors about outstanding payments;

  • Oracle shares VAT numbers with RCS, as this is useful when identifying duplicate suppliers;

  • And Oracle shares whether the tax position of a contributor has been checked with respect to IRS Form 1099 processing. Again this is a prerequisite for payment instructions to be sent by RCS to Oracle AP.

• 1. Approval

From an audit perspective it is important that new contributors are approved before they can be paid. The Rights administrator performs this role – a list of unapproved contributor records is queued for review. This is a fraud protection measure, but also ensures that the data is checked over for accuracy e.g. checking the County is not typed into the Town field, or checking phone numbers are correctly formatted.

• 1. Change history / audit

From an audit perspective it is also important that a change history (or audit trail) of key contributor data be kept, and be accessible to users, with the changes made clearly highlighted.

• 1. Reporting

There is a requirement for users to be able to request the following lists:

• 1. Photographer list

Format – csv

Delivery – emailed to user

• 1. Staff list

Format – csv

Delivery – emailed to user

Selection criteria

• • Casual staff only, or non-casual staff only, or both

  • Part-time staff only, full-time only, or both

• 1. Contributor list

Format – csv

Delivery – emailed to user

Selection criteria

• • Writers, Photographers, Illustrators, or all of these

  • Individuals, Organisations, or both

  • Contributors under contract only, or all

  • Contributors engaged by a specific Cost centre, or all

End of Document