Почему после обновления БП 2.0 счет 68.01 не разделился на субсчета и как это исправить?

При переходе на актуальные релизы конфигурации «Бухгалтерия предприятия 2.0» (БП 2.0) многие технические специалисты сталкиваются с проблемой: счет 68.01 («НДФЛ при исполнении обязанностей налогового агента») становится групповым, но накопленные на нем данные не переносятся автоматически на новый субсчет 68.01.1. В результате при попытке перепровести старые документы или создать новые программа выдает ошибку, сообщая, что счет является групповым и не может использоваться в проводках. Рассмотрим подробно причины возникновения этой ситуации и разберем по шагам алгоритм её решения.

Суть изменений в Плане счетов

Разделение счета 68.01 было продиктовано требованиями законодательства РФ в связи с введением прогрессивной шкалы НДФЛ (13% и 15%). Согласно логике типового решения 1С:

• Счет 68.01 становится «Группой» (в Плане счетов у него снимается признак «Счет является субсчетом» и флаг «Использовать в проводках»).
• Вводятся новые субсчета: 68.01.1 («НДФЛ исчисленный») и 68.01.2 («НДФЛ с доходов свыше 5 млн руб.»).
• Специальные обработчики обновления в режиме «1С:Предприятие» должны автоматически перенести все остатки и обороты со старого счета на новый субсчет 68.01.1.

Причина 1: Нарушение последовательности обновлений

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

Если вы пропускаете релиз, в котором был зарегистрирован обработчик перехода на новые счета НДФЛ, система может «проскочить» этот этап. При запуске в режиме «Предприятие» процедура ОбновлениеИнформационнойБазы просто не найдет нужных инструкций для вашего текущего скачка версий. Рекомендуется выполнять обновление последовательно, ориентируясь на файл update.htm в дистрибутиве, где указаны разрешенные версии для перехода.

Причина 2: Конфликт идентификаторов при наличии кастомизаций

Разберем наиболее сложный случай, описанный в сообщении 7. Если в вашей базе План счетов Хозрасчетный был изменен (добавлены свои субсчета или изменены свойства существующих), при обновлении через Конфигуратор может произойти подмена внутренних идентификаторов (GUID).

Проанализируем механизм: у каждого счета в 1С есть уникальный идентификатор. В типовой конфигурации счет 68.01 по идентификатору «превращается» в группу, а 68.01.1 создается как новый объект. Если при объединении конфигураций в окне сравнения/объединения вы неправильно выставили настройки (например, оставили «взять из конфигурации поставщика» без учета иерархии или сопоставления объектов), может возникнуть ситуация, когда:

1. Ваш старый счет 68.01 остался обычным счетом, но система считает его группой из-за изменения кода в модулях.
2. Новый субсчет 68.01.1 создался как дубль или вообще не создался.
3. Внутренние ссылки в документах продолжают указывать на старый объект, который теперь не имеет права участвовать в проводках.

Как правильно настроить объединение в Конфигураторе

Чтобы избежать подобных проблем при обновлении нетиповых конфигураций, выполните следующие действия:

1. Перед обновлением обязательно сделайте резервную копию.
2. В окне «Сравнение, объединение с конфигурацией поставщика» найдите План счетов -> Хозрасчетный.
3. Обратите внимание на пиктограммы соответствия. Если вы видите, что счет 68.01 сопоставляется с каким-то другим объектом, установите соответствие вручную.
4. Убедитесь, что для счета 68.01 признак «Счет является субсчетом» снимается, а для 68.01.1 устанавливается.

Ручное исправление ситуации в режиме «Предприятие»

Если обновление уже выполнено, счета разделились некорректно, а перепроведение документов вызывает ошибки, мы можем прибегнуть к принудительной замене счета. Для этого воспользуемся стандартной обработкой «Поиск и замена значений» (её можно найти на ИТС или в составе инструментов разработчика).

Рассмотрим алгоритм действий:

• В поле «Что заменять» выбираем объект из Плана счетов 68.01.
• В поле «На что заменять» выбираем новый субсчет 68.01.1.
• Нажимаем кнопку «Найти ссылки». Программа просканирует все документы, регистры бухгалтерии и регистры накопления.
• Нажимаем «Выполнить замену».

Важно: После такой замены все проводки в базе изменятся, ссылки в документах обновятся. Однако, если конфигурация сильно изменена, стоит проверить модули проведения. Рассмотрим пример кода, который может мешать работе в нетиповых базах:

// В старых модулях часто встречалось жесткое обращение к счету:
СчетНДФЛ = ПланыСчетов.Хозрасчетный.НДФЛ; // Это ссылка на 68.01

// После обновления в типовых релизах этот код заменен на:
СчетНДФЛ = ПланыСчетов.Хозрасчетный.НДФЛ_Исчисленный; // Это ссылка на 68.01.1

Если ваш программный код остался прежним, документы будут пытаться записать проводку на 68.01, что и вызывает ошибку. В этом случае необходимо глобальным поиском в Конфигураторе найти все упоминания ПланыСчетов.Хозрасчетный.НДФЛ и заменить их на актуальные значения субсчетов.

Особенности работы в распределенных информационных базах (РИБ)

Проанализируем ситуацию с РИБ. Как отмечено в сообщениях 8-9, крайне важно соблюдать последовательность:

1. Обновление сначала выполняется в Центральной базе (ЦБ).
2. В ЦБ запускается режим «Предприятие», отрабатывают все легальные процедуры обновления (перенос проводок на 68.01.1).
3. Только после завершения всех обработок в ЦБ выполняется выгрузка сообщения обмена для периферийной базы (ПБ).
4. В ПБ загружается обновление конфигурации, а следом — данные, которые уже содержат правильные субсчета в проводках.

Если в ПБ пользователи начнут работать и создавать документы до того, как из ЦБ придут изменения в Плане счетов и движениях, это приведет к конфликтам и «битым» ссылкам, которые придется выправлять вручную.

Проверка результата

После всех манипуляций проверьте состояние базы следующими отчетами:

1. Оборотно-сальдовая ведомость по счету 68.01: сальдо на самом групповом счете должно быть равно нулю (в некоторых версиях интерфейса оно может отображаться как сумма субсчетов, но проводок непосредственно на 68.01 быть не должно).
2. Оборотно-сальдовая ведомость по счету 68.01.1: здесь должны появиться все ваши исторические данные и текущие начисления.
3. Тестовое проведение документа: попробуйте перепровести любой старый документ «Начисление зарплаты». Если документ проводится без ошибок — вы справились с задачей.

Помните, что корректное разделение счетов — это залог правильного формирования регламентированной отчетности (2-НДФЛ и 6-НДФЛ), так как алгоритмы заполнения этих отчетов теперь ориентируются исключительно на новые субсчета и связанные с ними регистры накопления.