Overview & Terminology

This article describes Rules Engine - part of YayPay Collection Workflows that allows to react to different Events/Triggers and take configured actions. 

Collection Workflow (CW) - A component that configures a set rules to be executed for assigned customers based on certain events. Collection Workflow can be assigned to any number of customers in YayPay. One customer can only be assigned to one CW. There are multiple places in YayPay where one can assign Customers to a collection workflow - Aging Report, Excel Mapping in Business Settings. CW consists of the Timeline Workflow and Rules Engine.

Rules Engine (RE) - The new part of CW that allows you to configure individual workflow rules. That leads to unlimited workflow flexibility, reacting to dozens of different events (such as Dispute is opened, or Payment is declined) by taking any number of actions (such as Send Email, Create TODO Item, add a Note to a customer record, etc.).

Rule - An individual component of the RE configured via the Add new rule or Edit workflow dialog, consisting of the following elements:

• Event - Defines an event that YayPay waits for to trigger the configured actions.
  For more information about rule events, see the Rules Engine Events‍ article.
  
• Condition - Defines (optionally) a condition that checks if a given rule should apply to a particular customer or invoice. You can define multiple conditions.
  For more information about rule conditions, see the Custom Conditions in Rules Engine‍ article.
  
• Action - Defines an action that YayPay executes if the given event is triggered and the given conditions are met. You can define multiple actions.
  For more information about rule actions, see the Rules Engine Actions‍ article.
  

Scope - Describes the object the Rule reacts to. If an event is generated on the Customer level, then the scope is Customer. It is in the Invoice scope if the Event is triggered by an Invoice, and the same for Payment Scope, if it is triggered by a Payment. The Scope identifies what objects Conditions and Actions can work with. For example, if the event is in Customer scope, we can't be having Invoice conditions there, because the system does not "know" what invoice it should be looking at.

Timeline Workflow (TW) - A legacy part of CW. It allows you to add a series of time-related events, send email reminders and schedule calls with a customer based on those timeline events. Only such timeline events as "X days before/after the due date" and "X days after creation date" can be configured there.

Global Rules (GR) - this component is built and works exactly like Rules Engine, except for rules defined in GR are automatically applied to all Customers currently in YayPay. Is independent of the CW engine, you don't need to assign GR to any customers for it to start working. You can exclude customer(s) from GR if needed.

Also, see Global Rules.

Automated (Email) Reminder - Email reminder triggered and sent from one of the Collection Workflows, independently if it was sent from Timeline or Rules Engine. 

Manual (Email) Reminder - Email reminder that is sent by the finance team from Aging Report, Invoices, or Statement page in YayPay. 

Email Templates - You can configure any number of Email Templates which can be re-used in a repeatable manner across different Rules within the same or different Workflow. Refer to this Article link. 

Dynamic Tags (DT) - special tags that could be used in Email Templates, that are automatically replaced with the actual value at the moment when an email reminder is sent. A couple examples of DT are {CustomerCompanyName} and {StatementBalance}, which are replaced with actual values when email is sent. For more information, see the Dynamic Tags in Email Templates‍ section of the Creating Email Templates article.

Collection Workflow Settings

To configure a set of rules to be executed for assigned customers based on certain events, go to the Workflows page and either click on an already created Collection Workflow (CW) or on the ADD WORKFLOW button. This opens a respective workflow page:

To configure the workflow's settings, click on the Workflow settings icon located next to the workflow's name. This opens the Workflow settings dialog with the following options:

Collection workflow settings impact both Timeline Workflows and Rules Engine. 

Workflow "Active" Setting

If this setting is ON, this workflow will send triggering configured events for assigned customers. If this is OFF - none of the events will be executed. 

The activities on assigning, unassigning, and pausing the workflows are displayed under the CHANGE LOG tab on the Statement page:

Default Workflow

If selected - this workflow will be automatically assigned to all new Customers added to YayPay. 

Use Invoice billing contacts

By default, YayPay uses the Customer-level Billing contacts as recipients in the Email Reminder Action within a Collection Workflow (you can configure the Workflow to add Non-Billing contact(s) in the Recipients)

Select this option to overwrite the default for the Workflow to send Email Reminders to the email contact(s) linked to Invoices, instead of the customer billing contact(s). Refer to this article https://yaypay.helpjuice.com/en_US/71918-statement/customer-level-contacts-and-or-invoice-level-contacts for an overview of contacts in YayPay

When selected, CW Reminders will group the invoice reminders by the billing contacts before sending email reminders to the invoice-level billing contact(s).

For example, if a customer has 5 invoices, and 3 of them have billing contact "projectA@customer.com" and the other 2 have "another-project@customer.com" billing contacts and this setting is selected, then email reminders related to the 5 invoices will be sent to the 2 respective invoice billing contacts under the customer. 

One will list 3 invoices and another will have 2 invoices. 

Send to customer billing contacts (Cc:)

This Workflow Setting is enabled only when the option "Use Invoice Billing contacts" is selected,

If enabled, it will include customer-level billing contact as CC in all the automated reminders to billing contacts, grouped by invoice. 

For example, if Customer A has a billing contact "customerbc@customer.com" and invoices have individual billing contacts, e.g., "invoice-group-a@customer.com" and "invoice-group-b@customer.com", then reminders will be sent to those emails separately, but both will CC "customerbc@customer.com".

Run for oldest invoices only based on

If your customer has multiple open invoices at the same time, and you want to send only one email reminder, i.e. you don't want to send an individual reminder for every invoice, you can use this workflow setting. To do so, check the Run for oldest invoice only check box and select one of the following options:

• Creation Date – Triggers the rule for the invoices with the earliest creation date.
• Due Date – Triggers the rule for the invoices with the earliest due date.

If checked, Collection Workflow (CW) will only take into account the oldest invoice for:

• Customers. See also the Caution box below.
• Groups of invoices grouped by the selected invoice billing contact. This only applies if Use invoice billing contacts is checked.

In addition, checking the Run for oldest invoice only check box affects the following actions:

• Actions in the Timeline rules:
  • Send an email reminder.
  • Schedule a call.
• Actions triggered by the X days after invoice date and X days before/after invoice due date events:
  • Send an email reminder action.
  • Send group email reminder action.
  • Create ToDo action.
  • Schedule a call action.

These actions do not occur if the invoice is not the oldest.

For example, if a customer has 3 open invoices:

• Invoice 13, created on Jul 7, 2019
• Invoice 14, created on Jul 19, 2019
• Invoice 15, created on August 1, 2019

And if a Collection Workflow (CW) has multiple rules configured that trigger automated email reminders based on the number of days after the creation date, then the CW will only look at the creation date of the customer's oldest invoice, which is In Invoice 13.

Do not send a reminder if ERP PDF is missing 

At the point of the trigger of an Invoice/Credit Memo Event within the Workflow/Global Rules, it could be that your Document PDF is delayed or not yet synced from your ERP to YayPay, which also includes situations where the PDF is obtained via the PDF Email (Scrape) functionality, and a gap in time could exist between the Document created in YayPay and the PDF pulled into the system. 

This checkbox helps to address these scenarios where if the Invoice/Credit Memo that triggered the action does not have the PDF yet, no email reminder will be sent for the Document, while the system retries for the next 3 days.

As a summary, this is how it works in cases where the WF action is to "Send an Email Reminder" and this checkbox is enabled, the system first checks for the presence of the Document PDF.

If YayPay has the ERP PDF, an email reminder action will take place with no need for further retries

If YayPay does not have the ERP PDF, no email reminder action will take place, and the system will retry for the next 72 hrs as it keeps checking for ERP PDF to complete the Invoice/Credit Memo triggered event and action.

Exclude Invoices Before

When you turn on workflows for the first time, and you have a lot of open invoices already, you may not want customers to start receiving reminders based on the very old, outdated invoices. 

If this is the case, you can configure the Date in this setting and none of the reminders will be triggered by invoices that are created before this date.

Sending Time & Timezone

This setting allows configuring when you want automated email reminders to be delivered to your customers. Read the section "Sending and Cut-off Time" below to understand how it works in detail. 

Total Amount of an Invoice

This setting allows configuring the size of the invoice to be taken into account by this Collection Workflow. E.g. if you set Min to $5 and Max to $1000 - only invoices that have the Total Amount of an invoice within those boundaries will trigger automated reminders. 

Use Business Currency for Custom Conditions 

By enabling this checkbox, you can set up thresholds in custom conditions in your business currency, which implies the following: 

• Invoice and Payments events: all the number fields in custom conditions (including custom fields) will be multiplied by the document exchange rates for the corresponding entity currency unless the setting "Use daily exchange rate" is enabled
• Customer events: all the number fields in custom conditions (including custom fields)  will be multiplied by OANDA exchange rates

Sending & Cut-off Time

Currently (Sep 2021), independently of what time is configured in the Sending Time & Timezone setting of a Collection Workflow, there is a cut-off time, which is daily at 1 AM EST. 

This means that for Time-related Rules the decision of whether the Email reminder is going to be triggered is made at 1 AM Eastern Time daily. 

Let's look at the example. 

If we have a Rules Engine rule configured as follow:

Let's say right now is August 17, 1 AM EST - Cut-off time.

Let's also assume the Sending Time is configured to 4 PM EST (16:00 EST).

Here's what it means for the invoices:

* Displayed columns indicate the invoice age as it is displayed on the Aging Report and Statement Pages 

In this example, if Sending Time is set to 4 PM EST (16:00 EST), then at that time, Invoice 118 will already be 11 days after the creation date, and Invoice 15 will be 10 days after the creation date, but the reminder for this invoice will only be sent next day. 

Because of cut-off logic, if you make changes between Cut-off time and Sending Time, they will only take effect at the Cut-Off time the next day. 

The YayPay Product team is working on improving this logic and in the future, it is a subject to be changed. 

Consolidated Collection Workflow

Consolidated CW is an extension of the standard CW functionality applied for the particular case when YayPay Client has got a Parent (Holding) Company and Subsidiaries (of the first and second levels: "child" and "grandchild" companies) as Customers. 

Consolidated mode allows for email communications to aggregate information from the child companies to the Parent (e.g. the balance of each child company is reflected as the Parent company’s balance).

To enable Consolidated mode selectively for some Parent Customer(s) in YayPay:

1. Go to the Statement page of a Parent customer
2. Enable the Parent level collections checkbox found on the Settings tab towards the bottom of the page:

Consolidated mode not only changes the behavior of the Collection Workflows but also the way data is displayed on the Statement page and Customer Portal. 

If you select this option, the following things will be affected:

1. Consolidated Statement holds information on all invoices of the Parent Company and all Subsidiaries' invoices, consolidated Total Due.
2. CW, assigned to the Parent company, is now propagated to all its Children and will be executed if any of the Parent's or Children's invoices meet the conditions set.
3. All automated emails sent within Consolidated Collection Workflow will go to the Parent's Company contacts and will contain consolidated data (like Overdue Balance, Total due, the Oldest invoice date, link to the Consolidated Statement, etc).
4. If an automated reminder is triggered by Child's company invoice, the email will be sent to Parent's Company contacts and will contain information regarding the consolidated statement. There is an option to send a copy of the email to Child’s company contacts.
5. The exception is made for invoices with Invoice Billing Contact (IBC) assigned. If any invoice has IBC, and it triggers an automated reminder, the email will be sent to IBC. Information in the email will depend on if the invoice belongs to Parent Company (consolidated statement data) or Child Company (this particular statement data), and also will be filtered by IBC.
6. If the consolidated mode is disabled, CW still will be assigned both to the Parent and all Subsidiaries and should be unassigned/paused manually. In this case, each company will get its own data in automated reminders.
7. Once the consolidated mode is applied, the Child cannot be unassigned from the CW. CW cannot be paused for the Child company. All actions performed over Parent's CW will be propagated to Childs' CW.

Examples

Once an invoice engaged in the consolidated statement meets conditions set in the CW, an automated reminder is sent to the Parent Company contacts.

Email Reminder is triggered by the Parent's invoice:

1. the email goes to Parent's billing contact
2. Dynamic Tags have "Consolidated" values: there is data of the consolidated statement, including all subsidiaries;
3. Attachments are Consolidated: i.e. the oldest invoice is selected from all invoices of the parent and subsidiaries combined;
4. If "CC" to Child company contacts option is applied: Child's billing contact gets a copy of an email (not a separate email);
5. If Customer statement PDF is attached - it will be Parent company Statement PDF;
6. If Child statement PFD is attached: all statements of all Children are attached.

Email Reminder is triggered by the Parent's invoice AND Invoice Billing Contact (IBC) is configured

1. The email goes to this invoice IBC;
2. Dynamic Tags consider IBC: Billing contact is replaced with IBC, other contacts are Parent's, statement links lead to the statement with IBC invoices only; 
3. Total values and attachments are consolidated by the IBC group;
4. If "CC" to Child company contacts applied: email is NOT sent as there is no unambiguous linkage to Child Company for invoice group;
5. Customer statement PDF: is a statement of a Parent company;
6. Child statement PFD: all statements of all Children.

Email Reminder is triggered by the Child's invoice

1. The email goes to Parent's Billing Contact;
2. Dynamic Tags are "Consolidated" with the exception of CustomerCompanyName tag, which uses the name of Child company that triggered the reminder;
3. Attachments are Consolidated;
4. If "CC" to Child company contacts applied: Child's BC gets a copy (not a separate email);
5. Customer statement PDF: is of a Parent company;
6. Child statement PFD: this Child's statement, not all the children.

Email Reminder is triggered by the Child's invoice AND Invoice Billing Contact (IBC) is configured

1. The email goes to the Parent company;
2. Dynamic Tags consider IBC: Billing Contact is replaced with IBC, other contacts are Child's, statement links lead to the statement with IBC-grouped invoices only; totals and the oldest invoice data are consolidated for a Parent company;
3. Attachments are of a Parent-company consolidated set;
4. If "CC" to Child company contacts applied; Parent's BC, Child's BC, and Invoice BC get a copy.
5. Customer statement PDF: is of a Parent company;
6. Child statement PDF: triggering Child's statement.

Frequently Asked Questions

Q: On the Event "X Days after Invoice date", does the invoice date mean invoice Created At field as it is set in ERP?

Yes, X days after invoices date based on ERP Created At, which we are pulling into the same field in Yaypay.

Q: When an invoice is created with a future Invoice Date, will "X Days after Invoice date" execute only when the day after the Invoice Date comes?

Yes

Q: For the "Invoice is Created" event - it is triggering when the new invoice arrives from ERP, or when the Created At date comes (for future dated invoices)?

"Invoice is created" event triggers when an invoice arrives from ERP, including for invoices with the future date on them.

Note, if you create back-dated invoices, which are then imported to YayPay, "Invoice is created" will not work, as it only reacts to invoices imported to YayPay that have an Invoice Date within the last 24 hours. 

Q: What events are triggered at cut-off (1 AM EST) time?

Only the following events are affected by Cut-off time, the rest of the events trigger and execute actions immediately after the event happened:

• X days before/after due date
• X days after invoice date
• Promise to pay is broken
• X days after Workflow assignment date

Q: What Actions are affected by Sending Time setting of the workflow?

Sending time setting only affects Email action, all other actions will be executed at the moment when an event happened. 

Q: Which Event should I use for the initial invoice distribution?

We recommend using the "X days after invoice date" event and setting a configuration to 0 or 1 day after the invoice date. Do not use the "Invoice is Created" event if you have future-dated invoices in your system.