Processing Commitments

This chapter provides an overview of commitment processing, lists common elements, and discusses how to:

• Queue sessions for posting.

• Process and post sessions.

• Process credit card transactions.

• Purge credit card security data.

• Review electronic payment results.

• Work with denied credit card transactions.

• Review credit card activity.

• View accounting lines.

• View suspended sessions.

• View information about and transfer sessions.

• Manage the acknowledgement process.

• Process acknowledgement letters.

• Generate acknowledgement letters.

• Work with manually generated acknowledgements.

• Manage joint communications.

• Handle matching gifts.

• Manage giving clubs.

• Generate CAE reports.

Understanding Credit Card Processing

The Contributor Relations credit card processing feature is a platform independent, component based, and secure tool that enables your organization to accept and process credit card payments for the receipt of gifts and membership dues. Administrators can use the online pages for background credit card processing, and self-service contributors can make credit card donations through pages in self-service Involvement for real-time credit card donations.

Credit card processing involves the following functional areas:

• Entry of credit card information (through both core system and self-service pages).

• Credit card authorization.

• Credit card capture (settlement).

• Credit card adjustment.

• Support for multiple credit card types.

• Real-time (self-service pages) and background (core system) processing.

• Credit card transaction review.

In terms of security, this feature provides confidentiality of payment information, ensures integrity for all transmitted data, performs cardholder authentication, and maintains an audit trail of authorization and transaction capture.

Accessing the Credit Card Payment Pages

There are two primary users of the credit card payment pages − organization employees and self-service contributors. The following table lists each user's possible modes of access.

Administrators access the Gift Entry, Gift Adjustment, Membership Entry, and Membership Adjustment pages directly through the system's menu navigation to enter gifts and membership payments. The credit card entry page is accessible on each of these four pages using the Tender Detail button (if the tender type is set to a tender setup with a Credit Card special fields indicator).

Donors access the Make a Donation - Payment Information page through self-service Involvement functionality. To access this page, the donor must have an established transition ID or system ID and click either the Make your gift securely online link or the Invest in existing campaigns link on the Ways to Give page. Donors then enter gift information on the online giving pages that follow.

See Also

Working with Self-Service Involvement

Common Elements Used in This Chapter

Queuing Sessions for Posting

This section discusses how to queue balanced sessions for posting.

Page Used to Queue Sessions for Posting

Queuing Balanced Sessions

Access the Queue Sessions page (Contributor Relations, Session Management, Queue Sessions for Posting).

Note. After a session is queued, it cannot be reopened for editing. Make sure that you are only queuing sessions that you know are ready for posting in the GL Interface process.

Processing and Posting Sessions

This section provides overviews of session processing and posting, the GL interface process, and the process constituent accumulators process and also discusses how to:

• Run the GL interface job.

• Run the GL interface file extract process.

• Run the Constituent Accumulators process.

• View a journal generator template.

Understanding Session Processing and Posting

There are two processes you run to prepare balanced and queued sessions from the system to be posted as journal entries in PeopleSoft Financials.

1. The GL Interface process copies the transaction data from the Contributor Relations system into a table called AV_ACCTG_LN.

   In this table the transactions are associated with the appropriate item types in Financials. When you set up item types for designations that will receive gift and pledge payments, they may only be associated with a credit. This process brings the debit and credit sides together to enable dual-line accounting entries in the financial system.

   For example, a gift transaction for 100 USD has a debit of 100 USD to a tender account with a journal set of 0 and a credit of 100 USD to a designation account with a journal set of 1.

   Tender
   Debit	Credit
   100 USD

    

   Designation
   Debit	Credit
   	100 USD

   If the Feed Pledges check box is selected on the CR Installation page, a pledge transaction for 500 USD has a debit of 500 USD to accounts receivable with a journal set of 2 and a credit to a designation account with a journal set of 2. If the Feed Pledges check box is cleared, the pledge is not processed to the general ledger.

   If the Feed Pledges check box is selected on the CR Installation page, a pledge payment of 500 USD for the previous pledge has a debit of 500 USD to a tender account with a journal set of 0 and a credit to accounts receivable with a journal set of 3. If the Feed Pledges check box is cleared, pledge payment transactions are handled as though they are gift transactions.

   Tender
   Debit	Credit
   500 USD − Pledge Payment

    

   Accounts Receivable
   Debit	Credit
   500 USD − Pledge	500 USD − Pledge Payment

    

   Designation
   Debit	Credit
   	500 USD – Pledge

   If a gift or membership transaction that has been posted is adjusted from 1,000 USD to 100 USD, and the Refund check box is selected on the Gift Adjustment or Membership Adjustment page, the adjustment results in a refund to the donor. In this instance, the original transaction is negated by crediting the tender account 1,000 USD to reverse the original transaction, then debiting the tender account 900 USD for the refund and 100 USD for the new transaction amount. The designation account is adjusted by debiting 1,000 USD to reverse the transaction, then crediting 100 USD for the new transaction amount. Finally, the refund is recorded through a 900 USD credit to the clearing account. Refunds are not managed within the system except to create the entry to the clearing account.

   Note. The default clearing account is set up on the Institution Installation page.

   Tender
   Debit	Credit
   	1,000 USD (Gift)
   900 USD − Negate Gift
   100 USD − Adjusted Gift

    

   Clearing Account
   Debit	Credit
   	900 USD - Refund

    

   Designation
   Debit	Credit
   1,000 USD (Negate Gift)	100 USD (Adjusted Gift)

2. Depending on the version of PeopleSoft Financials your institution uses:

   • If your institution uses Financials 8.4 or 8.8, the information in the AV_ACCTG_LN table is sent to Financials using Integration Broker.

     The Journal Generator process is run within Financials to create journal entries.

     See Interfacing with PeopleSoft Financials.

   • If your institution uses another version of Financials or any other Financials application, the system creates a file that contains the AV_ACCTG_LN information, which is ready to be imported into the Financials system.

See Also

Setting Up Item Types

Understanding the GL Interface Process

When you run the GL Interface process, the following events occur:

For Each Session

The following occurs:

1. The process evaluates the session type and branches to the appropriate subroutine.

2. After the subroutine (described below) runs, the session status is set to "P" for Posted when results are correct.

   Session status is set to "S" for Suspended if required information is missing.

3. If the process fails because the session is suspended or the process fails to run, any rows entered into AV_ACCTG_LN for the session are deleted.

For Gift Sessions

The following occurs:

1. Checks the ITEM_TYPE table to determine tender information.

2. If ITEM_TYPE is correct, the routine processes the GL Interface.

   1. Checks the GL_INTERFACE table for ITEM_TYPE.

   2. Creates dual-line accounting entry in AV_ACCTG_LN by combining tender information with designation information.

3. If ITEM_TYPE is None, the session suspends with the message "Item type not defined for tender" or "Item type not defined for designation."

For Pledge Sessions

The following occurs:

1. Processes only pledges that are marked feed pledge.

2. If ITEM_TYPE is correct, the routine processes the GL Interface:

   1. Checks the GL_INTERFACE table for ITEM_TYPE information.

   2. Creates dual-line accounting entry in AV_ACCTG_LN by using designation information containing both credit and debit rows.

3. If ITEM_TYPE is None, the session suspends with the message "Item type not defined for designation."

For Membership Sessions

The following occurs:

1. Checks the ITEM_TYPE table to determine tender.

2. If ITEM_TYPE is correct, the routine processes the GL Interface:

   1. Checks the GL_INTERFACE table for ITEM_TYPE information.

   2. Creates dual-line accounting entry in AV_ACCTG_LN by combining tender information with designation information.

3. If ITEM_TYPE is None, the session suspends with the message "Item type not defined for tender" or "Item type not defined for designation."

4. If the session includes gifts, gift AV_ACCTG_LN entries are created following the process for gift sessions.

For Adjustment Sessions

The system processes information by:

1. Creating reversal rows in the AV_ACCTG_LN table for the most recent version of the transaction.

2. Creating new rows in the AV_ACCTG_LN table following the processes outlined above for the new version of the entry.

3. If a refund results from the adjustment, creating a row in the AV_ACCTG_LN table with the offsetting refund amount distributed to the clearing account defined on the Institution Defaults page.

Note. When posting a zero-amount transaction in a session, the system creates no lines in the AV_ACCTG_LN table and transmits nothing to the financials system. Similarly, when adjusting a transaction to zero, the system creates the necessary reversing entries and transmits them to the financials system. However, it does not create or transmit any new rows representing the zero amount of the adjusted transaction. Therefore, a session that contains only transactions with tenders that allow zero amounts will generate no rows in the AV_ACCTG_LN record.

Understanding the Constituent Accumulators Process

The Constituent Accumulators process builds accumulator tables that summarize data utilized by the Giving Profile and Commitment Summary pages. You can run this process as part of posting any session type using the AVPOST multi-process job, or run it independently through its own run control definition.

Your institution should decide if the information displayed on the Giving Profile and Commitment Summary pages needs to display the latest posted sessions. If so, the Constituent Accumulators process can be run along with the GL Interface in the AVPOST multi-process job. If not, the Constituent Accumulators process can be run independently in an off-peak processing window. Regardless of the run method, the process always attempts to complete all posted and nonaccumulated sessions in the system.

Here is how the process works:

1. Constituent records are loaded from the Constituent Pending Accumulation table (AV_CNST_ACC_PND) and locked.

2. Temporary accumulator records are calculated and updated from temporary tables.

3. Locks on constituent records are released.

4. Related constituent records from posted, nonaccumulated sessions are loaded and locked.

5. Temporary accumulator records are calculated and updated from temporary tables.

6. Locks on constituent records are released.

7. The accumulator flag on the session table (AV_SESSION_TBL.AV_ACCUM_FLG) is set to 'Y'.

Note. If a session does not accumulate because a constituent accumulator record is locked by another accumulator process, the system skips the session and processes it the next time the accumulator process runs. The locked constituent and the locking process instance is indicated in the Service Operations Monitor Log.

Note. If locking problems persist and the constituent accumulator record is locked by a process that is no longer running, check the constituent accumulator table (PS_AV_CNST_ACC) for records where the PROCESS_INSTANCE field is not equal to zero. Add all constituent records with a nonzero, nonprocessing PROCESS_INSTANCE to the pending accumulation table (PS_CNST_ACC_PND) and reset the locking records PROCESS_INSTANCE to zero. Re-run the process. After the process runs, the pending accumulation table should be empty, and all posted sessions should be processed.

The following graphic illustrates the Constituent Accumulators process flow, from the person or organization's matching gift or pledge schedule, through to the person or organization's commitment summary, including all of the tables affected during processing:

Constituent Accumulators process flow

Pages Used to Process and Post Sessions

Running the GL Interface Job (AVPOST and AVPOST2)

Access the GL Interface page (Contributor Relations, Session Management, Process Sessions, G/L Interface).

Sessions must be queued for posting before they are processed. This process combines the tender account with the designation to create a dual line accounting entry.

Note. You must select a default Clearing Account on the Institution Installation page for this process to run.

If the process is set up, when you click the Run button, Process Scheduler runs the GL Interface process at user-defined intervals.

If your institution uses Financials software other than Financials 8.4, run the AVPOST job, which completes the AV/GL Post process, creates an extract file for export to Financials, and accumulates constituent totals for the Giving Profile and Commitment Summary pages.

If your institution uses Financials 8.4, run the AVPOST2 job, which runs similarly to the AVPOST job but replaces the SQR report output with the EOP_PUBLISHA process.

The EOP_PUBLISHA process does the following:

1. Selects accounting lines based on three criteria: process or job instance, process name, and process status.

2. Collects accounting line entries generated by the GL Interface AVPACCTL COBOL process and publishes them to the Financials 8.4 database.

Financials subscribes to the published messages in the Contributor Relations database, takes the accounting lines into their AV_ACCTG_LN table, and runs those lines through Journal Generator to create journals. Financials then publishes the updated accounting lines, Contributor Relations subscribes to these lines, and the data published by Financials updates the Contributor Relations AV_ACCTG_LN table.

See Also

Running the AVPOST2 Job

Running the GL Interface File Extract COBOL Process (AVPACCTL)

Access the GL Interface File Extract page (Contributor Relations, Session Management, Process Sessions, G/L Interface File Extract).

If your institution uses a version of Financials earlier than 8.4, or uses an external Financials system, run this process if the AV_POST job failed or if you chose to run only the AVPACCTL process rather than the complete GL Interface job.

If the process is set up, when you click the Run button, Process Scheduler runs the GL Interface File Extract process at user-defined intervals.

Running the Constituent Accumulators Process (AVPOST)

Access the Constituent Accumulators page (Contributor Relations, Session Management, Process Sessions, Constituent Accumulators).

If you process sessions using the AVPOST multi-process job, the system runs the processes automatically as part of that routine. If you run the GL Interface independently, run this process to provide current accumulated data on the Giving Profiles and Commitment Summary pages.

If the process is set up, when you click the Run button, Process Scheduler runs the Accumulate Constituent Totals process at user-defined intervals.

Viewing a Journal Generator Template

Use the Journal Generator Template component to review how journal templates for Contributor Relations are set up in Financials.

See Also

PeopleSoft General Ledger 9.0 PeopleBook

Processing Credit Card Transactions

This section provides an overview of credit card transaction processing and discusses how to:

• Select gift and membership transactions for processing.

• Authorize gift and membership transactions.

• Capture gift and membership transactions.

• Authorize and capture transactions as a single process.

• Handle denied CyberSource transactions.

Understanding Credit Card Transaction Processing

After you have posted a gift or membership with a credit card tender type to the general ledger, you can then process it through the third-party payment processor, CyberSource. Contributor Relations supports the following transaction processes through CyberSource:

• Authorization

  Authenticates the credit card number and places a temporary hold on the specified amount against the cardholder's credit card. Also generates an authorization number and reduces the cardholder's available credit by the authorized amount. If the credit card information is not correct, or the cardholder does not have available credit, the system generates a message declining the transaction. Note that CyberSource does not bill the credit card at this time; it only verifies that the card is valid for the charge.

• Capture

  Confirms the temporary hold placed on credit card funds after a transaction has been authorized and bills the credit card.

• Authorize and Capture

  Combines transaction authorization and capture together in a single process.

• Credit

  Issues a refund to a customer's credit card account after an adjusted gift or membership.

The table below lists all possible transaction statuses that are assigned to gift and membership transactions as they move through the credit card payment process.

The following graphic illustrates the steps involved in processing gift and membership credit card transactions.

Summary of electronic payment transaction processing

Pages Used to Process Credit Card Transactions

Selecting Gift and Membership Transactions for Processing

Access the EP Transaction Processing - Filter Options page (Contributor Relations, Session Management, Process Electronic Payments, EP Transaction Processing).

Institution	Enter an institution code.
Business Unit	Enter a business unit for the gift or membership transactions to process. This field cannot be left empty because Transaction Requested field values are dependent on the business unit specified. Note. Session number and gift number fields are tied to the business unit; you must specify a business unit here to filter on these two fields later on the page.
Tender Type	Enter the electronic processing tender type for the gift or membership transactions to process. Note. The example above uses CC to designate this electronic payment tender type. However, you can define it as anything using the Tender Types page.
Transaction Requested	There are four credit card transaction processes currently supported by CyberSource: Authorize, Capture, Authorize and Capture, and Credit. Select the appropriate transaction for the processing step to complete.
Self Service Session	Select the type of session to process: All Sessions: to select gifts and memberships made through both Contributor Relations and Involvement self-service pages. Only Self Service: to select gifts made through the self-service Make a Donation pages only. Non Self Service: to select gifts made through Contributor Relations non self-service pages only.
Post Date	Enter both From and To dates to select gifts or memberships posted within the range.
Session Number	Enter a session number to select gifts made in this specific session only. To display a session, you must enter a business unit.
Gift	If you are processing gift transactions, this field is available for entry. Enter a gift number to select gifts made with this gift number only. To display a specific gift, you must enter a business unit.
Mbr Pmt Nbr (membership payment number)	If you are processing membership transactions, this field is available for entry. Enter a membership payment number to select membership transactions made with this payment number only. To display a membership, you must enter a business unit.
Search	Click to filter the electronic payment transactions according to the specified criteria and display the results on the EP Transaction Processing - Transaction List page.

See Also

Authorizing Gift and Membership Transactions

Capturing Gift and Membership Transactions

Adjusting Gift and Membership Credit Card Payments

Authorizing Gift and Membership Transactions

Access the EP Transaction Processing - Transaction List page (Click the Search button on the EP Transaction Processing - Filter Options page).

Note. On the EP Transaction Processing - Filter Options page, set Transaction Requested to Authorize.

The following fields on this page are defined on the EP Transaction Processing - Filter Options page: Business Unit, Tender, Session Nbr, Gift Nbr, Mbr Pmt, Nbr (if authorizing membership transactions), and Post Dt.

If the search criteria you enter on the EP Transaction Processing - Filter Options page does not meet any existing transaction records, you receive the following informational message:

Important! On the EP Transaction Processing - Transaction List page, if you click the Select All button to select transactions for processing, you receive the informational message above. This does not mean there was a processing error; the system uses this message to notify you that processing of the entire Transaction List is complete, and it has found no more records to process.

After the system authorizes a transaction, the value of the AV_PAYMENT_STATUS field for gift or membership transactions (AV_EP_GIFT_DTL or AV_EP_MBR_DTL) becomes A. If any transactions do not successfully authorize, you must complete them using the denied transactions process or using a gift adjustment session.

See Also

Working with Denied Credit Card Transactions

Adjusting Gift and Membership Credit Card Payments

Selecting Gift and Membership Transactions for Processing

Capturing Gift and Membership Transactions

After the system authorizes a group of transactions, you can filter for transactions using the EP Transaction Processing - Filter Options page and then select and capture the transactions using the EP Transaction Processing - Transaction List page. When you return to these pages, you must filter and process the transactions with a Transaction Requested field value of Capture.

Note. All gifts made through PeopleSoft Involvement self-service pages enter the system at this stage, authorized and ready to be captured.

After the system captures a transaction, the value of the AV_PAYMENT_STATUS field for gift or membership transactions (AV_EP_GIFT_DTL or AV_EP_MBR_DTL) becomes B.

See Also

Selecting Gift and Membership Transactions for Processing

Authorizing Gift and Membership Transactions

Authorizing and Capturing Transactions as a Single Process

Instead of authorizing and capturing gift and membership transactions in separate steps, you can run both processes in one step. For some organizations, this is preferable because it allows you to streamline your processes. For others, it is more valuable to monitor each process.

Note. Your organization may have financial considerations, because a third-party credit card processor charges a per transaction fee; authorizing and capturing are considered separate transactions. If you authorize and capture in a single succession, use a single transaction to authorize/capture.

If you decide to authorize and capture in a single process, you can use the same EP Transaction Processing - Filter Options and EP Transaction Processing - Transaction List pages as you would when authorizing and capturing separately. However, when you use these pages, you must filter and process the transactions with a Transaction Requested field value of Authorize and Capture.

After the system successfully authorizes and captures a transaction in a single succession, its status becomes B.

See Also

Selecting Gift and Membership Transactions for Processing

Authorizing Gift and Membership Transactions

Capturing Gift and Membership Transactions

Handling Denied CyberSource Transactions

Here is some additional information about handling denied CyberSource transactions:

1. If the EP Process receives a returned message indicating an E-System error, an error has occurred after the PeopleSoft-to-credit-card-merchant connection.

   In this instance, the transaction will be denied but will not be available to be reprocessed through the Denied Transactions component.

2. This does not stop the process from continuing for subsequent valid transactions in the same process run.

3. Contact the donor, because the transaction failed outside of the PeopleSoft/CyberSource connection. For example, the transaction was denied by the donor's bank.

Purging Credit Card Security Data

This section discusses how to purge security codes from the system associated with gift and membership transactions.

Understanding Credit Card Security Code Purging

Credit card security codes are retained until after the transaction is authorized. In real-time transactions, the security code record is deleted immediately after the self-service transaction is authorized. However, if the payment merchant is set up to perform batch authorizations, there could be a delay between the time that sessions containing transactions are submitted and when they are authorized. The Purge Gift Security Codes and Purge Membership Security Codes pages enable you to ensure the timely deletion of this data and remain PCI compliant.

Pages Used to Purge Credit Card Security Data

Purging Security Codes for Gifts and Memberships

Access the Purge Gift Security Codes or Purge Membership Security Codes page.

The fields on each page are the same for both gift and membership security code purges.

The fields in the Purge Cutoff Date group box enable you to periodically purge gift or membership security codes from your system. The cutoff date is calculated by subtracting the days, hours and minutes from the current system date and time, and any transaction with a date/time earlier than that is deleted.

Click the Run button to launch Process Scheduler and run the AV_CVVPURGE Application Engine process, which removes security codes from the AV_EP_PMT_CVV record that:

• Exceed the retention maximum days, hours and minutes, irrespective of whether they are authorized or not.

• Have been authorized, yet somehow were not purged by AV_EP_BATCH after the credit card transaction was authorized.

Reviewing Electronic Payment Results

This section discusses how to:

• Prepare to run the Electronic Payment (EP) processing audit.

• Generate the EP Processing Audit report.

• View EP processing audit information online.

Pages Used to Review Electronic Payment Results

Preparing to Run the EP Processing Audit

Before you can generate the AV704 report, you must:

1. Enter credit card gifts or membership payments on the Gift Entry or Membership Entry pages.

2. Balance, queue, and post those gift or membership sessions.

3. Submit a request to process the credit card transactions using the EP Transaction Processing page.

Generating the EP Processing Audit Report

Access the EP Run Review page (Contributor Relations, Session Management, Process Electronic Payments, EP Run Review).

When you run the process, the system generates the AV704 report. Each electronic payment Transaction Requested status begins a new page, and the last page provides total transaction amounts.

EP Processing Audit

You can enter a Process Instance number to use for this report, or click the button at the end of a Process Instance row to copy that instance's information into the fields of the group box.

Filter Options

The Filter by Operator ID field is available if you have gift or membership supervisor security status in the system.

Process Details

See Also

Contributor Relations Reports

Viewing EP Processing Audit Information Online

Access the EP Run Review - Transaction List page (Click the Process Instance link on the EP Run Review page). This page provides an online view of the same information contained in the AV704 report.

The List tab provides information about how the electronic transaction was handled during processing. Click the Reference Number link to access the Reference Number List view of the page, which displays a history of the reference number and previous attempts to work with the transaction.

The Detail tab provides information about the transaction itself and displays details about what was entered.

Click the Payment Status link to access the AV_EP_TRANS_SP page, where you can view system action details that relate to this transaction.

See Also

Selecting Gift and Membership Transactions for Review

Working with Denied Credit Card Transactions

This section provides an overview of denied credit card transactions and discusses how to:

• Select denied gift and membership transactions for processing.

• Authorize and capture denied gift and membership transactions.

Understanding Denied Credit Card Transactions

When you attempt to authorize or capture credit card gift and membership transactions, you occasionally receive denial messages from the third-party credit card processor. Denials occur for many reasons, including invalid card number, account over limit, internet communication problems with the third-party credit card processor, and so on. Whenever transactions are denied, the value of the AV_PAYMENT_STATUS field becomes D.

You can use the EP Denied Transactions - Filter Options and EP Denied Transactions - Transaction List pages to perform the following functions:

• Retry the authorization, process the capture, authorize and capture, or process a credit.

• Handle the transaction manually.

• Cancel the payment of the transaction.

Pages Used to Work with Denied Credit Card Transactions

Selecting Denied Gift and Membership Transactions for Processing

Access the EP Denied Transactions - Filter Options page (Contributor Relations, Session Management, Process Electronic Payments, EP Denied Transactions).

Use this page in the same way that you select gifts and memberships for authorization and capture; the difference is that this page only searches those transactions that the third-party credit card processor denied.

The fields on this page are the same as those on the EP Transaction Processing - Filter Options page. For denied gift or membership transactions, however, the Transaction Requested value you select is the stage at which the gift or membership transaction is denied: during authorization, capture, combined authorization/capture, or credit.

See Also

Selecting Gift and Membership Transactions for Processing

Authorizing and Capturing Denied Gift and Membership Transactions

Access the EP Denied Transactions - Transaction List page (Click the Search button on the EP Transaction Processing - Filter Options page).

Note. To authorize, on the EP Denied Transactions - Filter Options page set Transaction Requested to Authorize. To capture, set Transaction Requested to Capture.

The following fields on this page are defined on the EP Transaction Processing - Transaction List page: Payment Status, Business Unit, Tender, Session Nbr, Gift Nbr, Mbr Pmt Nbr, (if authorizing or capturing membership transactions), Post Dt, Reference Nbr, ID, and Gift Amt.

This page also lists the Result message for the transaction.

After you select the appropriate rows, click the Process button to retry the transaction. The process runs the same as it does for the initial attempt to authorize, capture, authorize and capture, or credit a transaction.

Click the Manual button to handle a denied transaction manually. For example, you may want to call the contributor, adjust the gift, or contact the third-party credit card processor directly to resolve the transaction. Denied transactions dealt with manually receive a status of M.

Note. When you handle a transaction manually, you must perform all subsequent actions manually, such as authorization, validation, or capture.

Click the Cancel Pmt button to cancel the transaction. The transaction then appears in the transaction log file with a status of N. When you cancel a transaction, you can no longer filter on it using the EP Denied Transactions - Filter Options page.

Important! After you click the Process, Manual, or Cancel Pmt buttons, give each process at least 30 seconds to run.

See Also

Authorizing Gift and Membership Transactions

Capturing Gift and Membership Transactions

Reviewing Credit Card Activity

You may need to track credit card activity by day, session, business unit, and so on. You may also need to track transactions that are waiting to be sent for third-party processing. Contributor Relations retains a historical record of all credit card activity that you can filter and review. For example, you can view which transactions were sent, which passed, and which failed, and other transaction details.

This section discusses how to:

• Select gift and membership transactions for review.

• Review gift and membership transactions.

• Review credit card processing messages.

Pages Used to Review Credit Card Activity

Selecting Gift and Membership Transactions for Review

Access the EP Transaction Log Inquiry - Filter Options page (Contributor Relations, Session Management, Process Electronic Payments, EP Transaction Log Inquiry).

The fields on this page are similar to those on the EP Transaction Processing - Filter Options page used to initially authorize, capture, authorize/capture, or credit transactions.

Use this page to filter any gift and membership transactions that have any status and are at any point in the credit card process. You can retrieve transaction details for any time period by entering a Transaction Date range. To review all transactions associated with a gift or membership, enter its 15-character Reference Nbr (reference number). To retrieve log information associated with a self-service gift, enter its 12-character Receipt Nbr (receipt number).

See Also

Selecting Gift and Membership Transactions for Processing

Reviewing Gift and Membership Transactions

Access the EP Transaction Log Inquiry - Transaction List page (Click the Search button on the EP Transaction Log Inquiry - Filter Options page).

Reference Number	The system populates this field by default with a system-generated reference number used to communicate with the third-party credit card processor.
Sequence Number	Indicates how many actions the system has taken on a particular reference number.
Payment Status	Click the link to view system action details that relate to this transaction.
Credit Card Message 1	Displays the resulting response message from the third-party credit card processor.

The Request Token field appears on this page. The Last Update Date/Time, Last Update User ID, and Process Instance fields are also on this page.

When your institution submits an initial credit card transaction request to CyberSource, then follows it with a separate request later, you must supply a request token with the second request. CyberSource generates and sends this token in its reply to any service request. For example, if you authorize a transaction and you later submit a follow-up request to capture it (not an auth/capture request), the process must provide CyberSource with this request token when you submit the capture request.

The Detail tab provides more clarity about each gift or membership credit card payment. For each transaction on the List tab, you view the corresponding Business Unit, Tender, Session Number, and Gift Nbr (numbers), Transaction Date, Authorization Date if applicable, the person or organization ID, the Gift or Dues Amt (amount), the Receipt Nbr (number), and the Authorization Reply the system received from the third-party credit card processor.

Reviewing Credit Card Processing Messages

When you run the Application Engine process that sends credit card transactions to a CR merchant for credit card processing, you can click the PeopleSoft Process Monitor (Process Monitor, Details, Message Log) link on that page to view the job status and the messages that the system sends during the process.

The system displays a message on this PeopleTools page for each declined transaction. In addition, if your CR merchant for credit card processing is set up for tracing, the system displays messages for all transactions, regardless of their status. To set up a merchant for service provider tracing, select the appropriate value in the Credit Card Tracing field on the CR Merchants page (Set Up SACR, Product Related, Contributor Relations, Session Management, Merchant Table).

Click the Explain button beside a message on the Message Log to access a PeopleTools Explain page where you can learn more about the message.

The Description portion of the page enables you to decode the message. For example, here is the meaning of the message "Decline MEDBU.1.M.162.52 101":

• Decline: the return status message. In this case, the third-party processor declined the transaction.

• MEDBU.1.M.162.52: the merchant reference breaks down as follows:

  • MEDBU is the business unit associated with the transaction.

  • 1 is the service requested code. Code 1 = authorization, 2 = authorize and capture, 3 = capture, and 4 = credit.

  • M is the session type of membership, membership adjustment, gift, or gift adjustment.

  • 162 is the system-generated number of the gift or membership session.

  • 52 is the gift or membership payment number.

• 101: the return status message provided by the third-party processor.

See PeopleTools: PeopleSoft Process Scheduler

Viewing Accounting Lines

This section discusses how to view generated accounting lines. The system generates accounting lines through the GL Interface process.

Page Used to View Accounting Lines

Viewing Generated Accounting Lines

Access the Accounting Line page (Contributor Relations, Session Management, Supervise Sessions, Accounting Line Summary).

Note. Multiple views of this page are available by clicking the tabs in the scroll area.

Search Criteria

Here are fields that are common to all views.

GL Chartfield 1 and 2

These tabs display the information sent to PeopleSoft Financials 8.4 and 8.8. The GL Interface process currently populates the following fields:

• Fund

• Alternate Account

• Budget Reference

• Chartfield 1

• Chartfield 2

• Chartfield 3

See Also

Viewing Accounting Lines

Interfacing with PeopleSoft Financials

Viewing Suspended Sessions

This section discusses how to view information about suspended sessions.

Page Used to View Suspended Sessions

Viewing Suspended Session Information

Access the Suspended Sessions page (Contributor Relations, Session Management, Supervise Sessions, Suspended Sessions).

When you post gift and pledge sessions, the system displays any sessions that were suspended for any reason on this page. You can reopen the session and make the necessary adjustments to enable proper posting.

If any of these errors occur in the GL Interface process, the system rolls back all processing related to the session and sets the AV_SESSION_TBL.SESS_STATUS field to S. These sessions appear on the Suspended Sessions page.

To fix the session for reprocessing, the situation underlying each error in the session must be corrected before balancing, queuing, and running the GL Interface process again. For example, if a designation is missing an item type, you have two choices.

You must either update the designation fund record by adding an item type on the Designation Funds page, or select a different designation for the transaction in the entry page of the session for the transaction that erred.

Viewing Information About and Transferring Sessions

Use the Session Filter and Session Summary pages to view information about existing sessions. The Session Filter page enables you to select criteria to narrow the number of sessions you view, and the Session Summary page displays summaries of the sessions matching your selection criteria. From the Session Summary page, you can reopen sessions that have been balanced, make changes to the transactions in a session, or transfer sessions to new users if you have gift and pledge supervisor status on the Staff Roles page.

This section discusses how to:

• Filter sessions.

• View a session summary.

• Transfer sessions.

• Reopen and edit expected counts and amounts for sessions.

Pages Used to View Information About and Transfer Sessions

Filtering Sessions

Access the Session Filter page (Contributor Relations, Session Management, Supervise Sessions, Session Summary, Session Filter).

Business Unit	Enter the business unit for which to view session information.
Session Status	Select a valid session status, such as Open, Balanced, Posted, Queued, or Suspense. If you do not specify a session status, the Session Summary page displays all sessions, regardless of session status. Field values are delivered with the system as translate values. Do not modify these translate values in any way. Any modifications to these values will require a substantial programming effort.
User ID	Displays the ID of the person who controls the session. Note. This field is only available for selection if you are a gift and pledge supervisor; otherwise, your user ID appears here.
Session Type	Select a valid session type, such as Gift, Pledge, Gift Adjustment, Pledge Adjustment, Member, or Member Adjustment. If you do not specify a session type, the Session Summary page displays all sessions, regardless of session type. Session types are delivered with the system as translate values. Do not modify these translate values in any way. Any modifications to these values will require a substantial programming effort.
Self Service Session	Select to filter for gifts made through the Involvement online giving process.
Date Opened, Post Date, and Balance Date	Enter a date opened, post date and balance date range. Select the earliest date in the range from the From prompt box, and the latest date in the range from the To prompt box. A post date range is the date range in which sessions were posted during the GL Interface process. A balance date range is the date range in which sessions were balanced in the system. The sessions matching your date ranges appear on the Session Summary page. Important! To filter transactions for an exact date, enter the same value in both the from and to fields.
Actual Total Count and Actual Total Amount	Enter an actual total count and actual total amount range. Enter the lowest count or amount in the From field, and the highest count or amount in the To field. An actual total count range specifies the number of transactions contained in a session. The actual total amount range specifies the monetary total of a session. The sessions matching the ranges you enter appear on the Session Summary page.
Search	Click to retrieve a list of results matching your selection criteria. Note. The Maximum Retrieval value, set on the Institution Installation page, determines the maximum number of results returned per search.

Viewing a Session Summary

Access the Session Summary page (Contributor Relations, Session Management, Supervise Sessions, Session Summary, Session Summary).

If you are a Gift and Pledge Supervisor, you can reopen and transfer sessions using this page.

See Also

Initializing and Balancing the Session

Transferring Sessions

Access the Transfer page (Click the Transfer Session link on the Session Summary page).

Sessions are tied to User ID; essentially, they are "owned" by the person who creates them. A gift and pledge supervisor or membership supervisor may need this page to transfer a session from one user to another, for example because the owner could not finish the data entry for one reason or another.

Reopening and Editing Expected Counts and Amounts for Sessions

If you try to balance a session on the Maintain Sessions page and you discover data entry errors that prevent you from balancing the session, you must correct the erroneous expected counts and amounts so that the session can balance. However, for security reasons, when you enter and save expected counts and amounts, the system locks them so that they cannot be changed without intervention. Therefore, to correct erroneous data you must reopen the expected counts and amounts for the session on which you are working. Note, however, that only individuals at your institution who have been assigned the role of Gift and Pledge Supervisor (GPS) or Member Supervisor (MS) on the Staff Roles page can reopen expected counts and amounts for a session. Thus, you must first assign an individual the GPS staff role, and then that person can reopen the expected counts and amounts.

Note. To reopen expected counts and amounts within a session, the session cannot have been queued for posting, nor can it have been posted through the GL Interface process.

To reopen expected counts and amounts:

1. Add an ID for the person who will be assigned the GPS role (if not already in the system).

   To add IDs, select Set Up SACR, Product Related, Contributor Relations, CR Common Definitions, Resources, Staff.

2. Assign the person the GPS role.

   Insert a row on the Staff Roles page, select the GPS role, and save the page.

   To assign roles, select Set Up SACR, Product Related, Contributor Relations, CR Common Definitions, Resources, Staff Roles.

   Note. If you are logged in as the ID to which you just assigned the GPS role, you do not have to log out to continue this procedure.

3. Select filter criteria on the Session Filter page and search for the session to be reopened.

   Your search criteria might return multiple sessions, which is fine.

   To select filter criteria, select Contributor Relations, Session Management, Session Filter.

4. Reopen the expected counts and amounts.

   Go to the Session Summary page. If you are logged onto the system as the GPS you have additional buttons such as Expected and Open, and a Transfer link. The buttons and links you see depend on the state of the session. Locate the row of the session to reopen and click the Expected button in that row. A message appears that indicates that the session has now been reopened.

   To access the Session Summary page, enter your criteria on the Session Filter page and click the Search button.

5. Edit the expected counts and amounts.

   Go to the Maintain Gift Sessions, Maintain Pledge Sessions, or Maintain Membership sessions page (depending on what you are working on). Upon entering this page be sure to select the session that you just reopened. The Expt Cnt (expected count) and Expt Amt (expected amount) fields are now available for input. You can edit these fields.

   To access the Maintain Sessions pages, select Contributor Relations, Session Management, Enter Gifts, Maintain Gift Sessions, or Contributor Relations, Session Management, Enter Pledges, Maintain Pledge Sessions, or Contributor Relations, Session Management, Enter Memberships, Maintain Membership Sessions.

   Note. When the fields are edited and saved, you would need to perform Steps 3 and 4 again to reopen the session for editing.

Managing the Acknowledgement Process

In Contributor Relations, acknowledgement letters and receipts are either queued automatically based on parameters you define when you set up your system or queued manually. After they are queued, communications are generated using the letter generator process.

Before you run the acknowledgement process you must first define the acknowledgement and letter setup for the institution and establish joint relationships. All gifts and pledges to be acknowledged must be posted through the GL Interface process.

The following diagram represents the way acknowledgement information feeds into the joint letter generation process:

Acknowledgement process into letter generation

The 3Cs Engine generates joint communications for acknowledgement letters and receipts. After the communications record exists, you can run the Letter Generator process (CCLTRGEN). The 3C Engine runs through a series of rules to determine which records are joined and should receive joint communications. Any remaining unjoined records receive individual communications. The Letter Generator creates a Comma Separated Values (.csv) file containing data needed to generate both joint and individual letters. The .csv file can be merged with a Microsoft Word template to produce actual letters.

Understanding How the Acknowledgement Generation Process Works

When acknowledgements are processed, the system runs a series of checks to determine which letters a donor should receive.

Those steps include:

1. The system runs through each item you prioritized on the Institution Installation 2 page.

   On that page, you entered numbers to represent the priority for sending acknowledgement letters. The priority you set determines which acknowledgement setup parameters are looked at first to determine which letter a donor receives. For each item you prioritized, the system checks the acknowledgement rules and either generates a communications record, assigns the acknowledgement to a role, or assigns it to suspense.

2. The system looks at the designation fund set up for each designation to which the donor gave.

   If an acknowledgement event ID is assigned to a designation fund, a communications record is generated. If a role is assigned to a designation fund, the acknowledgement is assigned to staff members with that role.

Note. If the Anonymous check box is selected on the Recognition page when entering a transaction, the system does not run these checks and does not produce an acknowledgement letter.

Understanding Joint Acknowledgements and Spousal Relationships

The Joint Letter Generator follows specific rules about spousal relationships when generating acknowledgements and receipts. You must be careful when defining defaults for gift recognition splits between spouses to ensure that gifts are properly acknowledged.

Note. To make spouses jointly acknowledged, you must establish a joint record and set up salutations and a joint address using the Relationships component.

On the Contributor Relations Installation page you can define default split percentages between a donor and spouse for various credit types.

Use the following example to determine how default splits affect joint receipting and acknowledgements.

Example

A donor gives a gift of 1,000 USD:

If a joint relationship exists between a donor and spouse and you set the following defaults:

The donor and spouse receive a joint receipt for 1,000 USD. Depending on how you set up acknowledgement rules, they may also receive a joint acknowledgement for 1,000 USD.

If a joint relationship does not exist between a donor and spouse and you set the following defaults:

The donor and spouse each receive separate receipts for 500 USD. Depending on how you set up acknowledgement rules they may also receive separate acknowledgement letters for 500 USD each. No joint communications are created.

If a joint relationship exists between a donor and spouse and you set the following defaults:

The donor and spouse receive a joint receipt for 1,000 USD. Depending on the acknowledgement rules you set up and whether the Acknowledge Soft Credit check box is selected on the Institution Installation 2 page, they may also receive a joint acknowledgement for 1,000 USD.

Note. We recommend that you use this configuration to ensure sending the appropriate acknowledgement letter for the highest hard credit recognized. The system adds hard credits for joint records together, but the letter code for the acknowledgement is selected based on an individual's hard credit rather than the joint hard credit calculation.

If a joint relationship does not exist between a donor and spouse and you set the following defaults:

The donor receives a receipt for 1,000 USD. The donor may also receive an acknowledgement letter for 1,000 USD. Depending on the acknowledgement rules you set up and whether the Acknowledge Soft Credit check box is selected on the Institution Installation 2 page, the spouse may receive an acknowledgement for 1,000 USD indicating zero charitable amount. No joint communications are created.

See Also

Understanding Joint Communications

Setting Up Institution Defaults

Processing Acknowledgement Letters

This section discusses how to automatically process acknowledgment letters.

Page Used to Process Acknowledgement Letters

Processing Acknowledgements Automatically Using a COBOL Process (AVPACKNL)

Access the Process Acknowledgements page (Contributor Relations, Session Management, Acknowledgements, Process Acknowledgements).

Business Unit	Enter the business unit for which to process acknowledgements.
Commit Level	Determine how many sessions for which acknowledgement letters are processed before the system commits them to the database.

If the process is set up, when you click the Run button, the system runs the AVPACKNL process at user-defined intervals.

Generating Acknowledgement Letters

Access the Letter Generation page (Contributor Relations, Communications, Process Communications, Letter Generation).

Contributor Relations uses Campus Community's letter generation process to generate acknowledgement letters when they have been processed.

See Using the Letter Generation Process.

Working with Manually Generated Acknowledgements

You can set up parameters so that acknowledgement letters are automatically generated based on a donor's service indicators, gift amounts, and so on. However, some commitments do not fall into the parameters of these defaults, so those acknowledgements are assigned to a staff member or a suspense file and written or processed separately.

This section discusses how to:

• View acknowledgements in suspense.

• View acknowledgement details.

• Transfer an acknowledgement.

• View acknowledgement lists.

Pages Used to Work with Manually Generated Acknowledgements

Viewing Acknowledgements in Suspense

Access the Acknowledge Suspense page (Contributor Relations, Session Management, Acknowledgements, Acknowledge Suspense).

Important! Acknowledgements are assigned to suspense if they do not fall into any of the setup parameters established when defining acknowledgement rules. They are also assigned to suspense if they are assigned to a role and there is not a resource assigned to that role.

If there is a gift level range (such as gifts less than 50 USD) for which only a receipt should be produced, be sure to include a row in the gift level portion of the acknowledgement setup to manage this. To produce only a receipt, set the No Receipt flag to Yes and select the same event ID that is selected for your receipt. The system generates a receipt but does not produce an acknowledgement letter. If you do not do this the acknowledgement process sends everything in the acknowledgement list to the manual acknowledgement suspense process.

You can build a workset from this page.

See Also

Building a Workset From a Page in the System

Viewing Acknowledgement Details

Access the Acknowledgement Detail page (Click the Process Button on the Acknowledgement Suspense or Acknowledgement List page).

When you process a letter you have the options of selecting and generating a standard letter, assigning a customized letter, or not sending a letter.

Note. We recommend that your institution create an event ID for the purpose of generating custom acknowledgements. The letter code you assign can be a "generic" or blank letter code, since it is not actually used to generate letters. Creating this event ID ensures that a communications record is generated for custom acknowledgements, enabling you to track the communication.

Transferring an Acknowledgement

Access the Transfer page for acknowledgements (Click the Transfer button on the Acknowledgement Suspense or Acknowledgement List page).

Enter the User ID of the person you are assigning the acknowledgement to. The acknowledgement is immediately assigned to the individual you select. If you have selected a group of donors to transfer to another user, all selected acknowledgements will be immediately assigned to the individual you select.

Viewing Acknowledgement Lists

Access the Acknowledgement List page (Contributor Relations, Session Management, Acknowledgements, Acknowledgement List).

Note. If more than one person at your institution is assigned to one role, the acknowledgement appears on the acknowledgement lists of each person with that role. When you complete the acknowledgement, it is removed from the acknowledgement lists of all people with that role so a second letter is not accidentally sent.

You can build a workset from this page.

See Also

Building a Workset From a Page in the System

Managing Joint Communications

Contributor Relations provides the ability to communicate with constituents jointly to a common address rather than producing individual communications for each constituent. For example, you can invite a married couple or two roommates to an event by sending a single invitation to their joint address.

Use the joint communication features on the Relationships and Communications pages to create joint communication for two individuals when at least one of the individuals exists in the database. To set up Joint Communications you must first set up joint salutations, establish a joint relationship, and identify the address to use for the joint communication.

There are two areas in Contributor Relations from which joint communications can be triggered: acknowledgements and receipting, and membership organizations and initiatives. In either instance, the 3C Engine process creates the communication record.

The 3C engine evaluates the selected joint options and determines which records are joined and should receive joint communication. Any remaining unjoined records receive individual communications. After the communication record exists, you can run the Letter Generator.

Note. The Joint Communications feature expands upon the functionality found in Campus Community's Letter Generator. No functionality has been removed from Letter Generator to create the Joint Communications feature.

The following is a list of the communication variable data that the system uses to determine whether or not to send a joint communication:

• Session_no

• Gift_no

• Recognition_type

• Designation

• Intv_cd

• AV_audience

• Aud_type

• Membership_nbr

• AV_mbr_org_cod

• Av_std_ben

• Mbr_pmt_no

See Also

Understanding Joint Communications

Handling Matching Gifts

This section provides and overview of matching gifts and matching gift processing, and also discusses how to:

• View an organization's matching gift rules.

• View an organization's matching gift restrictions.

• View outstanding matching gifts.

• View expected matching gifts.

• View matching gifts for people.

• View matching gifts for organizations.

Understanding Matching Gifts

Many of the donations donors make can be matched by their employers or by other organizations they are affiliated with. You can track information about the types of gifts organizations match, then have the system calculate a "best guess" of the potential matches for a particular gift. You can modify that "best guess" to reflect the actual matching amount expected for a gift, then track actual matching payments or denied matches against your expectations.

In addition, you can track the matching gift forms that must be submitted before some organizations match a gift.

The process works as follows:

1. Your institution enters information about an organization's matching gift rules and the match ratios for particular programs and gift amounts.

2. A donor gives a gift.

   The system checks for potential matching organizations based on the donor's relationships, current work experience, and whether he or she is a qualified contact of an organization. When any one of these criteria exist, the system makes a "best guess" at what the matching gift will be taking into consideration the organization's minimum requirements for amount, ineligible designation matching gift types, ineligible gift types, and match ratio. These expected matches appear on the Outstanding Matching Gifts and External Organization Matching Gifts pages.

3. If they have not already, the donor may need to submit a matching gift form.

   Indicate the date the form was received on the Outstanding Matching Gifts Page or the External Organization Matching Gifts page. Not all matching gift organizations require this step.

4. The organization makes a matching gift.

   When entering the organization's gift, you can select from a system-generated list of the donors expecting matching gifts from the organization, then indicate which original donations are being matched. Alternately, you mark the expected match record as "Denied," and it no longer appears as a current expected match.

Understanding Matching Gift Processing and Foreign Currencies

Matching gifts rules can be defined in any currency, and a donor can give a gift in any currency. However, all gift amounts are converted to your institution's base currency when transactions are stored. Expected match amounts for gifts where a matching gift is expected are determined as described in the following scenarios:

Assumption for these scenarios: the institution base currency is USD.

Scenario 1: The Gift and the Matching Rules are in Institution Base Currency

The matching gift ratios are set up as follows:

A gift of 500 USD is made to the institution. The expected and received match is 1,000 USD.

Scenario 2: The original Gift is in Institution Base Currency and the Matching Gift is not

The matching gift ratios are set up as follows:

A gift of 500 USD is made to the institution. The system expects a match of 1,000, USD but receives a match of 1,300 CAD. The system converts the matching gift to USD using the exchange rate between CAD and USD on the gift date. This rate can be overridden during the gift entry process.

Scenario 3: The Gift and the Matching Rules are not in Institution Base Currency

The matching gift ratios are set up as follows:

A gift of 500 CAD is made to the institution. The system converts the gift amount to the base currency of USD. The system also converts the matching gift rules to the base amount of USD as of the gift date, and applies the converted gift amount to the converted matching gift rules. The expected match amount is always generated in the base currency code.

Scenario 4: The Gift is not in Institution Base Currency, but is in Matching Rules Currency

The matching gift ratios are set up as follows:

A gift of 500 EUR is made to the institution. A matching gift of 1,000 EUR is expected/received. The system converts the expected/received matching gift amount to USD as of the gift date.

Pages Used to Handle Matching Gifts

Viewing an Organization's Matching Gift Rules

The Matching Rules inquiry component enables you to view the matching gift rules defined for an organization. You can view information about minimum match amounts and match ratios, the designations for which gifts can be matched, the annual matching gift budget, required information and contacts, and any matching gift restrictions the organization has.

Access the Matching Gift Rules inquiry page (Contributor Relations, Session Management, Matching Gifts, Matching Rules Details).

Min Amt (minimum amount)	Displays a minimum amount for gifts that the organization will match. The organization will only match gifts that are equal to or greater than the amount in this field.
MG Designation Type (matching gift designation type)	Indicates the designation to which matching gift funds must be applied when they are received. This field enables you to determine to what designations a matching gift company's payment should be allocated.
Receipts	Displays receipt options. Periodically: receipts may be combined and sent to the organization periodically. Each Gift: the organization requires a receipt from your institution for each company gift.
Distribution Schedule	Displays the frequency with which organizations make matching gift payments to your institution.
Deadline Date	Displays the date on which a completed matching gift form must be received by the organization in order for it to match the gift.
Payroll Eligibility	Indicates the organization offers employees the option of having payroll deduction gifts matched through its matching gift program.
Duplicate Match	Indicates the organization matches gifts that are matched by other organizations.

Annual Matching Gift Budget

Matching Gift Ratio

Restrictions

Attachments

Use the fields in this group box to view existing attachments to the organization's matching gift rules record. Click the View link to open the attachment in a new window.

Viewing Outstanding Matching Gifts

Access the Outstanding Matching Gifts page (Contributor Relations, Session Management, Matching Gifts, Person Matching Gift).

Business Unit	Enter the business unit for which to view a donor's gifts with outstanding matches. The outstanding matching gifts that fall within the parameters you select appear on this page.
Gift Number	Click a gift number link to view detailed information about a particular gift on the Gift Detail page.
Process Date	Displays the date the matching gift form was submitted to the matching gift organization.
Denied Date	If the matching gift is denied by the matching organization, enter the date that you received the denial.
Details	Click to view detailed information about a particular gift on the Gift Detail page.

Viewing Expected Matching Gifts

Access the Ext Org Matching Gifts page (Contributor Relations, Session Management, Matching Gifts, Ext Org Matching Gift).

This page displays both matching gifts entered individually as well as those picked up by the COBOL cleanup process run on the Maintain Sessions page.

Viewing Matching Gifts for People

Access the Person Matching Gifts page (Contributor Relations, Analyze Giving History, Person Giving Summaries, Person Matching Gifts).

This page displays both matching gifts entered individually as well as those picked up by the COBOL cleanup process run on the Maintain Sessions page.

See Also

Viewing Expected Matching Gifts

Viewing Matching Gifts for Organizations

Access the Ext Org Matching Gifts inquiry page (Contributor Relations, Analyze Giving History, Organization Giving Summaries, Ext Org Matching Gifts). The fields on this page are the same as those on the Person Matching Gifts page.

See Viewing Matching Gifts for People.

Managing Giving Clubs

This section provides an overview of giving clubs and discusses how to:

• Manually generate giving club memberships.

• Generating giving club memberships.

• Track giving club progress.

• View a giving club summary.

• View a giving club membership summary.

Understanding Giving Clubs

You can define the giving clubs, their levels, and their membership rules.

When clubs are created, membership is generated by the system using the Process Giving Clubs routine. When a donor reaches the required giving level for a giving club membership, he or she becomes a member of the club.

You can track information about the members of each giving club at your institution as well as information about the progress and structure of each giving club.

Pages Used to Manage Giving Clubs

Manually Generating Giving Club Memberships

Access the Giving Club Membership page (Contributor Relations, Session Management, Giving Clubs, Giving Club Membership).

To assign a donor to a giving club you must be the club's administrator. Other staff can view membership information on this page, but cannot update information.

Generating Giving Club Memberships

Access the Process Giving Clubs page (Contributor Relations, Session Management, Giving Clubs, Process Giving Clubs).

Institution	Enter the institution for which giving club records are generated.
Process Date	Enter the date on which the process is run. This field populates by default to the current date. Note. AVPGCLUB uses the date you enter to select currently active giving club records. A giving club's start date, end date, and status are determined on the Giving Club Rules page. AVPGCLUB also uses process date to select giving club eligible designations determined on the Giving Club Rules page. See Defining Giving Clubs.
Commit Level	Enter the number of sessions for which giving club memberships are processed before being committed to the database.

Important! If a donor's giving club eligibility is affected due to a transaction adjustment, the system "backs out" the membership or level change and returns the donor to his or her previous status. However, the system does not back out any membership additions or changes that are entered manually through the Giving Club Membership page.

In the Process Giving Clubs group box you have three processing options—Unprocessed Sessions, Initialize Select Giving Clubs, and Initialize All Giving Clubs—which are described in detail below. The processes that initialize clubs look at historical member data; the other simply looks at unprocessed current data. You need to select different processing options, depending on the state of your giving clubs.

When you process giving clubs, the AVGCLUB PSJob does the following:

1. Runs the AV_GCLUB Application Engine program, which saves existing giving club membership data based on the option selected on the Process Giving Clubs page:

   • Unprocessed Sessions – Does not back up any data. Runs the giving club process for all new commitments that have not been calculated into giving clubs as of runtime.

   • Initialize Select Giving Clubs – Backs up giving club data, from the AV_GCLUB_MBR to the AV_GC_MBR_TMP table, for the selected clubs as it exists immediately prior to runtime.

   • Initialize All Giving Clubs – Backs up giving club data as it exists immediately prior to runtime, from the AV_GCLUB_MBR to the AV_GC_MBR_TMP table, for all giving clubs active as of the process date.

2. Runs the AVPGCLUB COBOL program and calculates giving club membership based on club rules based on the option selected on the Process Giving Clubs page:

   • Unprocessed Sessions – Selects commitments entered within sessions where the giving club flag (GC_FLG) equals 'N', evaluates new commitment data according to club rules, and updates membership data on the AV_GCLUB_MBR table based on current commitments being processed and the last GCLUB_AMT to determine new member or accrual statuses for donors.

   • Initialize Select Giving Clubs – Selects commitments entered within sessions where the giving club flag (GC_FLG) equals 'Y', evaluates historical commitment data according to club rules for the selected clubs, and updates membership data on the AV_GCLUB_MBR table based on all historical commitments to determine new or reinitialized member or accrual statuses for donors.

   • Initialize All Giving Clubs – Selects commitments entered within sessions where the giving club flag (GC_FLG) equals 'Y', evaluates historical commitment data according to club rules for all clubs active as of the process date, and updates membership data on the AV_GCLUB_MBR table based on all historical commitments to determine new or reinitialized member or accrual statuses for donors.

3. Creates the AVGCINIT SQR report which compares the backed up data to the newly generated giving club member data based on the option selected on the Process Giving Clubs page:

   • Unprocessed Sessions – Generates a blank report and concludes the job.

   • Initialize Select Giving Clubs – Generates an SQR report that lists differences for the selected giving clubs, ordered by giving club and fiscal year.

     Where a difference occurs, the old giving club level and the new giving club level appear, as well as old and new statuses and amounts. The report also includes the previous Added By value.

   • Initialize All Giving Clubs – Generates an SQR report that lists differences for all giving clubs active as of the process date, ordered by giving club and fiscal year.

     Where a difference occurs, the old giving club level and the new giving club level appear, as well as old and new statuses and amounts. The report also includes the previous Added By value.

     Important! Giving club members who were previously added manually to override the giving club rules may not meet criteria for membership when the club is reinitialized. The AVGCINIT report helps you identify differences between prior data and recalculated data so that you can review memberships and add complimentary memberships (at levels higher than those calculated by the program) back in the system by using the Giving Club Membership page.

See Also

Contributor Relations Reports

Tracking Giving Club Progress

Access the Giving Club Progress page (Contributor Relations, Analyze Giving History, Person Giving Summaries, Giving Club Progress).

Fiscal Year	Enter the fiscal year for which to view giving club information. This field populates by default to the current fiscal year, but can be changed.
Status	Select the giving club status to view information about. Values are Member or Accruing. Member indicates that the donor is currently a member at the level you selected. Accruing indicates that the donor is still working toward membership eligibility at the level you selected.
Minimum and Maximum	Displays the donation range that determine the low and high end of giving to make donors eligible for giving club membership at this level.

Viewing a Giving Club Summary

Access the Giving Club Summary page (Contributor Relations, Session Management, Giving Clubs, Giving Club Summary).

Levels	Click to view information about the giving club levels associated with each club on the Giving Club Level Detail page.
Details	Click to view detailed information about a giving club on the Giving Club Detail page.

See Also

Defining Giving Clubs

Viewing a Giving Club Membership Summary

Access the Giving Club Membership Summary page (Contributor Relations, Session Management, Giving Clubs, Giving Club Member Summary).

Fiscal Year

Enter the fiscal year for which to view a list of giving club members.

You can build a workset from this page containing one or more club members.

See Also

Building a Workset From a Page in the System

Manually Generating Giving Club Memberships

Generating CAE Reports

This section discusses how to generate reports for the Council for Aid to Education (CAE).

Page Used to Generate CAE Reports

Running a CAE Report

Access the CAE Report page (Contributor Relations, CR Reports, Giving Reports, CAE Report).

The CAE report summarizes gift income by following standards created by the Council for the Advancement and Support of Education (CASE) and the CAE. Generating the report involves running the CAE Report COBOL process (AVPCAE), then running any or all of the three processes entitled GIFTINC, GIFTINCII, and GIFTINCIV. The result is a four-part report that provides a comprehensive view of donor giving for a single institution during a specific reporting period.

When you run AVPCAE, the COBOL process gathers data from several tables and writes it to two tables:

• AV_CAE_WRK – holds data for Parts I, II, and III.

• AV_CAE_WRK2 – holds data for Part IV.

When you run GIFTINC, GIFTINCII, or GIFTINCIV, the Crystal processes populate the report cells and calculate the report totals using the data in AV_CAE_WRK and AV_CAE_WRK2. The processes create the following sections of the report:

• GIFTINC creates Parts I and II.

• GIFTINCII creates Part III.

• GIFTINCIV creates Part IV.

Important! You must run AVPCAE before running GIFTINC, GIFTINCII, and GIFTINCIV in order for the report to populate correctly.

See Also

AVPCAE, GFTINC, GFTINCII, GFTINCIV − CAE Gift Income Report