Gerador de Código de Pedido

Como desenhar um bom código de pedido

Um código de pedido — order number em inglês — é o identificador único que o varejista atribui a cada transação comercial. Ele percorre o checkout, o gateway de pagamento, o WMS, a engine de NF-e, a etiqueta de envio, as APIs de marketplace e finalmente o ticket de atendimento. Código ruim gera pedido perdido, reembolso fantasma e cliente bravo no telefone; código bem desenhado é curto, ordenável, único e legível por humano.

O padrão típico combina três blocos: um prefixo (ORD, PED, SO de Sales Order, PO de Purchase Order), um componente de data ou epoch e uma sequência com dígito verificador opcional. Exemplos em produção hoje: PED-2026-001234, SO20260615123, ORD-2026-06-0001234.

Propriedades de um ID robusto

• Único em todos os canais e janelas de tempo.
• Monotônico (ou pelo menos quase crescente) — útil para sharding, indexação e ordenação por recência.
• Legível por humano — o atendimento lê pelo telefone; 8 a 12 caracteres é o ponto doce.
• Ciente de canal e ambiente — embutir flags para DEV, STAGING, PROD e para pedidos online / loja física / B2B / marketplace.
• Resistente a colisão — combinar timestamp, serial e salt aleatório.

Algoritmos comparados

UUID v4 é à prova de colisão mas ilegível — péssimo para suporte por telefone. Snowflake IDs (originalmente do Twitter) embutem timestamp e ID de máquina, têm 64 bits, são monotônicos e amigáveis para sharding. NanoID é URL-safe e mais curto que UUID. O favorito pragmático do e-commerce brasileiro é prefixo + contador + dígito verificador, às vezes com reset diário e um caractere estilo Luhn para detectar erro de digitação quando o atendente redigita.

Pontos de integração

Códigos de pedido fluem pela stack inteira: ERPs (SAP, TOTVS, Bling, ContaAzul, Omie), CRMs (HubSpot, Salesforce, RD Station), marketplaces (Mercado Livre, Magazine Luiza, Amazon BR, Shopee) e transportadoras (Correios, Jadlog, Loggi). Em portais B2B de fornecedor, cada cliente pode ter seu próprio esquema de numeração, que precisa ser armazenado junto com o ID interno do varejista. No Brasil, o código deve constar na NF-e — geralmente no campo xPed ou nas observações infCpl — para que o fisco concilie nota e pedido.

Ciclo de status do pedido

Fluxo canônico: criado → confirmado → pago → separado → embalado → enviado → saiu para entrega → entregue → (eventualmente) devolvido → reembolsado. Alguns varejistas expõem uma versão resumida ao cliente (Pedido recebido / Em preparação / Enviado / Entregue) e mantêm os estados granulares internos. IDs amigáveis ("Pedido P-123-ABC") com emoji são comuns em marcas D2C.

Perguntas frequentes

Aleatório ou sequencial? Híbrido é o melhor — contador sequencial diário mais sufixo aleatório curto, para concorrentes não scrapparem o volume a partir de IDs sequenciais.

Posso reiniciar o contador todo ano? Sim, desde que o ano faça parte do prefixo (PED-2026-0001). Sem prefixo de ano, o reset quebra idempotência nos sistemas downstream.

O código precisa ser visível ao cliente? Sim — exibir na página de confirmação, no e-mail de comprovante e na tela de rastreio do envio, para que o comprador referencie em qualquer contato com o suporte.

Devo expor IDs internos na URL? Evite. Use um token opaco ou identificador com hash na URL pública e mantenha o número sequencial bruto apenas internamente — previne ataques de enumeração e scraping competitivo.