Программа сап что это инструкция

Содержание

» SAP ушел и не надо возвращаться!»: Немецкий разработчик промышленного ПО SAP заявил о полном прекращении своей работы в России и Беларуси

На днях прошла новость: “Немецкий разработчик промышленного программного обеспечения SAP заявил о полном прекращении своей работы в России и Беларуси”. Вот я и расскажу сегодня, как они пришли и почему уходят.

«SAP предоставит сотрудникам во всех подразделениях в России и Беларуси выходные пособия. Каждый сотрудник может подать заявку на позицию в подразделениях SAP за рубежом»,— рассказали в пресс-службе.

Офисы компании продолжат работать в странах СНГ: Армении, Азербайджане, Грузии, Казахстане, Кыргызстане, Узбекистане, Таджикистане и Туркменистане. Компании будут выделены как новый кластер в бизнес-единице SAP в Центральной и Восточной Европе. По всей видимости всем предложат релокироваться из России или увольняться. Так сделали другие вендоры.

О приостановке своей деятельности в России SAP заявил в начале марта в связи с началом военной операции на Украине 24 февраля. В заявлении гендиректора SAP SE Кристиана Кляйна было сказано, что компания останавливает бизнес, продажи услуг и продуктов. Компания была одним из крупнейших поставщиков промышленного специализированного софта на российском рынке (с долей около 60%). Из финансовой отчетности SAP СНГ следует, что выручка компании в регионе в 2020 году составила около 35,8 млрд руб.

Урок 1. SAP Buisness one: Интерфейс системы

Немного дополню от себя: при том, что САП занимала примерно 60 % от софта для управленческого учета в России, про нее мало кто знает. Все знают 1С. А про ее немецкий аналог для крупных предприятий знает гораздо меньше народу. А все потому, что многие пользовались 1С-кой за которую платить очень немного. А вот за САП надо платить очень много.

И не платить не сможешь. Но САП внедрен практически на всех крупных предприятиях России.

Газпром, РЖД, Роснефть, ЛУК-ойл, Сбербанк и далее по списку. Как же так получилось?

Конечно, началось все (вы не поверите) с Ельцина с Горбачевым, которые сдали нашу страну на откуп западным капиталистам. Это был полный слив, потому что мы согласились принять правила игры западного мира. Это вылилось в то, что наши новые предприятий выходили неподготовленными новичками против монстров западного капиталистического мира. А это все равно, что мне выходить на ринг против чемпиона мира. Буду избит.

Собственно ровно то же самое случилось и в России на рынке приложений для управленческого учета. Пока в 90-е и начале 2000-х 1С почистила рынок для мелких и средних компаний, крупные компании методично окучивали немецкая SAP и американская Oracle с их Oracle EBS.

С 1С иностранцам было сложно конкурировать, потому что, она обходилась всем практически за копейки. Любое иностранное приложение обходилось заметно дороже. Да и 1С на самом деле сильный продукт (не могу это отрицать, хотя они всегда по сути были конкурирующим приложением).

Справедливости ради, кроме 1С в 90-е и начале 2000- были сотни приложений для учета бухгалтерии и отдела кадров. Но по сути победила 1С. 1С смогли создать коробочное решение, которое было легко распространять и создали сеть партеров, которые поддерживали это приложение.

САП для начинающих. Автоматическое назначение ролей полномочий в SAP

Я с 2001 года работал в одной из таких компаний новосибирской Алекте. Компания на днях отпраздновала 30-тилетие. И у нее был продукт Нордис/2. Правда мы были скорее не конкурентами 1С а конкурентами САП. Потому что наша система изначально была создана на базе Покачевского УТТ в 1992-е году.

Поскольку внедрение прошло относительно успешно, компании давали новые проекты в ЛУКойле. И к моменту моего прихода в Алекту, это уже был полноценный программный комплекс, который покрывал кадровый учет, ОТИЗ, складской учет, бухгалтерский учет и выпуск на линию автотранспорта. То есть, абсолютно готовый продукт.

С 2002 года шло объединение систем учета на разные предприятиях в единую систему с хождением документов между предприятием (накладные по учету материалов, основных средств, etc).

В 2003 году уже внедряли первые версии налогового учета.

Году так в 2004 (за давностью уже могу немного спутать) была реализована репликация итогов по всем предприятиям в единую корпоративную базу данных. Аналог по сути BI системы.

В общем, проекты по внедрению шли один за одним. ПРосто для понимания объема: внедрение системы на предприятии в 1000-3000 сотрудников проходила за 42 дня на тираже. Для САПа такие сроки выглядят просто немыслимыми. Отдельный проект внедрения на одном из предприятий я реализовал в качестве руководителя проекта за 50 дней (мы еще оборот за 5 месяцев внесли).

Вместе с обследованием и ТЗ от первой поездки на предприятие до закрытия баланса в новой системе ушло 4 месяцев. И это крупное перерабатывающее предприятие.

Спустя много лет, проработав на различных предприятиях в качестве исполнителя и заказчика, могу трезво оценивать что наша Новосибирская команда была очень сильной. В общем то, Новосибирский Академгородок неплохое место, для создания такой команды. В компании было немало кандидатов и докторов наук, включая и руководителя компании Александра Евгеньевича Жижина). Сама компания была одним из организаторов Новосибирского технопарка, который сейчас является филиалом Сколково. На пике в компании работало более 300 сотрудников.

Был накоплен колоссальный опыт, так называемый набор компетенций в одном месте. Работая на внедрении, по любому вопросу я мог обратится в Новосибирск, и мне могли дать профессиональный и компетентный ответ. Если же сразу ответ не давался (вопрос возникал впервые), то мне его давали через какое то время. В САПе редко знаешь кто тебе может помочь. Да и то, не факт что поможет.

Вернее помочь желающих много. Но задорого.

Понятно, что такой подход в Новосибирске можно было реализовать, так как и разработчики и аналитики и группа разработки моделей учета и группа информационного обеспечения находилась в одной компании. Спустя годы, могу констатировать, что команда была на самом деле высокопрофессиональная, а руководство построило компанию для внедрения подобных проектов достаточно компетентно.

И тут приходим к самому интересному, ради чего в общем то и начал писать сегодняшнюю статью.

В годах могу ошибаться, но примерно года так с 1996 САП приходит в ЛУК-ойл. Если Алекта внедряла на северах, то САП зашел в головное предприятие. Лет так 10 пытались запилить САП на головное предприятие в НК ЛУК-ойл. Так как в проекте не участвовал, не могу сказать, о том как шел проект. Поскольку мы понимали, что это наш прямой конкурент, то постоянно мандражировали.

Но проект САП шел слишком неуспешно, мы же к 2005-му году успели окучить всю западную сибирь (Лангепас, УРай, Когалым, (три буквы из названий ЛУК-ойла), Покачи, Ямал, Нарьян мар, Усинск, Калининград, Нижневолжскнефть (КОтово, Жирновск, Астрахань). Никого вроде не забыл. Все работало как часы. Да можно было искать изъяны в системе. И они были.

Но все разделы учета были реализованы, отчетность, гибкие инструменты для учета. Шли разговоры про начало внедрения системы в другой крупной российской компании из списка форбс (ТОП10 крупнейших российских компаний).

Наши сотрудники вроде как начали летать в Пермь, но вот тут и подкрался облом. По всей видимости САП в Москве допилили. Как там между собой проекты поделились я не знаю, но внедряла САП в ЛУК-ойле уже команда из Перми. Как минимум первое время. И вскоре начался уже тираж САПа по ЛУК-ойлу.

Вместо нашего замечательного российского Нордиса внедряли САП.

Понятное дело, что нам объемы стали сокращать. В свою очередь Алекта стала сокращать сотрудников. В 2010 году я ушел из компании по собственному желанию (до этого год перерыва был в БДО)..

Если смотреть трезво спустя много лет, то САП приходил в ЛУК-ойл с гораздо более слабым функционалом. Нордис создавался в ЛУКойле и для ЛУКойла. В России и под российский учет. А САП создавался в Германии под особенности учета в разных странах. Локализация САП в России в 90-е в начале 2000-х не была качественной.

Не был реализован учет спецодежды и выпуск на линию.

Когда уже в 2020 — м году я обратился в САП СНГ с просьбой продемонстрировать работу модуля для учета спецодежды, мне сказали, что у них нет такого модуля. Да какие то партнеры делали собственные разработки, вроде как на учете основных средств. Кто — то использует 1С только для учета СО.

В частности, сейчас уже не помню название, но какая то компания, партнер 1С, нам готова была внедрить модуль для учета СО. И говорили, что у них много проектов интеграции с САП. Для понимания сути проблемы: в своей первой командировке в 2001 году я занимался именно спецодеждой. Это в общем то, такой раздел учета, который в бухгалтерии достается наименее опытному бухгалтеру обычно.

У нас тоже. Что из себя представлял САП в начале 2000-х, я думаю понятно.

ПРи этом у САПа есть родовая травма: для российского учета нет двойной записи. Поэтому например модуль главной книги все-таки это пляски с бубном.

При этом, пока САП доделывали в головном ЛУКойле, ходили слухи, что потратили несколько сотен миллионов долларов на него. Не знаю насколько прадва. Но если просмотреть резюме любого САП консультанта в Москве в конце 2000-х, то там практически гарантированно был проект ЛУКойла. Думаю понятно, что это не дешево все было. SAP 2000-х годов был страшным франкенштейном, практически без страновой локализации и опыта его внедрения вендорами местными.

Любое внедрение САП в ЛУКойле было гораздо дольше, чем внедряли мы, зарплаты консультантов выше, лицензии дороже.

Так как у них не было учета Спецодежды, учет вели в Нордисе, а я летал например, внедрять интерфейс передачи данных между САП и Нордис. И было забавно наблюдать, как наш руководитель направления по СО общался с их руководителем. Это были специалисты из разных лиг просто.

То есть, ЛУК-Ойл выбрав иностранный продукт потерял в качестве, заплатил за него дороже, но тем не менее, платил и каялся. А чем был обусловлен такой выбор?

В начале 2000-х всем российским компаниям зачем то надо было выходить на IPO. Об этом говорили все иностранные консультанты и аудиторы. Ну как же, ведь на IPO можно получить дополнительное финансирование для своих проектов. Все просто: продаешь часть компании, и оцениваешь свою компанию в миллиарды долларов.

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

А теперь следим за руками: Запад в лице ФРС печатал (Очень внимательно: ПЕЧАТАЛ а не создавал активы) бумаги. За которые получал реальные активы созданные в Советском союзе гражданами Советского Союза.

По этим бумагам создавался колониальный налог, в виде дивидендов. То есть, по сути колониальный налог папуасов за бусы. Нам как стране дали бусы, и еще заставили платить за эти бусы.

А теперь вернемся к самому началу: это все происходило ровно потому что, мы сдали страну. Сдал Горбачев и Ельцин. Мы сели играть с шулерами за один стол, где правила определяет главный шуллер в том момент, когда ему выгодно принять то или иное решение.

Кроме колониального налога на бусы запад стал получать и мелкие плюшки, в виде пропихивания своих продуктов на рынок папуасов. В частности внедрять САП на всех крупнейших российских. Да это гешефт заметно поменьше, но то же неплохо. А как пропихнуть западный продукт на российский рынок? Да очень просто!

Для выхода на IPO у тебя должна быть современная западная система учета. То есть САП или Оракл EBS. Оракл по сути еще больше гавно чем САП. Локализацию в России полноценную так и не смогли создать, поэтому, насколько помню, в России он практически не прижился.

ПРи чем тут рука руку моет. Для выхода на IPO Вам надо, чтоб у Вас провели аудит иностранные компании из BIG4. Которые в свою очередь говорят, что у вас российское приложение, а значит фу-фу-фу. Никакое IPO Вам не светит. Западные инвесторы читают отчеты, и если Вы все-таки вышли на IPO, но у Вас не западная система — то аудиторы пишут там про такой косяк.

И Ваши акции стоят дешевле.

ПРи чем это вся система так заточена. Если кто — то умный начинает идти против системы, то вдруг неожиданно он становится нерукопожатным на Западе. аудиторы его компаниям начинают ставить плохие оценки. Инвесторы, которые читают аналитику от аудиторов из большой четверки, узнают что нельзя инвестировать в эту компанию.

Или например накладывают на какую то компанию санкции. И если кто — то ослушается, то его отлучают от рынка США. Самого большого и денежного по факту.

То есть, вся система заточена на то, чтоб в ней мог выжить САП и не выжил Новосибирский Нордис из Сибири. Он и не выжил. Компания в общем то до сих пор существует. Тут Нордис в общем то как небольшое недоразумение, которое должно было пострадать от открытия нашего рынка западным компаниям.

Точно то же самое произошло с производителями российского оборудования и программных комплексов для геологии (ну где я знаю) и многое другое.

То есть, когда мы согласились жить по правилам западного мира — по сути мы согласились выйти десятилетним ребенком против чемпиона мира на ринг. И были естественно биты и жестоко. Удивительно, но чуть страна после такого не развалилась. Вернее развалилась сначала на 15 стран, а потом еще и Россия чуть не развалилась на еще несколько.

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

Вообще данную публикацию решил сделать, после спора в комментариях. насчет САПа от MikeG из США:

Вообще то выходят на IPO, для того, чтобы получить капитал для развития. А иначе зачем вам туду выходить. Вас же не заставляют.

Согласитесь, достаточно здравый комментарий в рамках логики западного мира. Надо отдать часть реальных активов чтоб получить бумаги. Чтобы понять абсурдность такого заявления давайте попробуем в другую сторону попробовать?

Мы печатаем 2 трлн рублей и покупаем на них General Electric. А чтоб внедрить в GE Нордис, американцы покупают у нас рубли за доллары и платят нам рубли. Вы скажете что американцы так делать не будут и не делали, потому что им не выгодно. Они же не дураки. Правильно, дураки мы в такой ситуации.

Так и я соглашусь: американцам это не выгодно отдавать за напечатанные рубли реальную компанию General Electric.

А вот в обратную сторону, когда мы отдаем часть компании за доллары — это значит выгодно. Логика действий в общем то достаточно прозрачная. Но почему то даже грамотные люди вроде “MikeG” с настолько с зашоренными глазами, им столько говна экономиксов влили в различных MBA, что взять и развернуть ситуацию они не могут.

Почему это нам выгодно отдавать часть компании за доллары, а им не выгодно за рубли? А потому что они правила эти написали, которые выгодны им, и не выгодны нам. Вот это я и называю колониальной системой.

Текущая финансовая система выгодна бенефициарам этой системы, то есть в основном англосаксам.

Еще процитирую MikeG:

Имею слишком много знакомых и на самом верху российской «элиты». Знаком более 30-45 лет, с 4-мя миллиардерами и одним министром — лично, на уровне разговоров на «ты» в «курилке».Более того, я ЛИЧНО консультировал по некоторым вопросам бизнеса, Газпром, еще в начале 2000 тысячных.

То есть, обратите внимание, в текущем мироустройстве, если у тебя взгляды отличаются от тех, которые нужны ведущим бенефициарам этой системы, то тебе их прочистят такие, как MikeG. думаю он даже делает это неосознанно. Пользуясь тем, что образованный и грамотный человек, и в личном разговоре большинству людей будет практически невозможно спорить с ним или сомневаться в правильности всех этих понятий.

Подробно про SAP ALE

SAP ALE — Application Link Enabling — технология обмена данными, разработанная компанией SAP AG. Технология, потому что это набор инструментов, протоколов, форматов, которые позволяют обмениваться данными в режиме реального времени или оффлайн режиме между САП и не-САП системами. Это огромный пласт настроек, функциональности и возможностей, которыми мы редко пользуемся. Предлагаю рассмотреть технологию комплексно в виде стека.

CPIC — Common Programming Interface for Communication — низкоуровневый коммуникационный протокол. Почитать можно вот тут https://www-01.ibm.com/software/network/commserver/windows/library/cpic.htm
RFC — Remote Function Call — высокоуровневый коммуникационный протокол удаленного вызова
tRFC (tansactional RFC) / qRFC (queued RFC) / aRFC (asynchronous RFC) / sRFC (synchronous RFC) — способ доставки сообщения до получателя и подверждения факта доставки
IDOC — Intermediate DOCument / BAPI (Business Application Programming Interface) — формат сообщения, которое будет доставлено
EDI — Electronic Data Interchange — процедура обмена данными SAP-nonSAP. Международные стандарт по-совместительству.
ALE — Application Link Enabling — процедура обмена данными SAP-SAP.

Вот это и предлагаю обсудить, а спецам меня поправить.
RFC — Remote Function Call, механизм для удаленного вызова функций в системах. Идея простая и заключается в том, что, если мы знаем имя какой-то функции на удаленном сервере, то мы можем сказать: «Привет, удаленный сервер. Я знаю, что у тебя есть вот такая функция, с такими параметрами. Я хочу ее запустить _у тебя_.

Вот мои полномочия, вот мои данные для этой функциий, запусти и скажи, что получилось». Удаленный сервер чешет черепушку, шуршит дисками и, удостоверившись, что это не Баба-Яга, запускает у себя, на своих данных эту функцию под логином просящего. При этом программа на том же сервере может запустить эту же самую функцию локально, как бы у себя дома. Наличие галочки в транзакции SE37 для функционального модуля определяет, можно ли запускать эту функцию удаленно или нет.

RFC сам по себе это протокол, которым пользуются компоненты и сервера SAP для общения друг с другом. У вендора есть RFC SDK, который можно скачать и использовать в своих разработках.

Если присмотреться к стандартными соединениям в транзакции SM59, то можно увидеть, что многие коммуникации идут через RFC и так называемые зарегистрированные программы, например, печать документов, Adobe Lifecycle Designer, SAP GUI и другие. Идея в том, что мы на сервере можем повесить обработчик на RFC вызовы таким образом, что он будет срабатывать при обращении к системе и выполнять полезные нам функции. Я такой обработчик использовал для связи сервера по обработке временных отметок с SAP, когда SAP вызывал через ALE программу (в SM59 была зарегистрированна программа, а не адрес сервера), а программа по своему протоколу связывалась с сервером обработки отпечатков пальцев и просила его выслать данные. Так что, если у вас есть свой станок, а вы хотите прицепить его к SAP, то пишите свой драйвер, драйвер регистрируете как RFC совместимый в SAP, а потом при формировании товарной накладной через поток операций вызываете печать медальки на станке. Это и есть тот самый IoT, от которого сейчас все прутся (после биткоинов).

Допустим мы определили что вызывать: программу или функциональный модуль. Теперь нужно решить как ее вызывать: транзакционно, синхронно, асинхронно, в очереди.

sRFC (synchronous RFC) — синхронный вызов. Вызвал, система тут же бросается к удаленной системе. Если та недоступна, то немедленно возвращается ошибки.
tRFC (tansactional RFC) — транзакционный вызов. Вызвал, система побежала пытаться достучаться. Если удаленная система в запое, то запрос на вызов откладывается в ящик, который называется LUW (Logical Unit of Work). Такие ящички копятся-копятся, а потом как партнер очнется, то контейнером заезжают в него. При этом нет никакой трезвой связи кто за кем должен заезжать, ибо работают как на Почте России — все в кучу. Единственное, что гарантируется, что внутри одного ящика все вызовы будут выполнены последовательно либо не выполнены вообще. Мониторинг осуществляется в транзакции SM58
aRFC (asynchronous RFC) — улучшенный вариант Почты России, практически такой же tRFC. Появляется больше общения, так как система теперь не будет складировать вызовы в ящики, а либо сразу пошлет в лес, либо при доступном партнере отправит ему вызов. Чем это отличается от sRFC? Тем, что sRFC вызов обязательно дождется ответа удаленного сервера прежде чем перейдет на следующую строчку кода. aRFC отправит вызов и пойдет дальше. Вызов может случиться, а может не случиться.
qRFC (queued RFC) — продвинутый вариант tRFC с тем отличием, что последовательность ящиков LUW соблюдается один в один. Таким образом гарантируется минимальная целостность и доставка сообщений до адресата. Мониторинг осуществляется в транзакциях SMQ(1,2,S,R)

Зачем я все это вам пишу? Чтобы HR консультант понимал начинку того, что он настраивает, как он и что он должен написать в спеке программисту, ибо порядок обработки данных во внешних системах это бизнес-требование.

Поехали дальше. IDOC это структура данных, которая может быть представлена в виде плоского файла, XML, CSV, JSON, котика или любого другого формата. Структура состоит из трех частей:

Контрольная/управляющая запись.
Сегменты данных.
Статус документа.

Как у нас концептуально происходит процедура обмена информацией между системами? По событию или расписанию запускается программа выгрузки данных по HR (для примера). Либо по указателям изменений, либо вручную через PFAL вызывается функциональный модуль, который создает IDOC — на основании селекционного экрана, выбранных данных собирает все и заполняет все структуры IDOC.

Дальше система смотрит на модель распределения в BD64. У каждого IDOC есть свой тип сообщения, который мы указываем в модели распределения по принципу:

система отправитель — система получатель — тип сообщения — фильтры. Если все условия совпали, то IDOC помещается в очередь на отправку в указанную систему. Причем система это не всегда SAP, а виртуальный контейнер — логическая система, под которой может быть SAP, котик, Share Point или еще что угодно.

Согласно настройке партнера (об этом позже) уже на входящей стороне система определяет какой же функциональный модуль вызвать для обратного преобразования из IDOC в живые данные. Этот обработчик получает на вход IDOC и создает из них данные (где с помощью других функциональных модулей, а где напрямую — зависит от логики и данных).

Если идет удаленный вызов BAPI, то система также по модели распределения ищет кому приписан такой BAPI вызов, а затем осуществляет qRFC вызов или sRFC. Так, например, работает проверка FICO параметров при проводках в заработной плате.

Это очень упрощенно. Отдохнули?

Теперь возьмем скальпель.

IDOC — сегмент — поле, такова структура IDOC. Сам IDOC определяется типом сообщения (HRMD_A, транзакция WE81). Тип сообщения в зависимости от версии системы ссылается на тип IDOC (транзакция WE82).

Тип IDOC состоит из двух частей (транзакция WE30):

Базовый тип. Базовый тип это то, что поставил САП в своем решении. Как правило базовый тип уже содержит все необходимые поля для передачи данных. Если же вам чего-то не хватает, то можно выбрать уже существующий сегмент из другого типа IDOC, либо создать расширение
Расширение оно и в Африке расширение. САП же интернациональный. С помощью транзакции WE31 создаем новый сегмент, а в WE30 прописываем его как расширение к базовому типу. Останется прописать это расширение к типу сообщений HRMD_A в транзакции WE82

Рекламная пауза: создаем расширение IDOC:

Нужно не забыть наполнить этот сегмент данными. Это можно сделать с помощью user-exits или BAdI (смотрите в конце заметки). Нужно не забыть, что при нормальной передачи SAP — SAP данные в сегменте как записываются исходящей системой (один кусок кода), так и обрабатываются принимающей системой (второй кусок кода). Этот код нужно написать самим, а не дать угадывать системе. Для входящих айдоков нужно в транзакции WE57 указать, что IDOC был расширен на такой-то сегмент, поэтому его нужно обрабатывать тем же функциональным модулем (который в свою очередь расширен нижеукзанными user-exits или BAdI).

Допустим мы завершили наполнение IDOC данными. Умеем его наполнять, умеем распаковывать и создавать данные. Осталось самое простое — послать его куда подальше.

Для определения маршрута, куда бы его послать, существует несколько терминов, которые нужно понять, сосредоточить в едином поле и выразить в настройке. Это партнер, порт и модель распределения.

Партнер это отправитель или получатель (WE20). Порт — средство передачи IDOC (WE21). Модель распределения — маршрут, по которому система будет искать, как доставить сообщение от отправителя к получателю (BD64). Центр управления полетами — транзакция BD87.

Открываем WE21 для настройки портов. Здесь мы видим несколько вариантов, например, tRFC (отматываем повыше, чтобы вспомнить, о чем речь), File, XML HTTP, XML File, ABAP PI. По названиям несложно догадаться о форматах передачи данных. Для SAP-SAP мы выбираем tRFC и создаем новый порт. При создании система попросит RFC соединение — адрес, куда отправлять данные.

Как вы помните, tRFC работает поверх CPI-C, а это значит, что для передачи данных по нестандартным протоколам можно подключить свою библиотеку, зарегистрировать ее как RFC program в SM59, а здесь указать это соединение. В итоге получится порт с отправкой данных через вашу стороннюю библиотеку. Здесь же можно указать, что данные нужно обрабатывать по схеме qRFC с помощью галочки Queue Processing is supported.

Теперь создадим партнеров. Партнер должен быть в исходящей системе для отправки данных и в принимающей для приема. В исходящей системе создаем в транзакции WE20 партнера с типом LS — логическая система. Отправка данных HR будет происходить от имени системы. Обратите внимание на то, что партнер — система приемник, а данные мы пишем в Исходящие.

Мы как бы говорим системе, что вот этому партнеру нужно отправлять данные. А для принимающей системы будет наоборот, что вот от этого партнера нужно принимать данные. Чтобы обеспечить целостность в наименовании систем были придуманы так называемые логические системы, которые должны быть уникальны во всем ландшафте ИТ систем, которые интегрируются с САП. Это обязательное требование вендора.

Также создадим партнера в принимающей системе. Только теперь указываем Inbound параметр.

Осталось указать маршрут.
Открываем транзакцию BD64 в исходящей системе и создаем вот такую схему для отправки данных из системы ER1 манданта 100 в ER1 мандант 200.

Если после сохранения и попытки распределения (Edit — Model View — Distribute) система вас отругает, то пугаться не стоит. Распределение модели это тоже передача IDOC. Нужно создать партнера для этого.

Открываем транзакцию PFAL и пробуем отправить. Вроде все проходит без ошибок. Так как мы в настройке порта указали, что отправка идет через формирование очереди (то есть не сразу отправляется, а по расписанию), то смотрим в BD87 наш IDOC. Выбираем его и нажимаем кнопку Process для отправки. Все улетело.

А вот во входящей системе в BD87 нас ждет ошибка.

Все дело в том, что я в системе приемнике в данных партнера указал код обработки APLI Inbound IDoc: Individual Processing. А этот код применим для типовых IDOC, но не работает для HR. Для нас есть отдельный HRMD. Код обработки нужны для того, чтобы система могла понять, как обрабатывать входящий IDOC. На один и тот же тип IDOC может быть несколько разных кодов с разной логикой обработки.

Например, одни сегменты обрабатывать в единичном случае так, а при пакетном вводе иначе. Меняем в партнере код обработки на HRMD и заново запускаем обработку IDOC уже в системе получателе. Заново отправлять данные не нужно.

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

Описание статусов IDOC можно посмотреть в таблице TEDS1.

В следующие разы мы поговорим о сериализации, фильтрации, конвертации IDOC. Что-то я уже рассказывал, поэтому обобщим и сведем воеидино.

Репост, лайки, шары, решары, донаты и печеньки очень приветствуются. Вам не сложно, а мне приятно

P.S. Принимаются заявки на новые темы

Полезные user-exits и BAdI

•EXIT_SAPLRHA0_001: HR-CA: ALE Outbound Processing With Receiver Enhancement
•EXIT_SAPLRHA0_002: HR-CA: Export Parameters for ALE Inbound Processing IDOC_INPUT_HRMD
•EXIT_SAPLRHA0_003: HR-CA: Import Parameters for ALE Inbound Processing IDOC_INPUT_HRMD
•EXIT_SAPLRHA0_004: HR-CA: ALE Outbound Processing: Control Record
•EXIT_SAPLRHA0_005: HR-CA: ALE Inbound Processing: Check Object
•EXIT_SAPLRHA0_006: HR-CA: ALE Outbound Processing: Check Object
•EXIT_SAPLRHAL_001: HR-CA: ALE Outbound Processing: Change IDoc
•EXIT_SAPLRHAL_002: HR-CA: ALE Inbound Processing: Change Infotype Data
•EXIT_SAPLRHAL_003: HR-CA: ALE Outbound Processing: Convert Infotype / Segment
•EXIT_SAPLRHAL_004: HR-CA: ALE Inbound Processing: Convert Segment / Infotype

BAdI: Inbound Processing for HR Master Data

Business Add-In in inbound processing for HR master data (used in the function module IDOC_INPUT_HRMD).

BAdI: Check/Additional Processing of Object in Inbound Proce

The CHECK_OBJECT method of this Business Add-In enables checks to be performed for an HR object in the RH_IDOC_OBJECTS_SAVE inbound function module. The method is accessed after customer exit SAPLRHA0_005.

BAdI: Customer-Defined Inbound Processing

SAP-internal inbound processing for HR master data:

The system determines which HR objects should be removed from standard processing because no data structures exist for them in the receiving system. Irrespective of the type of receiving system, you can further process these HR objects.

BAdI: Fine Tuning of Original System Mechanism

Business Add-In for Original System Mechanism

BAdI: Outbound Processing HR Master Data

Business Add-In in output processing for HR Master Data (used in the function module RH_MASTER_IDOC_DISTRIBUTE_HRMD).

» SAP ушел и не надо возвращаться!»: Немецкий разработчик промышленного ПО SAP заявил о полном прекращении своей работы в России и Беларуси

Подробно про SAP ALE

Похожие заметки:

Для чего нужна программа компилятор

Программа смешанное белье для чего

Токси риск программа для чего

Программа аршин метрология для чего

Программа чек пфр для чего

Для чего предназначена программа стили

Для чего нужна программа тренажер

Для чего нужна программа apkpure