Join us on the #v2 channel on Slack to help hammer out the details for the next version of the app
Hi,
I don’t understand the InvoiceNinja I downloaded a couple of days ago, is already version v4.5.7 (now I see there’s a version 4.5.8) … so what’s the story with version 2 ?
Is InvoiceNinja a time travel machine ? 
Cheers,
L@u
The majority of our users are on our hosted platform and aren’t aware that we’re currently at version v4.5.x. To make it clearer that we’re rebuilding the app we’ve chosen to label it ‘v2’.
I’ve been wondering about this myself. While I understand the reasoning behind it, it really does confuse things when it comes to versioning. Perhaps instead of v2.0, it could get a new name for the end-user, and the internal versioning stays consistent? Like how Debian has Stretch, Wheezy, Jesse, etc., and Windows for a while had Millenium, XP, or Vista, and the version number is more of an internal thing. Maybe Invoice Ninja Redux or Invoice Ninja Reloaded (or something far less cringeworthy than what I just suggested)? Something that references the fact it’s a very mature product these days, and then the only people who need to worry about version numbers would be the self-hosted users.
That’s the thing… v2 won’t be a mature product, in many ways we’ll be starting over.
I expect there will be many bugs with the early v2 releases. That said, in the end I’m confident it will be the best invoicing application on the market 
Did I say mature? I meant “Something that references the fact it’s a very mature product these days completely new build of the same core product.”, lol.
But yeah, having an internal versioning with a completely different external version number in the name could lead to some consternation. Invoice Ninja Neo perhaps?
Just kidding. I’ll stop coming up with cringey names now.
I hear you… this was a tradeoff between confusing one group of people vs another.
The main problem that i have with the invoice ninja is that i can’t have invoices just for services !
I am wondering if it is possible the user to choose invoices for services or items, or if you can leave the user to build it buy himself
Thanks for your feedback, we’ll keep it in mind for v2.
One workaround in v1 is to invoice a task, add the services and remove the task.
Thanks for your reply.
Yes this works fine but it is a little bit tricky
Personally I think V2 should become Accounting-Ninja (or ERP-Ninja). So many products in that space fall short of the mark – just like your competitors in the Invoicing-only segment.
Adding features is probably a wise move.
Meanwhile:
in many ways we’ll be starting over
This can be really dangerous. Consider Joel Spolsky’s wise comments on this.
There’s also a good “graphical” analysis of the pitfalls (and possible benefits) of a re-write here.
What “latest and greatest web technologies” do you envision? Different framework? Different programming language altogether?
I’ll connect via Slack. Perhaps some of these questions are answered there, but people here would probably like to know.
Thanks for your feedback!
I’m a big fan of Joel Spolsky and have read his blogs for many years. We’re extremely aware that many v2’s fail and are keeping this at the front of our mind for all decisions we make.
The most common reason for failing is trying to overachieve, as such we’re being extremely selective with any features we’re adding.
Accounting features is a good example of this, it most likely won’t be included in v2. Although many of our users have requested it overall they represent a small minority of our user base. Additionally, this would be a non-trivial feature for which we have very little domain knowledge/experience.
Most of the JavaScript in v1 was written using KnockoutJS, it’s now an extremely outdated library. For v2 we’ll be using VueJS and TypeScript which are substantially better. For server side we’ll be sticking with Laravel (enabling us to share a large amount of code) however we’ll be using the latest version.
Hi Hillel:
“trying to overachieve” is probably not the greatest pitfall.
Paraphrasing Spolsky and others, a rewrite takes a lot of time to get back to “baseline”. Meanwhile, your competitors are adding features.
That said, I certainly understand that you want to use more current libraries and that can (fortunately) ultimately speed up adding features! My big fear was that you were going to completely abandon Laravel . . . or, worse, rewrite Invoice Ninja in something other than PHP. [ And that’s saying a lot – since I don’t like some of the underpinnings of Laravel (largely because of its mass). ]
Don’t worry too much that you “have very little domain knowledge/experience” in “accounting.” I guess the biggest hurdles might be issues like exchange of data with banks. Given your expertise working with a host of 3rd party payment processors, you would probably find dealing with bank data exchanges fairly straightforward.
Invoice Ninja already has so much of the conceptual plumbing required for a more complete “accounting” package it would be a shame to not go there in the near future.
A couple additional thoughts:
- Reinventing the "wheel" is not necessary. There are certainly accepted best practices for accounting features.
- You could liberally copy or mimic other good implementations like QuickBooks Online or (open source) Akaunting or Firefly III
Sorry, our view is pretty set on this. Double ledger accounting will simply add too much complexity for the majority of our users. Hope you still keep using the app…
Just to add… if anyone in the community wants to implement it as a custom module we’d gladly work with you to ensure you have the access needed in the code.
Hi Hillel:
Double ledger accounting will simply add too much complexity for the majority of our users.
It would be cool (and potentially eye-opening!) to run a poll to see what your users use for their more complete accounting package (i.e. beyond Invoice Ninja).
You might find that most (or many, at least) have the same problem as we do: there aren’t (m)any good self-hostable accounting packages in the PHP space. Some companies (like Akaunting) are working on it, but they seem to have a very long way to go before they reach any reasonable parity with something like QuickBooks Online.
My impression (having monitored your development pace for a couple years now) is that you could probably beat them to a “good usability” baseline.
Hope you still keep using the app…
As you can infer from my participation of late, yes, of course I will continue to examine and work with Invoice Ninja. I’ll keep providing constructive feedback too.
My biggest issue right now is that there is no good way to add recurring “items” for service invoices. I have (better) described this elsewhere.
Hello !
I am looking for the roadmap, the list of functions or new features for the future version: where can I find them ?
If I have suggestions, where can I post them ?
BR,
Marc
InvoiceNinja : 4.5.9
Debian GNU/Linux 9.7 (stretch)
Nginx : 1.10.3
MariaDB : 10.1.37
White labeled
Hi,
Quick question - is there a way that I can use this with a .net web app?
Please advise.