Manual Prático de ALE / EDI

IDoc
 Manual Prático de ALE/EDI e IDoc

O que é ALE?
SAP ALE (Application Link Enabling) é a tecnologia proprietária que permite a comunicação de dados
entre dois ou mais ambientes SAP R/3 ou R/3 e sistemas de terceiros. A tecnologia ALE facilita rápida
prototipação de aplicação e desenvolvimento de interface de aplicação, e ainda reduz o tempo de
implementação.

ALE vem com cenários de integração/distribuição de aplicação e um conjunto de ferramentas, programas,

definição de dados e metodologias que você pode facilmente configurar para construir e rodar uma
interface.

A arquitetura de ALE é composta de três camadas:

Application layer. Esta camada fornece a ALE uma interface para criar ou receber mensagens contendo
dados para/de sistemas externos (ou outra SAP R/3).

Distribution layer (ALE layer). A camada de distribuição filtra e converte mensagens contendo dados
baseados de regras predefinidas ou customizadas. Estas conversões podem ocorrer para assegurar a
compatibilidade entre diferentes releases de R/3 e R/2.

Communications layer. As comunicações ALE são realizadas tanto sincronamente quanto

assincronamente. Transmissões de mensagens sincronamente são tipicamente usadas para leitura de
dados diretamente, enquanto transmissões de mensagens assincronamente são usadas para transmitir e
receber dados da aplicação.

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 2 de 18

Tel: 11 5505-2473
 Manual Prático de ALE/EDI e IDoc

Existem várias vantagens pela utilização da tecnologia ALE:

• SAP garante a independência de release.

• ALE oferece melhor performance de interface de entrada do que as técnicas tradicionais como Batch
Data Communications (BDC) ou Call Transactions. ALE não utiliza batch-input baseada de telas.
• ALE fornece tecnologia tipo “caixa-preta”, com isso o usuário fica no nível mais alto de desenvolvimento.
• A maioria de interfaces ALE pode ser prototipada em alguns dias, resultando prazo menor de
implementação.
• Pouco ou não há desenvolvimento de ABAP. Na maioria dos casos, as funcionalidades ALE
desenvolvidas pelo SAP já preenchem os requisitos.
• ALE oferece recursos sistemáticos e organizados para manutenção de melhorias e extensões.
• Uma interface ALE é fácil de manutenção devido ao acesso estruturado e ao número mínimo de objetos
de desenvolvimento.
• ALE é a arquitetura estratégica do R/3 para efetuar conexão com sistemas legados e de terceiros e é o
elemento chave do Business Framework. Ele determina a arquitetura baseada em mensagens para
integração assíncrona de componentes de Business Framework, incluindo Business Components,
Business Objects, e BAPIs.

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 3 de 18

Tel: 11 5505-2473
 Manual Prático de ALE/EDI e IDoc

Qual é a diferença entre ALE, EDI, IDoc e BAPI?

O conceito de interface do R/3 é baseado em duas estratégias diferentes: Remote Function

Calls (RFC) e a troca de dados através de documentos de mensagem IDoc. RFC faz a
chamada direta e sincronizada de programa no sistema remoto. BAPIs são subconjunto de
módulos de função RFC, especialmente desenhadas como Application Programming Interface
(API) para objeto de negócio SAP, ou seja, BAPIs são módulos de função liberados
oficialmente pela SAP para serem chamados por programas externos.

IDoc(Intermediate Document) é documento de texto codificado com uma estrutura rígida que é
usado para troca de dados entre R/3 e sistemas externos. Ao invés de chamar o programa
diretamente no sistema destino, os dados são primeiramente empacotados para um IDoc e
depois o IDoc é enviado para sistema receptor, onde ele é analisado e adequadamente
processado. Por isso a troca de dados via IDoc é sempre um processo assíncrono. A principal
diferença entre uma chamada simples de RFC e a troca de dados via IDoc é, de fato, que cada
ação executada em IDoc é protocolada pelo R/3 e IDocs podem ser reprocessados se algum
erro ocorrer durante um dos passos de mensagem.

Enquanto IDocs são entendidos como protocolo de troca de dados, EDI e ALE são casos
típicos de uso para IDocs. R/3 utiliza IDocs através tanto EDI quanto ALE para distribuir dados
ao sistema receptor. A grande diferença entre EDI e ALE é o seguinte: se eu enviar dados para
um parceiro externo, de forma geral eu estou falando de EDI, enquanto ALE é o mecanismo
para replicar dados de forma confiável entre sistemas de confiança para armazenar cópia
redundante de dados de IDoc. Para esclarecer a diferença ainda mais, podemos pensar um
pedido de compra que é enviado através de um IDoc. Se nós enviarmos um pedido de compra
para o fornecedor então o fornecedor vai armazenar este pedido de compra como uma ordem
de venda. (Isto é o conceito de EDI.) No entanto, se nós enviarmos o pedido de compra via
ALE para outro ambiente R/3, então o sistema receptor vai armazenar o pedido de compra
também como pedido de compra.

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 4 de 18

Tel: 11 5505-2473
 Manual Prático de ALE/EDI e IDoc

Blocos de Construção de ALE e Seus Conceitos

Os seguintes blocos de construção são fundamentais para funcionalidade ALE:

Sistema Lógico. O Sistema Lógico(LS) é a representação de R/3 ou de um sistema externo para

distribuição de dados para/de sistema R/3.Cada cliente R/3 usado para ALE ou EDI precisa ter uma base
LS associada com o cliente. Este LS se torna o “sender” para mensagem de outbound e o “receiver” para
mensagem de inbound. Além disso, um segundo LS deveria ser criado para representar o sistema
externo usado na interface ALE. Neste caso, este segundo LS seria “sender” quando for a mensagem de
inbound e seria “receiver” quando for a mensagem de outbound.

Tipo de Mensagem. Um tipo de mensagem representa a troca de mensagem de aplicação entre

sistemas R/3 ou um R/3 e um sistema externo. Um tipo de mensagem caracteriza os dados enviados
entre sistemas e se relaciona com uma estrutura de dado que se chama Tipo de IDoc.

Tipo de IDoc e IDoc. Um tipo de IDoc representa a estrutura de dados associada a um tipo de
mensagem, enquanto um IDoc é um objeto contendo os dados de um tipo de mensagem particular. IDoc
é um recipiente de dados com inteligência embutida. Cada IDoc contém um e somente um objeto de
negócio.

Um IDoc consiste três tipos de registro: o registro de controle, registro de dado e registro de status.

• Registro de controle, ou EDI_DC, é uma estrutura de controle que contém vários campos com
as informações sobre o IDoc, tais como o tipo de IDoc, o tipo de mensagem, informação de
sender e de receiver, e a direção (1 para outbound e 2 para inbound). Estas informações

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 5 de 18

Tel: 11 5505-2473
 Manual Prático de ALE/EDI e IDoc

determinam dados de controle em IDoc de outbound, e opções de processamento em IDoc de

inbound. Ele também possui a sua chave de mandante (MANDT) e o número de IDoc (DOCNUM).
O registro EDI_DC de um IDoc é armazenado na tabela EDIDC. Cada IDoc tem um registro de
controle.

• Registro de dado, ou EDI_DD, ele contém os dados da applicação. Cada registro EDI_DD tem
uma porção de chaves que contêm uma série de campos descrevendo o conteúdo do registro.
Depois das chaves vem o campo SDATA com tamanho de 1000 bytes do tipo “Long Char”. O
campo SDATAguarda os dados da aplicação, e sua estrutura é determinada pelo campo chave
SEGNAM (nome do segmento). Um IDoc consiste um ou mais registros de dado. Registros de
dado são armazenados na tabela EDID4.
No SAP segmentos de IDoc aderem-se convenção de nomenclatura. Cada segmento possui três
componentes, e cada componente com prefixo diferente - E1 para tipo de segmento, E2 para
definição de segmento e E3 para documentação de segmento. Por exemplo, o primeiro segmento
do tipo de IDoc DEBMAS02 é E1KNA1M. Sua definição é contida na estrutura E2KNA1M, e a
documentação está na E3KNA1M. Quando o IDoc é externalizado, vemos o nome do segmento
iniciado com prefixo E2. Na prática, em todos os casos, usamos somente prefixo E2 para se referir
segmentos de IDoc.

• Registro de status, ou EDI_DS. Ele contém informações de estado de IDoc quando IDoc passa
pelo vários estágios de processamento. O registro de status mantém o histórico de um IDoc. Um
IDoc pode ter um ou mais registros de status, onde são armazenados na tabela EDIDS.

Porta. Porta é a representação lógica de canal de comunicação em SAP, com os IDocs sendo os dados
comunicados. São quatro tipos de portas que podem ser definidos em R/3: tRFC, File, R/2, e Internet.
ALE pode utilizar todas os tipos de porta para distribuir IDocs, enquanto EDI tipicamente utiliza a porta
baseada em “file”. As portas tipo tRFC e file podem ser ligadas aos destinos RFC conectados em R/3-
para-R/3 ou TCP/IP.

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 6 de 18

Tel: 11 5505-2473
 Manual Prático de ALE/EDI e IDoc

Destino RFC. O destino RFC é o termo que define as características de comunicação ligado a um
sistema remoto onde uma função precisa ser executada. A comunicação R/3-para-R/3 utiliza
tRFC(transactional RFC). O prefixo transactional indica meramente que uma função específica é
executada por unidade lógica de trabalho, que pode ser Mestre de Material, ou a entrega, ou o
faturamento.

Códigos de Processo. Códigos de processo são usados em ALE e EDI para identificar o módulo de
função ou API para ser chamado e conseqüentemente processado. Cada código de processo é
associado a um tipo de mensagem. Códigos de processo tipo outbound são armazenados na tabela
TEDE1 e códigos de processo tipo inbound são armazenados na tabela TEDE2.

Tipo de parceiro. Tipo de parceiro é um identificador do sistema para comunicar mensagens. Existem
quatro tipos de parceiro: KU (Cliente), LI (Fornecedor), B (Banco) e LS (Sistema Lógico). Tipo de parceiro
define vários elementos de ALE e EDI com os parâmetros de comunicação entre dois ou mais sistemas.
Os principais parâmetros são: tipos de mensagem, tipos de IDoc, códigos de processo, funções parceiro,
identificadores da aplicação, funções de mensagem, tipos de saída e portas.
Tipo de parceiro exerce um papel muito importante pois ele age como um gateway para comunicação
ALE e EDI. Ele transfere mensagens específicas através de tipos de IDoc definidos para a porta depois
da execução de certos módulos de função para processamento outbound. Ele também pode receber tipo
específico de IDoc, e identifica módulos de função apropriados para que insira dados no banco no caso
de interface inbound.

Modelo de distribuição. No sistema R/3, o Modelo de Distribuição é uma ferramenta que armazena
informações sobre o fluxo de dados entre vários sistemas. O modelo de distribuição armazena dados que
informam quais as mensagens (tipos de mensagem) sejam transmitidas para quais Sistemas Lógicos.
Várias mensagens podem ser transmitidas para um Sistema Lógico, e uma única mensagem pode ser
transmitida para vários Sistemas Lógicos.

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 7 de 18

Tel: 11 5505-2473
 Manual Prático de ALE/EDI e IDoc

Roteiro prático para criar IDoc de saída (outbound)

Vamos criar um IDoc de saída (outbound) usando a BAPI: BAPI_BANK_GETLIST.

1º passo: Criar os segmentos através da transação WE31:

Criar segmento conforme a estrutura BAPI1011_LIST:
Tipo de segmento: ZE1BANKLIST
Descrição breve: Lista de Bancos
Ite Nome de campo Elemento de dados
m
1 BANK_CTRY BANKS
2 BANK_KEY BANKK
3 BANK_NAME BANKA
4 CITY ORT01_GP

Salvar e liberar o segmento.

2º passo: Criar Tipo de IDoc através da transação WE30:

Nome IDoc: ZID_BANKLIST
Descrição: Lista de Bancos
Ligar o segmento ZE1BANKLIST abaixo do nome do IDoc:
Número mínimo: 1
Número máximo: 99999999

Salvar e liberar o tipo de IDoc.

3º passo: Criar Tipo de mensagem através da transação WE81:

Tipo de mensagem: ZMG_BANKLIST
Descrição breve: Lista de Bancos

4º passo: Relacionar tipo de mensagem ao tipo de IDoc através da transação WE82:

Tipo de mensagem: ZMG_BANKLIST
Tipo Básico: ZID_BANKLIST
Release: 46C

5º passo: Criar destino RFC através da transação SM59:

Clicar no botão <Criar>,
Destino RFC: DESTINO_RFC_IDOC005
Tipo de conexão: T
Descrição: Teste de destino RFC para IDoc ZID_BANKLIST

6º passo: Criar porta através da transação WE21:

Posicionar o cursor na palavra RFC Transacional
Portas
+-------RFC Transacional
Clicar o ícone <Criar>
Selecionar a opção “Gerar nome de porta”, o sistema irá gerar a porta com o próximo número
subseqüente, no nosso caso: A000000025
Descrição: Porta de saída para IDoc ZID_BANKLIST
Destino RFC: DESTINO_RFC_IDOC005

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 8 de 18

Tel: 11 5505-2473
 Manual Prático de ALE/EDI e IDoc

7º passo: Criar um módulo de função através da transação SE37:

Módulo de função: ZALE_GET_BANKLIST
Grupo de função: ZIDOC (criar se for necessário)
Texto breve: Buscar lista de bancos
Importação:
Nome parâmetro Atrib. Tipo referência Valor proposto Opc. Trans
BANK_CTRY LIKE BAPI1011_LIST X
SERIAL_ID LIKE SERIAL-CHNUM '0' X X
Tabelas:
Nome parâmetro Atrib. Tipo referência Opc.
RECEIVERS LIKE BDI_LOGSYS
COMMUNICATION_DOCUMENTS LIKE SWOTOBJID X
Exceção:
ERROR_CREATING_IDOCS

Texto fonte:

*-------------------*
* Tabelas internas
*-------------------*
DATA: BEGIN OF ti_bank_list OCCURS 0.
INCLUDE STRUCTURE bapi1011_list.
DATA: END OF ti_bank_list.

*-------------------*
* Variáveis globais
*-------------------*
DATA: idoc_control LIKE bdicontrol,
idoc_data LIKE edidd OCCURS 0 WITH HEADER LINE,
idoc_receiver LIKE bdi_logsys OCCURS 0 WITH HEADER LINE,
idoc_comm LIKE edidc OCCURS 0 WITH HEADER LINE,
syst_info LIKE syst.

*----------------*
* Processamento
*----------------*

* Popular registro de controle

* Tipo de mensagem
idoc_control-mestyp = 'ZMG_BANKLIST'.
* Tipo de IDoc
idoc_control-idoctp = 'ZID_BANKLIST'.
idoc_control-serial = sy-datum.
idoc_control-serial+8 = sy-uzeit.

*-------------------*
* Seleção de dados
*-------------------*
LOOP AT receivers.

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 9 de 18

Tel: 11 5505-2473
 Manual Prático de ALE/EDI e IDoc

CLEAR: syst_info.

CALL FUNCTION 'BAPI_BANK_GETLIST'

EXPORTING
bank_ctry = bank_ctry
max_rows = 0
TABLES
bank_list = ti_bank_list.

* call subroutine to create IDoc data-record *

CLEAR: syst_info, idoc_data.
REFRESH idoc_data.
PERFORM inserir_segmento_banklist TABLES ti_bank_list
idoc_data.

* distribute idocs *
REFRESH: idoc_receiver, idoc_comm.
APPEND receivers TO idoc_receiver.

CALL FUNCTION 'ALE_IDOCS_CREATE'

EXPORTING
idoc_control = idoc_control
chnum = serial_id
TABLES
idoc_data = idoc_data
receivers = idoc_receiver
created_idocs_additional = idoc_comm
EXCEPTIONS
idoc_input_was_inconsistent = 1
OTHERS = 2.

IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
RAISING error_creating_idocs.
ENDIF.

IF communication_documents IS REQUESTED.
LOOP AT idoc_comm.
CLEAR communication_documents.
communication_documents-objtype = 'IDOC'.
communication_documents-objkey = idoc_comm-docnum.
communication_documents-logsys = idoc_comm-rcvprn.
communication_documents-describe = space.
APPEND communication_documents.
ENDLOOP.
ENDIF.

ENDLOOP.

* applications do commit work to trigger communications *

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 10 de 18

Tel: 11 5505-2473
 Manual Prático de ALE/EDI e IDoc

COMMIT WORK.

ENDFUNCTION.

*---------------------------------------------------------------------*
* FORM inserir_segmento_banklist *
*---------------------------------------------------------------------*
* Criar IDoc data-record *
*---------------------------------------------------------------------*
FORM inserir_segmento_banklist
TABLES
ti_bank_list STRUCTURE bapi1011_list
idoc_data STRUCTURE edidd.

DATA: ze1banklist LIKE ze1banklist,

ti_ze1banklist LIKE edidd OCCURS 0 WITH HEADER LINE.

* for segment 'ZE1BANKLIST'

CLEAR ti_ze1banklist.
REFRESH ti_ze1banklist.
ti_ze1banklist-segnam = 'ZE1BANKLIST'.

LOOP AT ti_bank_list.
CLEAR ze1banklist.
MOVE-CORRESPONDING ti_bank_list TO ze1banklist.

IF NOT ze1banklist IS INITIAL.

ti_ze1banklist-sdata = ze1banklist.
APPEND ti_ze1banklist.
ENDIF.

APPEND ti_ze1banklist TO idoc_data.

ENDLOOP.

ENDFORM.

8º passo: Criar código de processo – saída através da transação WE41:

Cód.processo: ZCP_BANKLIST
Módulo de função: ZALE_GET_BANKLIST
Clicar <Enter> (O sistema traz a descrição automaticamente)
Double-click na palavra “Mensagem lógica”
Clicar no botão <Entradas novas>
Tipo mensagem: ZMG_BANKLIST

Salvar o código de processo

9º passo: Atribuir módulo de função a tipo de mensagem e de IDoc através da transação WE57:

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 11 de 18

Tel: 11 5505-2473
 Manual Prático de ALE/EDI e IDoc

Módulo: ZALE_GET_BANKLIST
Categoria: F
Tp.básico: ZID_BANKLIST
Tipo mensagem: ZMG_BANKLIST
Direção: 1

Salvar.

10º passo: Identificar o sistema lógico do próprio mandante através dos seguintes passos:
Transação: SALE
Abrir a opção:
Preparar sistema receptor e de envio
Instalar sistemas lógicos
Atribuir sistema lógico a mandante
Double-click na linha onde está o mandante do sistema
E descobrir qual o sistema lógico do mandante, no nosso caso é “DEV46”

11º passo: Criar tipo de parceiro através da transação WE20:

Abrir o tipo de parceiro LS (sistema lógico) e selecionar algum outro sistema lógico que não seja
do próprio “DEV46”, o nosso caso escolhemos “BCDEV46”
No parâmetro de saída, clicar o ícone <Criar parâmetro de saída>
Tipo de mensagem: ZMG_BANKLIST
Prt.Destinat: A000000025
Modo de saída: <Transf.imediatam.IDoc>
Tipo básico: ZID_BANKLIST
Aperte <Enter> e salvar

12º passo: Criar modelo de distribuição através da transação BD64:

Clicar no botão: <Criar visão modelo>
Texto breve: Lista de bancos
Nome técnico: BANKLIST
Selecionar a linha “Lista de bancos” e clicar no botão <Inserir tipo de mensagem>
Visão de modelo: BANKLIST
Emissor: DEV46
Destinatário: BCDEV46
Tipo de mensagem: ZMG_BANKLIST

Salvar o modelo de distribuição.

13º passo: Testar a função para disparar IDoc através da transação SE37:
Função: ZALE_GET_BANKLIST
BANK_CTRY: BR
RECEIVERS: BCDEV46

Executar a função.

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 12 de 18

Tel: 11 5505-2473
 Manual Prático de ALE/EDI e IDoc

14º passo: Listar IDocs enviados através da transação WE05:

Verificar o IDoc criado com o status 03 “Transferência de dados para a porta OK”. - O IDoc foi
enviado para um sistema R/3 ou para um programa externo, através de um RFC transacional.

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 13 de 18

Tel: 11 5505-2473
 Manual Prático de ALE/EDI e IDoc

Roteiro prático para criar IDoc de entrada (inbound)

Existem duas formas de realizar IDoc de entrada, dependendo da disponibilidade de recursos no SAP. A
primeira forma é aproveitar a estrutura existente de BAPI no SAP, se esta atende a necessidade do
usuário; caso contrario, é necessário criar uma função e configurar o ambiente para que a entrada do
IDoc seja efetuada.

Vamos começar o exemplo pela forma mais fácil, a de aproveitar a estrutura existente de BAPI.

1) Vamos criar um IDoc de entrada (inbound) usando a BAPI: BAPI_BANK_CREATE.

1º passo: Buscar o “bus” da BAPI através da transação BAPI:

Na transação BAPI, selecionar o folder “Alfabetic”, abrir a estrutura do ”bank” e clicar na palavra
“create”. Na parte direita da tela double-click a opção “create BAPI List” e depois na tela inferior
mostra o “bus” da BAPI no campo “CtgObjeto”. Anotar o bus. No nosso caso é “BUS1011”.

2º passo: Gerar interface ALE através da transação BDBG:

Na transação BDBG, entrar o nome do “bus” no campo “CtgObjeto/tp.interface” (BUS1011), e no
campo de “Método”, clicar no match-code, selecionar a opção “CREATE” e depois clicar no ícone
<criar>.
Se o interface já foi criado, então a mensagem “Existe o tipo de mensagem BANK_CREATE para
objeto BUS1011 e método CREATE” é mostrada. Neste caso, podemos consultar o interface
criado clicando o ícone <Verificar interface>. O sistema mostrará o tipo de mensagem
“BANK_CREATE”, o tipo básico (tipo de IDoc) “BANK_CREATE01”, os segmentos e as funções
de entrada (“IDOC_INPUT_BANK_CREATE”) e saída (“ALE_BANK_CREATE”). Todos estes
componentes de interface já foram criados.
Se o interface ainda não foi criado, então o sistema mostra uma janela pedindo o tipo de
mensagem, e depois mostra outra janela para que entre com os dados de tipo de IDoc, módulos
de função de entrada e saída. Após de entrar todos os dados, o sistema gerará tipo de
mensagem, IDoc, os segmentos e as função de entrada e saída automaticamente.
(Tipo de mensagem é gravado na tabela standard EDMSG).

3º passo: Criar código de processo – entrada através da transação WE42:

Na transação WE42, selecionar o código de processo BAPI (double-click)
Double-click na palavra “Mensagem lógica” situada no lado esquerdo da tela.
No table-control do lado direito da tela, verificar se tipo de mensagem “BANK_CREATE” está
cadastrado. Caso contrário, clicar no ícone <Entradas novas>.
Tipo de mensagem: BANK_CREATE

Salvar o código de processo.

4º passo: Atribuir módulo de função a tipo de mensagem e de IDoc através da transação WE57:
Verificar se o tipo básico “BANK_CREATE01” está cadastrado na transação WE57. Caso
contrário, clicar no ícone <Entradas novas>.
Módulo: BAPI_IDOC_INPUT1
Categoria: F
Tp.básico: BANK_CREATE01

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 14 de 18

Tel: 11 5505-2473
 Manual Prático de ALE/EDI e IDoc

Tipo mensagem: BANK_CREATE

Direção: 2

Salvar.

5º passo: Identificar o sistema lógico do próprio mandante através dos seguintes passos:
Transação: SALE
Abrir a opção:
Preparar sistema receptor e de envio
Instalar sistemas lógicos
Atribuir sistema lógico a mandante
Double-click na linha onde está o mandante do sistema
E descobrir qual o sistema lógico do mandante, no nosso caso é “DEV46”

6º passo: Criar tipo de parceiro através da transação WE20:

Abrir o tipo de parceiro LS (sistema lógico) e selecionar algum outro sistema lógico que não seja
do próprio “DEV46”, o nosso caso escolhemos “BCDEV46”
No “parâmetro de entrada”, clicar o ícone <Criar parâmetro de entrada>
Tipo de mensagem: BANK_CREATE
Cód.processo: BAPI
Processamento através módulo função: <Acionamento imediato>
Teclar <Enter> e salvar os dados.(Os dados são gravados na tabela standard EDP21).

7º passo: Criar modelo de distribuição através da transação BD64:

Clicar no botão: <Criar visão modelo>
Texto breve: Criar banco
Nome técnico: BANKCREATE
Aperte <Enter>
Selecionar a linha “Criar banco” e clicar no botão <Inserir BAPI >
Visão de modelo: BANKCREATE
Emissor: BCDEV46
Destinatário: DEV46
NomeObjeto/Interface: Bank
Método: Create
Aperte <Enter>

Salvar o modelo de distribuição.

8º passo: Testar a entrada de IDoc através da transação WE19:

Na transação WE19, vamos entrar com o nome de IDoc: BANK_CREATE01 no campo Tp.básico
e executar.
Na tela seguinte, clicar na linha EDIDC, o sistema mostra uma janela para entrar com os dados de
registros de controle:
Destinatário:
Port: SAPTRN (é a palavra “SAP” concatenado com o nome do sistema local, que
no nosso caso é “TRN”)

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 15 de 18

Tel: 11 5505-2473
 Manual Prático de ALE/EDI e IDoc

Nº parceiro: DEV46 (sistema lógico do próprio mandante descoberto no passo 5)

TpParceiro: LS
Remetente:
Port: A000000025 (criado no exemplo anterior. Se não encontrou então consultar a
página 7 passo 6 sobre como criar a porta)
Nº parceiro: BCDEV46
TpParceiro: LS
Tipo mensagem: BANK_CREATE
Tecle <Enter>
Clicar na linha do segmento “E1BANK_CREATE” e entrar os seguintes dados:
BANK_CTRY: BR
BANK_KEY: 999005 (chave do banco, entrar com uma chave inexistente)
Tecle <Enter>
Clicar na linha do segmento “E1BP1011_ADDRESS” e entrar os seguintes dados:
BANK_NAME: BANCO TESTE IDOC INBOUND S/A
REGION: SP
STREET: RUA FLORIDA 1670
CITY: SÃO PAULO
BANK_NO: 999005
Tecle <Enter>
Clicar no botão <Entrada standard>, o sistema mostra uma janela com as informações resumidas
sobre protocolo de transmissão, teclar <Enter> e um IDoc de entrada é criado.

9º passo: Listar IDocs recebidos através da transação WE05:

Verificar o IDoc criado com o status 53 “Documento de aplicação gravado”. - BAPI CREATE foi
chamado com êxito.
Verificar também a tabela standard BNKA (Mestre de bancos) um novo banco foi criado.

2) Suponha que no SAP não existe uma BAPI que satisfaz a necessidade do usuário. Por exemplo, o
SAP precisa receber IDocs para alimentar uma tabela Z.

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP – Pág 16 de 18

Tel: 11 5505-2473