Checklist de Atualizações

Funcionalidade: Funciona em partes. Sobre IMPORTAÇÃO, é difícil relatar algo pois não testei a funcionalidade dessa seção (para importar intermitentes, por exemplo, ou importar colaboradores para o sistema).

Agora sobre a exportação: não está funcionando corretamente em algumas seções. Ex: Check-In > Filtro > De 27/09/2025 00:00 Até 27/09/2025 23:59 > todos os check-ins aparecem. Quando clicamos em Exportar Excel Detalhado, recebemos um arquivo de 6,3 KB vazio (apenas com o cabeçalho de separação: ID / Razão Social / Nome Fantasia / CNPJ/CPF / Empresa / Data Evento / Hora Evento / Situação Operacional / Data / Hora / Serviço / Qtd. Escalada / Nome Completo / RG / CPF / Telefone 1 / Telefone 2 / Período / Presença). Arquivo gerado para esse teste: checkins2025-09-27T00_00_00ate2025-09-27T23_59_59.xlsx.

Outro exemplo: Profissionais Operacionais > Exportar Excel > chrome-error://chromewebdata/:1 GET https://sistemaprimiciaservicos.com.br/profissionais-operacionais/export-excel? net::ERR_HTTP_RESPONSE_CODE_FAILURE 500 (Internal Server Error) (erro apresentado via console do Google Chrome).

Funcionalidade: Indicador de cadastro incompleto NÃO é algo que funciona, e isso é facilmente explicado: a URL captura todas as IDs com algum campo incompleto, e isso sempre quebrará o navegador. Atualmente temos um link com 22.708 caracteres (4.652 palavras), abrangendo 4.645 IDs únicas. Isso não é funcional - nunca exibirá resultado nenhum. O viável seria armazenar tudo em uma lógica que dite o seguinte: SE o cadastro não tiver algo nos campos A, B, C e D, MOSTRE no card que está incompleto, porém com uma URL limpa (algo único, uma condicional que contenha todos os cadastros/todos os dados para uma visualização mais ampla, como por exemplo https://sistemaprimiciaservicos.com.br/profissionais-operacionais?sem_foto_pontuacao_cnh=1). Hoje os cards de CHECKINS ATRASADOS, CHECKINS AGUARDANDO REVISÃO, CADASTROS INCOMPLETOS e CAD. MANOBRISTAS INCOMPLETOS possuem essa restrição de link. O de manobristas incompletos ainda funciona, porém em um universo em que centenas de cadastros sejam criados em pouco tempo e alguns campos não sejam preenchidos, a quebra da URL continuará acontecendo.

Cadastros duplicados: não existe duas ou mais pessoas com o mesmo CPF, e isso continua ocorrendo. O sistema não possui trava para identificar e bloquear cadastros com o mesmo CPF, e por isso já tivemos inúmeros casos de cadastros duplicados. Essa lógica, na verdade, nem deveria existir, visto que não podemos ter dois e-mails iguais no mesmo servidor, dois cadastros com o mesmo CPF/E-mail em sites e serviços que utilizamos no dia a dia, duas pessoas com o mesmo acesso no gov... poderia citar diversos exemplos, mas é para mostrar que "cadastro duplicado" é algo que, trazendo para o nosso universo, não deveria existir desde o começo. Isso mostra que o sistema não foi (e continua não sendo) programado para evitar duplicações.

Ainda nesse #2024123101: "Unificação dos cadastros de profissionais". Inexistente. O que ocorreu: inativação de PERFIS DUPLICADOS e manutenção (com correções e inclusão de dados completos) de perfis existentes. Ou seja: ocorreu uma alimentação interna, partindo dos colaboradores internos da empresa, e não da parte de TI. Os cadastros foram inativados, mantivemos apenas um cadastro para os colaboradores (e, novamente, isso deveria ser uma regra explícita desde o primeiro momento) e só, não houve unificação de cadastros.

Funcionalidade: Como deveria ser: Falta leve = falta leve. Falta moderada = falta moderada. Falta grave = falta grave. Dispensa = dispensa. Cancelado = cancelado.

No check-in: ok, está sendo interpretado dessa forma. Tudo o que colocamos é traduzido assim. Porém na página do profissional operacional: falta é falta, cancelamento é falta, dispensa é falta. Todos acabam vindo como "Compareceu? Não". Então a lógica foi implementada apenas na página de check-in (como a própria descrição diz), mas não temos essa adaptação para a página dos profissionais. Tudo o que é do universo de faltas é classificado como uma falta, mas para fins de relatórios precisaríamos checar tudo manualmente (novamente, igual no outro caso citado acima).

Uma forma de verificar tudo seria exportando a planilha com os dados (algo que não está funcionando) e, mesmo se funcionasse, não traria resultados após a liberação dos check-ins. Uma vez liberado, ele sai da aba de check-ins e não podemos mais utilizar para fins de verificação. Ou seja: a implementação veio "faltando coisa", pois ao mesmo tempo em que ela é útil e serve um pouco ao propósito (afinal, colocar dispensa/folga mostra que não lidamos somente com presenças e faltas), ela fica "travada" no âmbito do check-in.

Inclusive, ainda sobre a demanda acima: os dois pedidos englobam a mesma coisa (novos botões e regras), porém não especificam exatamente quais botões. No segundo pedido tudo bem, temos a definição de botões de folga/dispensa. Porém no primeiro item, a questão ainda permanece. Tivemos, sim, alterações nos botões de falta, porém o mesmo serviço foi feito duas vezes? Um demandou 8h (#2025030701) e o outro 6h (#2025032001) - com relação a isso, como ficamos?

Funcionalidade: Novamente: filtrando por 01/09/2025 até 30/09/2025, por exemplo, utilizando Dir. Op. EDIVALDO MENDES DA SILVA: o Status das Solicitações por Data (gráfico em barra) traz 59 escalações no dia 14/09, 8 escalações no dia 17/09, 1 no dia 21/09 e 71 no dia 25/09. Porém no gráfico logo ao lado (gráfico pizza nomeado Total de Solicitações por Status), temos números MUITO maiores: 4.270 entregues, 365 faltas, 71 cancelados e 88 não escalados, totalizando 4.794 MOs. O filtro está ativo, então deveria trazer todos os números daquele filtro, e não de um somatório geral.

No gráfico abaixo dos citados anteriormente, também gráfico pizza (Serviços Solicitados), temos todos os serviços solicitados naquela data. Porém, novamente, o filtro não afeta o que está sendo exibido aqui: temos A&B, APOIO (E), APOIO (I), ATENDENTE (CREDENCIAMENTO) (...) até Orientador.

Os gráficos passam a exibir um pouco corretamente ao adicionarmos uma empresa (ex: PASS SOLUÇÕES traz Total de Solicitações por Status e Serviços Solicitados dentro da empresa PASS). Porém, quando a empresa é NULA (ou seja, quando não setamos nenhuma nas buscas e buscamos por todas), o filtro deveria ser lido e utilizado com o que estamos solicitando. Se eu quero saber sobre um diretor, por exemplo, eu não quero um somatório geral de solicitações de todas as empresas - quero um total daquele diretor, um total daquele período especificado e com o nome daquele gestor. Se não existir, ok, não apresente dados. Mas também não deveria apresentar dados totais da Primícia.

Funcionalidade: "Inclusão do campo região no cadastro de profissional operacional" - inoperante ultimamente. Citando exemplos concretos: IDs 8963, 8964, 8965, 8966, 8967, 8968, 8969, 8970, 8971, 8972: cadastros criados recentemente (de 26/09 a 27/09), todos com o campo "Região" sem preenchimento. O campo Região, no meu entendimento, deveria abranger tanto capital como interior e, no final, demais localidades (pois todas as cidades possuem regiões, não somente SP capital). Porém, o sistema não está se comportando como o esperado. Ao digitar o CEP temos o preenchimento completo de Endereço, Bairro, Cidade e Estado, porém Região não recebe o mesmo tratamento.

No mesmo pedido, temos o "Job para atualizar periodicamente o campo de região profissional operacional baseado no cep". No meu entendimento, seria um tipo de cron job (um agendador de tarefas, que executaria a mesma função todos os dias às 06h00, por exemplo). Porém, vamos retornar um pouco mais: ID 7900, criado em 20 de julho de 2025: região está nula, também sem preenchimento. Então o job de atualizar periodicamente está setado de quanto em quanto tempo? Pois utilizei exemplo de um cadastro de dois meses atrás, e segue sem a Região...

"Filtro por região na tela de escalações": Hotel Fasano Itaim, ID 15945. Filtrando como Região > Todas / Zona Norte / Zona Leste / Zona Oeste: ok, sem novidades. Os colaboradores aparecem. Filtrando como Região > Centro / Zona Sul: erro (Undefined variable $profissional_operacional). Para Zona Oeste, manobrista, temos três resultados. Como Zona Leste, seis resultados. Zona Norte: um. Ou seja: em algum momento a região foi setada, porém foi manualmente? O job chegou a funcionar por um período (pequeno) de tempo?

Funcionalidade: Os cards apresentam escalas atrasadas e check-ins atrasados, porém nunca foi muito bem desenhado.

Escalas Atrasadas = indicar escalas atrasadas a partir de meia noite do dia em questão (por ex.: 29/09/2025 temos uma escala pendente para o Center Norte às 13h): ok, é válido. Assim criamos um alerta para aquela escala em questão.

Check-ins atrasados = indicar um check-in das 14h como "atrasado" à meia noite é, na minha visão, errado. A diferença desse card para a escala atrasada: um check-in das 14h não está atrasado no início daquele dia, apenas a partir das 14h01 ele poderia ser considerado atrasado. Já a escala, para acender um sinal de alerta, não vejo problemas.

Um PS sobre outro card também: Checkins Aguardando Revisão. Eles mostram que estão aguardando revisão no momento em que o último check-in é realizado, porém deveriam subir um ou dois dias depois (para termos um tempo hábil de checagem, por exemplo). Esse é o menos crítico, pois no final o check-in só será liberado quando clicarmos na opção correta. Porém, os outros cards (principalmente os check-ins atrasados) estão com uma lógica um pouco errada, na minha visão.

Funcionalidade: na minha visão, seria para bloquear solicitações com mais de três meses (ex: criar algo para janeiro de 2026 hoje, dia 29/09). Porém: solicitação 15129, aberta em 17 de junho de 2025, estava com a data errada: 18/06/2026 (e permanece assim na escala da colaboradora JAQUELINE NASCIMENTO DOS SANTOS até hoje). O próprio supervisor Wagner abriu rascunho, contratou e precisamos criar uma nova ID para substituir essa. Ou seja: a trava não funciona.

Funcionalidade: Criação de links para anunciar vagas no WaCRM - inexistente. Nunca existiu nem na versão anterior, nem na nova atualização. Isso sequer foi discutido nos últimos tempos, e pelo que consta no e-mail disparado no dia 31 de janeiro de 2025, já foi pago há quase nove meses. Não temos opções de criação de links, nunca tivemos algo parecido também.

Da mesma forma, o kanban nunca foi funcional na primeira versão (não existia nenhum indicativo, era apenas algo discutido) e, nessa nova atualização, já temos um menu porém ele não é muito intuitivo. Atualmente o "Em aberto" mostra todas as conversas abertas - e demora cerca de um minuto para carregar tudo, pois ele faz um carregamento de cerca de 5000 dados simultaneamente.

Via descrição dos serviços: "Criar estrutura de kanban onde mostra os contatos por opcao selecionada no menu", "Ao fechar o atendimento tirar do kanban o contato", "Criar separação do kanban por grupo de fila" - o kanban é algo instável, então as opções não estão rodando com exatidão. A segunda está funcionando e já foi testada - ao fechar um ticket, ele sai do kanban. Porém atualmente só temos duas filas: em aberto (algo que já temos na página "Atendimentos") e Pendencias. É preciso melhorar/acrescentar novas filas e testar com maior precisão essa função.

Funcionalidade: Implementação da aba grupos - funciona parcialmente. Explicação: a aba Grupos foi implementada no começo do ano (fevereiro/2025), porém não está 100%, mesmo após a implementação do novo CRM. Todos os grupos precisam ser aberto manualmente, um a um, porém um bug ocorreu recentemente e fez com que perdessemos todos os grupos da aba - fazendo, assim, com que a equipe precise subir manually um a um de novo. O que ocorreu: o OPERACIONAL 1 e o OPERACIONAL 2 foram conectados recentemente após a implementação do novo CRM, porém houve uma inversão e o 2 ficou como padrão. Acontecesse que o 1, o principal, sempre foi o padrão (inclusive no CRM anterior), então fizemos a reconexão dos aparelhos para evitar problemas. Porém, mesmo com isso, os problemas persistiram: perdemos histórico dos grupos, perdemos todos os grupos da aba (resultando no que citei ali em cima: precisamos abrir, novamente, um a um). E um erro menor, porém também já relatado, persiste: conversas avulsas sobem para a aba "Grupos" até hoje. Se o colaborador FELIPE enviar uma mensagem enquanto um operador estiver na aba Grupos, a conversa subirá para lá e permanecerá ali até um recarregamento da página.

Funcionalidade: A apresentação poderia ter sido realizada por um profissional interno, sem a necessidade de contratação de horas (no caso, duas horas) para uma apresentação do sistema WaCRM. E, além disso, a apresentação durou pouco tempo. Foi realizada em uma sexta-feira com todo o operacional, portanto não tínhamos como abandonar a operação naquele instante. Ou seja, não durou as duas horas como cobrado no orçamento.