CiviCRM Community Forums (archive)

Yeah, I was originally or the opinion that contributions were payments but after reading responses to previous discussions I changed my mind. The main reason is that payments should never be pending. They are either paid or they don't exist. Even a bounced cheque is a completed payment following shortly thereafter by a completed negative payment.

In essence memberships, events & pledge are all frameworks to describe the payment one commits to make (and the business rules around them). Contributions are the commitments themselves (I would have two types:

1)  recurring - contributions are created in CiviCRM once the business rules (e.g. recurring contribution, pledge, membership say they should be paid
2) single - so a big pledge of say $2000 to be paid as and when might show up as one contribution but have many payments over time accrue. I presume the pledge module would describe how that would be followed up.)

There is already a table where some payments are stored: civicrm_financial_trxn and it already has  a potentially many to one relationship with a contribution.

I guess what I feel should happen is that the contribution record would record what people intend to pay and the aggregate of the financial_trxns is what they have actually paid. Once the aggregate matches the intention the contribution would be confirmed. An admin user would also be able to confirm a contribution that is not fully paid and at that point would have the option of changing the contribution amount to match the amount actually paid.

For me agreeing where contributions fit in the financials is a crucial first step to developing any data model.


http://wiki.civicrm.org/confluence/display/CRM/Finance+and+Accounting
http://civicrm.org/taxonomy/term/25

Just tying the link in circles:
discussion related to this thread is also here
http://civicrm.org/node/619