Histórico

Android: HistoricFragment · HistoricStatusViewModelNew SituationDetailFragment · SituationDetailViewModelNew

Histórico de inspeções veiculares por apólice. Exibe status consolidados (aprovados, reprovados, expirados), permite agendar novo checklist e — desde a entrega de junho/2026 — ver a situação de cada veículo, trocar reboque e retificar o checklist, espelhando o módulo do msystem_web.

Novidade (junho/2026): a tela migrou do pipeline de "último checklist" (2 chamadas) para uma análise consolidada que roda o fluxograma de TODOS os veículos da apólice numa só rota — POST /v1/checklist/fluxogram/analyze — com paginação paralela. Junto vieram as ações Ver Situação, Troca de Reboque e Retificação.

Fluxo de Dados (análise consolidada)

Seleção de empresa e apólice

Dois dropdowns (AutoCompleteTextView): empresa e apólice. As apólices ativas vêm de GET /v1/policy?_active=true. A apólice selecionada (currentPolicyId) é usada nas ações de situação/retificação.

Análise do fluxograma (uma rota, todas as páginas)

POST /v1/checklist/fluxogram/analyze roda o fluxograma de todos os veículos da empresa/apólice e devolve o resultado já consolidado. Como o backend pagina, o app percorre todas as páginas em paralelo (analyzeAllPages com async/awaitAll, lotes limitados) até cobrir o count real — evitando 429.

Consolidação + ordenação por status

Os itens de todas as páginas são acumulados, os totais somados (AnalyzeTotals) e a lista é publicada ordenada por status. Motivos de reprovação saem de analyze.results.results[].content. O ApiProcessingDialog cobre o tempo da análise com opção de retry.

Contadores de Status

O HistoricAdapter calcula e emite via setOnStatusCountsChangedListener as seguintes métricas:

Campo no binding	Significado
`approvedCount`	Veículos com último checklist aprovado
`rejectedCount`	Veículos com último checklist reprovado
`expiredCount`	Veículos com checklist expirado (`expiration_days ≤ 0`)
`totalCount`	Total de veículos na apólice

Ações por Veículo

Cada card do HistoricAdapter expõe callbacks para o HistoricFragment:

Callback	Ação
`onItemClick(plate)`	Navega para agendar novo checklist com a placa como argumento.
`onSeeSituation(item)`	Abre o detalhe Ver Situação (`SituationDetailFragment`).
`onTrailerEdit(item)`	Abre o diálogo de troca de reboque (`dialog_trailer_swap`).
`onRectify(item)`	Abre o diálogo de retificação (`dialog_rectify_checklist`). Habilitado só se `canRectify`.

Ver Situação

O SituationDetailFragment + SituationDetailViewModelNew espelham o modal t=ver&action=situacao do web. Tudo sai de uma chamada: GET /v1/checklist/{id}?_policy={policy}. O ViewModel já enriquece cliente/solicitante/origem e mescla os itens das três listas de resultado, mantendo por item o registro mais recente (maior datetime):

result_checklist — resultado do checklist
result_term — resultado do termo
result_rectification — resultado da retificação

Mapeamento de status do item (mesma tabela do legado):

code	status	code	status
`0`	Não Verificado	`3`	OK
`1`	Não Instalado	`4`	Análise Humana
`2`	Com Problema	`9`	Não Aplicado

Quando o status é 2 (Com Problema), o status_type é traduzido: 0=Ausência do Alerta, 1=Alerta Contínuo, 2=Falha Comunicação, 3=Não Atua. Origem: I=Monisat, E=Externo.

Troca de Reboque

O diálogo dialog_trailer_swap permite alterar quais reboques são considerados no checklist do cavalo e reexecutar a situação (espelha reexecutarSituacaoReboque do web):

Reboques considerados

Parte de item.trailers (atuais) + item.availableTrailers (pool). A placa vem em trailers[].plate; quando vem só o id, é resolvida pelo pool available_trailers pelo mesmo id.

Busca por placa

Campo de busca chama searchTrailers(plate) → GET /v1/vehicles?_type=R&_limit=10&_plate=... (apenas reboques). A busca aceita placa antiga ↔ Mercosul via PlateUtils (ver abaixo).

Reexecução

reanalyzeVehicle(trailerIds) → POST /v1/checklist/fluxogram/analyze single-vehicle com o array trailers:[{id}]. O card do veículo é substituído na lista mantendo a ordenação por status (replaceItem).

Retificação

Habilitada apenas se o usuário tem a permissão 405 (hasRectifyPermission(), mesmo critério do web: perm 405 + rectification == true). Espelha o modal type=retificar:

POST /v1/checklist/{id}/rectify

Corpo: policy (apólice selecionada), company_id, trailers:[{id}] considerados e, opcionalmente, files:[{name, base64}] (documentos selecionados pelo rectifyFilePicker).

upload_warnings: o backend pode responder 200 com a retificação aplicada, mas falhar no upload de algum documento (ex.: erro do Elasticsearch). Esses casos vêm em upload_warnings[].name e precisam ser avisados ao usuário, não engolidos.

Erros do backend são extraídos de { "erros": [{ "erro": "…" }] } ou { "message": "…" } (ex.: "Checklist já retificado", "mais de 3 itens…").

Busca de Placa (antigo ↔ Mercosul)

O HistoricFilterDialog e a busca de reboques usam PlateUtils para tratar placa antiga e Mercosul como equivalentes. A 5ª posição alterna entre dígito (antigo) e letra (Mercosul) — ex.: MSM2020 ↔ MSM2A20. A normalização compara ignorando esse dígito/letra de posição equivalente, então o usuário acha o veículo independentemente do formato digitado.

Paridade iOS: equivalente PlateMatcher no app iOS. Mesma regra de equivalência de posição.

Endpoints

GET /v1/policy?_active=true

Apólices ativas da empresa para popular o dropdown. Campos v1: id, name. expiration_days vem como string — converter para Int antes de comparar.

POST /v1/checklist/fluxogram/analyze

Roda o fluxograma e devolve o status consolidado de TODOS os veículos da apólice. Paginado — o app busca todas as páginas em paralelo. Também usado em modo single-vehicle (com trailers) para reexecutar a situação após troca de reboque.

GET /v1/checklist/{id}?_policy={policy}

Detalhe completo de "Ver Situação" — cliente, solicitante, origem e itens (result_checklist / result_term / result_rectification).

POST /v1/checklist/{id}/rectify

Aplica a retificação (perm 405). Aceita reboques e documentos base64. Retorna message e, se houver, upload_warnings.

GET /v1/vehicles?_type=R&_limit=10&_plate=...

Busca reboques (_type=R) por placa para a troca de reboque. Convertido em TrailerInfo(id, plate).

Autenticação e SharedPreferences

Nome	Chave	Uso
`jwt_tokens`	`jwt_token`	Bearer JWT — fonte confiável para chamadas v1
`selected_company`	`company_id`	Empresa selecionada usada como filtro inicial
`DATA`	`perms_user`	JSON de permissões — contém `405` para habilitar a retificação

Aborto silencioso: se jwt_token ou company_id estiverem vazios ao abrir o fragment, a tela não carrega dados e não exibe erro. Verificar logs com tag HistoricDebug.

Versões do ViewModel

Classe	API	Status
`HistoricStatusViewModel`	Legado (`api.monisat.online`)	Comentado / desativado
`HistoricStatusViewModelNew`	v1 (`api.monisystem.com`)	Versão ativa
`SituationDetailViewModelNew`	v1 (`api.monisystem.com`)	Detalhe "Ver Situação"