Кроме использования переносимых запросов на изменения, можно вносить локальные изменения. При таком типе изменений создаются локальные запросы на изменения. Подобные запросы не могут переноситься в другие системы. Запросы локальных изменений создаются в частности, когда конфигурация пути переноса еще не была создана или была создана неправильно. Если запросы изменения еще не были выпущены, можно присвоить их целевой системе и преобразовать их в запросы изменения, которые могут быть перенесены.
При назначении задачи в запросе на изменение, касающееся разработки, ПО одновременно служит обеспечением дополнительных мер безопасности. Данный объект блокируется для пользователей, не являющихся владельцами задачи и запроса на изменение, пока отвечающий за модификацию разработчик явно не передаст полномочия на эту задачу другому пользователю. Если проект разработки завершен, то сначала разблокируется задача, а затем запрос на изменение. Объект может быть изменен снова только после разблокирования запроса. Такой механизм предотвращает одновременное изменение одного и того же объекта несколькими пользователями.
Номер запроса
Все задачи и запросы имеют уникальный идентификатор, состоящий из трехсимвольного имени системы SAP R/3, идентификатора-ключа «К» и последовательного номера из 6 цифр, например «ЕА1К905975». Каждый запрос на изменение имеет одного только владельца — руководителя проекта, который отвечает за администрирование запроса. При необходимости владельца можно сменить. Запрос на изменение нередко состоит из нескольких задач, каждая из которых принадлежит одному пользователю. Запрос на изменение можно рассматривать как проект, в котором разные пользователи имеют разные задачи (см. рис. 6.4). Допускается передача задачи другому пользователю.
Завершение задач и запросов
Когда все задачи запроса изменения завершены и разблокированы, то проект можно закрыть и разблокировать сам запрос на изменение. Если этот запрос не является локальным, то, когда он будет разблокирован, будет происходить подготовка к переносу. Версия объектов, содержащихся в запросе, в момент разблокирования экспортируется в файлы на уровне операционной системы, а запрос помечается для импорта на целевой системе.
Импорт должен запускаться явно (см. раздел 6.3); во время экспорта импортируется версия объектов. То же самое применяется, даже если объекты системы источника были снова модифицированы — между разблокированием и импортом.

Рис. 6.4. Управление проектом
6.2.2. Редактирование запросов с помощью Transport Organizer (Организатора переноса)
До версии SAP R/3 4.6B запросы пользовательской настройки и к инструментальным средствам (Customizing и Workbench) обрабатывались отдельными инструментами: Customizing Organizer и Workbench Organizer. Начиная с SAP R/3 4.6C все запросы изменения и содержащиеся в них задачи можно редактировать с помощью Организатора переносов (ТО — Transport Organizer). Практический пример является простейшим способом иллюстрации работы с ТО.
В архивной области должны быть сгенерированы поддающиеся проверке архивные файлы. Для этого необходимо выполнить модификацию пользовательской настройки всех объектов архивации данных. Подобные модификации являются типичными для пользовательской настройки.
Создание запроса пользовательской настройки
Создать запрос пользовательской настройки можно двумя способами:
1. Внести изменение и позволить системе SAP R/3 сгенерировать запрос пользовательской настройки и задачу для изменения.
2. Использовать Организатор переносов (ТО) для создания запроса пользовательской настройки с включенной в него задачей. Затем внести изменение и явным образом назначить созданной ранее задаче.
Выбор процедуры зависит главным образом от принятой концепции пользователя. Назначая полномочия, можно запретить пользователям создавать собственные запросы на изменение. Эту задачу можно зарезервировать для выбранной группы пользователей. Преимущество подобной процедуры состоит в следующем: вы сохраняете контроль над запросами пользовательской настройки и назначением, а также для создания нового типа запроса на изменение можете переопределять права разработчика, например, разрешить ему вносить изменения только после создания и назначения соответствующих запросов на изменения уполномоченному лицу, такому как руководитель проекта. Это дает возможность более эффективно координировать разработку в системе SAPR/3 (cm. рис. 6.4).
Читать дальше