SUG Meeting

1. SUG Meeting 12th December 2007

2. Agenda

3. Agenda

4. Requirements Document Nigel Williams

5. MCIS Requirements & Standards Purpose of the document Explain the background to the requirements Define the high level Information Requirements, for all ERDF Participants Set out the data that must be collated by all Intermediate Bodies Provide data quality criteria through the definition of a data dictionary Identify system options to meet the Requirements Propose best practice guidance on system security and interoperability

6. Feedback & Response to v.031 Feedback Concerns that CLG are mandating the full MCIS, or develop an MCIS equivalent Mandating ISO27001 accreditation CLG do not have the authority to mandate IT standards The document does not reflect the understanding and agreements made on system choices It’s a shift from where we were It is gold plating and micro managing the RDAs

7. Update to MCIS Requirements 0.4 Document Update Recognise that the document is not communicating the right message Thorough update to v0.4 which includes a framework that sets out: A set of business requirements and data specifications whose validity is generally accepted across all the participants in the process; Options for regions to either acquire/develop systems to capture and process the project level information, or use a common system provided by CLG (MCIS); A centralised MCIS to collate programme level information (and some project information) for the purposes of declarations to the EC; Mechanisms to ensure compliance with these requirements and data standards

8. Data Dictionary & XML Schema Definitions Alan Hazell & Chris Crow

9. Data Dictionary • What is the Data Dictionary? • it is a definition of all the data items that need to be held by the various bodies involved in managing the Operational Programmes and Projects associated with the ERDF 2007-13 Programme; • it is also a definition of the data items that need to be supplied as part of the aggregated claims process so that the Certifying Authority (CLG) and Managing Authority (CLG) can verify the claim made by the A59(2) Intermediate Bodies (RDAs). • Current version is 1.1 and version 1.2 is scheduled to be issued by 21st December 2007, following review of feedback comments.

10. XML Schema Definitions • The definitions are broken down by the following business areas: • Programmes, Projects, Claims, Visits and Irregularities. • There a three categories of XML Schema Definitions (XSD): • detail schemas such as Project Details Schema. • these contain all detail relating to a business area; • summary schemas such as Claim Summary Schema, • these contain summary details relating to a business area and will be required to be submitted as part of the aggregated claims process; • specific schemas such as Irregularity SFIR Details Schema, • these contain specific details relating to a business area and will be required to be submitted as part of the aggregated claims process. • Current versions are 0.1 and versions 1.0 are scheduled to be issued by 21st December 2007, following review of feedback comments.

11. Frequency of Submission • Each A59(2) Intermediate Body (RDA) will make a monthly claim, in arrears, for defrayed expenditure. • For each claim the following data will be submitted for the period: • a list of projects commissioned using ProjectSummary.xsd • it will include changes to projects pervious reported plus new projects, • it will also include detail for any major project using MajorProjectDetails.xsd • a list of claims paid using ClaimSummary.xsd, • this will include all payments, credits and debits, made to projects • a list of visits carried out using VisitSummary.xsd, • this will include all visits carried out under Article 13 EC Regulation 1828/2006; • a list of irregularities reported using IrregularitySummary.xsd, • this will include a list of all irregularities found during the period, • it will also include detail for any irregularity greater that 10,000 euros using IrregularitySFIRDetails.xsd • In addition at six monthly interval all summary data will need to be re-submitted.

12. Frequency of Submission Example

13. Feedback Summary • Most RDAs have provide feedback some remains outstanding. • Feedback collated so far falls into the following categories: • format and data item clarifications, • all of this will be addressed and updated in the next version • audit/versioning • audit information is the responsibility of each RDA to ensure that all transactions relating to the information can be demonstrably traceable to the originator to avoid issues of fraudulent claims; • questioning the necessity to submit data items to verify claims • the submitted data is not just used to verify aggregated claims it is also used to check that the operational programmes are being effectively managed; • frequency of submission • version control and data item referencing • some data items were re-referenced in version 1.1, this was due to significant changes and moving visits to 400 and irregularities to 500, • more changes are required and some references will change in version 1.2, however all changes listed on the version control worksheet.