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

 Na tela do PDV são apresentados 4 botões de forma de pagamento que são: Dinheiro, Cartão de Crédito, Cartão de Débito e Cheque. Ao selecionar um destes botões o PDV utiliza valores fixos para estas formas de pagamento:

• • R$ - Dinheiro
  • CC - Cartão de Crédito
  • CD - Cartão de Débito
  • CH - Cheque. 

Sendo assim, deve ser parametrizado no Protheus qual será a forma de pagamento utilizada em cada um destes botões. Os parâmetros a serem criados são:

• • MV_DINHEIROMU: parâmetro de forma de pagamento para Dinheiro.
  • MV_CCMU: parâmetro de forma de pagamento para Cartão de Crédito.
  • MV_CDMU: parâmero de forma de pagamento para Cartão de Débito.
  • MV_CHMU: parâmetro de forma de pagamento para Cheque.

Desta forma, antes de enviar Cupom Fiscal ao BackOffice RM deve-se buscar no parâmetro correspondente qual é a forma de pagamento a ser considerada no BackOffice RM.  

Cenário 1

Cenário 2 - Administradora Financeira

Quando o Ponto de Venda trabalhar com a forma de pagamento Cartão de Crétido ou Cartão de Débito, ele deve cadastrar a Administradora Financeira no Protheus e vincular qual será a forma de pagamento utilizada. O objetivo deste cadastro é apenas para realizar a conciliação bancária, uma vez que o comissionamento será feito no BackOffice RM.

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