Histórico da Página

Informações Gerais

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

Objetivo

 Implementação do adapter de integração via Mensagem Única TOTVS do cadastro de Cliente com o PDV, viabilizando assim o CRUD completo do cadastro por envio de mensagem de integração.

Definição da Regra de Negócio

Considera-se como escopo deste requisito a implementação do adapter de envio de Mensagens Únicas TOTVS para integração do cadastro de Cliente (CustomerVendor), estando o adapter de recebimento desta mesma mensagem fora do escopo do requisito. 

A análise e o desenvolvimento do adapter será efetuado considerando a integração com o PDV Protheus (SigaLoja), mas também viabilizará a integração com outras fontes de dados desde que respeitado o layout da mensagem.

Tabelas Utilizadas

• FCFO – Cadastro de Clientes / Fornecedor.

Entidades de Integração

• DataServer envolvido
  • FinCFODataBR
• Transformação
  • Id: CustomerVendor
  • Versão: 2.002
• Extension: 6d654d7c-9aae-41b4-a710-219db8a20742

Restrições e Pontos de Atenção

• Se o EAI destino é capaz de cadastrar um único registro como ambos: deve verificar se já existe um registro com este ID, caso afirmativo fazer alteração deste registro para Cliente e alterar os demais campos, senão fazer inclusão.
• Se o EAI destino NÃO é capaz de cadastrar um único registro como ambos: primeiro deve verificar se já existe um Fornecedor com este ID, caso afirmativo deve tentar excluir este Fornecedor (não conseguindo gerar uma exceção semelhante a “o código xx já é um fornecedor não pode ser excluído/alterado para tipo cliente.”). Segundo, deve verificar se já existe um registro de Cliente com este ID, caso afirmativo fazer alteração dos demais campos, senão fazer inclusão.

• Se o EAI destino é capaz de cadastrar um único registro como ambos, deve verificar se o ID já existe para definir se faz alteração ou inclusão.
• Se o EAI destino tem 2 tabelas distintas, deve incluir/alterar um Cliente. E ainda incluir/alterar um fornecedor.

Opcional

Fluxo do Processo

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

Os campos considerados obrigatórios no envio para o correto recebimento no PDV são:

• Código do Cliente
• Loja - Campo mapeado para a Coligada do Cli/For
• Nome
• Nome Fantasia
• Endereço
• Entidade: pessoa física ou pessoa jurídica
• Município.
• Estado.
• País.

O gatilho de integração será executado sempre que a Classificação do registro for Cliente ou Ambos. Por padrão estes registros sempre serão integrados ao realizar qualquer ação no registro de Cliente/Fornecedor, caso a integração BackOffice RM x PDV Protheus esteja ativa.

Como o endereço é uma informação obrigatória para inclusão/alteração de Cliente do lado PDV, sugerimos que no diálogo do Cliente/Fornecedor do RM seja marcada a opção Preenchimento Obrigatório para os campos de Endereço Principal.

Cliente Padrão

No PDV existem parâmetros para definir qual será o Consumidor Final quando não for informado os dados do Cliente na Compra. Com isso, será necessário cadastrar este Cliente no RM e alterar os parâmetros MV_CLIPAD e MV_LOJAPAD no configurador PROTHEUS (SIGACFG) informando o código do cliente.

Fórmula Visual

Está sendo disponibilizado uma fórmula visual para que possa realizar customizações na integração da entidade Cliente/Fornecedor. Caso deseje utilizar este recurso será necessário importar a fórmula visual que encontra-se disponível na pasta “Fórmulas Visuais”, interna à pasta “ObjetosGerenciais” no ambiente instalado do sistema (“../CorporeRM/ObjetosGerenciais/Fórmulas Visuais”). Ao importar a fórmula visual deverá ser marcado para cada fórmula o parâmetro “Importar Gatilho” na rotina de Importação de Fórmula Visual.

Como para o PDV devem ser enviados os registro Cliente ou Ambos do cadastro de Cliente/Fornecedor, nesta fórmula visual foi criado um contra-gatilho no gatilho "Pode executar o contexto?" para os assinantes de Inclusão, Alteração e Exclusão de Cliente/Fornecedor via mensagem única (FinCFOTotvsMessageSbc). 

Observação: 

• Quando a integração Manutenção de Ativos (SigaMNT) x BackOffice RM estiver sendo utilizada juntamente com a integração BackOffice RM x PDV Protheus deve ser removido da fórmula visual utilizada para o PDV o contra-gatilho, uma vez que para a integração do Manutenção de Ativos deve-se enviar Cliente, Fornecedor e Ambos. Para isso você pode proceder com uma das seguintes maneiras abaixo:
  • Alterar o retorno do método "CustomCanExecute_ExecuteCode" para ser sempre "true" na fórmula visual de "01_PDV_Cliente.TotvsWF".
  • Editar a fórmula visual para considerar também os registros que possuem a classificação de Cliente/Fornecedor igual a Fornecedor
  • Desativar o gatilho da fórmula visual "01_PDV_Cliente.TotvsWF".

Carga Inicial

Visando facilitar a sincronização das bases de dados RM e PDV foi desenvolvida uma atividade de fórmula visual que se responsabiliza por, a partir de alguns parâmetros, obter os dados necessários e solicitar o envio da Mensagem Única TOTVS CustomerVendor_2.002.

Basicamente é necessário informar a esta atividade somente a lista de chaves dos registros que se deseja integrar, qual a Mensagem Única a enviar e qual o objeto de negócio (DataServer) responsável por retornar as informações do registro. A partir destas informações a atividade se responsabiliza pela leitura, transformação e envio dos dados ao sistema de destino, oferecendo como retorno o Log de integração.

Por padrão a consulta seleciona para envio registros do tipo Cliente ou Ambos que ainda não foram enviados para o Protheus ou que estejam desatualizados no mesmo (data de último envio anterior a data da última modificação do registro).

Todas as mensagens trafegadas também constarão no monitor da fila de integração, para posterior conferência.

Implantação do Adapter na Integração com PDV

Ao executar o configurador da integração será verificado se a base de dados do cliente utiliza a integração de Cliente/Fornecedor na versão 1.000 da mensagem CustomerVendor e caso positivo será apresentada mensagem de erro informando que não será feita a atualização para o uso da versão 2.002 pois existe uma incompatibilidade entre estas e este fato deve ser verificado juntamente com o Suporte.

A verificação será efetuada através da Fila de Mensagens do cliente, considerando que o mesmo possui a versão 1.000 sem conversão prévia caso as três condições abaixo sejam satisfeitas:

1. Existem registros na Fila de Mensagens para a versão 1.XXX da mensagem CustomerVendor.
2. Não existem registros na Fila de Mensagens para a versão 2.XXX da mensagem CustomerVendor.
3. Não existe Adapter em versão 2.XXX para nenhuma integração.

Utilização do campo StoreId (Loja)

Visando evitar erros de chave duplicada caso o usuário cadastre Cliente/Fornecedor global com mesmo código de um outro registro por coligada, o código da Coligada do registro (zero em caso de registro global) será enviado ao Protheus a partir do campo StoreId (Loja) ao invés de enviar o valor '01' fixo.

Listagem de Fórmula Visual:

Cliente

Inclusão / Alteração / Exclusão

01_PDV_Cliente.TotvsWF

Cliente

Carga inicial

Tabelas Utilizadas

• FCFO – Cadastro de Clientes / Fornecedor.
  
• HCINTEGRACAOID – Tabela de-para dos identificadores de cada integração.
• HCFILAMENSAGEM – Armazena dados da fila de mensageria única.

Entidades de Integração

• DataServer envolvido
  • FinCFODataBR
• Transformação
  • Id: CustomerVendor
  • Versão: 2.002
• Extension: 4d87df6a-0c52-43d1-bff2-f0cf4c498875

Restrições e Pontos de Atenção

• Mesmo que a empresa não utilize Cliente/Fornecedor global no RM, deve-se compartilhar a tabela referente no Protheus por empresa.
• No Protheus o código do cliente/fornecedor será composto pelo código do cliente/fornecedor e da coligada, conforme a mascara “[CODCOLIGADA]|[CODCFO]”.
• Como o código do País no Protheus é baseado na tabela de classificação do IBGE, deve-se cadastrar esta tabela no RM e definir nos parâmetros de integração qual será o código desta tabela.
  • No cadastro de Classificação de País incluir uma tabela de classificação.
  • No cadastro de País abrir o anexo Codificação de País e incluir a tabela de classificação informando o Código País.
  • Nos Parâmetros de Integração informar no parâmetro "CODCLASSIFICPAIS" o código da tabela de classificação utilizada e associado ao país.
• A informação de Condição de Pagamento padrão não é trafegada no adapter de envio.
  • Caso esta informação passe a ser considerada é importante que seu envio seja efetuado somente se o cadastro de condição de pagamento também for integrado (mensagem PaymentCondition), caso contrário haverá erro de "De-Para não encontrado".
  • Para a integração com PDV Protheus este campo deve ser desconsiderado pois o mesmo não possui uso no mesmo e assim sendo o cadastro de Condição de Pagamento não é sincronizado entre os sistemas.
• Uma vez que já foi feito consenso que Cliente e Fornecedor são tratados na mesma mensagem (CustomerVendor), é responsabilidade do destinatário processar a mensagem da melhor forma possível para garantir a consistência dos dados na origem e no destino. Se o destino implementa uma única tabela, terá que manipular apenas um registro. Se implementa mais de uma tabela, tem que manipular até 2 registros.
  
  Exemplo1: <TOTVSMessage ... CustomerVendor...>…<Event>upsert</Event>…<Type>Customer<Type>…
  
  Como não dá para saber se este Cliente (<Type>Customer) é uma inclusão ou uma alteração (<Event>upsert), tem que verificar no de/para.
  • Se o EAI destino é capaz de cadastrar um único registro como ambos: deve verificar se já existe um registro com este ID, caso afirmativo fazer alteração deste registro para Cliente e alterar os demais campos, senão fazer inclusão.
  • Se o EAI destino NÃO é capaz de cadastrar um único registro como ambos: primeiro deve verificar se já existe um Fornecedor com este ID, caso afirmativo deve tentar excluir este Fornecedor (não conseguindo gerar uma exceção semelhante a “o código xx já é um fornecedor não pode ser excluído/alterado para tipo cliente.”). Segundo, deve verificar se já existe um registro de Cliente com este ID, caso afirmativo fazer alteração dos demais campos, senão fazer inclusão.
  
  Exemplo 2: <TOTVSMessage ... CustomerVendor...>…<Event>upsert</Event>…<Type>Both<Type>…
  • Se o EAI destino é capaz de cadastrar um único registro como ambos, deve verificar se o ID já existe para definir se faz alteração ou inclusão.
  • Se o EAI destino tem 2 tabelas distintas, deve incluir/alterar um Cliente. E ainda incluir/alterar um fornecedor.

Fluxo do Processo

Image Added

Mapeamento dos Campos

• Mensagem CustomerVendor 2.002

Mapeamento dos Campos

• Mensagem CustomerVendor 2.002