Infor SyteLine3 min readNetray Engineering TeamUpdated March 4, 2025

The SyteLine Data Dictionary: What It Should Be and How to Keep It Alive

Every serious piece of SyteLine work, reports, integrations, customizations, upgrades, starts with the same question: what is actually in this database? The official answer is the Infor DataMap for CloudSuite Industrial, and it is a good start. But your database is not the factory schema. It is the factory schema plus fifteen years of user-defined fields, custom tables, and integrator additions. A useful SyteLine data dictionary describes that reality, and it stays current without someone maintaining a spreadsheet.

Why the Infor DataMap Is Necessary but Not Sufficient

The DataMap documents the delivered schema: the co and coitem order tables, the item master, the po purchasing tables, the job and jobmatl manufacturing structures, and the conventions that bind them, _mst suffixes on master tables and site_ref columns for multi-site scoping. What it cannot document is your site: which user-defined fields carry real meaning, which custom tables your integrations depend on, which delivered columns were quietly repurposed. Any dictionary that ignores the delta between factory and reality will mislead exactly when accuracy matters most.

The DataMap describes the product; your dictionary must describe your installation.
User-defined fields and custom tables are invisible to generic documentation.
Repurposed columns are the most dangerous gap: the documented meaning is actively wrong.
Multi-site databases add site_ref scoping rules that reports must respect.

The Living Dictionary: Intersect the DataMap with the Live Schema

The robust pattern is to build the dictionary programmatically: read the live SQL Server catalog (INFORMATION_SCHEMA and sys views) for structural truth, then layer DataMap semantics over the structures that match. The result covers everything that exists, with meaning attached wherever meaning is known. Critically, regenerate it on a schedule so it tracks schema changes automatically. This is exactly how SyteRay, Netray's AI layer for SyteLine, builds its schema pack: the CSI 10 DataMap intersected with the customer's live schema, covering 1,970 tables and 15,784 indexed column names on its reference deployment, refreshed as the database evolves.

What a Current Dictionary Unlocks

With a live dictionary, report authors stop guessing at joins, integration developers stop discovering surprise columns in production, and upgrade planning starts from an inventory instead of an excavation. It also becomes the foundation for AI over your ERP: systems like SyteRay validate every generated SQL query against the compiled schema, which is how they avoid inventing tables and columns, the classic failure of generic AI on ERP data.

Frequently Asked Questions

Where do I find the official SyteLine data dictionary?

Infor publishes the DataMap for CloudSuite Industrial, which documents the delivered schema version by version. It is available through Infor support channels and documentation portals. Remember that it describes the factory schema only; your site's user-defined fields, custom tables, and modifications are not in it.

What are the most important SyteLine tables to know?

For most commercial reporting: co and coitem (customer orders and lines), item (item master), po and poitem (purchase orders and lines), job and jobmatl (jobs and materials), and their _mst master-table counterparts. Multi-site environments scope rows with site_ref, which every query must handle correctly.

How does SyteRay keep its schema knowledge current?

SyteRay reads the live SQL Server catalog on a rolling basis and refreshes its compiled schema pack automatically, so additions and customizations show up without manual documentation work. On its reference deployment the pack covers 1,970 tables with 15,784 distinct column names indexed.

Key Takeaways

1Why the Infor DataMap Is Necessary but Not Sufficient: The DataMap documents the delivered schema: the co and coitem order tables, the item master, the po purchasing tables, the job and jobmatl manufacturing structures, and the conventions that bind them, _mst suffixes on master tables and site_ref columns for multi-site scoping. What it cannot document is your site: which user-defined fields carry real meaning, which custom tables your integrations depend on, which delivered columns were quietly repurposed.
2The Living Dictionary: Intersect the DataMap with the Live Schema: The robust pattern is to build the dictionary programmatically: read the live SQL Server catalog (INFORMATION_SCHEMA and sys views) for structural truth, then layer DataMap semantics over the structures that match. The result covers everything that exists, with meaning attached wherever meaning is known.
3What a Current Dictionary Unlocks: With a live dictionary, report authors stop guessing at joins, integration developers stop discovering surprise columns in production, and upgrade planning starts from an inventory instead of an excavation. It also becomes the foundation for AI over your ERP: systems like SyteRay validate every generated SQL query against the compiled schema, which is how they avoid inventing tables and columns, the classic failure of generic AI on ERP data..