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. 

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 a Administradora Financeira o usuário deverá selecionar qual é a forma de pagamento do RM que ficará associada ao registro.

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