Почему не сходятся остатки по счету в ОСВ и в запросе 1С? Разбор причин и детальное руководство по решению

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

Разработчики и аналитики 1С часто сталкиваются с ситуацией, когда данные в стандартном отчете Оборотно-сальдовая ведомость по счету (ОСВ) не совпадают с результатами самостоятельно написанного запроса к виртуальным таблицам регистра бухгалтерии. Особенно часто это происходит при анализе взаиморасчетов (например, по счету 60.01 или 62.01).

В этой статье мы подробно разберем, почему возникают такие расхождения, как устроена работа с итогами на уровне СУБД, и как правильно составить запрос, чтобы его результаты гарантированно сошлись с типовой ОСВ «копейка в копейку».

Причина 1. Несовпадение временных границ периода (00:00:00 против 23:59:59)

Это самая распространенная ошибка. Когда пользователь формирует ОСВ за определенный день (например, 01.01.2018), система автоматически берет весь день целиком — с первой секунды начала дня до последней секунды конца дня. На уровне платформы конечная дата преобразуется в 01.01.2018 23:59:59.

Если в запросе передать параметр даты без указания времени, например, просто &ДатаРасчета со значением 01.01.2018, то СУБД воспримет этот параметр как начало дня — 01.01.2018 00:00:00. Любые документы и проводки, записанные в течение этого дня (даже в 00:00:01), не попадут в результаты вашего запроса, но будут учтены в ОСВ.

Более того, стандартные отчеты используют специальный объект платформы Граница с видом ВидГраницы.Включая. Если документ записан ровно на границу секунды, обычное сравнение по дате может его упустить. Для решения этой проблемы в коде наложения параметров запроса необходимо использовать следующий подход:


ГраницаКонцаПериода = Новый Граница(КонецДня(ПараметрДата), ВидГраницы.Включая);
Запрос.УстановитьПараметр("КонецПериода", ГраницаКонцаПериода);

Если запрос выполняется в консоли запросов и нет возможности передать объект Граница, обязательно используйте функцию КОНЕЦПЕРИОДА внутри самого текста запроса:


ВЫБРАТЬ
    ХозрасчетныйОстатки.СуммаОстатокКт КАК Остаток
ИЗ
    РегистрБухгалтерии.Хозрасчетный.Остатки(КОНЕЦПЕРИОДА(&ДатаРасчета, ДЕНЬ), Счет = &Счет, , ) КАК ХозрасчетныйОстатки

Причина 2. Особенности расчета развернутого сальдо по субконто

В исходном запросе автора темы использовались поля СуммаКонечныйРазвернутыйОстатокКт и СуммаКонечныйРазвернутыйОстатокДт. Использование развернутого остатка без указания конкретных субконто в параметрах виртуальной таблицы — частая причина нестыковки цифр.

Рассмотрим, как платформа рассчитывает эти показатели:

  1. Если параметры семейства Субконто в виртуальной таблице ОстаткиИОбороты оставлены пустыми, расчет развернутого сальдо производится по всем субконто, которые назначены для данного счета в плане счетов. Для счета 60.01 это обычно «Контрагенты», «Договоры» и «Документы расчетов».
  2. Платформа сначала рассчитывает остатки в разрезе каждой аналитики на самом детальном уровне, а затем выполняет суммирование.
  3. Если в учете есть скрытые ошибки (например, пересортица по договорам, когда по одному договору контрагента висит дебет, а по другому — кредит), обычный свернутый остаток по счету взаиморасчетов покажет корректную разницу. Однако развернутый остаток просуммирует эти величины отдельно, что приведет к завышению конечных сумм в запросе по сравнению со свернутыми показателями в ОСВ.

Решение: Если вам нужен классический остаток по счету (свернутый), используйте стандартные поля СуммаКонечныйОстатокКт (или Дт) вместо развернутых полей. Если же требуется именно развернутый остаток, обязательно передавайте массив видов субконто в параметры виртуальной таблицы:


// МассивСубконто должен содержать только те разрезы, по которым строится отчет
РегистрБухгалтерии.Хозрасчетный.ОстаткиИОбороты(&НачалоПериода, &КонецПериода, , , Счет = &Счет, &МассивСубконто, )

Причина 3. «Битые» итоги в базе данных (Рассинхронизация таблиц)

Иногда код написан абсолютно верно, параметры времени переданы корректно, но данные все равно расходятся. В этом случае мы имеем дело с техническим сбоем механизма итогов 1С.

Физически в СУБД данные регистров бухгалтерии хранятся в двух основных типах таблиц:

Виртуальные таблицы запросов Остатки и ОстаткиИОбороты обращаются именно к таблицам итогов. В то же время Оборотно-сальдовая ведомость при определенных настройках периода или детализации может рассчитывать данные динамически, обращаясь напрямую к таблице движений.

Если в базе произошел технический сбой (например, аварийное завершение работы сервера СУБД или некорректная транзакция при обмене данными), итоги могут стать неактуальными («битыми»). Выяснить, в этом ли дело, можно с помощью полного пересчета итогов.

Для исправления ситуации выполните следующие действия:

  1. Запустите базу в режиме Конфигуратор.
  2. Откройте меню Администрирование — Тестирование и исправление...
  3. Установите флаг напротив пункта Пересчет итогов и запустите процесс.

Обратите внимание: На больших базах данных эта процедура может занять длительное время и требует монопольного режима работы. В качестве альтернативы в пользовательском режиме «1С:Предприятие» можно использовать стандартную обработку Управление итогами (раздел «Поддержка и обслуживание» или «Администрирование»), где можно пересчитать итоги по конкретному регистру без отключения пользователей.

Причина 4. Пустые ссылки в измерениях проводки вместо NULL

Данная проблема особенно актуальна для конфигураций версии КОРП (где используется сквозной учет по подразделениям) и для счетов с валютным учетом.

При ручном создании проводок или переносе данных через правила обмена в измерения регистра («Подразделение» или «Валюта») может записаться не значение NULL (которое должно быть там, если учет по измерению на данном счете не ведется), а пустая ссылка соответствующего справочника (например, Справочник.ПодразделенияОрганизаций.ПустаяСсылка).

На уровне визуальных отчетов эти записи могут выглядеть одинаково пустой строкой, однако СУБД при построении виртуальной таблицы остатков выполняет внутреннее соединение таблиц. Наличие пустой ссылки вместо физического значения NULL ломает логику оптимизатора запросов СУБД, и такие записи просто отсекаются из итогов виртуальной таблицы.

Решение: Запустить «Тестирование и исправление» с включенными проверками логической и ссылочной целостности, выбрав вариант «Очищать ссылки» или «Создавать объекты» при обнаружении некорректных данных.

Причина 5. Отсутствие отборов по измерениям (Организация)

Если в базе ведется многофирменный учет (по нескольким организациям), стандартная ОСВ всегда формируется с отбором по конкретной организации, выбранной в шапке отчета. Если в вашем запросе этот отбор не установлен, вы получите суммированные остатки по всем юридическим лицам базы сразу.

Проанализируем правильный шаблон запроса, который гарантирует корректное сопоставление с ОСВ по счету 60.01:


ВЫБРАТЬ
    ХозрасчетныйОстаткиИОбороты.Счет КАК Счет,
    ХозрасчетныйОстаткиИОбороты.СуммаНачальныйОстатокКт КАК НачальныйОстатокКт,
    ХозрасчетныйОстаткиИОбороты.СуммаКонечныйОстатокКт КАК КонечныйОстатокКт,
    ХозрасчетныйОстаткиИОбороты.СуммаОборотДт КАК ОборотДт,
    ХозрасчетныйОстаткиИОбороты.СуммаОборотКт КАК ОборотКт
ИЗ
    РегистрБухгалтерии.Хозрасчетный.ОстаткиИОбороты(
        НАЧАЛОПЕРИОДА(&ДатаРасчета, ДЕНЬ),
        КОНЕЦПЕРИОДА(&ДатаРасчета, ДЕНЬ),
        Период,
        ,
        Счет = &Счет,
        ,
        Организация = &Организация
    ) КАК ХозрасчетныйОстаткиИОбороты

Используя этот шаблон, мы жестко ограничиваем рамки расчета рамками одного дня (с 00:00:00 по 23:59:59), накладываем фильтр на конкретную организацию и используем свернутые показатели остатков (без слова «Развернутый»), что полностью исключает любые математические расхождения с показателями стандартного отчета.

← На главную