Introduction

This article looks at the process of using Importacular to import recurring gifts and their corresponding payments. The process is almost identical for pledges and pledge payments so we do not distinguish between them in this article. Unless otherwise highlighted the two are interchangeable in this document.


Terms Used

Raiser’s Edge does a poor job and distinguishing between a recurring gift template or schedule record and the payment record that is applied to it. The same can be said for a pledge and a pledge payment. The only distinguishing feature is that the gift type becomes “Pay-Cash” once applied to the RG or pledge.


For the sake of clarity, we refer to the recurring gift record which contains a schedule of how the donor will pay as “Recurring Gift template” or “RG template” for short.


We refer to the “Recurring Gift payment” record or “RG payment” as the application of a donation to the template.


These are not widely used in Raiser’s Edge but will hopefully make the process simpler to understand.


Process

It is not possible to import an RG template and an RG payment on the same Importacular mapping template.  The RG template needs to exist in RE before the payment can be applied to it.  Therefore, two separate mapping templates need to be created.


Creating the Recurring Gift Template Mapping (stage 1)

You can refer to this article for more information on Importing Recurring Gift or Instalment Schedules.


 

Creating the Recurring Gift Payment Mapping (stage 2)

Add a new mapping under Gift Mapping as you have done previously and map the fields based on how you wish the data to be imported. Example image below:



Depending on how you have set up your RG template, you may also want to map the reference field on your payment (See this article for more information).


Once you have saved the template, double click on the red button to configure the Area Settings for the Gift Mapping:


Gifts Tab



Select ‘a recurring gift’ and then choose from the dropdown which mechanism you want to match. The choices are:


First found – if there is just one active recurring gift on the constituent record this can be selected. If there are no active recurring gifts then the first inactive one will be selected.


If there is more than one active recurring gift per constituent record, there are other options:


Gift Attribute Description – When selecting this Importacular will attempt to match an incoming attribute description with the corresponding value on a constituent record. When selecting this option, you also need to select an attribute category from the second dropdown (as is seen in the example above)


Reference – Importacular will attempt to match a value mapped to the reference field with a value on the pledge or recurring gift reference field.


Reference Number – As with Reference, Importacular will attempt to match against the reference number field. Note that this field only appears for specific pay methods. The pay method of the incoming payment need not be the same. 


When processing payments, the data file does not always supply you with the fund, campaign and appeal. More often than not it will just be the date, amount and a unique identifier. You are able to select the values to be transferred from the RG template onto the payment. If you have ticked these boxes the they will overwrite the mapping.


Choose which of the following fields you want copied to the payment:


  • Fund
  • Campaign
  • Appeal
  • Package
  • GiftAid Qualification Method (UK version of RE).



Gift Matching Tab

The next tab asks whether you want to always import gifts regardless of whether a matching gift already exists. You can define your matching criteria here as well (eg. Date/Amount/Fund etc as seen below):



This is useful if you have a mixed batch of recurring gifts and regular gifts or if the recurring gift templates are in the same file as the payments. This way if the recurring gift template already exists on RE it will not be created again.



Recurring Gifts Tab


The third and final tab is where you can define how to handle exceptions.


If no match is found or if the amount is different, an exception can be generated.


There is also an editable field to specify the number of days difference which can be accepted (in the case where the transaction date is greater or less than the one specified). As alternative to raising an exception, you are able to skip the transaction so that the payment is applied to the correct date on the RG template.