Pubblicato
2009-08-10 01:41
I wasn't really sure when I wrote my first blog on accounts and CiviCRM whether it was a topic that would draw much interest but in fact I got a lot of really thoughtful comments and something of a blogathon took place. I have some ambition to write another piece summing up what I think has come out of the discussion - but in the meantime I want to pick up now on something Dave & I have talked about a little bit on the forums: invoice numbers.
To quickly recap on previous conversations - CiviCRM does not have a clear concept of an invoice. From an accounts point of view it would be great to see this considered in some future version but must be noted that it is not trivial.
In the meantime, many CiviCRM users need to meet legal invoicing requirements when people sign up for memberships or events online. In New Zealand, to my knowledge, the legal requirements for an invoice are:
1) The words 'Tax Invoice' must appear on it
2) The GST number (if registered) must appear on it
3) A unique invoice number must be present.
4) There needs to be a full address
Of this list most are simple text entries that can be entered through the CiviCRM front end or edited into the tpl file - (e.g. for event e-mails templates/CRM/Event/Form/Registration/ReceiptMessage.tpl)
The tricky item off the list, however, is the invoice number. The approach I have been using for the invoice number is to use a combination of the contactID and the participantID.
ie.
Tax Invoice : {contactID}-{participantID}
would appear on the e-mail as
Tax Invoice : 102-111
The participant ID is unique in itself but I like to use both. If I see a deposit in our bank account with the invoice number as a reference I can quickly find the contact by substituting their ID into the url - e.g. replace the 102 with the appropriate number.
http://sandbox.civicrm.org/civicrm/contact/view?reset=1&cid=102
As of release 3.0 the contactID, participantID and contributionID are assigned to Event Registration and Contribution receipt templates. In earlier releases the code needs to be edited to add them.
So, this is one approach - and one that has been working well for us.
I'd like to invite feedback on what requirements other people have for invoices and how they meet them. I'm interested to see if there is enough consensus that something could be in place 'out-of-the-box' so to speak. Organisations with resources will always customise these things but I am always very conscious that many CiviCRM users are small organisations without much in the way of technical resources.
Filed under
Comments
An alternative we are currently using is the Contribution ID for the "invoice number". Of course this means that one payment may result in multiple "invoices".
These are generated as PDFs using the API.
I agree that this is an important issue and would envisage that the invoice number could in future be stored as an invoice_id in a table that links multiple contributions to one invoice.
[EDIT: This was originally posted August 10, however I have edited the above last para as previously it was confusing invoices and receipts - which I have elsewhere sought to ensure are considered independently! ie a receipt corresponds to a payment, and a payment could correspond to one or more invoices/contributions
How important is it to people that there be an ability to have more than one contribution on an invoice at this stage? Is it more important to first be able to pay for more than one/or only part of one contribution with a single payment? I think the later but am keen for others thoughts]
In the UK (and accross the rest of the European Union + EEA, I assume, as we got it from some EU Directives) there are two lots of information required. There are the basic finance/tax requirements, which as far as I know aren't that different to the list above, but there are also requirements from regulation 9 of the E-Commerce Directive and (some partly overlapping) ones from the Distance Selling Directive. These don't apply to invoices as such, but do put information requirements on contracts concluded via websites and email (i.e. electronically and at a distance). These information requirements do not have to be satisfied on the invoice for the invoice to be valid as such, but if they aren't included (a link to them isn't always enough) in the thank-you email/invoice type response there is a risk that the recipient can dodge paying and and get a full refund (e.g. under the para 10 right of cancellation in the DSD), so they are relevant - if only so that links to them can be given.
The UK version of these are available online (ECD) and (DSD).
Implementation throughout the rest of Europe should be identical, in theory.
Information required is a fairly full list of contact information, full information about charging and refund processes, language of the contract, complaint options, how the contract is filed, any codes of conduct the seller complies with, how corrections can be made etc. The awareness of these rules in business is pretty sketchy, so a lot of companies don't comply with them but in theory they're there.
First off, how would the tax invoice support registering multiple participants? The invoice should be for the person paying, not necessarily the participant - right?
On a related topic, Most organizations already have an accounting method and an accountant. The accounting system is often considered the "master" operational database. I hope that an important part of the civi accounts vision is to integrate with (as opposed to replace) these systems. Often these systems are already set to do invoicing - in some cases they are not. I wonder as part of the vision, if supporting reconciliation and passing transactions shouldn't be at least as important as managing invoicing.
I'm not an expert in this area, but I know OFX, (QFX for quicken) and QIF (becoming obsolete) are popular with quickbooks. XLS / CSV can also be used, as long as the data is formatted properly for transactions.
Is this consistent with how you see civi invoices evolving?
In order to map well to accounting systems in the future, I suggest that the invoice be a unique (and separate) identifier. Each invoice can have one or more payments associated with it. If there is only one payment per invoice (e.g. when making a contribution or signing up for an event), the contributionID could be used, however this may cause problems if there are ever any other table structures that contain IDs which might clash numerically (for example a table containing separate goods payments, or other shopping cart transactions etc.)
Suggestion for base requirements:
1) there is exactly one invoice ID for an amount owed by the user.
2) Each invoice consists of one or more line items generated from various origins (yearly subscriptions, events, donations, goods)
3) Each invoice can have multiple payments applied to it until it has been fully paid.
4) Each payment can be of a different type (credit card, paypal, check.)
This is all fairly involved, but as long as we start with the basics (one invoice = one payment = one item) it should be fairly straightforward to implement and extend as long as we make sure we generate IDs properly from the get go.
While {userID} - {participantID} is a great way to reference the payment when contacting the user, I would suggest using a separate field for this. Many invoices have a reference field (sometimes named "purchase order no." , "reference" or "ref ID") so it would map well onto accounting systems once those are integrated.
In some ways the idea of an invoice number is similar to an "Order Number" used by most web shopping carts. It is unique per order, and it is straight-forward to look up old orders and see what is owed, overdue, pending, etc.