Melhoria no consumo de processamento – Agendamento
Foi identificado que a função de agendamento para emissão de documento não estava gerenciando corretamente os acessos simultâneos em momentos de alta demanda, para corrigir implementamos melhorias no código para reduzir o esforço da CPU, evitando processos repetidos e ajustando como as informações são gravadas no banco de dados.
Atualização de vaga disponível – Agendamento
Para que a disponibilização de vagas aconteça corretamente, adicionamos ao agendamento uma regra que bloqueia a efetuação de agendamentos com horários concorrentes.
Sendo assim, quando o requerente realizar o agendamento, a lista de agendamentos com as vagas disponíveis será atualizada.
Adequação de campos de filiação
A fim de adequar o sistema a Resolução CEFIC n° 020, ajustamos os campos de filiação contidos na CIN. Portanto:
O campo filiação comporta o número máximo de 148 caracteres;
Se o nome da filiação passar do limite máximo de caracteres, será abreviado para se encaixar na quantidade de linhas e caracteres;
Para os casos em que há 2 filiações, e pelo menos uma filiação tiver 37 caracteres, ela ocupará 1 linha, restando outras 3 para serem utilizadas pela outra filiação;
Para os casos em que há 2 filiações, as linhas serão divididas igualmente caso ambas possuam até 37 caracteres;
Para os casos em que há 3 filiações, apenas uma das filiações poderá ocupar 2 linhas, e se dentre as 3 filiações houver mais de uma que ultrapasse os 37 caracteres, todas as 3 serão abreviadas
Para os casos em que há 4 filiações, serão abreviadas todas as que tiverem mais de 37 caracteres.
Aplicando-se ao documento CIN.
Correção na visualização de informações na tela de conferência
Para atender as necessidades de usabilidade da tela de conferência, foi ajustado o layout da tela, como mostrado na imagem abaixo:
[CE] Ajuste no Fluxo de Protocolos Reaproveitados via VIPS
Foi definido que os protocolos reaproveitados automaticamente via VIPS devem seguir exatamente o mesmo fluxo de envio utilizado pelos protocolos iniciados do zero via DOC, bem como pelos protocolos criados por cópia total ou atendimento civil. Essa padronização assegura consistência em todas as etapas do processo, inclusive na impressão e finalização.
Ao reaproveitar um protocolo com o atributo “reaproveitamento”: true, o sistema deve marcar o protocolo como conferido automaticamente e realizar o envio para impressão com sucesso. Após essa etapa, o processo deve seguir normalmente até a conclusão final, sem necessidade de intervenção manual.
[CE] Envio de Requisições de 2ª Via com Reaproveitamento de Dados via Integração
Foi adicionada à tela de Consulta Identidade (Civil) a funcionalidade “Informar Cópia”, cujo objetivo é permitir que, após a realização de uma cópia total, o sistema envie automaticamente o protocolo antigo e o novo protocolo para a API externa, garantindo a correta atualização dos registros.
Com essa funcionalidade, o operador pode, ao concluir o processo de cópia total, acionar o botão “Informar Cópia” para enviar as informações de forma automática, mantendo a integridade do fluxo de integração e eliminando a necessidade de intervenções manuais.
Além disso, foi implementada a possibilidade de envio de requisições de 2ª via com reaproveitamento de dados através de integração com a VALID, dispensando o atendimento presencial nos casos de reimpressões que não apresentam alterações nos dados biográficos ou funcionais.
Essa atualização permite que, após finalizar os ajustes necessários no atendimento, o operador submeta o processo diretamente para a VALID por meio de API, garantindo maior agilidade, segurança e consistência no fluxo de reaproveitamento das informações.
[CE/ES] Consulta de Biometrias via Endpoint ConsultaBiometrias
Foi implementada a funcionalidade de consulta de biometrias para o parceiro VALID por meio do endpoint ConsultaBiometrias, utilizando parâmetros enviados via URL. Essa integração possibilita a obtenção de dados biométricos de forma flexível, com base nos filtros informados, garantindo a resposta adequada conforme os parâmetros utilizados na requisição.
Possíveis cenários de consulta
Consulta com todos os parâmetros válidos
Quando o parceiro VALID realiza uma chamada ao endpoint ConsultaBiometrias, preenchendo todos os parâmetros com valores válidos, a requisição deve ser concluída com sucesso e retornar os dados biométricos completos.
Consulta apenas por CPF
Quando apenas o CPF for informado, deixando o campo NúmeroProtocolo vazio, a chamada será concluída com sucesso e retornará os dados biométricos referentes ao CPF informado.
Consulta apenas por NúmeroProtocolo
Quando apenas o NúmeroProtocolo for informado, deixando o campo CPF vazio, a requisição será concluída com sucesso e retornará os dados biométricos vinculados ao protocolo informado.
Consulta apenas de Assinatura
Se o parceiro informar um CPF ou NúmeroProtocolo válido e preencher apenas o parâmetro Assinatura, a requisição será concluída com sucesso e a resposta conterá apenas os campos relacionados à assinatura.
Consulta apenas de Foto
Se for informado um CPF ou NúmeroProtocolo válido e apenas o parâmetro Foto for preenchido, a requisição será concluída com sucesso e a resposta conterá apenas os campos de foto.
Consulta apenas de Digitais
Quando um CPF ou NúmeroProtocolo válido for informado, e apenas o parâmetro Digitais for preenchido, a chamada será concluída com sucesso e retornará apenas os campos relacionados às digitais.
Consulta com CPF e NúmeroProtocolo vazios
Se os campos CPF e NúmeroProtocolo forem enviados vazios, a API deve retornar erro 400, informando na mensagem que ao menos um desses campos deve ser preenchido.
Consulta com Assinatura, Foto e Digitais vazios
Se os parâmetros Assinatura, Foto e Digitais forem enviados todos vazios, a API deve retornar erro 400, informando que ao menos um desses campos deve ser preenchido.
Consulta com valores inválidos
Se os campos CPF ou NúmeroProtocolo forem preenchidos com valores inválidos ou inexistentes, a API deve retornar erro 400, informando que o CPF ou protocolo não foi localizado.
[RN] Inclusão dos Campos Tipo de Material e Via nas Requisições de Impressão
Foi implementada a inclusão das informações de Tipo de Material (Papel ou Cartão) e Via (1ª ou 2ª via) nas requisições de impressão enviadas pelo Certfy para a nova gráfica Montreal, responsável pela impressão no estado do Rio Grande do Norte. Essa melhoria garante que os documentos sejam impressos no material correto, além de oferecer à gráfica um controle interno mais eficiente sobre os volumes de requisições de 1ª e 2ª via.
Com essa atualização, todos os processos que realizarem atendimento e integrarem com o MJ e GovBr, ao serem enviados para impressão externa, terão os campos TipoMaterial e NumeroVia corretamente preenchidos nas requisições.
Cenários de Envio
Os envios de lote de impressão, sejam realizados manualmente via Postman pelo endpoint /CadastrarPedido ou automaticamente através do job do servidor, devem conter as informações obrigatórias:
TipoMaterial: valor 0 para papel/cédula ou 1 para cartão de policarbonato.
NumeroVia: valor 0 para 1ª via ou 1 para 2ª via.
Exemplo de casos:
Para atendimentos de 1ª via, o campo NumeroVia é enviado com o valor 0.
Para atendimentos de 2ª via, o campo NumeroVia é enviado com o valor 1.
Para impressões em cédula (papel), o campo TipoMaterial é enviado com o valor 0.
Para impressões em cartão de policarbonato, o campo TipoMaterial é enviado com o valor 1.
Essas alterações asseguram que todo o fluxo de impressão externo, seja por lote ou via integração direta, ocorra de forma consistente e com os parâmetros necessários para a correta personalização dos documentos.