Live data from Hacker News

Generating PDF invoices using Lago

getlago.com

41–50 of 56 posts

Re: Generating PDF invoices using Lago

#41
post #36
post #23

Cool idea, I can see how this would be useful once you're dealing with more than a few invoices per month. For those like me that do indeed only send out a few a month, I've found the Numbers app on Mac to have a very nice invoice template that you can customize, fill out, and generate a professional-looking invoice from.

You can self host Lago for free under AGPLv3 licence. You have access to the entire billing service (UI, API and all related services). Feel free if you need a proper demo

Very nice! I hope to soon get to the point where I need this. I'm bookmarking this.

Re: Generating PDF invoices using Lago

#42

Earlier quoted context omitted.

Backend: Software application(s) that run on the server that provide the service.

Thank you so much for the definition, to clarify: as the API is already open source, see above comments, I was asking what else was requested / missing.

API just defines how another software can connect and interact with your software application. An API being "open" just means that the documentation of the way to connect and interact through an API is publicly available. The "Open Source" terminology however applies to source code of a software. If someone claims an API is "open source", it means the source code of the application providing the API is publicly available. In this case, the API is offered as a service and the software application that actually exposes and executes the API is on a server. That is why people are asking if the API is open source, where is the source code of the backend.

Edit: I can see now that someone has posted a link to the repository of their backend / API source code too. Many must have missed that earlier, and hence the query.

Re: Generating PDF invoices using Lago

#43
post #24

Not sure this actually solves a real problem. A lot of the questions/problems mentioned in the article are already things being addressed by any service worth using. At the end of the day, you just need to generate a PDF from a template. The template is a solved problem. Invoices generally do not have that huge amount of variability in terms of layout. I have been using microinvoice ( https://github.com/baptistejamin…

Subscription plans? Sure, you solve it with a single static template. The problem is reduced to producing PDFs (at scale).

But intricate pricing is unavoidable in some industries. Often to materialize physical or logistical constraints. Take cloud computing. There is elasticity, but some order of magnitudes are only reachable if you pay the price. Or you might get volume discounts. All of this requires segmented pricing.

How would you lay out an n-dimensions matrix on a 2D piece of paper? This is data design all over again.

With an invoice targeting the right audience, you can let your customer figure these complex schemes by themselves (and have them not feel cheated). It will make your support team happy to not have to answer the "where my money goes?" question ad nauseam.

And at the end we can't just send a JSON dump to the bookkeepers. The law still requires that document we call an invoice. So yes, I think invoice UX is a thing and is here to stay.

Re: Generating PDF invoices using Lago

#44
post #24

Not sure this actually solves a real problem. A lot of the questions/problems mentioned in the article are already things being addressed by any service worth using. At the end of the day, you just need to generate a PDF from a template. The template is a solved problem. Invoices generally do not have that huge amount of variability in terms of layout. I have been using microinvoice ( https://github.com/baptistejamin…

Is a PDF invoice typically expected to be generated every time you’re billed, or only when someone clicks “View PDF Invoice”? It seems like the % of customers that care to have PDF over an HTML page would greatly affect the need for scalability. What is this percentage, I don’t know. I wouldn’t have guessed high. Anecdotally even when I’ve preferred a PDF invoice, it’s been on a case by case basis.

The PDF is triggered when it’s requested from the UI or from the API. The job is asynchrone, so it’s returned when it’s ready (generally in milliseconds). This prevents performance issues

Re: Generating PDF invoices using Lago

#45
post #24

Not sure this actually solves a real problem. A lot of the questions/problems mentioned in the article are already things being addressed by any service worth using. At the end of the day, you just need to generate a PDF from a template. The template is a solved problem. Invoices generally do not have that huge amount of variability in terms of layout. I have been using microinvoice ( https://github.com/baptistejamin…

Is a PDF invoice typically expected to be generated every time you’re billed, or only when someone clicks “View PDF Invoice”? It seems like the % of customers that care to have PDF over an HTML page would greatly affect the need for scalability. What is this percentage, I don’t know. I wouldn’t have guessed high. Anecdotally even when I’ve preferred a PDF invoice, it’s been on a case by case basis.

In France and in most countries in EU, it's mandatory to have a PDF that follows very pecific guidelines. Can't say for sure for every country though!

Re: Generating PDF invoices using Lago

#46

12 years ago, I was working on a contract for an aircraft spares supplier. One of the hard requirements: all sales invoices, purchase orders, quotations, invoices, and so on, had to be printed AND available as PDF. The solution was to use JasperReports. The business could design their templates in a iReport Designer, test with dummy data, put the jrxml templates in a dedicated storage, and a simple http call would me…

> had to be printed AND available as PDF.

You just reminded me of a customer I was working for as a junior ERP consultant. They required us to have the proof a document was printed by a user.

I went far down the rabbit hole trying to come up with an end-to-end solution involving cryptographically signed messages sent to the printer, a physical QR code on the document to be scanned back for validation, and others convoluted half-backed contraptions. But I couldn't find an unhackable way to reconcile the state in the machine with the reality of the physical world.

A senior consultant solved it in 10 minutes. Showed them. They were ecstatic and we were paid.

What has he done? Just updated a "printed" column in the database to "True" when the user clicked the HTML "print" button.

Re: Generating PDF invoices using Lago

#47

Earlier quoted context omitted.

Is a PDF invoice typically expected to be generated every time you’re billed, or only when someone clicks “View PDF Invoice”? It seems like the % of customers that care to have PDF over an HTML page would greatly affect the need for scalability. What is this percentage, I don’t know. I wouldn’t have guessed high. Anecdotally even when I’ve preferred a PDF invoice, it’s been on a case by case basis.

In France and in most countries in EU, it's mandatory to have a PDF that follows very pecific guidelines. Can't say for sure for every country though!

The information required on a EU invoice is detailed by Article 226, Section 4 (Content of invoices) of Council Directive 2006/112/EC on the common system of VAT: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:...

Re: Generating PDF invoices using Lago

#48

12 years ago, I was working on a contract for an aircraft spares supplier. One of the hard requirements: all sales invoices, purchase orders, quotations, invoices, and so on, had to be printed AND available as PDF. The solution was to use JasperReports. The business could design their templates in a iReport Designer, test with dummy data, put the jrxml templates in a dedicated storage, and a simple http call would me…

> had to be printed AND available as PDF. You just reminded me of a customer I was working for as a junior ERP consultant. They required us to have the proof a document was printed by a user. I went far down the rabbit hole trying to come up with an end-to-end solution involving cryptographically signed messages sent to the printer, a physical QR code on the document to be scanned back for validation, and others conv…

In this case, the business owner would go through every printed document that landed on his desk. He really did, every day… it had to be printed, otherwise it did not exist.

Regardless what we think about it, the man was driving a Zonda and his garage has seen a couple of Koenigseggs, and I still build software.

Re: Generating PDF invoices using Lago

#49

Generating a custom PDF is just such a pain. You don't know it before you tried to do it. I've seen Anvil (a YC co) is building a product dedicated to this challenge, check it out!

If I needed to generate PDFs, I would use ReportLab[1]. The core is open source and there's a great company behind it. The product appears easy and mature. What am I missing? 1. https://docs.reportlab.com/

I have PTSD from 20 years ago trying to convert OpenOffice documents to PDF with ReportLab. It was janky because all elements had to be positioned in absolute coordinates to the virtual page.

Nowadays I'll go straight to https://weasyprint.org to produce PDFs in Python. That's what I used for https://scaleway.com invoices.

Re: Generating PDF invoices using Lago

#50

Earlier quoted context omitted.

> had to be printed AND available as PDF. You just reminded me of a customer I was working for as a junior ERP consultant. They required us to have the proof a document was printed by a user. I went far down the rabbit hole trying to come up with an end-to-end solution involving cryptographically signed messages sent to the printer, a physical QR code on the document to be scanned back for validation, and others conv…

In this case, the business owner would go through every printed document that landed on his desk. He really did, every day… it had to be printed, otherwise it did not exist. Regardless what we think about it, the man was driving a Zonda and his garage has seen a couple of Koenigseggs, and I still build software.

Sounds like he had some sort of business discipline. Or worse, couldn't delegate and had to double-check everything by hand. Paper was his medium of choice in which he felt productive for this particular task.

In my case I'm pretty sure the owners didn't care about the printed documents and never checked them. It was just required to have a proof because... process.

That's when I understood ERPs were not about software but workflow. Not a solution either, but a symptom. Some requirements are bullshit, because nobody has the time (or mandate) to question the sacred Process.

I quit doing ERPs not long after that.

Post reply on HN