POL00031276
POL00031276
FEB '96 10:23 FROM BAPOCL REGUIREMENTS
Item 2 of Paul Rich's leer “IT Concurrence Meeting" dated $ February
Though the meeting was with CardL ink. and thus the comments we
the one supplier. the issues are. for the most case, Zeneral and i
Cardlink’s solution than a reflection of the status of the requirements at the time of Bas.
writing this memo
Reconciliation / Role of TIP
Implication 1 “POCL will have to rely on the BA or the service provider for accurate
information for settlement”
Response: tio ment (approved by Tim Brown) covers part ef th
ely on the Service Provider for semleme
since ali date, of which BPS is one part. come: m PFT services, the anh
altemative being BA (who are fed by PF!
POCL's long-stop contro} over this is by the continuing in
from offices provided by the cash account.
is ne generic H
new on-line product will require a *bespoke’ rec
COST us an appropriate sum of money”
Of the three suppliers, CardLink has one of the x
reconciliation, using packages from the ACT Base:
software set
As there have been no definitive requirements specified fi
products there is a limit to what suppliers can de:
1n 2 situation where they are trying to win a cont
As with all suppliers, there will need to be some bespoke work, to develop
interfaces to third parties, and screens at the counter. The
is the real issue.
Given the ACT package in use by CardLink, “standard” products may be part of
the existing portfolio and thus require a small amount of bespoxe work.
Implication 3: “The benefit of continuing with the current TIP1 project becomes
questionable, as a major element of their scope is now taken by the serv
provider”
Tt is unclear on the precise
service provider is undertaking in th
changed.
FEB 'SE 10:24 FROM BA/POCL REQUIREMENTS
Tem 2 of Paul Rich's ieter "IT Concurrence Meeting" dated 9 February
Implication 4:
Response:
The understanding is that TIP is being fed “authorisation data” 4 3
can repeat the service providers checks against the EPOSS log version of
transaction data.
Given the likely risk transfer, it 15 unlikely the service provider would nor is
performing reconciliation even if it were not a requirement,
The question of whether TIP] is required te fuifll this function is a sp
cost case issue.
This is not a programme issue
“Service provider could cut POCL out of tran:
it through petro] stations”
The appropriate protection ag
POCL business rractual, bot
POCL and its client base
tt fs unlikely that reconciliation would be the primie concern if a service prc
wished to cut out POCL.
Office balance / Cash Accounting Process
Implication 4: “Dave Smith is currently reviewing the wav in which we account for ©
The result is this work is urgently needed ui prior to the ITT going out
Otherwi. WW be trapped ir:
process, endo sing the benefits of a more eiflexible appr
The strategic direction is not a programme issue. It should however be
that the cash account mechanism acts as a a the accuracy of the ser
providers data for reconciliation.
Current requirements require that the service prov upplies
will support POCLs current office procedures. Cardl ink are imp!
n of their Store View package, which can be de-coupled ara
approach ensures we retain financial contro! and avcountability un
an alternative is developed, and accommodates migration to the ‘new accour
and distribution systems’ in so far as they have been defined to the programme
“The new Accounting and Distribution Systems require a different set of
‘information and d different controls to those imposed by the cash account. T:
may not be supported”
The programme is constrained in defining requir
information on the interfaces to be supported
POL00031276
POL00031276