Ведение пользовательских документов изменений


3762
3

Часть 1. Создание объекта изменений генерация программы обновления.

В процессе реализации SAP расширений, позволяющих вводить дополнительные данные таких объектов как договор, установка, прибор, место потребления, объект подключения и т.д., а также при «написании» «собственной пользовательской» функциональности, возникает необходимость хранить и отображать историю изменений, как это реализовано в SAP, например, в документах изменений по объекту «Установка» (Рис. 1).

Рис. 1 Документы изменений по объекту «Установка»

Рассмотрим процесс настройки, создания и документирования изменений на примере расширения места потребления (группа функций XES60).

В ходе проектных работ возникла необходимость добавления исторических данных на объект «Место потребления», что повлекло за собой создание пользовательской таблицы ZISU_PREMISE_EXT (Рис. 2).

Рис. 2 Пользовательская таблица «ZISU_PREMISE_EXT»

Важным условием для создания документов изменения является реализация полей на элементах данных, как показано на рис. 2. При использовании встроенных типов данных возможности вести документы изменений не будет. При этом в настройках элементов данных необходимо отметить переключатель «Документ изменений» (Рис. 3)

Рис. 3 Настройка элемента данных.

Теперь необходимо создать объект документа изменений. Для этого заходим в транзакцию SCDO. Она находится по пути: SAP-меню: Инструменты →ABAP-инструментальные средства→Разработки→SAP BusinessWorkflow→ИнструментыОпределен→События→Создание события→Документы изменений→обзор (SCDO).

Нажимаем кнопку создать Рис. 4

Рис. 4 Основной экран транзакции SCDO.

Область имен не указываем. Идентификатор объекта документа изменений, как и во всех пользовательских разработках, должен начинаться с буквы Z (Рис. 5).

Рис. 5 Создание объекта документа изменений.

Далее заполняем текст объекта документа изменений и вставляем имя таблицы (их также может быть несколько). Если мы хотим передавать в модуль обновления таблицу, а не отдельную запись, то необходимо установить переключатель «Перенос как внут. таблицы». В нашем примере мы оставляем его неустановленным (Рис. 6).

Рис. 6 Настройка объекта документов изменений

Если установить переключатель «Докум. отдельных полей при удалении», то при удалении будет сохраняться история по каждому удаленному полю, иначе только факт удаления записи. Разницу иллюстрируют Рис. 7 и Рис. 8.

Рис. 7 Сохранение истории значений по всем удаляемым полям.

Рис. 8 Сохранение только факта удаления.

Нажимаем сохранить, после этого опять выходим  на первый экран и нажимаем кнопку «СгенерПрогрОбновл» (Рис. 9).

Рис. 9 Сгенерировать программы обновления.

На экране генерации программы обновления (Рис. 10) необходимо указать имя группы функций (я сделал ее совпадающей с именем объекта изменения, но это необязательно), остальные поля оставляем по умолчанию и нажимаем «Сгенерировать».

Рис. 10 Генерация программы обновления.

На информационном экране (Рис. 11) нажимаем кнопку «сохранить».

Рис. 11 Сохранение программы обновления.

После успешной генерации можно зайти и посмотреть информацию по генерации, нажав кнопку «Инфо по генерации» (Рис. 12)

Рис. 12 Информация по генерации.

В первую очередь нас интересует функциональный модуль обновления, который мы будем использовать при записи документов изменений (Рис. 13)

Рис. 13 Функциональный модуль обновления.

Имя функционального модуля обновления всегда состоит из имени объекта изменения с добавлением постфикса _WRITE_DOCUMENT. Модуль является полностью сгенерированным и готовым к использованию. При этом изменять вручную программный код модуля обновления нельзя. Если зайти и посмотреть модуль обновления при помощи транзакции SE37 мы увидим запись * THISFILEISGENERATED.NEVERCHANGEITMANUALLY,PLEASE!

Часть 2. Сохранение и просмотр документов изменений в программе.

Для работы с функциональным модулем обновления подключим в программу INCLUDE IEUPDMOD, в  котором (в ком?) хранятся константы для операций обновления, удаления и вставки строки таблицы. 

Примечание. Константы хранятся в INCLUDE IEUPDMOD.

Объявляем переменную для хранения идентификатора объекта изменений (в реализации SAP он зачастую совпадает с номером объекта, который

Ограниченный доступ

Для прочтения полной версии статьи необходимо зайти как зарегистрированный пользователь.

Комментарии:

Николай Кронский (Рейтинг: 345) 14:21, 05 февраля 2015

Виталий, информация по генерации преподнесена верно, но вот тема использования вызовов ФМ в собственной АВАР-разработке, мне кажется, раскрыта не полностью.
Внесу пару дополнений, если не возражаете:
1) Сгенерированные ФМ являются модулями обновлений с отложенным запуском (V2-Update). Соответственно, запускаться должны, в идеале, из модуля обновлений ваших данных.
2) Кроме того, можно было бы отметить возможность подготовки таблиц обновления с помощью стандартного ФМ CHANGEDOCUMENT_PREPARE_TABLES. Отдавая на вход таблицы с новыми/старыми данными, получим готовенькие таблицы с установленными индикаторами обновлений.
3) Еще есть нюанс - если запись документа изменений проводится для сложного бизнес-объекта (заголовок + позиции), то модуль, полученный автоматически (как описано в статье), разнесет разные виды изменений позиций (U, I,D) по различным документам изменений, что не всегда удобно и оптимально. В этом случае придется "пилить" собственный модуль записи документов изменений, основываясь, как и стандартный на ФМ CHANGEDOCUMENT_*.
15:25, 05 февраля 2015

Виталий Ванин (Рейтинг: 541)

Спасибо, Николай!
Очень полезная информация.
00:59, 10 февраля 2015

Александр Дублин (Рейтинг: 13408)

Николай, а нет ли желания и возможности написать собственную статью?
Мы поможем.

Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП»