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 61

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 61

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

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.

Página 3 de 61

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

O caso é registrado como erro.

3. Definir a constante

Atribui-se um valor constante ao campo.

Página 4 de 61

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.

É 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.

Página 5 de 61

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

As regras têm de estar criadas e atualizadas com as primeiras duas etapas.

Página 6 de 61

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.

Opções standard

Por standard, nenhum job está planejado.

Página 7 de 61

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) Atualizar os atributos para a variante Gravar a variante

Planejar jobs

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.

Página 8 de 61

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.

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).

Página 9 de 61

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.

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.

Página 10 de 61

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. Atualizar os atributos para a variante. Gravar a variante. 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.

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

Página 11 de 61

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.

Outras observações

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 um nome para a variante e selecionar criar. Entrar o tipo de mensagem (z.B. BLAORD). Atualizar os atributos para a variante. Gravar a variante. 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.

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.

Página 12 de 61

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. Criar um job para cada variante definida anteriormente.

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 Entrar um nome para a variante e selecionar criar. 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 Atualizar os atributos para a variante Gravar a variante

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.

Página 13 de 61

Atividades

Definir um job com a etapa RBDMOIND e a variante atualizada. 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.

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. Executar a função e entrar "RBDSTATE", clicar sobre as variantes e selecionar modificar. Entrar um nome para a variante e selecionar criar. Atualizar os atributos para a variante.

- 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.

Gravar a variante. 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.

Página 14 de 61

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. Criar um job para cada variante definida anteriormente.

Outras observações

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.

Outras observações

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.

Página 15 de 61

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. 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 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:

Página 16 de 61

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).

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.

Página 17 de 61

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 "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.

Página 18 de 61

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.

Outras observações

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)

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 2EDIO TS00007989 ErrorMessage 2EDIX TS00008070 SynErrorOut 2EDIY TS00008074 SynErrorInb 2EDIM TS00007988 ErrorMessage 2

Página 19 de 61

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).

Outras observações

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.

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

Página 20 de 61

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 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.

Outras observações

Considerar tanmbém os objetos de autorização da base e, se necessário, de outras aplicações.

Página 21 de 61

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 22 de 61

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 LOGSYS015 Sistema Lógico para o Mandante 015 LOGSYS020 Sistema Lógico para o Mandante 020

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

LOGSYS010 Sistema Lógico para o Mandante 010

LOGEXTERN Sistema Lógico Externo

COSMAS Master centro de custo DEBMAS Mestre de cliente DOCMAS Documento mestre FIDCC1 Envio de documentos FI c FIPAYM Dados de pagamento

Página 23 de 61

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.

LOGEXTERN Sistema Lógico Externo

<=== LOGSYS010 Sistema Lógico para o Mandante 010 COSMAS Master centro de custo DEBMAS Mestre de cliente DOCMAS Documento mestre FIDCC1 Envio de documentos FI completos (use FIPAYM Dados de pagamento

LOGSYS010 Sistema Lógico para o Mandante 010

===> LOGEXTERN Sistema Lógico Externo COSMAS Master centro de custo DEBMAS Mestre de cliente DOCMAS Documento mestre FIDCC1 Envio de documentos FI completos (use FIPAYM Dados de pagamento

Página 24 de 61

Verif. consistência Consistência técnica

LOGEXTERN Sistema Lógico Externo COSMAS Master centro de custo DEBMAS Mestre de cliente DOCMAS Documento mestre FIDCC1 Envio de documentos FI compl FIPAYM Dados de pagamento SYNCH Comunicação síncrona (ex: ve

aplicação Consistência dados controle

LOGEXTERN Sistema Lógico Externo COSMAS Master centro de custo DEBMAS Mestre de cliente DOCMAS Documento mestre FIDCC1 Envio de documentos FI compl FIPAYM Dados de pagamento

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 25 de 61

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 VarianteFunção Test

LOGEXTERN LS COSMAS LOGEXTERN LS DEBMAS LOGEXTERN LS FIDCC1 LOGEXTERN LS FIPAYM

Nº parceiro Tp.Funç. Tipo mensagem VarianteFunção Test

LOGSYS010 LS COSMAS LOGSYS010 LS DEBMAS LOGSYS010 LS FIDCC1 LOGSYS010 LS FIPAYM

Página 26 de 61

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 27 de 61

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 IDOCBD83 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 produtosWPCI Editar IDocs catálogo de produtos WPCJ Editar IDocs itens catálogo produtosWPIA Repetir a entrada dos IDocs POS WPIE Entr.IDocs modificados WTR1 Solicitação IDoc meios aux.vendas

Página 28 de 61

TRANSAÇÕES QUE ENVOLVEM ALE

AWW1 Iniciar infos imobilizado via ALEWEBBALA 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 infoMM90 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 / DIOYE4 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 29 de 61

TIPOS DE IDOC

Tipo básico Descrição

ABSEN1 Presenças/ausências em KK1ACCONF01 Confirmação do processamento do IDoc da aplicaçãoACC_ACT_ALLOC01 Contabilidade: lançar alocação de atividadeACC_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áriosACC_PURCHASE_ORDER01 Contabilidade: lançar pedidoACC_PURCHASE_REQUI01 Contabilidade: lançar requisição de compraACC_REVENUES01 Contabilidade: lançar receitasACC_SENDER_ACTIVITIES01 Contabilidade: lançar atividades prestadasACC_STAT_KEY_FIG01 Contabilidade: lançar índices estatísticosACLPAY01 Posting in accounting: Inbound invoiceACLREC01 Posting in accounting: Billing documentACPJOU01 Posting in accounting from materials managementACTIV3 Units in KK3ACTIV4 Units in KK4ALEAUD01 Confirmações sobre status de processamento de IDocs entradaALEREQ01 General request - Basis IDoc typeARTMAS01 Criar e modificar dados mestre de material (varejo)ASSMOD01 Sortimentos (módulos manuais)BATCH5 Lote em KK5BETMAS01 Site master data distribution ALEBLAORD01 Contratos de compraBLAORD02 Contratos de compraBLAREL01 ContractBOMDOC01 Mestre lista técnica - documentoBOMMAT01 Mestre lista técnica - materialBTC_ID01 Ordem de processo com componentesBTC_ID02 Requisição de compra do sistema standardBTC_ID03 Compromisso de produção com o sistema standardCBPRCP01 Rough-cut planning profileCHRMAS01 Mestre característica dados básicosCHRMAS02 Característica mestre com dependência de objetosCLFMAS01 Mestre classificação de objetosCLSMAS01 Master classCLSMAS02 Distribuição de classes com dependência de objetosCMREQU01 TR-CM: Invitation to TR-CM system to send dataCMSEND01 TR/CM-IDOC: Transfer of TR-CM dataCNPMAS01 Perfil de configuração mestreCOACOR01 Core master tipo de atividadeCOACTV01 IDOC para centro de custo/tipo de atividadeCOAMAS01 Mestre tipo de atividade

Página 30 de 61

COCOKA01 Segmento de controle objeto CO/classe de custoCODCMT01 IDOC para um documento COCOELEM01 Classes de custo: distribuição dos dados mestreCOGRP01 IDOC para grupos de CO (p.ex.grupos de centros de custo)CONDAT01 Change to customizing dataCOND_A01 Intercâmbio de condições: dds.mestre p/a determinação preçoCONF11 Confirmações em KK1CONF21 Confirmations in KK2, time eventsCONF31 Confirmations in KK3, time eventsCONF32 Confirmations in KK3, wage slipsCONF41 Confirmations in KK4, time eventsCONF42 Confirmations in KK4, wage slipsCONF51 CC5 confirmations run schedulesCOPAGN01 CO-PA entryCOPCPA01 Transferir cálculo de custos do produto CO-PC -> CO-PACOPCPA02 Copiar cálculo de custos do produtoCOSCOR01 Core master centro de custoCOSMAS01 Master centro de custoCOTOTL01 IDOC para registros de totais COCRECOR01 Vendor master data distribution ALE Core master dataCREMAS01 Credor distribuição de dados mestre ALECRESTA01 Repetir status de crédito (DebtorCreditAccount)DEBCOR01 Core master - customerDEBMAS01 Cliente mestreDEBMAS02 Cliente mestreDEBMAS03 Cliente mestreDELFOR01 Delivery schedule/JIT scheduleDELVRY01 Delivery interfaceDESADV01 Shipping notificationDES_ID01 Aviso de entregaDIFFE2 Differences in KK2DIFFE3 Differences in KK3DIFFE4 Differences in KK4DISTU2 Reasons for problems KK2DOCMAS01 Master documentDOCMAS02 Documento 02DOCMAS03 DocumentoDWLOAD Download transceiver configurationECMMAS01 Estrutura IDOC para controle de alteraçõesEKSEKS01 Dados do doc.compra para o sist.info comprasEXPINV01 IDOC doc.faturamento export.(E.F.I.)EXPINV02 Comério externo -IDoc doc.faturamentoEXTWA1 Rúbricas salariais externasFIDCCH01 IDOC p/modificações de um doc.FI (bloqueio contra reclam.)FIDCCP01 IDoc: documento FI completoFIDCMT01 IDoc para documentos FIFINSTA01 Account Statement, Lockbox, Polling InfoFIPARQ01 IDoc para dados de pagamento FIGLCORE01 Documentation deletedGLDCMT01 IDoc para rollups GLX

Página 31 de 61

GLMAST01 Dados mestre contas do Razão: IDoc máximoGSVERF01 IDOC entrada procedimento de nota de créditoHRCNF01 Aceitar confirmações (TimeMgtConfirmation)HRKK1ABSR HR TIM KK1: motivos de presença/ausência permitidosHRKK1EWUP HR TIM KK1: confirmação de rubricas salariais externasHRKK1EXWT HR TIM KK1: rubrs.sals.extrns.permitidasHRKK1PERS HR TIM KK1: mini registro mestre HR para registro de horasHRKK1TBAL HR TIM KK1: saldos de horas empregadoHRKK1TEUP HR TIM KK1: confirmação de eventos com registro hora pessoalHRKK1TEVT HR TIM KK1: tipos de evento com registro de hora permitidosHRKK1WRKC HR TIM KK1: centros de trabalho permitidosHRMD_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/COHRPLL40 Confirmações de logística p/gerenciamento recursos humanosHRTRPR01 Transferência TRV-PAY(PayrollTravelExpnses)HRTRVL01 HR-TRV: transferência despesas de viagens FI/COHRTRVL03 HR-TRV: transferência despesas de viagem folha de pagamentoIDCREF01 Mensagem de refer.como parêntese lóg.p/assinatura eletrônicaIMPINV01 Import Basis IDoc (I.B.I.)INFREC01 Purchasing info recordINVCON01 Dados de modificação de estoque p/o controlling de estoqueINVOIC01 Fatura/doc.faturamentoINVOIC02 Fatura/doc.faturamentoINV_ID01 FaturaKNOMAS01 Depend.objetos mestre: dados básicosLABELS00 ISR labeling: labelLIKOND01 Condições de catalogaçãoLIS_EXTR LIS inbound interface for external dataLOCAT5 Location in KK5LOIBOM01 Mestre lista técnicaLOICAL01 Mestre calendárioLOINUM01 Número dos IDOCs enviadosLOIPGR01 IDOC for product groupLOIPLO01 Mestre ordem planejadaLOIPRO01 Mestre ordem de produçãoLOIRNH01 Mestre hierarquia/diagramas de redeLOIROU01 Mestre roteiroLOIRSH01 Mestre cabeçalho da ordem de produção repetitivaLOISTD01 Mestre lista de estoques/necessidadesLOITMX01 Matriz de transiçãoLOIWCS01 Mestre centro de trabalhoLOIWCS02 IDoc mestre centro de trabalhoLPIPCM01 Campanha de produçãoMALFK5 CC5 reasons for scrapMATCOR01 Core master materialMATMAS01 Mestre materialMATMAS02 Mestre materialMATMAS03 Mestre material

Página 32 de 61

MRESCR01 Criar reservaOPERA2 Operations in KK2OPERA3 Processes in KK3OPERA4 Operations in KK4OPERS3 Operation status in KK3OPERS4 Operation status in KK4ORDERS01 Compras/vendaORDERS02 Compras/vendaORDERS03 Compras/vendaORD_ID01 Solicitação/cotação/pedido/modificação do pedidoOSTAT2 Status da operação KK2PALMAT01 Atribuição de centro para lista técnica materialPEROP2PERSO1 Registros mestres HR em KK1PERSO2 Registro mestre HR em KK2PERSO3 Registro mestre HR em KK3PERSO4 Registro mestre em KK4PEXR2001 Pag./aviso de pag./exib.nota crédito/exib.débitos lançadosPKHD5 KK5 Circuitos reguladores KanbanPKPS5 KK5 recipiente kanbanPKST5 KK5 Status para container KanbanPLANT3 Centros em KK3PLANT4 Centros em KK4PORDCR01 Criar pedidoPRCMAS01 Registro mestre de centro de lucroPRDCAT01 Catálogo de produtosPRDPOS01 Item do catálogo de produtosPREQCR01 Criar req.compraPREQDL01 Eliminar/concluir req.compraREQUI1 Solicitação de confirmação em KK1REQUI2 Solicitação de confirmação em KK2REQUI3 Solicitação de confirmação em KK2REQUI4 Solicitação de confirmação em KK4REQUI5 Solicitação de confirmação em KK5RSINFO BIW: IDoc info sobre os transportes de dadosRSREQUST BIW: requisição de dados a OLTPRSSEND BIW: enviar dados do sistema de origem para BIW (modelo)SAPRDI01 SAPscript Raw Data Interface IDOC TypeSCS02O01 External PO qt (semi conductor)SCS99N01 Semiconductor supply qtSDPAID01 Confirmação dados elemento de expedição p/entrega ao clienteSDPIID01 Confirmação de dados de picking para entrega ao clienteSDPIOD01 Mensagem de picking ao subsistema:SERDAT01 Dados de controle serializaçãoSHPMNT01 ShipmentSHPMNT02 ShipmentSISCSO01 SISD - ordem do clienteSISDEL01 VIS - deliverySISINV01 SISD - documento de faturamentoSOPGEN01 Distribuição da estrutura de info geral

Página 33 de 61

SRCLST01 Lista de opções de fornecimentoSRVMAS01 Registro mestre de atividades com textosSYIDOC01 CA-EDI: Transport of IDoc typesSYNCHRON Tipo de IDOC dummy para comunicação síncronaSYRECD01 CA-EDI: Transport of IDoc record typesSYSTAT01 CA-EDI: Transfer from status recordsTPSDLR01 Seleção via variante de um sistema externoTPSDLS01 Envio de docs.remessa p/um sistema de planej.transporteTPSLOC01 Envio de dados mestre local p/um sist.planej.transporteTPSSHT01 Envio de transportes planejados do sistema de transportesTXTRAW01 WF-EDI: Transferring free text to SAPoffice format 'RAW'UNIMA2 Unidades de medidas alternativas com referência ao materialUNIT2 Unidades em KK2UNIT3 Unidades no KK3UNIT4 Unidades no KK4UPLOAD Configuração de transceiver para uploadVTAMAS01 Mestre tabela de variantesVTMMAS01 Mestre atualização conteúdo de tabelaWBBDLD01 Lista de sortimento: dados de materialWBBDLD02 Lista de sortimento: dados de material (rel.4.0)WBB_ID01 Order book: Product messageWGSREQ01 Order receipt IS-RWGSREQ02 IDoc ordem de filial (incl.segmento de condição)WMBIID01 Bloquear posições no depósitoWMCAID01 Estorno/solicitação de estorno ordem de transporteWMINID01 Texto info para o acoplamento de subsistemasWMIVID01 Entrar resultados da contagemWMMBID01 Movimentos de mercadorias para entrada de dados móveisWMMBID02 Movimentos de mercadorias de sistemas externosWMRRID01 Liberação nº referênciaWMSUID01 Movimentar unidade de depósitoWMTCID01 Confirmar ordem de transporteWMTCID02 Confirmar ordem de transferênciaWMTOID01 Transport requestWMTRID01 Necessidade de transporteWORKC2 Centros de trabalho em KK2WORKC3 Centros de trabalho em KK3WORKC4 Centros de trabalho em KK4WPDCUR01 Interface POS: download taxas de câmbioWPDNAC01 Interface POS: download artigos pertencentesWPDSET01 Interface POS: download atribuições de setWPDTAX01 Interface POS: download taxas de impostoWPDWGR01 Interface POS: download mestre de grupo de mercadoriasWPUBON01 Interface POS: upload docs.vendas (recibos) não compactadosWPUERR01 POS interface: Upload messages FWWS/POS/SCSWPUFIB01 Interface POS: upload interface contab.financ.FWWS/POSWPUKSR01 Interface POS: upload dos dados do caixa p/estatística POSWPUTAB01 Interface POS: upload encerramento do dia POSWPUUMS01 Interface POS: upload dados de vol.vendas compactadosWPUWBW01 Interface POS: upload movimentos de mercadorias

Página 34 de 61

WP_EAN01 Interface POS: upload e download atribuições EANWP_PER01 Interface POS: upload e download dados de pessoasWP_PLU01 POS interface: Upload/Download article masterWP_PLU02 Interface POS: material e condição (entrada e saída)WTADDI01 Meios aux.vendasWVINVE01 Store phy.inv.: phy.inv. docs outbound; count data inboundWVINVE02 Invent.filial: saída docs.invent., entrada dados contagem

Página 35 de 61

EDI: categorias de mensagens lógicas

Mensagem lógica Descrição breve

ABSEN1 Presenças/ausências em KK1ACCONF Confirmação do processamento do IDoc da aplicaçãoACC_ACT_ALLOC Contabilidade: lançar alocação de atividadeACC_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_MOVEMENT

Contabilidade: lançar mov.de mercadoria (OAG: POST JOURNAL)

ACC_INVOICE_RECEIPT Contabilidade: lançar entrada de fatura (OAG: LOAD PAYABLE)ACC_PRIM_COSTS Contabilidade: lançar custos primáriosACC_PURCHASE_ORDER

Contabilidade: lançar pedido

ACC_PURCHASE_REQUI Contabilidade: lançar requisição de compraACC_REVENUES Contabilidade: lançar receitasACC_SENDER_ACTIVITIES

Contabilidade: lançar atividades prestadas

ACC_STAT_KEY_FIG Contabilidade: lançar índices estatísticosACLPAY Contabilidade: fatura recebidaACLREC Contabilidade: doc.faturamentoACPJMM Lançamento na contabilidade proveniente da adm.materialACTIV3 Unidades no KK3ACTIV4 Unidades no KK4ALEAUD Confirmações sobre status de processamento de IDocs entradaALEREQ Mensagem geral de solicitaçãoARTMAS Criar e modificar dados mestre de material (varejo)ASSMOD SortimentosBATCH5 KK5 loteBETMAS Mestre cent.BLAOCH Modificação do contrato de compraBLAORD Contratos de compraBLAREL Documentação da solic.remessa p/contratos distribuídosBOMDOC Listas técnicas: lista técnica c/ref.documentoBOMMAT Listas técnicas:lista técnica c/ref.materialCARNOT Fornecimento: notificação de expediçãoCBPRCP Rough-cut planning profileCHRMAS Sistema de classes: características mestreCLFMAS Sistema de classes: classificação mestreCLSMAS Sistema de classes: classes mestreCMREQU Solicitar o subsistema TR-CM para o envio dos dados TR-CMCMSEND O subsistema TR-CM envia os dados TR-CM para TR-CM

centralCNPMAS Perfil configuraçãoCOACOR Core master tipo de atividadeCOACTV IDOC para centro de custo/tipo de atividadeCOAFET Solicitar tipo de atividadeCOAMAS Mestre tipo de atividade

Página 36 de 61

COCOKA Segmento de controle objeto CO/classe de custoCODCMT IDOC para um documento COCOELEM Classes de custo dados mestreCOGRP1 Grupos de centros de custoCOGRP2 Grupos de classes de custoCOGRP5 Grupos de tipo de atividadeCOGRP6 Grupos de centros lucroCOGRP9 Grupos de conta (contabilidade de centro de lucro)CONDAT Dados de controleCONDBI Índice de condição para modificações de documentoCOND_A Condições: dados mestre para a determinação de preçosCONF11 Confirmações em KK1CONF21 Confirmações em KK2, evento c/registro de horaCONF31 Confirmações em KK3, evento c/registro de horaCONF32 Confirmações em KK2, folha de temposCONF41 Confirmações em KK4, evento c/registro de horaCONF42 Confirmações em KK4, folha de temposCONF51 Confirmações em KK5, ordem de produção repetitivaCONFIG Configuração para TransceiverCOPAGN Demonstr.resultadoCOPCPA Dados de cálculo CO-PC -> CO-PACOSCOR Core master centro de custoCOSFET Solicitar centro de custoCOSMAS Master centro de custoCOTOTL IDOC para registros de totais COCPS001 Demonstr.resultadoCREADV Exibição de nota de créditoCRECOR Core Master Data fornecedoresCREFET Buscar nos dados do fornecedorCREMAS Distribuir mestre de fornecedoresCRESTA Repetir status de crédito (DebtorCreditAccount)DEBADV Exibição de débitos lançadosDEBCOR Core Master mestre de clienteDEBFET Solicitar mestre de clienteDEBMAS Mestre de clienteDELINS Sol.rem./sol.rem.just in time p/o forncedor de componentesDELORD Ordem de fornecimentoDESADT Aviso de transporteDESADV Fornecimento: aviso de entregaDIFFE2 Desvios em KK2DIFFE3 Desvios em KK3DIFFE4 Desvios em KK4DIRDEB Cobrança bancária automáticaDISTU2 Motivos da avaria KK2DOCMAS Documento mestreDWLOAD Download configuração de TransceiverECMMAS Controle de modificaçõesEDLNOT Nota de remessa PSEKSEKS Documento de compra para o sist.info comprasEUPEXR Mensagem refer.p/assinatura eletrônica (em pgtos.ampliados)

Página 37 de 61

EXPINV Fatura exportaçãoEXTWA1 Rúbricas salariais externasFIDCC1 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.FIFIDCMT FI-IDOC para enviar partidas individuaisFINSTA Extrato de contaFIPAYM Dados de pagamentoFIROLL 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ãoGLM000 Teste redução GLMASTGLMAST Dados mestre contas do Razão (IDOC mestre)GLROLL Rollup ctg.mensagem FI-GLXGSVERF Procedimento de nota de créditoHRCNF Aceitar confirmações (TimeMgtConfirmation)HRCONF Confirmações da logística p/gerenciamento recursos humanosHRCPRQ Planejamento de custos c/pessoal - solicitação de CO p/ HRHRINW Folha de tempos da logísticaHRMD_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/COHRPRS Ausências da logísticaHRTRPR Transferência TRV-PAY(PayrollTravelExpnses)HRTRPY HR-TRV: transferência custos de viagens p/salário & ordenadoHRTRVL HR-TRV: transferência custos de viagens FI/COIMPINV Declaração de importaçãoINFREC Registro info para comprasINVCON IDOC controlling de estoquesINVOIC Fatura / doc.faturamentoKNOMAS Dependência de objetos globalKOMMOD Módulo de comunicação/transceiverLABELS WWS: etiquetagemLCROLL Consolidação legalLIKOND Condições de catalogaçãoLIP002 Distributed IS planningLIP021 IS distribuída - planejamentoLIP032 Upload estrutura de info estoques de depósito (S032)LIP035 Upload estrutura de info estoques de lote (S035)LIP125 IS distribuída - planejamentoLIS000 SIL dados externos: transmissãoLOCAT5 Depósito das ordens de produção repetitivaLOCKBX LockboxLOIBOM Lista técnicaLOICAL CalendárioLOINUM IDOC para o num.de IDOCs enviadosLOIPGR IDoc for product groupLOIPLO Ordem planejadaLOIPRO Ordem de produçãoLOIRNH Hierarquia/diagrama de rede

Página 38 de 61

LOIROU RoteiroLOIRSH Cabeçalho da ordem de prod.repetitivaLOISTD Lista nec./estoqueLOITMX Matriz de transiçãoLOIWCS Centro de trabalhoLPIPCM Campanha de produçãoMALFK5 Motivos da avaria, ordens prod.repetitivaMALFU2 Avarias em KK2MATCOR Core Master MaterialMATFET Solicitar materialMATMAS Mestre materialMKCLF1 ets clfMRESCR Criar reservaOPERA2 Operações em KK2OPERA3 Operações em KK3OPERA4 Operações em KK4OPERS2 Status da operação em KK2OPERS3 Centros de trabalho em KK3OPERS4 Centros de trabalho em KK4ORDCHG Modificação de pedido/ordemORDERS Pedido / ordemORDRSP Confirmação do pedido/ordemOSTAT2 Status da operação KK2PALMAT Atribuição de centro para lista técnica materialPAYEXT Ordem de pagamento ampliadaPCROLL Rollup centro de lucroPEROP2PERSO1 Registros mestres HR em KK1PERSO2 Registro mestre HR em KK2PERSO3 Registro mestre HR em KK3PERSO4 Registro mestre em KK4PICKSD Confirmação de dados de picking para entrega ao clientePI_BTC Transferência de dados para sistema de referênciasPKHD5 Circuito regulador kanbanPKPS5 Recipiente KanbanPKST5 Status possível para recipiente kanbanPLANT2 Centros em KK2PLANT3 KK3: tabela de centrosPLANT4 KK4: tabela de centrosPORDCR Criar pedidoPRCFET Solicitar centro de lucroPRCMAS Registro mestre de centro de lucroPRDCAT Catálogo de produtosPRDPOS Item do catálogo de produtosPREQCR Criar req.compraPREQDL Eliminar/concluir req.compraPRODPL Reporting plano de produçãoQUOTES CotaçãoRCLROL Rollup do ledger de reconciliaçãoRECSHP Transportes recomendados

Página 39 de 61

REMADV Aviso de pagamentoREQOTE SolicitaçãoREQUI1 Solicitação de confirmação em KK1REQUI2 Solicitação de confirmação em KK2REQUI3 Solicitação de confirmação em KK2REQUI4 Solicitação de confirmação em KK4REQUI5 Solicitação de confirmação em KK5RSINFO IDOC informação Business Information WarehouseRSRQST Requisição de dados Business Information WarehouseRSSEND Envio de dados Business Information WarehouseSAPRDI Tipo de IDoc para interface de dados brutosSCS02O Purchasing doc. for LIS; semi conductor purposeSCS99N Semiconductor supply qtSDPACK Confirmação de dados do elemento de expediçãoSDPICK Confirmação dos dados de pickingSERDAT Mensagem de controle: distribuição serializadaSHIPPL Entrada transportes planejadosSHPCON Fornecimento: confirmação expediçãoSHPMNT Saída de transportesSHPORD Fornecimento: ordem de expediçãoSISCSO SISD: ordem de clienteSISDEL SISD: fornecimentoSISINV SISD: documento de faturamentoSMMMAN Mestre materialSOPGEN IS distribuída - planejamentoSRCLST Lista opções fornec.SRVMAS Dados mestre mestre de atividadesSTATUS Mensagem sobre a transmissão de infos de statusSYIDOC Transmissão de tipos de IDocSYNCH Comunicação síncrona (ex: verif.ALE)SYRECD Transmissão dos tipos de registros de IDocTPSDLR Sist.planejamento de transporte: acionar seleção fornecedorTPSDLS Sist.planejamento de transporte: acionar seleção fornecedorTPSDST Mensagem de modificação de status de um doc.vendas e distr.TPSLOC Sist.planej.de transporte: transf.dados mestre localizaçãoTPSSHT Sist.planejamento de transporte: transf.transporte planejadoTRIDOC EDI: transporte de definições de tipo de IDocTXTRAW Mensagem para texto livre em formato 'RAW' do SAPofficeUNIMA2 Unidades de medidas dependentes do materialUNIT2 Unidades em KK2UNIT3 Unidades no KK3UNIT4 Unidades no KK4UPLOAD Configuração de transceiver para uploadVTAMAS Estrutura de uma tabela de variantesVTMMAS Conteúdo de uma tabela de variantesWBBDLD Lista de sortimento: dados de materialWBBLAB Lista de sortimento: reduzida para etiquetagemWGSREQ VWWS: entrada ordem/confirmação de ordem

(GOODS_REQUIREMENT)WHSCON Fornecimento: confirmação de depósito

Página 40 de 61

WHSORD Fornecimento: ordem de depósitoWMBBIN Bloquear posições no depósitoWMCATO Estorno/solicitação de estorno ordem de transporteWMINFO InformaçãoWMINVE Entrada de resultado da contagem de inventárioWMMBXY IDOC notificar movimentos de mercadorias em IMWMRREF Liberação nº referênciaWMSUMO Movimentar unidade de depósitoWMTOCO Confirmar ordem de transferênciaWMTORD Ordem de transporteWMTREQ Criar/estornar necessidade de transferênciaWORKC2 Centros de trabalho em KK2WORKC3 Centros de trabalho em KK3WORKC4 Centros de trabalho em KK4WPDCUR Interface POS: download taxas de câmbioWPDNAC Interface POS: download artigos pertencentesWPDSET Interface POS: download atribuições de setWPDTAX Interface POS: download taxas de impostoWPDWGR Interface POS: download mestre de grupo de mercadoriasWPUBON Interface POS: upload docs.vendas (recibos) não compactadosWPUERR Interface POS: upload mensagens FWWS/POS/SCSWPUFIB Interface POS: upload interface contab.financ.FWWS/POSWPUKSR POS upload dados caixaWPUPAE Interface POS: upload modificações de preçoWPUTAB Interface POS: upload encerramento do dia POSWPUUMS Interface POS: upload dados de vol.vendas compactadosWPUWBW Interface POS: upload movimentos de mercadoriasWP_EAN Interface POS: upload e download atribuições EANWP_PER Interface POS: upload e download dados de pessoasWP_PLU Interface POS: upload e download mestre de artigosWTADDI Meio auxiliar de vendasWTADDI_CVB1 Meio auxiliar de vendas sem 06...WVINVE Inventário filial/modificação valor VK

Página 41 de 61

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 42 de 61

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.

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

Página 43 de 61

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 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 44 de 61

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 45 de 61

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ósitoL_IDOC_CREATE_WMRRID01 Número de referência de solicitação de remessaL_IDOC_CREATE_WMCAID01 Ordem de anulação de OTL_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.

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

Página 46 de 61

L_IDOC_HEADER_CREATE Gerar os dados EDIDC necessários para cada IDOCL_IDOC_SEGMENT_CREATE Gerar um segmento de IDOCL_IDOC_SEND Enviar os IDOCs geradosL_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 47 de 61

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 48 de 61

Página 49 de 61

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çãoCabeçalho Define conteúdo, estrutura, remetente, receptor e

status do IDocSegmento 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 MATMASListas técnicas LOIBOM01 LOIBOMRoteiros LOIROU01 LOIROUCentros de trabalho LOIWCS02 LOIWCSHierarquia de centros de trabalho LOIRNH01 LOIRNHRede de recursos LOIRNH01 LOIRNHCalendário da fábrica LOICAL01 LOICALClassificação de objeto CLFMAS01 CLFMASNúmero de IDocs transferidos LOINUM01 LOINUMGrupo de produtos LOIPGR01 LOIPGRMatriz de transição LOITMXL01 LOITMX

Página 50 de 61

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 51 de 61

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 segmento003 : eliminar segmento

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.

Página 52 de 61

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 53 de 61

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 54 de 61

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 55 de 61

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çõesManual 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.

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

Página 56 de 61

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".

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

Página 57 de 61

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 Mestrede

FornecedorTipo de mensagem MATMAS DEBMAS CREMASTipo de IDoc MATMAS01 DEBMAS01 CREMAS01Nome do programa RBDSEMAT RBDSEDEB RBDSECR

ETipo de mensagem de obtenção FETMAT FETDEB FETCRECódigo do processo de entrada MATF DEBF CREFMó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 58 de 61

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 59 de 61

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 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’.

Página 60 de 61

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 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 61 de 61