Evangelical Lutheran Church in Canada
Directory   Search  
 

Who was Rasmus?

This project is named after Rasmus Jensen, the first Lutheran pastor in North America.

Pastor Jensen was the chaplain of an expedition sent in the spring of 1619 by King Christian IV of Denmark and Norway to search for the Northwest Passage to India. The expedition landed on the shore of Hudson Bay at the present day site of Churchill Manitoba in the fall of 1619.

His commemoration date is February 20.

Home » Project Rasmus » Comments Summary Send to a friend     print

Project Rasmus

Congregation Membership Application - Comments Summary

This is a summary of the discussion of the congregational membership application by the bishops, the representatives of the synod offices, and the representatives of congregations who met in Winnipeg June 16-18. Comments in blue have been added by Tony Kwok, the IBM representative who has been working closely with the ELCIC to develop the requirements for the applications.

  1. Member data
  2. Donation data
  3. Tax receipt data
  4. Baptismal data
  5. Marriage data
  6. General Functionality

Member Data

  • Need additional salutation field to record salutation for household mailings
  • Need additional field to store allergy information. This would be useful information in any situation where the church might be providing food or planning excursions.
  • Marital status should include Divorced, Separated and Widowed in addition to the current Married and Single options
  • There is a desire to have address information entered by the congregations automatically updating the Contact List database
  • COMMENT - The way that we could implement this is outlined below
    • Contact list will be preloaded with names from all of the currently existing large mailing lists
    • A database will need to be created which contains all names and addresses of congregation members across the country.
    • Each entry will have a field for storing a unique identifier that will be used for matching up peoples' mailing addresses from the congregations with the appropriate home mailing address record in the nationwide congregation member list. This unique ID will have a value generated for all names originally imported into the contact list. Whenever a user of the contact list adds someone, the system will generate this unique ID. A similar field will need to be added to the member records in the congregation membership app but this one will never be generated.
    • The Synods would own the creation of unique Ids and the process of matching new congregation members with a HOME address document in the contact list application
    • Each congregation will initially get an empty replica copy of the nationwide congregation database which will have a replication formula that will only replicate records which have this congregation's number in the congregation number field.
    • An agent will periodically copy over all of the names/addresses from the congregation database to this national congregation list. The first time, all of the names will have an empty unique identifier field. Any new people that the congregations add over time will also have blank unique id fields.
    • Each Synod office will have access to a view that shows all congregation members within their synod that have a blank unique identifier field. These would be the names coming from the congregations as the congregations get started and as they add new users over time.
    • The Synod staff would then try to find a matching home address for this person in the contact list. If it is found, then they would copy over the unique id from the contact list into this person's record in the nation wide congregation member list. If a match cannot be found, then add this person to the contact list and copy over the newly generated unique ID into the person's record in the nation wide congregation membership list.
    • Once this unique ID is copied from the contact list into the correct record in the nation wide congregation membership list, agents can be written which will automatically migrate address updates done at the congregation level to the correct record in the contact list database.
    • An agent at each congregation would compare the records in the national congregation members list with the records in that congregation's member database. If the synods added a unique identifier, then this value is copied into the appropriate field on the congregation member record. This agent would then make a second pass through the congregation member database where it would copy over all of the member data, including any newly updated unique id fields into the nation wide congregation member list. The effect of this is that all new member data is brought up for Synods to assign the unique ID created by the contact list and all the unique IDs assigned by the synods goes back down to the congregation membership databases. During the next cycle, the address that comes back up will have the new unique identifier and the synod people would not see it as an ID that needs the unique ID assigned.
    • An agent running on the server in National office would periodically go through the list of nation wide congregation members and copy over the address fields for any records where the unique ID matches the unique ID of a home address record in the Contact list database. This would effectively move all address changes made at the congregational level into the contact list database for all records where unique Ids have been assigned.
    • The users of the contact list simply pick names and give them a descriptive textual attribute that they can use to retrieve the desired list. The process described above will automatically keep the address for the people in these lists updated as the information is changed at the congregations.
    • If the National Office and Synod users get name change notifications, they would email them to the appropriate congregation for the congregations to make the name change if they have not already done so.
    • The congregations own the address information for all address information used for NO and Synod mailings.
    • Each member should have two address fields for their primary and their secondary address.
    • Immediately below the addresses, have some fields to define the start date (within a year) and the end date (within a year) when the secondary address should be used. This ability would let the congregation easily manage snowbirds and other people who have a different address at different times of the year.
    • Which ever address is the current MAILTO address will be sent up to the Contact List database to maximize the chances of ELCIC mailings going to the correct address
    • In extreme cases where a member does not want their address made available to anyone, the church address can be used as their mailing address and their real address can be in the secondary address so that the church can forward mailings.

Donation Data

  • A field needs to be added to track if a donation is taxable or non taxable
  • A field needs to be added to track the form of payment (Cash/Cheque/AutoDeposit)
  • A field needs to be added to identify a donation as a gift in kind. This is a non-cash gift (e.g. appliances, vehicles, real estate, etc.) where an estimated dollar value is calculated and recorded. This dollar value should be added to tax receipts, but it should not be displayed as part of the deposit slip.
    COMMENT - Whichever views get used as deposit slips can be set up to give a total for the donation period and break out the amounts that are gifts in kind so that it is easy to determine the dollar amount to deposit
  • There should be a way to view the total amount of money for the donation period plus how much money was entered under each envelope in the donation period. This lets the user do a quick audit to determine if they made any mistakes in recording data for each envelope and in counting the cash/cheques
  • Once the user is satisfied with the data entered into the donation forms, they should be able to post all of the donations that they deem as being entered correctly. Posting prevents the donation document from being edited. Corrections must be processed as another (possibly negative amount) donation document.
  • Data entry person should be able to enter donations by envelope number and it is OK for them to see who the envelope belongs to. However, they should not be able to see how much a person has donated over time. Perhaps this could be a setup option to allow/disallow viewing rights for the generic assistant ID
  • If a donation is of type MEMORIALS, display a comment box to record the details of the gift
    COMMENT - each donation document already has a comment field. Is there really a need to display a second comment field here? This is easily programmed, but seems like a waste of storage space as each field (even if blank) takes up some space.
  • Provide a way to capture donations made via pre-authorized payment
    • COMMENT - Some organization needs to be found (United Church apparently will provide this as a service) that will provide this as a service for congregations. The congregations would give a list of names with account numbers, monthly donation amount and cancelled cheques to this service provider. Each month the congregation would receive a report of monthly donations that were made electronically and they would compare this with the donation documents generated by the system.
    • COMMENT - Each member record could have a flag to identify that person as a direct payment user and fields could be added to capture all of the details required. A monthly agent could run against the membership list and auto create the appropriate donation documents without any human data entry required.
  • When starting a donation entry session, set default values that will be used when entering donations. These defaults should include YEAR, DATE, WEEKNUMBER, TAXABLEFLAG, PAYMENTTYPE
  • Donation data entry is one of the most tedious and time consuming tasks in a congregation, so it should be easy to quickly enter donations and the screens should be visual enough to allow volunteers to quickly figure them out and use them.
  • It would be nice if data entry can be entirely keyboard based, preferably with all of the data entry done using just the numeric keypad
  • Donation forms should have the following buttons at the top of the form
  • SAVE & NEW - saves the current document and lets the user enter a totally new donation documents
  • SAVE & SAME CONTRIBUTOR - saves the current document and creates a new document with the same envelope number
  • The donation form should display a running total on the form of all donations made to the current envelope number in the current donation period (generally week #)
  • When the user enters the first amount for an envelope number in the current period, this display is empty
  • If the donator wants the donation split up, the user would click the SAVE & SAME CONTRIBUTOR button. The new form should display the amount and designation of all donations made to this envelope in the current donation period. This allows the user to quickly determine which of the splits have already been entered.
  • The ability to enter all of the donation data from someone's home and then merging the data back into the main database would be a VERY useful feature
    COMMENT - If the "mobile" data entry feature is to also provide member names tied to the envelope numbers (to help the data entry person identify if the envelope number is wrong), this file could easily grow too big to fit on a floppy and other means of transferring the file will be needed
  • For congregations that regularly change envelope numbers, the application should provide some tools to assist in this task
    COMMENT - Is there any GOOD reason why envelopes need to be re-issued on a regular basis? If someone leaves and releases an envelope, could the congregation simply make that envelope available to the next person who requests an envelope? Why do some congregations give members new envelope numbers each year? Can the computer duplicate whatever functionality the re-issuing of envelopes provides in a paper based system? The only reason I heard was that people liked to have the envelope numbers assigned sequentially to match the alphabetical sorting of congregation members' names
  • It would be nice to have a report where you could print out all of the donations categorized and totaled by household and then by envelope holder within a household. This view should not display envelopes with zero balance

Tax Receipt Data

  • Record if receipts have been generated for a member/household and provide a way to identify which of the donations recorded to a household have not had receipts issued yet.
  • Provide ability to issue receipt immediately rather than at end of year (likely a status flag on each donation record that gets set upon issuing a receipt)
  • It would be nice to be able to control if donations generate an individual receipt or a household receipt
    COMMENT - Is this a REAL requirement?
    • We need to check with the government as several people commented that they believe that you are able to group together and split up receipts within the members of a family. If Revenue Canada allows you to claim the receipts of your immediate family members, then this is simply a matter of educating congregation members. We would then just print receipts at the individual level and then people can submit multiple receipts under one name if they are claiming under one name. If they know up front that they want to submit under one name, then they can simply use that person's envelope for all donations and one receipt is generated.
    • If Revenue Canada allows people to group receipts together for the members of a family, then we should be able to do everything at the individual level and provide reports if anyone wants to know what a household has given. Capturing data at the individual level may make it easier to deal with generating separate receipts if a couple divorces.
    • Can anyone come up with a REAL reason why this MUST be a feature. The added complexity and special cases introduced by managing individual AND family donations and providing an easy way to group/split these
    • The decisions on this and related topics will affect how several other features work including:
      • How you define who gets a tax receipt
      • Whether or not people can share an envelope number
      • Whether or not multiple envelopes can roll up into one receipt
  • It would be nice to be able to scan in signatures for receipts so that someone does not have to sign/stamp a signature on each receipt
    COMMENT - One option is to have the database simply capture donation/receipt data and provide tools to assist the user in managing the data. We could then provide buttons that would export the appropriate data for receipt information into a mail merge file. This would provide congregations with full flexibility of customizing their receipts as it is all done in their word processor. The database could ship with a word processor template in the most common word processors that each congregation may edit. This template could be used for merging with the receipts mail merge file generated by the system and would contain place holders for a congregation to enter all of the common data that must appear on all receipts.

Baptism Data

  • It would be useful to be able to view baptisms categorized by month and then sorted by date

Marriage Data

  • It would be useful to be able to view marriages categorized by month and then sorted by date

General Functionality Comments

  • Provide a means to move members and all of their records back and forth between the main database and an archive database. Likely only deceased members would be archived.
  • A congregation would never delete an entry; they would just archive it so that a historical record is kept.
  • Provide some way to track shepherd groups and home teams
    COMMENT - Is this something that can be managed using the user definable miscellaneous lists? A textual attribute can be assigned to any member and all members sharing that attribute can be recalled at any time for mailing list purposes.
  • Provide some way to track current church council and automatically make this information available to Synods and National Office
    • COMMENT - Fields can be added to the statistics form for each of these fields
    • COMMENT - If the congregation wishes to keep track of these lists (current and historical), they would simply create an appropriately worded miscellaneous list attribute and assign this attribute to the appropriate members' records so that they can be extracted for mailing lists and the like
  • Several of the existing products being used are based upon relational databases where a household record is related to individuals that make up that household.
  • Changing the address of the household changes the address of everyone in that household and people can be tracked by household number
    COMMENT - We need a list of all of the functionality that is needed at the individual and household levels.
  • Need to be able to generate household mailings where the salutation is appropriate for the household (e.g. Mr. And Mrs. Kwok)
  1. Member data
  2. Donation data
  3. Tax receipt data
  4. Baptismal data
  5. Marriage data
  6. General Functionality

 

We appreciate your comments and suggestions about Rasmus at this e-mail.

In full communion with The Anglican Church of Canada
© Copyright 2007 Evangelical Lutheran Church in Canada