1C integration via OData: exports, reports and document automation without configuration changes

What OData in 1C is and why few people know about it

OData is an open REST API protocol that the 1C:Enterprise platform has supported since version 8.3. Once an infobase is published, its objects — catalogs, documents, registers, constants — become available to external systems over plain HTTP: any programming language and any BI system can read them as tables.

The paradox is that this mechanism is barely used. 1C integration is habitually seen as an expensive project “with a 1C developer and custom rework”, although for most reading and standard writing tasks the built-in interface that already ships with your infobase — cloud or on-premise — is enough.

• works in standard configurations without rework
• supported both in cloud 1C and on your own server
• data is served as JSON — any system understands it
• access is governed by regular 1C permissions

Which tasks the standard interface covers

The first layer is exports. Product catalogs, counterparties, documents for a period, register movements — all of it exports to Excel or CSV with filters by date, warehouse and organization. Instead of the manual “build a report, save it, glue it together” you get a file that assembles itself on a schedule.

The second layer is analytics. Register virtual tables expose balances as of a date, turnovers for a period and trial-balance data. Management dashboards and recurring executive reports are built on top of them — without opening 1C.

The third layer is automation. Through the same interface you can create and post documents: website orders, goods receipts, HR documents. A document created via OData passes all the platform’s standard checks — exactly like one entered by hand.

Safety: why the integration doesn’t break your books

Every infobase owner’s main fear is “an external system will ruin something”. A proper architecture removes it by design: the connector is read-only by default, and writing is physically disabled until it is explicitly enabled for a specific infobase.

Access runs under a dedicated account with limited permissions — whatever it is not allowed to do in 1C is impossible via the API too. Documents created via OData are posted by the platform’s standard mechanisms with all their checks. Risky operations like physical deletion are simply not used in a sane setup: marking for deletion is used instead, as is customary in 1C.

• read-only mode by default
• a dedicated account with controlled permissions
• documents posted via standard platform mechanisms
• marking for deletion instead of deleting

Where OData ends and what to do when it isn’t enough

The standard interface has honest limits. Print forms and standard 1C reports do not exist in OData — analytics is built from register data. Server-side logic such as auto-filling tabular sections cannot be invoked from outside. Regulated reporting is readable only at the card level.

When such tasks pile up, the next step is a configuration extension with its own HTTP services. This is also a standard platform mechanism: an extension does not touch the vendor configuration and does not block its updates, but adds exactly the methods you are missing — print forms as PDF, complex reports, server-side calculations.

What a rollout looks like, step by step

The first step is an audit: we check whether your infobase has the OData interface published, and negotiate with the cloud-1C provider if it doesn’t yet. Then a capability map is built — a list of the infobase objects annotated with what can be read and what can be written.

Then come the tasks themselves: we set up exports and reports, connect external systems through an API layer (the website and CRM never get direct access to the infobase), and enable document writing where needed. The first exports usually appear within a few days of getting access to the infobase.