← На главную

При подготовке регламентированной отчетности за квартал бухгалтеры часто сталкиваются с неприятным сюрпризом: после очередного обновления конфигурации 1С:Бухгалтерия 3.0 (начиная с релиза 3.0.60.34 и выше) часть остатков и оборотов по счетам учета расчетов с учредителями (75.02) и уставного капитала (80) внезапно пропадает. При детальном анализе выясняется, что эти суммы «ушли» на странные счета с префиксом «Я» (например, Я75.02, Я80.01), которые помечены как «Не используется».

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

Выясняем причину: зачем 1С переименовывает счета в «Я»?

Для начала проанализируем методологические изменения, которые фирма «1С» внедрила в план счетов. В старых релизах аналитический учет (субконто) на счетах 75, 80 и 81 велся исключительно в разрезе справочника Контрагенты. Однако на практике учредителями организации могут выступать как сторонние контрагенты (юридические лица), так и физические лица (например, сотрудники компании или сторонние граждане).

Чтобы упорядочить учет, разработчики «1С» создали новый тип субконто — Учредители. Это составной тип данных, который позволяет выбирать элементы как из справочника ФизическиеЛица, так и из справочника Контрагенты.

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

1. Переименование старых счетов: Старые предопределенные счета (со старой аналитикой «Контрагенты») переименовываются в плане счетов. К их коду добавляется префикс «Я» (Я75.02, Я80.01, Я80.09), а к наименованию дописывается текст «(Не используется)».
2. Создание новых счетов: Создаются абсолютно новые предопределенные счета со стандартными кодами (75.02, 80.01 и т.д.), но уже с новым типом субконто — Учредители.
3. Автоматический перенос данных: Специальный обработчик обновления должен в фоновом режиме перенести все остатки и обороты со старых «Я-счетов» на новые «чистые» счета, автоматически сконвертировав элементы справочников в новую аналитику.

Если этот механизм отрабатывает корректно, пользователь даже не замечает изменений. Но если в процессе обновления происходит сбой, остатки «зависают» на неиспользуемых «Я-счетах». Поскольку эти счета исключены из алгоритмов заполнения баланса, регламентированная отчетность «разъезжается», а актив не сходится с пассивом.

Почему автоматический перенос данных дает сбой?

Проанализируем основные причины, по которым автоматический переход ломается:

• Конфигурация находится на измененной поддержке: Если ваш программист вносил изменения в план счетов или связанные объекты конфигурации, при обновлении через сравнение и объединение могли сбиться внутренние идентификаторы (UUID) предопределенных счетов. Из-за этого регламентный обработчик обновлений просто «не узнает» новые счета и пропускает их.
• Сложные ручные операции: Документы ОперацияБух (ручные проводки), созданные бухгалтерами вручную много лет назад, часто содержат нестандартные корреспонденции счетов или незаполненные субконто. Алгоритмы автоматического обновления не могут однозначно сопоставить такие данные и пропускают операцию во избежание искажения учета.
• Прерывание фоновых процессов: Процедура конвертации данных является ресурсоемкой и выполняется в режиме так называемого «отложенного обновления». Если базу данных закрыли, перезагрузили сервер или прервали сеанс до завершения фоновых задач, процесс останавливается на полпути.

Рассмотрим детальные инструкции по выходу из этой ситуации.

Решение 1. Проверка и принудительный запуск отложенных обновлений

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

Выполним следующие шаги:

1. Перейдем в раздел Администрирование, затем выберем пункт Обслуживание.
2. В открывшемся окне развернем группу Обновление программы и перейдем по ссылке Результаты обновления и отложенные данные.
3. Проанализируем список процедур. Если мы видим строки со статусом «Ошибка» или «Не выполнялась», связанные с конвертацией данных уставного капитала или расчетов по депонентам/дивидендам, значит, наш перенос завис именно здесь.
4. Выделим проблемную процедуру обновления, нажмем на нее правой кнопкой мыши и выберем команду Запустить повторно.

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

Решение 2. Локальное исправление единичных ручных операций

Часто бывает так, что все документы перенеслись корректно, но одна или две ручные операции за прошлые годы (например, за 2014 год) «застряли» на счете Я75.02. Проанализируем, как исправить эту ситуацию вручную.

Выполним следующие действия по шагам:

1. Создадим резервную копию информационной базы перед любыми изменениями прошлых периодов! Это критически важно.
2. Откроем Оборотно-сальдовую ведомость (ОСВ) по счету Я75.02 с детализацией до субконто и документов движения.
3. Найдем конкретный документ ОперацияБух, который сформировал проводку по этому счету.
4. Зайдем в этот документ. Поскольку прошлый период, скорее всего, закрыт для редактирования (установлена дата запрета изменения данных), нам потребуется временно отключить дату запрета в разделе Администрирование — Настройки пользователей и прав — Даты запрета изменения.
5. В проблемной строке проводки очистим счет Я75.02 и выберем заново актуальный предопределенный счет 75.02.
6. Обратите внимание на субконто: программа потребует заполнить новую аналитику Учредители. Нам нужно будет создать или выбрать соответствующего учредителя (физлицо или контрагента).
7. Запишем и проведем документ, после чего вернем дату запрета редактирования на место.

Решение 3. Массовый перенос данных с помощью групповой обработки

Если «Я-счета» содержат сотни проводок по разным документам за много лет, ручной перенос нецелесообразен. В этом случае нам поможет стандартный инструмент «Групповое изменение реквизитов».

Рассмотрим по шагам, как выполнить массовую замену:

1. Перейдем в меню Администрирование — Обслуживание — Корректировка данных — Групповое изменение реквизитов.
2. В поле «Выбирать элементы» укажем объект метаданных, движения которого мы хотим скорректировать. Нам понадобятся движения документов, поэтому выберем в списке Набор записей регистра бухгалтерии (Журнал проводок).
3. Добавим условие отбора: СчетДт Равно Я75.02 (или СчетКт Равно Я75.02).
4. В табличной части доступных реквизитов для изменения найдем поле Счет и укажем новое значение — 75.02.
5. Нажмем кнопку Изменить реквизиты.

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

Решение 4. Исправление конфликтов в Конфигураторе

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

1. Запустим базу данных в режиме Конфигуратор.
2. Откроем окно конфигурации и перейдем в Планы счетов — Хозрасчетный.
3. Проверим список предопределенных счетов. Убедимся, что новые счета 75.02 и 80 присутствуют в списке и имеют правильные имена и свойства.
4. Если при обновлении произошел конфликт идентификаторов, выполним операцию сравнения и объединения с типовой конфигурацией поставщика той же версии, уделив особое внимание свойствам планов счетов.
5. Запустим утилиту Тестирование и исправление информационной базы (меню Администрирование — Тестирование и исправление) с установленными флагами «Проверка логической целостности» и «Реструктуризация таблиц». Это позволит платформе сопоставить связи между ссылочными объектами базы данных.

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