Release de Produtos

Corrigir evolução para calcular o Juros simples quando marcada a flag

Identificou-se um problema ao ativar a opção de “juros simples” na evolução do contrato. Mesmo com essa opção marcada, a evolução do contrato não considerou o prorata de juros. O erro deixou de ocorrer a partir da versão 951.

Corrigir as interfaces 3040 e Risco de Crédito para que a soma das vértices apresente o mesmo valor do Saldo consolidado.

Foi identificado um problema em que o somatório dos valores das vertentes não coincidia com o valor consolidado nos arquivos 3040 e Risco de Crédito, conforme apontamento recebido.

Verificou-se que, em contratos com mais de 60 dias (quando a apropriação de rendas se inicia), o somatório das vertentes não correspondia ao valor apresentado no campo ‘Saldo consolidado’. Essa inconsistência gerava divergências e apontamentos do Banco Central.

Para corrigir essa situação se ajustou a lógica do sistema para garantir que o somatório dos valores das vertentes seja consistente com o valor consolidado nos arquivos 3040 e Risco de Crédito.

Essa correção foi implementada para assegurar a integridade e consistência dos dados, eliminando divergências apontadas pelo Banco Central.

Corrigir rotina de recomercializado no CorpWeb que não está mantendo o ctrprognum

Identificou-se uma inconsistência no CorpWeb em relação à manutenção de contratos para o mesmo imóvel, mesmo com a variável “Permite implantar mais de um contrato para o mesmo imóvel” (2ª aba Manutenção de Contratos) ativada. Nesse cenário, a rotina não estava mantendo o mesmo ctrprognum, resultando na transformação do contrato retomado.

Para solucionar esse problema, foi realizada uma correção na rotina de comercialização no CorpWeb. A implementação ajustou o comportamento da rotina para respeitar a variável de configuração mencionada, garantindo que a manutenção de contratos para o mesmo imóvel seja consistente, sem alterar o ctrprognum ao retomar um contrato. Essa correção visa evitar transtornos, especialmente na geração do anexo16, proporcionando uma experiência mais fluida e alinhada com as configurações definidas.

Corrigir duplicação de vendedores ao salvar a simulação de contrato

Ao tentar realizar uma liberação ao vendedor, o sistema apresentava uma mensagem de erro, impedindo a gravação da liberação.

O suporte identificou que a origem desse problema estava relacionada ao fato de um dos proponentes da operação ter o vendedor do imóvel como cônjuge. Isso resultava na duplicação do vendedor durante a gravação da simulação de contratos.

Para resolver essa questão, foi implementada a seguinte correção: O método responsável por salvar a simulação de contratos foi ajustado para não duplicar os vendedores quando um deles é mutuário/cônjuge do contrato. Essa correção assegura a consistência no processo de liberação ao vendedor, evitando mensagens de erro e permitindo a gravação adequada da liberação.

Corrigir emissão de recibo consolidado para considerar o pagamento parcial no cálculo das prestações vencidas

A rotina que retorna as prestações disponíveis para o cálculo do atraso (GetPrestacoesDisponiveis1) foi ajustada para fornecer corretamente o valor devido de uma prestação “Encargo” quando já existe um pagamento parcial. Essa correção visa garantir a consistência nos cálculos e evitar valores negativos nos registros correspondentes ao pagamento parcial do contrato mencionado..

Corrigir erro ao incluir dois movimentos contabéis no mesmo produto

Ao inserir um novo lançamento contábil no sistema, utilizando a funcionalidade SCCI > LANÇAMENTOS CONTÁBEIS > MONTAR MODELOS DE MOVIMENTOS > SELECIONAR MODELO > INCLUIR LANÇAMENTO, foi identificado que, ao utilizar o mesmo código de movimento (MOVIMENTO_CODMOV) e a mesma conta de débito (MOVIMENTO_CONTA_DEBITO), o registro mais recente estava sendo removido.

Foi corrigido o wtela:LancamentosdaContaDelta. Essa rotina, de acordo com o plano de testes, estava removendo o último registro cadastrado no momento da inclusão de um novo registro. Com essa correção, a exclusão indevida do último registro foi eliminada, garantindo a integridade e consistência dos lançamentos contábeis no sistema.

Corrigir diferença existentes nos relatórios de encargos a receber (AC35, AC37 e AC38) e a tela de atraso na competência

Ao realizar um batimento entre as informações presentes no AC35 (Encargos a Receber) e o atraso na carteira, existiam divergências em contratos antigos, alguns deles já finalizados. Notou-se que o relatório AC35 estava apresentando atrasos referentes a prestações muito antigas e já quitadas, o que não condizia com a realidade.

Foi corrigida a rotina contábil responsável por apurar os contratos sem efetivo atraso no fechamento. Agora, essa rotina identifica corretamente os contratos que não têm atraso real e realiza a correção nos campos pertinentes, eliminando assim as divergências entre o relatório AC35 e a situação atual dos contratos na aba documentos. Essa correção contribui para a precisão das informações de encargos a receber, proporcionando um retrato mais fiel da situação financeira dos contratos no sistema.

Corrigir o cadastro do município PIUMHI – MG

Um erro relacionado ao nome de um município cadastrado no SCCI, onde o município PIUMHI – MG estava incorretamente registrado como PIUI. Além disso, foi identificado que o código DIMOB associado a esse município estava zerado, enquanto deveria ser obtido a partir do menu ajuda do Programa Dimob, no grupo Instruções de Importação – Anexo A.

Para corrigir essas questões de forma definitiva e atender à solicitação do cliente, foram realizadas as seguintes implementações:

1. Correção do Nome do Município:
   O município PIUMHI – MG foi atualizado no sistema para refletir o nome correto, corrigindo a discrepância com a nomenclatura utilizada pelo cliente. Essa correção é agora parte integrante do arquivo de municípios distribuídos nas atualizações de versão do SCCI.
   
   
2. Atualização do Código DIMOB:
   O código DIMOB associado ao município foi corrigido e ajustado de acordo com as instruções obtidas no menu ajuda do Programa Dimob, no grupo Instruções de Importação – Anexo A. Isso assegura que o código DIMOB seja exibido corretamente para o município PIUMHI – MG.

Essas implementações proporcionam uma correção definitiva para o problema reportado pelo cliente, garantindo a precisão das informações relacionadas a esse município no SCCI.

Corrigir o número do Lote no relatório de dados cadastrais e histórico

Uma inconsistência na apresentação do número do lote no Relatório do Cadastro, onde, ao gerar o relatório, o N° de Lote estava sendo impresso com apenas 03 posições, cortando o último dígito.

Para solucionar esse problema, foi implementada a correção na demonstração do N° de Lote no Relatório de Cadastro (wtela/relCad). Agora, o N° de Lote é exibido corretamente com 04 posições, assegurando a representação integral do número do lote no relatório.

Corrigir a saldo a disposição (AC140) para contratos com término por outros

Alguns contratos apresentavam saldo a disposição mesmo após o lançamento do histórico de término por outros. Após a análise, foi constatado que o sistema não estava considerando as liberações feitas após esse histórico, o que resultava em divergências entre o relatório AC140 e as informações reais do contrato.

Foram realizadas as seguintes implementações:

1. Alteração no módulo contábil:
   A rotina contábil foi corrigida para continuar apurando o saldo de parcelas à disposição de contratos de construção (cad_tipoctr = 33), caso a variável de configuração ‘Utiliza controle financeiro e parcelas à disposição’ estivesse marcada e o contrato tivesse o status de término por Outros. Os saldos somente deveriam ser baixados quando houvesse efetuação da liberação da parcela.
   
   
2. Atualização do GMOVDIARIO:
   A rotina foi modificada para considerar as liberações de parcelas lançadas após a data do término por outros. Para contratos com FINRPA_STATUS igual a 4, o sistema passou a gerar as movimentações de liberação de parcelas e amortizar o saldo à disposição.

Corrigir cálculo de prazo a reduzir trazendo parcelas a mais, após informar o valor que deseja amortizar

Uma inconsistência no cálculo de amortização extraordinária no prazo apresentava um valor recalculado superior ao valor original informado. O valor deveria ser aproximado e menor ao informado pelo usuário.

A correção foi direcionada ao serviço “PostCalculaAM”, responsável pelo cálculo da amortização extraordinária. Essa correção busca assegurar que o cálculo da amortização extraordinária respeite as expectativas do usuário, gerando valores recalculados de forma coerente com a lógica financeira.

Verificar Bug Prestações Pagas – extrato com pagamento parcial – PRODUÇÃO V.948

Um erro na versão impossibilitou a efetuação de consulta dos pagamentos parciais nas prestações. O relatório de pagamento parcial estava sendo gerado vazio, o que levou à abertura dessa demanda.

A análise da situação indicou que a correção deveria ocorrer no método “RelPagamentoParcial” do programa “wtela”. Esse método é responsável pela emissão do relatório de pagamento parcial, disponível na opção “Prestações Pagas” na treeview lateral. O objetivo era garantir que os pagamentos parciais no contrato fossem adequadamente demonstrados no relatório gerado.

Verificar crítica ao calcular liberação de vendedores

Nas versões anteriores a 949 o preenchimento do campo “Conta para Crédito” na aba de inserção de contratos não era preenchido pois o sistema o preenchia automaticamente com 0, que é o default da tabela SQL. Na versão 949, esse comportamento foi alterado para inserir o valor -1. Essa mudança causou problemas na rotina GetNovaLiberacao, que verifica se o campo está preenchido ou vazio, comparando o valor com 0.

Para resolver essa inconsistência e padronizar o tratamento do campo foi executada para ajustar a rotina GetNovaLiberacao conforme a descrição acima. Essa alteração busca garantir que o condicional considere corretamente os valores inseridos, inclusive o -1, assegurando que o sistema reconheça a existência de tomadores mesmo quando o campo “Conta para Crédito” não é preenchido.

Corrigir rotina de efetivação de contrato do PASSIVO

O sistema apresentava uma crítica incorreta indicando que o contrato do Sistema de Retorno, correspondente ao contrato de financiamento, está em base de simulação do usuário supervisor, o que impede a implantação do contrato atual. No entanto, ao depurar um contrato, essa crítica não deveria ser apresentada, pois é um comportamento esperado.

A correção proposta foi ajustar a crítica indevida na efetivação de contratos (sim –> atv) para contratos do passivo (tipoctr=41). A ideia é permitir a efetivação da alteração, eliminando a crítica inadequada que está sendo apresentada.