Páginas filhas
  • Manual Operacional da Customização – SGE x Protheus – Parte 2

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Manual Operacional da Customização – Integração RM x Protheus – Parte 2 

...

O objetivo dessa customização é realizar a integração entre SGE e Protheus.


Projeto: FS007780 (873247-874083) – Integração RM com Protheus – Parte 2 (SESI-SENAI)
Data: 26/10/2017

...

O documento a seguir tem por objetivo orientar o usuário sobre as implementações realizadas para sua empresa. Todas as funcionalidades descritas neste manual têm como base do que está descrito no documento "Especificação Anexo I – Detalhamento Funcional – FS007779 – Parte 2".



Este requisito detalha a disponibilização do anexo customizado "Dados financeiros – Integração Protheus". O processo não apresenta diferenças entre as Coligadas do SESI e SENAI.
Expandir
titleAnexo customizado de Dados Financeiros no cadastro do Processo Seletivo
5.1.1

Pré-

Requisitos / Parametrizações

requisitos


Executar o processo de Importação de Cadastros Básicos, disponível no menu Educacional | Customização para importação dos cadastros de Itens Contábeis, Classes de Valor e Centros de Custo.

5.1.2 Descrição do Processo


Detalhamento do processo


O Anexo "Dados financeiros – Integração Protheus" está disponível no menu Processo Seletivo | Cadastros | Processo Seletivo | Anexo Dados Financeiros – Integração Protheus. O processo não apresenta diferenças entre as Coligadas do SESI e SENAI.


Image Modified


Nesta tela

teremos

temos três campos que

farão

fazem referência às tabelas SITEMCONTABILPROTHEUS, SCLASSEVALORPROTHEUS e SSERVICO filtrados pela Coligada do contexto. As informações definidas aqui

serão

são gravadas na tabela customizada ZIPPSDADOSFINANCEIROS e

serão

são utilizadas no processo de Exportação de Lançamentos Financeiros (Pedido de Venda) para o Protheus.
Para cada Processo Seletivo

poderá

pode ser vinculado apenas um Item Contábil, uma Classe de Valor e um Serviço.


O Centro de Custo

deverá

deve ser informado no campo nativo do cadastro do Processo Seletivo.


Image Modified

5.2. Req. 02 – do ContratoEste requisito detalha a disponibilização de campos customizados no cadastro Educacional. O processo não apresenta diferenças entre as Coligadas do SESI e SENAI.
Expandir
titleCriação de Campos Customizados no Cadastro do Contrato
Criação de Campos Customizados no Cadastro
do Contrato
5.2.1

Pré-

Requisitos / Parametrizações

requisitos


Criação da tabela dinâmica BANDEIRACC, para cada Coligada. Os itens da tabela

deverão

devem ser inseridos com o código correspondente no Protheus. Exemplo:

BANRICOMPRAS 002- MASTERCARD 003- VISA 006- VERDECARD

O Script para criação dessa tabela com os itens acima está contido no arquivo TOTVS_Custom_Consolidate_All_Parte2.sql.
Para manipular os itens da tabela dinâmica, acesse o Módulo Serviços Globais, menu Administração |Tabela Dinâmica. Seleciona a tabela BANDEIRACC e adicione quantos itens forem necessários no Anexo Item de Tabela dinâmica.

5.2.2 Descrição do Processo


Detalhamento do processo


Os campos customizados

estarão

estão disponíveis

na interface nativa de Contrato

no TOTVS Educacional disponível em TOTVS Educacional | Financeiro/Contábil | Contratos.


Image Modified


Estas informações

serão

são relevantes para quando o Aluno ou Responsável optar pelo pagamento do Curso, objeto do Contrato Educacional, via cartão de crédito ao realizar a Matrícula pela Secretaria. Em ocasiões como esta é necessário que os dados sejam enviados para o Protheus durante a integração de Pedido de Venda.


Segue abaixo o detalhamento dos 3 campos:

  • Pagamento com Cartão de Crédito: Quando marcado, o NSU e a Bandeira deverão devem ser informados obrigatoriamente.
  • NSU: Número Sequencial Único que identifica a transação realizada com o cartão de crédito, limitado a 8 caracteres.
  • Bandeira: Campo do tipo lista que irá buscar busca os itens da uma tabela dinâmica (BANDEIRACC) onde o usuário irá cadastrar manualmente os registros de Bandeiras de Cartões de Crédito (VISA, MasterCard, etc.). O campo exibirá exibe o código e a descrição da Bandeira do Cartão de Crédito.


Image Modified
Para utilizar o Pagamento por Cartão de Crédito, o usuário

deverá

deve gerar o Contrato, preencher os campos de Pagamento por Cartão de Crédito e posteriormente executar o processo de Gerar Lançamentos. Após execução deste Processo, não será permitido modificar o valor desses campos.
Importante:
Durante o processo nativo de matrícula, o usuário possui a opção de gerar o Contrato e os Lançamentos Financeiros do Contrato automaticamente. A geração dos Lançamentos automática não deve ser utilizada para os casos de pagamento por Cartão de Crédito, pois o usuário precisa informar o NSU e a Bandeira antes de gerar os Lançamentos. Após geração do Contrato, o usuário deverá acessá-lo, informar os campos do pagamento e executar o processo Gerar Lançamentos.
Se houver um erro por parte do usuário e caso utilize esta opção (Gerar Lançamentos automaticamente no processo da Matrícula), a baixa deverá ser realizada diretamente no Protheus. Após gerar os Lançamentos Financeiros do Contrato estes campos ficarão desabilitados para edição.


PONTOS DE ATENÇÃO:


Nota
titlePontos de Atenção
  • Não está prevista nenhuma rotina para preenchimento automático dos campos. O usuário deve preenchê-los manualmente, somente quando o pagamento for realizado com Cartão de Crédito.
  • Não está prevista nenhuma rotina para integrar as Bandeiras dos Cartões de Crédito. Os registros deverão ser inseridos no TOTVS RM manualmente na tabela dinâmica espelhando o cadastro no Protheus (mesmos códigos).
  • Ao salvar um Contrato cuja opção Pagamento com Cartão de Crédito esteja marcada, o usuário será informado que os dados da baixa serão enviados ao Protheus e que, portanto, as informações não poderão mais sofrer alterações após geração dos lançamentos financeiros. A partir desse momento os campos referentes ao cartão ficarão desabilitados e não poderão mais ser alterados.
Expandir
titleExportação de Clientes (TOTVS RM x Protheus)

5.3. Req. 03 – Exportação de Clientes (TOTVS RM  Protheus)

Este requisito detalha a exportação do cadastro de Clientes a ser realizada entre o TOTVS Gestão Financeira e o Protheus. O processo não apresenta diferenças entre as Coligadas do SESI e SENAI. Esse processo é automático e não precisa ser agendado.

5.3.1 Pré-Requisitos / Parametrizações

  1. Deve ser criado o campo complementar IDINTEGRACAO para a FCFOCOMPL: Alfanumérico, Tamanho 255, Texto. A criação deste campo já está contemplada no arquivo TOTVS_Custom_Consolidate_All_Parte2.sql.
  2. O RM precisa estar parametrizado para permitir Clientes e Fornecedores Globais (em todas as Coligadas). Esse parâmetro é ajustado no caminho: Módulo BackOffice Gestão Financeira, menu Ambiente  Parâmetros  TOTVS Gestão Financeira  Selecionar Contas a Pagar - Lançamento  Etapa Cliente/Fornecedor e marcar o parâmetro Permite Globais, conforme imagem abaixo. O campo "Default Cli/For Global" também precisa ser marcado para facilitar os cadastros. Abaixo, segue tela da parametrização.


5.3.2 Descrição do Processo

Ao acessar as funcionalidades disponíveis no cadastro do Aluno (Educacional | Currículo e Oferta | Aluno) através dos botões: "Cadastrar ALUNO como responsável", "Cadastrar PAI/MÃE como responsável", "Cadastrar RESPONSÁVEL ACADÊMICO como responsável" ou ao incluir ou editar um Cliente no módulo BackOffice | Gestão Financeira | Cadastros | Clientes/Fornecedores a exportação será acionada.
Na inclusão ou alteração, a customização acionará a função MATA030 (pacote IIFR_CLIENTE_PCK) e neste momento enviará o registro para o Barramento IIF, de onde será lido pelo Protheus.
A inclusão/alteração do Cliente será concretizada no TOTVS independente do retorno recebido pelo Protheus. Caso ocorra erro na integração, o usuário poderá visualizar o erro ocorrido e reenviar o registro através interface de log descrita através do Req. 08. Se for necessário alterar alguma informação no cadastro, ele será integrado novamente de forma automática após alteração. A interface de log mostrará também o pacote que foi enviado ao barramento.
O Cliente no Protheus é compartilhado, ou seja, utiliza um cadastro único para todas as empresas. Portanto, no TOTVS RM o Cliente deve ser global (coligada 0).
O campo complementar IDINTEGRACAO para a FCFOCOMPL receberá o resultado da integração realizada (Id Barramento).
Os campos de Endereço (Principal e Pagamento) são de preenchimento obrigatório, já que são obrigatórios no Protheus. São eles: CEP, Rua, Número, Bairro, Estado, Município e País. O campo Data de Nascimento também é obrigatório. Não será permitido salvar o cadastro sem informar estes campos.
PONTOS DE ATENÇÃO:

  • Nenhum anexo do cadastro de Clientes Fornecedores será integrado, tampouco acionará a integração no momento que for salvo.
  • Nenhum processo do cadastro de Clientes Fornecedores acionará a integração.
  • Os campos que serão integrados neste Requisito podem ser consultados na Especificação Funcional.
  • Somente serão exportados dados dos registros classificados como Clientes ou Ambos (FCFO.PAGREC = 1 Cliente ou FCFO.PAGREC = 3 Ambos).
  • Somente serão exportados dados de registros globais (coligada 0). Caso seja criado um Cliente não global, a customização irá gerar uma mensagem de erro na interface de log.
  • Através deste requisito serão integrados dados de inclusões e atualizações de Clientes. Não faz parte deste escopo a exclusão de registros.
  • Todos os campos do tipo texto serão tratados antes de serem enviados ao barramento IIF. Serão retirados alguns caracteres especiais e todo tipo de acentuação. Além disso, o texto será enviado em caixa alta.

...

Expandir
titleInterface de Log e Reenvio de Dados

5.8. Req. 08 – Interface de Log e Reenvio de Dados

Este requisito detalha a disponibilização de uma tela de log customizada capaz de apresentar o resultados de todos os registros enviados visível em TOTVS Educacional | Customização | Monitor de log de exportação.

5.8.1 Pré-Requisitos / Parametrizações

Não se aplica.

5.8.2 Descrição do Processo

Os registros que foram exportados e geraram ocorrências de erros, ficando com status "Pendente", poderão ser reprocessados através do processo de 'Reenvio de dados' disponível na visão Monitor de Log de Integrações.
Esta tela não permite inclusão, alteração ou exclusão de registro.
O campo IDFUNCPROC determinará o processo vinculado ao registro de log sendo:

IDFUNCPROC

Funcionalidade

Composição da Chave do Registro

1

Exportação de Clientes

CODCOLIGADA

CODCFO

2

Exportação de Pedido de Venda (Processo Seletivo)

CODCOLIGADA

IDLAN

3

Exportação de Pedido de Venda (Contrato Educacional)

CODCOLIGADA

CODCONTRATO

IDPERLET

RA


CODCOLCFO

CODCFO

3

Exportação de Pedido de Venda (Contrato Educacional - Parcela Avulsa)

CODCOLIGADA

CODCONTRATO

IDPERLET

RA


CODCOLCFO

CODCFO

IDLAN

4

Exportação de Baixa de Lançamento de Contrato Educacional (Cartão de Crédito)

CODCOLIGADA

IDLAN

5

Exportação de Lançamentos Contábeis (Contrato Educacional)

CODCOLIGADA

CODCONTRATO

IDPARTIDACREDITO

IDPARTIDADEBITO

14

Exportação de Baixa de Lançamento de Contrato Educacional (Cancelamento)

CODCOLIGADA

IDLAN

22

Exportação de Baixa de Lançamento de Processo Seletivo (Cancelamento)

CODCOLIGADA

IDLAN

25

Exportação de Pedido de Venda (Contrato Corporativo)

CODCOLIGADA

IDCNT

IDMOV

26

Exportação de Lançamentos Contábeis (Contrato Corporativo)

CODCOLIGADA

IDCNT

IDPARTIDACREDITO


IDPARTIDADEBITO

27

Exportação de Baixa de Lançamento de Contrato Corporativo (Cancelamento)

CODCOLIGADA

IDLAN


O campo STATUS determinará o status vinculado ao registro de log sendo:
S = Sucesso - Registro integrado com "sucesso".
E = Erro - Registro apresentou "erro" na integração e poderá ser reprocessado.
C = Cancelado - Registro teve seu reprocessamento cancelado e não está disponível para ser integrado.
A interface de log é composta por duas tabelas, cabeçalho do log - LOGINTEGRACAO e item do log - ZITMLOGINTEGRACAO.
Para o processo de reenvio, se o número da tentativa for menor ou igual ao "Limite Tentativas para Reenvio", parametrizado através do Req. 01 – Parâmetros da customização, o processo de reenvio de dados será executado na tentativa de integrar o registro novamente. Neste caso, não será gerado novo log para o registro, o log atual será atualizado com os dados do reenvio e com o número de tentativas de integração incidentes sobre o registro.
Caso o número de tentativas seja superior ao limite parametrizado, o processo customizado irá enviar um e-mail para o "Endereço de e-mail responsável' que deverá ser parametrizado através do Req. 01 – Parâmetros da customização, notificando ao usuário que o registro excedeu ao número de tentativas de integração permitido. O registro terá seu status alterado para "Cancelado" e não será reprocessado.

...