Funçoes para o Processamento de IDOC

Funções para o processamento de IDOC
Permite o processamento de determinadas informações no nível do campo ou do segmento ao

enviar e receber, no nível ALE. (ALE-Schicht).
Definir Filtros
Pode-se determinar, por tipo de mensagem e receptor, os segmentos do IDOC que não devem ser
transmitidos.
Observação: Os sistemas do parceiro tem de ser identicos, não é necessário filtrar os

segmentos obrigatórios e considerar que todos os segmentos anexados na
hierarquia sob um segmento também serão filtrados quando se filtra o segmento
superior.
Conversão
Permite a conversão de conteúdos do campo emissor para um campo receptor. Assim as unidades
organizacionais, as unidades de medida ou as conversões próprias, em relação ao cliente podem
ser efetuadas de um sistema para outro.
Existem várias possibilidades para a conversão do conteúdo:
 Atribuíção de constantes ( => SET );
 Atribuíção de intervalos no campo emissor para valores fixados em um campo receptor ( =>
GROUP );
 Combinação de diferentes campos emissores para valores fixados em um campo receptor ( =>
COMBINE );
 Determinação para todos os casos GROUP ou COMBINE não definidos ( => SET_R );
 Conteúdo do campo emissor é escrito por standard no campo receptor, se não tiverem sido
definidas regras de conversão para os campos ( => MOVE ).
Passos para definir uma regra de conversão:
1. Definição da regra: As regras são definidas sempre por segmentos.

2. Atualização da regra: Na atualização da regra determina-se a conversão no nível do campo
com regras definidas.
3. Atribuíção da regra do IDOC: A atribuíção define quando é que a regra deve ser utilizada. É
específico do tipo de emissor/receptor e mensagem.
Página 1 de 66
Definir as regras
Definir aqui uma regra de conversão por cada tipo de segmento.
Exemplo: Definição de uma regra de conversão E1MARRG para o tipo de segmento

E1MARAM.
Atividades:
1. Executar a função.
2. Mudar para o modo de modificação.
3. Entrar com um nome para a regra de conversão bem como o significado dela e o nome do
segmento IDOC para o qual a regra de conversão deve ser válida.
4. Gravar as entradas.
Atualizar as regras
Nesta seção processa-se a segunda etapa de trabalho para a regra de conversão. As regras de
conversão são determinadas por campo.
Nesta etapa determina-se como os campos de um objeto de origem são reproduzidos em um

objeto de destino. Os objetos podem ser, por exemplo, uma data mestre, um registro de dados de
movimento ou um segmento IDOC. A atualização de regras é utilizada para diversos fins. Ela
destina-se, por exemplo, a definir como os registros de um file são representados em dados mestre
ou a definir regras de derivação para dados de movimento. No caso de uma derivação, um registro
de dados mestre é complementado com valores de característica que faltam (derivado). Outra
aplicação consiste na definição da conversão de segmentos IDOC. Aqui modifica-se os valores dos
campos de um segmento.
Diferentes opções por objeto
Os objetos possuem diferentes características estruturais. A validade de dados de movimento

depende, por exemplo, de dados mestre. Por essa razão, na atualização das regras para dados
de movimento é oferecida a opção para verificar os valores com base nos dados mestre. Na
atualização de regras para dados mestre esta opção não é necessária e, portanto, não é
oferecida. Isto tem como consequência que na atualização de regras, dependendo dos objetos
processados, são oferecidas diferentes opções.
Estrutura emissora e receptora
Na atualização determina-se como os campos de uma estrutura emissora são representados nos
campos de uma estrutura receptora. Fala-se de uma estrutura emissora, pois trata-se de um
conjunto de campos selecionados que definem um objeto no R/3. A estrutura emissora
representa a estrutura dos dados transferidos. Ela descreve byte por byte a estrutura dos dados
transferidos. Em contrapartida, os campos de uma estrutura receptora são representados a partir
do objeto a ser lançado. Este objeto é entrado pelo usuário na atualização da estrutura emissora
ou é fixo e proposto para algumas aplicações. Assim, alguns campos, como por exemplo o
mandante, o autor da última modificação, a data de modificação ou o código da moeda, que
são alimentados com uma aplicação específica, não são exibidos. O usuário atribui uma variável
ao campo receptor. Isto permite que o campo seja entrado somente na execução da transferência
de dados. Pode-se, por exemplo, entrar a sociedade ou a empresa por file a ser importado.
Página 2 de 66
A primeira tela
A primeira tela é específica da aplicação. Na primeira tela determina-se a estrutura emissora

para a transferência de dados ou a regra de conversão para a conversão de segmento ou o
aspecto para a derivação. O usuário tem que decidir que tipo de processamento deve ser
utilizado.
A tela de síntese
A segunda tela exibe os campos da estrutura receptora dispostos em forma de tabela. Nesta
pode-se entrar as regras mais frequentemente utilizadas. Estas regras divergem segundo o tipo
do campo:
 Em campos de características pode-se entrar um campo emissor a ser transferido. Campos

de características são aqueles campos que no R/3 desempenham um papel de
características, atributos ou critérios de ordenação como por exemplo, empresa, data de
lançamento, número da ordem. Tecnicamente trata-se dos campos que possuem a categoria
de dados 'C', 'N', 'D' ou 'T', via de regra não são códigos de moeda ou de unidade e não
apresentam uma descrição puramente técnica como, por exemplo, o mandante.
 Em campos que no R/3 desempenham o papel de índices, valores ou saldos,

determina-se uma fórmula. Tecnicamente trata-se de campos com os quais pode-se efetuar
um cálculo. A categoria de dados geralmente é 'P'. Além disso, pode-se determinar um
tipo de conversão de moeda ou uma unidade de destino. É preciso indicar uma operação
global. A operação global determina o que acontece com os valores quando diversos
registros estiverem representados em um mesmo receptor. O campo emissor apresenta, aqui,
uma outra descrição do que os campos de características. A entrada de um campo emissor
somente faz sentido juntamente com a entrada de um valor de campo emissor. As entradas
fazem com que um valor somente seja calculado para o campo receptor se o campo
emissor possuir o valor do campo emissor.
Se o usuário desejar definir outras regras, tem que marcar o campo para poder saltar para as
telas de detalhes da atualização de regras.
A tela de detalhes para a atualização de regras de características
Pode-se utilizar as seguintes regras para as características:
1. Transferir o campo emissor
Atribuir os valores do campo emissor ao campo receptor. Através de Restringir conjunto

de dados, pode-se restringir os valores do campo emissor a serem transferidos para o
campo receptor. Além disso, pode-se indicar condições para outros campos para que a
transferência somente seja efetuada no caso de o registro de dados também conter
determinados valores.
2. Definir a constante
Atribuir um valor fixo ao campo receptor.
3. Definir a variável
Página 3 de 66
Atribuir uma variável ao campo receptor. Isto permite entrar o campo somente ao executar
a transferência de dados. Pode-se indicar, por exemplo, a sociedade ou a empresa por file
a ser importado. Além disso, é possível atribuir um valor fixo à variável.
4. Converter campos emissores
Atribuir determinados valores do campo emissor a um valor do campo receptor. Através de

Condições, determina-se as condições de seleção para os valores dos campos emissores a
serem atribuídos ao valor do campo receptor. Para isso é preciso indicar os campos
emissores a serem convertidos.
Através da indicação de um offset e de um comprimento, pode-se estabelecer que apenas

uma parte do campo emissor deva ser utilizada.
Também é possível indicar uma rotina de conversão. Isto é efetuado no valor do campo
emissor antes da conversão. A rotina de conversão é utilizada para, por exemplo, preencher
os campos com zeros à esquerda.
Com Condições salta-se para uma tela na qual determina-se para valores do campo recetor
quais valores devem estar contidos nos campos emissores. Na coluna esquerda, entra-se os
valores (de destino) do campo receptor. Nas colunas seguintes, entra-se valores individuais
ou intervalos para os campos emissores. Para que um campo receptor obtenha o valor, é
preciso que todos os campos emissores aceitem os valores específicos. Se este campo deve
aceitar mais de um valor, pode-se marcar a linha e pressionar o botão à direita do campo.
Um ícone à direita do campo indica que existe mais de uma condição. Pode-se atualizar
diversas linhas para um valor do campo receptor. No processamento das regras, a primeira
regra adequada é utilizada. A sequência das regras no processamento, porém, não está
definida. Também pode-se estabelecer, explicitamente, o valor inicial para um valor do
campo receptor.
5. Aplicação de regras gerais
Indicar uma regra que deve ser utilizada para diversas transferências. Por exemplo, em
transferências de um sistema R/2 para um sistema R/3, o usuário sempre deseja atribuir a
empresa 00002 à empresa 0003. Para isso, o usuário criou uma regra geral, à qual é feita
referência para a característica 'empresa'.
O usuário pode estabelecer que a regra atualizada no momento deverá ser utilizada como regra
geral. Para tal fim, é preciso indicar um nome e uma descrição. Assim que for feita uma
referência a esta regra, esta não poderá mais ser eliminada. Se o usuário desejar eliminar esta
regra mesmo assim, poderá deslocá-la para a regra que faz a referência.
Opções dependentes de aplicação
Em algumas aplicações, o usuário pode estabelecer o que acontece se um valor de característica

não contiver um valor, apesar das regras.
1. Definir o valor inicial
O valor contém o valor inicial.
2. Classificar como erro
Página 4 de 66
O caso é registrado como erro.
3. Definir a constante
Atribui-se um valor constante ao campo.

4. Transferir campo emissor
Atribui-se o valor de um campo emissor extraordinário.
Dependendo da aplicação, é possível determinar se um valor do campo receptor deve ser

verificado ou se o valor do campo receptor deve passar por uma rotina de conversão (de saída)
especial. Informações detalhadas sobre rotinas de conversão podem ser encontradas na ajuda F1.
Características especiais específicas de aplicação
Ao atualizar as regras de transferência para características relacionadas, é preciso observar

algumas características especiais:
a) É preciso atualizar regras para cada um dos campos. Não é feita nenhuma distinção
entre características relecionadas ou não relacionadas. Se os campos emissores forem
convertidos, o valor da característica, no qual é efetuada a conversão, não é verificado
na atualização de regras. O próprio usuário tem que verificar se o valor da
caracterísitca está correto.
b) Porém, na transferência de dados é efetuada uma verificação completa para a

característica relacionada. Isto significa que é verificado se um valor de característica e os
valores das características, das quais a característica depende, formam uma combinação
válida.
A tela de detalhes para a atualização de regras para índices
Na tela de detalhes determina-se como os valores de índices devem ser agregados, como moedas
ou unidades devem ser convertidas e como o índice deve ser representado no índice receptor.
Pode-se determinar se o índice deve ser sobrescrito no banco de dados ou não. Se o índice
deve ser sobrescrito no banco de dados, o valor determinado a partir dos registros emissores
sobrescreve o valor do banco de dados. Se o índice não deve ser sobrescrito, o valor da
característica será lido a partir do banco de dados. Na operação global, este valor é utilizado
como valor inicial. Depende da aplicação se esta operação é desejada.
Entrar uma operação global. As seguintes operações globais encontram-se à disposição:
SUM, MIN, MAX, LAST, FIRST, COUNT.
Elas apresentam as seguintes descrições: a fórmula do índice é analisada e calcula-se um

resultado. Em seguida, são efetuadas conversões de moedas ou unidades. No caso de diversos
registros de dados serem representados em um registro receptor, soma-se, em seguida, o total
dos resultados em SUM. Em MIN é utilizado o menor resultado, em MAX o maior, em LAST
o último, em FIRST o primeiro. Em COUNT é contado o número dos registros. Na operação
global COUNT, uma fórmula adequada é composta, por exemplo, pelo número '1'. Neste caso,
conta-se o número dos registros emissores representados no registro receptor.
Entrar uma unidade em campos de quantidade, caso não seja feita nenhuma proposta.
Página 5 de 66
É possível que seja efetuada uma conversão de unidade ou de moeda em campos de moeda.
Na conversão de moeda pode-se estabelecer com qual categoria de taxa de câmbio, com qual
taxa de câmbio e com qual moeda deve ser efetuada a conversão para a moeda de destino.
Pode-se criar, para isso, valores fixos para a moeda e para a data da conversão ou campos de
referência que contenham a moeda e a data da conversão. Também pode-se utilizar uma
variável para o tipo de conversão.
Definir a fórmula. As fórmulas de índices são representadas segundo as regras válidas para
impressões do ABAP. Pode-se efetuar cálculos com os campos emissores. A fim de obter uma
visão global dos campos emissores válidos, deve-se posicionar o cursor no campo de entrada e
pressionar F4. Também é possível utilizar variáveis de fórmulas na fórmula.
Com a ajuda de condições pode-se estabelecer que um índice somente deve ser preenchido se
um campo emissor aceita determinados valores. Esta função é necessária, por exemplo, no
exemplo abaixo:
A estrutura emissora contém os campos 'item do balanço' e 'saldo'. A estrutura emissora

contém os índices ATIVO e PASSIVO. Pode-se definir, agora, que o índice ATIVO somente
será preenchido se o campo 'item do balanço' contiver o valor 10000000.
Criar variáveis
Pode-se criar variáveis para valores de características, fórmulas e tipos de conversão para
utilizá-las em regras de transferência. As variáveis para fórmulas e tipos de conversão têm
utilização global. As variáveis para valores de características somente podem ser utilizadas para
o objeto que está sendo processado no momento. Para criar variáveis, selecionar na tela de
detalhes 'Saltar -> Variáveis'. Na tela seguinte, selecionar 'Processar -> Inserir linha'.
Insere-se '&' no campo. Entrar o nome da variável diretamente após este caractere. Selecionar
o tipo de substituição desejado. No tipo de substituição 2 também pode-se indicar as variáveis
no tipo de transação. No momento, este procedimento somente tem suporte na importação de
file e na compactação de aspecto. Para poder utilizar o tipo de substituição 5, é preciso entrar
um valor fixo. A fim de utilizar o tipo de substituição 3, é preciso ativar o módulo de função
EXIT_SAPFKCIM_003 no âmbito de um user exit. Entrar uma descrição da variável. Gravar as
entradas.
Definir conversão de IDOC
Nesta seção é processada a terceira etapa de trabalho para a regra de conversão. As regras de
conversão são definidas para um tipo de mensagem.
A atribuição da regra de conversão ao tipo de segmento é efetuada por sistema emissor e

receptor.
Exemplo:
Para o tipo de mensagem MATMAS é atribuída, por exemplo, a regra de conversão E1MARRG
para o tipo de segmento E1MARAM com sistema emissor e receptor.
Condições
Página 6 de 66
As regras têm de estar criadas e atualizadas com as primeiras duas etapas.
Página 7 de 66
Atividades
1. Executar a função. Entrar o tipo de mensagem ao qual a regra deve ser atribuída.
2. Entrar o sistema emissor e receptor com o tipo de parceiro. O tipo de parceiro é LS em
quase todos os cenários.
3. Entrar o tipo de segmento e a regra de conversão definida para tal.
4. Repetir as etapas dois e três para todas as outras regras.
5. Gravar as atribuições.
Trabalhos periódicos
Nesta etapa são planejados os trabalhos periódicos.
Planejar verificação ativa de consistência
Para verificar regularmente a consistência das opções ALE, escalonar um report que execute
uma verificação automática de consistência. Nesse caso, trata-se do report RBDCONCH.
Se se detetar inconsistência na verificação automática de consistência, aciona-se um evento de
erro correspondente que será analisado pelo tratamento de erros.
Para tal são necessárias as seguintes etapas de trabalho:
 Definir variiantes para o report,

 Planejar jobs com respetivamente o report e uma variante como etapa.
Definir variante
Nesta seção são definidas as variantes para o report RBDCONCH.
Opções standard
Por standard, não estão criadas variantes.
Atividades
 Executar a função e entrar "RBDCONCH", clicar sobre as variantes e selecionar modificar

 Entrar um nome para a variante e selecionar criar
 Preencher os campos de entrada
 Selecionar o botão avançar (F6)
 Atualizar os atributos para a variante
 Gravar a variante
Planejar jobs
Nesta etapa é planejado o job para a verificação da consistência ativa.
Condições
Tem de estar atualizada uma variante para o report RBDCONCH.
Página 8 de 66
Opções standard
Por standard, nenhum job está planejado.
Atividades
 Definir um job com a etapa RBDCONCH e a variante atualizada.

 Planejar o job como job periódico. O período deve estar adaptado às necessidades (por
 exemplo por hora, por dia, etc.).
 Gravar o job.
 Criar um job para cada variante definida previamente.
Planejar monitoring ativo
A monitorização ativa será, regra geral, planejada como batchjob periódico. Será analisado se o
núm.de IDocs que se encontram em um grupo de status ultrapassa um valor limiar. Se este for
o caso, haverá uma notificação na pasta de entrada integrada do recebedor indicado.
Durante a seleção analisar-se-ão os IDocs que cumpram os critérios de seleção. Os valores de

status possíveis de IDocs foram atribuídos a grupos de status. Se o valor de status atual de um
IDoc estiver atribuído a um grupo de status que foi atribuído ao report através de parâmetro,
este IDoc será contado como crítico. Se o núm.de IDocs críticos contados exceder o valor
indicado, a situação será designada como situação problemática e enviar-se-á uma notificação ao
recebedor workflow indicado.
Nessa altura pode planejar-se o report RSEIDOCM, que executará periodicamente a

monitorização ativa.
Definir variante
Nesta seção são definidas as variantes para o report RSEIDOCM.
A entradas válidas são necessárias para o programa de seleção para os campos recebedor e tipo
de recebedor, grupo de status, bem como número crítico de IDocs. Para além disso, a seleção
de IDocs pode ser restringida através de outros parâmetros.
Opções standard
Por standard, não foram criadas variantes.
Atividades
 Executar a função e entrar "RSEIDOCM", clicar nas variantes e selecionar modificar

 Indicar um nome para a variante e selecionar criar
 Preencher os campos de entrada
 Selecionar o botão avançar (F6)
Planejar jobs
Página 9 de 66
Nesta etapa é planejado o job para a verificação ativa da consistência.
Condições
Tem de estar atualizada uma variante para o report RSEIDOCM.
Opções standard
Por standard, não está planejado nenhum job.
Atividades
 Definir um job com a etapa RSEIDOCM e a etapa atualizada.

 Planejar o job como job periódico. O período tem de ser adaptado às necessidades do
 usuário (por exemplo por hora, por dia, etc.).
 Gravar o job.
 Criar um job para cada variante definida anteriormente.
Planejar geração de IDOC a partir de indicadores modificação
Para distribuir as modificações dos dados mestre, tem de ser planejado um report. Este report
lê os indicadores de modificação e gera IDocs.
São necessárias as seguintes etapas de trabalho:
 definir variantes para o report,

 planejar jobs com o report respetivo e uma variante como etapa.
Definir variantes
Nesta etapa são planejadas as variantes para o report RBDMIDOC.
Opções standard
Por standard estão criadas variantes para os tipos de mensagem standard. Estas variantes podem
ser utilizadas.
Atividades
 Criar para cada tipo de mensagem (por exemplo para mestre de materiais, clientes etc.)
 uma variante para o report RBDMIDOC.
 Executar a função e entrar "RBDMIDOC", clicar sobre as variantes e selecionar modificar.
 Entrar um nome para a variante e selecionar criar.
 Entrar o tipo de mensagem (por exemplo MATMAS).
 Atualizar os atributos para a variante.
 Gravar a variante.
 Repetir o processo até estarem criadas variantes para todos os tipos de mensagem de dados
 mestre.
Página 10 de 66
Planejar jobs
Nesta etapa de trabalho são planejados os jobs para a geração periódica de IDocs para os dados
mestre.
Os jobs são planejados por variante definida (isto é por tipo de mensagem).
Exemplo
Para distribuir, por exemplo, o mestre de materiais, tem de ser planejado um job para o tipo
de mensagem (por exemplo MATMAS) que verifica as modificações periodicamente (por
exemplo uma vez por dia) e que gera os IDocs.
Condições
As variantes por tipo de mensagem têm de estar atualizadas.
Opções standard
Por standard, não estão planejados jobs.
Atividades
 Definir um job com a etapa RBDMIDOC e uma das variantes atualizadas.

 Planejar o job como job periódico. O período tem de ser adaptado às necessidades (por
 exemplo por hora, por dia, etc.)
 Gravar o job.
 Criar um job para cada tipo de mensagem de dados mestre.
Planejar distribuição serializada
Para enviar um grupo de serialização são necessárias duas ações:
 primeiro têm de ser gerados os IDocs de um grupo de serialização de seguida são enviados os
IDocs
 Estas duas ações são planejadas no sistema emissor como trabalhos periódicos.
Geração de IDocs
O report RBDSER01 serve para gerar IDocs de um grupo de serialização. O grupo de

serialização a gerar é indicado para este report como parâmetro. O report seleciona todos os
indicadores de modificação de dados mestre atribuídos a este grupo de serialização. Os Idocs
são gerados a partir dos indicadores de modificação.
Enviar IDocs
Após a geração dos IDocs, o report RBDSER02 envia os IDocs a um grupo de serialização. A
este report é dado, como parâmetro, o nome do grupo da serialização a enviar. Para além
disso, é possível especificar os sistemas lógicos para os quais se deve efetuar o envio e qual o
período da geração/modificação do IDoc que deve ser considerado.
Página 11 de 66
Para além disso, o report também planeja o report RBDSER03 que verifica se todos os Idocs
foram enviados com êxito ao sistema receptor. Se tal for o caso, é enviada uma mensagem de
controle do tipo de mensagem SERDAT ao sistema receptor que origina aí o registro do grupo
de serialização. Para esse efeito, indicar nos parâmetros do report RBDSER02, qual o intervalo
de tempo após o envio em que o report RBDSER02 deve ser planejado.
Para além disso, existe a opção de enviar sempre a mensagem de controle, i.e. também nos
casos em que nem todos os IDocs foram transmitidos ao sistema receptor. Assim, pode ser
originado um processamento dos IDocs de entrada no sistema receptor, mesmo quando existem
IDocs na comunicação. Podem surgir problemas de serialização.
Outras observações
É possível planejar ambos os reports RBDSER01 e RBDSER02 um atrás do outro em um job.
O report RBDSER03 também pode ser planejado como job independente. Nesse caso não se deve
indicar a data e a hora.
Para as mensagens que são criadas e enviadas no âmbito de um grupo de serialização não é
necessário planejar a criação dos IDocs a partir dos ponteiros de modificação.
Definir variante
Nesta seção são definidas as variantes para os reports para o planejamento da distribuição
serializada. Geralmente trata-se dos reports RBDSER01 e RBDSER02.
Opções standard
Por standard, não existem variantes criadas.
Atividades
 Executar a função e entrar o nome do report para o qual deve ser definida uma variante.
 Clicar sobre variantes e selecionar modificar.
 Indicar um nome para a variante e selecionar criar.
 Preencher os campos de entrada.
 Selecionar avançar.
 Outras observações
Planejar jobs
Nesta etapa são planejados os jobs necessários para a distribuição serializada.
Condições
As variantes necessárias têm de estar atualizadas.
Página 12 de 66
Atividades
 Definir um job com os reports necessários e as variantes criadas como etapas.

 Planejar o job como job periódico. O período tem de ser ajustado às necessidades (por
 exemplo por hora, por dia, etc.)
 Gravar o job.
 Criar todos os jobs necessários.
 Outras observações
Planejar o envio de IDOCs
Alguns IDocs não são enviados de imediato. São agrupados até serem enviados em conjunto.
Para enviar esses IDocs tem de ser planejado o report RSEOUT00.
São necessárias as seguintes etapas de trabalho:
 definir variantes para o report,

 planejar jobs com o respetivo report e uma variante como etapa.
Efetua-se uma atribuição interna de números aos IDocs enviados. Para esse efeito, é necessário
atualizar intervalos de numeração no ponto opções básicas -> atualizar intervalo de
numeração para IDocs.
Definir variantes
Nesta seção são definidas as variantes para o report RSEOUT00.
Opções standard
Por standard, não existem variantes criadas.
Atividades
 Podem ser atualizados valores diferentes para o envio:
- Porta
- tipo de parceiro, função do parceiro,
- número do parceiro,
- tipo de mensagem.
 A SAP recomenda variantes com número de parceiro e tipo de mensagem.

 Criar variantes correspondentes para o report RSEOUT00.
 Executar a função e entrar "RSEOUT00", clicar sobre variantes e selecionar modificar.
 Entrar o tipo de mensagem (z.B. BLAORD).
 Repetir a operação até estarem criadas variantes para todos os tipos de mensagem.
 Os tipos de mensagem necessários para os cenários individuais estão descritos no ponto
- cenários de distribuição.
Página 13 de 66
Planejar jobs
Nesta etapa, os jobs são planejados por tipo de mensagem.
Condições
As variantes por tipos de mensagem têm de ter sido atualizadas.
Opções standard
Por standard, os jobs não estão atulizados.
Atividades
 Definir um job com a etapa RSEOUT00 e uma variante atualizada.

 Planejar o job como job periódico. O período tem de ser adaptado às necessidades do
 usuário (por exemplo por hora, por dia, etc.).
 Gravar o job.
Planejar conversão de status em execução tRFC com êxito
Se na saída foram transferidos com êxito IDocs para nível comunicação, estes receberão o status
"transferência de dados para porta OK".
Este status não significa que a comunicação através de um RFC transacional tenha sido efetuada
com êxito. Por isso tem que se iniciar um report em períodos periódicos, que verifique se a
comunicação teve êxito e em caso afirmativo modifique o status do IDoc.
Para o planejamento do report RBDMOIND são neccessárias as seguintes etapas de trabalho:
 Definir variante para o job,

 Planejar job com um report e uma variante como etapa.
Definir variante
Nesta etapa cria-se uma variante para o report RBDMOIND.
Opções standard
Por standard, não são entregues variantes.
Atividades
 Executar a função e entrar "RBDMOIND", clicar sobre as variantes e selecionar modificar

 Eliminar a data no campo 'data de geração IDoc (de)'
 Indicar um valor no campo 'IDocs por commit work'
 A SAP recomenda como valor para este campo o número 100
Página 14 de 66
Escalonar job
Nesta etapa é planejado o job para a modificação de status de IDocs enviados com êxito.
Condições
Tem de estar atualizada uma variante para o report RBDMOIND.
Opções standard
Por standard, não está planejado nenhum job.
Atividades
 Definir um job com a etapa RBDMOIND e a variante atualizada.

exemplo por hora, por dia, etc.).
 Gravar o job.
Planejar confirmações Audit
Para utilizar a auditoria ALE, o sistema recebedor de mensagens tem que enviar informações
sobre o estado de processamento de mensagens ao sistema emissor. Isto acontece através do
report RBDSTATE que deverá ser planejado periodicamente no sistema recebedor.
Para tal são necessárias as seguintes etapas de trabalho:
 Definir variantes para report,

 Planejar jobs com respetivamente o report e uma variante como etapa.
Definir variante
Nesta seção são criadas as variantes para o report RBDSTATE. Assim, pode ser determinado para
quais sistemas de quais tipos de mensagem são efetuadas as confirmações audit. A criação de
variantes é efetuada no respetivo sistema receptor da mensagem original.
Exemplo
Para a mensagem 'ORDERS' que é enviada pelo sistema A ao sistema B deve ser efetuada uma
confirmação audit ALE. Para esse efeito, tem de ser criada uma variante do report RBDSTATE
com o sistema receptor lógico 'A' e o tipo de mensagem 'ORDERS' no sistema B.
Atividades
 Podem ser atualizados valores diferentes para as variantes:

- sistema emissor lógico,
- tipo de mensagem,
- variante de mensagem,
- função de mensagem,
- data de criação dos IDocs.
 Criar as variantes correspondentes para o report RBDSTATE.
Página 15 de 66
 Executar a função e entrar "RBDSTATE", clicar sobre as variantes e selecionar modificar.
- O sistema emissor lógico indica para qual sistema deve ser efetuada uma confirmação
audit.
- Especificar tipo de mensagem, variante de mensagem e função de mensagem para quais
mensagens são efetuadas confirmações.
- Se os campos não forem atualizados para a variante, o sistema adopta as opções
possíveis do modelo de cliente de distribuição.
- A data de geração indica o intervalo da seleção. Se esta indicação não for efetuada, serão
consideradas todas as mensagens desde a última execução do report.
 Gerar tantas variantes de modo a considerar todos os fluxos de mensagem para os quais o
audit ALE deve ser efetuado.
Escalonar job
Nesta etapa são planejados os jobs para o audit ALE.
Condições
As variantes do report RBDSTATE a utilizar têm de ter sido criadas.
Atividades
 Definir um job com a etapa RBDSTATE e uma variante criada.

 Planejar o job como job periódico.
 Gravar o job.
Considerar, se possível, que entre o fim do momento da seleção da variante e o momento

execução do job existe um pequeno buffer de tempo para evitar um estouro da fila de Idocs
ainda não processados. nicht abgearbeiteter Zwischenbelege zu verhindern.
Planejar processamento de IDOC
Nesta seção, são planejados jobs para o processamento de entrada. Estes jobs têm de ser
planejados para as situações seguintes:
 Processamento dos IDocs que não são planejados no batch aquando da entrada, mas que são
planejados periodicamente (opções no protocolo de transmissão).
 Planejamento dos IDocs que foram arquivados no sistema, mas que não foram transferidos à
aplicação através das situações excepcionais.
São necessárias as seguintes opções:
 definir variantes para um report,

 planejar jobs com o report e uma variante como etapa.
Página 16 de 66
Um report RBDMANIN permite uma nova importação para a aplicação de IDocs já cancelados
com erros (por exemplo status: 51 erros na transferência para a aplicação). Também existe a
possibilidade de planejar um job com parâmetros selecionados para agrupar IDocs que não
foram processados antes, por exemplo devido a um problema de bloqueio.
Efetua-se uma atribuição interna de números para IDocs recebidos. Para esse efeito, é necessário
atualizar intervalos de numeração no ponto intervalos de numeração -> atualizar intervalo de
numeração para Idocs.
Definir variantes
Nesta etapa são criadas as variantes para o report RBDAPP01.
Opções standard
Por standard, não são entregues variantes.
Atividades
 Definir as variantes com os valores seguintes ou um subconjunto:

 tipo de mensagem lógico
 variante de mensagem
 função de mensagem
 tipo de parceiro do remetente
 número do parceiro do remetente
 função do parceiro do remetente
 SAP recomenda a definição de variantes com o tipo de mensagem lógico e o número do
parceiro. Quais os IDocs que são importados quantas vezes depende das necessidades.
 Criar uma variante para todos os parceiros e tipos de mensagem para os quais não é efetuado
um processamento imediato.
 SAP recomenda definir uma variante sem valores para entrar os restantes IDocs.
Planejar jobs
Nesta estapa são planejados os jobs para o processamento de entrada.
Condições
As variantes por tipo de mensagem têm de ser atualizadas.
Opções standard
Por standard, não estão planejados jobs.
Atividades
 Definir um job com a etapa RBDAPP01 e uma variante atualizada.

 exemplo por hora, por dia, etc.).
Página 17 de 66
 Gravar o job.
 Criar um job para cada variante definida previamente.
 Criar um job com a variante sem valores para importar os IDocs que não foram
 transferidos para a aplicação devido a situações excepcionais.
 Este job tem de ter um período maior do que o período máximo dos outros jobs.
Tratamento de erros
Nesta seção atualizam-se as opções para o tratamento de erros:
 Ligar unidades organizacionais a tarefas standard

 Atualizar administração EDI
 Atualizar código de operação de erros
O tratamento de erros efetua-se no sistema onde ocorreu o erro.
Condições
O tratamento de erros ALE utiliza o workflow. Para cada tipo de mensagem é fornecida uma
tarefa standard para o tratamento de erros.
O modo de funcionamento do workflow é descrito de seguida:
 Para o tratamento de erros gera-se um workitem que será arquivado como mensagem nas
caixas de correio de entrada dos funcionários responsáveis.
 Se um dos funcionários executar o work item, executa-se o método da tarefa standard para
tratamento de erros. Aqui, o usuário tem, por exemplo, a possibilidade de executar novamente
o processamento do IDoc.
 Após um processamento com êxito do IDOC, o work item é eliminado da entrada de todos os
funcionários responsáveis.
Para que o modo de procedimento acima referido possa ser efetuado, os funcionários
responsáveis para um determinado tipo de mensagem e parceiro (emissor ou receptor) têm de ser
determinados da seguinte maneira:
1. É estruturada uma hierarquia de unidades organizacionais (por exemplo "Departamento de

vendas") e cargos efetivos (por exemplo "Responsável pelos clientes, cliente X") e são
atribuídos os funcionários.
2. As tarefas standard para o tratamento de erros (por exemplo para erros na entrada da
ordem) são atribuídas às unidades organizacionais relevantes ou aos cargos efetivos (por
exemplo "Departamento de vendas")
3. Nos protocolos de transmissão é determinado por parceiro e tipo de mensagem qual a

unidade organizacional, o cargo efetivo ou a pessoa responsável pelos erros.
O sistema procede da seguinte maneira aquando de um caso de erro atual:
1. Determinação das pessoas segundo o plano de ocupação da unidade organizacional ou do

cargo efetivo à qual a tarefa standard está ligada.
2. Determinação das pessoas determinadas nos protocolos de transmissão (através do nome

do usuário, cargo efetivo e unidade organizacional).
Página 18 de 66
3. O conjunto de interseção dos dois grupos de pessoas forma o pool de funcionários que
recebem um work item.
Atividades
 Ligar unidades organizacionais a tarefas standard:

 Atualizar administração EDI
 Atualizar código de operação de erros
 Aqui verifica-se a atribuição dos códigos de operação de erros às tarefas standard, em
caso de utilização da comunicação EDI em uma versão anterior.
Criar unidades organizacionais e atribuir tarefas standard
Se ocorrer um erro na expedição ALE, os funcionário responsáveis recebem uma notificação. É

necessário atribuir os funcionários a uma unidade organizacional e efetuar uma atribuição da
unidade organizacional, do cargo efetivo ou do funcionário responsável pelo processamento de
erros especiais.
As unidades organizacionais são partes da estrutura organizacional da empresa. A estrutura

organizacional consiste basicamente de unidades organizacionais e da sua ligação entre si.
Também contém cargos efetivos ligados às unidades organizacionais e aos quais os titulares
(pessoas, funcionários, usuário) podem ser atribuídos.
Nesta seção determina-se a estrutura organizacional da empresa (se ainda não tiver sido
efetuado) e liga-se os elementos individuais às tarefas correspondentes.
No standard existem tarefas standard da SAP para o tratamento de erros. A ligação origina em
caso de erro uma mensagem às pessoas responsáveis. Têm de ser ligadas as seguintes tarefas
standard para os seguintes casos de erro:
 Erros técnicos,
 erros sintáticos,
 erros no registro na aplicação (para cada tipo de mensagem).
Exemplo
 A tarefa standard "ALE/EDI: tratamento de erros (entrada)," é atribuída à unidade

organizacional "vendas".
 No âmbito do protocolo de transmissão determina-se, por exemplo, o Senhor Müller das
vendas para a comunicação com o sistema lógico "K11MAND005" (vendas dec."Sul").
 Se ocorrer um erro no registro de um IDocs das vendas "Sul", o Senhor Müller recebe um
work item na sua entrada.
Opções standard
A SAP entrega tarefas standard para o tratamento de erros sem ligações.
As tarefas standard para erros técnicos e de sintaxe estão atribuídos ao ALE no customizing de
tarefas.
As tarefas standard para os erros no registro estão atribuídas às aplicações individuais. As

tarefas standard ligadas por cenário encontram-se no capítulo cenários de distribuição. Estas
tarefas standard têm de ser ligadas de acordo com o cenário de aplicação. (As tarefas para
Página 19 de 66
"ORDERS erro de entrada" e "ORDCHG erro de entrada" têm de ser ligadas, por exemplo,
nas vendas para o cenário SD para a ordem de cliente.)
Atividades
1. Executar a função e criar uma nova unidade organizacional ou modificar uma já existente.
2. Posicionar o cursor na unidade organizacional e selecionar plano de ocupação.
3. Posicionar o cursor sobre a unidade organizacional e selecionar criar cargo efetivo, para
criar um novo cargo efetivo para a unidade oranizacional. Repetir a ação até ter atribuído
todos os cargos efetivos à unidade organizacional.
4. Posicionar o cursor sobre o cargo efetivo e selecionar atribuir titular..., para atribuir um
novo usuário como titular ao cargo efetivo. Repetir a ação até ter atribuído todos os
titulares ao cargo efetivo.
5. Para a atribuição das tarefas standard a uma unidade organizacional ou a um cargo
efetivo, posicionar o cursor sobre a unidade correspondente e selecionar perfil de tarefas.
6. Posicionar o cursor de novo na posição à qual a tarefa standard deve ser atribuída
selecionar atribuir tarefa.... Indicar a tarefa standard pretendida.
As seguintes tarefas standard têm de ser sempre ligadas:
- ErrorProcOutALE/EDI: tratamento de erros (saída),

- ErrorProcInbALE/EDI: tratamento de erros (entrada),
- SynErrorOutALE/EDI: erro de sintaxe (saída),
- SynErrorInbALE/EDI: erro de sintaxe (entrada),
- ErrorMessageenviar mensagens de erro.
A verificação de consistência automática causa, em caso de inconsistências, eventos de erro

para as seguintes tarefas standard. Na utilização da verificação de consistência automática
também têm de ser ligadas estas tarefas standard:
- AleLinkTechALELINK: verificação de consistência técnica

- AleLinkApplALELINK: verificação de consistência de aplicação
AS tarefas standard entregues pela SAP para erros no registro na aplicação têm geralmente
o nome específico do tipo de mensagem '<tipo de mensagem>_Error'.
Para IDocs gerados de BAPIs é acionada, em caso de erro, a seguinte tarefa standard para
a qual também é necessária uma ligação:
- BAPI_IDOC_ERBAPI-IDoc erro de entrada
Para erros na transmissão de IDocs a um sistema R/2, utiliza-se a tarefa standard

ALEResendErr.
7. Repetir as etapas 5 e 6, até todas as tarefas standard estarem atribuídas.
No ponto "atualizar código de operação " atribuem-se tarefas standard aos códigos de operação
de erro. Aqui são entrados os números que se encontram nas informações detalhadas. Um
exemplo de seguida:
Tarefa standard nome descrição

TS00007989 ErrorProcOut ALE/EDI: tratamento de erros (saída),
TS00008074 SynErrorInb ALE/EDI: erro de sintaxe (entrada)
Página 20 de 66
Em caso de perguntas relativas à função da atribuição de tarefas standard ler o guia de
implementação base -> administração de workflow.
Atualizar administração EDI
Atualizar código de processo de erro
Nesta seção, a atribuição dos códigos de operação de erro às tarefas standard tem de ser
verificada em caso de utilização da comunicação EDI em uma versão anterior. Esta atribuição
também tem de ser atualizada para os desenvolvimentos próprios.
Conselho
Verificar, por um motivo de segurança, se a atribuição corresponde à tabela listada embaixo.
Atividades
1. Executar a função. A tabela tem de conter as entradas listadas de seguida para o

tratamento de erros ALE:
Código tarefa descrição versão

EDII TS00008068 ErrorProcInb 2
EDIO TS00007989 ErrorMessage 2
EDIX TS00008070 SynErrorOut 2
EDIY TS00008074 SynErrorInb 2
EDIM TS00007988 ErrorMessage 2
A tabela contém a atribuição do código de operação de erros (por exemplo EDII) às tarefas
standard (por exemplo TS00008068) na versão 3.0 (aqui codificada pelo 2).
No caso de uma utilização de EDI em uma versão anterior, ainda existem aqui atribuições das
tarefas standard das versões antigas para os códigos de operação EDII e EDIO. A entrada de
novas tarefas causa problemas no processamento ALE.
Desenvolvimentos
As funções para o desenvolvimento de cenários ALE e as funções encontram-se no menu R/3

sob ferramentas -> Business Framework -> ALE -> desenvolvimento.
Administração de autorizações
Na seção "Administração de autorizações"
 são definidas as autorizações para os objetos de autorização diferentes

 são compactadas as autorizações para os perfis de autorização.
Determinar autorizações
Esta seção informa quais os objetos de autorização que estão definidos para as funções ALE
individuais na entrega standard SAP. As autorizações para estes objetos podem ser atualizadas
no sistema SAP.
Página 21 de 66
Objetos de autorização
A lista seguinte indica quais os objetos de autorização que são verificados partir de quais
classes de objetos nas funções individuais.
Funções para...
Objeto Texto
Em classe de objeto base - administração:
Customizing:
S_TABU_DIS atualização de tabela (via ferramentas standard)

S_TABU_CLI atualização de tabelas tabela independente de mandante
em classe de objeto objetos de autorização válidos para todas as aplicações:
Recebimento de IDOC:
B_ALE_RECV ALE/EDI: receber IDOCs
Sistemas lógicos:
B_ALE_LSYS ALE/EDI: atualização de sistemas lógicos
Modelo de distribuição:
B_ALE_MODL ALE/EDI: atualização Modelo de cliente de distribuição
Redução:
B_ALE_REDU ALE/EDI: geração de mensagens
Dados mestre:
B_ALE_MAST ALE/EDI: distribuição de dados mestre
Em classe de objetos base - funções centrais:
Monitorização:
S_IDOCMONI WFEDI: acesso a monitorização IDOC
Funções IDOC:
S_IDOCCTRL WFEDI: acesso geral a funções IDOC
S_IDOCDEFT WFEDI: acesso a desenvolvimento IDOC
Comunicação:
S_IDOCPORT WFEDI: Acesso a declaração de portas (IDoc)
S_IDOCPART WFEDI: acesso a perfil de parceiro (IDoc)
Em classe de objetos base - ambiente de desenvolvimento
Dados de controle:
S_TRANSPRT Workbench Organizer e sistema de transporte
Os campos correspondentes a todos os objetos de autorização podem ser exibidos. O conteúdo

destes campos é verificado na verificação da autorização pelo sistema SAP. Se o conteúdo não
Página 22 de 66
coincidir com a característica do objeto de autorização para o usuário, este não tem autorização
para processar o objeto.
Conselho
No caso da definição de autorizações próprias, as denominações devem ser iniciadas com as

letras Y ou Z, uma vez que estes conjuntos de nomes estão livres na entrega standard SAP.
Atividades
1. Verificar as autorizações entregues
Selecionar as classes de objetos 'objetos de autorização válidos para todas as aplicações' 'base -
administração', 'base - ambiente de desenvolvimento' e 'base - funções centrais'. Recepção dos
objetos de autorização ALE. Selecionar um objeto. Recepção da lista das autorizações para este
objeto.
2. Se necessário, criar novas autorizações
Selecionar autorização -> criar. Entrar a autorização e um texto breve. Selecionar um campo
para atualizar os valores de campo individuais. Gravar a nova autorização e ativá-la.
Considerar tanmbém os objetos de autorização da base e, se necessário, de outras aplicações.
Página 23 de 66
Determinar perfis
Opções standard
Na entrega standard de SAP, os perfis estão pré-fixados.
Atividades
1. Verificar os perfis standard.

2. Criar novos perfis, se necessário.
Página 24 de 66
PASSOS UTILIZADOS PARA A CONFIGURAÇÃO
DE AMBIENTE PARA USO DE IDOC.
Transação: SALE.
Instalar Sistema Lógico:
 Sistema lógico Denominação
 LOGEXTERN Sistema Lógico Externo

 LOGSYS010 Sistema Lógico para o Mandante 010
 Atribuir Sistema Lógico ao Mandante
Mand. Denominação Cidade Moeda modific.em

 000 SAP AG Walldorf DEM
 001 Auslieferungsmandant R11 Kundstadt XEU
 005 Sandbox BRL 24.09.1998
 010 Sandbox Belo Horizonte BRL 05.04.1999
 015 Client - Anna BH BRL 23.03.1999
 020 Client - Teste Profile CpBH BRL 21.01.1999
 066 EarlyWatch Walldorf DEM
 Modelo distribuição
 GETSTART GetStart
 COSMAS Master centro de custo

 DEBMAS Mestre de cliente
 DOCMAS Documento mestre
 FIDCC1 Envio de documentos FI c
 FIPAYM Dados de pagamento
Página 25 de 66
 Atualizar modelo de distribuição
 Distribuição de dados mestre

 Reduzir estruturas intermediárias p/dados mestres
 Gerar ordem de transporte para tipo de mensagem
 Ativar indicador de modificação

 Ativar o indicador de modificações (geral)
 Ativar o indicador de modificação para tipos de mensagem
 para o sistema Distribuição via classes

 Atualizar os tipos de classes
 Atualizar classes
 Atribuir classes lógico
 Incluir classes no modelo de distribuição
 Distribuição serializada
 Criar grupos de serialização
 Atribuir tipos de mensagem
 Atualizar modelo de distribuição
 Definir processamento na entrada
 Distribuíção de Dados de Controle.
 <=== LOGSYS010 Sistema Lógico para o Mandante 010

 FIDCC1 Envio de documentos FI completos (use
 ===> LOGEXTERN Sistema Lógico Externo

 FIDCC1 Envio de documentos FI completos (use
Página 26 de 66
 Verif. consistência
 Consistência técnica
 FIDCC1 Envio de documentos FI compl
 SYNCH Comunicação síncrona (ex: ve
 aplicação
 Consistência dados controle
 FIDCC1 Envio de documentos FI compl
Comunicação
Destinos RFC
 Conexões R/3
 LOGSYS015 Sistema Lógico LOGSYS015
 LOGSYS020 Sistema Lógico LOGSYS020
 SAPOSS Sistema de serviço online SAP (CSE)
 TMSADM@UT0.DOMAIN_UT0 TMS Communication Interface *gener
 TMSSUP@UT0.DOMAIN_UT0 TMS Communication Interface *gener
 UT0
 Conexões internas
 BACK Servidor de aplicação UT0
 NONE Servidor de aplicação UT0
 ubhz01e4_UT0_00 Servidor de aplicação UT0 >ativo<
 Destinos lógicos
 LOGEXTERN DESTINO RFC/EXTERNO
 WORKFLOW_LOCAL_010 RFC destination for SAP Business Wo
 Conexões TCP/IP
 Ligações por driver ABAP/4
 Atribuir destino RFC ao Sistema Lógico
Sist.lóg. Destino RFC

----------------------------------------
LOGSYS010 LOGEXTERN
Página 27 de 66
 Gerar Protocolos de Transmissão
Visão modelo GETSTART

Sist.parceiro LOGEXTERN
Receptor de Mensagem
Tipo US Usuário
ID UZ02160 Marcos Vieira
Parametro de Saída
Versão: 3 = Tipos de registro IDoc a partir da versão

Tamanho pacote: 100 IDocs
Modo de Saída
(X) Transferir imediatamente IDoc
( ) Agrupar e transferir IDocs
Parametro de Entrada
(X) Processamento imediato

( ) Background, possível substituição através de código express
( ) Background, sem substituição através de código express
 Atualização manual de protocolos de transmissão
 Definir Portas
 Portas
 RFC assíncrono
 A000000015 Conexão ALE com mandante 020
 A000000016 Teste de transferência de dados mestres entre os m
 A000000018 DESTINO RFC/EXTERNO
 File
 PORTEXTERN Porta Externa p/Envio de Arquivos Textos - IDOC
 Sistema R/2
 Internet
 Atualizar o protocolo de transmissão
Nº parceiro Tp.Funç. Tipo mensagem Variante

Função Test
LOGEXTERN LS COSMAS
LOGEXTERN LS DEBMAS
LOGEXTERN LS FIDCC1
LOGEXTERN LS FIPAYM
Nº parceiro Tp.Funç. Tipo mensagem Variante

Função Test
LOGSYS010 LS COSMAS
LOGSYS010 LS DEBMAS
LOGSYS010 LS FIDCC1
Página 28 de 66
LOGSYS010 LS FIPAYM
Página 29 de 66
Desenvolvimento de Segmentos
Tipo de segmento: Z1CSKS

Descrição breve: Master centro de custos registro mestre (CSKS) - ampliação
Definiç.segmento: Z2CSKS000
Última modific. Por: UZ02160
Posi Nome de campo Elemento de dados Cpo.cód Cmpr.

1 MSGFN MSGFN 3
2 MANDT MANDT 3
3 KOKRS KOKRS 4
4 KOSTL KOSTL 10
5 BKZKP BKZKP 1
Tipo de segmento: Z1CSKT

Descrição breve: Master centro de custo textos (CSKT)
Definiç.segmento: Z2CSKT000
Última modific. Por: UZ02160
Posi Nome de campo Elemento de dados Cpo.cód

Cmpr.
1 MSGFN MSGFN 3
2 LTEXT KLTXT 40
Desenvolvimento de Tipos de Idoc
 ZCOSMAS2 Idoc Centro de Custo para o Legado

 Z1CSKS Master centro de custos registro mestre (CSKS) - ampliação
 Z1CSKT Master centro de custo textos (CSKT)
Página 30 de 66
TRANSAÇÕES QUE ENVOLVEM IDOC
BD20 Transmitir IDoc à aplicação

BD41 Enviar IDocs de um grupo
BD42 Verificar IDocs de grupo
BD43 Registrar IDocs de um grupo
BD73 Registrar novamente IDOC's (ALE)
BD79 Atualização regras de conversão IDOC
BD83 Enviar IDocs após erro ALE
BD84 Registrar IDocs após erro ALE
BD87 Processar IDOCs de entrada
BD88 Processar IDOCs de saída
BDM2 Monitoring: IDOCs com receptor
KE2T CO-PA: atribuição de campos IDOC
MCZ4 Criar estrutura IDoc
MCZ5 Modificar estrutura IDoc
MCZ6 Exibir estrutura IDoc
OYEA Administração IDoc
OYEB Acoplamento eventos p/entrada IDoc
OYSN Intervalo numeração IDocs
VEI1 IDOC exib.importação
VEI2 IDOC exib.exportação
VEI6 EDI: lista IDoc base de importação
WE06 Monitorização ativa p/IDoc
WE12 Teste IDoc: entr.file saída modif.
WE15 Teste IDoc: saída desde CM
WE16 Teste IDoc: entrad.file entr.orig.
WE17 Teste IDoc: entrada file status
WE19 IDoc: entrada ferramenta de teste
WE30 Editor tipo IDoc
WE31 Editor p/segmentos tipo IDoc
WE33 Valor do campo p/documentação IDoc
WE46 Administração IDoc
WE55 IDOC: módul.funç.para nomes caminho
WE57 IDoc: mensagens e objs.de aplicação
WE60 Documentação p/tipos de IDoc
WE61 Documentação p/tipos registro IDoc
WE63 Analis.sintát.p/tps.IDoc e tp.reg.
WE72 Conversão chave: tps.IDoc
WE82 EDI: atribuição IDOC<->ctg.mensagem
WE84 EDI: atribuição cmps.IDOC e aplicaç.
WJB3 Teste: importar IDOC lista sortim.
WPCC Editar IDocs modif.catálogo produtos
WPCI Editar IDocs catálogo de produtos
WPCJ Editar IDocs itens catálogo produtos
WPIA Repetir a entrada dos IDocs POS
WPIE Entr.IDocs modificados
WTR1 Solicitação IDoc meios aux.vendas
Página 31 de 66
TRANSAÇÕES QUE ENVOLVEM ALE
AWW1 Iniciar infos imobilizado via ALEWEB

BALA Menu aplicação ALE
BALD ALE desenvolv.
BALM ALE dds.mestre
BD63 Transporte de tabs.ALE p/ ctg.mensg.
BD73 Registrar novamente IDOC's (ALE)
BD83 Enviar IDocs após erro ALE
BD84 Registrar IDocs após erro ALE
BD95 Atualizar ctgs.obj.ALE
BD98 Verif.consistência ALE ativa
BDA4 Atualizar ctgs.obj.ALE
BDBG Gerar interface ALE (BAPI)
BDM7 Audit ALE: avaliações estatísticas
BDM8 Audit ALE: enviar confirmação
F8BK Atualiz.meios pagto.compatíveis ALE
KE75 EC-PCA: chamar centro de lucro ALE
KE77 EC-PCA: enviar centro de lucro ALE
KE78 EC-PCA: executar rollup export.ALE
KE79 EC-PCA: enviar hierarquias ALE
MAL1 Criar material através de ALE
MAL2 Modif.material através de ALE
MC7E Configuração ALE para estrutura info
MM90 Analis.log aplicação mestre mat.ALE
MM91 Prot.aplic.mestre mat.ALE eliminar
OMKY Conexão sistema externo via ALE
OMT2 Controle campos obrig.MM-BD ALE / DI
OYE4 Exibição das portas ALE
PFAL HR ALE: distrib.completa infotipos
RE_RHAL EACU Auto customizing for HR ALE
RE_RHAL ESMD HR-ALE: Change Pointer for HR MData
Página 32 de 66
TIPOS DE IDOC
Tipo básico Descrição
ABSEN1 Presenças/ausências em KK1

ACCONF01 Confirmação do processamento do IDoc da aplicação
ACC_ACT_ALLOC01 Contabilidade: lançar alocação de atividade
ACC_BILLING01 Contab.: lançar doc.de faturamento (OAG: LOAD RECEIVABLE)
ACC_EMPLOYEE_EXP01 FI-CO: lançamento HR LB (AcctngEmplyeeExpnses)
ACC_EMPLOYEE_PAY01 FI-CO: lançamento HR SC (acctngEmplzeePaybles)
ACC_EMPLOYEE_REC01 FI-CO: lançamento HR RR(AcctngEmplyeeRcvbles)
ACC_GOODS_MOVEMENT01 Contabilidade: lançar mov.de mercadoria (OAG: POST JOURNAL)
ACC_INVOICE_RECEIPT01 Contabilidade: lançar entrada de fatura (OAG: LOAD PAYABLE)
ACC_PRIM_COSTS01 Contabilidade: lançar custos primários
ACC_PURCHASE_ORDER01 Contabilidade: lançar pedido
ACC_PURCHASE_REQUI01 Contabilidade: lançar requisição de compra
ACC_REVENUES01 Contabilidade: lançar receitas
ACC_SENDER_ACTIVITIES01 Contabilidade: lançar atividades prestadas
ACC_STAT_KEY_FIG01 Contabilidade: lançar índices estatísticos
ACLPAY01 Posting in accounting: Inbound invoice
ACLREC01 Posting in accounting: Billing document
ACPJOU01 Posting in accounting from materials management
ACTIV3 Units in KK3
ACTIV4 Units in KK4
ALEAUD01 Confirmações sobre status de processamento de IDocs entrada
ALEREQ01 General request - Basis IDoc type
ARTMAS01 Criar e modificar dados mestre de material (varejo)
ASSMOD01 Sortimentos (módulos manuais)
BATCH5 Lote em KK5
BETMAS01 Site master data distribution ALE
BLAORD01 Contratos de compra
BLAORD02 Contratos de compra
BLAREL01 Contract
BOMDOC01 Mestre lista técnica - documento
BOMMAT01 Mestre lista técnica - material
BTC_ID01 Ordem de processo com componentes
BTC_ID02 Requisição de compra do sistema standard
BTC_ID03 Compromisso de produção com o sistema standard
CBPRCP01 Rough-cut planning profile
CHRMAS01 Mestre característica dados básicos
CHRMAS02 Característica mestre com dependência de objetos
CLFMAS01 Mestre classificação de objetos
CLSMAS01 Master class
CLSMAS02 Distribuição de classes com dependência de objetos
CMREQU01 TR-CM: Invitation to TR-CM system to send data
CMSEND01 TR/CM-IDOC: Transfer of TR-CM data
CNPMAS01 Perfil de configuração mestre
COACOR01 Core master tipo de atividade
Página 33 de 66
COACTV01 IDOC para centro de custo/tipo de atividade
COAMAS01 Mestre tipo de atividade
COCOKA01 Segmento de controle objeto CO/classe de custo
CODCMT01 IDOC para um documento CO
COELEM01 Classes de custo: distribuição dos dados mestre
COGRP01 IDOC para grupos de CO (p.ex.grupos de centros de custo)
CONDAT01 Change to customizing data
COND_A01 Intercâmbio de condições: dds.mestre p/a determinação preço
CONF11 Confirmações em KK1
CONF21 Confirmations in KK2, time events
CONF32 Confirmations in KK3, wage slips
CONF42 Confirmations in KK4, wage slips
CONF51 CC5 confirmations run schedules
COPAGN01 CO-PA entry
COPCPA01 Transferir cálculo de custos do produto CO-PC -> CO-PA
COPCPA02 Copiar cálculo de custos do produto
COSCOR01 Core master centro de custo
COSMAS01 Master centro de custo
COTOTL01 IDOC para registros de totais CO
CRECOR01 Vendor master data distribution ALE Core master data
CREMAS01 Credor distribuição de dados mestre ALE
CRESTA01 Repetir status de crédito (DebtorCreditAccount)
DEBCOR01 Core master - customer
DEBMAS01 Cliente mestre
DELFOR01 Delivery schedule/JIT schedule
DELVRY01 Delivery interface
DESADV01 Shipping notification
DES_ID01 Aviso de entrega
DIFFE2 Differences in KK2
DISTU2 Reasons for problems KK2
DOCMAS01 Master document
DOCMAS02 Documento 02
DOCMAS03 Documento
DWLOAD Download transceiver configuration
ECMMAS01 Estrutura IDOC para controle de alterações
EKSEKS01 Dados do doc.compra para o sist.info compras
EXPINV01 IDOC doc.faturamento export.(E.F.I.)
EXPINV02 Comério externo -IDoc doc.faturamento
EXTWA1 Rúbricas salariais externas
FIDCCH01 IDOC p/modificações de um doc.FI (bloqueio contra reclam.)
FIDCCP01 IDoc: documento FI completo
FIDCMT01 IDoc para documentos FI
Página 34 de 66
FINSTA01 Account Statement, Lockbox, Polling Info
FIPARQ01 IDoc para dados de pagamento FI
GLCORE01 Documentation deleted
GLDCMT01 IDoc para rollups GLX
GLMAST01 Dados mestre contas do Razão: IDoc máximo
GSVERF01 IDOC entrada procedimento de nota de crédito
HRCNF01 Aceitar confirmações (TimeMgtConfirmation)
HRKK1ABSR HR TIM KK1: motivos de presença/ausência permitidos
HRKK1EWUP HR TIM KK1: confirmação de rubricas salariais externas
HRKK1EXWT HR TIM KK1: rubrs.sals.extrns.permitidas
HRKK1PERS HR TIM KK1: mini registro mestre HR para registro de horas
HRKK1TBAL HR TIM KK1: saldos de horas empregado
HRKK1TEUP HR TIM KK1: confirmação de eventos com registro hora pessoal
HRKK1TEVT HR TIM KK1: tipos de evento com registro de hora permitidos
HRKK1WRKC HR TIM KK1: centros de trabalho permitidos
HRMD_A01 HR: Master and organizational data (application system)
HRMD_A02 HR: Master and organizational data (application system)
HRMD_B01 HR: Master and organizational data (basis system)
HRPAYP01 HR - transmissão FI/CO
HRPLL40 Confirmações de logística p/gerenciamento recursos humanos
HRTRPR01 Transferência TRV-PAY(PayrollTravelExpnses)
HRTRVL01 HR-TRV: transferência despesas de viagens FI/CO
HRTRVL03 HR-TRV: transferência despesas de viagem folha de pagamento
IDCREF01 Mensagem de refer.como parêntese lóg.p/assinatura eletrônica
IMPINV01 Import Basis IDoc (I.B.I.)
INFREC01 Purchasing info record
INVCON01 Dados de modificação de estoque p/o controlling de estoque
INVOIC01 Fatura/doc.faturamento
INVOIC02 Fatura/doc.faturamento
INV_ID01 Fatura
KNOMAS01 Depend.objetos mestre: dados básicos
LABELS00 ISR labeling: label
LIKOND01 Condições de catalogação
LIS_EXTR LIS inbound interface for external data
LOCAT5 Location in KK5
LOIBOM01 Mestre lista técnica
LOICAL01 Mestre calendário
LOINUM01 Número dos IDOCs enviados
LOIPGR01 IDOC for product group
LOIPLO01 Mestre ordem planejada
LOIPRO01 Mestre ordem de produção
LOIRNH01 Mestre hierarquia/diagramas de rede
LOIROU01 Mestre roteiro
LOIRSH01 Mestre cabeçalho da ordem de produção repetitiva
LOISTD01 Mestre lista de estoques/necessidades
LOITMX01 Matriz de transição
LOIWCS01 Mestre centro de trabalho
LOIWCS02 IDoc mestre centro de trabalho
Página 35 de 66
LPIPCM01 Campanha de produção
MALFK5 CC5 reasons for scrap
MATCOR01 Core master material
MATMAS01 Mestre material
MRESCR01 Criar reserva
OPERA2 Operations in KK2
OPERA3 Processes in KK3
OPERA4 Operations in KK4
OPERS3 Operation status in KK3
OPERS4 Operation status in KK4
ORDERS01 Compras/venda
ORD_ID01 Solicitação/cotação/pedido/modificação do pedido
OSTAT2 Status da operação KK2
PALMAT01 Atribuição de centro para lista técnica material
PEROP2
PERSO1 Registros mestres HR em KK1
PERSO2 Registro mestre HR em KK2
PERSO4 Registro mestre em KK4
PEXR2001 Pag./aviso de pag./exib.nota crédito/exib.débitos lançados
PKHD5 KK5 Circuitos reguladores Kanban
PKPS5 KK5 recipiente kanban
PKST5 KK5 Status para container Kanban
PLANT3 Centros em KK3
PORDCR01 Criar pedido
PRCMAS01 Registro mestre de centro de lucro
PRDCAT01 Catálogo de produtos
PRDPOS01 Item do catálogo de produtos
PREQCR01 Criar req.compra
PREQDL01 Eliminar/concluir req.compra
REQUI1 Solicitação de confirmação em KK1
RSINFO BIW: IDoc info sobre os transportes de dados
RSREQUST BIW: requisição de dados a OLTP
RSSEND BIW: enviar dados do sistema de origem para BIW (modelo)
SAPRDI01 SAPscript Raw Data Interface IDOC Type
SCS02O01 External PO qt (semi conductor)
SCS99N01 Semiconductor supply qt
SDPAID01 Confirmação dados elemento de expedição p/entrega ao cliente
SDPIID01 Confirmação de dados de picking para entrega ao cliente
Página 36 de 66
SDPIOD01 Mensagem de picking ao subsistema:
SERDAT01 Dados de controle serialização
SHPMNT01 Shipment
SHPMNT02 Shipment
SISCSO01 SISD - ordem do cliente
SISDEL01 VIS - delivery
SISINV01 SISD - documento de faturamento
SOPGEN01 Distribuição da estrutura de info geral
SRCLST01 Lista de opções de fornecimento
SRVMAS01 Registro mestre de atividades com textos
SYIDOC01 CA-EDI: Transport of IDoc types
SYNCHRON Tipo de IDOC dummy para comunicação síncrona
SYRECD01 CA-EDI: Transport of IDoc record types
SYSTAT01 CA-EDI: Transfer from status records
TPSDLR01 Seleção via variante de um sistema externo
TPSDLS01 Envio de docs.remessa p/um sistema de planej.transporte
TPSLOC01 Envio de dados mestre local p/um sist.planej.transporte
TPSSHT01 Envio de transportes planejados do sistema de transportes
TXTRAW01 WF-EDI: Transferring free text to SAPoffice format 'RAW'
UNIMA2 Unidades de medidas alternativas com referência ao material
UNIT2 Unidades em KK2
UNIT3 Unidades no KK3
UPLOAD Configuração de transceiver para upload
VTAMAS01 Mestre tabela de variantes
VTMMAS01 Mestre atualização conteúdo de tabela
WBBDLD01 Lista de sortimento: dados de material
WBBDLD02 Lista de sortimento: dados de material (rel.4.0)
WBB_ID01 Order book: Product message
WGSREQ01 Order receipt IS-R
WGSREQ02 IDoc ordem de filial (incl.segmento de condição)
WMBIID01 Bloquear posições no depósito
WMCAID01 Estorno/solicitação de estorno ordem de transporte
WMINID01 Texto info para o acoplamento de subsistemas
WMIVID01 Entrar resultados da contagem
WMMBID01 Movimentos de mercadorias para entrada de dados móveis
WMMBID02 Movimentos de mercadorias de sistemas externos
WMRRID01 Liberação nº referência
WMSUID01 Movimentar unidade de depósito
WMTCID01 Confirmar ordem de transporte
WMTCID02 Confirmar ordem de transferência
WMTOID01 Transport request
WMTRID01 Necessidade de transporte
WORKC2 Centros de trabalho em KK2
WPDCUR01 Interface POS: download taxas de câmbio
WPDNAC01 Interface POS: download artigos pertencentes
Página 37 de 66
WPDSET01 Interface POS: download atribuições de set
WPDTAX01 Interface POS: download taxas de imposto
WPDWGR01 Interface POS: download mestre de grupo de mercadorias
WPUBON01 Interface POS: upload docs.vendas (recibos) não compactados
WPUERR01 POS interface: Upload messages FWWS/POS/SCS
WPUFIB01 Interface POS: upload interface contab.financ.FWWS/POS
WPUKSR01 Interface POS: upload dos dados do caixa p/estatística POS
WPUTAB01 Interface POS: upload encerramento do dia POS
WPUUMS01 Interface POS: upload dados de vol.vendas compactados
WPUWBW01 Interface POS: upload movimentos de mercadorias
WP_EAN01 Interface POS: upload e download atribuições EAN
WP_PER01 Interface POS: upload e download dados de pessoas
WP_PLU01 POS interface: Upload/Download article master
WP_PLU02 Interface POS: material e condição (entrada e saída)
WTADDI01 Meios aux.vendas
WVINVE01 Store phy.inv.: phy.inv. docs outbound; count data inbound
WVINVE02 Invent.filial: saída docs.invent., entrada dados contagem
Página 38 de 66
EDI: categorias de mensagens lógicas
Mensagem lógica Descrição breve
ABSEN1 Presenças/ausências em KK1

ACCONF Confirmação do processamento do IDoc da aplicação
ACC_ACT_ALLOC Contabilidade: lançar alocação de atividade
ACC_BILLING Contab.: lançar doc.de faturamento (OAG: LOAD RECEIVABLE)
ACC_EMPLOYEE_EXP FI-CO: lançamento HR LB (AcctngEmplyeeExpnses)
ACC_EMPLOYEE_PAY FI-CO: lançamento HR SC (acctngEmplzeePaybles)
ACC_EMPLOYEE_REC FI-CO: lançamento HR RR(AcctngEmplyeeRcvbles)
ACC_GOODS_MOVEMEN Contabilidade: lançar mov.de mercadoria (OAG: POST
T JOURNAL)
ACC_INVOICE_RECEIPT Contabilidade: lançar entrada de fatura (OAG: LOAD PAYABLE)
ACC_PRIM_COSTS Contabilidade: lançar custos primários
ACC_PURCHASE_ORDE Contabilidade: lançar pedido
R
ACC_PURCHASE_REQUI Contabilidade: lançar requisição de compra
ACC_REVENUES Contabilidade: lançar receitas
ACC_SENDER_ACTIVITIE Contabilidade: lançar atividades prestadas
S
ACC_STAT_KEY_FIG Contabilidade: lançar índices estatísticos
ACLPAY Contabilidade: fatura recebida
ACLREC Contabilidade: doc.faturamento
ACPJMM Lançamento na contabilidade proveniente da adm.material
ACTIV3 Unidades no KK3
ACTIV4 Unidades no KK4
ALEAUD Confirmações sobre status de processamento de IDocs entrada
ALEREQ Mensagem geral de solicitação
ARTMAS Criar e modificar dados mestre de material (varejo)
ASSMOD Sortimentos
BATCH5 KK5 lote
BETMAS Mestre cent.
BLAOCH Modificação do contrato de compra
BLAORD Contratos de compra
BLAREL Documentação da solic.remessa p/contratos distribuídos
BOMDOC Listas técnicas: lista técnica c/ref.documento
BOMMAT Listas técnicas:lista técnica c/ref.material
CARNOT Fornecimento: notificação de expedição
CBPRCP Rough-cut planning profile
CHRMAS Sistema de classes: características mestre
CLFMAS Sistema de classes: classificação mestre
CLSMAS Sistema de classes: classes mestre
CMREQU Solicitar o subsistema TR-CM para o envio dos dados TR-CM
CMSEND O subsistema TR-CM envia os dados TR-CM para TR-CM
central
CNPMAS Perfil configuração
COACOR Core master tipo de atividade
COACTV IDOC para centro de custo/tipo de atividade
Página 39 de 66
COAFET Solicitar tipo de atividade
COAMAS Mestre tipo de atividade
COCOKA Segmento de controle objeto CO/classe de custo
CODCMT IDOC para um documento CO
COELEM Classes de custo dados mestre
COGRP1 Grupos de centros de custo
COGRP2 Grupos de classes de custo
COGRP5 Grupos de tipo de atividade
COGRP6 Grupos de centros lucro
COGRP9 Grupos de conta (contabilidade de centro de lucro)
CONDAT Dados de controle
CONDBI Índice de condição para modificações de documento
COND_A Condições: dados mestre para a determinação de preços
CONF11 Confirmações em KK1
CONF21 Confirmações em KK2, evento c/registro de hora
CONF32 Confirmações em KK2, folha de tempos
CONF42 Confirmações em KK4, folha de tempos
CONF51 Confirmações em KK5, ordem de produção repetitiva
CONFIG Configuração para Transceiver
COPAGN Demonstr.resultado
COPCPA Dados de cálculo CO-PC -> CO-PA
COSCOR Core master centro de custo
COSFET Solicitar centro de custo
COSMAS Master centro de custo
COTOTL IDOC para registros de totais CO
CPS001 Demonstr.resultado
CREADV Exibição de nota de crédito
CRECOR Core Master Data fornecedores
CREFET Buscar nos dados do fornecedor
CREMAS Distribuir mestre de fornecedores
CRESTA Repetir status de crédito (DebtorCreditAccount)
DEBADV Exibição de débitos lançados
DEBCOR Core Master mestre de cliente
DEBFET Solicitar mestre de cliente
DEBMAS Mestre de cliente
DELINS Sol.rem./sol.rem.just in time p/o forncedor de componentes
DELORD Ordem de fornecimento
DESADT Aviso de transporte
DESADV Fornecimento: aviso de entrega
DIFFE2 Desvios em KK2
DIRDEB Cobrança bancária automática
DISTU2 Motivos da avaria KK2
DOCMAS Documento mestre
DWLOAD Download configuração de Transceiver
Página 40 de 66
ECMMAS Controle de modificações
EDLNOT Nota de remessa PS
EKSEKS Documento de compra para o sist.info compras
EUPEXR Mensagem refer.p/assinatura eletrônica (em pgtos.ampliados)
EXPINV Fatura exportação
EXTWA1 Rúbricas salariais externas
FIDCC1 Envio de documentos FI completos (user exit 003/4)
FIDCC2 Envio de documentos FI completos (user exit 005/6)
FIDCCH Modificação de um doc.FI
FIDCMT FI-IDOC para enviar partidas individuais
FINSTA Extrato de conta
FIPAYM Dados de pagamento
FIROLL Rollup razão p/FI-GL (delta p/partida individual FIDCMT)
GLCORE Dados mestres contas do Razão (CORE-IDOC)
GLFETC Solicitar contas do Razão
GLM000 Teste redução GLMAST
GLMAST Dados mestre contas do Razão (IDOC mestre)
GLROLL Rollup ctg.mensagem FI-GLX
GSVERF Procedimento de nota de crédito
HRCNF Aceitar confirmações (TimeMgtConfirmation)
HRCONF Confirmações da logística p/gerenciamento recursos humanos
HRCPRQ Planejamento de custos c/pessoal - solicitação de CO p/ HR
HRINW Folha de tempos da logística
HRMD_A HR: dados mestre e de organização (sist.aplicação)
HRMD_B Base HR: dados de organização (interno SAP, utilizar HRMD_A)
HRPAYP HR: transferência FI/CO
HRPRS Ausências da logística
HRTRPR Transferência TRV-PAY(PayrollTravelExpnses)
HRTRPY HR-TRV: transferência custos de viagens p/salário & ordenado
HRTRVL HR-TRV: transferência custos de viagens FI/CO
IMPINV Declaração de importação
INFREC Registro info para compras
INVCON IDOC controlling de estoques
INVOIC Fatura / doc.faturamento
KNOMAS Dependência de objetos global
KOMMOD Módulo de comunicação/transceiver
LABELS WWS: etiquetagem
LCROLL Consolidação legal
LIKOND Condições de catalogação
LIP002 Distributed IS planning
LIP021 IS distribuída - planejamento
LIP032 Upload estrutura de info estoques de depósito (S032)
LIP035 Upload estrutura de info estoques de lote (S035)
LIP125 IS distribuída - planejamento
LIS000 SIL dados externos: transmissão
LOCAT5 Depósito das ordens de produção repetitiva
LOCKBX Lockbox
LOIBOM Lista técnica
Página 41 de 66
LOICAL Calendário
LOINUM IDOC para o num.de IDOCs enviados
LOIPGR IDoc for product group
LOIPLO Ordem planejada
LOIPRO Ordem de produção
LOIRNH Hierarquia/diagrama de rede
LOIROU Roteiro
LOIRSH Cabeçalho da ordem de prod.repetitiva
LOISTD Lista nec./estoque
LOITMX Matriz de transição
LOIWCS Centro de trabalho
LPIPCM Campanha de produção
MALFK5 Motivos da avaria, ordens prod.repetitiva
MALFU2 Avarias em KK2
MATCOR Core Master Material
MATFET Solicitar material
MATMAS Mestre material
MKCLF1 ets clf
MRESCR Criar reserva
OPERA2 Operações em KK2
OPERS2 Status da operação em KK2
OPERS3 Centros de trabalho em KK3
OPERS4 Centros de trabalho em KK4
ORDCHG Modificação de pedido/ordem
ORDERS Pedido / ordem
ORDRSP Confirmação do pedido/ordem
OSTAT2 Status da operação KK2
PALMAT Atribuição de centro para lista técnica material
PAYEXT Ordem de pagamento ampliada
PCROLL Rollup centro de lucro
PEROP2
PERSO1 Registros mestres HR em KK1
PERSO4 Registro mestre em KK4
PICKSD Confirmação de dados de picking para entrega ao cliente
PI_BTC Transferência de dados para sistema de referências
PKHD5 Circuito regulador kanban
PKPS5 Recipiente Kanban
PKST5 Status possível para recipiente kanban
PLANT3 KK3: tabela de centros
PLANT4 KK4: tabela de centros
PORDCR Criar pedido
PRCFET Solicitar centro de lucro
PRCMAS Registro mestre de centro de lucro
Página 42 de 66
PRDCAT Catálogo de produtos
PRDPOS Item do catálogo de produtos
PREQCR Criar req.compra
PREQDL Eliminar/concluir req.compra
PRODPL Reporting plano de produção
QUOTES Cotação
RCLROL Rollup do ledger de reconciliação
RECSHP Transportes recomendados
REMADV Aviso de pagamento
REQOTE Solicitação
RSINFO IDOC informação Business Information Warehouse
RSRQST Requisição de dados Business Information Warehouse
RSSEND Envio de dados Business Information Warehouse
SAPRDI Tipo de IDoc para interface de dados brutos
SCS02O Purchasing doc. for LIS; semi conductor purpose
SCS99N Semiconductor supply qt
SDPACK Confirmação de dados do elemento de expedição
SDPICK Confirmação dos dados de picking
SERDAT Mensagem de controle: distribuição serializada
SHIPPL Entrada transportes planejados
SHPCON Fornecimento: confirmação expedição
SHPMNT Saída de transportes
SHPORD Fornecimento: ordem de expedição
SISCSO SISD: ordem de cliente
SISDEL SISD: fornecimento
SISINV SISD: documento de faturamento
SMMMAN Mestre material
SOPGEN IS distribuída - planejamento
SRCLST Lista opções fornec.
SRVMAS Dados mestre mestre de atividades
STATUS Mensagem sobre a transmissão de infos de status
SYIDOC Transmissão de tipos de IDoc
SYNCH Comunicação síncrona (ex: verif.ALE)
SYRECD Transmissão dos tipos de registros de IDoc
TPSDLR Sist.planejamento de transporte: acionar seleção fornecedor
TPSDLS Sist.planejamento de transporte: acionar seleção fornecedor
TPSDST Mensagem de modificação de status de um doc.vendas e distr.
TPSLOC Sist.planej.de transporte: transf.dados mestre localização
TPSSHT Sist.planejamento de transporte: transf.transporte planejado
TRIDOC EDI: transporte de definições de tipo de IDoc
TXTRAW Mensagem para texto livre em formato 'RAW' do SAPoffice
UNIMA2 Unidades de medidas dependentes do material
UNIT2 Unidades em KK2
Página 43 de 66
UPLOAD Configuração de transceiver para upload
VTAMAS Estrutura de uma tabela de variantes
VTMMAS Conteúdo de uma tabela de variantes
WBBDLD Lista de sortimento: dados de material
WBBLAB Lista de sortimento: reduzida para etiquetagem
WGSREQ VWWS: entrada ordem/confirmação de ordem
(GOODS_REQUIREMENT)
WHSCON Fornecimento: confirmação de depósito
WHSORD Fornecimento: ordem de depósito
WMBBIN Bloquear posições no depósito
WMCATO Estorno/solicitação de estorno ordem de transporte
WMINFO Informação
WMINVE Entrada de resultado da contagem de inventário
WMMBXY IDOC notificar movimentos de mercadorias em IM
WMRREF Liberação nº referência
WMSUMO Movimentar unidade de depósito
WMTOCO Confirmar ordem de transferência
WMTORD Ordem de transporte
WMTREQ Criar/estornar necessidade de transferência
WPDCUR Interface POS: download taxas de câmbio
WPDNAC Interface POS: download artigos pertencentes
WPDSET Interface POS: download atribuições de set
WPDTAX Interface POS: download taxas de imposto
WPDWGR Interface POS: download mestre de grupo de mercadorias
WPUBON Interface POS: upload docs.vendas (recibos) não compactados
WPUERR Interface POS: upload mensagens FWWS/POS/SCS
WPUFIB Interface POS: upload interface contab.financ.FWWS/POS
WPUKSR POS upload dados caixa
WPUPAE Interface POS: upload modificações de preço
WPUTAB Interface POS: upload encerramento do dia POS
WPUUMS Interface POS: upload dados de vol.vendas compactados
WPUWBW Interface POS: upload movimentos de mercadorias
WP_EAN Interface POS: upload e download atribuições EAN
WP_PER Interface POS: upload e download dados de pessoas
WP_PLU Interface POS: upload e download mestre de artigos
WTADDI Meio auxiliar de vendas
WTADDI_CVB1 Meio auxiliar de vendas sem 06...
WVINVE Inventário filial/modificação valor VK
Página 44 de 66
Comunicação técnica
A tecnologia ALE e os RFCs síncronos são utilizados para transferir dados entre o sistema de
planejamento externo e o R/3. De acordo com o escopo da integração, tanto o ALE quanto o RFC
síncrono, ou o ALE somente, são utilizados.
A transferência de dados mestre para o sistema externo é ativada através de uma transação ALE
on-line ou por um job em background que utiliza os programas de transação. Ponteiros de
modificação, que ligam o documento modificado às transações ALE de saída de dados mestre, são
utilizados para transferir dados que foram modificados desde a última transação de dados.
Normalmente os ponteiros de modificação são ativados após a transferência de dados inicial, de
forma a reduzir o tráfego de dados. Um método alternativo consiste em recuperar dados mestre
através de um IDoc de requisição, que pode ser utilizado junto com os programas de transação
para garantir a consistência dos dados mestre no sistema externo.
O histórico de demanda e os dados de transação na lista de estoques/necessidades são

transferidos da mesma forma que os dados mestre. Não há ponteiros de modificação para eles.
Entretanto, há diversas opções disponíveis para enviar um novo histórico de demanda ou uma lista
de estoques/necessidades de material com novos dados de transação MRP.
Para carregar resultados de planejamento para uma fábrica, a interface utiliza IDocs ALE de
entrada que passam dados para Vendas e Planejamento de Operações (SOP) do R/3. Para lançar
resultados de planejamento ou um plano de implementação para centros de distribuição, a
interface cria pedidos de transferência de estoque através de ALE, ou requisições através de RFC
síncrono. A interface também fornece um módulo de função RFC para eliminar requisições
desnecessárias.
O ALE e o RFC síncrono utilizam a interface SAP de chamada remota de função (RFC). Os
documentos "Interface SAP para chamada remota de função (RFC)" e "Interface ALE" contêm
informações detalhadas sobre os requisitos que um subsistema ou integrador devem atender para
se conectarem ao R/3 e utilizarem a interface DRP.
Página 45 de 66
ALE: Conceitos e projeto
O conceito ALE (‘Application Link Enabling’) da versão 3.0 do R/3 suporta a construção e a
operação de aplicações distribuídas. Ele inclui um intercâmbio de mensagens controlado com
dados consistentes em aplicações SAP A aplicação não é alcançada através de um banco de
dados central, mas através de comunicações síncronas e assíncronas.
A interface DRP usa o projeto do ALE para trocar de forma eficiente e consistente grandes volumes
de dados entre o sistema de planejamento externo e o R/3. O ALE de saída é utilizado para
transferir dados mestre e dados de transação para o sistema externo. O ALE de entrada é utilizado
pelo sistema externo para passar resultados de planejamento para o R/3 e criar objetos de dados
relevantes. O diagrama a seguir ilustra o processamento ALE de entrada e de saída.
Página 46 de 66
A base para o intercâmbio de dados é o documento intermediário (IDoc), que é um depósito geral
de dados que pode conter quaisquer dados de aplicação R/3 desejados. Diferentes dados de
aplicação podem ser compactados no mesmo tipo de IDoc. Os IDocs diferem entre si por tipos de
mensagem diferentes.
Os IDocs normalmente possuem uma estrutura hierárquica de forma que todas as informações de
um objeto de dados (como uma ordem de produção ou ordem de cliente) podem estar contidas em
um único IDoc. Um tipo de IDoc consiste em três tipos de registro: registros de controle, de dados e
de status. Para extrair dados do R/3, o sistema externo precisa poder reconhecer a estrutura do
IDoc e ler o conteúdo dos registros de dados baseado no tipo de mensagem e no tipo de IDoc
gravados no registro de controle. Para transferir dados de volta para o R/3, o sistema externo
precisa preencher os IDoc corretamente com os dados gerados. Os detalhes da estrutura do IDoc
estão no documento SAP ‘Interface IDoc para EDI’, e a descrição dos IDocs utilizados para a
interface DRP está na seção ‘Descrição de IDoc’ deste documento.
O ALE normalmente utiliza TCP/IP para se conectar ao sistema externo. Isso requer uma série de
configurações que definem o canal de comunicação correto. O ALE também utiliza modelos
distribuídos de cliente para controlar a distribuição dos dados e garantir um fluxo de dados correto.
Configurações mais específicas estão disponíveis através do ‘Protocolo de transmissão’, que
também controla o tipo de fluxo de dados entre o sistema R/3 e o sistema externo.
O ALE também possui funções para tratamento de erros, que podem ser configuradas de forma a
se conectar ao mecanismo de workflow do R/3. Os dados de IDoc processados através do R/3
podem ser monitorizados e arquivados de forma a garantir a consistência e a integridade dos
dados. Para entender o processo e a customização do ALE, vide o documento SAP ‘ALE -
Application Link Enabling’.
Transação RFC
Transação RFC, cliente RFC e servidor RFC
Os IDocs recebem um destino e são enviados do sistema R/3 através da chamada do módulo
‘INBOUND_IDOC_PROCESS’ e utilizando o RFC de transação. O destino determina o computador
de destino e o programa destino é definido na configuração do ALE.
Para receber dados IDoc do R/3, o sistema externo precisa ter um programa chamado ‘cliente
RFC’. Esse programa deve possuir o nome do programa destino e conter o nome do módulo de
função. Os dados do R/3 contidos no IDoc são transferidos na forma de tabelas internas. Quando
contém todos os dados de aplicação, o EDI_DC possui os dados administrativos para cada IDoc.
A partir da versão 3.0C, é possível registrar esse programa através do gateway SAP no destino
RFC e estabelecer a conexão entre o sistema externo e o gateway. Ao registrar o gateway, o
programa pode precisar do arquivo saprfc.ini e do endereço do gateway.
Para enviar o IDoc para o R/3, o sistema externo precisa utilizar um programa RFC para se
conectar ao R/3 e chamar o módulo de função ‘INBOUND_IDOC_PROCESS’. Esse programa,
chamado servidor RFC, monta os dados de IDoc e os coloca na tabela interna da estrutura
EDI_DC. Um registro de verificação também deve ser criado para cada IDoc e colocado em uma
tabela interna da estrutura EDI_DC. É necessário verificar o Gerenciamento de Identificação de
Transações. Novamente, o arquivo saprfc.ini pode ser utilizado para se obter informações de
logon.
Tanto o cliente quanto o servidor RFC podem ser programados em C ou C++. A biblioteca de
classe RFC está disponível a partir do release 3.0F. Também é possível gerar um programa C a
Página 47 de 66
partir do módulo de função /nSE37 e utilizá-lo como estrutura básica. Para obter detalhes sobre a
programação de clientes e servidores RFC, vide os documentos ‘Interface ALE’ e ‘Tutorial RFC’.
Página 48 de 66
RFC síncrono
RFC síncrono: chamada externa de módulos de função
Programas chamados BAPI ("Business Application Programming Interface’ - Interface de

Programação de Aplicações Comerciais) ou módulos de função como
‘REQUISITION_LIST_DELETE’ são similares ao programa servidor RFC. Após se conectar ao
sistema R/3, o programa preenche as tabelas internas e parâmetros de importação e chama os
módulos de função RFC no R/3. Se é necessário recuperar informações, as tabelas internas e os
parâmetros de exportação contêm os dados para o sistema externo após a chamada da função.
O BAPI e outros módulos de função RFC aceitam campos dos tipos BCD QUAN, DEC e NUMC,
mas a biblioteca RFC só pode lidar com campos desses tipos a partir do release 3.1G. A biblioteca
de classes RFC só pode lidar com esses tipos de campo a partir do release 4.0. Pode ser
necessário codificar conversões de tipos de campos caso seja utilizada a biblioteca de classes
RFC anterior a 4.0 e a biblioteca RFC após 3.1G. O programa servidor RFC para ALE não
apresenta esse tipo de problema porque nenhum dos campos da estrutura IDoc pode ser definido
com tipo QUAN, DEC ou NUMC.
Meta Objetos
Ao usar ALE e recuperar dados de um IDoc, o sistema externo precisa conhecer a estrutura do
IDoc para poder identificar corretamente os campos necessários. A estrutura IDoc permanece
inalterada no mesmo release, mas pode haver pequenas modificações entre releases diferentes, o
que significa que os programas de integração podem requerer versões diferentes para releases
diferentes. Uma forma de evitar isso é criar meta objetos dinamicamente para a estrutura IDoc
quando a integração é instalada. O sistema externo utiliza esses meta objetos para pesquisar e
para identificar os campos relevantes.
Como a estrutura IDoc inclui uma hierarquia de segmentos que também efetuam um loop nos
mesmos níveis, os meta objetos devem ser projetados de forma a facilitar a pesquisa e a
identificação dos campos. A SAP fornece uma biblioteca de classes IDoc além da biblioteca de
classes RFC no 4.0. A biblioteca de classes IDoc ajuda a analisar os dados no IDoc.
A estrutura IDoc pode ser pesquisada facilmente através do seguinte caminho de menu:
Ferramentas ® Administração ® Administração ® Tecnologia de processos ® IDoc ® Base de IDoc

(/nwedi) ® Documentação ® Tipos de IDoc. Há duas outras formas de se recuperar estruturas IDoc
e utilizar suas saídas para construir meta objetos IDoc de maneira mais dinâmica.
Utilizar o relatório ‘RSEIDOC5’. Esse relatório exibe na tela a estrutura IDoc e os nomes de
segmentos e campos. Para utilizar esse relatório, o sistema externo pode descarregar a saída da
tela e construir os meta objetos.
Utilizar a chamada remota de função ‘EDI_FILL_SYIDOC01_FOR_RFC’. Esse módulo de função

usa os parâmetros de importação ‘Tipo de IDoc’ e ‘Número do release’ para preencher a tabela
interna EDI_DD, que contém o IDoc ‘SYSIDOC01’, com as descrições do tipo de IDoc solicitado.
Esse módulo de função ativa a recuperação on-line de estruturas IDoc.
Página 49 de 66
Saída (Envio de IDOCs para um Sistema Externo
São possíveis os cenários de modificação a seguir:
1. O IDOC standard está sendo utilizado, mas deseja-se modificar o processamento

standard, ou seja, a estrutura deste IDOC.
2. O IDOC standard está sendo utilizado, mas o usuário deseja especificar quando e para
quem um item de ordem de transferência no depósito deve ser enviado, ou seja, não
utilizar o procedimento proposto da interface.
3. Um IDOC modificado está sendo utilizado com segmentos do usuário e o usuário deseja
iniciar sua própria seqüência de processamento para geração dos dados deste segmento.
4. Um IDOC modificado está sendo utilizado com os segmentos do usuário e deseja-se
definir o procedimento para que o próprio usuário processe o IDOC, ou seja para que ele
estruture o IDOC.
5. Um IDOC modificado está sendo utilizado com os segmentos do usuário e não se deseja
utilizar o procedimento proposto da interface como no cenário 2.
6. Um IDOC do usuário está sendo utilizado com um novo tipo de mensagem e o usuário
deve definir o procedimento para que ele mesmo processe o IDOC.
7. Está sendo utilizado o IDOC do usuário com um novo tipo de mensagem e não se deseja
utilizar o procedimento proposto da interface como no cenário 2.
As opções individuais estão descritas a seguir.
As etapas preparatórias para o envido de IDOCs são executadas na aplicação. O IDOC é gerado,
os parceiros são determinados e o estrato ALE é ativado. O IDOC é gerado nos módulos de função
de aplicação.
Esta é a primeira situação na qual o usuário pode intervir no sistema através da geração de seu
próprio módulo de função de processamento. É necessário entrar este módulo em uma tabela
de customizing da interface no sistema de modo que ele possa ser chamado pela aplicação.
O sistema utiliza os módulos de função a seguir para gerar e enviar IDOCs, Exemplo:
Módulos de função de saída
L_IDOC_CREATE_WMTOID01 Ordens de transferência no depósito

L_IDOC_CREATE_WMRRID01 Número de referência de solicitação de remessa
L_IDOC_CREATE_WMCAID01 Ordem de anulação de OT
L_IDOC_CREATE_WMIVID01 Documentos de inventário
Observar os módulos de função. Aqui também podem ser utilizadas user exits para que o usuário
adicione seus próprios segmentos de IDOC ou modifique a estrutura do IDOC standard.
Se a interface standard no sistema não for utilizada porque o próprio usuário deseja decidir quando
deve ser feita a interface com o sistema externo e para quais sistemas externos os dados devem
ser enviados, ele mesmo deve configurar a interface. Neste caso não se deve ativar a interface no
sistema.
O usuário pode definir seus segmentos de IDOC na transação de atualização de IDOC (conforme
a entrada). Também é possível definir um IDOC específico do cliente para a saída. Tudo que é
necessário aqui além da definição do IDOC é a saída do protocolo de transmissão.
Página 50 de 66
Caso o usuário deseje gerar seus próprio módulo de função de envio a partir da sua aplicação,
é possível simplificar o procedimento através dos módulos de função a seguir que já são utilizados
nos módulos de envio SAP.
Módulos de função auxiliares de saída
L_IDOC_HEADER_CREATE Gerar os dados EDIDC necessários para cada IDOC

L_IDOC_SEGMENT_CREATE Gerar um segmento de IDOC
L_IDOC_SEND Enviar os IDOCs gerados
L_IDOC_FETCH Para acesso dos dados no programa do usuário após a chamada
do IDOC_CREATE_... do usuário .
As modificações a seguir podem ser feitas nos cenários de modificação individuais.
1. O usuário pode implementar seu próprio módulo de função de processamento para o

processamento do IDOC. Este módulo pode ser copiado do módulo de função standard do
respectivo tipo de mensagem e adaptado conforme necessário.
2. É possível ativar a exit de cliente no módulo de função standard para modificar a estrutura
de IDOC standard.
3. O usuário pode definir sua própria interface entre o sistema e o sistema externo.
4. O usuário pode definir seus próprios segmentos de IDOC no IDOC standard e utilizar a
exit de cliente para entrar dados em seus próprios segmentos.
5. O usuário pode definir seus próprios segmentos de IDOC no IDOC standard e
implementar seu próprio módulo de função que pode ser copiado do módulo de função
standard do tipo de mensagem respectivo e adaptado conforme necessário.
6. O usuário pode definir seus próprios segmentos de IDOC no IDOC standard e preparar
sua própria interface entre o sistema e o sistema externo.
7. O usuário pode definir seu próprio IDOC e implementar seu próprio módulo de função.
É possível utilizar o módulo auxiliar standard na geração do módulo de função.
8. O usuário pode definir seus próprio IDOC e preparar sua própria interface entre o sistema
e o sistema externo.
Página 51 de 66
Informações sobre implementação
A responsabilidade pela transferência de informações entre o R/3 e sistemas externos é

compartilhada pela SAP e seus parceiros.
A SAP envia as ferramentas técnicas necessárias para uma conexão com um sistema externo
(IDocs, ALE, RFCs) como parte do release 3.1 standard. Além das ferramentas, a aplicação
contém diversas funções que representam processos empresariais críticos e permitem que o
processamento correspondente seja efetuado no sistema R/3. Essas funções são transações,
IDocs standard e customizing.
Os parceiros da SAP são responsáveis pelos procedimentos de processamento necessários para a

transferência de dados do R/3 para o sistema de otimização e vice-versa. Em outras palavras, para
que exista uma comunicação técnica correta, os parceiros devem ser capazes de interpretar
corretamente os dados do R/3 e retornar a versão otimizada no formato correto.
Os parceiros interessados em trabalhar com a SAP nesses termos podem preencher o programa
de certificação para que seus sistemas externos possam ser corretamente conectados ao R/3.
Para receber o certificado, os parceiros precisam provar que possuem a capacitação técnica para
tratar da transferência e da funcionalidade de todas as conexões IDoc. Cenários de teste são
fornecidos em um documento à parte, e uma lista com todos os IDocs necessários para a
certificação para cada interface está contida nas descrições de cada IDoc.
Comunicação: ALE
Durante o download, os dados são enviados pelo ALE (Application Link Enabling). O ALE suporta a
criação e operação de aplicações distribuídas, e permite o intercâmbio de mensagens comerciais
entre sistemas de computador em um ambiente distribuído. A consistência dos dados é mantida
em toda a rede. A integração de aplicações não é obtida através de um banco de dados central,
mas através de comunicações síncronas e assíncronas.
O ALE consiste nas três seguintes camadas:
 Serviços de aplicação
 Serviços de distribuição
 Serviços de comunicação
Os dados são enviados de forma assíncrona do sistema R/3 para o sistema externo.
O intercâmbio de dados entre os sistemas SAP e os sistemas externos é feita através de depósitos
de dados chamados IDocs (intermediate document type). Os IDocs possuem uma estrutura de
dados neutra. O sistema externo, porém, deve conter uma função ‘inbound_IDoc_process’
necessária para o processamento de entrada no lado externo do intercâmbio.
O gráfico abaixo ilustra a comunicação entre o sistema SAP R/3 e um sistema externo.
Página 52 de 66
Página 53 de 66
Estrutura básica de Idoc
Um IDoc consiste em uma linha de cabeçalho, diversos segmentos de dados conectados e

registros de status.
Função dos elementos do Idoc
Elemento Função
Cabeçalho Define conteúdo, estrutura, remetente, receptor e
status do IDoc
Segmento de dados Consiste em um "líder" (número consecutivo de
segmento e uma descrição do tipo de segmento) e
uma cadeia de 1000 caracteres (que contém dados
do segmento)
Registros de status Descreve as etapas de processamento do IDoc até
agora
Para obter informações mais detalhadas, vide o Guia do consultor para o ALE. Para visualizar
IDocs específicos, seguir o caminho de menu Ferramentas  Administração  Administração 
Tecnologia de processos  IDoc  Base de IDoc  Documentação  Tipo de IDoc.
Interc. de dad.: SAP R/3 ® Sist. otim. ext.
Os dados a serem enviados para um programa de otimização podem ser selecionados em duas
telas de seleção. Os dados são divididos em dados mestre e dados de movimento. Um IDoc
especial é criado para cada business object e transmitido para o estrato ALE a ser enviado.
Dados mestre
A interface só suporta o intercâmbio de todo o registro de dados. Atualmente não é possível enviar
modificações feitas desde o último intercâmbio de dados entre o sistema R/3 e um sistema externo.
Uma vez selecionados, os dados mestre podem ser transferidos manualmente ou em um job batch.
São criados IDocs para cada business object. Os IDocs são estruturados claramente para que
possam ser lidos mais facilmente pelo sistema externo.
Através da redução dos IDocs é possível utilizar e definir outros tipos de mensagens (vide o guia
de implementação para ALE).
IDocs para download de dados mestre (Exemplo).
Dados mestre Tipo de IDoc mestre Tipo de mensagem

predefinida
Materiais MATMAS03 MATMAS
Listas técnicas LOIBOM01 LOIBOM
Roteiros LOIROU01 LOIROU
Centros de trabalho LOIWCS02 LOIWCS
Hierarquia de centros de trabalho LOIRNH01 LOIRNH
Rede de recursos LOIRNH01 LOIRNH
Calendário da fábrica LOICAL01 LOICAL
Classificação de objeto CLFMAS01 CLFMAS
Número de IDocs transferidos LOINUM01 LOINUM
Página 54 de 66
Grupo de produtos LOIPGR01 LOIPGR
Matriz de transição LOITMXL01 LOITMX
Seleção de dados mestre
Selecionar as opções de menu Logística  Funções centrais  Interfaces SCP
A tela Interface de Otimização da Produção é exibida.
1. Selecionar as opções de menu Processar  Enviar  Dados mestre.

A tela Seleção de Dados Mestre para Transferência é exibida
2. Na tela Dados mestre, selecionar as opções para o caminho de menu Modo de
transferência.
3. Entrar o sistema de otimização no campo apropriado.
Antes de entrar um sistema de otimização, é necessário criar primeiro o sistema lógico
correspondente em customizing. Para isso, selecionar Opções ALE para POI no IMG SCI .
Definir as opções apropriadas na seção Configuração básica.
Para obter informações mais detalhadas, vide o guia de implementação para o ALE.
4. Atualizar as opções de seleção: dados mestre
5. Selecionar as opções de menu Programa  Executar.
O programa também pode ser executado como um job batch. Para fazer isso, selecionar as opções
de menu Programa  Exec. em background.
O IDoc correspondente é criado e transmitido ao nível de distribuição de mensagem do ALE.

O usuário recebe uma mensagem quando o IDoc é transmitido corretamente.
É possível definir parâmetros adicionais de seleção para listas técnicas em customizing.
Página 55 de 66
Modo de transferência
Para identificar modificações nos objetos de dados mestre, o interface utiliza funções SMD (shared
master data - dados mestre compartilhados) que já existem no sistema R/3 standard. Para obter
mais informações sobre ferramentas SMD, vide a Biblioteca R/3, Aplicações válidas para todas as
aplicações  Guia do consultor ALE/Programação
Quando um objeto de dado mestre é modificado, e de acordo com os tipos de mensagens

definidos em customizing, é necessário gravar ponteiros de modificação. A interface processa os
ponteiros de modificação, o que faz com que esses objetos de dados mestre que foram
modificados no R/3 sejam enviados novamente para o sistema lógico externo.
Ao definir as opções de customizing da interface, é necessário especificar os tipos de mensagens

reduzidas que serão enviadas para o sistema externo. A interface usa as opções, lê os ponteiros
de modificação de tipo de mensagem e os processa. (Vide o IMG para obter informações sobre
opções de customizing para ativar a gravação de ponteiros de modificação.)
Ao efetuar o download de dados, há duas opções de modo, ‘completo’ ou ‘modificação’. Neste

caso, normalmente se escolhe completo.
Modo de transferência Completo:
Quando este modo é selecionado, todos os dados mestre correspondentes aos critérios de seleção
especificados na tela de seleção de dados mestre são enviados. Se há ponteiros de modificação
relativos aos tipos de mensagem para os objetos de dados mestre que sejam relevantes para o
download para o sistema de otimização externo, esses ponteiros devem ser definidos como
processados. Isso garante que somente os dados modificados desde a última transferência
completa serão descarregados se os dados forem modificados e transferidos mais tarde.
Modo de transferência Modificação:
Quando este modo é selecionado, somente os dados modificados desde o último download
completo serão enviados no caso de objetos de dados mestre entrados posteriormente. Essas
modificações incluem novas entradas, modificações de objetos e eliminações.
Para descarregar objetos de dados mestre para os quais não há suporte de modo modificação, é
necessário efetuar um download completo dos dados.
No modo de transferência modificação, assim como no download completo de dados mestre, todos
os ponteiros de modificação para os tipos de mensagem enviados para o sistema de otimização
externo precisam ser definidos como ‘processados’.
No caso dos objetos de dados mestre listados acima, as informações relativas a dados eliminados
também são descarregadas, de forma que o sistema de otimização externo também possa eliminá-
los. O campo MSGFN, presente em quase todos os segmentos, fornece informações sobre
modificações feitas nos dados do segmento e indica como os dados do segmento devem ser
utilizados.
Atualmente o campo MSGFN pode ter um desses dois valores:
005 : atualizar segmento

003 : eliminar segmento
Página 56 de 66
Normalmente o valor é 005, que indica que dados existentes devem ser atualizados. As
alternativas para o valor 003 incluem códigos de eliminação ou marcas de eliminação que indicam
que o segmento foi eliminado ou marcado para eliminação.
Os ponteiros de modificação obsoletos e processados devem ser eliminados periodicamente. Caso

contrário, a performance pode ficar prejudicada.
Se o sistema externo recebe um IDoc de um objeto, todas as informações relativas a ele devem
ser totalmente substituídas pelas novas informações.
Para descarregar modificações, é necessário definir as opções apropriadas em customizing.
Para registrar e processar modificações de dados, é necessário ativar a gravação de ponteiros de

modificação.
Tipos de mensagens reduzidas e o download de modificações de dados:
Se o download de modificações de dados está sendo feito com tipos de mensagens reduzidas, um
IDoc de mestre de material só será descarregado novamente se o campo modificado no mestre de
material também estiver contido no tipo de mensagem reduzida. Se um campo é modificado em um
mestre de material e não está contido no tipo de mensagem reduzida, o IDoc de material
correspondente não será enviado novamente. As modificações no mestre de materiais são
registradas por campos individuais.
No caso de IDocs de lista técnica e de roteiro, porém, as modificações de dados são registradas
para todo o objeto. Dessa forma, a modificação de um campo específico de uma lista técnica ou
roteiro não será registrada. Somente a lista técnica ou o roteiro em si serão registrados como tendo
sido modificados. Por esse motivo, é possível que uma lista técnica ou roteiro seja enviado mesmo
que um dos campos modificados não esteja no tipo de mensagem reduzida.
Para obter mais informações sobre este tópico, vide a seção sobre ferramentas SMD na biblioteca
do R/3, Aplicações válidas para todas as aplicações  Guia do consultor ALE/programação
Página 57 de 66
Procedimento: monitoramento de download
1. Selecionar as opções de menu Logística Funções centrais  Interfaces SCP.

A tela SCP é exibida.
O usuário tem as seguintes opções de exibição:
– Selecionar e exibir os IDocs transferidos para o estrato ALE segundo diversos critérios.
– É possível exibir os RFCs transacionais ainda não executados corretamente.
2. Para exibir IDocs transferidos para o estrato ALE.

– Selecionar as opções de menu SCI  Ambiente  Monitoramento  Síntese de IDoc.
A tela Listas de IDocs é exibida.
Marcar os IDocs desejados.
- Marcar IDocs por data e hora de criação.
- Marcar IDocs por tipo de mensagem lógica, código de mensagem ou função de
mensagem
- Marcar IDocs por tipo de parceiro, função de parceiro ou número de parceiro do
remetente ou receptor.
– Selecionar as opções de menu Programa  Executar.
É exibida uma síntese de todos os IDocs transferidos.
3. Para exibir os IDocs que ainda não foram transferidos corretamente pelo RFC transacional:
– Selecionar as opções de menu SCI  Ambiente  Monitoramento  RFC transacional.
É exibida a tela RFC transacional.
Marcar os IDocs desejados:
– Marcar os IDocs por período de exibição:
Entrar um período de exibição.
– Marcar os IDocs transferidos por um determinado usuário.
Entrar um nome de usuário.
– Selecionar as opções de menu Programa  Executar.
É exibida uma síntese de todos os IDocs ainda não transferidos.
Página 58 de 66
Campos especiais no seg. de controle do EDI_DC
Funções especiais devem ser consideradas para os seguintes campos.
Campo EDI_DC-DOCNUM: Número do documento
Na descrição central, o campo indica o número exclusivo no sistema SAP R/3 do documento
transmitido. Para que possa ser criada uma referência para os registros de dados anexos, é
necessário entrar um número exclusivo no subsistema. Quando o IDoc transmitido do subsistema é
importado pelo sistema R/3, o conteúdo de DOCNUM é substituído por um número interno,
determinado pelo sistema R/3. A referência para o antigo DOCNUM é gravada.
Campo EDI_DC-RCVPRT: Tipo de parceiro do receptor
O campo indica o tipo de sistema do parceiro e é geralmente definido como ‘LS’ (sistema lógico)
para comunicação com sistemas externos.
Campo EDI_DC-RCVPRN: Número do parceiro do receptor
Número ou nome do sistema receptor.
Campo EDI_DC-SNDPRT: Tipo de parceiro do transmissor
O campo indica o tipo de sistema do parceiro e é geralmente definido como ‘LS’ (sistema lógico)
para comunicação com sistemas externos.
Campo EDI_DC-SNDPRN: Número do parceiro do transmissor
Número ou nome do sistema transmissor.
A combinação dos campos SNDPRT e SNDPRN é extremamente importante para o subsistema

quando os dados dos IDocs de entrada são processados.
Esses dois campos são usados para separar documentos de diferentes sistemas R/3 ou
mandantes R/3. Um sistema de planejamento do transporte poderia, por exemplo, receber duas
remessas de dois sistemas R/3 com o mesmo número de remessa. Essas remessas não podem
ser misturadas durante a organização. Dessa forma, SNDPRT e SNDPRN funcionam como uma
parte adicional da chave para todos os campos de identificação.
Campo EDI_DC-ARCKEY: Identificação do documento no sistema externo
No campo ARCKEY o subsistema pode gravar informações adicionais para identificação unívoca
de um documento transmitido. Se um documento transmitido do subsistema não pode ser
processado pelo sistema R/3, uma mensagem de erro com o conteúdo de ARCKEY é enviada de
volta para criar uma referência para a transação de criação do documento.
Campo EDI_DC-MESTYP: Categoria de mensagem lógica
O campo contém o nome lógico de uma mensagem. Esse campo não é limitado por nenhum
standard EDI. Mensagens lógicas são atribuídas pelo SAP aos tipos individuais de IDoc.
Campo EDI_DC-IDOCTYP: Nome da categoria básica de IDoc
O tipo de IDoc é definido pelas aplicações. Esses tipos determinam a seqüência dos segmentos
SAP. Os tipos de IDoc fornecidos com o standard SAP são identificados através do campo
IDOCTYP como os tipos de IDoc criados pelo cliente.
Página 59 de 66
Campo EDI_DC-SERIAL: EDI/ALE: Campo de serialização
O campo de serialização contém um número exclusivo que pode ser usado para serialização, ou
seja, para definir a seqüência correta de transmissão de IDocs no sistema receptor. Geralmente é
um flag de tempo, que explode suficientemente a seqüência ou que fornece uma seqüência de
números consecutivos baseada na identificação unívoca da seqüência de criação e/ou da
seqüência de transmissão no sistema transmissor. O campo de serialização deve conter somente
números.
Opções e modificações no sistema SAP
Este capítulo apresenta uma síntese das opções necessárias no sistema SAP R/3, bem como
informações sobre ajustes adicionais disponíveis nas funções de cliente do R/3.
Síntese das fontes de informação
Também é possível utilizar as seguintes fontes de informação:
 Guia de implementação/IMG referência SAP (on-line)

Ferramentas  Customizing  Projetos de implementação  IMG referência SAP  Vendas e
distribuição  Transporte  Interfaces  Sistemas de plan.transporte externos
A síntese mostra que opções devem ser definidas no sistema R/3 para ativar e configurar a
interface de organização do transporte. Os pontos individuais a seguir fornecem uma ajuda
mais detalhada.
 Menu principal (on-line)

Logística  Vendas e distribuição  Transporte  Sistemas externos  Planejamento
transporte  Monitorização ALE
As funções ALE permitem monitorizar IDocs recebidos e enviados.
 A seguinte documentação impressa está disponível para uma análise mais profunda:
Manual RFC
Descrição técnica exata da interface de programação.

Manual de consultoria ALE
Informações gerais sobre o ALE e suas funções

Manual de workflow
Informações gerais sobre o conceito de Workflow (vide processamento de erros)
Processamento padrão de erros com o ALE
A transferência de IDocs através de Chamada de Função Remota ocorre na base TCP/IP. Uma
ocorrência de erro interrompe a ligação entre o transmissor e o receptor. O transmissor pode
utilizar os códigos de retorno das funções RFC utilizadas para controlar se a função foi ou não
chamada com sucesso no sistema receptor. Se houver erros TCP/IP, a ligação deve ser
desconectada e o IDoc deve ser retransmitido.
Página 60 de 66
Erros no estrato ALE que ocorram durante a transmissão ou recebimento do IDoc são indicados
como erros técnicos. O sistema R/3 gera um work item para cada IDoc incorreto quando ocorrem
erros técnicos ou lógicos (vide abaixo). Um work item é parte do processamento do workflow, e
funciona como uma mensagem de erro que é enviada para todos os usuários no sistema
associados a uma determinada posição. A mensagem de erro contém um texto de erro. Se um
dos usuários pega a mensagem na entrada, analisa o erro e envia o documento, a mensagem de
erro desaparece de todas as entradas.
O IDoc é gravado no banco de dados antes que qualquer processamento seja iniciado, e a
comunicação do processamento é desconectada. Se um erro ocorre durante o processamento, por
exemplo, atualização com tipo de transação não permitido ou incorreto, ou seja, um erro lógico de
aplicação, o SAP cria um work item com o texto de erro apropriado.
Ativação do processamento standard de erro
Uma mensagem é enviada para um ou mais usuários se ocorre um erro lógico ao processar um
IDoc. O texto a seguir descreve como o processamento de erro é configurado.
Tecnicamente, o sistema aciona uma tarefa standard específica para a categoria de mensagem. A
tarefa standard deve estar atribuída a uma posição que possui um usuário ou titular.
É possível criar uma ou mais posições dentro de uma unidade organizacional central.
As seguintes opções ocorrem:
 O usuário pode entrar uma unidade organizacional na definição de parceiro mas nenhuma
outra especificação no protocolo de transmissão por categoria de mensagem. Todas as
mensagens vão para os usuários atribuídos a essa unidade organizacional que possuem
uma posição onde a tarefa standard apareceu.
 O usuário entra um local definido no lugar da unidade organizacional na definição do
parceiro.
 O usuário substitui a entrada na definição do parceiro por entradas no protocolo de
transmissão para uma categoria de mensagem.
Normalmente é usada a primeira alternativa. Entretanto, quando há dois subsistemas que servem a
dois locais de organização do transporte diferentes, onde os administradores dos erros são duas
pessoas diferentes, é possível utilizar a segunda alternativa para enviar o mesmo erro através de
dois números de parceiro diferentes.
Exibição na entrada
A exibição na entrada pode ser ajustada individualmente. A seqüência a seguir descreve uma
opção que permite exibir as mensagens por categoria de IDoc.
Chamar a transação SIN1. Clicar em Configuração sob opções e criar uma nova configuração.
Selecionar o botão Iniciar configuração, para que esta configuração seja sempre utilizada
automaticamente. Gravar.
Selecionar Opções  Grupo e clicar duas vezes no campo desejado na coluna da direita para
ordenação na exibição da síntese. Os campos apropriados são 1.„Tarefa" e 2. „Data de criação"
Selecionar Opções  Marcar colunas e clicar duas vezes nos campos a serem exibidos na tela de
detalhe. Os campos apropriados são 1. "Ler", 2. "Processar", 3. "Denominação", 4. "Autor", 5.
"Data de entrada", 6. "Hora de entrada" e 7. „Status".
Página 61 de 66
Recuperação e transferência de dados mestre Condições
O ALE disponibiliza duas formas de passar dados mestre para o sistema externo.
Uma forma é iniciar a transferência de dados do R/3 com transações ou relatórios on-line (embora
esses programas sejam executados quase sempre como jobs em background). O segundo método
autoriza o sistema externo a obter dados através do envio de IDoc de requisição ao R/3. O R/3
processa os IDocs e devolve as informações solicitadas em IDocs de dados mestre. A tabela a
seguir relaciona as informações relevantes para esses métodos.
Mestre de Material Mestre de Cliente Mestre

de
Fornecedor
Tipo de mensagem MATMAS DEBMAS CREMAS
Tipo de IDoc MATMAS01 DEBMAS01 CREMAS01
Nome do programa RBDSEMAT RBDSEDEB RBDSECR
E
Tipo de mensagem de obtenção FETMAT FETDEB FETCRE
Código do processo de entrada MATF DEBF CREF
Módulo de função de entrada IDOC_INPUT_REQUEST
Os IDocs de dados mestre transferidos via ALE contêm quase todos os campos definidos para os
dados mestre. O sistema externo deve ser capaz de escolher os campos corretos nesses IDocs.
Além disso, quando se executam jobs em background com esses programas, normalmente um
intervalo de numeração de dados mestre é informado, e o sistema externo não tem controle sobre
quais os dados que deve receber. Para reduzir o tráfego de dados, porém, o ALE fornece filtros
nas definições do modelo de distribuição. O ALE primeiro cria os IDocs básicos e depois os replica
em relação aos modelos de distribuição. Se há filtros definidos para um determinado sistema
lógico, somente os IDocs que podem passar pelos filtros são criados e enviados para esse sistema
lógico.
Procedimentos
Para acessar a criação de filtros no IMG, selecionar Componentes para todas as aplicações  ALE
de distribuição  Atualizar modelo de distribuição.
Quando são usados ponteiros de modificação para a transferência de dados mestre, é necessário
um outro programa:
 Ativar os ponteiros de modificação de forma geral. Selecionar: Ferramentas  Business

Engineering  Customizing  Implementar projetos  SAP Ref IMG  Componentes para
todas as aplicações  ALE de distribuição  Distribuição de dados mestre  Ativar
ponteiros de modificação de forma geral
 Ativar os ponteiros de modificação para tipos de mensagens individuais. Selecionar:
Ferramentas  Business Engineering  Customizing  Implementar projetos  IMG Ref
SAP  Componentes para todas as aplicações  ALE de distribuição  Distribuição de
dados mestre  Ativar ponteiros de modificação para tipos de mensagem
 Executar o programa RBDMIDOC com o tipo de mensagem correto on-line ou em
background como um job periódico. No R/3, selecionar: Ferramentas  Business
Framework  ALE  Administração  Processamento periódico  Analisar ponteiros de
modificação
Página 62 de 66
Análise de erros
Erros técnicos no estrato ALE
Os seguintes erros podem ocorrer no estrato ALE:
 Erro de sintaxe no IDoc

 Protocolo de transmissão ausente
 O IDoc não é transferido para o RFC na transmissão
 O IDoc não é transferido para o RFC no recebimento
Saída
Erro de sintaxe no IDoc: Status de IDoc ‘07’
A sintaxe do IDoc individual é verificada na transmissão e no recebimento de IDocs. A sintaxe é

determinada quando o IDoc é definido, e inclui:
 os segmentos individuais da categoria de IDoc

 a relação entre os segmentos individuais
 quantos segmentos podem ser transmitidos em um IDoc ou com que freqüência um
segmento individual pode ocorrer em um Idoc
A verificação de sintaxe de um IDoc pode ser ativada no protocolo de transmissão para uma
categoria de IDoc e um determinado parceiro, e é recomendável especialmente para IDocs criados
pelo próprio usuário. Caso contrário, esse erro só ocorre normalmente na execução de teste. Os
IDocs incorretos não podem ser corrigidos e terão que ser retransmitidos quando a estrutura de
IDoc tiver sido corrigida no sistema SAP.
Protocolo de transmissão ausente ou incorreto: Status de IDoc ‘29’
Para transmitir um IDoc do sistema SAP para o subsistema, é necessário definir o processamento
de saída do protocolo de transmissão para a categoria de IDoc (tipo de mensagem) e todos os
parceiros relevantes. Uma descrição mais exata dos protocolos de transmissão pode ser
encontrada na documentação on-line do Guia de implementação (IMG). Se o parceiro (subsistema)
para transmissão do IDoc não pode ser determinado, é necessário seguir este procedimento:
 atualizar o protocolo de transmissão

 todos os IDocs de transmissão devem ser definidos para retransmissão. Como esse erro
acionou um work item para a tarefa standard ‘ALE/EDI: processamento de erro (saída)’ e o
enviou para a entrada do usuário em questão, o IDoc incorreto também precisa ser
definido para transmissão subseqüente na entrada. Na transmissão subseqüente, o IDoc
incorreto é marcado com o status ‘31’ e copiado para um novo IDoc, que possui dados
adicionais do protocolo de transmissão, e transferido para a RFC.
Erros nos protocolos de transmissão ocorrem normalmente na execução de teste.
IDoc não é transferido para a RFC na transmissão: Status de IDoc ‘30’
Embora o protocolo de transmissão tenha sido atualizado, o IDoc não é transferido para a RFC, ou
seja, o IDoc é estruturado porém não enviado. O subsistema em questão não precisa ter nenhuma
entrada aberta na análise da transação RFC. Embora esteja pronto para transmissão, o IDoc
precisa ser explicitamente controlado.
Página 63 de 66
Isso é feito através do relatório RSEOUT00, que pode ser planejado como um job periódico ou
iniciado diretamente pelo menu de transporte Logística ® Vendas e distribuição ® Transporte ®
Sistemas externos ® Planejamento transporte ® Monitoramento ALE ® Trabalhos periódicos ®
IDocs em saída ALE ® Enviar.
Aqui o modo de saída para o IDoc em questão deve ser verificado no protocolo de transmissão. No
modo de saída ‘2’, o IDoc criado é transmitido diretamente; no ‘4’, os IDoc são agrupados e
enviados em tamanhos de volume definidos. Os IDocs não devem ser transmitidos diretamente
para o modo ‘4’.
Status ‘30’ no IDoc só ocorre normalmente quando o modo de saída é igual a ‘4’.
Processamento na entrada
Erro de sintaxe no IDoc: Status de IDoc ‘60’
Como no processamento na saída, a verificação de sintaxe de um IDoc pode ser ativada no

protocolo de transmissão para uma categoria de IDoc e um determinado parceiro, e isso deve ser
feito especialmente para IDocs criados pelo próprio usuário. Caso contrário, esse erro só ocorre
normalmente na execução de teste. Os IDocs incorretos não podem ser corrigidos e terão que ser
retransmitidos quando a estrutura de IDoc tiver sido corrigida no sistema SAP.
Protocolo de transmissão ausente ou incorreto: Status de IDoc ‘63’
No recebimento de um IDoc no SAP, o processamento na entrada do protocolo de transmissão

para a categoria de IDoc (tipo de mensagem) e o parceiro de transmissão devem ser definidos.
Uma descrição mais exata dos protocolos de transmissão pode ser encontrada na documentação
on-line do Guia de implementação (IMG). Se o protocolo de transmissão e o método de entrada
para o IDoc receptor não puderem ser encontrados, a aplicação não pode ser ativada e o IDoc
permanece no sistema com status aberto. Nessa situação, proceder como segue:
 atualizar o protocolo de transmissão

 todos os Idocs abertos para transmissão devem ser definidos para retransmissão. Como
esse erro acionou um work item para a tarefa standard ‘ALE/EDI: processamento de erro
(saída)’ e o enviou para a entrada do usuário em questão, o IDoc incorreto também precisa
ser definido para transmissão subseqüente na entrada.
Erros nos protocolos de transmissão ocorrem normalmente na execução de teste.
O IDoc não é transferido para a aplicação no recebimento: Status de IDoc ‘64’
Embora o protocolo de transmissão tenha sido atualizado, o IDoc recebido não é processado e é
marcado como incorreto, ou seja, a aplicação não é controlada para processar esse IDoc. Embora
o IDoc esteja pronto para ser transmitido para a aplicação, é necessário definir explicitamente a
aplicação para processar o IDoc.
Isso é feito através do relatório RBDAPP01, que pode ser planejado como um job periódico ou
iniciado diretamente pelo menu de transporte Logística ® Vendas e distribuição ® Transporte ®
Sistemas externos ® Planejamento transporte ® Monitoramento ALE ® Trabalhos periódicos ®
IDocs em saída ALE ® Enviar.
Como na transmissão, o tipo de processamento é obtido no protocolo de transmissão. No

processamento ‘1’, os IDocs são transferidos para processamento na aplicação imediatamente
Página 64 de 66
após o recebimento. No processamento ‘3’ e, em parte, no processamento ‘2’, o processamento
não deve ser controlado diretamente, mas explicitamente.
O status ‘64’ no IDoc só ocorre normalmente em conjunto com os processamentos ‘3’ e ‘2’.
Erros lógicos na aplicação
Os erros descritos a seguir, que ocorrem na aplicação, são relativos a um IDoc de entrada no SAP.
O IDoc a ser transferido é estruturado na aplicação, de forma que qualquer opção de customizing
ausente ou incorreta será identificada diretamente no processamento do SAP como, por exemplo,
ao criar ordens de planejamento.
Os seguintes erros podem ocorrer na aplicação durante o processamento na entrada de um IDoc

no sistema SAP:
 Opções de customizing ausentes ou incorretas no sistema SAP

 Dados ausentes ou incorretos no IDoc
 Erro causado por objetos bloqueados
O IDoc incorreto é marcado com status ‘51’.
Opções de customizing ausentes ou incorretas no sistema SAP
O IDoc recebido não pode ser processado porque determinados dados do IDoc não foram
atualizados no sistema. Uma categoria de transporte, por exemplo, é transferida de um transporte
registrado no subsistema que não foi definido no sistema SAP. É necessário implementar as
opções de customizing para esses erros; o envio do IDoc incorreto pode ser controlado
posteriormente. O envio pode ser feito da entrada da pessoa responsável ou através do relatório
RBDMANIN, que pode ser planejado como um job periódico ou iniciado pelo menu de transporte
Logística ® Vendas/distribuição ® Transporte ® Sistemas externos ® Planejamento transporte ®
Monitoramento ALE ® Trabalhos periódicos ® IDocs em saída ALE ® Reenviar.
Dados ausentes ou incorretos no IDoc
Se os dados no IDoc recebido estão incompletos, é necessário decidir se o IDoc incorreto deve ser
retransmitido ou se é possível ou razoável efetuar as correções no sistema SAP. Também é
possível corrigir o IDoc diretamente. Isso pode ser feito através do Editor IDoc, mas só deve ser
feito em casos excepcionais.
Da mesma forma que os erros em opções de customizing, o IDoc incorreto pode ser enviado da
entrada do usuário responsável ou através do relatório RBDMANIN.
Erros causados por objetos bloqueados
Freqüentemente o bloqueio de objetos individuais gera erros no processamento do SAP. Mais de

um acesso a um objeto SAP irá encerrar o processamento, com uma nota de erro para o objeto
bloqueado. Esse erro é tratado como todos os outros erros no processamento de IDocs. O usuário
não precisa fazer nada para resolver o problema, uma vez que o reprocessamento posterior o
resolve automaticamente. Isso significa que é possível usar o processamento em background (job
periódico) do relatório RBDMANIN para enviar o IDoc. O parâmetro ‘status de erro’ nesse relatório
utiliza a identificação da mensagem de erro para restringir o envio para determinados erros; neste
caso, só para as mensagens relativas a um erro de bloqueio.
Notas de erro importantes na entrada
Para cada erro descrito é criado um work item, que é colocado na entrada do usuário responsável.
Work items são utilizados para determinadas notas de erro importantes, que são transmitidas
Página 65 de 66
diretamente do subsistema ou estruturadas no processamento do IDoc na aplicação. Os work
items não são utilizados para reiniciar o processamento de IDocs da entrada, mas para informar ao
usuário sobre um conflito ou para enviar uma mensagem importante do subsistema para o sistema
SAP. A mensagem é transferida para o SAP pelo IDoc SYSTAT01.
Ao contrário dos erros, o work item para notas não é processado da entrada, mas completado.
Página 66 de 66

Funçoes para o Processamento de IDOC

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Funçoes para o Processamento de IDOC

Enviado por

Direitos autorais:

Formatos disponíveis

Funções para o processamento de IDOC

Permite o processamento de determinadas informações no nível do campo ou do segmento ao

Observação: Os sistemas do parceiro tem de ser identicos, não é necessário filtrar os

Existem várias possibilidades para a conversão do conteúdo:

 Atribuíção de constantes ( => SET );

Passos para definir uma regra de conversão:

1. Definição da regra: As regras são definidas sempre por segmentos.

Definir aqui uma regra de conversão por cada tipo de segmento.

Exemplo: Definição de uma regra de conversão E1MARRG para o tipo de segmento

Nesta etapa determina-se como os campos de um objeto de origem são reproduzidos em um

Diferentes opções por objeto

Os objetos possuem diferentes características estruturais. A validade de dados de movimento

Estrutura emissora e receptora

A primeira tela é específica da aplicação. Na primeira tela determina-se a estrutura emissora

 Em campos de características pode-se entrar um campo emissor a ser transferido. Campos

 Em campos que no R/3 desempenham o papel de índices, valores ou saldos,

A tela de detalhes para a atualização de regras de características

Pode-se utilizar as seguintes regras para as características:

1. Transferir o campo emissor

Atribuir os valores do campo emissor ao campo receptor. Através de Restringir conjunto

Atribuir um valor fixo ao campo receptor.

Atribuir determinados valores do campo emissor a um valor do campo receptor. Através de

Através da indicação de um offset e de um comprimento, pode-se estabelecer que apenas

5. Aplicação de regras gerais

Opções dependentes de aplicação

Em algumas aplicações, o usuário pode estabelecer o que acontece se um valor de característica

1. Definir o valor inicial

O valor contém o valor inicial.

2. Classificar como erro

Atribui-se um valor constante ao campo.

Atribui-se o valor de um campo emissor extraordinário.

Dependendo da aplicação, é possível determinar se um valor do campo receptor deve ser

Características especiais específicas de aplicação

Ao atualizar as regras de transferência para características relacionadas, é preciso observar

b) Porém, na transferência de dados é efetuada uma verificação completa para a

A tela de detalhes para a atualização de regras para índices

Entrar uma operação global. As seguintes operações globais encontram-se à disposição:

SUM, MIN, MAX, LAST, FIRST, COUNT.

Elas apresentam as seguintes descrições: a fórmula do índice é analisada e calcula-se um

A estrutura emissora contém os campos 'item do balanço' e 'saldo'. A estrutura emissora

Definir conversão de IDOC

A atribuição da regra de conversão ao tipo de segmento é efetuada por sistema emissor e

Nesta etapa são planejados os trabalhos periódicos.

Planejar verificação ativa de consistência

Para tal são necessárias as seguintes etapas de trabalho:

 Definir variiantes para o report,

Nesta seção são definidas as variantes para o report RBDCONCH.

Por standard, não estão criadas variantes.

 Executar a função e entrar "RBDCONCH", clicar sobre as variantes e selecionar modificar

Nesta etapa é planejado o job para a verificação da consistência ativa.

Tem de estar atualizada uma variante para o report RBDCONCH.

Por standard, nenhum job está planejado.

 Definir um job com a etapa RBDCONCH e a variante atualizada.

Planejar monitoring ativo

Durante a seleção analisar-se-ão os IDocs que cumpram os critérios de seleção. Os valores de

Nessa altura pode planejar-se o report RSEIDOCM, que executará periodicamente a

Nesta seção são definidas as variantes para o report RSEIDOCM.

Por standard, não foram criadas variantes.

 Executar a função e entrar "RSEIDOCM", clicar nas variantes e selecionar modificar

Tem de estar atualizada uma variante para o report RSEIDOCM.

Por standard, não está planejado nenhum job.

 Definir um job com a etapa RSEIDOCM e a etapa atualizada.

Planejar geração de IDOC a partir de indicadores modificação