A Smoking Gun On Horizon And The Post Office

As I've said, jail them all

What went wrong at the Post Office over that Horizon computer system is being described as very difficult, complicated, we’ll never really find out and Whocouddaknowed?

This is not correct. The Post Office knowed, ICL knowed, Fujitsu knowed.

Therefore and thus, as I’ve said before, just Jail Them All. There will be some who will be able to argue their way out on the basis of their innocence and that’s fine, even great. But let’s start with everyone on the right side of the bars.

It’s long been - as I’ve said - common gossip among programmers that the base problem really was pretty base. The Horizon system counted incompletes as a transaction. So, a transaction is going through and it doesn’t quite make it. Communication problems, something. A sensible system looks at incompletes and ignores them. Only completes, fully handshaken and agreed, change the accounting ledgers. Horizon did not do this. It would count the incomplete as one transaction, then when the full one casme through count that as an additional, extra, transaction.

This is how a branch thought it had one number, the centre another. Because the branch regarded the incomplete and the resend as only the one transaction, the centre as two.

But common gossip among programmers isn’t enough, obviously.

One of my blog readers, jgh (and if he wants his full name added then I’ll do that) has been reading through the inquiry evidence. And found, here, this, on page 152 of the expert report:

Part of the changes allowed the user to re-start the

production of the CA Snapshot, Trial or Final if the

process was interupted by returning to the menu.

Previously, if the process was interupted then the

user was required to re-run the Office Balance Trial,

Final, CA Snapshot, CA Trial and then the CA Final

(Rollover). Due to an error, if the user does not run

the CA Snapshot process followed immediately by

the CA Trial and Final reports then the system writes

a further 'Brought Forward' transaction record each

time the process is interupted and re-started. This

causes the Cash Account Brought Forward value to

be multiplied up as many times as the process is reentered.

This problem does not occur in the LT2

software (due for release on 10.7.99) due to the

restructuring of the Cash Account production process

in line with the recent CRs. Tests have been

conducted to demonstrate that LT2 does not exhibit

the same behaviour. In the meantime, for the

remaining two Cash Account Periods on LT1, the

work-around is to re-run the Office Balance Trial and

Final reports, re-run the CA Snapshot process and

follow this immediately with the CA Trial and Final

prints.

Or, as jgh then describes it:

If a transaction update was interupted, if it was restarted it would reprocess the transactions, but using as the opening balance the balance from where the process was aborted. Eg

Opening balance 1000

credit 100 = 1100

credit 200 = 1300

debit 150 = 1150

credit 100 = 1250

*abort*

restart

Opening balance 1250

credit 100 = 1350

credit 200 = 1550

debit 150 = 1400

credit 100 = 1500

[Charles Cipione, pg 152]

This is an insane way to do banking or transaction software. But this is what ICL/Fujitsu did at least at one point in the process.

And that’s the core, base, problem. That’s how the system managed to have different numbers at each end of the process, with the subpostmaster and the central ledgers.

The rest of the process is people covering it up. Because this is a report of what the internal to the project people were saying about the software itself.

They knew.

Jail Them All.