1 <?xml version=
"1.0" encoding=
"ISO-8859-1"?>
2 <rss version='
2.0' xmlns:lj='http://www.livejournal.org/rss/lj/
1.0/'
>
4 <title>Petter Reinholdtsen - Entries from March
2016</title>
5 <description>Entries from March
2016</description>
6 <link>http://people.skolelinux.org/pere/blog/
</link>
10 <title>UsingQR -
"Electronic
" paper invoices using JSON and QR codes
</title>
11 <link>http://people.skolelinux.org/pere/blog/UsingQR____Electronic__paper_invoices_using_JSON_and_QR_codes.html
</link>
12 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/UsingQR____Electronic__paper_invoices_using_JSON_and_QR_codes.html
</guid>
13 <pubDate>Sat,
19 Mar
2016 09:
40:
00 +
0100</pubDate>
14 <description><p
>Back in
2013 I proposed
15 <a href=
"http://people.skolelinux.org/pere/blog/_Electronic__paper_invoices___using_vCard_in_a_QR_code.html
">a
16 way to make paper and PDF invoices easier to process electronically by
17 adding a QR code with the key information about the invoice
</a
>. I
18 suggested using vCard field definition, to get some standard format
19 for name and address, but any format would work. I did not do
20 anything about the proposal, but hoped someone one day would make
21 something like it. It would make it possible to efficiently send
22 machine readable invoices directly between seller and buyer.
</p
>
24 <p
>This was the background when I came across a proposal and
25 specification from the web based accounting and invoicing supplier
26 <a href=
"http://www.visma.com/
">Visma
</a
> in Sweden called
27 <a href=
"http://usingqr.com/
">UsingQR
</a
>. Their PDF invoices contain
28 a QR code with the key information of the invoice in JSON format.
29 This is the typical content of a QR code following the UsingQR
30 specification (based on a real world example, some numbers replaced to
31 get a more bogus entry). I
've reformatted the JSON to make it easier
32 to read. Normally this is all on one long line:
</p
>
34 <p
><img src=
"http://people.skolelinux.org/pere/blog/images/
2016-
03-
19-qr-invoice.png
" align=
"right
"><pre
>
36 "vh
":
500.00,
41 "nme
":
"Din Leverandør
",
42 "cc
":
"NO
",
43 "cid
":
"997912345 MVA
",
44 "iref
":
"12300001",
45 "idt
":
"20151022",
46 "ddt
":
"20151105",
47 "due
":
2500.0000,
48 "cur
":
"NOK
",
49 "pt
":
"BBAN
",
50 "acc
":
"17202612345",
51 "bc
":
"BIENNOK1
",
52 "adr
":
"0313 OSLO
"
54 </pre
></p
>
56 </p
>The interpretation of the fields can be found in the
57 <a href=
"http://usingqr.com/wp-content/uploads/
2014/
06/UsingQR_specification1.pdf
">format
58 specification
</a
> (revision
2 from june
2014). The format seem to
59 have most of the information needed to handle accounting and payment
60 of invoices, at least the fields I have needed so far here in
63 <p
>Unfortunately, the site and document do not mention anything about
64 the patent, trademark and copyright status of the format and the
65 specification. Because of this, I asked the people behind it back in
66 November to clarify. Ann-Christine Savlid (ann-christine.savlid (at)
67 visma.com) replied that Visma had not applied for patent or trademark
68 protection for this format, and that there were no copyright based
69 usage limitations for the format. I urged her to make sure this was
70 explicitly written on the web pages and in the specification, but
71 unfortunately this has not happened yet. So I guess if there is
72 submarine patents, hidden trademarks or a will to sue for copyright
73 infringements, those starting to use the UsingQR format might be at
74 risk, but if this happen there is some legal defense in the fact that
75 the people behind the format claimed it was safe to do so. At least
76 with patents, there is always
77 <a href=
"http://www.paperspecs.com/paper-news/beware-the-qr-code-patent-trap/
">a
78 chance of getting sued...
</a
></p
>
80 <p
>I also asked if they planned to maintain the format in an
81 independent standard organization to give others more confidence that
82 they would participate in the standardization process on equal terms
83 with Visma, but they had no immediate plans for this. Their plan was
84 to work with banks to try to get more users of the format, and
85 evaluate the way forward if the format proved to be popular. I hope
86 they conclude that using an open standard organisation like
87 <a href=
"http://www.ietf.org/
">IETF
</a
> is the correct place to
88 maintain such specification.
</p
>
90 <p
><strong
>Update
2016-
03-
20</strong
>: Via Twitter I became aware of
91 <a href=
"https://news.ycombinator.com/item?id=
11319492">some comments
92 about this blog post
</a
> that had several useful links and references to
93 similar systems. In the Czech republic, the Czech Banking Association
94 standard #
26, with short name SPAYD, uses QR codes with payment
95 information. More information is available from the Wikipedia page on
96 <a href=
"https://en.wikipedia.org/wiki/Short_Payment_Descriptor
">Short
97 Payment Descriptor
</a
>. And in Germany, there is a system named
98 <a href=
"http://www.bezahlcode.de/
">BezahlCode
</a
>,
99 (
<a href=
"http://www.bezahlcode.de/wp-content/uploads/BezahlCode_TechDok.pdf
">specification
100 v1.8
2013-
12-
05 available as PDF
</a
>), which uses QR codes with
101 URL-like formatting using
"bank:
" as the URI schema/protocol to
102 provide the payment information. There is also the
103 <a href=
"http://www.ferd-net.de/front_content.php?idcat=
231">ZUGFeRD
</a
>
104 file format that perhaps could be transfered using QR codes, but I am
105 not sure if it is done already. Last, in Bolivia there are reports
106 that tax information since november
2014 need to be printed in QR
107 format on invoices. I have not been able to track down a
108 specification for this format, because of my limited language skill
114 <title>Making battery measurements a little easier in Debian
</title>
115 <link>http://people.skolelinux.org/pere/blog/Making_battery_measurements_a_little_easier_in_Debian.html
</link>
116 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/Making_battery_measurements_a_little_easier_in_Debian.html
</guid>
117 <pubDate>Tue,
15 Mar
2016 15:
00:
00 +
0100</pubDate>
118 <description><p
>Back in September, I blogged about
119 <a href=
"http://people.skolelinux.org/pere/blog/The_life_and_death_of_a_laptop_battery.html
">the
120 system I wrote to collect statistics about my laptop battery
</a
>, and
121 how it showed the decay and death of this battery (now replaced). I
122 created a simple deb package to handle the collection and graphing,
123 but did not want to upload it to Debian as there were already
124 <a href=
"https://tracker.debian.org/pkg/battery-stats
">a battery-stats
125 package in Debian
</a
> that should do the same thing, and I did not see
126 a point of uploading a competing package when battery-stats could be
127 fixed instead. I reported a few bugs about its non-function, and
128 hoped someone would step in and fix it. But no-one did.
</p
>
130 <p
>I got tired of waiting a few days ago, and took matters in my own
131 hands. The end result is that I am now the new upstream developer of
132 battery stats (
<a href=
"https://github.com/petterreinholdtsen/battery-stats
">available from github
</a
>) and part of the team maintaining
133 battery-stats in Debian, and the package in Debian unstable is finally
134 able to collect battery status using the
<tt
>/sys/class/power_supply/
</tt
>
135 information provided by the Linux kernel. If you install the
136 battery-stats package from unstable now, you will be able to get a
137 graph of the current battery fill level, to get some idea about the
138 status of the battery. The source package build and work just fine in
139 Debian testing and stable (and probably oldstable too, but I have not
140 tested). The default graph you get for that system look like this:
</p
>
142 <p align=
"center
"><img src=
"http://people.skolelinux.org/pere/blog/images/
2016-
03-
15-battery-stats-graph-example.png
" width=
"70%
" align=
"center
"></p
>
144 <p
>My plans for the future is to merge my old scripts into the
145 battery-stats package, as my old scripts collected a lot more details
146 about the battery. The scripts are merged into the upstream
147 battery-stats git repository already, but I am not convinced they work
148 yet, as I changed a lot of paths along the way. Will have to test a
149 bit more before I make a new release.
</p
>
151 <p
>I will also consider changing the file format slightly, as I
152 suspect the way I combine several values into one field might make it
153 impossible to know the type of the value when using it for processing
154 and graphing.
</p
>
156 <p
>If you would like I would like to keep an close eye on your laptop
157 battery, check out the battery-stats package in
158 <a href=
"https://tracker.debian.org/pkg/battery-stats
">Debian
</a
> and
160 <a href=
"https://github.com/petterreinholdtsen/battery-stats
">github
</a
>.
161 I would love some help to improve the system further.
</p
>