Anveo EDI Connect / Config / Mappings / Modelagem de fluxos de trabalho de mapeamento
Esta é uma tradução automática. O post original está disponível em Inglês .

Modelagem de fluxos de trabalho de mapeamento

Na Anveo EDI Connect, você normalmente usa múltiplos mapeamentos para modelar um processo EDI. A seguir, vamos dar uma olhada em exemplos muito simples e outro mais complexo. O módulo é muito flexível e você pode mapear o processo da maneira que quiser, mas os exemplos a seguir são a nossa maneira recomendada de modelar o processo.

Antes de entrarmos em demasiados detalhes, vamos esclarecer alguns conceitos. Um mapeamento no Anveo EDI Connect pode ser executado. Depois há o conceito de uma transação de banco de dados. Simplificando, uma transacção de base de dados recolhe todas as alterações à base de dados durante uma transacção. No final da transação, os dados podem ser armazenados permanentemente, o que é chamado de compromisso de banco de dados. Ou as alterações podem ser redefinidas, ou seja, todas as alterações feitas durante a transação são desfeitas e não gravadas. Cada execução de um mapeamento é feita em uma transação de banco de dados separada. Se houver um erro durante a execução do mapeamento, a transação é transferida para trás. Caso contrário, a transação é comprometida. (Isto é verdade para a maioria dos mapeamentos. Na Anveo EDI Connect há gatilhos de tabela que podem executar código arbitrário. Se esse código contiver um comando COMMIT, o módulo não poderá reverter as alterações. Isto pode levar a comportamentos indesejados).

Ordem de venda de XML recebida

Usamos três mapeamentos neste exemplo, para importar um arquivo XML. Este é o mínimo recomendado. No primeiro passo, vamos mapear a estrutura de dados externos para as tabelas de buffer. A idéia é importar os dados, mesmo que nem todos os dados possam ser processados. Isto permitirá ao usuário final corrigir erros na transação EDI, sem o conhecimento do formato dos dados externos. Claro que isto só é possível, se houver erros de dados, não se a estrutura do arquivo não puder ser analisada.

O próximo passo é verificar os dados. Aqui você pode adicionar qualquer verificação lógica nos dados comerciais. Recomendamos fazer isso em uma etapa separada antes do processamento para coletar várias mensagens de erro e dar ao usuário final um protocolo de erro completo. Se você precisar consultar os dados da tabela do sistema e quiser persistir, faríamos isso em uma quarta etapa entre o mapeamento externo e o mapeamento de cheques.

O último passo é a criação do documento Microsoft Dynamics NAV 2009R2 RTC. Fazemos isso em uma etapa separada, para manter os cadeados de mesa nas mesas do sistema o mais curto possível.

Fatura EDIFACT de saída

Nos documentos de saída, geralmente há alguns valores, que não são armazenados diretamente na tabela de origem do Microsoft Dynamics NAV 2009R2 RTC. Para dar ao usuário final a possibilidade de ver esses dados e simplificar o mapeamento do formato de dados externos, recomendamos escrever primeiro os dados em uma tabela buffer. Nesta etapa você pode consultar os valores e fazer cálculos.

O mapeamento de exportação apenas pega nos dados armazenados em buffer e os escreve no formato de destino.

Processo EDI com Confirmação

O processo não tem de ser linear. Se você precisar enviar confirmações ou se quiser agrupar dados, você pode sempre chamar vários mapeamentos a partir de um mapeamento. Você também pode usar condições e ramificações condicionais, para executar diferentes mapeamentos com base nos dados.

Como configurar o fluxo de trabalho

Entraremos nos detalhes mais tarde. Se você quiser avançar, nós usamos duas técnicas para estruturar o fluxo de trabalho de mapeamento. As transações comerciais e o pós-processamento.