CiviCRM Community Forums (archive)

JMA will create a draft of the proposed new API and review with Eileen. We will also create a sample way to properly create all the needed entries in financial table for  the base case and review with Eileen (we will likely add a new optional param to indicate the API should do the extra table entries beyond contribution and line item).

We will try to confirm that the API call Karin cites:
$contributionResult = civicrm_api('contribution','create', $contribution);
creates unbalanced financial transactions, and why, and address that as appropriate. Since non-api transactions are working, and the API testing is less extensive here than the browser UI, it may turn out to be something in the way the API calls the BAO, or perhaps in the BAO itself. We'll see. Certainly we will not try to paper over issues in the BAO with fiddles at the API level.

Just to confirm, Eileen: we want for this round to support an api call to create a contribution that also includes a chained call to create one or more line_items. The result will be creating those records as well as associated records in financial_trxn, financial_item, and civicrm_entity_financial_trxn tables. We will not create membership or participant records, or entries in the member_payment or participant_payment tables, even if the line_items are for memberships or participant registrations.

Specifically regarding the repeat recurring transactions

 - I have added a PR that adds and tests a contribution.repeattransaction api

https://issues.civicrm.org/jira/browse/CRM-15996

This calls the existing (& now VERY commented) BaseIPN::completeTransaction function and identifies and fixes a bug in that function relating to creating line items for follow up transactions.

The patch is for master but I will also patch the LTS.

Regarding the 'complex api'

In the process of doing the above I realised the problems were in some ways converge on the ones I've been hitting in trying to make the contribution form layer simpler and trying to make the form layer support back office contributions for offsite processors.

If we look at the form layer we find that there are 2-3 flows
1) the flow for immediate payment
2) the flow for confirmed-later payment (ie. offsite processor).
3) the flow for paylater (somewhat the same as #2 & somewhat different - as some of you know I believe pay later should be implemented as a 'manual' processor).

The front end forms work VERY hard to create a fully confirmed payment for immediate payment, only after success, and to create a pending payment for pay later or confirmed-later.

What I propose is one flow
step one civicrm_api('contribution', 'preparetransaction' array(...));
step two civicrm_api('contribution', 'completetransaction', array(...));

The second of these already exists & has defined parameters so lets talk about the first :-)

I'm suggesting that we ALWAYS create a pending transaction with all related entities once we know about the intent. Once we know the outcome we call a second api call to update it to the outcome. No need for separate flows (at least at the form level) for different types of payment. Less form level logic.

The preparetransaction api is similar to the proposal for a 'thick' api - but since we already have some transaction-named api I'm using this name - which also allows us to build it in a new space without dealing with the existing one.

We would probably look at adding failtransaction too - We have agreement in principle from DGG to stop removing failed transactions and keep them in the DB as failed transactions.

In terms of parameters for preparetransaction I would start by looking at what the contribution forms receive as parameters & see how many of those we could pass on unwrangled.