Veröffentlicht
2009-10-05 17:06
The Physician Health Program of BC has a task that goes something like this: Their vendors, and even staff and board members, are not paid directly by them but by the provincial medical association (BCMA), so when invoices from vendors come in, they need to enter the information onto a special form and send that off to the BCMA for payment. Then they periodically send back a statement to reconcile against. Since all the vendors are contacts in CiviCRM already, it made sense to think about putting this in there too.
The customization for entering the invoices and generating the printable forms is currently in first-attempt mode and might still need some tweaking. You can find it in the unfortunately named php repository (php = physician health program). The reconciliation part isn't done yet so I'll just describe the first part. Well, I guess "not done yet" is a form of description. That's one of those blow-your-mind things: It's not possible to have something that can't be described even if it doesn't exist. Oooh.
I decided to go with a custom activity, largely because the users are very familiar with activities, and also the bulk of my experience so far with the civicrm code is with cases and activities, and like with everything there is a budget to think about. So the first step was to create a custom activity type called Invoice.
Then the next step was figuring out what to do about the custom fields. I needed fields for the line entries, and I needed more than one line entry per invoice. I wanted to mimic an invoice where the line entries contain a code, a description, a price, tax, and a total, and then have 5-10 rows of those. Doing this as custom fields is awkward because of the way they line up just vertically one after each other. A completely custom activity form has the drawback that you need to keep it in sync with the core form.
For CiviCase, the Civi team had put in a feature to allow inserting a template and associated php code into the core form by using a file naming convention. This is for example how the Change Case Start Date activity works - some extra fields get inserted into the form, and the php code updates the case record on save. The core code was general enough to be used for non-case activities so placing files in [custom_php]/CRM/Activity/Form/Activity/Invoice.php and [custom_templates]/CRM/Activity/Form/Activity/Invoice.tpl gets a proper looking invoice line entry table inserted. The ajaxy nature of the standalone activity form isn't aware of these, so you can't create these activities without doing it from a contact's record, but I decided to leave that for now.
Then I just needed some regular custom fields for per invoice data like invoice #. One of these custom fields is submission date, and it's used by the associated CiviReport to select which invoices haven't been submitted, and then that gets filled in when you run the CiviReport to generate the forms. The interesting thing about the CiviReport is that it uses the OpenDocument xml format to function like a form letter generator. They're designed for MS Word 2007, but I'm told they open in OpenOffice too.
Filed under