Gestão de pedidos
Por que a numeração de pedidos não é sequencial?
PEDIDOS.FAQ-15967
Abaixo seguem alguns motivos que fazem com que a numeração de pedidos não seja sequencial:
Tipos de pedidos
A numeração de pedidos é a mesma para todos os tipos de pedido, como por exemplo: pedidos de venda, ordens de serviço, ordens de compra, orçamentos, etc.
Isso significa, por exemplo, que em determinado estabelecimento, as emissões poderiam ser as seguintes:
| Tipo de pedido: | Número
|
|---|
| Pedido de venda | 100
|
| Ordem de serviço | 101
|
| Ordem de compra | 102
|
| Orçamento | 103
|
| Ordem de serviço | 104
|
| Pedido de venda | 105
|
| Ordem de compra | 106
|
| Ordem de serviço | 107
|
| Orçamento | 108
|
| Pedido de venda | 109
|
| Ordem de compra | 110
|
Desta forma, consultando determinado tipo de pedido seriam identificados vários "buracos" na sequência da numeração:
| Tipo de pedido: | Números:
|
|---|
| Pedido de venda: | 100, 105, 109
|
| Ordem de serviço: | 101, 104, 107
|
| Ordem de compra: | 102, 106, 110
|
| Orçamento: | 103, 108
|
Replicação
Quando a empresa trabalha com bases replicadas, faixas de sequências são distribuídas entre as bases de dados de forma a impedir que pedidos gerados em bases separadas sejam identificados com o mesmo número. O mecanismo de distribuição das sequências é configurado através do campo "Range size" da sequence "SEQ_PEDIDO" da interface Sequências. Este campo define o tamanho do "lote" de números que é distribuído para aquela base de dados.
Digamos, por exemplo, que uma empresa possua 3 estabelecimentos replicados (um servidor em cada estabelecimento) formados por uma matriz e duas filiais e que as filiais sejam configuradas com "Range size" de 50. Quando os servidores das filiais começarem a replicar, cada um irá consumir 50 números de pedidos do servidor da matriz. Assim, em uma situação inicial, teríamos algo como:
| Pedidos | Estabelecimento |
|
|---|
| 1 a 50 | Matriz |
|
| 51 a 100 | Filial 1 |
|
| 101 a 150 | Filial 2 |
|
| 151 a 200 | Filial 1 |
|
| 201 a 250 | Matriz |
|
| ... | |
|
E assim sucessivamente, sempre que acabar a numeração de um determinado estabelecimento, serão liberados 50 novos números para o mesmo.
Cache de memória
Também existe um recurso de "cache" utilizado para acelerar a distribuição de novos números de pedidos para o sistema. Este recurso é utilizado apenas em ambientes onde existe uma geração muito grande de pedidos a todo o momento.
Este recurso é definido informando-se um número maior do que 1 no campo "Cache" da interface Sequências. Quando ativo, toda a vez que o servidor for reiniciado pode-se perder um determinado número da sequência.
Por exemplo, se o cache estiver configurado em 10, pode-se perder até (no máximo) 9 números quando o servidor for reiniciado, ou seja, se o último pedido gerado tivesse o número 355, após a reinicialização do servidor, o próximo pedido poderia pular para 365.
Pedidos excluídos
A numeração do pedido é consumida imediatamente na sua criação. Ou seja, quando um pedido for iniciado, e salvo, ficando na situação "Em manutenção" e após isso for excluído, essa numeração será perdida, não sendo possível utilizar o número desse pedido novamente.
Considerações finais
Assim como o RG de uma carteira de identidade ou a placa de um veículo, a numeração dos pedidos é apenas um meio de identificação do mesmo. O principal objetivo é ter uma forma de localizar o pedido de forma direta, simples e inequívoca.
Não é possível voltar a numeração de pedidos, ou seja, aqueles números que estão "faltando" não poderão ser reutilizados, pois a numeração de pedidos continua de forma crescente a partir do último número utilizado, seguindo as regras mencionadas anteriormente.
A limitação de numeração de pedidos no sistema é de 9223372036854775807, ou seja, mesmo emitindo 1 bilhão de pedidos por dia, teríamos números disponíveis para operar alguns bilhões de anos.
Ver também: