Use custom fields for transaction data

If you have transaction data that doesn't fit into Determination's standard XML elements, you can use custom fields which are special XML elements.
These are XML input elements you define to match the needs of your implementation. 50 separate elements are provided at both the document and line levels, although some are reserved for use by the integration software that links your financial system to Determination.
Common uses for custom fields include:
  • Submitting pass-through data for storage in the Audit Database. For example, you might want to store additional location data, contact info, or comments for a transaction that aren't supported by the standard set of XML elements.
  • Submitting data which can match exemption certificate "limited-use" criteria.
  • Submitting data which, when evaluated by TransEditors, can trigger modifications to the XML input and resulting calculations.
  • Submitting data which, when evaluated by Rule Qualifiers, can determine the applicability of a rule to a transaction.

<USER_ELEMENT> structures

Custom fields are submitted in the following XML input structures:
<INVOICE> <USER_ELEMENT> <NAME>ATTRIBUTE[1-50]</NAME> <VALUE> </VALUE> </USER_ELEMENT> </INVOICE>
<INVOICE> <LINE> <USER_ELEMENT> <NAME>ATTRIBUTE[1-50] </NAME> <VALUE> </VALUE> </USER_ELEMENT> </LINE> </INVOICE>
For example, you may define ATTRIBUTE20 at the line level to contain a Project ID used at your implementation that may or may not be populated for each transaction. The presence of this field and its value can be evaluated to trigger rules, exemption certificates, or TransEditors. In addition, this evaluation can take into account only this single custom field or other custom fields and standard elements in combination.
As already mentioned, Determination integrations reserve some of the 50 elements at each level for their own use and shouldn't be populated. In general, custom fields 1 through 30 are always available, 31 through 39 may be available, and 40 through 50 are never available.

Automatic conversion for rule qualifiers and TransEditors

Custom fields are defined as strings by the Determination XML implementation. However, you can use these elements to pass in either numbers or dates and the system will correctly evaluate them in rule qualifier or TransEditor comparisons that use the <, <=, >, or >= operators. For example, a TransEditor could compare the value or <ATTRIBUTE25> against the value of <INVOICE_DATE> at the invoice level using one of the 4 operators. Or, a rule qualifier could compare it against a constant such as 2007-03-05.
The order of attempted conversions is number, date then string.
Number conversions
The system first attempts to convert to a number such that the left- and right-hands of the expression are both numbers.
For example:<ATTRIBUTE25> > <ATTRIBUTE24>
<ATTRIBUTE25> contains the string "10" and <ATTRIBUTE24> contains the string "5". Both are converted to numbers and the expression evaluates to "true":
10 > 5 evaluates to "true".
Date conversions
If number conversions fail, Determination attempts a date comparison.
For example:<ATTRIBUTE20> < <INVOICE_DATE>
<ATTRIBUTE20> contains the string "2007-03-05" and the <INVOICE_DATE> is "2007-03-04". Determination first attempts to convert and compare numbers, which fails, then attempts to convert and compare by dates, which is successful:
2007-03-05 < 2007-03-04 evaluates to "false"
String conversions
If number and date conversions both fail to generate a valid comparison, Determination attempts to treat both values as strings and attempts a lexicographical comparison.
For example:<ATTRIBUTE15> <= aab
<ATTRIBUTE15> contains the string "aaa" and the constant evaluated against is "aab". The value "aaa" can't be converted to number or date format and therefore gets evaluated against the constant as a string.
aaa <= aab evaluates to "true"