A tela de Pesquisas recebeu um ajuste visual para tornar a navegação mais clara e a experiência mais atual.
O que mudou:
O que não mudou:
Foi criada uma nova variável para utilização em modelos HTML e Word, permitindo exibir a informação preenchida no campo Correção da série financeira.
[[SERIE][N][CORRECAO_SERIE]]
Até então, não havia uma variável específica para retornar a correção configurada na série, o que exigia preenchimentos manuais ou adaptações nos modelos de contrato.
Com essa melhoria:
A variável retorna o conteúdo informado no campo Correção da série financeira.
⚠️ Importante:
Essa variável retorna a correção da série, e não a correção do contrato como um todo.
A variável pode ser utilizada em:
Correção monetária: [[SERIE][1][CORRECAO_SERIE]]Exemplo de resultado:
Correção monetária: IPCAA Listagem de Boletos passa a exibir também os boletos do tipo ATO, contemplando tanto integrações com Linkpay quanto com Avendre Pay.
Até então, os boletos de ATO não estavam disponíveis na listagem, dificultando o acompanhamento e a gestão desses pagamentos pelos usuários.
Com essa melhoria, os boletos de ATO passam a seguir a mesma experiência já existente para os boletos de comissão, centralizando a operação em um único local.
Os boletos de ATO agora são exibidos na Listagem de Boletos juntamente com os demais títulos financeiros.
São contemplados:
Os usuários poderão visualizar as informações dos boletos diretamente pela listagem, facilitando o acompanhamento do status e dos dados do pagamento.
Passa a ser possível realizar o download dos boletos de ATO da mesma forma que já ocorre com outros tipos de boleto.
Os boletos de ATO também poderão ser cancelados pela listagem, seguindo as mesmas regras e comportamentos já aplicados aos boletos de comissão.
📍 Caminho:
Gestor → Financeiro → Listagem de Boletos
Novas capacidades:
Foi criada uma nova API no padrão V4 para permitir o gerenciamento da condição de pagamento das reservas de forma mais flexível e segura.
Com ela, integrações passam a poder:
Tudo isso sem a necessidade de recriar a condição completa da reserva.
Antes dessa melhoria, alterações na condição de pagamento dependiam de processos exclusivamente manuais.
Agora, sistemas integrados conseguem realizar ajustes pontuais diretamente na reserva, mantendo maior aderência aos fluxos comerciais e financeiros.
Permite incluir uma nova série na condição de pagamento da reserva.
Endpoint
POST /v4/comercial/reservas/{idReserva}/condições
Permite alterar informações de uma série já existente na condição de pagamento.
Endpoint
PATCH /v4/comercial/reservas/{idReserva}/condicoes/{idReservasCondicoes}
Permite excluir uma série da condição de pagamento da reserva.
Endpoint
DELETE /v4/comercial/reservas/{idReserva}/condicoes/{idReservasCondicoes}
Todos os endpoints:
As APIs oferecem as mesmas possibilidades disponíveis na interface do sistema, incluindo:
A API valida automaticamente cenários como:
| Código | Descrição |
|---|---|
| 200 | Operação realizada com sucesso |
| 400 | Dados inválidos |
| 401 | Token JWT ausente ou inválido |
| 403 | Usuário sem permissão |
| 404 | Reserva ou condição não encontrada |
| 422 | Regra de negócio bloqueou a operação |
| 500 | Erro interno |
A nova API é ideal para integrações que precisam realizar manutenção da condição de pagamento após a criação da reserva, sem depender de ações manuais na interface. Consulte em https://desenvolvedor.cvcrm.com.br/.
Agora, ao realizar um distrato de reserva via integração, o sistema também registra automaticamente o motivo de bloqueio da unidade.
Antes dessa melhoria, quando o distrato era realizado por integração, a unidade era bloqueada sem qualquer identificação do motivo.
Isso dificultava:
Com a alteração, todas as unidades bloqueadas por distrato passam a possuir um motivo associado.
Ao receber uma solicitação de distrato via integração, o sistema:
Por padrão, será utilizado o motivo:
"Distrato via Integração"
Ao clonar uma reserva, o sistema agora passa a aplicar automaticamente a planta da unidade de destino, quando houver uma planta vinculada a essa unidade.
Antes da melhoria, a reserva clonada podia ficar sem uma planta associada, mesmo quando a unidade de destino possuía uma planta cadastrada.
Isso gerava inconsistências na reserva e exigia ajustes manuais por parte dos usuários.
Com a correção, a clonagem passa a respeitar as características da unidade selecionada.
A edição em lote de pagamentos de comissão foi ajustada para que os pagamentos selecionados sejam agrupados sob o mesmo identificador, permitindo a geração de um único boleto quando aplicável.
Em alguns cenários, ao corrigir pagamentos por meio da edição em lote — especialmente quando as datas originais estavam retroativas — o sistema criava novos pagamentos com IDs diferentes.
Como consequência:
Com a melhoria, os pagamentos editados em conjunto permanecem agrupados, seguindo a lógica esperada pela operação.
Ao realizar uma edição em lote de pagamentos:
O agrupamento será realizado apenas quando a comissão estiver configurada para trabalhar com boletos por data de pagamento.
Caso a configuração da comissão utilize outro modelo de geração de boletos, o comportamento atual será mantido.
Agora é possível configurar níveis hierárquicos nos times de atendimento. Você define um time N1 (primeiro contato) e um time N2 (apoio/escalonamento), vinculados por assunto. O sistema distribui os chamados seguindo a ordem configurada, com tempo máximo de resposta por nível. Quando necessário, o N1 encaminha o chamado ao N2 e o N2 pode devolvê-lo ao N1 para continuidade com o cliente.
Como funciona
Por que ela é importante:
Equipes com múltiplos perfis de atendimento precisam de um fluxo claro de escalonamento. Sem isso, chamados complexos ficam presos no primeiro atendente ou são transferidos de forma manual e desorganizada. Com os níveis configurados, o roteamento acontece de forma estruturada, o responsável pelo chamado é atualizado automaticamente e o histórico se mantém, reduzindo retrabalho e melhorando a experiência do cliente.
Agora, ao iniciar uma simulação por uma unidade que já possui espaço complementar associado, o sistema realizará a associação automaticamente.
Antes da melhoria, o usuário precisava adicionar manualmente o espaço complementar durante a simulação, mesmo quando ele já estava vinculado à unidade.
Com a automação:
🔹 O que é? A consulta de Campos Adicionais, que antes estava disponível apenas na CVDW, agora também está presente nas APIs gerais do CV CRM
🔹 Por que é importante? Quem integra com as APIs do CV passa a ter acesso aos Campos Adicionais sem precisar recorrer à CVDW. Tudo no mesmo ecossistema, seguindo o mesmo padrão de autenticação e estrutura já utilizados nas demais APIs do produto.
🔹 Como funciona? A API retorna uma listagem paginada de todos os campos adicionais cadastrados no sistema, com suporte a filtros e ordenação. A autenticação segue o padrão já utilizado nas APIs do CV, via Bearer Token ou JWT.
Todos os detalhes de parâmetros e exemplos de requisição estão disponíveis na documentação: https://desenvolvedor.cvcrm.com.br/reference/listarcamposadicionaisv4
