Question

Photo of Jason Jones

0

Event Registration Payments

4

Event Registrations with Cash/Check payments are managed by two different teams at our church.

1) Finance Team - This team processes all payments, scans them, applys them to people, deposits the money.

2) Ministries Team - This team manages all event registrations... How much money do you owe? how many payments have you made? etc


With FellowshipOne there were a number of reasons why would could not manage our registrations in the database.  So our Ministries team managed event registrations in an excel document. They tracked payments and many other things.


With our recent migration to Rock, we now realize that almost everything can be managed in Rock and there is no reason for an excel sheet any longer.


However - We came across an opportunity that we do not know how to solve on our own. :)


Person gives us $50 Cash and their paper registration form. (event may cost $400). Traditionally, the finance team would scan the $50, apply it to their profile in Rock/F1, send ministry a copy of the deposits for the week along with the paper registration form.  Ministry would register the individual and apply the $50 payment in an excel sheet.  Then when a parent/guest called... they could tell them exactly where they were in payments and ministry owned that process and connection with the family/guest.


However If we move to managing this process 100% in Rock, and Ministry went to apply the payment on the registration (so they could track everything in one place) as say, cash/Check... the $50 payment applies twice... 

1 - by the finance team on Monday when they scanned in the payment and applied it to their profile

2 - by the ministry team later in the week when they processed event registrations/payments


I think what I am asking for is in option to create a payment type that does not apply to ones rock account and ONLY lives within the event registration.


Based on what I can see, I think we only have 2 options right now (unless you have another idea)

1 - Finance Team does NOT apply event registration monies at all. They save it for the ministries team. 

-- PRO-- Ministries team can apply money as needed - WOOT WOOT

--CON-- Finance team looses their ability to capture a scanned image (I think)

--CON-- Finance and Ministry need to find a mutual time to process money from safe. (not terrible... but you know...)


2 - Finance Team does process payments as they have been with a scanned image, sends report to ministry... Ministry then applies a 'discount' to the individuals registration that would deduct the amount they have paid.

--PRO-- Finance receives its scanned image

--CON-- Ministry could not track each payment individually in the registration... the discount would just increasingly get larger.


Thoughts?


I LOVE the way 'fundraising matching' works... LOVE LOVE LOVE. maybe it would be possible to create a 'Registration Matching' in the future?


  • Photo of Daniel Hazelbaker

    0

    #1 is basically the way to go I think. The way we do it is the ministry team enters the cash/check/credit (if a pay by phone call come sin) on the registration. It is then their responsibility to print out a "deposit slip" that indicates how much money of each type (cash or check only) as well as the cash and checks in an envelope to the finance team to actually deposit. The finance teams handles *deposit* only - the data has already been entered in Rock.

    If the ministry team does not get the money to the finance team we fire them... or would if I had my way. :) In reality, they get a slap on the wrist and possibly a sit-down talk with the Executive Pastor on responsibility. It is their job to make sure the money flows correctly and if they don't want to perform their job as defined by the organizations rules, they don't need to work here. Obviously mistakes happen, and when they do you hope it's a $50 check and not a stack of multiple $400 camp payments.

    With this setup, the finance team still can capture a scanned image (though it wouldn't go in Rock, we don't care we already have the money recorded) and they get to control the actual deposit to the bank. But they are not in charge of updating the registration because they don't know the details of the registration. Each one is slightly different. They don't have answers for "The check is for $100 but they only owe $75 - what now?". The ministry people do.

    Hope this helps. The final answer is "there is no perfect solution, but this is the way we do it and it works for us. Just find what works for you and pisses off as few of your staff as possible" :)

  • Photo of Jason Jones

    0

    Thank you Daniel! - I agree with everything you mentioned.  Do you think this is something I should submit an idea for?

  • Photo of Kevin Rutledge

    0

    I have a third option, but it is sql and workflow based and I'm not entirely sure how to share easily.  

    On a registration Page where you looking at a person's registration.  I have a dynamic data block that shows all transactions recorded in Rock to the same account that the Registration Instance is linked to but that is not matched to a registration.  So this would be your payment scanned by the finance team.

    The person would click on the transaction from that list that belongs to that registration. This links to a workflow entry where the registration and payment info is sent as parameters to show a confirmation screen.  Once confirmed, sql is run that records the registration id to the payment which creates the link in finance and registrations of the payment to a registration.


    To make things easier for my team, i created a page that shows all the transactions for the two accounts we do this regularly for and all of the registrations for the two event registration instances that are linked to those accounts.  I can then look at the list of unmatched transactions, filter the registered people to find the right one and click on the name to go directly to the registration that needs the transaction listed.

  • Photo of Jason Jones

    0

    WHAT! @Kevin this is amazingly interesting!  I would love to process that