What is Epicor BAQ Distinct?

Definition

Epicor BAQ Distinct describes the use of distinct-result logic in an Epicor Business Activity Query (BAQ) to return unique records or combinations of selected field values rather than repeated rows. It is useful when a query joins multiple tables and the same business entity appears more than once in the output. By identifying the required level of uniqueness, users can produce cleaner datasets for analysis, dashboards, and financial reporting.

The result depends on which fields the query selects and how the query is configured. Two rows with the same supplier name but different invoice numbers may both be valid distinct rows when invoice number is included. If the query selects only supplier name, those rows may collapse into one unique supplier value when distinct-result behavior is applied.

Table of Contents

How Distinct Results Work in a BAQ

In an Epicor BAQ, distinct-result logic is concerned with duplicate combinations in the query output. The query may retrieve information from related tables such as supplier records, purchase orders, order details, invoices, or transaction history. When one record connects to several related records, the output can contain repeated values from the main table.

For example, one supplier may have five open purchase orders. A query joining supplier data to purchase-order data can return five rows containing the same supplier ID and name. If the objective is to list each supplier once, the query should return only the fields needed for that list and apply the supported distinct-result setting where available. If the objective is to review all five purchase orders, those rows should remain separate.

In Epicor ERP, the right result depends on the business question, the table relationships, and the selected columns. Distinct results should not replace a review of the query's joins or the intended record grain.

When to Use Epicor BAQ Distinct

Distinct-result logic is useful when the report needs unique values rather than a complete transaction-level listing. Before enabling it, decide what one row should represent: a supplier, customer, invoice, order, part, or another business entity.

  • Supplier directories: Display each supplier once even when supplier records connect to multiple purchase orders.
  • Customer lists: Identify unique customers represented in sales or accounts receivable activity.
  • Part and product analysis: Return unique part numbers appearing across order lines, shipments, or inventory transactions.
  • Financial review datasets: Prepare unique account, department, or transaction-category lists for reconciliation and reporting support.
  • Operational dashboards: Count or display unique entities when repeated joined rows would not match the dashboard's intended meaning.

For finance workflows, separate unique-entity reporting from transaction reporting. A supplier summary may need one row per supplier, while an accounts payable review usually needs each relevant invoice and its outstanding balance. The correct query design follows the decision that the report must support.

Distinct Values, Duplicate Rows, and Financial Totals

Distinct-result logic does not automatically correct every duplicate-row issue. It evaluates the selected output fields, so a row can remain distinct because one included field differs. Likewise, using distinct values to create a supplier list does not establish the correct total for invoices, payments, or purchase commitments.

Consider a supplier with two invoices of $1,200 and $800. An invoice-level query should retain both invoices, giving a total of $2,000. If a join to shipment or distribution records repeats each invoice across several rows, simply applying distinct-result logic to a wide selection of fields may not remove the repetitions because the joined fields differ. The query designer should instead verify the relationships and calculate totals at the appropriate level before aggregating.

For reliable reporting, compare query results with known ERP records and confirm that totals reconcile to the intended source. This is especially important when the dataset feeds a report, an export, or a downstream finance process.

Best Practices for Query Design

Start with a plain-language definition of the desired output, such as “one row per supplier with at least one open purchase order.” Then identify the fields needed to identify that entity and the conditions that determine inclusion. Keep the query focused on those requirements.

  • Define the intended row level before selecting fields or configuring distinct-result behavior.
  • Review one-to-many table relationships to understand why repeated values appear.
  • Remove unnecessary fields from summary queries when they cause otherwise identical entities to appear separately.
  • Test distinct output against a small, known set of suppliers, invoices, or orders.
  • Validate counts and monetary totals separately, especially when joining transaction and distribution data.

When extending epicor through integrations, document the query's output fields and how unique records are identified. Hyperbots Data Model Designer for ERP/HRMS Mapping provides related context for aligning data structures between enterprise systems. For broader finance connectivity, Epicor Integration Finance describes the relationship between ERP data and connected finance workflows.

Distinct BAQ Data in Connected Finance Processes

A BAQ can supply structured data for reports and workflows, while connected applications may use additional rules to validate transactions, match records, or determine the next action. For example, a query listing customer accounts is different from a process that matches incoming receipts to invoices and resolves unapplied cash. How Hyperbots AI Agents 10x Epicor Finance Operations and Closing Epicor Finance Gaps with Hyperbots AI Agents discuss ways AI-supported workflows can extend Epicor finance operations beyond data retrieval.

Hyperbots Platform supports company-specific configuration for ERP integrations, workflows, roles, and general ledger structures. Its Process Specific Capabilities address process-focused finance automation, while Ready to Deploy Capabilities include pre-trained agents and ERP connectors for supported finance tasks. Human in the Loop workflows can route exceptions for review, and Self Learning Capabilities use human feedback to refine supported decisions over time. These capabilities complement well-defined ERP data by connecting it to governed business processes.

Distinct performance obligation is a separate accounting concept concerning whether a promised good or service is separately identifiable within a customer contract. It should not be confused with distinct-result logic in a BAQ, which concerns unique query output.

Summary

Epicor BAQ Distinct helps users return unique query results when repeated values arise from joined tables or when a report requires one row per entity. Its effectiveness depends on the selected fields, query relationships, and intended record level. Define the reporting question first, validate joins, and reconcile counts and financial totals to ensure the resulting dataset supports accurate business analysis.

Related Articles

Closing Epicor Finance Gaps with Hyperbots AI Agents How Hyperbots AI Agents 10x Epicor Finance Operations Are Duplicate GL Codes Wrecking Your Financial Reports? SAP S/4HANA Order to Cash Automation