Examples

The following examples give you an idea of what you can accomplish using Smart Events and Smart Rules. Most of the examples include conditions that are used to guide the outcomes. It’s helpful to understand that a condition has a different purpose depending on whether it is used in a Smart Event or a Smart Rule:

If you are new to Smart Events and Smart Rules, take a look at the Smart Event Walkthrough before proceeding.

Smart Events

Use a custom field to track new business on a sales order

This example uses the API to select a New Business custom field checkbox on a sales order transaction document for a new customer (less than six months old). The example assumes there is a Start Date custom field on the customer record.

Object: Order Entry Transaction

Document Type: Sales Order

Events: Add, Set

Condition

The condition evaluates to true if the customer’s start date was within the last six months.

{!SODOCUMENT.CUSTOMER.START_DATE!} > pastdate(6,"month")`

API Body

<update_sotransaction key="{!SODOCUMENT.DOCID!}" disablevalidation="true">
    <NEW_BUSINESS>true</NEW_BUSINESS>
</update_sotransaction>

Use a custom field to indicate that a customer is no longer new on a sales order

This example uses the API to deselect a New Customer custom field checkbox on the customer record when that customer has been engaged for more than six months. The example assumes there is a Start Date custom field on the customer record.

Object: Order Entry Transaction

Document Type: Sales Order

Events: Add, Set

Condition

The condition evaluates to true if the customer’s start date was more than six months ago.

{!SODOCUMENT.CUSTOMER.START_DATE!} < pastdate(6,"month")

API Body

<update_customer customerid="{!SODOCUMENT.CUSTOMER.CUSTOMERID!}">
<NEW_CUSTOMER>false</NEW_CUSTOMER>
  </update_customer>

Add sales rep to the invoice header using a standard field

The example adds a customer sales rep’s print as field to the sales invoice header, so it can be printed on a custom invoice template. The example gets the sales rep from the related CUSTREP object on the customer record. The example assumes there is a SALES_REP custom field on the header level of Order Entry transactions.  

Object Order Entry Transaction

Document Type: Sales Invoice

Events: Add

API Body

<update_sotransaction key="{!SODOCUMENT.DOCID!}" disablevalidation="true">
    <customfields>
        <customfield>
            <customfieldname>SALES_REP</customfieldname>
            <customfieldvalue>{!SODOCUMENT.CUSTOMER.CUSTREP.CONTACT.PRINTAS!}</customfieldvalue>
        </customfield>
    </customfields>
</update_sotransaction>

Add sales rep to the invoice header using an employee dimension

The example adds an employee’s print as field to the sales invoice header, so it can be printed on a custom invoice template. The example gets the sales rep from the related employee object on the first line of the entries. The example assumes there is a SALES_REP custom field on the header level of Order Entry transactions.  

Object Order Entry Transaction Line

Document Type: Sales Invoice

Events: Add

Condition

The condition evaluates to true if the first line item on the invoice has an EMPLOYEENAME value that differs from the SALES_REP value on the invoice itself.

{!SODOCUMENTENTRY.LINE_NO!} == 0 && "{!SODOCUMENTENTRY.EMPLOYEENAME!}" != "{!SODOCUMENTENTRY.SODOCUMENT.SALES_REP!}"

API Body

<update_sotransaction key="{!SODOCUMENTENTRY.DOCHDRID!}" disablevalidation="true"> 
  <customfields> 
    <customfield> 
      <customfieldname>SALES_REP</customfieldname> 
      <customfieldvalue>{!SODOCUMENTENTRY.EMPLOYEE.CONTACT.PRINTAS!}</customfieldvalue> 
    </customfield> 
  </customfields> 
</update_sotransaction>

Send email when a customer is added

This example helps track customer creation by sending email when a customer is added.

Object: Customer

Events: Add

Email Subject

{!COMPANY.TITLE!} | customer {!CUSTOMER.CUSTOMERID!} has been created

Email Body

For company {!COMPANY.TITLE!} a customer {!CUSTOMER.CUSTOMERID!}--{!CUSTOMER.NAME!} has been created/edited 
by {!CURRENTUSER.LOGINID!} -- {!CURRENTUSER.DESCRIPTION!}`

Send email when a class is added or edited

This example helps track class creation by sending email when a class is added or edited.

Object: Class

Events: Add, Set

Email Subject

{!COMPANY.TITLE!} | customer {!CLASS.CLASSID!} has been created/edited

Email Body

For company {!COMPANY.TITLE!} a class {!CLASS.CLASSID!}--{!CLASS.NAME!} has been created/edited by {!CURRENTUSER.LOGINID!} -- {!CURRENTUSER.DESCRIPTION!}

Send email when a journal entry is made on a designated account

This example sends email when a journal entry is added or modified for a given account.

Object GL Entry (AKA Journal Entry Line)

Events: Add, Set

Condition

{!GLDETAIL.ACCOUNTNO!} == 1205

Email Subject

{!COMPANY.TITLE!} | Inter Entity Receivable Entry in Journal {!GLENTRY.BATCHNO!}

Email Body

The Inter Entity Receivable Account was entered in Journal Entry Number {!GLENTRY.BATCHNO!}.  

Details:
Transaction Date: {!GLENTRY.EXCH_RATE_DATE!}   
Line Number: {!GLENTRY.LINE_NO!}   
Account Number:  {!GLDETAIL.ACCOUNTNO!}--{!GLDETAIL.ACCOUNTTITLE!}   
Transaction Amount:  {!GLENTRY.CURRENCY!} {!GLENTRY.TRX_AMOUNT!}   
Location Dimension: {!GLENTRY.LOCATION!} -- {!GLENTRY.LOCATIONNAME!}   
Date Created: {!GLENTRY.WHENCREATED!}

Send email when a project is created or updated

This example sends email when a project is created or edited.

Object: Project

Events: Add, Set

Email Subject

Project {!PROJECT.PROJECTID!} has been created or edited

Email Body

Note that CURRENTUSER is the user that performed the action that caused the Smart Event to execute.

Project {!PROJECT.PROJECTID!} in company {!COMPANY.TITLE!} was created/edited by {!CURRENTUSER.LOGINID!} -- {!CURRENTUSER.DESCRIPTION!}.

Send email when a high priority bill is entered

This example sends email when a a high priority bill is entered. The example assumes there is a HIGH_PRIORITY custom field on the header level of AP Bill.  

Object: AP Bill

Events: Add, Set

Condition

{!APBILL.HIGH_PRIORITY!} == "True"

Email Subject

{!COMPANY.TITLE!} | Bill Number {!APBILL.RECORDID!} has been created/edited

Email Body

A bill marked as high priority has been entered or edited by {!CURRENTUSER.LOGINID!} -- {!CURRENTUSER.DESCRIPTION!}. 

Bill detail:
Bill number: {!APBILL.RECORDID!}
Vendor Name:  {!APBILL.VENDORNAME!}
Due date: {!APBILL.WHENDUE!}
Total amount: {!APBILL.TOTALENTERED!}
Total paid: {!APBILL.TOTALPAID!}
Total due: {!APBILL.TOTALDUE!}
Bill URL: {!APBILL.RECORD_URL!}

Smart Rules

Prevent creating records at the top level

In a multi-entity environment, you might want to require users to switch to an entity before creating records.

Object: Invoice

Rule Type: Error

Events: Add, Set

Condition

The condition CONTEXTLOCATION returns ROOT if at the shared top level, or if slid-in it returns [LOCATIONKEY]--[LOCATIONNAME] of the entity.

left("{!USERPROFILE.CONTEXTLOCATION!}", 4) != "ROOT"

To reverse this and force records to be created at the top, change the condition to be ==.

Error Message

You cannot add this record at the context location, {!USERPROFILE.CONTEXTLOCATION!}.

Prevent Vendor Invoices from posting greater than 30 days in the future

This example uses a Smart Rule to provide a warning when a Purchasing transaction has a GL posting date more than 30 days in the future.

Object: Purchase Order Transaction

Document Type: Vendor Invoice

Rule Type: Warning

Events: Add

Condition:

The condition evaluates to true if the posting date is not more than 30 days in the future. If the date is more than 30 days out, the rule is broken and a warning is sent.

{!PODOCUMENT.WHENPOSTED!} < pastdate(-30, "day")

Error Message

You have added a Purchasing transaction with a GL posting date greater than 30 days in the future.

Prevent direct journal postings to a GL account

NEW!

Transactions posted to sub-ledger applications, such as Accounts Receivable, Accounts Payable, or Cash Management, are automatically posted to the General Ledger in real-time. However, posting a journal entry directly to a GL account does not automatically tie it back to the appropriate subledger. This example shows you how to block direct posting to the GL account if this better reflects your use model.

The example creates a boolean custom field on GL accounts, then provides a Smart Rule that blocks direct posting based on the value of that field.

Custom field

Create a custom field on the desired GL account.

Object GL Account

Data Type: Check Box

Label: Block GL Posting

Default Value: Unchecked

Field ID: BLOCK_GL_POSTING

Smart Rule

Create a Smart Rule on the GL Entry object to prevent direct posting based on whether Block GL Posting is checked on the GL account.

Object GL Entry

Type: Error

Events: Add and Set

Condition:

{!GLENTRY.GLACCOUNT.BLOCK_GL_POSTING!} != "" ? false : true

Error Message:

Line {!GLENTRY.LINE_NO!} - Posting directly to GL Account {!GLENTRY.GLACCOUNT.ACCOUNTNO!}--{!GLENTRY.GLACCOUNT.TITLE!} is not allowed.

Smart Rule ID: GLENTRY_BLOCK_GL_POSTING

More information

See the Sage Intacct product help for more information about:

Provide feedback