Transaction Setup
- Megan Stanage (Unlicensed)
Analytics
Value Added Billing > Setup > Transaction > Transaction Setup
Query Transactions
Query transactions are broken down into three sections: Overview, Query, and Data.
Overview Section
| FIELD | DESCRIPTION |
|---|---|
| Transaction Name | A unique name is required for each transaction. |
| Description | A detailed description of the transaction. |
| Query or Code | Indicates that the transaction is based on query or code (a set of predefined algorithms too complicated for queries). |
| Active | Controls whether this transaction should be included during processing. |
| Transaction Code | If Code is selected in the Query or Code field, a drop-down list of predefined scripts is available. If Query is selected in the Query or Code field, this field is disabled. |
| Allow Duplicate Transactions | Indicates whether the transaction can be processed multiple times. In some instances, such as location inventory, the business requirement might be to evaluate transactions each time the processor runs. By default, Bill only processes a transaction once. Any future processing ignores the transaction. |
| Transaction Group | You can assign the transaction a transaction group for quick filtering. |
Query Section
The fields in the Query section are required for all query transactions.
Note
This section only displays if Query is selected for the Query or Code field.
FIELD | DESCRIPTION |
| DATA | |
Primary Table | Defines the primary table for the query. Selecting a primary table enables the Query button at the top of the form. All other drop-down lists in the Query section and Data Section are based off this table. |
| KEY FIELDS | |
| Primary Key Table | Defines the table within the query that stores the key field. |
Primary Key Field | Defines the primary key field for the first table in the query used for data selection. This field identifies the transaction record and prevents the transaction from being used again in future runs (unless Allow Duplicate Transactions is enabled). |
| Date Table | Defines the table to pull the date from. |
Date | Every database transaction is timestamped with various dates. This field identifies which date to use for evaluation during processing, and determines which billing cycle the transaction is included in. |
Day Offset | This field allows transactions to be included within a prior time window based on the offset (implied negative). For example: If the selected date is PostedDateTime, with a value of 1/30/2017 07:00:00 PM, and Day Offset is set to "2," the system uses the date 1/28/2017 07:00:00 PM for transaction evaluation. |
| Entity Table | Defines the table to pull the Entity value from. |
Entity | Defines which field contains the entity value throughout the system. The value corresponds with an account (customer or vendor). This entity is used throughout the system to identify and link transactions. Bill provides entity fields on key tables associated with customer, vendors, items, and locations. |
Note
On the Transaction Setup form, Entity identifies which field contains the entity value. Everywhere else in the system, Entity refers to the entity value.
For example: On the Transaction Setup form, ItemGroupID is selected for the Entity field. The ItemGroupID value is "Carpet." The Entity field elsewhere in the system must be set to "Carpet" to link all carpet transactions together.
Data Section
The Data section allows you to define additional fields to sort and filter during price book processing.
By default, Bill provides 10 fields each of the following types:
- String
- DateTime
- Real (number field)
- Real Unit (string fields that identify the unit of measure for associated Real field)
Note
A Real Unit should be included with each Real value.
The tables and data available for display are dependent on your primary table in addition to any joined tables.
Example
If my primary table is the WHSContainerTable and I do not have any joined tables in my query, the only data I can pull will be from the WHSContainerTable.
On the contrary, if I am joined on the WHSShipmentTable, I can add data from both the WHSContainerTable and the WHSShipmentTable.
Code-Based Transactions
Code-based transactions allow for more intricate options when creating transactions.
Example
A transaction requires a calculation or additional processing before returning a value.
Only the Overview section and parameters are necessary when setting up a code transaction.
The Query and Data sections are not required because that information has been specified by the developer in their code.
The Inventory Aging (VABCodedTransactionInventoryAging) transaction code calculates the number of days inventory has been in a location since the start of the current month.
Click Parms at the top of the form to open the Parameters flyout window and assign each code-based transaction a set of parameters.
FIELD | DESCRIPTION |
|---|---|
| Unit | The unit of measure that will be evaluated by the price book. |
| Filter values | This will filter the location by the zone ID. |
Output
The system generates records, viewable on the Transaction Detail form, with the following information:
FIELD | DESCRIPTION |
|---|---|
| Entity | Location's zone ID. |
| Primary Key Field | This transaction with the license plate ID. |
| Transaction Date and Time | Date the transaction was run. |
| String Field 1 | Item ID. |
| String Field 2 | Location's profile ID. |
| String Field 3 | Site. |
| String Field 4 | Warehouse. |
| String Field 5 | Location ID. |
| Real Field 1 | Days in location since the beginning of the month. |
| Unit 1 | Applied from the unit identified in the parameters. |
Buttons
History
Click this button to open the Transaction Detail form.
Copy
You can copy the information within a transaction setup to a new instance of the transaction. This allows similar transactions to be used with minor adjustments.
Click Copy to open a flyout window with fields for the new transaction name and description.
Query
Click this button to open the Inquiry form.