Fluxo de execução principal

Fluxograma completo do método executar(), com 5 etapas e liberação do lock no finally.

Figura 7 — Fluxograma completo do método executar(), com 5 etapas e liberação do lock no finally.

Detalhamento de cada etapa

#	Método	O que faz (simples)	O que faz (técnico)
1	`verificaLock()`	Garante que só uma cópia rode por vez	`flock` exclusivo em arquivo temporário
2	`getPonteiroExecucao()`	Pergunta: "desde quando devo buscar?"	`MAX(execucao)` em `log` onde `procedure='franquia_1beat'`
3	`getPedidoUltimaVerificacao()`	Acha o pedido mais novo no período	`MAX(data)` em movimentação PEDIDO > ponteiro
4	`getPedidosRecebidos()`	Copia e calcula quantidades e status	INSERT com CTEs + ON DUPLICATE KEY UPDATE
5	`atualizaPonteiroExecucao()`	Marca que terminou até tal data	INSERT/UPDATE em `log`

Processamento incremental

O módulo não reprocessa tudo a cada execução. Ele usa um "marcador de página" (ponteiro) para buscar apenas pedidos alterados entre a última execução e a data do pedido mais recente.

Apenas pedidos entre o ponteiro e a data mais recente são processados em cada execução.

Figura 8 — Apenas pedidos entre o ponteiro e a data mais recente são processados em cada execução.

Mensagens de erro comuns

"Ja tem outro processo em execucao, aguarde o termino" — outra instância do executar() está ativa.
"Não foram encontrados pedidos para atualizar" — não há pedidos novos desde o ponteiro.
"Nao foi possivel criar o arquivo de lock" — problema de permissão no diretório temporário.
"Erro ao inserir/atualizar pedidos recebidos na franquia_1beat." — falha no INSERT/UPDATE principal.

Tratamento de erros: exceções no executar() são capturadas e enviadas a error_byexception(). Os métodos intermediários (getPedidosRecebidos, atualizaPonteiroExecucao) também possuem try/catch interno que retorna null em falha. O lock é sempre liberado no bloco finally.