Объединение баз в 1С:ЗУП КОРП 3.1 с использованием упрощённого переноса

Публикация по итогам вебинара с ведущим специалистом «АиБ Цифровизация» Ольгой Черкасовой.

Мы поделимся опытом по объединению баз в «1С:ЗУП КОРП 3.1» [«1С:Зарплата и управление персоналом КОРП 3.1»] с использованием технологии «Упрощённый перенос».

На очередном проекте перед нами стояла задача произвести объединение трёх баз «1С:ЗУП КОРП» в одну, и запуститься в опытно-промышленную эксплуатацию с 1 января на предприятии с общей численностью сотрудников — около 5,5 тысяч человек.

Главная особенность исходных баз — каждую из них ранее сопровождали разные организации. В связи с этим в системах было много измененных и доработанных объектов, то есть они уже выходили за рамки типового функционала «1С:ЗУП», были адаптированы под требования заказчика.

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

Начнём с особенностей объединения баз и сравнения «полного» и «упрощённого переноса». Простыми словами, при полном объединении данных баз источника в объединённую базу, которую будем иногда называть «базой-приёмником», переносятся все справочники и документы с их движениями.

Если при «полном переносе» мы переносим данные баз с движениями, то повторного проведения документов не требуется. В свою очередь, «упрощенный перенос», кстати, именно этот вариант рекомендует компания «1С» при переходе на «1С:ЗУП КОРП 3.1» с предыдущих редакций, имеет отличия по ряду пунктов. Перечислим их.

Отличия «упрощённого переноса» 1С:ЗУП КОРП

    1. Создаём «Начальную штатную расстановку» на дату переноса. На слайде видно документ начальной штатной расстановки. Он типовой. И, как можно увидеть, в нём собрана вся информация по сотрудникам, по их начислениям, по количеству и назначенным отпускам, графику работы и также по дате приёма сотрудника. «Начальная штатная расстановка» — это документ, который является основополагающим при переносе данных.

    2. Переносим данные только по работающим сотрудникам. На самом деле, это значительно облегчает объём данных, которые мы переносим из базы-источника. В базу-приёмник, в объединённую базу, не попадают уволенные сотрудники с их движениями, с их записями в регистрах и так далее.

     3. Переносим вместо документации за прошедшие годы сведения из справочников и регистров. Нужно обратить внимание, что обязательно переносим информацию для исчисления среднемесячного заработка (это нужно для отпуска, для больничных листов, для командировок), а также данные для формы «Т-2».

На слайде можно видеть скриншоты документа «Перенос данных», в котором на верхней картинке показаны, выделены регистры накопления, которые мы переносили при объединении. Можно видеть, что на вкладке «Данные о начислениях для расчёта» у среднего заработка более 218 тысяч записей. Это много, и, нужно сказать, это перенос данных из базы с количеством сотрудников, около 700-800 человек. То есть при переносе данных из баз с бОльшим количеством сотрудников, конечно, записей будет больше. В нижней части слайда показаны, выделены регистры сведений, которые тоже были перенесены при таком типе переноса данных.

    4. Проводим перенос лишь остатков по взаиморасчётам работающих сотрудников, переходящего НДФЛ и остатков по резервам.

Вот слайд, где показаны регистры, остатки по взаиморасчётам именно работающих сотрудников для того, чтобы можно было создать ведомости на выплаты, которые не были проведены сотрудникам в том периоде, который остался в старой необъединённой базе. На следующем слайде можно посмотреть корректировочный документ «Резервы по оплате труда», который также необходим в объединённой базе-приёмнике для того, чтобы в дальнейшем корректно отрабатывали другие документы, которые мы будем создавать по резервам на оплату труда.

В каких случаях полный перенос «1С:ЗУП КОРП» не работает

    1. Объём базы «1С:ЗУП».

Когда на этапе проектирования мы задаём заказчику вопрос по поводу вида переноса данных при объединении, и заказчик, и сотрудники обычно просят «полный перенос», чтобы сохранились все данные, все движения, все исторические документы, чтобы можно было формировать отчёты за предыдущие года и распечатывать какие-то печатные формы. И, когда база маленькая, конечно, почему бы и не сделать полный перенос, ведь это не составляет большого труда. При этом малое количество сотрудников не должно вводить в заблуждение, нужно проверить именно на сам объём базы данных.

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

Не стоит забывать также, что при «полном переносе» в объединённую базу-приёмник переедет и ненужный «мусор». Например, перенесутся уволенные сотрудники, расформированные подразделения, документы, помеченные на удаление. Это всё, конечно, нагрузит базу-приёмник, что, в общем-то, нежелательно в рамках переноса, объединения.

    2. Архитектура документов.

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

С такой ситуацией мы столкнулись при переносе базы «1С:ЗУП 3.1» в организации численностью 170 сотрудников. Казалось бы, численность небольшая, но в 2017 году у документа «Резерв на отпуск» регистров совсем не было, и на момент переноса это не соответствовало структуре актуального документа «Резерва отпусков», что и не позволило корректно перенести данный документ.

    3. Отличие общих настроек системы и констант в базе-источнике и базе-приёмнике.

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

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

Подготовка к объединению баз

Переходим к подготовке объединения. Мы выделили семь этапов, которые необходимо обратить на них внимание. На каждом из этапов обязательно остановимся, но отметим, что именно первый этап «Анализ настроек» является важнейшей частью проектирования объединения баз, и на данный этап необходимо выделить, порядочное количество времени, достаточное, чтобы проанализировать все константы общей настройки. В системе таких настроек более 350, и из них 20 конфликтных.

Можно назвать, например, встречающиеся такой часто настройки заработной платы, как «Сведения для расчёта общего среднего заработка». В настройках заработной платы есть возможность ограничивать начала расчёта периода среднего заработка датой приёма. Согласитесь, разные компании по-разному используют эту настройку.

Если всё-таки обнаружен конфликт настроек, нужно адаптировать было базу-источник под объединенную базу-приёмник, чтобы перенос данных прошёл корректно. К примеру, в одной из баз-источников у нас был установлен флажок «Выполнять расчёт зарплаты без оптимизации», а в базе-приёмнике такой константы не наблюдалось.

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

Этапы подготовки объединения баз в «1С:ЗУП КОРП 3.1»

Давайте перейдем непосредственно к каждому из этих этапов и остановимся поподробнее на каждом из них.

1 этап. Проводим анализ настроек. Основные настройки кадрового учёта — это «Штатное расписание с историей», «Виды отсутствий», контроль уникальности номеров.

Яркий пример, с которым мы столкнулись на нашем проекте при объединении баз: в одной из баз-источников велось штатное расписание с историей сохранения и изменения штатного расписания. Во второй базе-источнике штатное расписание не велось вообще. И в базе-приёмнике штатное расписание велось без истории. Понятно, что без каких-то дополнительных операций объединить эти базы было бы невозможно.

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

Основные настройки зарплаты тоже являются одним из ключевых моментов, на которые нам необходимо обратить внимание. Это такие настройки, как расчёт стоимости часа, показатели, используемые при расчёте среднего периода, расчёты с момента приёма сотрудника на работу, их все необходимо скорректировать под локально-нормативные акты организации, чтобы в дальнейшем все расчёты происходили по определённому идентичному методу. Поскольку обычно объединяют базы «1С:ЗУП» организаций, принадлежащих одному холдингу, локально-нормативные акты в большинстве случаев похожи.

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

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

2 этап. Тщательно анализируем справочники «Виды рабочего времени», «Виды оснований увольнения», «Виды отпусков», «Графики работы», «Виды стажа сотрудников», чтобы избежать ситуации дублирования.

На следующем скриншоте – наша таблица, в которой мы собрали список объектов.

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

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

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

3 этап. Анализируем начисления и удержания.

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

Поэтому при решении использовать начисление базы-приёмника всё-таки нужно переименовать в базе-источника наименование и код идентично наименованию в базе-приёмнике. И после этого корректно написать правила переноса.

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

4 этап. Анализируем внешние печатные формы и обработку отчётов.

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

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

5 этап. Анализируем роли и прав доступа пользователей.

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

На слайде представлен скриншот из базы, в которой видно, что, цифрами обозначены группы доступа, которые уже присутствовали в базе-приёмнике.

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

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

6 этап. Анализируем перечень документов.

Нам необходимо также составить перечень документов и провести их анализ для переноса проведенными и не проведенными. Этот перечень объёмный, так как переносятся не только кадровые документы, но и расчётные. Также важно проанализировать регистры к переносу. Необходимо учитывать, что обязательными к переносу являются регистры, связанные с расчётом среднего заработка, регистры накопления по НДФЛ, учёту зарплаты по сотрудникам, выплаты бывшим сотрудникам.

Подготовительные работы в базе-источнике

Надеемся, что у вас уже создалось впечатление, что работа сама по себе объёмная и на неё нужно выделить достаточно времени. В следующих четырёх пунктах мы постарались сублимировать общие положения.

Первое — гораздо удобнее объединять базы данных с одинаковыми релизами. И, соответственно, задача первая —привести системы к общему знаменателю, чтобы все они были на одном и том же релизе.Второе — это изменить настройки системы, подготовить справочник в базе-источнике, соответствующий справочнику в базе-приёмнике.

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

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

С резюме подготовительных работ в базах источника закончили. Переходим к следующему большому блоку.

Объединие баз «1С:ЗУП» и чек-листы

Рекомендуем провести пробную загрузку объединения в тестовой копийной базе, потому что в первичном тесте выявляются все упущенные моменты при переносе данных. То есть, когда мы проанализировали, убедились, что всё хорошо, мы всё проверили, и всё должно пройти без сучка и без задоринки, или наоборот, выяснили, что выявились какие-то конфликты не решены и доработали эти моменты.

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

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

С этим столкнулись, когда расчётчики нам сообщали о том, что при заполнении документа данные по начисленным суммам совершенно не совпадают с данными, которые должны быть. И мы определили, что это случилось потому, что некоторые документы кадровиками ещё не были утверждены.

При переносе мы используем тактику «Перенос без проведения». С одной стороны, это облегчает пользователю работу по созданию документа, в котором, например, вручную пришлось бы подбирать сотрудников, как, например, с документом «Премия» в организации с количеством сотрудников 800 человек. А с другой стороны, мы предлагаем провести документ, предварительно пересчитав его. Так, для документов «Отпуск», «Командировка», «Отсутствие с сохранением среднего» при пересчёте проверяется расчёт среднего заработка и тем самым корректность переноса регистра накопления, данное начисление для расчёта среднего.

У вас может возникнуть вопрос «Вот вы рассказываете об упрощённой схеме переноса, приводите примеры, в которых фигурирует перенос документов, да еще и без проведения». Да, всегда есть соблазн. Единовременно, желательно прямо 1 января, в крайнем случае 1 числа начинающегося квартала, перенести данные в объединённую базу и сказать пользователям: «Всё, мы работаем в новый объединенный «1С:ЗУП». Но на практике мы сталкиваемся с тем, что к 1 числу ни одна более-менее крупная компания не закрывает период, да и выплаты за вторую половину месяца обычно производят с 5 по 15 число следующего месяца, а до выплаты, наряду с закрытием периода, создаются кадровые документы, увольнения, переводы, сотрудники увольняются, ездят в командировки, болеют, ходят в отпуска. Таким образом, на момент, когда заказчик нам объявляет, что готов к переносу данных и объединению баз, накапливается некоторое количество документов, которые уже созданы. И их необходимо перенести в базу-приёмник для того, чтобы дальше после переноса базы, которая переехала в базу-приёмник, могли продолжать свою работу, а не начали с набивания заново всех этих документов. Именно поэтому мы говорим о принятии решения по переносу документов, именно этих документов, проведенными или не проведенными.

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

Учесть весь процесс, учесть документы и шаблоны, и документы, данные для расчёта заработной платы, заполнение документов разовых начислений, конечно, начисление удержаний, и также премии. То есть всё-всё-всё это необходимо проверить в каждом конкретном случае.

Четвертое, проверка формирование ведомостей на выплату. Двумя пунктами выше, когда мы рассказывали о проверке документов кадрового блока, мы сказали о том, что выплата заработной платы за вторую половину месяца, как правило, приходится на начало следующего, и поэтому создание ведомостей на выплату этих сумм уже производится в объединённой базе. Тут важно предусмотреть такие моменты, как выплаты бывшим сотрудникам. Обычно это годовые премии или квартальные. И если таковые имеются, необходимо перенести регистры накопления, связанные с учётом доходов и НДФЛ по взаиморасчётам налогоплательщиков по этим сотрудникам.

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

Пятым пунктом чек-листа является проверка формирования документа отражения заработной платы в учёте.

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

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

Наверное, теперь имеет смысл сказать немного общих слов по проведению опытно-промышленной эксплуатации.

Опытно-промышленная эксплуатация объединённой базы «1С:ЗУП КОРП»

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

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

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

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

Второе, какие скрытые проблемы могут возникнуть, это в доработках документов. Доработаны бывают разные документы — «Табель», «Разовые начисления», документы «Премии». В них могут быть прописаны условия выполнения только для одной конкретной организации. Или документы могут быть прописаны, заполнены, доработаны так, что заполняются по определённым доработанным кнопкам показатели, только используемые для одной организации, а все наши пользователи объединённых баз, они тоже хотят пользоваться этим документом. И в случае использования документов получается некорректный расчёт или расчёт вообще отсутствует. Тут приходится уже на месте в процессе работы, опытно-промышленной эксплуатации всех пользователей объёмных организаций искать пути реализации и дорабатывать эти документы.

Дополнительные отчёты. Тут то, о чем я говорила мы говорили чуть ранее. При переносе из баз-источников, обращать нужно особое внимание на совместимость — это отбор по организации, кодировка, начисление или RLS.

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

Ну и важная рекомендация из опыта промышленной эксплуатации, который составляет минимум два месяца: для упрощения выбираемых данных рекомендуем использовать сверку данных в автоматическом режиме. Что это значит? Например, у нас существует «Отчёт по сверке данных», который разработан нашими программистами и достаточно успешно используется для того, чтобы не тратить время на выгрузку начислений или данных по каким-то другим объектам в Excel и не сравнивать вручную. В этом отчёте сразу видно расхождение, которое мы можем наблюдать.

Мы постарались коснуться практически всех тонких моментов на этапе подготовки, на этапе тестирования. В остальном же ничего суперсложного в объединении баз по упрощённому механизму нет. Надеемся, что наш рассказ и наша презентация были Вам понятна. Благодарим за внимание. В случае, если понадобится помощь высококвалифицированных специалистов, мы на связи.

Получить консультацию

ЭКСПЕРТНЫЕ МАТЕРИАЛЫ

→ 3 года с ERP в отделе закупок: выводы, промежуточные итоги
→ Нюансы настройки динамического планирования в «1С:ERP»
→ Компенсировать внедрение отечественного ПО на предприятиях субсидиями и грантами от государства?
→ Модуль WMS или модуль «Склад» в «1С:ERP»
→ «1С:ЗУП» – в ERP или нет?

Мы на связи: +7 (495) 120-40-02

Телеграм    ВКонтакте    Дзен