Acumatica GI Versioned Templates

Generic Inquiries are customization metadata, which means they can and should live in source control the same way a DAC extension or a graph extension does — and in every instance where I have inherited GIs that were only ever edited live in production, the lack of versioning has eventually caused a real incident: a GI silently broken by an edit nobody remembers making, or a "which version is actually live" argument during a go-live weekend.

GIs belong in a customization project, not free-edited live

The GI Designer (SM208000) lets you create and edit a Generic Inquiry directly against a live site with no project context at all — convenient for prototyping, dangerous as a permanent workflow. The moment a GI is used by anyone beyond you experimenting, it should be created or moved into a customization project, exported, and committed:

1. Open/create the GI inside an active Customization Project (not directly
   on the live site) via Customization Project Editor -> Generic Inquiries.
2. Design and test in a dev/test instance.
3. Export the project (.zip), extract, commit the GI's XML definition
   alongside the rest of the customization package in git.
4. Publish the project to higher environments through your normal
   deployment pipeline, not by hand-editing the GI in each environment.

This gets you the same benefits any code gets from source control: a diff showing exactly what changed between versions, a commit message explaining why, the ability to revert a bad change in seconds instead of trying to remember what the condition used to say, and a single source of truth for what "production" is actually running.

Naming conventions for GIs that need to evolve without breaking consumers

Renaming or restructuring a GI in place is fine when nothing external depends on its exact shape. It is not fine once something is consuming it via OData, a dashboard, or a scheduled export — those consumers reference the GI by name and expect a stable column contract. My convention for GIs with external consumers:

• Never remove or rename an existing column on a published, consumed GI — only add.
• If a breaking reshape is genuinely necessary, publish a new GI with a version suffix (KG-ARInvoiceFeed-v2), let both run in parallel, migrate consumers deliberately, and only retire the old one once nothing references it — verified via access logs or, more crudely, by asking every known consumer team directly.
• Put a short changelog in the GI's Description field even when the real history lives in git — the Description is what someone stares at from inside the live Acumatica UI at 2 a.m., without necessarily having the repo open.

Testing before promoting a new version

Because GI changes can silently alter row counts or column meaning (a join tweak fanning out rows, a condition change narrowing results), I run the same row-count and spot-check discipline described in the cross-table-joins piece before promoting any GI version change beyond dev — compare old-version and new-version output against the same test parameters, and confirm the diff is exactly the intended change and nothing else.

Wrapping up

Treat GIs as versioned customization artifacts from the start: build and edit them inside a customization project under source control rather than live on production, never break a published GI's column contract once something external consumes it, and version-suffix genuinely breaking changes instead of reshaping in place. The discipline costs a few extra minutes per change and saves the "who changed this and why" fire drill every time.