Проблема задвоения предопределенных счетов плана счетов в конфигурациях 1С, таких как 1С:Бухгалтерия, является достаточно распространенной и вызывает значительные сложности для пользователей и специалистов. Мы сталкиваемся с ситуацией, когда после очередного обновления в базе данных появляются дубли типовых счетов, хотя в самой конфигурации (в режиме конфигуратора) предопределенный элемент остается единственным. Это приводит к некорректному учету, ошибкам при формировании отчетности и необходимости трудоемких ручных исправлений. Давайте подробно рассмотрим причины возникновения этой проблемы и эффективные методы ее решения.
Мы выясним основные причины, по которым предопределенные счета могут задваиваться в информационной базе 1С при обновлении или переносе данных:
Изменение GUID предопределенных элементов в обновлении: Одна из наиболее частых и коварных причин заключается в том, что в новом релизе конфигурации могут измениться внутренние уникальные идентификаторы (GUID) предопределенных элементов. Если платформа 1С не смогла корректно сопоставить старый и новый GUIDы, она может создать новый предопределенный счет, вместо того чтобы обновить существующий. При этом в конфигураторе будет отображаться только один предопределенный элемент, а в базе данных появятся два или более, один из которых будет "лишним" дублем.
Особенности обновления конфигурации поставщика при снятии с поддержки: Если конфигурация была ранее снята с поддержки (т.е. был снят "замок" поставщика) для внесения изменений, то при последующем обновлении через файл поставки (CFU) она может "перекомпилироваться". Этот процесс иногда приводит к изменению GUID существующих объектов метаданных, что, в свою очередь, может стать причиной задвоения предопределенных элементов при дальнейшем сопоставлении.
Проблемы совместимости конфигурации с платформой: Иногда задвоение может происходить из-за проблем совместимости конфигурации с конкретной версией платформы 1С:Предприятие, которая используется. Несоответствие версий или наличие ошибок в самой платформе могут приводить к некорректной обработке предопределенных данных при обновлении.
Ошибки при переносе данных или обмене:
При переносе данных между базами (например, с БП 2.0 на БП 3.0), особенно через универсальные обработки обмена, может происходить задвоение предопределенных элементов, если при загрузке не выполняется должная проверка уникальности. Чтобы исключить такие ошибки, применяется обработка для переноса данных без создания дублей предопределенных элементов.
В режиме обмена данными, если программно установлен флаг ОбменДанными.Загрузка = Истина, проверка уникальности предопределенных элементов в пределах информационной базы может не выполняться. Это может быть использовано для ускорения обмена, но при некорректном применении приводит к их дублированию.
Ручные изменения:
Предшествующие ручные изменения в конфигурации, такие как добавление счетов с другими идентификаторами, которые пересекаются по наименованию или коду, или даже удаление типовых счетов, могли повлиять на процесс обновления.
Ручное изменение кода или наименования предопределенного счета в режиме предприятия также может привести к проблемам с его уникальностью при последующих обновлениях, поскольку платформа может "потерять" соответствие.
Проблема "Код счета неуникальный" и особенности субконто: При обновлении платформа 1С может столкнуться с ситуацией, когда она не может обновить существующий счет из-за ошибки "Код счета неуникальный", хотя счет с таким кодом уже существует. В таких случаях система может создать новый счет вместо обновления существующего. Это особенно актуально, если есть различия в субконто – например, в базе включен учет по подразделениям, а в конфигурации поставщика субконто для этого счета другие или их количество отличается (например, "в конфигурации их три, а в базе их четыре (те же + подразделения)").
Настройки обновления предопределенных данных: Поведение платформы при создании и обновлении предопределенных элементов регулируется свойством "Обновление предопределенных данных" у объектов конфигурации и настройками для всей информационной базы, а также зависит от вида узла распределенной информационной базы (РИБ). Если установлены значения "Не обновлять автоматически" или "Авто" в определенных сценариях, это может повлиять на корректность обновления. Например, в подчиненных узлах РИБ предопределенные элементы обычно не создаются и не обновляются автоматически, а должны быть получены из центрального узла.
Мы рассмотрим несколько подходов к решению проблемы задвоения предопределенных счетов – от профилактических мер до методов устранения уже возникших дублей. Выбор конкретного подхода зависит от текущей ситуации, степени повреждения базы и уровня ваших навыков.
Лучший способ решения проблемы – это ее предотвращение. Мы можем контролировать процесс обновления, чтобы минимизировать риск задвоения предопределенных элементов. Для регулярного сопровождения системы используется программа для автоматического архивирования, обновления и тестирования баз 1С в тихом режиме.
Отказ от автоматической замены объекта ПланСчетов: При обновлении конфигурации платформа 1С может предложить заменить объект ПланСчетов на тот, что в конфигурации поставщика. В некоторых случаях, особенно если есть подозрения на проблемы с GUID или ручные изменения, мы можем отказаться от этой автоматической замены и перенести изменения "ручками" в текущий план счетов через режим сравнения/объединения. Это дает нам полный контроль над тем, какие изменения будут применены.
Внимательное изучение изменений в Конфигурации поставщика: Перед применением обновления мы можем открыть конфигурацию поставщика (через меню "Конфигурация" -> "Поддержка" -> "Настроить поддержку...") и тщательно просмотреть изменения, касающиеся плана счетов. Мы можем даже сохранить конфигурацию поставщика в отдельный файл (.cf) для более детального анализа:
Откройте текущую конфигурацию в режиме конфигуратора.
Выберите "Конфигурация" -> "Поддержка" -> "Настроить поддержку...".
В открывшемся окне "Настройка поддержки" нажмите кнопку "Конфигурация поставщика".
Мы можем просмотреть структуру объекта ПланСчетов.Хозрасчетный, его предопределенные элементы и их свойства. Чтобы получить файл конфигурации, в этом же окне мы можем найти опцию "Сохранить конфигурацию в файл".
Загрузив этот файл в пустую базу, мы можем выгрузить его структуру в файлы для анализа GUID. Например, через команду "Конфигурация" -> "Выгрузить конфигурацию в файлы...".
Анализ GUID предопределенных счетов в новой конфигурации поставщика и сравнение их с текущими в рабочей конфигурации может помочь выявить потенциальные проблемы заранее.
Использование режима сравнения/объединения для ручного контроля: При обновлении, если конфигурация не на замке, мы всегда можем использовать режим сравнения/объединения. Это позволяет нам построчно контролировать изменения, применяемые к объектам, и вручную выбирать, какие изменения принимать, а какие отклонять. Это особенно полезно, когда мы видим, что система пытается добавить новый предопределенный счет вместо обновления существующего.
Мы разберем подробный, хотя и трудоемкий, метод, который показал свою эффективность в сложной ситуации, когда задвоение уже произошло. Этот метод требует глубокого понимания работы с конфигуратором и может быть выполнен только опытными специалистами.
Шаг 1: Подготовка и создание резервной копии.
Прежде чем приступать к любым изменениям, критически важно создать полную резервную копию информационной базы! Это позволит нам восстановиться в случае возникновения непредвиденных проблем. Мы можем использовать стандартные средства платформы 1С для выгрузки информационной базы (.dt файл) или средства СУБД (для SQL баз).
Шаг 2: Включение возможности изменения конфигурации.
Если конфигурация находится на поддержке с запретом изменений, нам придется временно снять ее с поддержки. Для этого в конфигураторе выберите "Конфигурация" -> "Поддержка" -> "Настроить поддержку..." и нажмите кнопку "Включить возможность изменения". Мы выбираем опцию "Изменяемая" или "Объект на поддержке с возможностью изменения" для тех объектов, которые планируем модифицировать (в данном случае, вероятно, сам ПланСчетов.Хозрасчетный и, возможно, ВидыСубконтоХозрасчетные).
Шаг 3: Удаление "кривых" предопределенных счетов из базы.
Мы должны идентифицировать и удалить дублирующиеся "кривые" счета. "Кривыми" мы называем те счета, которые задвоились и не соответствуют текущей конфигурации поставщика. Мы можем найти их, например, в списке элементов плана счетов по одинаковому коду и наименованию, но с разными внутренними идентификаторами. Однако мы не можем просто удалить предопределенный элемент. Сначала нам нужно снять с него признак предопределенности. При необходимости можно использовать расширение для административного редактирования счетов, которое позволяет изменять реквизиты напрямую.
Шаг 4: Снятие признаков предопределенности у субконто.
Если проблема связана с различиями в субконто (как в случае с учетом по подразделениям, упомянутым в сообщении), мы должны временно снять признак предопределенности у всех ВидовСубконтоХозрасчетные, которые могут быть затронуты. Это необходимо, потому что 1С может не дать обновить или удалить счет, если есть несоответствия в предопределенных субконто. Это можно сделать программно или через специальную обработку. Например, для каждого вида субконто:
ВидСубконто = ПланыВидовХарактеристик.ВидыСубконтоХозрасчетные.НайтиПоНаименованию("Подразделения"); // Или другое наименование
Если ВидСубконто <> Неопределено Тогда
ВидСубконто.Предопределенный = Ложь;
ВидСубконто.ИмяПредопределенного = "";
ВидСубконто.Записать();
КонецЕсли;
Шаг 5: Снятие признаков предопределенности у счетов-дублей.
Для каждого задвоившегося счета (например, 68.13, 68.52, 69.02.7, 69.06.5) мы должны снять признак предопределенности у "лишнего" дубля. Мы можем определить "лишний" дубль, например, по тому, что он не имеет ссылок, или по его GUID, который отличается от эталонного в конфигурации поставщика. Это также выполняется программно:
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| ПланСчетов.Ссылка КАК Ссылка,
| ПланСчетов.Предопределенный КАК Предопределенный,
| ПланСчетов.ИмяПредопределенного КАК ИмяПредопределенного
|ИЗ
| ПланСчетов.Хозрасчетный КАК ПланСчетов
|ГДЕ
| ПланСчетов.Код = &КодСчета
| И НЕ ПланСчетов.Предопределенный"; // Ищем тот, который уже не предопределенный или неправильный предопределенный
// Для каждого задвоившегося счета
СчетаДляПроверки = Новый Массив();
СчетаДляПроверки.Добавить("68.13");
// ... добавить другие коды
Для Каждого КодСчета Из СчетаДляПроверки Цикл
Запрос.УстановитьПараметр("КодСчета", КодСчета);
РезультатЗапроса = Запрос.Выполнить().Выбрать();
Пока РезультатЗапроса.Следующий() Цикл
СчетОбъект = РезультатЗапроса.Ссылка.ПолучитьОбъект();
Если СчетОбъект.Предопределенный Тогда
// Это "правильный" предопределенный, его не трогаем
Продолжить;
КонецЕсли;
// Это, скорее всего, дубль, с которого нужно снять предопределенность,
// если она по какой-то причине на нем еще висит.
// Или это тот самый "кривой", который надо удалить
СчетОбъект.Предопределенный = Ложь;
СчетОбъект.ИмяПредопределенного = "";
Попытка
СчетОбъект.Записать();
Исключение
Сообщить("Не удалось снять предопределенность со счета: " + СчетОбъект.Код + " " + СчетОбъект.Наименование + ". Ошибка: " + ОписаниеОшибки());
КонецПопытки;
КонецЦикла;
КонецЦикла;
После снятия признака предопределенности с дубля, он становится обычным элементом справочника.
Шаг 6: Пометка на удаление "кривых" счетов.
Теперь, когда "кривые" счета не являются предопределенными, мы можем пометить их на удаление стандартным способом в режиме предприятия (например, через "Все функции" -> "Стандартные" -> "Удаление помеченных объектов") или программно. Важно убедиться, что на эти счета нет ссылок в документах и регистрах, иначе система не позволит их удалить. Если ссылки есть, их необходимо перенести на "правильный" счет.
Шаг 7: Обновление конфигурации.
После всех предварительных манипуляций мы выполняем повторное обновление конфигурации. Мы ожидаем, что теперь 1С сможет корректно обработать план счетов и восстановить (или создать) "правильные" предопределенные счета, которые соответствуют новой версии конфигурации.
Шаг 8: Восстановление признаков предопределенности у субконто.
После успешного обновления мы должны вернуть признаки предопределенности у ВидовСубконтоХозрасчетные, которые мы снимали на Шаге 4. Это восстановит их типовое поведение.
Шаг 9: Замена дублей в базе.
Даже после обновления, возможно, останутся старые ссылки на удаленные или некорректные счета. Мы используем обработку "Поиск и замена значений" или специально разработанную обработку для замены всех ссылок со "старых" счетов на "новые", "правильные" предопределенные счета. Для этого мы сначала идентифицируем "правильный" счет (тот, который остался или был создан при обновлении и является предопределенным) и "неправильный" (старый дубль).
// Пример использования обработки "Поиск и замена значений"
// 1. Открываем обработку.
// 2. В поле "Что заменять" указываем "План счетов.Хозрасчетный".
// 3. Выбираем "Старое значение" (ссылка на "кривой" счет).
// 4. Выбираем "Новое значение" (ссылка на "правильный" счет).
// 5. Нажимаем "Заменить".
Шаг 10: Перепроведение документов.
Хотя "Поиск и замена значений" обычно меняет ссылки во всех местах, включая движения регистров, автор сообщения (15) отметил, что у него это не сработало, и в проводках возник "Объект не найден". В таком случае нам может потребоваться перепровести все документы, где участвовали затронутые счета. Это можно сделать пакетно, например, за определенный период или по списку документов, использующих эти счета. Это гарантирует, что все движения будут корректно привязаны к "правильным" счетам.
Шаг 11: Возврат конфигурации на поддержку.
После всех выполненных операций и тщательной проверки работоспособности базы данных, мы возвращаем конфигурацию на поддержку поставщика. Для этого мы сохраняем текущую конфигурацию базы данных (например, через "Конфигурация" -> "Сохранить конфигурацию в файл..."), а затем в меню "Конфигурация" -> "Поддержка" -> "Настроить поддержку..." загружаем конфигурацию поставщика из сохраненного ранее файла (или выбираем опцию "Сравнить, объединить или обновить конфигурацию с конфигурацией из файла"), чтобы она стала полностью соответствовать типовой конфигурации поставщика.
Это более быстрый, но потенциально рискованный метод, требующий большой осторожности и понимания последствий. Мы используем его, когда хотим "перезалить" план счетов из чистой конфигурации.
Шаг 1: Подготовка чистой конфигурации.
Мы создаем новую, пустую информационную базу и загружаем в нее типовую конфигурацию того же релиза, что и проблемная база. Это будет наш "эталон" для плана счетов.
Шаг 2: Выгрузка эталонного Плана счетов.
В этой чистой, эталонной базе мы используем стандартную обработку "Выгрузка/загрузка данных XML" или пишем небольшую собственную обработку для выгрузки всего плана счетов (ПланСчетов.Хозрасчетный) в XML-файл.
Шаг 3: Удаление предопределенных счетов в рабочей базе.
В проблемной рабочей базе мы предварительно удаляем все предопределенные счета из плана счетов. Это очень рискованный шаг, и он требует предварительного снятия счетов с поддержки, как описано в Подходе 2, и, возможно, временного снятия признака предопределенности со всех предопределенных счетов, чтобы их можно было удалить. Это действие должно выполняться с особой осторожностью и только при наличии свежей резервной копии.
Шаг 4: Загрузка Плана счетов из XML.
Сразу после удаления предопределенных счетов, не выходя из программы, мы загружаем план счетов из XML-файла, полученного на Шаге 2. Это должно создать новый, "чистый" набор предопределенных счетов с корректными GUID и признаками предопределенности. После загрузки необходимо провести тестирование и исправление базы данных (ТИИ) и, возможно, перепроведение документов, если ссылки были нарушены.
Этот метод предназначен для опытных специалистов, обладающих глубокими знаниями структуры данных 1С и умеющих работать с данными напрямую. Он позволяет точечно изменять GUID предопределенных элементов или их признаки, минуя стандартные механизмы.
Шаг 1: Создание обработки.
Мы разрабатываем внешнюю обработку или используем консоль запросов/команд для прямого доступа к данным плана счетов. Мы должны быть крайне внимательны к используемым запросам и операциям, чтобы не повредить базу.
Шаг 2: Изменение GUID или признаков предопределенности.
Мы можем написать код, который ищет дублирующиеся счета по коду и наименованию, определяет "правильный" счет (например, по тому, что на него больше ссылок или его GUID совпадает с эталонным из конфигурации поставщика) и затем заменяет ссылки на "неправильный" счет на ссылки на "правильный". Также мы можем программно менять признак предопределенности у дублей.
// Пример кода для поиска дублирующихся предопределенных счетов
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| ПланСчетов.Ссылка КАК Ссылка,
| ПланСчетов.Наименование КАК Наименование,
| ПланСчетов.Код КАК Код,
| ПланСчетов.Предопределенный КАК Предопределенный,
| ПланСчетов.ИмяПредопределенного КАК ИмяПредопределенного,
| ПланСчетов.УИД КАК УИД
|ИЗ
| ПланСчетов.Хозрасчетный КАК ПланСчетов
|ГДЕ
| ПланСчетов.Код В
| (ВЫБРАТЬ
| ПланСчетов1.Код
| ИЗ
| ПланСчетов.Хозрасчетный КАК ПланСчетов1
| СГРУППИРОВАТЬ ПО
| ПланСчетов1.Код
| ИМЕЮЩИЕ
| КОЛИЧЕСТВО(ПланСчетов1.Ссылка) > 1)";
РезультатЗапроса = Запрос.Выполнить().Выгрузить();
// Проанализируем результат, чтобы определить "правильные" и "лишние" счета
СчетПравильный = Неопределено;
СчетЛишний = Неопределено;
Для Каждого СтрокаТЗ Из РезультатЗапроса Цикл
// Логика определения "правильного" счета, например, по УИД из конфигурации поставщика
// или по количеству ссылок на него.
// ...
Если СтрокаТЗ.Предопределенный и (СтрокаТЗ.ИмяПредопределенного = "Счет68_13") Тогда // Пример
СчетПравильный = СтрокаТЗ.Ссылка;
ИначеЕсли СтрокаТЗ.Код = "68.13" и НЕ СтрокаТЗ.Предопределенный Тогда
СчетЛишний = СтрокаТЗ.Ссылка;
КонецЕсли;
КонецЦикла;
Если СчетПравильный <> Неопределено И СчетЛишний <> Неопределено Тогда
Сообщить("Найдено задвоение для счета " + СчетЛишний.Код + ". Правильный: " + СчетПравильный.Ссылка + ", Лишний: " + СчетЛишний.Ссылка);
// Далее используем типовую обработку "Поиск и замена значений" или пишем код для замены ссылок
// на регистры и документы.
// Например:
// УниверсальныеОбъекты.ЗаменитьСсылку(СчетЛишний, СчетПравильный);
// После замены пометить СчетЛишний на удаление.
КонецЕсли;
Иногда, возможно, потребуется не замена ссылок, а прямое изменение поля Предопределенный и ИмяПредопределенного у элемента справочника через объект ПланСчетов.Хозрасчетный, если элемент уже существует, но потерял признак предопределенности или его GUID изменился. Но это крайне рискованно и редко рекомендуется.
Шаг 3: Проверка и тестирование.
После любых прямых изменений данных обязательно проводим комплексное тестирование системы, перепроведение документов и сверку данных. Также запускаем "Тестирование и исправление" информационной базы. Чтобы быстро найти возможные расхождения с копией базы, используется программа для автоматической сверки бухгалтерских и налоговых проводок.
Независимо от выбранного подхода, мы всегда должны следовать общим рекомендациям, чтобы избежать проблем и обеспечить сохранность данных:
Резервные копии: Всегда делайте полные резервные копии информационной базы перед любыми операциями по обновлению или изменению структуры. Это ваша единственная гарантия восстановления в случае критических ошибок.
Тестирование и исправление ИБ: Регулярно используйте встроенные средства платформы для тестирования и исправления базы данных ("Администрирование" -> "Обслуживание" -> "Тестирование и исправление" в режиме предприятия или утилита chdbfl.exe в случае повреждения). Это поможет выявить и устранить логические и физические ошибки в структуре базы.
Анализ журнала регистрации: Для выяснения причин ошибок с предопределенными данными полезно анализировать события в журнале регистрации. Мы можем искать события по проблемному объекту (например, ПланСчетов.Хозрасчетный) и по категориям "Данные: Изменение предопределенных данных", "Удаление предопределенных данных", "Установка инициализации предопределенных данных", "ИнформационнаяБаза: Обновление предопределенных данных" и "Установка обновления предопределенных данных".
Осторожность с ручными изменениями: Если вы снимаете конфигурацию с поддержки для внесения изменений, делайте это максимально аккуратно и документируйте все изменения. Помните, что каждое изменение может повлиять на процесс обновления.
Важность проверки совместимости: Перед обновлением убедитесь, что версия конфигурации совместима с используемой версией платформы 1С:Предприятие. Иногда снижение версии платформы до предыдущей и повторный запуск обновления конфигурации может помочь в случае проблем совместимости.
Проблема задвоения предопределенных счетов, хотя и сложна, но решаема. Мы надеемся, что представленные подходы помогут вам успешно справиться с этой задачей и обеспечить корректное функционирование вашей системы 1С.