Ссылки на остальные части статьи:
1. Главные сложности решения, что отталкивает?
2. Плюсы решения, где они прячутся?
В этой статье рассмотрим задачу, с которой начинаются практически все проекты. Многие из этих проектов становятся проблемными. Причина - неверно выполненный перенос данных. В статье будут рассмотрены способы исключить проблемы при переходе на новую систему. Рассказ будет про переход на ЗУП 3, причем неважно с какой исходной системы. Однако, применить эти подходы можно к любой конфигурации.
1. Определяем заранее цели переноса данных.
Казалось бы... Что может быть непонятного? Цель одна - работа в новой системе! Вести кадровый учет, считать зарплату да налоги, сдавать отчетность.
Всё дело в том, что понятие "вести кадровый учет" в каждой организации своё, как и остальные понятия! Значит и цели у каждого свои. Следовательно их нужно описать заранее. Лучше всего описать, как говорится, "полный фарш". Если какая-то цель для текущей организации будет неактуальна - просто пропускаем. При описании целей переноса данных отвечаем на простой вопрос: "Что и зачем, иногда почему мы хотим делать в новой системе"?
Какие примеры можно здесь привести:
- Все организации ведут штатное расписание. Однако, не во всех организациях есть вредные условия труда, далеко не все организации находятся в условиях МКС/РКС. Некоторые организации используют разъездной характер работы или вахтовый метод работы. Что от этого зависит в штатном расписании:
- Необходимость заполнения полей "Код позиции списка" и "Основание досрочного назначения пенсии".
- Наличие надбавки и дополнительного отпуска за вредные условия труда
- Необходимость учесть в ФОТ позиции Районный коэффициент и Северную надбавку, а также дополнительный отпуск за работу в условиях МКС/РКС и т.д.
- В каждой организации ведется кадровый учет. Но в некоторых организациях работают инвалиды, или иностранцы, в т.ч. не резиденты. Это также накладывает определённые особенности:
- Необходимо корректно заполнить статус налогоплательщика по НДФЛ, иначе неверно будет исчислен налог и страховые взносы!
- Если это не гражданин РФ, он не имеет права на вычеты.
- Инвалиды имеют право на дополнительные 3 дня к основному отпуску. Это необходимо учитывать при заполнении и переносе кадровых приказов.
- Все ведут табель учета рабочего времени. Однако, при наличии вахтового метода работы возникают трудности с назначением и заполнение графиков работы. В периоды междувахтового отдыха у работника не идёт северный стаж и не начисляются соответствующие надбавки. Необходимо продумать, как будет решаться этот вопрос, какие и где данные необходимо для этого заполнить.
- Все считают зарплату. Но у некоторых есть управленческая часть зарплаты со сложным расчетом. Часто из предыдущей учетной системы необходимо перенести какие-то данные для расчета премий или доплат. Иногда, сначала нужно доработать систему, добавить нужные справочники/регистры и только потом переносить данные!
Для каждой цели необходимо указать, какие объекты метаданных необходимо заполнить, чтоб достичь поставленную цель. Прорабатывать данный пункт нужно с учетом особенностей организаций. Приведу "простой" пример: организация работает в Сургуте или Мурманске. Что необходимо заполнить, чтоб учесть территориальные условия:
- В справочнике "Виды стажа" должен быть элемент "Северный" с указанной категорией стажа "Северный".
- Регистр сведений "Виды стажа трудовой деятельности физических лиц" указывают виды стажа, которые требуется считать по работнику.
- Регистр сведений "Накопленные стажи физических лиц". В этом регистре хранятся сведения о стаже с даты приёма по текущий день (или на дату переноса). Если у работника есть стаж до даты приема, необходимо увеличить количество лет и месяцев данного стажа.
- Регистр сведений "Стажи физических лиц". По своей сути он дублирует предыдущий регистр.
- Регистр сведений "Проценты северной надбавки физических лиц". Именно в этом регистре хранится размер этой доплаты. Схема немного отличается от остальных плановых начислений.
- Регистр сведений "Параметры исчисления процента северной надбавки физических лиц". По этому регистру определяется, размер северной надбавки ещё увеличивается от стажа, или уже зафиксирован в максимальном значении.
- В справочнике "Подразделения" или "Территории" необходимо указать территориальные условия ПФР и размер районного коэффициента федерального и регионального.
Вот так, простая казалось бы задача превращается в сложную. Поэтому мною разработана подробная концепция с указанием целей переноса данных, списка метаданных, который нужно заполнить и объёма переносимых данных. Ознакомиться можно по ссылке (ВСТАВИТЬ ССЫЛКУ).
Теперь, когда понятно какие регистры заполнять, нужно пройти ещё один квест по поиску этих данных в устаревшей системе. За долго до переноса необходимо проверить какие данные есть в исходной системе, достаточно их или нет. Очень часто бывает, что в исходной системе вели неверный учет. Кто-то не считал стаж, кто-то не увеличивал размер северной надбавки, где-то ввели одно плановое начисление вместо двух и размер указывали суммарный. Ошибки бывают разные, но в ЗУП 3 обязательно вводить только корректные данные!
Для таких ситуаций пришлось написать обработку, которая основываясь на настройках подразделений автоматически генерирует все данные по надбавкам, стажам, дополнительным отпускам, связанным с условия труда в МКС/РКС. Данные генерируются как в штатном расписании, так и в кадровых приказах. Подробнее можно прочитать об этом по ссылке (ВСТАВИТЬ ССЫЛКУ).
Повторюсь, от того на сколько Вы проработаете цели и концепцию переноса, зависит успешность Вашего проекта! На этот этап рекомендую не экономить никаких ресурсов.
2. Корректные данные исходной системе - залог успешного переноса.
В предыдущих статьях уже писал о существующих заблуждениях при ведении проектов по ЗУП... Одним из главных считаю такое: "За данные отвечает заказчик, разработчик отвечает только за инструмент". Предлагаю разобраться в этом вопросе и устранить заблуждение.
Совместимость ЗУП с некорректными данными:
Сначала предлагаю ответить на такой вопрос: "Будет ли работать ЗУП 3 с некорректными данными?". Мой ответ - точно НЕТ! Это в ЗУП 2.5 мы могли перенести всё что угодно и сохранить возможность нормальной работы. Почему так? Причина в том, что в ЗУП 2.5 многие бизнес-процессы не связаны между собой.
Например, если штатное расписание велось криво, это никак не влияло на все остальные процессы, т.к. регистр сведений "Штатное расписание" нужен был только для одной цели - печатная форма Т-3. С этой целью он успешно справлялся... В ЗУП 3 тоже есть лишняя функциональная опция "Использовать штатное расписание". Все годы работы с ЗУП не понимал, как могут быть штатное расписание или табель не обязательными!?! При всём при этом если неверно заполнить надбавки, оклад, дополнительные отпуска в штатном расписании, то заполнять их придётся руками во всех приказах на прием/перевод.
Перенести неверные данные по налогам - вообще катастрофа! Налог удержанный заполняется только в ведомости. Повторное проведение документа не исправляет допущенные ошибки. Необходимо по каждой строке выплаты жать кнопку "обновить налог". Алгоритм удержания налога устроен так, что удерживается то что давно не удержано. Т.е. если перенесли ошибку, в первую очередь ЗУП 3 попробует её исправить. По опыту получается ещё хуже чем было. Ошибки накапливаются как ком. Исправление таких ситуаций требует невероятных усилий, иногда невозможно в принципе. Придётся "обрезать данные", обманывая алгоритмы ЗУП.
Посмотрим с позиции заказчика:
Когда организация ищет исполнителя на проект по переходу на новую систему, у них не стоит выбор между сделать качественно и сделать недорого! Не важно к кому они обратятся: к фрилансеру, к интегратору, возьмут в штат или по договору ГПХ... Цель - выполнить качественный переход.
Практически на всех моих проектах постановка задачи выглядит так: нам нужно сделать проект. Вот и вся постановка! Дальше есть только одно уточнение: скажите нам что нужно сделать. Здесь никто не обсуждает, что исходные данные находятся в плачевном состоянии. Чаще всего пользователи и не готовы даже их исправлять! Все ж заняты!
Поэтому правильная позиция звучит примерно так: проверим текущие данные , постараемся исправить ошибки, определим что необходимо переносить, подумаем над тем, как проверить результат переноса.
Тем кто до сих пор считает, что за данные отвечает заказчик могу сказать так: Грош цена инструменту, который переносит некорректные данные!
Выполняем детальную проверку предоставленных данных:
Рассмотрим способы проверки данных в исходной системе. Продолжу придерживаться позиции, что перенос данных может происходить из любой системы. Поэтому проверочные механизмы будут лишь частично описаны с ориентиром на ЗУП 2.5/УПП. Что проверяем:
- Полноту персональных данных. Вроде бы фраза общая... Какие данные надо проверить: информацию, которая попадает в регламентированную отчетность. Ведь это одна из целей перехода на новую систему. Часто встречаю, что вместо отчества для иностранцев ставят прочерк "-". Где-то ставят более одного пробела в ФИО, названиях должностей и подразделений. Орфографические ошибки также не редкость! Адреса, телефоны, место рождения должны быть введены в формате ФИАС.
- Если штатное расписание ведется вне системы, то стоит сверить наименования подразделений и должностей, как бы много их не было! Переносить в новую систему некорректные названия точно не стоит!
- Учтены ли условия труда в кадровой информации.
- Если кадровый учет и расчет зарплаты ведется в разных системах, необходимо провести работу по сопоставлению данных. Проверить, можно ли их объединить? Все ли сотрудники введены, все ли приказы отражены в нужные даты и т.д.
- Как введены данные об отпусках по уходу за ребенком. Для ЗУП 3 важно наличие документа Возврат из отпуска по уходу за ребенком, даже если он закончился в запланированную дату. В ЗУП 2.5 такой документ требовался только при досрочном завершении отпуска по уходу.
- Правильность налогов. Есть такое заблуждение, что в старой системе мы отчетность делаем руками, а в новой Вы нам сделайте обязательно автоматически! Дело в том, что это зависит от качества данных, а не от способностей внедренцев! Поэтому налоги выравниваем ДО переноса! Если в старой системе расчет верный - 99% что он будет верный и в ЗУП 3. Равно как и наоборот!
- Стоит обратится к своему опыту! Ответить на вопрос: "Где прошлый раз были проблемы с переносом?". Опыт - главный помощник при решении таких задач. Если уже наступили на грабли, стоит предпринять все возможные действия, чтоб больше этого не делать.
- Исправление известных "типовых" ошибок можно и нужно автоматизировать!
3. Определяем объём переносимых данных. Составляем концепцию переноса на основе целей.
Определимся теперь с вопросом: "Какие данные необходимо перенести?". При обсуждении этого вопроса с заказчиком обычно звучит так: "Нам надо всё переносить! Вдруг надо что-то посмотреть, мы не хотим туда сюда заходить в разные базы!" Уверен, что именно этот вариант является самым часто озвучиваемым со стороны заказчика. Но является ли он правильным? На мой взгляд нет! И вот почему:
- Если организация существует уже более 15 лет, а для крупных заводов и компаний это норма, она пережила уже не одну миграцию данных! Это значит, что данные, перенесенные из совсем старых учетных систем (ЗиК 7.7, старые версии Паруса, самописные, что не редкость) уже содержат в себе кучу ошибок! Более того, эти данные давно неактуальны! Люди уволены, подразделения расформированы.
- Какова вероятность, что эти данные понадобятся? Практически нулевая! К этим данным обращаются, если приходит запрос из ПФР на подтверждение стажа работы. Персональные данные понадобятся, если работник через много лет опять трудоустроится в эту компанию! Значит необходимо перенести справочник "Физические лица", заполнить по максимуму данные. Вторую потребность можно закрыть другим способом: либо обмен со старой базой, либо перенос информации для справки в сокращенном виде (что предусмотрено типовой конфигурацией!).
- Ещё раз повторюсь, что данные с прошлого переноса требуют корректировок для того, что перенести в ЗУП 3. Т.к. для обеспечения работоспособности ЗУП 2.5 нужно гораздо меньше данных, чем для той же цели в ЗУП 3.
- Некоторые заказчики ещё просят перенести расчетные данные за прошлые периоды. Кто-то просит за последние 2 года, чтоб можно было по расчетному листку проверить расчет среднего заработка. Кто-то просит вообще за весь период... Вот этого делать категорически нельзя! Следом за данными начислений потянутся данные по взаиморасчетам, налогам, взносам. Зачем они Вам? Поверьте в них много ошибок! При большой численности никто это не станет выверять и уж тем более исправлять! Период то закрыт, зарплата выплачена, налоги и взносы исчислены и уплачены. Налоги и взносы в ЗУП 3 частенько цепляют прошлые периоды, если есть перерасчет декабря в январе. И так по цепочке может зацепить несколько лет! И доначислит или сторнирует всё что посчитает нужным. Для корректного расчета НДФЛ потребуются данные о правах на вычеты и об использованных вычетах за эти годы. Если у Вас данных не будет, то ждите доначисления НДФЛ.
Этот перечень можно продолжать сколь угодно долго. Поэтому вот уже третий раз пишу, что нужна концепция переноса данных, которая под каждую цель описывает объём переносимых данных и метаданные, которые необходимо для этого заполнить.
От даты старта сильно зависит объём переносимых данных. Проще всего начать работу в новой системе с начала года. Но не всегда так получается сделать! Иногда требуется старт с начала квартала, или с начала любого месяца, иногда даже с середины месяца! Да, такой вариант есть и уже дважды встречался в моей практике.
Если стартуем не с начала года, то нужно дополнительно перенести все расчетные данные. Т.е. начисления, удержания, отсутствия, налоги, взносы, выплаты и т.д. Такая ситуация довольно часто возникает при переводе холдинга на новую систему. Все юридические лица холдинга в один момент перевести невозможно, поэтому проект разбивается на этапы. Кому то везет с переходом с начала года, кому-то нет. Но со своей стороны рекомендую прорабатывать вариант старта с середины чего угодно! Это связано с тем, что возникают дополнительные сложности, неверно пишут перенос данных, ошибки в данных не позволяют стартовать с первого раза и т.д.
Представьте себе, Вы запланировали старт с начала года. Допустим, разработчик сделал правила конвертации или обработку написал для старта с нового года. У Вас есть список доработок, которые требуется выполнить до начала работы в новой системе. И вот этот список сделать не успели! А заказчик не хочет стартовать без указанных доработок. И что Вы делать будете? Уверен будет много проблем в такой ситуации. Если у Вас правила или обработка позволяет стартовать с любой даты, Вы спокойно переносите дату старта, доделываете требования заказчика и в спокойном режиме начинаете работу в новой системе.
4. До переноса нормализуем и обновляем ключевые справочники и классификаторы.
Для того, чтоб начать перенос данных, необходимо подготовить "пустую" базу. Возникают вопросы:
- Где её взять?
- Какое состояние можно считать "пустым"?
- Какими данными её необходимо наполнить?
На практике встречал разные варианты: кто-то брал СФ и создавал пустую базу, кто-то брал демо-версию, чистил её от сотрудников и документов, и вот она пустая. На самом деле оба варианта неверные! Первый вариант верный частично.
Понимание правильного варианта появляется при описании целей переноса данных. Также задаём себе вопрос: какие данные нужно внести 1 раз и больше не запускать их повторную загрузку? Ведь финальный перенос данных - это примерно 15-я попытка загрузить данные). Если коротко, то нужны следующие данные:
1. Классификаторы. Самый простой пример банки и ФИАС.
2. Справочники, отражающие структуру и особенности предприятия: Организации, план видов расчета, графики работы.
3. Настройки учета.
Собственно вот и ответ на все 3 вопроса! Однако, справочники, отражающие структуру предприятия, необходимо нормализовать, прежде чем загружать. Вся эта информация, даже если загружена через правила обмена, должна быть тщательно выверена и настроена!
Для чего нужны настройки? Например, загружать кадровые приказы необходимо с выключенной функциональной опцией "Используется штатное расписание". Штатное расписание и все позиции штатного расписания будут сгенерированы автоматически на основании штатной расстановки. Если есть МКС/РКС - это настраивается в справочнике "Организации". Без этой настройки в план видов расчета не будут добавлены районный коэффициент и северная надбавка.
После всех проверок и настроек сохраняем файл ДТ - это и есть та самая "пустая база"!
5. Выверяем перенесенные данные.
Начну с самого распространённого способа проверки... На мой взгляд, он только вводит всех в заблуждение. Что делаем - пишем сверочный отчет, который тем же запросом, которым мы получали данные на выгрузку выводит исходный набор данных. Потом цепляем к нему ту таблицу, в которую мы положили данные и сравниваем... Интересно, какой будет результат сравнения?
Приведу другой пример из жизни. Дали, к примеру, задание: переложить бананы из картонной коробки в ящик для овощей в холодильнике. Какова вероятность накосячить в таком задании? Если только человек не съест по пути полкоробки... Надо ли выполнять проверку в такой задаче? Мне кажется нет, т.к. нет смысла пересчитывать бананы.
Все уж наверняка приготовили помидоры в меня кидаться... а рано! Вот что предлагаю проверить:
- Уже не раз говорилось о целях переноса данных. Так если мы поставили цели, значит надо проверить, достигли мы их или нет?
- Каждая цель отвечает за какой-то участок учёта. Каждый участок учета - это набор сценариев. Значит проверить каждую цель означает проверить все сценарии в этом блоке учета. Если все сценарии сработали - мы достигли нашу цель. Если какой-то сценарий не сработал - это повод для проверки объёма и качества перенесённых данных.
- Проверить правильность данных можно с помощью стандартных отчетов. Например, унифицированная форма Т-3 и штатная расстановка дают нам понимание о правильности перенесенных данных в этом блоке. Если не сходится численность или количество ставок или ФОТ - проверяем исходные данные и алгоритмы их переноса.
- Многие крупные компании используют этап "тестовый запуск". Его планируют за месяц или два до ввода системы в промышленную эксплуатацию. На этом этапе есть возможность ознакомиться с функционалом новой системы и оценить правильность и достаточность перенесенных данных. Выявленные ошибки быстро исправляются и тестирование продолжается/повторяется.
- Обычно тестовый запуск проводят на ограниченном наборе данных. Однако набор этих данных должен быть максимально сложным! Нет смысла тестировать начисление оклада. Есть смысл проверить расчет сдельной оплаты труда, разъездной характер работы, вахтовый метод работы и прочие сложности учета. На этом же этапе тестируем печатные формы приказов, трудовых договоров и дополнительных соглашений. В стадии промышленной эксплуатации придётся руками править тексты приказов и договоров, если не проверить заранее.
- Всё написанное не означает, что не нужно автоматизировать сверку. Должен быть чёткий алгоритм проверки, основанных на "узких местах" либо исходной программы, либо ЗУП 3. Когда есть чёткий алгоритм - проверочный отчет нам явно поможет! Но сравнивать бананы до перекладки в холодильник и после бессмысленно!
Вот, собственно, и всё! Описали цели переноса данных, составили концепцию, проверили исходные данные, перенесли, выполнили проверку данных - значит вероятность успешного переноса данных близка к 100%. Пропуск описанных этапов грозит проблемами на старте. Помните: ЗУП 3 не умеет обрабатывать некорректные данные! Есть ошибка в данных, значит, будет ошибка в работе ЗУП 3!
Напомню о наличии других полезных статей:
Часть 1. Общие вопросы. Доработка чужого кода. Code review.
Часть 2. Доработка типовой конфигурации. Обновление доработанной типовой конфигурации.
Часть 3. Разбор и доработка запросов
Часть 4. Программный интерфейс. Исправление чужих доработок.
Также напомню о статье про архитектора. Некоторые подходы, позволяющие решать сложные задачи, описаны в ней:
