TransEditors

TransEditors are customizable rules that modify input XML before a transaction is calculated for tax. Using TransEditors, you can modify the actual XML transaction data sent from your ERP system to Determination based on criteria you specify. This enables you to, for example:

Specify a value for an element that cannot be directly passed in by your ERP system. For example, a TransEditor might populate ZIP+4 data for a customer when it is not available in the ERP system.
Use the values of multiple elements to derive the value of another element. For example, a TransEditor might evaluate the values found in custom attributes for Cost Center and Project ID to determine the End Use of a product.
Override the value of an element based on other elements' values. For example, a TransEditor might evaluate the Ship To State, Product Code, and Customer Number, and substitute a different Product Code if the values match.

These are just a few of the examples of how TransEditors can be used. Others are shown later in this topic.

TransEditors are evaluated before any other processing takes place in Determination. You can see a diagram of the processing flow in Processing Flow of Determination Transactions.

Before you put a TransEditor into production, you should test it in the Workbench. Set up scenarios to test the transactions you want the TransEditor to perform. For more information, see Workbench Modeling and Testing.

TransEditor Components and Processing

You can maintain one or many TransEditors, and organize them in TransEditor Groups if desired. The illustration above shows that the DEFAULT group is selected and being worked on.

Within each group, TransEditors are maintained in a hierarchical Editors list, which enables you to organize TransEditors using AND and OR conditions:

If a TransEditor is a child of the top level, it will always be evaluated. This indicates an OR condition.
If a TransEditor is a child of another TransEditor, it will only be evaluated if its parent evaluates to true. This indicates an AND condition.

Consider the following list of TransEditors:

In this example, the first two TransEditors are children of the top level--they have no other parent TransEditors. They will always be evaluated. If the second TransEditor evaluates to True, the third TransEditor will also be tested. Only if both the second and third are true will the actions of Set PLUS4 Data be implemented.

The relationship between Editors is set using the Editor Details portion of the page. The Parent Editor can be set to the top level or to any TransEditor in the Editors list.

See Modifying TransEditor Groups and TransEditors for more information.

Conditions and Actions

Each transaction submitted to Determination is analyzed to see if it matches TransEditor conditions, and if those conditions all match, the Actions specified by that TransEditor are taken.

A TransEditor can have no conditions and one or more actions. In this case, the actions are always performed.
A TransEditor can have one or more conditions and no actions. This is common when using the AND logic shown in the example above.
A TransEditor can have both conditions and actions. In this case, the action is performed if the condition is met.

Let's evaluate the TransEditors shown above.

TransEditor Examples
SET SHIP FROM TO WAREHOUSE1	Because this TransEditor is at the top level, it will always be evaluated. Because it has no conditions, it always evaluates to true, and therefore the action of setting the value for Ship From Location to WAREHOUSE1 will take place for every transaction.
EVALUATE CUSTOMER ID AND STATE	Because this TransEditor is also at the top level, it will always be evaluated. Note that its order within the level is 2, so it will evaluate after the first TransEditor. Because it has two conditions, both must match for it to evaluate to true. Because it has no actions, the only impact of this TransEditor is to act as a gatekeeper for its child TransEditor, which cannot be evaluated unless this evaluates to true.
SET PLUS4	Because this TransEditor has a parent, it will only be evaluated if the parent is true. Because it has one condition, that must match for the action to be performed. If both the parent TransEditor and this one evaluate to true, the ZIP Plus4 address of 6864 will be added to the Ship To address for the transaction.

TransEditor Examples

SET SHIP FROM TO WAREHOUSE1

Because this TransEditor is at the top level, it will always be evaluated.

Because it has no conditions, it always evaluates to true, and therefore the action of setting the value for Ship From Location to WAREHOUSE1 will take place for every transaction.

EVALUATE CUSTOMER ID AND STATE

Because this TransEditor is also at the top level, it will always be evaluated. Note that its order within the level is 2, so it will evaluate after the first TransEditor.

Because it has two conditions, both must match for it to evaluate to true.

Because it has no actions, the only impact of this TransEditor is to act as a gatekeeper for its child TransEditor, which cannot be evaluated unless this evaluates to true.

SET PLUS4

Because this TransEditor has a parent, it will only be evaluated if the parent is true.

Because it has one condition, that must match for the action to be performed.

If both the parent TransEditor and this one evaluate to true, the ZIP Plus4 address of 6864 will be added to the Ship To address for the transaction.

Nesting TransEditors and Conditions

The examples above showed simple nesting of TransEditors to generate AND and OR scenarios. You can also:

Nest Editors to deeper levels (for example, create an AND+AND+AND scenario):
Mix Editors ANDs and ORs (for example, create and AND+(OR+OR) scenario):

To reiterate, the way to nest Editors is by modifying the Parent Editor field in each editor's Editor Details pane.

TransEditor Conditions use the same logic, also using parent and child conditions to create AND and OR scenarios.

If both conditions are at the same (top) level, the condition will be true if either are true (OR):

If one condition is a child of another, the condition will only be true if both parent and child are true (AND):

How Conditions Work

A condition tests a supplied element or expression against a constant, value element or expression, or reference list value.

A condition can test the value of the indicated Element / Expression, which can consist of:

An input XML element of any type.
An numeric input XML element modified by a mathematical expression.
A combination of numeric elements.

The following shows examples of valid entries in the Element / Expression field:

LINE.SHIP.TO.STATE
LINE.GROSS_AMOUNT+LINE.USER_ELEMENTS.ATTRIBUTE7
LINE.GROSS_AMOUNT*0.9

For information about setting TransEditor conditions, see TransEditor Conditions.

Math Support

Math support within the Element / Expression and Value Element / Expression field includes:

The +, -, *, and / operators for all numeric elements. String and boolean elements are not supported for math operations.
The ability to nest math expressions, for example, (LINE.GROSS_AMOUNT+LINE.USER_ELEMENTS.ATTRIBUTE7)*0.9.

For mathematical expressions, Determination will validate that the selected elements are valid (numeric or user_element). Additional validation will occur during calculation to ensure the elements are populated appropriately.

Math support does not include support for functions or rounding.

Comparison Options

You can compare the value of the element or expression shown above to:

Values found in the specified Reference Lists, a list of values you configure elsewhere in the system.
A Constant, using one of the supplied comparison operators.
A Value Element / Expression, using the same format as shown above for Element / Expression.

If you use a Constant, you can select from a wide variety of comparison operators. These include:

Standard comparison operators such as =, !=, <, >, <=, and >=.
String comparison operators such as LIKE and NOT LIKE.
Special operators such as EU and NOT EU to determine if a country is or is not in the European Union.

For complete details, see TransEditor Conditions.

How Actions Work

An Action sets the value of a Target Element to either a Constant or another Value Element / Expression.

The fields on this page have the same functionality and limitations as those on the Conditions page.

In addition, you can set the order of the actions (if there are more than one) by entering a value in the Order field. Actions are performed starting at the lowest number, in order to the highest.

For information about creating TransEditor Actions, see TransEditor Actions.

Creating TransEditors

To create TransEditors, you must Check Out the specific Editor Group that will contain your TransEditors. A Default group is provided if that is adequate for your needs; otherwise, you can create one or more additional groups. You cannot delete the Default group.

While a group is checked out, you can make changes to your TransEditors and test them using the Workbench without affecting live transactions on your system. When you are satisfied that the editors work as you intended, you can check the group back into the system to activate them.

Each time you check out a TransEditor group, it modifies the Update Last field for all objects (Editors, Conditions, and Actions) in that group, regardless of whether or not you changed the individual object. The Created (date) does not change.

For more information on TransEditors, please see the following pages.

See Modifying TransEditor Groups and TransEditors for information about:

Creating, modifying, and deleting TransEditor Groups on the TransEditor List page.
Checking out a TransEditor Group for editing on the TransEditor List page.
Adding, modifying, and deleting TransEditors associated with the checked out group on the TransEditor List page.

In addition, you can:

Add conditions for the selected TransEditor on the TransEditor Conditions page.
Add actions for the selected TransEditor on the TransEditor Actions page.

Using Reference Lists with TransEditors

Reference lists allow you to reduce the number of rule qualifiers and TransEditors that you need to create. Using reference lists, you can maintain lists of related items and organize conditions in a manageable way. For example, you can add a selected Project ID for inclusion in a reference list. Then the list of IDs can be referred to on a custom rule to trigger a specific rate.

Any set of related data that facilitates the same action within Determination can be included in a reference list. Examples include Project IDs, account codes, locations and vendors.

You can use a reference list to drive the desired calculation decision (such as triggering a rate, setting an exemption, or other action) in Determination. The values in the reference list must share the common characteristic you want to configure.

You can set up a single TransEditor that references one of your reference lists. Using this practice, a single TransEdit\or can perform the same task instead of requiring you to create multiple TransEditors to perform the same task.

To specify a reference list in a TransEditor, you must create the TransEditor on the Conditions tab of TransEditors page. Click the Reference List radio button and then select the reference list you want to use from the drop-down list. The Operator field automatically switches to EXISTS IN. If you want to exclude the values in the reference list, select NOT EXISTS IN from the drop-down list.

For more information about reference lists, see Rule Qualifiers. You may also want to review Reference Lists.