5,612 columns explained
Not the technical names: what the data means in your business, in plain language and written for someone who did not build the system.
593 tables and 5,612 columns documented in plain language: what each one holds, which module writes it and what happens if it changes. It is what keeps your information yours even if you change supplier.
What it solves
Any ERP stores your data. Very few tell you what it means. When an audit arrives, or an integration, or simply a new hire, the question "what exactly is this column?" can only be answered by whoever built the system — and that ties you to them far more tightly than any contract.
What is included
Not the technical names: what the data means in your business, in plain language and written for someone who did not build the system.
Each one with what it holds, which module writes it and what it relates to. The structure of your information stops being a map only one person has.
What is documented is what can be queried. The dictionary is not an appendix: it is what keeps building a report from being guesswork.
Where each figure comes from, field by field. Answering that with a document instead of an explanation shortens an entire audit.
When you need to connect another system, the structure is already written down. You do not have to infer it from sample data.
A new table without its documentation turns the test suite red. It is not a promise to keep it up to date: it is a ratchet.
How it works
It is inside the platform, with nothing to request and nothing extra to pay.
By module, by name or by what it describes.
For a report, for an integration or to answer an audit.
In detail
Saying that `monto_neto` is "the net amount" explains nothing. The entry says what it includes, what it leaves out and who calculates it.
It is the hardest question when something does not add up: knowing which module sets that value saves hunting through the whole system.
When two modules write the same field, the result looks right and is wrong. Documenting it is what makes it visible.
What is documented feeds the report builder. Removing or adding a table changes what can be queried, which is why it is not a cosmetic change.
The catalogues Zyntello maintains — countries, currencies, the tax register, ports — are kept apart from your operational data, which is the data that is yours.
A supplier who does not document your data ties you down without saying so. With the dictionary, changing systems is a project; without it, it is starting from scratch.
Who it is for
And you have to explain where each figure comes from.
And you need to know what is inside without guessing.
And your data must stay readable without them.
Common questions
No. It comes with the platform and covers the modules you have subscribed to.
Yes, all of it — written in Spanish inside the platform. And it does not describe the technical column: it describes what that data means in your business.
Yes: it is the structure written down, so connecting something stops requiring reverse engineering from sample data.
Yes — and not out of goodwill: a new table without its documentation turns the test suite red.
What is documented is what the report builder can query. The dictionary is what keeps building a report from being guesswork.
Yes, to take it into an audit or into the conversation with whoever is going to integrate with you.
And also
We will show you Data Dictionary running on a case much like yours, with no obligation.