Архив метки: миграция

Загрузка нескольких файлов в LSMW

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

На днях я загружал заработную плату с помощью стандартного BUS7023 ManagerExtPayroll. На выходе формируется IDOC, который складывается в T558* таблицы. Сама структура айдока иерархическая, где на верхнем уровне стоит сотрудник, ниже указаны периоды, а на третьем сами виды оплаты для периода.

Для простоты я решил сделать три соответствующих файла:

  • Сотрудники
  • Периоды
  • Виды оплаты

Каждый последующий файл содержит ссылку на предыдущий. Вот, что у меня получилось.

lsmw_py_0

Читать далее

Коды ошибок при чтении файлов в LSMW

Иногда начинаешь загружать файлик в LSMW (Read Data пункт), он система выдает ошибку в виде кода без всякого пояснения. Чтобы понять, что за ошибка, предлагаю сохранить себе кусок кода, который отвечает за чтение файлов с компьютера клиента (Frontend). По коду ошибки можно понять, что пошло не так. Многих такие ошибки путают.

Программа /SAPDMC/SAP_LSMW_READ_FORMS:

Миграция заработной платы

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

Также можно использовать LSMW для загрузки данных через IDOC. Это BAPI BUS7023, метод INSERTLEGACY. Эта часть работает с проверками основных данных (табельник, периоды).

Иерархические загрузки в LSMW

Привет, други и другалики.

Сегодня будем творить чудеса. Вы-то все это знаете, поэтому я для себя напишу, чтобы не забыть. Понадобилось, значит, нам сделать загрузку файлов таким образом, чтобы, как бы это сказать. Ну вы же представляете IDOC. Штучка такая для передачи данных между системами. А тут надо в одном айдоке заполнить несколько сегментов. Получается иерархическая загрузка, когда для одной старшей записи может быть несколько младших. Деревцо такое. А я помню, что в одном из документов по SAP Best Practices for HCM Payroll for USA было написано, что зарплату в T558* таблички надо грузить не как все, а по лучшим практикам — через IDOC. А у нас никто этого не знает, все абап пишут. САП не дурак, все продумал и сделал. Скорость обработки IDOC существенно выше обычной LSMW, так что на больших объемах подумайте.

И вот у нас есть файлик вида:
LINE1 Большая айдока
LINE2 Сегмента айдоки
LINE3 Пимпочка в третьем сегменте

Ерунда вообщем-то, но такая полезная оказывается. Что мы делаем? Включаем в каждую структуру исходника (Source Structure) поле с идентификатором уровня (наши LINE1, LINE2, LINE3) и ставим галочку, что это поле относится к идентификатам (в самом низу). Дальше связываем структуры как обычно, привязываем мэппинг в Field mapping. А когда создаем определение файла, то ставим галочку, что это не последовательный файл, а структурированный. И все. Система поймет, что все строчки, которые начинаются с LINE3 надо засунуть в структуру три к пимпочкам. И эти пимпочки относятся к LINE2, который относится к LINE1. И в рамках одной транзакции будет загружена иерархическая структурка.

Хочу сказать большое авторское Хрю Роману @metha. Без него я бы еще час ерундил.

Хотите подробную инструкцию? Видео? В картинках? Напишите в комментариях 😉

Тонкости загрузки зарплаты

Загружаем зп в систему через таблицу T558B и схему Ru30. Случилось так, что человек в одном месяце был уволен и принят обратно. Один табельный номер. Как правильно положить суммы в загрузку?

С помощью отладчика выяснил следующее. В драйвере расчета до запуска схемы идет проверка на строчку PGM TRN. Если такая строчка найдена, то система игнорирует состояние управляющей записи и грузит все периоды, которые есть в T558B. Но, для корректности загрузки она внутри себя строит таблицу APER, в которой по WPBP сама собирает периоды расчета. Если человек принят повторно в месяце, то мы должны разделить расчет заработной платы на два с помощью отдельного мероприятия — повторный прием. Признак разделения устанавливается в таблице T530. Система по этому признаку наш месяц поделила на два периода расчета с одним годом и месяцем, но разными датами начала и окончания (begda-endda).

Следующим шагом система читает t558b и сравнивает периоды в ней с периодами в APER. Если не сошлись, то выдает ошибку «Расчетный период 12 в T558B не совпадает с основными данными» (период расчета может быть любой). Поэтому в T558b должно быть два периода — уволенный сотрудник (без видов оплаты), вновь принятый (с видами начислений/удержаний). Если работник уволен, а потом повторно принят с разрывом в несколько месяцев, то в таблице T558b должны быть периоды, когда работник не работал.

В HRUCALC0 смотреть здесь:
Include RPCHRT09_FILL_APER

*———————————————————————-*
* new: to this point «K11K127822*
*———————————————————————-*
WHEN ‘TRN’. «tranfer old payroll results
PERFORM check_payty_t558b.
IF NOT rueckrab IS INITIAL.
PERFORM fill_aper_for_regular_payroll «QNZ note 331016
USING fa_datum. «QNZ note 331016
PERFORM check_aper_versus_t558b.
ENDIF.
PERFORM insert_bonus_runs_from_t558b.