SAP Tutorial de IDOC em ABAP: Guia passo a passo

⚡ Resumo Inteligente

SAP IDoc (Documento Intermediário) é um contêiner de dados padronizado que transfere informações comerciais entre SAP e não-SAP Este tutorial explica a definição, estrutura, tipos, tabelas, perfis de parceiros, portas e os processos de entrada e saída de ponta a ponta, utilizando ALE e EDI.

  • 📦 Definição Essencial: IDoc é um contêiner de dados independente de sistema, baseado em padrões EDI como ANSI ASC X12 e EDIFACT.
  • 🧱 Estrutura em três partes: Cada IDoc consiste em um Registro de Controle, Registros de Dados e Registros de Status, cada um armazenado em tabelas de banco de dados dedicadas.
  • 🆚 Hierarquia de tipos: Os tipos de IDoc básicos são fornecidos com SAP e não podem ser modificados; os Tipos de Extensão adicionam campos personalizados quando necessário.
  • 🔁 Fluxogramas de Processo: O módulo de saída cria e envia IDocs; o módulo de entrada os recebe e os publica por meio de módulos de função vinculados.
  • 🤖 Habilitação de IA: Ferramentas de monitoramento baseadas em IA detectam falhas de IDoc precocemente e mapeiam automaticamente os campos em todo o sistema. SAP e não-SAP parceiros.

SAP Tutorial IDOC

O que é um IDoc?

IDoc é simplesmente um contêiner de dados usado para trocar informações entre quaisquer dois processos que possam compreender a sintaxe e a semântica dos dados.

Em outras palavras, um IDoc é como um arquivo de dados com um formato específico, que é trocado entre dois sistemas que sabem como interpretar esses dados.

IDoc significa “Documento intermediário".

Ao executar um saída No processo ALE ou EDI, um IDoc é criado. SAP SystemOs IDocs são armazenados no banco de dados e cada IDoc possui um número único dentro de um cliente.

Características principais

  • IDocs são independente dos sistemas de envio e recebimento (SAP-A-SAP bem como não-SAP).
  • Os IDocs são baseados em EDI Os padrões utilizados são ANSI ASC X12 e EDIFACT. Em caso de conflito no tamanho dos dados, o IDoc adota aquele com maior comprimento.
  • IDocs são independente da direção da troca de dadosPor exemplo, o formulário ORDERS01 no módulo de Compras suporta tanto entradas quanto saídas.
  • Os IDocs podem ser visualizados em um editor de texto Porque os dados são armazenados em formato de caractere em vez de formato binário.

Estrutura de um IDoc

Estrutura de um IDoc

A estrutura do IDoc consiste em três partes:

  1. A parte administrativa (Registro de Controle) — Contém o tipo de IDoc, o tipo de mensagem, o status atual, o remetente, o destinatário e metadados semelhantes. Isso é chamado de Registro de Controle.
  2. Os dados da aplicação (Registro de Dados) — contém os dados comerciais. Estes são chamados de registros de dados ou segmentos.
  3. As informações de status (Registro de Status) — fornece informações sobre os vários estágios pelos quais o IDoc passou.

Você pode visualizar um IDoc usando uma transação. WE02 or WE05.

Registro IDoc mostrando Controle, Dados e Status.

Como pode ser visto na captura de tela acima, o registro IDoc possui três partes: Controle, Dados e Status. Cada parte é explorada em detalhes abaixo.

Registro de controle

  • Todos os dados do Registro de Controle são armazenados no EDIDC tabela. A chave desta tabela é o número IDoc.
  • Contém informações como número IDoc, direção (entrada/saída), remetente, informações do destinatário, canal em uso e porta em uso.
  • A direção “1” indica saída e “2” indica entrada.

Registro de Dados

  • O registro de dados contém dados do aplicativo, como informações de cabeçalho do funcionário, detalhes semanais, detalhes do cliente e assim por diante.
  • Todos os dados dos registros são armazenados em tabelas. EDID2 a EDID4 e EDIDD É uma estrutura onde você pode ver seus componentes.
  • Contém dados como o número do IDoc, o nome e o número do segmento no IDoc, a hierarquia e os próprios dados.
  • A carga útil real é armazenada como uma string em um campo chamado SDADOS, que é um campo de 1000 caracteres.

Registro de status

  • Um registro de status é anexado a um IDoc em cada etapa importante ou quando ocorre um erro.
  • Todos os dados do Registro de Status são armazenados no EDIDS tabela.
  • Os status 1 a 42 são para envios de saída, enquanto os status 50 a 75 são para envios de entrada.

Tipos de IDoc

Um Tipo IDoc (Básico) define a estrutura e o formato do documento comercial a ser trocado. Um IDoc é uma instância de um tipo de IDoc.Assim como o conceito de variáveis ​​e tipos de variáveis ​​em linguagens de programaçãoOs tipos de IDoc podem ser definidos usando transações. WE30.

O que é um Segmento?

Um segmento define o formato e a estrutura de um Registro de Dados Em um IDoc. Os segmentos são componentes reutilizáveis.

Para cada segmento, SAP Cria os seguintes componentes.

  • Tipo de segmento (independente da versão)
  • Definição de segmento (depende da versão)
  • Documentação do segmento

Os três últimos caracteres representam a versão do segmento. As definições podem mudar conforme a versão muda, mas o Tipo de Segmento permanece o mesmo. Transação: WE31.

Segmento em IDoc

O que é um tipo de IDoc de extensão?

Um IDoc é de dois tipos:

  1. Básico
  2. Extensão

Tipos de IDoc básicos e de extensão

SAP fornece muitos tipos de IDoc básicos predefinidos que não pode ser modificadoSe precisar adicionar mais dados a um Tipo Básico restrito, você pode usar um Tipo de Extensão. Na maioria das vezes, você irá... não Preciso de extensões.

Ilustração do tipo IDoc de extensão

Documentação

Cada IDoc é minuciosamente documentado na transação. WE60.

Documentação IDoc no WE60

Tipo de mensagem

Uma mensagem representa um tipo específico de documento que é transmitrelações entre duas partes, por exemplo, Pedidos, Respostas a Pedidos e Faturas.

Um tipo de IDoc pode ser associado a vários tipos de mensagem. Por outro lado, um tipo de mensagem pode ser associado a diferentes tipos de IDoc. Transação: WE81.

Tipo de mensagem no IDoc

Visualizações de IDoc

Um tipo de IDoc pode ser usado para mais de um tipo de mensagem, o que resulta em IDocs contendo mais campos do que o necessário para um determinado tipo de mensagem.

As IDoc Views melhoram o desempenho na geração de IDocs, garantindo que apenas os segmentos relevantes sejam preenchidos com dados. As IDoc Views são importantes apenas para o processamento de saída.

Visualizações de IDoc

Perfis de parceiros

Um parceiro é um sócio comercial com quem você realiza negócios e troca documentos.

No perfil do parceiro com quem os IDocs são trocados, você mantém os parâmetros necessários para a troca de dados. A transação utilizada é WE20.

Perfis de parceiros no IDoc

Porta

O Porto define as características técnicas da conexão entre o seu SAP O parâmetro `port` define o meio pelo qual os dados são trocados entre os dois sistemas.

Existem diferentes tipos de portas. As duas mais comuns são Portas TRFC usado em ALE e Portas de arquivo usado pelo EDI.

Para portas TRFC, você precisa fornecer o nome do destino lógico criado usando SM59Ao usar uma porta de arquivo, você pode especificar o diretório onde o arquivo IDoc deve ser colocado. O outro sistema ou middleware então busca o arquivo a partir desse diretório. Um módulo de função pode ser usado para gerar um nome de arquivo para o IDoc. ensaioVocê pode usar “Arquivo de saída” para especificar um nome de arquivo constante. A guia “gatilho de saídaO parâmetro “” pode ser usado para fornecer informações caso você queira acionar algum processamento no subsistema quando um IDoc for criado neste local. Especifique o nome do arquivo de comando e o diretório onde ele deve ser executado.

Porta em IDoc

Transação IDoc comum Codes

transação Code Propósito
WE02 / WE05 Exibir e monitorar IDocs
WE30 Criar ou alterar o tipo de IDoc
WE31 Criar ou alterar Segmento
WE20 Manter o perfil do parceiro
WE21 Manutenção dos portos
WE42 Defina o processo de entrada. Code
WE57 Alocar módulo de função de entrada ao tipo de mensagem
WE60 Documentação IDoc
WE81 / WE82 Criar tipo de mensagem / associar ao tipo de IDoc
BD51 Defina as características do módulo de função.
SM59 Manter destinos RFC

Processo IDoc: um exemplo do mundo real

Considere o exemplo de envio de uma Ordem de Compra a um fornecedor através do IDoc.

  • Sempre que uma Ordem de Compra (OC) é criada, o sistema precisa enviar um IDoc ao fornecedor.
  • O pedido de compra é enviado ao fornecedor (parceiro) na forma de um IDoc. Esse parceiro precisa estar habilitado para EDI no sistema. SAP reconhece que pode enviar o documento a este fornecedor eletronicamente.
  • O pedido de compra enviado pelo cliente como um IDoc de saída torna-se um IDoc de entrada para o fornecedor. SAP O sistema do fornecedor pode processar isso para criar um documento de aplicação (um Pedido de Vendas) em seu sistema.
  • Cotações, solicitações de cotação (RFQs), pedidos de compra (POs), ordens de venda (SOs), faturas e notas de entrega estão entre os documentos mais comumente trocados por meio do IDoc.

O processo de transferência de dados para fora do seu SAP sistema é chamado de Processo de saída, enquanto os dados se movem para o seu SAP sistema é chamado de Processo de entradaComo desenvolvedor ou consultor responsável pela configuração desses processos em sua organização, as etapas para configurar cada um deles estão detalhadas abaixo.

O processo de saída

Etapas envolvidas:

  1. Criar segmentos (WE31).
  2. Criar um tipo de IDoc (WE30).
  3. Criar um tipo de mensagem (WE81).
  4. Associe o tipo de mensagem ao tipo de IDoc (WE82).
  5. Criar uma porta (WE21).
  6. Se você usar o método de controle de mensagens para acionar IDocs, crie o módulo de função que constrói o IDoc e vincule-o a um processo de saída. Code.
  7. Caso contrário, crie um módulo de função ou um programa independente que crie o IDoc diretamente.
  8. Crie um Perfil de Parceiro (WE20) com as informações necessárias nos parâmetros de saída para o parceiro com quem você troca o IDoc e acione o IDoc.

O processo de entrada

Etapas envolvidas:

  1. Criar o tipo de IDoc básico (transação WE30).
  2. Criar o tipo de mensagem (transação WE81).
  3. Associe o tipo de mensagem ao tipo de IDoc básico (transação WE82).
  4. Crie o módulo de função para processar o IDoc.
  5. Defina as características do módulo de função (BD51).
  6. Atribua o módulo de função de entrada ao tipo de mensagem (WE57).
  7. Defina o processo Code (Transação WE42).
  8. Criar o perfil do parceiro (transação WE20).

Perguntas Frequentes

IDoc é assíncrono e usado para mensagens entre sistemas via ALE ou EDI. BAPI é síncrono e usado para acesso em tempo real a... SAP Objetos de negócio. O IDoc é enfileirado; a BAPI retorna imediatamente.

Um Tipo de IDoc define a estrutura técnica de segmentos e campos. Um Tipo de Mensagem define o significado comercial, como Pedidos ou Faturas. Um Tipo de IDoc pode servir a vários Tipos de Mensagem e vice-versa.

Utilize as transações WE02 ou WE05 para exibir IDocs e inspecionar registros de status. As transações de saída utilizam os códigos de status de 1 a 42; as de entrada, de 50 a 75. A transação BD87 reprocessa IDocs com erros.

O campo SDATA, que armazena a carga útil em cada registro de dados, tem 1000 caracteres. Um IDoc pode conter muitos registros de dados, portanto, a carga útil total aumenta proporcionalmente ao número de segmentos.

Sim. Os IDocs são independentes de sistema e seguem padrões EDI como ANSI ASC X12 e EDIFACT. Não-SAP Os sistemas podem produzir ou consumir arquivos IDoc por meio de portas de arquivo ou middleware, como por exemplo... SAP PI/PO.

Os registros de controle ficam na tabela EDIDC, os registros de dados nas tabelas EDID2 a EDID4 e os registros de status na tabela EDIDS. O número do IDoc é a chave que vincula todas as três tabelas para um determinado IDoc.

Ferramentas de monitoramento baseadas em IA agrupam erros recorrentes de IDoc, preveem falhas a partir de padrões históricos e recomendam correções para problemas de status 51 ou 56, reduzindo significativamente o tempo de reprocessamento manual.

Sim. Mapa baseado em IAping Os motores comparam as definições de segmento em todo o sistema. SAP e sistemas parceiros, propõem um mapa de campo.pinge aprender com correções anteriores — reduzindo drasticamente a configuração manual em projetos ALE e EDI.

Resuma esta postagem com: