customization-services/smart-rule-examples.md

---
title: Smart Rule Examples | Sage Intacct Developer
url: https://developer.intacct.com/customization-services/smart-rule-examples/
---

# Smart Rule Examples | Sage Intacct Developer

Getting Started with Customization Services

Smart Event Walkthrough

Smart Event Examples

Synchronous API Smart Events

Smart Rule Examples

Customization Packages

* Warn users that they’re adding a one-time use vendor
* Prevent users from entering customer names that are longer than 40 characters
* Prevent creating records at the top level
* Prevent Vendor Invoices from posting greater than 30 days in the future
* Prevent direct journal postings to a GL account
  + Custom field
  + Smart Rule

---

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:

* With a Smart Event, a condition is a gating factor. If it evaluates to true, the action of the event can proceed.
* With a Smart Rule, a condition is a data-validation rule that should not be broken. If it evaluates to false (broken) an error or warning is emitted.

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. Finally, check out the samples in our Sage Intacct Developer Club. Note that you must sign into the community to download the samples.

---

## 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.

```xml
{!VENDOR.ONETIME!}==False
```

**Error Message**

```xml
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.

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

**Error Message**

```xml
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.

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

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

**Error Message**

```xml
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.

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

**Error Message**

```xml
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:**

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

**Error Message:**

```xml
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:

* Methods available for Smart Events and Smart Rules
* Injection parameters

Provide feedback