Проблема с некорректным отображением ФИО сотрудников, когда буквы в фамилии, имени или отчестве начинают «двоиться» или «троиться» (например, «Ццарьков» вместо «Царьков»), является довольно редкой, но крайне неприятной технической ошибкой. Особенно остро она проявляется в крупных информационных базах (более 50 000 сотрудников), где ручная проверка данных невозможна, а ошибки в отчетности (такой как СЗВ-М или ЕФС-1) приводят к частичному непринятию документов контролирующими органами. Разберем подробно, почему возникает эффект «заикания» программы и как его устранить.
Первым делом проанализируем, где именно хранятся искаженные данные. В программах линейки 1С:Предприятие 8 (ЗУП 3.1, ERP 2.5, КА 2.5) данные о ФИО хранятся в нескольких местах:
ФИОФизическихЛиц: здесь хранится история изменений (фамилия, имя, отчество по отдельности) с привязкой к дате.ФизическиеЛица: содержит поле «Наименование» и скрытые реквизиты, используемые для быстрого доступа к текущему ФИО.Сотрудники: имеет поле «Представление», которое часто транслируется из данных физического лица.Как показывает практика, даже если в регистре сведений ФИОФизическихЛиц данные выглядят корректно, ошибка может «выстреливать» именно в поле «Наименование» или в вычисляемом «Представлении». Рассмотрим подробнее ситуацию, когда пользователь исправляет ошибку вручную, но через некоторое время (например, через 3 месяца) буква снова дублируется.
Первое подозрение всегда падает на «криворукость» пользователей. Однако, если ФИО меняется спонтанно у давно принятых сотрудников, это исключает первичный ввод. Рассмотрим ситуацию с повторным приемом. Часто сотрудников увольняют и принимают снова. В 1С:ЗУП 3.1 при этом создается новый элемент справочника Сотрудники, но физическое лицо должно оставаться прежним. Если при каждом приеме создавать новое физическое лицо, это породит дубли, но не вызовет удвоения букв в строке. Значит, корень проблемы глубже — в программных обработчиках записи объекта.
Наиболее вероятная причина «заикания» программы — это работа механизмов синхронизации данных (например, между ЗУП и Бухгалтерией предприятия). Разберем по шагам механизм возникновения ошибки:
Плана обмена объект регистрируется к выгрузке.ПередЗаписью или ПриЗаписи), который должен сформировать красивое «Представление» по шаблону «Фамилия И.О.».НовоеЗначение = ПерваяБуква + СтароеЗначение.Проанализируем ситуацию: если такая синхронизация происходит регулярно, то при каждой итерации обмена к фамилии будет добавляться еще одна буква, превращая «Царьков» в «Ццарьков», а затем в «Цццарьков».
Чтобы окончательно убедиться, что виноват программный процесс, а не человек, воспользуемся Журналом регистрации. Нам необходимо выполнить следующие действия:
Журнал регистрации по данному объекту (события «Данные.Изменение»).Рассмотрим пример анализа. Если в журнале мы видим, что изменение внесено фоновым заданием в 2 часа ночи, и в представлении события фигурирует ПланОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат, значит, проблема в правилах конвертации данных или в логике сопоставления объектов.
Для исправления ситуации недостаточно просто поправить буквы в справочнике. Проанализируем необходимые шаги для полного устранения ошибки:
1. Очистка кэша и проверка регистра истории. Проверьте, нет ли в регистре ФИОФизическихЛиц записей с «будущей датой» или пустых записей. Иногда система при записи создает «пустую» запись, которая при соединении строк дает неожиданный результат.
2. Проверка невидимых символов. Используйте консоль запросов или небольшую обработку, чтобы проверить строку ФИО на наличие символов с кодом 160 (неразрывный пробел) или других непечатных знаков. Пример кода для поиска таких «сюрпризов»:
Для Каждого ТекСтр Из ВыборкаФизЛиц Цикл
Для Поз = 1 По СтрДлина(ТекСтр.Фамилия) Цикл
КодСимвола = КодСимвола(Сред(ТекСтр.Фамилия, Поз, 1));
Если КодСимвола < 32 Тогда
Сообщить("Найден спецсимвол в ФИО: " + ТекСтр.Ссылка);
КонецЕсли;
КонецЦикла;
КонецЦикла;
3. Мониторинг планов обмена. Проанализируйте состав отправляемых данных в узлах обмена. Если объект «Физическое лицо» постоянно висит в очереди на отправку (даже если его не меняли), значит, какая-то подписка на событие постоянно помечает его как измененный, провоцируя бесконечный цикл перезаписи и «заикания».
4. Исправление представления. Если ошибка уже массовая, можно воспользоваться типовой обработкой «Групповое изменение реквизитов», но лучше написать скрипт, который перевызовет стандартную функцию формирования представления:
// Пример логики для обновления представления
ФизОбъект = Справочники.ФизическиеЛица.НайтиПоНаименованию("Ццарьков В.Н.");
Если Не ФизОбъект.Пустая() Тогда
Объект = ФизОбъект.ПолучитьОбъект();
// Вызов типового метода обновления ФИО
СклонениеФАМИЛИИИмениОтчества.ОтредактироватьФИО(Объект.Фамилия, Объект.Имя, Объект.Отчество, Объект);
Объект.Записать();
КонецЕсли;
Подведем итог: «заикание» букв в 1С — это почти всегда следствие работы фоновых заданий синхронизации. Система при обмене пытается «нормализовать» ФИО, но из-за некорректных исходных данных (лишние пробелы, спецсимволы) или ошибок в правилах обмена, алгоритм раз за разом дублирует первый символ строки. Решение заключается в выявлении конкретного плана обмена через журнал регистрации и очистке данных от невидимых символов в обеих синхронизируемых базах.