Erros comuns de replicação

MÓDULO: Serviços > Replicação > Erro Guia de erros comuns de replicação entre matriz e filial Identifique sintoma, causa e solução para os problemas mais comuns que travam a replicação entre bases. Este guia reúne os problemas mais frequentes que interrompem a replicação de dados entre matriz e filial (ou entre bases), organizados por sintoma e causa. Cada tópico abaixo traz o cenário, a causa confirmada e o passo a passo ou encaminhamento necessário para normalizar a replicação. Replicação parada por registro já existente na base de destino Este manual se aplica quando a replicação de dados entre matriz e filial (ou entre bases) para de processar porque um comando tenta inserir ou atualizar um registro (usuário, produto, título financeiro, conta contábil, item de PCP, entre outros) que já existe de forma idêntica na base de destino. O resultado esperado é a normalização da fila de replicação após a confirmação de que os dados já estão consistentes entre as bases. Sintoma A replicação para de processar novos comandos. Em alguns casos o cliente percebe um cadastro (usuário, cliente, produto) que não aparece replicado em uma unidade específica; em outros, um erro de duplicidade ou de chave é relatado ao suporte. Causa confirmada Um comando de inclusão (ou atualização) tenta gravar um registro que já existe, de forma idêntica, na base de destino. Isso ocorre normalmente quando o mesmo dado é cadastrado diretamente nas duas bases, quando há oscilação de comunicação que faz reenvio de comandos já processados, ou quando uma trigger de duplicidade barra o comando. Essa divergência bloqueia o processamento da fila, impedindo que os comandos seguintes sejam processados. Passo a passo 1 Verificar se o cadastro realmente não está replicado Confirme, na tela do cadastro afetado (usuário, cliente, produto, etc.), se o registro está de fato ausente ou divergente na unidade de destino, ou se apenas parece ausente por outro motivo (filtro, permissão de acesso). 2 Abrir chamado com os detalhes do cadastro afetado Caso o registro esteja realmente ausente ou divergente, abra um chamado em: atak.movidesk.com informando qual cadastro (usuário, cliente, produto, título, conta contábil) não está sincronizado e em quais unidades/bases o problema ocorre. 3 Comparar os dados entre as bases envolvidas O suporte compara o registro na base de origem e na base de destino para confirmar se as informações já estão consistentes e idênticas. 4 Liberar o comando bloqueado na fila de replicação Com a consistência confirmada, o suporte trata (ignora) o comando específico que estava causando o bloqueio, permitindo que a fila de replicação volte a processar normalmente. 5 Acompanhar a normalização da fila O suporte acompanha o processamento até que todos os comandos pendentes sejam concluídos e a replicação seja restabelecida. ⚠ Importante O comando só deve ser ignorado após confirmação de que os dados já estão consistentes entre as bases. Ignorar um comando sem essa validação pode causar perda de sincronismo entre matriz e filial. 📌 Observações Em alguns casos, a divergência foi relacionada a itens de PCP (planejamento e controle da produção) que não foram gerados automaticamente em uma das filiais no momento do cadastro do item. Em um dos atendimentos, o mesmo tipo de problema (cadastro não replicado) foi resolvido bloqueando e desbloqueando novamente o cadastro do cliente na origem, ao invés de tratar o comando na fila — alternativa mais simples quando a replicação em si não apresenta erro (solução não validada pelo cliente). Em alguns atendimentos, a divergência estava em um único caractere de formatação entre os dados (por exemplo “0” em uma base e vazio na outra) — o princípio de verificação é o mesmo: comparar e confirmar consistência antes de liberar o comando. Parte dos atendimentos referentes a este padrão foi encerrada automaticamente pelo sistema sem confirmação explícita do cliente (solução não validada pelo cliente). Replicação bloqueada por documento vinculado a lote da escrita fiscal Este manual se aplica quando a replicação entre bases é interrompida porque um comando tenta alterar ou excluir informações de um documento que ainda está vinculado a um lote da escrita fiscal na base de destino. O sistema possui uma validação interna que impede essa alteração enquanto o vínculo existir, bloqueando o processamento da fila de replicação. Sintoma A replicação para de processar comandos. O sistema pode apresentar uma mensagem informando que a alteração do lançamento não é permitida porque o documento está na escrita fiscal. Causa confirmada A replicação executa os comandos em uma ordem específica: primeiro tenta remover informações do documento e, somente depois, excluir esse documento do lote da escrita fiscal. Quando o primeiro comando é executado no banco de destino, o documento ainda está vinculado ao lote, e uma validação interna do sistema bloqueia o processo. Passo a passo 1 Relatar o erro ao suporte Abra um chamado em: atak.movidesk.com informando que a replicação está parada e, se disponível, a mensagem de erro exibida pelo sistema. 2 Identificar o documento e o lote envolvidos O suporte analisa a fila de replicação para localizar o documento vinculado ao lote da escrita fiscal que está causando o bloqueio. 3 Remover o vínculo do documento com o lote na base de destino O suporte solicita ou realiza a remoção manual do documento do lote da escrita fiscal diretamente na base de destino. 4 Conferir a quantidade de documentos do lote em ambas as bases Confira, com apoio do suporte, se a quantidade de documentos do lote está igual nas duas bases. Caso haja divergência, pode ser necessário excluir os documentos inconsistentes na base de origem e realizar o lançamento novamente. 5 Acompanhar a normalização da fila de replicação Após a remoção do vínculo, a replicação volta a processar os comandos pendentes normalmente. ⚠ Importante Quando a fila acumula um grande volume de comandos pendentes por causa desse bloqueio, o tempo de normalização completa pode ser significativamente maior. 📌 Observações O mesmo tipo de bloqueio pode ocorrer mais de uma vez durante o mesmo atendimento, se houver mais de um documento vinculado a lotes pendentes. Parte dos atendimentos referentes

Erro 405 ao salvar no V2 causado pelo módulo WebDAV do IIS

MÓDULO: Instalação e Configuração Como resolver o erro 405 ao salvar no V2 causado pelo módulo WebDAV do IIS? Como identificar e corrigir o erro 405 (verbo HTTP inválido) exibido ao salvar registros no V2, causado pelo módulo WebDAVModule ativo no IIS. Contexto do erro O problema foi identificado ao acessar o caminho V2 > Tabelas Auxiliares > Cadastro de Mensagens. Ao realizar a edição de uma mensagem e acionar a opção de salvar, o sistema apresenta erro. Evidência do erro Mensagem do erro: A página que você está procurando não pode ser exibida porque um método inválido (verbo HTTP) está sendo usado. Causas mais prováveis A solicitação enviada ao servidor Web usou um verbo HTTP que não é permitido no módulo configurado para tratar a solicitação. Foi enviada ao servidor uma solicitação que continha um verbo HTTP inválido. A solicitação é de conteúdo estático e contém um verbo HTTP diferente de GET ou HEAD. Foi enviada a um diretório virtual uma solicitação que usou o verbo HTTP POST, e o documento padrão é um arquivo estático que não oferece suporte para verbos HTTP diferentes de GET ou HEAD. Ações que você pode tentar Verifique a lista de verbos habilitados para o manipulador de módulo ao qual essa solicitação foi enviada, e verifique se esse verbo deve ser permitido no site. Verifique no arquivo de log do IIS qual verbo não é permitido na solicitação. Crie uma regra de rastreamento para controlar as solicitações com falha desse código de status HTTP. Informações detalhadas sobre o erro Módulo: WebDAVModule Notificação: MapRequestHandler Manipulador: aspNetCore Código do erro: 0x00000000 URL solicitada: http://172.20.1.142:8080/corev2/mensagem/editada Caminho físico: C:\inetpub\ERPATAXX\nho\COREV2\mensagem\editada Método de logon: Anônimo Usuário de logon: Anônimo Causa O módulo WebDAV pode estar ativo no IIS e interferir nas requisições da aplicação, bloqueando métodos HTTP como POST, PUT e DELETE. Esse comportamento gera o erro 405 ao tentar executar ações como salvar registros. Procedimento de correção Opção 1 — Remoção direta pelo IIS (recomendada) 1 Acessar o IIS (Gerenciador do IIS) 2 Selecionar o site afetado 3 Abrir a opção Módulos 4 Localizar o item WebDAVModule 5 Clicar com o botão direito e selecionar Remover 6 Testar novamente a aplicação Resultado esperado: o sistema volta a funcionar normalmente, sem necessidade de reiniciar o servidor. Opção 2 — Desativação via recursos do Windows Utilizar essa opção caso a remoção direta não resolva. Windows 10 / Desktop Acessar o Painel de Controle. Ir em Programas > Ativar ou desativar recursos do Windows. Navegar até: Serviços de Informações da Internet (IIS) > Serviços da World Wide Web > Recursos HTTP Comuns. Localizar Publicação WebDAV. Desmarcar a opção. Confirmar alterações. Reiniciar a máquina. Windows Server Abrir o Gerenciador do Servidor (Server Manager). Clicar em Gerenciar > Remover Funções e Recursos. Avançar até Funções do Servidor. Navegar até: Servidor Web (IIS) > Servidor Web > Recursos HTTP Comuns. Desmarcar Publicação WebDAV. Concluir o assistente. Reiniciar o servidor. Validação Após a aplicação da correção: Acessar o sistema. Repetir o processo: V2 > Tabelas Auxiliares > Cadastro de Mensagens > Editar uma mensagem > Salvar. Confirmar que o erro não ocorre mais. 📌 Observações Em alguns casos, o WebDAV pode já ter sido removido, mas ainda estar ativo em memória. Nessa situação, a reinicialização do servidor é necessária. A remoção via IIS costuma resolver de forma imediata e mais rápida.

Erro 500.19 ao abrir o ERP V2 no IIS por falta do ASP.NET Core Hosting Bundle

MÓDULO: Instalação e Configuração Como resolver o erro 500.19 ao abrir o ERP V2 no IIS por falta do ASP.NET Core Hosting Bundle? Como corrigir o erro HTTP 500.19 que impede o ERP V2 de iniciar no IIS, causado pela ausência do módulo AspNetCoreModuleV2. Problema Ao acessar o módulo V2 do ERP via IIS, a aplicação não carrega e retorna o erro: HTTP 500.19 — Internal Server Error Código: 0x8007000d O erro ocorre imediatamente ao tentar acessar a aplicação, antes da execução do sistema. Sintoma Acesso ao ERP V2 retorna erro 500.19 no IIS. Aplicação não inicia. Falha acontece na leitura do web.config. Causa raiz O servidor IIS não possui o módulo necessário para execução de aplicações ASP.NET Core: AspNetCoreModuleV2 (ANCM — ASP.NET Core Hosting Module). O web.config da aplicação contém a dependência modules=”AspNetCoreModuleV2″. Quando o módulo não está instalado ou registrado no IIS, o servidor não consegue interpretar a configuração e retorna erro 500.19. Cenários comuns Servidor novo sem Hosting Bundle instalado. IIS instalado após o .NET Runtime. Migração de aplicação sem dependências completas. Ambiente sem registro do módulo ASP.NET Core no IIS. Solução 1 Instalar o ASP.NET Core Hosting Bundle Instalar o ASP.NET Core Hosting Bundle compatível com a versão da aplicação (exemplo: .NET 8). O pacote deve conter: ASP.NET Core Runtime, .NET Runtime e AspNetCoreModuleV2 (obrigatório para IIS). 2 Baixar o Hosting Bundle A instalação deve ser realizada através do site oficial da Microsoft: dotnet.microsoft.com/download/dotnet/8.0. Dentro da página, acessar a seção “ASP.NET Core Runtime 8.x”, localizar a linha referente a Windows e selecionar a opção Hosting Bundle (x64). ⚠ Importante Não utilizar apenas “Runtime” ou “SDK”. Apenas o Hosting Bundle instala o módulo AspNetCoreModuleV2 necessário para o IIS. 3 Reinicializar o IIS (se necessário) Executar o comando iisreset. Em alguns casos, o módulo é carregado automaticamente após a instalação. 4 Testar Acessar novamente o ERP V2 via navegador, pelo caminho /v2. Resultado esperado IIS reconhece o módulo AspNetCoreModuleV2. web.config é interpretado corretamente. Aplicação ASP.NET Core inicia normalmente. Erro 500.19 é eliminado. Conclusão O incidente é causado exclusivamente pela ausência do ASP.NET Core Hosting Bundle no servidor IIS, resultando na falta do módulo AspNetCoreModuleV2 necessário para execução da aplicação.

Alteração de relatórios ErpAtak/Sisatak

MÓDULO: Serviços > Relatórios ErpAtak \ Sisatak > Alteração Como solicitar alteração em relatório do ErpAtak / Sisatak Entenda o fluxo de orçamento, aprovação e execução de alterações em relatórios do sistema. Visão geral Este manual explica como funciona o processo de solicitação de alteração, inclusão de campo/movimento ou personalização de relatórios do ErpAtak/Sisatak. Diferente de um problema de sistema, este é um serviço sob orçamento: qualquer alteração em relatório passa por uma etapa de aprovação de custo antes de entrar na fila de desenvolvimento. Entender esse fluxo evita atrasos e permite acompanhar o andamento do próprio chamado. Quando utilizar Sempre que for necessário alterar um relatório já existente do sistema — por exemplo, incluir um novo campo, adicionar um movimento a um filtro, mudar layout, orientação de página ou incluir uma nova coluna de informação. ⚠ Importante Este fluxo se aplica exclusivamente a relatórios personalizados do cliente. Relatórios padrão do ErpAtak/Sisatak não são alterados pelo suporte por esse serviço — nesses casos, o chamado precisa ser encaminhado ao time de desenvolvimento, que avalia e decide se a alteração será realizada. Como funciona O cliente abre o chamado no serviço “Suporte > Serviços > Relatórios ErpAtak \ Sisatak > 02 – Alteração”, descrevendo o relatório e a alteração desejada. O suporte analisa o pedido e, quando necessário, solicita informações complementares (por exemplo, o código do relatório, um PDF de exemplo ou os movimentos envolvidos). O suporte envia um orçamento de horas técnicas necessárias para a execução do serviço. Esse valor é sempre um mínimo estimado, podendo se estender conforme a complexidade real do ajuste. O orçamento tem validade de 10 dias para aprovação. Se não for aprovado dentro desse prazo, o chamado é encerrado automaticamente. Após a aprovação, o chamado entra na fila de atendimento para desenvolvimento. Quando a alteração é concluída, o relatório é disponibilizado para validação do solicitante. Se, após a disponibilização para validação, o chamado ficar muito tempo sem retorno do cliente, ele é encerrado automaticamente pelo sistema. 1 Abrir o chamado descrevendo a alteração Descreva o relatório a ser alterado e o que precisa mudar. Sempre que possível, anexe um exemplo do relatório atual e indique com clareza o campo, movimento ou filtro envolvido — isso evita idas e vindas na etapa de análise. 2 Aprovar o orçamento enviado pelo suporte Ao receber o orçamento de horas técnicas, aprove-o dentro do chamado. No menu lateral do chamado, acesse o campo “Aprovação de Orçamento” e selecione Aprovar ou Reprovar. O orçamento é válido por 10 dias; após esse prazo sem aprovação, o chamado é fechado automaticamente. 3 Acompanhar a execução Após a aprovação, o serviço entra na fila de desenvolvimento. O técnico responsável poderá solicitar acesso ao servidor ou informações adicionais para dar continuidade. 4 Validar o resultado Quando o relatório alterado for disponibilizado, teste o resultado e informe no próprio chamado se atende ao solicitado. Essa validação é o que confirma o encerramento do atendimento. ⚠ Importante Se houver desistência da solicitação ou ausência de retorno do cliente/terceiros após a aprovação do orçamento, sem decisão direta da Atak, o tempo já trabalhado pelo técnico é cobrado normalmente. Conteúdo Relacionado → Manual: Cobrança de horas técnicas após desistência de alteração de relatório → Siga o passo a passo completo clicando no manual acima para entender a cobrança de horas técnicas quando há desistência da alteração após a aprovação do orçamento 📌 Observações Dúvidas sobre o serviço solicitado ou sobre o processo de orçamento devem ser esclarecidas antes da aprovação. Aprovar o orçamento implica ciência das condições do serviço. Relatórios que já foram alterados diretamente pelo cliente fora do padrão originalmente fornecido pela Atak não recebem manutenção do suporte. Nesses casos, a alteração deve ser conduzida pelo próprio cliente. Se a análise técnica identificar que a estrutura atual do relatório não comporta a alteração pedida, pode ser necessário o desenvolvimento de um novo relatório, o que gera um orçamento revisado antes de prosseguir. ⚠ Atenção — Aviso de Escopo As causas e soluções acima são baseadas exclusivamente nos atendimentos analisados. Situações não listadas devem ser abertas como novo chamado em: atak.movidesk.com

Suporte não altera relatório já modificado por terceiros

DÚVIDA · SERVIÇOS > RELATÓRIOS ERPATAK / SISATAK Por que o suporte não altera um relatório que já foi modificado por mim ou por terceiros? Relatórios alterados fora do padrão original da Atak ficam fora da manutenção do suporte. Contexto Produto/Módulo: Serviços > Relatórios ErpAtak / Sisatak > Alteração Situação: o cliente abre um chamado pedindo alteração em um relatório do sistema. Condição: o relatório em questão já foi alterado diretamente pelo próprio cliente ou por terceiros, usando uma ferramenta externa de edição, fora do padrão originalmente entregue pela Atak. Termos relevantes: nenhuma sigla adicional além das já conhecidas do fluxo de chamados. Por que isso acontece? O suporte da Atak mantém e altera apenas relatórios que seguem a estrutura padrão originalmente fornecida pelo sistema. Quando um relatório é editado diretamente pelo cliente ou por terceiros, fora desse padrão, o suporte perde a garantia de que a estrutura interna do arquivo é compatível com o processo normal de manutenção. Por isso, esse tipo de relatório fica fora do escopo de atendimento do serviço de alteração. Como resolver? Se o relatório já foi alterado fora do padrão Atak, a alteração adicional deve ser conduzida pelo próprio cliente (ou pelo terceiro responsável pela edição anterior), utilizando a mesma ferramenta usada na personalização original. O suporte Atak não assume a manutenção desse arquivo enquanto ele permanecer fora do padrão original. Como evitar no futuro? Evite alterar relatórios diretamente por conta própria ou com terceiros fora do processo oficial de alteração da Atak. Sempre que precisar de um ajuste em relatório, abra o chamado no serviço de alteração antes de editar o arquivo por outro meio. Se um relatório já foi personalizado fora do padrão, mantenha o controle de quem fez a alteração e com qual ferramenta, para facilitar manutenções futuras. Caso deseje retomar a manutenção pelo suporte Atak, avalie com a equipe técnica a possibilidade de desenvolver um novo relatório dentro do padrão original. Conteúdo Relacionado →Manual: Alteração de relatórios ErpAtak/Sisatak ⚠ Atenção — Aviso de Escopo As causas e soluções acima são baseadas exclusivamente nos atendimentos analisados. Situações não listadas devem ser abertas como novo chamado em: atak.movidesk.com

Cobrança de horas técnicas após desistência de alteração de relatório

DÚVIDA · SERVIÇOS > RELATÓRIOS ERPATAK / SISATAK Por que fui cobrado mesmo desistindo da alteração após aprovar o orçamento? Entenda por que a desistência de um serviço de alteração de relatório não isenta a cobrança das horas já trabalhadas. Contexto Produto/Módulo: Serviços > Relatórios ErpAtak / Sisatak > Alteração Situação: o cliente solicitou uma alteração em relatório, recebeu e aprovou o orçamento de horas técnicas, mas decidiu desistir do serviço ou deixou de dar retorno antes da conclusão. Condição: a desistência ou ausência de retorno ocorreu após a aprovação do orçamento, sem uma decisão direta da Atak em contrário. Termos relevantes: nenhuma sigla adicional além das já conhecidas do fluxo de chamados. Por que isso acontece? Ao aprovar o orçamento, o serviço entra na fila de desenvolvimento e o técnico responsável passa a dedicar horas efetivas de trabalho à execução da alteração. A aprovação representa o aceite formal das condições do serviço, incluindo o entendimento de que o tempo técnico já investido é um custo real, independente do resultado final ser utilizado ou não pelo cliente. Por isso, se a solicitação for cancelada ou ficar sem retorno depois da aprovação — sem que a própria Atak decida encerrar o chamado por outro motivo — o tempo já trabalhado é cobrado normalmente. Como resolver? Não há reversão da cobrança das horas já executadas após a aprovação. Caso o cliente já tenha desistido ou não pretenda mais dar retorno sobre o serviço, o recomendado é formalizar essa decisão no próprio chamado o quanto antes, para que o técnico não continue avançando em etapas adicionais desnecessárias e o valor cobrado fique restrito ao trabalho já realizado até aquele ponto. Como evitar no futuro? Tire todas as dúvidas sobre o serviço e sobre o processo de orçamento antes de aprovar, já que a aprovação implica ciência das condições do serviço. Só aprove o orçamento quando tiver certeza de que deseja seguir com a alteração. Se surgir alguma mudança de decisão, comunique no chamado o mais rápido possível, antes que mais horas técnicas sejam investidas. Considere alternativas (como ajustar o escopo da alteração) antes de aprovar, caso o valor orçado seja um fator de decisão. Conteúdo Relacionado →Manual: Alteração de relatórios ErpAtak/Sisatak Observações 📌 Observações O orçamento de horas enviado é sempre uma estimativa mínima, podendo se estender conforme a complexidade real do ajuste identificada durante a execução. Se a Atak identificar tecnicamente a necessidade de encerrar o chamado por outro motivo, essa regra de cobrança por desistência não se aplica. ⚠ Atenção — Aviso de Escopo As causas e soluções acima são baseadas exclusivamente nos atendimentos analisados. Situações não listadas devem ser abertas como novo chamado em: atak.movidesk.com

Bloqueio de nota fiscal por prazo médio: por que não reduzir o limite

DÚVIDA · CADASTRO GERAL Por que reduzir ou remover o prazo médio máximo não é uma boa solução para o bloqueio de nota fiscal? Entenda por que alterar o prazo médio máximo apenas para contornar o bloqueio pode trazer riscos ao controle de crédito do cliente. Contexto Produto/Módulo: Cadastro Geral Situação: a emissão de nota fiscal foi bloqueada por exceder o prazo médio máximo cadastrado no cliente, e considera-se reduzir ou remover esse limite como forma de contornar o bloqueio. Condição: o bloqueio pode ser apenas reflexo de um pedido emitido em dia não útil, com a data de vencimento postecipada para o próximo dia útil, e não necessariamente um erro de configuração. Termos relevantes: prazo médio máximo (parâmetro cadastrado no cliente, usado como controle de crédito para limitar o prazo de vencimento permitido nas vendas). Por que isso acontece? O bloqueio por prazo médio é um mecanismo de controle de crédito, não um indicativo de erro no cadastro ou na configuração do movimento. Quando o bloqueio ocorre apenas por causa de uma emissão em dia não útil, reduzir ou remover o prazo médio máximo não corrige a causa real do problema — apenas elimina o controle de crédito de forma permanente, deixando o cliente sem essa proteção em situações futuras que não têm relação com dias não úteis. Como resolver? 1 Verificar se o bloqueio é reflexo de emissão em dia não útil Antes de alterar o prazo médio máximo, confira se o pedido foi emitido em um sábado, domingo ou feriado, e se a data de vencimento foi postecipada para o próximo dia útil. Isso pode explicar o bloqueio sem que haja erro de cadastro. 2 Manter o prazo médio máximo configurado Se o bloqueio for explicado pela emissão em dia não útil, mantenha o prazo médio máximo como está, já que ele continua sendo um controle de crédito válido para as demais situações. 3 Abrir chamado caso o bloqueio persista sem explicação de dia não útil Se o bloqueio continuar ocorrendo mesmo para pedidos emitidos em dias úteis e dentro do prazo cadastrado, abra um chamado em: atak.movidesk.com Como evitar no futuro? Dê atenção redobrada ao prazo médio configurado em pedidos emitidos próximos a fins de semana ou feriados. Antes de alterar qualquer parâmetro de crédito, avalie se o bloqueio tem uma explicação pontual, como a postecipação do vencimento para o próximo dia útil. Evite usar a redução ou remoção do prazo médio máximo como solução padrão para bloqueios, preservando o controle de crédito do cliente. Conteúdo Relacionado →Manual: Nota fiscal bloqueada por prazo médio mesmo com cadastro correto ⚠ Atenção — Aviso de Escopo As causas e soluções acima são baseadas exclusivamente nos atendimentos analisados. Situações não listadas devem ser abertas como novo chamado em: atak.movidesk.com

Nota fiscal bloqueada por prazo médio mesmo com cadastro correto

MÓDULO: Cadastro Geral Como resolver bloqueio de nota fiscal por prazo médio Entenda por que o sistema pode bloquear a emissão da nota fiscal por prazo médio quando o pedido é feito em dia não útil. Visão geral Este manual se aplica a situações em que a emissão da nota fiscal é bloqueada com referência ao prazo médio configurado no cadastro do cliente, mesmo quando o prazo informado no pedido de venda parece estar dentro do limite permitido. Ao final, o leitor entenderá por que esse bloqueio pode ocorrer mesmo sem erro de configuração e o que verificar antes de solicitar suporte. Sintoma O usuário relata que, mesmo com a condição de pagamento e o prazo médio corretamente preenchidos no cadastro do cliente, o sistema bloqueia a emissão da nota fiscal indicando que o prazo da venda excede o prazo médio máximo permitido. Causa confirmada Foi confirmado que o sistema compara a data de vencimento do título com o prazo médio máximo cadastrado. Quando a data de emissão do pedido cai em um dia não útil (por exemplo, um fim de semana) e a configuração do movimento está definida para postecipar o vencimento para o próximo dia útil, a quantidade de dias entre a emissão e o vencimento passa a ser maior do que o prazo médio contado em dias corridos. Isso faz com que o sistema identifique o prazo da venda como superior ao limite e bloqueie a emissão, mesmo que o prazo médio informado no cadastro esteja correto e não haja erro de configuração. Passo a passo 1 Verificar a data de emissão do pedido Antes de abrir um chamado, confira se o pedido foi emitido em um dia não útil (sábado, domingo ou feriado). Se a data de vencimento do título foi postecipada para o próximo dia útil, o total de dias corridos entre emissão e vencimento pode superar o prazo médio máximo cadastrado, mesmo que o prazo comercial acordado esteja correto. 2 Confirmar o prazo médio máximo no cadastro do cliente Verifique, no cadastro do cliente, o valor definido para o prazo médio máximo. Esse é o parâmetro comparado pelo sistema com o prazo de vencimento do título no momento do faturamento. 3 Abrir chamado caso o bloqueio persista sem explicação de dia não útil Se, após verificar os itens acima, o bloqueio continuar ocorrendo mesmo para pedidos emitidos em dias úteis e com prazo dentro do limite cadastrado, abra um chamado em: atak.movidesk.com ⚠ Importante Reduzir ou remover o prazo médio máximo apenas para contornar o bloqueio não corrige a causa e pode deixar o cliente sem esse controle de crédito no futuro. Antes de alterar o cadastro, avalie se o bloqueio não é apenas reflexo de uma emissão em dia não útil. Conteúdo Relacionado →Dúvida: Bloqueio de nota fiscal por prazo médio: por que não reduzir o limite 📌 Observações O bloqueio por prazo médio é um mecanismo de controle de crédito e não indica, por si só, erro no cadastro ou na configuração do movimento. Pedidos emitidos próximos a fins de semana ou feriados merecem atenção redobrada quanto ao prazo médio configurado. ⚠ Atenção — Aviso de Escopo As causas e soluções acima são baseadas exclusivamente nos atendimentos analisados. Situações não listadas devem ser abertas como novo chamado em: atak.movidesk.com

Consulta de cadastro via SEFAZ sem retorno: causa e correção técnica

MÓDULO: Cadastro Geral Como resolver falha na consulta de cadastro via SEFAZ Veja a causa mais comum de falha ao consultar cadastros via SEFAZ e como o suporte resolve esse problema. Visão geral Este manual se aplica quando a funcionalidade de consulta de cadastro via SEFAZ deixa de retornar os dados de fornecedores ou clientes, apresentando erro ao ser acionada. A resolução deste tipo de falha depende de intervenção técnica do suporte. Sintoma O usuário relata que a consulta de cadastro via SEFAZ não retorna os dados dos fornecedores ou clientes de nenhum estado, ou apresenta erro ao clicar no botão de consulta. Causa confirmada Foi identificado que a falha ocorre quando a versão dos componentes de integração relacionados à emissão de NF-e (dependências TNFe) está divergente ou desatualizada em relação à versão utilizada pelo ambiente em produção, o que impede o funcionamento correto da consulta via SEFAZ. O que fazer Este problema requer ajuste técnico pelo suporte. Abra um chamado em: atak.movidesk.com informando: Que a consulta de cadastro via SEFAZ não está retornando dados ou apresenta erro ao ser acionada. O print da tela com a mensagem de erro exibida. Se o problema ocorre para todos os usuários da estação ou apenas em uma máquina específica. 📌 Observações Após o ajuste técnico, é recomendável realizar um novo teste de consulta para confirmar que a funcionalidade voltou a operar normalmente. Esse tipo de falha não está relacionado ao cadastro em si, mas à integração técnica do ambiente com os serviços da SEFAZ. ⚠ Atenção — Aviso de Escopo As causas e soluções acima são baseadas exclusivamente nos atendimentos analisados. Situações não listadas devem ser abertas como novo chamado em: atak.movidesk.com

Parâmetro de CNPJ duplicado é global e afeta todo o cadastro

DÚVIDA · CADASTRO GERAL Por que a alteração do parâmetro de CNPJ duplicado afeta todos os cadastros do sistema, e não apenas o caso relatado? Entenda por que permitir CNPJ duplicado para um cenário específico altera a validação de duplicidade em todo o sistema. Contexto Produto/Módulo: Cadastro Geral Situação: foi solicitada a alteração de um parâmetro do sistema para permitir mais de um cadastro com o mesmo CNPJ (Cadastro Nacional da Pessoa Jurídica), cada um com endereço próprio, atendendo a um cenário específico de unidades, filiais ou entidades distintas. Condição: o parâmetro que controla a validação de duplicidade de CPF/CNPJ não é aplicado apenas ao tipo de cadastro ou ao cenário relatado — ele é uma configuração geral do sistema. Termos relevantes: nenhum termo adicional além dos já explicados acima. Como funciona? O parâmetro que controla a validação de duplicidade de CPF/CNPJ é uma configuração de customização do tipo de cadastro, aplicada de forma abrangente. Ao ser alterado para permitir CNPJ duplicado em um cenário específico, essa mudança passa a valer para a validação de duplicidade de todos os cadastros do sistema — não é possível restringir o efeito apenas ao caso relatado. Por isso, antes de solicitar o ajuste, é necessário avaliar se esse comportamento geral é realmente o desejado para a empresa. Como evitar no futuro? Antes de solicitar a alteração, avalie com o suporte se permitir CNPJ duplicado em todo o sistema é aceitável para a empresa, e não apenas para o cenário relatado. Documente internamente o motivo da alteração, para que a equipe entenda por que a validação de duplicidade deixou de bloquear CNPJs repetidos. Após a alteração, oriente os responsáveis pelos cadastros a conferir com atenção o endereço informado em cada novo registro com CNPJ repetido, já que o sistema não impede mais esse tipo de duplicidade. Conteúdo Relacionado →Manual: Cadastrando múltiplas unidades com o mesmo CNPJ e endereços distintos ⚠ Atenção — Aviso de Escopo As causas e soluções acima são baseadas exclusivamente nos atendimentos analisados. Situações não listadas devem ser abertas como novo chamado em: atak.movidesk.com