How Epicor BAQ Parameters Work
A BAQ defines the tables, joins, criteria, and output columns used to retrieve information. A parameter introduces a value that can be supplied at runtime and referenced in the query's criteria or supported expressions. The query then returns records that satisfy the conditions using that value.
When configuring a parameter, the designer typically specifies its name, data type, and default value where applicable. The parameter must be connected to the relevant criterion in the query. A parameter defined but not used in the query will not change the results.
For example, a supplier-focused BAQ might include a SupplierID parameter. The query's supplier criterion uses that parameter so the user can select a supplier when running the query. The exact configuration and prompt behavior depend on the Epicor version and the application through which the BAQ is executed.
Common Parameter Types and Business Uses
Parameters are most useful when the same query must answer recurring questions with different input values. Common examples include:
- Date range: Select a start date and end date to review invoices, receipts, shipments, or purchase orders within a reporting period.
- Supplier or customer: Filter transactions for a particular business partner when investigating balances or reviewing transaction history.
- Company or site: Restrict results to the relevant organizational unit when reporting across multiple companies or facilities.
- Transaction status: Display records with a selected status, such as open, completed, or pending, when the source field supports that distinction.
- Part or product identifier: Focus inventory, purchasing, or production results on a particular item.
Choose the parameter type to match the underlying field. Date parameters should use appropriate date types, identifiers should match the relevant field's data type, and numeric parameters should reflect the units and precision required by the query.
Example: Filter Purchase Orders by Date
Assume a purchasing team wants to review purchase orders created between April 1, 2026, and April 30, 2026. Rather than saving a BAQ with those dates permanently entered, the designer creates start-date and end-date parameters and uses them in the order-date criteria.
Example inputs: Start date = April 1, 2026; End date = April 30, 2026.
Expected result: The BAQ returns purchase orders whose creation dates fall within the selected period, according to the configured comparison operators and date-handling rules.
The purchasing team can reuse the same query for May or another reporting period by changing the inputs. Finance can use the resulting report to review purchasing activity, compare commitments with invoices, and investigate transactions around month-end. Confirm whether the date criterion should include both endpoints and whether it refers to order creation, approval, receipt, or posting date.
Parameter Design and Validation Best Practices
Reliable parameterized queries start with clear input definitions and criteria that reflect the business question. A useful parameter name should describe its purpose, such as StartDate or SupplierID, rather than using a vague label. Where supported, a sensible default can help users run routine reports quickly while preserving the ability to change the input.
- Match data types: Ensure the parameter and the field used in the criterion are compatible.
- Test boundary values: Check date endpoints, blank inputs, zero values, and identifiers that return no matching records.
- Review optional inputs: Define the intended behavior when users leave an input blank, rather than assuming that blank automatically means all records.
- Verify access and scope: Confirm that company, site, and user permissions align with the intended report audience.
- Compare sample results: Reconcile selected records against a trusted Epicor screen or report to validate the filtering behavior.
When extending epicor reporting, parameterized BAQs provide a reusable way to retrieve targeted data while keeping query logic aligned with the ERP environment. Epicor ERP describes the broader enterprise system, while Epicor Integration Finance focuses on connections between ERP data and finance workflows.
Parameters in Broader Finance and Automation Workflows
Parameterized BAQs can supply targeted datasets for operational dashboards, exception reports, and recurring finance reviews. For instance, a query can isolate open invoices for a chosen supplier or transactions within a selected period. Those records can help reviewers investigate discrepancies before reconciliation or posting. Matching customer payments and remittance details to invoices is a broader process; How Hyperbots AI Agents 10x Epicor Finance Operations and Closing Epicor Finance Gaps with Hyperbots AI Agents discuss finance workflows that extend beyond query filtering.
For organizations connecting reporting with AI-enabled finance operations, the Hyperbots Platform supports company-specific ERP integrations, workflows, roles, and general ledger structures. Process Specific Capabilities address defined finance processes, while Ready to Deploy Capabilities include pre-trained agents and ERP connectors. Self Learning Capabilities use feedback to refine supported decisions, and Human in the Loop enables review of exceptions and approval steps. Screening Parameters are another business term for criteria used to narrow a set of records or candidates, although their precise meaning depends on the process in which they are applied.
Summary
Epicor BAQ Parameters allow users to supply values that determine which records a Business Activity Query returns. They support reusable reporting by filtering data according to dates, suppliers, customers, companies, sites, statuses, or other relevant fields. Define appropriate data types, connect each parameter to the correct criterion, test boundary conditions, and verify the results against trusted records. Well-designed parameters make operational and financial reporting more flexible and consistent.