Hi Brush; Before I begin, I would like to invite you to join the -devel list as well, as some of the more implementation-centric portions of this discussion would be better handled there.
On 10/11/07, brush <[EMAIL PROTECTED]> wrote: > allies! > > it's wonderful to discover ledger-smb and this thriving community. i'm > tech and financial coordinator for TLC Farm, a "small to medium" > non-profit (NPO) with $100-200k annual budget. since our founding, > we've been committed to using open source technologies and approaches > regarding both software and information, content creation, etc. Welcome aboard! It also looks like open source is a good fit for the sort of community you are trying to develop with TLC Farm (judging by your web site). > sql-ledger was the only OSS accounting package available to us at the > time; we've been running a mildly (and badly) hacked version 2.4.11 since > then. CRM and donor relationship management has also been important to > us, and we've been growing with the CiviCRM project on top of drupal. > Understood. There has been some talk about CiviCRM integration. Most of this will probably need to wait for LedgerSMB 1.3 however. > i'd love to upgrade to ledger-smb, and am curious about various aspects > that would make our lives a lot easier. > > A: > first, and perhaps most importantly: the transaction categorization > capacity of SL 2.4.11 is not adequate to the needs of a nonprofit; this > has been mentioned in the thread on ledger-npo from last year. One of the most important thing to do is to understand exactly what is needed. This list (-users) is the best place to discuss functional (non-technical) requirements. Perhaps you can provide more information as to what you need exactly. > most organizations use a nested hierarchy within the chart of accounts > to achieve adequate reporting and distinction between different kinds of > transactions. so, for example: > > account 8110-022-123-ED07 might refer: > > 1) to the type of entry (8110 - supplies) > 2) to the program or department from whose budget it came (02x = > education; 022 = sustainability workshop series) > 3) to the grant or restricted asset to bill (123 - the 2007 whole > earth foundation "climate conditions" grant) > 4) to a budgeted project which may span multiple programs/grants (ED07 > - the Earth Day 2007 set of outreach, fundraising, educational, and > demonstration activities) Hierarchical accounts are somewhat of a problem on the current codebase. The best time and place to address this is as we start to move towards 1.4. If you are reasonably technical, please join us on the -devel list and help us work out how to make this happen. > one wants to be able to report dynamically over the various categories > of transaction. in the above example, one would want to be able to > search for "all education [ie. 02x] transactions" OR "-023- transactions > only" as well. in fact, one would like to produce reports in which > summaries by level of details can be chosen. > > ideally, one could accommodate the nested COA model since that is what > many org's already use. however, one could also use other fields; we've > tried to do this by using "department" for program and "project" for > project; the restricted funds bit is left out, and a major headache. I am guessing that a nested COA hierarchy system would make life easier for a lot of people. I have a few ideas. > > moreover, there is a major difficulty in using the "department" > field: each transactions, involving multiple entries, can only be > attached to a single department. however, frequently we have expenses > which are split over multiple departments (ie. telephone, split evenly > between fundraising, programs, and management). it is bulky and > confusing to create multiple transactions for a single bill. ideally, > the "department" (and other, hierarchically reportable fields) would be > able to be set per entry, like the project is. One of our major areas of effort is in separating workflow from accounting logic. When you enter a telephone bill, if you need to track by department, this is going to mean a separate line item for each. However, as we move forward, we want to make this a lot easier to automate. > > it seems this may be possible in ledgersmb 1.2.x; is that true? what > difficulties may remain? Basically, in these areas, we are not yet substantially different from SQL-Ledger 2.6. These areas are going to be re-engineered in 1.4, but the time to discuss how to make it work is now. > > B: for a variety of reasons, i think it makes sense for CRM modules to > be independent of accounting. however, they will ideally coordinate > information with a minimum of re-entered data or data mismatch. CiviCRM > is probably always going to reside on a different server than ledgersmb, > but we'd like transactions (probably entered first in CiviCRM) to be > smoothly uploaded into ledgerSMB. any work on this? thoughts? links > to other examples of automated batch processing? CiviCRM is also written in PHP which means we can't call eachother's functions directly. There are other ways of doing this, and there has been some discussion on the CiviCRM lists on such integration. Unfortunately the greatest obstacle at the momnt is that the relevant portions of both programs changing drastically between the current released branch and the next one. > > [UPDATE] i just noticed that some folk at least on the CiviCRM side are > investigating the possibilities: see http://civicrm.org/node/239 . any > thoughts on how we can support this happening? Bradley Kuhn of the SFLC seems to be pushing this. I am on the CiviCRM list in order to help provide some high-level guidance on making this happen easily. > > C: similarly, we'd like to be able to sync our PayPal transactions with > LedgerSMB (for now, just on a monthly basis). we'd need some > dupe-checking probably on transaction code, since CiviCRM entries may > already include paypal payments. any work on this? > Not at the moment. We would accept contributions if you want to work on it. This would seem to be a low priority at least for me and maybe for other community developers. However, you are welcome to take any of the paths available: 1) File a eature request. I can't imagine that this will be a huge priority for me, but you never know-- someone may see your feature request and decide they need ot too, and make a contribution. Regardless of other steps, this is a good place to start (sourceforge feature request tracker). 2) You can write the code yourself and contribute it. If you do this, it is a good idea to communicate a fair bit on the -devel list both before you write the code and while we are evaluating it. We will work with you to get your features added, but you can plan on having your first few submissions sent back for modifications. 3) You can hire someone (inside or outside the community) to do the development and have them coordinate with us via the -devel list. 4) For areas which are pending re-design, you can and should get involved in all discussions you feel comfortable with on both the -users (for usability/functionality/workflow issues) and -devel (for technical and implementation discussions). Hope this helps, Chris Travers ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Ledger-smb-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
