Hi, Read on BBC news web last night about the Greenpeace bacs direct debit mistake.
Quite relevent for me since just helped setup a bacsip new config
Found a good document from audit commission about checking and double checking submissions are correct.
Any ideas how the Greenpeace case happened about any lessons that can be learnt ??
Colin Johnston snipped-for-privacy@mx5.org.uk
Most BACS processing software has the facility to read in transactions from a "flat file". This could be in a fixed column width format so that the amount field always appears at a fixed offset with a fixed length.
A change in the file format (or less likely incorrect configuration of the BACS software) so that the position of the amount field is read in incorrectly is the most likely culprit.
The lesson to be learned is a simple one. Read reports.
It's even simpler, I think. Stop programming in COBOL.
Surely you need to know the correct file format irrespective of the development platform or is there some language that automatically understands BACS?
It may be possible to read the data using a flexible algorithm, so that the number of blanks between fields doesn't matter. But if you impose a fixed-column view (as I think Cobol is apt to do), then if you get the column numbers wrong, havoc results.
File formats, using fixed length records rather than variable length records with delimiters, exist and are often read into programs written in all sorts of languages. I don't think we need confuse the file format with Cobol on this occasion.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required