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

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

Integridade de registros entre RM e Protheus

Visto que a base Protheus possui carga com formas de pagamento padrão (obrigatoriamente constam na base de dados), deve-se efetuar o cadastro destas Formas de Pagamento 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 padrão no Protheus (até a presente data) e devem ser cadastradas no RM com o mesmo código de descrição são:

Obs.: Caso hajam outras formas de pagamento já cadastradas no Protheus as mesmas também deverão ser incluídas no BackOffice RM com mesmos códigos.

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

Cenários de integração com Ponto de Venda Protheus

Cenário 1 - Formas de pagamento Padrão

Algumas formas de pagamento são utilizadas atualmente no SigaLoja de forma rígida, ou seja, mantendo sempre o mesmo código para as modalidades de pagamento.

Com intuito de viabilizar o uso das formas de pagamento cadastradas previamente no BackOffice RM serão disponibilizados parâmetros para alterar estas formas de pagamento para a desejada. 

Assim sendo, o usuário terá a opção de trabalhar das seguintes formas:

1. Continuar utilizando o PDV com as Formas de Pagamento padrão, devendo assim garantir que todas estas formas de pagamento (listadas abaixo) constam com mesmo código no BackOffice RM.
   • R$ - Dinheiro
   • CC - Cartão de Crédito
   • CD - Cartão de Débito
   • CH - Cheque
2. 
   
3. Utilização de mapeamento de Formas de Pagamento integradas. Sendo assim, deve ser parametrizado no Protheus qual será a forma de pagamento utilizada para cada opção. Segue abaixo lista de parâmetros:
   • MV_LJMUDIN: parâmetro de forma de pagamento para Dinheiro.
   • MV_LJMUCH: parâmetro de forma de pagamento para Cheque.
   • MV_LJMUFI: parâmetro de forma de pagamento para Financiado.

Nesta opção antes de enviar Cupom Fiscal ao BackOffice RM o SigaLoja buscará no parâmetro correspondente qual é a forma de pagamento a ser enviada ao RM.  

Cenário 2 - Administradora Financeira 

Para utilizar o Ponto de Venda com pagamento em Cartão de Crétido ou Cartão de Débito, deve-se cadastrar a Administradora Financeira no Protheus e vincular qual será a forma de pagamento utilizada. Nenhuma das informações de Administradora Financeira será integrada com o BackOffice RM, sendo utilizado somente para identificação da forma de pagamento do Cupom Fiscal e demais controles de uso do Pinpad.

No cadastro de Administradora Financeira do Protheus será criado um campo que irá guardar o código da forma de pagamento do RM. Esta opção é necessária, pois quando as formas de pagamento são CC - Cartão de Crétido ou CD - Cartão de Débito, o processo de Vendas do Protheus utiliza de forma fixa os códigos CC e CD para recuperar a Administradora Financeira. Assim ao cadastrar formas de pagamentos do tipo Cartão de Crédito ou Cartão de Débito no RM, elas serão incluídas no Protheus na tabela de formas de pagamento (configurador) e o adapter Protheus irá realizar um pré-cadastro da Administradora Financeira gravando no campo "Form Pg Ext"  o código da forma de pagamento RM e no campo Descrição a descrição utilizada no RM.a Administradora Financeira o usuário deverá selecionar qual é a forma de pagamento do RM que ficará associada ao registro.

Image Added

Os dados de comissionamento e demais informações não precisam ser cadastradas no Protheus, visto que estes controles serão efetuados no BackOffice RM.

Restrições e Ponto de Atenção

• Formas de Pagamentos Padrão Protheus: visto que a base Protheus possui carga com formas de pagamento padrão (obrigatoriamente constam na base de dados) estes registros não poderão ser alterados e excluídos, sendo adotadas as seguintes ações abaixo:
  • Alteração: ao alterar uma forma de pagamento no RM, o Protheus realizará a alteração no cadastro. Caso a alteração seja em uma forma de pagamento padrão do Protheus, a alteração será aplicada no RM e será enviada uma mensagem de alteração para o Protheus, porém o registro não será atualizado por ser um registro padrão. A alteração será aplicada apenas no RM.
  • Inativação: 
    1. Ao inativar uma forma de pagamento no RM e a mesma não for uma forma de pagamento padrão do Protheus, serão excluídos o registro no cadastro do Protheus e na tabela De-Para.
    2. Caso seja uma forma de pagamento que pertence aos cadastros padrões do Protheus, será excluído apenas o registro da tabela De-Para.
  • Exclusão: após a exclusão da Forma de Pagamento no RM o registro será excluído no Protheus. Caso seja uma forma de pagamento padrão do Protheus a exclusão será realizada apenas no RM e no Protheus será realizada exclusão da tabela De-Para.

• 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

Mapeamento dos campos

Mensagem: PaymentMethod 1.000