Regras de negócio e situações
O módulo lê a situação do pedido na tabela movimentacao e traduz para o campo SITUACAO da tabela destino.
Figura 13 — Pedidos abertos e cancelados viram DESATIVO e são removidos da tabela após a sincronização.
Regra da quantidade pendente
| Pedido | Recebido | Pendente | Explicação |
|---|---|---|---|
| 10 | 7 | 3 | Caso normal: faltam 3 unidades |
| 10 | 10 | 0 | Pedido completo |
| 10 | 0 | 10 | Nada recebido ainda |
| 5 | 8 | 0 | Recebido a mais: pendente nunca fica negativo |
Entrada confirmada
O campo ENTRADA_CONFIRMADA indica se o pedido foi finalizado no ERP:
| Valor | Significado | Condição |
|---|---|---|
| 1 | Entrada confirmada | m.situacao = 'FINALIZADO' |
| 0 | Entrada não confirmada | Qualquer outra situação |
Recebimentos considerados
Para contar como "recebido", uma movimentação filha deve atender todos estes critérios:
- Estar vinculada ao pedido pai via
movimentacao_movimentacao - Ter situação
'Finalizado'(com F maiúsculo) - Ter itens ativos com
id_produto_gradepreenchido
Recebimentos em andamento ou cancelados não entram no cálculo de QTDE_RECEBIDA.
Processamento incremental
Figura 14 — O módulo foi projetado para rodar repetidamente, processando apenas o que mudou desde a última vez.
Concorrência — apenas uma execução por vez
O que acontece quando não há pedidos novos?
Se não existir nenhum pedido com data maior que o ponteiro, o método getPedidoUltimaVerificacao() lança uma exceção: "Não foram encontrados pedidos para atualizar". A execução é interrompida, o lock é liberado, e nada é alterado na tabela destino.
Ponteiro inicial
log), o ponteiro padrão é 2000-01-01 00:00:00, ou seja, todos os pedidos desde essa data serão considerados.