Подготовка к объединению баз в 1С:ЗУП КОРП 3.1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отвечу на ваши вопросы по особенностям полного и упрощённого переноса баз в «1С:ЗУП КОРП 3.1». Пишите: o.faychuk@aibcifra.pro.