Pjp comments added below
EPOSS RECONCILIATION and AI376
Actions agreed last week
On us by 24" January
On them by 24" January
We will complete mapping each of the
30 error types to the EPOSS
Reconciliation matrix and make this
available to POCL this week
We will make appropriate experts
available to further explain our analysis
as necessary.
\They will satisfy themselves that only 3 out
lof the 30 root causes of cash account
discrepancies would not have been trapped
yy the accounting integrity control (AIC),
land that appropriate processes have been
lidentified to trap these in future:
le One would now be trapped by the AIC
following prevention of negatives by
Oracle database constraints
le One would be prevented by signage
mapping rules now embedded in TPS
le One (the 196/ 197 issue) will require
business rule matching within the POCL
domain (see Reference Data actions)
CS error fixing: we will declare to
POCL the process controls in place for
managing the risk of CS’ introducing
intervention errors.
We will review the TIP Functional Spec,
to identify any gaps in the Pathway
solution.
[They will provide technical assistance to us
las appropriate.
[Further information to be provided on
IECCO office method.
378 type error (cash account fails): in
addition to seeking to correct the
underlying faults, we will install two
error detection modules at the counter
to
¢ identify pointer failure and repair it
wherever possible or otherwise
cause the cash account to be redone
by the postmaster, and
¢ identify any zero value cash account
and cause the cash account to be
redone by the postmaster
Cash account errors. There are two
types of error:
e Itis as printed and signed by the
IPOCL BSM will consider requesting us to
ireplace the screen instruction to call the help}
\desk by one to abort the cash account and
FUJ00118175
FUJ00118175
postmaster (see para 6 below)
¢ Itis not as printed and signed
(Oracle extraction error)
We will transmit the first type because it
accurately reflects what has happened
and TIP therefore need to know. We
should withhold the second, if caused by
a Data Error, but no instances have
occurred.
ifind the error (probably not for 24 January).
jot permitting the cash account to be
completed is another option, the fallback
being a reference data download to unlock
the constraint in the event of a pervasive
(eg. primary mapping) error (para 6 below).
(This is definitely not for 24 January.)
Receipts not equal to Payments. There
are two causal factors:
e Errors in reference data, most
frequently absence of primary
mappings
e Migration carry forward errors at
the outlet
The first is always identified by the
EPOSS Reconciliation facility (but the
cash account is transmitted as para 5
above). The second is not identified.
[The result from migrated offices will be no
orse than would have occurred anyway
lunder a manual cash account process. It is a
lone off legacy event.
[The mitigation lies in HFSO best practice at
gration.
FUJ00118175
FUJ00118175