Acumatica GI as a Data Warehouse Feed

Using Generic Inquiries as the extraction layer for a data warehouse is one of the most reliable integration patterns in the Acumatica ecosystem, and also one of the most commonly under-engineered — clients build one broad "everything" GI, point an ETL tool at it, and are surprised eighteen months later that the nightly load takes four hours and occasionally drops rows.

Why GI + OData beats querying the database directly

The temptation on private-cloud deployments is to skip GIs entirely and have the warehouse's ETL tool query the Acumatica database directly. Resist it. The schema carries implementation details — CompanyID tenant discrimination, DeletedDatabaseRecord soft-delete flags, denormalized balance and history tables that do not mean what their column names suggest — and none of that is documented as a stable contract. A GI exposed via OData is a contract you control: it applies tenant scoping and soft-delete filtering automatically, and its shape only changes when you change it.

GET /odata/KG-ARInvoiceFeed?$filter=LastModifiedDateTime ge 2026-07-08T00:00:00Z
    &$orderby=LastModifiedDateTime
    &$top=5000
Authorization: Basic {integration user}

Design for incremental extraction from day one

A full-table pull every night is the single biggest cause of "the load takes four hours" tickets. The fix is a LastModifiedDateTime (or equivalent audit timestamp field, present on most Acumatica DACs) watermark condition on the GI, combined with the ETL tool tracking the high-water mark from the previous run:

• Add LastModifiedDateTime >= @Watermark as a GI condition, with the parameter fed by the orchestration tool.
• Sort by that same field so pagination is stable across pages within one run.
• Handle deletes separately — a soft-deleted or genuinely removed record will not appear in an incremental "modified since" pull. If the warehouse needs to reflect deletions, you need either a separate "deleted records" feed (some entities expose this) or a periodic full reconciliation pass alongside the incremental daily pulls.

Pagination discipline

OData feeds from GIs are paginated ($top/$skip, or a continuation pattern depending on version), and a naive ETL pull that does not respect pagination silently truncates at the default page size — I have seen "the warehouse total is smaller than the ERP total" tickets that were exactly this, with no error anywhere, just a quietly truncated feed. Confirm your ETL tool's OData connector honors server-driven paging, and size batches (1,000–5,000 rows per page is a reasonable range) to balance request count against per-request payload.

Treat the feed GI as a versioned contract

Once a warehouse depends on a GI's shape, renaming or removing a column breaks the downstream load silently until someone notices a dashboard is wrong. I add new columns freely but never remove or rename an existing one on a feed GI already in production — if a field genuinely needs to change shape, I publish a new GI (KG-ARInvoiceFeed-v2) and migrate the ETL job deliberately, retiring the old one only after the new one has been validated in production for a full cycle.

Wrapping up

A GI-backed OData feed is the right extraction layer for a warehouse because it inherits tenant scoping and soft-delete handling for free — direct database access does not. Design for incremental pulls watermarked on a true last-modified timestamp, respect server-side pagination explicitly, and version the feed GI's schema rather than editing it in place once anything downstream depends on it.