Acumatica GI with Multiple Data Sources

"Multiple data sources" in a GI means two different things depending on who is asking, and it is worth separating them because one is routine and the other is a genuine limitation you need to design around.

Multiple tables within one Acumatica instance — this is just joins

If "multiple data sources" means pulling from several DACs across different modules — say, sales order headers, GL batches, and a custom manufacturing table — that is simply the Tables tab of a normal GI, joined however the business relationship requires. There is no real limit on how many tables a GI can reference beyond practical query performance; I have built GIs joining six or seven tables across SO, IN, and a custom module without incident, though each join is a cost worth justifying, as covered in the cross-table-joins piece. This case is not a limitation at all — it is the GI Designer's entire job.

Genuinely external data sources — this is the real constraint

The harder case, and the one people actually mean when they ask "can a GI combine Acumatica data with our other system's data": no, not directly. A GI's schema is BQL against Acumatica DACs; it has no connector framework for reaching into an external SQL Server instance, a REST API, or a flat file sitting on a network share. If the requirement is "show Acumatica sales orders next to fulfillment status from our separate WMS", the GI cannot reach across that boundary on its own.

The staging-table pattern in practice

For clients who need the "external data visible inside Acumatica" outcome, I build a plain custom DAC — no complex business logic, just columns mirroring what the external system exposes — and a small scheduled processing screen or a webhook-receiving endpoint that keeps it populated. The GI then joins this staging table to native Acumatica tables exactly as if it were original data:

Primary:  SOOrder
Join:     LeftJoin  KGWmsFulfillmentStatus
          On KGWmsFulfillmentStatus.OrderNbr = SOOrder.OrderNbr
-- KGWmsFulfillmentStatus is a custom DAC populated nightly
-- by a scheduled job calling the WMS's REST API

The tradeoff to be explicit with clients about: this data is only as fresh as the last sync, and the GI itself cannot tell you that — build a "last synced" timestamp column into the staging table and surface it in the GI so users know how current what they are looking at actually is.

Wrapping up

Joining multiple Acumatica tables in one GI is routine and effectively unlimited within reason. Combining Acumatica with a genuinely external system is not something a GI can do directly — either land the external data in a staging DAC first and join locally, or combine both sides downstream in an external reporting layer. Which one is right depends on whether the combined view needs to live inside Acumatica's own UI.