Интеграция с 1С

Целевой гайд для 1С-разработчика: как выгружать платежи в BCS и принимать выписки обратно в 1С. Формат — 1CClientBankExchange v1.02 / v1.03, кодировка cp1251.

:::info Архитектура интеграции с 1С BCS говорит на том же файловом формате, что и 1С пишет в банк: 1CClientBankExchange (TXT, cp1251). Это значит, что:

• Платежи: 1С генерирует тот же файл, что обычно отдаёт банку → POST в BCS → BCS отправляет в банк.
• Выписки: BCS получает данные из банка → отдаёт TXT в том же формате → 1С импортирует как обычно.

Никаких новых форматов / обработок не требуется. :::

Шаг 0. Что у вас должно быть

• API-токен с purpose=integration, scope_send_payments=true, scope_read_statements=true и явной ACL на нужный РС.
• bank_account_id — UUID РС в BCS. Узнаётся через GET /integration/bank-accounts (см. Расчётные счета).
• 1С 8.3 с настройкой «Обмен с банком» на нужный РС. Файл, который 1С генерирует — это и есть то, что нужно загружать в BCS.

Платежи: 1С → BCS → банк

Шаг 1. Выгрузка из 1С

В 1С: «Банк и касса» → «Платёжные поручения» → выбрать нужные → «Выгрузить в банк». 1С формирует файл (обычно 1c_to_kl.txt) в кодировке cp1251. Не открывайте в редакторе, который пере-сохранит в UTF-8 — кодировка должна остаться cp1251.

:::warning Номер документа в 1С = idempotency key в BCS Поле Номер из СекцияДокумент становится external_id в BCS. Это значит:

• Каждое платёжное поручение в 1С должно иметь уникальный номер в рамках одного API-токена. 1С обычно так и делает.
• Если изменили в 1С сумму или назначение под тем же номером и перевыгрузили — BCS вернёт 409 conflict на submit. Чтобы переотправить после правки — поменяйте номер в 1С. :::

Шаг 2. Загрузка в BCS

POST файл целиком как multipart:

curl --silent --show-error \
     -H "Authorization: Bearer bcs_live_<TOKEN>" \
     -F "bank_account_id=<bank-account-uuid>" \
     -F "file=@payments_to_bank.txt" \
     "https://bsc.example.com/api/v1/integration/payments/imports"

Ответ — JSON с batch_id и массивом items. Каждый item — одно платёжное поручение из файла. Статусы items:

Шаг 3. Submit в банк

После того как оператор проверил список в 1С / в вашем UI:

curl -X POST -H "Authorization: Bearer bcs_live_<TOKEN>" \
     "https://bsc.example.com/api/v1/integration/payments/imports/<batch_id>/submit"

Ответ — JSON с results[]: для каждого item один из статусов accepted / duplicate / skipped / rejected.

:::info Submit идемпотентен. Если оператор кликнул «Отправить» дважды — банк не получит дубли. Items, уже отправленные раньше, вернутся как skipped с reason=<текущий статус>. :::

Шаг 4. Опрос статусов (опционально)

Если 1С хочет показывать статус каждого платежа («отправлен» / «исполнен» / «отвергнут банком») — поллинг через GET /payments/{payment_order_id}. Статусы: created → submitting → submitted → completed; либо failed / rejected.

Выписки: банк → BCS → 1С

Шаг 1. Заказ выписки

Любая ваша система (1С обработка, отдельный скрипт, cron) заказывает выписку через REST:

curl -X POST -H "Authorization: Bearer bcs_live_<TOKEN>" \
     -H "Content-Type: application/json" \
     -d '{
       "bank_account_id": "<bank-account-uuid>",
       "external_id":     "1C-stmt-2026-05-18-001",
       "date_from":       "2026-05-01",
       "date_to":         "2026-05-17"
     }' \
     "https://bsc.example.com/api/v1/integration/statements"

external_id — придумайте свой стабильный формат (например, 1C-stmt-<account>-<period>-<n>); повторный POST с тем же external_id вернёт ту же выписку без повторного обращения в банк. Период — максимум 31 день.

Шаг 2. Дождаться готовности

GET /statements/{id} до status=ready. BCS опрашивает банк сам каждые 30 секунд; имеет смысл poll'ить не чаще 1 раз в 5 секунд. Обычно выписка готова в течение 1-2 минут.

Шаг 3. Скачать в формате 1С

curl --silent --show-error -OJ \
     -H "Authorization: Bearer bcs_live_<TOKEN>" \
     "https://bsc.example.com/api/v1/integration/statements/<statement_id>/export?format=1c&version=1.03"

Файл — TXT в кодировке cp1251, точно в том формате, который ждёт 1С при «Загрузить из банка». Параметр version=1.03 — стандарт для современных конфигураций; version=1.02 — для legacy.

Имя файла приходит в HTTP header Content-Disposition: attachment; filename=…. Сохраните и подсуньте 1С через «Загрузить из банка».

Пример 1С-файла платежей

1CClientBankExchange
ВерсияФормата=1.03
Кодировка=Windows
ДатаСоздания=18.05.2026
ВремяСоздания=10:00:00
ДатаНачала=18.05.2026
ДатаКонца=18.05.2026
РасчСчет=40702810000000001234
Документ=Платежное поручение
СекцияДокумент=Платежное поручение
Номер=100
Дата=18.05.2026
Сумма=1234.56
ПлательщикСчет=40702810000000001234
ПолучательСчет=40702810500000000111
Получатель=ООО Контрагент
ПолучательБИК=044525225
ПолучательИНН=5566778899
ПолучательКПП=556601001
НазначениеПлатежа=Оплата по счёту № 17 от 15.05.2026
КонецДокумента
КонецФайла

Минимально необходимые поля: ВерсияФормата, Кодировка, РасчСчет (в шапке = РС-плательщик), и в каждой СекцияДокумент — Номер, Дата, Сумма, ПлательщикСчет, ПолучательСчет, Получатель, ПолучательБИК, ПолучательИНН, НазначениеПлатежа. ПолучательКПП — обязателен для юрлиц.

Типичные ошибки

Соответствие концепций 1С → BCS

Что НЕ делать

• Не модифицировать Номер после первой загрузки в BCS — это сломает идемпотентность.
• Не отправлять параллельно несколько submit'ов одного batch'а — бессмысленно (второй вернёт skipped на всё, что уже ушло). Один последовательный submit на batch.
• Не использовать один токен для нескольких РС, на которые он не имеет права — будет 403 forbidden_account. Один токен = заранее согласованный набор РС.
• Не подсовывать в BCS файлы не от 1С (другие банк-клиенты с похожим, но не идентичным форматом). Парсер строго следует спеке 1CClientBankExchange v1.02 / v1.03.