October 15, 2018 at 4:49 pm #16689October 17, 2018 at 6:27 am #16703
Join us on the #v2 channel on Slack to help hammer out the details for the next version of the appJanuary 11, 2019 at 2:11 pm #18210
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 ? 😉
[email protected]January 11, 2019 at 2:19 pm #18211
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’.January 12, 2019 at 12:28 am #18217
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.January 12, 2019 at 4:44 pm #18224
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 🙂January 13, 2019 at 4:37 am #18240
Did I say mature? I meant “Something that references the fact it’s a
very mature product these dayscompletely 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.January 13, 2019 at 6:05 am #18242
I hear you… this was a tradeoff between confusing one group of people vs another.January 13, 2019 at 9:03 am #18248
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 himselfJanuary 13, 2019 at 9:09 am #18249
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.January 13, 2019 at 9:13 am #18250
Thanks for your reply.
Yes this works fine but it is a little bit tricky 🙂January 24, 2019 at 6:48 am #18488
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.
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.January 24, 2019 at 8:36 am #18498
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.
“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:
January 24, 2019 at 6:52 pm #18536
- 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…January 24, 2019 at 7:47 pm #18537
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.January 30, 2019 at 4:54 am #18747
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.February 21, 2019 at 3:52 pm #19581
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 ?
InvoiceNinja : 4.5.9
Debian GNU/Linux 9.7 (stretch)
Nginx : 1.10.3
MariaDB : 10.1.37
White labeledFebruary 21, 2019 at 4:21 pm #19582August 17, 2019 at 3:01 pm #21624
Quick question – is there a way that I can use this with a .net web app?
You must be logged in to reply to this topic.