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

«Огра­ни­чи­ва­ем выбор метода вы­ра­вни­ва­ния в SAP Finance»
Олег Точенюк:
Читайте про что такое BTE и как с этим работать.
«Огра­ни­чи­ва­ем выбор метода вы­ра­вни­ва­ния в SAP Finance»
Каглик Дмитрий:
Андрей, может быть Вам еще (©) ключ от квартиры где деньги лежат?   Если серьезно, то если Вы не знаете что такое OpenFI и с чем его едят, значит остальная часть текста Вам не поможет. Этот...
«Проблемы внедрения па­ра­лле­льных оценок на базе EHP5»
Анвар Байгулов:
Добрый день, рисунки в браузере не показывает

База знаний

Вы можете подписаться на эту колонки этого автора, если авторизируетесь или зарегистрируетесь

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

02 декабря 2013, 15:28

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


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

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

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

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

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

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


SAP предлагает стандартные инструменты для этой задачи, а именно IDOC. Существую специальные типы IDOCов и даже стандартные транзакции для «распространения» счетов Главной Книги, МВЗ, МВП, внутренних заказов, банков, итд.

Вы можете найти эти транзакции по пути в стандартном SAP Easy Access menu: Tools – ALE – Master Data Distribution. Вот краткий список транзакций:

  • Банк – FI08
  • Счет Главной Книги – BD18
  • МВП – KE77
  • Группа МВП – KE79
  • МВЗ – BD16
  • Группа МВЗ – KAVB
  • Внутренний заказ – KOA1

В качестве предпосылки, Вы должны настроить систему ALE между системами. Как? Поговорите с Базисом или спросите SAP Expert!

Я же хочу дать Вам несколько дополнительных советов по использованию данных транзакций.

  1. Направление распространения основных данных зависит от стадии проекта. В ранних стадиях внедрения и тестирования, или в начале продуктивной эксплуатации, проще всего использовать систему Разработки в качестве эталона. Если же проект уже находится в «стабильном полете», все процессы отработаны, то продуктивная система должна стать эталоном.
  2. Вы можете запланировать работу транзакций в виде периодических задач. Это позволит выравнивать основные данные между системами в автоматическом режиме.
  3. Не забывайте, что обработка IDOC может закончиться с ошибкой, поэтому Вам необходимо наладить систему мониторинга IDOCов в системе-получателе, анализировать ошибки и пытаться их исправлять.
  4. Не забывайте, что Вам нужно распространять основные данные как минимум в 2 системы: разработка + тестирование, или тестирование + продуктив, в зависимости от того, какая система принята за эталон. Запланируйте каждую из транзакций дважды с указанием различных систем-получателей.
  5. Если Вы распространяете основные данные МВЗ или МВП, не забывайте также передавать данные стандартных иерархий. Технически стандартная иерархия – это тоже группа МВЗ или МВП. Используйте соответствующие транзакции.
  6. Запланируйте передачу данных по МВП до отправления данных МВЗ для избежания ошибок, вызванных отсутствием связанных объектов.

Вы хотите узнать больше про выравнивание основных данных в SAP-системах Спросите SAP Expert!

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

Артем Седловский (Рейтинг: 223) 15:37, 18 февраля 2014

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