Recurring Contributions (DirectDebit) lose the line item data/records about com.iatspayments.civicrm HOT 16 CLOSED

Actually, I'm pretty sure this will be true of recurring credit card contributions using iATS. The code that creates the subsequent contributions doesn't do anything about line items, it just creates a vanilla contribution of the right amount and let's civicrm fill in the rest.

I'm not sure if there some internal magic that is doing this correctly for credit cards but not direct debit, but it seems unlikely.

Working on a fix now, but can you confirm that this is also a problem for credit cards?

Basically, I will model all subsequent contributions based on the original one, including the related line item records (as per this post: http://forum.civicrm.org/index.php/topic,29150.0.html)

from com.iatspayments.civicrm.

Allen - I ran into previous issues with recurring contributions with multiple line items on the Authorize.net side. With Authorize.net, I bypass the normal CiviCRM processing and have my own CRON job that deals with the Auth.net messages. I will post it on Git hub shortly

from com.iatspayments.civicrm.

It seems that CiviCRM isn't very sophisticated in supporting complex recurring contributions. The best I can do is as noted above - to model your recurring contribution on the earliest found contribution from the same series, which makes sense to me. I've just generated a new 1.2.12 release (not yet posted to the extension page) which should be clear from this commit:

e9c4d44

Also, i found a better way to do line items (see my comment on that forum post).

And, i've removed 4.2 as a supported version as of this release (and added 4.5). If you need 4.2 with this feature, I'll need you to test it for me (I've not evidence it won't work, but the line item complexity suggests it might not).

from com.iatspayments.civicrm.

I have been continuing to test "master" with regards to this issue. What I am now observing in production: The appropriate records are added to the "civicrm_line_item" table for each recurring contribution. HOWEVER, the related entries in other financial tables are missing. The result of the missing records: When exporting data to a general ledger (using the Accounting Batch area) or reviewing data on the "Bookkeeping Transaction Report, there are NO credit or debit data for the transaction. ( fields for "Credit Account Name, Credit Account Number, Debit Account Name, Debit Account Number are all BLANK)

If you look at the code in my extension at: https://github.com/sgladstone/com.pogstone.paymentprocessorhelper

You'll notice I do NOT use the buggy line item APIs. (I ran into these same bugs with Authorize.net and PayPalPro recurring contributions) Instead I insert data directly into the various financial tables. I think your best bet is to recycle my extension code, or we modify my extension to handle iATS recurring payments.

from com.iatspayments.civicrm.

Wow, I didn't know that the line_item option in the api was buggy, that sucks.

Any reason we can't just patch that? I'm not keen on direct manipulation of tables for the usual reasons.

from com.iatspayments.civicrm.

Whatever gets working code in my production environment faster. At this point, iATS extension is disabled due to this issue

from com.iatspayments.civicrm.

As you know the core APIs are not part of the iATS extension - we're just using them - and yes they need work/fixes/improvements [by core and maybe we can help - maybe you can help]. However if you disagree with that philosophy - you're welcome to fork and rewrite things the way you think they should be written.

from com.iatspayments.civicrm.

My main issue is that there is no method to test any of this as iATS rejects all transactions in the sandbox.

from com.iatspayments.civicrm.

Otherwise I agree with you

from com.iatspayments.civicrm.

Hi Sarah
We have just released new testing functionality for TEST88 and ACH. You can now run ACH tests on the TEST88 account and it will run in a similar way as live accounts.
You can create and ACH transaction and iATS will sweep it at the same time as live accounts (3pm PT) and change the status to Pending (ie sent to bank). In one hour we will then change the status to Approved or Rejected depending on the value you use. (This is the only difference as usually banks can take between 3-5 business days to respond in live accounts).
There is also an option for Refund testing.
Please refer to our testing page for further details: http://home.iatspayments.com/developers/test-credentials

from com.iatspayments.civicrm.

Fantastic!!!!!! I am so thrilled about the new testing tools!

from com.iatspayments.civicrm.

Sarah - it would be great if you could have a look at the buggy line item APIs in Core - open an issue for it on JIRA - see if you can get any traction to get those fixed? You understand these way better than we do. It would be awesome if you can help out with this bit.

from com.iatspayments.civicrm.

Karin - There already is an issue on JIRA. I will see if I can figure out the code to be able to submit a PR to the core. (Time permitting, as I am swamped at the moment)

from com.iatspayments.civicrm.

Thank you - appreciate it - please keep us posted here.

from com.iatspayments.civicrm.

I just had a further thought about this - you're looking at a fairly specific use of recurring contributions that might not apply to all cases. Specifically, part of the core function of recurring contributions is the ability to modify the amount - e.g. in the case where a regular donor wants to increase the amount they are contributing. At the moment, there's already an interface built into core that allows this to happen, and some associated methods of payment processors to deal with it.

So what happens if we're generating line items based on the original contribution but those don't equal the new total amount that a contribution has been increased to?

One solution might be to only reproduce the original contributions line items if the total amount hasn't changed, but this is all getting kind of fragile.

Any thoughts on this?

from com.iatspayments.civicrm.

I strongly encourage you to make your Payment Processor Helper extension an ad-hoc post-transaction extension. Let payment processor extensions do what they do - do not make any code edits - then run a post-recurring-bookkeeping extension that distributes the total amount over the applicable line items ad-hoc.

from com.iatspayments.civicrm.