Почему двоятся итоги в оборотно-сальдовой ведомости 1С и как убрать пустую строку по счету-родителю?

В практике работы с программой «1С:Предприятие» многие специалисты сталкиваются с неприятной ситуацией: в оборотно-сальдовой ведомости (ОСВ) по определенному счету начинают некорректно отображаться итоги. Это выражается в визуальном «задвоении» сумм и появлении странной пустой строки (без субсчета) прямо под родительским счетом. Особенно часто это происходит после того, как к ранее существовавшему счету без субсчетов (например, 86 «Целевое финансирование») добавляют подчиненные субсчета (например, 86.01 и 86.02).

В данной статье мы подробно разберем, почему возникает подобный эффект с точки зрения архитектуры платформы «1С:Предприятие 8.3», какие методологические риски несет в себе сохранение проводок на счете-родителе, и как правильно решить эту проблему раз и навсегда без разрушения типовой конфигурации.

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

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

1. Свобода выбора счета в проводках: Любой счет в системе, даже если у него появились подчиненные субсчета (то есть он стал родителем/группой), технически может быть выбран в документах и операциях. Это возможно в том случае, если в свойствах счета не установлен специальный признак-запрет (например, флаг Счет является группой и не выбирается в проводках или Запретить использовать в проводках).
2. Плавный переход: Данная архитектура создавалась для того, чтобы при обновлении или развитии базы данных можно было безболезненно добавить новые субсчета к уже работающему счету, не блокируя работу пользователей и не требуя немедленного перепроведения исторических данных.

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

Как 1С рассчитывает итоги в ОСВ при наличии проводок на счете-родителе

Рассмотрим ситуацию, когда в системе есть проводки на самом счете 86 (исторические или ошибочно введенные новые) и проводки на субсчетах 86.01 и 86.02. При формировании ОСВ алгоритмы компоновки данных платформы выполняют расчет следующим образом:

1. Расчет общего итога по родителю: Общий итог по счету 86 рассчитывается как математическая сумма всех оборотов и сальдо по субсчетам (86.01 + 86.02) ПЛЮС собственные обороты и сальдо, записанные непосредственно на родительский счет 86. Математически баланс сходится, итоговая сумма верна.
2. Выделение собственной строки родителя: Чтобы пользователь отчета видел, из чего сложилась итоговая сумма по счету-группе, система выводит под родителем виртуальную строку с пустым кодом субсчета. В этой строке отражаются данные, которые «висят» непосредственно на самом счете 86.
3. Иллюзия задвоения: Бухгалтер видит общую строку по счету 86 (где просуммированы субсчета и сам родитель) и чуть ниже пустую строку с точно такой же суммой (если все проводки были на родителе) либо с частью суммы. Визуально это воспринимается как дублирование информации, вызывая панику у пользователей и аудиторов.

Почему позиция бухгалтера «я хочу делать проводки на сам счет 86» ошибочна?

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

• Сбои при закрытии месяца: Большинство регламентных операций в типовых конфигурациях (таких как «1С:Бухгалтерия», «1С:ERP», «1С:Комплексная автоматизация») ориентированы исключительно на работу с конечными субсчетами (так называемыми «листьями» дерева планов счетов). Программа просто не «увидит» суммы, зависшие на родителе, из-за чего регламентные документы закрытия периода либо проигнорируют эти суммы, либо отработают некорректно.
• Ошибки в регламентированной отчетности: Правила заполнения бухгалтерского баланса, деклараций и других отчетов жестко прописаны под конкретные субсчета. Обороты и сальдо по счету-родителю с высокой долей вероятности не попадут в регламентированные формы, что приведет к искажению отчетности перед проверяющими органами.
• Человеческий фактор: Если оставить возможность выбора родительского счета в проводках, сотрудники будут хаотично указывать в документах то 86, то 86.01, то 86.02. Это полностью уничтожит аналитичность учета и сделает невозможным автоматический контроль остатков.

Как правильно решить проблему: пошаговое руководство

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

Способ 1. Полный перенос проводок на субсчета (рекомендуемый)

Это самый чистый и правильный с точки зрения методологии 1С вариант. Нам необходимо перенести все движения с родительского счета 86 на один из субсчетов (например, 86.01).

Разберем по шагам, как это сделать:

Шаг 1. Поиск документов-источников.

Для начала нам нужно найти все документы, которые сделали проводки непосредственно на родительский счет. Для этого можно воспользоваться универсальным отчетом или написать простой запрос в консоли запросов:

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ РАЗЛИЧНЫЕ
    |	ХозрасчетныйДвижения.Регистратор КАК Регистратор
    |ИЗ
    |	РегистрБухгалтерии.Хозрасчетный КАК ХозрасчетныйДвижения
    |ГДЕ
    |	(ХозрасчетныйДвижения.СчетДт = &СчетРодитель
    |			ИЛИ ХозрасчетныйДвижения.СчетКт = &СчетРодитель)";

Запрос.УстановитьПараметр("СчетРодитель", ПланыСчетов.Хозрасчетный.НайтиПоКоду("86"));
РезультатЗапроса = Запрос.Выполнить();
ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();

Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
    Сообщить("Документ, требующий исправления: " + ВыборкаДетальныеЗаписи.Регистратор);
КонецЦикла;

Шаг 2. Перенос данных в проводках.

В зависимости от объема данных у нас есть два пути решения задачи:

1. Если документов мало, проще всего зайти в них вручную, изменить счет учета с 86 на 86.01 и перепровести.
2. Если документов много, перепроводить их за закрытые периоды крайне нежелательно. В таком случае программист может написать обработку, которая без перепроведения документов («ловкость рук и никакого мошенничества») заменит в регистре бухгалтерии счет 86 на субсчет. Пример кода для такой обработки представлен ниже:

// Пример замены счета в движениях конкретного документа без его перепроведения
Процедура ЗаменитьСчетВПроводках(ДокументСсылка)
    НаборЗаписей = РегистрыБухгалтерии.Хозрасчетный.СоздатьНаборЗаписей();
    НаборЗаписей.Отбор.Регистратор.Установить(ДокументСсылка);
    НаборЗаписей.Прочитать();
    
    Модифицирован = Ложь;
    Для Каждого Запись Из НаборЗаписей Цикл
        Если Запись.СчетДт = ПланыСчетов.Хозрасчетный.НайтиПоКоду("86") Тогда
            Запись.СчетДт = ПланыСчетов.Хозрасчетный.НайтиПоКоду("86.01");
            Модифицирован = Истина;
        КонецЕсли;
        Если Запись.СчетКт = ПланыСчетов.Хозрасчетный.НайтиПоКоду("86") Тогда
            Запись.СчетКт = ПланыСчетов.Хозрасчетный.НайтиПоКоду("86.01");
            Модифицирован = Истина;
        КонецЕсли;
    КонецЦикла;
    
    Если Модифицирован Тогда
        НаборЗаписей.Записать();
        Сообщить("Успешно изменены движения для: " + ДокументСсылка);
    КонецЕсли;
КонецПроцедуры

Шаг 3. Блокировка счета-родителя.

После того как все старые движения перенесены на субсчета, необходимо зайти в План счетов, открыть карточку счета 86 и установить признак «Счет является группой и не выбирается в проводках» (в некоторых конфигурациях это флаг «Запретить использовать в проводках»). Это заблокирует возможность случайного выбора счета-родителя пользователями в будущем.

Способ 2. Создание транзитного (технического) субсчета

Если бухгалтер категорически настаивает на том, что часть сумм должна лежать отдельно и их нельзя смешивать с аналитикой субсчетов 86.01 и 86.02, мы можем предложить компромиссный вариант, который полностью устроит систему и не сломает отчетность:

1. Создаем новый субсчет 86.03 «Нераспределенные целевые средства» (или любое другое подходящее название).
2. Переносим все движения с родительского счета 86 на новый субсчет 86.03 с помощью групповой обработки или ручных операций.
3. Устанавливаем для счета 86 запрет на использование в проводках.

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

Почему нельзя дорабатывать сам отчет ОСВ?

Иногда у начинающих программистов возникает соблазн пойти по пути наименьшего сопротивления — не трогать данные в базе, а изменить схему компоновки данных (СКД) самого отчета ОСВ, чтобы скрыть виртуальную строку родительского счета. Мы настоятельно не рекомендуем делать это по следующим причинам:

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

Резюме

Мы проанализировали проблему появления пустых строк и задвоения итогов в ОСВ 1С. Выяснилось, что причиной является нарушение методологии учета — присутствие проводок на счете-родителе при наличии субсчетов. Единственным верным решением является перенос всех проводок на субсчета (включая возможность создания технического субсчета 86.03) с последующей установкой запрета на использование родительского счета в проводках. Это гарантирует стабильную работу регламентных операций закрытия месяца, правильное заполнение баланса и корректный вид всех бухгалтерских отчетов.