What does this solve?
Data about money, balances and counterparties are in the accounting system, and access to them is through people: you need a slice - you need an accountant who will upload it, or a programmer who will complete the report. AI-agent for 1C stands between the question and the base: “how much does the counterparty owe and on what invoices”, “which invoices were issued more than a month ago and have not been paid”, “do the receipts to the current account match the payments made”. The response is collected by a request, and not by an application to the improvements queue. The second routine to be removed is input: a standard document is prepared from a letter or a line in a chat, and not by hand in one field. Responsibility for carrying out remains with the person: the agent prepares a draft, the employee claims.
How it works
The bundle breaks down into three layers, and the confusion between them is the source of most failed implementations.
Data access layer
1С does not provide data to the model directly. One of the standard mechanisms sticks out.
| Mechanism | What it can do | Where it presses |
|---|---|---|
| Standard OData Interface | reading and writing objects: directories, documents, information registers | does not return virtual register tables (remainders, revolutions), heavy samples are slow |
| HTTP service in extension | any query in the built-in language, including balances and turnover, plus its own business logic | need to write and maintain code |
| Web service (SOAP) | the same as an HTTP service, with a formal description of the contract | verbose format, unnecessary XML parsing |
| External connection (COM) | full access to application objects | Windows only, sessions and state do not survive service work well |
| Replication to analytical database | arbitrary fast SQL slices without load on the working database | delayed data, recording not possible |
Direct queries to 1C working database tables are not included in this list. The table names are official, the register totals are recalculated by the platform, the locks are their own - external intervention breaks the data quietly and for a long time. If you really want SQL, they upload it to a separate database and work with it.
Tool layer
The model does not follow the URL at random. It is given a set of named operations with descriptions and parameters: долг_контрагента(инн, на_дату), неоплаченные_счета(период), создать_счёт(контрагент, позиции, комментарий). Technically, these are tool-calling functions or an MCP server, inside there are the same requests to OData and HTTP service calls. Each operation covers one business issue entirely and returns ready-made numbers, rather than a raw table for analysis of the model.
Rules layer
Reading is open, writing is according to the list. Each write operation takes an idempotency key and creates the document undone. Calling again with the same key returns the already created document instead of the second one.
Working order: question → the model selects an operation → the layer executes the request under the service user → the result is returned to the context → the model responds or takes the next step. Everything the agent did remains in the log under that user's name.
How to connect
1. Publish the database on a web server. Configurator → Administration → Publishing on a web server. Check “Publish standard OData interface” and, if you plan your own methods, publish HTTP services. Appears in the publication catalog default.vrd —you can also see the name of the database, which will be included in the URL.
2. Open the required objects in OData. The standard interface gives only what is explicitly included in the composition: Configurator → Administration → Configuring the composition of the standard OData interface. An empty composition is an empty answer, and this is the first reason “nothing works.” Mark pointwise, do not “select everything”: the composition determines the access area.
3. Create a service user. Individual user with 1C:Enterprise authentication, separate role, rights only to objects from point 2. Administrator rights are not needed here. Record-level restrictions are configured by the same role.
4. Check access from outside.
curl -u 'ai_agent:PASSWORD' 'http://1c.local/base/odata/standard.odata/$metadata?$format=json'The description of entities in the response means that publication and rights are ok. Empty list - return to step 2. Response 401 - return to step 3.
5. Take the first sample.
curl -u 'ai_agent:PASSWORD' 'http://1c.local/base/odata/standard.odata/Document_СчетНаОплатуПокупателю?$format=json&$top=5&$select=Number,Date,СуммаДокумента,Проведен'$select is required for combat volumes: without it, the platform gives all the details along with the tabular parts. $top , too, otherwise the first request for documents will pull out the whole story. Selection by period is written as $filter=Date gt datetime'2026-01-01T00:00:00', spaces in URL are encoded.
6. Add an extension for something that OData cannot do. Remains, turnover, calculations using accumulation registers - HTTP service in configuration extension: one method equals one operation, inside is a query to a virtual table, outside is JSON. Expansion instead of editing the configuration, so that the standard one remains supported and is updated regularly.
7. Wrap operations in tools. Each function receives a description for the model: what it returns, what parameters are required, what to do in case of an error. The error text is also written for the model - “counterparty by TIN was not found, please specify the name” works, “Error 500” does not work.
8. Separate reading and writing. Reading operations are performed freely. Writers - only through human confirmation, with an idempotency key, without auto-confirmation.
Useful scripts
- Accounts receivable for a specific counterparty with a breakdown of accounts, dates and partial payments.
- Reconciliation of bank statements with payments made and a list of discrepancies for analysis.
- Draft of an invoice or order based on a client’s letter with the substitution of details from the directory.
- Searching for duplicate counterparties and items by fuzzy coincidence is something that is difficult to catch with regular search.
- Morning summary in messenger: account balances, overdue payments, documents stuck without being processed.
- Layout of supplier price lists by item groups when loading.
- Deciphering the number in the report: the agent finds the documents from which it was formed and explains the composition.
Limitations
Sessions and licenses. Each OData or HTTP service connection raises a session, and sessions are subject to the installation-specific licensing scheme. The agent pulling the base in a loop competes with people for them, so connection pooling and frequency limiting are mandatory.
Speed. OData on documents with tabular parts is slow, and the model tends to query everything and filter then. It is treated by the fact that the filtration is hardwired into the operation and the model is not available.
Register analytics. You cannot get balances and revolutions through the standard interface. An attempt to calculate the balance by adding documents gives incorrect numbers on any non-trivial accounting scheme - reserves, batches, characteristics, warehouses.
Record. Posting affects movements across registers, mutual settlements and the closed period. Carrying out a model solution is a direct path to debriefing in a closed quarter.
Personal data. Directories of counterparties and individuals contain PD, and they go into the context of the model along with the answer. Either the provider and processing mode are consistent with company policy, or the fields are masked at the transaction level.
Typical on support. All logic lives in the extension. Editing the configuration for the sake of the agent increases the cost of each subsequent update.
How to check the result
Start with metadata: $metadata answers, the composition is not empty, it contains exactly the objects that were opened. Extra objects in the composition are also a defect, they are removed.
Take three questions with a known answer in advance and check them with 1C hands: the balance of one warehouse as of the date, the debt of one counterparty, the amount of one document. A discrepancy of a penny is usually about rounding and currency, a discrepancy by several times is about the fact that the agent folded the documents instead of requesting the register.
Run a write operation twice with the same idempotency key. The second call is required to return the same document, rather than create a new one. At the same time, check that the document was created unposted.
Open the log and filter by service user: every access, time and object is visible. A dense, monotonous flow means that the operation pulls the database in a loop and it must be rewritten in one request.
Check failure: ask for data on an object that is not included in OData. The correct behavior is a clear message of unavailability, not a plausible made-up answer.
One line rule: you can read from 1C with anything, write - only with a named operation in the extension, with an idempotency key and without auto-passing.