Выручает штатный механизм платформы - стандартный интерфейс OData. Ниже показываю, как на нём собрать выгрузку показателей в мессенджер, и какие грабли встречаются на практике. Все примеры из боевой файловой базы 1С:Бухгалтерии 3.0 (базовая, УСН).
Почему OData, а не расширение.
Несколько причин, по которым я выбрал именно этот путь:
1. Это штатная возможность платформы 8.3. База публикуется на веб-сервере, конфигурация не трогается, обновлениям это не мешает.
2. Работает в базовой версии, где расширения недоступны в принципе.
3. Доступ только на чтение. Заводится отдельный пользователь с ролью «Удалённый доступ через OData», без права записи. Для заказчика это снимает главный страх: испортить учёт снаружи нельзя.
4. Клиент пишется на чём угодно. Я читал данные обычными HTTP-запросами из Python, без единой библиотеки 1С.
Публикацию базы и настройку состава OData оставлю за скобками: это делается один раз из конфигуратора. Дальше про сами запросы.
Откуда брать цифры: регистр «Хозрасчетный»
Деньги, дебиторка, кредиторка, обороты - всё это сальдо и обороты по счетам, то есть регистр бухгалтерии. В OData у него есть две виртуальные таблицы:
Balance(Period=...) - сальдо всех счетов на момент.
BalanceAndTurnovers(StartPeriod=...,EndPeriod=...) - остаток на начало, обороты и остаток на конец за период.
Сальдо на дату (GET, basic-auth пользователя OData):
GET /Buh/odata/standard.odata/AccountingRegister_Хозрасчетный/Balance(Period=datetime'2026-06-23T23:59:59')?$format=application/json;odata=nometadata
Обороты за период, всё одним запросом - начало, дебет, кредит, конец:
GET /Buh/odata/standard.odata/AccountingRegister_Хозрасчетный/BalanceAndTurnovers(StartPeriod=datetime'2026-06-01T00:00:00',EndPeriod=datetime'2026-06-30T23:59:59')?$format=application/json;odata=nometadata
По каждой строке приходит Account_Key (ссылка на счёт), субконто ExtDimension1/ExtDimension2 с типами и суммы: СуммаBalance, СуммаOpeningBalance, СуммаTurnoverDr, СуммаTurnoverCr, СуммаClosingBalance.
Код счёта тянем отдельным запросом плана счетов и сопоставляем по ссылке:
GET /Buh/odata/standard.odata/ChartOfAccounts_Хозрасчетный?$select=Ref_Key,Code&$format=application/json;odata=nometadata
Дальше фильтруем уже на клиенте по коду счёта (51, 50, 62, 60 и так далее).
Грабли и решения
Ради этого блока всё и затевалось. Вот что ломается в реальной работе.
1. Не делайте по запросу на каждый счёт. Первое желание - для каждого счёта слать Balance(...) с условием AccountCondition. На файловой однопользовательской базе это медленно до боли: платформа сериализует обращения, и десяток мелких запросов встаёт в очередь. Берите один запрос без AccountCondition на все счета, а фильтруйте на клиенте. На реальной базе сведение дашборда так ускорилось примерно с 14 секунд до 4.
2. BalanceAndTurnovers даёт начало, оборот и конец одним запросом. Три отдельных обращения не нужны. Все четыре суммы лежат в одной строке. Один такой запрос закрывает сразу банк, кассу, дебиторку, кредиторку и остатки.
3. $select на виртуальных таблицах игнорируется. На Balance и BalanceAndTurnovers платформа возвращает все примерно 88 полей, что бы вы ни написали в $select. На урезание трафика тут не рассчитывайте. На обычных справочниках и документах $select, к слову, работает нормально.
4. Знак сальдо везде одинаков. СуммаBalance больше нуля - это дебет (актив, дебиторка), меньше нуля - кредит (пассив, кредиторка). Правило работает для любого счёта. Дебиторка - это дебет 62, кредиторка - кредит 60 (берём по модулю). Сверял с 1С по счетам 62, 76, 60.
5. «Контрагент» в документах - поле разное в зависимости от вида документа. Самая коварная штука:
В банковских и кассовых документах (Поступление и Списание с расчётного счёта, ПКО, РКО) поле Контрагент составного типа: там бывает и контрагент, и физлицо. $expand=Контрагент здесь не работает, разбирать нужно по Контрагент_Type. Если резолвить всё как контрагента, на физлице получите сырой GUID.
В «Реализации товаров и услуг» поле зовётся Контрагент_Key - это простая ссылка на справочник контрагентов. Составного Контрагент_Type тут нет, и если указать его в $select, прилетит HTTP 400.
Итог: для разных документов - разный код разбора контрагента, единой выборки нет.
6. Часовой пояс. Строите границы периода через new Date(...).toISOString() - получаете UTC, и в поясе +N «Сегодня» утром становится «вчера», а «Текущий месяц» начинается на день раньше. Собирайте дату из локальных компонентов, а не из ISO-строки.
7. Прибыль пуста, пока не сделано «Закрытие месяца». Финрезультат (счета 90.09, 91.09, 99) не заполнен до регламентной операции. Выручка (кредит 90.01) доступна всегда, а прибыль появится только после закрытия. И ещё момент: период, который перешагивает 31 декабря, искажается реформацией баланса, так что считайте в пределах одного года или явно это оговаривайте.
8. Параллельные запросы кэшируйте промисом. Когда данные тянет браузерный клиент и панелей много, оборачивайте fetch в кэш промиса по ключу периода: параллельные панели разделят один запрос, а не устроят шторм к 1С. И защититесь от гонки наложенных загрузок простым счётчиком поколений: запомнили номер на старте загрузки, под-загрузчик пишет в DOM только если номер ещё актуален. Иначе при быстром переключении периода старый запрос допишет данные поверх нового.
Что получилось
Сложив всё вместе, получаем читалку: один-два запроса отдают сводку по деньгам, долгам и оборотам, дальше она форматируется в сообщение мессенджера. Так устроен инструмент ИнфоБот, на котором я собирал примеры выше: он читает опубликованную базу по OData (только на чтение) и отправляет руководителю готовые цифры в Telegram и MAX. При этом сами приёмы универсальны и повторяются на любом клиенте, который ходит в 1С по OData.
Итог
Стандартный OData закрывает типовую задачу «показать цифры из 1С снаружи» без единой правки конфигурации. Подводные камни в основном про производительность файловой базы (один запрос вместо многих), про разнотипные поля документов и про регламентные операции учёта. Если знать их заранее, рабочую выгрузку реально собрать за вечер.
Вступайте в нашу телеграмм-группу Инфостарт