Query your own 1C database without new custom data processors

Any configuration on the 1C:Enterprise 8 platform that can publish the standard OData interface will do — industry-specific, customised in-house or written from scratch. The agent reaches it with ordinary HTTP requests to the published address, authenticating on every call, and uses only what OData offers by itself: filtering, ordering, expanding references and paging through results. No code is added inside the database for this.

The agent does not guess applied object names: it reads the /$metadata schema and lists which catalogues, documents, journals and information, accumulation, accounting and calculation registers are actually served outward. For a non-standard database that is a useful step in itself — you see what the publication really exposes before asking any substantive question about the data.

From there the agent works with your structure directly: it selects documents by period, counterparty or an arbitrary attribute and answers in the chat, with no new data processor needed from a developer; it takes the virtual tables of accumulation registers and returns balances and turnovers as of a date across the dimensions you need; and on a schedule it gathers the metrics of your configuration into a regular digest, even when the database has no standard report for the task.

Visibility is limited twice over: by the publication composition and by the permissions of the role of the user whose login and password are connected. The agent tells those two limits apart — an empty /$metadata or a missing object means it is not included in the publication composition rather than a permissions refusal, and the agent says exactly what needs fixing. Writing over OData is available only with the matching role permissions, so a read-only connection changes nothing in the database.