O envio de credores para o ERP Sienge agora permite configurar o valor do campo paymentTypeId, deixando de utilizar um valor fixo.

Por que isso é importante?

Antes, o sistema enviava o paymentTypeId = 2 por padrão. Embora funcionasse na maioria dos cenários, isso causava falhas em ambientes onde esse ID não existia ou foi removido.

Com a parametrização:

• A integração se adapta à realidade de cada cliente
• Evita bloqueios no cadastro de credores
• Elimina a necessidade de ajustes manuais (ex.: via Postman)

Como funciona?

Novo campo configurável

Foi criada uma configuração para definir o valor do paymentTypeId utilizado no envio de credores.

Caminho: .../gestor/configuracoes/integrações/sienge

Comportamento da integração

• O sistema passa a utilizar o valor configurado para paymentTypeId
• O envio respeita a estrutura existente no Sienge de cada cliente
• Caso necessário, o valor pode ser ajustado sem alteração de código

Impacto na operação

• Maior flexibilidade na integração
• Redução de erros no envio de credores
• Eliminação de dependência de valores fixos
• Menor necessidade de intervenção técnica

Pré-requisitos

• Integração ativa com o ERP Sienge
• Configuração do paymentTypeId conforme cadastro existente no ERP

O envio de reservas para o ERP Informakon agora passa a ser realizado com base na flag “Pode Faturar”, eliminando a dependência do processamento via cron a cada 5 minutos.

Por que isso é importante?

A melhoria traz dois ganhos principais:

• Envio instantâneo da reserva, sem necessidade de aguardar o cron
• Possibilidade de reenvio direto pela aplicação, sem depender de intervenção técnica

Antes, usuários precisavam abrir chamados para solicitar reenvio de reservas já enviadas, o que gerava atraso e sobrecarga operacional.

Como funciona agora?

• Ao passar pela flag “Pode Faturar”:
  • A reserva é enviada imediatamente para o ERP
• Caso necessário:
  • O usuário pode realizar o reenvio da reserva diretamente pelo sistema. Por exemplo, ao corrigir um dado na proposta, basta voltar a reserva para a etapa anterior e passar de novo pelo 'Pode Faturar'

Pré-requisitos

• Integração ativa com o ERP
• Utilização da flag “Pode Faturar” no fluxo de reserva

Agora é possível permitir que imobiliárias e corretores visualizem o checklist e as instruções das etapas no fluxo de comissões, por meio de uma configuração no workflow.

Por que isso é importante?

Antes, essas informações eram visíveis apenas para usuários com perfil de gestor, o que gerava:

• Falta de clareza sobre o andamento da comissão
• Dificuldade para entender próximos passos
• Erros ou atrasos em ações obrigatórias (ex.: envio de NF)
• Aumento de dúvidas e dependência de suporte

Com a melhoria, os participantes do processo passam a ter mais autonomia e entendimento do fluxo.

Como funciona?

Nova configuração no Workflow de Comissão

Foi criada uma configuração que permite ao gestor definir a visibilidade:

WF de Comissão → “Exibir checklist e instruções para imobiliárias/corretores”

Comportamento da configuração

Quando ativado

• Checklist visível para imobiliárias e corretores
• Instruções das etapas visíveis
• Usuários conseguem entender:
  • O que já foi realizado
  • O que ainda está pendente
  • Motivo da comissão estar na etapa atual
  • Próximos passos do processo

Quando desativado (padrão)

• Visibilidade mantida apenas para gestores
• Comportamento atual preservado

Pré-requisitos

• Workflow de Comissão configurado
• Permissão de acesso aos perfis envolvidos
• Configuração de visibilidade habilitada pelo gestor

Interface

• Checklist e instruções exibidos nas etapas da comissão

A API de Reservas passa a retornar o campo “Tipo de Reserva” nos endpoints de consulta, ampliando as informações disponíveis para integrações.

Por que isso é importante?

O campo já existia na interface do sistema, mas não estava disponível na API, limitando o uso completo das informações por sistemas externos.

Com essa melhoria, integrações passam a ter acesso ao tipo da reserva, permitindo maior consistência entre o CRM e aplicações integradas.

Como funciona?

Consulta de reservas (GET)

• O campo “Tipo de Reserva” passa a ser retornado nos endpoints de consulta
• Disponível junto aos demais dados da reserva

Pré-requisitos

• Consumo da API de Reservas
• (Opcional) Ajuste nas integrações para utilização do novo campo

Foram disponibilizadas duas novas variáveis para uso em contratos jurídicos, ampliando as possibilidades de personalização e controle das informações exibidas.

Por que isso é importante?

As novas variáveis permitem:

• Maior controle sobre a exibição condicional de informações no contrato
• Apresentação mais precisa do saldo devedor líquido, sem impacto de comissão
• Redução de ajustes manuais em minutas contratuais

Quais variáveis foram adicionadas?

Variável condicional com base em cálculo

[[SE][CALCULO][NOME_VARIAVEL][INTEIRO][INICIO]]
Digite seu texto
[[SE][CALCULO][NOME_VARIAVEL][INTEIRO][FIM]]

Essa estrutura permite exibir um trecho de texto no contrato somente quando o valor da variável for diferente de zero.

Regra de funcionamento

• Se o valor da variável informada for igual a 0 → o conteúdo não será exibido
• Se o valor for diferente de 0 → o conteúdo será exibido normalmente

Isso possibilita criar contratos mais dinâmicos e adaptáveis às condições da negociação.

Variável de saldo devedor líquido

[[SALDO_DEVEDOR_SEM_COMISSAO]]

Retorna o saldo devedor líquido, desconsiderando os valores de comissão.

Onde utilizar?

As variáveis podem ser aplicadas em:

• Contratos jurídicos
• Minutas personalizadas
• Documentos que utilizem variáveis dinâmicas do sistema

Pré-requisitos

• Modelo de contrato configurado para uso de variáveis dinâmicas
• Dados financeiros da proposta devidamente estruturados

A Listagem de Boletos foi ampliada para contemplar também os boletos do Avendre Pay, além da inclusão da funcionalidade de remoção de boletos diretamente pela interface.

Por que isso é importante?

Agora os usuários conseguem gerenciar boletos de forma mais autônoma, sem depender de intervenções técnicas (scripts), trazendo mais agilidade operacional e controle sobre os dados financeiros.

O que foi implementado?

Integração com boletos do Avendre Pay

A listagem passa a exibir também os boletos provenientes do Avendre Pay, centralizando a visualização em um único local.

Caminho:
Construtor → Desenvolvimento → CV → Gestor → Financeiro → Listagem de Boletos

Remoção de boletos pela interface

Agora é possível remover boletos diretamente na listagem, respeitando as seguintes regras:

• Apenas boletos não pagos poderão ser removidos
• A ação estará disponível conforme perfil de acesso (nova flag de permissão)

Comportamento da remoção

• Será enviado um evento de cancelamento para a pagadoria

Pré-requisitos

• Utilização do módulo Avendre Pay
• Permissão habilitada no perfil de acesso para remoção de boletos

Foi criada a nova variável [[FORMA_DE_PAGAMENTO_SUBTOTAL_CORRECAO_JUROS_COM_ADIMPLENCIA_LÍQUIDO]], que apresenta a condição de pagamento considerando valores líquidos, ou seja, descontando a comissão.

Por que isso é importante?

Essa variável permite que os contratos reflitam de forma mais precisa o valor efetivo da negociação, evidenciando os montantes sem o impacto da comissão.

Isso traz mais clareza para o cliente final e reduz a necessidade de ajustes manuais em documentos contratuais.

Como funciona?

A variável retorna a condição de pagamento completa, contemplando:

• Valor das parcelas (líquido de comissão)
• Subtotais das parcelas
• Correção monetária
• Juros aplicados
• Total geral da negociação (líquido)
• Inclusão da adimplência premiada no total, também de forma líquida

Regras de composição

• Todos os valores retornados são descontados da comissão
• Considera a estrutura completa da condição de pagamento
• Aplica correção monetária e juros conforme configurados
• Inclui o valor de adimplência premiada no total líquido
• Mantém o mesmo comportamento da variável original, alterando apenas a base de cálculo para valores líquidos

Observação

Essa variável é complementar à [[FORMA_DE_PAGAMENTO_SUBTOTAL_CORRECAO_JUROS_COM_ADIMPLENCIA]], permitindo escolher entre exibir valores brutos ou líquidos conforme a necessidade do contrato.

O webhook de tabelas de preço agora passa a incluir o campo Idempreendimento no payload das requisições enviadas.

Por que isso é importante?

Com a inclusão dessa informação, integrações externas conseguem identificar de forma direta a qual empreendimento a tabela de preço pertence, facilitando o processamento, organização e aplicação de regras específicas por projeto.

Como funciona?

• O campo Idempreendimento foi adicionado ao payload do webhook
• Ele será enviado junto às demais informações já existentes
• Representa o identificador único do empreendimento no sistema

Pré-requisitos

• Integração com webhook de tabelas de preço ativa
• (Opcional) Ajustes na integração para consumo do novo campo

A tela de comparação da reserva agora passa a exibir a tipologia da unidade, complementando as informações apresentadas ao usuário.

Por que isso é importante?

A inclusão da tipologia facilita a análise comparativa entre unidades, permitindo uma visão mais clara do perfil do produto (ex.: apartamento, sala comercial, etc.) durante a tomada de decisão.

Isso reduz ambiguidades e melhora a qualidade da análise comercial.

Como funciona?

• Ao acessar a tela de comparação da reserva
• Será exibida a tipologia da unidade junto às demais informações comparativas
• A informação é carregada automaticamente conforme os dados da unidade selecionada

Pré-requisitos

• Unidade com tipologia cadastrada
• Acesso à funcionalidade de comparação de reservas

Interface

• Nova informação de tipologia exibida na tela de comparação da reserva
  

Foi criado um novo pré-requisito de validação no Workflow de Reservas que exige a confirmação dos dados bancários antes de permitir a execução de determinadas ações no sistema.

Por que isso é importante?

A melhoria garante que operações financeiras sejam realizadas apenas com dados bancários validados, evitando inconsistências, falhas de pagamento e retrabalho operacional.

Validação de dados bancários

Antes de executar ações que dependem de informações financeiras, o sistema irá:

• Verificar se os dados bancários estão confirmados
• Considerar informações como:
  • Nome do titular
  • Chave Pix
  • Dados vinculados à empresa, corretor ou imobiliária

Exibição de modal obrigatório

Caso os dados não estejam confirmados:

• Será exibido um modal informativo ao usuário
• O aviso indicará claramente que é necessário confirmar os dados bancários para prosseguir
• A ação será bloqueada até que a confirmação seja realizada

Continuidade após validação

• Após a confirmação dos dados bancários
• O usuário poderá prosseguir normalmente com a ação desejada

Regras de aplicação

• A validação será aplicada de forma consistente em todos os fluxos que dependem de dados bancários
• Pode considerar a verificação de integração ativa com o módulo financeiro (ex.: Avendre Pay)
• Não deve haver impacto negativo na performance do sistema

Pré-requisitos

• Existência de cadastro de dados bancários
• Permissão de acesso para edição/validação dos dados
• Integração com módulo de reservas (quando aplicável)