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
Generating PDF invoices using Lago
41–50 of 56 posts
Re: Generating PDF invoices using Lago
#42Earlier 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.
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
#43Not 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…
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
#44Not 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.
Re: Generating PDF invoices using Lago
#45Not 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.
Re: Generating PDF invoices using Lago
#4612 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…
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
#47Earlier 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!
Re: Generating PDF invoices using Lago
#4812 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…
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
#49Generating 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/
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
#50Earlier 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.
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.