Wednesday, 23 April 2014

My brand new campervan damaged by Gatwick Airport Official Valet Parking, and they refuse to pay for it

We left our nearly-brand-new campervan at Gatwick Airport Official Valet Parking the other week and it had a broken bumper and scratch on the side when we retrieved it.

I rather expected them to say "Ooops, sorry, send us the bill we'll sort it for you." But instead they said this:

"Following our investigation we are unable to accept liability for the alleged damage as this damage is not conducive to the actions of valet driving. As we do not believe that any negligence of APCOA has caused this damage to your vehicle we are therefore unable to further assist you with your request."

"Not conducive to the actions of valet driving". What does that mean? Seems that they can neither drive nor write English proper.

The bumper will need replacing and the side panel paintwork will need repairing, and Gatwick Airport Official Valet Parking will be paying for that.

Update 23 April:

Good afternoon Mr Grieg,
Thank you for your email response and I am sorry for your continued disappointment.

We have discussed the case with the management team and although we are sorry you feel this way, as per our original response we do not accept liability for this type of damage to your car. Relating to our terms and conditions of parking, we do not believe negligence of APCOA has caused this damage as this type of damage is not conducive (for instance, would not be caused) by the actions of our valet driving and parking.

I appreciate this was not the answer you had anticipated, however this is our definitive response and I am sorry that we could not assist you further on this.

Yours sincerely,
APCOA Pre-booking Customer Services
on behalf of Gatwick Airport

Monday, 20 January 2014

Lego pendulum clock

I've quite got into clocks recently, after bringing back to life an old non-working grandfather clock which I inherited.

Here's a clock which I've built in Lego:

Credit to Ben Van der Waal for the beautiful and elegant escapement design.

Here are the gear ratios:

Gear      Ratio   Multiple   Time per revolution (s)
Escape    -       -          8
1         40:8    5          40
2         40:8    5          200
3         24:8    3          600   (This is drive wheel)
4         24:8    3          1800
5         24:12   2          3600  (Minute hand)
6         24:12   2          7200
7         8:8     1          7200  (Needed to reverse direction)
8         16:8    2         14400
9         24:8    3         43200  (Hour hand)

Drive weight is 2.4kg. It feels like the Lego could hold a much heavier weight, which could then move even slower and so last longer. But haven't tried that yet. If I can move the drive wheel to gear 4, it will last 3 times longer, roughly 12 hours (it lasts about 4 hours now).

Getting to 8 days (the duration of a typical grandfather clock) feels completely unachievable, but maybe with incremental improvements to reduce friction it is possible in Lego, we'll see. Or perhaps it would be possible to have several weights with a new weight engaging once the first has reached the ground.

Wednesday, 9 October 2013

Telegraph journalists in England have lower levels of basic skills than their grandparents

Right. This has really annoyed me.

Lots of papers today reporting result of latest OECD skills survey, and all claiming that school leavers have lower basic skills than their grandparents. For example:

That just seemed to me kinda unlikely. Schooling was fairly rudimentary for many people 50 odd years ago.

So I checked the stats, which are available here:

Sure enough, in both literacy and numeracy, 16-24 yr olds in England performed at pretty much the same level as 55+ year olds:

Then I went back to the Telegraph article to check what numbers they were using. Pretty much the same numbers, in a nice little graph, showing that 16-24 year olds performed at, yep, roughly the same level at 55+ year olds:

So the graph in their own article clearly refutes the assertion made in the sub-headline.

Two more things:

1. One reason why other countries are seeing their young people out-perform their oldies, is because their oldies aren't as smart as our oldies. E.g. German 55+ average literacy score is 254, vs 265 for England.

So it is harder for our youth to outperform our oldies because our oldies are a lot smarter than, say, German oldies.

2. On problem-solving (not mentioned in Telegraph article), our young people kick butt compared to the older generation:

Just sayin'

Thursday, 14 June 2012

VoxSciences turns your voicemails into emails

I've been looking for a while for a way to get Skype voicemails sent to me by email. Listening to voicemails is time consuming and fiddly. Skype's iPhone client for some reason often fails to play voicemails, so I have to login from a PC to get a voicemail. Then I have to actually listen to it to find out what it is about and how urgent / important it is.

I tried SpinVox via Skype, but I found that was unreliable (three voicemails in one day were totally ignored by SpinVox, no notification and no transcription. I only found them by logging in to Skype from a PC). And SpinVox only sends them as a text, not an email. Voicemails are usually important, but are rarely so urgent they need to be texted.

I found another service called VoxSciences, and it seems to work really well. It does two things which SpinVox doesn't:

1. Sends transcript by email
2. Attaches an MP3 of the voicemail to an email (so if the transcription is uncertain, I can easily listen to the original recording myself)

(Works with any telephone / VOIP, just forward unanswered calls to your VoxSciences voicemailbox and caller can leave a message which will be transcribed.)

Costs £5 for every 30 messages (with minimum fee of £5/ month).

I've no relationship with VoxSciences, but I'd highly recommend them to anyone who wants their voicemails transcribed and emailed to them.

Tuesday, 21 February 2012

Printing numbered raffle tickets is harder than it sounds

I spent the best part of an afternoon last week battling with Microsoft Office to print 500 raffle tickets for our local playgroup fundraising.

You'd think it's easy, right? Create one ticket in Word, do a simple mail merge to pull in 500 numbers, then merge to printer.

But it is really hard (in fact, I think it is not possible) to get Word to print several differently-numbered tickets on one sheet of paper.

Anyway, to save anyone else that pain, I wrote a whole blog post explaining how I eventually did it. And I even set up a whole new blog, just for that post, to make it as easy as possible for fellow raffle-ticket-printers to find it:

Instructions for creating and printing numbered raffle tickets on your own printer.

Tuesday, 17 January 2012

Send invoices via InvoiceHub so your clients don't have to rekey your invoice into their accounts software

I have a new project called InvoiceHub.

InvoiceHub accepts invoices, via email, from anyone. It extracts key data (invoice number, amount, etc.) from the invoice. Then it forwards the original to its intended recipient with a link inserted in the email to allow the recipient to view the extracted data, and zap it straight into their accounts software.

Here's an example:

Let's say I'm creating an invoice to send to a client. It doesn't much matter what software I use to create the invoice, as long as that software can produce a PDF which I can email to my client. Here's me creating an invoice in Xero. I'm invoicing a client called Eskimo Joe, for some supplies of ice:

I email that invoice, from Xero, to my client, Eskimo Joe:

His email address is But rather than send it direct to his email address, I send it via InvoiceHub, to

When Eskimo Joe checks his email, he gets an email that looks pretty much as if I sent it direct to him. It has my invoice, and my text, and comes from me:

But, actually, it's already been through the InvoiceHub system, and InvoiceHub has already extracted the data from the invoice, ready for Eskimo Joe to import into his accounts software. Look at the link at the top of the email:

That link has been inserted into the email by InvoiceHub. The beauty of it is, though, that if Eskimo Joe doesn't care much for automagically importing stuff into his accounts software, he can just ignore that link and open the regular PDF attachment. But if Eskimo Joe clicks the link, this is what he'll see:

My invoice on the left, with key data (invoice number, date and so on) already extracted. All Eskimo Joe has to do is give InvoiceHub permission to import this invoice into his accounts system. Let's say Eskimo Joe uses KashFlow. He pops his KashFlow username and password on the screen here and InvoiceHub fetches his list of suppliers and account codes, so Eskimo Joe can say where he wants this invoice to go:

Then he clicks "Import to KashFlow". That's all he needs to do. When he later looks in his KashFlow account, the invoice will be already there:

Neither I nor my client needed to set up anything in advance. All I did was send the invoice to instead of Try it yourself, and let me know what you think. Is this a useful tool? Or just a solution looking for a problem?

Thursday, 17 November 2011

Why are XML invoices not commonplace?

I'm quite intrigued by the idea of being able to send and receive invoices electronically. Big corporates have been exchanging purchase orders and invoices electronically for decades, but almost no SMEs do this (except for those who are required to, in order to bill their big corporate clients. But often that doesn't work out so well.)

On the face of it, it should be quite simple to include an XML version of your invoice in some standard format which any accounting software can read. Pretty much everyone is using accounting software to create invoices, but they then flatten that data by printing or emailing a PDF, only for the recipient to have to painstakingly type it all back into their software. Would be better if they could just have the raw data go straight into their accounts software, without any need to retype it.

I stumbled across one attempt to create a standard for this kind of invoice data exchange, called SimpleUBL. "UBL" is "universal business language", which looks like a horrendously complex standard for exchanging all sorts of business process information. SimpleUBL is trying to make that simpler. But it still ain't simple as in iPhone. Browsing through it, I'm seeing hundreds of "Common Aggregate Components", things like:


Does that stuff really need to be in a standard used by SMEs for exchanging invoices?

And the whole point of XML is that it is supposed to be human-readable, but even something as simple as displaying amount before tax and amount after tax is a little cumbersome in SimpleUBL:

 <cbc:LineExtensionTotalAmount amountCurrencyCodeListVersionID="0.3"amountCurrencyID="USD">479.50</cbc:LineExtensionTotalAmount>
 <cbc:TaxExclusiveTotalAmount amountCurrencyCodeListVersionID="0.3"amountCurrencyID="USD">479.50</cbc:TaxExclusiveTotalAmount>
 <cbc:TaxInclusiveTotalAmount amountCurrencyCodeListVersionID="0.3"amountCurrencyID="USD">527.45</cbc:TaxInclusiveTotalAmount>

Seems to me that it could be a lot simpler still, and still be useful for the majority of businesses, and be much easier to implement.

If you are actually typing details from a supplier's invoice into your accounts software, the key things you type in are the invoice number, the date, and the amount. If you are VAT registered, then you’ll also be splitting out the total before and total after VAT. So the absolute minimum you need would be something like this:

<Invoice> <InvoiceNumber>10011</InvoiceNumber> <InvoiceDate>2011-10-12</InvoiceDate> <AmountBeforeTax>100.00</AmountBeforeTax> <Tax>20.00</Tax> <AmountAfterTax>120.00</AmountAfterTax> </Invoice>

But you also need to record who the invoice is from and what it’s for. That’s a little trickier for the person creating the invoice to include usefully in their XML, because they don't know how they are represented in your accounts system, and they have no idea what your chart of accounts looks like. You might put a phone bill under “Office Overhead”, “Phone, Internet, Power”, or “Rent etc.”

Nevertheless, that information has to appear in the invoice, so your bare-bones XML invoice might start to look like this:

<From>British Telecom plc</From>
<To>Fictitious Startup Ltd</To>
<Description>Telephone service</Description>

I think in the UK you have to show the VAT % as well as the VAT amount, and there are probably other bits and bobs I haven't thought of, particularly where there are several different items on one invoice.

But my point is it just doesn't seem that hard.

Seems a little surprising that we are still having to email PDFs to each other rather than sending raw data. Is there a business here? Some kind of hub which accepts an invoice in any format, converts it to XML and zaps it over to the recipient's accounts software? Maybe.