Needing an EU VAT number for customers in other EU countries made me find a customer outside the EU. That is in spite of me not qualifying for VAT (self-employed with income below the threshold).
I think this bureaucracy discourages a lot of people from even starting a business.
I don't know where you are from and if the process is very different there but from the places I have experience with I would describe the process as, trivial.
Romania apparently. My country (Germany) isn't known for its easy to navigate bureaucracy but even here getting an EU VAT ID was trivial. Certainly easier than most of the other parts involved in starting a (legal) business. I think it was literally one of the documents they gave me to sign when I registered my company.
EDIT: I looked it up. It's literally just something you get to check off on the tax registration form for the company. Alternatively there's an online form (imagine that!) for existing companies. Impressively, there's no fax machine involved at any point.
This is great stuff! To use this in Canada, we have a few extra requirements as well. Firstly, we have to separate our tax onto two lines, one for Federal tax (called GST) and one for Provincial tax (has a different name in each province) and we are also legally required to include our Federal and Provincial tax registration numbers on the same line as the amount of tax being charged.
Even trickier is that some line items could also be tax-exempt.
A config option such as the following would help for that:
There's more to Canada tax rules than this, and they vary (like every country?). Some provinces have no provincial sales tax (one tax line), some provinces have Harmonized Sales Tax (HST) which aggregates GST and PST (one tax line). There's also no (federal) requirement to include your business number on the same line as the taxes.. it does need to be on the invoice if >$30 though.
Tax exemption at a federal or provincial level is then at the line-item level, not the invoice level (although perhaps invoice level is enough, for example agricultural products & prescription drugs shouldn't be taxed).
You may be required to charge the buyer's tax rate (rather than your operating tax rate).
And finally some goods/services have extra taxes (hospitality tax, for example).
running a company in the US makes you understand why companies tends to be successful there.
you can basically scribble an invoice on a napkin and it's gonna be ok, it's just so practical.
in other countries dealing with all the invoicing crap will burn you money and time while in the US you are already doing business, the upkeep is terrible.
This is nice. I wrote something like this a long time ago and actually used it to run my company for 1.5 years before moving to a web based system. The current code is over here https://github.com/hamon-in/invoice. These were my "features"
1. I used sqlite to handle everything including configuration
2. There was rudimentary templating. You could add a PDF letter head and then create a template using emacs org and it would render it onto the letterhead.
3. I was able to customise it quickly to move from one tax regime to another in India.
4. It would also generate an maintain timesheets (which employees send in as org files).
Thats a fun idea, I think I might add a public API endpoint to ZimTik to spit out invoices. Would be a little simpler with a system that already has all customer details and task details.
I'm not sure that's fair. The HN site guidelines encourage the submission of Anything that good hackers would find interesting. This is quite interesting, and the guidelines also suggest assuming good faith as to other's intentions.
The purpose of this tool is for generating invoices, not other documents. And it doesn't use a template, it writes a PDF using a Go library.
Totally, thanks so much! Also I do plan on adding different templates in the future through a --template flag which would write different PDFs based on the value selected.
Hey! Author here, I probably would have posted this to HN since this tool is just meant to make invoice generation possible from the command line. Now that we have this tool it's quite easy to add more templates (just another flag) and it can customize the look of the invoice.
Really nice to see! Since the past several years I'm working on a text based ERP system (that of course do invoicing as well). Nice to see that there's a demand!
So far it's an one person thing, I've been working on it on and off for 11 years. It has a this UI layer meaning that I so far has a text interface (that you can see a demo of here https://www.youtube.com/watch?v=W3kpD7om_aQ ) and a webb interface. Planning on adding android, ios, windows and os x as well.
Right now I've:
Accounting, CRM, Email, Products, Invoices, Quotes, Password manager, Tickets/Todos, Projects and basic IoT device monitoring and a static webpage generator. Most modules let the user add their own fields to a module so you can make if fit your needs.
Apart from this there's also lua support for reacting to events. Upcoming is webshop capabilities and cronjobs.
Feature sets are hard. But I'm prioritizing things my customers wants and what I need.
The best way to create invoices (not just invoices) IMHO is to use an html to pdf converter. There are several API services and you can use headless chrome to do it yourself. Easy to design an invoice using a web route and simply convert it to PDF.
Nope, the "easiest" way is to use a html to pdv converter, good enough for 90%.
But if you want precise good results (99%), you need to create it manually.
HTML to PDF is orders of magnitude slower than more direct PDF manipulation libraries in my experience, although I haven't used this particular library ( https://github.com/signintech/gopdf ) that this project uses so I can't say for sure.
I never liked wkhtmltopdf. We experimented with phantomjs, headless chrome, electron, headless firefox etc and headless chrome produces really good results at this point.
I did the same and ended up using Chrome to generate invoices too, after years of painful workarounds with other tools and methods. So much time was wasted on different tools and methods, until Chrome HTML print-to-PDF proved to be reasonably reliable and attractive.
Especially PhantomJS whose updates tended to break the invoice formatting severely (like radically changing the rendered font size in PDF across a PhantomJS update).
Firefox required a virtual X server, but that was doable. I'd prefer to use Firefox, but unfortunately its PDF rendering screwed up the thickness of border lines, making them far too thick or not present at all, though it did a better job of pagination than Chrome.
And even having settled into using Chrome for this, there are two ways to generate a print-to-PDF that produce different results in Chrome, at least when it's Chrome on MacOS. Only one of them lays out my invoice PDFs correctly.
It most certainly is. Never had a reason to create pdf documents fast though. Even when you have a user waiting for a PDF download it is generally acceptable.
Honest question, can't this be achieved with troff/groff and maybe in combination with m4? This is one of the tools on my TOLEARN list as is something that has been forever in the command line tools.
Yes, this is definitely possible with troff/groff/latex/etc... I built this tool as I wanted nice looking invoices that could be generated instantly. I want to add templates in the future so that I can change the style as well. I spend most of my time on the CLI so having interoperability with other tools such as `date` and `time` etc... to combine commands and script the generation process was one of my goals.
39 comments
[ 3.9 ms ] story [ 110 ms ] threadI think this bureaucracy discourages a lot of people from even starting a business.
EDIT: I looked it up. It's literally just something you get to check off on the tax registration form for the company. Alternatively there's an online form (imagine that!) for existing companies. Impressively, there's no fax machine involved at any point.
Well, now that's a fa(u)x pas(s).
Even trickier is that some line items could also be tax-exempt.
A config option such as the following would help for that:
And to handle items that are tax exempt, an item can have the:Tax exemption at a federal or provincial level is then at the line-item level, not the invoice level (although perhaps invoice level is enough, for example agricultural products & prescription drugs shouldn't be taxed).
You may be required to charge the buyer's tax rate (rather than your operating tax rate).
And finally some goods/services have extra taxes (hospitality tax, for example).
https://www.canada.ca/en/revenue-agency/services/tax/busines... https://www.canada.ca/en/revenue-agency/services/tax/busines...
you can basically scribble an invoice on a napkin and it's gonna be ok, it's just so practical.
in other countries dealing with all the invoicing crap will burn you money and time while in the US you are already doing business, the upkeep is terrible.
Would be great if we could integrate this with some go template language, would make customization easier.
1. I used sqlite to handle everything including configuration
2. There was rudimentary templating. You could add a PDF letter head and then create a template using emacs org and it would render it onto the letterhead.
3. I was able to customise it quickly to move from one tax regime to another in India.
4. It would also generate an maintain timesheets (which employees send in as org files).
I'm going to go out on a limb and say this is not something that the author would have posted to HN. It's just https://news.ycombinator.com/submitted?id=ingve submitting another post.
The purpose of this tool is for generating invoices, not other documents. And it doesn't use a template, it writes a PDF using a Go library.
I'm having same considarations, but strugling with finding the best feature-set
Right now I've: Accounting, CRM, Email, Products, Invoices, Quotes, Password manager, Tickets/Todos, Projects and basic IoT device monitoring and a static webpage generator. Most modules let the user add their own fields to a module so you can make if fit your needs.
Apart from this there's also lua support for reacting to events. Upcoming is webshop capabilities and cronjobs.
Feature sets are hard. But I'm prioritizing things my customers wants and what I need.
Especially PhantomJS whose updates tended to break the invoice formatting severely (like radically changing the rendered font size in PDF across a PhantomJS update).
Firefox required a virtual X server, but that was doable. I'd prefer to use Firefox, but unfortunately its PDF rendering screwed up the thickness of border lines, making them far too thick or not present at all, though it did a better job of pagination than Chrome.
And even having settled into using Chrome for this, there are two ways to generate a print-to-PDF that produce different results in Chrome, at least when it's Chrome on MacOS. Only one of them lays out my invoice PDFs correctly.