From 15f53faa3339990a9b9f9a9b01eb2cc9f25e2b4a Mon Sep 17 00:00:00 2001 From: Gabriel Date: Wed, 26 Aug 2026 17:45:20 -0300 Subject: [PATCH] =?UTF-8?q?Corre=C3=A7=C3=A3o=20operadora=20Dental=20Uni?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- portal_api/planos_saude/CHANGELOG.md | 4 ++++ portal_api/planos_saude/pipeline.py | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/portal_api/planos_saude/CHANGELOG.md b/portal_api/planos_saude/CHANGELOG.md index 76e8477..f04a12f 100644 --- a/portal_api/planos_saude/CHANGELOG.md +++ b/portal_api/planos_saude/CHANGELOG.md @@ -250,3 +250,7 @@ Usuário reportou (competência 09/2026, empresa Questor 604, arquivo "COP GERAL Usuário reportou, testando a correção acima pela tela: depois de editar Valor/Valor Empresa numa linha, os contadores do topo ("com valor lançado"/"em auditoria") e a aba Alterações continuavam mostrando o estado de antes da edição, só atualizando de verdade depois de sair da importação e reabri-la. Causa: o handler de `change` das células (`importacao-plano-saude.js`) já mandava o PATCH pro servidor, mas nunca atualizava `importacaoAtual` nem chamava `renderTabs()` depois — diferente de toda outra ação da revisão (adicionar/remover linha, vincular pessoa, reverter alteração), que já recarrega a importação inteira e re-renderiza. Corrigido replicando o mesmo padrão: depois do PATCH ter sucesso, `importacaoAtual = await pidFetchImportacaoPlanoSaude(...)` seguido de `renderTabs()`. Aproveitando a mesma conversa, usuário pediu que as células de Valor/Valor Empresa aceitem uma expressão de soma/subtração digitada direto (ex.: `"15,30-15"` pra abater R$15 do valor, sem precisar calcular fora e digitar o resultado pronto). Implementado client-side: `pidAvaliaExpressaoValorMonetario()` reconhece números em formato BR (vírgula decimal, ponto de milhar opcional) separados por `+`/`-` e, se o texto digitado for uma expressão válida (sobra zero caractere não reconhecido), substitui o campo pelo resultado já calculado antes do PATCH — um valor negativo isolado (ex.: `"-15,30"`) continua sendo só um número, não uma expressão (só conta como expressão se houver operador depois do primeiro caractere). O backend não teve nenhuma mudança — `valor`/`valor_empresa` continuam sendo `CharField` sem validação de formato, então já aceitava (e continua aceitando) qualquer string; a expressão nunca chega até lá, só o resultado. + +### Bug real — código de cadastro da Dental Uni Odonto estava errado (1723 → 4723) + +Usuário avisou que o código de cadastro da operadora "Dental Uni Odonto" no Questor está registrado errado desde a Rodada 49 (`1723`); o código correto é `4723` — confirmado batendo com os arquivos reais de planilha padrão já salvos no sistema (nomes de arquivo trazem `OPER_4723_DENTAL_UNI...`). Corrigido `OPERADORAS["dental_uni_odonto_mensalidade"]["codigo_operadora"]` em `pipeline.py`; o label de exibição (`"4723 - Dental Uni Odonto"`) é derivado desse campo em todo lugar que usa `label_operadora()`/`lista_operadoras()` (combobox de operadora, mensagens de erro, `nome_operadora` de importação), então a correção já se propaga sozinha sem precisar tocar em mais nada. Registros já persistidos de importações antigas (`ImportacaoPlanoSaude.nome_operadora`, texto congelado no momento da criação) não são retroativamente corrigidos. diff --git a/portal_api/planos_saude/pipeline.py b/portal_api/planos_saude/pipeline.py index 0ff6f4d..e3cfa6d 100644 --- a/portal_api/planos_saude/pipeline.py +++ b/portal_api/planos_saude/pipeline.py @@ -46,7 +46,7 @@ OPERADORAS = { "parser": ItamedSaude, }, "dental_uni_odonto_mensalidade": { - "codigo_operadora": "1723", + "codigo_operadora": "4723", "nome": "Dental Uni Odonto", "parser": DentalUniOdontoMensalidade, },