Plank help · updated 2026-09-17
Connecting 1C
Connect your 1C database so your assistant can look up products and stock, create customer invoices, and build reconciliation acts — exported as Excel and as PDFs that match your standard 1C printed forms.
Agents: fetch the raw markdown of this page at /en/help/connecting-1c.md
Connecting 1C
Your assistant can work directly with your 1C database — the same accounting and trade data you use every day. Once it's connected, you can ask in plain language ("create an invoice for this customer", "make a reconciliation act for Q1") and get back finished documents, without touching 1C yourself.
This works with cloud-hosted 1C (a provider runs your database online) and with on-premise 1C that's reachable over the network. The connection uses 1C's built-in OData interface — a standard, read-and-write doorway into your data that 1C ships with. You don't need to install anything; it's a setting your 1C administrator turns on.
The other 1C pages. This one is about getting connected. Once you are:
- Working with 1C over OData — the mechanics of reading and writing: what the integration user is allowed to do, how to tell a document already exists, how to create one safely, and the server limits worth designing around. Read it before writing any 1C script.
- Importing a bank statement into 1C — the full Kazakhstan workflow: arithmetic controls, classifying operations, taxes and penalties by КНП/КБК, and the five fund payments that need employee lists.
- The 1C starter kit — the working scripts that implement both pages. Check for these before writing any 1C code.
What your assistant can do once 1C is connected
- Look up products and nomenclature — prices, articles, names, units. It can find a customer by name, code, or BIN/IIN, so you never have to hunt for internal IDs.
- Check stock balances for your warehouses.
- Create customer invoices ("Счёт на оплату покупателю"). You describe the order in words — customer, products, quantities, price — and the assistant matches each one to the right record in 1C and assembles the invoice. It's created as an unposted draft so you can review it in 1C before posting.
- Export an invoice as a PDF and an Excel file — including a PDF laid out to match your standard 1C printed form, with your seal and signature.
- Build a reconciliation act ("Акт сверки взаиморасчётов") for a counterparty over any date range. The assistant gathers the sales, payment, and return documents from 1C, computes the running balance, and produces both Excel and a 1C-style PDF.
Finished invoices and acts are saved as files in your workspace, so you can download, send, or print them.
What you need before connecting
Connecting takes two one-time steps in 1C — usually done by whoever administers your database (your 1C partner, your hosting provider, or your IT person). Once they're done, you won't need to repeat them.
-
Turn on the OData interface. In 1C this is called publishing the standard OData interface (
standard.odata). On cloud/hosted 1C, ask your provider to enable OData publication for your database. On a self-hosted setup, your administrator publishes it on the web server. The result is a web address that looks like:https://your-1c-host/your-database/odata/standard.odata -
Create a login for the assistant — and ask for a full role. Add a dedicated 1C user with a password. Ask for the full set of rights: read, create, edit, delete / mark for deletion, and posting (проведение). Using a separate login still keeps the access clean and easy to review or revoke — but rights that were never granted are the single most common reason a working setup turns out to be half-usable a week later.
This is worth insisting on. A "read and create only" user looks fine at first: the assistant can pull data and draft documents. The problem appears the first time a draft is wrong. Without edit rights it can't be corrected, without delete rights it can't be removed, and without posting rights nothing can be finished without a person opening 1C — so every mistake becomes manual cleanup for you. Ask for the full role up front; narrowing it later is easy, widening it means going back to your provider and waiting again.
Granting posting rights does not mean the assistant posts documents on its own — it doesn't, by design (see How it keeps you safe below). It means that when you do say "post it", it can.
Tip: if you're not sure whether OData is available, open your 1C web client address, add
/odata/standard.odatato it, and try to open it. A login prompt or an "unauthorized" message means the interface exists and just needs your credentials — that's the good case.
If the OData address doesn't work
The most common snag isn't a wrong address — it's that OData was only half enabled. There are two independent switches, and hosting providers routinely flip only the first:
- Inside 1C — Администрирование → «Состав стандартного интерфейса OData», which chooses which objects are exposed. This is usually what a provider means when they say "OData is on".
- On the web publication — the database's
default.vrdneedspublishStandardOData="true"(the «Публиковать стандартный интерфейс OData» checkbox in Публикация на веб-сервере). Without this second switch, the OData address leads nowhere no matter how correctly it's spelled.
Watch out for a "friendly" error page. A cloud 1C host may answer an unpublished OData address with HTTP 200 and its own HTML page ("Ваша база отключена", "База не найдена") instead of a clean 404. Don't read the wording literally — that's the hosting provider's front-end talking, not 1C, and it appears for any address the provider doesn't recognise.
The decisive test. Compare the OData address against 1C's HTTP-services route on the same database:
<base>/hs/ → 401, header: WWW-Authenticate: Basic realm="1C:Enterprise 8.3"
<base>/odata/standard.odata/ → should challenge for a password too, or return XML
If /hs/ asks for a password but /odata/standard.odata returns an HTML page with no password prompt, then requests are reaching 1C and OData simply isn't published on that publication. These are separate flags on the same publication, so no alternative address will help — only your provider can change it.
What to ask your provider (send this as-is):
Для базы <название> включите публикацию стандартного интерфейса OData на веб-сервере (
publishStandardOData="true"вdefault.vrd) — не только состав OData в настройках конфигурации. Сейчас/hs/отвечает401 WWW-Authenticate: Basic realm="1C:Enterprise 8.3", а/odata/standard.odataотдаёт HTML-страницу с кодом 200 и без запроса авторизации — значит запрос до 1С не доходит. Проверка:$metadataдолжен вернуть XML либо запросить логин и пароль.Также заведите отдельного пользователя для интеграции с полной ролью: чтение, создание, изменение, удаление и пометка на удаление, проведение документов. Роли «только чтение и создание» недостаточно: ошибочный черновик, созданный через OData, невозможно ни исправить, ни удалить, ни довести до конца без ручной работы в 1С.
The one case where the address really is different: on 1С:Фреш (1cfresh) the shape is https://<host>/a/<app>/<zone>/odata/standard.odata, not <host>/<base>/odata/standard.odata. Fresh databases have no publication name of their own — if yours does, and it has a working /hs/ route, you're on a classic publication and the standard form is correct.
When your hosting provider has its own login in front of 1C
Some providers ask for their own login and password before you ever reach 1C — you see two sign-in screens in the web client. The connection check (check-access.py) tells you which of the two refused:
- "The hosting provider's own login refused these credentials" — the address wants the provider's login, not a 1C user. Get it from your provider.
- "Two logins stand in front of this base and they share ONE Authorization header" — the provider's login worked, but 1C has no user with that same login and password. A connection can send only one login, so pick one of these (whoever administers your base does it; neither makes anybody's login weaker):
- create a dedicated 1C user for the assistant with exactly the same login and password as the provider's login, with only the rights the assistant needs; or
- ask the provider to exempt
/odata/standard.odatafrom their own login (restricted by IP), so the 1C user's credentials reach 1C directly.
Two-factor or single sign-on logins. 1C's OData interface itself takes an ordinary login and password — a code from SMS or an app can only come from a layer in front of it. Your assistant never asks for, reads or reuses such a code, and turning the second factor off on your own account is not the fix. Ask your provider for a non-interactive integration login instead: a dedicated account exempted from the second factor by their policy, limited to what the assistant needs. If a person really has to sign in each time, use browser access: you sign in, the assistant works inside that session and never sees your password.
Connecting
Once OData is on and you have the login, you connect simply by telling your assistant in chat. Give it three things:
- the OData address (the
.../odata/standard.odatalink above), - the username, and
- the password.
The assistant stores these securely in your workspace and uses them only to reach your 1C. It never writes the password into notes, logs, or the chat history.
Then it runs a quick access check: it reads your database's catalog of available data and reports back how many data sets it can see (a healthy connection typically shows hundreds). If anything's off — wrong address, wrong password, or OData not yet published — it tells you in plain language so you know exactly what to fix.
After that, the 1C tools show up in your workspace's Integrations sidebar, grouped under 1C, and you can start asking for products, invoices, and acts. (See Integrations and Workspace scripts & the sidebar for how connected tools appear.)
How it keeps you safe
- Read-only unless you ask otherwise. Looking up products, stock, and documents never changes anything in 1C.
- Writing only happens on your say-so. When you ask for an invoice, the assistant prepares it and creates it as an unposted draft. It never posts on its own initiative — it posts only when you explicitly ask it to, and otherwise you review and post in 1C yourself.
- You control the login. Because the assistant uses a dedicated 1C user, you decide its rights and can change the password or remove it at any time to cut off access instantly.
Good to know
- It speaks your data's language. 1C databases are usually in Russian, and the assistant works with the Russian field and document names directly — you don't need to translate anything.
- Native-looking documents. The PDF invoices and acts are built to resemble your standard 1C printed forms, including seal and signature images, so they're ready to send to a customer.
- No internal IDs for you. You refer to customers, products, warehouses, and contracts by their normal names, codes, or BIN/IIN — the assistant resolves them to the right 1C records.
- Configurations. This works with 1C configurations that publish the standard documents over OData (customer invoices, sales, payments, returns). If a particular form isn't published in your database, the assistant will tell you and can suggest what to ask your 1C administrator to enable.
See also: Automations to have the assistant form documents on a schedule or in response to an incoming order, and Deliverables for how finished files are produced and shared.