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.
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>
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!}">
<customfields>
<customfield>
<customfieldname>NEW_CUSTOMER</customfieldname>
<customfieldvalue>false</customfieldvalue>
</customfield>
</customfields>
</update_customer>
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>
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>
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!}`
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!}
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!}
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!}.
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!}
You should use the API_ENDPOINT
injection parameter in any component that includes a SESSIONID
. Your server-side code should then use the endpoint when calling back to Sage Intacct Web Services (instead of using one hard-coded to https://api.intacct.com/ia/xml/xmlgw.phtml
).
For example, a dashboard Smart Link Fetch component can pass the session ID and API endpoint as follows:
https://www.example.com/dash.php?sessionId={!USERPROFILE.SESSIONID!}&endpoint={!API_ENDPOINT!}
Warning: Components are copied to sandbox or Preview environments when you opt in to these. If your code automatically uses the session and new endpoint value, take additional steps to validate the company ID making such a request to avoid mixing data across these environments.
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!}.
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.
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.
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
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
See the Sage Intacct product help for more information about: