Выравниваем основные данные между SAP-системами
Если Вы внедряете систему «с нуля», то Вы можете создать некоторые основные данные в системе разработки задолго до того, как продуктивная система будет проинсталлирована как таковая. Эти объекты остаются более или менее стабильными на протяжении всего жизненного цикла системы. Я имею в виду счета главной книги, МВЗ, МВП, иногда внутренние заказы.
Некоторые настройки системы содержат в себе указанные основные данные, например настройка автоматических проводок не обойдется без создания счетов ГК. Это означает, что необходимо выравнивать основные данные между различными системами в ландшафте.
Данная статья написана Дмитрием Кагликом и впервые опубликована на сайте http://www.sapexpert.co.uk на английском языке. Если вы хотите узнавать больше от экспертов из мира SAP раньше других, то, пожалуйста, подпишитесь на обновления на указанном сайте.
Как SAP Expert писал ранее, системный ландшафт в SAP обычно содержит несколько систем. Как минимум, Вы должны иметь систему разработки, тестирования и продуктив.
Если Вы внедряете систему «с нуля», то Вы можете создать некоторые основные данные в системе разработки задолго до того, как продуктивная система будет проинсталлирована как таковая. Эти объекты остаются более или менее стабильными на протяжении всего жизненного цикла системы. Я имею в виду счета главной книги, МВЗ, МВП, иногда внутренние заказы.
Некоторые настройки системы содержат в себе указанные основные данные, например настройка автоматических проводок не обойдется без создания счетов ГК. Это означает, что необходимо выравнивать основные данные между различными системами в ландшафте.
Даже если Ваш проект не является проектом «с нуля», необходимо иметь одинаковые основные данные в разных системах. Например, это нужно для выполнения тестов в системе разработки или тестирования перед импортом транспорта в продуктив.
Как можно этого добиться?
Конечно же, можно назначить сотрудника компании на задачу отслеживания изменений и вручную проводить необходимые корректировки в системах. Конечно же, это далеко не выход!
SAP предлагает стандартные инструменты для этой задачи, а именно IDOC. Существую
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
ЗарегистрироватьсяУ вас уже есть учетная запись?
Войти
Обсуждения
1
Комментарий от
Артем Седловский
| 18 февраля 2014, 15:37
Совет 1. Считаю, что здесь вообще нет правильного решения - делать эталоном продуктивную систему или разработку. В каких-то случаях счет приходится изначально заводить в разработке, прописывать его в каких-то настройках (сажать записи в настроечных таблицах в ченьч реквест). Например, для нового банковского счета создаем три счета ГК, а потом используем эти ОЗ в настройках собственных банков. Нельзя создать сразу нормально ОЗ ОСч в продуктиве, потому что для ракурса БЕ в продуктиве не будет сразу настройки счета - ее все равно будем делать в системе DEV. А настройки собственных банков и счетов в них у нас дружат с электронной банковской выпиской. То есть, предложенная схема распределения основных данных из продуктива "назад" по ландшафту противоречит даже абзацу 3 самой статьи. Так что применять такое распределение следует крайне осторожно.
Совет 3. Из практики, стоит мониторить не только вход, но и выход Idoc из системы-отправителя. Это позволяет отлавливать некоторые ошибки. Также, на выходе обязательно надо мониторить LUW'ы через SM58. Оно особо важно, если одни и те же ОЗ меняются во времени. Мониторинг LUW'ов нужен, чтобы не перетереть свежие записи более старыми.
Совет 4. Если использовать какую-то систему за эталон, то не обязательно из одной системы распределять непосредственно в две другие. Я распределял на том же Литаско из разработки в тест и из теста продуктив именно из тех соображений, что из теста в продуктив идут уже оттестированные данные. Ни в коем случае не навязываю такой вариант, просто мой вариант изначально в статье не предлагается, но на практике имеет свои преимущества.