Bloqueia
Usuário não tem permissão para autorizar pedidos (regra ORDEM_VENDA_*).
QuandoAprovar em filial 003/004 sem nenhuma regra ORDEM_VENDA_*. A linha mostra o texto em vermelho no resultado.
Caso sugerido para QA: o que fazer, o que esperar e como conferir no banco.
Recusa com a mensagem exata (HTTP 400, mostrada na tela).
Limitação, pendência ou ponto em que o código e a ajuda não coincidem.
Fila do aprovador: os pedidos de venda (2332) que esperam autorização de crédito e, quando a alçada pede, de preço, numa tela só, o de entrega mais próxima primeiro (os atrasados no topo). Cada pedido é analisado "a seco" (as mesmas análises do botão Autorizar do 2332, sem gravar) para o aprovador ver as restrições antes, e "Aprovar marcados" chama os endpoints do 2332. Inovação do faturamento (27/09/2026): o legado e o ceif não têm. Pacote faturamento.pedidovenda: PedidoVendaFilaAprovacaoService e ...Controller; tela FilaAprovacaoPedidos.vue.
2331 = o antigo "2332 › A": nasceu dentro do menu do 2332 e seguia a permissão dele; em 29/09/2026 ganhou opção própria (2-Lançamentos › 3-Saídas/Vendas › 1-Fila de Aprovação de Pedidos (2331), histórico 368). Sem linha em grupo_permissao a tela some para quem não é ADM (conceder no 444). Em AppShell.TELA_SEM_REGISTRO o link direto /?abrir=2331 abre a fila sem id, com permissao: '2331' (o histórico 353 ainda fala em "permissão do 2332").
Quem aprova e as travas continuam sendo as do 2332: POST /lancamento/pedido-venda/{id}/autorizacao-preco e POST /lancamento/pedido-venda/{id}/autorizacao, ambos com ?confirmado=true. A fila não tem endpoint de gravação próprio. Documento do próprio 2332: ver a documentação técnica dessa opção.
| Campo | Default | Efeito |
|---|---|---|
| Entrega de / até (Emissão de, fora do Brasil) | hoje − 10 dias até hoje + 15 dias | Brasil (codicfj 004): filtra fov.data_entrega; demais países: fov.data_emissao (faixa meio-aberta >= ini AND < fim + 1 dia: as colunas são datetime e há linhas com hora). Sem as duas datas o servidor recusa: "Informe as duas datas do período." (desde 04/10/2026) |
| Todas as minhas filiais | desmarcada | Desmarcada: filial da sessão. Marcada: FiliaisDoUsuario.permitidas |
| Crédito e preço / Só crédito / Preço pendente | Crédito e preço | Filtro local sobre a lista: "Preço pendente" = pendentePreco (o crédito vai junto); "Só crédito" = !pendentePreco, os que aguardam só o crédito. Todo item aguarda crédito; os dois filtros repartem a lista (ver G) |
| Atualizar | — | Recarrega a lista e reanalisa tudo, um pedido por vez ("Analisando N de M…") |
| Abrir ao entrar pelo celular | desmarcada | Grava localStorage 'fjfrigo.telaInicialCelular' = '2331' (por aparelho; só vale com largura ≤ 768 px) |
| Copiar link | — | Copia <origin>/?abrir=2331; sem permissão de área de transferência abre um prompt com o link |
| Abrir | — | Abre o pedido (PedidoVendaEditWindow) para corrigir; ao gravar, o pedido é reanalisado |
| Interno | — | GET /lancamento/pedido-venda/{id}/demonstrativo.pdf?versao=interno (margens, custo e tabela mínima) em outra aba |
| Aprovar marcados | — | Pede confirmação ("Aprovar N pedido(s)?" e, quando há, "N deles com restrição mostrada na fila - serão aprovados mesmo assim.") e aprova um a um: preço antes (se pendente), pedido depois |
Abaixo de 720 px a tabela vira cartões (celular). Cada linha mostra, além do pedido, cliente, valor, "em N dia(s)/N dia(s) atrás/hoje", o score de crédito (marcarScores), a coluna Motivo e o resultado da aprovação (verde "Aprovado" / vermelho com o texto do erro).
PedidoVendaService.listar(...) com autorizado=false, comExcluidos=false: a grade do 2332 com fov.autorizado <> 'T' e fov.excluido <> 'T' (faturamento_venda_ordem_venda). Se o usuário é de grupo cujo grupo_usuario.tipo contém "VEN" e tem usuario.idvendedor, a lista só traz os pedidos dele (fov.idvendedor).faturamento_venda.idpedido = fov.id vivo (idFaturamento > 0). Todo item sai com pendenteCredito = true (a lista só tem pedidos não autorizados).!precoAutorizado (sem idusuario_preco) e alçada tipo_aut_preco ∈ {ADM, GER}.diasParaEntrega crescente (negativo = entrega já passou, no topo; sem data, no fim), depois id. Dias = data_entrega − hoje.| Motivo da coluna (já vem na lista) | Condição |
|---|---|
| cliente sem limite | valorLimite ≤ 0 |
| pendência + pedidos em aberto acima do limite | valorPendente + pedidosAbertos > valorLimite |
| atraso de N dia(s), tolerância T | atraso > toleranciaAtraso |
| cliente inativo (última nota aaaa-mm-dd) | última nota há mais de 60 dias |
| parcela abaixo de 300 | valorParcela < 300 |
| prazo fora do cadastro do cliente | autorizadoPor = "PRAZO" |
| preço pede liberação (ADM|GER) | pendentePreco |
São os mesmos motivos da cor da linha do 2332 (constantes copiadas em PedidoVendaFilaAprovacaoService: 300, 60 dias, alçadas ADM/GER). Não substituem a análise por pedido.
filialParametros.buscar(jdbc, user.idFilial()) (a filial da sessão, ver G).filial.controla_pendencias_pedido estiver ligado): PedidoVendaCredito.analisar devolve recusas (impedem sem apelo) e restrições (liberáveis); podeLiberarCredito diz se o usuário pode passar por cima; se há restrição de limite, mostra o limite sugerido pelo score (ScoreCreditoService.sugestao).PedidoVendaPrecoAutorizacao.analisar(..., desautorizando=false).| Resultado | Mensagens (exatas) | Quando |
|---|---|---|
| Recusa de crédito | tipo de faturamento exige a regra ORDEM_VENDA_AUTORIZACAO_AJUSTE_ESTOQUE_REETIQUETAGEM | Brasil, tipos 11105/11116, sem a regra |
| Recusa de crédito | doação exige a regra ORDEM_VENDA_AUTORIZACAO_DOACAO | Brasil, tipo 1120, sem a regra |
| Recusa de crédito | pedido sem aprovação de preço | controla tabela mínima, alçada ADM e sem idusuario_preco (descartada pelo servidor na análise da fila quando o preço está pendente, porque "Aprovar" o libera junto) |
| Recusa de crédito | este pedido deve ter autorização de preço para faturamento (produto abaixo da tabela mínima) | Brasil, controla tabela mínima, tipo com tabela mínima, alçada ADM/GER sem preço liberado e produto abaixo do mínimo |
| Recusa de crédito | pedido com produto repetido | mesmo idproduto duas vezes na grade |
| Recusa de crédito | emitente sem segmentação | Brasil, emitente sem segmentação |
| Recusa de crédito | prazo fora do cadastro do emitente (exige ORDEM_VENDA_AUTORIZACAO_CREDITO) | Brasil, prazo do pedido ausente dos prazos do emitente e usuário sem a regra |
| Recusa de crédito | <produto>: sem tabela mínima / <produto>: produto sem NCM [vazio|valor] | Brasil, tipo que controla pendência: sem tabela mínima (se controla), NCM vazio ou com 3 a 7 caracteres |
| Restrição de crédito | pendência (X) acima do limite (Y); pendência + pedidos em aberto (X) acima do limite (Y); emitente sem limite de venda cadastrado | Só pedido a prazo, fora do Paraguai e fora do tipo de pagamento antecipado (10019) |
| Restrição de crédito | atraso de N dia(s), tolerância de T | Idem (a prazo, fora do Paraguai) |
| Restrição de crédito | cliente sem compras há mais de 60 dias; parcela de X, abaixo do mínimo de 300 | Brasil, qualquer prazo |
| Recusa / restrição de preço | pedido já autorizado...; autorizar preço exige a regra ORDEM_VENDA_AUTORIZACAO_PRECO ou grupo ADM/GER/GVE; pedido com alçada GER exige a regra...; "<idindustria> <produto>: pedido X, mínimo Y (ML Z%)" | Sem a regra necessária (..._PRECO alçada Gerente nos tipos 115, 1138, 1184, 1186, 11108, 11109, 11111, 11116, 11127; ..._PRECO_ABAIXO_MINIMO nos demais, abaixo do mínimo) vira recusa; com ela, restrição |
Fora do bloco de crédito (sem recusa nem restrição) ficam os tipos de faturamento sem tipo_faturamento.ordem_venda_controla_pendencia e os emitentes cujo grupo (grupo_emitente.intercompany) é intercompany; nestes a análise devolve só as recusas de permissão por tipo, produto repetido, segmentação e preço.
podeLiberarCredito.autorizacao-preco?confirmado=true (se precoPendente) e depois autorizacao?confirmado=true. Resultado "Aprovado" quando autorizado volta verdadeiro; senão "Não foi aprovado." ou a mensagem do servidor. Resumo final: "N aprovado(s), M com falha.".A lista e a análise não exigem regra: qualquer usuário com a opção no menu (e o endpoint sob /lancamento/* com JWT) vê a fila. A aprovação exige o que o 2332 exige, aplicado no servidor no momento do clique:
PedidoVendaService.exigirPermissaoDeAutorizar): em filial 003/004 (codicfj), ter alguma regra com prefixo ORDEM_VENDA_ (RegraAcessoService.temAlgumaComPrefixo); nos demais países, grupo de usuário (grupo_usuario.tipo_grupo) em ADM, GER, GVE, FAT, FIN ou CRE.ORDEM_VENDA_AUTORIZACAO_CREDITO; sem ela, só no Brasil, com filial.autorizar_pedido_simples ligada e se todas as restrições forem de limite (atraso, cliente inativo e parcela mínima continuam pedindo a regra).ORDEM_VENDA_AUTORIZACAO_PRECO; alçada GER exige GER/GVE ou a regra; abaixo do mínimo ..._PRECO_ABAIXO_MINIMO; master atravessa; com filial.autorizar_pedido_simples ligada no Brasil a liberação de preço não pede regra.Usuário não tem permissão para autorizar pedidos (regra ORDEM_VENDA_*).
QuandoAprovar em filial 003/004 sem nenhuma regra ORDEM_VENDA_*. A linha mostra o texto em vermelho no resultado.
Usuário não tem permissão para autorizar pedidos [grupo].
QuandoAprovar em outro país com grupo fora de ADM/GER/GVE/FAT/FIN/CRE.
autorizar preço exige a regra ORDEM_VENDA_AUTORIZACAO_PRECO ou grupo ADM/GER/GVE (o seu é X)
QuandoAprovação de preço sem regra e sem grupo. Aparece como recusa na análise: a linha nem fica marcável.
Aprovar N pedido(s)?
QuandoConfirmação do navegador antes de gravar (cancelar não faz nada).
| Onde | Item | Efeito |
|---|---|---|
filial | controla_pendencias_pedido | Desligada: não há análise de crédito (a tela mostra só o preço) |
filial | controla_tabela_minima | Liga a conferência de tabela mínima/preço |
filial | autorizar_pedido_simples (coluna opcional; ausente = falso) | No Brasil, dispensa regra para liberar preço e restrição só de limite |
tipo_faturamento | ordem_venda_controla_pendencia | Tipo fora do bloco de crédito (antes: lista de 13 ids chumbada) |
grupo_emitente | intercompany | Emitente de grupo intercompany fica fora do bloco de crédito |
grupo_usuario / usuario | tipo_grupo, tipo, idvendedor | Quem pode autorizar fora do Brasil; vendedor só vê os pedidos dele |
| Regras de acesso | ORDEM_VENDA_AUTORIZACAO, _CREDITO, _INATIVO, _MENOR_300_REAIS, _PRECO, _PRECO_ABAIXO_MINIMO, _RESTRICAO, _DOACAO, _AJUSTE_ESTOQUE_REETIQUETAGEM | Cadastradas no central; "basta UMA da família" para autorizar (critério do legado; o ceif exige ORDEM_VENDA_AUTORIZACAO nominal) |
| Navegador | fjfrigo.telaInicialCelular | Abrir a fila ao entrar pelo celular (largura ≤ 768 px) |
public/manifest.webmanifest | atalho "Aprovação" → /?abrir=2331 | App instalável no celular (sem service worker; não testado em celular) |
Constantes na fila: parcela mínima 300, 60 dias para cliente inativo (cópias das do 2332), alçadas com preço ADM/GER. Sem rotina agendada e sem e-mail.
Abrir a fila
FazerAbrir 2331 (Brasil) com os padrões.
EsperadoLista os pedidos não autorizados, não excluídos e não faturados com entrega entre hoje − 10 e hoje + 15, atrasados no topo. "Analisando N de M…" cresce até M; cada linha ganha cor e Motivo.
ConferirSELECT fov.id, fov.data_emissao, fov.data_entrega, fov.autorizado, fov.idusuario_preco, fov.tipo_aut_preco
FROM faturamento_venda_ordem_venda fov
WHERE fov.excluido <> 'T' AND fov.autorizado <> 'T'
AND fov.data_entrega >= :de AND fov.data_entrega <= :ate AND fov.idfilial = :filial
AND NOT EXISTS (SELECT 1 FROM faturamento_venda fv WHERE fv.excluido <> 'T' AND fv.idpedido = fov.id)
ORDER BY fov.data_entrega, fov.idA contagem da tela deve bater com a consulta (no vendedor "VEN", só os pedidos dele). Referência (central, 04/10/2026): 1.048 pedidos não autorizados no total, na história inteira.
Fora do Brasil usa a data de emissão
FazerRepetir em tenant paraguaio.
EsperadoO rótulo vira "Emissão de" e o filtro é data_emissao.
Análise por pedido
FazerEscolher um pedido com cliente sem limite ou com atraso e outro limpo.
EsperadoO primeiro mostra restrição em laranja e (se houver limite) o limite sugerido pelo score; o limpo fica sem cor e marcável. Pedido sem NCM no item, produto repetido ou cliente sem segmentação (Brasil): vermelho, não marcável. Filial com controla_pendencias_pedido desligado: sem análise de crédito.
ConferirSELECT controla_pendencias_pedido, controla_tabela_minima, autorizar_pedido_simples FROM filial WHERE id_filial = :filial (a coluna opcional pode não existir).
Restrição de crédito sem a regra
FazerCom um usuário sem ORDEM_VENDA_AUTORIZACAO_CREDITO, abrir um pedido com atraso.
EsperadoA linha fica laranja mas não marcável (a análise diz que o usuário não pode liberar). Com a regra, marca e, ao aprovar, o aviso conta quantas linhas têm restrição.
Aprovar pedido só de crédito
FazerMarcar um pedido sem preço pendente e clicar "Aprovar marcados" e confirmar.
EsperadoA linha fica verde "Aprovado" e some da fila no próximo Atualizar; resumo "1 aprovado(s), 0 com falha.".
ConferirSELECT autorizado, idusuario_autorizou FROM faturamento_venda_ordem_venda WHERE id = :id
Aprovar pedido com preço pendente
FazerMarcar um pedido de alçada ADM/GER sem preço liberado, com usuário que tem a regra de preço.
EsperadoPrimeiro idusuario_preco é gravado, depois autorizado = 'T' (ordem obrigatória). As recusas "pedido sem aprovação de preço" (ADM) e "este pedido deve ter autorização de preço..." (GER abaixo do mínimo) não aparecem na fila por causa disso; repetir com um pedido GER abaixo do mínimo, que agora fica marcável.
ConferirSELECT autorizado, idusuario_preco, tipo_aut_preco FROM faturamento_venda_ordem_venda WHERE id = :id
Sem permissão para autorizar
FazerUsuário sem nenhuma regra ORDEM_VENDA_* (003/004) tenta aprovar um pedido marcável.
EsperadoA linha vira vermelha com "Usuário não tem permissão para autorizar pedidos (regra ORDEM_VENDA_*)."; nada é gravado; o resumo conta 1 falha.
Filtros Só crédito / Só preço
FazerAlternar o combo.
Esperado"Só preço" mostra os pendentes de preço; "Só crédito" mostra os sem preço pendente (um pedido pendente de crédito e de preço só aparece em "Só preço" e em "Crédito e preço").
Celular e link direto
FazerAbrir /?abrir=2331 logado e em tela ≤ 720 px; marcar "Abrir ao entrar pelo celular".
EsperadoAbre direto a fila; a tabela vira cartões; "Interno" abre o PDF do demonstrativo interno em outra aba; na próxima entrada pelo celular a fila abre sozinha.
Aprovar não exercitado: validar em homologação
FazerAprovar de fato é o único ponto que o histórico 350 marca como não exercitado (só a lista e a análise foram rodadas, filiais 5, 64 e 32 do central).
EsperadoFazer o roteiro acima em homologação com pelo menos: pedido limpo, com restrição liberável, com recusa e com preço pendente.
Corrigido em 04/10/2026: bloqueio indevido na alçada GER com preço abaixo do mínimo
A tela só descartava a recusa "pedido sem aprovação de preço" (ADM). A da alçada GER — "este pedido deve ter autorização de preço para faturamento (produto abaixo da tabela mínima)" — ficava, e o pedido não era marcável embora "Aprovar" libere o preço antes. Agora PedidoVendaFilaAprovacaoService.analisar tira as duas de recusasCredito quando precoPendente (constantes PedidoVendaCredito.RECUSA_SEM_APROVACAO_PRECO e RECUSA_DEVE_TER_PRECO); a tela não compara mais texto. Recusa do próprio preço (regra que falta) continua em recusasPreco e impede. Conferido no menu2332.prg: no legado são dois cliques (Aut. Preço e depois Autorizar). Não testado na tela.
Ajustado em 04/10/2026: rótulos do filtro de pendência
Todo item aguarda crédito; "Só crédito" (!pendentePreco) é o pedido que aguarda só o crédito e o antigo "Só preço" virou "Preço pendente" (o crédito vai junto na mesma aprovação), com dica no item. Os dois repartem a lista; o comportamento não mudou.
Análise usa os parâmetros da filial da sessão, não os do pedido (decisão em aberto)
Com "Todas as minhas filiais", analisar lê filialParametros.buscar(jdbc, user.idFilial()) e FlagDaFilial.ligada(jdbc, user.idFilial(), ...). É o mesmo que a autorização do 2332 faz (alternarAutorizacao/alternarAutorizacaoPreco) e o mesmo do legado (oParametros da sessão, com lMultiFilial na grade). Mudar só a fila faria a análise "a seco" divergir do que o Aprovar confere; se for para mudar, é no 2332 inteiro (parâmetros da filial do pedido). Não alterado: decisão de negócio (04/10/2026).
Lista e análise sem regra de acesso
Quem tem o menu vê todos os pedidos pendentes (e seus motivos de crédito) das filiais escolhidas, mesmo sem poder aprovar; a aprovação é que checa as regras.
Corrigido em 04/10/2026: sem datas a lista vinha vazia sem aviso
O serviço agora recusa: "Informe as duas datas do período.". Junto, o recorte de data do 2332 (PedidoVendaRepository.aplicarFiltros, que a fila usa) passou a faixa meio-aberta: data_entrega/data_emissao são datetime e em central há linhas com hora (54 entregas e 10.507 emissões em 2026), que o <= fim perdia no último dia. Vale também para a grade do 2332.
Pendências
Status REVISAR (status-porte.csv, 02/10/2026; data da última conferência vazia). Aprovar não foi exercitado e a tela não foi testada (histórico 350); PWA/celular não testado em aparelho (353). O Javadoc do serviço diz "autorizado = 'F'", o SQL é autorizado <> 'T' (equivalente se a coluna nunca for nula).
Nada bate com essa busca. Tente um trecho menor, ou limpe os filtros.