Histórico da Página

(Obrigatório)

Informações Gerais

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

(Obrigatório)

Objetivo

<Nesta etapa informar o objetivo da especificação do requisito, ou seja, o que a funcionalidade deve fazer. Exemplo: Permitir que o usuário defina o percentual mínimo em espécie (dinheiro), a referência mínima para calculo dos débitos do aluno e o período de validade do parâmetro de negociação>.

(Obrigatório)

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

<Regra de negócio é o que define a forma de fazer o negócio, o processo definido e/ou as regras que devem ser contempladas. Devem ser descritas restrições, validações, condições e exceções do processo. Caso necessário, incluir neste capítulo também regras de integridade que devem ser observadas no momento do desenvolvimento>.

<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

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. 

Exemplo de Aplicação:

• Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
• Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades  como a referência mínima para calcular o débito total do aluno.
• Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
• O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.

Tabelas Utilizadas

• SE2 – Cadastro de Contas a Pagar
• FI9 – Controle de Emissão de DARF>.

Opcional

Protótipo de Tela

<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.

Protótipo 01

 Image Removed

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

Opcional

Dicionário de Dados

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

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.

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

 Image Added

Mapeamento dos campos

Mensagem: PaymentMethod 1.000

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Programas

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.