<link>http://people.skolelinux.org/pere/blog/</link>
<atom:link href="http://people.skolelinux.org/pere/blog/index.rss" rel="self" type="application/rss+xml" />
+ <item>
+ <title>"Electronic" paper invoices - using vCard in a QR code</title>
+ <link>http://people.skolelinux.org/pere/blog/_Electronic__paper_invoices___using_vCard_in_a_QR_code.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/_Electronic__paper_invoices___using_vCard_in_a_QR_code.html</guid>
+ <pubDate>Tue, 12 Feb 2013 10:30:00 +0100</pubDate>
+ <description>Here in Norway, electronic invoices are spreading, and the
+<a href="http://www.anskaffelser.no/e-handel/faktura">solution promoted
+by the Norwegian government</a> require that invoices are sent through
+one of the approved facilitators, and it is not possible to send
+electronic invoices without an agreement with one of these
+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 transferred 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>
+</description>
+ </item>
+
<item>
<title>Litt statistikk over offentlige anbud annonsert via Doffin siden 2008</title>
<link>http://people.skolelinux.org/pere/blog/Litt_statistikk_over_offentlige_anbud_annonsert_via_Doffin_siden_2008.html</link>
<tr> <td>2008</td> <td>7356</td> </tr>
</table></p>
-<p>Jeg troppet den ufullstendige måneden og året fra tabellen. Se
+<p>Jeg droppet den ufullstendige måneden og året fra tabellen. Se
lenken for oppdaterte tall.</p>
</description>
</item>
</description>
</item>
- <item>
- <title>What is the most supported MIME type in Debian?</title>
- <link>http://people.skolelinux.org/pere/blog/What_is_the_most_supported_MIME_type_in_Debian_.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/What_is_the_most_supported_MIME_type_in_Debian_.html</guid>
- <pubDate>Wed, 16 Jan 2013 10:10:00 +0100</pubDate>
- <description><p>The <a href="http://wiki.debian.org/AppStreamDebianProposal">DEP-11
-proposal to add AppStream information to the Debian archive</a>, is a
-proposal to make it possible for a Desktop application to propose to
-the user some package to install to gain support for a given MIME
-type, font, library etc. that is currently missing. With such
-mechanism in place, it would be possible for the desktop to
-automatically propose and install leocad if some LDraw file is
-downloaded by the browser.</p>
-
-<p>To get some idea about the current content of the archive, I decided
-to write a simple program to extract all .desktop files from the
-Debian archive and look up the claimed MIME support there. The result
-can be found on the
-<a href="http://ftp.skolelinux.org/pub/AppStreamTest">Skolelinux FTP
-site</a>. Using the collected information, it become possible to
-answer the question in the title. Here are the 20 most supported MIME
-types in Debian stable (Squeeze), testing (Wheezy) and unstable (Sid).
-The complete list is available from the link above.</p>
-
-<p><strong>Debian Stable:</strong></p>
-
-<pre>
- count MIME type
- ----- -----------------------
- 32 text/plain
- 30 audio/mpeg
- 29 image/png
- 28 image/jpeg
- 27 application/ogg
- 26 audio/x-mp3
- 25 image/tiff
- 25 image/gif
- 22 image/bmp
- 22 audio/x-wav
- 20 audio/x-flac
- 19 audio/x-mpegurl
- 18 video/x-ms-asf
- 18 audio/x-musepack
- 18 audio/x-mpeg
- 18 application/x-ogg
- 17 video/mpeg
- 17 audio/x-scpls
- 17 audio/ogg
- 16 video/x-ms-wmv
-</pre>
-
-<p><strong>Debian Testing:</strong></p>
-
-<pre>
- count MIME type
- ----- -----------------------
- 33 text/plain
- 32 image/png
- 32 image/jpeg
- 29 audio/mpeg
- 27 image/gif
- 26 image/tiff
- 26 application/ogg
- 25 audio/x-mp3
- 22 image/bmp
- 21 audio/x-wav
- 19 audio/x-mpegurl
- 19 audio/x-mpeg
- 18 video/mpeg
- 18 audio/x-scpls
- 18 audio/x-flac
- 18 application/x-ogg
- 17 video/x-ms-asf
- 17 text/html
- 17 audio/x-musepack
- 16 image/x-xbitmap
-</pre>
-
-<p><strong>Debian Unstable:</strong></p>
-
-<pre>
- count MIME type
- ----- -----------------------
- 31 text/plain
- 31 image/png
- 31 image/jpeg
- 29 audio/mpeg
- 28 application/ogg
- 27 image/gif
- 26 image/tiff
- 26 audio/x-mp3
- 23 audio/x-wav
- 22 image/bmp
- 21 audio/x-flac
- 20 audio/x-mpegurl
- 19 audio/x-mpeg
- 18 video/x-ms-asf
- 18 video/mpeg
- 18 audio/x-scpls
- 18 application/x-ogg
- 17 audio/x-musepack
- 16 video/x-ms-wmv
- 16 video/x-msvideo
-</pre>
-
-<p>I am told that PackageKit can provide an API to access the kind of
-information mentioned in DEP-11. I have not yet had time to look at
-it, but hope the PackageKit people in Debian are on top of these
-issues.</p>
-
-<p><strong>Update 2013-01-16 13:35</strong>: Updated numbers after
-discovering a typo in my script.</p>
-</description>
- </item>
-
</channel>
</rss>
projects / homepage.git / blobdiff