CiviCRM Community Forums (archive)

We seem to frequently deal with Branch Memberships and hit the recurring problem of how to link the membership to the associated Branch. The membership type has a field 'Membership Organisation' which I think was intended for this situation. However, it is not useful because the Membership Type is over-loaded with the need to have membership types of differing durations and differing relationships.

So, an organisation with 20 branches could find itself needing 100 memberships types. This could be good in that you could give out different financial types BUT entering front end and backoffice memberships with 100+ membership types is not currently a workable proposition. Creating the 100 membership types (or more!) is also a drag.

So, we are looking for another way of linking memberships to a specific Contact (Organization->Branch). This  is required for breaking down membership payments (for accounting reasons), for permissioning, & ideally for viewing members of the branch when you go to the branches contact record.

We have been using a custom contact reference field on membership and I recently had a go at making the branch visible on the individual member tab and the list of members visible on the Branch members tab. This improved the appearance but I couldn't make it work without tpl & php edits due to the way that tab is made available to developer hooks

I have also seen people (including us) asking for the ability to have a relationship linked with a membership and have it end when the membership ends. This potentially gives a shortcut to permissioning (ie. if there is now functionality in core whereby the person with dashboard permission over the branch then would have dashboard permission over the contact) and makes the connection visible on both contacts. This also suggests a way to represent the situation where the member changes branches - the membership persists but the relationship ends & a new one is started.

A final thought is about how payments for which a portion goes to the branch is represented in an accounting-type way. Ideally we would do this through a price set but we need more branches than could reasonably be presented with a select. We need an autocomplete. Presumably if the branch is known a hook can edit the price set.

What happens however, if the branch is not known by the person registering & entered later by a back-office person assigning them?

My preference is for some of this functionality to go in core and writing this I feel the ability to have relationships associated with memberships might be worth pushing that way. I would expect

1) Membership type could be configured to have a relationship field on it
2) The relationship field would have configurable limits as current contact reference fields do
3) Outside this requirement but in the future I would expect we would want the possibility to configure how many so that in fact one or more relationships would be possible.
4) when the membership becomes current / is approved the relationship would start
5) when the relationship expires the relationship would end
6) if the field that stores the relationship is altered to a different contact one relationship would end and another would start

None of which makes me any clearer how we would manage to assign a portion of the relationship fee to HO & a portion to the branch - esp if we didn't know the branch until later

Hi Joe

Thanks for the email bringing this topic to my attention.

We also use Rules for Membership in the OMMS app.

This is based on XML rules rather than trying to provide a UI to construct them.

Essentially when someone registers they or a back office person selects from a list of Branches and their is a "Member of" relationship created to that branch which is completely independent from the Membership record.  Initially we used to have the relationship inherit the end date of the membership, and then extend it when the membership was renewed, but we have now moved to having no end date on the relationship and having a cron that ends the "Member of" relationship/s of a person if their Membership has expired.

So in Eileen's use case you could just have a drop down list of all organisations that have a "Branch of" relationship of the "Owner organisation" and let people choose their branch, or if there are strict rules that apply to which branches they are allowed to be in and you don't have the budget to build those rules into the UI, you don't expose the Branches to the end user and just have the back end users allocate them to the appropriate Branch by creating a "Member of" relationship (or "Pending Member of" relationship if the Branch has to approve it).

You could then have a "hook" that upon setting a person's "Member of" relationship it looks up the person's Membership Fee and records a transfer of a percentage of that from the "Owner organisation's membership income and/or asset accounts" to the "Branch organisation's membership income and/or asset account".

It is a big job and the edge cases / reversals are the killers.  That's partly why we ended up building the OMMS app to talk to CiviCRM and orchestrate these things rather than try to get it into CiviCRM core (where it will likely overcomplicate things for the majority of users).  Back then it would have required a six figure MIH - the new finance system may bring it under that now... perhaps!

Often this detailed rules logic is the sort of thing that belongs in a client's App that uses the CiviCRM API, rather than putting it into CiviCRM core code (which should focus on providing strong reliable services for client apps to use - including the included default "CiviCRM UI app") or overrides that break when CiviCRM upgrades.  Absent that separation of concerns, there is a strong risk people will start using things like Salesforce as the "CRM service" for their Apps.

Hope the above helps.

Eileen - happy to do a Skype call to discuss.

OK - so your point about doing the financial transfers when the branch is defined makes sense & removes this aspect from the more common & standard issue of having a connection between the organisation/branch that a contact is signing up to and the contact signing up. ie. finding a way to make the described purpose of the 'membership_organization' field work for organisations with more than 4-5 branches.

I think changing core to the model you're suggesting is a significantly big project AND I'm still concerned about overcomplicating things for 80-90% of users for whom the current model fits.

If the main issues are UI to manage ~100 membership types + the upsell problem, maybe it makes more sense to leave the underlying data model in place and look at ways to attack those 2 issues.