Меню

Выравниваем основные данные между SAP-системами

Если Вы внедряете систему «с нуля», то Вы можете создать некоторые основные данные в системе разработки задолго до того, как продуктивная система будет проинсталлирована как таковая. Эти объекты остаются более или менее стабильными на протяжении всего жизненного цикла системы. Я имею в виду счета главной книги, МВЗ, МВП, иногда внутренние заказы.

Некоторые настройки системы содержат в себе указанные основные данные, например настройка автоматических проводок не обойдется без создания счетов ГК. Это означает, что необходимо выравнивать основные данные между различными системами в ландшафте.

Данная статья написана Дмитрием Кагликом и впервые опубликована на сайте http://www.sapexpert.co.uk на английском языке. Если вы хотите узнавать больше от экспертов из мира SAP раньше других, то, пожалуйста, подпишитесь на обновления на указанном сайте.


Как SAP Expert писал ранее, системный ландшафт в SAP обычно содержит несколько систем. Как минимум, Вы должны иметь систему разработки, тестирования и продуктив.

Если Вы внедряете систему «с нуля», то Вы можете создать некоторые основные данные в системе разработки задолго до того, как продуктивная система будет проинсталлирована как таковая. Эти объекты остаются более или менее стабильными на протяжении всего жизненного цикла системы. Я имею в виду счета главной книги, МВЗ, МВП, иногда внутренние заказы.

Некоторые настройки системы содержат в себе указанные основные данные, например настройка автоматических проводок не обойдется без создания счетов ГК. Это означает, что необходимо выравнивать основные данные между различными системами в ландшафте.

Даже если Ваш проект не является проектом «с нуля», необходимо иметь одинаковые основные данные в разных системах. Например, это нужно для выполнения тестов в системе разработки или тестирования перед импортом транспорта в продуктив.

Как можно этого добиться?

Конечно же, можно назначить сотрудника компании на задачу отслеживания изменений и вручную проводить необходимые корректировки в системах. Конечно же, это далеко не выход!


SAP предлагает стандартные инструменты для этой задачи, а именно IDOC. Существую

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев1

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

Артем Седловский

  |  18 февраля 2014, 15:37

Дима, спасибо за статью. Я на эту тему в свое время готовил презентацию "ALE для консультанта-функциональщика" для стажеров, поэтому позволь поделиться моими сомнениями по поводу некоторых советов.
Совет 1. Считаю, что здесь вообще нет правильного решения - делать эталоном продуктивную систему или разработку. В каких-то случаях счет приходится изначально заводить в разработке, прописывать его в каких-то настройках (сажать записи в настроечных таблицах в ченьч реквест). Например, для нового банковского счета создаем три счета ГК, а потом используем эти ОЗ в настройках собственных банков. Нельзя создать сразу нормально ОЗ ОСч в продуктиве, потому что для ракурса БЕ в продуктиве не будет сразу настройки счета - ее все равно будем делать в системе DEV. А настройки собственных банков и счетов в них у нас дружат с электронной банковской выпиской. То есть, предложенная схема распределения основных данных из продуктива "назад" по ландшафту противоречит даже абзацу 3 самой статьи. Так что применять такое распределение следует крайне осторожно.
Совет 3. Из практики, стоит мониторить не только вход, но и выход Idoc из системы-отправителя. Это позволяет отлавливать некоторые ошибки. Также, на выходе обязательно надо мониторить LUW'ы через SM58. Оно особо важно, если одни и те же ОЗ меняются во времени. Мониторинг LUW'ов нужен, чтобы не перетереть свежие записи более старыми.
Совет 4. Если использовать какую-то систему за эталон, то не обязательно из одной системы распределять непосредственно в две другие. Я распределял на том же Литаско из разработки в тест и из теста продуктив именно из тех соображений, что из теста в продуктив идут уже оттестированные данные. Ни в коем случае не навязываю такой вариант, просто мой вариант изначально в статье не предлагается, но на практике имеет свои преимущества.