Invoicing system / invoiceplane / CRM - discussion and feedback

Systems
8

As I understand it this sounds like a suitable division because I doubt we’ll find (or have the resources to make) one-size-fits-ALL-purposes software. Eg. as a “non-tech worker” running the Membership Register, it’s a legal requirement, but essentially separate from, say, invoicing. It seems to suit a standalone spreadsheet. I find it’s easy to operate in that way, and I’d hope we can avoid making it more complex than need be.

9

From Developing an Invoice Control Plugin

Kill Bill by default knows nothing about tax, and that logic is deferred to plugins implementing this api.

Three tax plugins:

10

Interesting… also:

Our plugin system uses the OSGi standard and today we support plugins written in either Java or Ruby.

Kill Bill | Subscription Billing

And a couple of old Java examples are here:

And a hello world example:

Worth noting:

Kill Bill is a standalone Java server that runs in your back-end. Your customers will never interact with it directly, instead your website (it could be a custom e-commerce website, a Drupal or WordPress deployment, etc.) will trigger REST API calls (over HTTP) to process subscriptions or orders. We also provide Kaui , the Kill Bill administrative UI, an interface to interact with Kill Bill for your support and finance teams (to manage refunds, invoice adjustments, etc.).

Getting Started

Overview video:

It uses three Docker containers:

  • one for MariaDB (shared database, used by both Kill Bill and Kaui)
  • one for Kill Bill, Java server (accessible on port 8080)
  • one for Kaui, the admin interface (accessible on port 9090)

So it’ll be quick to fire up for a play but there would be a lot of work to write a front end for it and learn how to use it, we might have to develop our own VAT plugin, which is all rather daunting, but we might not have much choice if we want to use Free software?

It is a whole other level than InvoicePlane, Invoice Ninja or OpenSourceBilling…

11

One thing we can do to make a switch to a new system a little easier is to not import the, already issued, existing invoices, they can simply be left on InvoicePlane and we can keep it running for a few years (as we did with the last system).

12

The Making Tax Digital (MTD) stuff does look like the most important consideration here. If we cannot implement a solution (or find an open source one, which I haven’t so far), then it means using some external/commercial software :confused:

Seems to depend a lot on how valuable the commitment to open source is. There is always a line where the data goes into a closed source system (government, bank, payment gateway, etc.).

There are some docs here:

They have a test API service, etc.

Perhaps it’s something other co-ops will need too? If we were able to put something open source together it could be offered as a service… I think would be hard to convince people happy with shiny proprietary SaaS services though to use an ugly open source UI though.

I like the killbill option with my developer hat on :slight_smile: but the UI of OpenSourceBilling looks much nicer.

OpenSourceBilling says: Receive payments through Paypal and Credit card which seems a bit limiting if receiving payments is interesting to do (which I think could be…).

InvoicePlane2 seems pretty nice though and can take payments, but development also seems to be quite slow to get a v2 release (announced in June https://community.invoiceplane.com/t/topic/6299/ and last commit in August https://github.com/InvoicePlane/InvoicePlane/tree/v2.0.0)

Tricky!

1 Like
13

I agree it is a really tricky one, it appears to me that we have three broad options:

  1. Choose which simple open source system to knock into shape for MTD VAT submissions, I don’t have strong preferences between these three, they all appear to be broadly similar:
    • InvoicePlane 2
    • Invoice Ninga
    • OpenSourceBilling
  2. Build a client facing UI and MTD VAT plugin for KIll Bill.
  3. Choose a non-free software invoicing system with MTD VAT support.

Personally I’d really like to avoid 3. if possible, but I suppose that before we can make an informed decision we should have a basic idea of what the options available under 3. are, perhaps we should ask with other people are doing on the CoTech forum?

My concern with 1. is that it would probably be a bit of a bodge, the developers of these programs are not UK based and might not have any other users who are UK based and have a turnover greater than £85k and will therefore probably not want MTD VAT code to be added to the main repo and since they don’t have plugin APIs we might end up having to basically fork the code bases… best avoided — if we are going to do some serious development work we should start with a robust code base.

So 2. looks, in many ways, to be the best option, however there would be a very significant amount of work needed for this, both with learning how Kill Bill works, writing a MTD VAT plugin and also developing a client facing interface — do we have the time / energy / resources to take this on (and the we here would probably mostly be you @nicksellen…)?

14

I would like to support the desire to avoid 3 :slight_smile:

So maybe from here:

  • ask on the CoTech forum (you?)
    • if anyone already uses opensource approach, and what they are doing regarding MTD
    • which non-opensource tools people use
  • explore options 1 and 2 a little deeper
    • option 1 choices could be viable even without a plugin API by writing a standalone MTD VAT tool, if they have an API, or a stable enough database schema that we can connect directly to
    • for option 2 why the need for a client facing UI? do the things in option 1 offer this? is the idea for payment? viewing services? or what?

Did you try the killbill demo? - it seems the Kaui just implements the minimum for someone managing the day to day accounts, but not adding new product lines, etc. Which is presumably done over the API / with client libs.

http://docs.killbill.io/0.20/userguide_subscription.html is a description of how the model works, a bit long and detailed though!

15

Good idea re connecting directly to the database for option 2.

Yes, I’ll post some questions on the CoTech forum later this evening.

Yes, I tried the Kill Bill demo, I did wonder how you would add products, but I can see from the Kill Bill subscription guide that we might be able to get away with simply editing the XML catalog in a text editor…?

Currently, with InvoicePlane, clients have a URL at which they can view their invoice, download a PDF version and also click a link to pay via PayPal, I think we would need at least this, but in time it would be nice for clients to have more…

16

Done:

17

I missed this earlier — it looks like sticking with InvoicePlane probably isn’t going to be a long term option:

18

Ah good spot, not very clear from the homepage :slight_smile:

19

Yeah, also just found this:

We’re just getting started on a complete rewrite of our web app (you can read more about it here: https://www.invoiceninja.com/invoice-ninja-v2-0/ ). If there’s interest in the InvoicePlane community we’d be more than happy to try to support the features currently missing in Invoice Ninja which are supported by InvoicePlane.

You can automatically transfer your data from InvoicePlane to v1, and we’ll support an automatic migration to v2.

Also note that a team is due to be announced to take over the running of InvoicePlane but how that will work out in practice remains to be seen…

20

InvoiceNinja is starting a rewrite for version 2:

It isn’t clear yet if InvoicePlane version 2 will progress from a alpha release…

OpenSourceBilling has made it to version 2 but doesn’t appear to have suport for VAT numbers on invoices:

21

Another option?

Dolibarr ERP & CRM

Potentially Dolibarr could take over a lot of functionality, there is a ticket module and a IMAP email fetcher for it (both GPL V3 but for sale, €171). The stable install is packaged as a .deb. Their forum looks like a blast for the past after getting used to Discourse!

22

webERP

23

I want to hide under the duvet after looking at some of the code [1] - a massive sprawl of global variable style, jQuery in php strings, lots of commented out code, and all seemingly untested code that handles payments :confused: … and 880 issues in the tracker.

To be fair I didn’t look at the code the other projects.

[1] https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/stripe/payment.php#L455

24

That really doesn’t surprise me, I fear webERP might be the same…

25

Odoo

Looks interesting, but I noted there are 900+ issues and 1k+ pull requests(!).

26

ERPNext

This looks like the most promising option so far, see the ERPNext for Services page. But 1.6k issues but the install looks OK and it has a basic command line interface.

Video on how to set it up for different VAT rules for different countries:

Loads more on their YouTube video channel.

Here they differentiate themselves from systems such as Odoo and Dolibarr:

100% Open Source

Unlike other open source business platforms, ERPNext is fully Open Source, because unlike them, we don’t think sustainability and open source live at odds.

Most open source platforms in the ERP / CRM / E-Commerce space are open core . These communities makes money from closed extensions and services to monetize their efforts. We believe this is not only wrong, but not sustainable.

https://erpnext.org/open-source

One the list of ERPNext Service Providers there is one based in the UK:

27

Ooh erpnext does look pretty good. And python backend too. Tests. Modern libraries. Docs looks good too and lots of screenshots.

Supports gocardless too which is a nice low fee way to take payment.

(I originally sent this via email but it didn’t appear :confused: )

1 Like