Smart Rule Examples

The following examples give you an idea of what you can accomplish using 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. Keep the cheat sheet handy, too.

Warn users that they’re adding a one-time use vendor

You can remind users that they selected the one-time use checkbox on the vendor detail page.

Object: Vendor

Rule Type: Warning

Events: Add

Condition

The condition ONETIME returns Yes if a vendor is created for one-time use.

{!VENDOR.ONETIME!}==False

Error Message

You just added a one-time use vendor; deselect the checkbox if this vendor will be used more than once.

Prevent users from entering customer names that are longer than 40 characters

This simple example prevents users from entering customer records with names longer than 40 characters.

Object: Customer

Rule Type: Error

Events: Add

Condition

The condition uses the strlen function to indicate the length of the customer name field.

strlen({!CUSTOMER.NAME!})<40

Error Message

Customer names must be fewer than 40 characters in length.

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

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