ICL Pathway
EPOSS Functional Description
Ref:
Version:
Date:
FUJ00079277
FUJ00079277
BP/FSP/004
4.0
5/3/99
Document Title:
Document Type:
Abstract:
Status:
Distribution:
Approvals
Reviewers
For Information
Authors:
Comments to:
Comments by:
EPOSS Functional Description
Functional Description
This document describes the functionality implemented by EPOSS at
NR2.
Approved
Library
John Dicks
Terry Austin
Dick Long
Gill Jackson
John Pope
Phil Hemingway
Steve Warwick
Les Ong
Steve Doyle
Margaret Cudlip
Chris Humphries
Martin Ridell
Peter Burdon
Colin Oudot
John Plowman
Bernadette O’ Donnell
Paul Redwood
Chris Plunkett
Customer Requirements Director
Systems Director
Systems Design Manager
Test & Integration Manager
Customer Requirements
System Design
Counter Systems Development
Test and Integration
System Design
System Design
Development
Customer Service
Customer Service
POCL
POCL
POCL
POCL
BPFSP004.doc
© ICL Pathway 1999
COMMERCIAL IN CONFIDENCE
Page I of 117
ICL Pathway
EPOSS Functional Description
Ref:
Version:
Date:
FUJ00079277
FUJ00079277
BP/FSP/004
4.0
5/3/99
0 DOCUMENT CONTROL
0.1 Document History & SCHEDULE
Version Date Reason
LO 20/11/95 Initial Version. Reviewed by POCL.
2.0 04/12/95 Incorporated POCL comments.
3.0 23/04/96
3.1 15/12/97 Revised to take into account the changes from FS V5.0 to SADD V4.0
3.2 30/3/98 Revised to take account of the Pathway/POCL workshops in January and February
1998
3.3 3/6/98 Basic Restructuring agreed at meeting with Graeme Seedall 21/5/98.
3.4 25/6/98 Interim draft
3.5 18/9/98 Draft for review. Factors in POCL Solution Proposals
3.6 30/9/98 Update from comments received. Distributed for review.
3.7 26/10/98 Updated from comments received (Prepared for Acceptance Test Review)
3.8 16/2/99 For final review.
40 5/3/99 Approved after being formally reviewed on 24/2/99
0.2 APPROVAL AUTHORITIES
Name Position Signature Date
John Dicks Customer Requirements Director
Terry Austin Systems Director
Dick Long Systems Design Manager
Gill Jackson Test & Integration Manager
0.3 ASSOCIATED DOCUMENTS
Reference Vers Date Title Source
EPOSS Business EP/DES/008 0.9 16/2/99 EPOSS Business Rules Pathway
Rules
RCF Resolutions —_ None. 19/1/99 — Memo to Chris Plunkett from John POCL
Plowman — Horizon Product Assurance
Team documenting RCFs raised during
POCL EPOSS business assurance
review
MOT Horizon MOT/MS/TB 1.0 4/1/99 Model Office Test Horizon POCL
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 2 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Development Development Review
Review
EPOSS FD/BR. None None 15/2/99 EPOSS FD/BR Comments Pathway
Comments
May be found in the library linked to
this document.
0.5 CHANGES IN THIS VERSION
Reflects comments from final review:
© The overview has been removed as it added little value.
e References to POCL Solution Proposals (used in the POCL business assurance
review) have been removed as they are un-maintainable.
e Change any reference to 35 days (data retention at counter) to relate to 2 complete
POCL Outlet Accounting Periods (Requirement 816/3).
© One or two cosmetic corrections.
0.6 FORECAST CHANGES
POCL have requested that the data displayed by each function be identified in this
document (the data items, not the format). This requires a systematic review of each
function and a common method of documenting the data. This has not been attempted at
this time.
The functionality for View Stock Units is being revised. It should display where a stock
unit is currently logged on. This requires a list to be displayed.
0.7 TABLE OF CONTENT
1, SCOPE...
2. OVERVIEW
2.1 EPOSS FUNCTIONS
ERROR! BOOKMARK NOT DEFINED.
. ERROR! BOOKMARK NOT DEFINED.
STOCK UNIT ADMINISTRATION ...... ERROR! BOOKMARK NOT DEFINED.
SERVE CUSTOMER . ERROR! BOOKMARK NOT DEFINED.
Recording a POS Transaction . Error! Bookmark not defined.
Mail Transactions Error! Bookmark not defined.
23.3 Committing Transactions . Error! Bookmark not defined.
. ERROR! BOOKMARK NOT DEFINED.
Error! Bookmark not defined.
Error! Bookmark not defined.
24 RECORD REMITTANCES AND TRAD OF STOCK AND/OR Casit.
24d Transfers Of Stock From One Stock Unit To Anothei
2.4.2 Remittances
25 REVERSE ERRONEOUS TRANSACTIONS, . ERROR! BOOKMARK NOT DEFINED.
2.6 RECOVER FALLBACK TRANSACTION! RROR! BOOKMARK NOT DEFINED,
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 3 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
2.7 BALANCE INDIVIDUAL STOCK UNIT..... .... ERROR! BOOKMARK NOT DEFINED.
271 Stock Unit Reports (voucher check)... .. Error! Bookmark not defined.
2.7.2 Balance Stock Unit (stock check) ..... .. Error! Bookmark not defined.
28 STOCK UNIT REPORTS .. ERROR! BOOKMARK NOT DEFINED.
2.9 BALANCE OFFICE AND PRODUCE CASH ACCOUNT..... ERROR! BOOKMARK NOT DEFINED.
29.1 Office Balance. ... Error! Bookmark not defined.
2.9.2 Dormant Stock Unit Rollover... . Error! Bookmark not defined.
2.9.3 Suspense Account. .. Error! Bookmark not defined.
2.9.4 Reversals... .. Error! Bookmark not defined.
2.9.5 Non-accounting Data... .. Error! Bookmark not defined.
2.10 PRODUCE OFFICE LEVEL REPORTS ERROR! BOOKMARK NOT DEFINED.
2.10.1 Cash Account.
2.10.2 Office Rollover...
. Error! Bookmark not defined.
... Error! Bookmark not defined.
241 JOURNAL BROWSING FUNCTIONS, ... ERROR! BOOKMARK NOT DEFINED.
3. CONCEPTS
3.1 ORGANISATION...
3.2 TRANSACTIONS
3.3 ACCOUNTING......
4, ACCOUNTING PRINCIPLES ......
41 ACCOUNTING CONVENTIONS
42 QUANTITY ACCOUNTING ..
43 THE JOURNAL.....
44 EXAMPLE TRANSACTIONS,
441 Remittances I ...cccseecreeees
4.4.2 Remittances Out.
44.3 Serve Customer ..
44.4 Reversal:
445 Adjustments & Resulting Cash Discrepancies
44.6 Office Balancing ....
447 Stock Units
44.8 Suspense Accounts...
5. STOCK UNIT ADMINISTRATION
5.1 THE DEFAULT STOCK UNIT...
5.2 STOCK UNIT CREATION...
5.3 STOCK UNIT DELETION.
54 ATTACH STOCK UNIT TO A USER..... . seca .
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 4 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
5.5 ‘VIEW STOCK UNITS...
5.6 VIEW ATTACHMENTS .......
5.7 VIEW USERS...
6. SESSIONS & TRANSACTIONS...
6.1 INTRODUCTION...
6.2 TRANSACTION SELECTION......
63 ‘SESSION MANAGEMENT.
6.3.1 Session Start...
6.3.2 Session Log Display -
6.3.3 Void Transaction...
6.3.4 Abandon Customer Session...
6.3.5 Continue Customer Session...
6.3.6 Session Finish ....
6.3.7 Session Control......
6.3.8 Transaction Messages...
63.9 Session Receipts .
6.4 DESKTOP MODES.
6.4.1 Customer Service Transactions (Serve Customer)...
6.4.2 RemittanceS.
6.4.3 Internal Transfers... 47
4A Reversals ... 49
64.5 Recovery Mode ..csss-
6.4.6 Local Schemes...
7, WEEKLY TRANSACTIONS.
71 HOUSEKEEPING...
72 HOUSEKEEPING TRANSACTION PROCESSING ....
73 ERROR NOTICE PROCES:
7.3.1 RD Cheques (Handling of)...
74 OFF-LINE EPOSS TRANSACTIONS
75 NON-ACCOUNTING DATA...
7.6 PARCEL TRAFFIC .........
8. REPORTING.
8.1 PRODUCTION OF CLIENT DAILY/WEEKLY REPORTS BY STOCK U)
SLL Counters Daily Reports.
8.1.2 User Daily Reports.
813 Counters Weekly reports . 5S
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 5 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
814 User Weekly Reports
8.2 PRODUCTION OF OFFICE DAILY/WEEKLY REPORTS.
8.2 Office Daily...
8.2.2 Office Weekly .
8.2.3 Reprints of Office Reports...
8.3 THE REPORT PRODUCTION PROCE!
831 Transaction Data ...
8.3.2 Accounting Periods.
83.3 Client Report Cut-off 58
834 Sub-Stock Unit Reporting.
83.5 Data Selection Criteria ..
8.3.6 The Generic Report Writer...
83.7 Printing, Previewing and Completing Reports
84 SOME SPECIFIC REPORTS...
84.1 Discrepancies Report...
84.2 Daily Cash on Hand.
8.43 Journal Reports...
9, ITHE ACCOUNTING PROCESS......
91 THE STOCK UNIT BALANCE FORM ..
9.2 THE MANUAL STOCK UNIT BALANCING PROCESS...
93 EXAMPLE...
9.3.1 Opening Stock on Hand ......
9.3.2 Balance Form...
9.3.3 Balance Calculation.
10. STOCK UNIT DECLARATION (ADJUST/DECLARE STOCK/CASR)....
10.1 DATA ENTRY
10.2 SHARED STOCK UNIT DECLARATION .
10.2.1 Declare Cash on Hand (Shared Stock Units)...
I
10.2.3 Declare Stock on Hand (Shared Stock Units) ...
Declare Stamps on Hand (Shared Stock Units)
10.2.4 Declaration Discrepancies (Shared Stock Units).....
10.2.5 Adjust Stock on hand (Shared Stock Units)...
10.3 INDIVIDUAL STOCK UNIT DECLARATION ..
10.3.1 Declare Cash on Hand (Individual Stock Units)...
10.3.2 Declare Stamps on Hand (Individual Stock Units)...
10.3.3 Declare Stock On Hand (Individual Stock Units) ...
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 6 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
10.3.4 Declaration Discrepancies (Individual Stock Units).
10.3.5 Adjust Stock in Hand (Individual stock units)
11, PRODUCE STOCK UNIT BALANCE REPORT...
1d STOCK UNIT BALANCING OV
112 STOCK UNIT TRIAL BALANCE......
11.2.1 Stock Unit Trial Balance Pre-requisites
11.2.2. Declaring Discrepancies....
11.2.3 Trial balance Report Production .....
11.2.4 Trial balance Report Printing and Previewing.
113 STOCK UNIT ROLLOVER AND FINAL BALANCE.....
4 DISCREPANCY HANDLING
COMMUNICATION INTEGRITY CHECKS DURING STOCK UNIT BALANCING AND REPORTING.....
11.6 STOCK UNIT BALANCE SNAPSHOT .....scsssesesesseeecessneeee
12, COMPLETE CASH ACCOUNT - STANDARD..
12.1 INACTIVE STOCK UNIT ROLL OVER........
12.2 PRODUCTION OF OFFICE REPORTS ..
12.3 OFFICE BALANCE (WEEKLY CASH BOOR).....
12.3.1 Office Balance Snapshot .rcsoseseeeese
12.4 OFFICE BALANCE REPORT
12.4.1 Office Balance Prerequisites...
12.4.2. Trial Balance Report.
12.4.3 Confirm Office Balance...
12.5 CasH ACCOUNT SNAPSHOT ........
12.6 CASH ACCOUNT REPORT.......
12.6.1 Cash account rollover...
12.6.2 Final Cash ACCOUN seccsisescsesiseseeesseeceeeseese
12.7 COMMUNICATION INTEGRITY CHECKS DURING THE PRODUCTION OF OFFICE REPORTS ..
12.8 DISCREPANCY HANDLING.......044+
13. COMPLETE CASH ACCOUNT - 2/3 WEEK ..
14, COMPLETE CASH ACCOUNT - FINAL...
15. POST BALANCE ERROR CORRECTIOD
16. REFERENCE DATA MAINTENANCE....
16.1 CLASS B REFERENCE DATA.
16.1.1 Reference Data Downloads
16.1.2 Checks for Update:
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 7 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
16.1.3 User Messages .
16.2 REVALUATION .......ccseo0
16.2.1 Revaluation Modes...
16.2.2 Revaluation Discrepancies... 9S
17. MANUAL PROCESSES...
18. INTEGRATED SERVICES.
18.1 END-OF-DAY PROCEDURE
1811 Manual End of Day Function.
18.1.2. System Invoked End-of-Day...
18.2 BES/EPOSS TRANSACTIONS...
18.2.1 BES/EPOSS Normal Transaction...
18.2.2 BES/EPOSS Recovery Transactions .....
18.2.3 BES/EPOSS End of account... .
18.2.4 BES/EPOSS Incomplete transactions...
18.3 APS/EPOSS TRANSACTIONS...
18.3.1 APS/EPOSS Normal Transactions...
18.3.2 APS/EPOSS Reversals .......
18.3.3 APS/EPOSS Crash Recovery
18.3.4 APS/EPOSS Fallback...
19, FALLBACK & RECOVERY...
19.1 Loss OF POWER.....
19.1.1 Single Position Outlet ....
19.2 SYSTEM FAILURE...
19.3 Loss OF EXTERNAL COMMUNICATIONS.
19.4 Loss OF ONE OR MORE PERIPHERAL DEVICES
19.4.1 Magnetic Card Reader...
19.4.2 Bar-code Reader...
ee a
19.44 Keyboard...
1945 Screen...
103
19.4.6 Outlet System Integrity
20. OPS...
20.1 USER ADMINISTRATION .....-.:eess0s000
20.2 POST OFFICE LOG ON... seseeosee
20.3 LOGON. 105
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 8 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
20.3.1 APS Crash recovery...
20.3.2. ONCH Reporting.
105
ReFERENCE DATA CHANGE WARNINGS at Logon ..scesssssssessseesees
20.3.4 Stock Unit Attachment...
20.3.5 CAP IMCGTIIY coacssseereerseee
20.3.6 Reference Data Updates seuss
20.4 LOGOUT...
20.5 SESSION MOBILITY ...
20.6 USER MAINTENANCE... ...scsesesosee
20.7 USER PRIVILEGE LEVEL......0000
20.8 USER INVOKED TEMPORARY LOCK
20.9 SUSPEND AND RESUME USER SESSIONS...
21. GLOSSARY AND ABBREVIATIONS...
more tb
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 9 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
PURPOSE
To describe the functionality of EPOSS at Pathway New release 2.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 10 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
2. SCOPE
The document outlines the accounting principles applied in post offices and then describes
the EPOSS functionality implemented in terms of products, transactions, accounting
processes and reference data.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 11 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
3. CONCEPTS
This section introduces some key EPOSS concepts used later in this document. Further
terms and abbreviations are listed at the end of this document.
3.1. ORGANISATION
Office The post office branch or other location where
EPOSS is in use.
Stock Unit A stock unit is the physical till tray containing the
cash and valuable stock items like stamps. There
are an arbitrary number of physical stock units.
There may be several drawers in a stock unit.
Counter Clerk Member of staff in the office responsible for
serving customers at the counter. In Crown offices
the clerk has personal accountability for the stock
and cash used.
Manager Manager of an office.
Node Identifies an Horizon terminal which is also
sometimes referred to as a counter position.
Client Organisation which “owns” a service provided at
the post office counter. Clients include BA, BT,
British Gas ete.
3.2 TRANSACTIONS
Product Is an item that can be transacted or a service that is
provided. It includes stock and cash items, other
methods of payment and open value services.
Transaction Identifies the type of transaction being performed,
Mode e.g. serve customer, reversal, transfer, remittance.
Journal Business transactions are recorded in the
accounting journal.
Transaction The journal entry that results from “selling” a
product across the post office counter. A service
like giving advice or handing out a form can also be
considered a transaction with a zero value.
Transactions record value (can be zero), quantity
and additional data if required.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 12 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
3.3. ACCOUNTING
Unit of With Horizon the stock unit is used as the basis of
Accountability accounting. The accounting journal for the office is
sub-divided by stock unit but not any further.
Individual In many Crown offices, MSPOs and Franchises the
Accountability method of working imposes complete
accountability on each member of staff for all value
stock and cash that they use. In practice this means
that a clerk has sole use and responsibility for a
stock unit.
In order to relieve himself from the responsibility
for a stock unit the clerk must first balance it.
Shared Where several users share a stock unit concurrently,
Accountability individuals are required to account for the stock
and cash in the portion of the stock unit they use in
a particular balance period.
Stock Unit The stock unit balance period represents the time
Balance period (within a Cash Account period) in which a
Period counter clerk has responsibility for a stock unit.
For each stock unit there is at least one balance
period in a Cash Account period. The balance
period ends when the stock unit is balanced.
Client Usually daily or weekly reports are required by
Reporting stock unit or office listing and/or summarising the
Period client’s business during the period. There may be
several client reporting periods in a balance period.
Cash Account Usually a period running from Thursday to
Period Wednesday. It normally excludes Sunday and
consists of six working days. At certain times of
the year, like Christmas and other bank holidays, it
is likely that the Cash Account period will not be
six working days long.
Balance The accounting and reporting procedure which
(stock unit or provides a reconciliation of all transactions and
. stock movements against the actual stock and cash
office)
held.
Cash Account The definitive weekly summary of all transaction
activities within a post office branch. One is
produced each week by every post office. The
layout and content is similar for all offices. The
main differences are between London and
Provincial localities and between Crown and
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 13 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Agency offices. For the Horizon system, POCL has
agreed the use of a unified Cash Account format.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 14 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
4. ACCOUNTING PRINCIPLES
Note: This section mostly ignores the concept of stock units and assumes a general cash
book. The stock unit is introduced near the end of the section when office level suspense
accounts are introduced.
4.1. ACCOUNTING CONVENTIONS
Debit and Credit are the left and right columns in accounts respectively.
There are 3 types of accounts: asset, capital and liabilities. The effect of increases and
decreases to these accounts is shown below.
Account Name
Debit Credit
Increase an asset. Decrease an asset.
Decrease capital Increase capital
Decrease liabilities. Increase liabilities.
Post offices don’t have to buy stock, it is provided to them on credit (so is therefore a
liability). Thus increases to a stock, including cash, increase the individual post office’s
liability to POCL and are posted as credits, decreasing a stock requires a debit entry to be
made.
4.2, QUANTITY ACCOUNTING
Post office accounting needs to track quantities as well as value, so accounts record both.
4.3 THE JOURNAL
Generally in accounting practice, journals are used to record transactions in sequence for
later allocation to individual accounts. The EPOSS journal requires certain data to be
recorded:
Account Debit Credit Transaction I Quantity Signed
Mode Value
e Account and credit or debit values for the transaction.
EPOSS uses accounting nodes instead of account names. The following examples use
an account name for ease of understanding.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 15 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
e A narrative describing the transaction, e.g. sell box of paper.
EPOSS uses transaction modes to encode the basic narrative - so RIOP £5 PO is Remit
In from Other Post Office £5 Postal Orders. The following omit the product name for
ease of understanding.
e EPOSS has to do quantity as well as value based accounting so requires an extra
column. Note: there are zero value products where the quantity will be the only value
recorded. Quantities are signed '+' for increase and '-' for decrease.
e Automated accounting systems tend to use signed values instead of credit & debit
columns to facilitate easy balancing. , '+' for increase and '-' for decrease as defined
earlier. EPOSS does this in addition to the basic debit and credit columns.
e EPOSS groups transactions into sessions. You may have several debits and credits in
a session listed in the order they were transacted. The session must balance in itself
to 0.
4.4 EXAMPLE TRANSACTIONS
4.4.1. REMITTANCES IN
Remit in: £500 cash, £400 general stamps, 20 x £5 Postal Orders, 30 MVLs and 20 milk
tokens.
This increases the liability of all 5 items so they are posted in the credit column.
There is a compensating remittance ‘settlement’ transaction purely for balancing the
session.
Account Debit Credit Transaction I Quantity Signed
Mode Value
Cash 500.00 I Remit In -1 -500.00
Stamps 400.00 I Remit In -1 -400.00
£5 POs 100.00 I Remit In -20 -100.00
MVLs Remit In -30 -0.00
Milk Tokens Remit In -20 -0.00
Remittances 1000.00 Remit In 1 1000.00
BALANCE 1000.00 1000.00 0.0
4.4.2 REMITTANCES OUT
Remit out: £200 cash, £100 general stamps, 5 x £5 Postal Orders, 10 MVLs and 5 milk
tokens.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 16 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
This decreases the liabilities of all 5 items so they are posted in the debit column.
A compensating remittances transaction is required purely to balance the session.
Account Debit Credit Transaction I Quantity Signed
Mode Value
Cash 200.00 Remit Out 1 200.00
Stamps 100.00 Remit Out 1 100.00
£5 POs 25.00 Remit Out 5 25.00
MVLs Remit Out 10 0.00
Milk Tokens Remit Out 5 0.00
Remittances 325.00 I Remit Out -1 -325.00
BALANCE 325.00 325.00 0.0
44.3 SERVE CUSTOMER
The following examples are shown as single transaction sessions (so each one has a
balancing cash payment). Normally there could be several transactions in a customer
session.
Sell £20 stamps for £20 cash. General stamps are sold as open price items so the quantity
is 1 value £20.
Sell 2 £5 Postal Orders for £10 cash.
Sell 1 MVL for £80 cash.
Accept a £70 BT Bill Payment paid for with £70 cash.
Accept a £140 BT Bill Payment paid for with £70 cash.
Give £29 cash to a customer as benefit encashment.
Give 2 milk tokens to a customer.
Account Debit Credit Transaction I Quantity Signed
Mode Value
Stamps 20.00 0 I Serve 1 20.00
Cash 0 -1 -20.00
2 10.00
BPFSP004.doc
© ICL Pathway 1999
COMMERCIAL IN CONFIDENCE
Page 17 of 117
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: $/3/99
Account Debit Credit Transaction I Quantity Signed
Mode Value
MVLs 80.00 0 I Serve 1 80.00
Cash 0 80.00 I Serve -1 -80.00
BT Bill 70,00 0 I Serve 1 70.00
Payment
Cash 0 70.00 I Serve -l -70.00
a : — (
BT Bill 140.00 0 I Serve 1 140.00
Payment
Cash 0 140.00 I Serve -l -140.00
Benefit 0 29.00 I Serve -1 -29.00
Encashment
Milk 0 0 I Serve 2 0
Tokens
Cash 29.00 0 I Serve 1 29.00
44.4 REVERSALS
Again as single transaction sessions.
Refund £2 stamps for £2 cash. General stamps are sold as open price items so the quantity
is 1, value £2. Likewise, cash transactions are open price items.
Refund a £70 BT Bill Payment with £70 cash.
Account Debit Credit Transaction I Quantity Signed
Mode Value
Stamps 0 2.00 I Reversal -1 -2.00
Cash 2.00 0 I Reversal 1 2.00
" c
BT Bill 0 70.00 I Reversal -1 -70.00
Payment
Cash 70.00 0 I Reversal 1 70.00
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 18 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
44.5 ADJUSTMENTS & RESULTING CASH DISCREPANCIES
Stock is checked as part of the balancing process to ensure the accounts reflect the actual
stock position.
A loss or gain is declared to correct accounts where there is a confirmed discrepancy
between the two. An adjustment is posted to the particular stock account and a
compensating entry is posted to the cash account. Note, by this action, stock losses and
gains are converted into cash losses and gains. Losses (increases in cash liability) are
posted as credits in the cash account, gains are posted as debits.
Example:
1) If there are £12 less stamps than expected, the stamps account is reduced by £12 and
the cash account is increased by £12.
2) If there are £5 more £1 POs than expected, the £1 POs account is increased by £5 and
the cash account is decreased by £5
Account Debit Credit Transaction I Quantity Signed
Mode Value
Stamps 12.00 0 I Negative 1 12.00
Stock
Adjustment
Cash 0 12.00 I Neg. Stock -1 -12.00
Adjustment
£1 POs 0 5.00 I Positive -1 -5.00
Stock
Adjustment
Cash 5.00 0 I Positive 1 5.00
Stock
Adjustment
Adjustments to the cash position generated by stock adjustments (above) must be balanced
by a posting a discrepancy to the discrepancies account.
A single Positive or Negative Discrepancy Declaration is posted depending on the overall
effect of adjustments during the balancing period.
Account Debit Credit Transaction I Quantity Signed
Mode Value
Cash 7.00 0 I Declare 1 7.00
Negative
Discrepancy
Discrepancies 0 7.00 I Declare 1 -7.00
Negative
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 19 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Account Debit Credit Transaction I Quantity Signed
Mode Value
Discrepancy
44.6 OFFICE BALANCING
Overall, the effect of the transactions and adjustments (above) on the office balance is as
follows:
The analysis shows the effect on the stock position (note stock in the office is a liability
and therefore has a negative sign).
The transactions are separated into receipts and payments in readiness for balancing. The
stock carried forward is added into the balancing equation.
Stock Position Office Balance
Receipt
s Payments
Openin Receipt] Rem —_Pay- Closing
Stamps POS Cash] g Stock Rem In sI__Out _ ments Stock
Brought Forward 0 0 0 0
RI Stamps -400/ -400 400
RO Stamps 100) 100 100
Serve Stamps 20 20 -20
Reverse Stamps 2 2 2
Ri POs 100 -100 100
RO POs 25 25 25
Serve POs 10 10 -10
Serve MVLs 80 -80 80
Serve BT Bill 70 -70 70
Serve BT Bill 140 “140) i406
Reverse BY Bill -70 70 -70
Serve Benefit ”-29 29 290
RI Cash -500 -500 500
RO Cash 200 200 i 200
Adj Loss 2 “12
Adj Gain “5 3
Carried Forward 270 ~-70~—«526 0 1000 220/325 29-866
-866) 1220 1220)
The balancing equation:
Balance B/F + Receipts + Rems In = Total Receipts
Payments + Rems Out + Stock on Hand + Net Discrepancy = Total Payments
Total Receipts = Total Payments
44.7 STOCK UNITS
The examples so far assume the post office to be the unit of accounting i.e. there is a
single journal for the office. To enable personal accountability, the journal is split into
stock units with each stock unit posting transactions to its own cash book.
BPFSP004.doc
© ICL Pathway 1999
COMMERCIAL IN CONFIDENCE
Page 20 of 117
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
At the end of each accounting period (cash account week) each stock unit is balanced
using the above balancing equation.
The balance totals produced are subsequently accumulated to create an office balance
from which the Cash Account report is derived.
4.4.8 SUSPENSE ACCOUNTS
Post offices operate an office level "Suspense Account’ to account for transaction issues
that cannot be resolved within the current accounting period or from previous periods until
they are resolved.
Adjustments are used to post value from a stock unit into suspense and to redeem it once
the issue is resolved.
Suspense account transactions may be cleared in a number of ways, for example, receipt
of an appropriate error notice from POCL Central Accounts or receipt of funds from a
customer.
Suspense account transactions contain additional information such as error notice
references to support the audit trail.
Examples:
1) The £7.00 discrepancy (see previous examples) is posted to the suspense account and is
subsequently written off.
Account Debit Credit Transaction Quantit Signed
Mode y Value
Discrepancies 0 7.00 I Declare -1 -7.00
Negative
Discrepancy
Post discrepancy to the office suspense account.
Discrepancies 7.00 Housekeeping: 1 7.00
Post loss to
suspense
Office 7.00 I Housekeeping: -1 -7.00
Suspense Post loss to
suspense
Use loss clearance voucher to clear the loss.
Remit out £7.00 cash (but send the loss clearance voucher instead).
Office 7.00 Housekeeping: 1 7.00
Suspense Redeem loss
from suspense
Cash 7.00 I Housekeeping: -1 -7.00
Redeem loss
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 21 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Account Debit Credit Transaction Quantit Signed
Mode y Value
from suspense
Cash 7.00 Remit Out 1 7.00
(Voucher)
2) A customer’s cheque for an MVL bounces. The cheque is returned to the post office.
Account Debit Credit Transaction Quantity I Signed
Mode Value
Remit the unpaid cheque into a stock unit. Then move it (cash value) into the
suspense account. Adjust the Unpaid Cheques to balance the cash.
Unpaid 99.00 I Remit In -I -99.00
Cheque
Cash 99.00 Housekeeping: 1 99.00
Post RD cheque
to suspense
Office 99.00 I Housekeeping: -1 -99.00
Suspense Post RD cheque
to suspense
Unpaid 99.00 Negative 1 99.00
Cheque Adjustment
Cash 99.00 I Negative -1 99.00
Adjustment
2a) The customer provides alternative cash funds.
Account Debit Credit Transaction Quantity I Signed
Mode Value
Redeem the cheque from the suspense account to balance the above amount.
Office 99.00 Housekeeping: 1 99.00
Suspense Redeem RD
cheque from
suspense
Cash 99.00 I Housekeeping: -1 -99.00
Redeem RD
cheque from
suspense
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 22 of 117
© ICL Pathway 1999
ICL Pathway
EPOSS Functional Description
Ref:
Version:
Date:
FUJ00079277
FUJ00079277
BP/FSP/004
4.0
5/3/99
2b) The DVLA rescind the MVL and inform POCL where Central Accounts issue an error
notice to clear the suspense item.
Account Debit Credit Transaction Quantity I Signed
Mode Value
Redeem the cheque from suspense to balance the above amount.
Office 99.00 Housekeeping: 1 99.00
Suspense Redeem RD
cheque from
suspense
Cash 99.00 I Housekeeping: -1 -99.00
Redeem RD
cheque from
suspense
Convert the cash to a cheque
Cheques 99.00 Positive -1 -99.00
Adjustment
Cash 99.00 I Positive 1 99.00
Adjustment
Remit out the cheque and error notice voucher.
Cheques 99.00 Remit Out 1 99.00
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 23 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
5. STOCK UNIT ADMINISTRATION
Stock Units are the logical boundary of responsibility used in post offices for conducting
business.
This section describes the Stock Unit administration facilities. The facility to create or
delete stock units is only available to a user with ‘manager’ level privileges.
5.1 THE DEFAULT STOCK UNIT
The architecture of the Riposte system requires that all users who log on to the system
must be associated with a stock unit. When a user first logs on to the system it is possible
that no ‘attachment’ has been made to an existing stock unit. In these circumstances the
system will attach the user to the ‘default’ stock unit.
Users who are attached to the default stock unit may not carry out any transactions on the
system which would require a ‘serving’ stock unit to be attached. The system will prevent
access to such functions until an attachment to a serving stock unit is made.
§.2 STOCK UNIT CREATION
This function allows new stock units to be “introduced” into the office. The information
pertaining to each stock unit will include a unique (to the outlet) stock unit identifier (1 - 3
alphanumeric or space characters -- not just spaces) and the type of stock unit (Individual
or Shared). The system will check to ensure that the stock unit identified does not already
exist in the outlet.
On creation, Stock Units operate in the current office Cash Account Period.
5.3 STOCK UNIT DELETION
This function allows stock units to be “deleted” from the system. The user will be
provided with a non-editable pick list (showing stock unit identifier, type and CAP/BP) of
the current stock units on the system and invited to select one for deletion. The system
will carry out the following checks prior to deletion:
e That the selected stock unit has not been used to carry out transactions in the
current Cash Account Period;
e That the total value of stock and cash in the stock unit is zero;
e That there have been no transactions recorded against the selected stock unit in
the current day (such as balancing the stock unit at the end of the Cash Account
Period)
e That there are no users currently attached to the Stock Unit.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 24 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
5.4
5.5
5.6
5.7
ATTACH STOCK UNIT TO AUSER
To conduct business, a user must be logged on and attached to a stock unit other than the
‘default’ stock unit.
This function allows a user to be ‘attached’ to a stock unit. The user will be provided with
a non-editable pick list (showing stock unit identifier, type and CAP/BP) of the current
stock units on the system and invited to select one for attachment. The system will then
present the user with a non-editable pick list of current users (showing user name and
current stock unit attachment, if any) in the outlet and request that a user be selected for
attachment to the chosen stock unit. If the chosen stock unit is not sharable and the stock
unit is already attached to a live user, the attachment will be refused. Users may only be
attached to one stock unit at a time.
If an existing user is using the stock unit elsewhere the requested attachment is refused.
The system will not provide a specific function to ‘detach’ users from a stock unit. In
order to detach from a stock unit the user must be ‘attached’ to another serving stock unit
or to the ‘default’ stock unit. Attachment to the ‘default’ stock unit allows the user to log
on to the system but the user may not carry out any accounting transactions while attached
to this default stock unit.
VIEW STOCK UNITS
This function allows the user to “view” stock units on the system. The user will be
provided with a non-editable pick list (showing stock unit identifier, type and CAP/BP) of
the current stock units on the system and invited to select one for viewing. The system
displays details of the stock unit identifier, its type, current Cash Account and Balance
Periods and at which terminals, if appropriate, the stock unit is being used.
VIEW ATTACHMENTS
This function allows the user to “view” all current users on the system. The user will be
provided with a non-editable pick list (showing stock unit identifier, type and CAP/BP) )
of the current stock units on the system and invited to select one. On selection, a non-
editable pick list (showing user names only) of users currently attached to the stock unit is
displayed.
VIEW USERS
This function allows the user to “view” all current users on the system. The user will be
provided with a non-editable pick list (showing user name and current stock unit
attachment, if any) of the current users and the stock unit to which they are attached. A
user not attached to a live stock unit will be shown as attached to the ‘default’ stock unit.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 25 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
6. SESSIONS & TRANSACTIONS
6.1 INTRODUCTION
The user must have a serving stock unit attached in order to use the Serve Customer
functions. If no serving stock unit is attached to the user at the time of log on, the system
allocates the user to the default stock unit. This default stock unit is a system maintained
‘holding’ area which facilitates the logon and authentication process but cannot be used
for carrying out transactions. Until a ‘serving’ stock unit is attached, the user will be
prevented from accessing any of the functions from the menu which would require
modification of stock unit data. The facility to select and attach a stock unit to a user is
part of the Administration functions. The stock unit status display will clearly show
whether the user has a stock unit currently attached.
6.2 TRANSACTION SELECTION
6.2.1.1 SELECTING PRODUCT TRANSACTIONS
Individual transactions may be selected using:
© buttons;
e tokens;
e PLU number;
© ‘Local Product’ pick lists;
© PLU pick list;
6.2.1.2 SELECTING TRANSACTIONS USING ‘BUTTONS’
Buttons are presented within the menu estate of the GUI in a 4 x 4 grid of 16, layer on
layer, creating the conceptual equivalent of a “tree” or menu hierarchy. The location of
products within the “tree” is defined within the MENU HIERARCHY document.
Buttons contain a caption containing the product name, a caption containing the location
of the equivalent keyboard key and a graphical icon depicting a visual recognition device
which aids user recognition or differentiation for selection. Icons are also defined in the
MENU HIERARCHY document.
All core products generate product buttons, non-core products can also generate product
buttons but only if the product is sellable at the (given) outlet. If a non-core product is not
defined as sellable within a (given) outlet by PODAT then the button will not appear but
the logical space within the menu hierarchy is kept and generates a blank display
inherently invisible to the user.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 26 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Products which are designated on the system by a specific button can be transacted by
selecting the button from the appropriate menu. Selection of a product using this method
will result in the execution of a sales transaction of the current default quantity for the
chosen product.
Buttons are also provided for non-EPOSS application services. These ‘extended’ services
are provided by separate application software at the desktop and are usually activated via
‘tokens’. Tokens comprise any of the following:
© magnetic stripe cards;
e bar-coded items;
© smart cards/keys;
However, these applications usually require to provide facilities to, among other things,
‘manually’ enter the data normally read from the token (to cater for reader failure or token
failure). The activation of these ‘manual’ operations can be invoked from the menu
hierarchy in the same way as normal EPOSS transactions.
6.2.1.3 SELECTING TRANSACTIONS USING TOKENS
Certain products can be transacted by reading a customer supplied token. Customer
supplied tokens include:
¢ Benefit Payment Cards;
e Bar-Coded Order Books;
e APS Magnetic Cards or Bar-Coded tokens;
The processing of the data entry parts of these product transactions is usually carried out
by an application written specifically for these products (e.g. the Benefit Payment Card is
processed by the Benefit Encashment Service application software). These ‘extended’
application services are invoked automatically by the ‘reading’ of the token. The
transaction messages produced by these ‘automated’ products are added to the customer
session log in the same way as other EPOSS transactions and are treated in all other
respects (e.g. for settlement) as though they had been generated by EPOSS.
6.2.1.4 NON-EDITABLE PICK LISTS
Several EPOSS functions are implemented using non-editable pick lists. The lists
themselves are specific to the particular EPOSS function - the functionality is generic.
For example, the product list, a list of product names and PLU numbers (if available) is
displayed in product name order (ASCII order - numbers precede letters).
Navigation of the pick list can be achieved using any combination of the following
methods:
© the navigation buttons (top, page up, page down, bottom) on the screen;
e the ‘arrow’ keys on the keyboard;
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 27 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
e by entering a search string.
To use the search string facility the user enters an alphanumeric search string to navigate
to a position in the list. The system matches the search string against product names in the
list. Starting at the beginning of both strings, the matching algorithm compares purely the
alphanumeric characters in the 2 strings looking for the first exact match in the list, thus,
entering a ‘5’ will match with a product name ‘£5...’ . The match is re-done as each
character in the search string is entered or deleted (using the backspace key). If the current
string does not match any record, the top of the list is displayed.
Transaction selection is by highlighting the entry and selecting it using the Select button or
F1 key or touch screen.
The search string facility is not provided for all non-editable picklists.
6.2.1.5 SELECTING TRANSACTIONS USING ‘PICK LISTS’
Instead of appearing as individual buttons, products may be ‘grouped’ under one or more
buttons accessed via the menu hierarchy. Selection of one of these buttons (e.g. for local
rent and travel schemes) will result in the system displaying a pick list of available
products which can be sold in the outlet. The user may select a product from this list using
the general Product Pick List functionality.
6.2.1.6 USING THE PRODUCT LIST
Some products which are sold over the counter are allocated PLU (Product Look Up)
numbers in the reference data supplied by POCL. This number is the unique number
assigned to each item.
Where the user wishes to select a product using a PLU (Product Look Up) number but
does not know the number to use, the system will provide a facility to list all the PLU
numbered products for selection. The user may select a product from this list using the
general Product Pick List functionality. The list is constrained to those products sold in the
outlet (defined by Reference Data).
Once the product has been selected the product will be sold in the same way as described
in Customer Service Transactions below.
It is possible to select a product from the PLU list which the outlet does not trade. EPOSS
will reject such selections as if the user had entered its PLU Number directly.
6.2.1.7 EDITABLE PICK LISTS
These are found in a variety of places within the user interface and contain, for example,
the product name and data entry fields for the user to indicate a value. The name, content
and ordering of the lists is controlled by reference data. The current implementation is
constrained to various declaration processes:
e Declare cash for cash reporting (ONCH)
e Declare cash for balancing
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 28 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
e Declare stamps for balancing
e Declare stock for balancing (the pick list for this = value stock minus a specified list of
products e.g. cash, general stamps).
Navigation of the pick list can be achieved using any combination of the following
methods:
e the navigation buttons (top, page up, page down, bottom) on the screen;
e the ‘arrow’ keys on the keyboard;
e by entering a search string
Data may be entered using the keyboard or screen keypad.
Confirmation of values entered or changed is made by completing the process (“Finish”
button) at which point data is committed and records are generated. Backing out of this
screen before confirming entries will result in abandonment of any values entered.
6.2.1.8 SELECTING TRANSACTIONS USING PLU NUMBERS
6.3
Some products are allocated PLU (Product Look Up) numbers in the reference data
supplied by POCL. This number is the unique number assigned to each item.
Over a period of time clerks who make extensive use of the system will become familiar
with the PLU numbers of a large number of the most popular products. Rather than
navigate to the menu containing the product ‘button’ they may prefer to select these
products by entering the PLU number directly. Entry of a PLU number will be achieved
by selecting the ‘PLU Number’ button and entering the required number. It is possible to
enter an invalid PLU number or one for a product which the outlet does not trade. EPOSS
will reject such selections.
Transaction selection using PLU numbers is available in all transaction modes but is
constrained to the transactions available for the particular mode. These are defined via the
menu hierarchy.
Note: PLU numbers are used purely for product selection and should not be confused with
product numbers which are recorded in the resulting transactions.
SESSION MANAGEMENT
The session comprises the set of transactions undertaken in a logical group (e.g. for the
same customer at one visit to the counter or a remittance batch). The desktop will display
an on-screen Session Log (referred to as the ‘stack”) and a running balance for session
settlement.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 29 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
6.3.1 SESSION START
A Customer Session is started the first time that a customer service transaction is carried
out on the system following either log on or the completion of a previous customer
session. The session number, or identifier, is taken from the unique Riposte message
number (usually the number of the first transaction in the session). A customer session
remains open as long as there are transactions displayed on the Customer Session Log.
6.3.2 SESSION LOG DISPLAY
The information displayed for each transaction in the session includes the name, quantity,
and total value. The running balance (‘finish’ button) shows the total value for the session.
Only the last three transactions plus the running balance will be visible on the normal
desktop display. Transactions over and above the last three can be viewed by selecting a
‘more’ option displayed at the top of the stack. When the ‘more’ button is selected the
most recent 10 transactions (9 transactions plus running balance) are displayed in place of
the normal menu buttons. A ‘page down’ button enables the next 10 most recent
transactions to be displayed, and so on. A ‘page up’ button reverses the process. The ‘less’
option returns the user to the normal desktop display.
Linked transactions are not always shown separately on the stack, the value being
accumulated with the main transaction value and added to a single ‘button’ on the stack.
Linked transactions are, however, printed separately on any receipts produced and are
recorded as separate transactions in the message store.
The desktop will display an on-screen stock unit status which will include the stock unit
ID, the current user name and the current Cash Account and Balance Period. The stock
unit contents will be maintained up-to-date during the serving process by the addition of
messages to the message store representing the transactions undertaken. The display will
also show whether the stock unit is being shared with other users (i.e. team balancing is in
place).
6.3.3 VOID TRANSACTION
It will be possible to void (cancel), a transaction within a customer session that has not
been committed to the message store, providing that the reference data supporting the
product allows for ‘voiding’. The user will select the ‘Bin’ button on the screen and then
select the transaction, from the session log, to be ‘voided’. Void transactions are not
committed to the message store.
It will be possible to abandon any incomplete transaction while it is still in progress. Ifa
transaction is abandoned it will not be added to the customer session log.
Once a transaction that is not voidable is added to the customer session log then voiding is
prevented and the ‘reversal’ functionality must be used to create a compensating
transaction to effectively remove the transaction from the journal.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 30 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Linked (mandatory associated) transactions have the same transaction identifier and are
voided as one.
6.3.4 ABANDON CUSTOMER SESSION
It will only be possible to abandon the customer session before settlement is reached if all
the transactions accumulated on the customer session log can be voided. However,
transactions that have already been settled and committed will not be able to be ‘voided’
although they could be reversed, in a separate reversal session, if the product reference
data supplied by POCL allows reversal of the product. When a customer session is
abandoned the system will return to the ready state. This is achieved by voiding each
transaction separately.
6.3.5 CONTINUE CUSTOMER SESSION
A mechanism to allow the continuation of a customer session is available, even if the
balance of the session is currently zero, providing that one of the ‘Fast’ options is not used
as the MoP for the current session. To continue a customer session the clerk may carry on
selling products/services and accepting MoPs so long as he/she does not use the ‘Fast’
MoP options or select the ‘Finish’ button when the outstanding balance is zero.
6.3.6 SESSION FINISH
The end of the current customer session is determined by the selection of the ‘Finish’
option on the button displaying the customer session total. If the balance of the session is
not ‘0.00’ at this point, the clerk will be offered the settlement menu containing various
Methods of Payment. When the Methods of Payment have been selected and the
appropriate values entered the system will determine whether the session balance is at zero
and, if so, the transactions (including the Methods of Payment entries) will be committed
to the message store and the system will be returned to the ‘ready’ state for the start of a
new customer session.
Normally, transactions are not actually committed electronically until the customer session
is explicitly completed. However, some transactions will mandate settlement and
committal, as a set, in their own right. All EPOSS transactions fall into the category of
those not committed until the customer session is completed, therefore EPOSS
transactions will remain un-committed to the message store while they are still visible on
the customer session stack.
Selecting ‘Finish’ in a Remittance session automatically settles it to a remittance settlement
product that does not appear on the accounts.
Selecting ‘Finish’ in a Recovery session automatically settles it to cash.
During the period between the start of the new customer session and the end of the
previous customer session the system is in the ‘ready’ state.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 31 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Some products may only be transacted with another one, e.g. you cannot redeem TV
License Stamps if you haven’t already added a TV License to the session. This
relationship is defined by reference data (mandatory inclusive precondition attribute).
Such transactions may not be added to the session if this rule is contravened. neither can a
session be finished.
6.3.7 SESSION CONTROL
There is no system limit constraining the number of transactions in a session.
If the transaction being undertaken is added to the customer session log more than a pre-
determined length of time (2 minutes) since the previous transaction in the current
customer session, the system will display a message to the user to determine whether this
transaction is in a new session. If the user confirms this, the system will end the current
session (settling the balance with ‘cash’) and will start a new session with the current
transaction. Otherwise the transaction is added to the session log.
6.3.8 TRANSACTION MESSAGES
All transactions carried out using the EPOSS system are recorded as messages in the
Riposte message store. The information contained in these messages varies depending on
the nature of the transaction being undertaken, although all messages contain a basic
common set of data which includes:
unique transaction identifier;
unique customer session identifier;
date and time of transaction;
product number sold;
value;
quantity;
user ID;
terminal node identifier;
stock unit identifier;
group number (= FAD code);
accounting nodes for the product (for balancing and reporting purposes)
The attributes for the Cash Account and Balance periods are not stored as part of each
transaction message. These attributes are determined from Riposte ‘markers’ placed in
the message store to record the beginning and end of each of these periods.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 32 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
6.3.9 SESSION RECEIPTS
6.3.9.1 RECEIPTS
Receipts relate to a session and report information on the transactional data relating to the
session, along with additional information such as Time and date, Office, Stock Unit, etc.
They are generally available throughout the Transactions branch of the menu hierarchy.
Receipt production is performed at the end of a session and may be manually requested by
the clerk or produced automatically, depending upon the context.
Manually requested receipts are available in Serve Customer, Recovery, New Reversal,
Non Accounting Data, Parcel Traffic and Off Counter Transactions modes. Receipts for
Housekeeping and Adjustments mode are only available via the Serve Customer mode
Receipt function.
Automatic receipts are provided for Remittance, Transfer, Revaluation and Existing
Reversal modes, as well as for any customer session which contains a product whose
reference data specifies that a session receipt must always be produced.
For manually requested receipts, the clerk will select the ‘Print Receipt’ button from the
appropriate menu. For both manual and automatic receipts, the receipt will be printed on
the attached ‘tally roll’ printer. If the printer is disconnected or has failed the receipt
details will be displayed on the screen so that a manual receipt can be prepared. The
format and content of the receipt will be specified in the document Horizon Reports and
Receipts Specification.
Outlets which have the ‘Welsh Language’ indicator set in the outlet details held in the
message store will automatically print customer receipts in accordance with the
Welsh/English Receipt format specified in the Horizon Reports and Receipts document.
Non-customer receipts are always in English.
The manually requested receipt printing facility is available at any time from the end of
one session to the start of the next.
The format of receipts are defined in the Horizon REPORTS AND RECEIPTS
FUNCTIONAL SPECIFICATION.
6.3.9.2 DUPLICATE RECEIPTS
A ‘duplicate’ receipt facility will be provided as an optional facility at the end of a
customer session. If required, the clerk will select the ‘Duplicate Receipt’ button from the
appropriate menu and the receipt will be printed on the attached ‘tally roll’ printer. If the
printer is disconnected or has failed the receipt details will be displayed on the screen so
that a manual receipt can be prepared. The format and content of the receipt will be
specified in the document Horizon Reports and Receipts Specification. The duplicate
receipt will be clearly marked as a ‘duplicate’ or ‘copy’ in order to differentiate it from the
original receipt.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 33 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Outlets which have the ‘Welsh Language’ indicator set in the outlet details held in the
message store will automatically print receipts in accordance with the Duplicate
Welsh/English Receipt format specified in the Horizon Reports and Receipts document.
The ‘duplicate’ receipt is only available if the ‘Print Receipt’ option has already been
selected for the required receipt. The ‘duplicate’ receipt printing facility is available at
any time from the end of one customer session to the start of the next.
6.4 DESKTOP MODES
Actions which take place on the counter desktop are controlled by means of desktop
‘modes’. While the desktop is in a given ‘mode’ the system will impose certain
limitations as to what actions the user can take. For example, if the user is in the ‘serve
customer’ mode then the system will prevent the user from accessing and transacting stock
transfers and remittances. The range of desktop modes to be supported include:
e Serve Customer
e Remittances
¢ Internal Transfers
e Reversals
e Bulk Input
e Adjustments
e Entry of Non-accounting Data
e Entry of Parcels Traffic Data
e Housekeeping
The product transactions available in each transaction mode are constrained by the menu
hierarchy. Products must be present in the relevant sub-tree of the hierarchy for the
particular transaction mode.
6.4.1 CUSTOMER SERVICE TRANSACTIONS (SERVE CUSTOMER)
Customer Service Transactions are services, or products, provided by the counter clerk to
the customer. The products range from simple fixed price items, such as stamps, to
complex open value transactions like the payment of benefits.
Simple fixed price and simple open value products can be comprehensively defined by
parameters and handled by generic applications. Complex transactions involving the
collection and derivation of information will be handled by augmenting the generic
functionality using custom applications. The custom applications can be as complex as
required by the transaction dialogue.
Quantities
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 34 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
The user inputs the required quantity prior to selecting the transaction. See the section
describing the Quantity Function below.
Transaction Selection
See previous section on this subject.
Fixed Price Product Transactions
Products may be defined in reference data as either fixed price, default price or open price.
Ifa fixed price item is sold no further interaction with the clerk is required and the
transaction total value is calculated from Quantity * Unit Price = Total Sale Value. An
icon representing the sale and displaying the quantity and total sale price is displayed on
the stack. The value of the stack total button is incremented in line with the total value of
the sale.
Default Price Product Transactions
If a product is designated in the POCL supplied reference data as a ‘default price’ product,
the system will display a data entry script to the clerk. The data entry script will display
the ‘default’ price and prompt the clerk to accept or alter the displayed price. The
transaction total value is calculated from Quantity * Unit Price = Total Sale Value. An
icon representing the sale and displaying the quantity and total sale price is displayed on
the stack. The value of the stack total button is incremented in line with the total value of
the sale.
Open Price Product Transactions
If a product is designated in the POCL supplied reference data as an ‘open price’ product,
the system will display a data entry script to the clerk with no value present. The data
entry script will prompt the clerk to enter the unit price of the product and the transaction
total value is calculated from Quantity * Unit Price = Total Sale Value. An icon
representing the sale and displaying the quantity and total sale price is displayed on the
stack. The value of the stack total button is incremented in line with the total value of the
sale.
Reference Data
Normal EPOSS transactions may impose minimum and maximum value and quantity
limits. These limits are controlled via Reference Data.
The Reference Data comprises:
e A primary, system-unique identifier for the item;
e A short name for the Item;
e¢ A medium length name for an Item;
e A long name for an Item;
e The price of a single Item (including VAT, if appropriate);
e The value that multiple sales of the Item must be divisible by. E.g. sales of National
Lottery Instants must be divisible by £1;
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 35 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
e The minimum value that can be assigned to an Item;
e The maximum value that can be assigned to an Item;
e The minimum quantity of a non-fixed price Item that can be transacted by a customer;
e The maximum quantity of a non-fixed price Item that can be transacted by a customer;
e Instructions to the clerk when transacting an Item;
e The number of receipts to be produced when transacting this Item;
© Code to identify VAT code;
e A unique system generated code to identify the Client owning the item
and the following indicators:
e Can an operator override an Item’s price?
« Are transactions of the Item allowed to be reversed ?
¢ Is perpetual inventory tracking on the stock unit product required ?
e Isa refund allowed against an Item ?
© Can the Item can be voided whilst serving the customer ?
e Is the Item is a core item?
e Can the Item change sign, i.e. is it cash or a cash equivalent (Mondex etc.)?
6.4.1.1 ADDITIONAL INFORMATION CAPTURE
Transactions Requiring Additional Data
Products which require the entry of additional items of data (e.g. the account number
associated with a Girobank deposit or withdrawal) will prompt for the appropriate
additional entry(ies) prior to prompting for the transaction Unit Price.
Reference Data
The data required, input form and input validation rules are defined in Reference Data.
The Reference Data comprises:
e A sequence number that identifies the order in which the fields occur.
e The name of an additional field of information. The name must be unique
e The description of an additional field of information.
e The message that is to appear on the screen when requesting input of an additional field
of information.
© A code that identifies the format of the additional field.
e The description of the Format Type Code e.g. Boolean, Date, Integer.
© The length of an additional field of information within the Field Format.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 36 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
e The number of decimal place for an additional field of information - default 0.
e The positioning of the content of an additional field of information. Default = left for
character fields, right for numeric fields.
e Identification of any leading figure required for a numeric additional field of
information, e.g. zeros. Default = blank.
e Identification of whether a numeric additional field of information is required to allow
negative values. Default = ‘N’.
e The presentation of an additional field of information.
e The value to store for an additional field of information if no data is entered.
¢ Identification of the default value for an additional field of information.
e The maximum permitted value of an additional field of information.
e The minimum permitted value of an additional field of information.
e Identification of whether data must be captured into the field, or it is allowed to remain
empty.
e Identification of the default value for the field when used for an Item. If present, this
value will override the normal Field Default Value for the Additional Field.
e Identification of whether the operator is allowed to override the default value for the
field.
e Identification of whether the additional fields are to appear before the standard Item
attributes, or after them. Valid values are “Y’, ‘N’, or blank - default = blank.
6.4.1.2 SELLING PRODUCTS USING THE SCALES
6.4.1.2.1 Scales Availability
Some products and services transacted in the outlet have their value calculated according
to, among other things, the weight of the item. These facilities are primarily used for
items of mail and are usually also associated with the provision of a variety of primary
and secondary services.
When a customer requires a weight-related mails service the system will provide the
facility to read the weight directly from a connected electronic scale (Avery D104). The
scales have a two-line display visible to the customer which offers information on weight,
service rates and an intuitive indication of the active node connection (i.e. which counter
position is accessing the scale).
The user will select the designated “Scales” button from the desktop.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 37 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
The Horizon screen will depict the destinations available (e.g. Inland, Europe,
International zone 1, International zone 2, Pick by Country). Upon selection of Pick by
Country, the user will be presented with a non-editable alphabetical pick list of available
countries, excluding inland, from which to select a country. When a destination (zone or
individual country) is selected, the Horizon terminal will attempt to claim the scales for
the terminal. If this access is gained, the transaction can continue. If this access is denied
the terminal will advise the user that the weight will have to be manually input if the
transaction is to continue or that the transaction can be abandoned.
One set of scales may be shared between one or two counter positions. Contention is
managed as follows. When the counter position tries to claim the scales, access may be
denied due to contention, office network failure or the absence of scales. Having claimed
the scales, the counter position will maintain its claim for up to a minute (by polling the
scales periodically). If the claim times out, a user message will be displayed.
In the event that the scales claim fails due to contention, the scales are out of service or
there are no scales connected, the clerk will be prompted to enter the weight (obtained
from any other scale device in the outlet) via the screen or keyboard. Once the weight is
entered, the system will display the weight entered and the cost of the basic service
selected. An option button is provided to access additional services available for the
selected destination (e.g. Small Packet, Surface Letter, Air Mail) and prompt the user to
select the required service.
6.4.1.2.2 Scales —Service Selection
Having gained access to the scale, the system will obtain a steady weight from the scale.
This will be either the weight as determined by any item already on the scale or, if no item
is present on the scale, the weight of any item to be placed on the scale. If no item is
present on the scale, the system will prompt the user to advise the customer to place the
item on the scale or enter a manual weight (if no item is available for weighing).
If the weight is the same as was there for the previous transaction (i.e. the weight has not
changed) the system will prompt for the next item to be placed on the scale. The system
will register the new weight.
The system will display (via a non-editable pick list) the weight and services available for
the destination selected along with associated price related to the captured weight. Only
appropriate services for the weight/destination are displayed. The price is calculated using
tariff data supplied as Reference Data.
The service required is selected by the user and this service and associated price will be
displayed in the message area on the scales, along with the weight.
The system will relinquish control of the scales at this point.
If subsequent changes are made to the item on the scale based on customer requirements
(e.g. more enclosures are made to the item) such that the weight changes, the transaction
should be abandoned and started again.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 38 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
6.4.1.2.3 Scales - Additional Transaction Details
After service selection, the system will display:
e The Basic Service Selected
© The Weight of the Item
e The Value of the Service
© Option to Select Additional Services (e.g. Recorded, Registered Etc.)
Any additional services that are available with the basic service are displayed using a
non-editable pick list from which a required service may be selected. The availability
of additional services with basic services, and the tariffs for them, are supplied as
Reference Data. Once this option is completed, the system adds the additional service
and tariff to the transaction details displayed and reflects this in the total transaction
value.
¢ Option to Change the Quantity of Items Being Transacted
There is a default quantity of one for scales transactions. This may be varied before the
transaction starts (in the normal manner) or via this option. The quantity applies to the
whole set of basic and additional services selected. Once this option is completed, the
system changes the quantity in the transaction details displayed and reflects this in the
total transaction value.
¢ Option to Specify any ‘Pre-Paid’ Value
Any pre-paid postage is entered into the system via this option. Once this option is
completed, the system adds this information to the transaction details displayed and
reduces the total transaction value accordingly. The system assumes the pre-paid
postage applies to each individual item (if the quantity is greater than 1).
¢ Option to Calculate The ‘Best Fit’ Mix of Stamps Required
The best fit look-up table (aimed at minimising the number of visits to the stamp book
and the number of stamps used to fulfil the transaction) is used to determine stamp
selection for a required item transaction price. This data is supplied to EPOSS as
Reference Data. It includes first and second class stamps as well as general
denominations and is therefore subject to amendment when these change. The user is
prompted to affix the best fit of stamps to the item or each individual item if the
quantity is greater than 1.
6.4.1.2.4 Scales — Recording Transaction Details
Once all the required details have been entered/selected by the clerk, the system will add a
scales transaction to the stack plus separate transactions for the value of ‘1st class stamps’,
‘second class stamps’ and ‘postage stamps’ sold to support the transaction. The quantity of
items is used to derive the transaction value. The scales transaction itself is not displayed
on the stack unless the postage due is zero (i.e. the transaction is completely pre-paid).
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 39 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
The relevant stock holding values for ‘1st class stamps’, ‘second class stamps’ and
‘postage stamps’ are updated.
The system will assume ‘postage stamps’ if best fit was not used, otherwise the
combination of best fit stamps is used to derive the value.
A session receipt is available as usual.
The following information is recorded in the journal against the scales transaction:
= service;
= country of destination (if present)
= item weight
= additional services (if present)
= quantity
= postage pre-paid
= stamps used (best fit if used, otherwise ‘other stamps’)
The details of scales transactions may be retrieved using journal reports.
6.4.1.3 ZERO VALUE PRODUCTS
It is possible for the system to legitimately ‘sell’ products which have no value. Examples
of these types of product are Milk Tokens and the issue of Forms E111. The EPOSS
system caters for these types of product through the reference data supplied by POCL. For
such products the fixed price, minimum price and maximum price are all set to zero. The
system records a transaction of the current quantity (default 1) but for a value of ‘0.00’.
These transactions are stored and accounted for exactly as for other products.
6.4.1.4 USING THE QUANTITY FUNCTION
The default quantity applied by the system to product sales is ‘1’. If the user wishes to
vary the transaction quantity they may do so at any time during the transaction by selecting
the ‘Quantity’ button and entering an alternative value. The system will retain this value
only for the current (or next, if modified before selecting the product) transaction.
The quantity can also be varied by simply typing the required number on the keyboard
prior to selecting a product for sale (e.g. type the number 10, select the ‘First Class Stamp’
button - the system sells 10 First Class Stamps). When using this facility, the two (or
more) digits of the quantity must be typed within 2 seconds of each other, otherwise the
system will assume that each of the typed numbers is required to modify the quantity
individually. For example if the keys ‘2’ and ‘3’ are typed within 2 seconds, the quantity
will be changed to ‘23’, if the same keys are typed 3 seconds apart the quantity will first
be set to ‘2’ and then to ‘3’.
Maximum and minimum quantity limits are specified in Reference Data and described in
the Customer Service Transactions section above.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 40 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
6.4.1.5 SELLING PRODUCTS USING ‘SHOPPING’ MODE
‘Shopping’ mode allows the user to enter the total value that a Customer wishes to spend
on a particular fixed price product and the system then calculates the quantity of the
product that is nearest the entered value. e.g. the customer asks for £10.00-worth of First
Class Stamps. The system calculates the nearest quantity within the value (38 = £9.88),
indicates the additional value needed to buy a further 1 of the item and requests
confirmation from the clerk. The confirmation will be either to accept the system derived
quantity or to accept one more of the item for an additional payment over and above the
originally specified value.
The quantity may be input directly using the numeric keys on the keyboard or using the
quantity button via the subsequently displayed numeric keypad.
Having entered the quantity, transaction processing is described in the Customer Service
Transaction section above.
6.4.1.6 LINKED TRANSACTIONS
Where the POCL supplied reference data indicates that the sale of one product must be
accompanied by the sale of another product the system will identify the linked transaction
and carry out an automatic secondary transaction for the linked product. Where the linked
product has a default or open price, the user will be prompted for the entry of the unit
price and any other necessary additional data as for normal product sales as specified in
the Customer Service Transaction section above.
6.4.1.7 APPLYING DISCOUNTS
Discount functionality is not used by POCL at NR2.
Product Reference Data will control whether Staff Retail Discount is available for each
product.
Discounting is achieved using a specific Staff Retail discounting product which
accumulates into the Counters Revenue Schedule accounting node. Note: This product
may not be discounted itself.
When a discount is entered the resulting transaction will be linked to one or more existing
serve customer transactions on the stack (depending upon if it was an item discount or
session discount).
EPOSS also supports Customer Discount. The same functionality is provided as for Staff
Retail Discount. This feature requires POCL supplied Class C Reference data changes
before it can be implemented.
6.4.1.7.1 Discount Transaction Selection
Discounts are only available in Serve Customer mode. A separate sub-menu containing
the following buttons is provided:
¢ Discount on a Single Item by Value;
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 41 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
e Discount on a Single Item by Percentage;
e Discount on a Session by Value;
e Discount on a Session by Percentage.
Percentage discounts are calculated to the nearest penny in favour of the customer.
6.4.1.7.2 Item Discount Processing
There may be more than one Single Item Discount in a serve customer session.
The transaction to be discounted is the last one that was added to the stack. The system
checks the requested discount is allowed for the product in this transaction. The user will
be advised if the transaction is not discountable. The user inputs the discount value or
percentage discount required. For percentage discounts, the discount value is calculated as
a percentage of the discounted transaction’s sale value. The resulting discount transaction
is linked to the discounted transaction.
6.4.1.7.3 Session Discount Processing
There may only be a maximum of one Session Discount in a serve customer session.
The set of transactions to be discounted comprises any transactions currently on the stack
for which the requested discount is allowed. The user will be advised if there are no
discountable transactions on the stack. The user inputs the total session discount value or
percentage discount required. For percentage discounts, the discount value is calculated as
a percentage of the total discounted transactions’ sale values. The resulting discount
transaction is linked to all the discounted transactions.
6.4.1.7.4 Voiding
Voiding a discount transaction itself is straightforward as it is just removed from the stack.
Voiding a discounted transaction causes the discount transaction linked to it to be voided
as well. Note: The voided discount transaction may be an individual or session discount.
6.4.1.8 SESSION SETTLEMENT
The session’s running balance in the form of a settlement to be paid in or paid out will
always be displayed. The displayed total will provide a visual indication of whether the
balance is to be paid to the post office or paid out to the customer. The system will also
display a message to the clerk indicating whether the balance is to be paid out or collected.
When the settlement function is invoked, the system will present the user with a list of
available Methods of Payment (MoP). These MoPs will include:
© Cash;
e Fast Cash;
e Cheque;
e Fast Cheque;
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 42 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
¢ any other items identified as MoPs in the POCL supplied reference data.
If the user selects one of the special ‘Fast’ MoPs (Cash or Cheque), the total outstanding
balance of the customer session will be deemed to have been settled by this MoP. In the
case of ‘Fast Cash’ the system takes into account whether the balance was due to the
customer or to be collected by the clerk. The customer session balance will be reduced to
zero and the session will be deemed complete. In the case of ‘Fast Cheque’, the total
value of the session is deemed to have been paid by the customer as a Cheque. Note that
if ‘Fast Cheque’ is used when the balance of the session is owing to the customer then the
session balance will be increased by the same amount rather than being set to zero.
If other methods of payment are selected, the system will invite the clerk to enter the
amount of the balance being tendered for the selected MoP. The entered value will then
be deducted from the amount outstanding for the customer session and the session total
displayed at the bottom of the stack will be adjusted accordingly. The clerk may continue
selecting further MoPs and entering values. When all the appropriate MoPs and values
have been entered, if the session total is reduced to zero the session can be completed by
selecting the ‘finish’ button. If the value is not at zero this will be because there is still a
further payment to be made (this may, in fact, be ‘change’ for the customer if the entered
values exceeded the session balance).
Certain of the products on the Settlement menu relate to ‘Redeemed Savings Stamps.
These products can only be selected as a MoP if the current customer session contains a
product to which the redeemed savings stamp is associated (e.g. if MVL Stamps
Redeemed’ is selected, the system will check that the sale of an MVL was included in the
current session). This linkage is referred to as a ‘Mandatory Inclusive Pre-condition’. If
the mandatory inclusive pre-condition is not satisfied then a suitable error message is
displayed and the selection is refused.
In a later release of the software, the system will check that the selected MoPs are
allowable for the transactions contained in the customer session. To achieve this, the
software will calculate the total value for each allowable MoP from the transactions held
on the customer session stack. The allowable MoPs for each ‘product’ will need to be
identified in the reference data supplied by POCL. As each MOP is selected and entered,
the allowable value for that MoP (if any) will be reduced by the entered amount. In the
event that an amount is entered which exceeds the maximum allowed for the MoP, the
system will display an error message to the clerk and reject the entry.
6.4.2 REMITTANCES
Cash and Stock remittances represent the movement of cash and stock items between an
outlet and one of a number of external sources/destinations. The list of external
sources/destinations supported by the system is controlled by reference data and is
essentially:
© Supplies Division;
e Other Post Offices;
© Data Central (Outward remittances only);
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 43 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
e Client
The range of products that each of the 2 types of offices (London and Provincial) can
remit is constrained depending upon the office type and source/destination. A number of
transaction modes are provided to support this so that when a particular mode is selected
the proper range of products is made available.
The EPOSS Remittance functions provide the following facilities.
© Cash and Stock receipts.
© Cash and Stock returns.
e The automatic update of outlet cash and stock holding.
© Reporting and reconciliation of all cash and stock movements.
An Inward remittance will be conducted in the following way:
e The outlet manager (or nominated deputy) will make a written request to the supplying
agency for the items required;
e When the items are delivered, the user will carry out the ‘Remittance In’ option for the
appropriate source from the remittances sub-menu;
e The system will produce a printed report of the remittance items and values;
The value of the cash or stock remitted into the outlet will be recorded against the stock
unit used by the user at the time that the remittance session is carried out.
An Outward remittance will be conducted in the following way:
e The user will prepare a written request for the items and values to be sent to the
receiving destination;
e The user will carry out the ‘Remittance Out’ option, for the appropriate destination,
from the remittances sub-menu;
e The system will produce a printed report of the remittance items and values;
© The physical items and a copy of the Remittance Out report will be sent to the
receiving destination.
The value of the cash or stock remitted out of the outlet will be recorded against the stock
unit used by the user at the time that the remittance session is carried out.
6.4.2.1 REMITTANCE REQUEST
The Remittance Request Form is used to identify the provider (external unit) and recipient
(stock unit) of the quantity and value for each stock item to be taken in.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 44 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
6.4.2.2 REMITTANCE IN
The receiver will use the “Remittance In” function to identify the external source from
which the items are to be received and select and confirm the quantity and value for each
stock item to be received.
The process for identifying the items and quantities to be remitted will be similar to that
used for serving customers. The system will display a product menu hierarchy but with
the screen title changed to identify the activity as being ‘Remittance In from xxx’ - where
xxx is the external source from which the remittance is to be made. The product menu
hierarchy will contain only those items of cash and stock which are identified in the POCL
supplied reference data as ‘value stock’ and appropriate to the particular external source
selected. Quantities and items will be selected in the same way as for customer service.
Selected products will appear on the ‘stack’ and can be ‘voided’ if required. When all
required items have been selected, the remittance session is completed by selecting the
‘finish’ button at the bottom of the stack. This process generates remittance in
transactions and increases the levels of the selected items in the stock unit. The system.
then prints a report of the items and value remitted. The format of the report is specified
in the Horizon Reports and Receipts Specification.
6.4.2.3 REMITTANCE OUT
The provider will use the “Remittance Out” function to select the external source to which
the selected items are to be sent and confirm the quantity and value for each stock item to
be given out.
The process for identifying the items and quantities to be remitted will be similar to that
used for serving customers. The system will display a product menu hierarchy but with
the screen title changed to identify the activity as being ‘Remittance Out to xxx’ - where
xxx is the external source to which the remittance is to be made. The product menu
hierarchy will contain only those items of cash and stock which are identified in the POCL
supplied reference data as ‘value stock’ and appropriate to the particular external source
selected. Quantities and items will be selected in the same way as for customer service.
Selected products will appear on the ‘stack’ and can be ‘voided’ if required. When all
required items have been selected, the remittance session is completed by selecting the
‘finish’ button at the bottom of the stack. When this is completed a “Remittance Out”
report is printed. This process generates remittance out transactions and decreases the
levels of the selected items in the stock unit. The system then prints a report of the items
and value remitted. The format of the report is specified in the Horizon Reports and
Receipts Specification.
6.4.2.4 REMITTANCE DISCREPANCIES
Remittances in are entered into the accounts as per the paperwork received with them.
Any discrepancies are recorded separately via the Housekeeping function. Housekeeping
products are provided to support both discrepancy declaration and redemption:
e Remittance Discrepancy - Surplus
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 45 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
e Remittance Discrepancy - Short
e Remittance Discrepancy - Surplus Redeem
e Remittance Discrepancy - Short Redeem
6.4.3 INTERNAL TRANSFERS
Stock transfers represent the movement of cash and stock items between stock units.
The EPOSS Transfer functions provide the following facilities.
© Cash and Stock receipts.
© Cash and Stock returns.
e The automatic update of stock unit and outlet cash and stock holding.
© Reporting and reconciliation of all cash and stock movements.
The transfer will be conducted in the following way:
e The receiving user will verbally agree with the supplying user that the items can be
transferred.
e The supplier will carry out the ‘Transfer Out’ option from the transfers sub-menu.
e The receiver will carry out the ‘Transfer In’ option from the transfers sub-menu;
© Both receiving and supplying users will produce a printed report of the transfer items
and values;
¢ Both receiving and supplying users will sign each others’ printed reports;
e The supplier gives the receiver the agreed items.
6.4.3.1 TRANSFER REQUEST
This is a manual process.
6.4.3.2 TRANSFER OUT
The provider will use the “Transfer Out” function as follows:
e the user will identify the receiving stock unit from a picklist of available stock units
(the list includes only those SUs operating in the same CAP as the issuing SU) ;
e the system will check the source and destination stock units are working in the same
cash account period;
e the user will enter the products, quantities/values of the items to be transferred in a
‘transfer out session’ (similar to a serve customer session);
e the user may complete or abandon the ‘transfer out’ session. The latter is achieved by
voiding each transaction individually.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 46 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
© oncompletion of the ‘transfer out session’ the system will record the transfer
transactions in the journal;
© the system checks the source and destination stock unit CAPs again at this point;
e the session is automatically settled;
e the system will finally print a ‘Transfer Out’ report.
During the ‘Transfer Out’ session the system will display a product menu hierarchy but
with the screen title changed to identify the activity as being ‘Transfer Out to xxx’ - where
xxx is the stock unit to which the transfer is to be made. The product menu hierarchy will
contain only those items of cash and stock which are identified in the POCL supplied
reference data as ‘value stock’. Quantities and items will be selected in the same way as
for customer service. Selected products will appear on the ‘stack’ and can be ‘voided’ if
required. Alternatively, the whole session may be abandoned. When all required items
have been selected, the transfer session is completed by selecting the ‘finish’ button at the
bottom of the stack. This process generates transfer out transactions in the journal and
decreases the levels of the selected items in the stock unit. The system then prints a report
of the items and value transferred. The format of the report is specified in the Reports and
Receipts Functional Specification.
6.4.3.3 TRANSFER IN
The receiver will use the “Transfer In” function.
The system will display a list of ‘pending’ transfers with detail of the originating stock
unit, transfer session identifier and total value.
The user will be able to:
© to select and view (but not modify) the contents of a transfer;
e print the contents of the transfer;
e ‘accept’ the contents of the transfer;
e ‘abandon’ the process if they decide not to continue.
The system will create the necessary ‘transfer in’ transactions for an accepted transfer and
increase the levels of the transferred items in the stock unit.
The format of the Transfer In report (to be viewed or printed) is specified in the Reports
and Receipts Functional Specification.
6.4.3.4 TRANSFER RECONCILIATION
A weekly report (at Office level) is available to allow the outlet manager to view the
transfers between stock units within the current Cash Account period. This report
identifies any pending transfers. Pending transfers must be resolved before the stock units
involved in the transfer can balance for the week.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 47 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
6.4.3.5 TRANSFER AVAILABILITY
It is not possible to perform a transfer out to the DEFault stock unit.
It is possible to transfer to an “inactive” stock unit: a stock unit that has no activity for the
week other than a pending transfer may not be “dormant” rolled whilst the transfer is
pending; if the transfer is accepted then dormant roll is still prohibited but if the transfer is
reversed (at source) then dormant roll will be allowed.
It is possible to transfer out to a stock unit that is operating on an isolated node: the SU
will not be notified of the pending transfer, this will not result in an irretrievable position
as the target SU is not permitted to balance while operating on an isolated node. However,
the source stock unit will not be able to balance until the pending transfer is cleared (at a
connected node). Transfers out are not permitted from an isolated node.
6.4.4 REVERSALS
A function will be provided to reverse transactions, providing that the product being
reversed is identified in the POCL supplied reference data as reversible. A reversal will
not result in the deletion of transaction information from the message store. A reversal
will effectively involve the insertion of an additional compensating transaction for the
same product with an equal and opposite accounting value. It is envisaged that all
transactions can be reversed at any time during the current cash account period unless
specifically prohibited by reference data which indicate otherwise. Transactions are posted.
to the journal with 'Reversal' mode.
6.4.4.1 NEW REVERSALS / REFUNDS
Selecting the New Reversal product from the Reversals menu causes the desktop to enter
Reversal/Refund transaction mode and a Serve Customer style menu hierarchy to be
entered. New reversals are processed using the same functionality as for normal serve
customer transactions except that they are written to the journal with the opposite sign to
that which their corresponding serve customer transaction would have. Any number of
product transactions may be added to the reversal/refund session which is balanced using
normal settlement products.
The same controls as for Serve Customer on quantity and value maximums and minimums
are applied.
New Reversal transactions have the mode of ‘Reversal’.
6.4.4.2 EXISTING TRANSACTION REVERSALS
Transactions created in any EPOSS mode (except Transfers) within the current CAP may
be reversed (if permitted by product reference data) . They must be reversed using the
same stock unit as was used in the original transaction.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 48 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
The user uses Transaction Log Reports to identify the transaction in the transaction
journal. Selecting the Existing Reversal product from the Reversals menu causes an input
screen to be displayed. The user enters the node and transaction reference in 2-8 format to
select the transaction to be reversed. Leading zeros need not be input. Erroneous input
must be re-entered again from scratch.
Each existing reversal is added to the session which is balanced to cash.
When a transaction is reversed using this method the ‘reversing’ transaction will be stored
with a cross-reference to the original transaction which has been reversed. It will also have
the mode of 'Existing Reversal’,
Transactions may only be reversed once.
6.4.4.2.1 Linked Transactions
Both parts of an original linked (mandatory associated) transaction bear the same
transaction reference and are reversed together when this reference is input. Any receipt
produced will show all the individual transactions that were reversed.
6.4.4,.2.2 Discount Reversals
Reversing a discounted transaction causes the discount transaction linked to it to be
reversed as well.
6.4.4.2.3 Remittance Reversals
This is effected using the Existing Reversals function. The user identifies the original
remittance transactions using the Journal Log reports as for other Existing Reversals and
enters the appropriate transaction reference for each remittance item that is to be reversed.
When the session is completed, a compensating remittance transaction is generated purely
to balance the session.
6.4.4.2.4 Transfer Out Reversal
This is effected using the Transfer Reversals function.
The whole session needs to be reversed so the user enters the original Transfers Out
session reference. Stock levels in the stock unit are increased for the stock involved.
The system displays details of the transfer being reversed. The user may confirm or
abandon the reversal. A receipt is produced automatically.
Reversal of a Transfer Out changes a dormant destination SU's status to active.
Once the receiver has accepted a transfer it may not be reversed.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 49 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
6.4.4.3 REVERSAL RECEIPTS
Receipts for Reversal/Refund sessions are available via the Serve Customer menu
hierarchy.
6.4.5 RECOVERY MODE
This function enables the user to enter multiple transactions as a single entry, with the data
being recorded as having been entered in ‘fallback’.
The bulk input function is provided for circumstances where there has been a loss of
service for a considerable period of time, during which serve customer transactions have
been carried out manually. Following a return to service there is a need to enter the
‘manual’ transactions into the system. The Recovery facility allows this to be done as a
single transaction for each type of product sold and also ensures that the transaction
messages which result from Recovery carry the attributes necessary to identify them as
being carried out as a ‘recovery’ activity. During ‘Recovery’ the normal validation rules
against products for minimum, maximum and multiple quantities and minimum,
maximum and multiple values (defined in the POCL supplied reference data) are
suspended.
Transactions which by their nature require the provision of additional items of information
(such as an account number for a Girobank Deposit or Withdrawal) require to be re-input
individually, although this may be achieved when in recovery mode so as to ensure that
the records are appropriately marked.
In other respects, the way in which a ‘Recovery’ session is handled is identical to that for a
customer session as described in the Serving Customers section above except that multiple
transactions for a product within a session are accumulated into a single stack item for that
product.
6.4.6 LOCAL SCHEMES
For the input of both Local Rent and Local Travel Scheme transactions refer to the
Selling Products Using Pick Lists section above.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 50 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
7.
7.1
7.2
7.3
WEEKLY TRANSACTIONS
HOUSEKEEPING
Housekeeping is a general term used to group together a variety of office level suspense
account and other transactions covering:
National Savings Error Notices - Deposits & Withdrawals
Giro Error Notices — Receipts and Withdrawals
POCL Error Notices - Receipts and Payments
Pre-purchase - posting and redemption
Surpluses and Losses (Shortages) — posting and redemption
Loan to Post Office and Loan to Post Office Withdrawn
Remittance Discrepancies (Surplus or Shortage) posting and redemption
Final Account Surplus or Deficiency
Unpaid Cheque posting and redemption
Voucher posting and redemption
HOUSEKEEPING TRANSACTION PROCESSING
Transactions have a default quantity of one, a value and optional additional details such as
account reference. The resulting transaction is placed on the desktop stack. As long as the
transaction doesn’t require additional data, the quantity can be changed using the quantity
button or by entering the quantity prior to transaction selection. Further adjustment
transactions can be carried out until all available transactions have been processed, at
which point the user should select the ‘Finish’ button at the bottom of the desktop ‘stack’.
At this point the individual error notice transactions are written to the message store and a
compensating adjustment is made to the level of Cash in the stock unit.
Receipts are available via the Serve Customer menu or the ‘Receipt’ button on the
keyboard.
ERROR NOTICE PROCESSES
Uses suspense account products as follows:
Error notice products will allow an authorised user to apply adjustment transactions as
required for the office balance process. Adjustments will include the bringing to account
of Error Notices (either POCL or Client), the transfer of values to the ‘Suspense Account’
and the removal of items from the Suspense Account.
7.3.1 RD CHEQUES (HANDLING OF )
Uses suspense account products as follows:
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 51 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
7.4
7.5
Unpaid Cheques and Vouchers are value stock products. They are remitted into the office
(i.e. into a stock unit).
Unpaid Cheques and Vouchers in a stock unit must not be carried over between balance
periods and must therefore be posted to suspense until they are resolved. This means the
value of Unpaid Cheques and Vouchers must be zero before a stock unit is allowed to
balance.
Four additional EPOSS value stock products are provided to facilitate the movement of
Unpaid Cheques and Vouchers to and from the suspense account (Post Unpaid Cheque to
Suspense and Redeem Unpaid Cheque from Suspense and the same for Vouchers). These
transactions will be available under the House Keeping / Adjustments menu (see above).
The housekeeping transactions move cash to and from suspense. The user has
subsequently to adjust the product stock holding, e.g. Unpaid Cheques, which generates a
cash adjustment to compensate for the initial housekeeping one to complete the process.
OFF-LINE EPOSS TRANSACTIONS
The totals of transactions recorded on other counter systems, such as Camelot terminals,
Bureau de Change terminals and AP terminals are entered on EPOSS as single customer
service transactions at the end of each day or week.
NON-ACCOUNTING DATA
In addition to the accounting data reported on the Cash Account there is also a need to be
able to report certain ‘non-accounting’ data on the report. This data is primarily
concerned with recording the volume of business for designated clients (such as Royal
Mail). These facilities are necessary because the required data is not always capable of
being derived from the transaction messages in the message store (e.g. when a Royal Mail
transaction is conducted the transaction is paid for by the sale of stamps). Other non-
account data includes Parcelforce Compensation Fees, Camelot Vouchers, Custody of
Postman’s Pouch and Lombard Business Information.
The ‘Non-Accounting’ option on the transactions sub-menu provides the facility to enter
such data within one of the stock units prior to the production of the final stock unit
balance of the week. By the nature of this function, no alteration is made to the value of
the cash and stock in the stock unit as a result of these entries.
These transactions (volumes) are reported in table 10g on the Cash Account.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 52 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
7.6 PARCEL TRAFFIC
As for the entry of ‘Non-Accounting’ data, there is a similar need to identify the volumes
and values associated with business transacted on behalf of Parcelforce (Royal Mail and
Parcelforce are separate companies within the Post Office Corporation). Postage stamps
are also used to make payment for Parcelforce services transacted across the counter,
therefore there is a need to identify the quantity and value of the business transacted for
Parcelforce as distinct from that for Royal Mail.
The ‘Parcel Traffic’ option on the transactions sub-menu provides the facility to enter such
data within one of the stock units prior to the production of the final stock unit balance of
the week. By the nature of this function, no alteration is made to the value of the cash and
stock in the stock unit as a result of these entries.
These transactions (volumes and values) are reported in table 12 on the Cash Account.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 53 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description BP/FSP/004
40
5/3/99
8. REPORTING
This section describes the Reporting functionality provided.
The range and the format of counter reports will be specified in the Horizon Reports and
Receipts Specification. The facility will be provided to produce reports using data
extracted by stock unit or user as well as by day, time, and date.
8.1 PRODUCTION OF CLIENT DAILY/WEEKLY REPORTS BY STOCK
UNIT
The following set of reports is representative of the daily output which is expected to be
produced:
8.1.1 COUNTERS DAILY REPORTS
Girobank Deposits
Girobank Withdrawals
BT Bills
APS Transactions
National Savings Deposits
National Savings Withdrawals
UK Passports
Daily Cash Declared
Cheques Listing
OB Cheque
8.1.2 USER DAILY REPORTS
BT Bills
APS Transactions
OB Cheque
Cheques Listing
UK Passports
8.1.3 COUNTERS WEEKLY REPORTS
Pensions and Allowances Weekly
Green Giro
Postal Order Encashment
DVLA V11
DVLA V10
Rent Schemes
Bus Tokens
BPFSP004.doc COMMERCIAL IN CONFIDENCE
© ICL Pathway 1999
Page 54 of 117
ICL Pathway EPOSS Functional Description
Ref:
Version:
Date:
FUJ00079277
FUJ00079277
BP/FSP/004
4.0
5/3/99
Transfers In
Transfers Out
Transfers Summary
Stock on Hand
Remittances In
Remittances Out
Remittances Summary
Infrequent Use/Unsummarised Transactions
8.1.4 USER WEEKLY REPORTS
8.2
Pensions and Allowances Weekly
Green Giro
Postal Order Encashment
DVLA V11
DVLA V10
PRODUCTION OF OFFICE DAILY/WEEKLY REPORTS
The following set of reports is representative of the weekly output which is expected to be
produced:
8.2.1 OFFICE DAILY
Giro Deposits
Giro Withdrawals
BT Bills
Remittances In (Daily)
Remittances Out (Daily)
National Savings Deposits
National Savings Withdrawals
UK Passports
8.2.2 OFFICE WEEKLY
Green Giro and MT
Remittances in (P)
Remittances Out (P)
Pensions and Allowances P2311MA
Pensions and Allowances P2311MA(B)
Redeemed Savings Stamps
Sales Report
Postal Orders Encashed
Counters Revenue
Suspense Account
BPFSP004.doc COMMERCIAL IN CONFIDENCE
© ICL Pathway 1999
Page 55 of 117
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
e Cash Flow
e Transfer Total
e Transfer Reconciliation
8.2.3 REPRINTS OF OFFICE REPORTS
Office reprints may only be accessed by users with the correct access levels for the
original reports.
Reprints will be available for the present and previous CAP the office is currently
operating in.
The following set of office reports may be reprinted:
Cash Account Report
Office Balance Report
Pensions and Allowances P2311MA.
Counters Revenue
Redeemed Savings Stamps
8.3. THE REPORT PRODUCTION PROCESS
Reports are produced generically.
Selection criteria, which may contain variable parameters to be supplied by the user, are
used to drive the data retrieval process.
During the retrieval process, totals for nodes in the accounting node hierarchy are derived
for subsequent inclusion in the report if required.
Pre-defined report formats are used to drive the report writing process. Reports may have
several sections each with different data selection criteria.
The pre-defined selection criteria, report formats, necessary user interface buttons and data
capture screens are defined as Reference Data.
8.3.1 TRANSACTION DATA
Repeated from a previous section.
Reports are based on raw transaction and event data. The core attributes of transactions
are:
unique transaction identifier;
unique customer session identifier;
date and time of transaction;
product number sold;
value;
quantity;
user ID;
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 56 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
terminal node identifier;
stock unit identifier;
group number (= FAD code);
accounting node for the product (for balancing and reporting purposes)
8.3.2 ACCOUNTING PERIODS
Transactions are written serially to the journal. Markers placed in the journal define the
boundaries of Cash Account Periods and Balance Periods for each stock unit (as if one
were ruling off the cash book in a paper based system at the end of a period). Further
markers, also written serially to the journal, define the Cash Account Periods for the office
level accounts.
8.3.3 CLIENT REPORT CUT-OFFS
It will be possible to declare a cut-off for each client report, including APS client
transactions. This will serve to control the production of client reports.
Both Stock Unit and Office reports may be cut off.
The option to produce a ‘cut-off’ report will not be allowed if the report is being produced
for a portion of stock unit (‘By User’ reports), since cut-off reports are intended to mark
all the transactions from the stock unit, not just those for a particular user.
When a client report is produced the user will be given the option to declare the printed
report as a ‘cut-off’ (but note the exception above regarding reports for a portion of a
stock unit). If this option is taken, the system will write a marker to the journal to mark
the point in the journal that the cut-off was declared. Any future invocation of the report
for the same stock unit will omit transactions which took place prior to the last ‘cut-off?
marker for that report for the current stock unit (or office, if the report is being produced at
office level).
The ‘cut off” process is not reversible.
Client reporting periods are primarily bounded by Cash Account and Balance Periods.
Client reports must be cut-off after all relevant transactions have been entered for a
balance period to ensure there are no unreported transactions in the period. Thus, a stock
unit cannot be balanced if there are outstanding client reports.
8.3.4 SUB-STOCK UNIT REPORTING
Stock unit client reports may be filtered by user. The purpose of these reports is to enable
each clerk to check and sort their dockets against an individual report for the current client
reporting period, i.e. up to the period cut-of point. To ensure a common basis of client
reporting between the clerks sharing a stock unit the cut-off must be made for the whole
stock unit before any individual reports are prepared. Thus sub-stock unit reports
essentially re-present the data from the previous client reporting period for the particular
Teport.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 57 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
The user selects the required report and then identifies the required user from a pick list of
users.
Sub-stock unit reports may be prepared at any counter position, i.e. not necessarily one
that is currently working the subject stock unit.
Sub-stock unit reports do not span more than one stock unit.
8.3.5 DATA SELECTION CRITERIA
Report data is usually selected primarily by office or stock unit and secondarily by Cash
Account or Balance Period.
To report on the raw transactions in a Cash Account Period for the whole office we need
to select the transactions in the message store bounded by the Cash Account Period
markers for each individual stock unit, and not those bounded by the office Cash Account
Period markers.
Other core transaction attributes may be specified as selection criteria e.g. user ID ,
accounting node etc.
Pre-defined data selection criteria are provided through Reference Data to retrieve the data
for each class of report required. Some selections criteria have variable parameters, values
for which can be supplied by the user at run time. There is no all purpose report with
totally variable selection criteria as its performance would be unpredictable.
8.3.5.1 ACCOUNTING NODES
Once the scope of the report has been defined, using office, stock unit, CAP, BP, user,
terminal node parameters as required, accounting nodes are the next key selection criteria.
This subject is explored in detail in a document EPOSS/Reference Data - EPOSS Cash
Account Implementation.
The Accounting Summarisation Hierarchy (or Accounting Node Hierarchy) defines the
static hierarchical structure about which reporting of product transactions will be made.
The structure is represented as a set of Nodes structured in Levels defined as Reference
Data.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 58 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Accounting Node Hierarchy
Level 5 Balance Node . Root Node
Level 4
Level 3 wa an a
INode ta.
INode Description
Level 2
Ey Leaf Nodes
The Accounting Node Hierarchy is constrained to 5 levels. Product transactions normally
map into level 1.
Other reference data defines, for each transaction mode, the different level 1 accounting
nodes to which each type of product transaction is to be posted when it takes place.
Note: EPOSS implements 2 accounting node references (primary & secondary) in
transaction records - this is purely for performance reasons and can be ignored in this
document.
As part of report production, quantity and value totals plus transaction counts for each
node in the accounting node hierarchy are accumulated from the values in the selected
transactions. In this way, the totals of the nodes in the hierarchy for the selected
transactions are prepared for potential use by the subsequent report writing stage.
8.3.5.2 CASH ACCOUNT MAPPING & NODE HIERARCHY
This subject is explored in detail in a document EPOSS/Reference Data - EPOSS Cash
Account Implementation.
The Cash Account Mapping defines for each product the static hierarchical structure from
which the Cash Account report is produced.
The structure is represented as a set of Nodes structured in Levels defined as Reference
Data.
The Cash Account Mapping Reference Data defines, for each transaction mode, up to two
cash account lines to which each product transaction is to be reported. One line may report
value and the other quantity.
The Cash Account Node Hierarchy is constrained to 7 levels. Product transactions may
map into any level.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 59 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
As with the Accounting Node Hierarchy, as part of report production, quantity and value
totals for each node in the Cash Account Node hierarchy are accumulated from the values
in the selected product transactions. In this way, the totals for nodes in the hierarchy for
the selected transactions are prepared for potential use by the subsequent report writing
stage.
8.3.5.3 DYNAMIC ACCOUNTING NODES
Report specific dynamic accounting nodes may be defined over and above the Accounting
Node and Cash Account Node Hierarchies. Quantity and value totals plus transaction
counts are also accumulated for these.
The dynamic nodes provide for the accumulation of data in specific groupings, e.g. a
dynamic node may group all products being reported by date or by stock unit or by date
within stock unit. The dynamic nodes effectively provide the sorting and sub-totalling
facilities for the report writer.
8.3.6 THE GENERIC REPORT WRITER
An overall report definition is constructed from one or more report section definitions to
be output in a specified sequence.
This approach enables report section definitions to be reused, e.g. for trial and final
balance reports where only the heading changes.
Each section defines the position of data items on the page and their data source from
either transaction records or accounting nodes.
Individual reports are always constructed from raw transaction data and not from previous
reports.
Any Reversals are presented with a negative sign on volume and value and make a
negative contribution to any totals. Settlements may also have a negative sign.
The date on the report is the current date.
The CAP on the report is the current stock unit CAP (or Office CAP for Office reports).
Some reports (e.g. Cash Account) require visibility of nil entries for volume and value.
Others (e.g. receipts for mail) require zero suppression.
Girobank client summaries limit the number of transactions in a single report. If there a
are more than the specified maximum, further reports will be produced. Each report
includes its own summary totals if required.
8.3.7 PRINTING, PREVIEWING AND COMPLETING REPORTS
Reports and receipts are produced either automatically or through user invoked actions.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 60 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
After the system has pre-processed the report data, the user will be invited to Print,
Preview or Complete the report. Printing causes the report to be output to the printer (tally
roll or back office) designated in the report definition. Previewing causes the report to be
output on the screen. Facilities for paging through the report (up and down) are provided.
Finally, the user exits from the printing function using the Complete button. Reports are
not saved to the message store.
Note: the Final Cash Account Report is stored as messages (not report text) in the
message store for transmission to TIP. This is a special function for this report only.
Reports are printed on the tally roll printer or office printer as directed for the particular
report.
Reports may be printed on cut sheets. In this case, where an office copy is also required,
all the cut sheets are printed first followed by the office copy on tally roll stationery.
If the required printer is unavailable, the report is automatically previewed.
8.4 SOME SPECIFIC REPORTS
8.4.1 DISCREPANCIES REPORT
The stock unit declaration process may generate discrepancies which may subsequently be
confirmed as losses or gains. Several varieties of the Stock Unit Discrepancies are
provided:
The report is available on demand.
It is run automatically after any individual stock unit declaration to view any discrepancies
caused by the declaration just made.
It is run early in the balance report process to list any discrepancies. The user is invited to
confirm the whole list of losses and gains displayed.
The report may be viewed but not printed.
8.4.2 DAILY CASH ON HAND
The system also provides for the declaration of cash on hand at the end of every day to
ensure that there is a cash locked up figure for all stock units. The Log on function will
provide a warning to the user (at the start of the next day) if no declaration of daily cash
locked up has been made for the stock unit on the previous day. Declarations of ‘Cash
Locked Up’ will not be used as part of the balancing process.
This must be done every day, even when the stock unit is not being balanced.
If the user misses a day there is no facility for entering previous day’s figures except at
login when yesterday’s figures may be input. If no declaration was made for the stock unit
the system prompts the user to make an ONCH declaration.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 61 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
8.4.2.1 INDIVIDUAL STOCK UNIT- DAILY CASH DECLARATION
The user selects the Daily Cash Declaration Report from the Counters Daily Reports
menu.
The system presents the user with an editable picklist of cash denominations. The amount
for each item is initially set to zero. The user enters the amount of each denomination held
in the stock unit. This task is completed using the Finish button.
If the total of cash doesn’t match the system derived figure, the user is presented with a
discrepancies screen. The user may confirm the discrepancy or return to the desktop which
voids the declaration completely.
The user may now Print or Preview a report of the declaration and is finally asked to
confirm the declaration using the Complete button.
The whole process may be repeated during a particular day with the latest declaration
replacing the previous one for the day in question.
An incorrect declaration is removed by replacing it with a nil, or otherwise valid,
declaration.
8.4.2.2 SHARED STOCK UNIT - DAILY CASH DECLARATION
The user selects the Daily Cash Declaration Report from the Counters Daily Reports
menu.
The system presents the user with an editable picklist of cash denominations. The amount
for each item is initially set to zero. The user enters the amount of each denomination held
in the stock unit. This task is completed using the Finish button.
The user enters a declaration ID.
As this is potentially a partial declaration of the cash held in the stock unit the system does
not check for any discrepancies.
The user may now Print or Preview a report of the declaration and finally asked to confirm
the declaration using the Complete button.
The whole process may be repeated during a particular day with the latest declaration
replacing the previous one with the same declaration ID for the day in question.
An invalid declaration is removed by replacing it with a nil, or otherwise valid,
declaration.
8.4.2.3 OFFICE REPORT - WEEKLY CASH FLOW
In selection of this report, the system displays a list of this weeks ONCH Declarations
showing the stock unit, declaration ID, date time, user ID and node ID for each individual
declaration or a report if no declarations were made this week.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 62 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
The user is asked if they wish to continue with the report production. The system then
produces a daily office aggregation of total cash on hand - one line per day (Thursday to
Wednesday, excluding Sunday).
The report incorporates all of this weeks individual and shared ONCH declarations.
Where a stock unit ONCH declaration is missing, the previous day’s value is carried
forward. Carry forward operates within and across CAP boundaries. Declarations are
carried forward in perpetuity until a new declaration is made. This also applies to partial
declarations on shared stock units where each declaration ID is carried forward.
The report format is defined in Reports and Receipts.
8.4.3 JOURNAL REPORTS
8.4.3.1 USE OF EVENT LOGS
A variety of events (messages defined in Reference Data) are written to the journal along
with transactions as they occur. These events form the Event Log. The information is
available in the outlet for 2 complete POCL Outlet Accounting Periods.
There are a set of Event Log reports accessed via the Reports menu in the normal way.
The user is invited to select from the set of available reports and to vary the parameters in
the data selection criteria. Depending upon the particular report, these currently include:
Criteria Data Entry
CAP numerics (99)
Date From date (dd/mm/yy)
Date To date (dd/mm/yy)
Start Date date (dd/mm/yy)
Stock Unit select from list.
User select from list or enter user name
A button is provided to display the current selection criteria.
Clerks may access their stock unit event log. Managers and auditors can access all event
logs in the outlet.
The available report formats and data selection criteria are specified in Horizon Reports
and Receipts. These currently include:
Report Criteria
All Events Date To; Date From.
Balancing Date To; Date From.
Office Balance CAP.
Stock Unit Balance CAP; Stock Unit.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 63 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Reports Date To; Date From.
Confirm Reports CAP; Stock Unit.
Report Produced CAP; Stock Unit.
Stock Unit Users Date To; Date From.
Stock Unit Date To; Date From.
User Date To; Date From.
User Maintenance Date To; Date From.
Attach User To Stock Unit CAP.
Access Control Date To; Date From.
User Summary All Users (fixed criteria)
User History Start Date; User or All Users if left blank
User Events Start Date; User or All Users if left blank
8.4.3.2 USE OF TRANSACTION LOGS
Transactions are written to the journal as they occur. These transactions form the
Transaction Log. The information is available in the outlet for 2 complete POCL Outlet
Accounting Periods.
There are a set of Transaction Log reports accessed via the Reports menu in the normal
way.
The user is invited to select from the set of available reports and to vary the parameters in
the data selection criteria. Depending upon the particular report, these currently include:
Criteria Data Entry
CAP. numerics (99)
Date From date (dd/mm/yy)
Date To date (dd/mm/yy)
Mode select from list.
Session ID numerics (99-99999)
Stock Unit select from list.
User select from list.
Value From signed value (99,999,999.99)
Value To signed value (99,999,999.99)
A button is provided to display the current selection criteria.
Clerks may access their stock unit transaction log. Managers and auditors can access all
transaction logs in the outlet.
BP; CAP; Date From; Date To; Mode; Session ID; Stock Unit; Time From; Time To;
User; Value From; Value To.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 64 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
The available report formats and data selection criteria are specified in Horizon Reports
and Receipts. These currently include:
Report Criteria
Customer Query Date From; Date To; Stock Unit; User; Value From; Value
To.
Summary Query CAP; Session ID; Stock Unit; Value From; Value To.
Balance Current Mode; User; Value From; Value To.
Balance Select CAP; Mode; Stock Unit; User; Value From; Value To.
Audit Query Date From; Date To; Stock Unit; User.
Reversal Query Date From; Date To; Stock Unit; User; Value From; Value
To.
Traffic Query Session ID; User.
Stock Movement Mode; Session ID; Stock Unit; Value From; Value To.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 65 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
9. THE ACCOUNTING PROCESS
Accounting in the office is carried out at two levels, Stock Unit and Office.
At the stock unit level the primary accounting process is the production of the stock unit
balance report. This report is required to be produced at the end of each ‘Balance Period’
(BP). A balance period is an arbitrary period (not greater than one cash account period)
and represents the period since the last balance was declared. There may be one or more
stock unit balance periods with a single Cash Account Period (CAP). The stock unit
balance records the details of the current holdings of stock and cash and all the receipts
and payments which have occurred since the last balance was declared. The Office
Balance is run once per CAP.
Cash Account Periods are nominally 1 week however, to allow for holidays etc. 2/3 week
periods are also required. Cash Account Periods are defined by POCL Reference data.
The Office Balance is the summary statement of the all the Stock Unit balances in the
outlet for the current CAP. The Office Balance is produced only once per CAP and
reflects the state of the stock unit balances at the end of the CAP. A facility is also
required to take a ‘snapshot’ view of the office balance at any time during the CAP.
The Cash Account is the formal report of the accounting position for an outlet and is
produced once for each CAP. The report includes a summary of all the stock unit data in
the outlet (but at a different level of granularity to the Office Balance) and also includes
the report of the current position of the outlet Suspense Account which is maintained at
outlet level rather than stock unit level.
9.1 THE STOCK UNIT BALANCE FORM
Currently, the stock unit balance is represented by the paper balance form. This balance
form consists of four approximately A4 size pages of tables which provide a summary of
the clerk’s activities during the stock unit balance period. A copy of this form is also used
as the office balance form and this is the amalgamation of all counter balance forms in a
Cash Account Period. The current balance form is represented by the following diagram:
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 66 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Page 1 Page 2
Page 3 Page 4
9.2 THE MANUAL STOCK UNIT BALANCING PROCESS
The following diagram shows a simplified balance form:
BPFSP004.doc COMMERCIAL IN CONFIDENCE
© ICL Pathway 1999
Page 67 of 117
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
‘BROUGHT
FORWARD Receipts (R) }Payments (P)_) I Stock and Gash (S)) 2
Md
[Transactions _I
Declare/Contirm
‘Transfers and Roms
NW
‘Transfers and Rams
The balance is worked out as follows:
Total Receipts = Total Payments + Discrepancies, where:
Receipts = Table of all receipt transactions including:
e the total transactions for each product
e the balance brought forward (i.e. the total stock and cash on hand at
the beginning of the stock unit balance period)
total of stock transfers and remittances in
Payments = Table of all payment transactions including:
e the total transactions for each product
total of stock transfers and remittances out
¢ total stock and cash on hand
Discrepancies = Loss or gain (adjustment that needs to be introduced in order to balance).
Note
Tha Balance Carried Forward figure on the balance report represents the value of the Total
Cash and Stock plus the discrepancies to be carried forward to the next stock unit balance
period.
The Balance Brought Forward figure on the balance report is the Total Cash and Stock on
Hand figure from the previous stock unit balance period. The brought forward
discrepancies are recorded in the ‘Discrepancies in the Account’ box at the top of the
balance form if they have not been cleared within the current balance period.
BPFSP004.doc COMMERCIAL IN CONFIDENCE
© ICL Pathway 1999
Page 68 of 117
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
9.3 EXAMPLE
The following example will show how the balance process works.
9.3.1 OPENING STOCK ON HAND
Product Value
Stamps 100.00
Cash 1000.0
0
Total 1100.0
ie}
Transactions
Product Value
Stamps bought 10.00
Cash in +10.00
Pension paid 100.00
Cash out -100.00
DNS Deposit 50.00
Cheque in +50.00
Giro Withdrawal 20.00
Cash out -20.00
Child Benefit 10.00
paid -10.00
Cash out
Bill Payment 70.00
Cash in +70.00
9.3.2 BALANCE FORM
Receipts Payments Stock/Cash on Hand
Product Value Product Value Product Value
Brought 1100.00 Cash 950.00
Fwd
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 69 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
DNS Dep 50.00 Pension 100.00 Cheques 50.00
Bill 70.00 Child 10.00 Stamps 90.00
Payment Benefit
Giro Withdl 20.00
Stock/Cash I 1090.00
Total 1220.00 Total 1220.00 Total 1090.00
9.3.3 BALANCE CALCULATION
Total Receipts (1220.00) = Total Payments (1220.00)
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 70 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
10. STOCK UNIT DECLARATION (ADJUST/DECLARE
STOCK/CASH)
10.1 DATA ENTRY
The volumes and values of stock holdings are entered using Editable Pick Lists described
elsewhere in this document. Where an item of stock is of fixed price, entry is of quantity
only. Where an item is of variable price, the entry is of value.
10.2 SHARED STOCK UNIT DECLARATION
10.2.1 DECLARE CASH ON HAND (SHARED STOCK UNITS)
This function allows users to declare the actual physical stock unit contents for each cash
denomination.
Declaration of the Cash will be achieved by the display by the system of a list of the Cash
(denomination) items. The system will not display the value currently calculated by the
system for the items. The user will select the items one at a time and enter the value of the
stock actually held in the stock unit. The data may be entered in-situ or by selecting the
‘Edit’ option and using the numeric key pad display.
The system checks that the amount input is divisible by the denomination value.
When the declaration is complete the user must enter a I or 2 digit declaration identity
(identifies the portion of the stock unit being declared). For consistency of reporting, each
portion of a stock unit which is being shared should use separate declaration ID and must
continue to use that same ID throughout a Cash Account Period. It should be noted that
the declaration ID is specific to the PORTION OF THE STOCK UNIT and not to the user.
This identity also allows the user to re-declare later if necessary (a subsequent declaration
replaces the current one). The allocation and management of declaration IDs is a manual
process.
The facility to print a Cash on Hand Report is available on request when the process is
finished. It will produce a report of all of the cash denominations that were declared for
the portion of the stock unit. In the event that the printer is not available at the time, an
option to print the report to the screen for transcription to a manual form will be provided.
Declarations may be abandoned using the ‘Previous’ key. No data is committed to the
journal.
10.2.2 DECLARE STAMPS ON HAND (SHARED STOCK UNITS)
As per Declare Cash on Hand (shared stock units) described above but for stamp
denominations.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 71 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
A Stamps on Hand Report is printed on request at the end of the declaration.
10.2.3 DECLARE STOCK ON HAND (SHARED STOCK UNITS)
As per Declare Cash on Hand (shared stock units) described above but for stock items
excluding cash and postage stamps.
The user will enter quantity for fixed price products and value for open price products.
A Stock on Hand Report is printed on request at the end of the declaration.
10.2.4 DECLARATION DISCREPANCIES (SHARED STOCK UNITS)
Shared stock unit item discrepancies cannot be calculated until all shared stock unit
declarations have been input. Because of this, they are not confirmed as losses or gains
until early in the Balance Report process (see below). Discrepancies from declare stock,
declare stamps, declare cash and adjust stock are confirmed at this time.
There is no limit to the number of declarations that can be made in a BP. Subsequent
declarations that have an existing declaration ID override previous ones made during this
balance period.
10.2.5 ADJUST STOCK ON HAND (SHARED STOCK UNITS)
This function may not be used for declaring shared stock units’ stock holdings, but is
available for entering adjustments.
See Adjust Stock on Hand (Individual Stock Units) for functionality.
Cash is excluded. The total for Postage Stamps may be adjusted (i.e. not denomination
level).
10.3 INDIVIDUAL STOCK UNIT DECLARATION
10.3.1 DECLARE CASH ON HAND (INDIVIDUAL STOCK UNITS)
Declaration of the stock will be achieved by the display by the system of a list of the cash
denominations. The system will not display the value currently calculated by the system
for the items. The user will select the items one at a time and enter the value of the stock
actually held in the stock unit. The data may be entered in-situ or by selecting the ‘Edit’
option and using the numeric key pad display.
The system checks that the amount input is divisible by the denomination value.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 72 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Unlike shared stock units however, the complete cash value for the stock unit is declared
so any discrepancy can be calculated straight away. After finishing the declaration the user
is invited to view any cash discrepancy as a potential loss or gain. The user may confirm
the discrepancy or return to the desktop in which case the declaration is voided. The
system records any accepted discrepancies for future integration into the stock unit and
office balance.
The facility to print a Cash on Hand Report is provided as an option when the process is
finished. It will produce a report of all of the cash denominations that were declared for
the stock unit. In the event that the printer is not available at the time, an option to print
the report to the screen for transcription to a manual form will be provided.
There is no limit as to the number of declarations that can be made in a BP. Subsequent
Cash on Hand declarations override previous ones made, until discrepancies are
committed during the stock unit balancing process. It is at this point that the system
figures are reset to the declared figure.
10.3.2 DECLARE STAMPS ON HAND (INDIVIDUAL STOCK UNITS)
Exactly as for Declare Cash on Hand (individual stock units) above but for stamp
denominations.
10.3.3 DECLARE STOCK ON HAND (INDIVIDUAL STOCK UNITS)
This function is not available for individual stock units.
10.3.4 DECLARATION DISCREPANCIES (INDIVIDUAL STOCK UNITS)
Discrepancies are the result of a mismatch between values declared (using the Cash or
Stamps declaration processes) and the values for these items calculated by the system
from the transactions recorded. If discrepancies are not rectified before the production of
the balance report (either by using the ‘Adjust Stock’ function or by carrying out
corrective transactions) then the individual discrepancies for each product (or cash) are
added together and are reported as part of the Stock Unit balance. If the stock unit Final
Balance report is produced (by the ‘rollover’ process) with discrepancies still existing,
these discrepancies are netted out to a single Loss Discrepancy or Gain Discrepancy and
the net discrepancy value is rolled over as part of the stock unit’s cash and stock holdings.
In this way, an uncleared discrepancy remains with the stock unit across BP and CAP
boundaries until cleared in a subsequent balance period.
Stock adjustments must precede cash and stamp declarations.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 73 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
10.3.5 ADJUST STOCK IN HAND (INDIVIDUAL STOCK UNITS)
An Adjust Stock function will be provided which will enable the user to adjust the value
of stock held by the system. This function replaces the ‘Declare Stock on Hand’ function
used for shared stock units. The function is normally only used by ‘individual’ stock unit
users because shared stock unit users do not necessarily have knowledge of the complete
value of stock in all the portions of the stock units. Note: this function is available for
shared stock units to enter accounting adjustments, but is not used for shared stock unit
stock declarations.
This function will display a list of the stock items to the user along with the current
quantity or value for the item as calculated by the system. The user will then select the
appropriate item and enter the correct quantity or value to represent the actual stock held
in the drawer. The current value held by the system is calculated from the opening value
for the item at the start of the balance period plus all the transactions (positive and
negative) for the product since the start of the balance period. The transactions included
in the calculation will include:
© customer service transactions;
e reversals;
e® remittances;
e transfers;
e revaluations;
e discrepancies;
e adjustments;
e housekeeping transactions (movements to/from the suspense account).
On completion of the adjustment session the adjustments are committed to the system.
The system will post an adjustment to the system held item stock holding value for each
adjustment made plus a compensating cash adjustment for the total session. Discrepancies
are not created.
There is no limit to the number of adjustments that can be made in a BP.
Cash is excluded from the adjustment pick list.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 74 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
11. PRODUCE STOCK UNIT BALANCE REPORT
The stock unit balancing process requires the user responsible for balancing to:
e Produce one or more Stock Unit Trial Balance Reports
e Produce Stock Unit Final Balance Report
© Rollover the Stock Unit
The following facilities are provided to support this process:
e Produce Stock Unit Balance Snapshot
e View Discrepancies
e View Outstanding Declarations
© View Shared Declarations
e View Negative Stock and Revaluation Errors
e View Outstanding Summaries
11.1 STOCK UNIT BALANCING OVERVIEW
The stock unit balancing process consists of accumulating all the receipts for the stock
unit and all the payments for the stock unit in the period for which the report is being
produced and ensuring that the total value of receipts matches the total value of the
payments. When this state is reached, the stock unit is said to be ‘balanced’.
Prior to the production of the final balance a number of checks are required to be made.
These include ensuring that any mandatory declarations have been made, that there are no
outstanding inward or outward transfers involving the stock unit and that mandatory client
reports have been produced.
Stock unit balancing is the process of reconciling the user’s current stock unit contents.
against the transactions carried out and the opening stock unit contents (i.e. at the start of
the balancing period). A stock unit must be balanced at the end of the Cash Account
Period, but may be balanced at any time during the Cash Account period and rolled.
forward into a new Balance Period. At the end of the Cash Account period the stock unit
is “rolled over” to the next Cash Account Period (CAP). When this occurs the stock unit
Balance Period (BP) will be reset to period one.
A stock unit is normally balanced at the end of the user’s duty (unless it is being shared
and is still in use by another user).
e IMPORTANT: a shared stock unit cannot be balanced whilst it is being used for
serving. The system will provide warnings if this activity is attempted and will
prevent the user from continuing until all other users of the stock unit have logged off
from the system.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 75 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
11.2 STOCK UNIT TRIAL BALANCE
Note: any steps in the following processes that are specific to Shared or Individual stock
units are highlighted (SSU) or (ISU) respectively.
11.2.1 STOCK UNIT TRIAL BALANCE PRE-REQUISITES
The system provides functionality such that when a stock unit trial balance report is
selected, the system ensures that:
all daily and weekly mandatory stock unit reports have been carried out
all balance declarations have been made
the total value of receipts and payments are equal
no negative stock or cash on hand figures exist
no revaluation errors have occurred on fixed price products (this is checked by
establishing whether the current quantity x unit price = total sale value)
there are no outstanding transfers in or out
the necessary communication integrity checks are made
(SSU) no other user is logged onto the stock unit
(SSU) no other user can log onto the stock unit until the stock unit has been rolled
over
Following these checks, the system will:
advise the user if any nodes are disconnected and provide the opportunity to continue
or abandon
display to the user any outstanding activities identified by the system checks
prevent trial report production until these mandatory checks are clear
11.2.2 DECLARING DISCREPANCIES
If all pre-requisites are successfully completed, the system will:
(ISU) display to the user any uncommitted discrepancies (Cash) identified as a result
of the balance declarations
(SSU) display to the user a record of all declarations that will contribute to the trial
balance report, i.e. all different types of declarations with differing declaration IDs
display to the user a list of any uncommitted discrepancies at item level, identified as a
result of the balance declarations
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 76 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
e allow the user to accept or reject the list of discrepancies as a whole. This has the
effect of committing the discrepancies by correcting the relevant stock item figures
and posting a loss or gain (a.k.a. Discrepancy OVER or SHORT) for the value of each
item discrepancy.
If the discrepancies are rejected, the system will:
e abandon the trial balance
e return the user to the desktop
e ensure that the trial balance process must then be started again from the beginning
If the discrepancies are accepted the system will:
e (ISU) commit the discrepancies to the stock unit balance as a cash discrepancy with a
compensating loss/gain discrepancy transaction
e (SSU) commit the discrepancies to the stock unit balance
© produce the Trial Balance Report
e ensure that no other system functions for this stock unit can be accessed during this
process
11.2.3 TRIAL BALANCE REPORT PRODUCTION
The system derives the data on the Trial Balance report by:
e applying the stock unit starting figures brought forward from the previous BP or CAP
(whichever is later), including cash, stock and previous discrepancies
e applying and summarising all transaction entered into the stock unit during the current
BP
e deriving volumes and values for cash and stock remaining by integration of the above,
including discrepancies identified
© create new ‘opening figures’ from the integration of the above
11.2.4 TRIAL BALANCE REPORT PRINTING AND PREVIEWING
The system provides functionality such that:
e the resultant data is applied to a report in the format as defined in the Reports &
Receipts FS
e the resultant report can be viewed on screen and printed
e the report must be printed except in the event of printer failure. In this event, the
report must be viewed on screen or abandoned
e When the trial report is produced, a check is made that the total value of Receipts on
the report is equal to the total value of Payments. The user is warned and may
abandon or continue with the report.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 77 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
e ifthe Trial Balance is abandoned, the Trial Balance is voided and has to be started
again
© the user is prompted with these options and consequences at all times
After printing or previewing the report, the system will:
e prompt the user to continue with the balance process (i.e. produce Final Balance
report) or return to the desktop to complete the balance process later. If the user
returns to the desktop and performs any transactions which will impact on the SU
balance, the Trial Balance will have to be derived again.
11.3 STOCK UNIT ROLLOVER AND FINAL BALANCE
This process is the same for both Shared and Individual stock units.
The system provides functionality such that:
e the Stock Unit Rollover function can only be selected as a continuance of the previous
selection - production and completion of a Trial Balance report
e the process is irreversible upon completion
e if the Rollover is not completed (e.g. system failure), the Final Balance is voided
If the Rollover function is selected, the system provides functionality such that:
e the stock unit must be in the same CAP as the office
e the stock unit can be rolled into the next BP or CAP
© the stock unit cannot be rolled over more than 1 CAP ahead of the office CAP. Note:
2/3 week CAPs are discussed separately below.
e no other system functions for this stock unit can be accessed during this process
© the same data that was derived for the latest Trial Balance report is used for the Final
Balance Report
e the resultant data is applied to a report in the format as defined in the Reports &
Receipts Functional Specification
© the report must be printed except in the event of printer failure. In this event, the
report must be viewed on screen (this is actioned automatically by the system)
© the user is prompted with these options and consequences at all times
After printing or previewing the report, the system will:
e prompt the user to continue with the balance process (i.e. roll over)
© create the opening stock and cash values for the start of the next balance period
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 78 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
11.4 DISCREPANCY HANDLING
The stock unit declaration process identifies any discrepancies between the system derived
figures and the stock values held.
The value of the difference (+ or -) generates an adjustment to the specific item of stock or
cash to bring the sytem held value in line with the declared value and creates a balancing
entry as a loss or gain discrepancy. These values are only committed to the stock unit
balance when the Trial Balance is completed. Until they are committed, subsequent
declarations during the balance period will override previous declarations.
Separate products are used to record loss and gain discrepancies so they do not
compensate for each other and are reported separately during the current CAP or BP.
However, when the stock unit is rolled over, the net of the loss and gain discrepancies is
carried forward as the opening balance for one of the two discrepancy products with the
other one being set to zero.
11.5 COMMUNICATION INTEGRITY CHECKS DURING STOCK UNIT
BALANCING AND REPORTING
As part of the process for deriving the Trial and Final balances for stock units, a
communication integrity check will be made before processes can continue. The system
checks that:
e the node in use is connected to the rest of the outlet terminals
e that none of the other terminals are disconnected from the network
If the node in use is not connected, the balance process cannot continue. In this situation
the user is prevented from selecting the menu option for stock unit balancing.
If any other node is disconnected, the user will be advised of this fact and offered the
opportunity to continue or abandon the process.
In the event of continuing there is a risk (minimised by manually checking whether the
stock unit has been used on the absent terminal) that not all transactions that have taken
place within the stock unit would be included in the balance process.
If there are any such transactions which impact upon the financial reporting of the stock
unit, a discrepancy will be identified although in reality this may not always be easy to
identify since there may be several discrepancies of different types. The business process
to check manual dockets against the system derived figures will ensure minimal errors.
The rollover process creates the start and end points within the stock unit that are
recognised when an office balance is performed. Therefore, any transactions which have
been captured at a disconnected node will not report to the cash account within the current
office CAP if the SU is rolled over. When the node is re-connected, these transactions
will report to the SU balance of the CAP in which communication is restored. This
should create a compensating discrepancy although again this will not always be identified
and again manual checking of dockets will minimise errors.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 79 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Stock units cannot be deleted if any nodes are disconnected.
11.6 STOCK UNIT BALANCE SNAPSHOT
Additionally there is a requirement that a user must be able to take a ‘snapshot’ view of
the stock unit balance at any time in order to monitor the current system view of the state
of the stock unit.
The stock unit snapshot balance provides the user with a view of what the balance report
would look like if the stock unit balance was to be declared at that time.
The report produced from the snapshot process will be identical to the final balance report
except that the report title indicates that the report is a “Stock Unit Balance SNAPSHOT’.
The report will also not show any discrepancies since these are only committed when the
Trial or Final balance reports are produced.
The process is the same as the Stock Unit Trial Balance process except:
e There are no pre-requisite checks except the warning regarding communication
integrity.
e Declarations are not required
e Discrepancies will not be committed
e The transactions included are for the current BP up to the time that the report was
requested (i.e. excluding any transactions that are posted by another user during this
snapshot process).
e The snapshot process does not continue to the final balance stage.
e Snapshots can be performed as many times as necessary during a BP.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 80 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
12. COMPLETE CASH ACCOUNT - STANDARD
The office cash account is the definitive summary of all of the business transacted in the
post office during the cash account period.
IMPORTANT
By definition, the production of the office cash account can only happen after all activities
in that cash account period have been completed. This means that all stock units must
have been balanced and rolled over to the next cash account period.
The cash account production process is, therefore, carried out on the data collected for one
cash account period whilst the stock units can be used to serve customers in the next cash
account period.
If errors are found at the ‘Office’ level after all stock units have been moved forward to
the next accounting period, a new stock unit will need to be created in order to carry out
any adjustments which are necessary.
12.1 INACTIVE STOCK UNIT ROLL OVER
A function to roll over inactive stock units is provided. For a stock unit to be deemed
inactive, no transactions for the stock unit can have been posted to the journal for the
current CAP and the stock unit must have no users attached.
The user is presented with a list of all the stock units in the office from which to select the
inactive stock unit to be rolled over.
The stock unit must be in the same CAP as the office.
As for active stock unit rollovers, this process is irreversible.
12.2 PRODUCTION OF OFFICE REPORTS
The mandatory reports required before balancing are produced by the general report
production process described in the Reporting section above. The rest of the report
production process is described here.
12.3 OFFICE BALANCE (WEEKLY CASH BOOK)
The Office Balance process produces a report, the contents of which closely mirrors the
current ‘Cash Book’ maintained in manual outlets. It provides a summary across all the
stock units in the outlet of the current cash and stock holdings, the totals by client of the
receipt and payment transactions (voucher transactions) and the stock movements in and
out of the outlet.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 81 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
A view of the office balance report should be capable of being produced at any time
during the cash account period but the ‘final’ office balance report can only be produced
once all the stock units in the outlet have successfully balanced and rolled forward into the
next CAP.
For this reason, an Office Snapshot report option is provided in addition to the ‘Final’
balance report option.
The reports and processes are as follows:
© Office Snapshot (may be done at any time — produces a SNAPSHOT report))
© Office Report (produce a TRIAL and, when confirmed, a FINAL OFFICE BALANCE
report)
e Snapshot Cash Account (produces a SNAPSHOT CASH ACCOUNT report - must
precede the Cash Account Report)
e Cash Account Report (produces a TRIAL CASH ACCOUNT report and when
confirmed, rolls over the cash account to a new CAP and produces 2 x FINAL CASH
ACCOUNT reports.
12.3.1 OFFICE BALANCE SNAPSHOT
The office balance snapshot balance provides the user with a view of what the balance
report would look like if the office balance was to be declared at that time. The
production of this report does not require the prior completion of the ‘Final’ balances for
each of the stock units. The report produced from the snapshot process will be identical to
the final balance report except that the report title indicates that the report is an ‘Office
Balance SNAPSHOT’. It is also unlikely that the report will contain the stock unit
discrepancies in the current week, unless one or more stock units has actually balanced.
The snapshot balance process can be repeated as many times as necessary and at any point
in the cash account period.
12.3.1.1 REPORT PRODUCTION
The system derives the data on this report by:
© applying the office starting figures brought forward from the previous CAP, including
cash, stock and previous discrepancies
e applying and summarising all transactions entered into all stock units within the office
which have been confirmed to the message store at the point that the report is
requested. This includes only discrepancies brought forward or declared and
confirmed by stock units.
e deriving volumes and values for cash and stock remaining
¢ create finishing figures from the integration of the above
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 82 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
12.3.1.2 REPORT PRINTING AND PREVIEWING
e the resultant data is applied to a report in the format as defined in the Reports &
Receipts Functional Specification
e the resultant snapshot report must be able to be viewed on screen and printed
12.3.1.3 REPORT AVAILABILITY
© office snapshots can be taken at any time and as often as required within a CAP in
advance of the office balancing process being applied
e office snapshots can be taken irrespective of the balance state of the stock units within
the office (i.e. there can be zero, some, or all stock units balanced)
© office snapshots can only be taken by users with the appropriate access level, as
defined in the Menu Hierarchy document
® acommunications integrity check is made of node connection to ensure that the user is
made aware of any disconnected nodes and therefore the possibility of any missed
transactions. Disconnected nodes do not, however, prevent the completion of the
report.
12.4 OFFICE BALANCE REPORT
The office balance proper is the formal declaration of a balance for the office at the end of
the designated CAP.
12.4.1 OFFICE BALANCE PREREQUISITES
e that all the stock units in the outlet must have been balanced and rolled forward into
the next CAP
e any of the mandatory Non-Accounting and Parcel Traffic data entries (the Cash
Account Table 10g and Table 12 details) must have been completed. A warning
message requiring confirmation should be displayed if there are no entries in the
current CAP for the Table 10g and Table 12 data and the user should have the option
of abandoning the process at this point in order to make any necessary entries.
The communication integrity checks (defined under Stock Unit Balancing) are also
performed and warnings given.
During the balance process, no other system functions are available in the office that
would impact upon the office balance.
12.4.2 TRIAL BALANCE REPORT
The Trial balance report must be printed before the Office Balance can be confirmed and
the Final Balance report produced. The report is derived from:
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 83 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
e applying and summarising all the stock unit starting figures brought forward from the
previous CAP
e applying and summarising the stock unit balance transaction figures from all stock unit
balances from the CAP
e applying and summarising all stock unit balance finishing figures from the latest BP
for each stock unit
This report is clearly marked OFFICE TRIAL BALANCE REPORT.
This report is printed automatically by the system. If the printer is unavailable, the system
previews the report.
If the balance process is abandoned or fails to complete it is voided and must be started
again.
When the trial report is produced, a check is made that the total value of Receipts on the
report is equal to the total value of Payments. The user is warned and may abandon or
continue with the report.
When the report has been produced the user will be provided with the option to complete
the process by ‘confirming’ the Office Balance.
12.4.3 CONFIRM OFFICE BALANCE
This function is provided as an option on the Office Balance screen. The option can only
be selected when a Trial Office Balance report has been successfully printed or previewed.
When selected, the accumulated values from the stock unit balances are committed to the
message store and a ‘Final’ Office Balance report is printed. The report is derived from:
e applying and summarising all the stock unit starting figures brought forward from the
previous CAP
e applying and summarising the stock unit balance transaction figures from all stock unit
balances from the CAP
e applying and summarising all stock unit balance finishing figures from the latest BP
for each stock unit
This report is clearly marked OFFICE FINAL BALANCE REPORT.
This report is printed automatically by the system. If the printer is unavailable, the system
previews the report.
If the balance process is abandoned or fails to complete it is voided and must be started
again.
When the report is produced, a check must be made that the total value of Receipts on the
report is equal to the total value of Payments. If these totals do not match then the user
cannot be allowed to continue with the office balance process.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 84 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
12.5 CASH ACCOUNT SNAPSHOT
The office balancing menu will contain an option to produce a ‘Snapshot’ Cash Account.
In order to produce the ‘Snapshot’ Cash Account report, the Office Balance must have
been produced, there must have been no further stock unit transactions and the
communications integrity checks are performed again.
During report production, no other system functions are available in the office that would
impact upon the office balance or Cash Account.
The snapshot cash account is a reflection of the information in the office balance as well
as the office management information (e.g. tables 10(g), 10(f) and 12) and the suspense
account details.
The report is clearly marked CASH ACCOUNT SNAPSHOT.
This report is printed automatically by the system. If the printer is unavailable, the system
previews the report.
If the report process fails to complete it is voided and must be started again.
When the report has been produced the user will be provided with the option to ‘complete’
the process and return to the menu.
No option is provided by this process to ‘rollover’ the Cash Account to the next period.
12.6 CASH ACCOUNT REPORT
The office balancing menu will contain an option to produce the Cash Account.Report.
In order to produce the Cash Account report, the Cash Account Snapshot must have been
produced, there must have been no further stock unit transactions and the communications
integrity checks are performed again.
The Cash Account report process consists of two distinct stages, the production of a ‘trial’
cash account and the rollover to the next CAP with production of the ‘Final’ cash account.
The Trial Cash Account report must be printed before the user is allowed to select the
‘rollover’ option. Pre-requisites for the production of the trial cash account are that the
Office Balance must have been produced, there must have been no further stock unit
transactions in this CAP, all stock units must have been rolled into the next CAP and the
communications integrity checks are performed again.
During report production, no other system functions are available in the office that would
impact upon the office balance or cash account.
The trial cash account is a reflection of the information in the office balance as well as the
office management information (e.g. tables 10(g), 10(f) and 12) and the suspense account
details.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 85 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
When the trial report is produced, a check is made that the total value of Receipts on the
report is equal to the total value of Payments. The user is warned and may abandon or
continue with the report.
The report is clearly marked CASH ACCOUNT TRIAL.
This report is printed automatically by the system. If the printer is unavailable, the system
previews the report.
If the report process fails to complete it is voided and must be started again.
When the report has been produced the user will be provided with the option to ‘rollover’
the cash account.
12.6.1 CASH ACCOUNT ROLLOVER
The system will make the following checks when the ‘rollover’ option is requested :
The user is given the option to rollover to the next CAP or abandon the process. If the user
selects the next CAP, the system will roll the office to the next CAP pre-determined by the
POCL cash account calendar (but see the section below on extended Cash Account
periods).
The rollover and final cash account are a continuous process and cannot be interrupted
therefore the system prevents the user from accessing any of the function keys which
could affect the process.
On roll-over, the outlet CAP is incremented to the next CAP in sequence (but see the
section below on 2/3 Week Cash Account periods). If the current CAP is either Week 52
or Week 53, the Cash Account process checks the Cash Account calendar data in the
message store (derived from POCL supplied Reference Data) to determine whether the
next CAP should be CAP Number I of the next accounting year.
At the time that the Cash Account data is committed, the office ‘Brought Forward’ values
are created and stored for use in the following week’s Cash Account production. Also at
this time, those adjustments which have been made to the suspense account values by
transactions carried out ‘in-week’ are calculated and the revised figures are stored for use
when calculating the suspense account values at the end of the next period.
12.6.2 FINAL CASH ACCOUNT
Providing all the checks have been met when rollover is selected, the system automatically
prints the final cash account. Any errors discovered at this point cannot be corrected
within the CAP.
The report is clearly marked CASH ACCOUNT FINAL.
This report is printed automatically by the system. If the printer is unavailable, the system
previews the report.
Two copies of the report are printed.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 86 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
An electronic copy of the 'Cash Account Report’ is stored for subsequent transmission to
the TIP system.
If the report process fails to complete it is voided and must be started again.
A facility to reprint a Cash Account Report is provided in case the hard copy of the report
was unable to be produced at the time of completion due to printer failure.
12.7 Communication Integrity Checks During The Production Of
Office Reports
As part of the process for deriving the Office balances and Reports, a communication
integrity check will be made before each process can continue. The system checks that:
¢ the node in use is connected to the rest of the outlet terminals
e that none of the other terminals are disconnected
If the node in use is not connected, the processes cannot continue. The user is advised of
this fact.
If other nodes are disconnected, the user will be advised of this fact and offered the
opportunity to continue or abandon the process.
The only way new transactions could be introduced on an isolated node at this stage of the
office processing is if a new stock unit was created — this is prevented on an isolated node.
12.8 DISCREPANCY HANDLING
The office balance accumulates the individual stock units’ net loss or gains for the period
as 2 separate figures which are presented on the cash account as losses and gains this
week.
Each stock unit net loss or gain is carried forward so if they aren’t cleared during the next
cash account period they will reappear on the next cash account.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 87 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
13. COMPLETE CASH ACCOUNT - 2/3 WEEK
In order to achieve the desired result it is necessary for the Outlet Manager to indicate to
the system that at the end of the current accounting period it is intended to ‘roll forward’
into a Cash Account Period (CAP) other than the normal current CAP+1. This action
needs to occur as early as possible in the CAP prior to the extended period and certainly
before any individual stock unit is balanced and rolled forward to the next CAP.
To achieve this, an ‘Extended CAP” button is provided on the Office Balancing Menu.
When it is selected, the system requests the user to select one of two option buttons to
indicate whether the extended CAP is to be a 2-week CAP or a 3-week CAP. The
selection is recorded.
Subsequently when a stock unit is rolled over it rolls over to the last week of the extended
CAP period, i.e. current CAP +2 or 3 as appropriate, instead of the normal current CAP
+1. The same applies when the cash account is rolled over.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 88 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
14. COMPLETE CASH ACCOUNT - FINAL
This Cash Account process relates to handing over to a new sub-postmaster.
This function is applied when a outlet transfers postmasters on a day other than at the
normal end of a CAP.
The process is as follows:
¢ All stock units are rolled over to the next BP in the current CAP.
e All office reports are produced.
e The weekly suspense account report is produced.
e The office balance snapshot is produced.
e If there are any errors, new transactions are entered and the SU is re-balanced etc.
e If there are any final account discrepancies these are entered using the products
provided for this and the SU is re-balanced ete.
e The ‘Final Office Cash Account (pink) is produced manually by transcribing details
from the system reports produced so far.
e All other Final Account process steps are manual.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 89 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
15. POST BALANCE ERROR CORRECTION
As a result of the process to produce that Cash Account, errors may be identified (e.g. a
transaction has not been entered).
Since all stock units have balanced and rolled into the following CAP, corrections have to
be entered into the system via the creation of a NEW stock unit and the creation of one or
more serve customer transactions or/and one or more new reversals. The cash and stock
of the SU will then be declared (as zero), the SU balanced and rolled over and
discrepancies will be created which will report to the office balance and Cash Account.
Understated or overstated transactions may be compensated for using a combination of
Serve Customer and New Reversal transactions
Transactions posted using the wrong cash account line (i.e. wrong product selected
originally) can be corrected by using a New Reversal for the original transaction and Serve
Customer for the correction.
Existing reversals are not available so certain transactions may not be corrected which
may result in Error notices being issued. These transactions currently include:
© Girobank in and outpayments (excluding Green giros)
° BT bills
e AP transactions
¢ Scales transactions
© Remittances in and out
e Transfers
After the correction has been made the stock unit would need to be balanced and rolled
into the next CAP to include the information in the Office Balance/Cash Account.
A new Office Balance and subsequent Cash Account will have to be produced.
The new stock unit would need to have its discrepancies dealt with in the next CAP (by
means of transfers of cash and stock to/from the original stock unit) and can then be
balanced at the end of the CAP with a zero cash and stock holding. In the CAP after the
one in which the ‘zero’ stock and cash has been balanced (i.e. two CAPs after the original
error was made) the stock unit could then be deleted if not required by the office.
There is no limit to the number of new stock units created for this function or the number
of attempts it takes to correct the error.
If the transaction took place in an earlier Cash Account Period then it is not reversible.
The error will probably result in the receipt of an error notice from the client.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 90 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
16. REFERENCE DATA MAINTENANCE
Reference data used at the counter is maintained centrally. The majority of the data
originates from POCL and is passed to ICL Pathway via the POCL RDP interface. Some
additional data (e.g. Tariff tables for mails transactions and the Cash Account mapping
data) is provided to ICL Pathway through other routes and is updated by ICL Pathway at
the written request of POCL. Further reference data needed by the applications (e.g. the
menu hierarchy and the definitions of buttons to appear on the screen) is generated and
maintained by ICL Pathway.
16.1 CLASS B REFERENCE DATA
The following POCL supplied Reference Data is included as class B Reference Data:
e Product Staff Discount flag.
POCL support a product Staff Discountable flag within POCL reference data. This flag
supports the Horizon function that will allow a staff discount to be generated against a
product for which staff discounting is a valid selection.
e Product Customer Discount flag.
POCL support a product Customer Discountable flag within POCL reference data. This
flag supports the Horizon function that will allow a customer discount to be generated
against a product for which customer discounting is a valid selection. It is understood
that at Release 2 none of the POCL products will be available for customer discount.
e Cash Account line - product mapping.
A cash account matrix is supplied to allow Pathway to construct a business compliant
relationship between the POCL product range and the cash account tables. The database
is currently maintained by POCL using an Excel spreadsheet.
e Scales Tariff Table.
Horizon supports a system link to the counter top letter weighing scales. The supporting
tariff rates and additional services are maintained in reference data as a set of tables.
Pathway have produced the supporting table structure and have populated the table with
the Royal Mail and ParcelForce tariff rates.
e Accounting nodes.
The accounting node hierarchy is supported by Pathway within an Access database. The
transmission of accounting node data is supported within version 3.3 of the AIS. However
the POCL reference data system requires modification before accounting node information
can be supported.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 91 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
16.1.1 REFERENCE DATA DOWNLOADS
All the above streams of reference data are distributed to the outlets via the ICL Pathway
RDMC (Reference Data Management Centre) system. The RDMC is able to ‘tailor’ items
of reference data so that they are distributed only to selected outlets.
16.1.2 CHECKS FOR UPDATES
At the end of day the system checks for any product changes due in the next 5 days and
adds these to a list of upcoming changes. This list is used at logon to warn the user of the
coming changes.
16.1.3 USER MESSAGES
When users log onto the system they are advised if there any impending product changes
changes. A report of products and new prices (if applicable) by date of change is printed
on the tally roll printer.
16.2 REVALUATION
The business process of revaluing stock arises from the way in which certain items of
POCL stock in offices are accounted for by the value remaining in the office rather than
the value sold and that these items can be subjected to price variances (e.g. a book of 10 x
first class stamps may be worth 260p today but may become worth 280p tomorrow).
When an item of value stock is revalued, the normal calculation of the stock unit balance
is disturbed. The residual value of the stock at the point at which the price changes
increases without any transaction taking place in the system to maintain the balance. This
compensating adjustment therefore has to be entered in the system in some way prior to
the conduct of the next stock unit balance. The amount of the compensating value must
accurately reflect the precise stock level, times the differential in price, at the time the
revaluation occurs.
In the case of a revaluation a book of 10 x Ist class stamps the current system effect can
be represented as:
Brought Forward = 100 books stamps @ 100 £260.00
260p
Sell 10 books of stamps -10 £- 26.00
Price increase by 20p to 280p (90 remaining)
Sell 10 books of stamps -10 £- 28.00
System derived value at end of period 80 £206.00
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 92 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
(=260.00 - 26.00 - 28.00)
Correct derived value at end of period = 80 80 £224.00
books of stamps @ 280p
It can be clearly seen from this that there is a need to create an additional uprating in the
value of the items stock at the end of the period of £18.00 to restore the correct position
(90 items at 20p).
16.2.1 REVALUATION MODES
In order to continue to provide the flexibility required by POCL to manually calculate and
enter the revaluation amounts but at the same time ensure that the system then accurately
reflects this in all subsequent displays and reports of the values of stock on hand, it is
necessary to ensure that any revaluation transactions occur against the specific products
being revalued.
To achieve this, the system will provide a menu structure which supports separate sub-
menus for revaluation up and revaluation down, with all relevant products appearing on
both sub-menus as selectable buttons. Selection of the Revaluation Up or Down menu
buttons will set the desktop mode to ‘Revaluation Up’ or ‘Revaluation Down’ as
necessary.
Both fixed and open price products may be revalued.
As with other transaction modes, the cash account mapping for each available product /
revaluation mode must be provided as Reference Data to ensure the correct posting of
transactions.
Once a revaluation menu option has been selected, the transaction will continue in the
same way as a ‘serve customer’ session with the selected transactions being placed on the
transaction stack for committal against a specific settlement product for revaluations (in
the same way that remittance sessions are settled). Revaluation Up transactions increase
the office’s liability to POCL and are therefore posted as credits. Revaluation Down
transactions are posted as debits.
Products involved in revaluation will be treated as ‘open price’ items, even if the reference
data indicates that they are ‘fixed price’. This is to allow the entry only of the PRICE
DIFFERENCE between the original product price and the new price. The quantity
attribute in the messages should be set to ‘0’ so as not to impact the quantity of stock on
hand when this is calculated for stock reporting/balancing purposes.
Revaluation transactions will appear as separate summary lines on the stock unit and
office balance reports. Revaluations ‘up’ will appear in the Receipts section of the
balance report, revaluations ‘down’ in the Payments section. The values of these items
will be included in the Receipts or Payments totals respectively.
Reversals are allowed in the normal way using the Existing Reversals function.
Example, Book of 10 x Ist class stamps price increase of 20p - stock holding 90, book of
10 x 2nd class stamps price decrease -10p stock holding 75.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 93 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Account Debit Credit Transaction I Quantity Signed
Mode Value
Books of 10 18.00 I Revaluation 0 -18.00
x Ist Class Up
Stamps
Revaluations 18.00 Revaluation 0 18.00
Up
.
Books of 10 2 Revaluation 0
x 2nd Class Down
Stamps
Revaluations 7.50 I Revaluation 0 -7.50
Down
16.2.2 REVALUATION DISCREPANCIES
Revaluation discrepancy can only be reported against a fixed price product where the
quantity x unit price does not equal the current stock value. This is checked during the
stock balancing/rollover process for both active and inactive stock units.
The system is unable to check the accuracy of the revaluation of open price products.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 94 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
17. MANUAL PROCESSES
Some POCL process functions are not supported by Pathway and are therefore manual.
This section lists these for completeness.
© Receipt of Forms
e Receipt of Non-Value Stock / Retail Stock
© Receipt of Training Materials
e Receipt of Stop Notices
© Receipt of Bureau de Change Exchange Rates
e Postshop Transactions
e Bureau de Change Transactions
e Balance Non-value Stock Items
© Order Stock for Till or Outlet
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 95 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
18. INTEGRATED SERVICES
This section considers the impact of integrated service events on EPOSS.
18.1 END-OF-DAY PROCEDURE
An end-of-day function will be provided. This function will ensure that activities such as
daily declaration of cash locked up, which are a prerequisite to end-of-day, are enforced.
The ‘End-of-Day’ function itself cannot be system enforced and must be user-invoked.
18.1.1 MANUAL END OF DAY FUNCTION
A user invoked function in which the user completes the activities performed at the end of
the working day.
These activities are :
e Girobank in and out payments summarised
© BT bills summarised
e Cheques summarised
© UKPA summarised
e BES transactions summarised
© Over night cash holdings declared (ONCH)
e National Savings in and out payments summarised
e National Savings new account declarations summarised
e TV licences summarised
e BES impounded cards summarised
e Rent schemes (cards and vouchers) summarised
© Council Tax (cards and vouchers) summarised
The user will select this function at the end of their working day. The above list is
displayed to the user as a check list. This process is followed by the user logging off from
the system.
If the over night cash holding declaration is not made by the user the system will prompt
the user to complete this activity at the next log on.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 96 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
18.1.2 SYSTEM INVOKED END-OF-DAY
A system-invoked end-of-day facility is also provided as a means of ensuring a ‘clean-
break’ for identifying transactions to be sent to POCL and to POCL’s clients. This system
invoked EOD is executed 30 minutes after the time the office is declared to close for that
day, as dictated in the outlet reference data supplied by POCL. In the event that either no
time is specified for the current day in the reference data or the time is after 19:00 hours,
the system will on these occasions insert the EOD ‘marker’ at 19:00.
As part of the system invoked EOD process a number of activities will take place:
e The system will check whether there are any items of product reference data in the
message store with a ‘start’ date 4 days ahead of the current date. Any such products
will be identified for reporting at logon the next day.
e The system will reconcile any unmatched BES Help Desk transactions received during
the day
The system rules off the journal for the day by placing a marker in the message store. Any
transactions in progress (i.e. either on a session stack and not committed, or being
prepared and not yet on the stack) will appear in the next day’s transactions.
18.2 BES/EPOSS TRANSACTIONS
18.2.1 BES/EPOSS NORMAL TRANSACTION
An EPOSS/BES Transaction for the appropriate benefit encashment or milk token
products is recorded in the journal. This contains both the EPOSS data for the cash or
milk tokens paid out and the BES data for the payments making up the encashments.
18.2.2 BES/EPOSS RECOVERY TRANSACTIONS
The clerk notifies EPOSS of benefit transactions he has performed in fallback using the
Recovery Transaction Facility. Normally this will be after the Payment Card Help Line
(PCHL) transactions have reached the outlet.
The Recovery Transaction Facility will seek to match the PCHL and EPOSS transactions.
Where a match is achieved a BES/EPOSS transaction is recorded in the journal. It
contains the EPOSS data for the cash or milk tokens paid out and the BES data for the
payments making up the encashments.
If the amount recorded by the clerk differs from the PCHL data then, besides an
notification record (see above), a BA Reconciliation Exception Details record is also
recorded.
The recommended way of working is to let the PCHL records reach the outlet before
inputting the receipt details because this affords an immediate check on the clerk’s input
by the system and allows the clerk to be prompted for corrections.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 97 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Nevertheless if the transaction is done before the PCHL records have reached the outlet,
then a partial BES/EPOSS transaction, containing only the EPOSS data for the cash or
milk tokens paid out, is recorded.
Where the PCHL records are delayed into a succeeding day automatic End of Day
Matching will run at the next end of day. If there is a mismatch in the amounts for a
transaction whose identifier matches then a BA Reconciliation Exception Details record is
recorded in the journal. If the End of Day Matching finds a match no record is recorded.
There is also the rare case of a PCHL record being misdirected to the wrong FAD code.
This will manifest itself as a PCHL record sent to the wrong office and will be
automatically presented at the point of office roll-over as an unmatched PCHL transaction.
Meanwhile in the correct post office the clerk will have input the EPOSS transaction. This
will be recorded in the journal as a partial BES/EPOSS transaction.
18.2.3 BES/EPOSS END OF ACCOUNT
At the end of the cash account period, at the point of office rollover, the post master is
presented with a list of unmatched EPOSS and PCHL transactions. He may be able to
match them, spotting errors he must have made when inputting the transaction ID ahead of
the PCHL records reaching the outlet.
For each EPOSS record the postmaster can perform a match or can answer “none”.
18.2.4 BES/EPOSS INCOMPLETE TRANSACTIONS
An incomplete transaction is one that the outlet has physically performed and has a receipt
copy for but, because of some malfunction and/or agreed counter procedures have not
been followed, there is no automated record of it.
The post master will be directed to the Pathway Business Support Unit (BSU) who will
effect the transaction for the outlet, in a similar manner to the PCHL handling fallback for
the outlet, notifying the system of the transaction ID and date from the receipt. The
automated transaction thus effected causes the equivalent of a PCHL record to reach the
office and the recovery then proceeds normally. In reinstating such automated transaction
records BSU will prevent duplicate encashments occurring. In some cases the BSU will
need to inhibit a subsequent event (e.g. stop) to prevent it blocking the correct
reinstatement of an incomplete transaction.
18.3 APS/EPOSS TRANSACTIONS
18.3.1 APS/EPOSS NORMAL TRANSACTIONS
APS/EPOSS Transactions contain both EPOSS and APS elements allowing EPOSS to
account for them properly.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 98 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
18.3.2 APS/EPOSS REVERSALS
This is similar to Existing Reversals (above) except an AP transaction number is entered.
In the case of APS, if an ‘end of day’ marker has been written since the time that the
original transaction took place, then the transaction may not be reversed. The erroneous
transaction will probably result in the receipt of an error notice from the client which must
be handled in accordance with the process for ‘clearing’ Error Notices.
18.3.3 APS/IEPOSS CRASH RECOVERY
In the event that a terminal should fail (due to power loss, disc failure, PC failure etc) it is
possible that there may have been one or more APS transactions in a customer session
which have not at that time been committed to the message store, although the customer
will have received a receipt with an APS transaction number on it. At logon after terminal
failure, the user is required to enter highest known APS receipt serial number for that node
(or ‘0’ if no APS transactions have ever been undertaken on the node). The system checks
for any gap between the last APS transaction number stored in the system and the number
entered by the user. If any gap exists it is ring-fenced (i.e. the numbers are reserved) and
the user is invited to perform the recovery activity. At this point the user may continue
with the recovery activity or abandon the process (completion of the recovery activity is
checked for during the balance process and is a mandatory precondition to producing the
SU balance).
When the option is selected to recover the missing transactions, the user is prompted by
the system to enter details for each transaction in sequence from the office copy of the
receipt. These details will include the date of the transaction (default is the current date),
the customer reference number and the value of the transaction. As each transaction is
recovered, the system prompts for the entry of the next until all the identified ‘missing’
transactions have been recovered. At any time during this process the user can opt to end
the recovery and return to normal service. Re-entry to the function subsequently will
resume at the next transaction number to be recovered. When all the missing transactions
have been recovered the user will be prompted to enter any manual transactions recorded
during the period of service disruption (Fallback Transactions).
18.3.4 APS/EPOSS FALLBACK
During a period of service disruption, APS transactions involving magnetic cards and
barcoded documents may have taken place and have been recorded manually. When the
system is returned to service, these transactions must be entered into the system to restore
the correct accounting balance and to record the transactions for transmission to the
client(s). Entry into the Fallback Recovery function is the same as for Crash Recovery
above. The system will require all missing transactions (Crash Recovery) to be entered
first (if any), followed by manual fallback transactions. The details to be entered are the
same for each type of APS recovery transaction.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 99 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
19. FALLBACK & RECOVERY
Fallback processing is required to cater for situations where all or part of the EPOSS
system is/has been inoperable for a period of time. During this period of service
loss/degradation transactions may have been carried out manually so as to be able to
continue to provide service to the customers. On return of the service to full operation one
or many transactions may need to be ‘recovered’. The principle causes of loss of service
are:
© loss of power;
¢ system failure;
e loss of external communications;
e loss of one or more peripheral devices.
19.1 LOSS OF POWER
If a loss of power occurs at a terminal or terminals during normal operation, there is a
possibility that one or more transactions which had either been completed or were in the
course of being carried out may fail to be recorded by the system. This situation will
apply to any incomplete customer session which is in progress at the time of failure.
Particular care should be taken to identify transactions in this category so as to ensure that
all required transactions are subsequently recovered. Any automated BES transactions
carried out in a current customer session which is disrupted by power failure should be
immediately notified to the BPS Help Desk so that the authorised payment(s) can be
marked as ‘paid’ to prevent the possibility of dual encashment.
19.1.1 SINGLE POSITION OUTLET
Ata single position outlet, loss of power to the system will result in the total loss of the
automated system for the duration of the power loss. During such outages, EPOSS
transactions can continue to be carried out in accordance with POCL Manual Procedures.
The situation for automated transactions (such as BES and APS) is dealt with separately in
the specifications of these services.
When the system is returned to service, it will be necessary to ensure that transactions
which took place manually during the period of service loss are recovered to the system
before the next accounting balance is taken. The recovery action need not necessarily take
place immediately that the system is returned to service, the action can be delayed until a
time convenient to the outlet staff.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 100 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
All transactions which have taken place manually can be identified either through the fact
that stock levels differ from those indicated by the system or through the vouchers which
the office will have retained in support of client transactions. To assist the outlet in
recovering these transactions, a transaction recovery facility described in the Recovery
Mode sub-section of the Desktop Modes section is provided.
Non-customer service transactions which took place during the outage (e.g. receipt or
dispatch of remittances) should be entered normally when the system returns to service.
19.1.2 MULTI-POSITION OFFICE
Where the power loss affects the complete outlet, the position regarding the conduct of
manual transactions and their subsequent recovery is the same as described above for
single position outlets.
Where the outage affects only one (or less than all) of the terminals in the outlet,
transactions may continue to be recorded through any remaining working terminals in the
outlet. Where the restriction of service to the working terminals would have an adverse
effect on quality of service in the outlet it may be necessary to continue serving at
unserviceable positions using manual fallback procedures. In such cases, recovery of the
transactions can either be left until the full service is restored, or can be accommodated on
the remaining working terminals in the outlet at a time convenient to the outlet staff
bearing in mind the need to maintain quality of service.
19.2 SYSTEM FAILURE
Total loss of service at one or more terminals in an outlet (or the only terminal in a single
position outlet) should be treated exactly the same as described in the Power Loss section
above.
19.3 LOSS OF EXTERNAL COMMUNICATIONS
The loss of external communications from the outlet does not affect the outlet’s ability to
continue to provide the EPOS Service at any of the terminals in the outlet. All EPOSS
transactions are processed locally and have no requirement to utilise the external
communication facilities other than to replicate the data recorded at the outlet to the
Horizon Data Centre(s). However, BES transactions, OBCS transactions and any APS
transactions requiring external communications may be affected by a loss of external
communications. In such cases, the software will notify the user that the external
communications are not available and the user will need to follow the agreed procedures
in such circumstances. Such procedures may involve the need to carry out specialised
‘fallback’ transactions at the outlet to bring transactions to account within the EPOSS
system (e.g. a BES/EPOSS fallback transaction to record the money paid out as a result of
a BES Help Desk Transaction).
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 101 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
19.4 LOSS OF ONE OR MORE PERIPHERAL DEVICES
With the possible exception of APS Smart Token transactions (not due to be implemented
in Release 2), the system is tolerant of individual peripheral failures. In the case of a
failure of the smart card reader, APS Smart token transactions cannot be undertaken.
For most other peripheral failure scenarios, the software provides the facility to
circumvent the problem and continue service, albeit with reduced ease of use.
19.4.1 MAGNETIC CARD READER
Failure of the magnetic card reader is dealt with by the provision of menu options for the
manual entry of the data. The data to be entered is embossed on the front of the card and
the manual entry is validated to ensure that data entry errors are eliminated. Facilities are
also provided to ensure that there is a differentiation made between the failure of the card
reader as opposed to the failure of the card itself (possibly due to physical damage).
19.4.2 BAR-CODE READER
Failure of the bar-code reader is dealt with by the provision of menu options for the
manual entry of the data. The data to be entered is printed on the form being read and the
manual entry is validated to ensure that data entry errors are eliminated. Facilities are also
provided to ensure that there is a differentiation made between the failure of the bar-code
reader as opposed to the failure of the bar-code itself (possibly due to physical damage).
19.4.3 PRINTER
Failure of the printer is handled by the provision of ‘Print Preview’ facilities which allow
any printed output from the system to be viewed on the screen and, if necessary,
transcribed onto a manual form or receipt.
19.4.4 KEYBOARD
Failure of the keyboard is catered for by the provision of a ‘touch’ screen capability. All
keyboard actions can be achieved through the use of the ‘touch’ screen, including the
input of alphabetic and numeric data.
19.4.5 SCREEN
Although failure of the screen does not actually prevent the system being used, it is
patently impractical to continue to use the terminal for service in such circumstances. The
failure of the screen should be treated exactly as for System Failure as described above.
19.4.6 OUTLET SYSTEM INTEGRITY
Covers:
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 102 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
e Isolated Nodes
e Less Than Full Service (node not available)
The system provides facilities to constantly monitor the condition of the communications
between all the terminals in the outlet and between the outlet and the data centres. The
software will check that the Riposte Message Server software has successfully exchanged.
data with each of it’s neighbour terminals within the last two attempts at synchronisation.
In the event that the software detects that the current terminal has failed to communicate
with any of its local neighbours (i.e. other terminals in the outlet) the system will display a
warning to the user and restrict the service at the particular terminal so that only basic
EPOSS functions are available for selection.
Some stock unit and office reporting functions require a full set of nodes to be available so
that all transactions to date are visible to them. These functions employ communications
integrity checks to check if all the nodes in the office are accessible before proceeding.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 103 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
20. OPS
This section identifies links to EPOSS services from certain OPS functions.
20.1 USER ADMINISTRATION
User administration is an OPS function.
20.2 POST OFFICE LOG ON
POLO is an OPS function.
20.3 LOGON
OPS Function via EPOSS using EPOSS Reporting on the Event Log (described elsewhere
in this document).
Following logon, a number of EPOSS related system functions are triggered, including the
following:
20.3.1 APS CRASH RECOVERY
Detection of the possible need for recovery of APS transactions following abnormal
termination of the user’s previous session, possibly due to failure.
See 0 (above)
20.3.2 ONCH REPORTING
Checks that the Overnight Cash Holding declaration for the current stock unit was carried
out the previous day (if not, the user is taken into the ONCH declaration process and a
declaration is recorded against the previous day’s date). The user may abandon this
process at any time.
20.3.3 REFERENCE DATA CHANGE WARNINGS AT LOGON
Reporting of changes to the ‘Product’ reference data where changes are due to come into
effect within the next 4 days (e.g. to allow users the chance to ensure that stock levels are
correctly revalued where appropriate). The’ 4 days’ includes the go live day for the
particular change.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 104 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
The system displays an appropriate dialogue message to the user and (upon confirmation)
offers a report listing all products for which a change has been received, detailing the
current state, due date of change and the change itself. The report is printed automatically
or previewed if there is a printer failure.
The changes displayed are: maximum and minimum vales and quantities; product name
and price.
20.3.4 STOCK UNIT ATTACHMENT
On creation, a user is assigned to a ‘default’ stock unit. The default stock unit cannot be
used to carry out any transactions, the user must first be attached to a valid ‘serving’ stock
unit.
At logon, the system checks for the last known Stock Unit attachment record. This will
either be the record that existed when the user last logged off or a record created through
the function of attachment. The last known attachment is re-applied.
20.3.5 CAP INTEGRITY
The system checks the Cash Account Calendar reference data (obtained from POCL
Reference Data) corresponding to the current SU CAP. If the current date is before the
“Start Date”, or after the “End Date” of the SU CAP, then a relevant message is displayed
to the user. Upon confirmation of the message the user is allowed to logon.
20.3.6 REFERENCE DATA UPDATES
EPOSS system reference data is associated with specific ‘start’ and ‘end’ dates. If a new
data item is detected with a current start date, the system will register the new data item.
Any items whose ‘end’ date has been reached will be ignored by the system.
20.4 LOGOUT
Logout ends the “user session” and relinquishes control of the workstation . The log out
function is selected from the root menu and performs no special processing. A
confirmation message is displayed to the user (from which logout may be abandoned). It is
possible to be logged out from a workstation without invoking the option from the root
menu: via the Temporary Lock function and the Timeout function. See elsewhere in this
document for further details.
20.5 SESSION MOBILITY
This function allows a user that is already logged on at a given workstation to logon at
another workstation without invoking the log out function at the first workstation.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 105 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
At the point that the user logs on at another terminal all processes described under Logon
above are applied but on completion the same screen that was on display at the first
terminal is presented. The system will automatically perform a log out from the first
terminal. Any data input and held in memory at the first terminal is transferred to the
second terminal (e.g. items contained within the stack).
In certain circumstances (e.g. where the initial terminal is engaged on a critical accounting
function such as balancing) the transfer of the session to another terminal is refused. In
these circumstances, the user is provided with a warning message explaining that the
session cannot be transferred at this time and the logon process is terminated. The
terminal returns to the normal Riposte ‘Splash’ screen.
20.6 USER MAINTENANCE
OPS not EPOSS Functions.
20.7 USER PRIVILEGE LEVEL
OPS not EPOSS Functions
Access to EPOSS functions is controlled by the OPS using user privileges.
Eight “user groups” or “roles” are provided on Horizon using Windows NT ‘user groups’
as a mechanism of determining access privileges. Users, once created, must be associated
with a group which is related to a pre-defined set of functionality, these relationships are
(usually) configurable through reference data (but not locally).
The association between user and group is independent of a user’s attachment to stock
units and remains intact until explicitly changed via the Modify User function (e.g. log off
does not reset the association). There are no limits to the number of groups which may be
associated with a user. There are no limits to the number of users which may be
associated with a group.
Three of the eight groups are normally used in outlets to provide general access to EPOSS
functionality: Manager, Supervisor and Clerk. Each of these roles subsumes the lower
level, i.e. ‘Supervisor’ has full ‘Clerk’ and additional functionality and ‘Manager’ has full
‘Supervisor’ and additional functionality. Manager is the highest access level available.
Groups have permissions marked as either “Yes’ or ‘No’ for each menu button displayed,
which are access controlling mechanisms for a (given) user associated with a (given)
group. From log on, EPOSS (through Riposte) will identify restricted functionality
through a display of “No Entry” graphics on buttons which are not available.
In the event of a ‘Temp-lock’ or inactivity time-out, the system will display the name of
the user logged on at the time. To regain access, two options are available:
e the password of the current user is entered and the user session is continued
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 106 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
e the Username of a Manager level user is entered followed by their password, the
original user session is terminated (full log off) and any transactions present on the
stack are committed.
20.8 USER INVOKED TEMPORARY LOCK
Users may temporarily ‘lock’ the terminal by selecting the option from the top level menu.
The system invokes temporary locks itself after a given period of input peripheral
inactivity (set to 15 mins at NR2)
Normally, access to the terminal is re-gained by entering the password of the original user.
In this case the current EPOSS session is resumed.
Abnormally, the terminal is unlocked by another user with the required user privileges e.g.
a manager. In this case the user session is terminated and any application program active
at that time will be alerted so that any exceptional processing can be carried out prior to
log off.
For EPOSS, this means any transactions displayed on the customer session ‘stack’ will be
committed to the message store prior to log off, the session being settled by ‘Cash’ to
maintain an accounting balance within the stock unit.
Once the Temporary Lock screen is displayed (whether user invoked or through a period
of inactivity) there is a limit on the time allowed for regaining access to the system. This
time limit is pre-set and is centrally configurable. For NR2 it is set to 59 minutes. If re-
entry is not successfully completed within this time limit the user session is automatically
terminated, the functionality of the forced logout (as described above) being applied.
Note: Unsuccessful attempts at re-entry do not set the available time back to 59 minutes.
20.9 SUSPEND AND RESUME USER SESSIONS
A facility is provided to ‘Suspend’ and subsequently ‘Resume’ a desktop session. Only
one session can be suspended in this way. During the suspension the clerk is presented
with a new main desktop menu and may carry out any of the system functions (including
serving another customer) while the original session is suspended. Each of the two
sessions (the suspended and the current) can be ‘toggled’ by selection of the
“‘suspend/swap’ button at the top of the customer session log. The two sessions will
remain in existence until the user returns one of the sessions to the ‘Desk Top’ and then
swaps to the other session.
While a suspended session is in progress, certain system functions (such as logout) will be
unavailable from the menus.
Suspend is not allowed during certain functions, viz. Balancing, pick list reports and
system critical activities.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 107 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
21. GLOSSARY AND ABBREVIATIONS
Agency Post
Office
Agent
Application
Attach
(User to stock
unit)
Balance
(stock unit or
office)
Branch
Post office run by an agent. Many
(possibly more than 1500) use
Capture or similar technology, and a
few larger branches use ECCO+.
Agency offices are generally free to
use whichever working procedures
suit. Some postmasters use more
than one stock unit at a time for
accounting convenience and ease of
use. A rigorous stock unit balancing
procedure is enforced at their
discretion.
The sub-postmaster. Not a POCL
employee.
A function, procedure, form or
program which is called and
executed. An applet is a mini-
application.
The action of associating a user with
a stock unit. It can be used in the
context of attaching a user to a stock
unit or a stock unit to a user.
Although more than one user can be
attached to a stock unit at a time, the
converse is not allowed. A user can
only be attached to a single stock unit
at a time.
The accounting and reporting
procedure which provides a
reconciliation of all transactions and
stock movements against the actual
stock and cash held.
Member of staff in the post office
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 108 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Manager or branch responsible for the overall
Sub- running of the branch.
Postmaster
(agent)
Branch Office Also known as a Crown Office. A post
(BO) office actually owned and operated
by POCL. Most use the ECCO+
technology although some non-
automated branches implement
“team balancing”. These make up
approximately 3.63% of all post
offices.
Cash Account The definitive weekly summary of all
transaction activities within a post
office branch. One is produced each
week by every post office branch.
The layout and content is similar for
all offices. The main differences are
between London and Provincial
localities and between Crown and
Agency offices.
Cash Account The Cash Account year begins
Calendar sometime in March and ends on
approximately the same date the
following year. It normally consists of
52 Cash Account periods, but it is not
unusual to have 53.
Cash Account Usually a period running from
period Thursday to Wednesday. It normally
excludes Sunday and consists of six
working days. At certain times of the
year, like Christmas and other bank
holidays, it is likely that the Cash
Account period will not be six working
days long.
Client Organisation which “owns” a service
provided at the post office counter.
Clients include BA, BT, British Gas
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 109 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
etc.
Commit A transaction is considered to be
have been committed when it has
been physically written to the
transaction journal. A session is
considered committed when all
transactions within it have been
committed.
(session or
transaction)
Community Town & Rural Community Cash
Cash Office Account Office - same as SPSOCA
but run more as a community service
(COMMCA) than a business. These make up
approximately 5.95% of all post
offices.
Community Town and Rural Community Credit
Credit Stock Stock Office - same as SPSOCSO
Office but run more as a community service
than a business. These make up
(COMMCSO) approximately 4.42% of all post
Offices.
Counter Clerk Member of staff in the post office
branch responsible for serving
customers at the counter. In Crown
offices the clerk has some personal
accountability for the stock and cash
used.
Customer Member of the public.
Duty (wrt a A clerk’s duty is the period which
clerk) begins when he attaches to a stock
unit and ends when he detaches.
EPOSS Electronic Point of Sale Service. It is
the branch automation infrastructure
which supports serving customers,
office administration and accounting.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 110 of 117
© ICL Pathway 1999
ICL Pathway
EPOSS Functional Description Ref:
FUJ00079277
FUJ00079277
BP/FSP/004
Version: 4.0
Date: 5/3/99
Franchise post
office
(FPO)
Individual
Accountability
ITs
ITS Agent
ITS Host
Linked
(products or
transactions)
Method of
Payment
Operate under a Franchise contract
with a large retailer, usually within
retailer's premises. These make up
approximately 0.8% of all post
offices.
In many Crown offices, MSPOs and
Franchises the method of working
imposes complete accountability on
each member of staff for all value
stock and cash that they use. In
practice this means that a clerk has
sole use and responsibility for a stock
unit.
In order to relieve himself from the
responsibility for a stock unit the clerk
must first balance it.
IMS to TMS System.
The software module which runs on
the TMS host (correspondence
server) which inserts/extracts IMS-
related data to/from TMS.
The platform on which the ITS runs.
Linked transactions are those that
have an association. They are not
necessarily contained in an
transaction session. Cross-selling is
an example of linking transactions.
A product which is defined as an
allowable way of settling (or being
used in part settlement) of a
transaction session.
BPFSP004.doc
© ICL Pathway 1999
COMMERCIAL IN CONFIDENCE
Page 111 of 117
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Modified Sub A converted ex-Crown office operated
Post Office by an Agent usually offering longer
(MSPO) opening hours with retail goods.
These make up approximately 3.32%
of all post offices.
Nested Nesting implies a hierarchy. A
Transactions customer session is a nested
collection of transactions. This
concept adds structure to customer
sessions which contain complex
transactions.
Outlet The post office branch or other
location where EPOSS is in use.
Post Office There are two main classes of post
Types offices:- Branch (or Crown) and
Agency. The number of Branch
Offices has been reduced greatly in
recent years as they have been
converted to Agency status.
Product Is an item that can be transacted or a
service that is provided. It includes
stock and cash items, other methods
of payment and open value services.
Regional The range of services offered at post
Variations offices differs between London and
Provincial (i.e. non-London)
branches.
Remittances Remittances are movements of stock
and cash between a stock unit and
an external remittance centre.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 112 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Restricted
Hours Cash
Account
(RESHRCA)
Reversal
Revisions
(remuneration)
Satellite office
(SATELITE)
Session
(customer or
transaction)
Settlement
(of a session)
Town & Rural restricted hours offices,
open between 4 and 20 hours per
week (provide a service where it is
hard to recruit full-time sub-
postmasters). These make up
approximately 0.8% of all post
offices.
A transaction which is used to
compensate for and correct errors.
Revisions is the process used to
determine the remuneration due to
the post office agent. In simple
terms, the agent is paid for the
volume/value of transactions (derived
algorithmically from Cash Account
information) that are carried out over
the period of one year. To further
complicate matters, the revisions year
is not the same as the Cash Account
year.
Office opened for restricted hours at
a temporary location whose cash
account is dealt with by another site.
These make up approximately 0.45%
of all post offices.
A session is a collection of
associated transactions. It can be a
customer session or an inseparable
collection of transactions within the
customer session.
The methods of payment which are
used to reduce the amount
outstanding from a transaction
session to zero.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 113 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Shared Stock A shared stock unit is one that is
Unit attached to more than one user at the
same time.
Stock and Refers to the collection of stock items
Cash and methods of payments that
comprise the stock unit.
Stock Unit A stock unit is the physical till tray
containing the cash and valuable
stock items like stamps. There are an
arbitrary number of physical stock
units.
Stock Unit The stock unit balance period
Balance Period represents the time period in which a
counter clerk has responsibility for a
stock unit. For each stock unit there
is at least one balance period in a
Cash Account period. The balance
period ends when the stock unit is
balanced.
Sub Post Town & Rural cash account offices -
Services Office operated by an agent usually in
conjunction with other retail business.
(SPSOCA) These make up approximately
79.01% of all post offices.
Sub Post Town & Rural Credit Stock Office - as
Services Office SPSOCA but all voucher processing
(Credit Stock & administration is dealt with by
Office) nearest BO. These make up
approximately 2.55% of all post
(SPSOCSO) offices.
System The term used to refer to the
collective hardware, system software
and application software components
of the counter terminal.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 114 of 117
© ICL Pathway 1999
FUJ00079277
FUJ00079277
ICL Pathway EPOSS Functional Description Ref: BP/FSP/004
Version: 4.0
Date: 5/3/99
Team Working
Transaction
Transfers
TTS
TTS Agent
TTS Host
Value Stock
Stock unit balancing is a time-
consuming task. Team working
allows many clerks to share a single
stock unit. This removes the need for
each clerk to balance their own stock
unit. The benefits in time savings
have to be set against a potential
increase in losses.
The journal entry that results from
“selling” a product across the post
office counter. A service like giving
advice or handing out a form can also
be considered a transaction.
Transfers are movements of stock
and cash between a pair of stock
units within the same post office.
TIP to TMS System.
The software module which runs on
the TMS host (correspondence
server) which inserts/extracts TIP-
related data to/from TMS.
The platform on which the TTS runs.
Value stock generally refers to the
tangible products which have an
associated unit price but may be
open value in some cases. Open
value products are not normally
considered to be value stock items.
BPFSP004.doc COMMERCIAL IN CONFIDENCE Page 115 of 117
© ICL Pathway 1999