Manual Prático de IDOC, ALE e EDI

5/9/2018 Manual Prático de IDOC, ALE e EDI - slidepdf.com

http://slidepdf.com/reader/full/manual-pratico-de-idoc-ale-e-edi 1/16

M anua l P rá t ico de ALE / ED I

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 dadosentre dois ou mais ambientes SAP R/3 ou R/3 e sistemas de terceiros. A tecnologia ALE facilita rápidaprototipação de aplicação e desenvolvimento de interface de aplicação, e ainda reduz o tempo deimplementaçã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 umainterface.

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

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

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

Communications layer . As comunicações ALE são realizadas tanto sincronamente quantoassincronamente. Transmissões de mensagens sincronamente são tipicamente usadas para leitura dedados diretamente, enquanto transmissões de mensagens assincronamente são usadas para transmitir ereceber dados da aplicação.

Rua Flórida, 1 670 – 5º Andar – Brooklin - São Paulo – SP –

Tel: 11 5505-2473

Pág 2 de 18




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 objetosde 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 paraintegração assíncrona de componentes de Business Framework, incluindo Business Components,Business Objects, e BAPIs.


Tel: 11 5505-2473

Pág 3 de 18





Tel: 11 5505-2473

Pág 4 de 18

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

O conceito de interface do R/3 é baseado em duas estratégias diferentes: Remote FunctionCalls (RFC) e a troca de dados através de documentos de mensagem IDoc. RFC faz achamada direta e sincronizada de programa no sistema remoto. BAPIs são subconjunto demó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 liberadosoficialmente 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 programadiretamente no sistema destino, os dados são primeiramente empacotados para um IDoc edepois o IDoc é enviado para sistema receptor, onde ele é analisado e adequadamenteprocessado. Por isso a troca de dados via IDoc é sempre um processo assíncrono. A principaldiferença entre uma chamada simples de RFC e a troca de dados via IDoc é, de fato, que cadaação executada em IDoc é protocolada pelo R/3 e IDocs podem ser reprocessados se algumerro ocorrer durante um dos passos de mensagem.

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




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 paradistribuição de dados para/de sistema R/3.Cada cliente R/3 usado para ALE ou EDI precisa ter uma baseLS associada com o cliente. Este LS se torna o “sender” para mensagem de outbound e o “receiver” paramensagem de inbound. Além disso, um segundo LS deveria ser criado para representar o sistemaexterno usado na interface ALE. Neste caso, este segundo LS seria “sender” quando for a mensagem deinbound e seria “receiver” quando for a mensagem de outbound.

Tipo de Mensagem. Um tipo de mensagem representa a troca de mensagem de aplicação entresistemas 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 demensagem, 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 denegó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 comas 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


Tel: 11 5505-2473

Pág 5 de 18




determinam dados de controle em IDoc de outbound, e opções de processamento em IDoc deinbound. 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 temuma 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”. Ocampo SDATAguarda os dados da aplicação, e sua estrutura é determinada pelo campo chaveSEGNAM (nome do segmento). Um IDoc consiste um ou mais registros de dado. Registros dedado são armazenados na tabela EDID4.No SAP segmentos de IDoc aderem-se convenção de nomenclatura. Cada segmento possui trêscomponentes, e cada componente com prefixo diferente - E1 para tipo de segmento, E2 paradefinição de segmento e E3 para documentação de segmento. Por exemplo, o primeiro segmentodo tipo de IDoc DEBMAS02 é E1KNA1M. Sua definição é contida na estrutura E2KNA1M, e adocumentação está na E3KNA1M. Quando o IDoc é externalizado, vemos o nome do segmentoiniciado 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 passapelo vários estágios de processamento. O registro de status mantém o histórico de um IDoc. UmIDoc 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 dadoscomunicados. 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 portabaseada em “file”. As portas tipo tRFC e file podem ser ligadas aos destinos RFC conectados em R/3-para-R/3 ou TCP/IP.


Tel: 11 5505-2473

Pág 6 de 18




Destino RFC. O destino RFC é o termo que define as características de comunicação ligado a umsistema remoto onde uma função precisa ser executada. A comunicação R/3-para-R/3 utilizatRFC(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 ofaturamento.

Códigos de Processo. Códigos de processo são usados em ALE e EDI para identificar o módulo defunçã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 tabelaTEDE1 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. Existemquatro tipos de parceiro: KU (Cliente), LI (Fornecedor), B (Banco) e LS (Sistema Lógico). Tipo de parceirodefine 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çãoALE e EDI. Ele transfere mensagens específicas através de tipos de IDoc definidos para a porta depoisda execução de certos módulos de função para processamento outbound. Ele também pode receber tipoespecífico de IDoc, e identifica módulos de função apropriados para que insira dados no banco no casode 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 queinformam 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.


Tel: 11 5505-2473

Pág 7 de 18




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: ZE1BANKLISTDescrição breve: Lista de Bancos

Ite

m

Nome de campo Elemento de dados

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_BANKLISTDescrição: Lista de BancosLigar o segmento ZE1BANKLIST abaixo do nome do IDoc:Número mínimo: 1Nú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_BANKLISTDescriçã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_BANKLISTTipo Básico: ZID_BANKLISTRelease: 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: TDescriçã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úmerosubseqüente, no nosso caso: A000000025

Descrição: Porta de saída para IDoc ZID_BANKLISTDestino RFC: DESTINO_RFC_IDOC005


Tel: 11 5505-2473

Pág 8 de 18




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 bancosImportação:Nome parâmetro Atrib. Tipo referência Valor proposto Opc. TransBANK_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 mensagemidoc_control-mestyp = 'ZMG_BANKLIST'.

* Tipo de IDocidoc_control-idoctp = 'ZID_BANKLIST'.idoc_control-serial = sy-datum.idoc_control-serial+8 = sy-uzeit.

*-------------------** Seleção de dados*-------------------*

LOOP AT receivers.


Tel: 11 5505-2473

Pág 9 de 18




CLEAR: syst_info.

CALL FUNCTION 'BAPI_BANK_GETLIST'

EXPORTINGbank_ctry = bank_ctrymax_rows = 0

TABLESbank_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_controlchnum = serial_id

TABLESidoc_data = idoc_datareceivers = idoc_receivercreated_idocs_additional = idoc_comm

EXCEPTIONSidoc_input_was_inconsistent = 1OTHERS = 2.

IF sy-subrc <> 0.MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno

WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4RAISING 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 *


Tel: 11 5505-2473

Pág 10 de 18




COMMIT WORK.

ENDFUNCTION.

*---------------------------------------------------------------------** FORM inserir_segmento_banklist **---------------------------------------------------------------------** Criar IDoc data-record **---------------------------------------------------------------------*FORM inserir_segmento_banklist

TABLESti_bank_list STRUCTURE bapi1011_listidoc_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_BANKLISTMódulo de função: ZALE_GET_BANKLISTClicar <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:


Tel: 11 5505-2473

Pág 11 de 18




Módulo: ZALE_GET_BANKLISTCategoria: FTp.básico: ZID_BANKLIST

Tipo mensagem: ZMG_BANKLISTDireção: 1

Salvar.

10º passo: Identificar o sistema lógico do próprio mandante através dos seguintes passos:Transação: SALEAbrir a opção:

Preparar sistema receptor e de envioInstalar sistemas lógicos

Atribuir sistema lógico a mandanteDouble-click na linha onde está o mandante do sistemaE 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 sejado 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_BANKLISTPrt.Destinat: A000000025Modo de saída: <Transf.imediatam.IDoc>

Tipo básico: ZID_BANKLISTAperte <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 bancosNome técnico: BANKLIST

Selecionar a linha “Lista de bancos” e clicar no botão <Inserir tipo de mensagem>Visão de modelo: BANKLISTEmissor: DEV46Destinatá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: BRRECEIVERS: BCDEV46

Executar a função.


Tel: 11 5505-2473

Pág 12 de 18




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 foienviado para um sistema R/3 ou para um programa externo, através de um RFC transacional.


Tel: 11 5505-2473

Pág 13 de 18




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

Existem duas formas de realizar IDoc de entrada, dependendo da disponibilidade de recursos no SAP. Aprimeira forma é aproveitar a estrutura existente de BAPI no SAP, se esta atende a necessidade dousuário; caso contrario, é necessário criar uma função e configurar o ambiente para que a entrada doIDoc 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 nocampo 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 paraobjeto BUS1011 e método CREATE” é mostrada. Neste caso, podemos consultar o interfacecriado 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çõesde 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 demensagem, e depois mostra outra janela para que entre com os dados de tipo de IDoc, módulosde função de entrada e saída. Após de entrar todos os dados, o sistema gerará tipo demensagem, 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. Casocontrário, clicar no ícone <Entradas novas>.

Módulo: BAPI_IDOC_INPUT1Categoria: F

Tp.básico: BANK_CREATE01


Tel: 11 5505-2473

Pág 14 de 18




Tipo mensagem: BANK_CREATEDireção: 2

Salvar.

5º passo: Identificar o sistema lógico do próprio mandante através dos seguintes passos:Transação: SALEAbrir a opção:

Preparar sistema receptor e de envioInstalar sistemas lógicos

Atribuir sistema lógico a mandanteDouble-click na linha onde está o mandante do sistemaE 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 sejado 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_CREATECód.processo: BAPIProcessamento 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 bancoNome técnico: BANKCREATEAperte <Enter>

Selecionar a linha “Criar banco” e clicar no botão <Inserir BAPI >Visão de modelo: BANKCREATEEmissor: BCDEV46Destinatário: DEV46NomeObjeto/Interface: BankMétodo: CreateAperte <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ásicoe executar.Na tela seguinte, clicar na linha EDIDC, o sistema mostra uma janela para entrar com os dados deregistros de controle:

Destinatário:Port: SAPTRN (é a palavra “SAP” concatenado com o nome do sistema local, queno nosso caso é “TRN”)


Tel: 11 5505-2473

Pág 15 de 18




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 apágina 7 passo 6 sobre como criar a porta)Nº parceiro: BCDEV46TpParceiro: LS

Tipo mensagem: BANK_CREATETecle <Enter>Clicar na linha do segmento “E1BANK_CREATE” e entrar os seguintes dados:

BANK_CTRY: BRBANK_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/AREGION: SPSTREET: RUA FLORIDA 1670CITY: SÃO PAULOBANK_NO: 999005

Tecle <Enter>Clicar no botão <Entrada standard>, o sistema mostra uma janela com as informações resumidassobre 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, oSAP precisa receber IDocs para alimentar uma tabela Z.


Tel: 11 5505-2473

Pág 16 de 18

Manual Prático de IDOC, ALE e EDI

Documents