Blogs

About 8 weeks ago we began looking into a CiviCRM / QuickBooks integration framework. Our goal is to write a module that allows CiviCRM contributions and contact information to be written to QuickBooks. Our target version is QuickBooks 2009 Premier Non-Profit edition, since that's what we use.

At the very least, the module should be able to:

A problem with using Civi for a members’ website based on Joomla is the need to be able to control access for different types of user – for example you might want ordinary members to be able to edit their own details but not see the details of other members for privacy reasons. But perhaps some groups of members might want to see each others details.

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.

- Here's a report back from Sacha Stanton

The New York Meetup was a great success last night, as 33 people got a glimpse into upcoming releases, several case studies, and great open floor discussions. Dave Greenberg, core contributor, joined in via Skype video to provide insight into upcoming features and answering questions.

This post started out as a reply to Eileen's "Banking Screen?" comment on my previous post on this topic, but by the time I was done, I thought that this warranted its own post. I think that the core "Accounts" or "Banking" functionality that could be helpful to Civi users without getting too out of control, is:

We are finding that CiviCRM/accounts issues are becoming increasingly important for our clients, and Eileen's recent blogs and the discussion they are generating are a fantastic step towards helping find the best way for Civi to deal with financial transactions.

For example, I think it could be useful for Civi to ultimately develop functionality for maintaining simple bank accounts within CiviCRM, so that small organisations can maintain basic accounts without the headaches of integration with an external package.

This is my second blog on the topic of integrating with CiviCRM with an accounting system. Those of you who haven't just run screaming from the room or suddenly discovered an urgent need to polish the inside of your car exhaust, re-organise your tupperware or push needles into your eyes ... read on.

One of the areas that occasionally hits the forums is whether CiviCRM integrates with accounting systems. I've been giving a little thought to accounts integration lately and have now spent a bit of time poking around the Xero API and thinking about what I would do if I were to spent time trying to get CiviCRM talking to Xero. The content of this blog is mostly non-technical so if you can safely ignore the stuff about APIs if it doesn't mean anything to you.

Some recent discussions and debates about Active Record and Data Mapper have popped up in the context of new architectural proposals for CiviCRM from Dharmatech and raSANTIAGO. We think it is important that the differences between each is known and to clarify what are some erroneous perceptions. This is not to claim that either design pattern is above criticism. It is to say, that there are some misperceptions that prevent a more intelligent discussion of the trade-offs between these two design patterns. Our hope is to bring some clarity to this discussion.

Current CiviCRM architecture pitfalls rasantiago has proposed a new CiviCRM architecture with details of the ORM layer. Torenware commented on the latter and mentioned some particular scalability issues.  Our own experience with the Active Record design pattern proposed by rasantiago is that it works well for small projects but doesn't scale well.  We believe that CiviCRM is now facing serious scaling problems in several areas, to wit: