sap edi что это

Подробно про 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 для функционального модуля определяет, можно ли запускать эту функцию удаленно или нет.

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

Зачем я все это вам пишу? Чтобы 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:

Нужно не забыть наполнить этот сегмент данными. Это можно сделать с помощью 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).

Источник

Электронный обмен данными

Электронный обмен данными

Компании тесно взаимодействуют со своими клиентами и производителями. Для многих крупных компаний эти отношения влекут за собой непосредственную связь между их компьютерными системами. Electronic Data Interchange (EDI) это система, предназначенная для автоматической передачи бизнес-документов. EDI также можно рассматривать в качестве BPR (Business Process Reengineering) для процессов внутри компании. В отличие от традиционных BPR, такой обмен не ограничивается одной компанией, а распространен за ее пределы. С этой точки зрения, помимо сокращения объема работ по внутренней и внешней обработке сообщений, перепроектирование процессов внутри компании путем внедрения EDI существенно уменьшает время ожидания, снижающее ценность.

Архитектура EDI

Электронный обмен данными (EDI) состоит из приложения, поддерживаемого EDI, интерфейса IDoc и подсистемы EDI. Приложение, поддерживаемое EDI, способно обрабатывать бизнес-операции, полученные через EDI, подобно SAP R/3. Интерфейс IDoc соединяет приложения и подсистему EDI. Подсистема EDI конвертирует сообщения EDI с международных стандартов (EDIFACT или Х.12) в IDoc и наоборот, и передает их обычно через сеть VAN. Подсистема EDI, имеющая трехчастную структуру, также выполняет множество других функций, среди которых:

• Передача и получение сообщений EDI

• Проверка статуса и составление отчетов

• Подтверждение доставки и функциональное подтверждение

• Повторная передача в случае помех

• Присвоение сообщений EDI IDoc и наоборот

• Перевод сообщений EDI в IDoc и наоборот

• Специфическая обработка в зависимости от партнера

• Ведение профилей партнеров

• Обмен полученными IDoc с системой R/3.

Поток данных в исходящей обработке

Как говорилось в разделе посвященном ALE, коммуникация IDoc у ALE и EDI довольно схожа. Сценарий отправки сообщения EDI через интерфейс IDoc включает следующие шаги (см. рис. 19.6):

1. Подключение интерфейса IDoc к подсистеме EDI.

2. Определение порта

3. Подготовка профиля партнера

4. Если это логистическое приложение, то по умолчанию источником сообщения будет либо модуль приложения, либо Контроль сообщений (Message Control). В последнем случае все параметры Контроля сообщений должны быть определены.

5. Настройка расписания программы RSNAST00.

6. После того, как сформируется новый заказ на поставку (Purchase Order, PO), он будет внесен в расписание коммуникаций, зависящий от настроек Контроля сообщений (Message Control).

7. Запуск программы RASNASTED для подготовки сообщения EDI.

8. RASNASTED считывает профиль партнера, определяет код обработки, связывается с модулем выбора приложения и выбирает запись для создания IDoc.

9. IDoc теперь расположен в базе данных SAP; в зависимости от выбранного режима вывода, IDoc записывается, один или вместе с другими, в файл, который заранее был определен при выборе порта.

10. В зависимости от выбранного режима вывода в профиле партнера, IDoc отсылается.

11. Используя номер IDoc в качестве идентификатора, система EDI посылает соответствующие сообщения о получении в интерфейс IDoc.

Рис. 19.6. Поток данных в исходящей обработке.

Читайте также

Электронный кошелёк

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

Обмен данными между гостевой и хостовой ОС

Обмен данными между гостевой и хостовой ОС Virtual PC предоставляет пользователю несколько способов обмена данными между гостевой и хостовой ОС. Один из них — применение разделяемых папок — был рассмотрен ранее. В этом подразделе рассказано, как осуществить оперативный

Обмен данными между гостевой и хостовой ОС

Обмен данными между гостевой и хостовой ОС По умолчанию любая вновь созданная ВМ способна обмениваться данными с хостовой ОС через буфер обмена. Правда, в отличие от Virtual PC, передавать в обоих направлениях можно лишь текст. Графические данные «обмену и возврату не

Обмен данными между гостевой и хостовой ОС

Обмен данными между гостевой и хостовой ОС Parallels Workstation предоставляет пользователю два способа обмена данными между гостевой и хостовой ОС: передача данных через буфер обмена и пересылка данных по локальной сети. В качестве дополнительного «однонаправленного» метода

Электронный адрес

Электронный адрес Рассмотрим поподробнее адрес из нашего примера: vasiliy@pupkin.ru. Он состоит из домена почтового сервера (в данном случае это pupkin.ru) и имени адресата (vasiliy). Имя адресата не обязательно должно совпадать с вашим собственным – это любое понравившееся вам

5.4. Обмен данными между приложениями Microsoft Office

5.4. Обмен данными между приложениями Microsoft Office Пакет Microsoft Office предлагает пользователям различные средства обмена между приложениями. Такие инструменты следует использовать, когда необходимо создать документ, в котором будут размещены элементы разных приложений Microsoft

7.2.6. Равноправный межпроцессный обмен данными

7.2.6. Равноправный межпроцессный обмен данными Все рассмотренные выше методы обмена данными имеют некоторую неявную иерархию, в которой одна программа фактически контролирует или управляет другой, а в противоположном направлении сведения обратной связи не передаются

7.2.6. Равноправный межпроцессный обмен данными

7.2.6. Равноправный межпроцессный обмен данными Все рассмотренные выше методы обмена данными имеют некоторую неявную иерархию, в которой одна программа фактически контролирует или управляет другой, а в противоположном направлении сведения обратной связи не передаются

Глава 8 Обмен данными между приложениями

Глава 8 Обмен данными между приложениями • СообщениеWM_COPYDATA• Использованиебуфераобмена• ПроецируемыевпамятьфайлыОрганизация обмена данными между приложениями, а именно между процессами этих приложений, является достаточно трудоемкой задачей. Архитектура Win32

11.2. Простой обмен данными

11.2. Простой обмен данными В начале работы с описанными в предыдущем разделе компонентами IdTCPServer и IdTCPChent рассмотрим создание несложного клиент-серверного приложения, клиентская и серверная части которого выполняют следующие функции.• Клиентское приложение соединяется

Обмен данными и проекты интеграции

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

4.4. Обмен данными между приложениями Microsoft Office

4.4. Обмен данными между приложениями Microsoft Office Пакет Microsoft Office предлагает пользователям целый ряд средств для организации обмена между приложениями. Эти инструменты следует использовать, когда необходимо создать документ, в котором будут размещены элементы разных

Электронный адрес

Электронный адрес Электронный адрес имеет вид: Ваше_Красивое_Имя@Адрес_Почтового_Сервера. То, что мы здесь обозначили как Ваше_Красивое_Имя, — в терминах интернет-технологий называется логин. Логин может состоять из букв латинского алфавита, цифр, точек, тире и символа

ЭЛЕКТРОННЫЙ КОШЕЛЁЧЕК

ЭЛЕКТРОННЫЙ КОШЕЛЁЧЕК Уже практически любой солидный человек пользуется различным интернет-банкингом, работает с так называемыми электронными деньгами (электронными платежными системами) и оплачивает в онлайне (то есть через Интернет) различные товары и услуги. И так

Электронный ключ защиты

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

Источник

Как это работает

Контур.EDI — это сервис для обмена электронными стандартизированными сообщениями и документами между поставщиками и заказчиками

Для чего нужен Контур.EDI?

Ускоряйте обработку заказов и подписание закрывающих документов

Увеличивайте оборот и быстрее получайте оплату за счет сокращения числа ошибок

Формируйте электронные юридически значимые документы

Экономьте на доставке, хранении и печати бумажных документов

Снижайте риск получить штраф от заказчика за недопоставку или поставку не в срок

Все партнеры — в одном сервисе

Торговые сети

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

Факторинговые компании

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

Несетевая розница

Загружайте прайс в сервис, чтобы вся несетевая розница региона видела ваши позиции. Сокращайте расходы на торговых представителей и получайте новых клиентов.

Производители

Получайте заказы от торговых сетей и дистрибьюторов и расширяйте каналы сбыта.

HoReCa

Поставляйте товары в кафе и рестораны, чтобы охватить новые сегменты рынка.

Собственные юрлица

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

Дистрибьюторы

Отправляйте заказы производителю и поставляйте товары заказчику в одном и том же сервисе

Поставщики услуг

Получайте закрывающие документы за услуги связи и ЖКХ.

Цепочка электронного взаимодействия

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

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

Как работает сервис

EDI (Electronic data interchange — электронный обмен данными) — стандартизированные форматы сообщений для передачи коммерческой информации между организациями.

GLN — это уникальные 13-значные числовые идентификаторы юридических лиц или их подразделений, они являются ссылочными ключами для извлечения из базы данных следующей информации:

Для получения GLN необходимо обратиться в «GS1». Наши менеджеры всегда готовы объяснить, как пройти процедуру получения, и помогут заполнить заявление.

PRICAT — ценовой лист, содержит информацию о перечне товаров с указанием цен, отправляется поставщиком.

ORDERS — заказ, формируется в учетной системе торговой сети, направляется EDI-сообщением и автоматически выгружается в учетную систему поставщика.

ORDRSP — подтверждение заказа, в ответ на заказ поставщик может направить EDI-сообщение ORDRSP, в котором уточнить фактурную часть и время поставки.

DESADV — уведомление об отгрузке, аналог товаросопроводительных документов (ТТН), передается в момент отгрузки и содержит актуальную информацию об отгрузке товара со склада поставщика.

ALCRPT — дополнительное сообщение по поставке алкопродукции, содержит информацию об алкогольной продукции, отправляется вместе с DESADV

RECADV — уведомление о приемке, содержит информацию о фактически принятом товаре (с указанием причины неприемки. Позволяет сразу после приемки сформировать корректный счет-фактуру).

В рамках действующего законодательства все виды EDI-сообщений не являются юридически значимыми.

Модули можно установить для следующих версий:

Также мы разработали принципиально новый универсальный модуль для 1С 7.7 — Custom Tools. Это настоящий конструктор, который адаптируется к различным конфигурациям учетной системы.

Для владельцев любых учетных систем (SAP, MS Dynamics, Oracle) предусмотрена простая интеграция через API.

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

Также всем клиентам доступна удобная и функциональная веб-версия.

Для работы в EDI.Контур подходят сертификаты квалифицированных электронных подписей любых Удостоверяющих центров.

Источник

Most Useful SAP EDI Transactions (SAP Idocs Tcodes) & SAP EDI Tables

SAP EDI Transactions: IDoc stands for intermediate document.

Idocs are a standard data structure for Electronic Data Interchange (EDI) between application and SAP System.

In this article, you will find the most important IDocs Tcodes and the most useful SAP Edi Tables to start you mastery journey with IDocs.

SAP EDI Transactions and SAP IDoc EDI Tables

Useful SAP IDocs Tables / SAP EDI Tables

List of Main tables for SAP IDocs EDI ALE:
Idoc’s header data is stored in the table EDIDC.

Status of IDocs can be found in EDIDS table.

Idoc’s data are in EDID4 table. The data are stored in SDATA field. To retrieve the data in the segment format, create a structure typed as the segment type and make a write/move SDATA field to your structure.

Useful SAP IDocs Tcodes / SAP EDI Transactions

Let’s first introduce the main edi transaction codes groups (or Menu)

Under the previous menu you can access edi transaction codes to handle everything for SAP EDI/IDOC.

The main List of main SAP Idocs / EDI Tcodes:

Inbound and Outbound Idocs Status

Outbound IDocs status

SAP IDocs are managed by Status. Here the List of Outbound IDocs status

Inbound IDocs status

Here the full List of Inbound IDocs status in SAP :

Источник