ALE, EDI & IDocs Введення та відмінності: SAP Підручник

Що таке EDI?

EDI (або електронний обмін даними) – це електронний обмін структурованими бізнес-даними між різними програмами. Замовлення на купівлю, оформлене в одній компанії, може таким чином надійти до системи постачальника як замовлення на продаж, без необхідності його повторного введення.

Еді Archiтектура

Як показано на діаграмі вище, EDI ArchiТекстура складається з трьох шарів –

1. Програми з підтримкою EDIВони підтримують автоматичну обробку бізнес-транзакцій.
2. Інтерфейс IDoc: Це було розроблено як відкритий інтерфейс. Інтерфейс IDoc складається з типів IDoc і функціональних модулів, які формують інтерфейс програми.
3. Підсистема EDI: Це перетворює типи IDoc на типи повідомлень EDI і навпаки. Цей компонент архітектури EDI не надається SAP.

Переваги процесу EDI

• Зменшення кількості помилок при введенні даних
• Скорочений час циклу обробки
• Доступність даних в електронному вигляді
• Зменшення паперової роботи
• Зниження вартості
• Зменшення запасів та краще планування
• Стандартні засоби комунікації
• Кращі бізнес-процеси
• Конкурентну перевагу

Що таке ALE?

EDI охоплює зовнішні торгові партнери. ALE вирішує проблему дзеркала всередині підприємства, де кілька SAP системи повинні йти в ногу.

ALE підтримує розподіл бізнес-функцій і процесів між слабозв’язаними SAP Системи R/3 (різні версії SAP R/3). Підключення від R/2 і без SAP системи також підтримуються.

ALE підтримує-

• Розподіл програм між різними випусками систем R/3
• Продовження обміну даними після оновлення випуску без необхідності спеціального обслуговування
• Спеціальні розширення для клієнтів.
• Комунікаційні інтерфейси, які дозволяють підключатися до не-SAP систем.
• Сполучення систем R/3 і R/2.

Що таке IDOC?

Як ALE, так і EDI вимагають обміну даними, і обидва передають це завдання одному й тому ж об'єкту.

IDOC is просто контейнер даних використовується для обміну інформацією між будь-якими двома процесами, які можуть зрозуміти синтаксис і семантику даних.

Простими словами, IDoc — це файл даних у певному форматі, який обмінюється між двома системами, що знають, як інтерпретувати ці дані.

IDOC розшифровується як «Проміжний документ».

Коли ми виконуємо вихідний ALE або EDI, створюється IDOC. В ан вхідний Процес ALE або EDI, IDOC слугує входом для створення документа програми. В SAP SYSTEM, IDOC зберігаються в базі даних. Кожен IDOC має унікальний номер (в межах клієнта).

IDOC базуються на стандартах EDI, ANSI ASC X12 та ЕДИФАКТУ разі будь-якого конфлікту в розмірі даних, він приймає той, що має більшу довжину. IDOC - це незалежно від напрямку обміну даними, наприклад, ORDERS01 у модулі закупівель використовується як для вхідних, так і для вихідних повідомлень. IDOC можна переглянути в редактор тексту оскільки дані зберігаються в символьному форматі, а не в двійковому. IDOC – це незалежно від систем надсилання та отримання (SAP-До-SAP а також не-SAP).

Структура IDoc: записи керування, даних та стану

Знання того, що IDoc є контейнером, стане корисним лише тоді, коли ви зможете прочитати, що в ньому міститься. Кожен IDoc, незалежно від типу повідомлення, складається з трьох типів записів.

Номери статусу також показують вам напрямок з першого погляду. CodeНомери в діапазоні від 01 до 49 належать до вихідних IDoc, де 03 означає «передано до порту», ​​а 12 — «відправлено». CodeДокументи від 50 і вище належать до вхідних IDoc, де 53 означає «документ заявки опубліковано», а 51 означає «документ заявки не опубліковано».

Як працює процес ALE та IDoc?

Записи вище рухаються через фіксовану послідовність кроків. Розуміння цієї послідовності дозволяє вам знайти, де зупинився інтерфейс, що вийшов з ладу.

Вихідний процес

1. Документ заявки створюється. Користувач або пакетне завдання зберігає бізнес-документ, наприклад, замовлення на купівлю.
2. Активується керування повідомленнями. Визначення вихідних даних знаходить тип повідомлення, наприклад, ЗАМОВЛЕННЯ, та профіль партнера, який вказує на необхідність створення IDoc.
3. IDoc згенеровано. Модуль функції вибору зчитує таблиці застосунку та заповнює записи керування та даних. IDoc отримує статус 30, «готовий до відправлення».
4. IDoc передається до порту. Визначення порту визначає носій, яким може бути файл, виклик віддаленої функції або передача XML. Статус стає 03.
5. Підсистема або партнер отримує його. Для EDI підсистема перетворює IDoc на повідомлення EDIFACT або ANSI X12. У разі успішної передачі повертається статус 16.

Вхідний процес

1. Прибуття IDoc через порт і записується в базу даних зі статусом 50.
2. Профіль партнера перевіряється. SAP шукає відправника, тип повідомлення та призначений код процесу.
3. Код процесу викликає функціональний модуль, який перевіряє сегменти на відповідність базовому типу.
4. Документ заявки опубліковано. Успіх повертає статус 53. Невдача повертає статус 51, а IDoc залишається в базі даних із доданим повідомленням про помилку.
5. Невдалі IDoc обробляються повторно після виправлення основних даних, без необхідності повторного надсилання партнером чогось.

Оскільки IDoc зберігається на кожному етапі, жодні дані не втрачаються, якщо крок завершується невдачею. Ця довговічність є основною причиною SAP Інтеграції все ще залежать від IDocs навіть через десятиліття після їх появи.

Різниця між ALE та EDI

Після визначення всіх трьох понять, розмежування стає легким для сформулювання.

ALE використовується для підтримки розподілених, але інтегрованих процесів у кількох SAP системи, тоді як EDI використовується для обміну діловими документами між системами ділових партнерів (які можуть бути неSAP системи).

ALE є SAPтехнологія для підтримки розподіленого середовища, тоді як EDI — це процес, який використовується для обміну діловими документами, яким тепер надано стандартний формат.

IDoc – це контейнер даних, який використовується для обміну даними як процесами EDI, так і ALE. Саме через цей спільний контейнер ці дві технології майже завжди вивчаються разом.

Звичайна транзакція IDoc Codeз в SAP

Щоденна робота з ALE та EDI відбувається за допомогою невеликого набору кодів транзакцій. У таблиці нижче вони згруповані за завданням, яке вони виконують.

Практична звичка усунення несправностей полягає в тому, щоб почати з WE02 для зчитування статусу, а потім використовувати BD87 для повторної обробки після усунення першопричини.

Поширені запитання