Как исправить задвоение основного отпуска в позициях штатного расписания в 1С ЗУП 3.1?

Программист 1С v8.3 (Управляемые формы) 1С:Зарплата и Управление Персоналом
← На главную

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

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

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

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

Возможные причины, которые мы будем рассматривать:

  1. Ошибки в запросах и отображении данных: Весьма вероятно, что проблема заключается в некорректной работе запросов, которые формируют данные для отображения в форме позиции штатного расписания. Это объясняет, почему в документах может быть один отпуск, а в отображении – два. Такие ошибки иногда исправляются в новых версиях платформы или конфигурации, но могут проявляться и в текущей версии из-за специфических условий данных.
  2. Особенности ведения истории изменений штатного расписания: Механизм ведения истории изменений штатного расписания в 1С ЗУП 3.1 является ключевым для поддержания актуальности данных и отслеживания изменений. Если флажок Ведется история изменений штатного расписания установлен, все изменения фиксируются документами Утверждение штатного расписания и Изменение штатного расписания. Включение или выключение этой настройки может приводить к перестроению данных, что иногда помогает устранить ошибки отображения, как это произошло в данном случае.
  3. Влияние переноса данных из предыдущих версий: В некоторых случаях подобные ошибки, связанные со штатным расписанием и занятостью позиций, могли возникнуть при переносе данных из предыдущих версий ЗУП (например, с ЗУП 2.5 на ЗУП 3.1). Такие проблемы иногда связаны с некорректным заполнением регистров при миграции, когда часть данных могла быть перенесена с ошибками или дублированиями.
  4. Некорректные остатки в регистрах накопления: Если в программе возникают некорректные остатки по регистрам накопления, в которых нет явных регистраторов (документов), это может указывать на ошибку расчета временных итогов. Для исправления такой ситуации может потребоваться использование типового инструмента Управление итогами с установкой максимально ранней начальной границы.

Разбираемся с диагностикой проблемы

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

  1. Проверка документов «Изменение штатного расписания» и «Утверждение штатного расписания»:

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

  2. Анализ регистра сведений «История ежегодных отпусков по штатному расписанию»:

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

    1. Проверка при отмененных документах: Мы отменяем проведение всех документов Изменение штатного расписания и Утверждение штатного расписания, которые относятся к данной позиции. Затем мы открываем регистр сведений История ежегодных отпусков по штатному расписанию и фильтруем его по проблемной позиции. В идеале, после отмены проведения, записи об отпусках по этой позиции либо должны отсутствовать, либо должны отражать ее самое раннее, корректное состояние до возникновения ошибки.
    2. Проверка при проведенных документах: Мы проводим один документ Изменение штатного расписания для этой позиции. После этого мы снова проверяем регистр История ежегодных отпусков по штатному расписанию. Если в нем появляется только одна запись, соответствующая проведенному документу, это служит сильным доказательством того, что фактического двоения в базовом регистре, который отслеживает историю, нет. Это укрепляет нашу гипотезу о том, что проблема кроется либо в отображении, либо в другом, возможно, вспомогательном регистре, участвующем в формировании данных для интерфейса.
  3. Идентификация задвоенных отпусков по уникальным идентификаторам (GUID):

    Для точного определения того, являются ли задублированные отпуска одним и тем же объектом или разными, нам необходимо использовать их уникальные идентификаторы (GUID – Globally Unique Identifier). Каждый объект в системе 1С (справочник, документ, элемент регистра) имеет свой уникальный идентификатор. Если GUID двух отображаемых отпусков совпадают, это однозначно указывает на то, что один и тот же отпуск (один и тот же элемент справочника ВидыОтпусков) отображается дважды, а не два разных отпуска.

    Как мы можем получить GUID для диагностики?

    1. Мы можем использовать Консоль запросов, которая является мощным инструментом для анализа данных в базе 1С. С помощью консоли мы можем сформировать запрос к базе данных, который выберет данные о видах отпусков, привязанных к конкретной позиции штатного расписания, включая их уникальные идентификаторы.
    2. Представим себе концептуальный запрос, который поможет нам это сделать (точные имена таблиц и полей могут отличаться в зависимости от версии конфигурации, но принцип остается неизменным):
      
      ВЫБРАТЬ
          ШтатноеРасписаниеОтпуска.ВидОтпуска.УникальныйИдентификатор КАК GUIDВидаОтпуска,
          ШтатноеРасписаниеОтпуска.ВидОтпуска.Наименование КАК НаименованиеОтпуска,
          ШтатноеРасписаниеОтпуска.КоличествоДнейОтпуска КАК КоличествоДней
      ИЗ
          РегистрСведений.ШтатноеРасписаниеСрезПоследних.ВидыОтпусков КАК ШтатноеРасписаниеОтпуска
      ГДЕ
          ШтатноеРасписаниеОтпуска.ПозицияШтатногоРасписания = &ТекущаяПозицияШР
      

      Мы должны выполнить этот запрос, подставив вместо &ТекущаяПозицияШР ссылку на проблемную позицию штатного расписания. В результате мы ожидаем получить список видов отпусков, фактически привязанных к этой позиции, с указанием их GUID. Если мы увидим две записи в результате запроса с абсолютно одинаковыми GUID и наименованиями, но при этом в интерфейсе они представлены как две отдельные строки, это подтвердит нашу гипотезу о двоении отображения одного и того же объекта.

  4. Проверка прав пользователя и дат запрета изменений:

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

    1. Полные права пользователя: Мы обязательно убедимся, что у пользователя, под которым мы работаем, установлены полные права доступа к системе и ко всем объектам конфигурации. Недостаточные права могут блокировать возможность изменения данных.
    2. Даты запрета изменений: Мы проверим, нет ли установленных в программе дат запрета изменений для нашей организации, структурного подразделения или конкретного пользователя. Эти даты могут блокировать редактирование или удаление любых данных, сформированных до определенной даты.

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

Пошаговое решение проблемы задвоения отпусков в 1С ЗУП 3.1

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

  1. Создание резервной копии информационной базы:

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

  2. Переход к настройкам кадрового учета:

    Мы открываем раздел Настройка в главном меню программы 1С:ЗУП. Это стандартный раздел для глобальных параметров конфигурации.

    Затем переходим в пункт Кадровый учет, где собраны настройки, касающиеся управления персоналом и штатного расписания.

  3. Временное отключение истории изменений штатного расписания:

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

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

  4. Ожидание применения изменений:

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

  5. Проверка позиции штатного расписания:

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

  6. Удаление задвоенного отпуска (если активно):

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

  7. Повторное включение истории изменений штатного расписания:

    После того как мы убедились, что задвоение устранено или лишний отпуск удален, мы возвращаемся в Настройка -> Кадровый учет. Этот шаг возвращает систему в ее стандартный режим работы с полным отслеживанием истории.

    Устанавливаем флажок обратно на опцию Ведется история изменений штатного расписания.

    Снова подтверждаем изменения и даем программе время на перестроение данных, связанное с восстановлением механизма истории.

  8. Финальная проверка результата:

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

Важное замечание после применения решения

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

  1. Распроведение документов: Мы отменяем проведение всех документов Изменение штатного расписания и Утверждение штатного расписания, которые затрагивают те позиции, по которым производились изменения. Это обеспечит их перезапись на основе актуальных данных.
  2. Интерактивное проведение: После распроведения мы проводим эти документы заново. Однако мы делаем это интерактивно, то есть непосредственно пользователем, вручную, а не автоматически через групповую обработку или фоновое задание.

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

Дополнительные рекомендации и информация

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

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

  2. Проверка целостности базы данных: Мы можем периодически выполнять проверку и исправление информационной базы средствами платформы. Для файловых баз это утилита chdbfl.exe, для клиент-серверных – соответствующие средства СУБД (например, DBCC CHECKDB для MS SQL Server). Это помогает выявить и устранить физические или логические повреждения базы данных, которые могут быть причиной аномального поведения.

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

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

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

← На главную