← На главную

Мы сталкиваемся с ситуацией, когда после обновления конфигурации 1С Зарплата и Управление Персоналом (ЗУП) до версии 3.1.18.217 обнаруживается, что некоторые подразделения, которые ранее были расформированы и не использовались, вновь приобретают статус активных. Позиций штатного расписания (ШР) в них не было, но, как выяснилось, могли остаться сотрудники. На тестовой базе проблема не воспроизводится. Проанализируем возможные причины этого поведения и разработаем пошаговую стратегию для диагностики и решения.

Как работает расформирование подразделений в 1С ЗУП?

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

1. Отсутствие сотрудников: В расформированном подразделении на текущий момент не должно быть ни одного сотрудника. Если сотрудник числится в подразделении, даже без активных позиций штатного расписания, система может воспринимать подразделение как потенциально используемое.
2. Отсутствие актуальных позиций штатного расписания: В штатном расписании организации не должно быть активных позиций, относящихся к данному подразделению. Если в организации ведется история изменения штатного расписания, для закрытия всех позиций в подразделении необходимо использовать документ Изменение штатного расписания.
3. Флаг "Подразделение расформировано и не используется после": В карточке самого подразделения должен быть установлен соответствующий флаг с датой расформирования. Как правило, этот флаг устанавливается автоматически после выполнения предыдущих двух условий, то есть после закрытия всех позиций штатного расписания в подразделении.

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

Особенности отложенного обновления и его влияние

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

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

Однако, эти фоновые задания имеют свои особенности:

1. Длительность выполнения: Отложенное обновление может выполняться длительное время, особенно на больших базах с большим объемом данных.
2. Чувствительность к ошибкам: Эти фоновые задания могут быть чувствительны к ошибкам в самой базе данных (например, некорректно заполненные справочники, "зависшие" ссылки) или к ошибкам в коде обработчика обновления.
3. Возможные сбои: Если обработчик отложенного обновления завершился с ошибкой, это может привести к частичному или некорректному обновлению данных, что проявляется в подобных проблемах.

Мы можем проверить статус выполнения обработчиков обновления, включая возможные ошибки, в разделе Администрирование – Обслуживание – Результаты обновления и дополнительная обработка данных. Этот инструмент будет полезен для дальнейшей диагностики.

Анализируем возможные причины возникновения проблемы

Исходя из описанной ситуации и общих принципов работы 1С ЗУП, мы можем выделить несколько наиболее вероятных причин, по которым расформированные подразделения могли вновь стать активными после обновления:

1. Неполное расформирование подразделений до обновления

   Это одна из наиболее распространенных причин. Если подразделение не было полностью расформировано согласно всем правилам, система может попытаться "исправить" его статус при обработке данных в новой версии. Мы должны обратить особое внимание на следующие моменты:

   • Наличие принятых сотрудников: Если в расформированном подразделении фактически остались сотрудники, которые были приняты в него, но не были переведены или уволены до расформирования, это могло повлиять на его статус. Вопросы и уточнения в исходной теме подтверждают, что такая ситуация вполне вероятна. Обработчик обновления мог увидеть запись о сотруднике в подразделении и посчитать его активным, даже если позиции ШР были закрыты.
   • Корректность закрытия позиций ШР: Убедимся, что все позиции штатного расписания в расформированных подразделениях были закрыты соответствующими документами, и история ШР корректно отражает их неактивность.

2. Ошибки в обработчиках отложенного обновления версии 3.1.18.217

   Версия 3.1.18.х, к которой относится и 3.1.18.217, могла содержать специфические ошибки в обработчиках отложенного обновления, которые могли некорректно обрабатывать статус подразделений. Известны случаи, когда для этой линейки релизов требовалась установка дополнительных патчей и ручной перезапуск фоновых заданий для обхода выявленных проблем.

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

3. Специфические ошибки данных в рабочей базе

   Тот факт, что проблему не удалось воспроизвести на тестовой базе, является ключевым индикатором. Это заставляет нас предполагать, что дело может быть в специфических данных вашей рабочей базы. Отложенные обработчики могут "споткнуться" на определенных некорректных записях, которые:

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

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

4. Различия в окружении тестовой и рабочей базы

   Мы должны принять во внимание, что на тестовой базе фоновые задания, как правило, могут быть заблокированы для экономии ресурсов или для контроля за их выполнением. Автор темы подтвердил, что на тестовой базе фоновые задания заблокированы. Это является очень важным моментом, объясняющим, почему проблема не воспроизвелась. Для корректного тестирования мы должны будем запускать фоновые задания вручную.

Пошаговая инструкция по диагностике и устранению проблемы

Чтобы выяснить точную причину возникновения проблемы и устранить её, мы выполним следующие шаги:

1. 1. Проанализируем Журнал регистрации

   В первую очередь, мы внимательно изучим Журнал регистрации. Нам необходимо найти записи об изменении объектов типа "Подразделение", которые произошли во время работы фонового задания отложенного обновления.

   Что искать:

   • Тип события: Изменение.
   • Объект: Справочник ПодразделенияОрганизаций.
   • Пользователь: Обычно Регламентное задание или системный пользователь, от имени которого выполняются фоновые задания.
   • Комментарий: Постараемся найти записи, явно указывающие на контекст отложенного обновления.

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

2. 2. Проверим "Результаты обновления и дополнительная обработка данных"

   Перейдем в раздел Администрирование – Обслуживание – Результаты обновления и дополнительная обработка данных.

   Что сделать:

   • Проверим статус выполнения всех обработчиков обновления.
   • Нас интересуют любые ошибки или незавершенные обработчики, особенно те, которые касаются справочников, связанных со структурой предприятия (подразделения, штатное расписание).
   • Если обнаружены ошибки, мы должны проанализировать их описание для понимания корня проблемы. Возможно, здесь будет указана конкретная запись данных, на которой "споткнулся" обработчик.

3. 3. Тщательно проверим состояние расформированных подразделений

   Для каждого подразделения, которое "ожило" после обновления, мы должны убедиться в соблюдении всех условий его расформирования.

   1. Проверим наличие сотрудников: Мы сформируем отчеты по сотрудникам организации (например, Список сотрудников организации) с отбором по этим подразделениям. Нам необходимо убедиться, что в них нет активных сотрудников, принятых или переведенных до даты расформирования. Если такие сотрудники будут обнаружены, их необходимо корректно перевести в другое подразделение или уволить.
   2. Проверим позиции штатного расписания: Сформируем отчеты по штатному расписанию (например, Штатная расстановка, Штатное расписание организации) и убедимся, что в этих подразделениях отсутствуют активные позиции. Если история ШР включена, мы убедимся, что все позиции были закрыты документом Изменение штатного расписания до даты расформирования подразделения.
   3. Проверим флаг в карточке подразделения: Откроем карточки "оживших" подразделений и убедимся, что флаг Подразделение расформировано и не используется после установлен корректно и дата расформирования указана верно.

   Если мы обнаружим несоответствия (например, оставшихся сотрудников или активные позиции), их необходимо будет устранить, используя стандартные документы 1С ЗУП (кадровые переводы, увольнения, документы по изменению штатного расписания).

4. 4. Воспроизведем проблему на тестовой базе (контролируемо)

   Чтобы более точно диагностировать проблему и протестировать возможные решения, мы попробуем воспроизвести ситуацию на тестовой базе.

   1. Копирование базы: Мы сделаем актуальную копию рабочей базы на тестовую.
   2. Контролируемый запуск фоновых заданий: На тестовой базе мы не будем глобально разблокировать фоновые задания, как это было указано в обсуждении. Вместо этого, мы запустим их вручную, либо используя стандартные средства 1С (например, Регламентные задания в режиме предприятия), либо средствами конфигуратора (если требуется более тонкая отладка).
   3. Фокусировка на отложенном обновлении: Особое внимание мы уделим фоновым заданиям, связанным с отложенным обновлением. Мы запустим их поэтапно, отслеживая изменения в статусе подразделений и в журнале регистрации. Это позволит нам изолировать проблему и понять, какой именно обработчик вызывает некорректное поведение.

   Этот подход даст нам возможность точно воспроизвести проблему и отладить её, не затрагивая рабочую базу.

5. 5. Поиск патчей и обновлений

   Мы настоятельно рекомендуем проверить официальные ресурсы фирмы "1С" (например, портал 1С:ИТС) на наличие актуальных патчей или исправлений для вашей версии 3.1.18.217. Возможно, проблема уже известна разработчикам и для неё существует официальное решение в виде патча. Установка патчей часто устраняет специфические ошибки, возникающие при отложенном обновлении.

6. 6. Ручная корректировка данных (как крайняя мера)

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

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

Резюмируя, проблема с "оживлением" расформированных подразделений после отложенного обновления в 1С ЗУП 3.1.18.217 часто кроется либо в недочетах самого расформирования до обновления, либо в специфике работы обработчиков обновления с конкретными данными, либо в ошибках в релизе. Тщательная диагностика журнала регистрации, результатов обновления и детальная проверка состояния данных помогут нам найти и устранить корень проблемы.