Cross Segmento - Backoffice (Linha Protheus) - SIGAEST - "Erro na chamada do processo" em rotinas de Processamento

Dicionários inconsistentes, em desacordo com o esperado pelo processamento em questão.

Um exemplo recorrente é o parâmetro MV_M330JCM estar com tipo diferente de C - caracter (que é o correto). Caso esteja, altere para tipo C e realize um novo teste. Detalhes do parâmetro aqui: https://tdn.totvs.com/pages/releaseview.action?pageId=354452990

Outro exemplo recorrente é o parâmetro MV_CUSTEXC não estar configurado como "Compartilhado" (filial em branco) impedindo o acesso da Filial em questão.

É essencial que as procedures estejam atualizadas contemplando as mais novas correções e inovações. Lembrando que atualizações devem primeiramente ser homologadas em ambiente/base Teste, e que após as atualizações, é importante reinstalar as procedures.

• Aplicar as atualizações: Acumulado SIGAEST conforme sua versão | Gestor de Procedures V.1.6.2
• Após as atualizações, desinstale as procedures 14 a 22;
• Faça um backup e delete a Stored Procedure da pasta \SYSTEM.
  
• Reinicie o TOPConnect.
• Execute o processamento da rotina em questão para se certificar que não ocorre nenhum erro;
• Cole a Stored Procedure na pasta \SYSTEM.
• Reinstale as procedures 14 a 22 com o novo gestor.

Detalhes aqui sobre como instalar as Stored Procedures

- Registro gravado com o campo B6_IDENT vazio / em branco;

- Campo B6_TPCF vazio ou divergente do cliente/fornecedor envolvido nas notas SD1 (D1_TIPO) e SD2 (D2_TIPO);

- Cliente/Fornecedor envolvido no poder de terceiros excluído na base de dados (referência inválida);

- Documento fiscal (ex SD1) não classificado. xx_IDENTB6 em branco, porém D1_TES preenchido, fazendo com que a rotina entendesse que o saldo foi realmente inserido no sistema.

Importante: Aqui estão listados alguns exemplos recorrentes, porém, não há como indicar com precisão qual o dado incorreto em sua base, sem a devida análise nos registros da base.

É necessário que analise os dados gravados no banco (obs: essa análise de registros no banco não é contemplada pelo atendimento de Suporte técnico na modalidade padrão. Havendo necessidade de análise da base, na falta de uma equipe interna de TI, recomenda-se a solicitação de consultor à seu ESN).

Para otimizar esse processo de validação da base, recomenda-se que tente processar a rotina utilizando um range menor de dados, ao invés de "Produto 'em branco' até 'zzzzz'"

Com um range menor, é mais provável chegar ao produto exato que ocasiona o problema no processamento.

Exemplo:

- Filtro do produto 000 até 500. Não apresentou erro;

- Filtro do 501 até 1000. Não apresentou o erro;

- Filtro do 1001 até 2000. É apresentado o erro.

Sabe-se então que o problema é no processamento de algum produto entre 1001 e 2000.

- Filtro então do produto 1001 até 1500. Não apresentou o erro;

- Filtro do produto 1501 até 1700. Não apresentou o erro;

- Filtro do produto 1701 até 2000. É apresentado o erro.

Sabe-se então que o problema é no processamento de algum produto entre 1701 e 2000.

E assim consecutivamente.

Então assim sendo, reduzir a extensão entre esses dados, até chegar no causador.

Ao localizar o produto causador do erro na chamada do processo, poderá validar a integridade do registro, bem como, comparar com outros registros que não apresentam o erro, para identificar qual a falha do dado gravado.

(Obs: com base nessa localização, pode-se inclusive mapear em segunda instância, através de novas simulações, o que estaria interferindo na gravação incorreta desse dado).