courtly
courtly
courtly
courtly

Upcoming Events

San Francisco CiviCRM Meetup - February 8th, 2012
February 8th, 2012
Come meet others from the Bay Area who are interested in, using or developing (more...)

UK usergroup - London meetup
February 8th, 2012
Come and meet others from the UK that are using CiviCRM or are interested in (more...)

London user and administrator training
February 23rd, 2012
A comprehensive two day hands on training course covering the configuration, (more...)

CiviCRM London sprint Feb 2012
February 27th, 2012
Following the CiviCRM training here in London, we will have a CiviCRM code (more...)

UK South West - CiviCRM Meetup
March 20th, 2012
Come meet others from the Area who are interested in, using or developing for (more...)

[Bristol, UK] user and administrator training
March 21st, 2012
A comprehensive hands on training course covering the configuration, (more...)

San Francisco user and administrator training
March 29th, 2012
A comprehensive two day hands on training course covering the configuration, (more...)

CiviCRM Usability, Test and Code Sprint - San Francisco (March 2012)
March 29th, 2012
This usability, code and test sprint is targeted at CiviCRM users and (more...)

CiviCon 2012 San Francisco Bay Area - April 2nd 2012
April 2nd, 2012
CiviCon is THE annual event bringing together the people who use, develop, (more...)

CiviCRM Documentation, Test and Code Sprint - after CiviCon San Francisco (April 2012)
April 4th, 2012
This sprint is targeted at CiviCRM users and developers who want to work on (more...)

CiviCRM Components

Tools for engaging your supporters...

CiviContribute


CiviEvent


CiviMail


CiviMember


CiviReport


CiviCRM and Sage

Not Just a Contact Database

These optional components give you more power to connect and engage your supporters.

  • civiCASE

  • Case management for clients and constituents.

  • civiEVENT

  • Online event registration and participant tracking.

  • civiMEMBER

  • Online signup and membership management.

  • civiMAIL

  • Personalized email blasts and newsletters.

  • civiREPORT

  • Report generation and template management.

January 29, 2009 - 12:43 — chrisivens

I'm hoping by posting this I can get a feel for how useful a Sage plugin and associated module for CiviCRM would be. We have a client that needs to have transactions from the various portions of CiviCRM that tend money to be recorded in their accounting package. I personally think it would be a great addition and being a client requirement, it has been factored into the costs.

There are several considerations as to how to approach this, I have thought of a good few ways of achieving the goal but I’d like if I may to ask for a little help fleshing out the details.

The main things I’ve been thinking of are:

  • Method
  • Synchronisation
  • Security
  • Direction
Method
I think that to get the structure of the data across neatly, XML may be the best option. With a reasonably well thought out structure all financials and arbitrary custom data can be successfully translated to something sage can work with.
Synchronisation
My main issue here is numbering the transactions. I think my best option here is to have a numbering system purely for CiviCRM transactions and reference them within Sage as opposed to trying to use Sage’s invoice numbers. There is so much scope for duplication of the numbers and getting out of sync that the best option is to keep them separate.

Also in synchronisation, we need to decide how data is passed around. The most logical solution here is for Sage to fetch the data. With Sage being a client-server app that means that a client will need to have a bespoke plugin installed. Once data has been retrieved, it needs to tell CiviCRM that it no longer needs the data that was prepared for it. Once again there are many ways of making sure that Sage only gets told about new transactions but which one is best? If CiviCRM provides an XML file i would mean that several Sage clients could have the plugin but if a Sage client were to ask for all transactions after a certain number we risk duplication of data.

Security
Obviously a concern when dealing with financial data. Although I see no need to pass card details around, the privacy of a user’s data is of great importance. If we are generating an xml file then it can easily be encrypted and hidden behind a secure area of a site for fetching by Sage.
Direction
That is, one-way or two-way data transfer. Do we really need to take data from Sage and add it to the CiviCRM system. I say no but I have a hunch that the client is saying yes. I can see a way of doing it but right now, I think I need to focus on getting the data out of CiviCRM and into Sage.

So, that’s the dilemma. Or rather, that’s basically part of my project for the next few days/weeks. I’ve added a huge number of other features for the client so far by using the api and occasionally overriding the core files with some custom ones so I should really let you know about those but for now, if there’s any comments or suggestions, please get typing.

Chris

( categories: )

Comments

Wondering the same thing...

I am also wondering how this went.

I just had a client sign up for Sage Pay for their virtual terminal. Now they want to connect CiviCRM to it, but I haven't found anything on it yet.

Hi Chris, Did you make any

Hi Chris,

Did you make any progress on this? I'd really like to discuss your experiences as we are heading down this route ourselves currently.

Sage connection is a good idea

As I mistakenly posted this comment to a different article... here's where it should be. I agree working on a Sage connection with CiviCRM is a good idea. We're currently planning to build a connection of some kind with Sage CRM and Sage Accpac software with CiviCRM and Drupal. Perhaps if many of us are working on this, we can compare notes in the future.

Good idea

Over the next couple of days I'll be fleshing out my strategy and will probably report back here.

A few more thoughts ..

1. Method: Use REST and XML

2. Direction: Since Sage is an accounting system, one way is more appropriate for now.

3. Security: https and api keys. Since all Sage requests come from one machine, you can add code to lock down by IP address. However you are transferrng credit card information (since we dont keep it). More like name/date/amount etc

4. I dont know the Sage API. However the code should be strong enough to handle the same data being returned. Contributions have a few unique identifiers that can/should be used (id, trxn_id, invoice_id). These can be used in conjunction with the contact_id

lobo

Use CiviCRM? Like CiviCRM? Then show your appreciation and donate to CiviCRM

general

Looks like an interesting idea. If you want to make it usefull for many, go for a simple and general interface.

Data exchange structure: Xml sounds reasonable.
Use, as far as possible, database field names as tags or attributes in xml . Conversion to the need of sage should be done outside of civicrm. If not possible just add a mapping function that can be modified for each user. In the same line make it one-way only (civicrm-sage).

As API provide a function that serves a html page with the requested data. Use POST parameters to specify the data displayed, use ACL to provide access restriction.

Security should be handled using https. Use standard authentication of civicrm.$

Happy coding!

Do the REST

Hi,

We have been working on a REST interface that can produce XML or JSON. It allows an external program to query (with the proper credential) the civicrm server and extract.

You can either fetch the various transactions (events, donation, membership...) separately and do the filtering grouping on the sarge bit, or develop your own php method to be called as a single call.

There is an api forum, with more details on it, and the wiki is mostly complete on that topic.

X+