--- title: "Event Definition Condition Logic" canonical: "https://kb.myframeworks.com.au/space/FRAM/344948737/Event%20Definition%20Condition%20Logic" format: markdown --- # Overview Event Definition Conditions in Frameworks are used to control when event actions are triggered. They are written as logical expressions that are evaluated at runtime using the ABL (Advanced Business Language) syntax. When an event occurs, the condition is evaluated, and if it returns `true`, the associated action (email, task creation, etc.) is executed. # How Conditions Work 1. **Event Trigger**: When an event occurs in the system (e.g., sales order creation, inventory changes), an EventNotification object is created 2. **Condition Resolution**: Field references in the condition (like `order:numTran` or `customer:idCust`) are replaced with actual values from the EventNotification object 3. **Condition Evaluation**: The resolved condition is evaluated as an ABL expression 4. **Action Execution**: If the condition evaluates to `true`, the event action is triggered # Syntax and Structure ## Basic Syntax Conditions follow standard ABL logical expression syntax: ``` : ``` ## Supported Operators | Operator | Description | Example | | --- | --- | --- | | `=` or `eq` | Equal to | `order:idCompany = 1` | | `<>` or `ne` | Not equal to | `customer:idCust <> "CASH"` | | `>` or `gt` | Greater than | `order:orderTotalInc > 1000` | | `>=` | Greater than or equal | `order:orderTotalInc >= 500` | | `<` or `lt` | Less than | `order:numTran < 100000` | | `<=` | Less than or equal | `order:numTran <= 99999` | | `and` | Logical AND | `order:idCompany = 1 and customer:idSalesRep = "REP01"` | | `or` | Logical OR | `order:backorderFlag = true or order:orderTotalInc > 5000` | | `not` | Logical NOT | `not order:isPickupDespatchMethod` | | `matches` | Pattern matching | `customer:idCust matches "BR*"` | | `begins` | Starts with | `customer:nameCust begins "ABC"` | | `can-do()` | List membership | `can-do("1,2,3", string(order:idCompany))` | ## Data Types and Values - **Strings**: Must be enclosed in double quotes: `"CASH"`, `"REP01"` - **Numbers**: Written as literals: `1000`, `1.5`, `-50` - **Logical**: `true` or `false` - **Dates**: Use ABL date format: `date("01/15/2024")` - **Null/Unknown**: Use `?` for unknown values # Available Entities and Fields ## For Sales Order Events (SalesOrderNotification) ### Customer Entity (`customer:`) - `idCust` - Customer ID - `nameCust` - Customer name - `primaryEmailAddress` - Primary email address - `idSalesRep` - Sales representative ID - `phoneMobile` - Mobile phone number ### Order Entity (`order:`) - `numTran` - Transaction/order number - `suffixTran` - Transaction suffix - `idCompany` - Company ID - `idBranch` - Branch ID - `idCust` - Customer ID - `idSalesRepCust` - Customer's sales rep - `orderTotalInc` - Order total including tax - `backorderFlag` - Whether order has backorders (true/false) - `isPickupDespatchMethod` - Whether order is pickup (true/false) - `dateDelivReqd` - Delivery required date - `deliveryDate` - Actual delivery date ### Company Entity (`company:`) - `idCompany` - Company ID - `nameCompany` - Company name ### Branch Entity (`branch:`) - `idBranch` - Branch ID - `nameBranch` - Branch name ## For Other Event Types Different event notification types will have different available entities. Common patterns include: - Purchase orders: `purchaseOrder:`, `supplier:` - Customer changes: `customer:` - Inventory changes: `product:`, `branch:` --- # Practical Examples ## 1. High-Value Order Alert **Scenario**: Send email notification for orders over $5,000 ``` order:orderTotalInc > 5000 ``` ## 2. Branch-Specific Notifications **Scenario**: Only notify for orders from specific branches ``` order:idBranch = 1 or order:idBranch = 3 ``` ## 3. Backorder Alert for Specific Customer Types **Scenario**: Alert for backorders from customers whose ID starts with "BR" ``` order:backorderFlag = true and customer:idCust matches "BR*" ``` ## 4. Sales Rep Specific Notifications **Scenario**: Notify when orders are placed for specific sales reps ``` can-do("REP01,REP02,REP05", customer:idSalesRep) ``` ## 5. Company and Value Combination **Scenario**: High-value orders for company 1 that are not pickup ``` order:idCompany = 1 and order:orderTotalInc >= 1000 and not order:isPickupDespatchMethod ``` # Internal Transfer/Branch Transfer Examples ## 6. Branch Transfer Detection **Scenario**: Identify when an order involves branch transfers (assuming branch transfer customers have specific naming) ``` customer:idCust matches "*TRANSFER*" or customer:nameCust matches "*Branch*" ``` ## 7. Inter-Branch Order Alert **Scenario**: Alert when orders are placed between different branches within same company ``` order:idCompany = 1 and order:idBranch <> customer:idBranch ``` *Note: This assumes customer record contains branch information* ## 8. High-Value Transfer Alert **Scenario**: Alert transport teams for high-value internal transfers ``` (customer:idCust matches "*TRANSFER*" or customer:nameCust matches "*INTERNAL*") and order:orderTotalInc > 2000 ``` ## 9. Urgent Transfer Notification **Scenario**: Immediate notification for same-day delivery transfers ``` customer:idCust matches "*TRANSFER*" and order:dateDelivReqd = today ``` ## 10. Multi-Condition Transfer Alert **Scenario**: Complex condition for internal transfers requiring special handling ``` order:idCompany = 1 and customer:idCust matches "*TRANSFER*" and order:orderTotalInc > 1500 and not order:isPickupDespatchMethod and order:backorderFlag = false ``` --- # Advanced Techniques ## Using Functions ABL functions can be used in conditions: ``` string(order:numTran) matches "1000*" year(order:dateDelivReqd) = year(today) ``` ## Multiple Entity References Combine data from different entities: ``` order:idCompany = company:idCompany and branch:nameBranch begins "WAREHOUSE" ``` ## Date Comparisons ``` order:dateDelivReqd <= today + 7 order:dateDelivReqd >= date("01/01/2024") ``` --- # Best Practices 1. **Keep Conditions Simple**: Complex conditions are harder to maintain and debug 2. **Use Meaningful Comparisons**: Ensure your conditions match business logic 3. **Test Thoroughly**: Verify conditions work with sample data before deploying 4. **Document Business Rules**: Comment your conditions to explain the business logic 5. **Consider Performance**: Complex conditions may impact system performance 6. **Handle Null Values**: Use appropriate checks for potentially null fields # Common Pitfalls 1. **Case Sensitivity**: String comparisons are case-sensitive unless specified otherwise 2. **Data Type Mismatches**: Ensure you're comparing compatible data types 3. **Null/Unknown Values**: Handle cases where fields might be null or unknown 4. **Operator Precedence**: Use parentheses to ensure correct evaluation order 5. **String Quoting**: Always quote string literals properly # Debugging Conditions When conditions don't work as expected: 1. **Check the Event Log**: Look at the notification queue for error messages 2. **Verify Field Names**: Ensure entity and field names are correct 3. **Test with Simple Conditions**: Start with basic conditions and build complexity 4. **Check Data Types**: Verify you're using the correct data type for comparisons 5. **Use Debug Logging**: Enable detailed logging to see resolved condition values # Integration with Email Templates Conditions work alongside email templates. The same field references used in conditions can be used in email templates: **Condition:** ``` order:orderTotalInc > 1000 and customer:idSalesRep = "REP01" ``` **Email Subject Template:** ``` High Value Order Alert - {order:numTran} - ${order:orderTotalInc} ``` **Email Body Template:** ``` A high-value order has been placed: Customer: {customer:nameCust} ({customer:idCust}) Order Number: {order:numTran} Order Total: ${order:orderTotalInc} Sales Rep: {customer:idSalesRep} ``` This documentation provides the foundation for creating effective Event Definition conditions that will help automate your internal transfer notifications and other business processes.