Phase 2 Business Analysis meeting - 17-May-2013

Attendees:  Liz Welch, Garry Robertson, Matthew Bunn, Jill Nicoll, John Allison

Agenda: To confirm:

A.   what new admin functionality is needed, to allow FIS to maintain lists of values, when Matthew is no longer available to apply updates directly to the database

B.   what reports are needed, to allow FIS to access data, when Matthew is no longer available to provide ad hoc csv downloads

A.  Admin functionality: 

      A.1.  Admin functionality for LoV data maintenance:

A1.1  Transaction Type LoV

• add new trans types
• change trans type values
• remove trans types

A1.2  For every LoV currently available within eAuthorisations

• add new record
• change record values
• remove record

Every LoV should allow alphanumeric entries.

No validation to be performed, so that FIS can apply any value to any LoV entry.

A1.3  For every LoV currently available within eAuthorisations

• provide a means of linking each value within the LoV to one or more values in the Transaction Type LoV

       A2.  Admin functionality to apply LoV values to individuals:

A2.1  For every LoV currently available within eAuthorisations

• provide a free-entry optional field that FIS admins [and devolved administrators - ?] can use to manually override the options available in the LoV with an absolute value
• provide an admin function that FIS admins can use to apply an across-the-board change to the value from the LoV that will be applied against a defined group of users.  e.g. “everyone on level 1 who currently has banding X, should be changed to instead have banding Y”.

       A3.  Adding new systems to eAuthorisations:

A3.1  New system does not involve any down-stream application:

A generic routine to add a new system to eAuthorisations, would have to accomplish the following steps:

• Create at least two new classes of code
• Create an interface abstract class for both classes
• Display a new section, with any required input boxes, on screen
• Create SQL to create new database tables
• Create stored procedures to update tables
• Copy any required data into tables

Matthew advised that it would cost more to create a generic procedure to accomplish this than is would to add several new systems manually. 

It was agreed that, provided the new system does not involve any down-stream application, it would instead be added as a new Transaction Type.

A3.2  New system does involve a down-stream application:

The project raised for the down-stream application will include a phase to create the required functionality in eAuthorisations.

B.  Reporting requirements:

It was felt that a BOXI universe against the eAuthorisations database would be the most versatile method for meeting this requirement.

Liz confirmed that it would be acceptable for all schools to be able to see all eAuthorisations data (i.e. no row constraints), since BOXI is read-only.

C.  Additional new functionality desired:

      C.1.  New Proxy user functionality, to enable FIS to manage users, for example on behalf of school administrators.

      C.2.  Purchase order processing authority should flow across all systems through which purchase orders can be raised..

      C.3.  Copy functionality, to apply an individual’s Cost Centre and Job Code access from one system to another system within eAuthorisations.

AOCB:

The next meeting, scheduled for 29th May, will change focus from Phase 2 business anlayis to project Terms of Reference review.

Actions:

A.  Admin functionality:

• John to assess the number of LoVs that currently exist in eAuthorisations.
• John to provide 3-pt estimates for the design, build, peer, and UAT support for each of the items outlined in sections A.1 and A.2 above.

B.  Reporting:

• John to confirm the number of tables in the eAuthorisations database. 
• Jill to seek Config team review and estimates for BOXI universe (section B above).