GNM_SLM_New_Orders_TS

• 1. .Introduction

     1. Purpose

The document GNM_SLM_Orders_FS.docx is the functional specification that describes what business functions SLM supports in relation to syndication Order processing.

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 requests. On-going order processing, the issuing of letters and licences, and reporting 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. .Recording a new request

     1. Identify the customer

New requests (aka orders) can be entered using this menu option: Syndication → New request. 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

Customer marketing data

SLM can contain customer data from an external supplier, Cision. This data can be searched as per all the other customer data but it is highlighted in grey as show below. All the contacts are listed on the right hand side of the screen.

In this state the Customer cannot be licenced in the usual way. Instead the user must import the customer into the SLM customer database by pressing the “Import marketing data…” button shown above. Once the customer has been imported it can be licenced in the normal way, as described in the following sections.

.

• 1. Request details

Pressing the “New request…” button, or double-clicking the highlighted record, starts the entry of the request. A screen is displayed into which the request details are entered, as shown below:

The left hand side of the screen is for the new request, while the user can scroll through previous requests from this customer (in order to copy the details using any of the 5 copy buttons) on the right hand side.

• 1. 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 RXXXXX where the XXXXX component is an alphanumeric based on a value from a database sequence named ORDR_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. Content

The user enters any known details of the content into the fields at the top of the screen and then presses “Find…”. This will open the Search for published content screen. Once the user has identified the content in that screen they press the “Process request” button and the focus returns to this screen with the content linked to the request. At this point the user is advised as to the rights position of the content.

• 1. Usage, fees, rights and chart of accounts

The leftmost column of fields relates to the customer’s publication.

To the right of this there are checkboxes and fields that determine the rights being requested, and below this fileds for the fees that will be charged. The fees may include a service fee and/or a licence fee.

Each request must have a Chart of Accounts coding in order for an invoice instruction to be passed to Oracle AR. The CoA codes should all be defaulted, but can be maintained in the window shown below:

• 1. Rejecting a request

If the user knows the request must be declined they can press the “Reject” button. They will be prompted to choose the reason why the request is being rejected.

• 1. Royalties

Where required one or more royalty fees can be entered. Royalty fees are based on the licence fee, but the service fee (if one exists) is not included in the calculation.

• 1. Technical complexities

The screen rcs_ordr_010_pc.fmb presents a number of challenges, many of which were resolved in rcs_comm_070_pc.fmb. Each solution is described below:

Search

The facilities to search for a customer require complex queries to be constructed programmatically on PRE-QUERY for the ‘default where’ property of the LIST block. The LIST block is based on a view which gets data from multiple tables.

Content

Identifying content involves calling another Oracle Form and returning the ID of the selected content back to this screen. This is done using a global variable.

Right to licence

The right to licence the content must be determined by examining the rights agreed against all contributor commissions and contracts linked to this content, taking the most restrictive rights if they differ.

Fees

A default set of fees is applied if the customer has a fee profile defined.

Rights requested

A default set of rights is applied if the customer has a rights profile defined.

Font size

The font size in this screen is generally larger than elsewhere in the system, as it is used quite heavily and this makes it easier.

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 an given user action e.g. on commit, or when navigating through the request process, on navigating back out of the process, on exiting a popup window, etc.

• 1. .Audit controls

     1. Created & last modified audit

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

Thereafter, whenever order 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.

• 1. Change history

A change history is kept of all changes to important order 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.

The change history is visible to the users in the Pending sales screen as shown below:

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

End of Document