The Future of InvoicePlane

Announcements
1

The Past

A few months ago, Kovah asked the community to find new maintainers so that he could step away and allow people who could dedicate more time and resources into growing and guiding InvoicePlane’s future.

Those who kept up with the community forums would have seen that a number of people stepped up to help keep InvoicePlane going, with the new maintainers brought in and over the last few months have been tweaking and changing things so Kovah could finally retire.

The Present

These are now all done, new hosting for the sites has been set up and been moved, leaving us now to thank Kovah for all his hard work, for his guidance and time were given to this incredible OpenSource project and for the new maintainers to guide InvoicePlane forward.

Today we announce where we are taking InvoicePlane, with the support of you, our users, fellow developers, and sponsors, we hope we can continue to make InvoicePlane your choice of software for invoicing.

The Future

InvoicePlane v1.5.9 - will be continuing bug and security fixes, with v1.5.10 aimed for the 1st of June 2019, with interworked quarterly releases with InvoicePlane v2 thereafter.

With the discontinuation of PHP 5.6, we are looking to migrate InvoicePlane v1 up to PHP 7.1 but the sheer number of changes in the core of InvoicePlane’s code, we have been extensively discussing how best to achieve minimal changes but maximize future compatibility.

We will be opening up the paths we can take after the release of v1.5.10 to see what the community believes is the best path forwards for InvoicePlane v1, this will, however, work alongside our v2 development.

InvoicePlane v2 - has caused us a lot of heartache in deciding where to take the development forward, the original developer of the current code has hinted that they may be continuing to develop their project commercially and its unlikely we would be able to work together on fixes or features.

We have come to the decision to not continue developing the code provided, instead to ourselves start from scratch on a wholly new InvoicePlane v2.

We can only apologize to those who have spent their time getting to know the current alpha code but we are pleased to say that it’s not all for nothing.

InvoicePlane v2 will continue to be based on the Laravel 5.7 framework but will be visually served by CoreUI Pro using Bootstrap 4, all an earlier idea of Kovah’s which sadly struggled to gain traction.

One of our core desires for InvoicePlane v2 is to be modular, flexible and scalable, from a small independent freelancer up to large companies who need to comply with local tax laws and digital submissions yet portable with mobile & tablet ready design, even so far as to have dedicated apps.

Final Words

We want InvoicePlane to be the software of choice for people and we’re actively investing in InvoicePlane to ensure it endures through these changes and develop it as the first choice in Open Source invoicing software.

9 Likes
3

Thanks for this post.

I’am one of the users come over from FusionInvoice. I did even use MyClientBase back in 2011 +/- 1 year. I loved all of it. As my requirements has grown, I started to implement AddOns and templates for myself and my clients… dozents…

I was really sad to see, that FusionInvoice disappeared. I downloaded InvoicePlane 2.0 Alpha 1 and started testing. I even set up 2 instances in december for clients as of I thought the disappearing of FusionInvoice was a final decission.

Since two weeks I mentioned, that they maybe come back and I was really interested in what’s going on here now. It’s sad to read that you plan to not migrate to FusionInvoice 2 but to start a new Codebase. I think this is not the right decission, you will lose a lot of time and potential users, but OK, it’s up to you.

Hint: FusionInvoice is already modular. There are devs out there (like me) who implement a lot of AddOns. Migrating to an OpenSource and maybe also donate to an OpenSource sounds like a good option to migrate all the existing AddOns/Templates…

Please answer one Question: Is the current database schema of 2.0 Alpha 1 compatible to the latest FusionInvoice, so I can migrate from 2.0 Alpha 1 to the next FusionInvoice version?

4

@lippoliv - as InvoicePlane v2.0 Alpha 1 undertook no database changes from the FusionInvoice 08-2018 release, we can only hope it will continue to work with any plans the developers may have.

There are other issues behind why we took this decision and I hope in time we can prevail in showing that this may be the harder path but the most rewarding for all.

1 Like
5

Thanks for the reply. I really wish you all the best for this, no joke.

6

Damn that sounds so good.

Yes I hoped that so hard! For me this is 100% the right decision

Its like christmas and B-Day at the same day :heart_eyes:

Yes :muscle: hopefully all with something where we can change Sass variables to customize it.
Love that, and CoreUI looks so good/professional!!

But I also have some questions:

Are some quicker BugFixes planned?
Like the fix to support PHP7.3?
Which already exists here in the Forum. → LINK

Is there a ETA for a Pre-Alpha for IP2? Because I would really love to test IP2 and report back.

1 Like
7

The hope is to get all the current fixes out by this weekend, time permitting, especially to ensure support of php7.3.

A Pre-Alpha for IP2 will be as soon as we can get the structure set up and the documentation up to standard to go alongside it. We are not slacking on the documentation and we want to ensure anyone can pick it up, work out where to go and get done what they want to do.

2 Likes
8

Interesting to see what’s happening guys. We would be willing to maintain the payments element going forward if that was of interest and a burden to you? We would look to switch out the current payment stack for our own and use our API, let me know if you want to discuss. Here’s more info. https://www.paywithbolt.com/saas-providers/invoicing-software-payments/

9

Nick what do you need exactly? A connection from invoiceplane to bolt? Then push invoice info to your api?

10

Yes, basically a connection from invoiceplane to Bolt is what we’d need. Then hit our end points with invoice data and we’ll fire webhooks on success, which can then be used to trigger receipts or whatever in invoiceplane. We maintain the payments infrastructure so you’d never need to recode the integration unless there were new end points or something, which we could amend for you. We’re also delivering new gateway integrations every month, which would then be available in invoiceplane. You’re welcome to do the integration yourself but I was offering resource.

1 Like
11

It’s definitely an interesting proposal, I’d be interested to know if the API would be able to support subscriptions as well as one-off charges.

I’d ultimately have to see what the community votes on, my initial thoughts would be to give users the choice, either on install as a module (ie IP-Payments Module || or || Pay with Bolt Module)

Could you also suggest your competitors and why your solution would be the best or better option over the rest?

12

No problem, yes you can do recurring payments either via card or direct debit or ACH in the near future via the API.

We’re aiming to become the defacto standard for connecting payment providers. Lots of our clients phase out their existing payments module and replace it with ours so this could be a way to go. I just thought it would be a lot easier for invoiceplane to maintain, with no cost to you or the platform. Users can use our service for free or pay $16 to brand the payment popup.

Our competitors for payments integrations could be Spreedly or the open source project called Active Merchant. However neither of those are a turnkey solution like ours. And secondly we are the biggest third party provider to QuickBooks for online invoice payments and payment gateway integrations. We have proper partnerships with the payment providers, card issuers and industry. We also provide an SLA are PCI DSS Level 1 compliant. Happy for the community to vote. Let me know if you want to know anything else or if you guys want to do the integration yourselves - https://paywithbolt.com/1weekchallenge

1 Like
13

I would not be in favour of a module being restricted to a single service, Implementations need to have a choice of payment providers. InvoicePlane should supply the hooks -service providers like yourself should be welcome to mould your offering to suit the requirements of the project, and to offer code enhancements to IP itself.

1 Like
14

Thanks for the update, I have a question, I am a new user and I started with v2 already. Is there a way to migrate back to 1.5.9 ?

15

Sadly not, there are massive differences between IP v1 and the former Fi/IP v2 software.

1 Like
16

Hi Crafter, we package up lots of payment providers: Stripe, PayPal etc. We release more providers every few months. I’m not sure you get what I was offering. Happy to talk about it further

17

Hi

I think it may be worth considering both, the current OmniPay as a module and PayWithBolt as a module, with agreement with the community. Would there be any discount that could be offered for your premium offering?

18

I think these Modules should not get shipped with the new IP2 Version by default, everyone who wants to have them should install them if he needs it.

For me it would be better if basic things like:

  • fully PayPal integration
  • AmazonPay integration
  • Banktransfer
  • etc

would be perfectly integrated out of the box and if its not enough for someone he can install some of the mentioned modules (OmniPay, PayWithBolt) etc.

I generally think that using things directly is much better and makes you independent and not depending on other services. Also services like these can change conditions and prices over night.

For me: I dont need PayWithBolt (also never heard about). So I personaly dont wanna have it in my IP2 but making IP2 support it (for other users then me) would make sense.

1 Like
19

That’s fine, the point is that as the dev. team you’ll have to maintain all these integrations yourselves. We won’t change prices on you, and you can use our service for free. If this is too challenging to wrap your heads around that is fine, I was just following invoiceplane and trying to help you get IP2 going.

20

The only reason you’d want our premium offer is if you want to white label the payments. I can give you a discount on that, but you can use our service fully featured for free. OmniPay is effectively an open source type competitor to us based on Active Merchant - why are we better than OmniPay or Active Merchant, because we have partner agreements with the payment providers, we also do a lot more of the heavy lifting in terms of the merchant on-boarding and checkout.