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.

Browser not supported