Aller directement à la fin des métadonnées
Aller au début des métadonnées

In order to provide the functionality that is required under the CiviAccounts umbrella (part-payments, statements of account, invoices, provide scope for carts, & banking reconciliations) we essentially need to be able to map this structure against accounts in CiviCRM.

Note that the diagrams below are done using DIA - an open source diagram app and if you locate the paperclip top left you can access them in DIA format. If you are clever enough to turn on the hidden layer you will find a whole lot of existing civicrm tables on it for you to push around that aren't included below (e.g pledge, membership etc tables)

Initially each invoice is likely to only have one line item but potentially could have a contribution and a membership or in some future more user friendly friendly version it might hold a basket of events, donations and memberships for one or more contact.  Invoices can be positive or negative (ie intended refunds / credit notes) and will need to follow rules such as only permitting soft-deletes.

The payment table represents all payments made either way - and one payment might be matched against one or more credit notes.

There are existing tables in CiviCRM that currently map to the credit match table and the payments table (although only credit card transactions are currently being recorded in these)

There are 2 possible scenarios for reflecting the two left-most tables in CiviCRM:

1) The civicrm_contribution table effectively represents a line-item. In this scenario a new invoice table will need to be added (not necessary in phase 1) and all contribution items that are potentially subject to different accounting rules (primarily tax) / account codes (e.g. premiums vs donations vs memberships) will need to have separate contribution records. Price sets will also require more than one contribution record IF there is a desire to attach different account codes to different elements in the price set. The below diagram shows (using events only but the structures are similar for the other entities: membership, pledges, products - there is currently a civicrm_product table).
Scenario 2

civicrm_contribution table represents invoices.

In this scenario the existing civicrm_line_item table has a much extended functionality. All contributions would create one or more line items in this file whether they used a price set (currently the case) or 'simple' pricing mechanism (in which case a single row would be created with the details for that line item.

  • Aucun

Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.