Note: The CMS Widget - Payment Schedule on the same page lists the installments of the invoice created from this summary.

Note: To show families the installments behind the deposit-only choice, add the CMS Widget - Payment Schedule to the same page. It switches between one payment today and the payment plan as the family changes the selection.

PCR Educator now shows families their full payment schedule on course registration checkout pages, before they enter a card. The Payment Schedule widget that lists installments on Application Forms works on registration pages as well, so a family choosing a quarterly or monthly plan sees the amount due today and every date and amount that follows.

What's new

Schedule at checkout. Add the Payment Schedule widget to any registration payment page that carries the Sign up Summary and Summer Submit widgets. It reads the cart total and the Payment Term configured on Summer Submit and lists each installment with its due date.

Same numbers as the invoice. The widget expands the payment term through the same schedule calculation the invoice uses, dated with the same Invoice For Date. Installments that are already due appear as Today. What the page shows and what PCR Educator bills are the same figures.

Follows the family's choice. When the Deposit widget offers Pay in Full and Pay Later, the schedule switches with the family's selection: one payment today, or the installment plan, with no page reload.

Installments as percentages. Turn on Show Percent to add a column with each installment's share of the total, on registration pages and on Application Forms alike.

One widget, both places. Application Form pages keep the schedule they have today, sectioned by ledger and printed on the contract PDF. Registration pages get the same table with the same settings.

Why it matters

A family committing a card to a payment plan expects to see what will be charged and when. Schools that collect the first installment overnight, rather than at submit, can now state the plan on the page instead of in a paragraph of text, and the schedule the family reads is the schedule the invoice carries. Fewer "what will I be charged" questions reach the office, and the parent portal statement matches what the family saw at checkout.

A few ways to talk about it

• The payment plan is on the checkout page, with dates and amounts, before the card goes in.
• The schedule comes from the invoice's own payment term, so the page and the bill agree.
• One Payment Schedule widget serves contracts and registrations.

Available now to all PCR Educator schools. Your account team can walk you through adding the widget to your registration pages whenever you're ready.

The Payment Schedule CMS widget lists every payment a family will make, with the due date and amount of each installment. The Payment Schedule widget is found under the Payments option. It is read-only and never changes what is collected at submit.

The widget works in two places.

On an Application Form page, the schedule comes from the contract: the deposit due at signing plus the balance spread across the payment term of each invoice template, sectioned by ledger when a contract bills through more than one book. The same table prints on the contract PDF.

On a registration payment page, the schedule is the invoice that the CMS Widget - Summer Submit widget will post: the total from the CMS Widget - Sign up Summary widget, expanded through the Payment Term configured on Summer Submit and dated with its Invoice For Date. Installments that are already due appear as Today. When a CMS Widget - Deposit widget is on the page, the schedule follows the family's choice: Pay in Full shows one payment today, and Pay Later shows the installment plan.

Show Percent adds a column with each installment's share of the total.

Visibility Source and Visibility Value show the widget only when the referenced drop down or checkbox holds the given value.

Note: On a registration page the widget requires the Sign up Summary and Summer Submit widgets on the same page and a Payment Term on Summer Submit. It hides itself when the cart is empty, when Summer Submit is used for the Online Store, or when the Deposit widget specifies a Pay Deposit Only Product or Deposit Only Fee Product. Support for those configurations will follow.

Note: The schedule is calculated by the same payment term function the invoice uses, so the table matches the invoice that appears in the parent portal after submission.

The Summer Submit CMS widget completes a course registration. At submission it enrolls each selected student in the courses chosen, creates the invoices for the registration, collects the payment, and sends the confirmation. The Summer Submit widget is found under the Registration option.

The widget is used together with CMS Widget - Sign up Summary, which lists the courses and fees being registered, and normally with CMS Widget - Deposit and a payment widget such as CMS Widget - Credit Card Payment. One Summer Submit widget is placed on a page.

Autopost Invoice posts the invoices created at submission. Note: A convenience fee invoice is posted on its own when the payment configuration used specifies that convenience fees are posted automatically, whether or not this setting is enabled.

Customer Memo is the memo recorded on the invoices created at submission. It is visible to the family.

Default AR Account is the accounts receivable account used for the invoices. Note: The account is matched to the ledger of the invoice line items.

Default Classification is the classification recorded on the invoice items. Note: When the payment configuration used for the payment specifies a classification, that classification is recorded instead.

Deposit Payment Term is the payment term applied to the separate deposit invoice. Note: When it is not specified, the deposit invoice uses Payment Term.

Internal Memo is the memo recorded on the invoices for staff. It is not shown to the family.

Inventory Error Message is the message shown when the inventory of a selected product cannot be reserved at submission. Note: When it is empty, a general message is shown. In both cases the registration is not submitted.

Invoice Attribute specifies an attribute and comment recorded on each invoice created at submission.

Invoice For Date is the date of the invoices and their items. Note: The date is used only while it is in the future. On or after that date, the invoices are dated the day of submission.

Invoice Thank You Email is the notification template sent for each invoice created at submission.

Navigation Menu specifies the navigation menu of the registration pages. When it is specified, submission produces a PDF of the registration and the family is taken to it before the thank you page.

Payment Configuration Credit Card and Payment Configuration Echeck specify the automatic payment configurations used to process a credit card or eCheck payment. Note: The ledger of the receipt comes from the configuration used.

Payment Term is the payment term applied to the invoices created at submission. It determines the due date and the amount of each installment the school bills. Note: CMS Widget - Payment Schedule lists those installments for the family before the payment is entered.

Pdf File Prefix is the title of the archived registration PDF. When it is empty the title is Summer.

Process In Test Mode sends the payment to the gateway in test mode so that no funds are captured. Note: Turn this setting off before the page is opened to families.

Receipt Invoice Number is the text recorded as the invoice number on the receipt. When it is empty the purchase type is recorded.

Require Payment determines whether a payment is collected at submission. When it is No, the registration is submitted and invoiced with no payment taken.

Save Profile determines when the payment information is saved for future automatic payments. Always saves it at every submission. Deposit Only saves it when the family pays a deposit rather than the full amount. Invoice With Outstanding Balance Only saves it when a balance remains after submission. Note: The payment information is saved only when the payment configuration used specifies a vault.

Submit Action Type is the action recorded on each student registered. Note: The action is recorded for the student's selected academic year.

Thank You Email is the notification template sent when a payment is taken. It is based on the receipt.

Thank You Email No Payment is the notification template sent when no payment is taken. It is based on the household.

Thank You Page Location is the page the family is taken to after submission.

PCR Educator now lets schools group discounts and tell the system that only one discount in the group may apply to a purchase. Tiered pricing such as one-week, two-week, three-week, and four-week rates can be entered at face value, in one place, and the highest tier a family qualifies for is the one they receive. Percentage scholarships and sibling discounts outside the group continue to stack on top.

What's new

Product Groups. A new setup page under Finance > Products holds named groups of products. Each group has a behavior. The first behavior, Exclusive, applies only the first qualifying discount in the group and skips the rest.

Order decides the winner. Discounts in a group are ranked by an order you set on the group's Products tab. Put the four-week rate first, the three-week rate second, and so on. A family registering for three weeks receives the three-week discount and nothing lower.

Groups compose with everything else. A discount outside the group, such as a percentage scholarship tied to a student attribute or a per-family sibling discount, stacks on the group's winner exactly as it does today.

Membership from the Products list. Select products, choose the Multi Action "Add Products to Product Group," and pick the group. Each discount's Discount tab shows which groups it belongs to.

Built for more than tiers. Early-bird and regular pricing with different expiration dates can share a group ordered early-bird first, so the better rate wins while it is open and the standard rate takes over afterward.

Why it matters

Summer programs, intensives, and camps price by the week, and families often qualify for several rates at once. With Product Groups the business office enters each rate as a true amount, keeps scholarships stackable, and lets the system choose the single correct tier for every cart. Setup reads the way the price sheet reads.

A few ways to talk about it

• Enter tier prices at face value. One group, one winner, no arithmetic on the back of an envelope.
• Scholarships and sibling discounts still stack on top. Only the tiers compete.
• Order the group the way the price sheet reads, and registration follows it.

Available now to all PCR Educator schools. Your account team can walk you through setting up a tiered discount group whenever you're ready.

The CMS Widget - Actions records a student action from a portal page and, when configured, collects typed attribute values alongside it. The widget can be found within the Student Details group. Please review Adding CMS Widget for more information. To limit the visibility of this widget, review CMS - Conditional Logic.

Action Types determines which student actions the page may record. When a single action type is selected, the type selector is hidden and every entry is recorded as that action.

Attributes determines which student action attributes are collected with the action. Each selected attribute renders the input that its data type calls for, so an Integer attribute is entered as a number, a Date attribute through a calendar, a Boolean attribute as a checkbox, and an attribute driven by a lookup list as a drop-down. Attributes are defined in Campus under Administrator, Maintenance, Student Action Attributes, and they appear in the order set on that page. Note: the list below the entry form carries an Attributes column that stays hidden until it is enabled through Columns.

Add Confirmation Email sends an email when an action is recorded. The emails are configured in Admin, Students, Email screen.

Delete Access Type controls who may remove a recorded action. Access Restricted To Modifier allows a user to remove only the entries that the same user recorded. Full Access allows any entry to be removed. No Access hides the delete option.

Hide Comment removes the comment box from the entry form.

Hide Date removes the date field. The action is then dated with the current date.

Hide File removes the file upload from the entry form.

Is Edit Disabled renders the widget as a read only list, with no entry form.

Is File Upload Required requires a file before the action may be saved.

School Division limits the widget to a single division.

Year determines which academic year the recorded action belongs to.

Example: a school that collects community service hours defines Activity, Hours and Description as student action attributes, then places this widget on a portal page with Action Types set to the service action and those three attributes selected. A student records each activity through the year, and the hours report in the Data Analytics Tool as their own value rather than as text inside a comment.

The CMS Widget - Button is a button that saves the CMS Page it is placed on and then sends the user to another page. It can also be configured to send the user to another page without saving. The widget can be found within the Content group. Please review Adding CMS Widget for more information.

Note: The button hides itself on a CMS Page that already holds a submit widget, such as CMS Widget - Inquiry Submit, so that only one control on a page saves the page and moves the user forward.

Label is the text shown on the button.

Behavior determines what the button does when the user clicks it.

- Save With Redirect Link saves the page and sends the user to the Save Redirect Page.
- Save And Next saves the page and sends the user to the next page in the Navigation Source menu.
- Save And Next Incomplete saves the page and sends the user to the next page in the Navigation Source menu that the user has not completed yet.
- Save And Previous saves the page and sends the user to the previous page in the Navigation Source menu.
- Redirect does not save the page. The widget renders as a link to the Save Redirect Page. Note: This option opens the page in a new browser tab.

Navigation Source is the CMS Widget - Menu whose pages the button moves through. It is required for the Save And Next, Save And Next Incomplete, and Save And Previous behaviors. Note: When the menu tracks completion and there is no further page to move to, the button hides itself.

Save Redirect Page is the CMS Page the user is sent to by the Save With Redirect Link and Redirect behaviors.

Forward Return Url carries the return address held by the current page over to the Save Redirect Page, so that the page being opened can send the user back to where they originally started. Note: A page holds a return address when the user was sent to it from a page that requires login. Use this setting on a button that offers account creation from a login page, together with Redirect To Return Url on the CMS Widget - Inquiry Submit, so that a user who creates an account lands back on the page they were trying to reach.

Skip Saving sends the user to the next page without saving any of the widgets on the current page.

Allow Saving With Missing Requirements saves the page even when required fields have been left empty.

Enabled determines whether the user can click the button.

Start With New Line places the button on its own line instead of alongside the control before it.

The CMS Widget - Shopping Cart Summary lists the products a user has placed in their cart, totals the order, and gives the user a way to keep shopping or to check out. The widget can be found within the Online Store group. Please review Adding CMS Widget for more information.

Ledger determines which ledger the cart belongs to. Only products that belong to this ledger appear in the summary.

Columns determines which columns appear in the cart, the heading shown for each one, and the screen size below which each one is hidden.

Product Detail Page is the CMS Page the user is sent to when they click a product in the cart.

Check Out Page is the CMS Page the user is sent to when they click Check Out. Note: The Check Out button is hidden while this setting is empty.

Continue Shopping Page is the CMS Page the user is sent to when they click Continue Shopping. Note: The Continue Shopping button is hidden while this setting is empty.

Preserve Selection sends a user who is not signed in to the login page of the Check Out Page when they click Check Out, and returns them to the page they were viewing once they sign in or create an account. Note: The login page is taken from the Unauthenticated Url of the Check Out Page, so that page must have one. Review CMS Page Details for the Unauthenticated Url setting. Without this setting the user is sent to the check out page first, is asked to sign in there, and arrives back at check out with an empty cart. To let a user create an account and still return to the product they were viewing, also set Forward Return Url on the CMS Widget - Button that offers account creation, and Redirect To Return Url on the CMS Widget - Inquiry Submit that creates it.

Max Quantity is the highest quantity a user can select for a product in the cart.

Empty Cart Text is the message shown when there is nothing in the cart.

Enhanced Description shows the product name as a heading that links to the Product Detail Page, instead of as plain text.

Ignore Inventory lets a user keep products in the cart that are no longer in stock. Note: When this setting is No, the cart warns the user and blocks check out for a product whose stock has run out since it was added to the cart.

Show Available Balance applies the balance the family already carries to the order total. Choose Household to use the household balance, or Student to use the student balance. Note: A credit reduces the order total and is shown as Available Balance. An amount the family still owes is added to the order total and is shown as Additional Balance Due.

Show Coupon Code shows a field where the user can enter a promotion code.

Add Promotion Code Text is the label shown above the promotion code field.

Shipping Fee Product is the product used to charge shipping on the order. The price of that product is charged once per order. Note: Shipping is not charged when the user selects Pickup as the delivery method.

Sale Tax Product is the product whose price is used as the sales tax rate for the order. Note: The price is the rate itself, so a product priced at 0.06 charges six percent.

Tax On Shipping Enabled includes the shipping fee in the amount that sales tax is calculated on.

Convenience Fee Label is the label shown for the convenience fee on the order total. Note: When this setting is empty, the label reads Convenience Fee.

The CMS Widget - Added to Cart confirms the product a user has just placed in their cart and gives the user a way to check out. The widget can be found within the Online Store group. Please review Adding CMS Widget for more information.

Note: The widget stays hidden until the user adds a product to the cart, so a page built around it shows nothing on a first visit.

Ledger determines which ledger the cart belongs to. Only products that belong to this ledger are counted.

Product Detail Page is the CMS Page the user is sent to when they click the product.

Check Out Page is the CMS Page the user is sent to when they click Check Out. Note: The Check Out button is hidden while this setting is empty.

Preserve Selection sends a user who is not signed in to the login page of the Check Out Page when they click Check Out, and returns them to the page they were viewing once they sign in or create an account. Note: The login page is taken from the Unauthenticated Url of the Check Out Page, so that page must have one. Review CMS Page Details for the Unauthenticated Url setting. Without this setting the user is sent to the check out page first, is asked to sign in there, and arrives back at check out with an empty cart.

The CMS Widget - Product Inventory lists the products a school offers for sale as a grid of tiles. Each tile represents a product category and shows its image, its name, and the price or price range of the products inside it. Selecting a tile opens the product. The widget can be found within the Online Store group. Please review Adding CMS Widget for more information.

The widget is normally used together with CMS Widget - Product Inventory Filter, which narrows the list, and the page it opens carries CMS Widget - Product Selector. One Product Inventory widget is placed on a page.

Ledger determines which ledger the products are drawn from. Only products that belong to this ledger are listed.

Product Category Attributes limits the list to the product categories carrying the attributes selected here. Note: When nothing is selected, every product category in the ledger is listed. Review Product Category for setting up categories and their attributes.

Product Detail Page is the CMS Page a tile opens. The product is carried across to that page, so the page opens on the tile the user selected. Note: When this setting is empty the tiles are not clickable.

No Results Text is the message shown when no product matches the current filter. Note: When this setting is empty the message reads No data was returned.

The CMS Widget - Product Inventory Filter shows the product attributes as filter options so that a user can narrow the list of products. The options are grouped by attribute category, and selecting one reloads the page showing only the products that carry it. The widget can be found within the Online Store group. Please review Adding CMS Widget for more information.

The widget is placed on the same CMS Page as CMS Widget - Product Inventory, which is the list it filters. One Product Inventory Filter widget is placed on a page.

Ledger determines which ledger the products are drawn from. The filter offers only the attributes carried by products in this ledger.

Product Attributes limits the filter to the attributes selected here. Note: When nothing is selected, every attribute carried by the products in the ledger is offered.

Filter By Text is the heading shown above the filter options.

Min Number Of Options For Dropdown is the number of options at which an attribute category is shown as a dropdown instead of a list of checkboxes. A category offering fewer options than this stays a list of checkboxes. Note: When this setting is zero or empty, every category is shown as checkboxes. The dropdown carries an Any entry at the top so that the user can clear that category.

The CMS Widget - Product Selector is the buying panel on a product page. It shows the price, offers the attributes the buyer chooses between, such as size or age group, offers the date when the product is sold by date, and adds the product to the cart. The widget can be found within the Online Store group. Please review Adding CMS Widget for more information.

The widget is placed on the CMS Page opened by CMS Widget - Product Inventory, normally alongside CMS Widget - Product Preview and CMS Widget - Product Description. One Product Selector widget is placed on a page.

Note: When the product is set up with a student or applicant filter, the widget first asks which child the purchase is for, and the Add to Cart button stays hidden until one is chosen. When the product is sold by date, the widget shows the available dates with the number of seats left on each.

Ledger determines which ledger the product is drawn from.

Add To Cart Redirect Page is the CMS Page the user is sent to after adding the product to the cart. Note: When this setting is empty the user stays on the product page, which lets the buyer keep adding without leaving the page.

Max Quantity is the highest quantity the user can add at once. Note: The quantity offered is also limited by the stock on hand, so the user is never offered more than is available.

Out Of Stock Text is the message shown in place of the Add to Cart button when the product has no stock left.

Auto Select Single Option Attributes hides an attribute category that offers only one option across the whole product family and selects that option automatically, so that the buyer is shown only the attributes that actually vary. Note: Turn this setting off to show every attribute category, including those with a single option. A category whose single option is missing from some of the products is always shown, because it remains a real choice.

The CMS Widget - Product Description shows the description of the product the user is viewing, as it was entered on the product record. The widget can be found within the Online Store group. Please review Adding CMS Widget for more information.

The widget is placed on the CMS Page opened by CMS Widget - Product Inventory, alongside CMS Widget - Product Selector. One Product Description widget is placed on a page. It has no settings of its own beyond the standard widget properties. Review Product for entering the description that this widget shows.

Note: The widget shows nothing when the attributes the user has chosen do not resolve to a single product, so that a description is never shown against the wrong product.

The CMS Widget - Product Preview shows the images of the product the user is viewing. The first image is shown at full size and the rest are shown as thumbnails beneath it. Selecting a thumbnail replaces the full size image. The widget can be found within the Online Store group. Please review Adding CMS Widget for more information.

The widget is placed on the CMS Page opened by CMS Widget - Product Inventory, alongside CMS Widget - Product Selector. One Product Preview widget is placed on a page. It has no settings of its own beyond the standard widget properties. Review Product for uploading the images that this widget shows.

Note: A placeholder image is shown when the product has no images uploaded.

The CMS Widget - Delivery lets the buyer say whether the order is collected or shipped, and collects the shipping address when it is shipped. The widget can be found within the Online Store group. Please review Adding CMS Widget for more information.

The widget is placed on the check out page alongside CMS Widget - Shopping Cart Summary, which it tells whether to charge the shipping fee. One Delivery widget is placed on a page.

Show Delivery Method Selector shows the Pickup and Shipping choice to the buyer. Note: When this setting is off the buyer is not asked, and the order uses Default Delivery Method. The choice is also hidden when the cart holds nothing for the ledger of the cart summary.

Default Delivery Method is the method selected when the page opens, and the method used for the order when the choice is not shown. Note: The address fields appear only for Shipping. Choosing Pickup removes the shipping fee from the order total.

The CMS Widget - Online Store Submit completes an online store purchase. At submission it creates the invoice for the order, collects the payment, and sends the receipt. The widget can be found within the Online Store group. Please review Adding CMS Widget for more information.

The widget is placed on the check out page together with CMS Widget - Shopping Cart Summary, which lists the order, normally with CMS Widget - Delivery and a payment widget such as CMS Widget - Credit Card Payment. One Online Store Submit widget is placed on a page.

Autopost Invoice posts the invoice created at submission. Note: A convenience fee invoice is posted on its own when the payment configuration used specifies that convenience fees are posted automatically, whether or not this setting is enabled.

Convenience Fee determines how the convenience fee is recorded. Invoice records it as an invoice of its own. Line Item adds it to the order invoice as another line. Note: The fee itself is set up on the payment configuration, not here. Review Auto-Pay Configuration (Finance) for configuring it.

Customer Memo is the memo recorded on the invoice created at submission. It is visible to the family.

Default AR Account is the accounts receivable account used for the invoice. Note: The account is matched to the ledger of the invoice line items.

Internal Memo is the memo recorded on the invoice for staff. It is not shown to the family.

Invoice Attribute specifies an attribute and comment recorded on the invoice created at submission.

Invoice Thank You Email is the notification template sent for the invoice created at submission.

Payment Configuration Credit Card and Payment Configuration Echeck specify the automatic payment configurations used to process a credit card or eCheck payment. Note: The ledger of the receipt comes from the configuration used.

Payment Term is the payment term applied to the invoice created at submission. It determines the due date and the amount of each installment the school bills.

Process In Test Mode sends the payment to the gateway in test mode so that no funds are captured. Note: Turn this setting off before the page is opened to families.

Receipt Invoice Number is the text recorded as the invoice number on the receipt. When it is empty the purchase type is recorded.

Thank You Page Location is the page the family is taken to after submission.

Student actions now carry structured fields. A student action can hold a number, a date, a checkbox, a link, or a value picked from a list, and each of those fields reports as its own column.

Student Action Attribute is a named field attached to a student action rather than to the student record. The attribute is defined once for the school and then recorded on individual actions, in the same way attributes already work for students, households, inquiries and staff.

Defining attributes

Requires the Admin Full role.

• Navigate to Administrator > Maintenance > Student Action Attributes.
• Enter a name under Category and click Add Category. A category groups related fields, for example Service Hours or Athletics.
• Select the category, enter a name under Attribute, and click Add Attribute.
• Set the Data Type. The choices are Text, Integer, Date, Boolean and Hyperlink.
• For a Text attribute, set a Lookup Type when the value should come from a list rather than free typing.
• Click Reorder Attribtues to drag the fields into the order staff and students should see them.

Note: attributes are defined for the school as a whole and are available on any student action. Limit which fields appear on a portal page through the widget settings described below.

Recording attributes in Campus

Requires the Actions Read role to view and the Actions Full role to edit.

• Open the student and go to Actions.
• Click Attributes on the action row.
• Choose the category and the attribute, enter the value, and click Add New.

Collecting attributes in the portal

• Add the Actions widget to a page from the Student Details group.
• Set Action Types to the action the page collects.
• Set Attributes to the fields the page should collect. The widget renders each one with the input its data type calls for, so an Integer attribute gets a number box and a Date attribute gets a calendar.
• To show recorded values in the list underneath, enable the Attributes column under Columns.

Values entered by a student save with the action in a single step.

Reporting

Student action attributes are available in the Data Analytics Tool as Student Action Attributes, joined to Actions and to the attribute definitions. Each attribute reports as its own value, and the comment field is free to hold narrative again.

Examples

Example: a school that requires community service defines a Service Hours category with Activity as Text, Hours as Integer and Description as Text. Students record each activity through the portal across the year. The registrar reports total hours by student, by grade level and by year, and produces a transfer letter listing every activity with its hours.

Example: an athletics department defines Sport and Season as Text attributes driven by lookup lists, and Varsity as Boolean. Participation reports then group cleanly by sport and season.

Example: a counselor defines Follow Up Date as Date and Referral Made as Boolean on a counseling action, and pulls a list of students whose follow-up date has passed.

Attribute Module is the type of record that an attribute can be attached to. An attribute is one mechanism reused across the system rather than a feature of any single record, so the same category and attribute definitions, the same data types, and the same way of recording a value apply whether the attribute sits on a student, a household, a donation or an action.

Every module works the same way. An administrator defines a Category and then the Attributes inside it, each with a Data Type of Text, Integer, Date, Boolean or Hyperlink, and optionally a Lookup Type so the value is chosen from a list. A user then records a value on an individual record. Please review Attribute, Attribute Category, Creating Attribute and Recording Attribute - Individual for the shared steps.

The order fields appear in follows the category order first and the attribute order inside it, both set with the Reorder buttons on the setup page.

Where attributes are defined

Note: attributes for inquiries, inquiry actions and event categories are defined from Admissions, Administrative Settings.

Where attributes are recorded

Attributes on an action

An action is a record in its own right, so it carries attributes the same way a student does. The difference is what the value describes: an attribute on a student describes the student and holds one value at a time, while an attribute on an action describes that one event, so a student may hold as many values as there are actions. A school recording community service enters the activity, the hours and a description on each action rather than on the student. Please review Student Action for the fields an action carries, and CMS Widget - Actions for collecting the values through a portal page.

Note: attributes are defined for the school as a whole and are offered on every action. A portal page limits which of them a student sees through the widget settings.

Schools can now pause a family's stored payment so PCR Educator stops charging it automatically, and resume it when the family is ready. The nightly automatic payment run, account top-ups and recurring pledge payments all skip a paused stored payment, whichever payment processor the school uses.

Key capabilities

Pause and resume from Campus. A Pause action sits on each stored payment in the customer's Auto-Pay information. The status and the reason appear alongside it, so anyone looking at the account can see why automatic payments stopped and who stopped them.

Optional self-service for families. Schools that want families to manage this themselves can turn on a Pause option in the parent portal. It stays off until the school enables it, because many schools prefer that conversation to go through the office.

Automatic pause after a returned payment. For schools processing through Authorize.net, a returned eCheck pauses the family's stored payment on its own, so an account that has already failed is not charged again.

A pause never blocks a family who wants to pay. Automatic charging stops, while the family can still choose that stored payment and pay whenever they like.

A hold stays until it is lifted. A pause set by a person remains in place even if the family updates their card or bank details, and only an explicit resume restores automatic payments. A pause that followed a returned payment still clears when the family saves new payment information, because that is the fix for it.

Why it matters

A family between jobs, a disputed charge, a payment plan under review: each is a reason to stop charging one account for a while. Pausing holds the arrangement in place, keeps the reason on the record, and leaves the family's enrollment and stored payment intact for when they are ready to resume. The automatic payment run also reports who was skipped and why, so a paused family is explained rather than a quiet gap in the run.

A few ways to talk about it

• Pause one family's automatic payments without deleting their stored payment or their enrollment.
• Honored wherever PCR Educator charges automatically, whatever the payment processor.
• Families can manage it themselves when the school turns that option on.

Available now to all PCR Educator schools. Your account team can walk you through the settings whenever you're ready.

1. Void Count and Net Deposit Columns: The deposit list now includes two new columns:
   • Void Count: Displays the number of voided receipts associated with the deposit.
   • Net Deposit: Shows the net amount of the deposit after accounting for voided receipts.
2. Associated Voids Dashboard Element: You can include an Associated Voids dashboard element to view voided receipts linked to the deposit. This element provides a clear and organized view of all voided receipts, enhancing transparency and ease of tracking.

1. Void a Receipt:
   
   • If a receipt needs to be voided, follow the standard procedure to void the receipt.
   • Note: This functionality applies to auto-pay receipts created since the 6/18 release.
2. Associate with a Deposit:
   
   • Once a receipt is voided, it can be associated with a deposit on the date of the void, provided it is for the same payment processor.
   • This ensures that the voided receipt is accurately reflected in the deposit records.
3. Review Deposits:
   • Navigate to the deposit list to review the updated columns:
     
     • Void Count: Verify the number of voided receipts for each deposit.
     • Net Deposit: Check the net deposit amount after void adjustments.
   • Add the Associated Voids dashboard element to your view. This will display all voided receipts connected to the deposit, making it easier to manage and reconcile your records.

When NSF Automation is turned on for an auto-pay configuration, PCR Educator creates this void deposit association for you as soon as it detects a returned payment, so the steps above are already done. See Configuring Settlement and Return Handling.

Roles required: FinanceAR Full or FinanceAR Read. This is the same access already needed to view customer receipts, so no additional role is needed for the gateway information described here.

Gateway Status is the record of what your payment processor did with a customer payment after the payment was accepted. A card or eCheck payment that succeeds at the moment of charge has not yet reached your bank. It settles in a batch later, and an eCheck can still be returned by the account holder's bank days after that. Gateway Status follows each payment through those stages and records the result on the receipt.

PCR Educator records Gateway Status for payments processed through Authorize.net and Stripe. For Authorize.net, a nightly process reads settlement results back from the processor. For Stripe, the processor notifies PCR Educator when a payment fails after acceptance.

Statuses

Pending. The payment was accepted by the processor and has not settled yet. Card payments normally settle the same night. eCheck payments normally settle in one to four banking days.

Settled. The payment settled in a processor batch. The settlement date and batch reference are recorded on the receipt.

Returned. The bank returned the payment after it settled, for example for insufficient funds or a closed account. The return code and the date of the return are recorded.

Failed. The processor rejected the payment.

Held for Review. The processor is holding the payment for fraud review.

Voided and Refunded. The payment was voided or refunded at the processor.

Unknown. The processor reported a status PCR Educator does not recognize. Treat these as items to review by hand.

Seeing gateway information on the receipts list

Navigate to Finance > AR > Receipts. Four columns are available and hidden by default: Gateway Status, Gateway Settlement Date, Gateway Batch and Gateway Return Code. Click the settings icon above the grid, check the columns you want, and click Apply. Your selection is remembered for your user.

The same four fields are available in the search bar, so you can filter the list on them and save the search.

Note: A receipt that has been voided does not appear in the list unless you check include all. When you search for returned payments that have already been processed, check that box, or the list will look empty.

Seeing the full history for one receipt

Open a receipt from the list, then choose Gateway from the receipt menu. The page shows the current gateway values for the receipt, including the transaction id, batch reference, settlement date, return code and description, and when the status was last checked.

Below that, Gateway Events lists everything that happened to the payment in order, with the date, the source of the event, and a description. A returned eCheck that was processed automatically shows the return itself, the stored payment being paused, and the automated returned payment routine, each as its own entry.

The Gateway page does not appear for receipts that were not processed through a payment gateway, and it shows a short message for receipts recorded before this feature was released.

Using gateway information in notifications

Because the four gateway fields are standard search fields on customer receipts, they can be used in notification triggers. A common setup is to alert the business office when a payment has not settled after a set number of days, or when any payment is returned. See Creating Notification Trigger for how to build the trigger.

Roles required: FinanceAR Full or Contract Full. This is the same access already needed to edit auto-pay configurations, so no additional role is needed for these settings.

Settlement and return handling is configured on each auto-pay configuration, so a school can treat tuition differently from donations. Navigate to Finance > Maintenance > Auto-Pay Configurations and edit a configuration. The settings appear only for configurations that use Authorize.net, because they depend on settlement results that only Authorize.net reports back.

All settings are off when the feature is released. Nothing changes for your school until you turn them on.

Before you begin

Use a separate auto-pay configuration for eCheck payments. The receipt method recorded on a receipt comes from the auto-pay configuration, not from the card or bank account actually used. The deposit automation looks for eCheck receipts, so a configuration labeled for credit cards that is used to take eChecks will not reconcile. See Configuring Payment Configuration.

Prepare an invoice template for the returned payment fee, with an accounts receivable account and a payment term.

Prepare a fee product for the returned payment fee, with a revenue account and a sale price greater than zero.

Prepare an email template for the message to the family, using the Customer Receipt entity and the email method.

Settings

Deposit Reconciliation. Off or Auto. When set to Auto, settled eCheck receipts are moved onto a deposit that matches the processor's settlement batch, and the deposit is marked as deposited. See Reconciling eCheck Deposits with Payment Processor.

NSF Automation. Off, Create Unposted, or Create and Post. When turned on, a returned payment is processed automatically the same way the Void NSF screen processes it by hand. Create Unposted leaves the fee invoice unposted so somebody reviews it first. Create and Post posts the fee invoice as well. Start with Create Unposted. See Voiding Returned Customer Payment.

NSF Invoice Template. The invoice template used for the fee invoice. The template supplies the accounts receivable account, the payment term, the classification and the memos.

NSF Fee Product. The product charged to the family for the returned payment. The product's sale price is the fee amount, so there is no separate amount to enter here. Changing the product's sale price changes the fee charged on future returns.

Family Return Email Template. The message sent to the family when a payment is returned, asking them to update their payment information. Leave this empty if you do not want the family notified automatically.

Pause Autopay on NSF. When checked, a returned payment pauses that family's stored payment so the next automatic run does not charge an account that has already failed. See Paused Stored Payment.

Note: If you set NSF Automation to a value other than Off without choosing both an invoice template and a fee product, the save is refused with a message and these settings are left unchanged. The rest of the auto-pay configuration still saves normally.

Recommended rollout

Turn on nothing at first and watch the gateway statuses appear on the receipts list for a week. Add Deposit Reconciliation next, because it is additive and easy to check against your bank. Add NSF Automation in Create Unposted mode last, and review the first several fee invoices before switching to Create and Post.

Roles required: Stored Payment. This is the same access already needed to add or delete stored payment information, so no additional role is needed to pause or resume.

A paused stored payment is a saved payment method that PCR Educator will not charge automatically. Pausing holds the family's auto-pay arrangement in place without deleting their stored payment or their enrollment, so automatic charging can be resumed later without asking the family to enter their details again.

Pausing works with every payment processor. Wherever PCR Educator charges automatically, a paused stored payment is skipped.

How a stored payment becomes paused

A member of staff pauses it in Campus. Use this for a family between jobs, a disputed charge, or a payment plan under review.

The family pauses it in the portal, if the school has enabled that option. It is off until the school turns it on.

A payment is returned by the bank. For schools processing through Authorize.net, a returned payment pauses the stored payment automatically when Pause Autopay on NSF is turned on for the auto-pay configuration. Returns where the account holder states the debit was not authorized always pause, because banking rules do not permit the school to present that debit again. See Configuring Settlement and Return Handling.

What a pause stops

A pause stops unattended charging. The nightly automatic payment run, automatic account top-ups and recurring pledge payments all skip a paused stored payment.

A pause never prevents the family from paying when they choose to. A pause set by staff or by the family stops automatic charging only, and the family can still select that stored payment and pay in the portal.

Where the pause followed a returned payment, whether the family can still use the payment method depends on why the payment came back.

Returned for insufficient or uncollected funds. Automatic payments stop, and the family can still choose that stored payment and pay in the portal. The balance may well cover the payment now, and the family is trying to settle the account.

Returned because the account holder revoked or never gave authorization. The payment method cannot be used again at all, including by the family. New payment information is required.

Returned because the account is closed, does not exist, or the number is invalid. The payment method cannot be used again, for the same practical reason. New payment information is required.

How a stored payment becomes active again

This depends on why it was paused, because the two situations call for different answers.

Paused after a returned payment. The family enters payment information again in the portal. Saving it reactivates the stored payment automatically and automatic payments resume on the next run, with no action required from the school. The new payment information is the fix, so nothing further is needed.

Paused by staff or by the family. Somebody resumes it deliberately, using the Resume action. A hold of this kind is not lifted by the family updating their card or bank details, because new payment information does not answer the reason the pause was put in place.

Pausing and resuming in Campus

Navigate to Finance > AR > Customers and open the customer. Go to Stored Payment Info. Click Pause on the stored payment and confirm when prompted.

The Status column then shows the stored payment as paused, with the reason and who set it. To start automatic payments again, click Resume on the same row.

Letting families pause automatic payments themselves

This is off unless the school turns it on. In the CMS Portal, open the page that carries the Household Auto Billing widget, or add the widget from the Payments category. See CMS Portal: Stored Payment Info Management Widget. Check the Allow Family Pause setting and click Save.

Families then see a Pause Automatic Payments button alongside their stored payment, and a matching button to resume.

Families cannot resume a stored payment that was paused because a payment was returned. That one clears when they save payment information again, which is what the portal asks them to do.

Note: Consider whether these requests should reach the business office first. Many schools prefer to handle a pause as a conversation and leave this option off.

Where you see it in Campus

The Status column on Stored Payment Info shows the stored payment as paused together with the reason and who set it, reading Paused by school, Paused by family, or simply Paused for one that followed a returned payment. A pause that followed a return also names the return code and the receipt involved. The same status appears on the Customer Auto-Pay dashboard widget and on the Stored Payment Info page of the household editor.

When you run automatic payments, families whose stored payment is paused are listed on the Review Invoices and Process Payments tabs under a note that says they were skipped because the stored payment is paused, with a count. Their invoices are not selected for payment.

What the family sees

On the Auto-Pay page of the portal, a notice under the stored payment explains why it is paused, and the wording follows the reason. A pause the family set themselves says automatic payments are paused at their request and can be resumed there. A pause the school set says automatic payments are paused by the school and invites them to contact the office. A pause that followed a returned payment explains that a payment was returned and invites them to replace the payment information.

On the Pay Now page, if the payment method may still be used, a notice explains that they can still pay with it now and that automatic payments resume once they re-enter their payment information.

Families see plain language only. Return codes, receipt numbers and internal detail are shown to staff, not to families.

PCR Educator now follows every gateway payment through to settlement and back. A nightly process reads settlement results from Authorize.net, records what settled and in which batch, and identifies any payment the bank has returned. Business offices see the whole life of an eCheck payment across the banking days it takes to complete.

Key capabilities

Gateway status on every receipt. Gateway Status, Gateway Settlement Date, Gateway Batch and Gateway Return Code are available as columns and as search fields on the Customer Receipts list. They also drive notification triggers, so the business office can be alerted when a payment has not settled after a set number of days.

Automatic deposit reconciliation. Settled eCheck receipts move onto a deposit that matches the processor's own settlement batch, dated the day the money settled.

Automated returned payment handling. A returned payment can void the original receipt, mark it NSF, associate the void deposit, and raise the fee invoice from your own invoice template and fee product, unposted for review or posted outright.

Family notification and autopay pause. The family receives your message asking them to update payment information, and their stored payment pauses so an account that has already failed is not charged again. Saving new payment information reactivates it automatically.

A complete record. Every receipt carries a Gateway page showing what happened and when, from settlement through return to fee invoice.

Why it matters

Reconciliation work that took a careful hour of matching and re-entry now happens overnight, and a returned payment is caught the night the bank sends it back. Every setting is off until a school turns it on, and lives on the auto-pay configuration, so tuition and donations can be handled differently. The automation never alters the original invoice or receipt; corrections are added as new records. Returns that call for judgment, such as a family stating a debit was not authorized, stay with a person.

A few ways to talk about it

• Every gateway payment is now tracked from charge to settlement to return, on the receipt itself.
• Settled eCheck receipts reconcile to the processor's own deposit batch overnight.
• Returned payments can void, re-invoice the fee, notify the family, and pause autopay automatically.

Available now to PCR Educator schools processing through Authorize.net. Your account team can walk you through the setup whenever you're ready.

Picture a dance school running a national audition tour: thirty cities, hundreds of dancers, a faculty panel that changes from stop to stop, and a line of walk-ins at every studio door. Registration lists drift out of date by morning, numbers get pinned at the check-in table, and score sheets pile up next to the sound system. PCR Educator runs that entire season in one system, from the family's first registration to the final placement report, and the same workflow covers interview days and entrance testing for schools that do not hold a single plié.

Before the tour: set up auditions once

Every audition belongs to an audition category: the summer intensive tour, company placement, year-round program auditions. The category carries the operating rules: capacity, how many attendees a family may bring, when online registration closes, and what lands on the dancer's record at sign-up. The individual stops on the tour, each with its own date, studio, and capacity, sit underneath.

The category also carries the panel. Assign your adjudicators to the category once, and every dancer who registers for any stop on the tour is routed to them automatically. When faculty rotate mid-tour, update the category and the assignments follow. Hand-picking a panel for one dancer still works, and the two approaches run side by side.

Dancers register themselves

Families register through the school's portal. They see open sessions, remaining spots, and your instructions; the system enforces registration windows and family limits. The moment a family registers, the dancer's record gets the audition on it, the admissions checklist advances, and the panel can already see the name on their list. Nobody at the front desk re-types a registration.

Audition day: check in, pin the number

Walk-ins are a fact of audition day, so check-in treats them like everyone else: staff attach the dancer to the audition, and the panel routing happens on the spot. At the same table, staff issue each dancer an audition number, the one pinned to the leotard. The number lives in its own field on the audition record, deliberately separate from the panel's notes, so registrars can sort and export by it without untangling comments. When the dancer returns for another audition, a new number takes its place. Each audition keeps its own history.

In the studio: score the whole room on one screen

Adjudicators open their screen, filter to the tour and the stop, and see exactly the dancers in the room, each with the number pinned to them. The scoring grid lays the room out side by side: one column per criterion (technique, artistry, musicality, whatever your rubric defines), a comment box, and the audition number. Rubrics are fully configurable per audition type, numeric ranges or custom scales, and each adjudicator sees only the dancers assigned to them. Finished evaluations lock, and every score is attributed to the panelist who entered it.

After the tour: results are already where they belong

Nothing waits for transcription. Scores, comments, and numbers are on the dancer's record the moment the panel saves. The admissions office pulls acceptance and placement reports sorted by audition number, aggregates results across panelists, and reaches every field through the Data Analytics Tool. Callbacks, re-auditions, and multi-city tours accumulate as clean per-audition history instead of overwritten spreadsheets.

The operating principle

Audition season is a throughput problem. The schools that run it well remove every manual handoff between the family, the check-in table, and the panel. That is what this workflow does: registration feeds the panel, check-in feeds the grid, and the grid feeds placement, with no re-keying anywhere in the chain.

Applicant evaluations in PCR Educator Campus now connect directly to your admissions events. Assign evaluators to an event category once, and every applicant who signs up is theirs to score. At check-in, staff issue an Alternate ID that follows the applicant onto the scoring grid. On evaluation day, the whole flow runs from one screen: filter to the event, see the room, score everyone side by side.

What's new

Evaluator assignment by event category. Add evaluators to an event category (an audition tour, interview days, entrance testing) and they automatically receive every applicant who signs up for any event in that category. Walk-ins are covered the moment staff record the sign-up at check-in. Per-applicant assignment still works exactly as before.

Per-event Alternate ID at check-in. When an applicant arrives, staff enter an Alternate ID on the check-in record or directly on the scoring grid. It stays its own field, so evaluator notes never get tangled with it, it exports cleanly for reports, and it resets naturally when the applicant returns for a later event.

Event filter on the Evaluations screen. Evaluators responsible for dozens of events pick a category and an event and see only the applicants in front of them, with the matching evaluation ready to score.

Bulk scoring grid. Select the applicants in the room and score one evaluation type side by side: a column per scoring category, comments, Alternate ID, and customizable columns, all in a single grid.

Why it matters

Evaluation days are high volume and unforgiving. Applicants arrive in waves, some unannounced, and evaluators cannot stop to hunt through assignment lists. Now the front desk issues the number, the evaluator filters to the event, and every score lands on the right applicant. Nobody re-keys data afterward, and the reports your team pulls sort cleanly by the ID your staff issued at the door.

A few ways to talk about it

• Assign evaluators to the event category once. Every sign-up, including walk-ins, reaches them automatically.
• Check-in issues the number. The scoring grid already knows it.
• Thirty events on the calendar, one filter to see today's room.

Available now to all PCR Educator schools. Your account team can walk you through event categories and the scoring grid whenever you're ready.

PCR Educator now suppresses duplicate emails within a single send. When one send would deliver identical content to the same address more than once, for example a household copy and a parent copy sharing one inbox, the system delivers exactly one copy and records the rest as suppressed duplicates.

What's new

One copy per address per message. Within a single send, each email address receives a given message once. If the same address appears as a household email, a parent email, and a named recipient, the first copy is delivered and the remaining copies are suppressed.

Personalized content still arrives. Suppression compares the merged content, not just the address. Two messages personalized for different students remain two messages, and both are delivered.

Every suppressed copy is recorded. The notification history shows each suppressed recipient with a reference to the copy that was delivered, so "did parent one receive it" always has a definite answer.

Read tracking follows the delivered copy. Opens and link clicks register on the copy that was sent, keeping read statistics meaningful.

Why it matters

Families who share an inbox, or who use one address for both the household and a parent record, stop receiving the same email two or three times. Front offices stop fielding "why did I get this twice" replies, and read rates stop being diluted by copies nobody opens twice. Nothing changes in how you configure sends: the suppression happens automatically, and different content to the same address continues to flow exactly as before.

A few ways to talk about it

• Same message, same address, one email. Every extra copy is recorded, not silently dropped.
• Personalized messages are never merged away: different content to one address still arrives separately.
• Read statistics now reflect real inboxes instead of duplicate copies.

Available now to all PCR Educator schools. Your account team can walk you through the notification history whenever you're ready.

PCR Educator now processes Canadian bank payments through Stripe pre-authorized debits (PAD) under Payments Canada rules. Canadian schools that could not use eCheck can now offer families the same save-once, pay-automatically experience that US schools have had for years, in Canadian dollars.

What's new

Pre-authorized debit support for Canadian schools. A Stripe payment configuration now accepts family bank accounts alongside credit cards. Families save an account once, and Auto-Pay drafts invoices on the school's schedule.

Bank account verification built into the portal. After a family saves a bank account, the portal shows a verification notice. Stripe sends two small deposits within 1 to 2 business days, and the family confirms the amounts through a linked Stripe page. Stripe also emails the family a confirmation of the debit agreement and a notification for each debit, as Payments Canada requires.

Charge currency follows the payment configuration. A Canadian school sets the Processor Culture to en-CA, and every Stripe payment processes in Canadian dollars.

Failed debit monitoring. Bank debits settle over several business days. If a debit fails after acceptance, PCR Educator is notified automatically and coordinates the receipt reversal with your business office.

Why it matters

Canadian schools have been exporting payment files and uploading them to their bank's EFT platform by hand. That workflow disappears. Families authorize once, invoices draft automatically, and bank debits cost a fraction of credit card processing. The business office keeps the same receipts, deposits, and reconciliation it uses today.

A few ways to talk about it

• Canadian families can now pay tuition straight from their bank accounts, with no manual EFT files.
• Save once, verify once, and Auto-Pay handles every invoice after that.
• Bank debits cost schools a fraction of credit card processing fees.

Available now to all PCR Educator schools. Your account team can walk you through Stripe setup and pre-authorized debits whenever you're ready.

One of the following roles is required to access this query: FinanceGL Full, FinanceGL Read.

This DAT Query returns fixed assets that are fully depreciated (Book Value equals Residual Value) as of a chosen date, excluding disposed assets. Book Value is calculated as Acquisition Price minus all depreciation scheduled through the chosen date.

The Depreciate Date is set as a DAT Parameterized Condition, allowing you to change the cutoff date on the Results screen (for example, 06/30/2026 for June 2026).

Note: To see every asset with its current book value rather than only fully depreciated assets, remove the Book Value = Residual Value condition on the Fixed Assets table.

    - Navigate to Scheduling > Courses > Sections in the current year schedule.

    - Select the sections to copy scheduling info for and go to multi-action > Copy Scheduling Info To Next Year.

    - Check the fields to copy (Period Code, Room, Section Name) and click the Copy To Next Year button.

Note: This feature is only available in the current year schedule and requires the Scheduling Full role. The selected sections must already exist in the next year (run Copy To Next Year first). Next year values for the checked fields are overwritten.

PCR Educator now lets schools copy Period Code, Room, and Section Name to next year for exactly the course sections they choose. Until now, the Copy To Next Year tasks moved scheduling details for every section in a division or for none at all. The new Copy Scheduling Info To Next Year multi-action brings that choice down to the individual section.

What's new

Selective copy from the Sections list. Navigate to Scheduling > Courses > Sections in the current year schedule, select the sections you want, and go to multi-action > Copy Scheduling Info To Next Year. Requires the Scheduling Full role.

Field-level control. Check any combination of Period Code, Room, and Section Name. Only the checked fields are copied; everything else in next year stays as it is.

Runs after the standard copy. The action updates the matching sections that already exist in next year, so it fits cleanly after Copy To Next Year has created them. Next year values for the checked fields are overwritten.

Period codes stay aligned. When Period Code is copied, each section is linked to the matching next year class schedule automatically.

Why it matters

Many schools keep the same room, period, and section notes year after year for only part of their catalog. Before, the choice was to copy everything and then delete what did not apply, or to copy nothing and re-enter details by hand. Now the rollover matches how scheduling actually works: run the standard copy for the whole division, then pull the details forward for just the classes that repeat. The rest of next year stays blank, which keeps it easy to see what still needs to be scheduled.

A few ways to talk about it

• Copy rooms, periods, and section names for exactly the sections you choose.
• Filter the Sections list by department, select, copy. Done.
• Everything you do not copy stays blank, so unfinished scheduling is still easy to spot.

Available now to all PCR Educator schools. Your account team can walk you through the new multi-action whenever you're ready.

Canadian pre-authorized debit (PAD) is a bank-account payment method for Canadian schools, processed through Stripe under Payments Canada rules. You need Security Full or Security Read roles to access the Security portal and the DBA Full role to access the Payment Configuration page. Finance setup requires the FinanceAR Full role.

Prerequisites

• A Stripe account for your school with pre-authorized debit payments enabled. Your Stripe dashboard shows the Publishable Key and Secret Key under Developers, API keys.

Setting up the payment configuration

• Navigate to Security, Maintenance, Payment Configurations and add a Stripe payment configuration. See Configuring Payment Configuration.
• Enter the Publishable Key, Secret Key, and Webhook Signing Secret from Stripe.
• Set the Processor Culture to en-CA. This processes every Stripe payment, including PAD, in Canadian dollars.
• In your Stripe dashboard, register a webhook endpoint pointing to https://{your school site}/Common/StripeWebhook.aspx?pcid={payment configuration id}&pid={any page id of your site}, subscribed to payment_intent.payment_failed, setup_intent.succeeded, and setup_intent.setup_failed. Enter the endpoint's signing secret on the payment configuration.

Setting up Auto-Pay configurations

• Navigate to Finance, Maintenance, Auto-Pay Configurations. See Auto-Pay Configuration (Finance).
• Point both the credit card and the eCheck Auto-Pay Configurations at the Stripe payment configuration when they share a Stored Payment Type.
• Set the Receipt Method on the eCheck configuration to a bank value rather than Credit Card so receipts and deposits reconcile correctly.

The family experience

• Families open the Auto-Pay page in the portal and enter their bank details. The routing number is the 9 digit electronic format: 0, followed by the 3 digit institution number and the 5 digit transit number.
• After saving, the portal shows a verification notice. Stripe sends two small deposits within 1 to 2 business days, and the family confirms the amounts through the linked Stripe verification page. Payments cannot be drafted until verification completes.
• Stripe emails the family a confirmation of the debit agreement and a notification for each debit, as Payments Canada requires.

Settlement and failures

PAD debits are accepted immediately and settle in roughly 3 to 5 business days. A debit can still fail after acceptance, for example for insufficient funds. PCR Educator is notified automatically and coordinates the receipt reversal with your business office, following the same procedure used for returned eChecks. See Reconciling eCheck Deposits with Payment Processor.

The CMS Widget - Login authenticates a visitor against their PCR Educator account and, on success, sends them to the configured destination page. It also doubles as the account creation form for portals that allow self-registration, such as Online Store or Alumni. The widget can be found within the User group. Please review Adding CMS Widget for more information.

Destination Page Url determines where a visitor lands after a successful login. Note: if the page carries a returnUrl (for example, because the visitor was sent here from a page that requires login), the returnUrl takes priority over Destination Page Url.

Login Title customizes the heading shown above the username and password fields.

User Name Label customizes the label for the username field.

Password Label customizes the label for the password field.

Failure Text customizes the message shown when a login attempt fails. Note: if the account's password predates PCR Educator's stronger password requirements, the widget shows a password reset message instead, regardless of this setting.

Enable Google Authentication sends the visitor straight to a Google sign-in prompt instead of showing the username and password fields. Note: this only applies when the application has an Email Domain configured and the widget is not on an admin page. If Google returns an error, the widget falls back to the standard login form.

Redirect If Already Logged In sends a visitor who is already signed in straight to Destination Page Url (or returnUrl, if present) instead of showing the login form. Note: this setting requires Destination Page Url or an incoming returnUrl; without one, the widget has nothing to redirect to and behaves as if the setting were off. If the destination page does not allow the signed-in visitor in, for example due to a role restriction, the widget shows the login form instead of redirecting again, along with the message configured in Already Logged In Text.

Already Logged In Text customizes the message shown when Redirect If Already Logged In is on but the visitor's account is not allowed on the destination page.

Hide Login hides the username and password fields and the Log In button, leaving only the account creation panel visible when Enable Create New Account is also on. Note: use this to build a registration-only page.

Enable Create New Account shows an account creation panel below the login form, letting a visitor create their own username and password.

Create Account Title customizes the heading above the account creation panel.

Create Account Button Text customizes the text on the account creation button.

Create Account Email is the confirmation email sent to a visitor after they create an account.

Create Account Redirect Page is where the Continue button sends a visitor after account creation, when no returnUrl or Destination Page Url applies.

Continue Button Text customizes the text on the button shown after a new account is created.

Create Account Success Text customizes the message shown after a new account is created successfully.

This Notification Trigger sends one email to parents and admins when a student reaches a specified absence threshold in the current semester. It uses the new period-aware quota controls so the email goes out exactly once per threshold per student per semester, not every day.

When to use

Schools often want to notify parents and admins when a student crosses an absence threshold: for example, 5 absences, 7 absences, 9 absences. Build one trigger per threshold, each pointing at the matching saved filter from FAQ: Configuring Absence Threshold Filter.

Steps

• Navigate to Home > Notifications > Notification Triggers.
• Click New to start a new trigger.
• Fill the standard top-of-form fields:
  • Category: the schedulable attendance trigger type (the entry that exposes the Send Rate controls in Custom Settings).
  • Name: a clear name such as "Absence Alert 5 in Semester".
  • Is Active: checked.
  • Recipient / Data Relationship: Parent-Child (parents receive the alert; admins are added via the role list at the bottom of the form).
• Set the filters:
  • Eligible Recipients Filter (User): the saved user filter for parents and admin recipients.
  • Merge Filter: the absence threshold filter from FAQ: Configuring Absence Threshold Filter, for example "Absences 5 or More, Current Semester".
• After both filters are selected, check Estimated Sendings at the bottom of the Notification Settings section. The statistic shows the number of recipients who would receive the alert if the trigger ran right now, which confirms that the absence filter matches the students you expect before the trigger goes live.
• Pick the absence alert Email Template.

Send Rate Settings

These controls (introduced in Update: Notification Triggers, Now on Your School's Calendar) cap the trigger so each student receives exactly one email per threshold per semester:

• Send Rate: Daily. The job evaluates each day, and the caps below prevent daily sending.
• Minimum days between fires: 30. This is a per-student frequency floor that prevents repeat sends if a student's count momentarily flickers.
• Maximum fires per: Semester. Pick Academic Year instead if you would rather cap once per year across both semesters.
• Maximum number of fires: 1.
• School division for period: required when Maximum fires per is Semester or Marking Period. Pick the appropriate division. The dropdown is hidden for Academic Year and Don't limit.

Note: If you pick Semester or Marking Period without selecting a School division for period, the save is blocked with the message "Pick a school division - required when 'Maximum fires per' is Semester or Marking Period."

Visible for Roles

At the bottom of the form, check the admin role(s) that should also see the notification in their inbox.

Save and repeat

Click Save. To create the trigger for 7, 9, and higher thresholds, clone the trigger and change only:

• The trigger Name (for example, "Absence Alert 7 in Semester").
• The Merge Filter selection (point at the matching saved filter for that threshold).

Send Rate, Minimum days between fires, Maximum fires per, Maximum number of fires, and School division for period stay identical across thresholds.

How the period scoping works

The trigger's Maximum fires per: Semester cap counts fires within the boundaries of the selected School division for period's marking-period and semester calendar. When the semester turns over, the per-student counter resets and the trigger is eligible to fire again on the new semester.

This works in tandem with the Merge Filter from FAQ: Configuring Absence Threshold Filter, which uses Division Calendar to scope the absence count itself to the current semester.

Together: the filter answers "does this student have 5 or more absences in the current semester," and the trigger answers "should we send the email now, or have we already sent it this semester."

Notes

The trigger evaluates daily because Send Rate is set to Daily, but the Maximum fires per: Semester cap and the Minimum days between fires floor ensure that any given student receives at most one email per threshold per semester.

If a customer wants a less aggressive cadence (for example, two reminders per semester instead of one), increase Maximum number of fires accordingly and adjust Minimum days between fires so the reminders are spaced appropriately.

Closing a fiscal year tells PCR Educator that a financial year is finished and should no longer accept new or changed transactions. It is a soft close, so you can re-open the year at any time if a correction is needed. Complete your year-end reconciliations and statements before you close, because closed-year transactions drop out of your day-to-day working lists.

Only users in the FinanceGL Full or Contract Full role can close or re-open a year.

How to close a year

1. Go to Finance and open Fiscal Years.
2. Select the year you want to close to open its Details page.
3. Confirm the Begin Date, End Date, and Open Period Date are correct.
4. Click Close Fiscal Year.

The Is Open box clears, and the button changes to Re-open Fiscal Year.

What closing affects

Closing removes the year from the open posting window, so new General Ledger, Accounts Receivable, and Accounts Payable activity must be dated in an open year. Transactions in the closed year stay in the system but leave the standard lists; use Include All to see them. Refunds cannot be dated in a closed period. Gift entry in Fundraising is not blocked, but General Ledger posting and reports still follow the open year. Nothing is deleted, and reports on closed years are unaffected.

How to re-open a year

Open the year's Details page and click Re-open Fiscal Year. The year returns to the open posting window and its transactions return to the standard lists. Make your correction, then close the year again.

Need help

Open a ticket through the PCR Educator customer portal or email support@pcreducator.com. Include your school name and the fiscal year you are working with.

A PCR Educator DAT Query can now compute an aggregate across a wider group than the row it sits on, while the query stays grouped at its own level. A new Partition By option on any Aggregate field puts a row's own number and the total it belongs to side by side. Running totals, subtotals, and share-of-whole calculations fit in a single DAT Query.

What's new

Partition By on any Aggregate field. Set a field's role to Aggregate, choose the function (Sum, Count, Average, and the rest), then pick a Partition By column from a typeahead. The aggregate computes across that wider partition while each row stays grouped at the DAT Query's own level.

Optional on every Aggregate field. Partition By is there when you want a wider calculation. An Aggregate field with no partition set is a standard aggregate.

One DAT Query for the comparison. A row can show its own value and the value of the group it belongs to, together, in a single DAT Query.

Why it matters

A row can carry both its own number and the number it belongs to. Show each course's enrollment next to its department's total enrollment. Show a donor's giving next to the campaign total. Show a student's tardies this term next to their full-year count. The reader sees the part and the whole together, and the comparison is immediate.

A few ways to talk about it

• Running totals, subtotals, and share-of-whole math live in a single DAT Query.
• Partition By sets each row next to the total of the group it belongs to.
• An Aggregate field with no partition set stays a standard aggregate.

Available now to all PCR Educator schools. Your account team can walk you through Partition By in a DAT Query whenever you're ready.

Check In / Check Out is a PCR Educator CMS widget that lets a student, a staff member, or an authorized pick-up identify themselves at a screen and check in or out for the day. Schools commonly deploy it as a self-serve attendance kiosk on a laptop, a tablet, or a wall-mounted touch panel. The widget is configured entirely from the standard page editor, with no developer involvement, and it can optionally write period and daily attendance.

Setup happens in the CMS page editor, so configuring the widget requires an account with permission to edit CMS pages.

Schools deploy the widget for:

• Morning carpool and after-school care check-in stations
• Athletics, field trip, and extended-day program rosters
• Late-arrival and early-dismissal desks at the front office
• Optional automatic period attendance for late or early-departure students

Setup at a glance

From the page editor:

• Open the CMS page where the kiosk will live, or create a new page.
• Click Add Widget, then User, then Check In / Check Out.
• Open the widget Properties dialog with the gear icon and configure Sign In Type, Operations Type, Program Type, the button text, and any of the optional customizations described below.
• Save the widget. The kiosk is live immediately.
• On the device itself, sign in once with a staff or operator account before leaving the kiosk unattended. The widget checks for a signed-in account when the page first loads. Once the device is signed in, any number of students sign themselves in and out against it. Note: the signed-in account is recorded as the operator in the Modified By column of the Check In/Check Out list in Campus. If that login expires later in the day, the kiosk keeps recording scans and the column shows [No User]. Reload the page and sign in again to restore the operator name.

To write Late, Absent, and Leaving Early stamps automatically, which is recommended for schools that want period attendance from the kiosk:

• Add a second widget to the same page: Parent/Student Attendance Entry.
• In its Properties, set Late Type, Absent Type, Leaving Early Type, and, optionally, Daily Attendance Type to the attendance discipline types your school uses.
• If your school runs more than one division, set Excluded Divisions on that same widget to every division except the one this kiosk serves. A daily attendance row belongs to a single division, so a student enrolled in several divisions gets no daily row until exactly one division is left for them.
• Save. The kiosk now writes period attendance automatically when students check in or out.

For full configuration of the partner widget, see CMS Widget - Parent/Student Attendance Entry.

Sign-in modes

Each kiosk supports one or more of the following sign-in methods. Enable as many as appropriate with the Sign In Type property. When two or more are enabled, a pill row appears at the top of the kiosk so the user can choose. With one enabled, the row is hidden.

One kiosk can offer student and staff sign-in together. The widget records each check-in as student or staff from the mode the person used: the Staff ID mode records a staff member, and every other mode records a student. Staff check-ins are recorded against the staff roster. They do not send notification emails, and the period attendance integration applies to student check-ins only. Staff sign in through the Staff ID mode, because the Username, Name + PIN, PIN, and Alternate ID modes resolve against student and household records.

Pick one default with the Default Active Mode property. That pill is highlighted on first load. The kiosk also remembers which pill the user last touched and restores it after any submission, so a barcode scanner station that opens to Student ID stays on Student ID after each scan.

Optional: period attendance integration

Placing a Parent/Student Attendance Entry widget on the same page changes the kiosk from a record of who is on campus into a full attendance writer. On every successful student check-in or check-out, the kiosk will:

• Write Absent stamps for any scheduled periods that ended before the student checked in, which fills the gap.
• Write a Late stamp for the period in session at check-in time.
• Write a Leaving Early stamp for the period in session at check-out time.
• Optionally stamp every period after the check-out as Absent, when the school enables it.
• Optionally write a single daily attendance row. Three things have to be true for that row to appear: a Daily Attendance Type is set on the partner widget, the student resolves to exactly one division once Excluded Divisions has been applied, and the date is an attendance day for that division. If any of the three is not met the check-in still succeeds and no daily row is written.

All writes respect a same-user audit gate, so teacher-entered attendance is never overwritten, and prior kiosk stamps can be cleanly cleared when the student returns the same day. For the full setup of the partner widget, see CMS Widget - Parent/Student Attendance Entry.

Late and early departure thresholds

Many schools have rules such as "a student more than 20 minutes late is marked Absent" or "a student leaving in the first 30 minutes counts as Leaving Early, and beyond that it is a normal departure." The kiosk supports both with two integer properties.

Both thresholds measure minutes elapsed since the current period's nominal start time, using the school's schedule data. If the student has no scheduled period at that moment, such as during lunch, before school, or after dismissal, the thresholds do nothing and the kiosk falls back to its default behavior.

Customization options

Beyond the sign-in modes and thresholds, the widget includes a broad set of properties for tailoring messages, behavior, and presentation. The most commonly used:

What students see

On every kiosk the experience is the same: large touch targets, no scrolling, and no logins to remember unless the school chooses Username mode.

• A row of sign-in pills at the top, hidden if only one mode is enabled.
• The matching input panel below, which is a numeric keypad for ID or PIN, a username and password form for Username mode, or a name and PIN form for Name + PIN.
• Large Check In and Check Out buttons.
• A completed ID or PIN submits on its own where the kiosk offers a single action, so a student who fills every slot never reaches for a button. Where both Check In and Check Out are available the student still chooses, because the number alone does not say which one they meant. An ID shorter than the configured slot count leaves slots empty, so those students press the button as before.
• After submitting, a calming success card with the school greeting, the student's name shown prominently, and their photo and profile (Name, ID, Grade, Status). The form returns automatically after the configured timeout, and when Start Over Text is set, a button on the card returns it straight away.
• On error, the form stays in place, the typed value is preserved so the student can fix a typo without retyping, and the error message displays in red.

Best practices

• For high-traffic stations such as carpool, enable a single sign-in mode, either PIN or Student ID, so the pill row hides entirely. Fewer taps mean faster lines.
• Pair Alternate ID with a USB barcode scanner mounted at the kiosk so students can scan an existing school badge with no typing, as long as the barcode value is numeric and fits within the configured slot count.
• When using the Late Absent Threshold, set it to match the school's published Late versus Absent policy, for example "20 minutes late is Absent." Communicate the rule to families in your handbook.
• Pair an Auto Reset Seconds value of 3 with a kiosk on a public touch screen to keep the next student's experience clean. Use a higher value, 8 to 10, where staff want time to read each success card.
• Test with at least one student account from each grade level or school division before going live. Different schedules can expose configuration gaps.

Need a hand?

Your PCR Educator account manager can walk you through a setup tailored to your school's carpool, after-school, or athletics workflow, including custom sign-in messages and visual styling. Submit a ticket from your Customer Portal, or email support@pcreducator.com.

A PCR Educator DAT Query now supports an Auto mode for the Pivot role. Pick a field, set its role to Pivot (Auto), choose the aggregate function and the field to count or sum, and the query discovers the most-frequent values on its own. Each becomes its own column, with an "Other" bucket catching everything else.

What's new

Pivot (Auto) as a field role. A new value in the Role dropdown sits next to Group, Aggregate, and Pivot. Pivot (Auto) is eligible for any field that holds categorical values, no upfront value list required.

Top values discovered at query time. The query finds the most-frequent values in the chosen field each time it runs, up to twenty columns, and adds an "Other" bucket for the long tail.

One aggregate per pivoted column. Count, Sum, Average, Minimum, or Maximum. Whatever function you pick applies to every discovered column and to "Other."

Built for fields where the value list is unknown or shifts. Course names, action types, donor categories, inquiry sources. Anywhere a manual Pivot would mean typing out values that change year to year.

Saves and reruns like any other DAT Query. The auto-pivot refreshes with the query, so the columns reflect the current data each time the report runs.

Why it matters

Manual Pivot expects the user to list the values that should become columns. That works when the list is short and stable. It does not work when the catalog changes from year to year, or when no one wants to track down every value a field can hold. Pivot (Auto) removes that work. A course-load matrix or an action-type breakdown stays current as new courses are added and new action types appear, with no edits to the query.

A few ways to talk about it

• Pick the field, the function, and the target. The columns come from the data.
• Top twenty values plus an "Other" bucket, refreshed every time the query runs.
• A natural fit for high-cardinality fields where the value list is unknown or shifts year to year.

Available now to all PCR Educator schools. Your account team can walk you through Pivot (Auto) in a DAT Query whenever you're ready.

A PCR Educator DAT Query now puts a copy icon on every field row. One click creates a second instance of the same field, and that copy carries its own role and settings. The same field can do two jobs in one DAT Query.

What's new

Copy icon on every row. Each field row in a DAT Query has a copy icon. Selecting it adds a second row for the same field, ready to configure on its own.

A role for each copy. The duplicate is a separate row with its own Role, so the same field can be grouped on in one row and aggregated on in another.

Two aggregates of one field. A number can appear as both a Sum and an Average in the same DAT Query, each in its own row.

Why it matters

A DAT Query often calls for the same field in more than one role. A date can group the rows and count them. A balance can show as a total and as an average in the same view. Duplicating a row makes both uses visible on screen: two rows, one field, each with its own job.

A few ways to talk about it

• A copy icon on every field row puts the same field to work in two roles.
• Group on a field and aggregate on it in the same DAT Query.
• Show a value as both a Sum and an Average, side by side.

Available now to all PCR Educator schools. Your account team can walk you through the duplicate-row button whenever you're ready.

A calculated field in a PCR Educator DAT Query can now reference another field by its alias name in square brackets, for example [Absences in Class] * 100.0 / [Total Absences]. The expression reads in plain English, and the DAT Query stays correct when fields move.

What's new

Reference by name. A calculated field can name the field it needs by its alias, written in square brackets. The alias is the field name you already see in the query.

Stable when fields move. An alias reference points to a field by name, so reordering or duplicating fields keeps every calculation correct. PCR Educator resolves the alias to the field when the DAT Query runs.

Readable expressions. An expression like [Gifts This Year] minus [Gifts Last Year] explains itself. The next person who opens the DAT Query can read the math directly.

Why it matters

Naming the field keeps the meaning of a calculation visible on the page. An expression built from aliases reads the way a school talks about its data. Concentration ratios, year-over-year deltas, and weighted averages can be written with names that say what they mean, and the DAT Query keeps working when someone rearranges the fields later.

A few ways to talk about it

• Calculated fields in a DAT Query reference other fields by name, so the math reads in plain English.
• Reorder or duplicate fields freely. Alias references stay pointed at the right field.
• Concentration ratios, year-over-year deltas, and weighted averages, written the way you would say them.

Available now to all PCR Educator schools. Your account team can walk you through alias references in a DAT Query whenever you're ready.

This filter identifies students who have reached a specified number of absences in the current semester. It uses the new Division Calendar table so the filter automatically scopes to the current marking period and semester, with no date editing required at the start of each term.

When to use

Schools often want to notify parents and admins when a student crosses an absence threshold: for example, 5 absences, 7 absences, 9 absences, and so on. Build one filter per threshold. Each filter feeds a separate Notification Trigger that sends exactly one email per threshold per student per semester. See FAQ: Configuring Absence Threshold Notification Trigger for the trigger configuration.

Filter structure

The completed filter follows this tree:

• Student Info
  • Period Attendance And Discipline
    • Count of Period Attend Disc Id > 4
    • Division Calendar ((attendance only))
      • School Id = 1

The Division Calendar ((attendance only)) child is the join that makes the filter scope to the current semester. For the Division Calendar feature itself, see Update: Division Calendar, Now in Data Analytics.

Steps

• Navigate to Scheduling > Students.
• Click the filter funnel icon next to the Select Saved Filter... dropdown above the student grid.
• In the Add Filter Item dropdown, pick New Filter and click Add.
• The query tree appears with Student Info as the root. Click the + icon next to Student Info.
• In the second dropdown at the top of the Connect modal (to the right of With), pick Period Attendance And Discipline.
• Click Select on the Student Info > Period Attendance And Discipline path.

Note: Always pick the destination table from the second dropdown at the top of the Connect modal. The Find Table autocomplete and Search button below open a Connect To dialog that does not list path-registered variants like Division Calendar ((attendance only)).

• The Period Attendance And Discipline conditions modal opens. In the Conditions row:
  • Change the first dropdown from Field to Calculated/Aggregate.
  • Set the aggregate function to Count.
  • Pick the field Period Attend Disc Id.
  • Change the operator to >.
  • Type the threshold value (for example, 4 for a "5 or more absences" filter, since greater-than-4 catches 5, 6, 7, ...).
  • Click Add.
• Click Save on the Period Attendance And Discipline modal.
• Back on the query tree, click the + icon next to Period Attendance And Discipline.
• In the Connect modal, click the second dropdown (to the right of With) and pick Division Calendar ((attendance only)).
• In the Division Calendar ((attendance only)) conditions modal, add a condition: Field School Id, operator =, value the school_id for the division you want to scope to (commonly 1). Click Add, then Save.
• Back in the Filter modal, click Save at the bottom.
• On the Save Filter page, type a clear name in Filter Name (for example, "Absences 5 or More, Current Semester") and click Save New.

The filter is now available as a Merge Filter on any Notification Trigger that targets students, and is also selectable from the Students page Select Saved Filter dropdown.

Cloning for additional thresholds

To create the filter for 7, 9, and higher thresholds, repeat the steps and change only the threshold value in the Count condition. Because Division Calendar always returns the current semester for each division, these filters do not require updates when the semester or academic year rolls over.

Example: For a "7 or more absences" filter, the Count condition is Count of Period Attend Disc Id > 6. For "9 or more," use > 8.

Notes

The aggregate condition lives on the parent table (Period Attendance And Discipline), not on Division Calendar. The Division Calendar join scopes which attendance records are counted to the current semester. The aggregate condition counts them.

The variant name in the second dropdown (here Division Calendar ((attendance only))) reflects the specific join path registered for that source table in dmt_table_joins. Other source tables may show different Division Calendar variants.

Setting up a field in a PCR Educator DAT Query is one choice. The Fields step gives each field a single Role: Group, Aggregate, or Pivot. Choose the role, and the controls that role needs appear with it.

What's new

One Role per field. Each field in a DAT Query has a single Role with three values: Group, Aggregate, and Pivot. The role drives how the field behaves in the query.

Controls that match the role. Choosing a role brings up the controls it needs. The Aggregate role brings the function and Partition By options. The Group role keeps the row simple.

Pivot offered where it fits. The Pivot role appears for fields that are eligible to be pivoted.

Why it matters

One decision sets up a field. The field grid stays focused on what each row actually uses, so a DAT Query is quick to build and quick to read, especially for someone building their first one.

A few ways to talk about it

• Field setup in a DAT Query is one Role choice per field: Group, Aggregate, or Pivot.
• Each role brings its own controls, so the grid shows what the field actually uses.
• Quick to learn on a first DAT Query, quick to scan on every one after.

Available now to all PCR Educator schools. Your account team can walk you through the Role column whenever you're ready.

PCR Educator's Data Analytics Tool now lets you decide what an empty cell should say. A new If Empty column on the Fields tab takes any placeholder you type, in any format the field supports, and renders it wherever the data is blank. Reports that used to leave readers guessing now finish their own sentences, in your school's own language.

Why it matters

When a query pulls data from more than one source, for example "show me all students, and their check-in status for today," some students will not have a matching record. Out of the box those cells appear empty, and the reader is forced to interpret. Is the data missing? Is the student absent? Did the report break? Each guess sends staff down a different path, and most of those paths are wasted time.

If Empty removes the ambiguity. You decide what an empty cell should say, so your report reads exactly the way you want it to, the first time, every time.

How it works

1. Add any field to your query.
2. On the Fields tab, find the new IF EMPTY column (it sits between Aggregate and Pivot Aggregate).
3. Type the value you want to display when the field is blank.
4. Save the query and run it. Every empty cell in that column now shows your chosen value.

The control adapts to the field type automatically, so the placeholder you type always matches what the field would normally hold:

• Text fields get a text box, and the placeholder also replaces empty strings, not just NULLs.
• Number fields get a text box for a numeric placeholder.
• Yes/No fields get a checkbox.
• Date fields get a date picker.
• Date and time fields get a date and time picker.
• Time fields get a time picker.

Examples in practice

Check-In Status. Set the placeholder to "Not checked in." Viewers see "Not checked in" wherever a student has no check-in record, instead of a blank cell.

Solicitor Assigned. Set the placeholder to "Unassigned." Development reports surface prospects with no owner, so the gift officer who runs the list knows exactly where to start the week.

Emergency Contact Phone. Set the placeholder to "Missing, please update." Staff see a clear call to action instead of an empty field, and the gap closes itself.

Tuition Balance. Set the placeholder to 0.00. Totals add up correctly, exports stay numeric, and the business office stops chasing phantom rows.

Photo Consent. Set the placeholder to "Not on file." Plain English replaces an unchecked box, so the reader does not have to guess whether unchecked means "no" or "not yet asked."

Key benefits

Cleaner reports. No more mystery blank cells, no more reports that read as if they are half finished.

Better communication. Replace technical emptiness with plain English meaning, in your school's vocabulary.

Smarter exports. Excel and PDF exports carry the replacement value, so downstream consumers, board members, parents, and auditors all see the same thing the on-screen reader sees.

Safer joins. When you combine tables with optional relationships, for example students with or without donations, every row reads coherently. Optional joins stop creating cognitive load.

No formula required. Type a value, save, run. No SQL, no expressions, no training, no help-desk ticket.

Where to find it

DAT, then open or build a query, then the Fields tab. The new IF EMPTY column sits between Aggregate and Pivot Aggregate. The feature is available on every field, in every query.

Compatibility

Existing queries are unaffected. The column is optional and defaults to blank, so reports built before this release continue to behave exactly as they always have. Adopt If Empty on the queries that need it, on your own timeline.

A few ways to talk about it

• Blank cells now say what you mean: type a placeholder, save, run.
• One control adapts to every field type: text, number, checkbox, date, time.
• Cleaner joins, cleaner exports, no formulas required, no SQL.

Available now to all PCR Educator schools. Your account team can walk you through the new column, and the examples above, whenever you're ready.

PCR Educator Data Analytics has a new table called Division Calendar. It exposes each division's current Marking Period, Semester, Academic Year, Admissions Year, Development Year, and Fiscal Year as a single always-current row per school. Saved filters, queries, and notification triggers can reference the current period directly, and the values stay accurate as the calendar rolls over.

What's new

One row per division. Division Calendar returns the current calendar values for every division a school runs, keyed on School Id, with columns for Marking Period, Semester, Academic Year, Admissions Year, Development Year, and Fiscal Year.

Division-aware values. Schools that run different calendars per division (Lower, Middle, Upper, or multi-campus) get the right current value for each division automatically.

Drop-in join for any table. Join Division Calendar to any existing table on School Id to scope a full DAT report or notification trigger to "this division's current marking period," "this division's current academic year," and so on.

Cross-departmental coverage. Academics, Admissions, Business Office, and Development all reference the same shared current-period table, so dashboards stay aligned across roles.

Why it matters

Build a filter once and it keeps working term after term, year after year. A query like "students with 5 or more absences in the current marking period" reads the current value from Division Calendar and stays correct as the calendar advances. Reports and notification triggers stay aligned to the actual calendar each division follows, automatically.

Example queries

• All students with 5 or more absences in the current Marking Period for their division
• Inquiries created in the current Admissions Year, by division
• Giving totals year-to-date for the current Development Year
• AR aging snapshot inside the current Fiscal Year
• Gradebook averages for sections in the current Semester

A few ways to talk about it

• Filters that stay current automatically: build once, reuse across every term and every year.
• One shared source of truth for the current period across Academics, Admissions, Business Office, and Development.
• Division-aware by design: Lower, Middle, and Upper school dashboards each read the right calendar value automatically.

Available now to all PCR Educator schools. Your account team can walk you through Division Calendar whenever you're ready.

A Household Notification Trigger is a notification trigger that operates on a Household record rather than on an individual student. It parallels the existing Student trigger type and is available automatically in the trigger Category dropdown.

PCR Educator has added the Household trigger type so that schools can send a single message per family for events that are inherently household-level, such as tuition billing, re-enrollment, annual giving, and emergency communication. This is a major step forward for schools that have wanted family-level automation without the duplication that comes from looping over each student.

The Household trigger appears in the Category dropdown for any school running notifications on a supported build.

How the Household trigger works

The Household trigger reads from the Household record as its primary scope. The condition query is written against Household fields, and the resulting message is addressed to the household rather than to a single student.

The Household trigger supports the full set of suppression controls. See Notification Trigger Suppression for the SendOncePer, MaxFiresPerScope, and PeriodScopeSchoolId fields and how each is evaluated.

Roles required

The Notification Triggers page is restricted to users with the Security Full role. The same role is required for creating and editing Household triggers.

Configuring Household Trigger

• Open the Notification Triggers page in Campus.
• Click Add Trigger.
• In the Category dropdown, select Household.
• Define the condition query against the Household record.
• Set the message template, recipients, and schedule.
• Optionally set the suppression fields described in Notification Trigger Suppression.
• Save the trigger.

Example: A trigger that fires when a household has any unpaid invoice over thirty days past due, configured with SendOncePer set to one fire per billing cycle.

Use cases by department

Business office and finance

• A tuition past-due reminder that fires once per household per billing cycle rather than once per student.
• A reminder to refresh autopay banking information, capped at one fire per household per year.

Admissions and enrollment management

• A re-enrollment open notification that lands once per returning family on the published open date.
• A withdrawal-risk outreach trigger for households flagged by year-over-year engagement scoring.

Advancement and development

• A capital campaign pledge reminder gated by SendOncePer so donors are not approached twice in the same quarter.
• A legacy family milestone notification when cumulative household giving crosses a recognition threshold.
• A parents association membership renewal reminder tied to the household record.

Notification Trigger Suppression is a set of controls on every Notification Trigger that limits how often the trigger may fire, both per target record and across the school as a whole. Suppression keeps automated communication useful by preventing the same family, student, or staff member from receiving the same message more often than the school intends, and by capping the total number of fires for high-risk triggers within a defined period.

Suppression applies to every trigger Category, including Student and Household. When a quota cap is reached, the trigger is suppressed quietly. The underlying condition query is not modified, and no error is raised.

Roles required

The Notification Triggers page is restricted to users with the Security Full role. The same role governs all trigger Categories and all suppression fields.

Suppression fields

Every Notification Trigger exposes the following fields.

• SendOncePer defines the minimum interval that must pass between two fires of the same trigger for the same target record. The interval is anchored to the school's calendar period.
• MaxFiresPerScope caps the total number of fires for the trigger within the defined period, counted across all target records at the school.
• PeriodScopeSchoolId identifies the school whose calendar period anchors both the SendOncePer interval and the MaxFiresPerScope window. The period boundary follows the school's fiscal or academic calendar as configured.

Note: SendOncePer is evaluated per target record. MaxFiresPerScope is evaluated across the school. The two fields are independent and may be used together.

How suppression is evaluated

When a Notification Trigger is scheduled to fire, the system performs the following checks in order.

• The trigger condition query is evaluated against the target Category, producing a candidate set of records.
• For each candidate record, the SendOncePer interval is checked against the trigger's fire history. Candidates that fired within the interval are dropped.
• The MaxFiresPerScope cap is checked against the trigger's fire history for the current period. If the cap has been reached, the remaining candidates are dropped.
• The trigger fires for the surviving candidates, and the fire history is updated.

Example: A trigger with SendOncePer set to one fire per billing cycle and MaxFiresPerScope set to five hundred fires per cycle will fire at most once per target record and at most five hundred times in total across the school within a single billing cycle.

Configuring suppression

• Open the Notification Triggers page in Campus.
• Open the trigger to edit.
• Set SendOncePer to the desired per-record interval.
• Set MaxFiresPerScope to the desired total cap, or leave blank for no cap.
• Set PeriodScopeSchoolId to the school whose calendar anchors the period.
• Save the trigger.

Note: Leaving SendOncePer blank allows the trigger to fire on every evaluation cycle that matches the condition. Leaving MaxFiresPerScope blank removes the total cap. Both behaviors may be appropriate for low-volume triggers, but should be reviewed before saving.

Use cases

• A tuition past-due reminder configured with SendOncePer set to one fire per billing cycle, so the same household receives the reminder at most once per cycle.
• A capital campaign pledge reminder configured with SendOncePer set to one fire per quarter, so donors are not approached more than once per quarter.
• A severe weather closure notice configured with MaxFiresPerScope set to a sensible cap per academic term, so a string of incidents does not generate excessive messages across the school.
• A re-enrollment reminder configured with SendOncePer set to one fire per enrollment season, so each family receives a single reminder per season.

Note: Suppression applies to the trigger itself. If two separate triggers are configured to send similar messages, each trigger maintains its own suppression history.

PCR Educator's check-in / check-out kiosk has grown from a simple sign-in log into a connected workflow that touches attendance, billing, admissions, and advancement. With the May 2026 release tying the kiosk into period attendance, this is a good moment to look at every workflow it now supports. Most schools use one or two. The module supports nine.

What it does

Front-desk sign-in and sign-out. Receptionist records a student or staff arrival or departure with a reason code, a comment, and a full audit trail on both legs of the trip.

Period attendance write-back. New in May 2026. Mid-day sign-out marks the in-session period Leaving Early. On return, the in-session period flips to Late and missed periods reconcile cleanly. Teacher entries are never overwritten.

Aftercare and extended-day billing. A fee schedule maps each program and time window to a billable product. The business office reviews matched records and runs Create Invoice to post line items to family ledgers in a batch.

Self-service family kiosk. Parents, students, emergency contacts, and authorized pickups can sign in or out using credentials, a student ID scan, or a five-digit pincode. Pincode scope is configurable as unique per household or unique across the database.

Bulk dismissal and field trips. Multi-action surfaces in the student list let a coordinator check an entire cohort in or out with one click.

Health office and counselor visits. Programs and reasons are lookup driven, so the same kiosk handles Health Office, Counseling, Late Pickup, and Early Release with their own audit trails on the student profile.

Reporting in Administrator and Finance. The same list view is mounted in both roles, so each team sees the records it owns through familiar filters and saved queries.

Mail and email merge. Templated letters and emails run directly off a selection of check-in records, with merge fields tied to the entity.

Admissions and donor event check-in. A dedicated event flow matches an inquirer's or donor's household to admissions and advancement events scheduled within plus or minus one hour of the current time, then credits attendance to the right event.

Why it matters

The lobby kiosk and the rest of the platform now share one record. Front-desk staff, faculty, the business office, admissions, and advancement see the same student under the same household, with the same audit trail. Emergency rosters reflect who is on campus right now. Aftercare invoices match the time the family actually picked up. Period attendance reflects the kiosk in real time. The work that used to live in different systems, or in different spreadsheets, now lives in one.

A few ways to talk about it

• One kiosk, nine workflows, one student record. From morning arrival to admissions tours to aftercare invoicing.
• The May 2026 release ties sign-out and return directly to period attendance. Teacher entries always win.
• Most schools are using one or two of these. The other seven are already in your platform.

Available now to all PCR Educator schools. Your account team can walk you through any of the nine workflows whenever you are ready.

PCR Educator filters now support count, sum, and average conditions, the same aggregate logic that has long lived inside DAT queries. Schools can build saved filters that find students based on how many records they have or how much something totals, then drop those filters into notification triggers, contracts, or anywhere else a saved filter is used.

What you can build

Aggregate filters answer the questions schools ask every day:

• Students with more than 8 absences this semester
• Students with more than 4 discipline points in the current marking period
• Students with at least 3 tardies in any marking period
• Students who have any record in a given table

Build the filter once. Reuse it everywhere a saved filter is selected.

Key capabilities

Six aggregate functions. Sum, Count, Count Distinct, Average, Min, and Max are available across supported fields.

Time-window scoping. Combine aggregate conditions with marking period, semester, academic year, admissions year, fiscal year, or development year, so counts stay inside the window that actually matters.

Round-trip editing. Save an aggregate filter, reopen it, and the condition reads cleanly (for example, "Count of records > 4").

Plain-English filter descriptions. Saved aggregate filters describe themselves in the filter list and pickers, so the next person who picks one up understands what it does at a glance.

Why it matters

A request like "find students with more than 4 discipline points in the current marking period" used to require a custom DAT report or a one-off query. Now it is a single saved filter that any teacher, advisor, or admin can reuse, drop into a notification trigger, or attach to a contract. Logic that lived only in the reporting layer is now usable across the system, in the same place schools already manage their saved filters.

A few ways to talk about it

• Filters now ask aggregate questions: count, sum, average, min, max, count distinct.
• Save once, reuse everywhere: notification triggers, contracts, and any picker that takes a saved filter.
• Time-aware counts: scope to marking period, semester, academic year, admissions year, fiscal year, or development year, so the math matches the calendar.

Available now to all PCR Educator schools. Your account team can walk through example filters whenever you're ready.

PCR Educator notification triggers can now fire on a school-calendar rhythm: once per marking period, once per semester, or up to N times per academic year. The new period-aware quotas sit alongside the existing rolling-day floor, so schools control exactly how often a parent or staff member hears from the system.

What's new

"Maximum fires per" period quotas. A new dropdown on every trigger caps notifications by Marking Period, Semester, or Academic Year. Combine it with "Maximum number of fires" to express patterns like "up to 3 escalation emails per semester."

"Minimum days between fires" (renamed for clarity). The legacy frequency floor now reads exactly as it works. Period quotas and day floors apply independently, so a single trigger can be both "at most 3 per semester" and "at least 14 days apart."

"School division for period." Students sit in many divisions at once, so the admin explicitly picks which division's calendar defines the period boundaries. The dropdown appears only when the scope needs it, requires a selection, and includes three layers of safeguards so a misconfigured trigger never silently skips suppression.

Framework-level coverage. Attendance, gradebook, discipline, balance-low, action reminders, and any future trigger type inherit the new options automatically, with no per-type configuration work.

Why it matters

Suppression now aligns to the actual school calendar. Configure "semester, max 3 fires" once and a 4 / 7 / 9 absence escalation ladder resets cleanly when the semester turns over. Parents see the right number of messages at the right cadence, and admins stop approximating "a semester" with a day count that drifts from the calendar. Existing triggers keep running exactly as they do today, because the new options are additive and opt-in per trigger.

A few ways to talk about it

• Notification triggers now speak your school's calendar: once per marking period, once per semester, or up to N times per academic year.
• Configure escalation ladders in one place. 4 absences, 7 absences, 9 absences. Three emails per semester, not three hundred.
• Two independent rules, one trigger: minimum days between sends, plus maximum sends per period. Both apply, both protect parents from email overload.

Available now to all PCR Educator schools. Your account team can walk you through the new dropdowns whenever you're ready.

Your check-in / check-out kiosk now updates period attendance in real time. When a student signs out mid-day, the class in session is marked Leaving Early (or your school's configured code), and the rest of the day can auto-mark as Absent. When that student returns, the record reconciles itself: the in-session class flips to Late, and any missed periods in between are filled in cleanly.

What's new

Real-time mid-day check-out. Current period reflects the student's status the moment they sign out.

Automatic reconciliation on return. The system recognizes a student coming back and adjusts the record without anyone touching the grid.

Teacher entries always win. The kiosk only updates rows it created. Manual teacher entries stay untouched, so the classroom remains the source of truth.

Configurable per school. Leaving Early, Absent, and Late codes come from your existing widget settings. Your wording, your policies.

Every sign-in mode supported. Username and password, student ID, and PIN-only kiosks all run the same integrated flow.

Full audit trail. Every automatic change is logged for administrator review.

Why it matters

Emergency rosters reflect who is actually on campus right now. Teachers see accurate period attendance the moment a student walks back in. Front-desk staff and faculty stay aligned without extra steps, and your school keeps full control over the codes applied in every scenario.

Available now to all PCR Educator schools using the check-in / check-out kiosk. Your account team can walk you through the configuration options whenever you're ready.

The Actions (Delete) multi-action allows mass deletion of selected students' actions. To access this multi-action, navigate to Administrator > Students. You need the Admin Full, Admin Read, Registrar Full, or Registrar Read role to access this page. You need the Actions Full role to use this multi-action. Select the desired students, and choose the multi-action Actions (Delete).

On the following page, choose the academic Year and the Action. Click the "Delete Actions & Files" button to delete the matching actions along with any files attached to them. To remove only the files attached to those actions and keep the actions themselves, click the "Delete Files Only" button instead.

We have refined two parts of the PCR Educator interface to give you a cleaner workspace and quicker access to the controls you use most.

Main selectors now live in the menu. Year, term, division, ledger, and other context controls are consolidated in the main menu.

Widget configuration is now on each widget. Click the settings (gear) icon on any widget to open its configuration. Every option you had before is one click away.

The result is more room to work, more consistent navigation across modules, and a stronger foundation as we continue to expand the platform.

Our support team is happy to walk you through the new layout anytime.

Stripe Vendor Payment is a Finance feature in PCR Educator that lets your school send electronic payments to vendors through Stripe Financial Connections, replacing paper checks with direct ACH transfers. Vendors connect their own bank accounts through the vendor portal, so your finance team does not collect or store vendor banking information.

This article walks through the school-side setup. Setup takes about 15 to 20 minutes of work on your end, plus 1 to 2 business days for Stripe to verify the application.

Required role: To configure Stripe Vendor Payment, the user must have access to Finance > Maintenance in PCR Educator.

Before you start

Please have the following ready:

• An authorized financial signer who can complete Stripe's identity and business verification.
• Your school's banking details for the payout account.
• The General Ledger account you want tied to electronic payouts.

Creating the Stripe Financial Connections account

• Go to https://stripe.com and click Sign up. If your school already has a Stripe account, log in instead.
• When prompted to select a product, enable Stripe Financial Connections.
• Complete the business verification fields. When Stripe asks how your platform is configured, use the values below exactly. These match the integration PCR Educator has built against Stripe Connect. Changing them will cause the connection to fail.

Funds flow: Buyers will purchase from you. Sellers will be paid out individually.

Industry: Business management software

Account creation: Onboarding hosted by Stripe

Account management: You will redirect sellers to the Express Dashboard to manage their Stripe account.

Liability for refunds and chargebacks: You are responsible for refunds and chargebacks to buyers.

• Confirm the Connect Platform Agreement when prompted.
• Submit the application. Stripe typically verifies within 1 to 2 business days.

Sending the Stripe Customer ID to PCR Educator

Once Stripe approves your account:

• From your Stripe dashboard, copy your Stripe Customer ID. This is the identifier PCR Educator uses to link your school's Stripe account to your PCR Educator portal.
• Send the Stripe Customer ID to PCR Educator support through your established secure channel. Do not email it in plain text.
• PCR Educator will configure Stripe as a payment method on your portal and confirm when it is live.

Note: At this time, the Stripe Customer ID is configured by PCR Educator support on your behalf. A self-service field is on the roadmap.

Connecting the payout account

Once PCR Educator confirms Stripe is configured on your portal:

• Log in to PCR Educator.
• Navigate to Finance > Maintenance > External Payment Accounts.
• Click New and select your connected Stripe account.
• Link the payout account to the General Ledger account you want associated with electronic payouts.
• Save.

Your payout account is now active and available for payment runs.

Inviting vendor to the vendor portal

Vendors connect their own bank accounts through the PCR Educator vendor portal. Your team does not collect, store, or manage vendor banking information.

To send invitations:

• Go to Finance > Vendors.
• Select the vendors you want to onboard.
• Use the Send Vendor Portal Invitation action.

Each vendor receives an email with portal credentials and a link to connect their bank account.

Running electronic payment

When your finance team generates a payment batch and selects a Stripe-enabled payout account, the system automatically issues electronic transfers to every vendor with an active connected bank account. Vendors who have not yet connected a bank account continue to receive paper checks. Both methods run inside the same payment batch.

Common question

Do we still need to print checks? Only for vendors who have not connected a bank account through the portal. The system handles both methods in one payment run.

Where do vendors see their payment status? The vendor portal displays pending and completed payouts.

What if a vendor's bank details change? Vendors update their own information through the portal. No action is required from your finance team.

Are there transaction fees? Stripe charges standard ACH fees per transfer. Review Stripe's current pricing on their website.

Can we reverse an electronic payment? Once submitted, ACH transfers follow Stripe's standard reversal rules. Contact PCR Educator support immediately if a payment was issued in error.

For help with any step, open a ticket through the PCR Educator customer portal. Include your school name and the step where you are stuck.

• Default is used for most products.
• Deposit is originally used for (Re) Enrollment Contract deposits.  Note: There is no functional difference between Default and Deposit.  Both allow specifying a Deposit amount in the left menu.  The Deposit option is retained for backwards compatibility only.  Use Default instead. Note: When a Deposit Account is specified on the product, the system will use the Deposit Account when recording the transaction. If no Deposit Account is specified, the system will default to the Revenue Account associated with the product.
• Discount is for Summer Camp and POS purchases.
• Donation is for specifying online donations.
• Fee (Fixed Amount) is used for fee products where a fixed amount is applied.  Example: ECheck convenience fees are usually a fixed amount.  Note: Permissible values for fees may be subject to state or local regulations.
• Fee (Percentage) is used for fee products where a percentage is applied.  Example: Credit Card convenience fees are usually a percentage. Note: Permissible rates for fees may be subject to state or local regulations. Example: late fees are usually a percentage.

• A DAT Query
• A list of entities (such as the list of students, courses, or households)
• CMS portal as a mechanism to restrict the visibility of certain elements
• Automated Notifications as a mechanism to determine  the list of recipients
• (Re)Enrollment Contracts and Forms to determine the list of eligible households and students

• Initializing DAT Filter
• Initializing DAT Filter from DAT Query
• Initializing DAT Filter from List
• Adding DAT Filter Condition
• Creating New DAT Filter
• Filter Group
• Creating Filter Group
• Using Filter Groups on Lists

• DAT Query - Step 1 - Adding Conditions
• DAT Query - Step 1 - Connecting Tables

• Managing DAT Filter Conditions
• Saving DAT Filter
• Managing DAT Filter
• Deleting DAT Filter
• Reviewing Existing DAT Filter
• DAT Query and DAT Filter Common Mistakes

1. Click on the table name that would be used for the new filter.
2. Under “Conditions” pick “New Filter” from the available choices.
3. Click on the blue filter (funnel) icon.

1. DAT Query - Step 1 - Adding Conditions
2. DAT Query - Step 1 - Connecting Tables

1. Click Save on a DAT Filter popup window.  Note: You can replace an existing filter by choosing it from the dropdown on the Save screen.
2. Managing DAT Filter

• Filter Group
• Filter

1. Navigate to Campus > Home > Filter Setup > Filter Groups
2. Click New
3. Enter a Group Name for the Filter Group
4. Enter Group Owner
5. Enable Is Public if the Filter Group should be visible to other users
6. Click Save

• Navigate to Admin > Maintenance > Official Reports, or open the student record and review Progress PDF, Report Cards PDF, or Transcripts PDF.
• Confirm that the report has an Available Date.
• Confirm that the Available Date has already passed.
• Confirm that the Available Date is correct for your school's time zone in Application Setup (CMS/Website).
• Review the Household saved on the archived report. Archived reports are generated for qualifying primary households. If a student has multiple send mail households, each qualifying household receives its own copy.
• If the student had an academic hold or financial hold, confirm whether the report was intentionally archived with a later Available Date.
• If grades, comments, or an incomplete changed after the report was first archived, re-archive the report using Overwrite.
• Confirm that the parent is checking the Student area of the Parent Portal, where archived report cards and transcripts are displayed for download.