Invoicing system / invoiceplane / CRM - discussion and feedback


#1

The scope here could be smaller or larger, I’d just like to collect together a few needs/ideas/discussions to inform what to do next.

It has potential to balloon in scope too much, so I would be keen to avoid that by collecting lots of thoughts, but not expecting to solve them all with a Magic Solution, but just be able to improve at least something.

In https://wiki.webarch.net/wiki/Nick's_writeup_of_thoughts, I wrote:

  • invoiceplane 1.x is current system

  • invoiceplane 2.x is a totally different system, not released yet

  • evaluate new invoicing software, consider integrating membership management too

    • invoiceninja (self hosted option allows all features from pro/enterprise too). does a lot more than just invoicing.
    • other options?
  • timescale, perhaps by January or February aim to have system in place? to coincide with VAT registration needs too?

  • goals:

    • ensure recurring invoicing works
    • centralized store for client information and notes
    • ensure manual adjustments can be made as needed
    • possibly more/semi-automated input of payment info from bank/paypal
    • more?
  • nice to haves / optionals / considerations

    • online payment methods?
    • mapping services/invoices to deployed resources? (e.g… which server does a site end up on - useful for better outage information, but maybe more uses?)
    • importing bandwidth reports into system with fewer manual steps?
  • nongoals:

    • full automation
    • replacing all spreadsheets

… and a consideration of whether to include the membership management system in this too:

  • possible move to a CRM system in the future, possibly try and combine that with the invoicing system if so

In the previous email chain @chris said:

We might also want to consider adding the other tools to this list
– Adam uses Mailman for client financial correspondence and I use RT
for technical correspondence and GitLab for issues and time tracking for
a small number of clients.


#2

Regarding the source of truth idea, one complication is there is a split between tech workers and non-tech workers about preferred/acceptable methods of data entry. Maybe a reasonable assumption could be:

  • account / client / contact / billing type information should be in a tool with a nice/usable web UI
  • infrastructure information associated with that account could be more like yaml-in-git-repo type storage, which could be exported elsewhere as readonly content if needed by non-tech workers

#3

One added issue to consider is that on or before April 2019 we expect we will have to register for VAT and Making Tax Digital for VAT will come into effect from April 2019 — I’d suggest that we might need to start by looking for a Free software package which has or could potentially have, a plugin for this…


#4

I have started a thread on the InvoicePlane Discourse forum:

And opened an issue for Invoice Ninja:

What other Free software applications are there we can consider?

I suspect that we might find that there are none that are currently able to interface with the UK Government API and we might therefore be in a situation where we need to evaluate which project we should put some time and energy into to add this capability to?


#5

Other applications we could evaluate:

OpenSourceBilling

Looks like it might be too simple…


#6

There is also killbill:

… didn’t look into features so much


#7

Cheers I hadn’t come across Kill Bill before, I have asked them the same question:


#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 http://docs.killbill.io/0.20/invoice_plugin.html

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.

https://killbill.io/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.).

https://docs.killbill.io/0.20/getting_started.html

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!


#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: