Integração Protheus x GFE
Contexto de negócio (Introdução)
A integração de dados entre rotinas do ERP Microsiga Protheus e o módulo SIGAGFE utilizando comunicação direta entre as rotinas, sem aplicativos intermediários e sem tráfego de dados no formato XML. O ponto de integração para Simulação de Fretes no Pedido de Venda já utiliza comunicação direta, por isso não necessitará intervenção. Serão mantidas as regras de negócio atuais da integração, alterando-se apenas o modelo de troca de dados.
A integração visa manter os dados cadastrais do ERP, quando necessário, sincronizados ao GFE; manter os dados relacionados a documentos, custos e despesas com transporte, integrados aos demais módulos do software ERP; e possibilitar a simulação do preço do frete durante os processos do ERP (pedidos de venda, pedidos de compra, faturamento etc.) nos quais essa informação possa ser necessária.
Sistemas Envolvidos
- ERP Microsiga Protheus;
- Módulo de Gestão de Frete Embarcado.
Integração
Modelo com EAI e TOTVS ESB
Modelo alterado
Lista dos pontos de integração de dados do ERP para o SIGAGFE
| Rotina ERP (MS Protheus) | Eventos | Model SIGAGFE |
|---|---|---|
| FISA010 – Cadastro de Municípios | Incluir, Alterar, Eliminar | GFEA020 – Cidades |
| MATA030 – Cadastro de Clientes | Incluir, Alterar, Eliminar | GFEA015 – Emitentes de Transporte |
| MATA050 – Cadastro de Transportadores | Incluir, Alterar, Eliminar | GFEA015 – Emitentes de Transporte |
| MATA020 – Cadastro de Fornecedores | Incluir, Alterar, Eliminar | GFEA015 – Emitentes de Transporte |
| CTBA180 – Cadastro de Centros de Custo | Incluir, Alterar, Eliminar | GFEA089 – Centros de Custo |
| CTBA020 – Cadastro de Contas Contábeis | Incluir, Alterar, Eliminar | GFEA090 – Contas Contábeis |
| TMSA530 – Cadastro de Tipos de Veículo | Incluir, Alterar, Eliminar | GFEA090 – Contas Contábeis |
| OMSA060 – Cadastro de Veículos | Incluir, Alterar, Eliminar | GFEA046 – Veículos |
| OMSA040 – Cadastro de Motoristas | Incluir, Alterar, Eliminar | GFEA012 – Motoristas |
| OMSA200 – Montagem de Cargas | Incluir, Alterar, Eliminar | GFEA050 – Romaneios |
| MATA460 – Notas Fiscais de Saída | Incluir | GFEA044 – Documentos de Carga |
| MATA521 – Cancelamento de Notas Fiscais | Eliminar | GFEA044 – Documentos de Carga |
| MATA103 – Documentos de Entrada | Incluir, Eliminar | GFEA044 – Documentos de Carga |
Em cada um dos programas haverá uma função para integração, a ser executada por cada evento listado, com a finalidade de montar a lista de informações a serem enviadas (vide de-para de campos na sequência desta especificação) para o objeto de negócio (model) indicado. Serão utilizadas as operações padrões de manutenção de registros da técnica MVC com o respectivo tratamento do retorno de mensagens de erro. A execução da função será condicionada aos parâmetros MV_INTGFE e MV_INTGFE2.
| Model SIGAGFE | Evento(s) | MSExecAuto |
|---|---|---|
| GFEA055 – Pré-fatura | Envio para ERP | FINA050 – Título a Pagar (Provisão) |
| GFEA065 – Documento de Frete | Envio para ERP | MATA103 – Documento de Entrada |
| GFEA065 – Documento de Frete | Envio para ERP | MATA140 – Pré-nota |
| GFEA065 – Documento de Frete | Envio para ERP | MATA116 – Nota de Conhecimento de Frete |
| GFEA065 – Documento de Frete | Envio para ERP | MATA116 - Pré-nota de Conhecimento |
| GFEA070 – Fatura de Frete | Envio para ERP | FINA050 – Título a Pagar |
| GFEA100 – Contrato com Autônomo | Envio para ERP | FINA050 – Título a Pagar |
| GFEA100 – Contrato com Autônomo | Envio para ERP | MATA116 – Nota de Conhecimento de Frete |
Em cada um dos programas será implementada a execução (MSEXECAUTO) do objeto de negócio correspondente do ERP, enviando a lista de informações (vide de-para de campos na sequência desta especificação) necessárias à inclusão ou eliminação de registros com o respectivo tratamento do retorno de mensagens de erro. As mensagens de erro ficarão registradas em campo descritivo dos próprios registros do SIGAGFE e para cada integração há um campo de controle indicando o estado: Não-integrado, Pendente, Rejeitado, Atualizado e Pendente de Cancelamento. Com a alteração do modelo de integração os estados “Pendente” e “Pendente Cancelamento” tornam-se obsoletos pois o resultado da integração será conhecido logo após o evento de “Envio para ERP”.
Entidades do ERP utilizadas diretamente pelo SIGAGFE (não precisam de integração)
| Rotina/Entidade |
|---|
| 01 (SX5) – Séries de Notas Fiscais |
| EICA100 – Países |
| 12 (SX5) – Unidades de Federação |
| QIEA030 – Unidades de Medida (SAH) |
Regras Gerais
1. Integração em Geral
a. Todas as integrações estão condicionadas ao parâmetro MV_INTGFE; o conteúdo “.T.” indica que a integração está ativa;
b. A integração direta, sem o uso de EAI e TOTVSESB está condicionada ao parâmetro MV_INTGFE2; os conteúdos “1” ou “S” indicam que a integração entre os módulos do ERP base e o SIGAGFE é direta;
2. Registros de Cadastros
a. No SIGAGFE há dois parâmetros que indicam a origem dos cadastros (ERP ou SIGAGFE): MV_CADERP (Municípios, Emitentes, Contas Contábeis e Centros de Custo) e MV_CADOMS (Tipos de Veículo, Veículos e Motoristas); o controle é separado porque algumas empresas não utilizam o SIGAOMS;
b. Os cadastros integrados entre ERP e SIGAGFE permitem inclusão apenas pelo ERP;
c. O SIGAGFE não permite eliminar os registros de cadastros recebidos do ERP; esse comportamento é condicionado ao parâmetro MV_CADERP = “1=ERP” (ou MV_CADOMS = “1=OMS”);
d. O SIGAGFE restringe a alteração dos registros de cadastros recebidos do ERP apenas aos campos próprios do SIGAGFE (que complementam os dados recebidos do ERP e são utilizados apenas pelo SIGAGFE); esse comportamento é condicionado ao parâmetro MV_CADERP = “1=ERP” (ou MV_CADOMS = “1=OMS”);
e. A eliminação de registros de cadastros no ERP altera a situação do registro no SIGAGFE para “Inativo”, sem eliminá-lo. Dessa forma não há impedimento para eliminação no ERP mesmo que o registro possua relacionamentos ativos com outras entidades do SIGAGFE. Ao incluir novamente um registro anteriormente eliminado (com a mesma identificação única), a integração retorna o registro no SIGAGFE para a situação “Ativo”. A situação “Inativo” impede que o registro seja relacionado a novos processos no SIGAGFE (um motorista “Inativo” não pode ser informado em uma nova montagem de Romaneio, por exemplo);
f. Apenas o evento de eliminação altera a situação (Ativo/Inativo) dos registros dos cadastros integrados; esse comportamento é condicionado ao parâmetro MV_CADERP = “1=ERP” (ou MV_CADOMS = “1=OMS”);
g. As operações de inclusão e alteração, dos cadastros integrados, não são completadas se houver erro de validação na integração com GFE; o usuário recebe uma mensagem informando quais são as inconsistências e assim avaliar como proceder corretamente com a operação.
3. Registros de Processos enviados pelo ERP
a. O parâmetro MV_FATGFE permite configurar se a conclusão da emissão de Notas Fiscais depende do êxito da integração com o SIGAGFE; a rotina de integração das Notas Fiscais com Erro de Integração permite realizar a integração posteriormente, amparando a existência desta opção;
b. A eliminação da Nota Fiscal só é concluída com sucesso se não houver erro de validação na integração com o SIGAGFE; podem ser requeridos ao usuário procedimentos no SIGAGFE para que não hajam restrições no SIGAGFE (a fim de impedir que sejam canceladas Notas Fiscais que já foram expedida, por exemplo) e a eliminação ocorra com êxito.
4. Registros de Processos enviados pelo SIGAGFE
a. Os dados gerados pelo GFE no ERP não pemitem eliminação pelo ERP, somente alteração. A eliminação deve ser solicitada pelo SIGAGFE (que executa a integração para eliminar o registro no ERP e retorna o registro da entidade de origem no SIGAGFE para a situação “Não-integrado”);
b. O SIGAGFE não envia alteração de dados, apenas inclusão e eliminação; no caso de necessidade de quaisquer alterações deve-se acionar a ação “Desatualizar ERP” no SIGAGFE sobre o respectivo registro que dessa forma pode ser alterado e posteriormente enviado novamente para o ERP.
5. Regras Particulares e Correspondência entre os Dados
Os campos que compõem a identificação única do registro estão destacados com asterisco. Os campos não indicados na tabela de correspondência devem assumir (na operação de inclusão) o valor inicial indicado no dicionário de dados (ação executada automaticamente pelo model). Nas alterações de registros os dados que não são atribuídos pela integração devem ser preservados. A correspondência entre os campo se baseia no mapeamento já existente da integração via XML, conforme a tabela abaixo:
| Integração | Arquivo de Mapeameto |
|---|---|
| FISA010 (Municípios) para GFEA020 (Cidades) | ProtheustoGFE_Munici_Cidade.xsl |
| MATA030 (Clientes) para GFEA015 (Emitentes) | ProtheustoGFE_Client_Emitente.xsl |
| MATA050 (Transportadores) para GFEA015 (Emitentes) | ProtheustoGFE_Transp_Emitente.xsl |
| MATA020 (Fornecedores) para GFEA015 (Emitentes) | ProtheustoGFE_Fornec_Emitente.xsl |
| CTBA180 (Centros Custo) para GFEA089 (Centros Custo) | ProtheustoGFE_Centro_Custo.xsl |
| CTBA020 (Plano Contas) para GFEA090 (Contas Contábeis) | ProtheustoGFE_Plano_Contas.xsl |
| TMSA530 (Tipos Veículo) para GFEA045 (Tipos Veículo) | ProtheustoGFE_TipoVeiculo.xsl |
| OMSA060 (Veículos) para GFEA046 (Veículos) | ProtheustoGFE_Veiculo.xsl |
| OMSA040 (Motoristas) para GFEA012 (Motoristas) | ProtheustoGFE_Motorista.xsl |
| OMSA200 (Cargas) para GFEA050 (Romaneios) | ProtheustoGFE_Carga_Romaneio.xsl |
| MATA460 (NF Saída) para GFEA044 (Doc Carga) | ProtheustoGFE_NfSaida_DoctoCarga.xsl ProtheustoGFE_CancelNfSaida_DoctoCarga.xsl |
| MATA103 (Doc Entrada) para GFEA044 (Doc Carga) | ProtheustoGFE_NfEntrada_DoctoCarga.xsl |
| GFEA055 (Pré-fatura) para FINA050 (Título a Pagar) | GFEtoProtheus_Financeiro-PreFat.xsl ProtheusToGfe_Ret_Fatura.xsl |
| GFEA065 (Doc Frete) para MATA103 (Doc Entrada) | GFEtoProtheus_DoctoEntrada.xsl ProtheusToGFE_Ret_DoctoEntrada.xsl (retorno) |
| GFEA065 (Doc Frete) para MATA116 (Nota Conhecimento) | GFEtoProtheus_NFRateio-CTRC.xsl ProtheusToGFE_Ret_DoctoFrete.xsl (retorno) |
| GFEA070 (Fatura) para FINA050 (Título a Pagar) | GFEtoProtheus_Financeiro-Fatura.xsl ProtheusToGfe_Ret_Fatura.xsl |
| GFEA100 (Contrato) para FINA050 (Título a Pagar) | GFEtoProtheus_Financeiro-Contrato.xsl ProtheusToGfe_Ret_Fatura.xsl |
| GFEA100 (Contrato) para MATA116 (Nota Conhecimento) | GFEtoProtheus_NFRateio-Contrato.xsl |
Nas integrações realizadas no sentido GFE para o ERP há duas operações “Atualizar” e “Desatualizar”, correspondendo à Inclusão e Eliminação. Para cada integração há um campo de controle na tabela de origem com a seguinte lista de opções: “1=Nao Enviado;2=Pendente;3=Rejeitado;4=Atualizado;5=Pendente Desatualizacao;6=Nao se Aplica”. Nas rotinas em que há a alteração da situação de “1=Não Enviado” para “2=Pendente”, o sistema deve executar a integração via MSExecAuto, com a operação Inclusão, quando o parâmetro MV_INTGFE2 = “1=Sim”; nas rotinas em que há a alteração da situação de “4=Atualizado” para “5=Pendente Desatualizacao”, o sistema deve executar a integração via MSExecAuto, com a operação Eliminação, quando o parâmetro MV_INTGFE2 = “1=Sim”. Abaixo a lista de programas com os quais é possível acionar as integrações:
| Integração | Rotina | Opção | Operação |
| Pré-fatura –> Financeiro | GFEA055 | Ação relacionada “Atualizar Financeiro ERP” | Atualizar |
| GFEA055 | Ação relacionada “Desatualiz Financeiro ERP” | Desatualizar | |
| GFEA055 | Ação relacionada “Gerar” quando o Transportador está configurado para confirmar pré-faturas automaticamente (GU3_CAUTPF = “1”) e o modo de integração for automático (MV_GFEI15 = “2”) | Atualizar | |
| GFEA057 | Ação relacionada “Confirmar” quando o modo de integração for automático (MV_GFEI15 = “2”) | Atualizar | |
| GFEA099 | Execução com o parâmetro “Ação” na opção “Atualizar” ou “Atu Rejeitado” | Atualizar | |
| GFEA099 | Execução com o parâmetro “Ação” na opção “Desatualizar” | Desatualizar | |
| GFEX100 | Ação relacionada “Enviar Financeiro” | Atualizar | |
| Doc Frete –> Fiscal | GFEA065 | Ação relacionada “Atualizar Fiscal ERP” | Atualizar |
| GFEA065 | Ação relacionada “Atualizar Pré nota” | Atualizar | |
| GFEA065 | Ação relacionada “Desatualiz Fiscal ERP” | Desatualizar | |
| GFEA065 | Confirmação da ação “Incluir” quando o resultado da conferência for “Aprovado Sistema” (GW3_SIT = 3“) e o modo de integração for automático (MV_GFEI13 = “2”) | Atualizar | |
| GFEA066 | Confirmação da ação “Aprovar” quando o modo de integração for automático (MV_GFEI13 = “2”) | Atualizar | |
| GFEA067 | Execução com os parâmetros “Tipo de Integração” na opção “Fiscal” e “Ação” na opção “Atualizar” ou “Atu Rejeitado” | Atualizar | |
| GFEA067 | Execução com os parâmetros “Tipo de Integração” na opção “Fiscal” e “Ação” na opção “Desatualizar” | Desatualizar | |
| GFEA070 | Ação relacionada “Atualizar Doc Frete Fiscal ERP” | Atualizar | |
| GFEA115 | Ação “Processar” após importação do Documento de Frete do arquivo CONEMB quando o resultado da conferência for “Aprovado Sistema” (GW3_SIT = 3“) e o modo de integração for automático (MV_GFEI13 = “2”) | Atualizar | |
| GFEA118 | Ação “Processar” após importação do Documento de Frete do arquivo CT-e quando o resultado da conferência for “Aprovado Sistema” (GW3_SIT = 3“) e o modo de integração for automático (MV_GFEI13 = “2”) | Atualizar | |
| GFEX100 | Ação relacionada “Enviar Fiscal” | Atualizar | |
| Fatura –> Financeiro | GFEA065 | Confirmação da ação “Incluir” quando o resultado da conferência for “Aprovado Sistema” (GW3_SIT = 3“), o Transportador estiver configurado para gerar Fatura Automaticamente (GU3_FATAUT = “1”), o resultado da conferência “Aprovada Sistema” (GW6_SITAPR = 3“) e o modo de integração for automático (MV_GFEI16 = “2”) | Atualizar |
| GFEA070 | Ação relacionada “Atualizar Fiscal ERP” | Atualizar | |
| GFEA070 | Ação relacionada “Desatualiz Fiscal ERP” | Desatualizar | |
| GFEA070 | Ação relacionada “Conferir” com o resultado da conferência “Aprovada Sistema” (GW6_SIT = 3“) e o modo de integração for automático (MV_GFEI16 = “2”) | Atualizar | |
| GFEA071 | Confirmação da ação “Aprovar” quando o modo de integração for automático (MV_GFEI16 = “2”) | Atualizar | |
| GFEA097 | Execução com o parâmetro “Ação” na opção “Atualizar” ou “Atu Rejeitado” | Atualizar | |
| GFEA097 | Execução com o parâmetro “Ação” na opção “Desatualizar” | Desatualizar | |
| GFEA115 | Ação “Processar” após importação do Documento de Frete do arquivo CONEMB, quando o resultado da conferência for “Aprovado Sistema” (GW3_SIT = 3“), o Transportador estiver configurado para gerar Fatura Automaticamente (GU3_FATAUT = “1”), o resultado da conferência “Aprovada Sistema” (GW6_SITAPR = 3“) e o modo de integração for automático (MV_GFEI16 = “2”) | Atualizar | |
| GFEA116 | Ação “Processar” após importação da Fatura de Frete do arquivo DOCCOB, quando o resultado da conferência for “Aprovada Sistema” (GW6_SITAPR = 3“) e o modo de integração for automático (MV_GFEI16 = “2”) | Atualizar | |
| GFEA118 | |||
| GFEX100 | Ação relacionada “Enviar Financeiro” | Atualizar | |
| Doc Frete –> Recebimento/Compras | GFEA065 | Ação relacionada “Atualizar Aprop Desp ERP” | Atualizar |
| GFEA065 | Ação relacionada “Atualizar Pré CT” | Atualizar | |
| GFEA065 | Ação relacionada “Desatualiz Aprop Desp ERP” | Desatualizar | |
| GFEA065 | Confirmação da ação “Incluir” quando o resultado da conferência for “Aprovado Sistema” (GW3_SIT = 3“) e o modo de integração for automático (MV_GFEI14 = “2”) | Atualizar | |
| GFEA066 | Confirmação da ação “Aprovar” quando o modo de integração for automático (MV_GFEI14 = “2”) | Atualizar | |
| GFEA067 | Execução com os parâmetros “Tipo de Integração” na opção “Aprop Despesas” e “Ação” na opção “Atualizar” ou “Atu. Rejeitados” | Atualizar | |
| GFEA067 | Execução com os parâmetros “Tipo de Integração” na opção “Aprop Despesas” e “Ação” na opção “Desatualizar” | Desatualizar | |
| GFEA115 | Ação “Processar” após importação do Documento de Frete do arquivo CONEMB quando o resultado da conferência for “Aprovado Sistema” (GW3_SIT = 3“) e o modo de integração for automático (MV_GFEI14 = “2”) | Atualizar | |
| GFEA118 | Ação “Processar” após importação do Documento de Frete do arquivo CT-e quando o resultado da conferência for “Aprovado Sistema” (GW3_SIT = 3“) e o modo de integração for automático (MV_GFEI14 = “2”) | Atualizar | |
| GFEX100 | Ação relacionada “Enviar Materiais” | Atualizar | |
| Contrato -> Financeiro | GFEA098 | Execução com os parâmetros “Tipo de Integração” na opção “Financeiro” e “Ação” na opção “Atualizar” ou “Atu Rejeitado” | Atualizar |
| GFEA098 | Execução com os parâmetros “Tipo de Integração” na opção “Financeiro” e “Ação” na opção “Desatualizar” | Desatualizar | |
| GFEA100 | Ação relacionada “Enviar ERP Financeiro” | Atualizar | |
| GFEA102 | Confirmação da ação “Imprimir” quando o modo de integração for automático (MV_GFEI17 = “2”) | Atualizar | |
| GFEX100 | Ação relacionada “Enviar Financeiro” | Atualizar | |
| Contrato -> Recebimento/Compras | GFEA098 | Execução com os parâmetros “Tipo de Integração” na opção “Aprop Despesas” e “Ação” na opção “Atualizar” ou “Atu Rejeitado” | Atualizar |
| GFEA098 | Execução com os parâmetros “Tipo de Integração” na opção “Aprop Despesas” e “Ação” na opção “Desatualizar” | Desatualizar | |
| GFEA100 | Ação relacionada “Apropriação Despesa” | Atualizar | |
| GFEA102 | Confirmação da ação “Imprimir” quando o modo de integração for automático (MV_GFEI17 = “2”) | Atualizar | |
| GFEX100 | Ação relacionada “Enviar Materiais” | Atualizar |
6. Cadastro de Municípios (FISA010 – tabela CC2)
| Campo | Recebe | Observações |
|---|---|---|
| GU7_NRCID* | Código IBGE do CC2_EST + CC2_CODMUN | Utilizar a tabela de códigos IBGE x UF (abaixo) |
| GU7_NMCID | CC2_MUN | |
| GU7_UF | CC2_EST | |
| GU7_PAIS | 105 |
7. Tabela para obtenção do Código IBGE das Unidades de Federação (função TMS120CdUf)
| UF | AC | AL | AM | AP | BA | CE | DF | ES | GO | MA | MG | MT | MS | PA |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| IBGE | 12 | 27 | 13 | 16 | 29 | 23 | 53 | 32 | 52 | 21 | 31 | 50 | 51 | 15 |
| UF | PB | PE | PI | PR | RJ | RN | RO | RR | RS | SC | SE | SP | TO | EX |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| IBGE | 25 | 26 | 22 | 41 | 33 | 24 | 11 | 14 | 43 | 42 | 28 | 35 | 17 | 99 |
Escopo
Descreva, dado o contexto, qual o escopo de atuação da integração. Cite as áreas/perfis de usuários e funções impactadas. Se existe uma parte do contexto de negócio que a integração não tenta resolver, deixe explícito.
Defina exatamente o que a integração FAZ, o que ela NÃO FAZ e a sua finalidade.
[O conteúdo poderá estar disponível na ferramenta PMS – Painel de Gestão de Projetos, opção Plano do Projeto]
Como são os processos os que serão integrados, mas com uma visão geral e não só o ponto de integração caso contrário a homologação [ou outro que pegar o documento] não saberá do que se trata no sistema vertical, de forma sucinta, como funciona e o(s) ponto(s) de integração.
Citar a responsabilidade de cada produto.
Descrever com mais detalhes sobre o que será integrado (mas não ser especialista nas entidades/processos, pois suas particularidades serão descritas posteriormente) incluindo diagramas, prints, imagens, etc o que for interessante para auxiliar o entendimento.
Interessante aqui a inclusão de diagramas, imagens, lógicas, fluxo(s) do(s) processo(s) o que considerar interessante e agregador ao documento e ao escopo.
Pré-requisitos instalação/implantação/utilização
Relacione quais são os pré-requisitos (técnicos ou de negócio) para a integração. Este tópico não deve incluir informações da implantação normal do módulo, mas apenas informações específicas da integração. É como se este tópico já partisse do princípio que o módulo que será integrado já está normalmente instalado.
Entre os tópicos deste tópico podemos citar:
- Versões mínimas de produtos.
- Módulos ou programas que geram informações necessárias a integração. Muitas vezes a integração partirá de informações que somente são trabalhadas em um determinado programa ou processo, que deverá estar em uso no cliente.
- Ferramentas que são necessárias a integração, como: EAI, ESB, servidor de WebService etc.
- Aspectos legais nos quais as partes envolvidas na integração devem estar inseridas, caso as informações envolvidas sejam utilizadas para o cumprimento de alguma lei específica.
- Requisitos de hardware ou Software, como servidores, link de internet, capacidade de armazenamento e memória, sistema operacional.
Datasul
Insira aqui as informações pertinentes a Datasul.
Logix
Insira aqui as informações pertinentes ao Logix.
Protheus
Insira aqui as informações pertinentes ao Protheus.
RM
Insira aqui as informações pertinentes ao RM.
Instalação/Atualização
Este tópico tem por objetivo orientar a instalação da integração, visando o seu funcionamento completo. Instalação de produtos ou ferramentas necessárias podem referenciar outros documentos existentes, desde que estejam disponíveis no repositório de documentação da TOTVS ou sejam enviados junto com o documento da integração em si. As informações mínimas necessárias para teste tópico são:
- Procedimentos que devem ser observados quando um dos produtos for atualizado.
- Configuração necessária que deve ser realizada em arquivos de configuração ou programas de parâmetros etc.
- Arquivos diversos que devem ser mantidos em determinados locais para o funcionamento da integração, exemplo: xml, xsd.
- Atualizações necessárias em banco de dados ou instruções para que elas sejam feitas.
- Processos, módulos ou programas que precisam ser instalados ou atualizados. Deve ser definida a versão mínima necessária dos programas envolvidos.
- Ferramentas, servidores ou serviços que precisam ser disponibilizados e configurados, o que pode gerar necessidade de novo hardware ou aumento de capacidade. Exemplo: serviço de WebService.
- Instruções para habilitar a comunicação da ferramenta EAI entre as partes, quais rotas devem ser definidas ou como as transações devem ser habilitadas.
Observação: evite o uso de Prints de telas, facilitando, assim, o trabalho de tradução e versionamento deste documento.
Datasul
Insira aqui as informações pertinentes a Datasul.
Logix
Insira aqui as informações pertinentes ao Logix.
Protheus
Insira aqui as informações pertinentes ao Protheus.
RM
Insira aqui as informações pertinentes ao RM.
Controle de Versão
O grupo TOTVS, representado por suas marcas, irá administrar as demandas de evolução dos layouts e demais ajustes, acordando junto aos solicitantes o prazo de liberação de release.
Todas as evoluções programadas deverão ser discutidas e aprovadas pelas marcas antes do início do desenvolvimento e somente serão desenvolvidas em caso de concordância das marcas e alinhamento com as diretivas definidas pelo Comitê de Integração TOTVS.
Suporte
O suporte aos recursos da Integração será de responsabilidade de todas as linhas, sendo assim as equipes de suporte dos produtos RM Conector e Backoffice Protheus estarão aptas a fazer a primeira análise e, quando necessário, repassar para a equipe mais adequada em cada caso.
Observação: Este modelo de suporte está sendo revisado pela TOTVS.
Transações/Entidades/Mensagens únicas
Apresente quais as transações/entidades que são trocadas e quem envia a informação para quem. Pode (e recomenda-se) ter um diagrama, uma tabela ou afins que apresente este fluxo.
Relacione quais são as mensagem únicas (TOTVSMessage) utilizadas e qual o seu relacionamento com as entidades já existentes do ERPs envolvidos.
Exemplos:
Método | ID | Descrição | Origem | Destino | XSD (versões podem variar) |
Cadastros | 01 | Cliente/Fornecedor | RM | Protheus | CustomerVendor_1_000.xsd |
02 | Moeda | RM | Protheus | Currency_1_000.xsd | |
03 | Unidade de Medida | RM | Protheus | UnitOfMeasure_1_000.xsd | |
04 | Produto | RM | Protheus | Item_?_000.xsd | |
05 | Centro de Custo | RM | Protheus | CostCenter_1_000.xsd | |
06 | Ativos | RM | Protheus | NOVA, Ativo fixo | |
07 | Funcionários | RM | Protheus | Employee_1_000.xsd | |
08 | Projeto | RM | Protheus | Project_1_000.xsd | |
09 | Obra | RM | Protheus | SubProject_1_000.xsd | |
10 | Tarefa | RM | Protheus | TaskProject_1_000.xsd | |
11 | Meio de Pagamento | RM | Protheus | ?????.xsd | |
12 | Condições de pagamento | RM | Protheus | PaymentCondition_1_000.xsd | |
13 | Coligada* | RM | Protheus | Company_1_000.xsd | |
14 | Filial* | RM | Protheus | Branch_2_000.xsd | |
Processos | 15 | Solicitações (compras/armazém) | Protheus | RM | Request_1_000.xsd |
16 | Cancelar movimento (solicitação, OS, etc) | Protheus | RM | CancelRequest_1_000.xsd | |
17 | Cancelar movimento (solicitação, OS, etc) | RM | Protheus | CancelRequest_1_000.xsd | |
18 | Baixa de estoque | Protheus | RM | Request_1_000.xsd | |
19 | Baixa de estoque | RM | Protheus | Request_1_000.xsd | |
20 | Consulta Saldo | Protheus | RM |
| |
21 | Apropriação de custos |
|
| Request _1_000.xsd | |
22 | Geração de OS |
|
|
| |
23 | Consulta de OS |
|
|
| |
24 | Ampliação patrimonial |
|
|
|
Fluxo das Informações
Para cada fluxo de informação descreva, se necessário, alterações de comportamento que o respectivo produto irá sofrer. Por exemplo: quando o Logix recebe o PEDIDO de OUTRO ERP, este pedido não poderá ser alterado no Logix.
Liste quais as entidades integradas e como é o mapeamento entre as diferentes estruturas. Por exemplo: Classe no sistema A vira categoria no sistema B, o campo X é refletido no campo Y etc.
Liste quais transações/operações a integração fará com as entidades relacionadas. Exemplo: Insert de PEDIDO, Insert, update de ITEM, buscar saldo em estoque do ITEM no dia X ou buscar dados do FUNCIONÁRIO.
Cadastros
Descreva características gerais do fluxo de informações e que serão comuns para este tipo de entidade. Características particulares para cada entidade deverão ser citadas em tópicos específicos de cada entidade.
Sempre que existir (a sugestão é sempre criar) e for agregador ao documento acrescentar aqui os diagramas/imagens ou até mesmo colocar tais diagramas diretamente na especificação dos processos
Em seguida faça uma descrição para cada um dos fluxos para cada entidade
<Transação/Entidade>
Identificador da Mensagem: <mensagem>
Versão: <versão>
Módulo <marca 1>: <BackOffice – Gestão xxxxxxx>
Módulo <marca 2>: <SIGAXXX>
Tipo de Envio: <Assíncrona/Síncrona>
Mensagem Padrão | PROTHEUS | RM | ||
Tabela | Campo | Tabela | Campo | |
Code | CTO990 | CTO_SIMB | GMOEDA | SIMBOLO * |
Description | CTO990 | CTO_DESC | GMOEDA | DESCRICAO |
Symbol | CTO990 | CTO_SIMB | GMOEDA | SIMBOLO |
Notas:
Observações sobre comportamento desta mensagem ou dos processos envolvidos nela/para ela
A seguir descrever as variações, particularidades da mensagem e processos (integração) de acordo com cada marca
Limitações/Restrições
Descreva limitações e restrições para a integração que está sendo descrita.
Processos
Descreva características gerais do fluxo de informações e que serão comuns para este tipo de entidade. Características particulares para cada entidade deverão ser citadas em tópicos específicos de cada entidade.
Sempre que existir (a sugestão é sempre criar) e for agregador ao documento acrescentar aqui os diagramas/imagens ou até mesmo colocar tais diagramas diretamente na especificação dos processos
Em seguida faça uma descrição para cada um dos fluxos para cada entidade
<Transação/Processo>
Tipo de Fluxo: Protheus -> RM
Mensagem: Request_1_000
Versão: 1.000
Descrição de todo o comportamento e funcionamento do processo. Breve contexto, origem, regras, integração (geração da mensagem, envio, recebimento no destino), o quê supostamente irá ocorrer no destino, retorno, impacto, consequências, o que foi afetado, como conferir, validar, etc o retorno.
Acrescentar um diagrama do processo.
A seguir descrever as variações, particularidades da mensagem e processos (desta integração) de acordo com cada marca
Notas:
Observações sobre comportamento desta mensagem ou dos processos envolvidos nela/para ela
Limitações/Restrições
Descreva limitações e restrições para a integração que está sendo descrita.
Limitações / Restrições Gerais
Descreva limitações e restrições para cada fluxo descrito no tópico anterior. Exemplo:
- ERP1 envia ITEM cadastrado para o ERP2
ERP1 somente enviará o ITEM se este estiver em uma das famílias cadastradas no parâmetro FAMILIA_INTEGRACAO.
Se o tipo de valorização do estoque for FIFO.
- ERP2 envia PEDIDO cadastrado para o ERP1
O pedido recebido no ERP1 vindo do ERP2 estará bloqueado para alteração.
Como fazer (opcional)
Descreva os passos que viabilizem a integração.
Exemplo:
Os passos para viabilizar a integração são:
- No Logix ou no Protheus efetue o cadastro das seguintes informações: Clientes, fornecedores, transportadores, cidades, cotação de moeda e unidades de medida.
- No Logix cadastrar um novo depositante e efetuar toda a parametrização necessária para a operação de WMS.
- No Logix cadastrar um novo produto que seja controlado pelo WMS, para o depositante cadastrado anteriormente.
- No Logix efetuar um processo de recebimento para o produto cadastrado anteriormente, utilizando uma nota fiscal provisória (tipo “A”).
- No Protheus consultar a nota fiscal de recebimento que foi registrada no Logix, validando as informações recebidas.
- No Logix efetuar um processamento de regularização fiscal, efetuando a cobertura dos produtos recebidos anteriormente.
- No Protheus verificar se foi efetuado corretamente o relacionamento entre os dois documentos.
- No Logix efetuar um processo de expedição para o novo produto cadastrado, até o momento do envio da mensagem de integração de pedido de venda.
- No Protheus efetuar o faturamento do pedido de venda recebido.
- No Protheus verificar se a nota fiscal gerada contém todas as informações necessárias para o segmento de operador logístico (armazém geral).
- No Protheus efetuar a escrituração fiscal das notas fiscais, verificando se as regras da legislação deste segmento foram respeitadas.
- No Logix é possível consultar o número do pedido de venda gerado para as notas fiscais de retorno simbólico e conta/ordem no programa WMS6333 (Consulta de Documentos). Para os processos de faturamento de serviço o número do pedido está disponível no programa WMS6411 (Movimentos a Faturar).
Situações comuns (opcional)
Descreva situações problemáticas comuns que podem ocorrer durante o funcionamento da integração e como solucioná-los. Neste ponto também é importante dar instruções de como reconhecer e investigar problemas que podem vir a ocorrer durante a integração. Se houver, apresente tabelas de códigos e descrições de erros que a integração poderá apresentar.
Este tópico possivelmente será alimentado com as experiências durante o desenvolvimento da integração e poderá ser realimentado durante o uso da integração no cliente.
Exemplo 1:
Tratamento de erros de integração (Produto A)
Erro | Mensagem | Solução |
Código do erro | Mensagem exibida | Ação a ser tomada para resolução do erro. |
Tratamento de erros de integração (Produto B)
Erro | Mensagem | Solução |
Código do erro | Mensagem exibida | Ação a ser tomada para resolução do erro. |
Exemplo 2:
Quando uma mensagem é enviada do Logix para o Protheus, podem ocorrer situações em que o WebService não estará totalmente funcional. Nestes casos uma mensagem de erro genérica irá aparecer na tela:
Exemplo:
Erro ao enviar a mensagem de Cidade via Integração
Se o arquivo de log for analisado, poderemos ver a falha na comunicação com o sistema destino:
-------------------------------------------------------------------------------
WSCERR044 / Não foi possível POST : URL http://172.16.31.57:8011/ws/FWWSEAI.apw
ADVPL WSDL Client 1.080707 / tst on 20120315 08:49:51
-------------------------------------------------------------------------------
Para resolver este problema, verifique as configurações do sistema de destino, analisando o funcionamento do servidor utilizado para esta comunicação e a habilitação do endereço do WebService.
Checklist de suporte da aplicação
Crie um check-list de verificação de alguns pontos importantes para o funcionamento e atendimento da integração.
Instalação/Configuração
Relacione itens de verificação para garantir que a integração está corretamente instalada e configurada. Isto não pode ser uma cópia do procedimento de instalação/configuração, mas verificações pontuais que podem remeter aos itens da instalação.
Checklist de Verificações:
Relacione itens de verificações para que o atendente possa:
- Identificar o funcionamento da integração;
- Identificar a ocorrências de problemas;
- Coletar evidências do mau funcionamento relatado pelo cliente;
- Realizar possíveis ajustes na integração quanto à configuração ou negócio.