Informe a data inicial.
QuandoSem data inicial (a tela confere antes, com a mesma frase). A data final é opcional.
Não grava. statuscode 400 com a frase abaixo, que a tela mostra como está.
Pergunta antes de seguir. Nestas telas quem pergunta é a própria tela.
Passa, mas com um comportamento que surpreende quem está conferindo, ou uma linha que aparece na lista "Não reprocessados" / na coluna de observação.
"Ver prévia" só lê e lista só o que muda. "Aplicar" refaz toda a conta no servidor e grava numa transação — não grava o que a prévia mostrou.
Duas metades, só na filial da sessão e por emissão no período (o vendedor/comprador é filtro opcional):
Pedido de venda (2332) → venda (2333) → títulos. Pedidos dos tipos 113, 114, 1121, 1194, 11107, 11151, 11154, 11109 e 11153 com venda viva: o % sai da tabela de comissão do vendedor (emitente_comercial), pela mesma conta do Pedido 2332, com 2 casas; grava no pedido (junto com o tipo de faturamento da venda) e em perc_comissal das parcelas 1 vivas de todas as vendas vivas do pedido.
Ordem de compra (2321) → compra de carne (2322) → títulos. Ordens 112, 1112 e 1113 com compra viva: o % é o do pedido da venda que a compra referencia (a "Fat. referência": venda viva do mesmo cliente, documento igual antes do parcial); grava na ordem (com o tipo da compra) e nas parcelas 1 da compra, cada compra no próprio tipo.
Informe a data inicial.
QuandoSem data inicial (a tela confere antes, com a mesma frase). A data final é opcional.
A data final é anterior à inicial.
QuandoPeríodo invertido.
Sistema antigoSó usava a data inicial, embora a tela tivesse as duas.
Só o usuário master pode reprocessar as comissões.
QuandoAplicar por usuário sem usuario.master. A tela já deixa o botão desabilitado ("Só o usuário master aplica."); a prévia é livre.
Sistema antigoSem restrição.
Gravar o % de comissão em 14 lançamento(s) e 18 título(s)?
QuandoPergunta da tela, antes de aplicar.
venda 1002131035 é troca de nota (11109) - não reprocessada
QuandoA venda do pedido é do tipo 11109. Sai na lista "Não reprocessados".
Sistema antigoA mesma exclusão (:832).
pedido sem vendedor - % vai a zero
QuandoPedido sem vendedor: o reprocesso segue e grava 0%.
compra 100312804 sem documento de referência - ordem não tocada
QuandoA compra da ordem não tem documento2 (a "Fat. referência").
Sistema antigoCom documento vazio o LIKE '%%' casava todas as vendas do cliente.
nenhuma venda viva do cliente com o documento [000038988] - ordem não tocada
QuandoNenhuma venda viva do emitente da ordem tem o documento de referência.
(sem mensagem) — a compra de carne 112 não leva comissão
QuandoOrdem cuja compra é do tipo 112: pulada sem aviso; só as devoluções (1112/1113) levam o %.
Sistema antigoA mesma exclusão (:941).
(sem mensagem) — sobrescreve o % acertado à mão no título
QuandoO título que teve o % mudado pelo 221 ("Comissão") volta ao % da tabela do vendedor. A prévia mostra a diferença (% atual × novo).
AtençãoMantido assim por decisão do usuário (24/09/2026): hoje não há como distinguir o acerto manual. Conferir a prévia antes de aplicar.
Venda (2333): toda linha tipo_produto = '1' das vendas vivas do período recebe o custo médio móvel do produto no fim do dia da emissão e vlr_tab_minimo = a tabela de preço mínimo vigente na emissão (a mais recente, se houver duas). Pedido (2332): só as linhas com custo médio zerado ou nulo recebem o custo — ou, sem ele, o próprio valor unitário.
O custo é o custo médio móvel em Java (a mesma conta que Pedido e Venda usam ao gravar), não a função customedionew do banco: percorre todo movimento de estoque do produto na filial — entradas (compra de carne por data de entrada; lançamento manual de entrada: produção 115, implantação 111, transferência 113) e saídas (venda, lançamento manual de saída, cupom do PDV) —, em kg e na moeda local, 3 casas. Filtros: período (obrigatório), filial (vazio = todas as suas) e produto (vazio = todos).
Informe o período (data inicial e final).
QuandoFalta uma das datas (a tela confere antes, com a mesma frase).
A data final é anterior à inicial.
QuandoPeríodo invertido.
Você não tem acesso à filial 18.
QuandoA filial escolhida não está entre as do usuário (usuario_filial).
Sistema antigoSem filtro de acesso.
Só o usuário master pode reprocessar o custo médio.
QuandoAplicar por usuário sem usuario.master. A tela já deixa o botão desabilitado; a prévia é livre.
Gravar o custo médio em 162 linha(s)?
QuandoPergunta da tela, com o total de linhas que mudam (não só as mostradas).
Sem custo médio na data (grava zero)
QuandoLinha de venda de produto sem nenhuma entrada com preço até o fim do dia: grava 0, como a gravação da Venda. Sem tabela mínima vigente, vlr_tab_minimo também vai a 0.
Sistema antigoO STR() de um nulo derrubava o laço no meio.
Sem custo médio: vale o valor unitário da linha
QuandoLinha de pedido sem custo médio e sem custo calculado: grava o valor_unitario da própria linha, como o sistema antigo.
(a grade mostra as primeiras 3000)
QuandoMais de 3.000 linhas mudam: a grade mostra as 3.000 primeiras, o resumo conta todas e o Aplicar grava todas.
AtençãoOs números mudam em relação ao gravado mesmo sem movimento novo: a conta nova é em kg, com produção e lançamentos manuais, e olha o dia inteiro (inclui o que entrou depois no mesmo dia).
Depois de incluir, alterar ou excluir o movimento, na mesma transação, o sistema refaz o custo_medio das linhas de venda (tipo_produto 1, vivas) dos produtos do movimento, na filial dele, da data do movimento até hoje. Lê o movimento antes e depois da gravação: trocar a data ou o produto afeta os dois. Pedido e cupom não disparam nem são tocados.
Movimento de estoque com data de 19/06/2026, mais de 30 dias atrás: o custo médio das vendas seguintes NÃO foi recalculado. Se a empresa controla custo médio, rode 4-Manutenção › 5-Integrações › Reprocessar Custo Médio (459) a partir de 19/06/2026.
QuandoA data mais antiga do movimento (antes ou depois da gravação) é anterior a hoje menos 30 dias. A gravação acontece normalmente; só o recálculo não roda.
AtençãoChega pelo cabeçalho X-Aviso-Sistema e aparece num painel com OK depois de gravar — não é erro. Movimento com data futura não recalcula nem avisa.
(sem mensagem) — só onde a venda grava custo médio
QuandoO recálculo só roda com parametros.codicfj 004 (Brasil) ou 005 (Chile); nos demais países não faz nada nem avisa. Venda de tipo marcado como filial_tf estoque não entra na média e não muda nada.
grep hUsuarioRegras no menu459.prg devolve zero. As duas telas não estão em opcao_sistema (itens do menu sem código de permissão). A prévia é livre; aplicar é só do master (usuario.master) nas duas — decisão do sistema novo, porque é UPDATE em massa de pedido, venda e financeiro. GET …/permissoes diz à tela se o botão Aplicar acende. O PED alcança só a filial da sessão; o CM, as filiais do usuário.
Recusa de regra: HTTP 200 com statuscode 400 e a frase, que a tela mostra na faixa vermelha. Falha sem frase aparece como "Falha ao montar a prévia." ou "Falha ao gravar.". Os avisos do PED aparecem na lista "Não reprocessados" abaixo da grade; os do CM na coluna de observação da linha. O aviso de mais de 30 dias chega pelo cabeçalho X-Aviso-Sistema da gravação da outra tela. Erro inesperado traz o código de ocorrência de 8 caracteres — copie-o no chamado. O log do servidor registra cada aplicação (base, usuário, período e quantidades).
| Regra | Valor |
|---|---|
| tipos de pedido do PED | 113, 114, 1121, 1194, 11107, 11151, 11154, 11109, 11153 (:810 — sem coluna equivalente em tipo_faturamento) |
| tipos de ordem de compra do PED | 112, 1112, 1113 (:917) |
| venda de troca de nota / compra sem comissão | 11109 (:832) / 112 (:941) |
| devolução no custo médio | tipo 1113 entra pelo custo corrente |
| limite do recálculo automático | 30 dias |
| países do recálculo automático | codicfj 004 e 005 |
| linhas mostradas na prévia do CM | 3.000 |
| Ponto | Situação |
|---|---|
| prévia e transação (PED e CM) | prévia antes de gravar e gravação numa transação só; o antigo gravava linha a linha, sem transação e sem dizer o que mudou |
| conta do % (PED) | a do Pedido 2332 (valor recalculado no Brasil, peso só das linhas com produto e total, 2 casas); o PED antigo usava o valor_total cru — em central jun-set/2026 dão o mesmo % em 5.460 de 5.460 pedidos |
| títulos (PED) | só vivos; o antigo reescrevia também os excluídos |
| vendas do pedido (PED) | todas as vivas; o antigo só a primeira (LIMIT 1) |
| venda referenciada (PED) | regra da "Fat. referência" do 2321; o antigo usava LIKE '%documento2%' testando o excluido da ordem, e com documento vazio casava todas as vendas do cliente |
| tipo da compra (PED) | cada compra no próprio tipo; o antigo usava o da primeira para todas |
| % acertado à mão no título (PED) | é sobrescrito — decisão do usuário (24/09/2026); marcar o acerto manual fica para decisão futura |
| custo médio (CM e gravações) | média móvel em Java no lugar de customedionew: determinística, em kg, com produção/lançamentos manuais e cupom, UNION ALL, moeda local, compra pela data de entrada. Desktop e web passam a divergir no número |
| período (CM) | faixa meio-aberta; o antigo usava DATE(coluna) BETWEEN |
| tabela mínima (CM) | a mais recente vigente; o antigo pegava qualquer uma |
| alcance (CM) | filiais do usuário; o antigo, o banco inteiro |
| recálculo automático | não existe no antigo; decisão do usuário (24/09/2026), com o limite de 30 dias |
| teste de tela | pendente nas duas telas: exercitado contra o banco com conexão que não grava |
Nenhuma regra bate com essa busca. Tente um trecho menor da mensagem, ou limpe os filtros.