From: Petter Reinholdtsen <pere@hungry.com>
Date: Tue, 12 Feb 2013 09:24:14 +0000 (+0000)
Subject: New post.
X-Git-Url: https://pere.pagekite.me/gitweb/homepage.git/commitdiff_plain/37fd26280bc7158dd63848214249ce0b9b62577f

New post.
---

diff --git a/blog/data/2013-02-12-qr-invoice.txt b/blog/data/2013-02-12-qr-invoice.txt
new file mode 100644
index 0000000000..2dde248954
--- /dev/null
+++ b/blog/data/2013-02-12-qr-invoice.txt
@@ -0,0 +1,71 @@
+Title: "Electronic" paper invoices - using vCard in a QR code
+Tags: english, standard
+Date: 2013-02-12 10:30
+
+Here in Norway, electronic invoices are spreading, and the solution
+promoted by the Norwegian government is not really decentralised and
+require that invoices are sent through one of the approved
+facilitators.  This seem like a needless limitation to be able to
+transfer invoice information between buyers and sellers.  My preferred
+solution would be to just transfer the invoice information directly
+between seller and buyer, for example using SMTP, or some HTTP based
+protocol like REST or SOAP.  But this might also be overkill, as the
+"electronic" information can be transfered using paper invoices too,
+using a simple bar code.  My bar code encoding of choice would be QR
+codes, as this encoding can be read by any smart phone out there.  The
+content of the code could be anything, but I would go with
+<a href="http://en.wikipedia.org/wiki/VCard">the vCard format</a>, as
+it too is supported by a lot of computer equipment these days.</p>
+
+<p>The vCard format support extentions, and the invoice specific
+information can be included using such extentions.  For example an
+invoice from SLX Debian Labs (picked because we
+<a href="http://www.linuxiskolen.no/slxdebianlabs/donations.html">ask
+for donations to the Debian Edu project</a> and thus have bank account
+information publicly available) for NOK 1000.00 could have these extra
+fields:</p>
+
+<p><pre>
+X-INVOICE-NUMBER:1
+X-INVOICE-AMOUNT:NOK1000.00
+X-BANK-ACCOUNT-NUMBER:16040884339
+X-BANK-IBAN-NUMBER:NO8516040884339
+X-BANK-SWIFT-NUMBER:DNBANOKKXXX
+</pre></p>
+
+<p>The X-BANK-ACCOUNT-NUMBER field was proposed in a stackoverflow
+answer regarding
+<a href="http://stackoverflow.com/questions/10045664/storing-bank-account-in-vcard-file">how
+to put bank account information into a vCard</a>.</p>
+
+The complete vCard could look like this:
+
+<p><pre>
+BEGIN:VCARD
+VERSION:2.1
+ORG:SLX Debian Labs Foundation
+ADR;WORK:;;Gunnar Schjelderups vei 29D;OSLO;;0485;Norway
+URL;WORK:http://www.linuxiskolen.no/slxdebianlabs/
+EMAIL;PREF;INTERNET:sdl-styret@rt.nuug.no
+REV:20130212T095000Z
+X-INVOICE-NUMBER:1
+X-INVOICE-AMOUNT:NOK1000.00
+X-BANK-ACCOUNT-NUMBER:16040884339
+X-BANK-IBAN-NUMBER:NO8516040884339
+X-BANK-SWIFT-NUMBER:DNBANOKKXXX
+END:VCARD
+</pre></p>
+
+<p>The resulting QR code created using
+<a href="http://fukuchi.org/works/qrencode/">qrencode</a> would look
+like this, and should be readable (and thus checkable) by any smart
+phone, or for example the <a href="http://zbar.sourceforge.net/">zbar
+bar code reader</a> and feed right into the approval and accounting
+system.</p>
+
+<p><img src="http://people.skolelinux.org/pere/blog/images/2013-02-12-qr-invoice.png"></p>
+
+<p>The extension fields will most likely not show up in any normal
+vCard reader, so those parts would have to go directly into a system
+handling invoices.  I am a bit unsure how vCards without name parts
+are handled, but a simple test indicate that this work just fine.</p>