Top.Mail.Ru

За что программисты не любят ЗУП. Часть 2.

Первую часть, где мы рассматриваем ситуации, где требуются доработки ЗУП можете почитать по ссылке.

Кейс №2. Увольнение сотрудника

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

Представим ситуацию, что сотрудник увольняется 31 октября. Согласно Трудовому кодексу, день увольнения - это рабочий день для работника. Человек должен отработать до конца рабочего дня, подойти в бухгалтерию, получить расчет и забрать трудовую книжку. В табеле в этот день будет стоять явка (или другой вид времени, но этот день будет заполнен).

image4.png

Если посмотреть на движения документа “Увольнение” и знакомый нам уже регистр сведений “Кадровая история сотрудников” - запись об увольнении появится 1 ноября. В регистре “Состояния сотрудников” запись об увольнении также с первого ноября. 

image5.png

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

Кейс №3. Работа со справочниками «Физические лица» и «Сотрудники»

Раньше справочник “Сотрудники” были только в ЗУПе. Сейчас одноименный справочник появился в Бухгалтерии 3.0, УТ, КА  и в других конфигурациях нового поколения. И во всех этих конфигурациях возникают те же вопросы, что и в ЗУП при работе с физическими лицами и сотрудниками.

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

Справочник “Сотрудники” служит для хранения основной информации о трудовых отношениях организации и физлица. Соответственно в справочнике “Физические лица” запись о каждом физлице будет одна, даже если он в организации может выступать в нескольких ипостасях: сотрудник, акционер, контрагент и т.д.

А вот в справочнике “Сотрудники” по физлицу может быть несколько записей, так как трудовых отношений может быть несколько: человек работает по договору подряда и по трудовому договору, в качестве основного сотрудника и в качестве совместителя, сотрудник уволился и потом опять оформился с новым трудовым договором. 

Возьмем классический пример для ЗУП: плановый отдел считает премию в excel и передает в бухгалтерию таблицу, в которой есть только ФИО сотрудников и сумма уже рассчитанной премии. И эти данные надо загрузить в ЗУП программно. В чем может быть сложность? 

Всегда нужно помнить, что связь справочников “Физические лица” и “Сотрудники” - один ко многим.

image6.png

Когда нам нужно загрузить данные по сотрудникам, мы должны программно определить нужного сотрудника, имея, как правило, характеристики физического лица (ФИО, СНИЛС, ИНН).

Также еще до сих пор встречаются задачи, когда нужно выстроить обмены между ЗУП и программами старого поколения, например УПП. В УПП нет справочника “Сотрудники”, только “Физические данные”, поэтому если задача требует передавать из УПП в ЗУП данные в разрезе сотрудников, то сразу встает вопрос, а как мы будем определять нужного нам сотрудника.

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

Например, при загрузке премии как минимум, мы можем на дату загрузки отбрасывать уволенных сотрудников, редко когда начисляют премию уже уволенным. Нужно обязательно проверить, а по этому сотруднику на дату загрузки есть трудовые отношения, возможно это договорник (ГПХ): премию они не получают. 

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

Кейс №4. Определяем уникальность сотрудника

Развивая предыдущий кейс, продолжим список вопросов, которые могут возникнуть при работе с справочником “Сотрудники”: когда мы загружаем данные в разрезе работников, выстраиваем обмены между разнородными системами, нам надо как-то сотрудников идентифицировать, синхронизировать по какому-либо признаку. Находить сотрудника по ФИО не всегда получается, женщины часто меняют фамилию, в больших организациях встречаются полные однофамильцы, поэтому часто выбираемый вариант - табельный номер сотрудника.

image7.png

Но так ли тут все просто? Если смотреть в конфигураторе справочник “Сотрудники”, то видим, что контроля уникальности здесь нет. Контроля уникальности табельных номеров можно добиться с помощью функциональной опции, но эта настройка ничего не гарантирует. 

image8.png

Мы, работая с базой, не знаем, когда эту галку поставили. Возможно, был переход с другой системы: с 2.5 в 3.1. А в ЗУП 2.5 или другой системе был нарушен контроль уникальности, и оттуда пришли сотрудники с одинаковыми номерами. В организации может быть такая политика, что, когда сотрудник увольняется, а потом приходит обратно, то ему присваивают тот же табельный номер. В любой момент пользователи могут решить этот флаг отключить. Поэтому я призываю очень осторожно использовать в качестве идентификатора табельные номера: возникает слишком много условий для корректной работы нашего доработанного функционала, и если приходится все-таки задействовать табельные номера, стоит сразу же реализовать проверку контроля уникальности и выдавать служебные сообщения о возникающих проблемах. Какие еще варианты можно задействовать: 

  1. GUID справочника “Сотрудники” - вариант хороший, если задача синхронизации техническая и все базы, между которыми обмениваются данные, 1С-овские. Если же грузим премию из excel, навряд ли пользователи будут напротив ФИО сотрудника проставлять его уникальный внутренний идентификатор.
  2. СНИЛС или ИНН.Часто выбирают эти варианты для определения сотрудника, но мы же помним, что это характеристики справочника “Физического лица”, по ним мы найдем физическое лицо, а нам еще нужно определить сотрудника. Еще бывают ситуации, что сотрудник просто не имеет СНИЛС или ИНН, или эти данные не внесли в базу данных. Такие ситуации все реже и реже случаются, но вот иностранцы совершенно спокойно могут не иметь этих документов.
  3. Разработать новый идентификатор, по которому в дальнейшем строить обмены. Этот вариант не всегда удобен - новый реквизит кто-то должен заполнить, но подходит для ситуаций, когда сотрудника первично заводят в какой-то другой системе, там присваивают уникальный код и в дальнейших отчетах, обменах нужно использовать его. Такое встречала в международных компаниях, где своя единая система по персоналу, в компаниях, где первично сотрудника заводят на корпоративном портале.
Опять же  нет однозначного ответа как быть и архитектурное решение строится в зависимости от ситуации заказчика и поставленной задачи, но об этих нюансах надо знать.

Кейс №5. Головная организация и Организация: в чем разница.

Как правило, любой отчет, любая печатная форма, любая обработка требует отбора по организации. И при обращении к регистрам расчета и накопления  мы видим два поля, где упоминается организация: “Головная организация” и “Организация”.  Встает вопрос, а какую организацию использовать?

image9.png

Часто эти поля содержат одну и ту же информацию, поэтому кажется, что не принципиально как именно строить отборы. 

Но может возникнуть ситуация, что в базе данных Заказчика на данный момент  “Головная организация” и “Организация” содержат одинаковое значение, а через несколько месяцев или пару лет там уже разные организации, так как изменилась деятельность компании, изменился подход и в одну базу объединили все организации, которые вели в нескольких базах. В каких случаях реквизиты могут быть разными? 

image10.png

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

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

А если требуется информацию по всему холдингу, мы строим запросы по Головной организации.

image11.png

Также стоит осторожно использовать реквизит “Организация” из справочника “Сотрудники”. 

В примере на слайде работнику оформили прием на работу в филиал в Волгограде. А если смотреть на справочник “Сотрудники” и на его реквизит “Организация”, то там стоит Крон-Ц.

image12.png

Иногда хочется пойти по простому пути и определить организацию работника, получив значение из одноименного реквизита в справочнике  “Сотрудники”, но мы рискуем вывести неверные данные. Точную информацию можно получить из соответствующих регистров сведений, например “Кадровая история сотрудников”.

Кейс №6. Плановые начисления сотрудника в ЗУП 3.1

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

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

Когда смотрим состав регистров, то первым делом в глаза бросается регистр сведений “Плановые начисления”. Вроде бы подходящий регистр, есть и виды начислений, и размер, и сотрудники. 

Те, кто работал с ЗУП 2.5 также хорошо помнят этот регистр, именно с ним и работали для решения подобных задач. 

image13.png

Но в ЗУП 3.1  данного регистра недостаточно. Есть второй регистр сведений “Значения периодических показателей расчета зарплаты (для сотрудников)”.

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

Если вы делаете переход с ЗУП 2.5 на 3.1, с УПП на 3.1, адаптируйте отчеты с плановыми начислениями. Иначе будет некорректно работать. И вот почему.

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

Разберем ситуацию с окладом:

Наш сотрудник трудоустроился 25.01.2010 года, при приеме на работу ему назначен  оклад в размере 35 000 р.

Анализируем регистр сведений “Плановые начисления”: 

  • есть запись от 25.01.2010,

  • вид расчета “Оплата по окладу”, 

  • ресурс “Используется” - истина,

  • Размер - 35 000.

Теперь регистр сведений “Значения периодических показателей расчета зарплаты (для сотрудников)” -  на 25.01.2010 также есть запись, показатель “Оклад”, размер 35 000.

На первый взгляд информация дублируется. Можно использовать регистр “Плановые начисления” и мы получим верные данные.

Дальше нашему сотруднику повышают зарплату и с 01.07.2021 года ему назначают оклад до 40 000 руб.

Смотрим на регистр сведений “Плановые начисления” - на 01.07.2021 по начислению “Оплата по окладу” никаких записей нет.

А вот в регистре “Значения периодических показателей расчета зарплаты (для сотрудников)”  - есть запись: показатель “Оклад”, размер - 40 000 руб.

!!! То есть при работе только с регистром сведений “Плановые начисления” мы не получим все изменения по нашим плановым начислениям.

Вторая ситуация: Надбавка за наставничество. При приеме на работу сотруднику также назначили надбавку за наставничество в размере 10% от оклада.

В регистре сведений “Плановые начисления” есть запись от 25.01.2010:

  • вид расчета “Надбавка за наставничество”,

  • ресурс “Используется” - истина,

  • размер 3 500 (то есть уже в абсолютной величине),

В регистре сведений “Значения периодических показателей расчета зарплаты (для сотрудников)” также на 25.01.2010 есть запись, где указан размер - 10%. И следующее событие по сотруднику: 01.07.2021 - ему повышают оклад и отменяют надбавку  за наставничество. 

В регистре сведений “Значения периодических показателей расчета зарплаты (для сотрудников)” на 01.07.2021 никаких записей нет, а вот в регистре  “Плановые начисления” есть запись, где ресурс “Используется” - ложь. 

image14.png

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

Разработка и новости из мира 1С

Подпишитесь на Телеграм-канал, чтобы быть в курсе

Эту статью хорошо дополняют
Казначейство в 1С:ERP. Планирование денежного потока
Реализация конфигурации с нуля. Портал для клиентов организации с синхронизацией с учетной системой
Частичная ликвидация основных средств в 1С
Модернизация основного средства в 1С
Основы бюджетирования и способы его автоматизации в 1С
Разукомплектация основного средства в 1С
Основные отличия 1С: Бухгалтерия 8 ПРОФ от КОРП
Основные отличия ПРОФ и КОРП 1С: Документооборот
Назначение и особенности 1С: Бухгалтерия 8
Свяжитесь с нами