Creating and reconciling pledges

Manually Added Pledges

These are pledges that are not generated by or connected to a form. They are created by going to a persons profile page, selecting the Finance tab, selecting Pledges - and Adding.

Pledges are reconciled via the Add A Transaction screen. (i.e. not a collective and not working from a bank (or Xero) imported record)

Once a persons name is selected, all available pledges are shown. If a date is entered, this date is used, otherwise todays date is used to filter the returned list. The pledge transactions that are shown will be 50 days prior through to 14 days after the supplied date. It will only show the items that are identified as Scheduled or Planning. If its paid or deleted then it won't be displayed.

The user is presented with the Match option.

Match

Selecting Match creates a transaction for the person specified, using the account code, campaign, tracking data, payment method from the pledge. It uses the amount and date from the specific recurring record to create the transaction.

The details of who to receipt (individual or organsation) is taken from the Reconcile screen.

The date of when to receipt (oneoff or combined) is also taken from the Reconcile screen.

Mark the chosen recurring record as paid on the date of the supplied transaction. It will be linked to the matching transaction.

Pledges added via a form

Pledges added by a form are processed in one of the following ways:

1. Using a Non-payment gateway payment method

• An email is sent to the user and the 'notify' people
• The form is not marked as paid
• No payment history is added to this form
• A pledge is created as described below. Note that there is no tracking data at this point, this is added at approval time.

2. A form entered - recur one time - for today

• A one off pledge is created for today and marked as 'scheduled'

3. A form entered - recur one time - for 1st of next month

• A one off pledge is created for 1st of next month and marked as 'planned'

4. A form entered - recur weekly - Today until 12 months time

• A weekly pledge is created, with repeating dates as per the schedule, and the first payment is today and marked as 'scheduled' and the subsequent ones marked as 'planned'.

5. A form entered - recur weekly - 1st of next month until 12 months time

• A weekly pledge is created, with repeating dates as per the scheduled, and the first and subsequent payments is marked as 'planned' dated 1st of next month onwards

6. Using a payment gateway (e.g. Stripe of ezidebit) that is able to process the payment directly

• An email is sent to the user and those added to the Notify field.
• The payment history has:

1. A Request when the user is taken to Stripe
2. A Token when the token is returned by Stripe

• A pledge is created as described below. Note that there is no tracking data at this point, this is added at approval time.

  a. A form entered - recur one time - for today

  • A one off pledge is created for today and marked as Scheduled
  • For Stripe, the form is shown as paid in full
  • ezidebit schedules payments, so this is shown as not paid in full
  • The payment history shows Paid for Stripe, Scheduled for ezidebit

  b. A form entered - recur one time - for 1st of next month

  • A one off pledge is created for 1st of next month and marked as Planned
  • The form is not shown as paid
  • Only request and token are shown in the payment history

  c. A form entered - recur weekly - Today until 12 months time

  • A weekly pledge is created for today and weekly for the year.
  • Todays payment is marked as Scheduled and subsequent ones marked as Planned
  • For Stripe payments the form is shown as paid in full
  • As ezidebit schedules payments, this is shown as not paid in full
  • The payment history shows Paid for Stripe, Scheduled for ezidebit

  d. A form entered - recur weekly - 1st of next month until 12 months time

  • A weekly pledge is created for 1st of next month and weekly for the year. The all payments are marked as Planned
  • The form is not shown as paid in full
  • Only request and token are shown in the payment history

Activities after a form is entered, and before it is approved

As recurring pledges have been created, the request for payments can continue despite the form not being approved.

Where infoodle can process the payment (Stripe, ezidebit, eway) - a record is added to the form payment history to state the transaction has been Scheduled

To stop payments being processed - delete the form

Transactions are not created at this point.

Adding a payment

On a form that is not identified as paid (because its not paid by Credit card), the user can add payment in the payment history. This only allows non-credit card payments (as the user shouldn't have access to their credit card authorisation).

This will record the action as a Manual Payment against the form and marks the form as paid.

This process will not create a transaction on the persons record - this has to be done through the reconcile, or add transaction, processes.

Editing a form before approval

Changing the amount, account code, tracking data can be done before the form is approved.

Once changed, select Save changes. This will reload the screen and the recurring payment field will show the new details. Review these details prior to approving the form as this is the data the form will use on the pledge that was created. This is the data that the transactions will use to create the transactions.

To stop payments being processed - delete the form.

Approving a form

Transactions will not be able to be created until the form has been approved. Once done, the Add Transaction or Reconcile processes can now 'see' the form and pledge data. It is these processes that create the transactions using the pledge data (account, amount etc.)

Approving a form is the process of selecting a contact to whom the payments are to be applied. The approval will do the following:

• Connect the emails sent, to the chosen contact. The visibility of the email is either the person approving the form, or the selected group.
• Connect the pledge to the chosen contact.

Once a form is approved

When looking at an approved form, the details are read only.

If the form is connected to a pledge, this is described in detail in the section above the Disconnect from user button.

Disconnecting a Form

If you have approved a form, and later discover it is against the wrong contact then you can select Disconnect. This will simply remove the link between the current contact and the form. The pledge and any created transactions will remain associated with the previous user.

If you subsequently re-approve the form to a new user, the entire pledge and associated pledge records are connected to the new contact. Any existing transactions are left associated with the previous contact.

Note that any other data changes (e.g. name, address, custom fields etc.) are not un-done.

Making changes to a pledge

• Stopping further payments being taken - delete the pledge from the persons finance/pledge screen
  
  
• Adjusting a one-off amount or date it is to be taken - edit the specific pledge amount on the persons finance/pledge screen
  
  
• Adjusting a pledge so that future payments will have different amounts, account codes, campaigns, tracking data - edit the pledge in the persons finance/pledge screen and set the 'effective date' to be when you want the new pledges to start being taken.

Creating transactions associated with pledges

When the money arrives in the bank you can record that payment. This will add a transaction to infoodle and connect the transaction to the pledge entry marking it as paid.

Getting a list of items to pay

When reconciling transactions imported from a bank statement, CSV file, or Xero (for example):

• when a persons name is selected, infoodle uses the Transaction date and the chosen name....

When adding transactions:

when a persons name is selected, infoodle uses the Date entered (if no date then all available options are used) and the name....
using the supplied data... infoodle will:

Get a list of unreconciled forms for the specified user. This means they have not been paid as yet. The date the form was processed must be before the date of the transaction. It can be as far back as needed

Get a list of recurring transactions that are not marked as paid or deleted, that occur from date-50days, to date+14days and the amount matches
'PAY' a form (from Add Transaction & Reconcile screen)

When a form is shown as being available to be 'paid' then the user is offered the button with 'pay'.

Clicking 'pay' will mark the form as paid, add a 'paid on reconcile' to the forms payment history.

If there is a pledge record, the first pledge record is marked as paid (matched).

The date of the transaction created is based on the date entered on the screen.

'MATCH' a pledge (from Add Transaction & Reconcile screen)

Once the form is marked as paid, then the next time a person is selected the form is excluded from the list and any recurring pledges are shown. This is filtered based on the persons name, amount and transaction date being date-50days, to date+14days.

Clicking 'match' will mark the transaction as paid (matched), add a 'paid on reconcile' to the forms payment history.

The date of the transaction created is based on the date entered on the screen.

Account code, campaign, tracking data is taken from the pledge.

Once a pledge item has been scheduled or paid, the date and amount of that pledge transaction cant be changed in the persons finance/pledge screen

Forms that have multiple amount fields (including stock) can and are paid, will create multiple transaction records in the persons profile - which allows for different tracking and account code data.

Forms that have multiple amount fields and have recurring, will create a single pledge record, therefore do not (currently) support split transactions.

Notes of changes:

As the user is completing the form:

a) If a recurring period of One Off is chosen, and the build screen has First payment date ticked, then the First payment date is shown (label changed to Payment date) so the user can choose when the one-off payment is taken.

b) The label text itself now has its own class for styling purposes - labeltxt

c) The notification email sent to the admin users now includes the Entry ID in the subject

d) recurring records are now created when the user saves the form (i.e. not at approval time)

After the form is completed, before it is approved:

a) the request for payment does not require a form to be approved in order to request payment

b) ** beta, not fully released ** an email is sent to the owner of the payment method (email address in payment methods) showing status of payments taken/or not

When reviewing the form for approval...
a) The first notify email, and the email sent to the user are connected to the form entry. This way when reviewing the form entry, the emails themselves can be reviewed.

b) When reviewing a form entry, the 'show entries' button is duplicated at the bottom of the screen

c) The 'recurring amount' field now describes in detail the pledge that is going to be created based on the form entries. Edit the form entries and 'save changes' to alter these values.

d) recurring stripe payments now record the charge succeed/fail against the form each time.

e) The date & time the form was created is shown at the top of the screen.

Reconciling transactions:

a) if the logged in user is in a cluster, the reconcile screen no longer enforces the need for a campaign when using a 'pay' function.

Also:

a) Stripe users only. On Administration/System/Payment methods - stripe - there is a new option 'Allow stripe to issue receipt email?'. This is 'Yes' by default. You can set it to 'No' here - in which case stripe will not issue an email when a charge is made to the account, you will need to manage any communication out of infoodle alone.