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

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

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

Миграцию можно поделить на два вида, если так можно сказать. Это миграция с начала налогового периода (то есть начала календарного года в России), и миграция с середины налогового периода.

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

Укрупненно миграцию можно разделить на две части: часть, которая влияет на расчет заработной платы, и часть, которая не влияет. Например, виды образования, документы, квалификации, какие-то иные данные можно загрузить после расчета заработной платы, так как они не критичны. Оргструктуру, присвоение, графики рабочего времени, регулярные начисления и удержания – все это нужно загружать в первую очередь и тщательно выверять.

11.1 Инструменты

Основным инструментом миграции данных, а мы говорим о загрузке данных в систему SAP, является LSMW. Часто консультанты пишут свои программы, но есть ли в этом необходимость? Пока что я не встречал в своей практике случаев, когда нельзя было бы обойтись средствами стандартной системы для переноса данных из внешних систем в SAP. LSMW достаточно гибкий инструмент, который может решить большинство задач миграции данных. Если не хватает возможностей записи данных в таблицы (например, T558*), то есть стандартные BAPI или IDOC, которые могут помочь загрузить данные, а заодно и проверить их. Поэтому не торопитесь писать свои программы.

По функционалу миграцию можно разбить на блоки. Организационный менеджмент, кадровое администрирование, рабочее время, заработная плата и все остальное. Именно в таком порядке, так как это обеспечит целостность данных. Например, если у вас есть наследуемые с оргменеджмента данные, то позвольте системе отработать это наследование самостоятельно, а не загружайте инфо- тип с принудительно присвоенными значениями. Часто это касается инфотипа «Основные данные», когда делается собственная разработка наследования оклада или часовой тарифной ставки из инфотипа 1005 в 0008. При этом сам восьмой инфотип загружают с установленными значениями. Система снимает признак косвенной оценки при сохранении инфотипа, и получается, что для всех смигрированных табельных номеров механизм наследования перестает работать. Нарисуйте заранее все взаимосвязи инфотипов и алгоритмов, которые могут быть неявно использованы в оценке времени или расчете заработной платы. Это позволит сэкономить время в будущем.

11.2 Организационный менеджмент

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

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

11.3 Кадровое администрирование

Инфотипы кадрового администрирования загружаются этапами. Сначала создается табельный номер путем загрузки инфотипов 0000, 0001, 0002. Следующим этапом создается привязка табельного номера к штатной должности, которая была загружена в организационном менеджменте заранее. Для синхронизации связей OM-PA запускаются программы RHINTE10, RHINTE20. Далее уже загружаются инфотипы, которые влияют на расчет заработной платы (0004, 0007, 0008, 0014, стажи, налоговые и так далее). И последними загружаются все прочие инфотипы (0022, 0024, 0290 и пр.). Не стоит забывать про автонумерацию. Если есть такая возможность, то, как и с OM, можно загрузить все во внешний диапазон, а затем переключить на внутренний.

11.4