Back office usage?

[sgladstone]

I have configured the IATS payment processor in my test environment using the agent code and password "TEST88" as specified in the readme. I can see how to connect it to a contribution page. However, when I try to use it in the back-office by clicking "Create New ... Contribution(Credit Card)" and then selecting my iATS ACH processor, the screen does not have all the needed entry fields. It does have billing name and billing address. But the screen is missing the fields for:
Account type
Name of Account Holder
Bank Account Number
Bank number + branch transit number
Bank Name

BTW: I am in the US. Will this test account work for US currency?

[adixon]

Thanks for this, I hadn't thought about testing separately for the backoffice use of ACH/EFT, even though that's the more sensible usage...

I think it's just a code bug - I had to modify the default ACH/EFT form, but I suspect it only applied to the front end version.

Re: US currency - in theory, yet.

[sgladstone]

Do you have an date estimate as to when you will fix this extension to work in the back-office too?

[adixon]

Definitely within the next month, 2 weeks is a good estimate.

[adixon]

So it appears that back-office direct debit is not supported by CiviCRM. I've posted the details here:

http://forum.civicrm.org/index.php/topic,32036.0.html

In any case, I'm going to renege on my estimate, it will likely take longer.

[sgladstone]

Alan - What sort of timeline to you predict? This is really critical.

[sgladstone]

Also you may want to look at the code for the project: https://drupal.org/project/vanco_payment This is a payment processor for Vanco which also offers ACH within CiviCRM

[adixon]

Okay, I think i see a strategy - basically replace the backend link to the front end link with the addition of a c=cid in the url. It won't be exactly like the existing backend form, but it will allow a logged in administrator to add contributions on behalf of an existing user.

[sgladstone]

This approach has many limitations - In the back-office area the bookkeeper can fill in many custom/internal data fields that are not directly available on a contribution page. Such as soft credits, custom data fields, choosing any financial type or priceset they prefer, etc.

[adixon]

Yes, true. The workflow would have to be that the initial contribution would be entered via a selected page (i suppose maybe a dedicated one that isn't normally advertised?), and then any customizations would be done separately by editing the contribution after it went through. I'm not convinced that this is a bad idea, actually, since it makes the backend customization more explicit. If you're doing a lot of backend contribution customizations, I think there's likely a better process.

[sgladstone]

I understand that its less time-consuming to ignore the issue of ACH not working in the back-office, but for a bookkeeper it would be VERY frustrating to be unable to not have this working. Esp. since the back-office works for the other payment processors.