POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 463 Release spr 1
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - development
Requirement Description:
Additional requirements for OPS equipment
Samples of all OPS equipment must be supplied for purposes other
than production work. Examples include:-
testing by BA/POCL
training
demonstrations and marketing.
It should be noted that specimens of all OPS equipment or
proposed OPS equipment will be needed from time to time to
undergo destructive safety testing.
Precise figures for this requirement cannot be predicted at this
stage, but it is unlikely that more than the equivalent of 8 post
offices with a total of 50 counter positions equipment will be
needed for acceptance testing by BA/POCL.
Requirements for training are unknown at this stage, and are
dependent on the training methodology employed.
Requirements for destructive testing would not normally exceed
one example of each hardware component that is proposed for use
in the OPS.
Requirements Page 1 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 464 Release spr 1
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Service management
Requirement Description:
Agreement to offer services using OPS and TMS.
Services which utilise OPS or TMS may only be provided subject to
the express agreement of BA/POCL.
Requirements Page 2 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 465 Release spr 2
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - design
Requirement Description:
Appearance of the equipment within OPS.
The livery of the equipment to be used within OPS must be
specifically agreed with BA/POCL. A single livery will be agreed
for all outlets to fit in with POCL’s style guide for post
offices
The effort required to maintain the acceptable appearance of the
equipment must be minimal
Requirements Page 3 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 466 Release spr 1
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Service - steady state
Requirement Description:
Consumables.
Detailed specifications of all the consumables that will be used
by the OPS must be supplied to BA/POCL with estimates of the
likely consumption of each.
The service provider must be prepared to supply all consumables.
However BA/POCL may choose to source consumables separately.
Requirements Page 4 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 467 Release spr 2
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - design
Requirement Description:
Links from OPS to TMS.
Each instance of OPS within outlets must be connected to the TMS
to allow the transfer, in both directions, of authorised data
files and messages.
The transfer of data between OPS and TMS must be secure,
complete, accurate and robust.
Within OPS it must be possible to identify whether data has been
‘collected’ by the TMS or not.
Requirements Page 5 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 468 Release spr 1
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Service - steady state
Requirement Description:
OPS equipment - engineering visits.
Maintenance and repair of the OPS equipment involving on-site
attendance by engineers must not interfere unduly with the
ability of the outlet to serve customers. It must be borne in
mind that many of the outlets have a single counter position
and/or extremely limited physical space.
Requirements Page 6 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 469 Release spr 1
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Procedures &
documentation
Requirement Description:
OPS - technical documentation.
The supplier must provide technical documentation for OPS
suitable to allow BA/POCL to procure applications which will
utilise OPS or hardware which will interface with OPS. These
procurements would not necessarily be from the supplier. All
changes to the documention must be specifically agreed with
BA/POCL
Requirements Page 7 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 470 Release spr 1
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Procedures &
documentation
Requirement Description:
TMS - technical documentation.
The supplier must provide technical documentation for TMS
suitable to allow BA/POCL to procure applications which will
utilise TMS. These procurements would not necessarily be from the
supplier. All changes to the documention must be specifically
agreed with BA/POCL
Requirements Page 8 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 471 Release spr 2
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - design
Requirement Description:
Messaging facilities.
Using TMS and OPS it should be possible to broadcast short
messages to all or a subset of outlets. As a guide, a message
length of approximately 2000 bytes is likely to be acceptable.
The message should be brought to the attention of staff working
in the outlet at the earliest practical opportunity. It should be
possible to produce a hard copy of the message within the outlet.
Using TMS and OPS it should be possible for staff working in the
outlets to gain access to electronically held information such as
is currently published in ‘Counter News’ and the operations
manuals.
Requirements Page 9 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 472 Release spr 1
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Security
Requirement Description:
Security of data and audit trail for OPS.
Data capture within OPS must be accurate and robust.
The integrity and security of data held within the OPS must be
protected at all times. Logs of events within OPS must be
maintained and an audit trail of interactions with, and actions
within OPS must be maintained.
The integrity and security of data held within OPS must not be
compromised when OPS is re-established following any failure.
Requirements Page 10 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 473 Release spr 15
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - design
Requirement Description:
User access to OPS.
Any remote access to OPS must be restricted to specifically
authorised users and must be via TMS.
Access to OPS and services offered via OPS to staff working in
the outlets must be controlled by a mechanism, conforming to the
Style Guide, offering multiple access levels and providing
specific identification of each user.
It must be possible to restrict the functionality available at an
outlet; some services will not be offered through all outlets.
There must be support available to users who have forgotten their
passwords. It must be borne in mind that a large proportion of
the outlets have only a single counter position. The mechanism
used must not unduly reduce the effectiveness of access control.
There must be a secure and reliable mechanism for users to
suspend and resume access to OPS and services offered via OPS.
This must not be unduly onerous or time consuming.
Requirements Page 11 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 474 Release spr 1
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - design
Requirement Description:
Health, Safety and Legal on OPS equipment.
1.All OPS Equipment must be continuously rated and capable of
functioning safely and reliably, attended or unattended, for an
indefinite period in outlets.
2.Each installation of OPS must be physically and electrically
safe and in compliance with relevant legislation and recognised
best practice. It must not cause interference with other devices.
It should be borne in mind that the equipment may be installed in
premises that would be classified as residential.
2.1 This includes all relevant UK Regulations and Council
Directives (that is, Directives of the Council of the European
Communities) which are implemented by HMG. The equipment must be
maintained to be compliant with any subsequent legislation.
2.2 This includes mandatory standards, including all relevant UK
Regulations and Council Directives (that is, Directives of the
Council of the European Communities) which are implemented by
HMG. The equipment must be maintained to be compliant with any
subsequent legislation or mandatory standards.
2.3 All OPS equipment must comply with BS EN60950 : 1992 (BS7002
31992) and any subsequent amendments.
2.4 All OPS equipment comprising AC power adaptors must comply
with BS EN60065 : 1993 (BS7002 :1992).
2.5 The workstation aspects of all OPS equipment must comply with
the Health and Safety (Display Screen Equipment) Regulations
1992, which implement Council Directive 90/270/EEC on working
with display screen equipment.
2.6 Any OPS equipment containing laser emitters must comply with
BS EN 60825:1992. (Examples laser printers and laser barcode
scanners).
2.7 Any OPS telecommunications equipment must comply with Council
Directive 91/263/EEC (the Telecommunication Terminal Equipment
Directive) and have a current BABT certificate or equivalent for
connection to the public telephone network
2.8 All OPS equipment defined as Machinery must comply with the
Supply of Machinery (Safety) Regulations 1992, which implement
the Machine Directive 89/392/EEC as amended by 91/368/EEC.
2.9 All OPS equipment must comply with the Electrical Equipment
Requirements Page 12 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
(Safety) Regulations 1994, which implement the Low Voltage
Directive 93/23/EEC as amended by 93/68/EEC.
2.10 All OPS equipment must meet the requirements of the Non-
automatic Weighing Instruments (EEC Requirements) Regulations
1992 Schedule 3 Applications.
2.11 All OPS visual display terminal equipment must comply with
the relevant requirements of either BS 7179:1990 or ISO 9241:1992
(applies to keyboards).
2.12 All Equipment which falls within the scope of The
Electromagnetic Compatibility (EMC) Regulations 1992, which
implement Council Directive 89/336/EEC (as amended by 92/31/EEC)
must comply with these regulations.
2.13 All OPS Equipment must meet the minimum EMC requirements of
both residential and commercial installations, including
compliance with BS EN 50081 and BS EN 50082 with the following
amended test severity levels and with no degradation of
performance:
IEC 801 part 2 class 3, 6kV contact discharge
IEC 801 part 3 3V/m
IEC 801 part 4 +/- 1kV injected onto mains AC supply
IEC 801 part 5 +/- 2kV.
2.14 All OPS equipment covered by EN45501:1992 must comply with
clause A4.5 (voltage variations) and Annex B of that standard.
2.15 All items of OPS equipment must have an Index of Protection
rating of IP3X as defined in BS EN 60529:1992.
3. The OPS equipment and its installation must not constrain
BA/POCL and its agents from meeting their legal safety
responsibilities as employers.
4. It must be possible to prove compliance with legislation or
mandatory standards as and when necessary.
Requirements Page 13 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 475 Release spr 1
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Service - design
Requirement Description:
Style Guide
The supplier must draw up a Style Guide and agree this with
BA/POCL. Any services to be offered via the OPS will be
constrained by the Style Guide. Any changes to the Style Guide
must be specifically agreed with BA/POCL.
The style guide will set out general guidelines for the Human
Computer Interface, including screen layouts, system navigation
routes and help and manual entry facilities.
The Human Computer Interface must be intuitive and easy to use,
to minimise errors and delays. The Human Computer Interface must
provide a consistent look and feel across all applications and be
easy to adapt to allow the introduction of new applications.
Requirements Page 14 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 476 Release spr 2
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Service management
Requirement Description:
Release control.
1. A release refers to a set of electronic data (software and/or
reference data) which is to be distributed to and subsequently
activated within any of the services.
2. The following must be agreed explicitly with BA/POCL:-
the contents of any release
the upgrade path for any release
the timing of the distribution of any release
the timing of the activation of any release
3. Proof of sufficient and satisfactory testing of each release
is required including the following aspects:-
- at individual component (unit test) level
- of all components working together (system test)
- of all components in combination with different hardware and
software combinations which may be encountered in production
running.
4. Proof of sufficient and satisfactory preparation for the
implementation of a release is required. This will include
testing the implementation and reversion from the release.
5. The implementation of any release of software and/or reference
data must not cause any significant disruption to users, must not
disrupt the normal working environment and must not require
significant involvement from end users.
6. The implementation of any release of software and/or reference
data must not cause any corruption to data held on behalf of
BA/POCL.
7. A detailed record of all releases of software and reference
data and where they are deployed must be maintained.
Requirements Page 15 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 477 Release spr 1
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Service management
Requirement Description:
Asset register.
A detailed list of all physical system components ( an asset
register) must be maintained and available to BA/POCL on request.
From the list it must be possible to identify all equipment
installed at any location, for example in a post office.
Requirements Page 16 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 478 Release spr 12
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - design
Requirement Description:
Basic TMS facilities.
1. TMS must link into each instance of OPS which is to be used
for production work.
2. TMS must provide links into other computer systems as required
to support BA/POCL. These systems will include:-
client systems operated on behalf of POCL’s clients
other POCL systems, for example TIP
3. TMS must provide the links to PAS and CMS.
4. TMS must provide data file collection and data file delivery
services, where a data file is simply any set of electronic data.
4.1 Files may be collected from or delivered to any computer
system attached to TMS.
4.2 The collection or delivery of data files must be triggerable
by any of
- operator action
- time
- in response to a message from an attached computer system or
generated within TMS
4.3 The collection or delivery of data files must be retried
automatically, under parameter control, in the event of any
failure.
4.4 It must be possible to specify a pre-defined list of computer
systems to which a data file is to be delivered or from which a
data file is to be collected.
5. TMS must provide a message switching capability, where a
message consists of electronic data which must be passed from one
computer system to another (switched) with minimal delay.
5.1 It should be possible to switch messages between any two
attached computer systems. This includes any two instances of
OPS.
5.2 Where TMS is unable to deliver a message it must notify the
originating computer system.
5.3 The TMS must include the following processing capabilities
- validation of data files
consolidation of many data files into one data file
generating many data files from one data file
Requirements Page 17 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
- reformatting the contents of a data file
- generating control totals through access to the contents of
data files
- reconciliation of control totals
- produce reports summarising financial transactions.
6. A full audit trail of all TMS activity must be maintained.
7. TMS must ensure that any transfer of data files or messages
can be shown to be secure, complete accurate and robust.
Requirements Page 18 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 479 Release spr 1
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - design
Requirement Description:
Control and monitoring of TMS links.
1. No computer system may be connected to the TMS without the
express authority of BA/POCL.
2.TMS must only allow connections to it to be established with
computer systems which are authorised to be connected. This
implies that there must be a register of computer systems with
which connections are allowed.
3. TMS must authenticate the identity of any computer system with
which a link is to be established.
4. TMS must produce reports detailing any attempt to establish a
link which is rejected. These reports must be available to
BA/POCL on request.
Requirements Page 19 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 480 Release spr 12
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - design
Requirement Description:
Discreteness of TMS.
TMS must be kept logically discrete from other services such
that, in extremis, the service could be separately procured.
In particular there must be a clear and documented interface
between PAS and TMS functions and CMS and TMS functions. These
interfaces should include:
- specification of any programming inteface that exists
- specification of any shared data and data standards
- specification of any other protocols that exist to allow
communication between functions within the services
- specification of any other constraint that enables the
interoperability between services
Requirements Page 20 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 481 Release spr 12
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Documentation
Requirement Description:
There will be a comprehensive and definitive guide for completing
transactions that are processed using the automated platform this
could include Post Shop transactions where appropriate.The guide
will also include the definitive procedural instructions for
transaction support processes at outlets e.g. accounting,
balancing, value stock taking, and details of what to do in
emergency situations eg system failure.
In essence the guide will provide full details of completing all
business transactions in all post office outlets, including non
automated transactions such as giving information to customers
Requirements Page 21 of 407 Version 5.0 - Pathway
AUTHORITIES' AGREEMENT
SCHEDULE BO1
POL00028168
POL00028168
RESTRICTED - CONTRACTS
Requirement 482
Programme Implementation
Grouping
Requirement Description:
The guide must conform to POCL identity
standards
Release
No
Subject
Heading
spr 3
Implementation (POCL)
Documentation
and communication
Requirements
Page 22 of 407
Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 483 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Documentation
Requirement Description:
The guide is to incorporate additional product information for
specific products e.g. posting restrictions
Requirements Page 23 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 484 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Documentation
Requirement Description:
The guide must be available to all users and others (including
helpline operators, non serving staff in retail outlets who may
be asked to supply information/advice together with others as
appropriate) whenever the operating platform is in use.
Requirements Page 24 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 485 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Documentation
Requirement Description:
The guide must be updatable, in line with agreed service levels,
to ensure information is always current.
Requirements Page 25 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 486 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Documentation
Requirement Description:
All documentation must be given final approval by the AUTHORITY
before publication
Requirements Page 26 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 487 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Installation
Requirement Description:
The supplier will carry out the survey of outlets to accertain
what modifications are needed to install the office platform
Requirements Page 27 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 488 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Installation
Requirement Description:
The installation and acceptance of the office platform will be
undertaken in one day.
Requirements Page 28 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 489 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Installation
Requirement Description:
The supplier will disconnect and remove to an agreed location
existing automated equipment as specified by the AUTHORITY.
Requirements Page 29 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 490 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Installation
Requirement Description:
Installation is carried out within the outlets hours of business
Requirements Page 30 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 491 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Installation
Requirement Description:
The supplier will carryout internal office modification work at
all outlets necessary to enable the installation of the office
platform.
Requirements Page 31 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 492 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Installation
Requirement Description:
All contractors carrying out modification work will conform to
all legislative requirements
Requirements Page 32 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 493 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Installation
Requirement Description:
The supplier will be responsible for the removal / fitting of the
equipment when offices are either relocated or refurbished. The
supplier will be required to move equipment within post offices
if needed for refitment/refurbishment reasons - including open
plan - this may include the requirement for extra equipment. The
service provider will be required to equip new sites/relocated
sites in line with POCL's evolving network strategy.
Requirements Page 33 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 494 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Installation
Requirement Description:
The supplier shall respond within the agreed timescale to network
change requests supplied by POCL, as per agreed service levels.
This requirement covers provision and installation of equipment
in new and relocated sites as well as the
movement/reconfiguration of equipment within existing retail
outlets.
Requirements Page 34 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 495 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Installation
Requirement Description:
The supplier shall provide the equipment at all 'live' counter
serving positions. A 'live' position is defined as being one at
which counter transactions take place. This will include
modified parcel positions and may include non-modified positions.
Requirements Page 35 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 496 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Installation
Requirement Description:
The supplier shall install the equipment at any site designated
by POCL which may include Cash Centres and training centres
Requirements Page 36 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 497 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Installation
Requirement Description:
The supplier will install the office platform in outlets
Requirements Page 37 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 498 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Integration of services
Requirement Description:
Existing products and systems will be migrated from current POCL
platforms - APT, ECCO+, ALPS, Manual - to the new automated
platform with no customer/client discontinuity of service. The
Service Provider will work closely with POCL personnel to plan
how best to achieve effective migration. At post office outlets,
data transfer and associated tasks should be expedited as
efficiently as possible with minimum staff/ subpostmaster
involvement.
Requirements Page 38 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 499 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Integration of services
Requirement Description:
Installation should not take place until the infrastructure and
support service are ready
Requirements Page 39 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 500 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
The supplier must obtain certification from Authorised Personnel
- to be agreed - that relevent permissions have been granted
before modifications are carried out.
Requirements Page 40 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 501 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
The supplier will ensure there is a process in place to ensure
all outlets and regional liaison points are aware of and agree
the times and dates of all site visits. The regional liaison
point will be the final arbiter in case of disagreements.
Requirements Page 41 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 502 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
The supplier will carry out all survey activities without
degradation of Post Office and retail operations - including
existing systems at the outlet
Requirements Page 42 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 503 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
The supplier will carry out all modification activities without
degradation of Post Office and retail operations - including
existing systems at the outlet.
Requirements Page 43 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 504 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
The service provider shall indicate their proposals to utilise
the existing kit
Requirements Page 44 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 505 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
No specific requirements expressed on geography, although
regional roll out is not the preferred option.
Requirements Page 45 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 506 Release spr 15
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
The limited live trial should take place in a maximum of three
POCL regions, one of which must be South East or North Thames,
but not both.
Requirements Page 46 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 507 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
POCL would not wish the supplier to install the equipment in most
offices during particular business periods, namely Christmas and
New Year pressure periods, and other office specific dates agreed
on an annual basis.
Requirements Page 47 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 508 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
POCL will reserve the right to suspend the roll out programme if
the supplier fails to deliver the agreed service levels.
Requirements Page 48 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 509 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
Within a specification to be agreed with the Authority, the
siting of the office platform will be agreed by the outlet
manager.
Requirements Page 49 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 510 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
For the purpose of rollout planning no particular distinction
should be made between types of "main" post office - Branch
offices; modified sub post offices; and franchised post offices.
Requirements Page 50 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 511 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
The supplier will carry out all installation activities without
degradation of Post Office and retail operations - including
existing systems at the outlet.
Requirements Page 51 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 512 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
Roll out should be undertaken as quickly as possible subject to
the over-riding requirement to
(i) maintain service and client continuity
(ii) maintain the quality of service delivery to clients and
customers
(iii) appropriate support systems including training - being in
place
(iv) avoidance of damage to POCL's brand, reputation and
integrity
(v) demonstrate the robustness of the approach to roll-out in
the context of uncertainty and risks
(vi) treat POCL's staff and agents professionally and with
respect.
Requirements Page 52 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 513 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
If at some point in the future the supplier wishes to upgrade
equipment at the outlets, this will only be carried out with the
agreement of the AUTHORITIES.
Requirements Page 53 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 514 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
There will be a mechanism for
- Post Offices - are ready to
determining that individual outlets
go live i.e. that the new platform
functionality should be activated for use. POCL reserves the
right to withhold such agreement if, for any reason, it
determines that to do so ina
detrimental to its customers,
live" is not sanctioned, POCL
resolve outstanding issues as
particular set of circumstances is
clients, staff, or agents. If "go
and the Service Provider will
soon as possible.
Requirements Page 54 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 515 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
The service provider is asked to propose a support package for
offices within the first few weeks of "go live", in
acknowledgement that there may be additional training or other
corrective action needed at this early stage. These proposals
should also include a process for identifying problem offices.
Requirements Page 55 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 516 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
POCL reserve the right to amend the roll out plan as necessary in
order to protect its service levels.
Requirements Page 56 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 517 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
The Post Office outlet modifications will be completed in one
visit to the outlet.
Requirements Page 57 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 518 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
The Post Office Outlet survey will be completed in one visit to
the outlet.
Requirements Page 58 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 519 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Service - steady state
Requirement Description:
The supplier shall provide and install the equipment at
previously unequipped counter serving positions as directed by
POCL.
Requirements Page 59 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 520 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Supporting services
Requirement Description:
The supplier shall ensure that all the agreed support services
will be available from day 1 in line with agreed service levels
Requirements Page 60 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 521 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Supporting services
Requirement Description:
The supplier will provide one phone number as a single point of
access to all Helpdesk services
Requirements Page 61 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 522 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Supporting services
Requirement Description:
The Helpdesk contact point will be a "freecall" number.
Requirements Page 62 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 523 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Supporting services
Requirement Description:
Appropriate levels of support services must be available
(i) to provide support when all users have access to the system
(ii) to cover the operation of interfaces with other systems
(iii) to provide support for all other helpdesks linked to the
service provider helpdesk facility
Requirements Page 63 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 524 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Supporting services
Requirement Description:
The Helpdesk service will deal with calls relating to the
hardware
This will include, but is not exclusive to
Fault diagnosis
Maintenance call out
Caretaking advice
Configuration management
Requirements Page 64 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 525 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Supporting services
Requirement Description:
The Helpdesk must be able to provide access for users to
additional support services for day 1 and when requested to do so
by the authority in the future. This will include
Access to training facilities
Access to training materials
Operational support documentation
Consumables
Requirements Page 65 of 407 Version 5.0 - Pathway
AUTHORITIES' AGREEMENT
SCHEDULE BO1
POL00028168
POL00028168
RESTRICTED - CONTRACTS
Requirement 526
Programme Implementation
Grouping
Requirement Description:
All reported incidents must be resolved
service levels.
Release
No
Subject
Heading
spr 3
Implementation (POCL)
Supporting services
in line with agreed
Requirements
Page 66 of 407
Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 527 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Supporting services
Requirement Description:
A dedicated POCL Helpdesk staffed by fully trained, qualified and
experienced personnel must be provided working to specified
service level agreement.
Requirements Page 67 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 528 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Supporting services
Requirement Description:
Calls made to the Helpdesk that are not pertinent to it must be
re-routed to the appropriate point as per service levels
Requirements Page 68 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 529 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Supporting services
Requirement Description:
The Helpdesk support service must comply with POCL help service
behavioural standards in accordance with Service Levels.
Requirements Page 69 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 530 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Systems - design
Requirement Description:
If for any reason it is not possible to - or it is decided by
POCL not to - make EPOS functionality immediately live on Day One
of operation of the new platform, BES/APT functionality will be
available and operational with no adverse system or operational
impacts. In effect it will be a requirement to "ring-fence" EPOS
functionality so that it cannot inadvertently be used/misused to
the detriment of customer service and POCL accounting needs.
Requirements Page 70 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 531 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Training
Requirement Description:
Training must be provided to enable POCL's target audience to
achieve acceptable standards in key competencies as defined by
POCL. These competencies will be reviewed from time to time. For
some groups this may mean familiarisation training only. The
target audience will include users, managers, trainers, auditors
and certain non user groups i.e. retail network managers, regional
helpline staff, and account teams in business centres. The
service provider to give details of his proposals as to how, when
and where he will deliver the training, differentiating between
roll out and steady state as appropriate.
Competence will be measured by a method agreed by POCL and the
service provider
Requirements Page 71 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 532 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Training
Requirement Description:
The Service Provider must train all appropriate staff in the
requirement for new products or product changes
Requirements Page 72 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 533 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Training
Requirement Description:
If the system has a facility to operate in dummy training mode,
it must not interfere with data transfer or integrity.
Requirements Page 73 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 534 Release spr 3
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Training
Requirement Description:
The Service Provider's training solution must take account of
users experiences in term of automated products and platforms
(ECCO+, APT, ALPS) and their differing propensities to learn.
The service provider will agree with POCL the training
requirements for the different target audiences identified
including training required when individuals move between these
target audiences. This may include change of office, promotion,
new recruits etc.
Requirements Page 74 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 536 Release spr 3
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Service - design
Requirement Description:
OPS equipment - general requirements.
1. Peripheral and input devices supplied as part of OPS must be
reliable, robust and easy to use.
2. Peripheral and input devices supplied as part of OPS must be
capable of detecting contention, premature removal/swapping of
tokens etc as appropriate.
Requirements Page 75 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 537 Release spr 4
No
Programme POCL Subject POCL Infrastructure (SMS)
Grouping Infrastructure Heading
Systems - design
Requirement Description:
System management.
System Management of all the services provided to BA/POCL must be
carried out in a consistent and coherent manner to ensure the
following: -
1. Activities within the services, including PAS, CMS, TMS, OPS,
BES, OBCS, APS and EPOSS, are co-ordinated.
2. Changes to the services offered can be made speedily and
accurately.
Requirements Page 76 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 538 Release spr 15
No
Programme POCL Subject POCL Infrastructure (SMS)
Grouping Infrastructure Heading
Systems - design
Requirement Description:
System management - synchronisation of time.
SMS must provide a facility for synchronising the date and time
across all services and computer systems providing them. This
should cater for the handling of clock changes at the beginning
and end of British Summer Time for example.
A facility is required to allow transactions to be processed using
local time and / or GMT, thus each computer system must be able to
derive both local time and GMT.
Requirements Page 77 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 539 Release spr 15
No
Programme POCL Subject POCL Infrastructure (SMS)
Grouping Infrastructure Heading
Systems - design
Requirement Description:
System management - Reference Data handling.
1. Within the System Management Service it will be necessary to
maintain reference data necessary to the operation of the systems
and the applications.
2. It will be necessary to receive store and utilise reference
data from sources outside of the CONTRACTOR domain (e.g. TIP and
potentially client systems).
CONTRACTORS should bear in mind that it may be necessary to
implement changes in reference data to tight timescales. As an
example it would be necessary to implement reference data changes
consequent on a Budget by start of business on the following day.
Requirements Page 78 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 540 Release spr 4
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Service - design
Requirement Description:
OPS equipment - environmental considerations.
Due attention should be given to the effects of the OPS equipment
on the environment during manufacture, installation and use. This
includes:-
- use of CFCs
- energy consumption
- recyclability of components
- recyclability of consumables
- waste minimisation
- use of sustainable resources
- disposal of displaced equipment and waste
- making appropriate use of recycled materials
The service provider must adhere to relevant environmental
legislation such as the 'Duty of Care'
Requirements Page 79 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 541 Release spr 4
No
Programme POCL Subject POCL Infrastructure (TMS)
Grouping Infrastructure Heading
Flexibility - systems
Requirement Description:
TMS scaleability.
TMS must be scaleable to meet POCL’s business needs.
It must be borne in mind that POCL are looking to re-engineer
current client transactions and develop new capabilities. This may
involve considerable volumes of transactions needing authorisation
from a client system or a central point in POCL.
Requirements Page 80 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 542 Release spr 4
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - steady state
Requirement Description:
Continued support of operating systems ,middleware and
applications software.
The operating system software, any middleware and any
application software used within the services supplied must be
fully supported during the life of any computer systems on which
they are utilised in providing the services.
Requirements Page 81 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 543 Release spr 4
No
Programme POCL Subject POCL Applications (APS)
Grouping Applications Heading
Service - design
Requirement Description:
APS Tokens.
The APS shall support the following range of Tokens:
- Landis & Gyr PISCES smart card;
- GEC Meters WATERCARD smart card;
- Schlumberger Smart Key for the water industry;
- Schlumberger Smart Key for the electrical industry;
- Magnetic stripe card;
- British Gas Quantum smart card;
- Bar coded documents.
Requirements Page 82 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 544 Release spr 17
No
Programme POCL Subject POCL Applications (APS)
Grouping Applications Heading
Service - design
Requirement Description:
APS Clients/Client Service Types.
The CONTRACTOR shall provide the APS to POCL in respect of all its
Clients.
The CONTRACTOR shall provide the APS such that Clients or Client
Service Types (which conforms to generic APS) may be added to,
modified or removed from, the APS on a regular basis.
The CONTRACTOR shall provide assistance to implement an interface
to additional third party applications/Tokens if so required by
POCL.
The CONTRACTOR shall provide technical assistance to support
POCL’s relationship with Clients and potential Clients.
The CONTRACTOR shall develop and maintain the APS in a generic way
that enables additional Client Service types to be added with
minimum cost and disruption.
Requirements Page 83 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 545 Release spr 4
No
Programme POCL Subject POCL Applications (APS)
Grouping Applications Heading
Documentation
Requirement Description:
APS Documentation
The Contractor shall provide technical and overview documentation
describing the APS. The technical and overview documentation is to
be in sufficient detail as to allow POCL to market the Service to
Clients and potential Clients and to consider the suitability of
additional services.
The Contractor shall agree the content of the documentation with
POCL and any changes to it.
The Contractor shall develop and maintain an AP Client
Specification which specifies the details of each Client/Client
Service Type of the APS, including but not limited to the Client
interface specification, the presentation of information on the
OPS, the data involved and any necessary timings.
AP Client Specification contents include:
1. Client identity and overview.
This section identifies the Client for whom a specific instance of
the APS is to be provided and provides an overview of the business
objectives of the service.
2. Tokens and Methods of Payment
A description of the token(s) that the Client requires its
customers to use and the method(s) of payment that are acceptable
to the Client.
3. Transaction data
- Contents
- Validation
- Sort/Substitution/Customisation
- Batching
- Transfer
4. Other data
- Contents
- Validation
- Availability
5. Service Levels
Requirements Page 84 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 546 Release spr 4
No
Programme POCL Subject POCL Applications (APS)
Grouping Applications Heading
Service - design
Requirement Description:
APS General Constraints
The Contractor shall deliver the APS using the POCL Strategic
Infrastructure.
APS shall be available at all counter positions and at such other
places as required by POCL.
The Contractor shall ensure that the availability of each Client
Service Type at each Outlet is individually controllable.
Requirements Page 85 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 547 Release spr 4
No
Programme POCL Subject POCL Applications (APS)
Grouping Applications Heading
Systems - design
Requirement Description:
APS Data Capture and Validation
The CONTRACTOR shall ensure that data are captured correctly
robustly, accurately, securely and as agreed with POCL.
The APS shall, as a minimum, validate data, whether read from
Tokens or entered by the User, in accordance with a set of rules
identified in:
(a) POCL APS Generic Rules;
(b) Token technology specifications;
(c) the AP Client Specification
The APS shall check data, whether read from Tokens or entered by
the User, against any valid Client Data or reference data for the
Client Service Type (e.g. stop lists) and take the action
prescribed in the AP Client Specification or Token Technology
Specification.
The APS shall enable the display of user instructions specific to
a Client Service Type as identified in the AP Client
Specification.
Requirements Page 86 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 548 Release spr 4
No
Programme POCL Subject POCL Applications (APS)
Grouping Applications Heading
Service - design
Requirement Description:
APS Transaction Committal.
The APS shall commit the transaction when:
- monies have been accepted; or
- a transaction has been reversed; or
- a Token has been issued; or
- a Smart Token has been accessed (including an abandoned or
enquiry transaction).
Requirements Page 87 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 549 Release spr 4
No
Programme POCL Subject POCL Applications (APS)
Grouping Applications Heading
Service - design
Requirement Description:
APS Transaction Reversal.
The APS shall enable the reversal of committed transactions if
eligible for reversal as defined in the:
- POCL APS Generic Rules
- Token Technology Specifications
- AP Client Specification.
The Contractor must provide a secure and auditable process for
dealing with transaction reversals.
Requirements Page 88 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 550 Release spr 4
No
Programme POCL Subject POCL Applications (APS)
Grouping Applications Heading
Service - design
Requirement Description:
Update of APS Tokens.
The APS shall write data to APS Tokens in accordance with the
rules identified in the appropriate Token Technology
Specification, AP Client Specification and POCL APS Generic Rules.
Requirements Page 89 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 551 Release spr 4
No
Programme POCL Subject POCL Applications (APS)
Grouping Applications Heading
Service - design
Requirement Description:
APS Receipting.
The APS shall produce a transaction receipt for each committed
transaction.
The transaction receipt shall include, as a minimum, information
sufficient to provide a transaction audit, plus any other
information identified in the appropriate AP Client Specification
and Token Technology Specification.
The receipt produced for a reversal transaction shall identify it
as a reversal and identify the original (reversed) transaction.
In the event of printer failure the APS shall provide information
to enable a manually completed receipt to be produced.
The APS shall enable individual Outlets to produce bi-lingual
receipts (Welsh/English) .
The APS shall facilitate retrieval of transaction information for
the purpose of resolving customer queries in the Outlets and this
may be by retention of a duplicate receipt or by other means.
Requirements Page 90 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 552 Release spr 4
No
Programme POCL Subject POCL Applications (APS)
Grouping Applications Heading
Service - design
Requirement Description:
APS Transaction Collection/Delivery.
The APS shall maintain and deliver committed transactions to POCL
and Clients in accordance with the following:
- APS Generic Rules;
- the appropriate AP Client Specification;
- Token technology Specification.
Requirements Page 91 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 553 Release spr 4
No
Programme POCL Subject POCL Applications (APS)
Grouping Applications Heading
Systems - design
Requirement Description:
APS Client Data Collection and Distribution.
The CONTRACTOR shall ensure that Data Files from POCL and Clients
are collected/received and validated in accordance with the
relevant AP Client Specification, Token technology specification
and POCL APS Generic Rules.
The CONTRACTOR shall ensure that Data Files from POCL and Clients
are available to all, groups of, or specific Outlets in accordance
with the appropriate AP Client Specification, Token technology
specification and POCL APS Generic Rules.
Requirements Page 92 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 554 Release spr 4
No
Programme POCL Subject POCL Applications (APS)
Grouping Applications Heading
Systems - design
Requirement Description:
APS Fallback and Recovery
The CONTRACTOR shall provide fallback facilities for situations
when a User is unable to use part or all of the POCL Strategic
Infrastructure (for whatever reason) and this provision shall
maintain the integrity, auditability, security and levels of
customer service.
The CONTRACTOR shall ensure that following an Incident the User
can return to a known position and identify what transaction data
has to be recovered.
The CONTRACTOR shall ensure that following an Incident any
previously recorded data which has been corrupted is discarded.
The APS shall provide facilities for the re-input (recovery) of
previously captured transaction data which has been lost following
an Incident.
The APS shall provide facilities for the input (recovery) of the
details of customer transactions performed whilst the OPS was
unavailable.
The APS shall provide facilities to enable data recovery to be
achieved swiftly and in an auditable way.
The APS shall enable data recovery to be achieved without impact
to customer service.
The APS is not required to produce a receipt for recovered
transactions (a receipt would have been produced, either manually
or automatically produced, at the time of the counter
transaction).
The APS shall facilitate the over-riding of certain validation
rules for recovery transactions, as specified in the POCL APS
Generic Rules.
Requirements Page 93 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 555 Release spr 17
No
Programme POCL Subject POCL Infrastructure (OPS
Grouping Infrastructure Heading
Systems - design
Requirement Description:
Capabilities of OPS on initial implementation.
1. In all outlets, at all automated counter positions, from
initial implementation, OPS must :-
1.1 support the reading of track 2 from magnetic Cards complying
with ISO 7811 parts 1-4.
1.2 support the reading from and writing to smart Cards complying
with
ISO 7816 parts 1 and 2
and /or ISO 7816 parts 1,2 and 3
and be capable of supporting future applications complying with:
ISO 7816 part 4.
1.3 CONTRACTORS should note that some clients may issue Magnetic
stripe or Smart Cards which do not match the above standards in
all respects. For example, embossing may not be in the correct
position, or the magnetic stripe may not adhere fully to the
standards. CONTRACTORs should indicate the impact of such non-
standard features on their solution.
1.4 Support the reading of 1 dimensional bar codes. The maximum
bar code width to be read will be 10.9cm at a resolution of 9mils.
OPS must support, at minimum codel28, EAN 8, EAN 13, code 39
Support for the Royal Mail four state code (RM4SCC) is not
required.
2. In all outlets from initial implementation EPOSS must:-
2.1 support printing on manually fed pre-printed forms at the
counter, for example Girobank summary forms G4631, G4632 and G4633
2.2 support printing on cheques and other forms at the counter
2.3 support printing of existing client reports at the counter.
This includes printing in large fonts and printing with 90 degree
rotation.
2.4 support the connection to electronic weighing scales, which
will be supplied separately from this procurement. As a minimum,
connections are to include Avery Berkel type D104 and A702. It
must be possible to share a set of weighing scales between OPS at
two or more counter positions.
2.5 support the printing of reports necessary to meet existing
client commitments
Requirements Page 94 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
2.6 support the printing of cash accounts and plain paper
summaries
2.7 support the printing of PDF417 two dimensional barcodes on
forms generated through back office processing. Typically the two
dimensional barcode would be used to contain cash account
information.
2.8 it would be desirable to support the printing of one
dimensional bar-codes at the counter on forms as well as tally
roll print, as a minimum code 128, EAN 8, EAN 13 and code 39
should be printable.
2.9 it would be desirable to support the printing of one
dimensional bar-codes at the back office, as a minimum code 128,
EAN 8, EAN 13 and code 39 should be printable.
Requirements Page 95 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 556 Release spr 17
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - current
Requirement Description:
Schlumberger smart keys
1. In some outlets, from initial implementation, OPS must support
the reading from and the writing to
Schlumberger smart keys.
2. The precise number of outlets and counter positions is not
known at this time; the capability will be required in no more
than 10,500 outlets.
3. The outlets requiring this capability will be chosen on a
geographical basis
4. In any outlet requiring this capability it will be acceptable
to use an external peripheral device which may be shared between
counter positions where practical.
Requirements Page 96 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 557 Release spr 5
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - development
Requirement Description:
Flexibility of OPS.
1. OPS must have the flexibility for additional peripheral types
to be added in the future, including input devices and printers.
2. Up to 3 additional peripheral types may be required within the
next 5 years.
3. There is a potential requirement to support the reading of OCR
to interpret code lines on bills etc. The decision on whether to
implement this capability on initial implementation or later has
not been made and suppliers are requested to indicate what
difference there would be to charges dependent on this.
4. There is a potential requirement to support the reading of 2
dimensional barcodes. The decision on whether to implement this
capability on initial implementation or later has not been made
and suppliers are requested to indicate what difference there
would be to charges dependent on this
5. There is a potential requirement to link OPS to teller cash
dispensers in due course.
Requirements Page 97 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 558 Release spr 5
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - design
Requirement Description:
OPS equipment - capacity.
1. The OPS must support the POCL imperative of keeping transaction
times to a minimum.
2. The OPS must be capable of supporting the entire range of
business transacted at outlets for current and projected volumes
of business.
Requirements Page 98 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 559 Release spr 5
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Interface with OPS
Requirement Description:
Extent of OPS.
1. OPS must be provided in each of POCL’s outlets.
2. OPS must support the automation of all POCL counter
transactions in due course.
3. From initial implementation OPS must be capable of supporting
APS, BES and OBCS and EPOSS.
Requirements Page 99 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 560 Release spr 12
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - steady state
Requirement Description:
OPS equipment - technology refresh.
BA/POCL recognise that technology will change during the period of
the contract, and will wish to take advantage of this.
1. BA/POCL require that no change be made to the specification of
equipment to be used within the POCL strategic infrastructure,
without prior express agreement.
2. BA/POCL require that periodically the specification of the
equipment being used and installed is reviewed with the service
provider, to ensure that the most appropriate technology is
deployed.
Requirements Page 100 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 561 Release spr 5
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Commercial policy
Requirement Description:
Licence indemnities.
The supplier shall indemnify BA/POCL against any dispute of the
suppliers' or BA/POCL's right to utilise the hardware, software or
information used for any of the supplied services, e.g. third
party challenges with reference to licensing or intellectual
property rights. In the event of any dispute, the supplier shall
ensure that there is no impact on service.
Requirements Page 101 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 691 Release spr 7
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Systems - design
Requirement Description:
EPOSS - Inventory Management
EPOSS must allow cash and stock ordering at denomination level.
EPOSS must allow the recording of stock and cash transfers into
and out of the Outlet.
EPOSS must provide a facility to allow the authorised update of
stock and cash through TMS or another remote source as part of
SMS.
EPOSS must allow the physical receipt of stock and cash to be
reconciled by the system against the consignment note. Any
discrepancy must be recorded against the consignment reference.
Requirements Page 102 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 692 Release spr 21
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Systems - design
Requirement Description:
EPOSS - MoPs
EPOSS must accept single or multiple methods of payment as
settlement.
EPOSS must allow the implementation of new types of methods of
payment such as debit cards and EFTPOS.
The Service Provider shall indicate their proposals to implement
an EFTPOS service commencing the first quarter of 1997.
POCL requires an EFTPOS facility as method of payment on EPOSS,
probably just
debit cards initially (e.g. Switch, Connect) but perhaps extending
to credit cards later,
e.g. Visa and Mastercard. The capability to handle both debit and
credit cards from
Day 1 is desirable.
Indicative volumes for end of roll-out are:
* between 30 and 50 million EFTPOS payments p.a.;
* 70% above the floor limit (£15 working assumption) and so
needing authorisation;
* the main transactions for which EFTPOS will be used are
expected to be: motor vehicle licence renewals (34%), bill
payments (38%, about half BT and half others), television licence
payments (11%) and payment for purchases from Post Shops (5%), all
estimates;
* other likely transactions leading to EFTPOS are expected to
include Travel Insurance and Bureau de Change and cash
withdrawals;
* there would be no “cash-back” option initially.
Business arrangements have not yet been finalised but the current
assumptions are for:
* a single “Merchant Acquirer”;
* on-line authorisation and batch transaction submission to be
via TMS;
* reconciliation of EFTPOS payments on the EPOSS transaction log
with an electronic data stream version of the daily bank account
updates;
* signed receipts may be stored in the outlets, remitted to
distribution centres or dispatched to a central facility (which
the Service Provider may wish to offer);
* POCL expects to need to retrieve receipts in order to prove
transactions at 0.2% or between 60,000 and 100,000 p.a. at above
volumes.
Requirements Page 103 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
POCL also requires guidance from the Service Provider as to the
options for EFTPOS on the particular facilities being proposed and
the relative costs and benefits of each.
Requirements Page 104 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 693 Release spr 7
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Systems - design
Requirement Description:
EPOSS - Receipting
EPOSS must allow production of a VAT style customer receipt on
demand.
EPOSS must allow automatic production of a non VAT style customer
receipt to support a specific Client service e.g. BES or APS.
The format of all styles of receipts will be agreed by POCL.
A bilingual Welsh/English receipt header/footer is required..
EPOSS must allow production of additional (duplicate) receipts and
they must be marked as such.
Requirements Page 105 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 694 Release spr 7
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Systems - design
Requirement Description:
EPOSS - Data Capture
Provide an Point of Sale / "Till" function to record all sales.
Data should be automatically recorded in EPOSS if captured during
another service.
EPOSS must allow the input of weight values where scales are not
linked.
EPOSS must be event driven so that both data capture and the
recording of services such as BES and APS are dynamic.
EPOSS must have the facility to read data from any input devise
supplied as part of the OPS.
Requirements Page 106 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 695 Release spr 7
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Systems - design
Requirement Description:
EPOSS - Stock Unit Control
EPOSS must provide the facility to adjust cash and stock levels
within a stock unit to reflect the actual levels on hand.
Each Outlet shall have the flexibility to set up stock unit(s
according to the local working practice requirement.
Within EPOSS there must be a stock unit management facility a
Outlet level to change stock unit options and assignments.
Stock units are individual units of accountability which contain
stock (fixed price items, customer and client specific tokens
rental items, cash and transaction vouchers for an office
accounting period.
EPOSS must allow a clerk or group of clerks to be accountable for
a stock unit, so that each Outlet has at least one stock unit, but
there can be other stock units, effectively operating
independently.
Each stock unit can in turn be tied to both a user or group of
users or a single till or group of tills.
EPOSS must allow each stock unit to be balanced individually. The
stock unit may be balanced more than once within an accounting
week. Cash and stock items must be entered by denomination or
stock item level. This applies whether or not multiple tills are
linked to a single stock unit.
At the end of the office accounting week an office balance is
struck with the details provided by the balanced stock units.
An Outlet will bring to account manual voucher transactions,
automated voucher transactions, report the suspense account
position and the stock and cash totals within the approved cash
account format.
The cycle will be repeated in the new accounting week with an
office balance brought forward value that will include the stock
and cash in hand, suspense account and loss and gain position
from the previous period.
EPOSS must provide a secure mechanism for controlling access to a
stock unit.
Requirements Page 107 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 696 Release spr 7
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Systems - design
Requirement Description:
Reporting
EPOSS must allow production of a daily report that will show, at
office level the cash holdings by individual denomination of bank
note and coin. The format of the report will be agreed by POCL and
the Contractor.
EPOSS must support the summarisation of daily and weekly
transaction vochers at stock unit level.
EPOSS must support a reporting facility to print on Client cut
sheet stationary where the client requires it (such as Girobank
daily summaries).
Girobank is only a current example - we neeed to keep the
flexibility to print on other cut sheets e.g. Tax Discs / cheques
in due course.
The format of all styles of receipts will be agreed by POCL and
the Contractor. A bilingual Welsh/English version is required.
EPOSS must allow production of duplicate receipts and they must be
marked as such.
EPOSS must support the summarisation of daily and weekly
transaction vouchers at stock unit level.
EPOSS must support a reporting facility to print on Client cut
sheet stationary to support Girobank and the Postmaster’s daily
Record (PDR) summarisation.
EPOSS must support reporting by journal/tally roll and on A4
sheets to predefined Client requirements at both stock unit and
office levels.
EPOSS must allow reporting to be previewed on screen.
Requirements Page 108 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 697 Release spr 7
No
Programme General Subject General
Grouping Heading
Audit
Requirement Description:
Audit Access
The CONTRACTOR and his Sub-CONTRACTORs shall keep or cause to be
kept full and accurate records (including financial records) of
all services provided to the AUTHORITIES, covering materials and
services provided, timesheet records, contracts let to Sub-
CONTRACTORs and charges levied to the AUTHORITIES. These records
will be those held for the CONTRACTOR's own audit purposes.
The CONTRACTOR shall permit the AUTHORITIES or AUTHORITIES'
representatives (including internal and external auditors, the
National Audit Office and any other independent body appointed by
the AUTHORITIES) unrestricted access to the records relating to
the provision of services to the AUTHORITIES for the purpose of
auditing and reporting on the operation, including charging and
accounting aspects, of the services and the performance of the
contract.
The BA will have the right to inspect the PAS and CMS, POCL will
have the right to inspect the TMS and all applications utilising
OPS. The AUTHORITIES may appoint an independent auditor to examine
areas that are mutually commercially sensitive.
Such access will be provided on request and will include access to
premises, facilities, services documentation, information
(magnetic or otherwise), staff, procedures, timesheets and other
data used as a basis for charging belonging to the CONTRACTOR
which relate to the provision of service to the AUTHORITIES.
Such access shall be required within 4 hours where investigation
into suspected impropriety or negligence must be carried out.
The CONTRACTOR shall implement audit recommendations in accordance
with provisions of the change control procedures.
The CONTRACTOR shall provide within reasonable timescales either
documentary or demonstrable evidence of such changes and shall if
required provide access to the AUTHORITIES' representatives to
monitor and confirm the implementation of such changes.
Clarification:
The following clarifications are provided in relation to this
requirement:
3rd paragraph - DSS will have the right to inspect the PAS and
CMS
Requirements Page 109 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
5th paragraph - The AUTHORITIES will wish under change control
to change the requirement for access from 'within 4 hours' to
‘immediately on request!
Requirements Page 110 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 698 Release spr 7
No
Programme General Subject General
Grouping Heading
Security
Requirement Description:
Security Policy
The CONTRACTOR shall minimise and control liabilities to itself
and the AUTHORITIES.
The CONTRACTOR shall set-up an organised security infrastructure
covering:
- The agreement of a Security Policy
- Allocation of Security Responsibilities;
- Security Education and Training;
- Reporting Security Incidents;
- Physical Security Control;
- Virus Control;
- Business Continuity;
- Control of Proprietary Software;
- Safeguarding BA and POCL Records;
- Information Classification;
- Compliance with Data Protection and other legislation;
- Information Exchange Control;
- External Contractors and Suppliers;
- Compliance with Security Policy;
- The management of fraud and risk during service operation.
The implementation of a security policy with the features
described is one means by which risk can be assessed, monitored
and controlled. The suppliers will have additional policies that
achieve the same objectives.
The Service Provider shall be compliant with BS7799.
Clarification:
The following clarification is provided in relation to paragraph 2
of this requirement:
"Safeguarding BA and POCL Records' should read as 'Safeguarding
DSS and POCL Records'
"External CONTRACTORs and CONTRACTORs' should read ‘External
contractors and CONTRACTOR's sub contractors and suppliers'
Requirements Page 111 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 699 Release spr 7
No
Programme General Subject General
Grouping Heading
Audit
Requirement Description:
Audit Trail
1. An audit trail must be maintained during periods of service
operation including fallback and recovery.
2. The audit trail must record all data file transfer,
messaging and processing, whether as a result of manual or
automated action.
3. The information recorded must be sufficient to identify the
action, by whom it was undertaken, when it was undertaken, why it
was undertaken and the resulting outcome.
4. The audit trail must allow activities that utilise more than
one of the services provided to be traced across the services
from start to finish, or from an intermediate service in any
direction, with certainty.
5. The audit trail must provide information to allow the
original transaction to be recreated.
6. The content of the audit trail must be agreed explicitly with
the AUTHORITIES.
7. Audit trail records must be retained for a period consistent
with Companies Act requirements.
8. The audit trail must be available for inspection by the
AUTHORITIES.
9. The audit trail must have a level of security such that it
cannot be altered or deleted.
10. The integrity of the audit trail must be continued during
periods of partial or complete service loss or failure.
11. It must be possible to provide a suitable legal assurance as
to the integrity of the audit trail.
12. Technological changes must not render the audit trail
unusable.
Clarification:
The following clarification is provided in relation to this
requirement:
3. The information provided should also indicate where the action
was undertaken
7. Records should be provided for a period consistent with
Companies Act requirements, or a period of 18 months, whichever is
the greater
Requirements Page 112 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 700 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Systems - design
Requirement Description:
The CONTRACTOR shall supply and issue Benefit Payment Cards to the
correct Authorised Person, to support benefit payment when
notified by CAPS. Only changes to personal details authorised by
the DSS through CAPS may be made.
Requirements Page 113 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 701 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Policies & standards
Requirement Description:
All Benefit Payment Cards and Temporary Tokens remain the property
of the Secretary of State.
Requirements Page 114 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 702 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Policies & standards
Requirement Description:
The Card can only be used for benefit payment unless authorised by
the Secretary of State.
Requirements Page 115 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 703 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Policies & standards
Requirement Description:
Card designs are subject to approval of the Secretary of State.
Requirements Page 116 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 704 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - development
Requirement Description:
The CONTRACTOR must ensure that they will supply and maintain
cards of more than one livery / logo.
Clarification:
The following clarification is provided in relation to this
requirement:
The CONTRACTOR will ensure that at any time an Authorised Person
will not have more than one valid card
Requirements Page 117 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 705 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
Details to appear on the card are as follows:-
NINO
Authorised Person Initials & Surname
Card ID No
Expiry Date
ee eH
Requirements Page 118 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 706 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
Every card number shall be unique and must conform to financial
industry numbering standards as within the Benefit Payment Card
technical specification document.
Requirements Page 119 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 707 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
The CONTRACTOR must ensure that a facility is available to allow
for emergency encashment when a valid Card is not available, i.e.
Temporary Token.
Clarification:
The following clarification is provided in relation to this
requirement:
If Temporary Tokens are to be used, there will need to be a secure
method of supplying the Temporary Tokens, recording and
replenishing stock levels at the prescribed points of issue.
Requirements Page 120 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 708 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Policies & standards
Requirement Description:
The CONTRACTOR must conform to the relevant financial industry
standard for Card usage. They must also conform with the agreed
life expectancy of the Card, to be agreed between the CONTRACTOR
and the DSS.
Requirements Page 121 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 709 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
The CONTRACTOR must provide a migration strategy to Integrated
Circuit (IC) smart Card technology for all Benefit Payment
Services within a time frame to be agreed within the DSS.
Requirements Page 122 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 710 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Security
Requirement Description:
The CONTRACTOR must ensure that a series of successively more
secure anti-fraud measures can be deployed using the proposed
underlying architecture, infrastructure and interfaces without the
need for significant re-engineering and must not have an impact on
the overall transaction time.
Requirements Page 123 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 711 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Security
Requirement Description:
The CONTRACTOR must be capable of updating any chosen security
verification details or procedures without adversely affecting the
Authorised Persons ability to collect Authorised Payments and must
not have an impact on the overall transaction time.
Requirements Page 124 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 712 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
Card production, personalisation and size must conform to relevant
International Standards Organisation (ISO) and Association of
Payment and Clearing Services (APACS) standards as detailed within
the Benefit Payment Card technical specification document.
Requirements Page 125 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 713 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Systems - design
Requirement Description:
CMS will renew a Card when the Card has reached the end of its
life expectancy and CAPS has not indicated that no further Cards
are required.
Requirements Page 126 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 714 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
Renewal Cards must be available for the Authorised Person in good
time, so that the renewal does not impinge upon the Authorised
Persons ability to collect benefits and there is no impact on DSS
offices.
Requirements Page 127 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 715 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
Replacement Cards must be available for use by the Authorised
Person in time to access their benefits following notification
from the DSS that any of the Authorised Persons details relating
to the Card (Card type) or details shown on the Card have
changed or where the Authorised Person has reported the Card as
lost, stolen, damaged, or not available.
Requirements Page 128 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 716 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
CMS will accept a notification from CAPS when a Authorised Person
no longer requires a Card and will send no further Cards to that
Authorised Person. On expiry CMS must remove the Authorised
Persons details from the operational database in accordance with
archiving policy (x-ref 753).
Requirements Page 129 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 717 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
When a Card is renewed CMS will invalidate the previous Card when
it expires or when the new Card is activated, whichever occurs
first. Until the old Card is invalidated, CMS must not allow the
new Card to be used.
Requirements Page 130 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 718 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
The CONTRACTOR will ensure that the issue of initial, renewal and
replacement Cards does not adversely affect the Authorised Persons
ability to collect Authorised Payments.
Requirements Page 131 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 719 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Security
Requirement Description:
The CONTRACTOR shall distribute CARDS by secure method(s) agreed
in advance of their use by the DSS and the CONTRACTOR.
Requirements Page 132 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 720 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Systems - design
Requirement Description:
The CONTRACTOR shall ensure that CMS will record:-
1. Date and time of request received from CAPS to issue a Card;
2. Date, time, location of production facility, destination of the
Card issued by the CONTRACTOR;
3. Expected date of arrival of the Card at its destination;
4. Method of Card delivery (if appropriate);
5. Card received at the collection location (date, time, and
location received at) if appropriate;
6. Card returned from location,if appropriate and to include
(date, time and reason for return e.g. damaged, uncollected)
7. Pick Up Notice (PUN) issued if appropriate and to include
(date, time, method of delivery, destined collection location);
8. Card in Authorised Persons possession;
9. Cards incapable of activation and use by the Authorised Person
due to the Card being damaged or unserviceable on delivery;
10. If the CONTRACTOR intends to use a collection location, CMS
must record the issue of a reminder to the Authorised Person after
(initially but subject to review) forty (40) days of non-
collection of the Card requesting that they pick up the Card or
contact the DSS to inform them of any change of circumstances.
Requirements Page 133 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 721 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
If the CONTRACTOR intends to use a collection location for the
issue of new or replacement Cards they shall ensure that
Authorised Persons are notified of their availability.
Requirements Page 134 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 722 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Security
Requirement Description:
Card Authentication methods must be positive rather than negative,
resistant to forgery or other unauthorised manipulation and
include a mechanism agreed by the CONTRACTOR and the DSS for
identifying the attempted use of non genuine and invalid Cards and
Temporary Tokens.
Requirements Page 135 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 723 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Security
Requirement Description:
Cardholder Verification methods must be resistant to impersonation
and shall include a mechanism agreed by the CONTRACTOR and DSS for
identifying the attempted use of a Card or Temporary Token by a
person other than an Authorised Person.
Requirements Page 136 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 724 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
CMS will on request from the DSS, invalidate a Card or Temporary
Token and change and record the new status.
Requirements Page 137 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 725 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Security
Requirement Description:
The CONTRACTOR shall automatically and immediately invalidate a
Card or Temporary Token when CMS determines that it has not been
received at the collection location or home address within three
(3) working days of the expected arrival at that location.
Requirements Page 138 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 726 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Security
Requirement Description:
The CONTRACTOR shall automatically and immediately invalidate a
Card if it is not in the Authorised Person's possession within
(initially but subject to review) 56 (fifty six) calendar days of
its issue. Temporary Tokens will be invalidated (initially but
subject to review) seven (7) calendar days from the date of
issue.
Requirements Page 139 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 727 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Security
Requirement Description:
The CONTRACTOR shall on receipt of the appropriate data,
invalidate a Card or Temporary Token following a report of loss,
theft, destruction or damage beyond use of the Card or Temporary
Token by the Authorised Person or the DSS.
Requirements Page 140 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 728 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
CMS must be able to monitor the issue, distribution, collection,
usage and status of current or previous Cards, ensuring that
status confirmation is available for secure and auditable enquiry
by all DSS staff at locations to be agreed by the CONTRACTOR and
the DSS, but as a minimum all DSS offices.
Requirements Page 141 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 730 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Customer services
Requirement Description:
The CONTRACTOR shall provide a Customer service Help Desk facility
(accessed via a Freephone or low rate call service), to deal with
general enquiries, reports of loss, damage and theft of Cards from
Authorised Persons.
Requirements Page 142 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 731 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Interface with BA staff
Requirement Description:
The CONTRACTOR shall provide secure and auditable access to CMS
to enable authorised DSS staff to notify the CONTRACTOR of a Card
or Temporary Token termination.
Requirements Page 143 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 732 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
In response to enquiries made via CMS, the CONTRACTOR shall ensure
that the service displays as a minimum the following
information:-
* Authorised Persons NINO;
* Card identification number;
* Card status;
* previous Card status and date status changed.
Requirements Page 144 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 733 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Customer services
Requirement Description:
The CONTRACTOR shall provide a Help Desk function for DSS staff as
defined within the Service Levels and Remedies Schedule.
Clarification:
The following clarification is provided in relation to this
requirement:
add "and the Service Interface Definition Document" at the end of
sentence
Requirements Page 145 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 736 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Integration of services
Requirement Description:
The CONTRACTOR shall ensure that a logical separation is
maintained between CMS, PAS and POCL Infrastructure and have in
place a detailed interface specification agreed between the
CONTRACTOR and DSS to support this.
Requirements Page 146 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 740 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Security
Requirement Description:
The CONTRACTOR shall ensure that all relevant information produced
at the request of the DSS shall be evidentially admissible and
capable of certification in accordance with the Police and
Criminal Evidence Act. (PACE) 1984 and the Police and Criminal
Evidence [Northern Ireland] Order 1989.
Clarification:
The following clarification is provided in relation to this
requirement:
add "and equivalent legislation covering Scotland". After Order
1989
Requirements Page 147 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 741 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Flexibility - services
Requirement Description:
CMS will support the payment of existing, new and additional
benefits and any change to existing benefits.
Requirements Page 148 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 742 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Interface with BA staff
Requirement Description:
The CONTRACTOR shall be aware of the requirements imposed by the
Welsh Language Act 1993 and will ensure that the CMS has the
capability of producing bi-lingual Cards and collateral material
as required for those Authorised Persons living in Wales.
Requirements Page 149 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 743 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Management information
Requirement Description:
Service Level reports must be received no less then five (5)
working days before regular Service Review meetings. Reports
required for ad hoc meetings will be provided in agreement with
the AUTHORITIES.
Requirements Page 150 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 744 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Management information
Requirement Description:
Service Level reports must indicate performance against all
service levels detailed in the Service Levels and Remedies
Schedule.
Requirements Page 151 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 745 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
If the CONTRACTOR intends to use a collection location for the
issue of new or replacement Cards, CMS must recognise the failure
of an Authorised Person to collect the Card within forty (40)
calendar days of issue and send a reminder note to the Authorised
Person advising them to pick up the Card or contact the DSS.
Requirements Page 152 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 746 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
The CONTRACTOR must have contingency procedures to allow payments
to continue to be made without degradation of service if any
failure occurs with any components of the Benefits Payment Service
(BPS) or any service required to operate BPS.
Requirements Page 153 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 747 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Security
Requirement Description:
All aspects of Card Management including production, storage,
delivery and destruction of Cards must be secure, auditable and
allow the production of audit trails of all Cards and collateral
material.
Requirements Page 154 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 748 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
The CONTRACTOR must deal directly with Card related enquiries
ensuring that Authorised Persons are provided with a seamless, one
stop service.
Requirements Page 155 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 749 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
The CONTRACTORS Card distribution process must allow for
circumstances where the Authorised Person is unable to visit a
Post Office, DSS office or other office in person in order to
collect their Benefit Payment Card.
Requirements Page 156 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 750 Release spr 8
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Customer services
Requirement Description:
If the CONTRACTOR intends to use a collection location for the
issue of new or replacement Cards, it shall have contingency plans
in place for the situation where there is an inconsistency between
pick-up information and actual Card availability. (E.g. pick-up
information provided and no Card available, pick-up information
missing and Card available.)
Requirements Page 157 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 751 Release spr 19
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Systems - design
Requirement Description:
The CONTRACTOR shall ensure that Authorised Payment information
forwarded from CAPS to PAS is accepted and available for
subsequent encashment from the due date until the end of the
period of validity.
Requirements Page 158 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 752 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
PAS must recognise payments from CAPS that have been advanced due
to a National or Regional holiday (so that the Post Office clerk
and Authorised Person can be informed) .
Requirements Page 159 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 753 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
CAPS will supply and revise personal details to PAS until they are
no longer required, at which point personal details must be
deleted from the operational database and archived in accordance
with an archiving policy to be agreed between the CONTRACTOR and
the AUTHORITIES (x-ref 716).
Requirements Page 160 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 754 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
PAS must support Urgent Payments forwarded from CAPS.
Requirements Page 161 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 755 Release spr 19
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
A facility to stop payments authorised must be available on stop
request from CAPS, so that payments so identified cannot be
encashed. Following the receipt of a request, PAS must notify CAPS
of the success or failure of the stop (x-ref 766).
Requirements Page 162 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 756 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
PAS must accept new or changed personal details provided through
CAPS and take them into account in any subsequent encashment or
enquiry.
Requirements Page 163 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 758 Release spr 19
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
PAS must recognise different types of payments according to the
timing constraints of the payment (urgent,next day etc.) as
defined in the Service Levels and Remedies Schedule.
For all payments PAS must recognise four (4) different types of
status:
* stopped payments;
* encashed payments;
* uncashed payments;
a) received but not due;
b) due but not collected and within the validity period;
* uncollected payments beyond validity period.
Requirements Page 164 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 759 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service management
Requirement Description:
PAS must support the authentication process to ensure that valid
Cards are accepted and invalid Cards rejected.
Requirements Page 165 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 760 Release spr 19
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Customer services
Requirement Description:
Following the successful authentication process to validate the
Card, PAS must provide the data to support verification of
Authorised Person's identity. If an Authorised Person is
collecting benefits on behalf of other Beneficiaries the
verification and authentication checks must only be required once
per visit to the Post Office counter.
Requirements Page 166 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 761 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Security
Requirement Description:
PAS must have the provision to advise the Post Office clerk of the
action to be taken when Card Authentication or Cardholder
Verification checks are not satisfied.
Requirements Page 167 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 762 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
PAS must respond to CAPS requests for encashment status on
particular payments, with either the relevant encashment data or
with an indicator that the payments has not been encashed.
Requirements Page 168 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 763 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
PAS must allow for payment of cash and tokens (e.g milk tokens) as
authorised by CAPS.
Requirements Page 169 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 764 Release spr 19
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
PAS must support the production of legible receipts with details
as follows:-
* Authorised Person's name and abbreviated NINO;
* Appointee's Name and abbreviated NINO; (if appropriate)
* Name of Permanent Agent and Signing Agent and abbreviated NINO
(if available) (including Casual Agent if possible.);
Benefit Payment Description;
Amount (Ss);
Signature - (space for signature clearly identifiable);
Time - (numerical 24 hour clock);
Date - (DD/MM/YY);
Due dates;
Token Type;
No.of token(s);
Code of Post Office of payment;
Predicted due date of next payment;
Total amount encashed;
Declaration of Entitlement (combined or otherwise);
Message (subject to physical constraints of receipts and CAPS);
Pe
The receipt must also include the following details produced
externally from PAS;
* Unique encashment transaction identifier;
* Unique Post Office counter clerk transaction identifier.
Clarification:
The following clarification is provided in relation to this
requirement:
amend first and third bullet points to read:-
* Beneficiary’s name and abbreviated NINO
* Name and abbrieviated NINO (if available) of Person collecting
payment(s) eg Permanent Agent, Signing Agent, Casual Agent (if
possible)
and in brackets after bullet point "Unique encashment transaction
identifier the following wording":-—
(Either this must be the same as that passed back to CAPS with the
encashment confirmation or it must be possible to cross reference
for audit purposes).
Requirements Page 170 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Receipts for any Authorised Person receiving a benefit from a Post
Office in Wales can receive a receipt in Welsh if required
(thereby complying with the Welsh Language Act 1993).
Requirements Page 171 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 765 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Process - development
Requirement Description:
PAS must support the process to prompt the post office clerk to
retain the original signed receipt (together with any other forms
presented) for us by the DSS. The forms to be accepted are to be
agreed between the CONTRACTOR and the DSS.
Requirements Page 172 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 766 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
PAS must support the process necessary to allow the encashment to
be terminated before it is completed if the Authorised Person or
DSS so requests (x-ref 755).
Requirements Page 173 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 767 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
PAS must support payment to Authorised (as identified within the
payment data passed from CAPS) and Casual Agents.
Requirements Page 174 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 768 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
As a minimum, any conditions which apply to the Authorised Person
or payments made to them will also apply to a Casual Agent
encashment (x-ref 944).
Clarification:
The following clarification is provided in relation to this
requirement:
While procedures for Casual Agent encashment may be more stringent
than current procedures, they must not cause undue hardship to DSS
Customers
Requirements Page 175 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 769 Release spr 21
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
PAS must support the use of Nominated Post Offices, as notified by
CAPS. Appointees, Alternative Payees and Permanent Agents will
have their own Nominated Post Office for their Card (if
applicable) and payment collection, distinct from that of the main
Authorised Person.
Requirements Page 176 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 770 Release spr 19
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
Foreign Encashments must be limited to (x) in a rolling (y) week
period (where (x) and (y) are parameters to be provided by the
DSS, initially (x)=2 and (y)=26), PAS must prompt the Post Office
clerk to inform the Authorised Person on the final allowable
Foreign Encashment, of the date of the next allowable Foreign
Encashment (equivalent information to be printed on the receipt),
and that to collect further payments a change of Post Office is
required, or return to the Nominated Post Office. PAS must not
identify the Nominated Post Office. Social Fund payments must be
excluded from the rule, except where other benefits are encashed
at the same time. Encashment of Temporary Tokens are also
excluded from this rule as they will have a Post Office nominated
by the DSS at the time of issue.
Clarification:
The following clarification is provided in relation to this
requirement:
When the CONTRACTOR is notified by the AUTHORITY that for whatever
reason the Nominated Post Office is closed the Authorised Person
will be allowed to encash their benefit at a Post Office other
than their Nominated Post Office and the transaction will not be
recorded as a Foreign Encashment . If the Post Office is closed
and the Authorised Person is subject to a restriction in where
they encash their benefits, the Authorised Person should be
referred to the DSS Office for a contingency Post Office to be
nominated.
Requirements Page 177 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 771 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
PAS must restrict encashment to one specific Post Office's when
notified by CAPS to do so. Restriction will be in respect of an
Authorised Person, or any person collecting benefit on their
behalf.
Requirements Page 178 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 772 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
PAS must provide for an encashment to proceed in the event of a
Card Read Failure, subject to Card Authentication and Customer
Verification checks being satisfied.
Requirements Page 179 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 773 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
PAS must ensure that encashment confirmation is provided to CAPS
for each Authorised Payment that is collected.
Requirements Page 180 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 774 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
Uncollected payments that have reached the end of their validity
period must be invalidated.
Requirements Page 181 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 776 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
The CONTRACTOR must provide a Help Desk function for DSS staff.
Requirements Page 182 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 778 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
The CONTRACTOR must ensure that any services are able to interface
and exchange information with CAPS.
Requirements Page 183 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 779 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Security
Requirement Description:
Integrity of payment details must be maintained to ensure data is
not alterable once transferred from CAPS, except where specified
in requirement 798.
Requirements Page 184 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 780 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service management
Requirement Description:
Police and Criminal Evidence Act 1984 and PACE(NI) Order 1989
certification must be provided to demonstrate services were
operating within normal parameters at time of an alleged offence.
Clarification:
The following clarification is provided in relation to this
requirement:
The CONTRACTOR shall ensure that all relevant information produced
at the request of the DSS shall be evidentially admissible and
capable of certification in accordance with the Police and
Criminal Evidence Act (PACE) 1984, the Police and Criminal
Evidence (Northern Ireland) Order 1989 and equivalent legislation
covering Scotland.
Requirements Page 185 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 781 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
Any records denoted as sensitive must be treated in accordance
with the Social Security IT Security Standards document.
Requirements Page 186 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 782 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
PAS must provide the facility to allow the Contracting Authority
to identify where and when a card or number of cards are being
used, within two (2) seconds of use.
Clarification:
The following clarification is provided in relation to this
requirement
Where DSS Investigations staff (i.e. BA OFT) require immediate
information on where a specific Card has been used the CONTRACTOR
will allow secure password controlled access to the PAS helpdesk
for the information. Information to be provided immediately. The
number of DSS staff with the access will be limited and will be
for agreement between the DSS and CONTRACTOR. This facility would
be in addition to any access that may be provided to DSS staff in
general to support payment enquires (should this be required by
the CONTRACTORS solution).
Requirements Page 187 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 783 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
PAS must support payment of existing, new and additional benefits
and any change to existing benefits or frequency of payments.
Requirements Page 188 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 785 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Management information
Requirement Description:
Service Level reports must be received no less than five (5)
working days before regular Service Review meetings. Reports
required for ad hoc meetings will be provided in agreement with
the DSS.
Requirements Page 189 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 786 Release spr 19
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service management
Requirement Description:
Service Level reports must indicate performance against all
service levels detailed in the Service Levels and Remedies
Schedule.
Requirements Page 190 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 787 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
Where an Authorised Person has nominated an Alternative Payee who
may collect specified benefit(s), PAS must ensure that the payment
can also be collected by either person, but paid only once.
Requirements Page 191 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 788 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Security
Requirement Description:
Where an Authorised Person is collecting payments for more than
one beneficiary PAS must allow the Authorised Person to select the
beneficiary for whom they want to collect.
Clarification:
The following clarification is provided in relation to this
requirement:
An Appointee for more than one Beneficiary may select the
beneficiary’ they wish to collect for. This requirement should be
cross referenced with requirement 767 and vice versa
Requirements Page 192 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 789 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
If the Authorised Person is collecting payments for more than one
Authorised Person i.e. Permanent/Casual Agent encashments
(including potentially himself), PAS must enforce a separate
handover of payment supported by a separate receipt for each.
Clarification:
The following clarification is provided in relation to this
requirement:
after Authorised Person, amend "i.e" to "e.g"
Requirements Page 193 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 790 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
Where a system failure requires manual keying of a Card number the
CONTRACTOR must provide a system for the detection of incorrect
keying of Card numbers to prevent the wrong account being
accessed.
Requirements Page 194 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 791 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
PAS must inform CAPS if an encashment is attempted which would
infringe a restriction to a single Post Office imposed by the DSS.
Requirement 793 Release spr 19
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
The CONTRACTOR must ensure that for every payment encashed there
must be a Declaration of Entitlement signed by the Beneficiary
(or, where appropriate the Appointee or Alternative Payee).
A signature is also required from the Authorised Person collecting
the payment to confirm receipt.
Where appropriate (i.e. it is the same person) a single signature
will serve to confirm entitlement and receipt.
A further signature may be required from the Authorised Person to
authorise collection by a Permanent Agent or Casual Agent.
Requirements Page 195 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 794 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Customer services
Requirement Description:
Access to PAS can only be achieved within the Post Office by the
use of a valid and genuine Card or a valid and genuine Temporary
Token.
Requirements Page 196 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 795 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
PAS must determine the total amount of benefit available for
encashment (based on Requirement 904). The individual amounts (as
supplied by CAPS) and the total must be shown, to the Post Office
clerk.
Requirements Page 197 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 796 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Customer services
Requirement Description:
If no payment is due PAS will prompt the Post Office clerk to
return the Card to the Authorised Person and in cases of dispute
or enquiry advise them to contact the DSS. In these circumstances
if the Authorised Person requests it, PAS must have the facility
to produce a receipt showing nil entitlement due.
Requirements Page 198 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 797 Release spr 19
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service management
Requirement Description:
As part of the contingency arrangements for failure of CAPS, PAS
must be able to continue payments to Authorised Persons based on
the most recent payment successfully passed from CAPS. This
facility must be enabled only if and when explicitly requested by
the DSS. Such emergency payment must be for the same payment value
and be due on the “next payment earliest encashment date” as
specified in the last correctly authorised payment from CAPS (but
only if that due date has not passed). For a given Authorised
Person, emergency payments must be limited to no more than one for
each benefit type, unless specifically requested by DSS.
At the explicit request of the DSS, contingency payments made on
this basis may need to be repeated (using the appropriate interval
between the last correctly Authorised Payment and the next payment
due i.e. weekly, four weekly etc.)
Clarification:
The following clarification is provided in relation to this
requirement:
line 8 delete wording in brackets beginning (but only if that due
date....)
line 10 change Authorised Person to Beneficiary
Requirements Page 199 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 798 Release spr 8
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service management
Requirement Description:
PAS must accept change of Nominated Post Office at the counter,
if required by the Authorised Person(s) (or an Appointee or legal
representative). This change must be supported by completion of
form P80MA or equivalent. This change must take effect, so that
any due payment can be collected. This facility must not be
available to those restricted to a single Post Office. The
Nominated Post Office can only be changed to that in which the
request is made. PAS must pass the change to CAPS.
Requirements Page 200 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 799 Release spr 9
No
Programme POCL Subject POCL Applications (APS)
Grouping Applications Heading
Service - design
Requirement Description:
APS Token Issue
The CONTRACTOR shall provide a facility that permits the issue at
Outlets of replacement APS Tokens and APS Tokens for new
customers, as directed by POCL.
Requirements Page 201 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 800 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Serve Customers (A)
EPOSS must support the recording of all transactions between the
customer and the clerk.
EPOSS must allow the selection of a customer session to allow for:
- normal customer service or
- a customer refund or,
- a reversal to correct errors in data entry.
EPOSS must uniquely identify a customer session and each
transaction within the balance period.
EPOSS should allow customer session completion in an ordered
fashion. This is required to encourage a 'one customer one
session' rule.
EPOSS must allow a cash tendered facility to calculate change due
to the customer. Use of this feature must be at the discretion of
the user and not forced by EPOSS.
Requirements Page 202 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 801 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Product Styles.
EPOSS must support the current range of business performed within
Outlets that are generically grouped as:
- Value Stock,
- Method of Payment,
- a counter shortage known as a "Loss",
- a counter overage known as a "Gain",
- a Retail sales product
- an inpay supported by a Client voucher (receipt)
- an outpay supported by a Client voucher (payment)
EPOSS must support the customer transaction by price type:
- Fixed Price (price fixed to that looked up by the
system) or
- Variable Price (price set by the clerk, overwriting a
default looked up by the
system).
Variable Price products are of one of two forms:
- Open Price where the clerk will enter the actual price, If
the valid range excludes
zero, the clerk will be forced to change to enter a non
zero price.
- Default Price where the default price is non zero. The
clerk can either accept
this price or can overtype to change it within the legal
range.
Where necessary 'Composite' products will be broken down and
declared at individual denomination level by the clerk as part of
the balancing activity.
Requirements Page 203 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 802 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Value Stock Management
EPOSS must maintain the current stock record for value stock
products and MoPs to reflect the transactions done, so that if a
postal order and the associated fee are sold for cash the stock of
the former is decreased and that of the cash is increased.
EPOSS must allow compensating errors to be remedied without the
need to perform a reversal or a sale.
Requirements Page 204 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 803 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Data Resilience.
EPOSS must accurately maintain data and avoid recording a one
sided transaction session.
If the OPS is interrupted or fails during a customer session the
system must ensure that data capture is resiliant and consistent
with the need to retain a balanced status.
Requirements Page 205 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 804 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Transaction Log /Inspection
A journal of all transaction data must be available to allow the
User to refer back to a previous transaction.
EPOSS must provide a transaction log for any balancing period in
the current accounting period by stock unit.
This function maybe used in conjunction with a transaction
reversal where the User need to identify the unique transaction
identification.
The Transaction Log must be readily available for the resolution
of enquiries.
Requirements Page 206 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 805 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Audit/Event Log and Inspection.
EPOSS must maintain a log of activities attempted and actioned at
stock unit level.
EPOSS must provide an Audit/Event Log for any balancing period in
the current accounting period by stock unit.
EPOSS must provide a facility to allow the User to inspect
activities on the stock unit within the accounting period so
that for example all attempts to access a stock unit can be
detected.
The Audit/Event Log must be readily available for the resolution
of enquiries.
Requirements Page 207 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 806 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Set Date and Time
Maintain the date and time as accurate within EPOSS and remain
instep with the GMT and BST.
Requirements Page 208 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 807 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Transfers between Stock Units.
EPOSS must allow and record the movements of value stock products
and MoPs into and out of stock units within the same office.
Allow a transfer event for one or more value stock products and/or
MoPs.
The data should be entered in a transaction set similar to a
customer session except that the session total comes to the
transfer total rather than to zero.
The system adjusts product stock levels when the data entry
session is complete so that the "Balance" of the system is
maintained.
Each transfer is entered to the current balance period for the
stock unit.
Requirements Page 209 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 808 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Office balance
EPOSS must provide a facility to reconcile non value items with
unique serial numbers.
Reconciliation will be by volume initially and by stock unit as:
- number on hand at the start of the outlet accounting
period (plus)
- number received (equals)
- number on hand at close of outlet accounting period (plus)
- number issued/spoilt/returned.
EPOSS must provide a suspense account facility where items that
cannot be cleared operationally during one outlet accounting
period can be identified and carried forward to the next.
EPOSS must provide an on demand office balance report to a POCL
agreed format that will provide a snap shot of Outlet position
with the current outlet accounting period.
Requirements Page 210 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 809 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Customer Session
Within a customer session maintain:
- a running record of all transactions performed
- the current balance
- the accounting sense (pay out/take in)
- settlement details.
Multiple transactions for the same customer must be logically
grouped into a single customer session.
Requirements Page 211 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 810 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Transaction Rules
EPOSS will allow the refund or reversal of a transaction with
access maintained at user level. Note that certain transactions
may not be refundable or reversible to comply with Client and POCL
accounting and business rules.
EPOSS must be able to validate against reference data. For example
price look up and Client parameters.
Provide the ability to ‘rate shop’ against a value input for a
fixed price product.
Requirements Page 212 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 811 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Data transmission
EPOSS must allow the facility for all recorded information to be
passed to TMS or other authorised remote location.
EPOSS must be flexible enough to support the introduction of new
Client services in an integrated manner and thereby ensure that
any new product is event driven and that EPOSS is automatically
updated.
Requirements Page 213 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 812 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Transaction Reversal
EPOSS must allow a reversal transactions for customer service and
transfers either within the Outlet or to a remote location.
Reversal transactions may be entered for normal transactions (but
not for reversal transactions) as follows:
Only for customer service transactions which are not part of other
services e.g. BES or APS or disallowed in reference data.
All such reversals need not correspond to a particular transaction
on the transaction log, which allows for correction of bulk
figures where the requirement is to get the totals right but the
detail is not critical.
Requirements Page 214 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 813 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Revaluation of Value Stock.
EPOSS must allow revaluation of fixed price value stock products
and MoPs when the price changes.
While price changes would not normally apply to MOPs, the
possibility is allowed in case of future alternative currencies,
e.g. the "Euro". However, the remainder of this requirement is
written in terms of value stock.
When a price changes for a fixed price value stock item, the stock
value must change to maintain the relationship stock value = stock
quantity x price. The change in stock value must be "balanced" by
one or more transactions for designated products (and thence
reported on designated cash account lines). Thus the requirement
for maintaining an equal and opposite effect on the stock unit is
maintained.
EPOSS must allow efficient revaluation of multiple value stock
products of the same generic type e.g. postal order fees.
EPOSS must ensure that only allowable value stock products can be
accessed.
Requirements Page 215 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 814 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Enter Cash on Hand
EPOSS must provide a function to enter to the system the value of
cash held in the stock unit by denomination for two distinct
purposes:
= as part of the cash flow reporting process;
= as part of the stock unit balancing process.
The declaration screen may be shared by both activities to avoid
unnecessary duplication when balancing.
As part of the cash flow/balancing reporting process:
= at any time but normally daily as part of the end of
day activity
= enter by cash value for each denomination and total
value declared (validate each field entry as an integer)
The total entered is used in the stock unit balance report and the
difference between this total and the system figure for the "Cash"
MoP stock value will generate a loss or gain.
The system stock value for the "Cash" MoP is not altered during
the process. The user is advised of any discrepancy to warn of
potential errors and (in balancing) the implied balancing loss or
gain.
A zero cash holding is declared by using the function in the
normal way and confirming zero entries.
EPOSS must allow the last known declaration to be carried forward
for cash flow reporting purposes where no activity has occurred to
change the last known cash position. This is required to cater for
rest days including offices that shut on Saturdays etc.
In offices that 'Team Work' allow cash declaration across all the
tills that contribute to the stock unit position.
Requirements Page 216 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 815 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Process Dormant Stock Units
EPOSS must allow a function to bring unused stock units (and their
stock unit information) forward into the next Outlet Accounting
Period.
A dormant stock unit is one for which no activity has taken place
since its last final balance.
This function may be used at any time to ensure that all stock
units registered in an Outlet are recorded as fully up to date,
prior to producing the Cash Account for that OAP.
The co-ordination of this activity is under the control of the
office manager.
Requirements Page 217 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 816 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Audit
EPOSS must maintain/retrieve and review (but not amend) a complete
set of outlet records for a rolling period of 18 months.
All record retrieval must be packaged in weekly batches as a
complete outlet accounting period cycle.
Outlet enquiries will centre upon activities performed in the
recent past (16 weeks for POID) and therefore records must be made
available - say at 24 hours notice. Outlets will have need of more
recent record retrieval on demand, for the previous 2 complete
outlet accounting periods.
EPOSS must record all events and data entries including fallback
and recovery actions. Require entry of user identity and password
to access the system.
Action each facility with a user authority level (clerk
supervisor, manager). Provide reasonable safeguards against
accidental or deliberate access by other than the normal means to
software or data.
Within an Outlet there should be a facility to maintain and
allocate a user access and privilege level log.
Requirements Page 218 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 817 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Discounting
EPOSS must allow discounting for all discountable products. A list
of discountable products will be maintained in reference data.
EPOSS must allow discount by an entered percentage for the last
transaction or for all discountable product transactions in the
customer session.
EPOSS must allow discount by an entered value for the last
transaction or for all discountable product transactions in the
customer session.
Requirements Page 219 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 818 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Reference Data
EPOSS must provide a facility to update reference data files with
reference data supplied from TIP. It must be possible for a date
and time stamp to be applied to reference data to facilitate
timely price changing.
The reference data content must be available as a locally produced
report. Changes made in reference data should be presented
clearly. The changes must be brought to the attention of the local
Outlet by electronic means.
EPOSS must maintain other reference data. This will depend upon
the design but will include parameters for products, product
groups and subgroups, external transfer sources and destinations.
Various formatted outputs including the cash account and the cash
flow report. Changes to the product range and the internal
reporting structure within current principles should possible by
reference data rather than software.
EPOSS should check consistency, reporting errors, warning of non
critical and preventing critical errors. Refuse deletions if there
is dependent business data. Pass reference data to the counter
terminals. Check reference data consistency and report exceptions.
Requirements Page 220 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 819 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - The Outlet Trial/Final Cash Account
EPOSS must sustain a dynamic set of cash account tables that will
allow Outlets to introduce additional reporting lines as new
products are introduced within the Business. It should be noted
that more than one cash account format must be supported and
currently there are three in use - London, Provincial and CRU and
there are validation rules that could be applied to individual
line entries as some are unique to certain types of outlets.
A printed format that allowed reference data product mapping
through to the appropriate line(s) would be advantageous.
EPOSS must provide a facility to assign cash account details
including week end date and week number. The association of
period to number is controlled and sanctioned yearly. However
under certain authorised circumstances an authorised Outlet may
produce one cash account to span a 2/3 week period and this must
be managed by EPOSS. Within this variation there is a
requirement to correctly associate the week number with a specific
transaction according to a Client's requirements. This will be one
of either:
- the week in which the transaction took place or;
- the final week in when the cash account is
produced.
EPOSS must (initially) support the production of the cash account
in two formats - printed and electronic.
There is a requirement for the printed copy cash accounts to
include a 2D bar code.
There should be a facility to allow users to produce trial office
cash accounts.
EPOSS needs a facility to move forward into the next outlet
accounting period once a final cash account has been produced.
Requirements Page 221 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 820 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Fallback and Recovery
EPOSS shall provide a means of controlling user access to its
data, processes, and functions.
EPOSS shall provide fallback facilities for situations where the
user cannot use the OPS for any reason.
These facilities shall maintain the integrity, security and levels
of customer service consistent with the need to maintain trading.
EPOSS shall ensure that, following an Incident, or if
operationally desirable for any other reason:
(a) the user can return to a complete and recent position;
(b) no corruption of secured data has occurred; and
(c) a full recovery can be effected swiftly and in an
auditable manner.
EPOSS must allow the backing up of stock unit and Outlet data in
order to maintain confidence in the ability to return to a recent
known position for fallback and recovery. There are also strategic
times within the cash account cycle (pre/post cash account roll
over) when local control is desirable.
EPOSS must allow recovery of data to a known recent position. This
may include both the Outlet and individual stock unit data where
this is necessary to maintain system integrity. Recovery should
not itself constitute a risk e.g. a one shot only option. Thus in
the event of a power down/ power interruption during a recovery
activity further recovery attempts can be made later.
EPOSS must ensure that the committal process for a transaction is
robust and consistent across all transaction types so that an
interruption will/should not result in an unrecoverable systems
error.
EPOSS must ensure that in the event of a system failure, recovery
can be performed from a known position and with the minimum of
disruption to the user. Data re-entry must be minimal where
previously committed transactions have to be re-entered.
EPOSS must warn the user where there is the possibility of working
with a corrupt data set.
Requirements Page 222 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 821 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Business Rules
EPOSS shall be flexible enough to provide the ability to define
the transaction range available at specific Outlets, including:
(a) preventing specific transactions from being available
locally (by Outlet);
(b) declining to use specific non-mandatory transactions
locally (by Outlet);
or
(c) modifying specific transactions, where allowed, for
specific Outlets.
(d) EPOSS shall be flexible enough to introduce new
functionality as agreed with POCL.
EPOSS shall provide facilities to:
(a) prepare EPOSS transaction data and EPOSS processed
data for export to, and
(bo) import data from other systems outside the OPS.
Requirements Page 223 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 822 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - design
Requirement Description:
The Service Infrastructure shall be designed such that it can
interface into any POCL inventory management systems, and shall
have sufficient capacity not to preclude such interfacing.
Requirements Page 224 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 823 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Data Management
Ensure that all EPOSS transaction and process data captured
through EPOSS are available to
any Service delivered through the medium of the OPS and agreed
with POCL as requiring
access to data.
EPOSS shall ensure that, in the event of an Incident, data
integrity is maintained and that
no corruption of data is introduced arising from the interruption
of any uncompleted activity.
Requirements Page 225 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 824 Release spr 9
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS - Weighing Scales
EPOSS must provide the price for a particular weight of package
(provided by the scales), with the contention being handled by the
scales accepting or denying a connection by a counter terminal.
The counter terminal will request the scales only when needed and
can only proceed with the scales associated service if the scales
accepts its request. The counter terminal will release the scales
as soon as it has finished with it.
Requirements Page 226 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 825 Release spr 19
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
Serve Customer (B)
Provide an EPOSS function to record all sales.
EPOSS must be event driven so that both data capture and the
recording of services such as BES and APS are dynamic.
All counter transactions are to be maintained within a session.
Data should be automatically recorded in EPOSS if captured during
another service e.g. BES, APS or OBCS.
Multiple transactions for the same customer must be logically
grouped into a single customer session.
Within a customer session maintain:
= a running record of all transactions performed;
= the current balance;
= the accounting sense (pay out/take in);
= settlement details.
EPOSS must accept single or multiple methods of payment as
settlement.
EPOSS must allow the implementation of new methods of payment
including EFTPOSS and Debit Cards.
EPOSS must allow a customer session to be suspended and then
recalled for completion at a later date. In between the clerk must
be able to continue to enter and complete further sessions as
required.
Provide a "Void" facility. Note that Client and POCL acounting and
business rules may prohibit use of "Void" for certain
transactions.
EPOSS will allow the refund or reversal of a transaction with
access maintained at user level. Note that certain transactions
may not be refundable or reversible to comply with Client and POCL
accounting and business rules.
Some POCL products are linked and must remain so within customer
service, including for refund/reversal or voiding purposes. In
most cases the link is a coupling although not exclusively so, for
example a Postal Order of £1.00 is associated with a fee product
of £0.25 pence. As part of this linkage it should be noted that
items with no current price may be re-classified as value stock
items e.g. tax discs.
Requirements Page 227 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
EPOSS must have the facility to read data from a variety of media
such as, tokens, keyboard, electronic scales, bar codes and to add
functionality to capture data from other approved peripheral
devices.
EPOSS must allow the input of weight values where scales are not
linked.
EPOSS must be flexible enough to support the introduction of new
Client services in an integrated manner and thereby ensure that
any new product is event driven and that EPOSS is automatically
updated.
Requirements Page 228 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 826 Release spr 9
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Flexibility - systems
Requirement Description:
Requirement
Future flexibility - sharing of specialist peripherals.
It is likely that, in due course, specialist peripherals will
need to be connected to OPS in such a way that they can be
accessed by two or more terminals. A possible example would be
parcel scales. Generically OPS must be able to support this type
of connection.
In such a case it must be possible to restrict access to a
subset of the terminals in the outlet.
Requirements Page 229 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 827 Release spr 9
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Flexibility - systems
Requirement Description:
Requirement
Ability to maintain authorisation data.
It is likely that, in due course, re-engineered POCL products
will require specific authorisation, either through access to a
computer system external to the services provided or within the
services provided.
1. The supplier must confirm that the solution can be developed to
support the maintenance and use of
- stop lists
- go lists
- other authorisation types.
2. The supplier must confirm that the solution will support
authorisations through access to external computer systems.
Requirements Page 230 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 828 Release spr 10
No
Programme General Subject General
Grouping Heading
Security
Requirement Description:
Data Security
The confidentiality, integrity, validity and completeness of data
must be maintained throughout all storage, processes and
transmissions, including during periods of service failure and
recovery from service failure.
Clarification; The CONTRACTOR must ensure that all data passed
from PAS and CMS to CAPS will adhere to the current DSS Business
Data Standards Document and any future amendments.
Requirements Page 231 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 829 Release spr 10
No
Programme General Subject General
Grouping Heading
Security
Requirement Description:
Prosecution support
The CONTRACTOR shall ensure that all relevant information produced
at the request of the AUTHORITIES shall be evidentially admissible
and capable of certification in accordance with the Police and
Criminal Evidence Act (PACE) 1984 and the Police and Criminal
Evidence (Northern Ireland) Order 1989
At the direction of the AUTHORITIES, audit trail and other
information necessary to support live investigations and
prosecutions must be retained for the duration of the
investigation and prosecution irrespective of the normal retention
period of that information.
Clarification:
The following clarification is provided in relation to the first
paragraph of this requirement:
"relevant information' should also be evidentially admissible and
capable of certification in accordance with relevant Scottish
legislation
Requirements Page 232 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 830 Release spr 10
No
Programme General Subject General
Grouping Heading
Security
Requirement Description:
Contingency
The CONTRACTOR must describe the contingency arrangements that
will be used to ensure continuity of service to the AUTHORITIES.
The arrangements must consider the impact of failures affecting
the AUTHORITIES' other systems that connect to the contractor's
services.
Clarification:
The following clarification is provided in relation to this
requirement:
Contingency Plans:
1. The CONTRACTOR will ensure that all services are supported by
Contingency Plans including Fallback Transactions that will
minimise or negate the impact of failure in any part of the
services.
2. The CONTRACTOR will ensure that the Contingency Plans for each
service are compatible with an overall Service Continuity
framework.
3. The Contingency Plans will be based on Impact and Risk
Assessments agreed between the CONTRACTOR and the AUTHORITIES
4. Ownership of all contingency actions will be identified.
5. The Contingency Plans will include activation procedures and
time periods within which the contingency measures will be
activated.
6. The Contingency Plans will include a testing strategy with two
distinct parts:
1 Initial testing on implementation and deployment
6.2 Regular testing
7. The Contingency Plans will include without limitation the
following:
Prevention measures
Preparedness measures
Contingency measures
Recovery of normal service
Change control procedures
NNNNN
G®WHH
Requirements Page 233 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
7.6 Contact lists
7.7 Service levels - the CONTRACTOR will be liable as per Service
level agreements
8. The Contingency Plans will be subject to joint review by the
CONTRACTOR and AUTHORITIES
Requirements Page 234 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 831 Release spr 10
No
Programme End to End Subject Interfaces
Grouping Service Heading
Integration of services
Requirement Description:
POCL INTERFACES
The CONTRACTOR shall support the interfaces between (i) POCL
systems and (ii) the Services and the Service Infrastructure
Service, as such interfaces are defined in the POCL Interfaces
documentation maintained by POCL. These will include:
1. Transaction Information Processing (TIP) system
interfaces to/from TMS and Outlets;
2. Interfaces between Outlets, TMS and Clients;
3. TIP / TMS interface for authorisation data:
- provide the capability for reconciliation between
POCL and its Clients by ensuring TIP receives a
copy of all original authorisation data via TMS as
specified on an individual Client basis by POCL.
The POCL Interfaces documentation will cover: data content in
logical groupings, physical layouts, controls (including
security), timings, volumes, technical interface specifications
(initially options and constraints), configuration management and
contingency arrangements. A version of the POCL Interfaces
documentation containing the existing interfaces will be made
available to the CONTRACTOR within three (3) months after
execution hereof.
The POCL Interfaces documentation will not initially cover further
potential interfaces in respect of:
- EFTPOS
- reconciliation and exception reporting
- operational management information
- performance monitoring
- inspection of Transaction and event logs for audit
and security purposes
- transitional arrangements in relation to the
automated payments / ALPS host
- transitional arrangements in relation to 'cash
account processing'
The detailed format of all interfaces must be agreed with POCL.
The specification details will be subject to refinement while the
TIP system in particular is being defined.
Requirements Page 235 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 832 Release spr 10
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Process - development
Requirement Description:
EPOSS Business Processes
The overall business processes following the automation of
transaction processing at the counter are to ensure that:
= the capture of data at the Outlet is complete, accurate and
robust e.g. a unique reference per transaction;
— any transfer of data is secure, complete, accurate and
robust;
= whether on line or off line the service must be capable of
validating transactions by format and value;
= in the event of fraud it can be proved that the service was
operating without defect;
os for specific transactions receipts are automatically
generated for customers and a copy retained in the Outlet to
allow recovery or problem resolution;
- accountability for cash, stock and any supporting
documentation is maintained by Outlet and user where appropriate;
= the method of payment is recorded at the point of sale;
= the access control system allows segregation of
responsibilities and a log of users and the functions to which
they have access must be available to Outlet managers;
= a back up of all transactions is taken each day;
= operator and device are uniquely identified within each
Outlet;
a data should undergo a balancing procedure to enable a final
review and authorisation;
oa all transactions are collected using a secure method at the
earliest opportunity;
a transactions not collected from previous days are clearly
identifiable;
— all transactions can be reconciled to an appropriate
supporting voucher and where necessary these vouchers are to be
available for central validation of amounts collected;
Requirements Page 236 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
= maintain an up to date record of cash and stock on hand for
audit purposes and be capable of reporting current balances;
- all transfers to and from other Outlets and between staff are
clearly recorded;
— all specified summaries are produced automatically when
required and all transactions are included since the last summary
was completed;
a items posted to suspense accounts can be identified for
future investigation;
= information to show compliance with the relevant legislation,
e.g. Health and Safety, Data Protection Act, Companies Act;
= an Outlet must be able to continue operating and to maintain
an audit trail in the event of system failure.
Requirements Page 237 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 833 Release spr 10
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Training
Requirement Description:
EPOSS - Training Mode
EPOSS should provide a training mode to allow familiarisation with
the package and must operate in such a way as to preclude any
corruption of live data.
Requirements Page 238 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 834 Release spr 10
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - design
Requirement Description:
Transitional / Contingency Arrangements
The service provider must ensure that adequate contingency
arrangements are available for all Outlets both during and after
roll-out.
Due consideration needs to be given to the implementation plan for
parent and satellite offices.
To provide adequate contingency cover during and after roll-out,
each automated Outlet must be capable of producing plain summaries
to a format agreed with POCL.
The outlet platform at every office must be capable of printing a
2 dimensional bar-code on any plain paper summary.
Requirements Page 239 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 835 Release spr 10
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Systems - design
Requirement Description:
EPOSS Related
Benefits encashment and other automated transactions must be
integrated with the transaction recording elements of EPOSS such
that:
a there is no necessity to seperately notify the EPOSS
system of the transaction;
- there is a single transaction record created and
stored locally to provide the basis for office summarisation and
balancing and transaction level data transfer;
= transaction records created and stored locally must
be entirely consistant with any data transferred at the time of
the transaction to PAS or other systems;
= transaction times are kept to a minimum.
EPOSS must be capable of providing summaries of any type of
transaction for comparison with physical records contained within
the office. For example the system must be able to:
= summarise the quantity of tax discs on hand;
= summarise the quantity of milk tokens on hand;
= list and total cheques accepted by value;
= list and total benefits transactions made via BES for
comparison against physical records (office copy of receipts).
As transactions become automated the relevant summaries should be
enhanced to include details of items issued/on hand, by individual
serial number.
Requirements Page 240 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 836 Release spr 10
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - development
Requirement Description:
Service Development
PostShops are equipped with EPOSS terminal - CRISP (Counters
Retail Information Systems in PostShops) which is a stand alone
system, but POCL would be interested in integration options.
Where an Agent of the Post Office may in future use the counter
infrastructure (e.g. EPOS) for his own business, it will be
necessary to identify the transactions seperately from Post Office
work, in particular for financial accounting.
Automation of transaction processing at the counter - the
following information must be captured:
' value of each transaction
= volumes of transactions
= a unique code for each product so that detailed information
can be made available across all Clients (e.g. breakdown by
denomination of Royal Mail stamps sold)
- source (e.g. outlet , clerk and till idntification)
— client reference and Client scheme or product reference for
each transaction
= customer identification and details (e.g. for transactions
involving cheques, passports, motor tax discs)
= method of payment
- date and time of the transaction.
The counter application will require the ability to add further
applications to the service. Service Providers should be willing
to integrate and operate these via the service agreeement,
provided that there are no valid technical reasons that preclude
their inclusion in the service.
Requirements Page 241 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 837 Release spr 10
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS Reporting
EPOSS must support the production of a variety of reports in pre-
defined formats as:
- transaction level reports by stock unit for Clients using
pre-printed cut sheets (client stationery);
- transaction level reports by stock unit for Clients printed
on plain paper;
- reports on the current level of value stock products at
stock item level;
- reports on transaction volumes and values;
- cash account reports;
- reconciliation reports for non-value stock items e.g. Milk
Tokens, Tax Discs;
- reports on transfers of cash and value stock;
- ad-hoc reports for management information purposes.
Reports can be produced at the users discretion, subject to POCL
and Client rules on frequency of despatch and designed accounting
periods. Client reports are produed on a daily or weekly basis.
Where operationally appropriate, several weekly reports may be
produced during an accounting period.
Requirements Page 242 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 838 Release spr 10
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Management information
Requirement Description:
EPOSS - General
EPOSS must have the facility to allow input of transaction related
data after the event for items required for management information
purposes, e.g. for Clients, Agents pay, which does not impact on
the Outlet balance e.g. non value items, value recorded for
information only.
EPOSS must also support the input of data for local schemes where
the value is not recorded for accounting purposes but the volume
is.
Requirements Page 243 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 839 Release spr 10
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Service - design
Requirement Description:
EPOSS Retail Functionality
EPOSS must provide the point of sale retail functionality in use
in PostShops.
This includes, but is not restricted to:
- till functionality;
- discounting;
- coupon management;
- multibuys;
- promotions;
- marketing;
- reporting.
Requirements Page 244 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 840 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
The Benefits Encashment Service must support the facility to check
the validity of a card and to verify the identity of the customer
presenting the card.
Requirements Page 245 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 841 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
A signature is required to confirm receipt of benefit and
entitlement, verification of an Authorised Person will only be
required once per visit.
Requirements Page 246 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 842 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES will operate the Cardholder Verification Methods as required
to enable the identity of an authorised person to be verified.
fe.g. if the POCL clerk is suspicious.]
Requirements Page 247 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 843 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES will prompt the counter clerk to impound the Card when
necessary, eg on instructions from PAS in line with the
contractors proposals to be agreed with the contacting
authorities.
Requirements Page 248 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 844 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES will present relevant payment information to enable the
customer to encash their entitlements as instructed by PAS.
Requirements Page 249 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 845 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES will allow the POCL clerk to terminate the transaction before
the encashment procedure is complete, if the authorised person so
requests, and subject to appropriate security standards.
Requirements Page 250 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 846 Release spr 19
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES will forward confirmation of every encashment of authorised
benefits to PAS and TIP via TMS.
Requirements Page 251 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 847 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
At the end of the transaction BES will prompt the POCL clerk to
confirm the transaction has been completed successfully including
the retention of the signed top copy of the receipt and issuing a
copy to the authorised person.
Requirements Page 252 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 848 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES will enable customer to encash their benefit entitlement when
due.
Requirements Page 253 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 849 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES will enable customers to receive payments away from their
Nominated Post Office in accordance with guidelines laid down by
the contracting authorities [currently proposed as (2 in a 26)
week period] and must be adaptable to meet any changes to those.
Foreign encashments must be limited to (x) in a rolling (y) week
period (where (x) and (y) are parameters to be provided by the
Contracting Authority, initially (x) = 2 and (y) = 26).
Requirements Page 254 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 850 Release spr 19
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES will facilitate the batching, filing and dispatch of signed
receipts, plus any associated froms, within POCL locations.
Requirements Page 255 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 851 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
The encashment information provided to PAS from the outlet must be
identical to the information recorded on the outlet transaction
file.
Requirements Page 256 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 852 Release spr 19
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
Back up systems will be in place to ensure continued payments of
benefits on failure, for any reason, of all or any elements of
BES.
Requirements Page 257 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 853 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
Auditable recovery of benefit data will be provided in the event
of a failure of a service used by BES [e.g. OPS].
Requirements Page 258 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 854 Release spr 19
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
Arithmetic checks should be made by BES to ensure that the sum of
the individual encashment amounts equal the total encashment
figure.
Requirements Page 259 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 855 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Security
Requirement Description:
The PO clerk must not be able to manipulate data to and from PAS.
E.g. the authorised amount due for each individual benefit.
Requirements Page 260 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 856 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
Systems and procedures will be in place to allow encashment to
proceed if a Card Read Failure occurs.
Requirements Page 261 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 857 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Interface with PAS
Requirement Description:
Requests for confirmation of a benefit transaction from the outlet
to PAS must include data specified by the AUTHORITIES.
Requirements Page 262 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 858 Release spr 10
No
Programme POCL Subject POCL Applications (BES
Grouping Applications Heading
Interface with PAS
Requirement Description:
BES will have the facility to advise the POCL clerk with a message
in the event of an attempted foreign encashment in accordance with
information from PAS. It will not identify the Nominated Post
Office to them.
Requirements Page 263 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 859 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Interface with PAS
Requirement Description:
Encashment details from the outlet to PAS must include data
specified by the Contracting Authorities.
Requirements Page 264 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 860 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Supporting services
Requirement Description:
Help desk facilities will be available.
Requirements Page 265 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 861 Release spr 19
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES will enable an Alternative Payee arrangement to operate where
specified by the DSS.
Requirements Page 266 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 862 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
If no payment is due BES will prompt the POCL clerk to return the
Card to the Authorised Person and in cases of dispute or enquiry
advise them to contact their local Benefit Office
Requirements Page 267 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 863 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES can only be accessed by a genuine and valid Benefit Payment
Card or genuine and valid Temporary Token.
Requirements Page 268 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 864 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Interface with PAS
Requirement Description:
BES will only permit encashment in-line with authorised payment
details from PAS.
Requirements Page 269 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 865 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES will enable benefits to be encashed on behalf of authorised
customers by:- casual agents; permanent agents; appointees.
Requirements Page 270 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 866 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Interface with PAS
Requirement Description:
BES will identify customers requiring milk /other tokens, from the
information provided by PAS, specify the number to be issued and
enable the issue of tokens to be recorded via EPOS.
Requirements Page 271 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 867 Release spr 10
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES will allow customers to make changes to their nominated Post
Office.
Requirements Page 272 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 868 Release spr 19
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Customer interface
Requirement Description:
Customer enquiries in post offices about the Benefit Payment
Service should be minimised i.e. BES should be designed in a
flexible way so as changes can be readily made to reduce the
number of enquiries.
Requirements Page 273 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 869 Release spr 10
No
Programme POCL Subject POCL Infrastructure (SLA)
Grouping Infrastructure Heading
Service levels
Requirement Description:
Transaction Monitoring System (TMS) service levels.
1. BA/POCL are not concerned with the performance of individual
sub-systems per se. The primary concern is with the overall
performance of the service as it impacts upon the their own
systems, clients, staff, agents and customers. Targets for the
level of internal performance between Service Provider’s sub-
systems will therefore not be set by BA/POCL. However internal
sub-system performance will be judged by BA/POCL as it affects
overall service performance.
2. Service Providers must specify the internal performance
requirements of any sub-system that potentially may be re-
tendered. Service providers will therefore need to maintain and
report actual measured performance for TMS as it interfaces to
other subsystems.
3. For the TMS Service Providers must specify the performance
requirements and tolerances for:
3.1 hours of operation of TMS
3.2 response time required between TMS and
3.2.1 PAS
3.2.2 CMS
3.2.3 OPS
3.2 the number of outages of TMS, identifying types of outages
monitored
3.3 the availability of TMS
4. Service Providers must report against all performance
requirements identified in section 3 above.
5.Service Providers must maintain detailed technical documentation
of the interfaces from TMS to PAS, CMS, OPS and all attachable
computer systems. In the event of changes to any interface to TMS,
this must be notified to and agreed with BA/POCL in advance, with
updates to the technical documentation being provided within 10
working days of the change being implemented.
Requirements Page 274 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 870 Release spr 10
No
Programme POCL Subject POCL Applications (EPOSS
Grouping Applications Heading
Service levels
Requirement Description:
EPOSS - transaction times
1. The EPOSS system must not slow down the activity of the counter
clerk in serving customers and as such each transaction in EPOSS
must be designed to minimise the number of key depressions (or
other clerk interaction with peripheral devices). In all cases the
system response to any peripheral input must be instantaneous.
2. Summarisation and balancing activities, including processing
and printing, must be optimised and avoid re-processing when data
is changed during accounting.
3. The supplier must identify technical measures which will
relate to the transaction times identified in sections land 2
above and monitor these measures and report against them. The
measures must be capable of identifying trends in transaction
times and in identifying specific outlets where transaction times
are significantly better or worse than the average.
4, For each outlet where the overall transaction times are more
than 10% greater than the average the supplier must agree a remedy
with BA/POCL.
Requirements Page 275 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 871 Release spr 10
No
Programme POCL Subject POCL Applications (SLA)
Grouping Applications Heading
Service levels
Requirement Description:
EPOSS - general service levels
1. EPOSS must be implemented such that the version of any
reference data being referenced from outlets has been updated with
the latest version of reference data. The version of the reference
data is fully updated once all updates have been applied. If one
days worth of updates have not been applied then the version is
deemed 1 day behind and so on.
On any business day:
95 % of outlets must be referencing a version which is fully
updated
99% of outlets must be referencing a version which is no more
than 1 day behind.
100% of outlets must be referencing a version which is no more
than 2 days behind.
2. Transaction data must normally be forwarded to POCL central
systems (e.g. TIP) soon after the completion of the business day
on which the transaction occurred as part of a batch transmission.
Transaction data not available for the next batch transmission
must be include in a subsequent transmission.
Data which is included in the first batch transmission to take
place after the time of the transaction is deemed to be in the
first batch transmission and so on.
Transaction data from the outlets must reach the POCL central
computer system(s) as follows:-
the data from 90% of outlets must reach within the first batch
transmission
the data from 98% of outlets must reach within the first or
second batch transmissions
the data from 100% of outlets must reach within the first,
second or third batch transmissions
3. Batch transmission times will be agreed for each POCL central
system, but will not be scheduled to complete before 04.30. For
each system primary and secondary transmission windows will be
agreed.
For each client
99% of all transmissions must complete within the primary
transmission window
100% of all transmissions must complete within the primary or
secondary transmission window.
Requirements Page 276 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirements Page 277 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 872 Release spr 11
No
Programme General Subject General
Grouping Heading
Security
Requirement Description:
Nationally Sensitive Cases
Cases marked as Nationally Sensitive must be handled in accordance
with the current version of the DSS IT Security Standards.
Requirements Page 278 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 873 Release spr 11
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Flexibility - services
Requirement Description:
BES must be flexible and, without impinging the agreed service and
security levels, the designed solution must be capable of
introducing and supporting outpayment services for other Post
Office Counters clients.
Requirements Page 279 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 874 Release spr 11
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
When a terminated card is presented, BES will prompt the counter
clerk to take appropriate action.
Requirements Page 280 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 875 Release spr 11
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES will prompt the counter clerk to impound the temporary token
when necessary, e.g. on instruction from PAS in line with the
contractors proposals to be agreed with the contracting
authorities.
Requirements Page 281 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 876 Release spr 19
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Flexibility - services
Requirement Description:
BES should be flexible and provide the facility to support the
encashment of new benefits or changes to existing benefits with
the minimum disruption and cost.
Requirements Page 282 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 877 Release spr 11
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES must provide, or be linked to, a token management system which
is capable of being used for Benefit or other POCL clients and
which will allow card receipt and card issue to be managed
effectively.
Requirements Page 283 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 877 Release spr 11
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES must provide, or be linked to, a token management system which
is capable of being used for Benefit or other POCL clients and
which will allow card receipt and card issue to be managed
effectively.
Requirements Page 284 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 878 Release spr 11
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Integration of services
Requirement Description:
Benefits encashment transactions must be integrated with the
transaction recording elements of EPOSS. (See Requirement No 835).
Requirements Page 285 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 879 Release spr 11
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
All foreign encashments must be identified as such in the single
transaction file.
Requirements Page 286 of 407 Version 5.0 - Pathway
AUTHORITIES' AGREEMENT
SCHEDULE BO1
POL00028168
POL00028168
RESTRICTED - CONTRACTS
Requirement 880
Programme POCL
Grouping Applications
Requirement Description:
Transaction data from the outlet to TIP
Release
No
Subject
Heading
specified by the Contracting Authority.
spr 19
POCL Applications (BES)
Service - design
(via TMS) must be as
(See Requirement No 831)
Requirements
Page 287 of 407
Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 881 Release spr 11
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES must be capable of producing a nil receipt on request (no
benefit due).
Requirements Page 288 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 882 Release spr 19
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
In addition to producing a single declaration for signature by the
customer and retention in the Post Office, BES must be capable of
producing a legible receipt for each encashment, to satisfy
customer requests, notwithstanding any equipment failure.
Requirements Page 289 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 885 Release spr 11
No
Programme Benefit Payment Subject DSS Services (SLA)
Grouping Service Heading
Service levels
Requirement Description:
Payment Authorisation Service (PAS) internal service levels.
1. BA/POCL are not concerned with the performance of individual
sub-systems per se. The primary concern is with the overall
performance of the service as it impacts upon the their own
systems, clients, staff, agents and customers. Targets for the
level of internal performance between Service Provider’s sub-
systems will therefore not be set by BA/POCL. However internal
sub-system performance will be judged by BA/POCL as it affects
overall service performance.
2. Service Providers must specify the internal performance
requirements of any sub-system that potentially may be re-
tendered. Service providers will therefore need to maintain and
report actual measured performance for PAS as it interfaces to
other subsystems.
3. For the PAS Service Providers must specify the performance
requirements and tolerances for:
3.1 hours of operation and function provided by PAS in support of
other internal subsystems.
3.2 response time required between PAS and
3.2.1 TMS
3.2.2 CMS
3.2 the number of outages of PAS, identifying types of outages
monitored
3.3 the availability of PAS
4. Service Providers must report against all performance
requirements identified in section 3 above.
Requirements Page 290 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 887 Release spr 11
No
Programme Benefit Payment Subject DSS Services (SLA)
Grouping Service Heading
Service levels
Requirement Description:
Card Management Service (CMS) internal service levels.
1. BA/POCL are not concerned with the performance of individual
sub-systems per se. The primary concern is with the overall
performance of the service as it impacts upon the their own
systems, clients, staff, agents and customers. Targets for the
level of internal performance between Service Provider’s sub-
systems will therefore not be set by BA/POCL. However internal
sub-system performance will be judged by BA/POCL as it affects
overall service performance.
2. Service Providers must specify the internal performance
requirements of any sub-system that potentially may be re-
tendered. Service providers will therefore need to maintain and
report actual measured performance for CMS as it interfaces to
other subsystems.
3. For the CMS Service Providers must specify the performance
requirements and tolerances for:
3.1 hours of operation and function provided by CMS in support of
other internal subsystems.
3.2 response time required between CMS and
3.2.1 TMS
3.2.2 PAS
3.2 the number of outages of CMS identifying types of outages
monitored
3.3 the availability of CMS
4. Service Providers must report against all performance
requirements identified in section 3 above.
Requirements Page 291 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 888 Release spr 15
No
Programme Benefit Payment Subject DSS Services (SLA)
Grouping Service Heading
Service levels
Requirement Description:
PAS Helpdesk - service levels.
1. INTRODUCTION
This paper documents the key help desk service requirements for
the Payment Authorisation System.
2. HELP DESK SERVICE
2.1 General
The CONTRACTOR will provide a help desk service which will act as
the first point of contact for customers of the service. The
Customers are DSS staff. The CONTRACTOR’s help desk service will
provide lst and 2nd level services. The help desk must respond to
calls within 10 seconds.
2.2 1st Level Service
The CONTRACTOR’s lst level service will provide an immediate
problem and query solving service for all simple and
straightforward cases, which can be resolved within 5 minutes.
The lst level member who takes the call owns the problem/query
from initial logging through to resolution to the customers
satisfaction. The CONTRACTOR must cater for lst level members
being off duty.
Help desk contact will be over the telephone.
2.3 2nd Level Service
The CONTRACTOR’s 2nd level service will provide answers to more
complex queries which cannot be answered within 5 minutes by the
lst level service, but which can be resolved within 30 minutes.
Calls will be referred electronically from the lst level service
to the 2nd level service. 2nd level staff will have access to a
prioritised list of outstanding queries, and all the details on
the query entered by 1st level staff. Query answering at 2nd
level will be over the telephone.
2.4 Hours of Service
The CONTRACTOR will provide a continuous help desk service as
specified below:
lst Level - 08:00-18:00
2nd Level - 08:00-18:00
The CONTRACTOR, given 2 working days notice, will extend the 2nd
level service to whatever is needed. In emergency circumstances,
the CONTRACTOR will, given 5 hours notice, provide a 2nd level
service outside normal hours.
2.5 Problem and Query Management
Requirements Page 292 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
The CONTRACTOR will provide a problem/query management system to
record the problem/query details such as:
unique problem/query serial reference, generated automatically
by the problem/query management system
customer reference, contact, address, location and telephone
number
help desk contact
description of the problem/query, including frequency of
occurrence
serial references of similar faults and previous occurrences
problem/query category
estimated elapsed time to solve problem/query
any change of referral point
date and time of referral
The CONTRACTOR will update the problem/query management system
with the following information, as appropriate:
date and time of update
help desk contact updating record
textual description of the work done, or the fact that the
problem/query had to be referred, elsewhere and who has taken it
on
date and time problem/query was cleared
date and time the solution was accepted by the customer
actual elapsed time to solve problem/query.
The CONTRACTOR will manage the resolution of any problem using
documented procedures agreed with the AUTHORITIES. These
procedures must be comprehensive in that they cover all aspects of
problem resolution from initial logging through to closure.
Escalation procedures must be included. A problem/query can only
be cleared when a customer has confirmed satisfaction with the
resolution.
2.6 Resilience
The CONTRACTOR is responsible for ensuring that a contingency plan
is in place to cater with any help desk incident, e.g. loss of
staff, loss of telephone system, loss of problem/configuration
management systems. The contingency plan is to be agreed with the
AUTHORITIES and must state how quickly the service will be
restored in the event of an incident.
2.7 Training
The CONTRACTOR will provide any necessary training to ensure
AUTHORITIES staff work effectively with the help desk. The
CONTRACTOR will develop training plans for its own staff.
2.8 Personnel
The CONTRACTOR will ensure that all staff have suitable and
appropriate skills and training and that sufficient skilled
resources are available to cater for holidays, sickness and
natural wastage within the CONTRACTOR’s organisation.
The CONTRACTOR will resolve at least 95% of calls assigned to
level 2 within 30 minutes. The CONTRACTOR will resolve 100% of
calls assigned to level 2 within 45 minutes.
Requirements Page 293 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
The percentage of ‘calls not answered’ will be less than 1%. This
includes calls where the line is busy as well as calls answered
but put on the ‘waiting queue’.
3. Service Monitoring
The CONTRACTOR will produce service information, in electronic
form, and will deliver this information to the AUTHORITIES within
5 working days of the end of the period to which they relate. The
following is an example of the information required:
number of calls outgoing/received/number of calls not answered
% of calls answered within target times
number of problems/queries logged
number and % of problems/queries solved within target times
number of problems/queries assigned to level 1 that were not
cleared within 10 minutes
number of problems/queries with secondary complications (e.g.
repeat calls)
number of problems/queries escalated
% of time full help desk was available
The AUTHORITIES may wish to analyse the information by:
category of problem/query
level and solving group at which the problem/query was solved
customer group and location
mean time to clear.
The CONTRACTOR will maintain help desk records for a minimum of 18
months.
Each quarter a survey will be conducted by the AUTHORITIES to
determine user satisfaction with the help desk. The AUTHORITIES
and CONTRACTOR will agree the approach to be taken and the
format/content of the questionnaire.
The CONTRACTOR will, on request, provide on-line access to the
problem Management System. The AUTHORITIES will inform the
CONTRACTOR of who is authorised to access the system. The
CONTRACTOR will provide ad-hoc reports, as requested by the
authorised representatives of the AUTHORITIES, within three
working days.
Requirements Page 294 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 889 Release spr 15
No
Programme Benefit Payment Subject DSS Services (SLA)
Grouping Service Heading
Service levels
Requirement Description:
CMS Helpdesk - service levels.
1. INTRODUCTION
This paper documents the key help desk service requirements for
the Card Management Service.
2. HELP DESK SERVICE
2.1 General
The CONTRACTOR will provide a Card Management help desk service
which will act as the first point of contact for customers of the
service. Customers include both Benefits Agency staff and
members of the public. The CONTRACTOR’s help desk service will
provide lst and 2nd level services. The help desk must respond to
calls within 10 seconds.
2.2 1st Level Service
The CONTRACTOR’s lst level service will provide an immediate
problem and query solving service for all simple and
straightforward cases, which can be resolved within 5 minutes.
The lst level member who takes the call owns the problem/query
from initial logging through to resolution to the customers
satisfaction. The CONTRACTOR must cater for lst level members
being off duty.
Help desk contact will be over the telephone.
2.3 2nd Level Service
The CONTRACTOR’s 2nd level service will provide answers to more
complex queries which cannot be answered within 5 minutes by the
lst level service, but which can be resolved within 30 minutes.
Calls will be referred electronically from the lst level service
to the 2nd level service. 2nd level staff will have access to a
prioritised list of outstanding queries, and all the details on
the query entered by 1st level staff. Query answering at 2nd
level will be over the telephone.
2.4 Hours of Service
The CONTRACTOR will provide a continuous help desk service as
specified below:
lst Level - 24 hours a day, 7 days a week; all year round (Xmas
day excepted)
2nd Level - 08:00-18:00
The CONTRACTOR, given 2 working days notice, will extend the 2nd
level service to whatever is needed. In emergency circumstances
the CONTRACTOR will, given 5 hours notice, provide a 2nd level
service outside normal hours.
Requirements Page 295 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
2.5 Problem and Query Management
The CONTRACTOR will provide a problem/query management system to
record the problem/query details such as:
unique problem/query serial reference, generated automatically
by the problem/query management system
customer reference, contact, address, location and telephone
number
help desk contact
description of the problem/query, including frequency of
occurrence
serial references of similar faults and previous occurrences
problem/query category
estimated elapsed time to solve problem/query
any change of referral point
date and time of referral
The CONTRACTOR will update the problem/query management system
with the following information, as appropriate:
date and time of update
help desk contact updating record
textual description of the work done, or the fact that the
problem/query had to be referred, elsewhere and who has taken it
on
date and time problem/query was cleared
date and time the solution was accepted by the customer
actual elapsed time to solve problem/query.
The CONTRACTOR will manage the resolution of any problem using
documented procedures agreed with the AUTHORITIES. These
procedures must be comprehensive in that they cover all aspects of
problem resolution from initial logging through to closure.
Escalation procedures must be included. A problem/query can only
be cleared when a customer has confirmed satisfaction with the
resolution.
2.6 Resilience
The CONTRACTOR is responsible for ensuring that a contingency plan
is in place to cater with any help desk incident, e.g. loss of
staff, loss of telephone system, loss of problem/configuration
management systems. . The contingency plan is to be agreed with
the AUTHORITIES and must state how quickly the service will be
restored in the event of an incident.
2.7 Training
The CONTRACTOR will provide any necessary training to ensure
AUTHORITIES staff work effectively with the help desk. The
CONTRACTOR will develop training plans for its own staff.
2.8 Personnel
The CONTRACTOR will ensure that all staff have suitable and
appropriate skills and training and that sufficient skilled
resources are available to cater for holidays, sickness and
natural wastage within the CONTRACTOR’s organisation.
3. Service Monitoring
Requirements Page 296 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
The CONTRACTOR will produce service information, in electronic
form, and will deliver this information to the AUTHORITIES within
5 working days of the end of the period to which they relate. The
following is an example of the information required:
number of calls outgoing/received/number of calls not answered
% of calls answered within target times
number of problems/queries logged
number and % of problems/queries solved within target times
number of problems/queries assigned to level 1 that were not
cleared within 10 minutes
number of problems/queries with secondary complications (e.g.
repeat calls)
number of problems/queries escalated
% of time full help desk was available
The AUTHORITIES may wish to analyse the information by:
category of problem/query
level and solving group at which the problem/query was solved
customer group and location
mean time to clear.
The CONTRACTOR will maintain help desk records for a minimum of 18
months.
Each quarter a survey will be conducted by the AUTHORITIES to
determine user satisfaction with the help desk. The AUTHORITIES
and CONTRACTOR will agree the approach to be taken and the
format/content of the questionnaire.
The CONTRACTOR will, on request, provide on-line access to the
problem Management System. The AUTHORITIES will inform the
CONTRACTOR of who is authorised to access the system. The
CONTRACTOR will provide ad-hoc reports, as requested by the
authorised representatives of the AUTHORITIES, within three
working days.
Requirements Page 297 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 890 Release spr 11
No
Programme POCL Subject POCL Applications (APS)
Grouping Applications Heading
Service levels
Requirement Description:
APS Reconciliation.
The CONTRACTOR shall ensure and demonstrate that all committed
transactions have successfully passed from the Outlets through
POCL and Clients.
The CONTRACTOR shall enable at least one point in the day when all
transactions to be sent to a Client are in step with those to be
sent to POCL.
Requirements Page 298 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 891 Release spr 15
No
Programme End to End Subject Shared Services
Grouping Service Heading
Accounting &
reconciliation
Requirement Description:
RECONCILIATION REQUIREMENTS
a) General Requirements
The CONTRACTOR shall ensure that all captured data are complete
and accurately reflected in the appropriate outward interfaces:
- this applies to Transaction data of all types and modes
(including normal working, fall-back and Recovery, and to normal
usage, amendment, reversal, and so forth) and to Stock and cash
levels; and
- this applies to Reference Data changes, both local and as
received from the AUTHORITIES as follows:
(i) from DSS in respect of Reference Data for PAS and CMS;
(ii) otherwise from POCL's TIP system except for any specific
transient arrangements; e.g. OBCS Stop Lists;
- this applies equally at all levels and across Service
components.
The CONTRACTOR shall synchronise data flows and storage, and
shall:
- monitor data transfers and account for data brought forward,
received, passed on and carried forward;
- monitor data transfers and account for data, across Service
interfaces and Service components;
- where a single datastream is "switched" to more than one
recipient:
(i) reconcile any timing differences between transfers;
(ii) account for any differences in processing or accounting
cycles of the recipients of related flows; and
(iii) provide information to each recipient to enable them to
reconcile with the other recipients of related data.
The CONTRACTOR shall ensure that data are consistent between the
levels where Transaction or Stock and cash level data are held,
maintained or transferred at more than one level.
The CONTRACTOR shall perform daily operational cut-over
reconciliations for any on-line interfaces with external systems.
The CONTRACTOR shall report reconciliation results to the relevant
AUTHORITY, including any discrepancies and any doubtful items, and
report progress on resolution of outstanding items in relation to:
- interfaces between Service components and the AUTHORITIES’
systems;
- external interfaces between the AUTHORITIES and Clients (to
enable them to maintain their commercial relationships) ;
- interfaces between Service components.
Requirements Page 299 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
The CONTRACTOR shall apply appropriate integrity controls at all
interfaces and provide information demonstrating integrity.
For interfaces that are already in place integrity controls shall
be specified in the document titled “POCL Interface Requirements
for BA / POCL System”, version 1.6, dated 16 April 1996. For new
interfaces such integrity controls shall be agreed through a
process that shall be agreed by the Drop Down Completion Date.
The CONTRACTOR shall control the implementation of configuration
changes, including changes to Reference Data, including:
- checking and reporting the implementation of changes against
instruction;
- maintaining the integrity of other reconciliation processes
across configuration changes.
The CONTRACTOR shall meet all reconciliation requirements in
contingency situations as well as in normal working.
Service Levels for all reconciliation requirements are as follows:
- full reconciliation with 100% of items demonstrably accounted
for;
- provision of the ability to reconcile by agreed processes at
detailed level, including without limitation at Transaction level
for Transaction data;
- any differences, doubtful items or errors to be resolved by the
CONTRACTOR;
- reconciliation reports and identification of doubtful items and
errors to be delivered to the relevant AUTHORITY by 9 a.m. of the
following day;
- the CONTRACTOR shall make all reasonable endeavours to resolve
any doubtful items and errors promptly.
b) Post Office Outlet Reconciliation Requirements
Stock and cash levels shall be reconciled with Transaction data:
- by Customer session, at Outlet level and, where Outlets are so
organised, by Stock Unit.
Outlet accounting information must reconcile, taking account of
Stock and cash brought forward, carried forward, Transaction data
and local suspense items (details defined in EPOSS requirements) .
This must also be sustained in fall-back and during recovery after
any failure of the Services.
The requirements in this section (b) must be satisfied instantly.
c) BPS Reconciliation Requirements
The CONTRACTOR shall apply BPS reconciliation to any Tokens by
type of Token as well as to monetary amounts.
The CONTRACTOR shall identify and resolve any differences between
entitlement information passed by CAPS to PAS and encashment
information as received by PAS, on an individual item basis (by
"Authorised Payment Id" supplied by CAPS). The CONTRACTOR shall in
Requirements Page 300 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
so doing:
- take account of both:
(i) amounts encashed as notified via TMS in normal
circumstances;
(ii) any adjustments raised directly by the CONTRACTOR to
resolve errors or due to maintenance activities;
- inform CAPS of actual payment amounts encashed where there are
any unresolved errors, (by "Authorised Payment Id").
The CONTRACTOR shall reconcile payment amounts authorised to
Outlets by PAS via TMS against amounts encashed as advised by
Outlets via TMS to PAS. In doing so, the CONTRACTOR shall notify
both DSS and POCL of any adjustments to PAS made resolving errors.
The means of processing the CONTRACTOR's corrections shall be
agreed with the AUTHORITIES within three (3) months of execution
hereof. Such agreement shall involve agreement as to the
notification channels for different cases.
The CONTRACTOR shall provide a common basis for settlement between
the AUTHORITIES. This shall ensure that the amounts encashed as
received by PAS via TMS are reflected unchanged in the EPOSS
Transaction records as delivered to TIP via TMS. Any data
recovered from other records must be verified against PAS (or
recovered from PAS on entry of the authorisation reference from
the record). Provision of the common basis may include
identification and resolution of any differences by individual
item.
The CONTRACTOR shall synchronise the CAPS, PAS and TIP streams to
agreed settlement process dead-lines; and shall report and agree
the 'unencashed balance' by Agency Code within CAPS and PAS by
value and number of Transactions, accounting for:
* Authorised Payments due
* payments encashed
* items in transit
* items under investigation for the defined settlement period
(at least daily).
The CONTRACTOR shall produce a daily statement of the agreed
encashments, by encashment date, for both AUTHORITIES.
d) TMS Reconciliation Requirements
The CONTRACTOR shall provide operational control reports on
operations, including polling and any loss of communications with
Outlets or with other Service components.
The CONTRACTOR shall apply controls on file and data transfers at
all technical levels and, using relevant counts and financial
totals, at business levels.
Note that POCL will rely on information provided via TMS
interfaces to its TIP system for reconciliation and control of
various Outlet business processes.
Requirements Page 301 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
The CONTRACTOR shall ensure that information provided to POCL via
TIP makes explicit what Transaction data have been sent to its
Clients.
e) Card Management Reconciliation Requirements
The CONTRACTOR shall reconcile DSS Card management actions against
instructions received from DSS. Details of such reconciliations
shall be agreed within three (3) months of execution hereof and
should depend on the proposed solution. The reconciliation
requirements apply both to Cards and to any Temporary Tokens that
may be used.
f£) Commercial Reconciliation Requirements
The CONTRACTOR shall provide information to enable reconciliation
of Services provided with Charges made.
The CONTRACTOR shall act, and be seen to be acting, on behalf of
the relevant AUTHORITIES in reconciliations with other parties,
and provide the necessary information for the AUTHORITIES to exert
appropriate management control over operations performed on their
behalf. The CONTRACTOR shall ensure in so doing that the
commercial relationships between the AUTHORITIES and third parties
are not compromised.
Requirements Page 302 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 893 Release spr 11
No
Programme Benefit Payment Subject Interfaces
Grouping Service Heading
Systems - design
Requirement Description:
INTERFACE DATA CO-ORDINATION
Ensure all transaction references (encashment identifiers and
payment authorisation references) are consistent across all
interfaces to enable efficient communication about particular
items in reconciliation and settlement processes:
- the EPOSS transaction reference will be used as the Encashment
Id passed to PAS from EPOSS and thence to CAPS:
* if the encashment is more than one EPOSS transactions,
indicate the range concerned (e.g. nnn...n03 to nnn...n24 could be
nnn...n0324);
- include in the EPOSS transaction log and the transaction data
sent to TIP:
* the Authorised Payment Id passed by CAPS to PAS;
* the NINO of the Beneficiary, as opposed to any agent;
(helps DSS to look-up corresponding item in their systems)
* the Agency code provided by CAPS;
- ensure that BES receipts contain the EPOSS transaction
reference(s) or Encashment Id to enable traces to both DSS and
POCL records (not necessarily easily recognisable to the public).
Requirements Page 303 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 894 Release spr 11
No
Programme General Subject General
Grouping Heading
Management information
Requirement Description:
Management Information Requirement
POCL needs management information over and above that specified
under accounting, reconciliation and settlement to enable it to
manage the contract and manage the service provided as well as
supporting general business requirements.
1. Service Provider to provide details of the type of information
they believe POCL will require to manage the contract and service,
2. POCL to have the right to request and receive during the
contract, and after, any information it believes it requires to
manage its business, the contract, any service, and also to
facilitate re-letting and hand-over of contract,
3. Service Provider to provide data to enable resource, network
productivity and cash management,
4. Service Provider to provide data to enable marketing planning.
This data to include:
* operational and "event" data will include things such as:
= office, user and stock unit registration/deletion and mutual
association,
- log-on/off,
= completion of summaries and returns/reports, roll-over to
new balances and/or Outlet accounting periods,
= polling events,
= receipt/implementation of new issues of software/reference
data, local reference data updates,
= equipment failure/repair/replacement, down-time, recovery
time, file corruption etc.
* information to enable POCL to monitor/manage SLAs,
* exception reports.
MIS captured will need to be by Outlet, Outlet type, region and
any other organisational structure.
Requirements Page 304 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 895 Release spr 11
No
Programme General Subject General
Grouping Heading
Security
Requirement Description:
Irregular Encashment Patterns
The requirement is for the service to be capable of monitoring
irregular encashments and reporting on irregular encashments.
Information is to be shared immediately with POCL
audit/Security/Operations when it relates to a post office.
Examples are defined as:-
1 Non encashment of a means tested benefit for a period of (4
weeks) ;
2 Non encashment of a non means tested benefit for a period of
(6 weeks) ;
3 Change of nominated P.O. and encashments for a period of (6
weeks), where there is no notification of change of address being
received by CMS from CAPS.
4 High Risk transactions indicating a potential exposure to fraud
e.g.:
-Foreign encashments;
-Casual agent encashment;
-Regular casual agent encashment (4 consecutive weeks);
-Multiple encashments (will depend on period of validity - to
be defined);
-Any combination of the above;
5 Any encashment made or attempted where a stop is in operation;
6 Any encashment of a payment where a subsequent loss report is
received;
7 Presentation of a non genuine card;
8 Apparent presentation of a duplicate card (both to be cancelled
immediately);
9 Any attempted keyed transactions out of specified service
hours;
10 Multiple keyed or telephone authorised transactions by clerk
and outlet, where there is no report of service or equipment
failure (contingency transactions at a level anything above the
agreed service efficiency levels);
11 Any transactions at a non-live post office i.e. one reported as
temporarily out of commission;
12 Usage of duplicate clerk identification devices or numbers
(note that both must be cancelled immediately)
Clarification:
The following clarification is provided in relation to the first
paragraph of this requirement:
"reporting of irregular encashments' is required to the DSS.
Requirements Page 305 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 896 Release spr 12
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Documentation
Requirement Description:
POCL is keen to explore the benefits and advantages of using
electronic communications in the user documentation area.
Requirements Page 306 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 897 Release spr 12
No
Programme General Subject General
Grouping Heading
Security
Requirement Description:
BPS Security Standards
The CONTRACTOR’s security objectives must be in conformance with
the security objectives stated in the BPS Security Statement.
There must be an appropriate countermeasure to each threat
identified in the security Statement.
Clarification:
The following clarification is provided in relation to the last
paragraph of this requirement:
The 'security Statement' refers to the BPS Security Statement.
Requirements Page 307 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 898 Release spr 21
No
Programme Order Book Subject Order Book Control
Grouping Control Service Heading Service
Service - design
Requirement Description:
Order Book Control Service (OBCS) - general requirements.
The Order Book Control Service must be quoted for as a separate
service, which the AUTHORITIES may take up in nominated outlets,
at the AUTHORITIES discretion, to be available when the platform
rolls out.
1. OBCS must be implemented using TMS and OPS.
2. The implementation of OBCS must comply with the Style Guide.
3. Help Desk support must be available to all Users of OBCS.
4. OBCS must be available at every counter position in any
automated outlet requiring the service during the normal opening
hours of that outlet.
Requirements Page 308 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 899 Release spr 21
No
Programme Order Book Subject Order Book Control
Grouping Control Service Heading Service
Service - design
Requirement Description:
Stop list maintenance.
The Order Book Control Service must be quoted for as a separate
service, which the AUTHORITIES may take up in nominated outlets,
at the AUTHORITIES discretion, to be available when the platform
rolls out.
1. The CONTRACTOR must maintain a stop list recording details of
order books which have been stopped, and against which no further
payments are to made, and order books which have been recalled. In
the case of recalled books orders may be paid for a number of days
following receipt of the recall; the last allowable order date
must be calculated within the OBCS service.
2. A communications link must be initiated between the DSS
computer and the TMS 7 nights each week and a datafile containing
stop list updates transferred. The stop list updates will include
entries that are to be added and reference to those that are to be
deleted. Notices not deleted by the DSS should be removed after an
appropriate period and archived.
3. Stop list update files must be applied in the order in which
they are delivered.
4. The maximum size of the stop list will be 1.5 million entries.
5. The maximum size of a stop list update will normally be 100,000
entries. In the event that an update of greater size is needed
special arrangements will be made.
6. The minimum size of a stop list update will be 0 (zero)
entries; in this case a file with an appropriate header and footer
will be sent.
7. Details of the stop list update interface with the DSS computer
system are given in <document reference number>
Requirements Page 309 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 900 Release spr 21
No
Programme Order Book Subject Order Book Control
Grouping Control Service Heading Service
Service - design
Requirement Description:
Order book processing - barcoded books.
The Order Book Control Service must be quoted for as a separate
service, which the AUTHORITIES may take up in nominated outlets,
at the AUTHORITIES discretion, to be available when the platform
rolls out.
There must be a facility for dealing with barcoded order books
presented for encashment of benefits at automated outlets
requiring the service.
1. The barcode must be scanned, validated and checked against the
stop list:-
- when the order book is received at the outlet
- when the order book is issued to a Beneficiary
- when the order book is presented for payment.
2. Whenever the barcode on an order book is scanned the system
must provide both a visual and an audible indication of the result
of the scan. There must be a clear difference between the audible
indication given for ‘success or normal’ and ‘failure or
exception’. There must be a clear distinction between the
instructions to ‘impound’ and ‘ cash and impound’.
3. When an order book is received the barcode must be scanned,
and checked against the stop list. The electronic record of the
transaction must be transmitted to the DSS computer system within
a datafile.
3.1 If the order book is on the stop list then the system must
instruct the clerk to impound, hole punch the book and return it
to the DSS.
3.2 The system must be capable of recording the re-direction of
the order book to another outlet or its return to the DSS.
3.3 If there are three consecutive failures to read the barcode
the system must prompt the clerk to enter the barcode information
via the keyboard. Subsequently the system must instruct the clerk
to hole punch the book and return it to the DSS. The system must
record the book as unreadable.
3.4 The maximum number of order books received in an outlet ona
business day is expected to be approximately 600.
4, When an order book is issued to the Beneficiary the barcode
must be scanned, and checked against the stop list. The
electronic record of the transaction must be transmitted to the
Requirements Page 310 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
DSS computer system within a datafile. The rules for making
payments and order book retention are as for encashments below.
4.2 The maximum number of order books issued at any one outlet in
a business day is expected to be approximately 100, but it should
be borne in mind that there will be an uneven distribution across
days, with peaks expected on Mondays and Thursdays.
5. When an encashment is made against the order book the barcode
must be scanned and checked against the stop list. Details of the
transaction must be transmitted to the DSS computer system within
a datafile.
5.1 If the barcode is not valid, or the book is identified as
counterfeit, then the system must instruct the clerk to impound
the book without payment. The transaction must be recorded by the
system.
5.2 If the order book is not on the stop list then the system must
instruct the clerk to pay normally and prompt for the number of
vouchers encashed. A default number of one should be presented
with the clerk having the ability to override this.
5.3 If the order book has been recalled then the system must
instruct the clerk to pay up to a specified date and prompt for
the number of vouchers encashed. A default number of one should be
presented with the clerk having the ability to override this with
a valid number, including zero. The system must instruct the clerk
to retain the book, hole punch it, and return it to the DSS.
5.3 If the order book has been stopped the system must instruct
the clerk to make no payment and impound the book , hole punch it
and return it to the DSS.
5.4 If there are three consecutive failures to read the barcode
the system must prompt the clerk to enter the barcode information
via the keyboard. If the book is on the stop list for impounding
then this takes precedence, otherwise the system must instruct the
clerk to pay one voucher and then hole punch the book and return
it to the DSS. The system must record the book as unreadable.
6. Details of the interface with the DSS computer system for
receiving transaction records noted above are given in <document
reference number>.
Requirements Page 311 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 901 Release spr 21
No
Programme Order Book Subject Order Book Control
Grouping Control Service Heading Service
Service - design
Requirement Description:
Order book processing - non-barcoded books.
The Order Book Control Service must be quoted for as a separate
service, which the AUTHORITIES may take up in nominated outlets,
at the AUTHORITIES discretion, to be available when the platform
rolls out.
1 If the book is identified as counterfeit, then the system must
instruct the clerk to impound the book without payment. The
transaction must be recorded by the system.
2. When an order book with no barcode is presented for encashment
the system must prompt the clerk to enter the number of vouchers
to be encashed. A default number of one should be presented with
the clerk having the ability to override this.
3. For each outlet for each business day a single electronic
record giving the total number of vouchers encashed must be
transmitted to the DSS computer system within a datafile.
3. Details of the interface with the DSS computer system for
receiving voucher totals records noted above are given in
<document reference number>.
Requirements Page 312 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 902 Release spr 21
No
Programme Order Book Subject Order Book Control
Grouping Control Service Heading Service
Service - design
Requirement Description:
Order Book Control Service (OBCS) - transaction times
The Order Book Control Service must be quoted for as a separate
service, which the AUTHORITIES may take up in nominated outlets,
at the AUTHORITIES discretion, to be available when the platform
rolls out.
The following transaction times must be achievable using the
OBCS:-
1. Logging the receipt of an order book, measured as the time from
any point in the cycle for one order book to the same point in the
cycle for the next order book assuming an the books do not appear
on the stop list, must take no more than <> seconds.
2. In issuing an order book to a beneficiary, assuming that the
order book is not on the stop list, the checking against the stop
list using OBCS must not add more than <> seconds to the time that
would have been taken with no stop list check.
3. In making an encashment, assuming the order book is not on the
stop list, the checking against the stop list using OBCS must not
add more than <> seconds to the time that would have been taken
with no stop list check.
Requirements Page 313 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 903 Release spr 21
No
Programme Order Book Subject Order Book Control
Grouping Control Service Heading Service
Service - design
Requirement Description:
Order Book Control Service (OBCS) - general service levels
The Order Book Control Service must be quoted for as a separate
service, which the AUTHORITIES may take up in nominated outlets,
at the AUTHORITIES discretion, to be available when the platform
rolls out.
1. The stop list functionality must be implemented such that the
version of the stop list being referenced from outlets has been
updated with the stop list updates from the DSS computer. The
version of the stop list is fully updated once all updates
received have been applied. If one days worth of updates have not
been applied then the version is deemed 1 day behind and so on.
On any business day:
96 % of outlets must be referencing a version which is fully
updated
98% of outlets must be referencing a stop list which is no more
than 1 day behind.
100% of outlets must be referencing a stop list which is no more
than 2 days behind.
2. Transaction data must normally be forwarded to the DSS computer
system soon after the completion of the business day on which the
transaction occurred as part of a batch transmission. Transaction
data not available for the next batch transmission must be include
in a subsequent transmission.
Data which is included in the first batch transmission to take
place after the time of the transaction is deemed to be in the
first batch transmission and so on.
Transaction data from the outlets must reach the DSS computer
system as follows:-
the data from 96% of outlets must reach DSS within the first
batch transmission
the data from 98% of outlets must reach DSS within the second
batch transmissions
the data from 100% of outlets must reach DSS within the third
batch transmissions
Requirements Page 314 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 904 Release spr 19
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
PAS must allow collection of all payments that the Authorised
Person is entitled to collect, ensuring that:-
* each payment only to be cashed once and for the amount
authorised by CAPS;
* partial encashment of any single payment is not permitted.
The following rule must apply for each encashment;
Each Authorised Person must collect all monies due to each
Authorised Person for whom collection is being made. A person who
is authorised to collect payments in respect of more than one
Authorised Person will be able to select the Authorised Person for
whom they want to collect. An Alternative Payee, for example, will
choose whether or not to collect their partner’s Child Benefit.
All other payees must encash all monies due if the total is less
than the limit (initially £1,000.00 but it must be possible to
vary this).If the total exceeds this limit then the Customer has
a choice, as follows
I. take all;
II. take nothing;
III. take all payments, in multiples of total weekly entitlement
up to but not exceeding the limit.
The priority order for collecting benefits will be to take any
ongoing benefit entitlements, oldest payment first - before any
one off benefit entitlement e.g. Social Fund or bonus payments.
Social Fund or bonus payments must always be collected in full.
Clarification:
The following clarification is provided in relation to this
requirement:
Authorised Persons collecting payments under £1,000.00 have 2
options:—
* take all
* take nothing
Second paragraph last sentence - However, an Alternative Payee
will be able to choose whether or not to collect their partner’s
Child Benefit.
Requirements Page 315 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 905 Release spr 12
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Systems - design
Requirement Description:
The system must be designed in order to give the user support in
maintaining transaction accuracy and to assist the transfer of
accurate product information to customers
Requirements Page 316 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 906 Release spr 12
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Roll-out
Requirement Description:
The service provider will plan so as to harmonise roll-out and BES
card availability. Offices should be provided with new terminals
on the day of installation. Installation covers physical
placement, connection to the system and testing
Requirements Page 317 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 908 Release spr 19
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES will produce a receipt containing the information as specified
in Requirement 764. Additionally, it may be necessary to generate
and record a unique transaction identifier to enable recovery
following equipment failure.
Requirements Page 318 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 909 Release spr 19
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES will enable an Authorised Person, or the Authorised Person's
casual agent, to encash benefits on behalf of people living in
Nursing/Residential/Retirement homes with a single signature on a
summarised receipt. The receipt, in these circumstances, should
identify those individuals on whose behalf a transaction has taken
place. It is not uncommon for 30 or more benefits to be collected
in one visit; there should be no maximum in terms of numbers or
cash value imposed by the system. The CONTRACTOR may wish to
consider whether separate security verification check(s) should be
introduced for signing agents.
Requirements Page 319 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 910 Release spr 12
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
BES must support the ability to vary the limit below which the
payee must encash all monies due (requirement 904), preferably by
use of one or more system parameters.
It should be borne in mind that some payees (i.e. recipients of
social fund payments and Alternative Payees) are not limited in
the same way. It is desirable that this rule is also implemented
by system parameter(s).
Requirements Page 320 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 911 Release spr 13
No
Programme End to End Subject General
Grouping Service Heading
Service - design
Requirement Description:
INTEGRITY ACROSS CHANGES
Maintain accounting and reporting integrity across changes,
including structural changes to software and reference data,
changes to controls and/or control mechanisms, and so forth.
This should include implementation of changes, reverting to
previous states (should this prove necessary, for example in fall-
back and recovery), co-existing before and after states (e.g. if
simultaneous implementation does not occur) and reporting across
change boundaries (e.g. using appropriate reference data versions
for each part of a report).
Requirements Page 321 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 912 Release spr 13
No
Programme POCL Subject POCL Infrastructure (SMS)
Grouping Infrastructure Heading
Systems - steady state
Requirement Description:
Portable Appliance Testing
The service provider shall carry out any regular testing of
equipment installed as part of the services in post offices and on
any other Authority premises as required by legislation
Requirements Page 322 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 913 Release spr 13
No
Programme Implementation Subject Service Level Agreements
Grouping Heading
Documentation
Requirement Description:
POCL user documentation service level agreement
1. Introduction
Comprehensive user documentation is required for all users of the
automated platform, and by other users, as notified by POCL.
2. Availability
2.1 Users of the automated platform
User documentation must be available to all users of the automated
platform 100% of the time that the automated platform is in use.
2.2 Other users
User documentation must also be available to others, (such as
helpline operators, non serving staff in retail outlets, Retail
Network Managers etc.) 100% of the time that the automated
platform is in use.
2.3 Contingency/disaster recovery arrangements
User documentation which contains information to users on
contingency/disaster recovery arrangements, such as what to do
during a system failure, must be available to all users during all
hours of business.
3. Content of user documentation
User documentation must contain all information which a user of
the documentation requires to complete all business transactions
at post office sites. This includes topics such as:
- performing counter transactions
- accounting
- balancing, including value stock taking
- stock ordering
- stock acceptance, disposal, destruction, remitting etc.
- contingency arrangements e.g. system failure
- giving information to customers e.g. how to obtain a duplicate
Motor Vehicle Licence disc
- product information for specific products e.g. posting
restrictions
- performing business transactions at Remittance Units e.g.
Girobank deposits.
4. Accuracy of information
All information in user documentation must be accurate.
5. Design of documentation
5.1 Visual identity
All user documentation must conform to POCL’s ‘Design Applications
Guidelines’, which is part of POCL’s ‘Visual Identity’ policy.
Requirements Page 323 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
5.2 Communications policy
All user documentation must conform to POCL’s communications
policy, which is covered in the draft document ‘A Guide to Head
Office Communications Team’ (first draft to be released in
February 1996).
5.3 Environmental policy
All user documentation must conform to POCL’s Environmental
policy.
6. Documentation for a new product/service
6.1 Notification of requirement by POCL
POCL must advise the CONTRACTOR of the requirement for
documentation for a new product/service [] days before the
implementation of that new product/service.
6.2 Drafting of documentation
The final copy of user documentation for a new product/service
must be completed [] days before the implementation of that
particular product/service.
6.3 Final approval by POCL
All user documentation for a new product/service must be given
final approval by POCL [] days before the implementation of that
particular product/service.
6.4 Availability
User documentation which contains the details of a new
product/service must be available to all users of the
documentation immediately prior to implementation of the new
product/service.
7. Updating user documentation
7.1 Planned changes
7.1.1 Notification of changes by POCL
POCL must advise the CONTRACTOR of the requirement to update user
documentation [] days before the implementation of the change.
7.1.2 Drafting of documentation
The final copy of updated user documentation must be completed []
days before the implementation of that particular change.
7.1.3 Final approval by POCL
All updated user documentation must be given final approval by
POCL [] days before the implementation of that particular change.
7.1.4 Availability
Updated user documentation must be available to all users of the
documentation immediately prior to implementation of that
particular change.
7.2 Emergency updates
Emergency updates to user documentation must be made available to
all users of the documentation within [24] hours of the changes
being notified to the CONTRACTOR by POCL.
Requirements Page 324 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
8. Requests for new/replacement copies
Any request for a new or replacement copy of user documentation
must be fulfilled within [3] days of notifying the Helpdesk. (This
is only required if paper based documentation is produced).
9. User satisfaction
9.1 Frequency of monitoring
User satisfaction with user documentation must be measured
annually.
9.2 Target for user satisfaction
User satisfaction with user documentation must be no less than
90%.
9.3 Topics to be covered
Topics to be covered by the user satisfaction survey will include
areas such as:
- overall use/effectiveness of documentation
- comprehensiveness of index/indices
- accuracy of index/indices
- relevance of any cross references
- accuracy of any cross references
- layout, style and language etc.
- readability/size/usefulness of graphics
- quality and clarity of text.
Requirements Page 325 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 914 Release spr 13
No
Programme Implementation Subject Service Level Agreements
Grouping Heading
Supporting services
Requirement Description:
SERVICE LEVEL AGREEMENT
OPERATIONAL SYSTEMS HELP DESK
1. INTRODUCTION
This paper documents the key help desk service requirements for
the operational systems.
2. HELP DESK SERVICE
2.1 General
The CONTRACTOR will provide a help desk service which will act as
the first point of contact for customers of the service.
Customers include both AUTHORITIES staff and staff of POCL clients
having a direct interface with the services provided.
AUTHORITIES staff includes BA and POCL staff as well as the ITSA
service delivery function.
The CONTRACTOR will:
act as a central point for information on the working state of
the services provided
keep customers notified of any scheduled interruptions
assist in any negotiations between the AUTHORITIES and its
customers where interruptions to the services provided are
scheduled
will keep customers informed of when the service will be
restored
The CONTRACTOR’s help desk service will provide lst, 2nd and 3rd
level services. The help desk must respond to calls within ten
seconds.
2.2 1st Level Service
The CONTRACTOR’s lst level service will provide an immediate
problem solving service for all simple and straightforward
problems, which can be resolved within 5 minutes, and all general
enquiries.
The lst level member who takes the call owns the problem from
initial logging through to resolution to the customers
satisfaction. The CONTRACTOR must cater for lst level members
being off duty.
Help desk contact will be over the telephone.
2.3 2nd Level Service
The CONTRACTOR’s 2nd level service will provide a diagnostics and
fixing service for all problems which cannot be fixed within 5
minutes by the 1st level service, but which can be resolved within
30 minutes.
Calls will be referred electronically from the lst level service
Requirements Page 326 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
to the 2nd level service. 2nd level staff will have access to a
prioritised list of outstanding problems, and all the details on
the problem entered by 1st level staff.
2.4 3rd Level Support
If the help desk is unable to resolve a problem at the 1st or 2nd
level the CONTRACTOR will categorise and prioritise the problem so
that it can be actioned and completed within a standard timescale.
2.5 Hours of Service
The CONTRACTOR will provide a continuous help desk service as
specified below:
lst Level 05:00-00:00, Mon-Sun(*), all year round (Xmas day
excepted)
2nd Level 05:00-00:00, Mon-Sun(*), all year round (Xmas day
excepted)
* - NB: Approximately 200 outlets would currently using the system
on Sundays although this may increase.
The CONTRACTOR shall ensure that calls made to the help desk
outside specified hours are accepted by CONTRACTOR.
The CONTRACTOR will provide the facility to transfer calls which
are received and are outside its area of responsibility. The
CONTRACTOR will also provide the facility to receive transferred
calls from POCL help desks and helplines.
The CONTRACTOR, given 2 working days notice, will extend the level
of service to whatever is required. In emergency circumstances,
the CONTRACTOR will, given 5 hours notice, provide a lst and 2nd
level service outside normal and extended working hours.
2.6 Problem Management
The CONTRACTOR will provide a problem management system to record
the problem details such as (but not exclusively):
unique problem serial reference, generated automatically by the
problem management system
customer contact, address, location and telephone number
date and time problem occurred
date and time problem was reported to help desk
help desk contact
description of the problem, including frequency of occurrence
serial references of similar faults and previous occurrences
hardware equipment involved; serial number etc.
software product and release version
assessed impact on customers business
priority for solution
problem category
estimated elapsed time to solve problem
any change of referral point
date and time of referral
The CONTRACTOR will update the problem management system with the
following information, as appropriate:
date and time of update
help desk contact updating record
Requirements Page 327 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
textual description of the work done, or the fact that the
problem had to be referred, elsewhere and who has taken it on
date and time problem was cleared
date and time the solution was accepted by the customer
actual elapsed time to solve problem.
The CONTRACTOR will also keep a record of all problems relating to
the failure of uploading and downloading data.
The CONTRACTOR’s lst level service staff will assign a priority to
the problem. Possible priorities could be:
Priority Description
le Live working disrupted. Office cannot continue
normal working.
2s Live working disrupted but work around possible.
3 Minor inconvenience. Help desk provide short term
resolution.
Throughout the life of the problem the CONTRACTOR staff will
monitor the progress of the problem and inform the customer at
regular intervals, to be agreed with the AUTHORITIES. This would
apply to 2nd and 3rd level services.
The CONTRACTOR will manage the resolution of any problem using
documented procedures agreed with the AUTHORITIES. These
procedures must be comprehensive in that they cover all aspects of
problem resolution from initial logging through to closure. For
example, in the event of a major service failure at a post office,
procedures must exist to cover the possible closure of the post
office and the re-allocation of its responsibilities to other post
offices. Escalation procedures must be included.
A problem can only be cleared when a customer has confirmed
satisfaction with the resolution.
The help desk service will be the contact point for requesting
consumables, training and documentation.
2.7 Systems and Services Supported
The CONTRACTOR will maintain user, asset, problem and change
management databases.
2.8 Resilience
The CONTRACTOR is responsible for ensuring that a contingency plan
is in place to cater with any help desk incident, e.g. loss of
staff, loss of telephone system, loss of problem/configuration
management system. The contingency plan is to be agreed with the
AUTHORITIES and must state how quickly the service will be
restored in the event of an incident.
2.9 Training
The CONTRACTOR will provide any necessary training to ensure
AUTHORITIES staff work effectively with the help desk. The
CONTRACTOR will develop training plans for its own staff.
2.10 Personnel
Requirements Page 328 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
The CONTRACTOR will ensure that all staff, including back-up
staff, employed on the help desk service must have suitable and
appropriate skills and training. The CONTRACTOR must ensure that
sufficient skilled resources are available to cater for holidays,
sickness and natural wastage within the CONTRACTOR’s organisation.
2.11 Service Targets
The CONTRACTOR will answer at least 98% of all calls to the help
desk within ten seconds during level 1 support hours. 100% of
calls must be answered within 20 seconds.
The percentage of ‘calls not answered’ will be less than 1%. This
includes calls where the line is busy as well as calls answered
but put on the ‘waiting queue’.
The CONTRACTOR will resolve at least 95% of calls assigned to
level 1 within 5 minutes. The CONTRACTOR will resolve 100% of
calls assigned to level 1 within 10 minutes.
The CONTRACTOR will resolve at least 95% of calls assigned to
level 2 within 30 minutes. The CONTRACTOR will resolve 100% of
calls assigned to level 2 within 45 minutes.
3. Service Monitoring
The CONTRACTOR will produce service information, in electronic
form and/or paper, and will deliver this information to the
AUTHORITIES within 2 working days of the end of the period to
which they relate. The following is an example of the information
required:
number of calls outgoing/received/number of calls not answered
% of calls answered within target times
number of problems/queries logged
number and % of problems/queries solved within target times
number of problems/queries assigned to level 1 that were not
cleared within 10 minutes
number of problems/queries with secondary complications (e.g.
repeat calls)
number of problems/queries escalated
% of time full help desk was available
supplier performance against agreed service levels for response
service availability at each office.
The AUTHORITIES may wish to analyse the information by:
category of operational problem/query
level and solving group at which the problem/query was solved
customer group and location
mean time to closure.
The CONTRACTOR will maintain help desk records for a minimum of 18
months.
Each quarter a survey will be conducted by the AUTHORITIES to
determine user satisfaction with the help desk. The AUTHORITIES
and CONTRACTOR will agree the approach to be taken and the
format/content of the questionnaire.
Requirements Page 329 of 407 Version 5.0 - Pathway
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED
POL00028168
POL00028168
- CONTRACTS
The CONTRACTOR will, on request, provide on-line access
problem Management System. The AUTHORITIES will inform
CONTRACTOR of who is authorised to access the system.
CONTRACTOR will provide ad-hoc reports, as requested by
to the
the
The
the
authorised representatives of the AUTHORITIES, within three
working days.
Requirements Page 330 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 915 Release spr 13
No
Programme Implementation Subject Service Level Agreements
Grouping Heading
Training
Requirement Description:
Training Services SLA
1. Introduction
This paper documents the training requirements and key measurables
that will be used to assess the effectiveness of the training
service as a whole.
2. Training Services
2.1 General
The Training provided will enable both AUTHORITIES staff or
Agents to achieve acceptable standards in key competencies in the
use of the Suppliers Service.
The Training Services will incorporate the development design and
delivery of agreed training events and support materials.
2.2 Specific Responsibilities
Supplier
- Design of Training events
- Development of Training materials (Day to day and maintenance)
- Delivery of Training - To delegates ( as appropriate)
- To Trainers
- Communication of Training activity - To delegates
- To Authorities
- To Regions
- To District Offices
- With BA/POCL
- Management of training processes - Training Plans
- Call up notices
- Site selection and
preparation
Provision of appropriate kit
- Management Information (Training)
- Provide defined reports on training completed for agreed
periods.
- Attend regular training review meetings
- Identify Improvement to training services
Authority
Requirements Page 331 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
- Agree and sign off supplier training proposals and processes.
- Monitor and review performance
Attend regular training review meetings
Identify improvements to training services.
3. Key measurables
3.1 Timeliness
Training courses should be available within 10 working days notice
being provided
Training should not be delivered more than 5 working days before
live usage of the system.
3.2 Quality
Trainees satisfaction with the training venue will be measured by
a training satisfaction questionnaire and should not be less than
85%.
The training must have received a positive rating of not less than
95% as a result of a training measurement questionnaire.
3.3 Cycle Time
Training should take no longer than x days/Hours in total to
enable delegates achieve the required standard of competence.
3.4 Contingency/disaster recovery
Notification of course cancellations must be issued at the
earliest possible time . A minimum of 48 hours notice must be
provided for 98% of cases.
No more that 2% of courses should be cancelled by the supplier.
When a designated training site becomes inoperative an alternative
must be made available and functioning within xx days to enable
continuation of the training plan.
3.5 Data Accuracy & integrity
There will be no degradation to any transaction data in the live
system environment as a result of accessing localised training
packages.
Training course content will have no factual errors at the time of
acceptance and release.
3.6 Competence levels
Requirements Page 332 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
The training services provided must ensure that 95% of trainees on
completion of the course will be able to demonstrate achievement
of the agreed level of competence, which shall reflect a score of
90% for knowledge related areas for transactions and the operating
platform.
Competence levels will be measured for delegates to x level of the
Kirkpatrick model utilised by POCL.
4. Communication
Delegate performance feedback will be provided for each person
attending a training course.
Regional Offices will be provided with a status report on
delegates whose attainment level of the key competencies for
their user group is below the agreed standard within 5 days of
course completion.
Trainees should receive call up papers one month prior to proposed
date of training course.
Call up notices should provide options as to days and times of
attendance for courses.
5. Monitoring Training Services
The CONTRACTOR will supply information to the AUTHORITY in the
agreed format which identifies actual performance against the key
measurables stated.
6. Training review meetings
Review meetings will be held on an agreed regular basis
Operational Trial - Bi-weekly
lst 6 Months Live running - Monthly
7 months > 18 Months - Quarterly
18 Months + - Adhoc or emergency review meetings may be called
by either party.
Note : Meetings timing will be subject to agreement these are only
indicators
7. Escalation Procedures
Failures in service levels will be managed and rectified between
the nominated SLA managers of the AUTHORITY and the SUPPLIER
whenever possible.
Issues which cannot be rectified will follow the agreed escalation
path as detailed within the Service Management schedule
8. Change Management
Permanent variations to the agreed levels of service and or the
Requirements Page 333 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
training services provided will be progressed through the standard
change control process.
9. Training Service SLA Management
This SLA will be managed on a day to day basis by
- The XXXXXXXXXXXXXX Manager for BA/POCL
- The XXXXXXXXXXXXXX Manager for CONTRACTOR
The SLA will be managed within the overall framework of the
agreed Service Management schedule.
Requirements Page 334 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 916 Release spr 14
No
Programme Implementation Subject Implementation (DSS
Grouping Heading
Customer education
Requirement Description:
Specify recommendations for marketing and education about the
Benefit Payment Service, for all external DSS and SSA customers
(i.e. Social Security benefit recipients and War Pensioners), and
POCL customers, using as a guideline the AUTHORITIES’ Marketing
and Education Plan 1996. This should include measurable
objectives, media to be used and detailed costings for each stage
of the implementation of the Contract, from the Award of Contract.
Requirements Page 335 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 917 Release spr 14
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Customer education
Requirement Description:
Specify recommendations for marketing and education about the new
infrastructure and POCL applications, for all POCL external
customers, using as a guideline the AUTHORITIES’ Marketing and
Education Plan 1996. This should include measurable objectives,
media to be used and detailed costings for each stage of the
implementation of the Contract, from the Award of Contract.
Requirements Page 336 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 918 Release spr 14
No
Programme General Subject General
Grouping Heading
Customer education
Requirement Description:
Process requirement for DSS, SSA and POCL:
Communications, marketing and education will be managed by the
AUTHORITIES and the CONTRACTOR. Within this structure, make
recommendations on the allocation of roles and responsibilities,
working processes, cost and resourcing implications. The
AUTHORITIES will retain the right of veto on all communication,
marketing and education for all DSS, SSA and POCL customers, DSS
and SSA staff, POCL employees, subpostmasters and other agents and
their staff.
Requirements Page 337 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 919 Release spr 14
No
Programme General Subject General
Grouping Heading
Customer education
Requirement Description:
Specify and provide costs for the production of education material
in Welsh in accordance with the Welsh Language Act 1993, about the
Benefit Payment Service, for all Welsh speaking DSS customers and
provide this service if required.
Requirements Page 338 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 920 Release spr 14
No
Programme General Subject General
Grouping Heading
Supporting services
Requirement Description:
Provide advice and information in support of internal
communications activity to DSS and SSA staff, POCL employees,
subpostmasters and other agents and their staff.
Requirements Page 339 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 921 Release spr 14
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Security
Requirement Description:
The OPS will provide a secure timeout facility for each counter
terminal and back office terminal.
The facility must allow the clerk to resume work with the minimum
delay consistent with achieving security.
It must be clear that the facility is in use to remove any
confusion between a terminal with the facility activated and a
terminal that is available for use by any authorised user.
Under circumstances where the facility has been activated and the
clerk is no longer able to cancel it, for whatever reason, with
appropriate authority:-
the completion of clerk and office balances must be possible;
it must be possible to make the terminal available to another
authorised clerk;
the circumstance must be logged to the audit trail.
Requirements Page 340 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 922 Release spr 15
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Systems - design
Requirement Description:
The acoustic noise emission of any item of OPS equipment must not
exceed 60dB(A) measured at a distance of 1m.
Requirements Page 341 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 924 Release spr 15
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
Through BES it must be possible to reconcile the cards actually
held at an outlet against those recorded on the system(s)
Requirements Page 342 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 925 Release spr 19
No
Programme Implementation Subject Implementation (Joint)
Grouping Heading
Operational Trial
Requirement Description:
Operational Trial Requirements
There are 2 elements to this requirement:
1. The Operational Trial element (in which the 3 phases "must
finish in sequence", and the live trial is of 3 months duration,
initially in 10 outlets, expanding to 60 outlets).
2. Steady State Testing (which continues for the life of the
contract, relates to new or amended services, and for whose live
trials parameters will be agreed between the CONTRACTOR and the
AUTHORITIES) .
The second stage may start before the first has finished.
A. The CONTRACTOR must comply with the AUTHORITY'S approach to,
and measurement of, the operational trial and acceptance testing,
contained in the control document ref. 011 (Operational Trial-
Technical & Model Office test requirements of the service
suppliers). Each operational trial (be it the initial Operational
Trial Stage or subsequent Operational Trials of new or amended
services, individually or in groups) will consist of three
distinct phases, which may overlap but must finish in sequence.
Phase 3 must in each case must not start until the relevant Phase
2 has been successfully completed
The phases are listed below:
1 A technical test that confirms that the underlying systems
function correctly.
2 A model office test that simulates the service provision
from end to end.
3 A live trial that tests the service with live data and
true users and customers.
B The CONTRACTOR will undertake the technical test. The
AUTHORITIES will oversee the technical test. The AUTHORITIES will
agree the test plans and monitor to ensure that the test is
completed effectively. Control document Ref. 011 contains full
details of testing activities.
C Testing will continue for the life of the contract. As new
services are added or existing services amended these will be
subject to detailed technical, model office and live trial
Requirements Page 343 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
testing.
D The CONTRACTOR will produce all of the deliverable documents
defined in control document Ref. 011.
E The CONTRACTOR will produce test scripts to reflect all test
conditions supplied by the BA/POCL test team. The BA/POCL test
team reserve the right to define and produce other test scripts
for more testing as required.
F The CONTRACTOR will support the testing taking place in the
POCL Model Office. The Model Office testing is intended to
simulate as far as possible the live operation of the end to end
system without using live operational data.
G The CONTRACTOR will install hardware, communications and
software and will commission the test equipment in the agreed
configuration at the Model Office site. It is estimated that 48
terminals will be required at the Model Office site.
H The live trial phase of the Operational Trial will be of 3
months duration. It will initially take place in 10 outlets and
expand to 60 outlets. The AUTHORITIES and the CONTRACTOR will
agree the location and types of outlets.
All live trials will include, but not exclusively:
1 Training of users
2 Installation processes
3 Synchronisation of services
4 Live data handling from end to end
I All new or current products to be migrated on to the platform
must undergo a technical test, a model office test anda _ live
trial. The parameters of live trials taking place after the
initial (3 month 10 to 60 outlets) trial will be agreed between
the AUTHORITIES and the CONTRACTOR.
K For maintenance and upgrade purposes the CONTRACTOR will, in
the Operational Trial Stage, proceed as agreed in close liaison
with the AUTHORITIES, and will, subsequent to that stage, regard
the Model Office in all respects as an outlet.
Requirements Page 344 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 926 Release spr 15
No
Programme Implementation Subject Implementation (DSS
Grouping Heading
Roll-out
Requirement Description:
DSS Implementation - Generic Requirement
All roll out plans and changes to the plans to be agreed with the
AUTHORITIES. Any changes to functionality will be implemented only
with the agreement of the AUTHORITIES. A change control procedure
for all aspects of the service will be agreed with the
AUTHORITIES.
The AUTHORITIES will reserve the right to suspend the roll out
programme if the CONTRACTOR fails to deliver the agreed service
levels.
Requirements Page 345 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 927 Release spr 15
No
Programme Implementation Subject Implementation (DSS
Grouping Heading
Documentation
Requirement Description:
DSS Implementation - Procedural Documentation
The CONTRACTOR shall provide information to the DSS to enable them
to complete procedure manuals, forms and leaflets for internal DSS
use. The information must include sufficient detail to allow DSS
staff to understand what happens in the Post Office and the type
of problems Customers are likely to encounter. The information is
required within twenty one (21) days of the award of contract. In
addition, CMS guides will need to be provided directly by the
CONTRACTOR.
There will be an agreed process for updating information in the
procedure manuals, forms and leaflets. This information must be
available, where timescales allow, four (4) months before the
proposed change.
Requirements Page 346 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 928 Release spr 15
No
Programme Implementation Subject Implementation (DSS
Grouping Heading
Documentation
Requirement Description:
DSS Implementation - Technical Documentation
The DSS will have copies of the Service Architecture and Design
documentation describing CMS, PAS and BES. The content and level
of detail of the Service Architecture and Design documentation to
be agreed with the DSS within x days of the award of Contract (x
to be agreed by the DSS and CONTRACTOR).
The Service Architecture and Design documentation will be updated
to ensure information is always current.
Requirements Page 347 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 929 Release spr 19
No
Programme Implementation Subject Implementation (DSS
Grouping Heading
Roll-out
Requirement Description:
DSS Implementation - Foreign Encashment
From the start of use of the Card it must be possible for an
Authorised Person to be paid using a Card at his/her Nominated
Post Office and, in accordance with the rules for Foreign
Encashments:
- at any other automated office
- in any main office.
There are approximately 1500 Post Offices classified as 'main'
detailed in schedule X (to be issued).
The CONTRACTOR should bear in mind that procedures in Post Offices
will not be allowed to impact on quality of service measures, and
thus it is seen as desirable that some automated system, enabling
at least payments to be authorised, is implemented in main Post
Offices as soon as possible after the start of roll out. It is
anticipated that some automation will be needed in all main Post
Offices to support Foreign Encashments within twelve (12) months
of the start of roll out.
Requirements Page 348 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 930 Release spr 15
No
Programme Implementation Subject Implementation (DSS)
Grouping Heading
Installation
Requirement Description:
DSS Implementation - Installation
If the CONTRACTOR’s solution requires any activity within DSS
nominated sites the roll out schedule must be agreed with the DSS.
Requirements Page 349 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 931 Release spr 19
No
Programme Implementation Subject Implementation (DSS
Grouping Heading
Supporting services
Requirement Description:
DSS Implementation - Support Services
The CONTRACTOR shall ensure that all agreed support services will
be available to DSS staff and Authorised Persons at least four (4)
weeks before Card payments are made and all services to perform to
agreed Service Levels.
Appropriate levels of support services must be available:
* to provide support when Users have access to the system;
* to cover the operation of interfaces with other systems;
* to provide support for all other Help Desks linked to the
CONTRACTOR Help Desk facility;
* to provide replacement Cards to Authorised Persons who have
reported them lost/damaged/not received.
If appropriate a CONTRACTOR Help Desk will deal with calls
relating to Equipment and Software installed in DSS nominated
sites. This will include, but is not exclusive to:
* Fault diagnosis
* Maintenance call out
* Caretaking advice
* Configuration management.
Requirements Page 350 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 932 Release spr 15
No
Programme Implementation Subject Implementation (DSS
Grouping Heading
Training
Requirement Description:
DSS Implementation - Training
The CONTRACTOR shall provide information to the DSS to enable
them to complete training material. This information is required
within twenty one (21) days of the award of contract. It must be
possible to update this information to incorporate any changes.
This information must be available, where timescales allow, four
(4) months before the proposed change.
The CONTRACTOR will provide training for a limited number of CAPS
training development staff. This training will be available during
Implementation and Steady State.
Requirements Page 351 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 933 Release spr 20
No
Programme Implementation Subject Implementation (DSS
Grouping Heading
Service - design
Requirement Description:
Roll out of Card Payments
The current state of roll out planning is for a 3 month pilot -
September to December 1996, followed by a 24 month roll out.
There are two key drivers to the volumes during this period;
firstly benefit systems being made Card ready - this timetable is
covered in the CAPS component release strategy; and secondly the
automation schedule for the Post Offices. There is currently
general agreement between BA and POCL on this schedule.
For planning purposes, the assumption is that both the above
drivers produce linear conversions over the 24 month roll out from
January 1997 to December 1998. This would produce a hyperbolic
curve for the number of Card payments throughout this period - for
example, after 12 months, both roll outs would be 50% complete
allowing only 25% of payments to be made by Card. This curve will
be further refined as more detailed plans can be applied.
Requirements Page 352 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 934 Release spr 15
No
Programme Benefit Payment Subject Interfaces
Grouping Service Heading
Interface with CAPS
Requirement Description:
SERVICE BOUNDARY DEFINITIONS
1. Service Boundary : CAPS to CMS.
led. Business supported across the boundary.
The following business transactions shall be supported across this
boundary:
Transactions initiated by CAPS:
* Personal details notification - all DSS Customers (Beneficiaries
and payees) will be referred to throughout the BPS by their NINO.
The first such Transaction involving CMS that relates to a
specific Customer will always be a personal details notification.
The CONTRACTOR shall treat this notification both as a statement
that this person must be able use any CMS supported Services and
also that the personal details supplied must be used in any CMS
supported interaction involving that Customer. Specifically, once
the Customer has been accepted onto CMS the CONTRACTOR shall
ensure that a Card (or equivalent Token) is always available to
the Customer to enable collection of benefit payments. This
facility must continue until 'end of interest' is received by the
CONTRACTOR.
For changes to personal details notified later, the CONTRACTOR
shall ensure the revised details are used in all succeeding CMS
supported interactions. Revisions to personal details will only be
supplied via this route and the CONTRACTOR shall ensure this is
the only route available for changing the personal details used by
CMS (the only exception is for Nominated Post Offices which may be
changed by requests at the post office counter as defined in the
CAPS to PAS Service Boundary).
* End of interest notification - when the DSS no longer wishes a
Customer to be able to use CMS supported facilities, it will send
an ‘end of interest’ Transaction. The CONTRACTOR shall ensure
that, until or if any subsequent personal details notification is
received, the person identified is unable subsequently to take any
part in use of any CMS supported facilities (i.e. any Transaction
requiring them to hold a Card is rejected).
There are no Transactions across this boundary that may be
initiated by the CONTRACTOR.
1.2. System and Service responsibility
Business responsibilities are as outlined within the definition of
each Transaction as are any Transaction specific constraints that
Requirements Page 353 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
have been identified (including specific timing and sequencing
constraints) .
Over and above DSS office staff , equipment and infrastructure,
the CONTRACTOR shall provide any staff, premises, networks (voice
and / or data), hardware, software, procedures and training
required to deliver these Services to the nominated CAPS hardware
platforms. The CONTRACTOR is entirely responsible for roll out,
operation and management of all such equipment, subject to DSS
approval. The CONTRACTOR shall undertake to provide such
connection(s) at sites nominated by DSS that may change over the
period of the DSS Agreement. These connections include those
connections within the CAPS processors that enable data to be
transmitted between the CAPS and CMS systems.
The CAPS hardware platform will be ICL VME based and will be
located in the ACCs currently operated for DSS by EDS. It is for
DSS's operator of the CAPS services and the CONTRACTOR to agree,
subject to DSS approval, the technical nature of the connection.
The CONTRACTOR’s Service responsibilities extends to:
* transport of CAPS created transactions and associated
information (e.g. reference data) from the CAPS service to the
Services along with all subsequent processing. This normally
includes detecting the availability of such Transactions and data
on the CAPS services;
* provision of all responses to such Transactions (e.g.
acknowledgements) along with delivery to the CAPS service and
notification of their availability.
The CONTRACTOR is solely responsible for all activities required
to discharge the above responsibilities. In all cases he must
ensure integrity, security, auditability and maintenance of full
audit trail of all Transactions and data as they are transmitted
and processed by him.
Requirements Page 354 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 935 Release spr 15
No
Programme Benefit Payment Subject Interfaces
Grouping Service Heading
Interface with CAPS
Requirement Description:
1. Service Boundary : CAPS to PAS
1.1 Business supported across the boundary
The following business transactions shall be supported across this
boundary:
Transactions initiated by CAPS:
* Payment Authorisation - Customers who, having been adjudicated
as entitled to benefit, will receive one or more payments. For
those Customers who so elect, these payments may be collected at
post offices and may require the use of the Card based method of
payment. For each payment that is to be made available for
collection in this way, the DSS will supply details of the payment
and authorise the CONTRACTOR to enable its collection.
* Payment Stop Request - Having authorised the CONTRACTOR to make
a payment collectable, the DSS need the facility to withdraw that
authorisation (i.e. to stop the payment). This stop must be
successful if issued at any time after a payment is authorised but
before encashment.
* Payment Enquiry - Having authorised the CONTRACTOR to make a
payment collectable, the DSS need the facility to enquire upon its
current status (i.e. ‘awaiting encashment’ or ‘encashed’). The
CONTRACTOR shall return the current status along with encashment
details if status is ‘encashed’.
* Personal details notification - all DSS Customers (Beneficiaries
and payees) will be referred to throughout the BPS by their NINO.
The first such transaction involving PAS that relates to a
specific Customer will always be a personal details notification.
The CONTRACTOR shall treat this notification both as a statement
that this person must be able to use any PAS supported services
and also that the personal details supplied must be used in any
PAS supported interaction involving that Customer. For changes to
personal details notified later, the CONTRACTOR shall ensure the
revised details are used in all succeeding PAS supported
interactions. Revisions to personal details will only be supplied
via this route and the CONTRACTOR shall ensure this is the only
route available for changing the personal details used by PAS (the
only exception is for Nominated Post Offices which may be changed
by requests at the post office counter).
* End of interest notification - when DSS no longer wishes a
Customer to be able to use (or be referred to in )PAS supported
facilities, it will send an end of interest Transaction. The
Requirements Page 355 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
CONTRACTOR shall ensure that, until or if any subsequent personal
details notification is received, the person identified is unable
subsequently to take any part in use of any PAS supported
facilities (i.e. any Transaction containing their NINO is
rejected).
Transactions initiated by the CONTRACTOR:
* Expiry confirmation - CAPS defines the validity period of a
payment and will treat the payment as expired if uncollected
within the specified time. The CONTRACTOR shall also supply
confirmation that each such transaction is uncollectable once it
has passed its expiry date.
* Encashment Notification - the CONTRACTOR shall notify CAPS of
all BPS encashments.
* Restricted Post Office Infringement - the CONTRACTOR shall
notify CAPS of all failed encashment attempts that would have
contravened post office restrictions.
* Change Nominated Post Office Request - the CONTRACTOR shall
notify CAPS of any requests for change of Nominated Post Office by
a Card holding DSS Customer at the post office. If such changes
are unacceptable to the DSS then revised Personal Details
broadcasts will be sent to PAS and CMS notifying the CONTRACTOR of
the DSS authorised post office.
1.2. System and Service responsibility
Business responsibilities are as outlined within the definition of
each Transaction as are any Transaction specific constraints that
have been identified (including specific timing and sequencing
constraints).
Over and above the DSS office staff, equipment and infrastructure,
the CONTRACTOR shall provide any staff, premises, networks (voice
and / or data), hardware, software, procedures and training
required to deliver these Services to the nominated CAPS hardware
platforms. He is entirely responsible for roll out, operation and
management of all such equipment subject to DSS approval. The
CONTRACTOR must undertake to provide such connection(s) at sites
nominated by the DSS that may change over the period of the DSS
Agreement. These connections include those connections within the
CAPS processors that enable data to be transmitted between the
CAPS and PAS systems.
The CAPS hardware platform will be ICL VME based and will be
located in the ACCs currently operated for DSS by EDS. It is for
the DSS's operator of the CAPS services and the CONTRACTOR to
agree, subject to DSS approval, the technical nature of the
connection.
The CONTRACTOR’s Service responsibilities extends to:
* transport of CAPS created transactions and associated
Requirements Page 356 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
information (e.g. reference data) from the CAPS service to the
Services along with all subsequent processing. This normally
includes detecting the availability of such transactions and data
on the CAPS services;
* provision of all responses to such transactions (e.g.
acknowledgements) along with delivery to the CAPS service and
notification of their availability;
* transport of CONTRACTOR created Transactions and information
from the Services to the CAPS service and notification of their
availability.
* detecting CAPS generated responses to such Transactions and
transport of those responses to the Services along with subsequent
processing.
The CONTRACTOR is solely responsible for all activities required
to discharge the above responsibilities. In all cases he must
ensure integrity, security, auditability and maintenance of full
audit trail of all Transactions and data as they are transmitted
and processed by him.
Requirements Page 357 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 936 Release spr 15
No
Programme Benefit Payment Subject Interfaces
Grouping Service Heading
Customer interface
Requirement Description:
1. Service Boundary : DSS Customer to CMS
In this context a DSS Customer is a Person who is currently or
potentially a Beneficiary or payee involved in collecting benefit
payments via the Benefit Payment Service.
Throughout this requirement the word 'Card' is used to mean either
a personalised Card that will be valid for an extended period of
time or any Temporary Token that is used for a limited duration
(or limited number of events). The use of such a Temporary Token
is entirely the CONTRACTOR's choice. It may be acceptable as a way
of guaranteeing access to CMS supported services if there are
circumstances where personalised plastic Cards cannot be delivered
in time. The CONTRACTOR must limit, and fully define the
restrictions applying to, the use of such Temporary Tokens.
1.1. Business supported across the boundary
The following business transactions must be supported across this
boundary:
Transactions initiated by the CONTRACTOR:
* Customer Education - DSS Customers who will use the BPS must
have information provided to them that enables them to understand
both what facilities are available to them and how they may use
such facilities. Normally the CONTRACTOR will provide all such
information pro-actively to the Customer (i.e. without an explicit
request from the Customer) although they must provide the facility
for Customers to request such material. The CONTRACTOR may wish to
deliver this element of the service via multiple interactions with
the Customer.
* Card Issue - Having accepted a Customer as a valid User of CMS
services it is the CONTRACTOR's responsibility to ensure a Card
(or equivalent Token) is available to the Customer whenever
required for benefit payment. An integral part of this process is
therefore the ability to place a Card in the Customer's hand. The
CONTRACTOR must ensure that they can get a Card to all Customers.
Additionally they must monitor all aspects of the process to
ensure problems lying with the CONTRACTOR or his sub- contractors
are detected and resolved before they affect the Customer. The
CONTRACTOR may wish to deliver this element of the service via
multiple interactions with the Customer (for instance, the use of
Pick-Up Notices (PUNs) and collection reminders is acceptable
although not mandated.)
This function may be initiated for a variety of reasons which must
Requirements Page 358 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
include automatic initiation for:
* initial issue of Card to Customers newly authorised to use CMS
facilities;
* replacement of a Card as a result of loss, theft, damage or
destruction;
* renewal of Cards sufficiently frequently to minimise the number
of Cards unusable as a result of normal wear and tear;
* replacement of Card due to revision of personal details as
passed from CAPS to CMS wherever they affect what is on the Card.
Transactions initiated by the Customer:
* Customer Enquiries - The CONTRACTOR must provide a service
whereby all of DSS's Customers are able to enquire on all aspects
of the Card Management Service and receive prompt and accurate
responses. Such enquiries depend on the services proposed by the
CONTRACTOR but must, as a minimum, encompass enquiries about:
* the use of all CMS supported services available to the Customer;
* whether the Customer should expect to receive a Card or not;
* the status, type and expected availability (time and location)
of any Card the Customer is expecting but has not yet received;
* the status of any Card(s) he currently holds (at a minimum which
are valid for payment collection and which are not);
* the status of any Card(s) he previously held. It is for the
CONTRACTOR to propose a retention period to be agreed by the DSS.
* Customer Reports - The CONTRACTOR must provide facilities by
which the Customer can report various events relating to his
Card(s). Having accepted such reports, the CONTRACTOR is
responsible for all subsequent processing / recovery actions
needed to ensure the Customer can collect whatever payments are
due to him. The reports to be supported are dependant on the
CONTRACTOR solution but must as a minimum include:
* report of non-receipt of Card by Customer - the CONTRACTOR must
undertake ensuing recovering action to either ensure receipt of
that Card by the Customer or invalidation of that Card along with
its replacement;
* report of loss, theft, damage or destruction - the CONTRACTOR
must take whatever invalidation and replacement actions are
necessary.
There are common facilities that the CONTRACTOR must make
available to support any interaction initiated by the Customer on
this service boundary. These include:
Requirements Page 359 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
* trace facilities to identify the Customer - although the DSS
promotes the use of NINO in communications with Customers, the
CONTRACTOR cannot rely on a Customer supplying his NINO in any
interaction. Nor can the CONTRACTOR rely on the use of Card
numbers (since the Customer will, in many cases, not have the Card
at hand). Therefore the CONTRACTOR must have other facilities for
identifying Customers based on other information available to him.
The CONTRACTOR must define what these facilities are and any
circumstances in which they may require additional DSS support
(and hence incur extra costs to the DSS);
* ensuring the Customer is who he claims to be - the CONTRACTOR
must enforce checks that are sufficient to prevent fraudulent or
malicious use of the services;
* applying agreed access criteria - the CONTRACTOR must define
which Customers can access which services (for example can a
husband report the loss of his wife's Card) and must gain
agreement from the DSS for these restrictions. Such restrictions
must be implemented in their solution
1.2. System and Service responsibility
All the Card Management functions described above are entirely the
CONTRACTOR's responsibility. The use of DSS staff and facilities
to deliver any part of this service is possible although subject
to the following constraints:
* the CONTRACTOR must promote the use of his facilities for
delivering all of the services above;
* the CONTRACTOR must minimise the operational impact of the BPS
on DSS staff and services;
* the CONTRACTOR should use existing DSS office equipment and
infrastructure (for example, telephones, terminals, cables
servers, exchanges, wide area network connections (voice and data,
public and private)). The CONTRACTOR should not propose a solution
that requires rollout of any additional equipment or any changes
to existing equipment unless it is the most cost-effective taking
full account of any disruption to DSS offices. Any such disruption
costs will be evaluated as part of the cost-effectiveness of
CONTRACTOR proposals;
* the CONTRACTOR must enable the DSS to deliver the Customer
initiated elements of the above services to as high a quality as
that delivered by the CONTRACTOR directly (although only for
periods where DSS offices are open to callers). The CONTRACTOR
must take all cost-effective actions to minimise the use that
Customers make of such DSS supported facilities;
al the use of DSS staff and facilities for any other part of
these services is only acceptable if no other cost-effective
solution is viable (for example, if the CONTRACTOR issues
Temporary Tokens then physical delivering to Customer by DSS staff
may be the most cost-effective solution);
Requirements Page 360 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
& the cost (direct and indirect) of any use of DSS staff or
facilities by the CONTRACTOR will be evaluated in assessing the
overall cost effectiveness of their solution;
% the CONTRACTOR retains sole responsibility for all activity
and must supply services that enable him to do so.
The detailed processes are for the CONTRACTOR to define but:
= must deal with all DSS Customers (including, for example,
those of no fixed abode, those where the DSS has not been informed
of an address, those who cannot attend the Post Office for Card
collection, etc.);
bs must not degrade existing service levels (for example, the
Customer must not have to spend significantly more time or effort
in collecting a Card and supporting material than he does in
collecting current IOPs and supporting material);
* must not place other additional burdens on the Customer (for
example, requiring long distance telephone calls is unacceptable).
Over and above the DSS office staff , equipment and
infrastructure, the CONTRACTOR must provide any staff, premises,
networks (voice and / or data), hardware, software, procedures and
training required to deliver these services to all of the DSS's
Customers. He is entirely responsible for rollout, operation and
management of all such equipment subject to DSS approval. The
CONTRACTOR must undertake to provide such facilities to all
Customers and via all DSS locations to be nominated by the DSS.
The CONTRACTOR must provide connections to all such DSS sites
which may be anywhere in the United Kingdom and which will change
both in number and location over the period of the contract.
At Version 1 connections to all DSS offices are expected. DSS
offices are within the DSS, DHSS(NI), and ES, and number
approximately 2,000 currently (although this figure may change
significantly before full implementation as well as subsequently).
For services involving DSS staff, the CONTRACTOR'S service
responsibilities extend to:
e collecting information from the DSS clerk and all subsequent
processing;
e presenting information back to the DSS clerk.
The CONTRACTOR is solely responsible for all activities required
to discharge the above responsibilities. In all cases he must
ensure integrity, security, auditability and maintenance of full
audit trail of all transactions and data as it is transmitted and
processed by him.
Requirements Page 361 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 937 Release spr 15
No
Programme Benefit Payment Subject Interfaces
Grouping Service Heading
Interface with BA staff
Requirement Description:
1. Service Boundary : DSS Staff to CMS
In this context DSS staff are any individuals authorised by the
DSS to administer benefit payment operations.
Throughout this requirement the word 'Card' is used to mean either
a personalised Card that will be valid for an extended period of
time or any Temporary Token that is used for a limited duration
(or limited number of events). The use of such a Temporary Token
is entirely the CONTRACTOR'S choice. It may be acceptable as a way
of guaranteeing access to CMS supported services if there are
circumstances where personalised plastic Cards cannot be delivered
in time. The CONTRACTOR must limit, and fully define the
restrictions applying to, the use of such Temporary Tokens.
1.1. Business supported across the boundary
The following business transactions must be supported across this
boundary:
Transactions initiated by DSS Staff:
DSS Staff Enquiries - The CONTRACTOR must provide facilities
whereby all authorised DSS staff are able to enquire on all
aspects of the Card Management Service and receive prompt and
accurate responses. Such enquiries depend on the facilities
proposed by the CONTRACTOR but must, as a minimum, include all
enquiries that a DSS Customer is able to make and also encompass
enquiries about:
* for a particular Customer, the current status and type of all
Cards related to him (i.e. all Cards the CONTRACTOR intends or
ever has produced for this Customer regardless of whether the
Customer has received them or not). For each such Card, a full
history of all relevant status changes must be available
(including date, time and reason for each status change) .
Additionally, information must be available regarding likely dates
and times of any future status changes (for example, when a Card
in production is likely to be available for collection, when a
currently valid Card is due to expire, etc.);
* for a particular Card, who is the Cardholder. In addition, all
the information above should be available for that Card.
DSS Staff Reports - The CONTRACTOR must provide facilities by
which DSS staff can report various events relating to the Card
Management Service. Having accepted such reports the CONTRACTOR is
responsible for all subsequent processing / recovery actions
required to ensure the Customer has continuous, uninterrupted
Requirements Page 362 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
access to CMS supported services. The reports possible are
dependant on the CONTRACTOR solution but must as a minimum
include:
& report of non-receipt of Card by Customer - the CONTRACTOR
must undertake ensuing recovering action to either ensure receipt
of that Card by the Customer or invalidation of that Card along
with its replacement;
EJ report of loss, theft, damage or destruction - the CONTRACTOR
must take whatever invalidation and replacement actions are
necessary.
There are common facilities that the CONTRACTOR must make
available to support any interaction initiated by DSS staff on
this service boundary. These include:
& facilities to identify the clerk and ensure he has security
clearance to use the service;
* applying agreed access restriction to particular functions -
the CONTRACTOR must define which categories of DSS staff can
access which services and must gain agreement from the DSS for
these restrictions.
Transactions initiated by the CONTRACTOR
None are mandated.
Other transactions the CONTRACTOR may propose:
The CONTRACTOR may, subject to various restrictions, propose
solutions that require support for other interactions across this
boundary. Such proposals may include (but are not limited to):
* transitional arrangements - for example to support Urgent
Payment collection (see the CAPS to PAS Service Boundary
requirement) ;
% support for other elements within the boundary of the
CONTRACTOR's responsibility - for example the CONTRACTOR may
propose DSS operational support for elements of the Card issue
process (for instance, Temporary Tokens) or for tracing Customers
the CONTRACTOR cannot identify (see below for restrictions on such
proposals).
1is2a System and Service responsibility
All the Card Management functions described above are entirely the
CONTRACTOR'S responsibility. The service delivered to DSS staff is
subject to the following constraints:
% the CONTRACTOR must promote the use of his CMS facilities by
the DSS's Customers;
* the CONTRACTOR must minimise the operational impact of
Requirements Page 363 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
delivering these services on DSS staff and services;
ba the CONTRACTOR must use existing DSS office equipment and
infrastructure (for example, telephones, terminals, cables
servers, exchanges, wide area network connections (voice and data,
public and private)). The CONTRACTOR should not propose a solution
that requires rollout of any additional equipment or any changes
to existing equipment unless it is the most cost-effective taking
full account of any disruption to DSS offices. Any such disruption
costs will be evaluated as part of the cost-effectiveness of
CONTRACTOR proposals;
% the use of DSS staff and facilities to deliver elements of the
CONTRACTOR'S service is only acceptable if no other cost-effective
solution is viable (for example, if the CONTRACTOR issues
Temporary Tokens then physical delivering to Customer by DSS staff
may be the most cost-effective solution). The cost (direct and
indirect) of such of DSS staff or facilities by the CONTRACTOR
will be evaluated in assessing the overall cost effectiveness of
their solution.
Over and above the DSS office staff , equipment and
infrastructure, the CONTRACTOR must provide any staff, premises,
networks (voice and / or data), hardware, software, procedures and
training required to deliver these services to all authorised DSS
staff. The CONTRACTOR is entirely responsible for rollout,
operation and management of all such equipment subject to DSS
approval. The CONTRACTOR must undertake to provide such facilities
to all locations to be nominated by the DSS. The CONTRACTOR must
provide connections to all such DSS sites which may be anywhere in
the United Kingdom and which will change both in number and
location over the period of the contract.
At Version 1 connections to all DSS offices are expected. DSS
offices are within the DSS, DHSS(NI), and ES, and number
approximately two thousand (2,000) currently (although this figure
may change significantly before full implementation as well as
subsequently).
For services to DSS staff, the CONTRACTOR’S service
responsibilities extend to:
e collecting information from the DSS clerk and all subsequent
processing;
e presenting information back to the DSS clerk.
The CONTRACTOR is solely responsible for all activities required
to discharge the above responsibilities. In all cases he must
ensure integrity, security, auditability and maintenance of full
audit trail of all transactions and data as it is transmitted and
processed by him.
Requirements Page 364 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 938 Release spr 15
No
Programme Benefit Payment Subject Interfaces
Grouping Service Heading
Management interfaces
Requirement Description:
SERVICE BOUNDARY: Data Protection Act 1984 to DSS
Business supported across Service Boundary.
DSS will require access to the information covered and provided
under the Data Protection Act 1984 functional requirement. The
nature and form of the access is not as yet defined in detail but
will be needed to support some or all of the following:
Fraud detection and prevention;
Security violation investigation;
Probity assurance;
Criminal investigations;
Information to support DSS policy questions;
CONTRACTOR responsibility.
The CONTRACTOR is responsible for providing a detailed functional
specification for approval by the DSS prior to implementing any
services affected by the Data Protection Act 1984.
The CONTRACTOR is responsible for providing all services to
support the functional requirements.
The CONTRACTOR is responsible for ensuring that any information
supplied under the Data Protection Act 1984 is accurate and that
assurances can be given as to the integrity of that information.
The CONTRACTOR is responsible for delivering any information
requested under the Data Protection Act 1984 to the requesting
body, Person or DSS as appropriate.
Outline Service requirements.
The Data Protection Act 1984 became law from 11/11/87, all
subsequent alterations and reviews to this law must be integrated
and adhered to.
The CONTRACTOR must record all written requests for a data
protection print from a Customer, representative or DSS within
forty (40) days of receipt of the request, and deal with queries
raised within a timescale to be agreed with the AUTHORITIES.
All information provided under the Data Protection Act 1984 must
be made available to facilitate inspection.
Requirements Page 365 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Details of responses of a request and response made under the Data
Protection Act 1984 must be retained consistent with the Data
Protection Act 1984 requirements.
Clarification
The following clarification applies to the last sentence of this
requirement:
delete "responses of"
Requirements Page 366 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 939 Release spr 15
No
Programme Benefit Payment Subject Interfaces
Grouping Service Heading
Management interfaces
Requirement Description:
SERVICE BOUNDARY: BPS MIS Reports to DSS
Business supported across Service Boundary
DSS will require access to the Management Information collected as
part of the response to the BPS Management Information Catalogue
requirements. The nature and form of presentation of this
information is not as yet defined but is expected to be presented
in report formats to be agreed with the DSS.
The Management Information will be required to support the
following:-
Fraud detection and prevention
Security detection and investigation
Failure investigation
Service disputes
Service quality
Audit
Accounting and validation
Information to support policy development, policy monitoring,
Parliamentary and Ministerial questions etc.
CONTRACTOR’S responsibility.
The CONTRACTOR is responsible for providing detailed response
specifications for approval by the DSS prior to the commencement
of collection and reporting of the MIS required.
The CONTRACTOR is responsible for providing all the services
necessary to support the provision of the information requested
within the BPS MIS Catalogue.
The CONTRACTOR is responsible for ensuring that the contents of
the Management Information reports are accurate and that any
assurances or appropriate requests for confirmation of the
integrity of the reports is available.
The CONTRACTOR is responsible for the delivery of the Management
Information reports within an agreed period following the required
completion of the information collection, and for filtering the
limited reports to a number of central DSS services for further
processing.
Outline Service Requirements.
The CONTRACTOR must make available utilities to facilitate
Requirements Page 367 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
inspection of the Management Information data by DSS.
The Management Information must be retained for a period
consistent with the Companies Act requirements.
Requirement 941 Release spr 15
No
Programme Implementation Subject Implementation (DSS)
Grouping Heading
Roll-out
Requirement Description:
DSS implementation - Post Office roll out
The planned go live for Post Office automation will be agreed by
the CONTRACTOR and the AUTHORITIES, and the CONTRACTOR will inform
DSS of the acceptance by POCL of each Post Office installation.
Northern Ireland will be a discrete area for roll out purposes.
Requirements Page 368 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 942 Release spr 15
No
Programme Benefit Payment Subject Interfaces
Grouping Service Heading
Audit
Requirement Description:
SERVICE BOUNDARY: DSS to Supplier Audit Trails
Business supported across Service Boundary.
DSS will require access to the audit information captured as part
of the audit trail functional requirement. The nature and form of
the access is not as yet defined in detail but is likely to be
needed to support some or all of the following:
Fraud detection and prevention
Security violation investigation
Probity assurance
Failure investigation
Service and Contractual disputes
Criminal investigations
Information to support policy development, policy monitoring,
Parliamentary and Ministerial questions etc.
CONTRACTOR’S responsibility.
The CONTRACTOR is responsible for providing a detailed functional
specification for approval by the DSS prior to implementing any
such services.
The CONTRACTOR is responsible for providing all services to
support the functional requirements.
The CONTRACTOR is responsible for ensuring that the contents of
the audit trail are accurate and that suitable legal assurances
can be given as to the integrity of the audit trail.
The CONTRACTOR is responsible for delivering the total or a
filtered subset of the audit trail to a limited number of central
DSS services for further processing. The delivery should include
any technical transformation and/or reformatting that may be
required to ensure the audit trail is understandable by the
receiving services.
Outline Service requirements
The audit trail must be maintained during all periods of operation
including fallback and recovery.
The audit trail must record all transaction and data passing
across service boundaries and all major processing actions
The information recorded must allow tracking of a business
transaction through the CONTRACTOR services and across service
Requirements Page 369 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
boundaries to other supplier’s services.
The information recorded must identify origin of transaction, time
and outcome.
The audit trail must be made available to the DSS as logically a
single entity showing a chronological trail of events.
The CONTRACTOR must make available utilities to facilitate
inspection of the audit trail by DSS.
The audit trail must be retained for a period consistent with the
Companies Act requirements.
Requirements Page 370 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 943 Release spr 15
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
PAS must restrict encashment to Great Britain or Northern Ireland
for specific benefits when notified by CAPS.
Requirements Page 371 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 944 Release spr 15
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
Casual Agent encashment must be restricted to the Authorised
Persons Nominated Post Office (x-ref. 768).
Clarification:
The following clarification is provided in relation to this
requirement:
Note that Alternative Payees cannot nominate a Permanent Agent or
Casual Agent to collect any payments for which they are the
Alternative Payee.
Requirements Page 372 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 945 Release spr 15
No
Programme Implementation Subject Service Level Agreements
Grouping Heading
Installation
Requirement Description:
1. This paper documents the Installation Service Level
requirements for the operational systems.
2. Survey
2.1 The CONTRACTOR will provide [] working days written notice of
the survey date to the OUTLET MANAGER.
2.2 The CONTRACTOR will agree with OUTLET MANAGER the number of
positions to be automated, should this not be agreed by the
region.
2.3 The survey date and time will be agreed with the OUTLET
MANAGER.
2.4 The survey will be undertaken at the agreed date and time.
2.5 The surveyor will conform to the agreed identification
process before starting the survey.
2.6 The survey will be completed in a maximum of [] visits.
2.7 The CONTRACTOR will give [] days notice to the OUTLET MANAGER
and the database liaison of a cancelled appointment.
2.8 The CONTRACTOR will agree, within agreed parameters, with the
OUTLET MANAGER and obtain sign off the siting of the OPS.
2.9 A quality survey will be conducted by the AUTHORITIES to
measure User satisfaction with the survey. The AUTHORITIES and the
CONTRACTOR will agree the approach to be taken and the
format/content of the questionnaire.
2.10 The CONTRACTOR will achieve []% satisfaction rating from the
survey.
3 Modifications
3.1 The CONTRACTOR will provide [] working days written notice of
the modifications date to the OUTLET MANAGER.
3.2 The modifications date and time will be agreed with the
OUTLET MANAGER.
3.3 The modifications will be undertaken at the agreed date and
time.
3.4 The CONTRACTOR will give [] days notice to the OUTLET MANAGER
Requirements Page 373 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
and the database liaison of a cancelled appointment.
3.5 The CONTRACTOR will agree, within agreed parameters, with the
OUTLET MANAGER and obtain sign off the siting of the OPS.
3.6 Cosmetic damage will be scheduled for repair within [ ] days
of the requirement being raised.
3.7 98% of repairs will be carried out within their scheduled
timescales.
3.8 Modifications will not be carried out during specified/
agreed period. These period will be agreed between the CONTRACTOR
and the AUTHORITIES every quarter.
3.9 Visits to carry out further modifications will be scheduled
with the OUTLET MANAGER.
3.10 A quality survey will be conducted by the AUTHORITIES to
measure User satisfaction with the survey. The AUTHORITIES and the
CONTRACTOR will agree the approach to be taken and the
format/content of the questionnaire.
3.11 The CONTRACTOR will achieve [ ]% satisfaction rating from
the modifications exercise.
4 Installation
4.1 The CONTRACTOR will provide [] working days written notice of
the installation date to the OUTLET MANAGER.
4.2 The installation date and time will be agreed with the OUTLET
MANAGER.
4.3 The installation will be undertaken at the agreed date and
time.
4.4 The CONTRACTOR will give [ ] days notice to the OUTLET
MANAGER and the database liaison of a cancelled appointment.
4.5 A quality survey will be conducted by the AUTHORITIES to
measure User satisfaction with the survey. The AUTHORITIES and the
CONTRACTOR will agree the approach to be taken and the
format/content of the questionnaire.
4.6 The CONTRACTOR will achieve [ ]% satisfaction rating from the
installation exercise.
4.7 The CONTRACTOR will inform the AUTHORITY at the end of each
working day, in a format to be agreed, of the following, though
not exclusively:
- The outlets that have been successfully installed
- Configuration details
- Serial numbers of the OPS
Requirements Page 374 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
4.8 The AUTHORITIES will at the end of each calendar month inform
the AUTHORITIES of any configuration changes or swapouts and the
relevant serial numbers.
4.9 Cosmetic damage will be scheduled for repair within [ ] days
of the requirement being raised.
4.10 98% of repairs will be carried out within their scheduled
timescales.
Requirements Page 375 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 949 Release spr 16
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Training
Requirement Description:
The Service Provider must be capable of delivering POCL's total
training requirement if required in due course.
Requirements Page 376 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 950 Release spr 16
No
Programme General Subject General
Grouping Heading
Overview of Solutions
Requirement Description:
Requirement - Service Provider Solutions Document
The Supplier will provide an overview document which will describe
and summarise the solutions they are proposing in response to the
requirements documents sent to them. It is to be written in such
a way that it logically links back to the requirements.
It is expected that this document will also include aspects of the
overall end to end solution which are not explicitly defined in
the individual responses to requirements.
The document should be text biased and not exceed 35 pages. It may
be supported by annexes which could include flow diagrams of the
technical solution and the support processes. It should be
provided on floppy diskette in Word 6 (12 point)format accompanied
by 3 hard copies.
The format is to cover the following:
BA
This should describe the CMS and PAS services and should include
the following topics:-
Hardware proposed and sizing
Physical locations of central sites
Software proposed
Network (including topology, protocols)
External Interfaces (including CAPS and POCL systems)
Resilience and availability
Security
Fallback and Recovery
Scalability
POCL
An end to end description of how the Post Office Strategic
Infrastructure will operate covering all outlets. This should
cover the solutions for OP, TMS, SM, APS, BES, EPOS and OBCS
services and should include the following topics:-
Hardware proposed (with expected utilisation)
Physical locations of central sites
Software proposed (including operating system, middleware and
application software)
Wide Area Network (including topology, protocols, message
authentication)
Security (including any key management)
External Interfaces (including POCL and client systems)
Fallback and Recovery
Requirements Page 377 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Resilience and availability
Scalability
System Management
Technical Interfaces
A description of how all the components of the system interact
with each other and with other systems such as CAPS and Post
Office accounting systems
Benefit Payment Service
This should draw together the specific solutions to CMS, PAS and
BES into an integrated end to end picture of how the system will
work. This should draw together the specific solutions to:-
card design
responsibilities
security
Fraud Investigation
Contingency
Provision of Services
An end to end description of how the solutions will be implemented
and should include:-
Roll out through to steady state
Migration of existing automation and services
Training and Documentation
Customer education and Marketing
Support services, specifically Help facilities.
The report should be written at a level directed at Programme Team
members who will have a knowledge of the solution proposed.
Requirements Page 378 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 951 Release spr 17
No
Programme General Subject General
Grouping Heading
Systems - design
Requirement Description:
The Contractor must develop and maintain a document describing the
design of the service architecture.
As a minimum the document must specify:
- the major components, provided directly or sub-contracted,
used in providing the services
- the functionality within the major components
- the interfaces between the major components
- the service levels required across the interfaces to meet the
objectives of the overall services
- all the interfaces with the Authorities' systems and with
other parties
The audience for the document will be technical staff within the
Authorities. It must be self contained, though it is expected
that it will reference other documents to provide further levels
of detail as appropriate. The level of detail within the document
must be such that it gives a thorough background to the
construction of the services and the rationale for the approach.
It is anticipated that the document will be between 200 and 400
pages in length.
Requirements Page 379 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 952 Release spr 17
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Service - design
Requirement Description:
APS key management
The OPS must support a reliable, secure and encrypted means for
the transfer of data that may subsequently be used for
cryptographic applications at the counter e.g. the mechanism must
be suitable for key management.
Requirements Page 380 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 953 Release spr 17
No
Programme POCL Subject POCL Infrastructure (OPS)
Grouping Infrastructure Heading
Service - design
Requirement Description:
Concurrency
The OPS must support concurrent access to its services.
The OPS must ensure data integrity, e.g. reports printed at the
back office whilst serving at the front office should be
consistent, with a clearly stated policy of what front office data
is included in the report.
The office performance should not be significantly degraded by
other office activity, e.g. front office, back office and
communications activities should not unduly impact each other.
Requirements Page 381 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 954 Release spr 20
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
If, before expiry of the existing Card and after CAPS has sent a
notification that an Authorised Person no longer requires a Card,
CAPS sends new personal details for that Customer , the CONTRACTOR
must use the existing Card rather than issuing a new Card.
Requirements Page 382 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 955 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
The CONTRACTOR shall ensure that all Temporary Tokens, which will
have a validity of seven (7) days, are terminated on payment of
the single encashment authorised by the DSS. If a Authorised
Person is entitled to benefit on successive days additional tokens
may be issued for each days entitlement. All Temporary Tokens will
be payable at the Post Office nominated by the DSS at the time of
issue and retained by the Post Office clerk following encashment.
Requirements Page 383 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 956 Release spr 18
No
Programme Benefit Payment Subject Interfaces
Grouping Service Heading
Interface with OPS
Requirement Description:
1. Service Interface : ESNCS to OBCS
1.1. Business supported across the interface
The following business transactions must be supported across this
boundary:
Transactions initiated by ESNCS:
Order Book stops - ESNCS will provide to OBCS amendments to the
currently held list of Order Books that should be stopped and
impounded when they are presented at a Post Office. That is, Order
Books where no further payment on foils within the specified Order
Book should be made;
Order Book recalls - ESNCS will provide to OBCS amendments to
the currently held list of recalled Order Books with the recall
date. A recalled Order Book will be impounded upon presentation at
a Post Office but payments
Purge Order Book Notification - ESNCS will provide a list of
Order Books which OBCS may purge from its list of recalls or
stops. OBCS will not subsequently need to support any stop or
recall action on such Order Books unless they are subsequently re-
notified via either the stop or recall processes;
Restate Full List - ESNCS can, on request from either the DSS or
the CONTRACTOR, provide a full list of all stops and recalls that
are currently in force. This is an ad hoc transaction which
requires negotiations between both parties before it can be
initiated.
Transactions initiated by the CONTRACTOR:
Notification of outcome of Order Book receipt at Post Office -
OBCS will notify ESNCS of the outcome of the Order Book receipt
process in the Post Office. The outcome will be one of:
e the Order Book is acceptable;
e the Order Book is immediately impounded (due to a stop or recall
request previously accepted from ESNCS);
e the Order-Book bar-code is found to be unreadable and is to be
sent by the Post Office to a DSS Office for re-issue;
Notification of outcome of an Order Book redirection - the Post
Office will detect delivery of an Order Book to the wrong Post
Office and attempt to redirect it to the correct one. OBCS will
notify ESNCS of the outcome of such events which will be one of:
e the Order Book is redirected successfully;
e the Order Book is immediately impounded (due to a stop or recall
request previously accepted from ESNCS);
e the Order Book bar-code is found to be unreadable and is to be
sent to a DSS Office for re-issue.
Notification of Outcome of Order Book handover to customer -
OBCS will notify ESNCS of the outcome of the Order Book handover
to customer. The outcome will be one of:
e the Order Book is handed over successfully;
Requirements Page 384 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
e the Order Book is immediately impounded (due to a stop or recall
request previously accepted from ESNCS) ;
e the Order Book bar-code is found to be unreadable and is to be
sent to a DSS Office for re-issue;
Notification of Outcome of Order Book foil encashment - OBCS
will notify ESNCS of the outcome of the Order Book foil
encashment. The outcome will be one of:
the encashment is successful and the number of foils encashed is
reported;
* no encashment is made and the Order Book is immediately
impounded (due to a previous stop request accepted from ESNCS) ;
e one or more foils are encashed and the Order Book impounded (due
to a previous recall request accepted from ESNCS);
e one foil is encashed and the Order Book is impounded due to the
Order-Book bar-code being unreadable;
Post Office Summary transaction - OBCS will notify ESNCS daily
for each Post Office of:
e the total number of non bar-coded Order Books presented at that
Post Office;
e the total number of Order Books impounded without any
encashments due to the bar-code being invalid.
1.2. System and Service responsibility
The CONTRACTOR must provide all networks, hardware, software,
procedures and training required to connect and deliver services
to the nominated ESNCS platforms. He is entirely responsible for
rollout, operation and management of all such resources subject to
the approval of the DSS. The CONTRACTOR must undertake to provide
such connection(s) at sites nominated by the DSS and which may
change over time.
ESNCS is ICL VME and UNIX based and resides in the DSS Area
Computer Centres operated for the DSS by EDS. It is for DSS's
operator of the ESNCS gateway platform (currently SEMA) and the
CONTRACTOR to agree the technical nature and implementation of the
connection. This should be in negotiation with EDS and subject to
DSS approval.
The CONTRACTOR cannot change the ESNCS interface as currently
implemented in any way without the agreement of the DSS. The
exception to this is the acknowledgement of Order Book stops and
recalls which is in addition to the current implementation. A
detailed specification is available to the CONTRACTOR.
The CONTRACTOR'S service responsibilities extend to:
e transport of ESNCS created transactions and any associated
information (e.g. reference data) from the ESNCS service to
their own services along with any subsequent processing. This
normally includes detecting the availability of such
transactions and data on the ESNCS services;
e provision of responses to transaction where requested along with
delivery to the ESNCS service;
e transport of CONTRACTOR created transactions and information
from their own services to the ESNCS service and notification of
their availability if required.
The CONTRACTOR must agree a Service Level Agreement with the DSS
prior to service commencement.
Requirements Page 385 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirements Page 386 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 957 Release spr 18
No
Programme Implementation Subject Implementation (DSS
Grouping Heading
Roll-out
Requirement Description:
DSS Implementation - Live Operational Trial
The live Operational Trial will last for approximately three (3)
months. This
geographical
(seven) days
will be made
will initially require X Post Offices in a small
location to be agreed with the AUTHORITIES within 7
of the award of contract. During this period payments
to a limited number of Customers.
Requirements
Page 387 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 958 Release spr 18
No
Programme Implementation Subject Implementation (DSS)
Grouping Heading
Trials & Testing
Requirement Description:
DSS Implementation - Testing
Software and Equipment to be available for the purpose of end to
end testing - to ensure the whole network of services and system
from DSS feeder systems through PAS/CMS to the finance package are
able to work as a whole.
The CONTRACTOR is required to provide infrastructure and support
services for DSS testing environment.
The CONTRACTOR will produce a testing strategy and plan to be
agreed with DSS within x days of the award of Contract (x to be
agreed by the DSS and CONTRACTOR) .
The Service Acceptance Test of the Operational Trial will not be
closed until all aspects of the Acceptance Criteria have been met.
Clarification:
The following clarification is provided in relation to the last
paragraph of this requirement:
‘Service Acceptance Test’ is a term used in previous draft
versions of Clause 403 (Operational Trial). This clause no longer
makes reference to this and is therefore no longer applicable as a
distinct term. In the original drafting of Requirement 958 it was
intended to be used as a generic term to describe a period during
which all of the Acceptance Criteria would be satisfied and was
not retrospectively removed from this requirement. For the
purposes of Requirement 958 therefore this term is no longer
appropriate and may be disregarded. The last line of this
Requirement may therefore be interpreted as:
‘The Operational Trial will not be closed until all aspects of the
Acceptance Criteria have been met’
Requirements Page 388 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 959 Release spr 18
No
Programme Implementation Subject Implementation (DSS)
Grouping Heading
Service - design
Requirement Description:
The Urgent Payment and immediate stop facility will be required by
July 1997.
Requirements Page 389 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 960 Release spr 19
No
Programme POCL Subject POCL Applications (EPOSS)
Grouping Applications Heading
Accounting &
reconciliation
Requirement Description:
ZERO-VALUE TRANSACTIONS
EPOSS shall allow POCL to record various zero-value Transactions
to measure work done, for example for various Royal Mail and
Parcelforce activities and for distribution of various forms, for
example Ellls. The measurement of work may be for charging
clients, for remunerating subpostmasters, for monitoring work done
to check assumptions in cases where the costs are subsumed in
other charges, and so forth. Potential reasons for new zero-value
Transactions might be to provide data for clients in support of
Service Level monitoring, for example recording Transaction times
for mail receipts.
Automated zero-value Transactions shall be reported separately.
Initially these will be:
* Automated Payments which fall into two categories:
= Smart Tokens, where "voids" from a User viewpoint are
really recorded as Reversals and any Transactions are recorded
(even if zero-value) once the Client has been identified since
this implies interaction with the Smart Token;
bd swipe-cards or keyed Transactions, where recording of zero-
value Transactions is controlled by POCL Product parameters for
minimum and maximum values but where a Transaction can be made
void during Customer service.
% Benefit Encashment transactions, which may be zero-alue for
various reasons, e.g.:
= Customer terminates before signing the declaration,
perhaps as a quasi-enquiry;
= User terminates, perhaps if unsatisfied by Customer
identity, etc.;
= no payment due;
= no payment available at this Outlet (e.g. Restricted Post
Office or Foreign Encashment) ;
= the Transaction is normally zero-value, e.g. requested
change of Nominated Post Office,
= statement request;
* Associated benefit Card Transactions, (if "automated" with POCL
sub-contracted to the CONTRACTOR as "Client",
recording:
iad receipt of batches of Cards into Outlets;
= returns of uncollected Cards;
- issuing of Cards to cardholders.
* Transitional arrangements for OBCS with registration of order
Requirements Page 390 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
book receipt and issue in Outlets.
Particular aspects are:
a) zero-value BES transactions should be recorded on the EPOSS
Transaction log and included in data passed to POCL's TIP system,
as indicated in requirement 881 (nil-value receipts);
b) Automated Payments should continue as now;
c) extra automated Transactions, including zero-value ones such
as those indicated above for Card/book/receipt movements should be
designed as POCL Products in the normal way with normal
Transaction controls and data flows, including interfaces with
POCL systems.
Requirements Page 391 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 961 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Security
Requirement Description:
The CONTRACTOR shall ensure that the reverse of the Card mandates
that Cards which are found ARE NOT returned to the Post Office
but to a secure freepost address nominated by the CONTRACTOR.
Requirements Page 392 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 962 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Customer education
Requirement Description:
The CONTRACTOR shall ensure that the reverse of the Card carries a
message that reminds the Authorised Person of their responsibility
in reporting changes in circumstances which may affect their
entitlement to benefit, to the DSS. The content of the message is
to be agreed between the DSS and the CONTRACTOR.
Requirements Page 393 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 963 Release spr 19
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
All payments made using contingency procedures must be clearly
distinguishable from routine payments when notified to CAPS.
Requirements Page 394 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 964 Release spr 19
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
PAS must be able to handle temporary increases in the volume of
data from CAPS during recovery of a CAPS failure (to catch up with
data lost during the failure). The CONTRACTOR must specify what
constraints their solution will impose under such circumstances.
Requirements Page 395 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 965 Release spr 19
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
The POCL counter clerk must not be able to enter the amount
encashed. They must only be able to indicate whether the amount
authorised by CAPS has been collected.
Requirements Page 396 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 966 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
In the event of a postal dispute, or other unforeseen
circumstances, CMS must be able to introduce new Authorised
Persons to the service in a secure and auditable manner to allow
collection of Authorised Payments on the due date. Such events
must be clearly distinguishable from routine introductions to
prevent duplication and to support audit.
Requirements Page 397 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 967 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Interface with CAPS
Requirement Description:
CMS must be able to handle temporary increases in the volume of
data from CAPS during recovery of a CAPS failure (to catch up with
data lost during the failure). The CONTRACTOR must specify what
constraints their solution will impose under such circumstances.
Requirements Page 398 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 968 Release spr 19
No
Programme Benefit Payment Subject DSS Services (CMS)
Grouping Service Heading
Service - design
Requirement Description:
If the CONTRACTORS solution includes the issue of a Pick Up Notice
(PUN) the DSS may require the issue of information notes prepared
by the CONTRACTOR and any other associated collateral material (to
be agreed between the CONTRACTOR and the DSS) to be issued with
the PUN. It is not envisaged that the collateral material will
increase postage costs. CONTRACTORS should separately identify the
cost of providing such a service.
Requirements Page 399 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 969 Release spr 19
No
Programme POCL Subject POCL Applications (BES)
Grouping Applications Heading
Service - design
Requirement Description:
When the CONTRACTOR is notified by POCL that for whatever reason
the Nominated Post Office is closed unexpectedly (e.g. audit
closure, safe failure, fire etc., but not including failure of the
Operating Platform), BES will allow Authorised Persons to encash
their benefits at a post office other than their Nominated Office.
These transactions will not be recorded as a Foreign Encashment as
outlined in requirement 770.
Requirements Page 400 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 970 Release spr 19
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Service - design
Requirement Description:
The CONTRACTOR must have a process for identifying (in conjunction
with POCL) Post Offices that have been permanently closed (for any
reason) and which alternative Post Office should be used.
Requirements Page 401 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 971 Release spr 19
No
Programme Implementation Subject Implementation (POCL)
Grouping Heading
Interface with POCL
applications
Requirement Description:
Farnborough requirement
It is a POCL requirement that its automated payment clients
receive only one stream of unreconciled data irrespective of the
source of the polling at outlets (via whether Farnborough or
CONTRACTOR facilities). The CONTRACTOR and the AUTHORITY will
agree a strategy to achieve this requirement from day 1.
The strategy will include, but not exclusively, a timetable
separate from and shorter than the roll out timetable, for the
CONTRACTOR to absorb the reducing workload from Farnborough.
Requirements Page 402 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 972 Release spr 19
No
Programme Implementation Subject Implementation (Joint
Grouping Heading
Roll-out
Requirement Description:
The CONTRACTOR will conform to the AUTHORITIES rollout strategy
which is as follows:
1. Installation will take place in major conurbations first.
2. The M25 area and Northern Ireland will be subject to separate
rollout plans.
3. The M25 rollout will take place during the second half of the
overall timetable.
4. The rollout will start in September 1996 and end in December
1998.
Requirements Page 403 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 973 Release spr 20
No
Programme End to End Subject Interfaces
Grouping Service Heading
Flexibility - services
Requirement Description:
Services supplied by the CONTRACTOR may, during the lifetime of
the contract or at termination, need to be replaced or
supplemented with services provided by other suppliers. It must
therefore be both technically and commercially viable for the
CONTRACTOR’S services to be replaced by and/or interface to
services from other suppliers. To support this, the CONTRACTOR
must declare all internal interfaces between separate service
components within the overall service boundary (including those
between PAS and CMS, PAS and the POCL Infrastructure, CMS and the
POCL Infrastructure). For each interface the supplier must provide
an interface specification covering the same properties and to the
same level of detail as Requirements 934-940 and 942. The
CONTRACTOR must also describe the costing and charging basis for
integration with other suppliers' services.
Requirements Page 404 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 974 Release spr 20
No
Programme Implementation Subject Implementation (DSS
Grouping Heading
Service - development
Requirement Description:
Benefits Agency Migration
The migration of benefit payments into CAPS and the CONTRACTOR's
services will be in accordance with the Benefit Migration
Timetable provided. This timetable is provisional, and may be
subject to change.
Requirements Page 405 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 975 Release spr 21
No
Programme Benefit Payment Subject DSS Services (PAS)
Grouping Service Heading
Flexibility - services
Requirement Description:
BPS must be flexible to allow other benefit payment postal
authorities e.g. Channel Island Post Offices, British Forces Post
Offices and Isle Of Man Post Offices, to be connected to it
without significant re-engineering should the AUTHORITIES require
to do so in the future.
Requirements Page 406 of 407 Version 5.0 - Pathway
POL00028168
POL00028168
AUTHORITIES' AGREEMENT SCHEDULE BO1 RESTRICTED - CONTRACTS
Requirement 976 Release spr 20
No
Programme Benefit Payment Subject Interfaces
Grouping Service Heading
Documentation
Requirement Description:
The CONTRACTOR should comply with the service interface
requirements which are detailed in requirements 934 - 940 and 942,
and in more detail in the BA/POCL Service Interface Definition
Document .
Requirements Page 407 of 407 Version 5.0 - Pathway