Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UsingQR – “Electronic” paper invoices using JSON and QR codes

people.skolelinux.org

Post reply on HN
Print view View original

11–20 of 28 posts

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#11

Post by jon-wood »

dfox wrote: post #9

In Czech republic, QR codes that encode payment details for invoices are pretty common. It uses format called SPAYD for encoding of data which is variation of vCard formatting (as proposed in the begining of this article). Idea is that the same data in this format could also be transfered directly, but that is not so common, probably because there also is widely supported national standard for XML representation of e…

I routinely pay my cellphone bills by doing absolutely nothing (apart from having a skim of my bank statement now and again). In the UK almost all regular payments are done using Direct Debit, where you grant the company billing you permission to transfer the money automatically. Sadly it lacks the ability to specify an upper bound on that, but I've yet to have any issues in practice so I'm not massively worried.

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#12

Post by fit2rule »

jakub_h wrote: post #8
xfour wrote: post #3

Earlier quoted context omitted.

Only problem with this is it discourages shifting to paper-less business. Remember when that was a goal of business and government. It's been so successful via the fact that it's simply easier than shuffling papers about. That being said, it is clever, sort-of a 255byte or so flash-rom storage on a piece of paper.

I love the way in which LibreOffice can export a PDF with the original document still embedded. If a scannable code on a paper document could contain all the data needed to recreate it without any loss, you'd get effectively the same thing in a tangible form.

"This PDF is a Webserver, which will serve this PDF."

(See Chapter 9).

https://www.alchemistowl.org/pocorgtfo/pocorgtfo11.pdf

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#13

Post by josemrb »

In Bolivia, starting this year, all the electronically printed invoices have to include an QR code that contains the necessary information for tax filling.

Having one of the worst tax system in the world I'm surprised that somebody had the idea to implement this mechanism.

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#14

Post by randommodnar »

jon-wood wrote: post #11
dfox wrote: post #9

In Czech republic, QR codes that encode payment details for invoices are pretty common. It uses format called SPAYD for encoding of data which is variation of vCard formatting (as proposed in the begining of this article). Idea is that the same data in this format could also be transfered directly, but that is not so common, probably because there also is widely supported national standard for XML representation of e…

I routinely pay my cellphone bills by doing absolutely nothing (apart from having a skim of my bank statement now and again). In the UK almost all regular payments are done using Direct Debit, where you grant the company billing you permission to transfer the money automatically. Sadly it lacks the ability to specify an upper bound on that, but I've yet to have any issues in practice so I'm not massively worried.

Do not do this!!!

If you end up in a dispute with your phone company, you are putting yourself at their mercy. It's waaay easier to fight a charge you haven't paid yet, then to recover money you've already paid.

I've gone through hell because of this.

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#15

Post by userbinator »

Why JSON?

QR can store binary data. Something like BSON would make a lot more sense, given the tiny amount of storage in a QR code. Even ASN.1 seems more appropriate than the silly data->ASCII->ASCII-structured-format->binary encoding that's going on here, and admittedly in a lot of other transport formats too.

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#16

Post by jvhaarst »

randommodnar wrote: post #14
jon-wood wrote: post #11

Earlier quoted context omitted.

I routinely pay my cellphone bills by doing absolutely nothing (apart from having a skim of my bank statement now and again). In the UK almost all regular payments are done using Direct Debit, where you grant the company billing you permission to transfer the money automatically. Sadly it lacks the ability to specify an upper bound on that, but I've yet to have any issues in practice so I'm not massively worried.

Do not do this!!! If you end up in a dispute with your phone company, you are putting yourself at their mercy. It's waaay easier to fight a charge you haven't paid yet, then to recover money you've already paid. I've gone through hell because of this.

The bank doesn't allow you to roll back the automatic transfer of money ? Over here (NL) all banks allow you to retrieve your money without any hassle within about 2 months.

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#17

Post by arnarbi »

userbinator wrote: post #15

Why JSON? QR can store binary data. Something like BSON would make a lot more sense, given the tiny amount of storage in a QR code. Even ASN.1 seems more appropriate than the silly data->ASCII->ASCII-structured-format->binary encoding that's going on here, and admittedly in a lot of other transport formats too.

Not wanting to start flame wars, but consider CBOR instead of BSON (which only really makes sense if you want to integrate with MongoDB).

http://cbor.io/

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#18

Post by foldr »

randommodnar wrote: post #14
jon-wood wrote: post #11

Earlier quoted context omitted.

I routinely pay my cellphone bills by doing absolutely nothing (apart from having a skim of my bank statement now and again). In the UK almost all regular payments are done using Direct Debit, where you grant the company billing you permission to transfer the money automatically. Sadly it lacks the ability to specify an upper bound on that, but I've yet to have any issues in practice so I'm not massively worried.

Do not do this!!! If you end up in a dispute with your phone company, you are putting yourself at their mercy. It's waaay easier to fight a charge you haven't paid yet, then to recover money you've already paid. I've gone through hell because of this.

You can always get a direct debit refunded by your bank in the UK. It's then the company's responsibility to pursue the debt if they believe that you owe them the money.

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#19

Post by Roritharr »

I'm in this space in Germany, where such ideas are always taken to their logical extremes.

The current push towards creating some kind of standard for electronic invoices (which would allow for a standardized data package to be transformed into QR) is called ZUGFeRD.

http://www.ferd-net.de/front_content.php?idcat=231 The Zip(?!?) Containing the specification can be found here:

http://www.awv-net.de/updates/zugferd/zugferd10.zip

This is a push towards adding data to the PDF Metadata that would allow for digitally reading of that electronic invoice by financial systems.

The current problem, from my reading, is that there is not enough players that see a positive ROI for implementing this standard on a wide scale on systems where it would make sense.

Re: UsingQR – “Electronic” paper invoices using JSON and QR codes

#20

Post by thesimon »

A german banking app already tried to do something similar [0], but used the QR code to encode an URL containing all data instead. It seems a bit more efficient.

But FWIW, it never got popular. I guess you can tell by the design of the website.

[0] http://www.bezahlcode.de (In German only)

Edit: It is actually not encoding all data of the invoice, but only the bank details needed for the transfer.

Post reply on HN