O ERP caiu no sábado: o que acontece com as vendas que entraram nesse meio-tempo

Em 1 minuto

Um ERP que cai por um tempo não é raro: há manutenções, atualizações e falhas. O caro é o que acontece com as vendas que entraram nesse meio-tempo. Se cada venda é guardada antes de ser prometida, reenviada com paciência, não se duplica ao ser repetida e o que não passa fica separado com o motivo, a queda vira um trâmite. Se não, vira dias de digitação manual, pedidos em dobro e um fechamento que não bate.

Imagine uma empresa que vende on-line e no balcão. Ela é fictícia, mas se parece com muitas. Num sábado, o ERP dela para de responder. Pode ser uma atualização que se estendeu, um servidor que reiniciou ou um link que caiu; para o que vem a seguir, tanto faz. A loja virtual continua aberta. Os clientes continuam comprando. E cada venda precisa chegar ao ERP para baixar o estoque, registrar a receita e, depois, ser faturada.

Alguém da operação percebe tarde, porque um cliente pergunta pela nota fiscal. Nesse momento a empresa tem três caminhos, embora raramente sejam escolhidos de propósito:

1. Fechar a loja até o ERP voltar. É seguro e é caro: perde-se a venda e, às vezes, o cliente.
2. Continuar vendendo e «digitar depois». Alguém exporta os pedidos para uma planilha e depois os lança à mão. É barato durante a queda e caro no dia seguinte.
3. Continuar vendendo, com cada venda guardada numa espera ordenada, que se põe em dia quando o ERP volta, desenhada para não duplicar e com a lista do que não conseguiu passar.

Este artigo é para quem dirige operação, finanças ou tecnologia numa empresa cujos sistemas dependem uns dos outros. Ele sustenta uma ideia: a queda não é o problema; o problema é não saber o que ficou pendente. E explica, em linguagem de negócio, as cinco peças que fazem do terceiro caminho o normal.

Não é um artigo sobre como escolher entre uma chamada on-line, uma fila ou um evento; isso está em Online ou assíncrono?. Nem sobre reconstruir a história de um pedido; para isso existe O pedido não se perde, perde-se o rastro. Aqui o foco é outro: conservar, dosar e conciliar o que está pendente durante uma queda e na volta.

Tudo o que vem a seguir é genérico de propósito. Vale para um ERP, um sistema de faturamento, uma transportadora ou o sistema de um parceiro: qualquer destino que um dia não responda.

A queda não é o problema: não saber o que ficou pendente

Nenhum sistema responde o tempo todo. Os fabricantes publicam janelas de manutenção, as redes caem e os servidores reiniciam. O próprio padrão da web reserva um código para isso: o 503 indica que o servidor não consegue atender por uma sobrecarga temporária ou uma manutenção programada, que provavelmente se resolverá depois de algum tempo (tradução livre) [7]. Ou seja, a indústria dá como certo que o destino às vezes não estará lá.

O que muda de uma empresa para outra é o que acontece com o que chegou enquanto o destino não estava. E aí aparecem três perguntas que, no dia seguinte, alguém vai fazer em voz alta:

• Quantas vendas entraram enquanto o ERP estava fora do ar?
• Quantas já chegaram, quantas continuam esperando e quantas não vão passar sozinhas?
• Alguma chegou duas vezes?

Se a resposta a qualquer uma for «é preciso verificar», uma queda curta vira dias de trabalho manual e conciliação. E o pior não é o tempo: é que ninguém consegue afirmar com certeza que a lista está completa.

O que acontece em cada momento de uma queda

Convém separar a queda em três momentos, porque em cada um se quebra algo diferente.

As cinco peças a seguir protegem o que entra durante a queda; a seção seguinte cobre a volta e o fechamento.

Cinco peças para que uma queda seja um trâmite

1. Guardar a venda antes de prometê-la

A primeira regra é simples de dizer: a venda é guardada na empresa antes de ser enviada a qualquer lugar. Não na memória do programa que a envia, que se perde se esse programa reiniciar, mas num lugar que sobreviva a uma falha.

A forma mais conhecida de fazer isso tem nome na indústria: a caixa de saída (em inglês, transactional outbox). Ao registrar a venda, no mesmo passo anota-se também «é preciso avisar o ERP». Um processo à parte lê essa caixa e faz o envio. Assim, a venda não fica registrada sem a pendência [3]. Atenção: isso protege o que acontece dentro da empresa; não confirma que o ERP recebeu. Essa confirmação chega depois, quando o ERP responde.

Se entre os dois sistemas houver mensageria, existe uma ideia complementar, a entrega assegurada (em inglês, Guaranteed Delivery): depois que o sistema de mensageria aceita uma mensagem, ele a guarda no armazenamento dele e não a apaga até que o passo seguinte a tenha recebido [6].

Na linguagem do comitê: se o ERP não responde, a venda espera registrada, em vez de se perder.

2. Reenviar com paciência e com espaço

Quando o envio falha, o natural é tentar de novo. E está certo, com dois cuidados.

Paciência: cada nova tentativa espera um pouco mais que a anterior, até um teto, para não tentar demais [1]. Se o ERP vai demorar a voltar, não adianta perguntar a cada segundo. E isso vale para falhas passageiras: se o ERP rejeita uma venda por um dado digitado errado, tentar de novo não resolve (isso fica na peça 5).

Espaço: as novas tentativas de muitas vendas não devem cair no mesmo instante. O guia de novas tentativas da Amazon explica assim: se todas as chamadas que falharam esperam o mesmo tempo, ao tentar de novo elas voltam a chegar juntas e voltam a saturar o destino; a solução é acrescentar um pouco de acaso à espera para distribuí-las no tempo [1]. O mesmo guia resume numa frase que vale levar ao comitê: as novas tentativas são egoístas (tradução livre); cada uma exige que o destino gaste mais recursos para atendê-la e, se o destino já está saturado, tentar de novo piora a sobrecarga em vez de aliviá-la [1].

Se o destino responde com uma sugestão de quanto esperar —o padrão da web prevê um aviso técnico para isso, chamado Retry-After [7]—, ela é levada em conta junto com a regra de novas tentativas combinada.

3. Parar de bater na porta

Há um ponto em que tentar de novo já não ajuda. Se o ERP está há um bom tempo sem responder, enviar cada venda para que falhe uma a uma só gasta recursos dos dois lados e gera falhas repetidas que não ajudam a operar.

Para isso existe o disjuntor (circuit breaker). Martin Fowler o descreve assim: a chamada ao outro sistema é envolvida num objeto que conta as falhas; quando elas chegam a certo limite, o disjuntor «desarma» e as chamadas seguintes voltam com erro sem que a chamada seja sequer tentada; e convém que, ao desarmar, ele avise alguém [2]. Não é qualquer erro que deve desarmá-lo, só as falhas definidas para isso [2]. De tempos em tempos, ele deixa passar um teste controlado; se o destino já responde, o fluxo segue.

Na linguagem do comitê: a empresa fica sabendo da queda por um alerta, não por um cliente que pergunta pela nota fiscal.

4. Repetir não pode duplicar

Esta é a peça que mais protege dinheiro. Uma nova tentativa pode chegar duas vezes: o envio saiu, o ERP registrou, mas a resposta se perdeu no caminho; quem enviou não sabe se chegou e envia de novo. O guia da Amazon diz isso sem rodeios: que uma chamada falhe ou estoure o tempo não significa que o efeito dela não tenha acontecido, e uma operação que tem efeitos não é segura para tentar de novo a menos que tenha sido desenhada para isso [1]. A caixa de saída traz o mesmo alerta: o processo que envia pode mandar uma mensagem mais de uma vez —por exemplo, se cair logo depois de enviá-la e antes de anotar o envio—, então quem a recebe precisa reconhecer o que já processou [3].

A forma de conseguir isso é que cada venda viaje com um número de referência único que o destino reconheça e guarde: se ela chega duas vezes, a segunda não cria um pedido novo, mas responde o mesmo que a primeira. O número de referência só funciona se o destino o comparar de verdade, e isso se testa com cada sistema que participa, inclusive o de cobrança. Os processadores de pagamento fazem assim; a Stripe, por exemplo, guarda a resposta da primeira solicitação com uma chave e, se chega outra com a mesma chave, devolve a resposta guardada em vez de repetir a operação; além disso, compara os dados com os da primeira e conserva a chave por um tempo, não indefinidamente [5]. Essa propriedade se chama idempotência: repetir não muda o resultado.

Na linguagem do comitê: a nova tentativa é desenhada para que o cliente tenha um único pedido e uma única cobrança, e a conciliação do final comprova isso.

5. Separar o que não passa, com o motivo

Nem tudo o que falha é por causa da queda. Algumas vendas não vão passar mesmo com o ERP perfeito: um produto que não existe no catálogo do ERP, um dado fiscal digitado errado, um preço que não bate. Se essas vendas forem reenviadas sem limite, travam as demais e ninguém fica sabendo.

A prática habitual é definir um limite de tentativas e, ao chegar a ele, separar a venda numa fila à parte (em inglês, dead-letter queue). A fila não guarda o motivo sozinha: junto com a venda, anotam-se o erro, a tentativa e quem decide o passo seguinte. A documentação de filas da Amazon descreve assim: define-se quantas vezes uma mensagem é tentada antes de movê-la para essa fila, e separá-las serve para isolar o que não foi processado e descobrir por quê [4].

O importante não é a fila: é que ela tenha dono. Uma venda separada sem responsável é uma venda perdida com um nome melhor.

Quando o ERP volta: a ordem e o ritmo

O momento mais delicado não é a queda: é a volta. Há dois erros frequentes.

Enviar tudo de uma vez. Depois de uma queda longa, pode haver centenas de vendas esperando. Se forem todas enviadas ao mesmo tempo, o ERP recém-levantado recebe uma avalanche e pode cair de novo. É a mesma lição do ponto 2, em grande escala: o pendente é enviado num ritmo que o ERP aguente, e esse ritmo se decide e se testa antes, não no meio da emergência.

Enviar fora de ordem. Se um cliente comprou e depois cancelou, o ERP precisa receber primeiro a compra e depois o cancelamento. Ao contrário, o cancelamento não encontra o que cancelar e a compra continua viva. Para cada venda, define-se a ordem do que acontece com ela —por exemplo, com o número de referência e um número de passo— e a regra para aplicá-la, de modo que o cancelamento não seja processado antes da compra, mesmo que haja novas tentativas. Vendas diferentes podem avançar em paralelo. E se uma venda passou pela fila de separados, essa ordem é respeitada ao devolvê-la; a documentação de filas da Amazon adverte que uma fila de mensagens com falha pode quebrar a ordem das mensagens [4].

E, no final, uma conciliação: o que foi enviado contra o que o ERP confirmou, com a lista do que falta. Não é desconfiança do desenho; é a evidência de que a queda terminou de verdade.

O que o cliente vê nesse meio-tempo

Durante a queda, o ideal é que o cliente perceba só o que de fato depende do ERP. A regra útil é que cada aviso ao cliente saia quando o que ele anuncia já aconteceu:

• «Recebemos o pedido» pode sair na hora, porque a venda já ficou guardada na empresa.
• «A nota fiscal está pronta» só sai quando a nota existir, não antes.
• Se o estoque é controlado no ERP, convém que a loja reserve do lado dela o que foi vendido nesse meio-tempo, para não vender duas vezes a última peça.

Um aviso que sai antes da hora diz algo que ainda não é verdade, e o cliente se lembra disso mais do que da demora.

Os riscos, em linguagem de negócio

Cinco perguntas para o próximo comitê

1. Na última vez que o ERP —ou o sistema de faturamento, ou a transportadora— não respondeu, quantas vendas entraram nesse meio-tempo, e quanto tempo a empresa levou para saber?
2. Onde ficam guardadas essas vendas enquanto o destino não responde? Se a resposta for «no programa que as envia», elas se perdem quando esse programa reinicia.
3. Se uma venda é enviada duas vezes, o ERP cria dois pedidos? Peça à tecnologia que demonstre isso em testes, não que apenas afirme.
4. Quem é o dono das vendas que não passaram sozinhas, e como fica sabendo?
5. Quando o ERP volta, quem decide em que ritmo ele se põe em dia? Se ninguém decidiu antes, decide no meio da emergência quem estiver de plantão.

Se várias respostas forem «não sei», tome isso como sinal para medir o fluxo antes da próxima janela de manutenção.

Por onde começar esta semana

Faça um simulado. Num ambiente de testes, desligue de propósito o destino —o ERP, o faturamento ou o que mais preocupa— durante um período e com um volume de vendas de teste que a equipe defina. Inclua três casos difíceis: uma venda cuja resposta se perde embora o destino a tenha registrado, uma venda que o destino rejeita por um dado digitado errado, e uma venda que é comprada e cancelada durante a queda. Depois, responda por escrito:

• Quantas vendas entraram durante o simulado, e quantas chegaram ao destino quando ele voltou?
• Alguma chegou duas vezes?
• Quais não passaram, e alguém ficou sabendo sem procurá-las?
• Quanto tempo o destino levou para se pôr em dia, e ele aguentou o ritmo?
• Alguém recebeu o alerta da queda, e a conciliação final identifica cada número de referência como confirmado ou pendente?

A planilha que resultar é uma especificação muito concreta do que a operação precisa.

O que a Hábil faz

Na Hábil, construímos sob medida o espaço entre os sistemas da empresa: a loja, o ERP, o faturamento, as transportadoras e os parceiros. É justamente onde se decide o que acontece com uma venda quando o destino não responde.

Se o diagnóstico confirmar que uma queda vira dias de digitação manual, a proposta está no Hábil MDW: a camada que fica entre os sistemas que a empresa já tem, sem substituí-los. Cada envio fica com a resposta ou com o motivo da falha, e as novas tentativas são desenhadas para não repetir o efeito. De cada operação fica o que foi enviado, o que cada sistema respondeu, a que horas e, se falhou, por quê. O escopo, os sistemas que se conectam e o ritmo de recuperação são revisados com o caso.

A conversa pode começar pela última queda de que a empresa se lembre: quanto durou, o que foi feito com as vendas e quanto custou se pôr em dia. Com isso, revisamos juntos onde está o risco na operação. Escreva para nós no WhatsApp; para proteger os clientes, não compartilhe por esse meio números de pedido nem dados pessoais: combinaremos na conversa o canal para o caso.

Peça a primeira conversa, sem custo.

Consultadas em 12 de novembro de 2026. Cada referência traz o nível de confiança: alta (fonte primária lida).