Offline Recurring Payment Extension

[andyw]

Hi All,

We've published another extension - this one is basically a port of Rajesh's civicrm_offline_recurring_payment module - it's been updated slightly to create contributions via Scheduled Jobs, that kind of thing.

There's some documentation / a basic overview here.

It should appear on the Manage Extensions page if you have a compatible Civi version (currently supports 4.1 - 4.3) - or download it from here.

Any problems, let me know!

Andy

[xavier]

Hi,

where is the source code? github? Also, your documentation link goes to the home page of your company, do you have something more specific

Anyway, could you describe the logic of the cronjob? is this using the date of the next contrib to create a new one?

[andyw]

Also, your documentation link goes to the home page of your company, do you have something more specific

Yes, follow the link above where I've written "There's some documentation / a basic overview here"

Anyway, could you describe the logic of the cronjob? is this using the date of the next contrib to create a new one?

It is - just download it and read the code if you're interested.

Cheers!

Andy

[xavier]

Yes, follow the link above where I've written "There's some documentation / a basic overview here"

I was referring to the documentation link (taken from the info file most probably):
http://civicrm.org/extensions/v12
Could you fix the file to point to the blog post instead than your home page?

It is - just download it and read the code if you're interested.

I am wondering if part could be re-used for the sepa. Do you have a git repository or do we have to download the zip like in the good old days?

X+

Andy
[/quote]

[andyw]

I was referring to the documentation link (taken from the info file most probably)

I know what you were referring to thanks. I will fix it in due course.

do we have to download the zip like in the good old days

You definitely do, Xavier, yes - if you want me to spend my time helping you, probably sarcasm is not the best way to achieve that.

[xavier]

Hey sorry if it came through sarcastic it wasn't intended, was just surprised there isn't a git repository.

[andyw]

Yeah, sorry Xavier, we don't really use it, although I'd like to - I know it's supposed to be the trendiest SCM in the world and everything

So it would take a lot of time to sort it out right now. I've already spent a lot of time packaging up the extension, testing it, writing the documentation (and it took ages) so I can't really spend any more time sorting that out right now.

It's on my to do list though - I'll send you a link to it on Github when I've done it, but it might not be this week.

Hope that's ok!

Andy

[Fabian_SYSTOPIA]

Hi Andy,

first of all: Thanks a lot for all your work making the extension available for 4.3! I have tested it and so far it works like a charm.

I have a couple of questions though - maybe you or somebody else in the forums can help me out...

• Is there any way to find existing recurring payments via the UI? Of course one can find the actual contributions that are created by the extensions but it may be important for users to find and / or list the existing recurring payments that have been set up.
• Is it possible to change the default settings for the payments that are created by the extension? E.g. the values in the fields "Campaign", "Source" or "Paid by"?
• I would like to make a (very) humble contribution to the module by translating the strings in order to make it available to German-speaking Users. However I do not know exactly, how it works with extensions - can I find the strings in Transifex? And if not, what would be the best way to proceed?

Thanks again and greetings from Germany
Fabian

[xavier]

Hi,

You can find the recurring contributions from the contribution tab (listed at the bottom). on sepa dd, the contrib template has been modified to add a link to the recurring contrib. Probably something that makes sense no matter the type of recurring contrib

Check out with Mathieu, he has found the solution to get the translation working on extensions. The only constraint is that you need the "native gettext" mode, ie have your linux that speak german. It's not a constraint per se, just the right way of doing it.

[andyw]

Hi Fabian,

Thanks a lot for all your work making the extension available for 4.3! I have tested it and so far it works like a charm.

You're very welcome - I'm glad it's of use!

Is there any way to find existing recurring payments via the UI?

If you mean search for the Contribution Recur directly, I don't think there's a way to do that (but maybe someone can correct me if I'm wrong on that).

The extension will list all the Contribution Recurs for a particular user on the Contributions tab of their Contact record, and you can also search for all Contributions that were created from a Contribution Recur record - so you can probably find the information you want using a combination of those techniques - but there's no way to directly list all Contribution Recur records on the system as far as I know.

Is it possible to change the default settings for the payments that are created by the extension? E.g. the values in the fields "Campaign", "Source" or "Paid by"?

Not at present, but we could look at adding some sort of settings form to it in the future to do that. It seems reasonable to expect that people would want to change those defaults.

I would like to make a (very) humble contribution to the module by translating the strings in order to make it available to German-speaking Users. However I do not know exactly, how it works with extensions - can I find the strings in Transifex? And if not, what would be the best way to proceed?

That sounds great!

Unfortunately, it seems like the ability to translate extensions is something that's still lacking in Civi, but a guy called mathieu is making some progress on implementing that here:

http://forum.civicrm.org/index.php?topic=28426.0

I can drop him a line, find out how he's getting on with that - whether that's something we can use and maybe include his code with the extension for now to get your translation done.

We can get one of our developers to help you with that at some point, provide you with a list of translatable strings etc, if that's something you want to do.

Hope that helps!

Andy

[andyw]

Oops, sorry xavier - didn't see you'd already replied to some of that.

[Fabian_SYSTOPIA]

Thanks Andy and Xavier for the fast answers!

Searching for the Contribution Recurs directly would be very useful - especially because it would then probably be easy to create a report that lists them, thus making it possible to estimate your future income generated by recurring Contributions. Unfortunately I am no developer and cannot contribute to create this function - but maybe somebody more capable is also interested in having that function...

Not at present, but we could look at adding some sort of settings form to it in the future to do that. It seems reasonable to expect that people would want to change those defaults.

That would be great - until then one can always change it manually when one is editing the generated payments.

I will look into the methods suggested to translate the extensions and will let you know when I made any progress.

Cheers
Fabian

[adixon]

As I look at this code - it appears that it will generate contribution records for any and all recurring contribution table entries. Isn't that a bad idea - in case a site has a mix of say Paypal recurring contributions as well as off-line contributions? Don't you want that initial select to filter to only those entries that were put in using this system? I'm not sure what the best way to do that would be, other than to create some kind of dummy processor and filter on the corresponding payment_processor_id.

[andyw]

Hi there,

Yes, you're right - I hadn't noticed that before, but like you say, that's not going to play well with recurring contributions created through other means.

I'm not too keen on the idea of creating a dummy payment processor - that seems like a bit of a hack. We could create a table to join against which keeps track of which recurring payments are owned by the extension though ..

Not too crazy about that idea either really - but I will work out which is the lesser of those two evils and get that done - or maybe there's a better way I've not thought of yet.

Thanks for pointing that out though!

Andy

[andyw]

or maybe there's a better way I've not thought of yet.

It looks like processor_id (not payment_processor_id) might be the best way to go about it. From what I understand, that's an arbitrary varchar field we could potentially hijack, insert the extension key into that field when a record is created, then we know which ones are ours.