Atualizações Julho2023

COMERCIAL

Realizar atualização de cadastro de clientes

Chave Criada: INTERVALO_DIAS_OBRIGATORIO_ATUALIZAR_CLIENTE

Ao abrir a tela do cliente (Comercial -> Clientes), o sistema deverá verificar na tb_Cliente o campo dataUltimaAtualizacao, a ultima atualização feita dos dados pessoais deste cliente e verificar se o intervalo para atualização esta num prazo menor que o estipulado.

Se estiver em um prazo maior que o estipulado, o sistema deverá exibir a mensagem.

Mensagem de Cliente Desatualizado

Caso a chave esteja NULL, ele não fará a validação.

Cliente Churn - Endpoint para alimentar a nova tabela relacionada a cliente com dado de risco de cancelamento

1. Criada a nova tabela TB_InformacaoAdicionalCliente no módulo comercial.
2. Criado um novo endpoint para Webservice Adapter que receba os dados para pontuação do cliente.
3. Este endpoint alimenta a TB_InformacaoAdicionalCliente e o campo PontuacaoTotalRiscoCancelamento.
4. Caso seja enviado um dado de um cliente que ja possua este campo preenchido, o sistema deve sobrescrever este dado;
5. Se o campo PontuacaoTotalRiscoCancelamento estiver preenchido, será exibido na tela principal de dados do cliente;

Exibição de Risco de Churn em Tela de Cliente

Endpoint Criado: https://[URL]/ws/comercial/clientes/informacao_adicional

Adicionar novos campos na TB_InformacaoAdicionalCliente e no cadastro de cliente

Adicionados os campos UFRG, EstadoCivil (SOLTEIRO, CASADO, DIVORCIADO, VIÚVO, OUTRO), Naturalidade, UFNaturalidade;

Estes campos estarão populando a tabela TB_InformacaoAdicionalCliente.

Serão apresentados quando for um cliente pessoa física, sendo que apenas o UF RG é obrigatório.

Novos Campos para Informação Adicional do Cadastro de Cliente

Log Edição Endereço

Implementada a criação de log de edição de endereços. Tais modificações estarão disponíveis nas tabelas TB_LogCliente e TB_LogContrato.

Ao realizar uma edição do cadastro de endereço de um cliente, há uma pergunta em um pop up: "Deseja apenas corrigir algum erro no cadastro de clientes?":

• Caso a resposta seja SIM: O sistema deverá salvar as alterações na tabela TB_LogCliente;
• Caso a resposta seja SIM: O sistema deverá salvar as alterações na tabela TB_LogCliente e na TB_LogContrat do contrato vinculado;

• Caso a edição venha do botão "vincular novo", em contrato > endereços e através do botão cadastrar: O sistema deverá salvar as alterações na tabela TB_LogCliente;
• Caso a edição venha do botão "vincular novo", em contrato > endereços e um novo endereço seja vinculado: O sistema deverá salvar as alterações na tabela TB_LogContrato.

Log de edição de endereço

Deverão ser levadas em consideração as edições nos campos:

• CEP;
• Estado;
• Cidade;
• Bairro;
• TipoLogradouro;
• Logradouro;
• Número;
• TipoComplemento;
• Complemento;
• Referência;
• Classificação;
• Latitude;
• Longitude;

Atualização de Prospectos

Ao cadastrar um prospecto no sistema, ao informar o CPF do prospecto, caso já haja na base um cadastro de cliente com o mesmo CPF informado, antes de sobrescrever os dados do prospecto, o sistema deverá checar se os dados de telefone celular, telefone fixo, sexo, e-mail informados no prospecto são iguais aos dados já no cadastro do cliente.

• Se sim, prosseguir com a recuperação dos dados de cliente como é feito atualmente e seguir com o cadastro do prospecto.
• Se não, o sistema deverá exibir modal com os dados divergentes e permitir que o usuário escolha qual dado será mantido em ambos os cadastros. Ao selecionar a opção de manter dados seja do prospecto seja do cliente, os dados deverão ser atualizados em ambos os cadastros.

A alteração realizada deverá gerar log na TB_LogCliente (edição) e na TB_LogProspecto (cadastro),

Armazenar dados do SPC e Clear Sales

Criada chave DIAS_INTERVALO_CONSULTA_CLEARSALE no módulo comercial.

Ao cadastrar um prospecto no sistema, após informar o CPF do prospecto, e nos filtros correspondentes as ações de qualificação CONSULTA_CLEAR_SALE e CREDITO_POR_CPF o sistema deverá validar se há outros prospectos registrados para o mesmo CPF registrados no sistema:

Se sim: VALIDAR CLEAR SALE

No prospecto registrado anteriormente, há algum registro na TB_ProspectoDataTrust com data da consulta igual ou inferior aos dias informados na chave DIAS_INTERVALO_CONSULTA_CLEARSALE:

• Se sim: o sistema deverá exibir mensagem ao usuário, informado que o CPF já possui resultados da consulta.
  • Se aprovado ou reprovado na consulta anterior, o sistema deverá replicar o registro de TB_ProspectoDataTrust do prospecto anterior para o novo prospecto, simulando a realização da consulta.
• Se não: seguir com a realização da consulta integrada normalmente.

Validar SPC/SERASA/SOPHUS

No prospecto registrado anteriormente, há algum registro na TB_ConsultaCredito com data da consulta igual ou inferior aos dias informados na chave DIAS_INTERVALO_CONSULTA_SPC.

• Se sim: o sistema deverá exibir mensagem ao usuário informado que o CPF em questão já resultado da consulta.
  • Se aprovado ou reprovado na consulta anterior. Não é necessária replicação de registro pois a TB_ConsultaCredito é vinculada apenas a CPF e não a prospecto.
• Se não: seguir com a realização da consulta integrada normalmente.

Inclusão de dois ou mais itens no mesmo pacote

Será permitido o cadastro de pacotes de planos no sistema, que tenha mais de um item de tecnologia OUTROS, na tela de cadastro de pacotes de planos.

Pacote com 2 itens da tecnologia OUTROS.

Melhoria de Prospecto

Criada uma nova qualificação de funil automática chamada CONSULTA_CEL_EMAIL.

Criada uma nova chave de configuração do modulo comercial IDS_FUNIS_PROSPECTO_ALTERACAO_CEL_EMAIL.

Criada a tabela TB_ConsultaCelularEmailInterno, no módulo comercial, semelhante as outras qualificações de prospectos;

Regra de Negócio

No funil de qualificação CONSULTA_CEL_EMAIL, a consulta busca dados da base interna do sistema, consultando se o e-mail e tekefon celular informados no cadastro do prospecto já estão vinculados a um ou a mais clientes:

• Se sim, o prospecto será reprovado;
• Se não. o prospecto seguirá o cadastro;

A qualificação CONSULTA_CEL_EMAIL deve ser exibida no histórico de qualificações.

Melhoria em Motivos de Cancelamento de um Contrato

Criado novo atributo IsDesistencia (boolean) na tabela TB_MotivoCancelamento;

Alterado o cadastro de motivos de cancelamento para que seja possível informar na tela se o motivo de cancelamento se trata de uma desistência de contratação (sim/não).

Ao realizar o cancelamento de contrato o sistema deverá:

• Se o status do contrato for AGUARDANDO_INSTALACAO, recuperar a listagem apenas dos motivos de cancelamento cadastrados com IsDesistencia true.
• Se o status do contrato for diferente de AGUARDANDO INSTALACAO, recuperar a listagem apenas dos motivos de cancelamento cadastrados com IsDesistencia = false:

Cadastro de Motivo Cancelamento com Flag Desistência

Criada nova tabela TB_MotivoCancelamentoPerfil (IDMotivoCancelamento,IDPerfil);

Alterado o cadastro de motivos de cancelamento, para que seja possível informar a quais perfis o motivo estará liberado para visualização.

Ao realizar o cancelamento do contrato o sistema deverá recuperar a lista de motivos liberados para o perfil do usuário.

Melhoria nos vencimentos exibidos do contrato

Nos combos onde há seleção do dia do vencimento exibir uma legenda para o dia inicial e final de cobrança do período configurado no vencimento no combobox.

Modificadas as telas de venda de um contrato e alteração de vencimento.

Períodos de Vencimentos Apresentados

FINANCEIRO

Alterar multa do cancelamento compulsório

Alterada a forma em que o sistema realiza o cálculo da multa do cancelamento compulsório, para que se padronize se fazer o cálculo pela mesma regra do cancelamento voluntário, ou seja, considerando como parâmetro de data o vencimento da fidelidade do contrato e a data do cancelamento.

Chave criada: MULTA_CANCELAMENTO_COMPULSORIO_POR_DATA_CANCELAMENTO, campo boolean;

Regra de Negócio:

• Se a informação desse campo for true, o sistema deverá realizar o cálculo de multa no cancelamento compulsório baseado na data de vencimento da fidelidade e data de cancelamento.
• Se a informação desse campo for false, o sistema deverá realizar o calculo de multa do cancelamento compulsório baseado na data de vencimento fidelidade, a data de vencimento da primeira fatura em aberto e o conteúdo da chave MINIMO_DIAS_PARA_NEGATIVAR , como é feito atualmente.

Permissão de faturas e faturamento por cliente

Regra de Negócio para Faturamentos:

• Criada a permissão GERAR FATURAMENTO POR CLIENTE.
• Os perfis que tiverem a permissão GERAR FATURAMENTO POR CLIENTE devem visualizar apenas a tela de geração de faturamento por cliente;
• Os perfis que estiverem ativos com a permissão GERAR FATURAMENTO - FT01, devem visualizar as telas de geração de faturamento por cliente, por forma de cobrança e em massa;

Tela de Faturamento disponível apenas por cliente

Regra de Negócio para Faturas:

• Criada a permissão GERAR FATURA POR CLIENTE.
• Os perfis que tiverem a permissão GERAR FATURA POR CLIENTE devem visualizar apenas a tela de geração de faturas por cliente;
• Os perfis que estiverem ativos com a permissão GERAR FATURA - FT08, devem visualizar as telas de geração de faturas por cliente, por forma de cobrança e em massa;

Tela de Fatura disponível apenas por cliente

Alteração tela de impressão em massa,

Na tela de impressão em massa, o sistema não irá exibir as formas de cobrança marcadas como IsCartaoRecorrente = true;

Criada a tabela TB_UsuarioFormaCobranca.

Alterado o cadastro de usuários Adapter para que apresente uma tela de seleção de formas de cobrança. Ao ser selecionado, esta determina as formas de cobrança que estarão disponíveis ao utilizar a tela de impressão em massa.

Tela de seleção de formas de cobrança para impressão em massa

Colocar limit opcional e campo para filtro de opções de cidade

Foram adicionados, um campo de Quantidade de clientes, que recebe um número inteiro e limita o número de impressões;

E um combo de seleção de cidades, com filtro de pesquisa textual;

Combo de seleção de cidades, Filtro e Campo Quantidade, em impressão em massa

Alterar atributo de "apto carnê" contratos cancelados

Alterado o atributo "apto para gerar carnê", agora ele ficará disponível para edição deste atributo em contratos cancelados.

Alterar observações fiscais contratos cancelados

Será permitida a alteração de observações fiscais e observação de fatura em contratos cancelados.

Campos de Observações dos contratos, em Contratos -> Dados de cobrança e fiscais

Filtro de forma de cobrança

Na tela de serviços adicionais, em Clientes -> Dados Financeiros -> Serviços Adicionais, serão exibidos serviços que:

• Estejam vinculados a área de cobertura da cidade, do endereço do cliente;
• Que a empresa vinculada à conta financeira seja igual ou esteja contida na composição do cadastro de serviço (Ainda sendo implementado);

Serviços disponíveis para adicionar ao contrato

Alteração de Fatura Proporcional

Criada uma nova chave, no módulo financeiro, denominada STATUS DE CONTRATO PARA GERACAO DE PROPORCIONAIS. Nessa chave, devem ser informados os nomes dos status que permitem geração de faturamento mensal de proporcionais.

Serão aceitos dados nessa chave dados no formato texto exatamente iguais aos cadastrados para status de contrato no sistema (CANCELADO, EM NEGOCIACAO, HABILITADO, HABILITADO EM CONFIANCA, INATIVO TEMPORARIAMENTE, SUSPENSO, SUSPENSO PARCIALMENTE)

Alterar as procedures de faturamento que informam os status de contrato que deverão passar a ler essa chave para geração.

Na geração de faturamentos deverá ser respeitado o parâmetro para a geração.

Alteração na tela de Integração de Faturamentos

Otimizada a SPU spuBuscaFaturamentosPendentesIntegracao para diminuir o tempo de resposta da tela de integração de faturamento pendente.

Retirado botão + da tela de integração -> faturamentos.

Retirado botão +

Adicionar flags de formas de cobranças para gerar remessas

Para atender a necessidade de gerar remessas para várias formas de cobrança ao mesmo tempo, foi desenvolvido:

Na funcionalidade "integração bancária -> gerar remessa", estará disponível a opção contas financeiras (alterado em atividade posterior para Agrupador, leia Grupo de Formas de Cobrança, na mesma página), que ao ser selecionado, deve recuperar todas as contas financeiras liberadas para visualização do usuário que está utilizando.

O sistema gerará o arquivo de remessa unificado com dados de todas as formas de cobrança selecionadas. Na tabela TB_ArquivoRemessa, será gerado um arquivo de cada forma de cobrança, com o mesmo arquivo.

Considere estas mudanças aplicadas na tela de Gerar Remessa, Gerar Remessa Avulsa e Gerar Remessa de Alterações.

Tela Gerar Remessa com Filtro de Agrupador Disponível

Grupos de forma de cobrança

Criada a Tabela TB_GrupoFormaCobranca e o atribuo IDGrupoFormaCobranca na TB_FormaCobranca;

Na tela de geração de remessa, adicionar o filtro do agrupador para selecionar as formas de cobrança a partir dele. Não será necessário adicionar conta financeira nos filtros.

Criado um CRUD de grupo de forma de cobrança, em Financeiro -> Tabelas de apoio -> Configuração bancaria -> Grupos de formas de cobrança. Os grupos deverão ser formados respeitando que os atributos sejam iguais:

• ContaFinanceira
• NumeroSequencial
• CodigoCarteira
• SemRegistro
• EntidadeEmissoraBoleto
• ModalidadeCobranca
• PercentualMulta
• PercentualJuros
• DebitoAutomatico
• BoletoPix
• CodigoTransmissao
• CodigoConvenio
• Operacao
• IdIntegradoraEletronica
• IdIntegradoraPix
• Cnab

Permissão: ALTERAR_GRUPOS_FORMA_COBRANCA = DC07 criada para cadastro dos grupos de formas de cobrança;

Cadastro de Grupos de Forma de Cobrança

Criar tela para arquivos de negativação

Tela apresentará arquivos da pasta indicada nas configurações, chave PATH_ARQUIVO_INCLU�SAO_EXCLUSAO_SERASA

Caminho:

INTEGRAÇÃO

Melhoria na integração de clientes SAP

Criada a tabela TB_ClienteIntegracaoSAP no módulo integração.

Na rotina de integração com os clientes:

Caso o campo IDClienteSAP estiver preenchido, no campo "CardCode", será enviado o dado IDClienteSAP, preenchido na TB_ClienteIntegraçãoSap;

Caso o campo IDClienteSAP for Null, será enviado no campo "CardCode" o mesmo dado que é enviado atualmente (C+IDCliente);

A tabela foi criada no banco de dados apenas, não há campo em tela;

Edição spuInclusaoSPC e spuRemocaoSPC

Para realizar integração com a SOPHUS, foi necessário atualizar as SPU's spuInclusaoSPC e spuRemocaoSPC.

• Adicionados os campos: Sexo, UFRG, UFNaturalidade, Naturalidade, Estado Civil para ambos as SPU's;
• Adicionados os campos: Número do Boleto; Nome da Mãe; Nome do Pai; Número celular (Telefone Móvel) para a spuRemocaoSPC.

OBS: Exceto o campo 'Sexo', todas as informações são disponibilizadas na tabela TB_InformacaoAdicionalCliente, do Módulo Comercial.

Realizar alteração de integração de multas no SAP

Alterada a spuBuscaFaturamentosPendentesIntegracao, que exibe dados de faturamento para integração na aba Financeiro -> Integração -> Faturamentos. Nessa tela serão exibidos todos os faturamentos já apresentados atualmente na spu, mas serão retirados os faturamentos cuja composição financeira tenha o atributo unidadeMedida igual a 1.

Criada uma nova procedure, apenas para a tela de faturamentos com pagamento, para exibir os faturamentos com pagamento e identificados com o atributo unidadeMedida = 1;

Criado novo parâmetro de conf.cfg da rotina de integração de faturamentos: emissaoMultaDataPagamento.

Alterar a rotina de integração de faturamentos para ler o novo parâmetro, emissaoMultaDataPagamento:

Sim: ao integrar o faturamento de composições financeiras que possuam o campo unidadeMedida=1 o sistema deverá enviar nos campos DocDate e TaxDate do JSON deverão ser informados com data de pagamento da fatura vinculada.Exemplo: Fatura do cliente: DataPagamento 10/07/2023.

Ao integrar para o SAP os campos DocDate e TaxDate, deverão ser enviados com a data do pagamento, ao invés da data atual como era antes desta atividade.

Não: Manter o Funcionamento do sistema;

Tela de integração de Pagamento - Negociadas

Criada uma nova tela para integrar faturamentos pagos por negociação. Nessa tela deverão ser exibidos os faturamentos cujas faturas originais foram negociadas, mas que não possuíam notas fiscais integradas.

Os valores referentes as negociações deverão ser enviadas para emissão de notas fiscais considerando o valor final da dívida, ou seja, deverão ser emitidos considerando os valores de multa, juros e descontos concedidos na negociação.

INTRANET

Adição do menu configurações do modulo intranet na tela

Adicionado ao menu do módulo intranet, link para a página de configurações do módulo.

Nesta página estarão disponíveis as chaves de configuração dos módulos de intranet.

Configurações Intranet

Caminho: Intranet -> Tabelas de apoio -> Configurações;

Permitir a manipulação de arquivos de imagem para central e app anexada no módulo intranet

Criado um caminho para mapear onde os arquivos serão salvos no servidor. Tabela Configurações, módulo intranet, chave: PATH_ARQUIVOS_CENTRAL.

Através da Tela, será possível, editar a descrição das imagens e excluir imagens.

Cadastro de Imagens para App e Central, no módulo Intranet

No módulo intranet, criar uma nova tela que permita anexar arquivo de imagem para exibição na central e no novo app de clientes

Criada uma nova tela que permita anexar arquivo de imagem para exibição na central e no novo app de clientes.

Localizada em Intranet -> Arquivos Central -> Cadastro.

Tela de Envio de Arquivos para Central do Cliente e App do Cliente

OPERACIONAL

Log de Alteração de atendimento

Será registrado em log, na TB_LogAtendimento. alterações no atendimento relacionadas ao tipo de atendimento ou tipo de contrato.

Validação no endpoint de abertura de atendimento

Ao solicitar a abertura de um atendimento via webservices, será validado se já há um atendimento com status diferente de SOLUCIONADO e SEM_SOLUCAO;

Se houver, será exibida a mensagem: "Não é possível abrir atendimento, pois o contrato já possui atendimento do tipo..." e será bloqueado a abertura do atendimento;

Alteração nos endpoints: /ws/comercial/atendimentos/cadastrar e /ws/comercial/atendimento;

Criação de histórico nas tipificações

Criada uma nova tabela, TB_LogTipoAtendimento, no módulo comercial.

Adicionada uma divisão "histórico" na tela de cadastro dos tipos de atendimentos. Quando cadastrar ou editar algum tipo de atendimento, este registro será adicionado na tabela de Log.

Exibição de histórico de log de tipo de atendimento

Atendimento de Contrato Cancelado

Ao realizar um upgrade ou Downgrade de contratos, o sistema irá analisar se no antigo contrato, existe vinculado algum atendimento do tipo de serviços de SUPORTE, INTERNO, ALTERACAO_ENDERECO ou SOLICITACAO_SERVICO com status diferente de SOLUCIONADO ou SEM_SOLUCAO.

Pop up de aviso de atendimentos sendo transferidos a um novo contrato

Caso haja, o sistema irá apresentar uma mensagem ao usuário avisando: "Existem atendimentos vinculados ao contrato anterior que serão transferidos ao novo contrato".

O sistema deverá automaticamente vincular ao novo contrato os atendimentos que se enquadrarem a regra. O sistema deverá criar log na TB_LogAtendimento no formato:

EDIÇÃO DE ATENDIMENTO

# Contrato do atendimento alterado por Upgrade/Downgrade:

- Antigo: Contrato A

- Novo: Contrato B

Realizar a Não Geração de O.S para Tecnologia OTT e Tv

Criado o atributo "geraOS" na TB_Plano, do tipo boolean;

Ao realizar uma edição de endereço no cadastro do Cliente -> Dados Pessoais -> Endereços, o Adapter deverá trazer a relação de todos os contratos vinculados ao endereço que está no processo de edição.

Na alteração de um endereço, a alteração deverá ocorrer seguindo as seguintes regras:

• Todos os contratos selecionados para edição;
• Nos casos de contratos vinculados ao mesmo pacote, a alteração deverá ocorrer de forma obrigatória, não permitindo que o usuário consiga alterar as flags de marcação;
• Caso exista algum contrato no qual o plano esteja com a flag "geraOS" com atributo "false", o sistema Adapter não deverá realizar a abertura de OS de Alteração de Endereço.

Na tela de Contratos, em endereços vinculados, não será permitida a edição de endereços diretamente por esta tela, quando o contrato selecionado estiver vinculado à um pacote. Esta alteração deverá ser feita a partir da tela em Clientes > Dados Pessoais > Endereços, para que haja efeito sobre todos os contratos vinculado ao pacote.

Botão "Vincular Como" foi retirado das opções disponíveis para contratos pacote

Realizar Confirmação de Tickets Pendentes

Na abertura de atendimentos, quando usuário realizar alguma ação tangível ao sistema, na tela de atendimentos, o sistema deverá mostrar uma mensagem ao usuário sobre a confirmação de salvar o atendimento:

Pop Up de Atendimentos Pendentes

Ao clicar em confirmar, o sistema deve salvar o atendimento. Caso clique em voltar, o usuário será redirecionado à tela de atendimentos.

Encaminhamento de Solicitação em Aberto

Criadas as tabelas TB_AtendimentoEncaminhamento, TB_MotivoEncaminhamento e TB_MotivoEncaminhamentoPerfil;

Em comercial -> tabelas de apoio -> atendimentos, criar nova tela para cadastrar os motivos de encaminhamento, com as informações de:

• Descrição;
• Ativo(sim/não);
• Perfis para seleção;

Regra de Negócio:

Na tela de atendimentos, ao clicar no botão alterar destino e selecionar o novo destino do atendimento, o sistema irá abrir um modal onde serão apresentados os motivos de encaminhamento ativos e atribuídos ao perfil do usuário logado. Essa informação deverá ser obrigatória.

No mesmo modal também deverá ser apresentado o campo de observações não obrigatória. Na edição dos atendimentos, deverá ser apresentada opção de visualizar histórico de encaminhamentos onde

RELATÓRIOS

Inclusão de coluna "nome do contrato" na exportação do faturamento

Adicionada a coluna nome do contrato, ao exportar faturamentos;

Para utilizar, adicione field nomePlano(String) no arquivo relatorio_eventos_faturamento.jasper;

REDES

Alteração no autenticador do provisionamento

ID_CONEXAO_TELNET_PROVISIONAMENTO não preenchido:

• Mapeamento Interno Adapter: Quando a chave do ID_CONEXAO_TELNET_PROVISIONAMENTO não estiver preenchida, o sistema irá buscar a OLT de acordo com o IdCaixa, passado como parâmetro no body da requisição;
• Mapeamentos Integrados: Quando a chave do ID_CONEXAO_TELNET_PROVISIONAMENTO não estiver preenchida, o sistema irá buscar a OLT através dos parâmetros tipoEquipamento, idCidade, tipoONT caso não tenha o IdCaixa;

Através da OLT o sistema irá buscar as conexões vinculadas a ela e o provisionamento irá ocorrer normalmente como e atualmente.

Foi corrigido um relacionamento incorreto, na consulta no banco na busca das conexões da OLT.

Alterar chave de integração para mapeamento

Criada a chave ID_SERVIDOR_INTEGRACAO_MAPEAMENTO;

Removidas as chaves que faziam menção à mapeamentos integrados, ID_SERVIDOR_INTEGRACAO_MAPEAMENTO_OZ_MAP e ID_SERVIDOR_INTEGRACAO_MAPEAMENTO_GEOGRID;

ROTINAS

Alterar rotinas que tenham impressão de fatura/código de barras para utilizarem a biblioteca impressaoBoleto

Alteradas as rotinas que tenham impressão de fatura/código de barras para utilizarem a biblioteca impressaoBoleto,

Alteradas para verificar se é dia útil por cidade, nas rotinas q utilizam a TB_DiaNaoUtil.

Modificadas as rotinas EnvioFaturasNotasFiscais, ImpressaoMassa e EnvioAtrasoSMS.

Criar uma rotina para executar a consulta de pagamentos de pix (cielo) e dar baixa na fatura caso a mesma tenha sido paga.

Endpoint criado : /ws/financeiro/pix_dinamico/pagamentos/consultar

Regra de Negócio:

• O endpoint busca todas as cobranças pix geradas e não pagas, que a data de expiração seja maior que o dia anterior, através da spuBuscaPixDinamicoSemPagamento.
• Para cada registro encontrado, será acionado o endpoint da cielo (/1/sales/ - GET), conforme documentação, para verificar se foi pago ou não.
• Caso o status de retorno seja 1 ou 2 (de acordo com documentação da Cielo), dará baixa na fatura;
• Ao final de toda execução o endpoint roda uma query para apagar todos os pix com data de expiração menor que ontem.

OBS: Esse endpoint interno, salva todos os logs da consulta na integradora na TB_LogPixDinamico.

Atendimento Log4 - Status de Rotina de Atendimento Recorrente

Criado um novo parâmetro, no arquivo conf.properties, nomeado StatusAtendimentoRecorrente. Nesse parâmetro deve ser passado o status que o atendimento de recorrência, criado pela rotina vaio assumir. Deverá ser informado um valor único dos status aceitos pelo sistema.

Alterada a rotina de atendimentos recorrentes, para na abertura de atendimentos do tipo recorrência, o status do atendimento aberto seja o informado na configuração da rotina.

TELEFONIA

Estudar forma de enviar as estatísticas diárias do SIP PULSE ativadas no momento da venda do contrato

Alterar a forma de enviar novos contratos para a integração SIP Pulse, para que seja possível enviar, no momento da venda as estatísticas diárias dos contratos ativadas.

Para isso, ao incluir um novo assinante (venda de um novo contrato), o sistema deverá, após as chamadas de inclusão de assinante na plataforma SIPPULSE, chamar o método de ativar estatísticas e setar o campo BloqueioEstatisticasDiarias deverá ser salvo como false.

WEBSERVICES

Criar novo método para retornar imagem para central e app anexada no modulo intranet  

Endpoints criados:

GET - intranet/central/arquivos

GET - intranet/central/arquivos/{id}

Dúvidas, consultar o manual webservices Adapter;

Novo Endpoint de Negociação

Criado novo endpoint: https://URL/ws/financeiro/faturas_negociar

Criado no objetivo que não seja necessário enviar a senha da central no endpoint, recebendo apenas o CPF do usuário;

Mais detalhes, consultar o manual de webservices Adapter.