Как получить остатки и субконто регистра бухгалтерии прямым SQL-запросом к базе данных 1С

Программист 1С v8.3 (Управляемые формы) Бухгалтерский учет IT и автоматизация бизнеса
← На главную

При интеграции систем или выгрузке данных во внешние аналитические хранилища разработчики иногда обращаются к базе данных 1С напрямую через SQL. Однако попытка найти привычные поля субконто в основной физической таблице проводок часто заканчивается неудачей. Разберем, как устроена физическая структура хранения регистра бухгалтерии в СУБД, где искать аналитику счетов и как правильно собирать остатки.

Физическая структура таблиц регистра бухгалтерии

В платформе 1С:Предприятие регистр бухгалтерии на уровне СУБД представлен не одной таблицей, а целым комплексом связанных таблиц. Проанализируем основные из них:

  1. Таблица основных движений (префикс _AccRg<n>): содержит даты проводок, ссылки на документы-регистраторы, номера строк, ссылки на счета дебета и кредита (_AccountDtRRef, _AccountCtRRef), суммы и количество. Полей конкретных субконто в ней нет.
  2. Таблица значений субконто (префикс _AccRgED<n>): хранит ссылки на аналитику (номенклатуру, контрагентов, договоры, склады) для каждой строки проводки.
  3. Таблицы итогов (префиксы _AccRgAT0<n>, _AccRgAT1<n>, _AccRgAT2<n>, _AccRgAT3<n>): агрегируют рассчитанные остатки и обороты по счетам с соответствующим количеством субконто (без субконто, с 1, 2 или 3 субконто).
  4. Таблица настроек и дат актуальности (_AccRgOpt): содержит информацию о точке актуальности и периодичности расчета итогов.

Связывание движений и субконто: таблицы AccRg и AccRgED

Если задача заключается в анализе детальных проводок регистратора, свяжем основную таблицу движений _AccRg с таблицей значений субконто _AccRgED. Связь между ними осуществляется по составному ключу: ссылке на регистратор (_RecorderRRef) и номеру строки (_LineNo).

Рассмотрим структуру полей таблицы _AccRgED. Так как субконто в 1С может иметь составной тип данных, для каждого значения аналитики формируется группа полей:

  1. _Fld<n>RRef — бинарный идентификатор (GUID) ссылки на справочник или документ.
  2. _Fld<n>_TYPE — тип значения.
  3. _Fld<n>_RTRef — идентификатор типа метаданных.
  4. _KindRRef — ссылка на вид субконто из плана видов характеристик (например, «Номенклатура» или «Склады»).

Посмотрим на пример структуры объединения таблиц движений и субконто на уровне SQL:


SELECT 
    reg._Period AS Period,
    reg._RecorderTRef AS RecorderTRef,
    reg._RecorderRRef AS RecorderRRef,
    reg._LineNo AS LineNo,
    reg._AccountDtRRef AS AccountDt,
    reg._AccountCtRRef AS AccountCt,
    reg._Amount AS Amount,
    sub._KindRRef AS SubcontoKind,
    sub._Value_RRRef AS SubcontoValue
FROM 
    _AccRg468 reg WITH (NOLOCK)
INNER JOIN 
    _AccRgED666 sub WITH (NOLOCK)
    ON reg._RecorderTRef = sub._RecorderTRef
    AND reg._RecorderRRef = sub._RecorderRRef
    AND reg._LineNo = sub._LineNo
    AND reg._Active = 0x01
WHERE 
    reg._AccountDtRRef = 0x... -- GUID счета 41.01 в binary(16)

Обратим внимание на обязательную проверку флага активности проводки: поле _Active = 0x01 гарантирует, что в выборку не попадут отключенные или сторнированные записи.

Особенности работы с остатками и таблицами итогов AccRgAT

Попытка посчитать остатки на счете простым суммированием всех строк из таблицы _AccRg приводит к сильной просадке производительности на больших базах. Сама платформа 1С использует механизм предрассчитанных итогов.

Разберем, как устроена работа с остатками:

  1. Периодичность итогов: итоги рассчитываются и хранятся помесячно в таблицах _AccRgAT*. Актуальные текущие остатки хранятся с фиктивной датой в будущем (например, со смещением 3999-11-01).
  2. Использование таблицы нужного уровня: для счета 41.01 с тремя субконто (Номенклатура, Склады, Партии) платформа обращается к таблице _AccRgAT3. Если по счету ведется только одно субконто, данные хранятся в _AccRgAT1.
  3. Расчет на произвольную дату: чтобы получить остаток на середину месяца, платформа берет срез из таблицы итогов на начало периода и суммирует движения из таблицы _AccRg только за интервал между датой итогов и целевым моментом времени.

Важные технические нюансы прямого доступа к СУБД

При написании прямых запросов к базе 1С необходимо учитывать системные особенности платформы:

  1. Порядок байтов в UUID (binary(16)): в базе данных 1С GUID ссылочных типов хранятся в бинарном формате с перестановкой байтов (little-endian для определенных блоков). Передавать строковый GUID из 1С напрямую в условие SQL без конвертации нельзя, иначе запрос вернет пустой результат.
  2. Смещение дат: во многих базах 1С включено смещение дат на 2000 лет (параметр _YearOffset = 2000). В этом случае дата 2026-01-01 хранится в базе как 4026-01-01.
  3. Блокировки таблиц: прямое чтение без хинта WITH (NOLOCK) на MS SQL Server может приводить к эскалации блокировок и конфликтам с пользователями, проводящими документы в 1С.

Как гарантированно узнать имена физических таблиц

Не рекомендуется угадывать имена таблиц вручную через SQL Server Profiler, так как после реструктуризации базы или обновлений конфигурации суффиксы номеров таблиц могут измениться. Для получения точной структуры используем штатную функцию 1С:


Структура = ПолучитьСтруктуруХраненияБазыДанных(
    "РегистрБухгалтерии.Хозрасчетный", 
    Истина
);

Для Каждого Таблица Из Структура Цикл
    Сообщить("Назначение: " + Таблица.Назначение + " -> Таблица в SQL: " + Таблица.ИмяТаблицыХранения);
КонецЦикла;

Данная функция возвращает массив описаний, в котором четко разделены имена основной таблицы движений, таблицы значений субконто и всех таблиц итогов по субконто.

Рекомендуемые альтернативы прямому SQL

Прямые запросы к СУБД несут в себе риски повреждения транзакционной целостности, обхода прав доступа (RLS) и поломки при обновлениях. В большинстве интеграционных сценариев эффективнее использовать штатные инструменты:

  1. Собственные HTTP-сервисы: разработка компактного сервиса в 1С, который выполняет запрос к виртуальной таблице РегистрБухгалтерии.Хозрасчетный.Остатки(...) на языке запросов 1С и возвращает сериализованный JSON. Этот метод автоматически задействует таблицы итогов и корректно учитывает все типы субконто.
  2. Стандартный интерфейс OData: публикация таблиц остатков через встроенный REST-интерфейс платформы без необходимости изменения конфигурации.
  3. COM-соединение: использование внешнего подключения через V83.COMConnector для выполнения платформенных запросов из внешних приложений.
← На главную