How do you know what a GI's OData column names and order will be?

Hi ​@saratvemuri ,

The property list an exposed Generic Inquiry returns over OData is neither the order nor the exact set of columns you put in the Results Grid. Here is how Acumatica handles it:

1. The Key Fields Always Come First

Acumatica will automatically hoist any "Entity Keys" (the primary key fields of the tables included in your GI) to the very front of the OData field list. It does this regardless of where you positioned them in the GI Results Grid, or even if you included them in the Results Grid at all.

2. Field Names vs. Aliases

While you can assign a "friendly" header name or alias in the GI Results Grid, the OData feed often defaults to the underlying system field name or a generated alias (for example, outputting BranchID_2 instead of a custom label like "Company").

The Solution: How to know the exact schema

Because the output doesn't perfectly mirror your GI configuration, you cannot rely purely on the Results Grid to determine the final OData schema.

The definitive way to see the exact column names, data types, and order is to inspect the $metadata endpoint for your specific GI.

To do this, navigate to your OData URL in a web browser and append $metadata to the end:

https://<YourAcumaticaInstance>/odata/<TenantName>/<YourGIName>/$metadata

This will return an XML schema that explicitly defines every property and its type as it will be exposed by the OData service.

Hope above helps!!

Thanks ​@Rakshanda. 

I understand that $metadata give the property names.  But It doesn’t tell me what those map to on the results grid.  You can usually pair them by eye, if you are human :-).   

I was using Claude to document GIs at scale (About 115 GIs) so that it helps with AI descriptions that then would make them more useful via MCP (This is the MCP4Acumatica project I built and is open source).  As good as models are these days, apparently it can’t always know that column acctCD came across as property EmployeeID.  So, documenting the projection i.e. how result grid maps to odata properties would be very helpful in this case.

Our solution for now is to explicitly set a name in the Caption field, which becomes the property name.  

Also, the above URL needs /t and /api and $metadata at service root can cover exposed GI at once:https://<instance>/t/<TenantName>/api/odata/gi/$metadata

Hi ​@saratvemuri 

Thank you for sharing the updated OData URL structure

(https://<instance>/t/<TenantName>/api/odata/gi/$metadata)—retrieving the metadata for all exposed GIs at the service root is definitely much more efficient when documenting at scale!

Your workaround of explicitly setting the Caption field in the Results Grid is a great solution. Here's why that is the best approach for programmatic mapping:

When Acumatica generates the OData projection for a Generic Inquiry, it tries to derive the property name from the underlying Data Access Class (DAC) field (e.g., acctCD). If multiple tables have the same field name, or if it resolves it in a non-obvious way, the default mapping becomes unpredictable (as you saw with acctCD becoming EmployeeID).

By explicitly defining a Caption, you are overriding the default resolution logic. Acumatica respects the explicit Caption as the alias for the OData property name. This creates a hard, deterministic link between what you define in the GI and what is exposed in the API, eliminating the guesswork for an LLM (or any integration) trying to map the GI Results Grid back to the $metadata schema.

It sounds like your MCP4Acumatica project is doing some really interesting things by leveraging LLMs to interpret and document these inquiries. Forcing a 1:1 mapping via the Caption field is definitely the most robust way to give Claude (or any AI) the exact schema it needs to bridge that gap!