Часть 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 он зачастую совпадает с номером объекта, который меняется):

DATA:
    objectid TYPE cdhdr-objectid.

В нашем случае переменной objected назначим номер места потребления.

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

  DATA:

    line_premise_ext_new TYPE zisu_premise_ext, 
    line_premise_ext_old TYPE zisu_premise_ext.

Структура line_premise_ext_new будет хранить запись для вновь вставляемой строки(операция INSERT), а также для новой строки при модификации данных (операция UPDATE). Структура line_premise_ext_old будет хранить запись для удаляемой строки (операция DELETE), а также для старой строки при модификации данных (операция UPDATE).

Процедуры записи в таблицу документов изменений будут выглядеть следующим образом:

a)     Вставка новой строки:

      CALL FUNCTION 'Z_PREMISE_EXT_WRITE_DOCUMENT'