Архив метки: изменение

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

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

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

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

Вот и все.

Изменение компании

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

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

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

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

MASS(D)

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

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

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

Note 338256 – Retroactive change of payroll area not required

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