TRATATIVA DE ERROS TRATATIVA DE ERROS GSURF - DICAS E TRATATIVAS Existem cenários com restrições de permissões (firewall e/ou políticas de usuários com restrições de acesso) que podem resultar em erros durante o processo de instalação e/ou utilização do módulo TEF/PIX. Objetivo deste artigo é fornecer base para algumas tratativas destes cenários e fornecer dados para acionamento de suporte do time GSURF. 1. Boas práticas: O cenário ideal para utilização do GSURF LISTNER - Serviço de VPN necessário para utilização do módulo de TEF deverá ser validado com as boas práticas descritas abaixo: Verificação de Requisitos sem apresentação de erros Perfil Administrador do Sistema Operacional (não de nosso ERP) Firewalls desabilitados 2. Cenários de erros: Execução do VERIFICADOR DE REQUISITOS - GSURF - Veja o print abaixo: No print acima são exibidos o status OK em verde, se forem apresentados erros em vermelho parecidos com os alistados abaixo: Erros relacionados a coleta FINGERPRINT Erros de comunicação relacionados a DNS / CDP / UDP / TCP Erros relacionados a comunicação com GSURF Políticas de segurança e restrições de firewall: Se nosso cliente possuir politicas de segurança de usuários e/ou restrições de firewall, isso pode ocasionar erros de comunicação com SITEF e/ou GSURF 3. Verificações relacionadas a permissão de acesso GSURF Permissão total de gravação e leitura da pasta CLISITEF Porta TCP 4096 liberada e não sendo utilizada por outro sistema de VPN: Para validar a liberação da porta acima, utilize o aplicativo TCP VIEW - Clique aqui para realizar o download! Print acima demonstra a utilização do TCP VIEW: No campo de pesquise, insira a porta 4096, o cenário ideal é que nenhum aplicativo e/ou serviço esteja utilizando esta porta, o resultado da pesquisa não pode retornar nenhum resultado Se nosso cliente possuir POLÍTICAS DE SEGURANÇA o time de TI de nosso cliente deverá validar as seguintes liberações: Endereço IP e Máscara de Sub-rede: Endereço IP: 18.231.194.64 Máscara de sub-rede: /26 (Isso significa que o intervalo de IPs vai de 18.231.194.64 a 18.231.194.127) Portas de Liberação TCP: 4096 443 55844 55845 Portas de Liberação UDP: 18.231.194/26 443 DNS Local 53 UDP (consultas em gsurfnet.com) Permissões de Usuário Instalação: Usuário que realiza a instalação do GSURF LISTNER e instalação da TEF no terminal precisa ser de perfil ADMINISTRADOR (do sistema operacional e não de nosso ERP) Permissões de Usuário OPERADOR PDV: Usuário com permissão de validação FINGERPRINT Serviço GSURF LISTNER utiliza metodologia TLS 4. Acionamento time GSURF As verificações e orientações ao cliente acima, devem ser realizadas nos cenários de erro pelo analista que realiza a instalação do módulo de TEF. Em alguns cenários de erro de comunicação com SITEF, o time de SUPORTE SITEF pode sinalizar a necessidade de verificações adicionais pelo time de SUPORTE GSURF, neste caso o analista deverá acionar o time GSURF pelos contatos abaixo: Time SUPORTE GSURF: Telefones: (48) 3254-8700 / (48) 3181-0033 COLETA DE EVIDÊNCIAS No cenário de erros de transações, após validação do time de PPI, pode ser necessário abertura de chamado junto a SITEF ou outras tratativas internas. Quando houver esta necessidade, será obrigatório a abertura de ticket relacionado ao respectivo caso, alistamos abaixo informações obrigatórias que devem constar neste chamado: Dados do Cliente: SCHEMA CNPJ Razão Social Equipamentos utilizados: Modelo do PINPAD Versão do PDV/TOTEM Identificação da Adquirente: Tipo da Transação: Inserção Aproximação Cartão Bandeira do Cartão Aproximação Smartphone: Atenção aos dados abaixo: Modelo Iphone ou Android Qual aplicativo utilizado: ApplePay GooglePay AndroidPay Qual Banco utilizado? 04 primeiros números do cartão que foi utilizado na transação: Estes números (também identificados com BIN) são obrigatórios para que a FISERV possa ter acesso detalhado a transação. É realizado debito e estorno de maneira automática no respectivo banco ou cartão do cliente final? Dados da Transação: Data e Hora da transação Valor da Transação Se cliente utilizar mais de um PDV/TOTEM, qual PDV/TOTEM origem da transação Evidências do Erro Vídeo do erro, mostrando tentativa e erro DMP do respectivo PDV/TOTEM - Arquivo dentro da pasta CLISITEF Se totem enviar LOG RETORNO DE ERRO: DADOS LÓGICOS - SOLICITAÇÕES TEF O retorno de dados lógicos inválidos pode se dar pelas seguintes razões: Erro de digitação nos dados lógicos Dados lógicos não vinculados ao CNPJ do cliente em questão Dados lógicos expirados ou ainda não validados pela adquirente Tratativas de solução: Compartilhar com cliente o print enviado no retorno de erro Orientar o cliente a acionar a adquirente e solicitar novos dados lógicos ou a confirmação da liberação dos mesmos dados lógicos, para o respectivo CNPJ: ATENÇÃO PARA CENÁRIO MULTI-EMPRESA é comum haver divergência entre dados lógicos e CNPJs das filiais. Obrigatório coletar a evidencia desta tratativa entre cliente e adquirente: um PRINT que conste os dados do cliente (CNPJ e Razão Social) e dados lógicos informados pela adquirente. O print se faz necessário para eliminar a possibilidade de erros de digitação. Responda no ticket em questão as informações acima, principalmente com o PRINT como evidência. Observação importante: Nenhum analista da CPLUG tem autonomia para acionar uma adquirente e validar dados lógicos de qualquer cliente. Tratam-se de dados sensíveis e de responsabilidade total entre cliente e adquirente. RETORNO DE ERRO: FALHA NAS CREDENCIAIS - SOLICITAÇÕES PIX O retorno de falha nas credenciais pode se dar pelas seguintes razões: Falta de vínculo com respectivo Bankline ou portal do respectivo banco: Cenários onde existe mais de uma chave pix cadastrada, alguns bancos exigem vínculo com a chave pix correta Erro de digitação das credenciais: Em casos de credenciais com CLIENT ID e CLIENT SECRET a possibilidade de erro de digitação é grande Tratativas de solução: Compartilhar com cliente o print enviado no retorno de erro Validar com cliente processo de vínculo com Bankline ou portal do respectivo banco. Utilize os artigos desta seção para consulta - Clique aqui! Obrigatório coletar a evidencia do vínculo com Bankline ou portal do respectivo banco: um PRINT que conste as respectivas credenciais. O print se faz necessário para eliminar a possibilidade de erros de digitação. Orientar o cliente a acionar o banco e solicitar novas credenciais ou a confirmação da liberação das mesmas credenciais. Obrigatório coletar a evidencia desta tratativa entre cliente e banco: um PRINT que conste os dados do cliente (CNPJ e Razão Social) e credenciais informadas pelo banco. O print se faz necessário para eliminar a possibilidade de erros de digitação. Responda o ticket com as informações acima, principalmente com o PRINT como evidência. Observação importante: Nenhum analista da CPLUG tem autonomia para acionar um banco e validar credenciais de qualquer cliente. Tratam-se de dados sensíveis e de responsabilidade total entre cliente e banco. RETORNO DE ERRO: CNPJ EXISTENTE NA FISERV - SOLICITAÇÕES TEF Informações importantes sobre o erro de CNPJ EXISTENTE NA FISERV: Cenário onde o respectivo cliente já utilizava outra Software House ou Integradora de TEF pela FISERV (utilizando SITEF EXPRESS, SkyTef ou outra integradora que utilize a base ou serviços vinculados a FISERV) O credenciamento na base de dados da CPLUG via SITEF EXPRESS de um cliente no perfil acima só é possivel se forem atendidas uma das alternativas abaixo: Exclusão completa do cadastro: Opção mais indicada e de menor complexidade Duplicação de CNPJ feita pelo time FISERV: Importante destacar que a duplicação a solicitação junto a FISERV, deve ser feita entre CPLUG e FISERV. Veja detalhes abaixo, de como o cliente deve solicitar isso para CPLUG. Tratativas de solução: 1. Exclusão completa de cadastro: 1.1 Antiga Software House ou Integradora precisa EXCLUIR COMPLETAMENTE cadastro na FISERV/SITEF EXPRESS/SKYTEF, após exclusão é necessário reiniciar módulo GERPDV no respectivo ambiente FISERV/SITEF EXPRESS/SKYTEF. 1.2 Evidência que formalize e confirme a exclusão: um print de um email que conste dados do cliente (CNPJ e Razão Social, Dados da antiga Software House ou Integradora e confirme a EXCLUSÃO do cadastro e reset do módulo GERPDV. 1.3 Obrigatório que o analista envie um print deste email em resposta ao retorno de erro. 1.4 SLA desta solicitação dependerá de atuação time Nlógicos e  time FISERV: não deve ser informado o prazo de 24 horas úteis, o time NLOGICOS retornará assim que finalizada a ocorrência. 2. Duplicação de Cadastro na FISERV: 2.1 Caso a antiga Software House ou Integradora não forneça a evidência acima ou dificulte o processo: O cliente deve enviar para o analista que esta tratando a solicitação) no seguinte padrão: Titulo do email: Solicitação de Migração de Parceiro - FISERV Corpo do email: Dados da Empresa: CNPJ e Razão social Formalizo o interesse de migrar de parceiro, passarei a utilizar a CONNECT PLUG como integradora na FISERV e desejo que meu cadastro seja duplicado no ambiente FISERV, para que a ConnectPlug possa me credenciar como seu cliente, em sua base de dados na FISERV. 2.2 Obrigatório que o analista envie um print deste email em resposta ao retorno de erro, no respectivo ticket, 2.3 SLA desta solicitação dependerá de atuação time Nlógicos e  time FISERV: não deve ser informado o prazo de 24 horas úteis, o time NLOGICOS retornará assim que finalizada a ocorrência.