Fujitsu
Services
Horizon - Streamline Application Interface Specification
COMMERCIAL IN CONFIDENCE
FUJ00001670
FUJ00001670
Ref.: EF/IFS/002
Version 1.1
Date: 07/08/2002
Document Title:
Document Type:
Release
Abstract:
Document Status:
Originator & Department:
Contributors:
Horizon - Streamline Application Interface Specification
Application Interface Specification (AIS)
BI3 or later
This document defines the interface between Fujitsu Services
(Pathway) Ltd and Streamline Merchant Services to support
EFTPoS Transactions.
It also covers the interface from Fujitsu Services (Pathway) Ltd to
Post Office Ltd to define the mapping of counters onto MIDs and.
TIDs.
Approved
David Hollingsworth
Peter Wiles
Tom Northcott
Klaus Léffler
Approval Authorities
Name
Position — I Signature
Date
Peter Jeram
Programme Director, Fujitsu
Services Pathway
Gill Jackson
Development Director, Fujitsu
Services Pathway
Tony Drahota
Manager ASD, Fujitsu
Services Pathway
Torstein Godeseth
Post Office Ltd
Andy Harvey 7
Manager, National Accounts,
Streamline Merchant Services
1
Descriptions of internal processing provided as background material (which are highlighted as described in section 1.1)
are not covered by the Streamline sign-off. In particular, Chapter 6 describes the interface between Fujitsu Services
(Pathway) Lid and Post Office Lid and so is also not covered by the Streamline sign-off.
© 2002 Fujitsu Services (Pathway) Ltd
File: EFIFS002_DCS_Streamline_AIS.doc
COMMERCIAL IN CONFIDENCE
Page 1 of 37
Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Chapter 0 -
Document Control
0.1 DocuMENT HISTORY
Version Date Reason for Issue SE . Associated CP/
PinICL Nos.
0.1 25/03/2002 I First Draft issued for comment and input to a None
I_number of outstanding questions.
0.2 08/04/2002 _ Incorporating initial comments from internal None
distribution
0.3 17/05/2002 I Incorporating further comments from internal None
distribution and external distribution
0.4 14/06/2002 _ Incorporating further comments from internal None
distribution and external distribution
0.5 27/06/2002 I Incorporating comments from review on 21/06/2002 I None
0.6 29/07/2002 I Incorporating further comments from internal None
I distribution and external distribution
1.0 02/08/2002 I Re-issued for Approval None
4.1 08/08/2002 I Comment removed as a result of late commercial None
I feedback within Fujitsu Services
2.0 12/08/2002 ___ Re-issued for Approval None
0.2 Review DETAILS
Review Comments by:
Review Comments to: Originator & Klaus Loffler, Programme Directorate
Mandatory Review Authority 3 Name
Customer Requirements Mike Chawner
ASD Tony Drahota
Customer Services Richard Brunskill
APDU Development Mark Taylor
IPDU Development Peter Dreweatt
Test Team Leader Mike Deverell
PTU Mike Deverell
Post Office Ltd Barry Forrest
Torstein Godeseth
Streamline Paul Whitmore
Optional Review/Issued for Information
IPDU Clare Keane
Nial Finnegan
Brian Muir
Mark Ascott
APDU Dave Johns
Rex Dixon
Tom Northcott
ASD Peter Wiles
Geoffrey Vane
Mark Jarosz
Programmes Klaus Loffler
Post Office Ltd Bob Booth
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 2 of 37
File: EFIFS002_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
[Streamline [Annie Roberts ]
(*) = Reviewers that returned comments
0.3 ASSOCIATED DOCUMENTS
[Reference [Doc \Vers- [Date [Title Source
jon
[APACS] 17 1/3/02 (Standard 30- Specification foran IAPACS
(Authorisation Terminal
(BR) (CR/FSP/010 IEFTPoS Statement of Business Pathway
Requirements
[CDMV] ISU/SPE/021_ [8 (Oct 2001 [Card Details Specification — Streamline
MasterCard, Visa Cards (including
[Maestro & Electron)
[CDSS] SU/SPE/022 {11 (Oct 2001 [Card Details Specification — Streamline
(Switch, Solo Cards
DC} ISU/SPE/028 13. Sep 2000 Technical Specification for the Streamline
[Delivery of Transaction Data via
Direct Communication
[DTO] ISU/PRP/005 1.2 11 1/6/02 [Proposal for the Data Take On Streamline
Approach for The Post Office
Limited
EMIS} ISU/SPE/024 10 fAug 2001 Technical specification for [Streamline
IElectronic Management
Information Service (EMIS)
(MFMV]} SU/SPE/027 [2.1 lan 2002 [Merchant Functional Specification Streamline
MasterCard, Visa, Switch Cards
MFS] ISU/SPE/023 1.0 (April 1997 IMerchant Functional Specification IStreamline
t Solo Cards
[OLA] [Operational Level Agreements [TBS
(POTIS} TIF S/008 [Pathway to Post Office Technical [Pathway
Interface Specification
[RECREP] INB/PRO/002 8.0 0/5/02 Network Banking Reconciliation IPathway
land Incident Management
[SDs] IEF/SDS/001 System Design specification for [Pathway
he Debit Card Service (DCS)
Tis] IEF/IFS/001 Technical Interface Specification [Pathway
Horizon to Streamline
(TS) ISU/SPE/029_ 2.3 29/07/02 ITechnical Schedule for Streamline
implementation as Bulking Retailer)
[Phase 1 - POS Functionality / auto}
jauthorisation / data delivery
Unless a specific version is referred to above, reference should be made to the current
approved versions of the documents.
0.4 ABBREVIATIONS & DEFINITIONS
0.4.1 Abbreviations
Abbreviation I Definition
[Al Authorisation request returned from the MA to the Horizon Counter
{cl Confirmation message
[Co] Confirmation message indicating that the Outcome of a transaction differs from that
in the [A] received by the Counter (or that no [A] was received)
© 2002 Fujitsu Services (Pathway) Ltd
File: EFIFS002_DCS_Streamline_AIS.doc
COMMERCIAL IN CONFIDENCE Page 3 of 37
Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
{RI Request message
AIS Application Interface Specification; standard document type required for each
external interface to the Horizon system
APACS Association for Payment Clearing Services
Dcs Debit Card System. The functionality to be provided by Horizon to support EFTPoS
Transactions
DCSM DCS Management (Server) [was EFT Management Server]
DRS Data Reconciliation Service
EFTPoS Electronic Funds Transfer at Point of Sale; new Horizon Method of Payment likely to
be introduced during the same development timescale as NBS. Now referred to as
DCS (qv)
EMIS Electronic Management Information Service
FAD Finance Accounts Division, part of Post Office Ltd
FTMS File Transfer Management Service, Horizon process that provides configurable file
transfer services between Horizon and Post Office Ltd’s Clients. Services available
include data compression and encryption
FTP File Transfer Protocol
ITU International Telecommunication Union. Standards body responsible for the X.25
protocol (among many others)
MA Merchant Acquirer
MID Merchant ID
MSU Management Support Unit (within Fujitsu Services Pathway Customer Services)
OBC ‘Operational Business Change (procedures for change to Post Office Ltd Reference
Data)
OTR Originators Transaction Reference
PIN Personal Identification Number
RDS Reference Data System; Post Office Ltd system that provides a Reference Data
feed to Horizon and other systems
RID Registered Identifier: identifies the organisation to which a range of TIDs has been
allocated.
SOLVE /PFG I Solution for On Line Verification / Payment File Generator
A Retail Logic application that takes transaction files that have accumulated over a
certain period (normally a day) and converts them into a Merchant-Acquirer-specific
format, and prepares them to be sent to the MA for settlement.
SOLVE / SE Solution for On Line Verification / Stores Environment
A Retail Logic application that processes credit / debit card-based transactions
initiated at an Electronic Point of Sale terminal
TID Terminal 1D
TIP (Post Office Ltd’s) Transaction Information Processing system
X.25 ITU recommendation for Packet Switched networks
0.4.2 Definitions
The following terms, when capitalised as here, have specific meanings as indicated.
Term Definition
Authorisation I On-line Authorisation [A] response by MA to on On-line Request. It can have a
value of “Approve”, “Decline” or “Refer”
A response of “Refer” will be treated as a “Decline”
Business Rules governing the conduct of a Transaction which are contained within Reference
Rules Data
Campus ‘One of two data centres installed by Fujitsu Services Pathway in Bootle and Wigan
Each can handle the entire Horizon workload
Card Issuer The institution that issues a payment card to a Cardholder.
Confirmation I Confirmation [C] message sent from the Counter in near time to the Campus
stating the outcome of a DCS transaction:
Counter Counter PC installed in a Post Office Outlet
Counter An application resident within the Counter that contains the business logic
Application controlling the dialogue with the Clerk, or other business specific functions on the
Counter (such as End of Day processing)
Counter Clerk I Person working in an Outlet and operating a Counter
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 4 of 37
File: EFIFS002_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Customer ‘A member of the public transacting, or seeking to transact, business with Post
Office Ltd through any of the Services
Data Service provided by Fujitsu Services Pathway to Post Office Ltd which matches
Reconciliation I transaction flows from Counter and DCSM, and reports on these to Post Office Ltd
Service (DRS)
DCS Agent Hardware platform on which SOLVE / SE and its controlling processes run
Server
Debit Card A plastic payment card which is linked to a bank or building society account and
used to pay for goods and services by debiting the holder's account. Debit cards are
usually combined with other facilities such as ATM and cheque guarantee functions
Decline Verdict supplied by the Fl, Cl, MA or by the Counter Clerk, such that a request for a
withdrawal (or deposit) of funds or payment by debit card is denied
Electronic The technology and practice of making payment for goods and services by means
Funds of EFT initiated at the point where the goods or services are purchased. Can utilise
Transfer at Credit, Debit or House Cards for the transfer of funds.
Point of Sale
(EFTPoS)
Fallback Where a system has attempted to go On-line but failed and has the ability to
proceed with the transaction in an Off-line manner — typically with limits on the
transaction value
Horizon Name that encompasses the totality of the systems provided by Fujitsu Services
Pathway to support the automation requirements of Post Office Outlets
Merchant A financial institution that undertakes the total business and technical relationship
Acquirer with a merchant at any particular outlet on behalf of a card scheme. This includes
marketing the card scheme, supporting the merchant and settlement of
transactions.
Method of The form of payment recorded against a Transaction involving a Customer
Payment
‘On-line Where a system attempts to communicate with another system — typically the
Counter seeking immediate authorisation from a Fl, MA or Cl
Operational ‘A non-contractual agreement between Fujitsu Services Pathway and Post Office Ltd
Level on the nature and quality of specific elements of a service (e.g., Interface
Agreement Agreement for Problem Management (CS/IFS/009))
Outlet Post Office location with one or more Counter PCs installed as part of the Horizon
programme
Payment File I Files produced by collating transaction files for presentation to the Merchant
Acquirer for settlement of funds
Receipt A printed record of the Transaction at the Outlet
Reconciliation I Ensuring the financial integrity of transactions across service boundaries
Reference Configuration data and parameters for use by the rest of the system, within the
Data Horizon Programme
Request Request message [R] sent On-line from Counter to MA initiating a DCS dialogue
Reversal This is used in two ways:
+ Atthe counter it is a Transaction that nullifies a specific previous Transaction
that has been completed (committed) in a previous Customer Session, subject
to business rules (e.g. time limits, previous receipt). As far as the interface to
the MA is concerned this is treated as a Refund.
« At the interface to the MA, it is a transaction that nullifies the previous
transaction. It may be generated implicitly (by reusing the previous
transaction’s sequence number) or explicitly as a result of a counter not
receiving a response or the clerk cancelling the confirmation
Settlement This is used in two different ways:
* — Settling a Customer Session where the balance of the session is reduced to
zero and the appropriate cash (and other items such as cheques, tokens,
stamps etc) is exchanged between the Customer and the Clerk
«¢ Settlement between Post Office Ltd and a MA where an agreement is made as
to the aggregate value of transactions for a given period (probably a day)
Settlement This is set by the MA and is part of the commercial terms. It is based on the day the
Date transaction file is presented for processing. Post Office Ltd will receive the funds on
the day of processing as long as the transaction file is delivered by 2am. The
Settlement date is not included in authorisations from the MA.
It is only known when the EMIS file is received (ie when the [C4] is produced), but
can be anticipated following transmission of the Payment file (and hence in the [S]
message)
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 5 of 37
File: EFIFS002_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Stock Unit Collection of goods and cash that is assigned to a Counter Clerk and for which he
or she is responsible while logged-in to the Counter
Transaction A recorded and auditable instance of business activity, involving service provision
or Stock movement across organisational or service boundaries
0.5 CHANGES IN THIS VERSION
0.5.1 Changes in Version 2.0
Change marks removed and status changed to Approved.
0.5.2 Changes in Version 1.1
Comment on system shortfall in section 3.3 removed.
Document classification changed to COMMERCIAL IN CONFIDENCE.
Changes (other than to page headers and footers) are marked in red with deletions in-
strikeout.
0.5.3 Changes in Version 1.0
Minor corrections in light of comments.
= Now reference version 2.3 of [TS] (also section 4.2 updated to reflect the fact that
Company Identifier is now included in [TS])
= Internal Horizon Definition of Reversals in section 0.4 now “greyed out”.
= Discussion on “greying out” text has been moved from section 2.1 to section 1.1
since it now applies to more than just Chapter 2.
= Footnote added to Table 2 — Setting of standard APACS30 fields.
Comment added on liability due to system shortfall added to section 3.3
2 paragraphs of section 3.4 “greyed out”.
‘cardholders’ Financial Institution’ replaced with Card Issuer in section 3.5.3
Spurious “ICL” removed from section 6.5.
They are not specifically marked in the document
0.5.4 Changes in Version 0.6
This version is provided for a limited informal circulation to confirm that changes are
acceptable prior to issuing as version 1.0 for approval.
Changes in response to comments received. All changes are marked in a red font (like
this).
Deleted text is highlighted in green like this!
Sections not subject to Streamline sign-off are now highlighted in grey like this.
References to JCB cards removed, since they are not supported by DCS.
DCS redefined as Debit Card System (rather than Debit Card Service) to align with the
contractual position.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 6 of 37
File: EFIFS002_DCS_Streamline_AlS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
All relevant information from [DTO] is now included in this AIS. The role of [DTO]
is now purely to define the interface between Post Office Ltd and Streamline (which is
outside the scope of this AIS).
0.5.5 Changes in Version 0.5
Changes in response to comments received. All changes are marked in a red font (like
this).
Various minor clarifications of the text.
Chapter 6 has been restructured to clarify the differences between the initial take-on of
MIDs and TIDs and ongoing Operational Business Change. It also now includes all
the relevant text from [DTO].
A number of changes have been made to Chapter 2 & Chapter 3 to separate the
description of the processing within Horizon from the interface to Streamline. All such
internal processing descriptions are now in Chapter2 and may be ignored by
Streamline.
0.5.6 Changes in Version 0.4
Changes in response to comments received. All changes are marked in a red font (like
this).
Various minor clarifications of the text.
Table added to section 3.4.2, justifying the setting of the Timeout to 18 seconds.
Section 4.3 restructured to distinguish between fatal and non-fatal errors.
Actual TID values included in section 6.2.
Section 6.3.3 expanded to provide more detail of this interface and to make it clear
that it covers both the initial delivery of MID / TID mappings and their ongoing
maintenance.
0.5.7 Changes in Version 0.3
Changes in response to comments received. All changes are marked in a red font (like
this). The document has been reformatted. Format changes have not been explicitly
marked.
The term EFTPoS has in general been replace by DCS to reflect the fact that the
service to be provided by Horizon is now the Debit Card Service.
Much of the Terminology in section 0.4 has been removed since it was not actually
referred to in the document.
All outstanding drafting notes within the text are now listed in section 0.6.1 with
details of how they are to be resolved.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 7 of 37
File: EFIFS002_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
0.5.8 Changes in Version 0.2
Cross reference to APACS 30 added in 0.3
Timeout values in Section 3.3.2 corrected
Changes to reversal handling logic documented
Various typographical errors corrected and minor clarifications added in response to
initial Fujitsu Services Pathway comments
0.6 CHANGES EXPECTED
0.6.1 Outstanding Design Issues
A number of areas of in the document require clarification (marked in yellow highlight
in this working draft).
The following is a list of outstanding Issues in the document :-
(Section [Issue [Action Jon ate
3.3 Streamline consider the proposed IThe behaviour will be as statedIFS (KL) IA
fail-over behaviour to be for the initial release and will
junacceptable be reviewed later.
Table 1 —Outstanding Issues
0.7 CONTENTS
0.7.1 Table of Contents
CHAPTER 0 - DOCUMENT CONTROL...
0.1 DocuMENT HIsToryY. 2
0.2 REVIEW DETAILS. sesiannnnentenee se ss ssssnsennnnnenenee rnseneeeD
0.3 ASSOCIATED DOCUMENTS. 3
04 ABBREVIATIONS & DEFINITIONS 3
0.4.1 Abbreviations...
0.4.2 Definitions.
0.5 CHANGES IN THIS VERSION. 6
Changes in Version 2.
Changes in Version 1.
Changes in Version 1.0.
Changes in Version 0.6..
Changes in Version 0.5.
Changes in Version 0.
Changes in Version 0.
Changes in Version 0.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 8 of 37
File: EFIFS002_DCS_Streamline_AlS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
0.6 CHANGES EXPECTED.
0.6.1 Outstanding Design Issues.
0.7 CONTENTS.
0.7.1 Table of Contents.
0.7.2 Table of Figures.
0.7.3 Table of Tables...
CHAPTER 1 - INTRODUCTION.........c00e0000 anssnnsensenseneen
11 PURPOSE. ia
1.2 READERSHIP, 12
13 RELATED DOCUMENTS ....os:snnnsnmnnnnnnninnnnnnnnn ee
CHAPTER 2 - SCOPE
21 OVERVIEW OF DCS CAPABILITY WITHIN HORIZON. snes . sovneneenne 3
211 Transaction Authorisation.
21.2 Transaction Confirmation.
2.1.3 Reversal Transactions..
214 Card Impound Data Flow:
21.5 Payment File Generation & Transfer.
2.1.6 Reconciliation...... .
pS ivA Reference Data Management...
218 MID / TID Management...
2.2 TRANSACTION SEQUENCING AND LIFECYCLE. 17
221 MID /TID Set Up...
2.2.2 Authorisation Transaction Operatio
2.2.3 Payment File Confirmation Record.
2.2.4 EMIS Reconciliation File Record.
CHAPTER 3 - TRANSACTIONAL INTERFACE — REQUEST / AUTHORISATION..........0..20
3.1 GENERAL, 20
3.2 SUPPORTED TRANSACTION & MESSAGE TYPES. 20
3.2.1 Authorisation request.
3.2.2 Authoriser response
3.3 TRANSACTION & TERMINAL IDENTITY AND SEQUENCING......000.:snnmnnmnnnnsnnnnnnnnnnes 22
3.4 TRANSACTION DUPLICATES AND TIMEOUTS.....:::s:nninnnninnnnnnnnnnnnnnnnennennnnnnnne 23
3.4.1 Duplicates.
3.4.2 Timeou
3.4.3 Unsolicited Messages
3.5 SYSTEM QUALITY ATTRIBUTES.....00:csnnnnnennnnnnnnieennnns . sneer 24
351 Security.
3.5.2 Scalability
3.5.3 Resilience and Fail-c OVER... 24
CHAPTER 4 - PAYMENT FILE - BATCH INTERFACE... wesessessneees 26
41 PAYMENT FILE GENERATION. 26
© 2002 Fujitsu Services (Pathway) Ltd © COMMERCIAL IN CONFIDENCE Page 9 of 37
File: EFIFS002_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
42 TRANSFER TO THE MA...
43 ERROR HANDLING.
4.3.1 Fatal Errors..... .
4.3.2 Transaction Errors...
44 SYSTEM QUALITY ATTRIBUTES. 28
4.4.1 Security.
4.4.2 Scalabili
4.4.3 Resilience an
‘ail-ove
CHAPTER 5 - RECONCILIATION REPORTING - EMIS BATCH INTERFACE.......cc.sesse000 29,
SL SETTLEMENT REPORTING... seststntntnenuetueueuens sssnnennennensens severe 29.
5.2 SYSTEM QUALITY ATTRIBUTES. 29
S.2.1 Security.
5.2.2 Scalabili
5.2.3 Resilience and Fail-over.
CHAPTER 6 - MANAGEMENT INTERFACE - MIDS & TIDS...
61 GENERAL, soennntntnnnennnnneeen senninennnnnsennnnsenn . conneee 31
6.2 INITIAL MID / TID ALLOCATION & SET-UP. 31
63 MID / TID CHANGE MANAGEMENT, 32
6.3.1 TID change:
6 MID changes.
MID / TID Change Reporting
6.4 SYSTEM QUALITY ATTRIBUTES. 34
6.41 Security.
6.4.2 Scalabili
6.4.3 Resilience and F
jilover.
65 FILE FORMAT FoR MID / TID ALLOCATION AND CHANGES. a 34
6.5.1 Derivation of MID / TID Data..
6.5.2 Business Triggers for MID / TID Management.
0.7.2 Table of Figures
Figure 1 — DCS High Level Data Flows.
Figure 2 Horizon-Streamline message flows
Figure 3 — Authorisation Request Message Sequence.
0.7.3 Table of Tables
Table I —Outstanding Issues.
Table 2 ~ Setting of standard APA
Table 3 —Streamline Response Times.
Table 4 —Numbers of TIDs and MIDs 1
Table 5 — Mapping of Reference Data for Streamline MID / TID Management Records.....35
Table 6 ~ Meaning of Instruction Codes... .
Table 7 ~ OBC Triggers for MID / TID Change Management... 37
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 10 of 37
File: EFIFS002_DCS_Streamline_AlS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 11 of 37
File: EFIFS002_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
Fujitsu
Services
FUJ00001670
FUJ00001670
Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Chapter 1 -
Introduction
1.1
PURPOSE
As part of the Horizon service capability, EFTPoS functionality is being introduced to
support the use of certain debit card schemes as a method of payment for products
transacted across the Post Office counter network. The chosen Merchant Acquirer to
provide this service for Post Office Ltd is Streamline Merchant Services part of The
Royal Bank of Scotland Group (hereafter called Streamline).
The Horizon Debit Card system makes use of the Retail Logic SOLVE product, which
has previously been accredited by Streamline for EFTPoS use in accordance with the
relevant APACS standards.
This document defines the application level interfaces between the Streamline domain
and the Horizon domain to support the Horizon Debit Card system.
An overview of the architecture of the Horizon Debit Card system is given in the
diagram below.
1 7-5 Individual Card Issuers I
ci cl2 ci3 4 cl4 I Operational I
Domain’
srchant Acquirer!
Streamline (MA) Operational ;
Domain
Transaction POCL}
Information I Operational ;
Processing Domain’
Interfaces specified __yI
in this document 1]
MID/TID Reference
Processing I IData System
: Pathway I
Pathway Data Centres Operational I
Domain:
Outlet
Outlet approx. 17,500 Outlets
Fra nontomen > Till
Hf I approx. 38,000 Counters
Counters Counters
Counter transactions (card based only) H
Figure 1 — DCS High Level Data Flows
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 12 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
= an overview of the end-end message flows between the major components to
provide the context for the Horizon - Streamline interface. This is the subject of
Chapter 2.
= a specification of the various application message and file flows between Horizon
and Streamline. These are the subject of Chapter 3 - Chapter 6. These Chapters
make extensive reference to external industry specifications which are supported by
Streamline and the Retail Logic software
This document does not define the physical interconnection arrangements between
Horizon and Streamline to support the above application interfaces; this is the subject
of [TIS].
The document is written essentially as a commentary on the required interpretation of
the cross-referenced specifications. These cross-referenced documents contain the
formal specifications to support the application interface between Horizon and
Streamline. It also defines the document baseline against which DCS will be built and
any exclusions.
Some parts of this document are not part of the formal specification of the interface
and so are not subject to sign off by Streamline. Specifically the following parts are
excluded from Streamline’s sign-off:
Part of the Definition of Reversals in section 0.4
2.1 - Figure 2 — Horizon-Streamline message flows
2.1.4
2.1.6 ‘Within the DRS...settlement process with the MA.”
2.1.7
2.1.8
2.2.1
2.2.2.3 Ist paragraph
3.4.2 3" and 4" Paragraph
Chapter 6
To make it clear these parts are highlighted in grey (as in this paragraph) to indicate
this other than in Chapter 6 which has been left un-highlighted for clarity.
1.2 READERSHIP
This document is intended for application developers concerned with development of
the DCS capability between Horizon and Streamline.
1.3 RELATED DOCUMENTS
See section 0.3 for a full list of referenced documents
In addition a number of external specifications from the APACS organisation may be
referenced for further information on the interface to the Merchant Acquirer.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 13 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Chapter 2 -
Scope
2.1 OVERVIEW OF DCS CAPABILITY WITHIN HORIZON
The diagram following illustrates the main components of the end to end message and
file flows and in particular how they operate across the Streamline — Horizon interface.
= Merchant Acquirer =
Reversal
Authorisatio
EMis
Streamline
Horizon
As DCS Manager
SolvelSE H MID & TID Mgt aw ol]
r SoWve/PFG
[ a
locs a Servet ‘MIDI ] ¢ Post Office Ltd
ails}
Sessa!
Counter PC > Confirmation}
I
Figure 2 — Horizon-Streamline message flows
2.1.1 Transaction Authorisation
DCS enables Counter Clerks in Outlets to accept debit cards as an additional Method
of Payment during a Customer Session. A single card may be used for part or all of the
balance outstanding at the Settlement point within the session.
The Customer hands his or her payment card to the Clerk, who swipes it through the
standard Counter magnetic swipe card reader. If the card is of a type supported by
Post Office Ltd, DCS will seek authorisation from the MA (Streamline). This is done
using a Horizon Request [R1] message. Two types of transaction are supported:
= Purchase (customer present), no cashback
= Refund (customer present), when used to settle one of the following Horizon
reversal transaction types - Existing Reversal, New Reversal
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 14 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
The authorisation request is passed through to a DCS Agent Server, located within the
Horizon Campuses, which supports the Retail Logic SOLVE / SE software. The DCS
Agent Server converts the message into APACS 30 message format and communicates
with the MA, which may authorise the transaction (or decline it) using its own
information, or may refer it to the Customer’s Card Issuer. The result of the
authorisation is passed back by the MA to the DCS Agent Server and thence to the
Counter ([A3] message). The MA may also return a response requesting that the clerk
should contact the MA. SOLVE / SE will be configured to treat this as a Decline.
2.1.2 Transaction Confirmation
The final outcome of the transaction is recorded at the counter as a Confirmation [C]
message and this is transferred to the Horizon Data Reconciliation Service from
whence it is forwarded to the DCSM to support payment file generation (in addition to
supporting various reconciliation checks). Payment file generation is done using the
SOLVE / PFG product.
2.1.3 Reversal Transactions
If the authorised transaction is not completed at the counter a reversal transaction will
be generated at the counter. There are three circumstances under which this will occur:
= A transaction is declined by the counter clerk due to failed signature or card
verification
= Transaction timed out at the counter with no response received (due to message
loss either internal /external to Horizon, or no response received from the MA)
= During counter recovery after failure, where no completed transaction
confirmation exists within the local message log an explicit reversal request is
normally generated
Note that in such a case, although the customer may not be present at the time the
reversal is actually generated, it is acceptable to set the “Customer Present” flag in
the Reversal request should it eventually be sent to Streamline.
Reversal transactions are generated at the counter by the writing of a Horizon [CO]
message. This is passed to the DCS Agent Server, which will then generate an Explicit
Reversal Transaction, which is then mapped to the appropriate APACS30 message to
reverse the previous authorisation from that terminal.
Note that in many cases such Explicit Reversals will be generated where the original
Request that is being reversed had not been passed through to Streamline. However in
that case SOLVE / SE will reject the Explicit Reversal resulting in no Reversal being
passed across the interface to Streamline.
2.1.3.1 Explicit and Implicit Reversals
There are 2 types of Reversal:
= Implicit Reversal
This is a standard APACS 30 authorisation request message which is also used to
advise the MA that an authorisation response for a previous request has not been
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 15 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
received by the highest level component which handles the external APACS 30
interface with the MA. An implicit reversal is indicated by reusing the same
APACS 30 message sequence number for the current transaction as that used for
the previous request (i.e. the next request for the same TID).
= Explicit Reversal
A specific APACS 30 message type, containing the amount, card number etc. for
which an on-line authorisation was requested by the POS terminal, a response
received by the POS terminal / store controller / host system, but not actually used
2.1.4 Card Impound Data Flows
Card impound operations may be initiated by the Card Issuer (or Streamline) in
response to a transaction [R] from the counter including card details. The impound
instruction will be included as a message element within the [A] message returned by
Streamline. The impound instruction received by the DCS Agent Server will be
inserted as a field in the [A] messages as a “decline and retain card” response for
action by the counter application.
The [C] message written at the counter will include a field for reporting the results of
the clerk instruction — normally confirming that the card has been retained, but
exceptionally indicating that the clerk has not retained the card. This information is not
returned to Streamline but is retained for internal Horizon use.
For DCS, business rules will state that card impounds should only be carried out in
response to such an instruction included in the [A] message. (EFTPoS rules
additionally permit card impounds as a result of a telephone referral, but telephone
referrals are not supported for DCS Release 1 in Horizon and any such request will be
interpreted as a “decline”.)
Note that a card should not be retained unless the clerk is explicitly instructed to do so.
2.1.5 Payment File Generation & Transfer
Transaction confirmations from the counter are processed by the SOLVE / PFG and
this settlement information is passed via FTP to Streamline at intervals. Any reversals
generated from the counter will be netted out before they are passed to SOLVE / PFG.
The Payment file is generated by the DCSM system for processing by the MA in
accordance with the Streamline formats specified in [DC].
A file level acknowledgement is provided (by return file). (See section 4.2 for details).
2.1.6 Reconciliation
The records from the EMIS files received from Streamline are forwarded to the
Horizon Data Reconciliation Service (DRS).
Within the DRS transactions are subjected to a four way matching process, using:
= Confirmation message from the counter
= Expected payments sent from DCSM to MA
s__EMIS confirmation record received from the MA.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 16 of 37
File: EFIFS002_DCS_Streamline_AlS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
= Transaction Confirmation message generated by Horizon for reporting to the Post
Office Ltd TIP system following receipt of the outlet’s End of Day message.
Discrepancies are reported to Post Office Ltd and the Pathway MSU by Fujitsu
Services for resolution in support of the Post Office Ltd settlement process with the
MA. This is described further in [RECREP].
Through the transaction and reconciliation cycle, individual transactions are identified
by the unique Horizon Transaction Id allocated at the counter. The Horizon
Transaction Id (in a compressed form) is submitted to Streamline within each
transaction record included within the Payment File as the Originator’s Transaction
Reference (OTR). However there is no requirement to be able to look up transactions
based on this compressed form.
2.1.7 Reference Data Management
The operation of the system is configured by the use of Reference Data of various
types. In particular, Reference Data, provided by the Post Office Ltd RDS service, is
used to determine the range of cards supported by the Horizon system and the valid
operations supported against the various classes of card.
There are two levels at which card ranges are managed:
= Wide Card Ranges: these are defined in the card scheme documents (ie refs
[CDMYV] and [CDSS]) and subsequent bulletins roughly every 6 months
This is primarily a paper-based approach
= Narrow Card Ranges: these are define and updated via EMIS 2 to 3 times per
week
This is an automated approach
To reduce the level of change, Wide Card Ranges will be used.
Note that the same card may be valid for both DCS and Banking transactions and the
particular use of the card will be determined by the point in the counter activity
dialogue at which the card is swiped (or manual entry selected). Banking transactions
cannot be initiated in session settlement, whereas DCS transactions can only be
initiated during session settlement.
The card related characteristics of the Card Detail Specification documents require to
be reflected in this Reference Data to control the behaviour of the DCS counter
application.
Similar Reference Data is also required to configure the SOLVE / SE product,
however this will not be automatically updated. This means that the processes for
amending card reference data must take this into account. Specifically it is Post Office
Ltd’s responsibility to raise a Change Request on Horizon at the appropriate time
should any changes occur to card schemes that impact the SOLVE / SE configuration.
2.1.8 MID / TID Management
Each DCS transaction carries the identity of the Merchant and the Terminal submitting
the request.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 17 of 37
File: EFIFS002_DCS_Streamline_AlS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Ranges of Merchant Identifiers (MIDs) and Terminal Identifiers (TIDs) for Horizon
use are allocated for use by Pathway during system set-up phase, prior to their use in
live system operation.
The allocated MID / TIDs are explicitly mapped to Horizon outlet / counter device
identities by the Horizon DCSM and are made available to the DCS Agent Server
software for use in individual transactions with the MA. NB a TID is not mapped to a
“physical” terminal but effectively to that counter position. Ie when a terminal is
changed (for example following a hardware failure), its replacement doesn’t use a new
TID.
The DCS Agent Server software maps individual Horizon transactions and Horizon
device addresses (FAD code and Node within FAD) into the appropriate MID / TID
and transaction sequence number in accordance with the APACS specification.
A change management system is operated by Horizon and this supports changes to the
MID / TID usage mappings as details of the Horizon estate configuration change
(covering new outlets, closed outlets, additional or removed counter positions within
outlets).
A set of files specifying the Horizon to MID / TID mappings in use is made available
to Post Office Ltd (who are responsible for passing this on to Streamline). This is used
to supply the initial set of mappings on commencement of the DCS.
A daily “changes” file will also be produced as a result of the Horizon Operational
Business Change process (OBC). If there are no Operational Business changes on a
given day, then a NULL file will be produced.
Chapter 6 describes this interface in more detail.
2.2 TRANSACTION SEQUENCING AND LIFECYCLE
The sequencing of operations across the Horizon Streamline Interface is as follows:
2.2.1 MID / TID Set Up
Prior to the operation of DCS at any Horizon outlet counter / MIDs and TIDs are
allocated and mapped against the Horizon outlet and counter (node) addresses.
These mappings are notified to Streamline prior to the submission of any DCS
transaction from a specific MID / TID source in Horizon and will remain consistent
across the transaction lifecycle — authorisation request, payment file, EMIS file.
The Counter application will print the MID on the DCS Outlet and Customer receipts.
The MID will be returned to the Counter as part of the authorisation response [A3]
originated from the DCS Agent Server.
2.2.2 Authorisation Transaction Operation
2.2.2.1 Request
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 18 of 37
File: EFIFS002_DCS_Streamline_AlS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
A DCS transaction across the Horizon - Streamline Interface commences with a
Request for Authorisation from Horizon. This is sent as a standard APACS30
message generated by SOLVE / SE.
2.2.2.2 Authorisation
For each request Streamline will respond with an authorisation message, confirming,
declining or referring the request. A Referral will be treated as a Decline.
Where a declined authorisation is returned and processed by the counter application
the Streamline transaction is complete at this point (i.e. no further message interaction
with Streamline will occur). Note that where the declined response is not received at
the counter, a reversal may be generated.
2.2.2.3 Confirmation
Horizon always generates an explicit final outcome message [Confirmation] at the
counter for the Horizon transaction, irrespective of the type of authorisation response
(approve / decline) or whether a counter triggered reversal was required.
When an approved authorisation response is returned three outcomes are possible:
= Where the transaction completes normally this will result in a Payment File Record
being generated and sent on the Payment File Interface (see section 2.2.3).
= Where the transaction is locally declined due to signature or card verification
failure an explicit transaction reversal request is sent to the DCS Agent Server and
then passed on to Streamline. This is triggered by a [CO] message sent from the
counter prior to writing the final transaction outcome [Confirmation]. Such
messages are sent from the DCS Agent Server to Streamline using normal message
sequencing.
= Where the Authorisation message is not received by the counter PC the transaction
status at the MA is indeterminate. In this case the counter generates a [CO]
message and the DCS Agent server will send an explicit reversal message to
SOLVE / SE, which may result in an explicit reversal being sent to Streamline (see
section 2.1.3).
2.2.3 Payment File Confirmation Record
Where the transaction result is a completed, authorised (confirmed) transaction an
equivalent record is generated within the Payment File sent from Horizon to
Streamline. Under normal system operation this will be in the overnight window of the
day following the counter transaction.
However, under failure conditions this will be deferred until communications is re-
established between the Post Office outlet and the Horizon central systems. Failure to
deliver a payment file record for the transaction may result in the authorisation timing
out within the MA and removal of the funds ring-fence in the target account. (Ring-
fencing of funds lasts a set time — a minimum of 3 working days and usually about 7 -
10 days.)
Acknowledgement of receipt of the payment file is at file level; details are provided in
section 4.2
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 19 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
2.1.4 EMIS Reconciliation File Record
Following receipt of the payment file and processing of the transaction record,
Streamline will generate an equivalent record in the EMIS file transferred back to
Pathway. This EMIS record contains reconciliation information used by the Horizon
Data Reconciliation System (DRS).
Failure to return an EMIS record corresponding to a specific payment file record will
result in a Horizon reconciliation exception and a manual investigation of transaction
status.
This investigation will be initiated by Fujitsu Services Pathway’s MSU and carried on
in consultation with Post Office Ltd.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 20 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Chapter 3 -
Transactional Interface — Request /
Authorisation
3.1 GENERAL
This interface supports message flows between the SOLVE / SE software and the
Streamline Merchant Acquirer transaction authorisation system.
The interface is based upon APACS30 message exchange as defined in [APACS].
The SOLVE / SE product is already certified by Streamline as compliant with this
standard and therefore no detailed specification of the APACS30 message formats is
required in this AIS.
The commentary following identifies how the interface is operated in the context of the
Horizon system.
3.2 SUPPORTED TRANSACTION & MESSAGE TYPES
The following diagram identifies the transaction types and message sequence to be
used between Horizon and Streamline.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 21 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
Fujitsu
Services
FUJ00001670
FUJ00001670
Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
3.2.1
Horizon APACS 30
Agent a
[R1] Authorisation Request
Counter SOLVE Streamline
/SE (Purchase or Refund)
Timer Timer
[A3] Authorisation Response
{Co}
(if verification failure) Explicit Reversal
(Timer
[A3 Decline - host timeout] Expiry)
Implicit reversal I
(Timer
Y Expiry) [CO - counter timeout]
Explicit Reversal I
Complete
transaction (¢1 Confirmation]
{___~_ "> to DRS & DCSM
Figure 3 — Authorisation Request Message Sequence
Authorisation request
The following transaction types are generated by the Horizon system:
= Purchase request (customer present)
= Refund request (customer present)
= Purchase (explicit) reversal
= (Implicit reversal see discussion in section 2.1.3.1)
Transactions are initiated by the presentation at the counter of a magnetic stripe card in
conformance with ISO 7810-7813, identified as valid for DCS transactions within the
Post Office Ltd supplied Reference Data. The normal mode of use will be swipe-
captured data. The use of manually entered card data is supported (if allowed by the
Reference Data), with an appropriate flag set.
PIN use is not supported and cardholder verification is by signature comparison.
SOLVE/SE will be configured such that the following APACS 30 fields are set as
indicated:
PACS30 Field Name Value _IComment
[Dial Indicator 4 {‘no dial”
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 22 of 37
File: EFIFS002_DCS_Streamline_AlS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
erminal Type/ Capabilities [2160 __ Iindicates the following flags
Magnetic Stripe Supported
1 line of Display available
Hold Capability
Down-line loading of floor-limits and Date2
[Descriptive Data INULL Not applicable
IEMV Terminal Type INULL INot applicable
[Reason On-line Code INULL_ INot applicable
\Auxiliary Data INULL [Not applicable
Table 2 — Setting of standard APACS30 fields
The remaining fields in the Authorisation request will be set based on the specific
transaction subject to the constraints specified in this AIS and in [TS].
3.2.2 Authoriser response
[TS] describes Streamline’s interpretation of the APACS 30 standard and the way
response values are to be used in the Authoriser Response. Specifically:
= The authorised amount is always equal to transaction (requested) amount, or zero.
= The only use for the Message field is advisory. It is acceptable for Horizon to
ignore it and use its own messages for screen display / receipt print etc.
However the text of the message field does need to be checked since that is the
only way of detecting whether a request for a Card Impound is being made.
= Streamline does not use the Response Additional data fields.
= [TS] defines the full range of Authoriser Response Codes which require to be
supported in the Authorisation Response Message.
No special treatment is required for “Hold” messages. Timeouts values override any
Hold messages that may be received.
3.3 TRANSACTION & TERMINAL IDENTITY AND SEQUENCING
All transactions are initiated by Horizon.
Each transaction will be allocated a transaction identifier by Horizon at the counter.
This full Horizon transaction identifier is not used directly as part of the Request and
Authorisation messages to Streamline.
All transactions across the Horizon — Streamline interface will use the MID and TID
field in accordance with the valid MID / TID addressing range previously supplied by
Streamline and managed by Horizon (as described in Chapter 6).
The DCS Agent Server software maps individual transaction’s device addresses (FAD
code and counter position within FAD) into the appropriate MID and TID in
accordance with the APACS specification.
2. Although the physical terminal doesn’t have this capability, this is the default value used by SOLVE / SE and is agreed as
being acceptable 10 Streamline.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 23 of 37
File: EFIFS002_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
SOLVE / SE maintains the current transaction sequence number of each Terminal
(TID). Following a fail-over, a different instance of SOLVE / SE will be used. The
transaction sequence numbers will not be preserved across such a fail-over.
NB, there is a chance (1 in 10,000 transactions) that the next transaction sequence
number to be used following a fail-over will be the same as the one used immediately
prior to the fail-over. This will result in the MA interpreting this as an Implicit
Reversal. However, this should be a rare occurrence and is therefore considered an
acceptable behaviour, since the impact is purely to remove the ring fencing of the
funds.
3.4 TRANSACTION DUPLICATES AND TIMEOUTS
3.4.1 Duplicates
There are occasional failure or recovery conditions which can lead to a duplicate
instance of a Horizon transaction being presented across the Horizon-Streamline
interface (arising from a single transaction at the counter). Such circumstances will
result in a second (logically identical) request message being generated to Streamline
(and consequently ring-fencing the funds twice) but will result in only a single payment
file record being generated.
There are no circumstances which may result in a duplicate [A] message responding to
a request being processed at the counter.
3.4.2 Timeouts
Horizon will operate timeouts at the counter PC and across the Horizon-Streamline
interface.
At the Horizon-Streamline interface a timeout value will be set on the connection for
the receipt of the authorisation message corresponding to request. This is detailed in
the [TIS]. After expiration of this value SOLVE / SE will generate an Explicit
Reversal to Streamline and transmit a “decline — no authoriser available” response to
the counter. The timeout value is set at 18 seconds. Any response received from
Streamline after this is discarded.
At the Horizon counter, a counter timeout value is used to bound the duration of the
wait for the authorisation request. This value is set globally for the Horizon estate.
This value is set at 33 seconds, providing 15 seconds for Horizon system transit, plus
the 18 seconds at the Horizon-Streamline interface as controlled by the timeout
described above. On timeout, the counter application locally declines to complete the
DCS transaction and generates a [C0] message, requesting an explicit reversal.
Under rare conditions this may “cross-over” with a response returned from Streamline
or SOLVE / SE, but in such circumstances the local status prevails and the transaction
is handled as an explicit reversal (ie a [CO] message is generated at the counter,
resulting causing an explicit reversal being sent to Streamline) and any subsequent
message from Streamline or SOLVE / SE is discarded.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 24 of 37
File: EFIFS002_DCS_Streamline_AlS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Note that Streamline recommend that the APACS standards are adhered to regarding
timeout values. However that Post Office Ltd requirements are that timeouts are
configurable to values agreed between Post Office Ltd and Fujitsu Services.
The following table (supplied by Post Office Ltd) shows some typical response times
from Streamline once the transaction is within Streamline’s domain. The table does not
reflect any network time between Horizon and Streamline.
Seconds No.Auths Percenta Cumulative
4 ge
0-2 6,995,795 91.989185 91.989185%
%
2.001 -5 567,476 7.461862 99.451047%
%
5.001 -8 15,076 0.198238 99.649284%
%
8.001 - 1,777 0.023366 99.672650%
10 %
10.001 - 24,458 0.321603 99.994254%
15 %
15.001 - 431 0.005667 99.999921%
20 %
20.001 - 6 0.000079 100.000000
40 % %
7,605,019
Table 3 -Streamline Response Times
This shows that with a timeout value of 18 seconds, and allowing for the Network time
between Horizon and Streamline, a very small number of authorisations that could be
responded to would get timed out.
3.4.3 Unsolicited Messages
Unsolicited messages received across the Streamline - Horizon interface are logged
and discarded. (Note such messages can only occur on existing open X.25 level 3
circuits, since Horizon will not accept incoming X.25 level 3 virtual circuit
establishment).
3.5 SYSTEM QUALITY ATTRIBUTES
3.5.1 Security
The data is sent in clear between two secure Data Centres.
3.5.2 Scalability
There are no scalability implications at application level. The concurrency of the
application level interface is bounded by
= the speed of the physical communications interface(s) and
3 APACS standards recommend a 30-second timeout on the interface to Streamline.
4 Sample taken from 15/12/2001
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 25 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
= the number of available concurrent X.25 virtual circuits and their re-use policy
These characteristics are specified within the [TIS].
3.1.3 Resilience and Fail-over
Resilience is provided by supporting concurrent operational interfaces between each of
the two Pathway host sites and the Streamline operational sites.
Failure of a DCS Agent Server will affect approximately 25% of outstanding request
transactions. In these cases outstanding requests are not recovered and the transactions
will timeout at the counter.
Any fail-over between processing a request and a subsequent reversal, may well result
in the reversal being ignored resulting in the “ring fencing” of the funds not being
removed until the “ring fencing” is removed by the Card Issuer.
Failure of the Streamline authorisation host or site will result in all outstanding
requests being timed out at the Horizon - Streamline interface (or in some cases at the
counter).
Fail-over to the alternative Streamline site is not visible to Horizon.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 26 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Chapter 4 -
Payment File - Batch Interface
4.1 PAYMENT FILE GENERATION
The Payment File Generator within the DCSM is a software application that takes as
input a file or files containing card authorisation transaction records from the Horizon
outlets and produces as output a single Payment File for each MA. These Payment
Files will be transferred to the MA who will process them for onward transmission to
the Card Schemes
For this interface the DCSM will produce Payment Files in Streamline Standard
Format as per [DC] Appendix A.
Any duplicate confirmation records will have been removed (by Horizon) resulting in a
payment file with no duplicates. Reversals generated at the counter will also not be
included in the Payment File.
The content of the original Horizon Transaction Id will be included in the Originator’s
Transaction Reference field within the General Transaction Record 2 specified within
[DC]. Note that a mapping is required in order to fit this in and so it is not appropriate
to use this for manual reconciliation purposes.
4.2 TRANSFER TO THE MA
Details of file conventions and file transfer interface are specified in the [TIS]. Details
of file names to be used and the Company Identifier to be used are specified in [TS].
A file level acknowledgement is provided (by return file), which will be available no
later than 30 minutes after the transmission of the payment file is completed. The
format of this file is defined in [DC] Appendix G. This file will contain details of the
name of the file that has been accepted, a count of the number of records contained in
the file received and the date and time the file was received. Should this
acknowledgement file not be retrieved 30 minutes after sending the Payment File or
the file name or count differ from those in the Payment File sent, then the Payment File
should be resent. If an acknowledgement file is not available or is incorrect after the
second transmission then manual intervention is required. This should be treated as a
major incident and will require escalation as described in [OLA].
Should the file be rejected then a FAX is sent from Streamline to Horizon together
with a follow ‘phone call as defined in [OLA].
This will be a daily transfer process, to an agreed service delivery time [02.00].
However files will not be processed on Saturdays, Sundays or English Bank Holidays.
Note that a maximum of 9 files per day may be sent to Streamline using the same
generation date. Specifically, although Streamline do not process Payment Files on
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 27 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
Fujitsu
Services
FUJ00001670
FUJ00001670
Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
4.3
4.3.1
the file
4.3.2
Saturdays, Sundays and English Bank Holidays, they do accept files at all times other
than between 07:00 and 22:00 on Sundays.
ERROR HANDLING
Validation of the Payment File can give rise to two classes of errors:
= Fatal Errors
= Non-Fatal or Transaction Errors
These are discussed below.
There is also a concept of “Transaction Rejection Level” which can be set at Batch,
Submission or Transaction level. It is usually set at Transaction level, which indicates
the number of non-fatal errors in individual transactions, allowed before the file rejects.
Fatal Errors
Fatal errors will cause the file to fail regardless of the Transaction Rejection Level set.
The following are example of Fatal Errors:
= Company no. not recognised — either a Streamline set up issue or an error within
Outlet not recognised - either a Streamline set up issue or an error within the file
File already processed — a file Streamline believe to be a duplicate
Sequence error — file id out of sequence
Batch header invalid — total of file does not equal total in batch header
Record sequence error — transactions not in order of sequence number
The above covers the majority of reasons for rejection, these are internal descriptions
and it cannot be guaranteed that these will be used to inform Horizon of a rejection.
The Streamline File Delivery team will inform the nominated contact of a rejection and
advise where the error is in the file and the correcting action required. This will not be
automated and will require human intervention at both ends.
Transaction Errors
The file may be rejected as a result of accumulated errors at the individual payment
transaction record level; a control parameter will be set indicating the acceptable
number of record level errors before file rejection. The value to be used (constrained
to be between 0 and 50) will be specified in [TS].
Given the overall design of the system and the fact that all Payments in the Payment
files will have resulted from a Transaction that has already been authorised, transaction
errors in the Payment File should not occur. Any errors that do occur (ie where the
Payment in the EMIS file is marked as Rejected) should result in a [D] message being
generated for the DRS to process through the manual reconciliation route.
Some records may be marked as “pending” which allows Streamline to attempt to
manually amend the transaction so that it can be processed. If the Streamline
Exceptions Team cannot do this it moves to the rejected file which will result in the
transaction being rejected in the following night’s EMIS file.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 28 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Note that any records that are successfully manually processed by the Streamline
Exceptions Team will result in the transaction being returned without its Originator’s
Transaction Reference, which in turn will result in it being treated as invalid by
Horizon’s Data Reconciliation Service. Such a record will be reported in the
Reconciliation reports as an exception for manual processing.
4.4 SYSTEM QUALITY ATTRIBUTES
4.1.1 Security
The data is sent encrypted between two secure Data Centres
4.1.2 Scalability
The maximum size of an individual payment file is constrained only by the maximum
record count per file (company identifier) which is 8 digits (ie 99,999,999 records).
This is specified in [DC] as 99,999.
Limit of a maximum of 99,999 transactions to one batch (MID). Maximum of 9 files
per day to be sent to Streamline using the same header date.
Multiple payment files per day may be submitted in accordance with the file transfer
sequencing provisions as specified within [DC].
4.1.3 Resilience and Fail-over
Files are not resilient to in-flight failures during transfer.
Streamline have defined the File Retransmission Procedures as follows :-
= if there is no acknowledgement file after 30 minutes resend the file.
= = If there is still no acknowledgement file after 30 minutes contact Streamline.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 29 of 37
File: EFIFS002_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Chapter 5 -
Reconciliation Reporting - EMIS Batch
Interface
5.1 SETTLEMENT REPORTING
Horizon uses the information returned in the Streamline EMIS file for reconciliation
reporting to support Post Office Ltd settlement.
The EMIS file contains an individual record for every payment record submitted within
the aggregated set of payment files for a specific settlement day.
The data contained within the EMIS file is structured in accordance with the file
definition in Appendix B1 of [EMIS]
Records will contain the content of the Horizon Transaction Id submitted as the
Originator’s Transaction Reference. Note that a mapping is required in order to fit this
in and so it is not appropriate to use this for manual reconciliation purposes.
The Settlement Date will be based on the date that the Payment File is processed. It
can be assumed, that provided the acknowledgement for delivery of the Payment File is
time-stamped with a time earlier than the Streamline processing deadline (02:00 each
Monday to Friday other than English Bank Holidays), then settlement will take place
on that day. (This will normally be at least a day later than the Payment File was
generated, and this must be allowed for when generating the Settlement date for [S]
messages from the Payment File.)
There are no other normal circumstances in which the Settlement Date could vary from
this (Day B).
The file handling conventions to support this file flow are defined within the [TIS].
Details of file names to be used are specified in [TS].
5.2 SYSTEM QUALITY ATTRIBUTES
5.2.1 Security
The data is sent encrypted between two secure Data Centres
5.2.2 Scalability
There is no limit to the size of a generated EMIS file.
The currently forecast worst case (350K transactions) will be 52.44Mb based on
17,000 outlets.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 30 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
5.1.3 Resilience and Fail-over
Files are not resilient to in-flight failures during transfer.
No specific measures are provided at application level. [TIS] includes procedures for
fail-over to alternative host sites.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 31 of 37
File: EFIFS002_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Chapter 6 -
Management Interface — MIDs & TIDs
6.1 GENERAL
[DTO] defines the formal interface between Post Office Ltd and Streamline. This
chapter describes the interface between Fujitsu Services Pathway and Post Office Ltd
and is based on [DTO]. Therefore this chapter is not subject to sign-off by Streamline.
Strictly the entire chapter should be highlighted in grey, however only this comment has been
so highlighted for ease of reading.
There are two aspects of MID and TID Management:
= Initial Allocation of MIDs and TIDs to Outlets and Terminals
= Changes as part of the OBC process
Due to the number of MIDs and TIDs involved the process for managing the initial
allocation will be different from that to be used for ongoing changes. The two
processes and the interfaces associated with them are described in the following
sections.
Note that there are no available mechanisms for us to check that new MIDs and TIDs have
been configured in Streamline and so we will assume that if we have informed Post Office Ltd
as defined in this AIS, then the change can go ahead.
6.2 INITIAL MID / TID ALLOCATION & SET-UP
The initial loading of the large number of MIDs and TIDs on both the Streamline
service and DCSM will be a joint one-off exercise between Fujitsu Services Pathway,
Post Office Ltd and Streamline.
The number of TIDs and MIDs are:
1D Numbe I Allocation Notes
is
MID I 18,750 MA / Fujitsu Services Corresponds to number of Outlets, with some spares
Pathwa’
TID_I 50,000__I APACS / Post Office Ltd Corresponds to number of Counters, with some spare
Table 4 —Numbers of TIDs and MIDs
The procedures used for initial MID / TID allocation are as follows:
Streamline will supply Pathway with a range of 18,750 MIDs in advance of live service
as defined in the project plan.
The Terminal Identity (TID) is a unique reference, made up of a Registered Identifier
(digits 1 to 4), and a Unit Identifier (digits 5 to 8). The Registered Identifier (RID)
identifies the organisation to which a range of TID's has been allocated, and the Unit
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 32 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Identifier (UID) is unique to cach terminal within the Registered ID. APACS allocate
RIDs as required. The retailer can then allocate the 10,000 TIDs associated with a
RID as required. Post Office Ltd has been allocated 5 consecutive RIDs (2250, 2251,
2252, 2253 & 2254) thus providing 50,000 TIDs. Since TIDs may be reused
following outlet / counter closure, it is unlikely that further TIDs would be required.
However if it is found that further TIDs are required, then Post Office Ltd will need to
request further RIDs from APACS via Streamline.
Pathway will undertake the mapping of MIDs and TIDs to outlets (FAD code) and
counters (nodes) within the outlet. Note that the range of MIDs will not be
contiguous.
It is understood that one TID needs to be set aside for a special "default" terminal for use by
SOLVE / SE. This TID is not passed to Streamline.
These mappings will be made available to Post Office Ltd (who are responsible for
passing them on to Streamline) in the format specified in section 6.5.
The way in which these initial files are to be delivered to Post Office Ltd is outside the
scope of this AIS. The mechanism to be used for ongoing change management will
not be available at this time, since it is necessary to deliver the initial set of MIDs and
TIDs 6 months before Live operation commences.
6.3 MID / TID CHANGE MANAGEMENT
Support of the MID / TID Change Management process will start when DCS is
introduced to the Horizon Data Centres. Since this will be about 6 months after the
initial supply of MID / TID information there will be a significant number of changes
when the Change Management system process starts to catch-up on changes to the
estate over that 6 month period. In particular, this catch-up feed will pass all
individual changes and will not summarise 2 or more changes that have taken place for
a particular outlet. (Eg 2 separate counter increases for an outlet will be sent as 2
separate increases and will not be summarised as 1 combined counter increase.)
The Horizon mapping of MIDs and TIDs allocated against outlets and nodes will
change periodically as a result of Horizon Operational Business Change (OBC).
The OBC change management system is operated by Horizon and supports changes to
the MID / TID usage mappings as details of the Horizon estate configuration change
(covering new outlets, closed outlets, additional or removed counter positions within
outlets).
6.3.1 TID changes
The initial allocation of TIDs (50,000) is intended to be sufficient for Horizon use into
the foreseeable future.
TIDs associated with closed outlets or removed counters within an operational outlet
will be held available for potential re-use in new outlets or additional counters
deployed to an existing outlet. A minimum of 35 days will be allowed before re-
allocation of any previously assigned TID to a new counter PC.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 33 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Each TID change will be reported to Post Office Ltd (who are responsible for passing
them on to Streamline) using the mechanism described in section 6.3.3 below. Such
changes (whether involving the use of a new TID or re-assignment of a “used TID”
from the re-use pool) will be made a minimum number of working days (as defined in
Table 7) before any transaction shall be submitted for that TID.
6.3.2 MID changes
The current working practice by Streamline is not to re-use MIDs.
MIDs associated with outlets which have closed will therefore be discarded. An initial
allocation of spare MIDs will be provided at system set-up and mappings from this
pool will be used to populate new outlets with MIDs.
Each MID change will be reported to Post Office Ltd (who are responsible for passing
them on to Streamline) using the mechanism described in section 6.3.3 below.
Horizon will need to monitor the number of “spare” MIDs available and when this falls
below a threshold value, will need to ask Post Office Ltd to apply for additional MIDs
from Streamline. A process to support the application for and allocation of new MIDs
is included in [DTO].
Also need to decide how we manage this within Pathway, however that is outside the scope of]
this AIS.
6.3.3 MID / TID Change Reporting
An interface is defined for Fujitsu Services Pathway to report to Post Office Ltd the
allocation of MIDs and TIDs against Horizon FAD code and outlet device nodes.
This interface will also be used for reporting changes, for example when new terminals
(counters) are added to an outlet, terminals are removed from an outlet, or outlets are
opened or closed. In the case of changes to terminals in an existing outlet only details
of the changed terminals will be included (ie it is not necessary to include details of
unchanged terminals in an outlet).
Table 7 (in section 6.5.2) describes the business triggers for initiating changes to the
use of MIDs and TIDs. A file of such changes (in the format defined in section 6.5)
will be generated each day. This file will be made available to Post Office Ltd (who are
responsible for passing them on to Streamline) and will be delivered via the existing
Horizon — Post Office Ltd FTMS system at Huthwaite. The technical interface for this
link is specified in [POTIS]. Such files will be delivered each working day (ie
Mondays to Fridays excluding English Bank Holidays), with an empty file being
generated if there are no changes on a given day. Each file will be delivered in the
morning and contain all changes since the last file was delivered. Specifically, the
Monday morning file will include any changes implemented on Friday, Saturday and
Sunday.
The proposed naming convention for the interface files is:
MTID<sequence no>.csv
where <sequence no>.is a 6 digit sequence number, allowing missing files to be
detected.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 34 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
It is understood that Streamline do not wish to receive any empty files, and so they will not take
any notice of missing sequence numbers, however the interface between Post Office Ltd and
Streamline is outside of the scope of this AIS. (It is defined in [DTO].)
Note that the restriction of 1,000 lines in a file still applies. In the unlikely event of
more than 1,000 changes being required on a given day, then multiple files will be
generated.
Note that [DTO] specifies that email will be used for communication with Streamline.
Horizon’s responsibility (and hence that of this AIS) is to deliver the information to
Post Office Ltd on the FTMS gateway system at Huthwaite.
6.4 SYSTEM QUALITY ATTRIBUTES
6.4.1 Security
No security provisions are implemented at application level for MID / TID
management reporting from Horizon to Streamline.
6.4.2 Scalability
Not applicable.
The file is intended to be structured to cater for the maximum size of MID / TID pool.
A maximum of 1000 row entries is assumed per spreadsheet; see earlier comment
concerning initial set up of TIDs.
6.4.3 Resilience and Failover
Not applicable.
6.5 FILE FORMAT FOR MID / TID ALLOCATION AND CHANGES
This is based on the format specified in [DTO] Appendix 2.
This is based on a series of CSV files, with a maximum of 1,000 lines per CSV file. A
separate row is required for each TID leading to the requirement to submit 40,000
rows during initial data set up. Where values in fields may contain commas (for
example addresses), then the entire field will be encapsulated in quotes (normal CSV
tules).
For initial set-up a row is required for each outlet defining all its details (including the
TID of the first terminal for that outlet) using the “Set up new outlet” instruction code.
Then a separate row is required for each additional terminal defining its TID using the
“Add TID” instruction code. All terminals for a given outlet should be included in the
same file, thus it is likely that files will probably contain slightly less than 1,000 entries.
The current estate contains nearly 40,000 terminals, hence the estimate of 40,000 rows
to be supplied during set up.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 36 of 37
File: EFIFSO02_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Table 5 defines the mapping to be used from existing Post Office Ltd Reference Data
transferred to Pathway in setting up the CSV files for MID / TID Management
Records. It also defines the structure of each row within the CSV file.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 36 of 37
File: EFIFS002_DCS_Streamline_AIS.doc Printed on 20/6/2002 8:39:00 by gij
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
6.5.1 Derivation of MID / TID Data
Streamline Column No. & Contains Format I From Reference Data Notes
Name
4 Outlet ID MID N(8) N/A Sourced from / merged in Horizon
2 Outlet Name Outlet Name AN(26) I Office Name Align Left
Truncate to 26
3 Retailers Narrative 1 FAD Code AN(10)__I FAD Code Align Left, fill blanks right (6 digit FAD code used)
4__I Retailers Narrative 2 Town AN(18)_I Address 4 Post Town Align Left
5 I Cardholder narrative2 Outlet Name. AN(13)_I Office Name’ Align Left
6__I Address 1 Address Part 1 AN(30)_I Address 4-5 Omit Blank Lines, pack towards 3 lines
7__I Address 2 Address Part 2 AN(20)_I Address 1-5 Omit Blank Lines, pack towards 3 lines
8 Address 3 Address Part 3 AN(20)_I Address 1-5 Omit Blank Lines, pack towards 3 lines
9 I Postcode 1 Postcode first part AN(4) __I Postcode’ Split Postcode on Break? First part
10 __I Postcode 2 Postcode second part_I AN(4)__I Postcode Split Postcode on Break? Second _part
11_I Tel. No. Telephone No. N(15)___I Telephone No: Truncate, convert Ex Directory to Zeros
42_ I TID Terminal ID N(8) N/A Sourced from / merged in Horizon.
13 __I Instruction Code See Table 6 N(2) N/A See section 6.5.2
14 _I Effective Date Date AN(8) [I DD/MM/ccYY DD/MM/YY Time and_cc part of date omitted
Table 5 —- Mapping of Reference Data for Streamline MID / TID Management Records
Notes:
Code: N — Numeric, AN - Alpha-Numeric, (length)
instruction Code _IMeaning [Columns required
H Set up new outlet 4-14
2 [Close outlet 1,13 & 14
[Remove TID 1, 12, 13 & 14
4 Add TID iM, 12, 13 & 14
9 Amendment to outlet name 1, 2, 13, & 14
6. {Amendment to telephone no. 1, 11, 13 & 14
id Amendment to address / postcode 1, 4-10, 13 & 14
is Amendment to retailer narrative 1 (FAD code) 1, 3, 13& 14
io) Amendment to retailer narrative 2 (town) iM, 4,13 & 14
10 {Amendment to cardholder narrative 2 (town) 1, 5, 13 & 14
FUJ00001670
FUJ00001670
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE
File: EFIFS002_DCS_Streamline_AlS.doc
Page 37 of 37
Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
Table 6 — Meaning of Instruction Codes
Note that there are some circumstances in which amendments to Outlet details (ie use of codes 5, 6, 7, 8, 9 or10) may result in some Null
changes being generated (ie where the new value is actually unchanged from the old value).
6.5.2 Business Triggers for MID / TID Management
The table below proposes how the outlet changes requested by Post Office Ltd will be mapped onto the instruction codes required by
Streamline (as documented in [DTO] Appendix 2). It also shows when the changes will be triggered within Horizon in relation to a key
date and what trigger event will be used to initiate notification of the change. All such changes will be notified to Post Office Ltd on the
next working day following the “trigger”. It is then Post Office Ltd’s responsibility to notify Streamline of such changes in sufficient time
before the effective date for the changes to be activated by Streamline.
IClosure
notification has expired and will prevent closure
instructions being sent.
[Business Change [Trigger IPO Amendment Instructions INotification date — lExplanatory notes
[Type i (days)
INew Outlet IOBC Change _ [Set Up New Outlet instruction (IC=1) followed by n-1_ [Open date - 11 \See note 1.
IAdd TID instructions (1C=4), where n = number of Post Office Ltd must provide details into
jcounters. reference data by open date - 12.
ICancel New Outlet [OBC Change IClose Outlet instruction (IC=2) preceded by n-1 ICancel date + 180 é will re-use TIDs at cancel date + 195 (seeI
[Remove TID instructions (IC=3) if required. Inote 2).
Permanent Closure IOBC Change (Close Outlet instruction (IC=2) preceded by n-1 IClosure date + 180. e will re-use TIDs at closure date + 195
[Remove TID instructions (IC=3) if required. \(see note 2).
ICancel Permanent IOBC Change A cancel will be received before the 180 day IN/A
Outlet Details
Change
Reference Data
Change
[One or more of.
IAmendment to Outlet Name (IC=5)
[Amendment to Telephone Number (IC=6)
Amendment to Address/Postcode (IC=7)
Amendment to Retailer Narrative 2 (IC=9)
[Amendment to Cardholder Narrative 2 (IC=10)
lEffective date - 3
Post Office Ltd must provide details into
reference data by effective date - 4.
© 2002 Fujitsu Services (Pathway) Ltd
File: EFIFS002_DCS_Streamiine_AIS.doc
COMMERCIAL IN CONFIDENCE
Page 38 of 37
Printed on 20/6/2002 8:39:00 by gij
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
FUJ00001670
FUJ00001670
ICancel Outlet Details
Change
Reference Data
Change
{One or more of:
lamendment to Outlet Name (IC=5)
\Amendment to Telephone Number (IC=6)
Amendment to Address/Postcode (IC=7)
\IAmendment to Retailer Narrative 2 (IC=9)
Amendment to Cardholder Narrative 2 (1C=10)
[On receipt if original
change has been
Inotified
May not actually get cancels, may only get an
Outlet Details Change that sets the data backI
to its previous value.
[Counter Increase [OBC Change IAdd TID instruction (IC=4) for each additional counter. IInstall date - 11 [See note 1
Cancel Counter (OBC Change [Remove TID instruction (IC=3) for each cancelled new ICancel date + 20 fe have kept the notification of the cancel at
increase counter }+20 days to make a cancel increase like a
ounter decrease.
fe will re-use TIDs at cancel date + 35 (see
Inote 2).
ICounter Decrease [OBC Change [Remove TID instruction (IC=3) for each cancelled new IRemoval date + 20. fe will Re-use TID at removal date + 35 (seeI
counter Inote 2)
fe will not notify Streamline straight away to
jallow for cancels, where removal didn’t occur.
ICancel Counter [OBC Change A cancel will be received before the 20 day notification IN/A
[Decrease lhas expired and will prevent closure instructions being
lsent.
Table 7 —- OBC Triggers for MID / TID Change Management
Notes:
1. For new outlets, re-opens and counter increases there is a balance in timing to be struck between giving Streamline enough time to configure their
systems whilst allowing Post Office Ltd the opportunity to change their mind and cancel the request without the need to undo the changes. Within the
existing Operational Business Change framework we commit ourselves to start making changes on target change date -11 and we propose to use this
same notification date for Streamline. Cancels of new outlets, re-opens and counter increases that occur before the notification date will simply never
be notified to Streamline.
2. We have allowed 15 calendar days from the notification of a TID removal before we would allow the TID to be reused
3. All times are in calendar days (not working days) and are the dates when the interface file will be sent to Post Office Ltd. (All times in [DTO] are in
working days.)
4. Temporary Closures (and subsequent re-openings) are not notified to Post Office Ltd, however long they are for.
© 2002 Fujitsu Services (Pathway) Ltd
File: EFIFS002_DCS_Streamiine_AIS.doc
COMMERCIAL IN CONFIDENCE
Page 39 of 37
Printed on 20/6/2002 8:39:00 by gij
FUJ00001670
FUJ00001670
Fujitsu Horizon - Streamline Application Interface Specification Ref.: EF/IFS/002
Services
Version 1.1
COMMERCIAL IN CONFIDENCE Date: 07/08/2002
5. We will never produce an IC code 8 for amendment to retailer narrative 1, since this has been mapped to FAD code. We cannot change the FAD code
of an outlet, because this is the unique identifier for a given outlet. In Horizon terms the change of a FAD equates to a closure of the old FAD and the
opening of a new outlet.
© 2002 Fujitsu Services (Pathway) Ltd COMMERCIAL IN CONFIDENCE Page 40 of 37
File: EFIFS002_DCS_Streamiine_AIS.doc Printed on 20/6/2002 8:39:00 by gij