Revo Mobilepainel do app

Dúvidas e homologação

Respostas ao QA de campo da v6

Revo Mobile 6.0.35 (60035) · medido na homologação em 11/09, tarde e noite, e no campo de 14/09 a 02/10 · relatório de campo do Eduardo, a demanda de fila offline e o retorno da noite de 09/09, tudo respondido item por item.

Os cinco itens do relatório original foram investigados um a um contra a homologação, com os romaneios liberados para teste. Três eram do app e estão corrigidos. Dois são do TMS — para esses o app ganhou o comportamento certo enquanto o servidor não muda: em vez de insistir para sempre e mentir na tela, ele para, guarda e avisa.A demanda de fila de envio e sincronização offline que chegou depois é o mesmo item 04 visto do outro lado. Ela também revelou um defeito do app, encontrado ao investigar e já corrigido.Depois disso veio um teste na 6.0.14 com mais três observações, na mesma noite: a cor do campo 01, um bairro duplicado e o cliente aparecendo como telefone. Duas eram defeito do app e foram corrigidas na 6.0.15.Em 11/09 chegou o schema real da baixa: o 500 que antes parecia culpa do TMS era o corpo que o próprio app mandava. Corrigido na 6.0.16.Na tarde de 11/09, com a homologação de volta, tudo foi medido de novo: o que o TMS passou bate com o servidor. Sobraram dois pontos do lado do TMS (idempotência repetida na baixa e a sessão de teste sem serviço) e três ajustes do app, que entraram na 6.0.18.O vídeo do teste de 11/09 mostrou a fila parada nos anexos. O defeito era do app: desde a 6.0.13, foto, assinatura e áudio não saíam do aparelho, e a tela registrava isso como "sem conexão". Está corrigido na 6.0.19, e o que ficou preso na fila sobe sozinho depois de atualizar.Na noite de 11/09 o TMS passou a devolver `servicoId` em cada documento da sessão — medido em 10 placas, 57 serviços, 57 com o id preenchido. Até aqui o app derivava o id do número do documento, e a baixa ia para um id que o TMS não reconhecia. A 6.0.20 usa o id do TMS e, como os ids gravados antes estavam errados, zera o banco do aparelho na primeira abertura. É isso que resolve o "4 de 8" que o Eduardo reportou: a contagem estava certa, o que sobrava era linha de romaneio antigo.Em 14/09 o Eduardo entrou na segunda e as coletas abertas de sexta não voltaram. O defeito era do app: a lista guardada no aparelho ao sair vencia em 12h, e o TMS não entrega de novo o que já entregou. Na entrega itinerante o motorista roda dias com a carga. A 6.0.21 mantém entrega e coleta pendente no aparelho sem prazo, até a baixa, inclusive quando o login é feito sem sinal.Ainda em 14/09 o teste da 6.0.21 achou dois pontos do app. Depois de finalizar e sincronizar o romaneio 747/26, sair e entrar de novo trazia de volta o romaneio já finalizado: a regra da 6.0.21 devolvia a cópia inteira quando o login era em até 12h. E o campo RG ou CPF recebia o ditado formatado como telefone, sem validação. A 6.0.22 nunca devolve serviço concluído — com tudo baixado o app abre limpo — e só aceita CPF com dígito verificador válido ou RG de 7 a 10 dígitos.Na conferência da coleta 2425 com o fornecedor, os anexos da baixa chegaram ao TMS, mas apareceram dois pontos do app. A assinatura ia com fundo transparente e podia ficar preta ao virar JPG, e uma foto tirada em 11/09 subiu três dias antes da baixa, sem ligação com ela. A 6.0.23 manda a assinatura com fundo branco, liga cada foto à baixa no momento em que é tirada e só envia o anexo depois que a baixa existe.O relatório de validação de 14/09 trouxe cinco itens, todos do app. O crítico: coleta nova só aparecia depois de sair e entrar. O combinado desde o início era o app consultar o romaneio em segundo plano, no mesmo processo que manda a posição do veículo, e isso não estava acontecendo — a consulta só rodava com a lista aberta. A 6.0.24 consulta alterações e romaneio novo junto com cada posição enviada, inclusive minimizado, na tarefa de segundo plano e ao voltar para frente. Os outros quatro: documento inválido agora avisa em vermelho no campo, sequências como 1234567 são recusadas, a tela de assinatura não sai com o gesto de voltar do iOS 26 e a fila não mostra mais o que já foi enviado.O relatório de 15 e 16/09 e as observações de 16/09 trouxeram o que faltava na fila de envio: ela listava só o que estava esperando, e não o romaneio. A 6.0.25 passou a espelhar o romaneio inteiro, mas isso trouxe o serviço sem baixa para dentro da fila como "aguardando baixa", e o vídeo de 17/09 mostrou o problema: sete entregas listadas antes de qualquer baixa. A 6.0.26 corrige: só entra na fila o que o motorista já baixou (aguardando envio, enviando, enviado, bloqueado ou erro), e o resumo do romaneio — baixados, sem baixa, no romaneio — fica num bloco à parte, separado da transmissão. A 6.0.26 também grava na auditoria, a cada sessão, quantos serviços vieram com número da coleta, janela, volumes previstos, peso, bairro e coordenada, por tipo de serviço, sem nenhum dado do serviço; é com isso que se confere se o TMS está mandando os campos da coleta. O áudio do ditado que a central recusava por tamanho (HTTP 413) passa a ser gravado em 16 kHz e reduzido no aparelho antes de subir; o que ficou preso na 6.0.24 é reduzido na próxima tentativa, sem reinstalar. O documento do recebedor só é validado quando é obrigatório: opcional deixa passar o que foi digitado, obrigatório recusa qualquer valor com até 6 dígitos. Na lista, a coleta mostra CL-número, volumes e horário, e o botão da ocorrência virou "Não foi possível coletar". A separação entre ocorrência administrativa e normal é do lado do TMS, pelo campo retornaHoje que o app já manda.A 6.0.27 fecha o que ficou de tela. O card do serviço atual na lista estava fora do protótipo: agora traz a faixa "COLETA · AGORA" ou "ENTREGA · AGORA", o CL na mesma linha dos documentos, seta para cima na coleta e para baixo na entrega, e "Bairro · Cidade/UF" com o bairro em cinza antes da cidade. No iPhone o botão de baixo ficava colado no indicador de início, e o login e a tela de serviço não encontrado tinham espaço duplo embaixo: a área segura de baixo passou a ser a maior entre a reserva do aparelho e a folga da tela, em vez da soma. Por dentro, cada assunto de tela ganhou um dono só — área segura, raiz com barra de status, rodapé, botão de ícone escuro e cabeçalho escuro — sem mudar pixel fora do combinado.Os vídeos de teste de 18/09 mostraram um RG inventado passando igual a um RG de verdade. A 6.0.28 passa a decidir o documento pelo tamanho: com 11 dígitos é CPF e confere os dois dígitos verificadores (vale também para a identidade nova, que usa o número do CPF); RG de 8 ou 9 posições tem o dígito conferido pela conta de SP e, quando não bate, o campo avisa "Confira o RG" sem travar, porque não existe uma conta de RG que valha para todos os estados e o campo não traz a UF. Quando o documento é obrigatório e está errado, o Continuar trava dizendo o motivo — faltam números ou o CPF não confere. Quando é opcional, não trava: o campo avisa e o documento fica de fora da baixa, em vez de subir um número que não é RG nem CPF. Tocar no microfone fecha o teclado. A 6.0.28 também mostra o prazo da coleta (coletarAte) no card, grava na auditoria quantos serviços vieram com esse campo e o tamanho de cada anexo enviado, e deixa de consultar em segundo plano romaneio que já foi encerrado.O vídeo de 21/09 mostrou o outro lado da mesma moeda: um RG correto recebendo "Confira o RG: o dígito não bateu". O RG de São Paulo tem 8 números mais o dígito, e quem digita só os 8 — que é o comum — tinha o oitavo número lido como se fosse o dígito. A conta não fechava e o alarme aparecia num documento certo. O erro de fundo é anterior à conta: RG não tem regra nacional. Cada estado emite do seu jeito, vários não têm dígito, e o campo é um só, "RG OU CPF", sem a UF. A 6.0.29 para de conferir dígito de RG. Ela recusa só o que não pode ser documento nenhum — vazio, menos de 5 números, número repetido ou sequência — e deixa passar qualquer RG, com dígito, sem dígito ou com X. Quando o que foi digitado tem exatamente 11 números e os dois dígitos do CPF não fecham, o campo avisa sem travar, porque pode ser RG de 11 posições. A auditoria das 176 baixas de 11 a 21/09 sustenta a mudança: nenhuma foi recusada pelo TMS por causa do documento — os 400 são de 11/09, no contrato antigo, e os 503/504 são indisponibilidade do servidor em 14 a 16/09. De 17/09 em diante, nenhuma falha. Conferência de documento contra a base de clientes só existe do lado do TMS; o app sozinho não tem como saber se um RG existe.

Para a API completa, veja o contrato. Para o panorama da v6, veja o guia. Para o histórico completo de builds, veja as atualizações.

6

Itens corrigidos

1

App pronto · falta serviço de teste

1

Depende do TMS

496

Testes automatizados · 0 falhas

123

Chamadas medidas em homologação

Resumo por item

#ItemFrenteSituação na 6.0.35
01Tipo de documento na lista de serviçosAppCorrigido — tipo 4 agora sai Minuta
02Coletas novas não chegam sozinhasApp + TMSApp pronto — rota nova responde 200; falta serviço de teste para ver a coleta chegar
03Mensagem de romaneio não encontradoAppCorrigido
04Baixas não transmitemAppCorrigido na 6.0.16 — corpo no schema do TMS
05Destinatário e endereço errados (minuta)TMSDado chega errado — app com defesa
—Fila de envio / sincronização offlineApp + TMSCorrigido na 6.0.16 — sobra o id de 6 documentos
—Remover natt:trueAppFeito — e não havia o que remover
→Cor do campo 01 na coleta (09/09 à noite)AppCorrigido na 6.0.15
→Bairro duplicado na tela (09/09 à noite)AppCorrigido na 6.0.15
→Cliente saindo como telefone repetidoTMSDado chega errado — app com defesa
→"4 de 8" na lista com romaneio de 4 entregasAppCorrigido na 6.0.20 — era linha de romaneio antigo no banco, não erro de contagem
→id do serviço na baixaTMS + AppResolvido — o TMS passou a mandar servicoId (57/57 medidos) e a 6.0.20 usa ele
→Alterações do romaneio com codigo 13TMSConfirmado com o fornecedor: só aceita data à frente da última sincronizada. O app ignora e segue — nada trava
→Coleta pendente sumiu depois do fim de semana (14/09)AppCorrigido na 6.0.21 — pendente fica no aparelho sem prazo, até a baixa
→Romaneio finalizado voltando depois de sair e entrar (14/09)AppCorrigido na 6.0.22 — serviço concluído nunca volta; tudo baixado abre limpo
→RG ou CPF formatado como telefone e sem validação (14/09)AppCorrigido na 6.0.22 — ditado limpo, CPF com dígito verificador, RG de 7 a 10 dígitos
→Assinatura com fundo preto no TMS (coleta 2425)AppCorrigido na 6.0.23 — PNG com fundo branco; assinatura refeita cita a mais recente
→Foto subindo antes da baixa, sem ligação com ela (coleta 2425)AppCorrigido na 6.0.23 — anexo nasce ligado à baixa e só sobe depois dela
→Coleta nova só chega depois de sair e entrar (validação 14/09, crítico)AppCorrigido na 6.0.24 — consulta em segundo plano junto com a posição, na tarefa de fundo e ao voltar para frente
→RG ou CPF inválido travava sem avisar (validação 14/09)AppCorrigido na 6.0.24 — mensagem em vermelho no campo
→1234567 e 123456789 aceitos como documento (validação 14/09)AppCorrigido na 6.0.24 — sequência e dígito repetido recusados
→Gesto de voltar do iOS 26 saindo da assinatura (validação 14/09)AppCorrigido na 6.0.24 — baixa e ocorrência sem swipe-back
→Fila listando o que já foi enviado como "Romaneio anterior" (validação 14/09)AppCorrigido na 6.0.24 — enviado some da fila; o resto mostra o cliente da baixa
→Fila de envio não espelha o romaneio (item 02 do relatório de 15-16/09)AppCorrigido na 6.0.25 — cada serviço do romaneio com o estado real e o resumo executados / pendentes / no romaneio
→Fila listando serviço sem baixa como "aguardando baixa" (vídeo de 17/09)AppCorrigido na 6.0.26 — só entra na fila o que já foi baixado; resumo do romaneio (baixados / sem baixa / no romaneio) em bloco à parte
→Campos da coleta (número, janela, volumes) não conferíveis pela auditoriaAppCorrigido na 6.0.26 — a auditoria conta, por sessão e por tipo, quantos serviços vieram com cada campo
→Áudio do ditado recusado pela central por tamanho (HTTP 413)AppCorrigido na 6.0.25 — gravado em 16 kHz e reduzido no aparelho antes de subir; 413 não trava a fila
→Documento opcional travando e obrigatório aceitando poucos dígitos (obs. 16/09)AppCorrigido na 6.0.25 — opcional passa sem validar; obrigatório recusa até 6 dígitos
→Coleta sem número, volumes e horário no card (obs. 16/09)AppCorrigido na 6.0.25 — CL-número, volumes previstos e janela no card; botão "Não foi possível coletar"
→Ocorrência administrativa vs. normal (obs. 16/09)TMSApp já manda retornaHoje na ocorrência; a classificação é do lado do TMS
→Card da lista fora do protótipo (faixa COLETA · AGORA, CL, setas, Bairro · Cidade/UF)AppCorrigido na 6.0.27 — card do serviço atual igual ao protótipo
→Botão de baixo colado no indicador de início do iPhone; espaço duplo no loginAppCorrigido na 6.0.27 — área segura de baixo é a maior entre a reserva do aparelho e a folga da tela; Android com botões não muda
→RG inventado aceito igual a RG de verdade (vídeos de 18/09)AppCorrigido na 6.0.28 — CPF com dígito verificador; RG de 8 ou 9 posições com o dígito de SP conferido, como aviso; obrigatório errado trava dizendo o motivo
→Documento opcional subindo do jeito que foi digitadoAppCorrigido na 6.0.28 — não trava, avisa no campo e fica de fora da baixa
→Teclado aberto cobrindo o Continuar durante o ditado (vídeos de 18/09)AppCorrigido na 6.0.28 — tocar no microfone fecha o teclado
→Prazo da coleta (`coletarAte`) fora do cardAppCorrigido na 6.0.28 — o card mostra o prazo quando ele vem; a auditoria conta quantos serviços vieram com o campo
→RG correto recebendo "o dígito não bateu" (vídeo de 21/09)AppCorrigido na 6.0.29 — o app não confere mais dígito de RG; barra só o impossível (vazio, menos de 5 números, repetido, sequência)
→Sem som ao tirar foto (relatório de 21/09)AppCorrigido na 6.0.30 — toda captura (coleta, entrega, ocorrência) toca um clique curto, que sai também com o aparelho no silencioso e sai igual no Android
→Coleta e romaneio novos chegando só com aviso visual (relatório de 21/09)AppCorrigido na 6.0.30 — um alerta sonoro toca quando o app recebe serviço novo, uma vez por lote
→Não dá para voltar da tela de foto para a leitura de NF-e (relatório de 21/09)AppCorrigido na 6.0.30 — a tela de foto ganhou a seta de voltar; dá para rever as notas e remover a bipada errada antes da baixa
→Nome e documento exigidos mesmo quando o TMS não exige (CL-2501, CL-2600, romaneio 765)AppCorrigido na 6.0.30 — o app lia a obrigatoriedade do documento de um lugar só e, na falta, exigia. Agora lê nos dois blocos e em qualquer grafia de chave, e a auditoria registra de qual chave veio cada obrigatoriedade
→Som da foto tocando em uma e pulando a seguinte (vídeo de 22/09)AppCorrigido na 6.0.31 — medido no vídeo: das 8 fotos o som saiu em 5. O app rebobinava e disparava no mesmo instante, e quando o disparo chegava antes do rebobinar tocava o fim do arquivo, que é silêncio
→Coleta única no romaneio e coleta inserida pela central chegando sem som (relatos de 22/09)AppCorrigido na 6.0.31 — o alerta passou a tocar no ponto onde o serviço novo é detectado, então vale também em segundo plano e com uma coleta só; antes duas rotinas guardavam o aviso sem tocar
→Nome, RG e assinatura ainda exigidos na 6.0.30, na coleta e na entrega (relatório de 22/09)AppCorrigido na 6.0.31 — o TMS confirmou em 22/09 que parâmetro inativo não gera a linha no JSON. O app lia a ausência como "exige"; agora lê como "não exige", e volta a exigir se o bloco da transportadora não chegar
→GPS continua ligado depois do último serviço e depois de desconectar (relatório de 29/09)AppCorrigido na 6.0.32 — o app mandava parar, mas conferia se o GPS estava ligado numa leitura antiga e concluía que já estava desligado. Agora confere na hora: para no último serviço baixado e ao desconectar
→Mensagem de "sem serviços" cortada no login (relatório Android de 30/09, item 01)AppCorrigido na 6.0.33 — a mensagem aparece inteira. O erro de concordância está no texto que o TMS envia e será corrigido lá
→Botão "Receber romaneio" (item 02)AppCorrigido na 6.0.33 — passa a "Receber serviços"
→Todo documento de viagem aparece como "Romaneio" (item 03)AppCorrigido na 6.0.33 — lista, fila, bipagem e perfil mostram tipo e número de cada documento: 1 RE, 2 MDF-e, 3 MDM, 7 RC, 9 MDO, conforme a tabela do TMS
→Código da transportadora com 2 dígitos não libera o "Continuar" (item 04)AppCorrigido na 6.0.33 — libera de 2 a 4 dígitos; o TMS já aceita 2
→Bipar: MDF-e e dois textos (item 05)AppCorrigido na 6.0.33 — saem o filtro MDF-e, o MDF-e da ajuda, o subtítulo e o texto do rodapé
→Texto do botão "Bipar QR do DANFE" (item 06)AppCorrigido na 6.0.33 — "Bipar código de barras ou o QR do DANFE"; a leitura já aceitava os dois
→Teclado cobre o campo Observação (item 07)AppCorrigido na 6.0.33 — a tela rola e o campo fica acima do teclado, também em nome e documento do recebedor e nos 44 dígitos
→Alterações do romaneio deixam de ser consultadas quando o TMS responde "romaneio não localizado" (romaneio 2401/26, 01/10)AppCorrigido na 6.0.34 — enquanto o romaneio tem serviço pendente, o app continua consultando as alterações mesmo com essa resposta. A resposta "não localizado" para romaneio recém-liberado está com o TMS
→Coleta dada como feita com 0 volumes conferidos (serviço 24478, 01/10)AppCorrigido na 6.0.34 — coleta feita não passa com 0 volumes; o app orienta usar "Não foi possível coletar". Coleta não realizada com 0 volumes passa a ser aceita pelo TMS
→Texto do botão do DANFE quebrando em duas linhas (02/10)AppCorrigido na 6.0.35 — opção 1: "Bipar código de barras do DANFE" numa linha, com o desenho do código de barras embaixo e sem a palavra QR, também na tela da câmera
→Conferir se o RG existe de verdadeTMSSó o TMS pode, contra a base de clientes — RG não tem dígito de regra nacional e o campo não traz a UF
O app está pronto para o novo teste, e a 6.0.35 já está disponível nas duas plataformas (bloco Comece a testar). O que continuar sem resolver depois dela é do lado do TMS, e está detalhado no bloco O que falta do TMS, com o que precisa acontecer.A demanda de fila de envio e sincronização offline que chegou depois é o mesmo item 04 visto do outro lado, e fecha junto com ele na 6.0.16 (bloco Fila offline).

→11/09 à tarde — a resposta do TMS, medida na homologação

Resposta recebida 11/09Medida 11/09 à tarde2 pontos em aberto

Status / previsão

Medido com a homologação de volta, com os corpos exatos que o app manda: 18 chamadas. O que o TMS passou bate com o servidor. Ficaram dois pontos do lado do TMS: a baixa com idempotência repetida devolve 500, e a sessão de teste está sem serviço, o que impede conferir o tipo 4 e os parâmetros novos (pedidos 10 e 11). A 6.0.18 (60018) trouxe os três ajustes que saíram dessa medição.
PontoO que o TMS definiuNo appMedido em 11/09
AlteraçõesRota nova, com o número do romaneio no query string/mobile/romaneio/{transportadora}/alteracoes?romaneio=&desde=200 em 2303/26 e 720/26. Romaneio que o TMS não localiza dá 400 codigo 13, e a 6.0.18 pula esse sem acusar falha
PosiçõesCorpo do swagger: transportadora numérica, lat/lon em textoAdotado, com ponto decimal200
Posição da baixaDecimal com ponto"-23.5505", não mais vírgula200 nas três baixas
codigoOcorrenciaÉ o ocorrenciaIdMobile, numéricoNumérico200 · baixaIds 8 e 9
coleta.documentos[].tipoPode ir escrito, NFE — na coleta só vale NF-e"NFE" escrito200 · baixaId 10. Chave de CT-e dá 400 codigo 58; a 6.0.18 recusa antes de enviar
Tipo 4É Minuta; MDF-e é o 2A tela mostra Minuta (antes, MD-e)Sem serviço na sessão de teste para conferir
ParâmetrosFotos de coleta e de entrega, telefone da centralLidos do bloco novoSessão devolve 400 codigo 7 — sem serviço
Anexo repetidoPassa a responder 409409 conta como já recebido409 · codigo 31
Ocorrência sem recebedorAjuste do lado do TMSO app segue mandando recebedor vazio; vale dos dois jeitos200 dos dois jeitos
Baixa repetida—409 conta como já enviada (6.0.18). codigo 23 depois de uma queda de rede também (6.0.19)500 · codigo 23 nos três reenvios com a mesma idempotência
recebedor.setorEm análiseFora do corpo até o TMS confirmar—

→11/09 — a baixa grava. O 500 era o corpo que o app mandava

Schema recebido 11/09Corrigido na 6.0.16200 em homologação: entrega, coleta e ocorrência

Correção sobre o que se dizia antes

Antes deste ajuste, o 500 da baixa foi atribuído ao TMS. Estava errado. O app montava o corpo pelo contrato publicado no swaggerhub — resultado em texto e executadoEm na raiz. O servidor lê resultado como objeto; recebendo texto, estourava um NullReferenceException. Com o schema real, a 6.0.16 grava.
POST /mobile/servicos/{id}/baixa — o mesmo serviço, antes e depois:
6.0.15 · HTTP 500
{
  "servicoId": "2495",
  "idempotencia": "1789…245",
  "resultado": "executado",
  "executadoEm": "2026-09-11T09:10:17-03:00",
  "posicao": { "lat": -23.55, … },
  "fotos": [{ "anexoId": "1789…246", … }]
}

resultado em texto: o servidor esperava um objeto
6.0.16 · HTTP 200
{
  "servicoId": 2495,
  "idempotencia": "1789…245",
  "resultado": {
    "executado": true,
    "ocorrencia": false,
    "executadoEm": "2026-09-11T09:10:17-03:00"
  },
  "recebedor": { "nome": "…", "documento": "…" },
  "posicao": { "lat": "-23,55", … },
  "fotos": [{ "seq": 1, "anexoId": 1789…246 }]
}

Validado em homologação com o corpo novo

CenárioServiçoResposta
Entrega com recebedor2416200 · baixaId 1
Coleta completa + 2 fotos + assinatura2440200 · baixaId 6 · anexos 200
Ocorrência (codigoOcorrencia 1)2443200 · baixaId 7
Ocorrência sem recebedor2443500 · codigo 15 — depois do ajuste do TMS já dá 200 (pedido 2)
O mesmo anexoId enviado de novo2440500 · codigo 31 — depois do ajuste do TMS já dá 409 (pedido 4)
As baixas de teste ficaram nos serviços antigos 2416, 2440 e 2443 (baixaIds 1 a 7). O serviço 2495, do teste de campo original, não foi tocado.

O log da auditoria

Uma dúvida recorrente é se o log da auditoria é o mesmo JSON do envio. Não é: era um resumo até a 6.0.15. Na 6.0.16 a auditoria passou a registrar o corpo exato que sai para o TMS, com nome e documento do recebedor mascarados, e os campos reais do multipart do anexo.

A fila que ficou presa

A fila guarda a baixa, não o JSON. Quem atualizou para a 6.0.16 teve o que estava preso por erro 500 reenviado já no corpo novo, sozinho. O que foi bloqueado por codigo 18 continua dependendo do pedido 1.

→Relatório de campo da noite de 09/09 — três observações na 6.0.14

Recebido em 09/09, à noiteDuas corrigidas na 6.0.15Uma depende do TMS

Status / previsão

O teste foi feito na 6.0.14 (60014) e as três observações procediam. Duas eram defeito do app e estão corrigidas na 6.0.15 (60015), com teste automatizado para cada uma. A terceira — o cliente saindo como um telefone repetido — é dado que chega errado do TMS: o app parou de imprimir a repetição, mas o nome de verdade continua não vindo.
O que foi vistoFrenteSituação na 6.0.15
Campo 01 da coleta saindo laranja em vez de azulAppCorrigido
Bairro repetido na tela do serviço da vezAppCorrigido
Cliente aparecendo como 11996720018 11996720018TMSDado chega errado — app com defesa

A · a cor do campo 01 (defeito do app, corrigido)

"Olha a cor do campo da coleta 16974, está laranja ao invés de azul."
Estava certo, e o defeito era do app — entrou junto com a correção do item 01, quando o campo 01 passou a mostrar sigla e número do documento. O componente novo nasceu com a cor fixa em laranja: uma coleta saía com o selo "COLETA · 4ª" em azul e, do lado, "Coleta 16974" em laranja, no mesmo card.
coleta = azul   ·   entrega = laranja
Na 6.0.15 o campo 01 herda a cor do tipo do serviço, igual à borda esquerda, à seta e ao selo. O resto das telas foi conferido em busca de outro lugar com a cor presa no código: era só esse.

B · o bairro duplicado (defeito do app, corrigido)

As duas capturas mostravam "Jardim Modelo" e "ESTADIO" aparecendo duas vezes no mesmo endereço. A 6.0.14 já tinha um freio para isso, mas cobria só uma das formas: quando o TMS manda o bairro sozinho no campo localComplemento. O caso novo é a outra forma — o bairro vem colado no fim do próprio endereço:
Campo do TMSValor que chegou
localEnderecoAVENIDA 23, 459 - ESTADIO
localBairroESTADIO
Como saía na telaAVENIDA 23, 459 - ESTADIO · ESTADIO
Como sai na 6.0.15AVENIDA 23, 459 · ESTADIO
O corte é conservador de propósito: só apaga quando o trecho inteiro é o bairro, ou quando o bairro está no fim atrás de um separador. Uma "RUA DA MOOCA" com bairro MOOCA continua inteira, porque ali o bairro é o nome da rua — esse caso tem teste próprio. A comparação ignora acento, caixa e pontuação, senão "JD. CRUZ ALTA" e "JD CRUZ ALTA" passariam como coisas diferentes.

Verificação

A regra nova foi testada contra os 14 documentos reais das duas capturas de homologação: 14 de 14 sem repetição, e a "RUA DA MOOCA" preservada.

O que ficou em aberto

Não foi possível reproduzir exatamente o registro original — o romaneio da captura tem 15 serviços, o de teste tinha 14, e os números dos documentos são outros. A correção cobre as duas formas que a duplicata pode chegar, por isso a confiança nela é alta; mas para confirmar no registro específico da coleta 16974, é preciso o número daquele romaneio, para puxar e conferir campo a campo.

C · o cliente saindo como um telefone repetido (TMS)

Na mesma captura o cliente aparece como 11996720018 11996720018. Isso não é a tela montando errado: é o campo destinatarioNome chegando com o telefone no lugar do nome, e repetido. É o mesmo sintoma do item 05 — bloco de destinatário preenchido com o dado errado na origem.O que dá para fazer do lado do app está feito na 6.0.15: quando o campo é o mesmo número duas vezes, imprime uma. O nome de verdade não tem como ser inventado — ele precisa vir preenchido no destinatarioNome.

Item a item, com o que foi pedido para confirmar

Busque por palavra, número do item ou trecho de mensagem de erro.

O que falta do lado do TMS

O app está pronto para o que depende só dele. Estes pontos precisam de uma mudança ou uma resposta do TMS para fechar.

Trava a baixa de parte dos serviços

Pedido 1Trava a baixa

Um identificador de serviço que a baixa aceite — publicado no romaneio

Dos 14 documentos, só 8 têm identificador que o TMS resolve. Os outros 6 (as NF-e e os CT-e, ex. 345198, 100256) dão codigo 18 para todos os campos publicados. Falta saber qual campo da resposta de sessão é o id que a baixa espera — ou que ele passe a vir.

Idem para o anexo: codigo 29 no mesmo cenário.

Defeitos da API já resolvidos ou em acompanhamento

Pedido 2Parcialmente resolvido

Ocorrência sem recebedor

Resolvido pelo TMS em 11/09, conferido às 12:33. Sem o bloco recebedor e com recebedor: null, os dois dão 200 (baixaId 18 e 19). O app segue mandando recebedor vazio.
Pedido 3Confirmação

O mesmo serviço aceita várias baixas

O 2416 recebeu os baixaIds 1 a 5, cada um com uma idempotência diferente. Medido de novo em 11/09 às 12:35: o 2440, já baixado, aceitou mais uma (baixaId 20). A equipe do TMS vai colocar a rotina.

Serviço com baixa executada: devolver 409 (ou 200) com o baixaId original. Serviço com ocorrência: continuar aceitando baixa nova, porque quem dirige volta e entrega. O app já conta 409 como enviada.

Pedido 4Parcialmente resolvido

Anexo repetido devolvia 500

Resolvido pelo TMS em 11/09. Mesmo anexoId de novo agora responde 409 · codigo 31, e o app conta como recebido.
Pedido 5Parcialmente resolvido

/alteracoes precisava aceitar número de romaneio com barra

Resolvido pelo TMS em 11/09 com a rota nova, número no query string (item 02). Medido: 200 em 2303/26 e 720/26.
Pedido 6Parcialmente resolvido

localComplemento precisa trazer o complemento, não o bairro

14 de 14 documentos, duas capturas, todos os tipos. Ver item 05.
Pedido 7Parcialmente resolvido

destinatarioNome precisa trazer o nome, não o telefone duplicado

Mesma origem do item 05.
Pedido 8Confirmação

Um contrato que bata com o servidor

O Swagger em /ApiMobile/swagger/docs/v1 está vazio, e o do swaggerhub divergia do servidor — foi essa divergência que gerou o 500 da baixa. Com o schema real o app se alinhou; se o Swagger da homologação publicar os modelos certos, isso não se repete na produção.

Pontos que o TMS confirmou

PontoO que o app faz hoje
posicao: separador decimalConfirmado em 11/09: texto com ponto ("-23.5505")
anexoId é Int64 (long)?Número de 16 dígitos gerado no aparelho
codigoOcorrenciaConfirmado em 11/09: o ocorrenciaIdMobile, numérico
Grafia do tipo do documentoConfirmado em 11/09: escrito, NFE; na coleta só vale NF-e
Anexo de áudiotipo: audio, com campo, transcricao e duracaoSeg a mais. Responde 200
recebedor.setorFora do corpo, porque não está no schema
Posições: corpoResolvido em 11/09 pelo swagger: placa, romaneio, transportadora numérica e as posições

Confirmação pendente

Pedido 9Confirmação

Confirmar se o TMS quer busca de romaneio em segundo plano

Hoje o segundo plano só envia; não busca. É decisão de projeto (bateria e dados de quem dirige) — com a confirmação, o app implementa.

Da medição de 11/09 à tarde

Pedido 10Trava a baixa

Serviço de teste para a placa ABC1020 na transportadora 999

A sessão devolve 400 · codigo 7 "Não existem serviços disponíveis para motorista e veículo". Sem serviço não dá para conferir o tipo 4, os parâmetros novos e o complemento, nem fazer um fluxo inteiro no aparelho.
Pedido 11Confirmação

Baixa com idempotência repetida devolvia 500

Mesma idempotencia de novo → 500 · codigo 23 "Não possível registrar a Baixa.", em 3 de 3 reenvios, com e sem mudança no corpo. Acontece quando a resposta se perde no caminho e o app reenvia — pedido de resposta 409 (ou 200 com o baixaId original), como no anexo.A 6.0.18 já trata o 409 como enviada. A 6.0.19 trata o codigo 23 como enviada quando a tentativa anterior caiu por rede, que é exatamente o cenário do reenvio. Fora desse caso a mensagem não diz que a baixa existe, e o app segue tentando — com o 409 do TMS isso fica exato.
Pedido 12Confirmação

Confirmar o significado do codigo 13 nas alterações

O 141/26 responde 400 · codigo 13 "romaneio não localizado". Foi entendido como romaneio encerrado, e a 6.0.18 pula esse caso sem acusar falha de sincronização — se o 13 puder significar outra coisa, é preciso avisar.

Comece a testar

Cinco itens estão corrigidos e são conferíveis sem depender de mais nada do lado do TMS — incluindo a baixa, que passou a gravar, e a cor do campo 01 e o bairro duplicado de 09/09. Os romaneios de teste foram liberados na noite de 11/09 e a medição rodou em cima deles. A build é a mesma para os dois ambientes: ela roteia para homologação sozinha quando a transportadora digitada no login é 999 ou 9999. A v6 roda só na homologação: no iPhone ela é distribuída pelo TestFlight e no Android pelo APK do Expo. A 6.0.35 não mexe no banco: quem atualiza da 6.0.24 em diante continua com o romaneio e a fila que tem no aparelho, e o áudio que ficou preso é reduzido e sobe sozinho.

Android · build 60035

APK do perfil preview do Expo
A distribuição é direta, fora da Play Store — que está fora do ar no momento por um erro de permissão da conta de serviço. Baixe o APK abaixo e, no aparelho, libere a instalação de fontes desconhecidas quando for pedido.

iOS · build 60035

TestFlight — envio automático
A 6.0.35 (60035) sobe para o App Store Connect sozinha quando a build termina. Quem for testar precisa mandar o e-mail Apple para entrar como testador — o convite chega na hora.

Credenciais da homologação

Transportadora
999
Motorista
334.***.***-65
Placa
ABC1020

Roteiro de teste

  1. Baixa — uma entrega com recebedor, uma coleta com fotos e assinatura e uma ocorrência: cada uma deve aparecer no TMS, e a fila zera.
  2. Auditoria da baixa — abrir a baixa na auditoria e conferir que o log é o corpo enviado, no schema do TMS.
  3. Tipo de documento — abrir a lista com os quatro tipos de documento e conferir campo 01 e campo 02 em cada card.
  4. Cor do campo 01 — numa coleta, o número do documento à direita sai azul, igual ao selo; numa entrega, laranja.
  5. Bairro duplicado — abrir o serviço da vez e conferir que o bairro aparece uma vez só no endereço.
  6. Romaneio não encontrado — entrar com um motorista sem romaneio e conferir o texto exato.
  7. Mensagem de sessão — entrar com transportadora errada e ver a mensagem real do TMS aparecer, em vez de "sessão expirada".
  8. Anexos — fazer uma coleta com foto, assinatura e áudio e conferir que a fila zera e os três aparecem no TMS. Quem tinha anexo parado na 6.0.18 vê a fila esvaziar sozinha depois de atualizar, ou na hora pelo botão TENTAR AGORA.
  9. Fila offline — pôr o aparelho em modo avião, fazer baixas com foto e áudio, reconectar, e observar que a fila não trava mais: cada item é tentado por si, e o que a central recusa aparece em vermelho, com o motivo.

O que ainda pode travar durante o teste

  • Baixa de serviço cujo id o TMS não localiza (codigo 18) — é o pedido 1.
  • Baixa que recebe 500 · codigo 23 sem ter caído a rede antes — é o pedido 11.
  • Qualquer item da lista, se a sessão de teste não tiver serviço — é o pedido 10.

O que mudou, versão por versão

6.0.35 (60035)

Versão atual
  • ColetaBotão do DANFE na opção 1 escolhida em 02/10: "Bipar código de barras do DANFE" numa linha só, com o desenho do código de barras embaixo e "jeito mais rápido". Sai a palavra QR, também na tela da câmera; o leitor continua aceitando QR se aparecer

6.0.34 (60034)

  • RomaneioQuando o TMS responde "romaneio não localizado" na consulta de alterações, o app só deixa de consultar aquele romaneio se ele não tiver mais serviço pendente no aparelho. Com serviço pendente, continua consultando e não perde alteração da central
  • ColetaColeta feita não passa com 0 volumes conferidos, nem com motivo de diferença. A tela orienta usar "Não foi possível coletar" quando não houver nada para coletar

6.0.33 (60033)

  • LoginA mensagem de erro aparece inteira, sem corte; o botão passa a "Receber serviços"; o código da transportadora libera com 2 dígitos
  • Documento de viagemA lista, a fila, a bipagem e o perfil mostram o tipo e o número de cada documento (ex.: MDF-e 2244/26 · RE 7744/26 · RC 1312/26), pela tabela do TMS: 1 RE, 2 MDF-e, 3 MDM, 7 RC, 9 MDO. Código sem sigla combinada mostra só o número
  • BipagemSaem o filtro MDF-e, o MDF-e do texto de ajuda, o subtítulo e o texto do rodapé. O botão da nota passa a "Bipar código de barras ou o QR do DANFE"
  • TecladoCom o teclado aberto, a tela rola e o campo em digitação fica visível: observação da ocorrência, nome e documento do recebedor e os 44 dígitos da nota
  • AuditoriaA abertura de sessão registra quantos serviços vieram com cada código de documento de viagem

6.0.32 (60032)

  • GPSO rastreamento para quando o último serviço do romaneio é baixado, mesmo com a transmissão pendente — o que já foi lido continua subindo, nada novo é lido. A auditoria mostrou o defeito em 24 e 25/09: posições gravadas até 20 minutos depois da última baixa. O app mandava parar, mas conferia o estado do GPS numa leitura feita na abertura, que dizia desligado, e não parava
  • GPSDesconectar para o GPS na hora, com ou sem serviço pendente. Fechar o app sem desconectar continua rastreando enquanto houver serviço pendente
  • GPSO rastreamento volta sozinho quando a central inclui serviço num romaneio já concluído, e para de novo quando ele é baixado. Antes, se o GPS já estava ligado na abertura do app, ele parava uma vez e não voltava
  • GPSO aparelho que ficou com o GPS ligado pela versão anterior é liberado ao abrir a 6.0.32, e a posição lida depois do desconectar é descartada — não sobe no login seguinte

6.0.31 (60031)

  • FotoO clique tocava em uma foto e pulava a seguinte. Medido no vídeo de 22/09: das 8 capturas o som saiu em 5, e falhou na 2ª, na 4ª e na 6ª. O app mandava rebobinar e disparar no mesmo instante; quando o disparo chegava primeiro, tocava o fim do arquivo, que é silêncio, e só depois o rebobinar chegava — por isso falhava alternado. Agora espera o rebobinar terminar e toca em todas
  • RomaneioO alerta de serviço novo passou a tocar no ponto em que o serviço é detectado, e não só na tela da fila. Isso cobre os dois casos relatados em 22/09: romaneio com uma coleta só, e coleta inserida pela central numa manutenção. Antes duas rotinas detectavam, guardavam o aviso e não tocavam — a que roda junto com o envio de posição, em segundo plano, e a que carrega a tela da fila, que ainda por cima descartava o contador
  • RecebedorNome, RG e assinatura deixam de ser exigidos quando o TMS está com o parâmetro desligado. O TMS confirmou em 22/09 que são dois parâmetros — obriganomerg, que vale para nome e RG juntos, e obrigaassinatura — e que parâmetro inativo simplesmente não gera a linha no JSON. O app já procurava essas duas chaves no lugar certo; o que ele lia errado era o silêncio, que tratava como "exige". Se o bloco da transportadora não chegar, ele volta a exigir os três, para não liberar a baixa sem comprovação por causa de uma resposta incompleta
  • AuditoriaA abertura de sessão passa a registrar também qual padrão foi aplicado quando o TMS não manda a obrigatoriedade, ao lado das chaves que vieram no bloco

6.0.30 (60030)

  • FotoToda captura toca um clique curto — coleta, entrega e ocorrência. O som vai dentro do app, então sai com o aparelho no silencioso e sai igual nas duas plataformas; o obturador do iPhone, que o botão lateral cala e que não existe no Android, fica desligado para não tocar em dobro
  • RomaneioColeta ou romaneio novo passa a avisar com som, além do aviso visual que já existia. Toca uma vez por lote, não uma por serviço
  • BaixaA tela de foto ganhou a seta de voltar. Quem bipou uma nota, avançou e percebeu que faltavam outras volta para a leitura de NF-e, remove a nota errada e segue — antes o único caminho era sair da baixa e perder o que tinha feito
  • RecebedorNome e documento deixam de ser exigidos quando o TMS diz que não são. O app lia a obrigatoriedade do documento de um lugar só (parametros.exigeDocumento) e, na falta, exigia; era a única das três sem campo legado de reserva. Agora as três são procuradas por padrão de chave, primeiro no bloco de parâmetros e depois no da transportadora, e o campo antigo obriganomerg vale para nome e documento
  • AuditoriaA abertura de sessão passa a registrar de qual chave veio cada obrigatoriedade e quais chaves o TMS mandou no bloco — nomes de chave e booleanos, nenhum dado de pessoa. Antes não dava para distinguir "o TMS mandou exigir" de "o TMS não mandou nada e o app exigiu por padrão"

6.0.29 (60029)

  • RecebedorO app não confere mais o dígito do RG. RG não tem regra nacional — cada estado emite do seu jeito, vários não têm dígito, e o campo é um só ("RG OU CPF"), sem a UF. O RG de São Paulo ainda tem 8 números mais o dígito, e quem digitava só os 8 recebia "Confira o RG: o dígito não bateu" num documento correto
  • RecebedorPassa a ser recusado só o que não pode ser documento nenhum: vazio, menos de 5 números, número repetido (11111111111) ou sequência (123456). Qualquer RG passa — com dígito, sem dígito ou com X no fim
  • RecebedorOnze números com os dígitos do CPF errados viram aviso, não erro: pode ser RG de 11 posições. O Continuar não trava por causa disso
  • AuditoriaLevantamento das 176 baixas de 11 a 21/09: nenhuma foi recusada pelo TMS por causa do documento. Os 400 são de 11/09, no contrato antigo, e os 503/504 são indisponibilidade do servidor em 14 a 16/09; de 17/09 em diante, nenhuma falha

6.0.28 (60028)

  • RecebedorO documento é lido pelo tamanho: 11 dígitos é CPF e confere os dois dígitos verificadores, o que cobre a identidade nova, que usa o número do CPF. RG de 8 ou 9 posições tem o dígito conferido pela conta de SP e, quando não bate, o campo avisa "Confira o RG: o dígito não bateu" sem travar, porque RG de outro estado segue outra conta ou não tem dígito. RG de 7 ou 10 posições continua conferido só no formato
  • RecebedorDocumento obrigatório errado trava o Continuar dizendo o motivo: "Faltam números no RG ou CPF" ou "CPF não confere". Documento opcional errado não trava: o campo avisa "Não é RG nem CPF: a baixa segue sem documento", o número fica de fora da baixa e não aparece na assinatura
  • DitadoTocar no microfone fecha o teclado, no recebedor e na ocorrência, e o Continuar fica à vista durante o ditado
  • ColetaO card mostra o prazo da coleta (coletarAte) quando ele vem na sessão, no romaneio e no serviço avulso
  • AuditoriaA sessão conta quantos serviços vieram com coletarAte e guarda amostras do valor recebido; o envio de cada anexo grava o tamanho em bytes, já reduzido
  • RomaneioRomaneio encerrado deixa de ser consultado em segundo plano até a próxima sessão aberta com sucesso

6.0.27 (60027)

  • ListaO card do serviço atual segue o protótipo: faixa "COLETA · AGORA" ou "ENTREGA · AGORA", CL na mesma linha mono dos documentos, seta para cima na coleta e para baixo na entrega, e "Bairro · Cidade/UF" em caixa de título, com o bairro em cinza antes da cidade
  • TelasNo iPhone o botão de baixo não fica mais colado no indicador de início, e o login e a tela de serviço não encontrado perdem o espaço duplo embaixo: a área segura de baixo passa a ser a maior entre a reserva do aparelho e a folga da tela, em vez da soma. No Android com botões nada muda
  • TelasCada assunto de tela passa a ter um dono só: área segura, raiz com barra de status, rodapé, botão de ícone sobre fundo escuro e cabeçalho escuro (a fila passa a usar o mesmo cabeçalho das etapas). Pixel idêntico fora de dois detalhes combinados: o botão de voltar da fila fica um pouco mais claro e responde ao toque, e o rótulo MENU ganha 0,005 de espaçamento

6.0.26 (60026)

  • FilaServiço sem baixa não entra mais na fila: só aparece o que o motorista já baixou, com o estado da transmissão (aguardando envio, enviando, enviado, bloqueado, erro). O resumo do romaneio — baixados, sem baixa, no romaneio — fica num bloco à parte, acima da lista, e não se mistura com a contagem do que está esperando envio
  • AuditoriaO resumo da sessão gravado na auditoria passa a contar, por tipo de serviço, quantos vieram com número da coleta, documento, janela, volumes previstos, peso, bairro, remetente e coordenada. Só contagem; nenhum dado do serviço vai para o registro

6.0.25 (60025)

  • FilaA tela espelha o romaneio inteiro: cada serviço vira uma linha com o estado real (pendente, na fila, enviando, enviado, erro, bloqueado) e o topo traz executados / pendentes / no romaneio. Serviço de romaneio anterior com baixa presa aparece marcado como tal. Romaneio concluído e tudo enviado limpa a lista e mostra a mensagem de concluído
  • ÁudioO ditado é gravado em WAV 16 kHz e reduzido no aparelho quando passa de 1 MB, ao enfileirar e de novo antes de cada envio. HTTP 413 da central vira "Arquivo grande demais para a central" e sai do rodízio sem travar o resto da fila. Áudio preso da 6.0.24 é reduzido na próxima tentativa, sem reinstalar
  • BaixaRG ou CPF só é validado quando o campo é obrigatório. Opcional deixa passar o que foi digitado; obrigatório recusa qualquer valor com até 6 dígitos, com ou sem X, e mostra "O CPF ou RG informado está incorreto"
  • ListaCard da vez da coleta com selo CL-número e a linha de documentos sem repetir o número da coleta. Cards da lista mostram CL-número, NF-e e janela de horário
  • BaixaBotão da ocorrência de coleta renomeado para "Não foi possível coletar"
  • ListaAlteração do TMS que remove um serviço já concluído no aparelho não mexe mais nos contadores "feitos" e "faltam X de Y"

6.0.24 (60024)

  • RomaneioAlterações e romaneio novo passam a ser consultados em segundo plano: junto com cada posição do veículo enviada (app aberto, minimizado ou fechado), na tarefa de fundo que envia a fila e ao voltar o app para frente. Coleta nova entra sozinha, sem sair e entrar. A reabertura de sessão no TMS respeita um piso de 3 min
  • RomaneioO que chega com o app fechado fica guardado e aparece na faixa de novos serviços ao abrir a lista
  • BaixaRG ou CPF inválido mostra "O CPF ou RG informado está incorreto" em vermelho no campo, ao sair dele, depois do ditado ou ao tocar em Continuar travado
  • BaixaSequências (1234567, 123456789), dígitos repetidos e CPF com dígito verificador errado são recusados
  • BaixaTelas de baixa e de ocorrência sem o gesto de voltar (swipe-back do iOS 26); a assinatura não perde o que foi feito
  • FilaO que já foi enviado não aparece mais na fila. Os demais itens mostram o cliente da baixa em vez de "Romaneio anterior"

6.0.23 (60023)

  • AssinaturaA imagem da assinatura sai em PNG com fundo branco. Antes o fundo ia transparente e, convertido para JPG no TMS, podia aparecer sobre fundo preto
  • AssinaturaAssinatura refeita na mesma baixa: a baixa cita sempre a mais recente, não a primeira gravada
  • AnexosFoto e prova de ocorrência já nascem ligadas à baixa em andamento, e só sobem para o TMS depois que a baixa existe no aparelho. Antes uma foto podia subir dias antes da baixa, sem referência a ela
  • AnexosAo abrir ou retomar a baixa, fotos e áudios do mesmo serviço que ficaram soltos ou presos a uma baixa descartada passam para a baixa atual e sobem junto com ela

6.0.22 (60022)

  • RomaneioServiço concluído nunca volta ao sair e entrar de novo, em qualquer prazo. Com o romaneio todo baixado o app abre limpo, esperando o próximo; se sobrou pendente, volta só ele. Substitui a regra das 12h da 6.0.21, que trazia de volta o romaneio já finalizado
  • BaixaO ditado do campo RG ou CPF deixa só os números (e o X do RG), sem o formato de telefone
  • BaixaDocumento do recebedor validado: CPF só com dígito verificador válido, RG com 7 a 10 dígitos. Valor inválido não conclui a baixa, mesmo quando o campo é opcional

6.0.21 (60021)

  • RomaneioEntrega e coleta pendente ficam no aparelho sem prazo, até a baixa, mesmo saindo do app e voltando dias depois. Antes a lista guardada no logout vencia em 12h, e o TMS não entrega de novo o que já entregou
  • RomaneioO que já foi baixado só volta se o motorista entrar de novo em até 12h, para a lista não acumular serviço concluído
  • LoginLogin sem sinal também abre a lista que está no aparelho, com aviso na tela
  • RomaneioA lista guardada é separada por motorista (transportadora, CPF e placa): outro motorista saindo no mesmo aparelho não apaga a de ninguém

6.0.20 (60020)

  • BaixaO id do serviço passa a ser o servicoId que o TMS devolve na sessão, em vez de derivado do número do documento. Medido em 10 placas: 57 serviços, 57 com o id preenchido
  • BancoNa primeira abertura da 6.0.20 o aparelho zera romaneio, baixa, anexo e fila gravados pelas versões anteriores, porque os ids antigos apontam para serviço que o TMS não reconhece. Roda uma vez só
  • ListaO "faltam 4 de 8" com romaneio de 4 entregas some junto: a contagem estava certa, o que sobrava era serviço de romaneio antigo ainda no banco
  • AnexosArquivo acima de 4190 KB (codigo 44) para de ser retentado — o arquivo não encolhe entre uma tentativa e outra, e insistir só enchia a fila
  • Anexoscodigo 60 depois de uma queda de rede conta como anexo já recebido, mesmo tratamento que o codigo 31 já tinha

6.0.19 (60019)

  • AnexosFoto, assinatura e áudio voltam a subir. Desde a 6.0.13, o envio era recusado dentro do próprio aparelho e aparecia como "sem conexão"
  • FilaBaixa com codigo 23 depois de uma queda de rede conta como já enviada; anexo cujo arquivo sumiu mostra o motivo
  • LogsFalha de rede grava o erro original junto de "sem conexão"

6.0.18 (60018)

  • BipagemNa coleta só entra chave de NF-e: modelo 55 e dígito verificador. CT-e ou MDF-e é recusado na hora
  • FilaBaixa respondida com 409 conta como já enviada
  • SincronizaçãoRomaneio com codigo 13 nas alterações é pulado: não segura a marca de "consultado até" nem mostra erro

6.0.17 (60017)

  • SincronizaçãoAlterações pela rota nova: /mobile/romaneio/{transportadora}/alteracoes?romaneio=&desde=
  • PosiçõesCorpo do swagger: transportadora numérica, lat/lon em texto com ponto
  • BaixaPosição com ponto decimal; codigoOcorrencia numérico; tipo do documento escrito (NFE)
  • Anexos409 do TMS conta como "já recebido"
  • Lista de serviçosTipo 4 aparece como Minuta; MDF-e (2) passa a existir
  • ParâmetrosBloco novo lido: fotos de coleta e de entrega e telefone da central
  • BipagemChips de MDF-e e Minuta

6.0.16 (60016)

  • BaixaCorpo no schema real: resultado como objeto, ids numéricos, posição em texto, recebedor sempre presente
  • AuditoriaO log passa a ser o corpo real enviado, com o recebedor mascarado

6.0.15 (60015)

  • Lista de serviçosCampo 01 herda a cor do tipo: coleta azul, entrega laranja
  • EndereçoBairro colado no fim do endereço também é cortado, com o nome de rua preservado
  • DestinatárioTelefone repetido no lugar do nome é impresso uma vez só

6.0.14 (60014)

  • Lista de serviçosDocumento principal por prioridade de papel; NF-e sempre no campo 02
  • SincronizaçãoFalha deixa de ser engolida; todos os romaneios da sessão são consultados; a marca de "consultado até" só avança com todos respondendo
  • LoginEnvelope de erro é lido antes de classificar o 401 — recusa de negócio deixa de virar "sessão expirada"
  • LoginTexto exato de "nenhum romaneio encontrado"
  • FilaRecusa permanente (18, 29) sai do rodízio e vira bloqueado, com motivo à vista
  • FilaErro de rede isolado não aborta mais a rodada; sinal é consultado ao aparelho
  • FilaTempo limite de 180 s para foto e áudio (era 45 s)
  • FilaFaixa vermelha honesta quando há item recusado
  • EndereçoComplemento igual ao bairro é descartado em vez de exibido
  • ParâmetrosCota de fotos separada por tipo de romaneio (coleta / entrega)
  • SessãonAtt removido do app — impossível enviar true

Revo Mobile · Grupo Aleff — resposta ao relatório de QA de campo de 09/09/2026 e ao retorno da mesma noite, atualizada com o schema da baixa, a resposta do TMS de 11/09 e as medições da tarde e da noite e os retornos de campo e de teste de 14/09 , a conferência da coleta 2425 com o fornecedor, o relatório de validação de 14/09, o relatório de 15-16/09, as observações de 16/09, o vídeo de 17/09, os vídeos de 18/09 o vídeo de 21/09, o relatório de ajustes de 21/09, o relatório e o vídeo de 22/09, o relatório de 29/09, o relatório Android de 30/09 e os retornos de 01/10 e 02/10 · versão 6.0.35 (60035) · 05/10/2026