Gift processing is a very complicated process, and goes through several stages before it is completed. All batches that have a status of Closed, Totals, or Y (YY tables update failed) are eligible to be processed. Any batch with a different status will be ignored by gift processing.
When a fatal error is encountered within a batch during the processing run, the result is that the batch is incompletely processed. In this case, the error must be corrected and the batch must be reprocessed. Meanwhile, all the other good transactions are held up and DO NOT appear in the database. For this reason, it is recommended that batches be kept to a reasonable size, usually no more than one hundred transactions per batch. Please refer to the policies set forth by your organization or institution.
Gift processing is normally run during off peak hours. This is preferable since the program needs to lock several different parts of the database at various stages of its work. If the attempted lock eventually fails, even though gift processing makes several attempts to lock the row in question, it could result in a batch being 'Incompletely' processed. It is also recommended that gift processing be run using a script so error messages can be written to the log file. Validation errors are always written to zz_gperrorlog. Other error messages are written to the deferred processing run log.
Normal daily operations include gift processing, some type of receipts program, some type of financial reporting, and other types of reporting. Since different reports are run daily, weekly, monthly, quarterly, etc., it is suggested that several different scripts be constructed to run gift processing. For example, daily and weekly gift processing scripts. Each one would contain the types of reports that are needed on a daily and weekly basis. This could also be expanded to include scripts for monthly, quarterly and end of year processing.
All of the reports should be set to run AFTER gift processing. In addition, any backup should be performed BEFORE gift processing.
The first step gift processing performs is to verify that the different types of transactions in a batch are valid and all of the components necessary to process the transaction are in place. If any one of the transactions in the batch fails to pass all of the validations, the status of the batch is set to 'Validation' Error and the batch is not processed. The problem that caused the validation error will be written out to the zz_gperrorlog file.
Gift Processing performs the following validations for each individual batch:
Validates the status of the batch. If the status is not C, T or Y, it skips the batch.
Validates that the original record exists for a reversal. This includes both matching gift reversals and regular gift reversals (matching gift, primary gift, primary pledge, payment schedules).
Validates that the donor is in the database; uses the entity information and does not differentiate between a person or an organization.
Validates that the allocation exists, that the year code does not cross fiscal year boundaries, and that the allocation is Active.
Verifies that the gift, matching gift, or pledge to be processed does not already exist in the database, based on the receipt number.
Verifies that the primary gift record exists for the gift to be matched.
Verifies that the pledge being reversed does not have any payments attached to it and that all of the associated pledge records and payment schedules exist.
Verifies that the pledge being modified has not already been modified in an earlier batch in the same run.
If the batch passes the validation phase, transactions in the batch are processed in the following order:
Matching reversals
Gift reversals
Pledges
Gifts
Matching Gifts
YY Tables
Totals
As in the validation phase, any fatal error encountered during any stage may cause some of the transactions in the batch to fail to process. Whenever that occurs, the status of the batch will be set to Incompletely Processed. If possible, the error will be written out to the log file. As some errors are not part of the gift processing program, not all errors can be written out to the log file. Some examples of this would be a power failure, a system crash, etc.
Any batch that has a status of Y means that gift processing failed to write to the YY tables. Before attempting to correct the error, you will need to figure out why it couldn't write to the YY tables. This may occur because the tables are out of space, out of extends, out of index space, or due to a problem with the data. Once you feel confident that you have solved the problem, do not change the status of the batch from Y. The next time you run gift processing, the procedure will attempt to pick up where it left off the previous time and make another attempt to write the data to the YY tables. When the status is set to Y, the transactions themselves have been written out to the database, but the donor summary and fiscal year totals have not been updated. Gift processing will also attempt to update these tables after you rerun gift processing after you have fixed the problem.
Any batch that has a status of Incompletely processed should be CAREFULLY examined to determine what caused the problem. In addition, all transactions in that batch will be backed out of the database.
In the matching gift reversal stage, gift processing writes the matching gift row to the matching gift reversal table and deletes it from the matching gift table. It also attempts to recreate the matching claim information, if appropriate. If the matching gift matched a pledge payment, the primary pledge record is also updated to subtract out the match amount. In addition, the totals for the organization and the donor matched are also updated.
During the gift reversal stage, the program writes the primary gift row to the primary gift reversal table and writes all of the associated donor gift rows to the gift reversal table. Those primary gift and associated donor gift rows are then deleted from the primary gift and the donor gift tables. If there are any claims associated with this transaction, they are deleted. If the gift is a pledge payment, it also updates the paid amount in the primary pledge row and any affected pledge schedule rows. The donor summary and the fiscal year totals are also updated.
When the pledge is processed, a primary pledge row and one pledge row for each associated donor is created. Based on the information in the pledge record and/or the batch control record, the payment schedules are created. The donor summary and the fiscal year totals are also updated.
When the gift is processed, a primary gift row and one gift row for each associated donor is created. If the gift is a pledge payment, then the primary pledge row and the payment schedules are also updated. If there is claim information associated with the gift, then the matching claim information is also written out. The donor summary and the fiscal year totals are also updated.
When the matching gift is processed, the matching gift row is written out. An index is created to link the gift matched to the matching gift. In addition, the claim associated with the donor gift for this organization ID number is deleted. If the gift matched was a pledge payment, then the matched amount in the primary pledge row is updated. In addition, the donor summaries and the fiscal year giving totals for both the organization and the donor matched are updated.
The batch reversal row in the batch is simply a pointer to all of the transactions that are being modified or reversed. It allows gift processing to determine how it will update the appropriate columns in the appropriate rows. The original receipt number element will still contain the receipt number of the gift being reversed.