Third Party Payments Electronic Notifications / Appendix 1 Business & Technical Specification
e-Business & Messaging
Third Party Payments Electronic Notifications
Business & Technical Specification
Contents
Glossary 2
1 Introduction 3
1.1 Background 3
1.2 Purpose 3
1.3 Scope 3
2 Business Process 4
2.1 Specification Overview 4
2.2 Assumptions and constraints 4
2.3 Automated process overview 4
3 Technical Specification 6
3.1 The HP ES DWP e-Business Gateway 6
3.2 PACS Payment Schema 7
4 Transport Service Options 11
4.1 Value Added Network 11
4.2 SMTP and S/MIME 11
4.3 SMTP via GSI/GSX/GCSX 12
5 Frequently Asked Questions 12
5.1 Technical Support Questions 12
6 Appendix A – PACS Schema 15
6.1 PACS TPP Schedule Document Header 15
6.2 PACS TPP Schedule Document Detail 16
6.3 PACS TPP Schedule Document Summary 17
6.4 PACS Payment Schema – Text Based Version 18
6.5 Sample PACS Payment XML Message 21
7 Appendix B – HP ES Level of Service Summary 22
7.1 Pre-Implementation 22
7.2 Post-Implementation 23
7.3 The following activities are not covered by HP ES 23
Glossary
ACT Automated Credit Transfer
AP Accounts Payable
CESG Communications-Electronics Security Group
COTS Commercial Off The Shelf
EDI Electronic Data Interchange
FTP File Transfer Protocol
GSI Government Secure Intranet
GXS Global eXchange Services
HP ES Hewlett Packard Enterprise Services
PACS Programme Accounting Computer System
NISSA Northern Ireland Social Security Agency
SPVA Service Personnel & Veterans Agency
SSL Secure Sockets Layer
TPP Third Party Payments
TX TradeXpress
VAN Value Added Network
XML eXensible Mark-up Language
1 Introduction
This document defines the Business and Technical Specification for the transmission of Third Party Electronic Notifications to creditors who participate in the Direct Deductions Scheme. This document is correct at time of going to print and subsequent amendments are listed in the Amendments Section included with the Creditor Pack.
1.1 Background
1.1.1 The Programme Accounting Computer System (PACS) Accounts Payable Module (AP) is used by DWP Shared Services Payment Resolution Service to make Third Party Payments (TPP) to creditors who participate in the Direct Deductions Scheme.
1.1.2 All TPP creditors are paid by direct payment every 4 weeks. For each direct payment made a notification is generated by PACS. Creditors are encouraged to request that notifications be provided electronically in order to facilitate a direct upload of the information to their computer system. This requirement forms the basis of this Business & Technical Specification.
1.2 Purpose
1.2.1 This and subsequent versions of the Business and Technical specification define an agreed set of technical solutions which provide the platform for organisations to subscribe to this electronic process.
1.3 Scope
1.3.1 This document is limited to defining the business process and technical solutions associated with automating transfer of Third Party Payment notifications.
1.3.2 The implementation is limited to transfer of the dataset that is included within the equivalent printed notifications; this project does not seek to enhance the underlying functionality of the existing Third Party Payments notification process e.g. Recovery Notifications by electronic means are not to be introduced within the scope of this change. All Recovery notifications will still be issued via the postal method.
2 Business Process
2.1 Specification Overview
2.1.1 The Programme Accounting Computer System (PACS) Accounts Payable (AP) Module is used by DWP Payment Resolution Service, Third Party Payments team within Shared Services to make Third Party Payments to creditors e.g. local authorities and utility companies. This scheme allows for deductions from benefit (IS/JSA) to be paid directly to a creditor on behalf of the benefit customer. DWP Shared Services has been paying Direct Deductions to creditors using the PACS AP module since August 1998. The same service has been provided to the Service Personnel & Veterans Agency (SPVA) and Northern Ireland Social Security Agency (NISSA) since October 2000.
2.1.2 All DWP and NISSA TPP creditors are paid every 4 weeks. For each payment made a notification is generated by PACS, which gives a breakdown of the payment. Creditors receiving printed notifications then input this information manually into their respective systems.
2.1.3 The key business benefits that underpin these requirements are:
§ Support of the Government’s e-commerce agenda
§ Improvement in the levels of service provided to customers by meeting their requirements
§ Increase in security of processing
§ Reduction in the complaints and queries from creditors leading to reduced costs in TPP
§ Reduction in the environmental wastage
§ Enhanced speed of transfer and delivery for creditors
§ Removal of re-keying requirement for participating creditors and removal of keying errors
§ Scope for integration of electronic record receipt direct into creditor end application
2.2 Assumptions and constraints
The following assumptions and constraints have been made in developing this specification:
2.2.1 Recovery Notifications by electronic means are not to be introduced within the scope of this change. All Recovery notifications will still be issued via the postal method.
2.2.2 The take up of electronic notifications is controlled by DWP through the development and implementation of a ‘Migration Plan’, with priority given to creditors who receive bulky paper notifications.
2.2.3 Each individual creditor is responsible for ensuring that they can receive and process the electronic notifications sent. As a result the creditor may be required to make enhancements to their computer systems. The technical element of this document provides the basis for defining this electronic notification interface which informs the creditors of changes they may need to make to their systems to successfully receive and process electronic notifications.
2.2.4 Successful testing of the electronic notification interface between PACS and the creditors systems’ is required prior to a creditor record being updated to enable them to receive TPP payment notifications electronically.
2.2.5 The creditor is responsible for ensuring that their own work plan allows for the development of the relevant systems and business processes required to handle electronic notifications within the specified timescales necessary to match Payment Resolution Service implementation proposals.
2.3 Automated process overview
2.3.1 Electronic notifications are transferred to participating agencies usually on the day before the paper notification would have been dispatched.
2.3.2 Electronic notifications are sorted by creditor identification/agency and transferred as separate transactions even where the receiving system is within the same organisation.
2.3.3 The DWP e-Business Service Provider (HP ES) actively manages this electronic connection and informs both creditor organisations and DWP Business of any potential transfer problems. A nominated technical contact will be required from each participating organisation - the preferred communication mechanism for such contact will be via e-mail.
2.3.4 In the event of transfer difficulties, the DWP system is capable of re-transmitting transactions to any nominated system.
2.3.5 In the event of a file transfer problem the notification can be transferred again quickly within a 2 month period. An archive of data beyond 2 months enables recovery of payment notifications if exceptional circumstances demand.
2.3.6 The electronic notification transactions are optionally compressed. The compression requirement will depend on volume, transport service restrictions within both DWP and creditor domains and/or the desire to reduce transfer costs/timescales.
2.3.7 The electronic notifications are transmitted with levels of security appropriate to the transfer medium. Managing the security environment is the responsibility of the DWP e-Business Service Provider (HP ES).
2.3.8 The electronic notification transactions for each agency contains two record types:
§ Payment records
§ Adjustment records
2.3.9 Both record types (payment and adjustment) contain the same data:
§ Location – the “owning” office
§ National Insurance Number of the DWP customer on whose behalf the payment is being made;
§ Customer Reference - the creditor’s reference for the DWP customer;
§ Date from/Date through - the period covered by the payment/adjustment;
§ Amount - the payment/adjustment amount in pence.
The electronic transaction includes additional business information related to the total numbers of record type and information specific to the electronic transfer medium - this is defined in later sections of this specification.
3 Technical Specification
The purpose of this technical specification is to define the interface that creditors must implement in order to enable receipt of Third Party Electronic notifications from the DWP PACS system. The primary point of connection with the DWP for participating creditors is the HP ES DWP e-Business Gateway. Please see Appendix B which details the level of service HP ES provides to creditors with regard to each activity associated with the process.
3.1 The HP ES DWP e-Business Gateway
3.1.1 The HP ES DWP e-Business Gateway (e-Business Gateway) seeks to provide a generic service for the transfer and transformation of high volume structured data between Departmental applications and business partners. Consistent with a range of existing DWP e-Business applications, the TPP Electronic notifications service exploits the transformation and transport services provided by this key infrastructure component.
3.1.2 The e-Business Gateway provides a range of transformation (translation) services based on EDI For Administration, Commerce & Transport (EDIFACT) and eXtensible Mark-up (XML) language. All transformation takes place on the AIX Illicom TradeXpress component of the e-Business Gateway using COTS based software. EDIFACT transformation uses the TX proprietary Translation Control Language. The XML Service utilises the following integrated components:
· XML Parser – Apache Xerces C++ 1.1.0
· XSLT Processor – Apache Xalan C++ 1.1
This version of the document only examines the XML option - there are currently no plans to support the legacy EDIFACT option.
3.1.3 The e-Business Gateway also provides a range of transport services including Value Added Network connection via secure file transfer and secure email (SMTP + S/MIME) via GSI/the Internet. This version of the document examines the Value Added Network and SMTP options.
3.1.4 The e-Business Gateway comprises AIX and Windows XP environments, the latter providing additional transport services. Illicom TradeXpress version 4.3.2 is supported by a p-series model 6H1 server under AIX 4.3.2. The system is sited at a secure data centre and connects, over IP, to the DWP Electronic Messaging Service (EMS) across the DWP Wide Area Network (WAN). The DWP EMS provides external email routes to public X.400 services and an accredited SMTP connection to GSI and the Internet. There are two 6H1 devices providing parallel production and development environments and identified by their respective Network Names: ebg001 and ebg002. In addition to email transport, this system also provides file transfer capability via the GXS IE VAN. All content transformation processes, XML and EDIFACT, are provided by the TradeXpress component.
3.1.5 Windows XP components connect directly to the IBM AIX Servers across NFS and extend the functionality of the e-Business Gateway environment through provision of additional transport services. These services include external secure file transfer via GSI based on the Expedite product set and SMTP + S/MIME (3DES 128-bit encryption using X.509 standard digital certificates) providing authenticated and confidential external email transfer across the DWP Electronic Messaging Service, GSI and the Internet.
3.1.6 An overview of this architecture is described in the following diagram:
3.2 PACS Payment Schema
3.2.1 This section describes the usage of the following PACS Payment Information XML document, version b.
The implementation guidelines in this document assume a basic understanding of XML Rules. For further information, refer to:
www.w3c.org or
http://www.govtalk.gov.uk/schemasstandards/schemasstandards.asp
3.2.2 The PACS Payment Schema will comprise three sections:
§ Header section: comprising the creation date/time and batch/sequence number as supplied by the PACS application for all creditor records output on this date, and the Creditor ID and Notification Reference specific to the receiving agency.
§ Detail section: comprising the payment and adjustment records for the creditor detailed in the header section.
§ Summary section: comprising a summary of the payment/adjustment records held within the Detail section.
3.2.3 All PACS XML TPP Files will be sent using the following file-naming convention shown below
<CreditorID>_dat_<Notification Reference>_<Date>_<Time>
Example:
0000000099_dat_0000000001_20030729_130700
This specification will apply regardless of the transport method (SMTP, FTP, etc) used.
File extension will be .txt for natural XML format, or .gz for compressed.
3.2.4 The following diagram describes the branching diagram for each of the above components associated with this XML Schema:
3.2.5 A fuller description of the XML Schema components is included within the Appendices of this document, including an example XML instance. To aid understanding of the full end to end process, the following table describes the mapping between the internal file format and the XML messages to be exported to individual creditors once the daily output file from PACS has been sorted by individual recipient/agency:
Field name / Format / Description / XML MAP / Size / Start / End
Header / H / 1 / 0 / 1
Record type / AN / 01' / 2 / 2 / 3
Creditor ID / AN / PACS A/P id / DocumentHeader/CreditorID / 10 / 4 / 13
File Sequence / N / Sequence number / DocumentHeader/BatchNumber / 5 / 14 / 18
File Creation date / N / CCYYMMDD / DocumentHeader/PACSDocumentCreationDate / 8 / 19 / 26
File Creation time / N / HHMMSS / DocumentHeader/PACSDocumentCreationTime / 6 / 27 / 32
Notification reference / N / Settlement number / DocumentHeader/NotificationReference / 10 / 33 / 42
Detail Record (Payments) / D / 1 / 0 / 1
Record type / N / ‘02’ / DocumentDetail/RecordType / 2 / 2 / 3
Location / N / Owning Office / DocumentDetail/LocationCode / 6 / 4 / 9
Nino / AN / DocumentDetail/NationalInsuranceNumberType / 8 / 10 / 17
Cust ref / AN / Customer reference number / DocumentDetail/CustomerRef / 18 / 18 / 35
Date from / N / CCYYMMDD / DocumentDetail/DateFrom / 8 / 36 / 43
Date thru / N / CCYYMMDD / DocumentDetail/DateTo / 8 / 44 / 51
Amount (sign) / AN / Blank = positive, ’-’ = negative / DocumentDetail/DetailAmountSign / 1 / 52 / 52
Amount / N / Amount in pence / DocumentDetail/DetailAmountType / 10 / 53 / 62
Detail Record (Adjustments) / D / 1 / 0 / 1
Record type / N / ‘03’ / DocumentDetail/RecordType / 2 / 2 / 3
Location / N / Owning Office / DocumentDetail/LocationCode / 6 / 4 / 9
Nino / N / DocumentDetail/NationalInsuranceNumberType / 8 / 10 / 17
Cust ref / AN / Customer reference number / DocumentDetail/CustomerRef / 18 / 18 / 35
Date from / N / CCYYMMDD / DocumentDetail/DateFrom / 8 / 36 / 43
Date thru / N / CCYYMMDD / DocumentDetail/DateTo / 8 / 44 / 51
Amount (sign) / AN / Blank = positive, ’-’ = negative / DocumentDetail/DetailAmountSign / 1 / 52 / 52
Amount / N / Amount in pence / DocumentDetail/DetailAmountType / 10 / 53 / 62
Creditor Trailer record / T / 1 / 0 / 1
Total Amount (sign) / AN / Blank = positive, ’-’ = negative / DocumentSummary/SummaryAmountSign / 1 / 1 / 2
Total Amount (Creditor) / N / Amount in pence / DocumentSummary/SummaryAmountType / 10 / 2 / 12
Total 02 Record count (Creditor) / N / Number of ‘02’ records for creditor / DocumentSummary/Total02Records / 10 / 12 / 22
Total 03 Record count (Creditor) / N / Number of ‘03’ records for creditor / DocumentSummary/Total03Records / 10 / 22 / 32
3.2.6 Following transformation to XML syntax, the electronic notification transactions are optionally compressed. Compression is configured on a per creditor basis and its usage depends on volume, transport service restrictions within both DWP and creditor domains and/or the desire to reduce transfer costs/timescales.