Se você já se deparou com mensagens de erro relacionadas a chaves duplicadas ou problemas no fechamento do custo médio no TOTVS Protheus, é muito provável que o campo D3_NUMSEQ e seus mecanismos de controle tenham cruzado o seu caminho.

Neste artigo, vamos explorar a fundo como este campo funciona, o porquê de problemas de duplicidade surgirem na tabela de movimentação de produção (SD3), e o que você precisa conferir no seu ambiente para manter a operação blindada.

O que é e como é gravado o D3_NUMSEQ?

O D3_NUMSEQ é um campo essencial na tabela SD3 (Movimentos de Estoque / Produção). Ele representa uma numeração sequencial única gerada pelo sistema para cada linha de movimentação.

Sua principal finalidade é estabelecer uma cronologia absoluta e a rastreabilidade exata dos insumos e produtos gerados, dados vitais para o cálculo correto do Custo Médio.

A Evolução: Do MV_DOCSEQ ao License Server (NEWPROXNUM)

Historicamente, o controle de qual seria o próximo número sequencial ficava centrado quase que exclusivamente no parâmetro MV_DOCSEQ.

No entanto, com a modernização das releases do Protheus (especialmente a partir da 12.1.2410), o sistema passou a adotar funções nativas como o NEWPROXNUM, que delega a geração atômica e segura das sequências para o TOTVS License Server.

• A Chave no License Server: Para gerenciar isso de forma centralizada e sem concorrência entre múltiplas threads, o License Server cria chaves estruturadas no formato:$$\text{@@@SD2+empresa+0}$$Onde o prefixo @@@ indica uma chave especial de controle, SD2 (ou tabelas irmãs como SD1/SD3) o escopo, seguida pela empresa/filial e o particionamento.
• A Diretiva CheckSpecialKey: Para que o License Server autorize e processe essas chaves especiais com segurança, é obrigatório que a diretiva CheckSpecialKey=1 esteja devidamente configurada e ligada na seção [GENERAL] do arquivo de configuração do seu AppServer (appserver.ini). Se ela estiver desligada (0), o sistema bloqueará a operação.

O Problema: Por que ocorrem duplicidades no D3_NUMSEQ?

O erro de duplicidade ocorre quando o sistema tenta gravar um valor de D3_NUMSEQ que já existe na base de dados, gerando rejeições nas rotinas de apontamento de produção ou movimentações internas. Os principais motivos para isso incluem:

1. Desalinhamento de Parâmetro ou Cache: Quando customizações ou rotinas legadas ainda tentam manipular diretamente o parâmetro MV_DOCSEQ, dessincronizando-o do maior valor real gravado na tabela SD3.
2. Ambientes Múltiplos com a mesma SpecialKey: Em cenários de homologação e produção compartilhando a mesma chave de identificação no License Server, os contadores de numeração sequencial podem entrar em conflito.
3. Falta de Validação de Chaves de Segurança: Ambientes onde chaves essenciais de integridade do servidor de licença não estão ativadas corretamente.

Pontos de Verificação: O que conferir para evitar a duplicação?

Para garantir que o seu ambiente processe os movimentos de produção sem riscos de duplicidade no D3_NUMSEQ, certifique-se de validar os seguintes pontos cruciais:

1. Ativação da Chave CheckSpecialKey

Certifique-se de que a chave CheckSpecialKey está devidamente ligada na seção [GENERAL] do arquivo de configuração do seu servidor (AppServer.ini). Essa chave garante a checagem rigorosa de licenças e identificadores de ambiente, evitando conflitos de numeração sequencial entre bases distintas (como homologação apontando para o servidor de produção).

2. Isolação de Ambientes (SpecialKey Exclusiva)

Cada ambiente (seja ele Produção, Teste ou Homologação) deve possuir uma SpecialKey exclusiva configurada no AppServer.ini. Isso assegura que o License Server trate a contagem de sequências de forma isolada para cada base de dados.

3. Atenção a Customizações e ao Parâmetro MV_DOCSEQ

Revise se existem fontes AdvPL customizados que manipulam ou gravam valores fixos no parâmetro MV_DOCSEQ. Com o comportamento moderno das releases atuais, o controle deve ser delegado integralmente às funções nativas do License Server, evitando saltos ou recontagens incorretas.

4. Auditoria de Rastreio (I_N_S_D_T_)

Aproveite os recursos de auditoria nativos das releases mais recentes. O campo complementar I_N_S_D_T_ (presente nas tabelas SD1, SD2 e SD3) registra a data e hora exata da inclusão física do registro no banco de dados, facilitando a identificação de momentos exatos de concorrência em análises de log junto com o DBA.

Como agir em caso de registros já duplicados?

Se a duplicidade já ocorreu na base de dados, a recomendação padrão dos canais de atendimento da TOTVS orienta:

• Avaliar o Estorno: Sempre que possível, realize o estorno do documento de origem para que o sistema possa gerar novamente o registro sem repetir a chave sequencial, após a devida correção dos parâmetros.
• Saneamento por DBA: Caso o estorno não seja viável devido ao fechamento de estoque ou complexidade fiscal, recomenda-se o acionamento de um analista de banco de dados para a correção pontual dos registros afetados, ou a abertura de chamado técnico especializado na TOTVS.

Manter o ecossistema atualizado, com as chaves do License Server bem configuradas e sem interferências de rotinas legadas, é o segredo para uma produção sem sobressaltos e com um custo médio 100% íntegro!

Fontes:

TOTVS Central de Atendimentos – Salto de Numeração ou registros Duplicados no NUMSEQ

TOTVS Central de Atendimentos – CheckSpecialKey

TOTVS – Validação SpecialKey

TOTVS – Parâmetro MV_DOCSEQ

Autor: