Capítulo 04

OS, Garantia, RMA e Reteste

Ordem de serviço, garantia por IMEI, devolução (RMA) e o reteste de qualidade.

O iMportex é o ERP (sistema de gestão) da KL, atacado de iPhones usados: os aparelhos chegam do Paraguai (PY), passam pela triagem (avaliação inicial que dá uma nota de qualidade — a grade, de A a C, mais o combinado MIX), seguem pro Inventário e Estoque, são expedidos pra São Paulo (SP) e vendidos no atacado B2B — em reais (BRL) nas vendas de SP, em dólares (USD) nas vendas do PY.

Este capítulo cobre o pedaço do fluxo que cuida do conserto e do pós-venda:

  • OS (Ordem de Serviço) — o chamado que documenta um reparo, do defeito ao custo, aparelho por aparelho.
  • Mutirão — atalho pra fechar várias OS de uma vez, quando o defeito é repetido em muitos aparelhos.
  • Reteste — o controle de qualidade que confere o conserto antes do aparelho voltar pro estoque que pode ser vendido.
  • Qualidade (FPY) — o placar de quem conserta bem de primeira.
  • Garantia — quando um cliente que já comprou reclama de defeito dentro de 90 dias.
  • RMA — o canal mais amplo de devolução/troca/remessa reversa (inclusive de volta pro fornecedor).

Cada aparelho é rastreado pelo IMEI (o número de série único de cada iPhone — como um CPF do aparelho) e muda de status conforme passa por esses módulos.

Fluxo do módulo em 1 olhada

  1. Aparelho sai da Triagem com defeito (ou volta reprovado do Reteste) — status EM_TRIAGEM.
  2. Alguém abre uma OS em /os, vinculando o aparelho a um técnico (próprio ou parceiro) — o aparelho vira EM_ASSISTENCIA.
  3. O técnico registra o(s) serviço(s) executado(s) e a(s) peça(s) usada(s) no detalhe da OS — ou usa o Mutirão (/os/mutirao) pra fechar vários aparelhos do mesmo defeito de uma vez.
  4. Se o custo do reparo passar do limite configurado, a OS pausa esperando aprovação de ADMIN/GERENTE (fila /aprovacoes).
  5. O técnico marca "pronto" (quando ele não é também supervisor) — o Supervisor/Gerência confirma a conclusão, escolhendo a grade final do aparelho.
  6. O aparelho concluído vai pro Reteste — alguém que não foi quem consertou aprova ou reprova o serviço.
  7. Aprovado → vai pro estoque disponível (pronto pra expedição/venda). Reprovado → volta pra assistência, é liberado com defeito mesmo assim, ou é sucateado — o operador escolhe.
  8. O desempenho de cada técnico (quantos consertos passam de primeira, sem retrabalho) fica visível em Qualidade (FPY).
  9. Em paralelo, no pós-venda: o cliente aciona Garantia (até 90 dias da venda) ou abre um RMA (devolução, troca, defeito pós-venda, ou remessa reversa a fornecedor) — cada um decide o desfecho (crédito, troca, reparo), e o caminho de reparo reabre o ciclo de OS → Reteste de novo.

Fila de Ordens de Serviço

Fila de Ordens de Serviço

Pra que serve: tela central da assistência técnica — lista todas as OS (ordens de serviço, o chamado que documenta 1 reparo) abertas, em andamento e concluídas, com custo agregado, e é onde se abre uma OS nova pra um aparelho que está em triagem ou já em assistência.

Quem usa: ADMIN, GERENTE, FINANCEIRO, TECNICO_PROPRIO, SUPERVISOR_ASSISTENCIA, OPERADOR_SP e OPERADOR_PY — qualquer outro perfil é redirecionado pro Dashboard. O que muda por perfil: o KPI "Custo reparos" e a coluna "Custo Real" só aparecem pra quem tem permissão de ver valores em dinheiro (ADMIN/GERENTE/FINANCEIRO) — pros demais o dado nem sai do servidor (não é só escondido na tela). OPERADOR_SP só abre/conclui OS do tipo Parceira (assistência externa); OPERADOR_PY entra na lista porque é quem reabre OS quando um aparelho reprova no reteste.

Ações principais:

  • "Nova OS": formulário inline — escolhe o aparelho (só os que estão EM_TRIAGEM ou EM_ASSISTENCIA), o tipo (Própria = técnico da casa, Parceira = terceirizado), o técnico, defeito identificado, plano de reparo e custo estimado. Se o aparelho veio da triagem, defeito e plano já chegam pré-preenchidos.
  • "Mutirão (bipar)": atalho pra /os/mutirao.
  • Banner "Levas/redistribuições de assistência aguardando seu aceite": aparece quando alguém te mandou um lote de aparelhos fisicamente (leva, também chamada de handoff — um repasse físico registrado no sistema, com aceite de quem recebe). "Recebi ✓" registra o aceite e tenta abrir 1 OS por aparelho automaticamente; "Recusar" devolve o lote com motivo obrigatório (mín. 3 caracteres). Desde 19/09, essa OS já nasce com uma lista de itens (1 por defeito da pré-grade do aparelho) — é essa lista que o Mutirão usa pra saber o que ainda falta fechar (ver a seção Mutirão, mais abaixo).
    • Se algum aparelho do lote não conseguir abrir OS (ex.: mudou de status por outro caminho enquanto a leva estava a caminho), o aceite da custódia não é desfeito — o(s) aparelho(s) já estão fisicamente com você — mas a leva fica marcada como divergente em vez de "conferida" como se nada tivesse falhado (correção de 06/09: antes o sistema dizia "recebi os 5" mesmo quando só 4 ganharam OS, e o 5º ficava sem dono rastreável no sistema). A tela avisa quantos de fato abriram OS e lista, aparelho por aparelho, quem ficou de fora e por quê — abra a OS que faltou manualmente em "Nova OS".
  • Filtro por status, filtro por técnico, busca por IMEI/modelo.
  • Clique na linha abre o detalhe da OS.

Fluxo correto:

  1. Aparelho sai da triagem com defeito e aparece na lista de aparelhos elegíveis.
  2. Clique "Nova OS", selecione o aparelho — defeito e plano de reparo vêm pré-preenchidos da triagem.
  3. Escolha o tipo (Própria/Parceira) — a lista de técnicos filtra sozinha pelo tipo escolhido.
  4. Confirme "Abrir OS": o aparelho muda pra EM_ASSISTENCIA e você é levado direto ao detalhe da OS.
  5. Quando alguém manda um lote físico de aparelhos pro seu nome (leva), aceite pelo banner amarelo — isso abre 1 OS por aparelho sozinho.

Se pular ou errar: sem OS aberta, o aparelho fica parado em EM_TRIAGEM/EM_ASSISTENCIA sem ninguém sabendo que precisa de conserto. Tentar abrir OS pra aparelho em outro status (ex.: já vendido) é recusado com mensagem explicando a situação atual. Já existe OS ativa pro mesmo aparelho? Uma trava do próprio banco de dados impede a 2ª OS — a tela pede pra recarregar.

Detalhes e estados: status possíveis da OS: ABERTA, EM_ANDAMENTO, AGUARDANDO_PECA, AGUARDANDO_APROVACAO, CONCLUIDA, CANCELADA. Se a leva vier de uma redistribuição (o supervisor troca o técnico de uma OS já existente), o "Recebi ✓" não abre 2ª OS — reatribui a que já existe.

🔜 Vindo em breve, ainda não no ar: uma configuração avançada (desligada por padrão) vai passar a exigir que "Nova OS" só possa ser aberta a partir do aceite de uma remessa do Pacote (leva ou pedido) — hoje abrir OS avulsa por aqui continua liberado normalmente, sem exigir aceite de nada antes.

Detalhe da OS

Detalhe da OS

Pra que serve: tela de trabalho da OS individual — onde o técnico registra o que fez (serviço + peça), pede custo extra quando precisa, e onde a OS é concluída ou cancelada.

Quem usa: mesma lista de perfis da fila (/os). O que muda por perfil: TECNICO_PROPRIO e SUPERVISOR_ASSISTENCIA veem os custos desta OS (o que eles mesmos lançam — esconder o que a pessoa digita não faz sentido); OPERADOR_SP e OPERADOR_PY não veem nenhum valor em R$ aqui. Só ADMIN/GERENTE cancelam OS. "Concluir"/"Confirmar conclusão" só aparece pra quem tem permissão de fechar; se você é o técnico dono da OS e não é também supervisor/gerência, o botão vira "Marcar reparo pronto" — quem confirma de fato é sempre outra pessoa (controle de 2 atores).

Ações principais:

  • "Registrar serviço": escolhe 1 serviço do catálogo e o tempo gasto (minutos) — o custo de mão de obra é calculado sozinho no servidor (tempo × custo/minuto do técnico, ou o preço combinado com o parceiro).
  • "Registrar peça": escolhe 1 peça do catálogo e a quantidade — baixa do estoque automaticamente; se o estoque cair abaixo do mínimo, o dono é avisado.
  • "Solicitar custo extra": pede um valor adicional com motivo — se passar do limite configurado (padrão R$ 200), a OS pausa em AGUARDANDO_APROVACAO até ADMIN/GERENTE aprovar.
  • "Retomar OS": volta a OS pra EM_ANDAMENTO depois que o custo extra foi aprovado.
  • "Marcar reparo pronto" (técnico dono) / "Concluir OS" ou "Confirmar conclusão" (quem tem permissão de fechar): escolhe a grade final (pode ser diferente da pré-grade da triagem — isso é esperado depois de um reparo).
  • "Cancelar OS" (ADMIN/GERENTE): devolve o aparelho pra triagem com motivo.
  • "Devolver ao supervisor": o técnico dono (ou ADMIN/GERENTE/SUPERVISOR_ASSISTENCIA) devolve a OS com motivo — ela continua com o técnico até o supervisor remanejar ou assumir; não passa pra outro técnico sozinha.

Fluxo correto:

  1. Abra a OS pela lista.
  2. Registre todos os serviços necessários — cada um grava o custo de mão de obra na hora, de forma imutável.
  3. Registre as peças usadas em cada serviço.
  4. Se o custo passar do limite, espere a aprovação (ou peça pra ADMIN/GERENTE aprovar em /aprovacoes), depois clique "Retomar OS".
  5. Reparo pronto: técnico dono clica "Marcar reparo pronto"; supervisor/gerência confirma escolhendo a grade final. Se quem executa já é supervisor/gerência, o clique único já conclui.
  6. Ao concluir, o aparelho vai pro Reteste (padrão) — e some da fila desta tela.
  7. Se a OS é de uma garantia (aberta pelo caminho "Recolher e reparar" em /garantia), concluir aqui também resolve a garantia sozinho: soma o custo do reparo na margem da venda original e fecha o caso.

Se pular ou errar: concluir sem escolher grade final é bloqueado (campo obrigatório). Concluir ou cancelar com custo extra pendente de aprovação é recusado — aprove/rejeite primeiro. Cancelar só funciona em ABERTA/EM_ANDAMENTO (se estiver AGUARDANDO_APROVACAO, resolva o custo extra antes).

Detalhes e estados: o sistema registra data/hora e quem marcou "pronto" — é o controle de 2 atores: quem executa nunca é o único a aprovar o próprio serviço. Quando a OS é devolvida ao supervisor, o sistema só grava esse registro — ele não redistribui a OS sozinho, alguém precisa remanejar ou assumir. Custo de mão de obra e de peça são snapshot (foto congelada no momento do registro — se o preço da peça mudar no cadastro depois, o que já foi consumido não muda); só os totais agregados da OS são recalculados quando você adiciona mais itens. Existe um 2º destino pós-conclusão (direto pro estoque de SP, sem passar pelo reteste) — mas esta tela nunca oferece essa opção; ela só é usada pela tela de Assistência Externa, que fica no capítulo Recebimento, Triagem e Assistência.

⚠️ Faixa "OS REABERTA" — hoje NÃO aparece pra reaberturas novas (regressão de 19/09): quando um aparelho reprova no reteste e volta pra Assistência, a OS que você está vendo é a mesma de um reparo anterior, reaberta automaticamente (ver a seção Reteste, mais abaixo neste capítulo) — isso continua acontecendo de fato. Mas a faixa amarela "OS REABERTA — o aparelho voltou [N vezes]" só é desenhada quando a tela reconhece o texto gravado nas observações da OS, e a função que faz a reabertura mudou de formato em 19/09: passou a gravar "Novo ciclo: ..." em vez de "Reaberta: ...", e a tela continua procurando só pelo formato antigo. Resultado: toda reabertura feita a partir de 19/09 acontece de verdade (histórico e custo somam na mesma OS, do jeito descrito abaixo), mas a faixa amarela não aparece mais — a tela fica igual à de uma OS que nunca reabriu. Até isso ser corrigido, não confie na ausência da faixa pra concluir que a OS é nova: confira o histórico de observações da OS pra ver se ela já teve um reparo anterior.

⚠️ OS por item (19/09): quando a OS nasce de um aceite — o banner "Recebi ✓" desta tela, ou o aceite de um pedido do Pacote (tela do Pacote, capítulo de Assistência) —, ela carrega por baixo uma lista de itens, 1 por defeito. Essa lista não aparece aqui: quem trabalha e fecha os itens é o Mutirão (próxima seção). Se você usar "Registrar serviço"/"Registrar peça" desta tela numa OS desse tipo, o lançamento é gravado normalmente, mas os itens continuam "pendentes" até alguém passar pelo Mutirão (ou marcar "não fazer") — hoje isso não bloqueia nada (a trava só liga quando a configuração "serviço obrigatório" abaixo for ativada), mas evite misturar os dois caminhos na mesma OS pra não perder o controle do que já foi de fato feito. Numa OS aberta manualmente ("Nova OS" nesta tela), numa Garantia, num RMA ou numa Assistência Externa, essa lista de itens não existe — continua tudo exatamente como sempre foi.

Existe também um comando interno de regularização pra 2 situações raras achadas em auditoria: aparelho aceito fisicamente que ficou sem OS (corrida entre 2 aceites ao mesmo tempo, já corrigida) e OS aberta antes desta atualização sem nenhum item cadastrado. A regularização sempre cria os itens como pendentes — nunca inventa que um serviço já foi feito — e exige um motivo escrito; quem opera é ADMIN, GERENTE ou o supervisor de assistência, pela tela do Pacote (capítulo de Assistência), não por aqui.

🔜 Vindo em breve, ainda não no ar (3 configurações desligadas por padrão):

  1. Serviço obrigatório — hoje dá pra concluir uma OS mesmo sem nenhum item da lista executado. Ligada, concluir vai exigir zerar os itens pendentes (executando ou marcando "não fazer" cada um) ou ter pelo menos 1 execução registrada.
  2. Checkpoint do pacote — hoje, ao concluir, o aparelho sempre segue sozinho pro Reteste. Ligada, ele passa a esperar uma remessa própria confirmar a saída da assistência antes de seguir.
  3. Parcial fica na assistência — hoje, uma OS que termina com item pendente (um resultado interno chamado "desfecho parcial", que ainda não aparece nesta tela) sempre volta pro Pacote. Ligada, vai dar pra designar um técnico pra continuar com ela sem devolver.

Mutirão de reparo

Mutirão de reparo

Pra que serve: acelerador de fechamento de OS em massa. Fechar 1 aparelho na tela normal custa em torno de 13 toques em 3 telas — com dezenas de aparelhos do mesmo defeito na fila, isso vira uma enxurrada de cliques. Esta tela reusa exatamente as mesmas ações da OS normal (registrar serviço, registrar peça, marcar pronto, concluir); ela só empacota a sequência.

Quem usa: qualquer perfil que enxergue /os — a mesma trava que filtra a fila normal (técnico vê só as próprias OS; supervisor/gerência vê todas) filtra aqui também. Não tem item próprio no menu lateral — chega-se só pelo botão "Mutirão (bipar)" dentro de /os.

Ações principais: duas abas.

  • Bipar: bipa ou digita 1 IMEI e tecla Enter — resolve o primeiro item pendente desse aparelho (1 por defeito, na ordem em que a OS os criou) usando o padrão de defeito cadastrado (em Assistência › Padrões de reparo): aplica sozinho o serviço, a peça e o tempo do padrão, e usa a pré-grade da triagem como grade final. Se o aparelho tem mais de um defeito pendente, a bipada avisa "TEM MAIS N" com um botão "Fazer agora" pra cada um dos outros — clicar resolve aquele item na hora, sem bipar de novo nem abrir a OS. Em defeito de carcaça ou tampa, o "Fazer agora" também deixa escolher a cor nova do aparelho (opcional). Antes de tocar na OS, confere a trava manual do aparelho (o bloqueado do inventário) — aparelho travado é recusado ali, sem lançar serviço nem mão de obra (correção de 06/09: antes a pistola não olhava essa trava e fechava a OS mesmo assim, cobrando o conserto de um aparelho que alguém tinha travado por um motivo).
  • Liberar em lote: agrupa as OS abertas por modelo + defeito idênticos (ex.: "iPhone 14 · Vidro", 40 aparelhos de uma vez), o técnico informa 1 tempo pra todo o grupo, desmarca os que ainda não terminou, e libera o resto de uma vez (até 50 aparelhos por lote).

Fluxo correto:

  1. Abra /os/mutirao pelo botão dentro de /os.
  2. Fechar rápido 1 a 1: aba Bipar, bipe o IMEI, Enter, repete pro próximo.
  3. Fechar um grupo inteiro do mesmo defeito: aba Liberar em lote, abra o grupo, confira/edite o tempo sugerido, desmarque quem não terminou, clique liberar.
  4. Técnico puro (não supervisor/gerência): a bipada/lote marca a OS como pronta — o supervisor confirma depois. Supervisor/ADMIN/GERENTE: a bipada/lote já conclui a OS (move pro reteste).

Se pular ou errar: sem padrão cadastrado pro defeito exato do item, a bipada recusa e pede pra cadastrar o padrão (Assistência › Padrões) ou fechar aquele item pela tela normal (Detalhe da OS). Bipar um aparelho que não tem mais nenhum item pendente não cobra de novo — avisa "já não tem item pendente, nada foi cobrado de novo" (idempotente — repetir a ação não duplica o efeito). Aparelho bloqueado ou com custo extra pendente de aprovação nem aparece pra oferta em lote; na bipagem 1 a 1, bipar um IMEI bloqueado mostra "está bloqueado no inventário. Desbloqueie antes de fechar a OS pelo mutirão." — e para exatamente aí, sem lançar nada, mesmo que o resto do defeito bata certinho com o padrão cadastrado.

Detalhes e estados: teto de 50 aparelhos por lote (acima disso a operação pode demorar demais e falhar). A liberação do lote roda sequencial, aparelho por aparelho, de propósito — nunca em paralelo, pra evitar travar o banco quando muitos aparelhos são liberados juntos. A fila de itens de cada OS é por ciclo: toda vez que a mesma OS reabre depois de um reteste reprovado (ver a seção Reteste, mais abaixo), só os itens do ciclo atual aparecem pra bipar — os de um ciclo anterior já concluído ficam no histórico, fora da fila.

Reteste

Reteste

Também chamado de: liberar aparelho que voltou da assistencia, aprovar o conserto, validar reparo, aparelho em reteste, liberar do reteste

Pra que serve: controle de qualidade independente — confere o aparelho que voltou do conserto (ou que saiu direto da triagem sem precisar de reparo) antes de liberar pro estoque que pode ser vendido.

Quem usa: a própria tela não bloqueia nenhum perfil por redirecionamento — qualquer usuário logado consegue abrir. Mas só ADMIN, GERENTE, TECNICO_PROPRIO, OPERADOR_PY, TESTADOR e SUPERVISOR_ASSISTENCIA conseguem de fato aprovar/reprovar (os demais recebem erro ao tentar). No menu lateral só TESTADOR, OPERADOR_PY e SUPERVISOR_ASSISTENCIA têm o link — é o time que efetivamente testa. Trava extra: quem consertou o aparelho não pode aprovar/reprovar o próprio conserto — o sistema identifica o técnico da última OS e bloqueia com mensagem clara, obrigando outra pessoa a validar.

Ações principais:

  • Aprovar: manda o aparelho pro estoque disponível do Paraguai, reimprime a etiqueta (sem faixa de "em conserto") e grava o resultado do teste. A grade pode ser ajustada aqui (subir OU descer, desde 08/09) a partir do que a testadora observou de carcaça/tela (ou escolhida direto no seletor) — quem calcula é o servidor, nunca o que o navegador manda pronto.
  • Checklist marcando algo como falho bloqueia o Aprovar: hoje, se qualquer item do checklist do reteste for marcado como falho ("NOK"), o botão Aprovar trava — mesmo um defeito puramente cosmético, vendável do mesmo jeito, obriga a usar Reprovar. Essa regra nunca tinha sido explicada aqui, e já gerou chamados reais de gente achando que o sistema "só deixa reprovar".
  • Reprovar: exige uma nota curta (mín. 3 caracteres) do que ainda está errado e escolhe 1 de 3 destinos:
    • Assistência — reabre pra reparo. Ao escolher esse destino, abre um modal "Reprovando por quê?": escolha o defeito numa grade de padrões de reparo (a mesma grade de Assistência › Padrões) ou toque em "Outro" e descreva em texto livre — esse defeito é o que estrutura a reabertura e vai pra etiqueta nova. Pra esse destino, a nota curta do campo principal vira opcional (os outros dois destinos continuam exigindo nota). O sistema não cria uma OS nova: reabre automaticamente um novo ciclo na MESMA OS do reparo anterior (o custo do 2º reparo soma no mesmo aparelho, e o FPY continua vindo da tabela de retestes, não da OS), grava o motivo nas observações da OS, e cria uma ficha de triagem nova com o defeito escolhido agora — é essa ficha nova que faz a etiqueta sair com a faixa RMA e o problema atualizado (sem ela, o papel continuaria mostrando o defeito antigo). Sem uma OS concluída anterior pro aparelho (caso raro), o sistema não inventa uma OS — nesse caso, abra manualmente pela tela de Ordens de Serviço.
    • Liberar mesmo com defeito — manda pro estoque mesmo reprovado (defeito cosmético considerado aceitável pelo operador). A grade também pode ser ajustada aqui, do mesmo jeito que no Aprovar.
    • Sucata — descarta o aparelho; só ADMIN/GERENTE podem escolher esse destino.

Fluxo correto:

  1. Aparelho concluiu a OS (ou saiu direto da triagem) e aparece na fila de Reteste.
  2. Testador confere o aparelho físico contra a tela: modelo, capacidade, cor, grade, o que foi reparado, quem reparou.
  3. Tudo certo: Aprovar (ajusta a grade se for o caso).
  4. Ainda tem problema: Reprovar, escreva a nota, escolha o destino. Se descer a grade, escreva também o motivo do rebaixamento (mín. 10 caracteres, obrigatório) — o botão fica bloqueado até o texto existir.
  5. Escolheu "Assistência": a OS anterior reabre sozinha (novo ciclo) e uma ficha nova de triagem é criada com o defeito escolhido agora — o aparelho fica esperando o recolhimento do lote de volta rumo à assistência (não pula na hora pra bancada, ver "Detalhes e estados" abaixo), já com o papel pronto dizendo o defeito de AGORA, não o de dias atrás.
  6. Cada julgamento fica registrado (quem testou, quem reparou, resultado) — alimenta a tela de Qualidade (FPY).

Se pular ou errar: não tem como um aparelho ir pro estoque disponível a partir do status de Reteste sem passar por aqui. Tentar reprovar um aparelho que não está nesse status é recusado (trava de origem) — fecha o caminho que permitiria sucatear qualquer aparelho disponível chamando a ação diretamente, sem passar pelo reteste de verdade. Descer a grade sem escrever o motivo (ou com menos de 10 caracteres) é bloqueado — subir ou manter a grade não pede motivo nenhum.

⚠️ Reprovar pra Assistência quebra de novo pra SUPERVISOR_ASSISTENCIA e TECNICO_PROPRIO (regressão de 19/09). O banco autoriza seis perfis a registrar reteste — ADMIN, GERENTE, TESTADOR, OPERADOR_PY, TECNICO_PROPRIO e SUPERVISOR_ASSISTENCIA. Em 10/09 isso foi corrigido pra valer (ver a história abaixo). Mas em 19/09, ao trocar a função que reabre a OS por uma nova (que agora também controla o ciclo de itens por defeito), a lista de perfis liberados voltou a ter só quatro — TESTADOR, OPERADOR_PY, ADMIN, GERENTE — copiando sem querer a versão antiga e já corrigida do gate. Resultado: hoje, se SUPERVISOR_ASSISTENCIA ou TECNICO_PROPRIO reprovar escolhendo "Assistência", o aparelho já saiu do Reteste (esse passo roda antes e não é desfeito) e a OS falha ao reabrir — o aparelho fica sem OS ativa e sem reteste registrado, precisando de correção manual. Até isso ser corrigido, só ADMIN, GERENTE, TESTADOR e OPERADOR_PY devem reprovar pra "Assistência"; se SUPERVISOR_ASSISTENCIA ou TECNICO_PROPRIO precisar reprovar um aparelho, peça pra um desses quatro perfis fazer.

Vale registrar a história completa, porque já foi um vaivém: a correção de 10/09 (que fez a reabertura da OS passar por uma função com privilégio do sistema) primeiro liberou só quatro perfis, com a justificativa de que eram "os mesmos que operam a tela de reteste". Não eram — corrigido no mesmo dia pra espelhar os seis perfis que o banco deixa registrar reteste. Foi essa correção de seis perfis que a mudança de 19/09 perdeu ao trocar de função.

⚠️ Atenção: "Liberar mesmo com defeito" não significa aprovado — é o oposto: o aparelho reprovou no teste, mas foi liberado assim mesmo por decisão do operador. O rótulo já se chamou "Estoque pronto" antes e foi trocado exatamente porque confundia — em toda outra tela "pronto" significa "passou no teste"; aqui é o contrário.

Detalhes e estados: status de origem = RETESTE (o que aparece na fila desta tela). Reprovar pra Assistência não muda o status pra "Em assistência" na hora — o aparelho continua com status Reteste, só muda de localização interna (fica esperando alguém recolher o lote de volta rumo à assistência, mesmo circuito do Pacote descrito no capítulo de Assistência); é normal, olhando a ficha do aparelho, ver "Reteste" por um tempo antes dele reaparecer trabalhável em /os. Reprovar pra Liberar mesmo com defeito manda pra DISPONIVEL_PY (reusa a mesma ação da aprovação normal); pra Sucata manda pra SUCATA (descarte — sai dos números de estoque, mas o custo histórico gravado não é apagado, só deixa de contar como estoque vivo). Toda mudança de grade no reteste (subida ou rebaixamento) fica registrada em grade_alteracoes com autor, data e motivo — a ficha do aparelho lê esse histórico. Um rebaixamento também dispara um aviso pro sino de notificações da empresa, pra gestão saber que um aparelho piorou de grade depois do reparo.

🔜 Vindo em breve, ainda não no ar: três mudanças planejadas pro Reteste, nenhuma delas vale hoje. (1) A regra "qualquer item falho bloqueia o Aprovar" vai afrouxar — só iCloud/MDM (indício de fraude, aparelho possivelmente roubado) vai continuar bloqueando de verdade; os demais itens marcados como falho vão liberar o Aprovar com um modal de confirmação explícita em vez de travar sozinho. (2) Vai nascer um atalho "Bateria errada? Corrigir aqui" dentro do próprio card do Reteste, pra corrigir a % de bateria que vai pra etiqueta sem precisar sair da tela e ir em /inventario/<IMEI>. (3) Uma configuração avançada (desligada por padrão) vai passar a exigir chegada confirmada da remessa — e nenhuma divergência aberta — antes do aparelho aparecer na fila de Reteste; hoje a fila mostra todo mundo, sem esse filtro extra. Enquanto isso não for publicado, use os caminhos exatamente como estão descritos acima.

Corrigir defeito (sem reabrir a triagem)

Também chamado de: adicionar defeito, tirar defeito, defeito que a triagem não viu, corrigir defeito no DNA do aparelho

Pra que serve: ajusta a lista de defeitos de um aparelho já triado sem devolver ele pra triagem do zero. Fica na ficha do aparelho (/inventario/<IMEI>, botão "Corrigir defeito") — não dentro do Reteste nem da OS —, mas o efeito de uma correção aparece aqui: um defeito adicionado que bloqueia a venda manda o aparelho de volta pro Pacote, reentrando no mesmo circuito da Assistência sem passar pela triagem inteira de novo.

Quem usa: ADMIN, GERENTE, OPERADOR_PY, SUPERVISOR_ASSISTENCIA e TESTADOR.

Ações principais:

  • Adicionar defeito: escolhe um defeito na mesma grade de padrões de reparo ou "Outro" (texto livre, até 200 caracteres), escreve o motivo (mín. 3 caracteres — ex.: "testadora viu na bancada, ficha da triagem não tinha") e confirma. Não pede senha/PIN do dono (diferente da ferramenta de devolver pra triagem) — a correção fica registrada em nome de quem fez, com data e hora.
  • Remover defeito: mesma grade, pra tirar um defeito que não deveria ter entrado.

Fluxo correto:

  1. Abra a ficha do aparelho pelo IMEI.
  2. Clique "Corrigir defeito" → escolha Adicionar ou Remover.
  3. Escolha o defeito na grade (ou "Outro") e escreva o motivo.
  4. Confirme — se o aparelho estava disponível pra venda e o defeito adicionado bloqueia a venda, ele sai da venda e vai pro Pacote automaticamente, com aviso na tela.

Se pular ou errar: sem escolher um defeito, ou com "Outro" escolhido e o texto em branco, o botão de confirmar fica desabilitado. Sem motivo (mín. 3 caracteres), idem.

Detalhes e estados: quando a ação é Adicionar, a correção também grava um evento interno ("defeito que a triagem não viu") — é matéria-prima pra auditoria de qualidade da triagem, sem efeito visível nesta tela.

Paradeiro (consulta em lote)

Pra que serve: responde rápido "cadê esse(s) aparelho(s)?" pra uma lista de IMEIs de uma vez, sem abrir ficha por ficha. Mostra a etapa exata do aparelho dentro do circuito (16 etapas possíveis — ex.: "Assistência · com o técnico", "Reteste · aguardando teste", "Reteste · reprovado, aguardando pacote"), quem está com ele agora, o que falta pra ele andar, e há quanto tempo está parado ali.

Quem usa: ADMIN, GERENTE, OPERADOR_PY, OPERADOR_SP, SUPERVISOR_ASSISTENCIA, TESTADOR e TECNICO_PROPRIO — praticamente qualquer perfil que já bipa ou acompanha aparelho no dia a dia.

Ações principais:

  • Cole ou bipe uma lista de IMEIs (1 por linha, ou separados por espaço/vírgula/ponto-e-vírgula) e clique em consultar.
  • "Exportar CSV": baixa a tabela pra planilha.
  • Clique no IMEI de uma linha pra abrir a ficha completa daquele aparelho.

Fluxo correto:

  1. Abra /paradeiro.
  2. Cole ou bipe os IMEIs que quer localizar.
  3. Consulte — a tabela mostra 1 linha por IMEI, na mesma ordem em que foram colados (nunca reordena nem junta duplicados: IMEI repetido aparece repetido).
  4. Precisa agir em algum aparelho? Clique nele pra abrir a ficha — esta tela é só consulta, sem ação em lote (nem criar pedido, nem mover, nem devolver nada por aqui).

Se pular ou errar: IMEI que não existe no sistema aparece na tabela como "Não encontrado" (nunca é omitido da lista). Tentar consultar sem colar nenhum IMEI é bloqueado com aviso.

Detalhes e estados: aparelho antigo que ainda não passou pela etapa fina (recurso das Fases 55/56) cai num modo mais simples: mostra o status básico (ex.: "Em triagem") em vez da etapa detalhada, e "há quanto tempo" conta desde a entrada no sistema em vez de desde a última mudança de etapa.

Qualidade — FPY por técnico

Qualidade — FPY por técnico

Pra que serve: placar de FPY (First Pass Yield — a taxa de reparos que passam no reteste já na primeira tentativa, sem precisar refazer) agrupado por técnico. Quanto maior o FPY, menos retrabalho esse técnico gera.

Quem usa: desde a Fase 35 (15/09), só ADMIN, GERENTE e SUPERVISOR_ASSISTENCIA — qualquer outro perfil (inclusive o próprio técnico avaliado) é bloqueado ao tentar abrir a página. Antes disso a tela só checava login (qualquer perfil logado via o desempenho individual nominal de cada técnico); a correção fechou isso porque é o mesmo tipo de dado do Placar de Grade, que já era restrito a esse trio. Se um técnico quiser saber o próprio FPY, precisa pedir pra um desses três consultarem. Não tem item próprio no menu lateral; chega-se pelo link "Qualidade (FPY)" dentro de /reteste (e volta por "← Reteste").

Ações principais: só leitura — nenhum botão de ação. Tem um filtro de período (7/30/90 dias ou um dia específico) e técnico, igual ao do Painel da Assistência. Mostra o FPY geral do período filtrado e uma tabela por técnico (aprovados / reprovados / total / % FPY), ordenada do pior FPY pro melhor (quem precisa de mais atenção aparece primeiro).

Fluxo correto:

  1. Abra pelo link dentro de /reteste.
  2. Ajuste o filtro de período/técnico se quiser um recorte específico.
  3. Veja o FPY geral no topo.
  4. Olhe a tabela por técnico — quem está no topo (FPY mais baixo) é quem está gerando mais retrabalho. Nas janelas de 7/30/90 dias, tem uma coluna a mais comparando com o período anterior de mesmo tamanho (↑ melhorou, ↓ piorou, = igual).

Se pular ou errar: não há como errar nesta tela — é só leitura. Sem nenhum reteste registrado no período selecionado, ela mostra uma mensagem avisando disso.

Detalhes e estados: até 15/09 os números vinham do histórico dos 5.000 retestes mais recentes por empresa (acima disso, os mais antigos saíam do cálculo). A Fase 35 trocou isso por um filtro de período de verdade: 7/30/90 dias ou um dia específico, com uma coluna de comparação contra o período anterior de mesmo tamanho nas três janelas fixas — escolhendo um dia específico, essa coluna some (comparar "sexta" com "quinta" não faz sentido).

Garantia (90 dias)

Garantia (90 dias)

Pra que serve: gerencia acionamentos de garantia — quando um cliente que já comprou um aparelho reclama de defeito dentro de 90 dias corridos da venda, aqui se registra o caso e se decide o desfecho.

Quem usa: leitura liberada a quem tem permissão de ver valores em dinheiro (ADMIN/GERENTE/FINANCEIRO — veem tudo, com os valores em R$) e a VENDEDOR (só as garantias das próprias vendas, sem os campos de dinheiro — ele acompanha o status do cliente dele, mas não decide valores). Qualquer outro perfil, incluindo SUPERVISOR_ASSISTENCIA, é redirecionado pro Dashboard — o envolvimento do supervisor no reparo em si acontece em /os, não aqui. Abrir um chamado de garantia é só ADMIN/GERENTE. Resolver (decidir o desfecho) é ADMIN/GERENTE/FINANCEIRO.

No menu lateral, o link pra Garantia foi retirado do VENDEDOR de propósito (decisão registrada: dar crédito ao cliente é poder de gestão) — mas se ele acessar a URL /garantia diretamente, a tela abre normalmente e mostra as garantias das vendas dele, sem valores. Não é falha: é a regra escrita — ele acompanha, não decide dinheiro.

Ações principais:

  • "Abrir garantia": busca a venda, escolhe o aparelho (item daquela venda) e descreve o defeito relatado pelo cliente/lojista. O sistema calcula sozinho se ainda está dentro dos 90 dias.
  • "Resolver": escolhe 1 de 4 caminhos:
    • Crédito ao lojista — lança um valor de crédito na conta do cliente, pra usar em compras futuras.
    • Recolher e reparar — abre uma OS própria vinculada à garantia (escolhe o técnico); quando essa OS for concluída em /os, o custo do reparo é somado automaticamente ao custo da venda original (ajusta a margem pra trás) e a garantia fecha sozinha.
    • Trocar por outro — entrega um aparelho substituto do mesmo modelo (precisa estar disponível em estoque); o aparelho antigo volta pra triagem. Sem substituto do mesmo modelo disponível, o sistema cai automaticamente pra "Crédito ao lojista" — não trava a decisão.
    • Negar — fecha o caso sem nenhum efeito financeiro.

Fluxo correto:

  1. Cliente reclama de defeito dentro de 90 dias da venda.
  2. ADMIN/GERENTE clica "Abrir garantia", escolhe a venda, o aparelho e descreve o defeito.
  3. ADMIN/GERENTE/FINANCEIRO decide o caminho de resolução. No caminho "Recolher e reparar", também escolhe o técnico próprio responsável.
  4. Se foi "Recolher e reparar": a garantia fica "Em processamento" até a OS aberta ser concluída em /os — só aí ela vira "Resolvida" e o impacto no custo da venda original é aplicado.

Se pular ou errar: acionar fora do prazo de 90 dias é recusado na hora, com a mensagem explicando o prazo. Tentar trocar sem aparelho do mesmo modelo disponível não trava — vira crédito automaticamente (o operador é avisado do caminho efetivo). Resolver uma garantia que já foi resolvida antes é recusado — evita gerar crédito duplicado num duplo clique.

⚠️ Atenção: concluir a OS de uma garantia em /os não é só terminar o reparo — o sistema soma esse custo automaticamente na margem da venda original e fecha o caso sozinho, sem etapa extra de revisão.

Detalhes e estados: status = ABERTA → EM_PROCESSAMENTO (só no caminho "Recolher e reparar") → RESOLVIDA (ou CANCELADA). O campo que liga a garantia à OS de reparo só é preenchido nesse caminho. O valor do impacto no custo só é gravado quando a OS de garantia conclui — antes disso fica em branco, mesmo com a garantia "Em processamento". A trava que restringe VENDEDOR às garantias das próprias vendas existe em duas camadas: na tela (o que é buscado) e no próprio banco de dados (uma trava que existe mesmo que alguém tente ler os dados por fora da tela).

Garantias por modelo (Fase 35, 15/09): logo abaixo da lista de acionamentos tem um ranking dos últimos 90 dias mostrando quais modelos mais acionam garantia — sem nenhum valor em dinheiro, só contagem de casos por modelo. Segue o mesmo recorte de quem está olhando: VENDEDOR só vê o ranking calculado sobre as garantias das próprias vendas. Serve pra enxergar padrão (ex.: "o iPhone 12 puxa garantia muito mais que os outros") sem precisar abrir os acionamentos um por um.

RMA — Devoluções e trocas

RMA — Devoluções e trocas

Pra que serve: canal mais amplo de logística reversa (o "voltar" de um aparelho por qualquer motivo) — devolução do cliente, troca, garantia (por outro caminho que não o módulo Garantia), defeito pós-venda, e devolução PRA o fornecedor (quando o problema é de origem, não da KL). Cada RMA (o termo em si — autorização de devolução) tem um laudo (texto com o diagnóstico/motivo da decisão) e um histórico de eventos registrado.

Quem usa: a própria página não bloqueia ninguém por redirecionamento — a trava real está espalhada entre a permissão de banco (um controle interno do próprio banco de dados) e as ações. Resumo por poder:

  • Abrir RMA / confirmar recebimento do item: ADMIN, GERENTE, OPERADOR_SP, VENDEDOR e, desde 06/09, também SUPERVISOR_ASSISTENCIA.
  • Marcar retorno de remessa ao fornecedor: ADMIN, GERENTE, OPERADOR_SP (sem VENDEDOR nem SUPERVISOR_ASSISTENCIA — mexe em estoque/logística, é mais estreito de propósito).
  • Aprovar/recusar o RMA no início do fluxo: ADMIN/GERENTE.
  • Decidir o desfecho final (endurecido em ago/2026 — antes metade das decisões não tinha checagem nenhuma de perfil): decisões financeiras (Reembolsar, Gerar crédito) → ADMIN/GERENTE/FINANCEIRO; todas as outras 6 decisões (Trocar, Reparar, Voltar ao estoque, Devolver ao cliente, Devolver fornecedor, Sucata) → só ADMIN/GERENTE, mesmo as que parecem puramente operacionais (ex.: Trocar marca um aparelho como vendido sem venda real por trás — é poder de mutação de estoque igual às outras).
  • No menu lateral só ADMIN/GERENTE (acesso total) e OPERADOR_SP têm o link — VENDEDOR e SUPERVISOR_ASSISTENCIA podem abrir/receber RMA pela permissão que têm, mas não têm o item no menu; só chegam sabendo a URL /rma.
  • Controle fino por linha (ago/2026, mesma regra da Garantia): VENDEDOR só enxerga os RMAs vinculados a vendas dele; um RMA sem venda vinculada (ex.: RMA de fornecedor) fica invisível pra ele. ADMIN/GERENTE/FINANCEIRO/OPERADOR_SP continuam vendo tudo.
    • SUPERVISOR_ASSISTENCIA enxerga e opera RMA normalmente desde 10/09. Vale saber por que isso aparece aqui: a permissão de 06/09 liberou pra ele abrir RMA, mas a trava de leitura da lista (select_rmas) ficou pra trás. Por quatro dias ele conseguia salvar um RMA novo e depois a lista voltava vazia — e "Confirmar recebimento do item" falhava com "RMA não encontrado", porque essa ação relê o registro antes de gravar. Foi corrigido em 10/09 (leitura e atualização liberadas para o perfil). Se você tentou abrir RMA nesses dias e achou que tinha feito algo errado: não tinha — o RMA foi salvo, você só não conseguia vê-lo.

Ações principais:

  • "Novo RMA": informa o IMEI, o tipo (Devolução, Troca, Garantia, Defeito pós-venda, RMA fornecedor) e o motivo. O sistema acha a venda automaticamente pelo IMEI e aplica a política por prazo: até 7 dias corridos da venda = arrependimento (aprova sozinho); até 90 dias = garantia (aprova sozinho); depois disso, fica "Aguardando aprovação" manual.
  • "Aprovar"/"Recusar" (quando não auto-aprovou): ADMIN/GERENTE decide se o chamado segue.
  • "Confirmar recebimento do item": marca que o aparelho físico voltou; o RMA passa pra "Em inspeção".
  • "Decidir": escolhe 1 de 8 desfechos — Reembolsar, Gerar crédito, Trocar produto, Reparar, Voltar ao estoque, Devolver ao cliente, Devolver fornecedor, Sucata — com valor em R$ (quando envolve dinheiro), laudo, e o IMEI do substituto quando for troca (o sistema faz o "auto-swap": entrega o substituto ao cliente e o defeituoso volta pra triagem).
    • Reparar (conserto 06/09) exige escolher também o técnico próprio responsável — sem técnico, "sem técnico não há OS" e a decisão é bloqueada. Ao confirmar: o aparelho sai de VENDIDO e volta pra EM_TRIAGEM, e uma OS própria abre pra ele — igual ao caminho "Recolher e reparar" da Garantia. A diferença importante: aqui o RMA fecha (FECHADO) na hora, junto com a abertura da OS — ele não fica "em processamento" esperando a OS terminar como a Garantia fica. Depois de decidido "Reparar", o acompanhamento do conserto em si é só pela OS aberta em /os, não mais pelo RMA.
  • Aba de Remessas ao fornecedor: lista o que foi devolvido a fornecedor (via a decisão "Devolver fornecedor") e permite "Marcar retorno" quando ele devolve — o aparelho volta pra triagem pra reinspeção.

Fluxo correto:

  1. Cliente devolve/troca um aparelho, ou chega uma remessa de fornecedor com problema.
  2. "Novo RMA": bipa o IMEI, escolhe o tipo, escreve o motivo.
  3. Dentro da política de prazo (7 ou 90 dias), o sistema já aprova sozinho; fora disso, ADMIN/GERENTE aprova ou recusa manualmente.
  4. Quando o item físico chega de volta, "Confirmar recebimento do item".
  5. Quem tem permissão decide o desfecho final, com laudo — isso fecha o RMA.
  6. Se o desfecho foi "Devolver fornecedor", acompanha na aba de Remessas até ele devolver de volta.

Se pular ou errar: decidir um RMA já fechado é bloqueado (evita gerar crédito 2 vezes num duplo clique). Reembolso/crédito sem valor maior que zero é recusado. Troca sem informar o IMEI do substituto, ou com substituto indisponível/igual ao próprio aparelho do RMA, é recusada. A tela de decisão mostra as 8 opções pra qualquer perfil que consiga abrir o RMA — quem não tem permissão só descobre ao tentar confirmar (a trava real é na ação, não um botão escondido). "Reparar" sem escolher o técnico é bloqueado antes de mexer em qualquer coisa. Na "Troca", o sistema move o substituto pro cliente primeiro e só depois devolve o defeituoso pra triagem — se esse segundo passo falhar, a mensagem de erro avisa explicitamente que o substituto já foi entregue e orienta resolver a pendência do defeituoso e decidir o RMA de novo, em vez de repetir a troca (repetir mandaria um segundo aparelho pro mesmo cliente).

⚠️ Atenção: no RMA, a decisão "Trocar" marca um aparelho como vendido mesmo sem venda de verdade por trás — é por isso que só ADMIN/GERENTE decidem, mesmo parecendo uma ação puramente operacional.

Detalhes e estados: status = SOLICITADO/AGUARDANDO_APROVACAO → APROVADO → RECEBIDO/EM_INSPECAO → FECHADO (ou RECUSADO/CANCELADO). O valor do RMA é sempre o preço do item devolvido, nunca o total da venda inteira (uma venda de 3 aparelhos devolvendo 1 não vale 3×). "Sucata" em RMA é decisão de baixa de estoque, não "crédito ao cliente" — por isso continua em ADMIN/GERENTE mesmo separada da trava financeira.

Métricas de RMA (Fase 35, 15/09): seção própria na tela, com botões de período (7/30/90 dias — sem opção de dia específico aqui, diferente das outras telas da Fase 35) mostrando 3 colunas: motivos mais frequentes (top 5), fornecedores com mais retorno (top 5, só remessas devolvidas a fornecedor) e tempo médio por etapa (onde o RMA costuma travar mais tempo). Ajuda a enxergar padrão — por exemplo, um fornecedor específico gerando retorno demais — sem precisar somar RMA por RMA.

Erros comuns e como evitar

  1. Confundir pré-grade com grade final. A pré-grade é da triagem (antes do conserto); a grade final só existe depois que a OS conclui, e pode ser diferente pra melhor ou pra pior — isso é esperado, não é erro de digitação.
  2. Estranhar que o técnico não consegue aprovar o próprio reteste. É de propósito: o controle de qualidade não pode ser feito por quem fez o serviço. Peça pra outra pessoa testar.
  3. Tentar acionar garantia ou RMA fora do prazo pelo formulário normal. O sistema recusa na hora; caso excepcional (decisão comercial fora de política) precisa ser tratado por fora, não forçado no formulário.
  4. Achar que "Liberar mesmo com defeito" no reteste significa aprovado. É o oposto: o aparelho reprovou, mas foi liberado assim mesmo por decisão do operador.
  5. Tentar cancelar OS ou fechar RMA com custo extra pendente de aprovação. O sistema trava — aprove ou rejeite o custo primeiro em /aprovacoes.
  6. Esperar que o Mutirão em lote "avise" o supervisor pra confirmar tudo de uma vez. Hoje o supervisor confirma as OS marcadas-prontas uma a uma, no detalhe de cada OS — a confirmação em lote já existe dentro do sistema, mas ainda sem botão ligado na tela.
  7. VENDEDOR achar que perdeu acesso à Garantia/RMA porque sumiu do menu. Ele não perdeu: sabendo a URL, ainda vê os casos das próprias vendas — só não decide dinheiro, e o link não aparece mais no menu lateral.
  8. Tentar reabrir uma 2ª OS pro mesmo aparelho sem checar se já existe uma ativa. O banco recusa com uma trava própria — a mensagem pede pra recarregar a tela e conferir a OS existente.
  9. Achar que SUPERVISOR_ASSISTENCIA ainda não vê o RMA que abriu. Isso já foi verdade entre 06/09 e 10/09 (a permissão de abrir chegou primeiro, a de ler a lista ficou 4 dias pra trás) — hoje já está corrigido, ele enxerga e opera RMA normalmente. Se alguém contar essa história como se fosse o estado atual, é a versão antiga.
  10. Achar que a OS que abriu de novo depois de um reteste reprovado é uma OS nova. Desde 10/09, reprovar pra "Assistência" reabre a mesma OS do reparo anterior — o histórico e o custo continuam somando no mesmo registro, não em dois. ⚠️ A faixa amarela "OS REABERTA" no topo, porém, não aparece pra reaberturas feitas a partir de 19/09 (regressão — ver o aviso na seção Detalhe da OS); a reabertura de verdade acontece mesmo sem a faixa mostrar.
  11. Achar que reprovar pra "Assistência" manda o aparelho na hora pra bancada. Hoje ele fica esperando o recolhimento do lote de volta rumo à assistência — o status continua "Reteste" por um tempo, isso não é erro nem aparelho perdido.
  12. Registrar serviço pela tela normal (Detalhe da OS) numa OS que tem itens por defeito (nascida de aceite/leva) achando que isso fecha a lista de pendências. Não fecha — hoje ninguém trava por causa disso, mas quem quer marcar os itens como feitos de verdade (ou "não fazer") precisa passar pelo Mutirão.