Page Comparison

Manual payment scheduling per Batch via Developer Console

Manual Payment Scheduling

Step 0: Delete the existing payment schedule named “ASPP__ProcessingPayment” beforehand. To check, go to → Setup | Schedule Jobs

Step 1: From your user menu, click the Setup Gear icon and select Developer Console

Step 2: From your developer console, click Debug in the menu and select Open Execute Anonymous Window.

Step 3: A pop-up Enter Apex Code windowwill appear.  

A. Copy the script (below) and paste in to Enter Apex Code window. 

String schedule_time = '0 0 2 * * ? *';   

System.schedule('ASPP__ProcessingPayment', schedule_time, new ASPHPP.ScheduleBatchedProcessPayment()); 

Note: This is just a sample scheduling every 2AM. See other payment processing schedules below - “Other Payment Processing Schedules section” 

B. Click “Execute” button. 

...

Step 4: Confirm the created schedule in the Scheduled Jobs. Go to Setup | Schedule Jobs

Other Payment Processing Schedules 

A. Sample time schedules 

Change the value of the schedule_time variable to any preferred time schedule. 

Every hour = '0 0 * * * ?' ; 

Every midnight = '0 0 0 * * ?' ; 

Every 1 AM = ’0 0 1 * * ? * ‘ ;  

Every 2 AM = ’0 0 2 * * ? * ‘ ;  

Every 3 AM = ’0 0 3 * * ? * ‘ ;  
 

B. Time Schedule Formats 

Set your desired time schedule by following this format. 

second:        0 (this doesn't actually do anything) 

minute:        0–59 

hour:          0-23 

day_of_month:  1-31 - * ? / L W 

month:         1-12 JAN-DEC , - * / 

day_of_week:   1-7 SUN-SAT , - * ? / L # 

optional_year: null or 1970–2099 , - * / 

ProntoPayments Batches

Go to | ProntoPayments Settings | Scheduler

Parse Payment From ASPP_Logs (No) 

A chained process from Batch Payment Processing so this will be called internally every batch payment processing attempt. 

Batch Payment Processing (Yes) - Schedule for 9pm 

Default schedule is 9PM. 

Batch Get Payment Status (Yes) - Schedule for 9am 

This is for Ezidebit, Westpac and Paydock transactions only. This will update the statuses of those pending transactions based on the gateway response and opportunity stages. 

Batch Attach ProntoPayments Logs (Yes) - Schedule for 9pm 

This will create a backup for old ASPP Logs so that when Batch Delete ProntoPayments Logs is scheduled, we can still those records as csv file. 

Batch Send Email for Expired Cards (OPTIONAL - client preference) - Consider deprecation - replace with subscribing to report  

This will send an email notification to the running user. The email contains a list of payment sources records. Default schedule is 11PM. 

Batch Get Payments (OPTIONAL - client preference) 

Sync payments from gateway to salesforce. Below are the supported gateways. 

1. Paydock 

2. Ezidebit 

3. eWAy 

4. Paypal Rest 

5. PIN 

6. Stripe 

7. DebitSuccess 

Batch Get Tokens (OPTIONAL - client preference) 

Sync tokens (as payment sources) from gateway to salesforce. 

Batch Inactive Expired Payment Source (OPTIONAL - client preference) 

All expired payment sources, both tokenisation-credit card and credit card, will be updated to inactive ONLY if expiry date is not empty.

Batch Get Subscriptions (OPTIONAL - client preference) 

Sync subscriptions from gateway to salesforce. 

Batch Create Subscription PPayment (OPTIONAL - client preference) 

Will retrieve transactions from the gateway only if subscription is processed on the gateway (not on salesforce). 

Batch Payment Status Update (No) 

A chained process from Batch Payment Processing so this will be called internally every batch payment processing attempt.

Sandbox Clean up Batch (No) 

Necessary when a sandbox have live data. 

Get Payment Transaction Settlement  

This batch will update transactions where gateway is either BPOINT or Ezidebit. This will retrieve settlement dates from the gateway (when available).

ProntoGiving 

Go to ProntoGiving Settings | Schedule Process | Settings

BDE Item processing will only process standard objects; custom objects are not supported.

ProntoGiving - Other Batches 

Description: 

ASPHPPADDON__Donation_Page_Error_Log__c records are created if errors are encountered in Donation Page/Forms i.e. Contact, Account or Payment Source could not be created due to validations errors 

Opportunity/RD records needs to be created in SF even if some records could not be created to capture the donation attempt and take action to complete the donation process 

Query Criteria: 

• All ASPHPPADDON__Donation_Page_Error_Log__c with lookup to Opportunities that are Closed/Won with CreatedDate <: LAST_N_DAYS (settings) 

What the batch does, for all retrieved ASPHPPADDON__Donation_Page_Error_Log__c records:

Remove these records because they’re no longer significant, donations are already Closed Won 

Process BDE Items - Yes - 6pm?. Setting should Exclude items linked to BDE 

Query Criteria: 

All ASPHPPADDON__BDE_Item__c with ASPHPPADDON__Processing_Status__c = ‘Pending Processing’ 

If PRONTOGIVING_SETTINGS.Include_BDE_Items_linked_to_a_BDE__c is TRUE, all BDE Items 

If PRONTOGIVING_SETTINGS.Include_BDE_Items_linked_to_a_BDE__c is FALSE, exclude BDE Items linked to a Batch Donation Entry 

What the batch does, for all retrieved ASPHPPADDON__BDE_Item__c records: Process these records, just like processing BDE Items via list view. 

Recurring Donations – ProntoGiving

Recurring Donations Monitoring  

Batch Class Name: BatchUpdateRecurringFields 

Schedule Time: Every Hour 

Query Criteria: 

• All non-closed RDs with Exclude RD Monitoring == FALSE 

What the batch does, for all retrieved RD records: updates 

• Overdue Installments - how many related opportunities on that recurring donation with Close Date <= TODAY that are still

Pledged/Open that should have been Closed Won 

• Total Overdue Amount - how much of the related opportunities on that recurring donation with Close Date <= TODAY that are still

Pledged/Open that should have been Closed Won 

• Total Missed Payments - how many related

Closed Lost opportunities on that recurring donation with Close Date <= TODAY that should have been Closed Won

• Status to Overdue

o   sorts the related opportunities on that recurring donation with Close Date <= TODAY in ASC

o   if the last opportunity is Closed Lost, status is updated to Overdue 

• Status to Active

o   sorts the related opportunities on that recurring donation with Close Date <= TODAY in ASC 

o   if the last opportunity is Closed Won, status is updated to Active 

o   if the Status is Cancelled or On Pause, RD is not updated to Active 

• First Donation Date - Close Date of the first Closed Won opportunity 

Update Number Of Failed Recurring Donations 

Batch Class Name: BatchUpdateNumberOfFailedRD 

Schedule Time: Every Midnight 

Query Criteria: 

· All non-closed RDs 

· All closed RDs but with Exclude_in_Updating_Number_of_Failed_Rec__c == FALSE 

What the batch does, for all retrieved RD records: 

· Number of Failed Recurring Donations 

o  Counts the number of (latest) consecutive closed lost opportunities 

o  If latest stage name is Closed Won, value is 0 

· If Open-Ended Status is Closed, Exclude_in_Updating_Number_of_Failed_Rec__c is set to TRUE

Close Open Recurring Donations with Contact Flagged as Deceased 

Batch Class Name: BatchCloseOpenRDWithDeceasedContact 

Schedule Time: Every Midnight 

Query Criteria: 

· All non-closed RDs with Contact npsp__Deceased__c == TRUE 

What the batch does, for all retrieved RD records: 

· Open-Ended Status = Closed 

· Status = Cancelled

Total Recurring Donations - Last Financial Year 

Accessible in: 

· ProntoGiving Settings > Consolidated Statement Settings > Calculate Recurring Donations in the Last Financial Year 

Batch Class Name: BatchTotalRecurringDonationsFY 

Query Criteria: 

· Closed Won opportunities linked to RD with Close Date within last Financial Year 

What the batch does, for all retrieved RD records: 

· Contact record: Total_Recurring_Gifts_Last_FY__c (amount) 

· Account record: Total_Recurring_Gifts_Last_FY__c (amount) 

Lock/Unlock Recurring Donations Payment Processing

Accessible in: 

· ProntoGiving Settings > Recurring Donation Settings > Lock Recurring Donations Payment Processing (toggle) 

Batch Class Name: BatchLockUnlockPaymentProcessing 

Query Criteria: 

· All opportunities linked to RD 

What the batch does, for all retrieved RD records: 

· If action is to lock, 

o  set log record on the opportunity as PGIV_Lock_Payment_Processing__c → TRUE 

o  set log record on the opportunity as ASPHPP__Lock_Opportunity__c → TRUE 

· If action is to unlock, 

o  set log record on the opportunity as PGIV_Lock_Payment_Processing__c → FALSE 

o  set log record on the opportunity as ASPHPP__Lock_Opportunity__c → FALSE 

Number of Fails before Cancelling Recurring Donation

· Based on “Number of Failed Recurring Donations” field on RD record, if the field matches the set limit in ProntoGiving Settings, RD Status is updated to “Cancelled”, thus Open-Ended Status is updated to “Closed”
 

Batch Re-active RDs (not RD Monitoring Batch)

WHERE Status__c =: RD_STATUS_PAUSE AND npe03__Next_Payment_Date__c = LAST_N_DAYS 

LAST_N_DAYS -> 30 days

IE: updates donation back to active 30 days prior to next donation date.

ProntoPlus

Go to ProntoPlus Settings | Schedule Processes