Connecting a bot to 1C without copying data by hand

A familiar picture: orders arrive through the website or a messenger, and someone retypes them into 1C. Stock levels are exported to Excel to check them against a marketplace. Bank payments are matched to invoices by hand. All of this can be handed to a bot — but it has to be connected to 1C properly, or the integration will break with the very first configuration update.

What usually gets automated

Orders into documents. The bot takes an order from the website or Telegram and creates a sales order or an invoice in 1C.
Stock and prices out. The bot pulls current stock levels and prices from 1C and passes them to the website, a marketplace or a manager in a chat.
Reconciliation. The bot matches payments, invoices and shipments and reports any discrepancies.
Scheduled reports. Revenue, receivables, today’s sales — as a Telegram message, without opening 1C.

Ways to connect

1C:Enterprise has built-in mechanisms for exchanging data with external systems. Which one you choose determines whether the configuration has to be modified.

The standard OData interface

A REST interface the platform provides without any programming in the configuration. The database is published on a web server, and you specify which catalogs, documents and registers are exposed. Through it you can read data, create and modify objects and post documents.

Its main strength is that the standard configuration does not need to change, so its updates do not break the exchange. Its limitation is that you work with objects “as they are”, and any complex logic has to be repeated on the bot’s side.

HTTP services

Custom REST methods inside 1C, written for the task at hand: for example, “create an order and return its number” in a single call, with all the checks done by 1C itself. Flexible and reliable, but it does require modifying the configuration.

So that the modification does not get in the way of updates, it is packaged as an extension — a separate layer attached to the database that leaves the main configuration untouched.

File exchange

The bot and 1C exchange files on a schedule. It is the simplest option when there is no web access to the database, but the data arrives with a delay and exchange errors are harder to track down.

What not to do

Write to the database directly with SQL. It is technically possible, but it bypasses 1C itself: no validation runs, no register records are created, no change history is written. The result is data that looks right while the reports disagree.

Modify the standard configuration without extensions. Every update then turns into moving your changes across by hand, and the exchange breaks at the worst possible moment.

Making the integration reliable

A dedicated user for the bot with rights only to the objects it needs. If something goes wrong, the bot cannot damage the rest of the database.
An exchange log: every operation, its result and the error text if there was one. Without a log, “the order never arrived” turns into an investigation.
Retries and duplicate protection. If the connection drops, the bot retries the operation — without creating a second copy of the same document.
Error alerts to a responsible person, not just an entry in a log file.

What to prepare before work starts

which configuration and edition you run, and whether it is standard or customised;
where the database runs: on your own server, as a file-based database or in the cloud;
whether the database is published on a web server — this decides whether OData and HTTP services are available;
who maintains your 1C: an in-house developer, a partner firm or nobody;
which operations are done by hand today and how much time they take.

With cloud-hosted 1C it all depends on the provider: if they allow access to web services, the connection works the same way; if not, we find a workaround.

What the work includes is on the 1C bots page.