FUJ00122103
FUJ00122103
R. vs. Teja — notes for Penny
Ref: _ d:\profiles\jenkinsgareth\my documents\gij documents\notes\penny_obcs.doc
Author: Gareth I Jenkins
Date: 08/09/2005 09:52:00
1. Introduction
The purpose of this note is to attempt to answer some question about Horizon
Operations, specifically to do with OBCS.
The text of the question is in red, with my responses in black or blue. Text in blue is
copied directly from the standard witness statement. Anything outside that which I
have written especially for this case is in black
2. Questions
Following a meeting on 2" September, at which the DWP's computer system was
discussed a number of additional questions have arisen. These are outlined below and
supplement the list previously provided.
ty
2)
The DWP staff were unable to describe the communications link in use
between the Horizon and PRS systems other than mentioning the presence of a
“hub”. Could this be expanded upon please ? (e.g. Were the systems connected
using a dedicated secure line, leased virtual circuit, ISDN, ethernet etc. ? What
encryption/authentication mechanisms were in place ? Did any other systems
share the communications network ?)
I can’t help with this one. Try Alex Kemp in CS.
It was disclosed that the DWP system received a single batched data file from
Horizon, containing all transactions over an unspecified period (typically 24
hours). How was this data file assembled ?
The Post Office counter processing functions are provided through a series of
counter applications: the Order Book Control Service (OBCS) that ascertains
the validity of DWP order books before payment is made; the Electronic Point
of Sale Service (EPOSS) that enables Postmasters to conduct general retail
trade at the counter and sell products on behalf of their clients; the Automated
Payments Service (APS) provides support for utility companies and others
who provide incremental in-payment mechanisms based on the use of cards
and other tokens and the Logistics Feeder Service (LFS) which supports the
management of cash and value stock movements to and from the outlet,
principally to minimise cash held overnight in outlets. The counter desktop
service and the office platform service on which it runs provides various
common functions for transaction recording and settlement as well as user
access control and session management.
Information from counter transactions is written into a local database and then
replicated automatically to databases on all other counters within a Post Office
outlet. The information is then forwarded over ISDN (or other communication
service) to databases on a set of central Correspondence Servers at the Fujitsu
document!7
Printed at I TIME J on [ DATE \@ "d/M/yyyy" \* MERGEFORMAT I Page 1 of 4
3)
4)
FUJ00122103
FUJ00122103
Services data centres. This is undertaken by a messaging transport system
within the Transaction Management Service (TMS). Various systems then
transfer information to Central Servers that control the flow of information to
various support services. Details of outlet transactions are normally sent at
least daily via the system. Details relating to the outlet's stock holding and
cash account are sent weekly. Details are then forwarded daily via a file
transfer service to the Post Office accounting department at Chesterfield and
also, where appropriate, to other Post Office Clients. In this respect DWP is a
Post Office Client.
It was further disclosed that the Data received could contain transactions older
than the "average age" for the file (Le. Older than 24 hours). How could this
situation arise ? (e.g. Were sub-post offices retaining data during periods of
communication failure and then sending several days transactions to Horizon
in one transmission ? Please clarify the nature of the post office counter
systems and how they interfaced with the Horizon system.)
A check is carried out at the end of the day in each Post Office Outlet, that all
counters are communicating with the “gateway” counter that communicates
with the Data Centre. Should this check be successful and End of Day record
is written to the local database identifying all records associated with that
day’s trading.
The Horizon Central systems will only process data from Post Office outlets
for which an End of Day record has been successfully replicated to the data
centre. Missing End of Day records can occur for one of two reasons:
e The End of Day record was not produced in the outlet — usually due to the
gateway being unable to communicate with one of the other counters — for
example it has failed or been switched off.
e The end of Day record has not been successfully replicated from the Post
Office outlet to the data Centre — usually due to a communications
problem.
End of Day Records will eventually be generated and communicated to the
Data Centre when the initial problems are resolved and the transactions
associated with these “late End of Day” records will be communicated to other
systems when they are available. In such cases the data transmitted to clients
(such as DWP) will be more than 24 hours old. Such transactions will have
the original timestamps from when they took place.
It appears that withdrawn order book information was passed from the DWP
system to Horizon in another single batch data file each day. How were the
data in this file processed by the Horizon system and passed on to post office
counters ? How was information about "stopped" order books passed to post
offices other than the "home" post office ?
The Order Book Control System (OBCS) software, linked to the Horizon
system was developed in conjunction with the DWP. OBCS provides details
of DWP order books on the national stop payment list, and, enables data
regarding the movement of order books, and, encashments to be captured on
their behalf. Each Horizon terminal at a Post Office counter has access to the
national stop list through OBCS, when a barcoded DWP order book is scanned
document!7
Printed at I TIME J on [ DATE \@ "d/M/yyyy" \* MERGEFORMAT I Page 2 of 4
FUJ00122103
FUJ00122103
at the Post Office counter, or the order book details are manually keyed into
Horizon at the Post Office counter. Each night, the national stop payment list
is updated from information supplied electronically from the DWP computer
centre. National stop payment list data is held centrally within the Horizon
system, and is available to all Post Offices. However, certain information from
the national stop payment list is also downloaded to individual Post Offices for
faster access; this download process is called polling. The polling of individual
Post Offices also involves receiving details of order book movements and
encashments at Post Offices, centrally within Horizon, for onward
transmission to the DWP.
Each Order Book is associated with a National Insurance Number (NINO)
which identifies the person to whom the Order Book has been (or is about to
be) issued. The Horizon Central database maintains a list of every Post Office
outlet at which that NINO has been used by the OBCS application. This
information is also held in the local outlet database.
All information received from DWP associated with withdrawn or stopped
Order Books is passed to all branches at which the associated NINO has been
used (if any).
If an OBCS transaction is carried out in an outlet and the NINO associated
with the Order Book is not found in the local database, an enquiry is made to
the Central database as to the state of all Order Books associated with the
NINO. That outlet is then registered as being associated with that NINO for
all future Order Book control information. Thus over a period of time a
number of branches become associated with each NINO.
What forms of validation were performed by the post office counter system
and Horizon system on data received about each transaction processed by
counter staff ?
Not quite sure what this means, I'll try the following.
Horizon’s documented processes relate to each Post Office outlet. They state
that at each Post Office, there are counter positions which each have a
computer terminal, a visual display unit and a keyboard and printer. This
individual system records all transactions input by the counter clerk working
at that counter position. Each clerk logs on to the system by using their own
unique password. The transactions performed by each clerk, and the associated
cash and stock level information are recorded by the computer system in a
stock unit. Once logged on, any transactions performed by the clerk must be
recorded and entered on the computer and are accounted for within the user's
allocated stock unit.
All OBCS transactions are normally initiated by scanning in the barcode from
the Order Book. From this the NINO is extracted and this is then checked in
the local database. If the NINO is found in the local database, then the local
database is then checked for any stop / withdrawal notices associated with the
Order Book than has been presented. If the NINO is not found in the local
database, then the central database is asked to associated the NINO with the
outlet and pass all order book control information associate with the NINO to
the Branch. This is then checked as before to see if there is any control
information associated with the Order Book that has been presented.
document!7
Printed at I TIME ] on [ DATE \@ "d/M/yyyy" \* MERGEFORMAT I Page 3 of 4
FUJ00122103
FUJ00122103
I assume, but am not 100% sure, that the OBCS counter application will not allow an
Encashment if there is a stop associated with a book. I seem to remember that some stops
allow the current encashment but no further ones.
Would need to check with the OBCS Counter app support. I think this was done by SSC (try
Mik Peach for a name), but since OBCS was withdrawn in May 2005, we may no longer have
much expertise in this area.
6)
7)
Which transaction between the counter system and the Horizon system were
performed in real-time and which were in batch mode ?
If the NINO is not found in the local system the enquiry for OBCS
information associated with that NINO is carried out in real time. Such an
enquiry will only happen once for any NINO in a given outlet. All other
OBCS transactions are batch.
What did the counter system and Horizon system do with any erroneous or
invalid transaction data ?
Not quite sure what this means. Please clarify.
How were post office identifier numbers (as used in the IOP transaction file)
generated and issued ?
T assume this is referring to FAD codes.
9)
Post Office outlets are identified by Post Office Ltd with a FAD Code. These
identifiers are passed from Post Office Ltd to Horizon when a Branch is first
Opened (or migrated to Horizon in many cases).
How are counter position identifiers (as used in the IOP transacton file)
generated and issued ?
When a Branch is first opened (or migrated to Horizon), Post Office defines
the number of Counter Positions required (including any Back Office
positions). These are then allocated Counter positions from 1 (which is the
gateway counter used to communicate to the Data Centre) up to the number of
counters. The Counter position is fixed and is associated with a Physical
terminal when it is installed in an outlet.
document!7
Printed at I TIME J on [ DATE \@ "d/M/yyyy" \* MERGEFORMAT I Page 4 of 4