Изменение содержимого IDOC

Travel Management интересная штука. Когда вы делаете проводку в FI систему, то оно не проверяет на период, открыт ли он. И ваш IDOC с авансовым отчетом может успешно уйти из HR и потеряться в FI. И никто об этом не узнает, если только не нажмет кнопочку проверки в транзакции управления прогонами PRRW. Так и сегодня отправили мой авансовый в FI и забыли. А он на дошел. В таком случае сторнировать нельзя, так как HR считает, что документ уже проведен.

Вот и приходится искать обходные пути. Либо удалять и заново создавать, утверждать у начальства и пр. Либо поменять всего лишь дату проводки в IDOC для FI документа. Я решил пойти вторым путем. В BD87/WE02 открываем нужный нам IDOC. Разворачиваем до уровня сегмента и нажимаем два раза на листочек рядом с названием сегмента. Теперь через меню меняем нужное нам поле и сохраняем. Сам IDOC при этом копируется, получает новый статус.

Осталось самое маленькое — отправить этот исправленный IDOC заново. Просто так этого не сделать, так как установленный статус 32 (отредактирован) не даст. Для этого меняем статус на 30 с помощью программы RC1_IDOC_SET_STATUS.

Вот и все.


Изменение БЕ в PPOME

Сегодня приобрел новый опыт. Вроде бы банальная штука — изменить контировки на штатке и наследовать сотруднику. А вот фигу. Если вы хотите поменять МВЗ, которое относится к другой БЕ, то система не даст этого сделать. Обычно на проектах включают проверку, что МВЗ принадлежит только одной БЕ. Ввиду этого, есть трюк.

Итак, для изменения БЕ в PPOME (или МВЗ) на уровне штатного расписания и затем на табельном номере нужно сделать следующее:

1. Рассоединяем людей от штатки (ограничиваем записи соединений).
2. Изменяем контировку с новой даты.
3. Делаем мероприятие перевода на ту же самую позицию с новой даты.

Только так можно обмануть систему и изменить БЕ, МВЗ в 0001 инфотипе. Однако!


Массовое изменение данных в SAP

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

При этом никто не отменял старую LSMW: Первое SAP видео про LSMW


Изменение единицы расчета в прошлом периоде

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

Note 338256 — Retroactive change of payroll area not required

Если кратко, то изменение единицы расчет задним числом при расчете приведет к задвоению записей в кластере (с типом A), неверной работе функции импорта IMPRT, неверной работе отчетов (задвоение цифр). Вообщем, не надо трогать 🙂

 

Правильнее изменить запись инфотипа 1, а единицу расчета поменять с начала месяца в будущем (где еще нет расчета).