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 Forma de Pagamento viabilizando assim o CRUD completo do cadastro por envio de mensagem de integração no padrão de Mensageria Única TOTVS.

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 Forma de Pagamento, estando o adapter de recebimento desta mesma mensagem fora do escopo do requisito, ou seja , o cadastro de Forma de Pagamento será realizado somente no BackOffice RM.

A análise e o desenvolvimento do adapter será efetuado considerando a integração do BackOffice RM com PDV Protheus, mas também viabilizará a integração com outros destinatários desde que respeitado o layout da mensagem e os campos especificado para envio. 

Tratamento de tipos de Forma de Pagamento

O cadastro de Forma de Pagamento possui tipos primitivos que efetuam a classificação do mesmo. O mapeamento de equivalência entre os tipos do cadastro de da Mensagem Única segue a logica abaixo:

Tabelas Utilizadas

• TFORMAPAGTO – Meio de Pagamento

Entidades de Integração

• DataServer de Gatilho
  • MovFormaPagtoData
• Transformação
  • Id: PAYMENTMETHOD
  • Versão: 1.000
• SourceCode (Evento)
  • GUID: ac6342d3-d879-4d02-9654-7bcbed6ae0eb
  • Nome: PaymentMethod_1_000

Regras de Integridade

Visto que a base Protheus possui carga de forma de pagamento padrões, que obrigatoriamente constam na base de dados, deve-se efetuar o cadastro destas unidades no RM respeitando o mesmo código do Protheus para viabilizar a integração de registros que utilizem estas como parâmetro. A lista de forma de pagamentos que existem no Protheus e devem ser cadastradas no RM com o mesmo código de descrição são:

Compartilhamento de registros por Coligada e Filial

Visto que o registo no BackOffice RM não considera a Filial como parte da Chave e existe a restrição na Mensagem Única TOTVS para envio do 'CompanyInternalId' completo (Coligada + Filial), é necessário que o sistema destinatário possua este cadastro exclusivo por Coligada e compartilhado por Filial.

Em resumo, o sistema de destino não deve considerar a informação de Filial enviada, pois caso no BackOffice RM este campo esteja nulo será enviada a Filial do contexto de integração, que e a primeira filial da empresa disponível na tabela De-Para.

Em relação ao Protheus deve seguir o seguinte compartilhamento:

• • Empresa:  Exclusivo
  • Unidade:   Deve ser equivalente à entidade relacionada no De-Para de integração (Empresa ou filial)
  • Filial:        Compartilhado

Ponto de Venda

Cenário 1

Cenário 2

Restrições e Ponto de Atenção

• Cadastro de Condição de Pagamento: visto que o PDV envia ao RM o parcelamento definido (meio de pagamento) não será necessário integrar a condição de pagamento e esta informação também não deverá ser enviada na mensagem de Cupom Fiscal.
  

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

Mapeamento dos campos

Mensagem: PaymentMethod 1.000