API Reference
Start typing to search…

General Ledger

General Ledger

Overview

The General Ledger (GL) is your accounting ledger that tracks all financial transactions affecting your chart of accounts. It aggregates entries from invoices, shipments, payments, journal entries, and consolidations, providing a complete financial picture of your business. The GL exists at the GraphQL layer as a calculated view, built from the underlying transaction data.

Every transaction that has financial impact creates general ledger entries. When you ship products, GL entries record the cost of goods sold and the reduction in inventory value. When you invoice customers, GL entries record revenue and create accounts receivable. When you receive payments, GL entries reduce receivables and increase cash. These automated entries ensure your books always reflect your operations without manual accounting work.

GL accounts categorize transactions into the standard accounting framework. Asset accounts track things you own - cash, accounts receivable, inventory. Liability accounts track what you owe - accounts payable, taxes payable. Revenue accounts track sales and income. Expense accounts track cost of goods sold and operating expenses. Each GL entry posts to a specific account, building up the balances that feed your financial statements.

Every GL entry follows double-entry accounting: debits must equal credits. When you ship a product, you debit cost of goods sold (an expense) and credit inventory (an asset reduction). When you invoice a customer, you debit accounts receivable (an asset) and credit revenue (income). This balancing ensures your books are always accurate and supports financial statement generation.

Consolidations help manage GL volume for high-transaction businesses. Rather than creating individual GL entries for hundreds of daily shipments, consolidations aggregate them into single daily or weekly entries. This keeps the GL readable for accountants while preserving all detail at the transaction level. You can always drill down from a consolidated GL entry to see the individual shipments or invoices that make it up.

The GraphQL API provides flexible GL querying. You can view entries for specific accounts to see all activity affecting that account. You can filter by date range to see what happened in a particular period. You can trace entries back to their source transactions - seeing exactly which invoice or shipment created each GL entry. This traceability is essential for audit support, financial analysis, and regulatory compliance.

GraphQL API

The generalLedger collection provides access to generalLedger data via the GraphQL API. All queries use the Relay connection specification with cursor-based pagination.

Query Name: generalLedgerViewConnection

Available Features:

  • Cursor-based pagination (first/last/after/before)
  • 22 filter options
  • 6 relations to other collections

Query Examples

Basic Query

The generalLedger collection is accessed via the generalLedgerViewConnection query, which returns a Relay-style connection with pagination support.

query {
  generalLedgerViewConnection(first: 10) {
    edges {
      node {
        amount
        amountPerUnit
        averageCost
        balance
        cbm
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

Pagination

Use cursor-based pagination to retrieve large datasets:

# First page
query {
  generalLedgerViewConnection(first: 50) {
    edges {
      node { lotId }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

# Subsequent pages
query {
  generalLedgerViewConnection(first: 50, after: "cursor-from-previous-page") {
    edges {
      node { lotId }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

Filtering

Apply filters to narrow results (see Filters section for all available options):

query {
  generalLedgerViewConnection(
    first: 10
    account: "Sales Revenue"
  ) {
    edges {
      node { lotId }
    }
  }
}

Relations

Query related data (see Relations section for all available relations):

query {
  generalLedgerViewConnection(first: 10) {
    edges {
      node {
        lotId
        account {
          name
          glAccountUrl
        }
      }
    }
  }
}

Summary and Aggregation

This collection supports metrics aggregation through the summary field. You can calculate totals, averages, counts, and other aggregate values across filtered data.

Note: This collection does not support groupBy dimensions. For dimensional analysis, use collections like product, order, or invoice.

For a comprehensive guide to using aggregations, see the Aggregation Concept Guide.

Query Structure

generalLedgerViewConnection(filters...) {
  summary {
    errorCode
    errorMessage
    metrics {
      # Calculated metrics (see table below)
    }
  }
}

Available Metrics

This collection provides 8 metrics that can be aggregated:

MetricParametersDescription
amounttransform, operatoramount for generalLedger
inStockAmounttransform, operatorinStockAmount for generalLedger
inTransitAmounttransform, operatorinTransitAmount for generalLedger
packedAmounttransform, operatorpackedAmount for generalLedger
wipAmounttransform, operatorwipAmount for generalLedger
expenseAmounttransform, operatorexpenseAmount for generalLedger
revenueAmounttransform, operatorrevenueAmount for generalLedger
countNoneCount of items in the result set

Common Parameters:

  • operator - Aggregation function: sum, mean, min, max
  • transform - Mathematical transformation: abs
  • dateRange - Filter to specific date range
  • facilityUrlList - Filter to specific facilities

Examples

Example 1: Total generalLedger Metrics

Calculate aggregate metrics across all generalLedger records:

query {
  generalLedgerViewConnection(first: 1) {
    summary {
      errorCode
      errorMessage
      metrics {
        totalCount: count
      }
    }
  }
}

Expected result structure:

{
  "data": {
    "generalLedgerViewConnection": {
      "summary": {
        "errorCode": null,
        "errorMessage": null,
        "metrics": {
          "totalCount": [1523]
        }
      }
    }
  }
}

Fields

This collection has 54 fields:

  • 46 simple fields
  • 8 enum fields (with predefined values)
  • 0 parameterized fields (accept query options)

Note on Field Formatting: All scalar fields support the formatter argument to control output format. Available options: "html", "none", "abbreviated", "blank-zero". Some fields have a default formatter (shown below). See the Formatting guide for details.

Note on Sorting: Field sortability may vary depending on the UI context and query parameters used. Some parameter options explicitly disable sorting (marked with ⚠️ not sortable).

Simple Fields

These fields return values directly without additional options.

amount

The signed monetary value of a general ledger transaction, calculated based on whether the transaction is a debit or credit and the type of account involved. The amount field applies accounting sign conventions: debits to debit-normal accounts (like assets and expenses) are positive, while credits to these accounts are negative. Conversely, debits to credit-normal accounts (like liabilities, equity, and revenue) are negative, while credits are positive. This ensures that increases to accounts are positive and decreases are negative, following standard accounting principles. The raw transaction amount is transformed by multiplying it by +1 or -1 based on the isDebit flag and the account's glaccountIsCreditAccount property. For example, a purchase shipment with a debit of $96.00 to inventory (asset account) shows as +96.00, while the corresponding credit of $96.00 to accounts payable (liability account) shows as +96.00 from the liability's perspective. The field can be positive or negative and is formatted as currency.

Label: Amount
Sortable: No

amountPerUnit

The transaction amount divided by the quantity in inventory units. This calculated field divides the total amount by the units to show the per-unit cost or value of items in general ledger transactions. When quantity is zero or units are not available, the field returns null. For example, an inventory transaction with an amount of $240.00 and 80 units would show an amount per unit of $3.00.

Label: Amount per unit
Sortable: No

averageCost

The average cost per unit of a product at the time of a general ledger transaction. This represents the moving average cost that is calculated based on inventory transactions and is used for inventory valuation. The value is retrieved from stock history records and reflects the product's cost basis at the specific transaction date. When average cost information is unavailable (such as for non-inventory items or when the total units available are negative), this field returns NaN. This field is used to calculate cost of goods sold (COGS), margin analysis, and inventory valuation metrics.

Label: Average cost
Sortable: No

balance

The running cumulative balance for an account as of each transaction. The balance is calculated by accumulating transaction amounts chronologically, showing the account's balance after each transaction is applied. For example, if an account has transactions with amounts of 48, 48, and 96, the corresponding balances would be 48, 96, and 192. The balance field is formatted as currency and represents the account's cumulative financial position at each point in the transaction history. When viewing summary rows, the balance appears with initial balance rows (showing the starting balance before the filtered date range) and ending balance rows (showing the final balance after all transactions in the range). The balance can be filtered using balanceTypeLineItem to include all balances, only non-zero balances, only zero amount transactions, or only zero-balance accounts.

Label: Balance
Sortable: No

cbm

A computed subtotal representing the total volume in cubic meters (CBM) for items in a general ledger transaction. This field is calculated by multiplying the product's volume per unit (CBM per unit) by the quantity of units in the transaction. CBM is used for volume-based calculations, such as allocating adjustments by volume or analyzing shipping and storage requirements. The field is only populated when volume tracking is enabled in the system preferences.

Label: CBM subtotal
Sortable: No

class

A customizable classification dimension used to categorize general ledger transactions for reporting and analysis purposes. The class field's value depends on the transaction type and is configured through the accounting class list in customization settings.

For sales-related transactions (invoices, shipments, orders, payments), the class can be set to track:

  • Sale source (the channel or marketplace where the sale originated, such as "Amazon US" or "Manual")
  • Product category (the product's category classification, such as "Fruits" or "Vegetables")
  • Custom fields defined on orders or products

For variance transactions (inventory adjustments), the class can track:

  • Variance reason (why the inventory was adjusted)
  • Product-specific custom fields

For journal entries, the class field uses the accounting class value from the journal entry item itself.

The class field is commonly used to segment financial data by business dimensions that matter to the organization, such as tracking profitability by sales channel, analyzing costs by product category, or reporting on custom business classifications. When no class configuration is active (classNone), the field returns empty values.

Label: Class
Sortable: No

cost

The standard accounting cost amount for a product on a general ledger entry. This value is calculated by multiplying the quantity (units) by the product's standard accounting cost per unit (the cost field from the product record). It represents the total accounting cost for the line item and is used for cost accounting, inventory valuation, and financial reporting. This field requires canViewCost authorization to access and is available when analyzing general ledger entries that include product information.

Label: Std accounting cost amount
Sortable: No

credit

The credit side of a double-entry accounting transaction. In double-entry bookkeeping, every transaction affects at least two accounts - one debited and one credited. The credit field displays the transaction amount when the transaction is a credit (when isDebit is false), and shows null for debit transactions. The field uses the same underlying amount value as the debit field, but only displays it when the transaction represents a credit entry. For example, when recording a purchase that increases inventory (asset debited) and increases accounts payable (liability credited), the credit column would show the amount for the accounts payable side of the transaction while the debit column would be empty for that entry, and vice versa for the inventory entry. The credit field is formatted as currency and can display positive or negative values depending on the transaction. The credit field is commonly used alongside the debit field in general ledger reports to show the full double-entry structure of accounting transactions.

Label: Credit
Sortable: No

debit

The debit side of a double-entry accounting transaction. In double-entry bookkeeping, every transaction affects at least two accounts - one debited and one credited. The debit field displays the transaction amount when the transaction is a debit (when isDebit is true), and shows null for credit transactions. The field uses the same underlying amount value as the credit field, but only displays it when the transaction represents a debit entry. For example, when recording a purchase that increases inventory (asset debited) and increases accounts payable (liability credited), the debit column would show the amount for the inventory side of the transaction while the credit column would be empty for that entry, and vice versa for the accounts payable entry. The debit field is formatted as currency and only displays positive, finite values. The debit field is commonly used alongside the credit field in general ledger reports to show the full double-entry structure of accounting transactions.

Label: Debit
Sortable: No

expenseAmount

The amount value for general ledger entries posted to expense-type accounts. This field represents the monetary value for transactions that impact accounts classified as expenses in the account taxonomy hierarchy, including cost of goods sold (COGS) accounts and other expense accounts. The value is calculated by checking the account's taxonomy classification and returns the transaction amount only when the account's parent taxonomy is EXPENSE, otherwise it returns null. The amount is typically displayed as a negative value for expense transactions, following standard accounting conventions where expenses reduce equity. This field is useful for filtering and analyzing expense-related transactions separately from revenue, asset, or liability transactions.

Label: Expense amount
Sortable: No

glAccountUrl

A URL identifier that references the general ledger account associated with this transaction entry.

In the general ledger view, each transaction creates debit and credit entries that reference specific accounts. This field identifies which account is being debited or credited for the transaction. The account determines how the transaction affects financial reporting and account balances.

The glAccountUrl field can also be broken down into separate components: the account code (via the account.code compound field) and the account name (via the account.name compound field).

IMPORTANT: Treat URL values as opaque strings supplied by the server. Do not attempt to parse, interpret, or construct URL values manually:

  • ID values embedded in URLs may differ from entity ID values
  • The URL structure is an internal implementation detail subject to change
  • Manually constructing URLs can lead to bugs and system errors
  • Always use URL values exactly as provided by the API

Label: Account
Sortable: No

inStockAmount

The monetary value of inventory that is currently on hand at a location. This field represents the amount (in currency) for items with stock type 0 (on-hand stock), calculated by multiplying the quantity on hand by the cost per unit. The field returns the negative of the general ledger amount for on-hand items, and returns infinity for other stock types (in transit, packed, etc.). This field is commonly aggregated using the sum metric to calculate total on-hand inventory value across products, locations, or other dimensions in inventory-focused general ledger reports.

Label: In stock amount
Sortable: No

inStockQuantity

The quantity of inventory items that have a stock type of "In stock" (stockType = 0). This field filters general ledger transactions to show only the quantity values for items that are physically available in stock, excluding items that are in transit, packed, or work-in-progress. When a general ledger entry has a quantity value and stockType of 0, this field returns that quantity; otherwise it returns an empty value. This field is commonly used in inventory reports alongside related stock status fields like inStockUnits and inStockAmount to track on-hand inventory quantities.

Label: In stock quantity
Sortable: No

inStockUnits

The number of individual units (eaches) for inventory that is currently in stock (on hand). This field converts the quantity based on the packing configuration. For example, if the quantity is 10 and the packing is "cs 12/1" (12 cases of 12 units each), the inStockUnits would be 120 (10 cases × 12 units per case). When no packing is specified, inStockUnits equals the quantity. This field only applies to items with stockType 0 (in stock); for other stock types like in-transit inventory, the value is not applicable.

Label: In stock units
Sortable: No

inTransitAmount

The monetary value of inventory that is currently in transit. This represents inventory items that have been shipped on a transfer shipment but have not yet been received at their destination facility. In-transit inventory is tracked separately from other stock types (such as in-stock, packed, or work-in-progress) and appears in general ledger entries with a stock type classification of "in transit". The amount is calculated based on the average cost or transaction cost of the inventory items multiplied by the quantity in transit.

Label: In transit amount
Sortable: No

inTransitQuantity

The quantity of inventory that is currently in transit as part of a shipment. This field specifically represents stock with a stock type of "in transit" (stockType = 1), which indicates items that have been shipped but not yet received at their destination.

When a shipment is created and items are moved from one location to another, the inventory transitions through different states: on hand, packed, in transit, and eventually back to on hand at the destination. The inTransitQuantity captures the middle state where goods are actively being transported between facilities.

This field returns an empty value when the stockType is 0 (in stock) and returns the actual quantity value when stockType is 1 (in transit). It is used in conjunction with related fields like inTransitUnits and inTransitAmount to provide complete visibility into inventory that is currently being transferred between locations.

Label: In transit quantity
Sortable: No

inTransitUnits

Represents the number of individual units of inventory currently in transit between locations. This field is calculated based on the quantity of a product and its packing configuration when the stock type is "in transit" (stockType = 1).

In transit inventory occurs during transfer shipments: when a transfer shipment is shipped, stock moves from "in stock" status to "in transit" status, and when the shipment is delivered, it moves from "in transit" back to "in stock" at the destination location.

For products with packing configurations, the units are calculated by multiplying the quantity by the units per case. For example, if a quantity of 10 cases with packing "12 cs 12/1" is in transit, the inTransitUnits would be 120 (10 cases × 12 units per case). For products without packing configurations, the units equal the quantity.

The field returns null (displayed as empty) when the stock type is not "in transit" (stockType ≠ 1).

Label: In transit units
Sortable: No

inventoryQuantity

The quantity of items associated with inventory account transactions in the general ledger. This field filters general ledger entries to show quantity values only when the general ledger account is classified under the INVENTORY_ACCOUNT taxonomy (such as inventory asset accounts). When a transaction involves an inventory account and has a quantity value, this field returns that quantity; otherwise it returns an empty value. This field is used to track inventory quantities specifically for accounting entries that affect inventory accounts, distinguishing them from other general ledger transactions that may involve products but don't impact inventory accounts (such as expense or revenue accounts).

Label: Inventory quantity
Sortable: No

inventoryUnits

The total number of individual units for entries with inventory accounts. This field calculates units by multiplying quantity by the units per case from the packing string, and only displays values for general ledger entries where the account type is classified as an inventory account (INVENTORY_ACCOUNT taxonomy). For entries with non-inventory accounts, this field returns null. This field is commonly used to track inventory movement in reports filtered by inventory account types.

Label: Inventory units
Sortable: No

lotId

The lot identifier associated with inventory transactions in the general ledger, formatted with a descriptive prefix such as "Lot: ", "Mfg: " (manufacturing date), or "Exp: " (expiration date). This field tracks lot-specific inventory movements through various transaction types including shipments, returns, variances, and build operations. Visibility of this field is controlled by system settings for manufacturer date shift tracking. Query using lotId(formatter: "default") to get the formatted value with the appropriate prefix based on the lot ID type.

Label: Lot ID
Sortable: No

lotIdUnprefixed

A formatted version of the lot identifier that removes the "Lot: " prefix when displaying lot IDs that begin with "L_". This field provides a cleaner display format for user-facing interfaces where the "Lot: " label is redundant or unnecessary.

The field uses the same underlying lot ID value as the lotId field, but formats it differently. For lot IDs starting with "L_", it strips the "L_" prefix and omits the "Lot: " label (e.g., "L_A223-2" displays as "A223-2"). For manufacturing date lots (starting with "M") and expiration date lots (starting with "E"), it displays the same formatted date as the standard lotId field (e.g., "M20140202_" displays as "Mfg: 2/2/2014" and "M20100308_2nd" displays as "Mfg: 3/8/2010 2nd").

Label: Lot ID unprefixed
Sortable: No

nativeNeq

The Net Explosive Quantity (NEQ) subtotal calculated using the product's native unit of measure, without system of measure conversion. This field represents the total net explosive mass for the transaction, computed by multiplying the quantity by the product's NEQ per unit value. It differs from the neq field which uses converted values based on the product's NEQ per unit system of measure setting. The native NEQ calculation is used for accurate tracking of explosive materials in their original units throughout inventory and transaction records.

Label: Native NEQ subtotal
Sortable: No

nativeWeight

A calculated subtotal of the weight for items in a transaction, using the product's native weight unit as stored in the database. This is computed by multiplying the transaction quantity (in units) by the product's weight per unit. Unlike the "weight" field which converts all weights to the organization's system of measure (either kilograms for SI or pounds for US customary), nativeWeight preserves the original unit of measurement (e.g., grams, ounces, pounds) as defined for each product. This field is primarily used in reporting and analytics when weight data needs to be displayed in its original form without system-wide conversion.

Label: Native Weight subtotal
Sortable: No

neq

The Net Explosive Quantity (NEQ) subtotal for the general ledger entry, representing the total explosive mass in the user's preferred system of measure. This field is calculated by multiplying the quantity by the product's net explosive mass per item, then converting the result to the system of measure configured for the account (e.g., pounds, kilograms). NEQ is used for tracking explosive materials for regulatory compliance and safety purposes, particularly in industries handling hazardous materials like ammunition, fireworks, and blasting materials. This differs from the nativeNeq field, which reports the value in the product's original unit of measure without system conversion.

Label: NEQ subtotal
Sortable: No

packedAmount

The monetary value of inventory that has been packed into shipments but not yet shipped. This field represents the amount component of packed inventory transactions, filtered by stock type. Packed inventory refers to products that are physically packed and ready to ship, typically associated with sales shipments that are in a "packed" status at a facility. The amount is calculated based on the transaction cost of the inventory items when they were packed. This field is commonly used alongside packedQuantity and packedUnits to analyze inventory that is staged for shipment, and appears in inventory account type reports to track the financial value of goods that have moved from available stock into the shipping process.

Label: Packed amount
Sortable: No

packedQuantity

The quantity of a product that has been packed for a sales shipment but not yet shipped or unpacked. When a sales shipment is packed (status changes to SHIPMENT_PACKED), inventory is moved into a "Packed" stock type, creating a corresponding general ledger entry. This field tracks that packed quantity for inventory and financial reconciliation purposes. The packed quantity can be transferred between locations while maintaining its packed status, and is ultimately removed when the shipment is either shipped or unpacked. This field is displayed alongside related fields like packedAmount and packedUnits to provide a complete picture of packed inventory value and volume.

Label: Packed quantity
Sortable: No

packedUnits

The quantity of inventory units that have been packed for shipment but not yet shipped. This represents stock that has been allocated and prepared for specific sales orders but is still physically at the origin facility. When a shipment is packed in the system, inventory moves from the "on hand" state to the "packed" state, reducing available stock while maintaining the total units count. The packed units return to normal stock if the shipment is unpacked, or leave inventory entirely when the shipment is marked as shipped. This field is particularly useful for tracking inventory that is committed to orders but hasn't yet left the warehouse, and is commonly used in integrations with e-commerce platforms where orders must be packed in the system before being marked as shipped.

Label: Packed units
Sortable: No

packing

Field does not exist in this collection.

After comprehensive research of the codebase, the packing field (also known as normalizedPackingString) does not exist in the generalLedger collection.

Where packing information IS available

The packing field exists in item-level collections that track specific product movements:

  • Order items (orderItemPacking)
  • Shipment items (shipmentItemPacking)
  • Return items (returnItemPacking)
  • Variance items (varianceItemPacking)
  • Stock items (stockPacking)
  • Scan lookup items (scanLookupPacking)

About the generalLedger collection

The generalLedger collection focuses on accounting transactions, tracking debits, credits, amounts, and account balances related to inventory and financial accounts. It does not include detailed product-level information like packing specifications.

If you need packing information in the context of a general ledger transaction, you would need to navigate through the transaction's relationships to the underlying item records (e.g., shipment items, order items) that contain packing details.

Label: Packing
Sortable: No

quantity

The number of items (in cases or other packing units) involved in an inventory-related general ledger transaction. This field captures the quantity when physical goods are moved or affected by business operations such as receiving shipments, shipping sales orders, processing returns, recording inventory variances, or completing manufacturing builds.

For transactions that involve physical inventory movement (shipments, variances, builds), this field records the actual quantity of items being moved or adjusted. For non-inventory transactions such as payments, invoices, or journal entries that don't involve physical goods, this field is set to 0.

The quantity value works in conjunction with the normalizedPackingString to indicate the packing unit being tracked (e.g., cases, each), and with the stockType field to indicate the inventory state (in stock, in transit, packed, or work-in-progress). Together with the units field, which converts quantity to individual units, this provides a complete picture of the physical inventory impact of each accounting entry.

Label: Quantity
Sortable: No

quantityCaseOrCaseEquivalent

The quantity expressed in cases when the transaction line packing is already in cases, or converted to case equivalents when the packing is in individual units. This field normalizes quantities to a case-based unit of measure for consistent comparison across different packing configurations.

For items tracked by case (where packing specifies cases, such as "cs 12/1"), this field shows the case quantity directly. For items tracked as individual units (where packing is blank or specifies units), the quantity is converted to case equivalents by dividing the unit quantity by the product's standard units per case. For example, if a transaction has 60 units and the product's standard packing is 12 units per case, this field would show 5.0 case equivalents.

This field is particularly useful for reporting and analysis when working with products that have varying packing configurations, as it provides a standardized view of quantities in case terms regardless of how the original transaction was recorded.

Label: Quantity, case or case equivalent
Sortable: No

quantityCaseStock

The quantity of inventory stored in case or packaged form (as opposed to open stock). This field returns the transaction quantity when the item has a normalized packing string defined, indicating it's tracked in cases, packs, or other standardized packaging units. If the item has no normalized packing string (meaning it's stored as open stock), this field returns 0. This allows for separate tracking and reporting of cased versus open inventory quantities within general ledger transactions.

Label: Quantity, case stock
Sortable: No

quantityOpenStock

The quantity of items counted as individual units rather than full cases. This field represents inventory tracked without case packing, where items are not organized into standard case configurations. When a general ledger transaction has a quantity value and the item's normalizedPackingString is 0 (indicating no case packing), this field returns that quantity; otherwise it returns an empty value. This is the counterpart to quantityCaseStock, which tracks quantities organized in full cases. Together, these fields allow inventory systems to separately track loose individual units and full case quantities for the same product in general ledger entries.

Label: Quantity, open stock
Sortable: No

recordDate

The date associated with the business event that generated the general ledger transaction. For inventory transactions, this is the date when the physical inventory movement occurred (such as when a shipment was packed or delivered, when a build was completed, or when stock was adjusted). For financial transactions like payments and invoices, this is the date when the transaction was posted. The recordDate is used for filtering and sorting general ledger entries by their chronological business occurrence, and defaults to a 30-day range in the general ledger view. This date is distinct from the transaction commit timestamp, which records when the transaction was actually committed in the system.

Label: Record date
Sortable: No

revenueAmount

The transaction amount for entries posted to revenue-classified general ledger accounts. This field filters the general ledger amount to only display values when the associated GL account belongs to the REVENUE taxonomy category (which includes SALES and OTHER_INCOME account types). For transactions posted to non-revenue accounts such as assets, liabilities, or expenses, this field returns null, allowing for selective analysis and reporting of revenue-related transactions in the general ledger.

Label: Revenue amount
Sortable: No

shortCode

A Finale-generated barcode identifier that uniquely represents a specific combination of product, packing configuration, and lot. This field appears in general ledger entries related to inventory transactions and provides a scannable reference code for the exact inventory item being tracked.

Short codes are specifically designated as "INVENTORY_SHORT_CODE" type scan lookups (distinct from regular barcodes) and are computed by combining the product URL, normalized packing string, and lot identifier. For example, a product "99010" in standard packing generates "0200000008000", while the same product in "12/1" packing generates "0200000008024", and product "99012/A" with lot "Mfg: 3/8/2010 2nd" generates "0200000008031".

The field is read-only and automatically populated for inventory-related general ledger entries (shipments, returns, variances, builds) where the underlying transaction has an associated scan lookup entry. For non-inventory transactions or transactions without defined short codes, this field remains empty.

Label: Short code
Sortable: No

sourceReason

Identifies the source or reason for a general ledger transaction, with the specific value depending on the transaction type. For sales-related transactions (invoices, payments, shipments), this field contains the sale source (e.g., "Online", "Email", "Phone", "Manual", or custom sale sources like "Amazon US"). For inventory variance transactions, this field contains the variance reason (e.g., "Damaged", "Expired", "Lost", "Found", "Spoiled"). The field combines two conceptually different dimensions into a single filterable field, allowing users to filter general ledger entries by either sale source or variance reason depending on the context of the transaction.

Label: Source / reason
Sortable: No

transactionCommitTimestamp

The timestamp when the underlying transaction that created this general ledger entry was committed to the database. This represents the exact moment the transaction was recorded in the system, which may differ from the accounting record date. The field can be filtered by date range and supports multiple display formats including full timestamp and abbreviated date-only format.

Label: Transaction timestamp
Sortable: No

transactionDescription

A human-readable description of the transaction that created each general ledger entry. The description combines the transaction type with an identifier (such as a shipment number, invoice number, or payment ID) and the transaction status.

For inventory-related transactions, descriptions follow patterns like "Purchase 891 received" for receiving purchase shipments, "Transfer 301 sent" or "Transfer 301 received" for transfer shipments, and "Stock change 103" for inventory variances. Quick stock changes and quick stock transfers display simplified descriptions without transaction IDs.

For financial transactions, descriptions include "Invoice posted", "Bill payment posted", "Sales payment posted", "Sales receipt posted", and "Supplier credit posted", each followed by the relevant document identifier.

For manufacturing transactions, descriptions follow patterns like "Build completed" or "Build started" with the associated work effort identifier.

For average cost adjustments and journal entries, descriptions display "Average cost change" or "Journal entry" followed by the entry identifier and status.

Summary rows in the general ledger display special descriptions: "Initial balance" for opening balances and "Ending balance" for closing balances. Correction rows display specific messages like "Missing purchase price correction", "Missing build valuation correction", or "Missing build consume cost correction" depending on the type of adjustment being corrected.

Label: Transaction description
Sortable: No
Default Formatter: html

Example Query:

{
  generalLedger(generalLedgerUrl: "example-url") {
    transactionDescription    # Uses default formatter: html
    transactionDescriptionRaw: transactionDescription(formatter: "none")  # Get raw value
  }
}

transactionDetails

Provides contextual information about the parties, locations, and other relevant details associated with a general ledger transaction. The field dynamically displays different information based on transaction type: for sales shipments, it shows customer name, origin facility, and tracking code; for purchase shipments, it shows supplier name, destination facility, and tracking code; for transfer shipments, it shows origin and destination facilities with tracking; for payment transactions, it shows the party (customer or supplier) and payment notes; for inventory variances, it shows observed quantity, reason, and notes; for work efforts, it shows the product being produced and description; for journal entries, it shows notes. The details are formatted as semicolon-separated key-value pairs (e.g., "Origin: Hdqtrs; Destination: South Annex; Tracking: B23"). For rollup transaction rows that consolidate multiple corrections, it displays the count of transactions being corrected. The field may be empty for certain transaction types that have no additional contextual details to display.

Label: Transaction details
Sortable: No

transactionId

The user-facing identifier for the transaction that created this general ledger entry. This is a polymorphic field that returns different ID values depending on the transaction type: for invoices it returns the invoice ID, for shipments the shipment ID (which may include an order ID and sequence number like "891-2"), for payments the payment ID, for journal entries the journal entry ID, for work efforts (builds) the build ID, and for inventory variances the variance ID. This field provides a human-readable reference to trace general ledger entries back to their originating business transactions.

Label: Transaction ID
Sortable: No

units

The total number of individual product units involved in a general ledger transaction, calculated by multiplying the quantity by the units per case from the normalized packing string. This field represents the actual count of individual items (as opposed to cases or packages) and is used in various calculations throughout the system.

For inventory-related transactions, the units field tracks the flow of individual items in and out of stock, and can be aggregated (generalLedgerUnitsSum), tracked as a running total (generalLedgerUnitsRunningSum), or tracked with initial balance (generalLedgerUnitsRunningSumWithInitialBalance). The field is also used to calculate amount per unit by dividing the transaction amount by units, which helps determine per-unit costs for inventory valuation and cost of goods sold calculations.

Units can be filtered by stock type (in stock, in transit, packed, or work-in-progress) to analyze inventory movement across different stages of the supply chain. When units is zero or null, the amount per unit calculation returns null to avoid division errors.

Label: Units
Sortable: No

unitsPerCase

The number of individual units contained within one case of a product, extracted from the normalized packing string. For example, a packing string of "12 cs 12/1" indicates 12 units per case. This value is used throughout the system to convert between case quantities and individual unit quantities in inventory calculations, order processing, and financial reporting. When calculating unit-based metrics, quantities are multiplied by unitsPerCase (e.g., quantity * unitsPerCase = total units). The value defaults to 1 for open stock items (items not packed in cases) or when the packing information is not available. This field is essential for accurate cost per unit calculations, pricing formulas, and inventory valuations across different packing configurations.

Label: Units per case
Sortable: No

weight

The total weight for a general ledger transaction line, calculated by multiplying the transaction quantity by the units per case (from the packing string) by the product's weight per unit, converted to the user's system of measure (imperial or metric). This provides a weight subtotal that aggregates weight across transaction quantities while respecting the user's preferred weight units (pounds or kilograms).

Label: Weight subtotal
Sortable: No

wipAmount

The monetary value of inventory that is currently in the work-in-progress state during manufacturing or production processes. This field represents the amount (in currency) for items that are being actively produced or transformed through work efforts, calculated based on the transaction cost of materials and resources consumed in production. WIP inventory includes materials, components, and partially completed products that have been allocated to production work orders but have not yet been completed and moved to finished goods. This field is typically associated with the WIP_INVENTORY general ledger account type and is commonly used alongside wipQuantity and wipUnits to track the financial value of goods in production, appearing in inventory reports to monitor capital tied up in the manufacturing process.

Label: WIP amount
Sortable: No

wipQuantity

The quantity of inventory that is currently in work-in-progress (WIP) state during manufacturing or production processes. This field specifically represents stock with stockType 3 (WIP), which indicates materials and components that have been allocated to production work orders but have not yet been completed and moved to finished goods.

When a build is started and materials are consumed for production, the inventory transitions to WIP status. The wipQuantity tracks the quantity of these items that are actively being produced or transformed through work efforts. This represents the middle state in the manufacturing process where goods are partially completed or materials are being consumed to produce finished products.

This field returns an empty value when the stockType is not WIP (e.g., in stock, packed, or in transit) and returns the actual quantity value when stockType is 3 (WIP). It is used in conjunction with related fields like wipAmount and wipUnits to provide complete visibility into inventory and financial value tied up in the manufacturing process. Together, these fields help track both consuming materials (inputs to production) and producing items (outputs being created) in work orders.

Label: WIP quantity
Sortable: No

wipUnits

The number of individual units (eaches) for inventory that is currently classified as work-in-progress (WIP). This field converts the quantity based on the packing configuration. For example, if the quantity is 10 and the packing is "cs 12/1" (12 cases of 12 units each), the wipUnits would be 120 (10 cases × 12 units per case). When no packing is specified, wipUnits equals the quantity. This field only applies to items with stockType 3 (WIP); for other stock types like in-stock or in-transit inventory, the value is not applicable. WIP inventory typically represents materials that are currently being consumed in manufacturing processes or builds.

Label: WIP units
Sortable: No

Enum Fields

These fields return one of a predefined set of values.

consolidationStatus

Indicates whether a transaction has been consolidated for accounting purposes. This field is used when the "Consolidate transactions" integration is active, which allows multiple individual sales transactions to be summarized into single consolidated journal entries that are pushed to the accounting system instead of each individual transaction.

The field has four possible values:

  • Excluded: The transaction is not eligible for consolidation (default for most transactions)
  • Pending: The transaction matches an active consolidation configuration and is eligible to be included in a future consolidated journal entry
  • Consolidated: The transaction has been included in a posted consolidated journal entry
  • Consolidation: The transaction itself is a consolidated journal entry that summarizes other transactions

Transactions are marked as "Pending" when they match the criteria defined in consolidation configurations (based on equivalence class, transaction type, and sale source). Once a consolidated journal entry is created and posted containing these transactions, their status changes to "Consolidated". The general ledger view typically filters to exclude consolidated transactions and show consolidations by default, preventing double-counting in reports.

Label: Consolidation status
Sortable: No

Possible Values:

  • ##consolidationStatusExcluded - Excluded
  • ##consolidationStatusPending - Pending
  • ##consolidationStatusConsolidated - Consolidated
  • ##consolidationStatusConsolidation - Consolidation

rowType

Categorizes each row in the general ledger as either a regular transaction or a correction entry. Transaction rows represent normal accounting entries from business operations (sales, purchases, builds, etc.), while correction rows represent system-generated adjustments that fix missing or incomplete cost information from prior transactions. Correction rows are specifically used for scenarios like missing purchase prices, missing build valuations, or missing build consume costs. This field allows filtering and distinguishing between actual business transactions and automated accounting corrections.

The field has two possible values:

  • Transaction: Regular accounting entries from business operations
  • Correction: System-generated adjustments for missing cost information

Label: Row type
Sortable: No

Possible Values:

  • ##rowTransaction - Transaction
  • ##rowRollupTransaction - Correction

stockType

Indicates the inventory status category for general ledger entries that affect inventory accounts. This field classifies whether the transaction impacts stock that is "In stock", "In transit", "Packed", or "WIP" (work in progress). For entries that post to non-inventory accounts (such as accounts payable, revenue, or variance accounts), this field is set to an invalid/null state since the transaction doesn't affect a specific inventory location or status. This allows filtering and reporting on inventory-related transactions by their stock status, enabling analysis of inventory value movements across different inventory states.

Label: Stock type
Sortable: No

Possible Values:

  • 0 - In stock
  • 1 - In transit
  • 2 - Packed
  • 3 - WIP

summaryRows

A filter field used to control which types of rows are included in general ledger queries. The general ledger contains three types of rows: initial summary rows (showing the initial balance), transaction rows (showing individual transactions), and ending summary rows (showing the ending balance). This filter accepts a list of values to determine which row types to include: "##rowInitialSummary" for initial balance rows, "##rowTransaction" for transaction rows, and "##rowEndingSummary" for ending balance rows. When this filter is applied, transaction rows are always included automatically, so filtering to just summary rows will return initial summaries, ending summaries, and all transactions. This allows users to view complete ledger data with opening and closing balances while still seeing all transaction details.

Label: Summary rows
Sortable: No

Possible Values:

  • ##rowInitialSummary - Initial summary
  • ##rowTransaction - Transaction
  • ##rowEndingSummary - Ending summary

transactionStatus

Indicates the current status of the transaction that created this general ledger entry. The field can have three values: Posted, Canceled, or Pending. Posted transactions represent completed, finalized transactions that are included in financial calculations. Canceled transactions are transactions that were initiated but later voided or reversed, and are excluded from sum metrics in reports to prevent them from affecting financial totals. Pending transactions represent transactions that have been created but not yet finalized. The transaction status reflects the state of the underlying source transaction, such as the status of a shipment (e.g., SHIPMENT_SHIPPED for posted, SHIPMENT_CANCELLED for canceled, SHIPMENT_INPUT for pending). When filtering general ledger data, the default behavior is to show only Posted transactions.

Label: Transaction status
Sortable: No

Possible Values:

  • ##transactionPosted - Posted
  • ##transactionCanceled - Canceled
  • ##transactionPending - Pending

transactionType

Categorizes general ledger transactions into high-level business transaction types. This field classifies each transaction by its fundamental business purpose, such as whether it represents a sale shipment, purchase shipment, invoice, payment, journal entry, build, transfer, stock adjustment, or consolidation.

The transaction type determines which entity (shipment, invoice, payment, journal entry, etc.) the transaction relates to and provides a simplified view for reporting and filtering. For example, multiple detailed transaction update types for invoices (receivable invoice posted, payable invoice posted, sales receipt posted, supplier credit posted) all map to their respective high-level transaction types (Invoice, Bill, Sales receipt, Supplier credit).

This field is commonly used in general ledger filters and reports to analyze transactions by their business purpose. For instance, users can filter to see only invoice-related transactions, or only shipment-related transactions, regardless of the specific state or subtype of those transactions. The transaction type works in conjunction with the more granular transaction update type field, which tracks specific states and steps within each transaction type.

Label: Transaction type
Sortable: No

Possible Values:

  • 1050 - Sale shipment
  • 1051 - Transfer
  • 1052 - Purchase shipment
  • 1053 - Return shipment
  • 1054 - Stock change or take
  • 1055 - Build
  • 1056 - Invoice
  • 1057 - Journal entry
  • 1058 - Bill
  • 1059 - Sales receipt
  • 1060 - Bill payment
  • 1061 - Sales payment
  • 1062 - Consolidation
  • 1063 - Supplier credit

transactionUpdateType

Represents the specific state or action within a transaction lifecycle that generated the general ledger entry. While transaction types categorize entries by business entity (such as sales shipment, invoice, or payment), transaction update types provide granular detail about the specific event or update that occurred within that transaction.

For example, a sales shipment transaction may generate multiple general ledger entries with different update types: one for COGS when shipped (value 50), another for income recognition (value 51), entries for packing (71), unpacking (72), or transfer activities (74). Similarly, invoices, payments, bills, journal entries, inventory variances, builds, and other transactions each have associated update types that track their various stages and accounting impacts.

Transaction update types in the general ledger collection range from 50 to 77, with each numeric value representing a specific combination of transaction category and event. These values map back to their parent transaction types (values 1050-1063) through the system's transaction type hierarchy.

This field is commonly used for filtering and grouping general ledger entries by specific transaction events, particularly in consolidation configurations where different update types within the same equivalence class (such as sales COGS or sales income) are grouped together for accounting integration purposes. The field is also used to determine which entity configurations to apply when syncing transactions to external accounting systems.

Label: Transaction update type
Sortable: No

Possible Values:

  • 50 - Sale shipment shipped COGS
  • 51 - Sale shipment shipped income
  • 52 - Purchase shipment received
  • 53 - Invoice posted
  • 54 - Stock change or take
  • 55 - Build completed
  • 56 - Return shipment received
  • 57 - Purchase shipment valuation change
  • 58 - Return shipment received income
  • 59 - Journal entry completed
  • 60 - Average cost change
  • 61 - Bill posted
  • 62 - Sales receipt posted
  • 63 - Bill payment posted
  • 64 - Sales payment posted
  • 65 - Consolidation posted
  • 66 - Supplier credit posted
  • 67 - Transfer shipment shipped
  • 68 - Transfer shipment received
  • 69 - Build started
  • 70 - Stock transferred
  • 71 - Sale shipment packed
  • 72 - Sale shipment unpacked
  • 73 - Packed shipment shipped COGS
  • 74 - Packed shipment transferred
  • 75 - Purchase shipment inventory reallocated
  • 76 - Build produce inventory reallocated
  • 77 - Build produce valuation change

warning

An array of warning flags that indicate potential issues or anomalies with a general ledger transaction. Each entry is represented as an icon with a tooltip message in the UI. The warning field can contain multiple values simultaneously:

  • Missing average cost: The transaction involves a product where the average cost could not be determined at the time of the transaction. This typically occurs with sales shipments, inventory variances, work effort production/consumption, and transfers when average cost data is unavailable. When this warning is present, the system uses a zero value for cost calculations.

  • Missing purchase price: The purchase price is not available for a purchase shipment transaction. When this warning occurs, the system uses an expected amount based on missing cost calculations instead of the actual purchase price.

  • Product value missing quantity: An inventory valuation change was applied to a product with zero quantity on hand. This indicates that a cost adjustment is being recorded for a product that has no inventory to apply it to.

  • Expected/resulting cost mismatch: For inventory valuation changes, the expected resulting cost after the adjustment does not match the actual resulting cost. This suggests a discrepancy in the cost calculation.

The warning field is computed automatically based on transaction type and the state of inventory and cost data at the time of the transaction. Canceled transactions display a "Canceled" warning with an error icon, and pending transactions display a "Pending" warning with a loop icon.

Label: Warning
Type: ##iconWithTooltip
Sortable: No

Possible Values:

  • ##glWarningAverageCost - Missing average cost
  • ##glWarningPurchasePrice - Missing purchase price
  • ##glWarningValueAppliedToZeroQuantity - Product value missing quantity
  • ##glWarningExpectedResultingCostMismatch - Expected/resulting cost mismatch

Relations

account

  • Related Collection: generalLedgerAccount
  • Label: Account

TODO: Add relation description

party

  • Related Collection: party
  • Label: Customer / supplier

TODO: Add relation description

connectionRelation

  • Related Collection: connectionRelation
  • Label: Integration

TODO: Add relation description

product

  • Related Collection: product
  • Label: Product

TODO: Add relation description

sublocation

  • Related Collection: facility
  • Label: Sublocation

TODO: Add relation description

transactionCommitUser

  • Related Collection: userLogin
  • Label: Transaction user

TODO: Add relation description

Filters

account

  • Label: Account
  • Type: String
  • Enabled: Yes

Filter Type: Text value

This filter accepts freeform text values.

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    account: "Sales Revenue"
  ) {
    edges {
      node {
        generalLedgerId
        account
      }
    }
  }
}

accountType

  • Label: Account type
  • Type: String
  • Enabled: Yes

Filter Type: Text value

This filter accepts freeform text values.

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    accountType: "Revenue"
  ) {
    edges {
      node {
        generalLedgerId
        accountType
      }
    }
  }
}

balanceTypeLineItem

  • Label: Net credit/debit for transaction
  • Type: String
  • Enabled: Yes
  • Options:
    • Show all items (##allBalanceLineItem)
    • Show non-zero account items only (##nonZeroBalanceLineItem)
    • Show single account items only (##zeroBalanceAccountLineItem)
    • Show zero amount items only (##zeroBalanceLineItem)

Filter Type: Predefined options

Get Current Options:

These options may vary by account configuration. To get the current list:

query {
  dataSetMeta(purpose: "uiGeneralLedger") {
    dataSets(name: "generalLedger") {
      filters {
        name
        optionList {
          value
          label
        }
      }
    }
  }
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    balanceTypeLineItem: ["##zeroBalanceLineItem", "##nonZeroBalanceLineItem"]
  ) {
    edges {
      node {
        generalLedgerId
        balanceTypeLineItem
      }
    }
  }
}

connectionRelationErrorDates

  • Label: Latest error date
  • Type: dateRangeInput
  • Enabled: Yes

Filter Type: Date range

Input Structure:

{
  begin: string  // ISO date format: "2024-01-01"
  end: string    // ISO date format: "2024-12-31"
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    connectionRelationErrorDates: {
      begin: "2024-01-01"
      end: "2024-12-31"
    }
  ) {
    edges {
      node {
        generalLedgerId
        connectionRelationErrorDates
      }
    }
  }
}

connectionRelationSyncStatuses

  • Label: Sync status
  • Type: List|String
  • Enabled: Yes
  • Options:
    • Excluded from syncing (##crStatusSkipped)
    • Has error (##crStatusError)
    • Not synced (##crStatusNotPushed)
    • Partially synced (##crStatusPartiallySynced)
    • Synced (##crStatusPushed)

Filter Type: Predefined options

Get Current Options:

These options may vary by account configuration. To get the current list:

query {
  dataSetMeta(purpose: "uiGeneralLedger") {
    dataSets(name: "generalLedger") {
      filters {
        name
        optionList {
          value
          label
        }
      }
    }
  }
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    connectionRelationSyncStatuses: ["##crStatusNotPushed", "##crStatusPushed"]
  ) {
    edges {
      node {
        generalLedgerId
        connectionRelationSyncStatuses
      }
    }
  }
}

consolidationStatus

  • Label: Consolidation status
  • Type: List|String
  • Enabled: Yes
  • Options:
    • Consolidated (##consolidationStatusConsolidated)
    • Consolidation (##consolidationStatusConsolidation)
    • Excluded (##consolidationStatusExcluded)
    • Pending (##consolidationStatusPending)

Filter Type: Predefined options

Get Current Options:

These options may vary by account configuration. To get the current list:

query {
  dataSetMeta(purpose: "uiGeneralLedger") {
    dataSets(name: "generalLedger") {
      filters {
        name
        optionList {
          value
          label
        }
      }
    }
  }
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    consolidationStatus: ["##consolidationStatusExcluded", "##consolidationStatusPending"]
  ) {
    edges {
      node {
        generalLedgerId
        consolidationStatus
      }
    }
  }
}

facilityUrl

  • Label: Facility
  • Type: List|FacilityUrlLocationOrSublocationString
  • Enabled: Yes

Filter Type: Reference to facility collection

Note: Includes both locations and sublocations

This filter accepts values from the facilityViewConnection query. To get available values:

query {
  facilityViewConnection(
    first: 100
    type: ["FACILITY_LOCATION", "FACILITY_SUBLOCATION"]
    status: "FACILITY_ACTIVE"
  ) {
    edges {
      node {
        facilityUrl    # Use this value in the filter
        name
      }
    }
  }
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    facilityUrl: ["FACILITY_URL_VALUE"]
  ) {
    edges {
      node {
        generalLedgerId
        facility {
          name
        }
      }
    }
  }
}

inventoryValuationFacilityDetail

  • Label: Inventory valuation facility detail
  • Type: String
  • Enabled: Yes

Filter Type: Text value

This filter accepts freeform text values.

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    inventoryValuationFacilityDetail: "Warehouse A"
  ) {
    edges {
      node {
        generalLedgerId
        inventoryValuationFacilityDetail
      }
    }
  }
}

orderOrderUrl

  • Label: Order
  • Type: OrderUrlString
  • Enabled: Yes

Filter Type: Reference to order collection

This filter accepts values from the orderViewConnection query. To get available values:

query {
  orderViewConnection(
    first: 100
  ) {
    edges {
      node {
        orderUrl    # Use this value in the filter
        orderId
      }
    }
  }
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    orderOrderUrl: "ORDER_URL_VALUE"
  ) {
    edges {
      node {
        generalLedgerId
        order {
          orderId
        }
      }
    }
  }
}

productUrl

  • Label: Product
  • Type: List|ProductUrlString
  • Enabled: Yes

Filter Type: Reference to product collection

This filter accepts values from the productViewConnection query. To get available values:

query {
  productViewConnection(
    first: 100
  ) {
    edges {
      node {
        productUrl    # Use this value in the filter
        title
      }
    }
  }
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    productUrl: ["PRODUCT_URL_VALUE"]
  ) {
    edges {
      node {
        generalLedgerId
        product {
          title
        }
      }
    }
  }
}

recordDate

  • Label: Record date
  • Type: dateRangeInput
  • Enabled: Yes

Filter Type: Date range

Input Structure:

{
  begin: string  // ISO date format: "2024-01-01"
  end: string    // ISO date format: "2024-12-31"
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    recordDate: {
      begin: "2024-01-01"
      end: "2024-12-31"
    }
  ) {
    edges {
      node {
        generalLedgerId
        recordDate
      }
    }
  }
}

rowType

  • Label: Row type
  • Type: List|String
  • Enabled: Yes
  • Options:
    • Correction (##rowRollupTransaction)
    • Transaction (##rowTransaction)

Filter Type: Predefined options

Get Current Options:

These options may vary by account configuration. To get the current list:

query {
  dataSetMeta(purpose: "uiGeneralLedger") {
    dataSets(name: "generalLedger") {
      filters {
        name
        optionList {
          value
          label
        }
      }
    }
  }
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    rowType: ["##rowTransaction", "##rowRollupTransaction"]
  ) {
    edges {
      node {
        generalLedgerId
        rowType
      }
    }
  }
}

sourceReason

  • Label: Source / reason
  • Type: List|String
  • Enabled: Yes

Filter Type: Text value

This filter accepts freeform text values.

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    sourceReason: "Sale"
  ) {
    edges {
      node {
        generalLedgerId
        sourceReason
      }
    }
  }
}

stockType

  • Label: Stock type
  • Type: List|String
  • Enabled: Yes
  • Options:
    • In stock (0)
    • In transit (1)
    • Packed (2)
    • WIP (3)

Filter Type: Predefined options

Get Current Options:

These options may vary by account configuration. To get the current list:

query {
  dataSetMeta(purpose: "uiGeneralLedger") {
    dataSets(name: "generalLedger") {
      filters {
        name
        optionList {
          value
          label
        }
      }
    }
  }
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    stockType: ["0", "1"]
  ) {
    edges {
      node {
        generalLedgerId
        stockType
      }
    }
  }
}

summaryRows

  • Label: Summary rows
  • Type: List|String
  • Enabled: Yes
  • Options:
    • Ending summary (##rowEndingSummary)
    • Initial summary (##rowInitialSummary)

Filter Type: Predefined options

Get Current Options:

These options may vary by account configuration. To get the current list:

query {
  dataSetMeta(purpose: "uiGeneralLedger") {
    dataSets(name: "generalLedger") {
      filters {
        name
        optionList {
          value
          label
        }
      }
    }
  }
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    summaryRows: ["##rowInitialSummary", "##rowEndingSummary"]
  ) {
    edges {
      node {
        generalLedgerId
        summaryRows
      }
    }
  }
}

transactionCommitTimestamp

  • Label: Transaction timestamp
  • Type: dateRangeInput
  • Enabled: Yes

Filter Type: Date range

Input Structure:

{
  begin: string  // ISO date format: "2024-01-01"
  end: string    // ISO date format: "2024-12-31"
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    transactionCommitTimestamp: {
      begin: "2024-01-01"
      end: "2024-12-31"
    }
  ) {
    edges {
      node {
        generalLedgerId
        transactionCommitTimestamp
      }
    }
  }
}

transactionCommitUser

  • Label: Transaction user
  • Type: List|UserLoginUrlString
  • Enabled: Yes

Filter Type: Text value

This filter accepts freeform text values.

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    transactionCommitUser: "admin"
  ) {
    edges {
      node {
        generalLedgerId
        transactionCommitUser
      }
    }
  }
}

transactionCommitUserAccountType

  • Label: Transaction user account type
  • Type: List|String
  • Enabled: Yes
  • Options:
    • API connection (##apiConnection)
    • External user (##externalAuth)
    • Finale staff (##finaleStaff)
    • Finale user (##normal)

Filter Type: Predefined options

Get Current Options:

These options may vary by account configuration. To get the current list:

query {
  dataSetMeta(purpose: "uiGeneralLedger") {
    dataSets(name: "generalLedger") {
      filters {
        name
        optionList {
          value
          label
        }
      }
    }
  }
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    transactionCommitUserAccountType: ["##finaleStaff", "##externalAuth"]
  ) {
    edges {
      node {
        generalLedgerId
        transactionCommitUserAccountType
      }
    }
  }
}

transactionStatus

  • Label: Transaction status
  • Type: String
  • Enabled: Yes
  • Options:
    • Canceled (##transactionFilterCanceled)
    • Pending (##transactionFilterPending)
    • Posted (##transactionFilterPosted)
    • Posted, pending, or canceled (##transactionFilterAll)

Filter Type: Predefined options

Get Current Options:

These options may vary by account configuration. To get the current list:

query {
  dataSetMeta(purpose: "uiGeneralLedger") {
    dataSets(name: "generalLedger") {
      filters {
        name
        optionList {
          value
          label
        }
      }
    }
  }
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    transactionStatus: ["##transactionFilterPosted", "##transactionFilterCanceled"]
  ) {
    edges {
      node {
        generalLedgerId
        transactionStatus
      }
    }
  }
}

transactionType

  • Label: Transaction type
  • Type: List|String
  • Enabled: Yes
  • Options:
    • Bill (1058)
    • Bill payment (1060)
    • Build (1055)
    • Consolidation (1062)
    • Invoice (1056)
    • Journal entry (1057)
    • Purchase shipment (1052)
    • Return shipment (1053)
    • Sale shipment (1050)
    • Sales payment (1061)
    • Sales receipt (1059)
    • Stock change or take (1054)
    • Supplier credit (1063)
    • Transfer (1051)

Filter Type: Predefined options

Get Current Options:

These options may vary by account configuration. To get the current list:

query {
  dataSetMeta(purpose: "uiGeneralLedger") {
    dataSets(name: "generalLedger") {
      filters {
        name
        optionList {
          value
          label
        }
      }
    }
  }
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    transactionType: ["1050", "1051"]
  ) {
    edges {
      node {
        generalLedgerId
        transactionType
      }
    }
  }
}

transactionUpdateType

  • Label: Transaction update type
  • Type: List|String
  • Enabled: Yes
  • Options:
    • Average cost change (60)
    • Bill payment posted (63)
    • Bill posted (61)
    • Build completed (55)
    • Build produce inventory reallocated (76)
    • Build produce valuation change (77)
    • Build started (69)
    • Consolidation posted (65)
    • Invoice posted (53)
    • Journal entry completed (59)
    • Packed shipment shipped COGS (73)
    • Packed shipment transferred (74)
    • Purchase shipment inventory reallocated (75)
    • Purchase shipment received (52)
    • Purchase shipment valuation change (57)
    • Return shipment received (56)
    • Return shipment received income (58)
    • Sale shipment packed (71)
    • Sale shipment shipped COGS (50)
    • Sale shipment shipped income (51)
    • Sale shipment unpacked (72)
    • Sales payment posted (64)
    • Sales receipt posted (62)
    • Stock change or take (54)
    • Stock transferred (70)
    • Supplier credit posted (66)
    • Transfer shipment received (68)
    • Transfer shipment shipped (67)

Filter Type: Predefined options

Get Current Options:

These options may vary by account configuration. To get the current list:

query {
  dataSetMeta(purpose: "uiGeneralLedger") {
    dataSets(name: "generalLedger") {
      filters {
        name
        optionList {
          value
          label
        }
      }
    }
  }
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    transactionUpdateType: ["50", "51"]
  ) {
    edges {
      node {
        generalLedgerId
        transactionUpdateType
      }
    }
  }
}

warning

  • Label: Warning
  • Type: List|String
  • Enabled: Yes
  • Options:
    • Expected/resulting cost mismatch (##glWarningExpectedResultingCostMismatch)
    • Missing average cost (##glWarningAverageCost)
    • Missing purchase price (##glWarningPurchasePrice)
    • Product value missing quantity (##glWarningValueAppliedToZeroQuantity)

Filter Type: Predefined options

Get Current Options:

These options may vary by account configuration. To get the current list:

query {
  dataSetMeta(purpose: "uiGeneralLedger") {
    dataSets(name: "generalLedger") {
      filters {
        name
        optionList {
          value
          label
        }
      }
    }
  }
}

Usage Example:

query {
  generalLedgerViewConnection(
    first: 10
    warning: ["##glWarningAverageCost", "##glWarningPurchasePrice"]
  ) {
    edges {
      node {
        generalLedgerId
        warning
      }
    }
  }
}