Foi disponibilizada uma nova API para consultar os associados vinculados a uma reserva.

Com a nova funcionalidade, integrações e sistemas externos podem acessar de forma estruturada as informações dos associados relacionados a uma reserva específica.

Por que isso é importante?

Em uma negociação, uma reserva pode possuir diferentes pessoas vinculadas ao processo.

A nova API facilita a consulta dessas informações, permitindo que integrações recuperem os associados de uma reserva de forma centralizada e estruturada.

Pré-requisitos

É necessário possuir acesso e autorização para utilizar a API do sistema.

Agora existe um endpoint de API dedicado para trocar o titular de uma reserva, reaproveitando exatamente as mesmas regras de negócio já validadas na tela do sistema.

https://{dominiodocliente}.cvcrm.com.br/api/v3/comercial/reservas/{idReserva}/titularidade

Agora é possível:

• Alterar o titular de uma reserva diretamente via API;
• Integrar essa ação a ERPs, portais do cliente e apps parceiros sem simular a interface.

Por que isso é importante?

Até então, a troca de titularidade só era possível pela tela, e integrações externas não tinham como executá-la de forma automatizada. A nova API elimina essa limitação, mantendo total consistência com o comportamento da interface.

Como funciona?

A troca só é permitida para uma pessoa que já seja associada da própria reserva. A operação respeita as permissões existentes, as regras de bloqueio de pessoa e a configuração de visibilidade por situação da reserva. Todo o processo é atômico: ou tudo é concluído, ou nada é alterado.

ATENÇÃO

O idassociado informado deve ser um associado ativo da própria reserva, obtido previamente em
GET /v3/comercial/reservas/{idReserva}/associados. A API não aceita promover uma pessoa nova ou
externa à reserva — apenas associados já existentes.

A troca é cruzada: o titular atual passa a ocupar a posição de associado que era do associado promovido,
preservando o vínculo de cônjuge quando existente.

A operação é bloqueada se a pessoa do novo titular estiver com bloqueio de reserva ativo e não houver
exceção para o corretor da reserva.

Pré-requisitos

• Possuir permissão de alteração de titularidade;
• O novo titular deve já ser um associado ativo da reserva.

O relatório de Acompanhamento de Reservas foi aprimorado com a inclusão de uma nova coluna para exibir a situação anterior da reserva.

Agora, além da situação atual, é possível visualizar também o status em que a reserva se encontrava anteriormente.

Por que isso é importante?

O acompanhamento das mudanças de situação é importante para entender o histórico e a evolução de uma reserva ao longo do processo.

Com a nova informação disponível diretamente no relatório, fica mais fácil identificar de onde a reserva veio e analisar suas movimentações.

Como funciona?

No relatório de Acompanhamento de Reservas, foi adicionada a coluna Situação Anterior.

A coluna apresenta a situação em que a reserva se encontrava antes da sua situação atual, permitindo uma análise mais completa das alterações realizadas.

Foi disponibilizada uma nova API para consultar os tipos de reserva cadastrados no sistema.

O novo endpoint permite listar os tipos de reserva e suas principais informações:

 https://{dominiodocliente}.cvcrm.com.br/api/v3/configuracoes/tipos-reserva

Por que isso é importante?

A nova API facilita o acesso às configurações dos tipos de reserva por integrações e sistemas externos.

Com isso, torna-se possível consultar de forma estruturada informações importantes utilizadas na configuração e no gerenciamento das reservas.

Pré-requisitos

É necessário possuir acesso e autorização para utilizar a API do sistema.

O que foi desenvolvido?

Foi adicionada uma nova ação às funcionalidades de Vencimento de Leads e Vencimento por Empreendimento: Alterar situação do lead.

Ao selecionar essa ação, o usuário poderá escolher, por meio de um select, para qual situação do workflow o lead deverá ser direcionado quando vencer naquela etapa.

O select exibirá somente as situações ativas do workflow.

Como funciona?

Ao ocorrer o vencimento do lead, caso a ação Alterar situação do lead esteja configurada, o lead será automaticamente direcionado para a situação selecionada.

As ações configuradas entre a situação atual e a situação de destino do workflow, caso existam, serão executadas normalmente.

Porém, nesse processo, os pré-requisitos configurados no workflow serão ignorados, permitindo que o lead seja direcionado para a situação definida mesmo que não atenda às condições normalmente exigidas para entrada nessa etapa.

Qual o benefício?

A melhoria permite que o gestor tenha maior controle sobre o comportamento dos leads após o vencimento, podendo definir automaticamente o próximo estágio do lead no workflow.

Isso reduz a necessidade de movimentações manuais e permite criar fluxos específicos para leads que não foram tratados dentro do prazo definido, mantendo a execução das ações da etapa de destino sem impedir a movimentação por conta de seus pré-requisitos.

1. O que foi desenvolvido?

Foi criada uma nova configuração de específico para a integração com o Facebook, permitindo que o cliente defina se os leads que ficaram pendentes devido a erros ou falhas de permissão deverão ser processados novamente após a normalização da integração.

2. Qual problema essa melhoria resolve?

Atualmente, quando ocorre uma falha de permissão no Facebook, os leads podem permanecer pendentes. Em alguns casos, o cliente acaba realizando o cadastro ou a importação desses leads manualmente para não perder as oportunidades.

Quando a integração é normalizada, esses leads pendentes podem voltar a ser processados, fazendo com que sejam convertidos novamente de forma atrasada ou gerando duplicidade no fluxo do cliente.

A nova configuração permite que o cliente tenha controle sobre esse comportamento, evitando o reprocessamento de leads que já foram tratados por outro meio.

3. Qual o benefício para o cliente?

Maior controle sobre o recebimento dos leads provenientes do Facebook, permitindo que cada cliente defina o comportamento mais adequado para sua operação e evitando que leads tratados manualmente durante uma indisponibilidade da integração retornem posteriormente de forma inesperada.

🔹 O que é?
A API que retorna os contratos assinados por assinatura eletrônica de uma reserva passou a devolver também o link de acesso ao documento assinado, no índice link_contrato_assinado. A melhoria é voltada para quem utiliza o DocuSign como plataforma de assinatura eletrônica.

🔹 Por que é importante?
Antes, quem consumia a API sabia que o contrato havia sido assinado, mas precisava entrar na plataforma de assinatura ou no CV para chegar até o documento. Agora o link vem junto na própria resposta, permitindo que sistemas integrados acessem, armazenem ou disponibilizem o contrato assinado automaticamente, sem etapa manual no meio do caminho.

🔹 Como funciona?

• Faça a chamada no endpoint api/v3/comercial/reservas/{idreserva}/contratos-assinados, informando o ID da reserva.
• A resposta traz os contratos assinados por assinatura eletrônica daquela reserva e, para cada um, o índice link_contrato_assinado.
• O índice vem preenchido apenas para contratos assinados via DocuSign. Para as demais plataformas de assinatura eletrônica, o campo é retornado vazio.
  
  OBS: para os 3 serviços de assinatura temos como baixar o documento assinado, para Clicksign e CV Sign é no link da API, para o Docusign tem uma diferença pois é fornecido pela integração o certificado e o contrato assinado de forma separada e por isso, foi adicionado essa melhoria. 

🔹 O que é?
As variáveis extras do tipo moeda — criadas recentemente no sistema — agora geram automaticamente duas variáveis de contrato: uma com o valor informado no campo e outra com esse mesmo valor por extenso.

🔹 Por que é importante?
Contratos costumam exigir que valores monetários apareçam em algarismos e por extenso. Antes, esse texto precisava ser escrito manualmente, o que abria espaço para erro de digitação e divergência em relação ao valor real. Agora o extenso é gerado a partir do próprio valor da variável, mantendo os dois formatos sempre iguais.

🔹 Como funciona?

• Em Contratos > Criar Variáveis, cadastre a nova variável escolhendo o tipo Moeda.
• Ao salvar, o sistema disponibiliza automaticamente duas variáveis na lista de variáveis do contrato:
  • [[EXTRAS][NOME_DA_VARIAVEL]] — traz o valor informado no campo.
  • [[EXTRAS][NOME_DA_VARIAVEL_EXTENSO]] — traz esse mesmo valor escrito por extenso.
• No editor do contrato, clique na variável desejada para inseri-la no texto. Você pode usar as duas juntas, no formato usual de contratos (valor seguido do extenso).

Agora é possível controlar, por perfil de acesso, quem pode abrir assistência técnica em áreas comuns e em localidades pelo Painel Gestor.

O que foi entregue:

• Duas novas permissões no perfil de acesso: uma para abertura em áreas comuns e outra para localidades
• Bloqueio automático da abertura em área comum quando a permissão estiver desmarcada no perfil
• Solicitações originadas pelo cliente passam a ter escopo restrito à unidade dele

Como configurar:

1. Acesse o cadastro de Perfis de acesso no Painel Gestor
2. Localize as permissões de abertura de assistência em áreas comuns e localidades
3. Desmarque as permissões nos perfis que não devem ter essa autonomia

Por que isso importa:

• Garante que a abertura em área comum aconteça somente quando houver respaldo formal do síndico, evitando chamados sem legitimidade
• Reduz retrabalho da equipe de assistência com solicitações abertas fora do escopo correto
• Deixa claro o limite de atuação de cada perfil, diminuindo divergência entre o que o cliente solicita e o que a construtora atende

Nas bases já existentes, os perfis seguem com a permissão liberada — o comportamento atual não muda. O bloqueio só passa a valer quando você desmarcar a permissão no perfil.

O que foi feito:
O endpoint PUT de assistência passou a aceitar o envio de campos adicionais (customizados) diretamente no payload da requisição, bastando informar o ID do campo adicional e o valor correspondente. Antes, a atualização desses campos exigia uma chamada separada; agora ela pode ser feita na mesma requisição de atualização da assistência.

Por que é importante para o produto:
Reduz o número de chamadas necessárias para manter a assistência atualizada, simplifica a integração para clientes que usam campos customizados no fluxo de atendimento/assistência técnica, e elimina risco de inconsistência entre a atualização da assistência e a dos seus campos adicionais (que antes podiam ficar dessincronizados por serem chamadas separadas).