Histórico da Página
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
Informações Gerais
Especificação | |||
Produto | TOTVS Gestão de Estoque, Compras e Faturamento | Módulo | Faturamento |
Segmento Executor | TOTVS Construção e Projetos | ||
Projeto1 | Integração BackOffice RM x PDV Protheus | IRM1 | PCREQ-7769 |
Requisito1 | PCREQ-7809 | Subtarefa1 | PDR_CP_MOV008-54 |
Chamado2 |
| ||
Release de Entrega Planejada | 12.1.10 | Réplica | Não |
País | ( X ) Brasil ( ) Argentina ( ) Mexico ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) Colombia ( ) Outro _____________. | ||
Outros | <Caso necessário informe outras referências que sejam pertinentes a esta especificação. Exemplo: links de outros documentos ou subtarefas relacionadas>. |
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.
Rotina | Tipo de Operação | Opção de Menu | Regras de Negócio |
Meio Pagamento | Inclusão \ Alteração \ Exclusão | RM \ BackOffice \ Gestão de Estoque, Compras e Faturamento \ Cadastros \ | - |
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:
RM | Mensagem Única | ||
Descrição | Código | Descrição | Código |
---|---|---|---|
Dinheiro | 0 | Dinheiro | 1 |
(Tipo + Tipo transação) Cartão + Crédito | 2 + 1 | Crédito | 2 |
(Tipo + Tipo transação) Cartão + Débito | 2 + 2 | Débito | 3 |
Cheque | 1 | Cheque | 4 |
Demais tipos | - | Outros | 5 |
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:
Código | Descrição | |
---|---|---|
BOL | BOLETO BANCARIO | |
CC | CARTAO DE CREDITO | |
CD | CARTAO DE DEBITO AUTOMATICO | |
CH | CHEQUE | |
CO | CONVENIO | |
CR | CREDITO | |
DC | DEBITO EM CONTA CORRENTE | |
FI | FINANCIADO | |
FID | FIDELIDADE | |
R$ | DINHEIRO CX | |
VA | VALES | |
VP | VALE PRESENTE |
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
Mensagem Padrão | Descrição | RM | ||
Tabela | Campo | Observação | ||
CompanyId | Código da empresa. | TFORMAPAGTO | CODCOLIGADA | Código da Coligada é obtido a partir do De-Para de Filial. |
BranchId | Código da filial | TFORMAPAGTO | CODFILIAL | |
CompanyInternalId | InternalId da chave completa de empresa do produto | TFORMAPAGTO | CODCOLIGADA|CODFILIAL | |
Code | Código do Forma de Pagamento | TFORMAPAGTO | CODFORMAPAGTO |
|
InternalId | InternalId de Integração | TFORMAPAGTO | CODCOLIGADA|IDFORMAPAGTO |
|
Name | Nome da Forma de Pagamento | TFORMAPAGTO | DESCFORMAPAGTO | |
Active | Forma de Pagamento Ativa/Inativa | TFORMAPAGTO | INATIVO | |
Type | Tipo da Forma de Pagamento | TFORMAPAGTO | TIPOFORMAPAGTO e TIPOTRANSACAO | Vide logica apresentada nas regras de negócio |
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|