TOTVS S/A

Sim, a solução do BigWings funcionou. Deu certo habilitando a opção para salvar apenas as nf processadas. Obrigado.

Sim, quem está utilizando é somente minha aplicação, e o problema ocorre ao executar o metodo WriteToTXT apos o envio, acredito eu que pelo fato de já existir o arquivo xml criado pelo metodo "assinar. " Na maquina do cliente nao tem antivirus.

Vou tentar essa opção. reporto assim q tiver o retorno

Estou com esse mesmo problema, repentinamente começou a ocorrer erro no momento de transmitir as vendas, justamente depois q assinar o arquivo. Cliente nao utiliza antivirus nas maquinas...vc conseguiu identificar a causa?

Boa tarde, Não deu certo a tentativa...mesmo chamando apenas o comando enviar, o erro sobre o arquivos estar sendo utilizado por outro processo persiste nesse cliente. Existe alguma configuração que pode ser feita pra identificar que o arquivo esta sendo utilizado, ou salvar o arquivo apenas apos o envio(nao salvar no momento de assinar)?

Boa tarde, Vou fazer um teste agora. Obrigado

Boa tarde, Estou com um problema ao enviar venda, onde é retornado o erro "O arquivo já está sendo usado por outro processo". Percebi que ocorre depois que o arquivo é assinado, pois nesse momento é gerado o arquivo xml no diretorio que foi configrado no PathNFe, e logo depois vem o envio do arquivo retornado a mensagem abaixo no log da aplicação: 27/04/2020 13:47:21,829 Envio NFC-e = Inicio TNFeRecepcao 27/04/2020 13:47:23,111 Envio NFC-e = ERRO: Erro ao salvar. Cannot create file "C:\Winthor\PROD\MOD-020\Arquivos\NFCe\Aprovadas\27743546000199\202004\29200427743546000199650010000507111003860070-nfe.xml". O arquivo já está sendo usado por outro processo 27/04/2020 13:47:23,439 Envio NFC-e = Versão Layout: 4.00 esse problema ocorre em apenas 1 cliente, e minha duvida é se existe alguma configuração que pode ser feita no componente para que seja verificado se o arquivos ainda em uso antes de enviar, pois como utilizo a opção salvar = true, o erro acima ocorre sempre. Se nao houver uma configuração, é viavel aguardar alguns segundos entre o processo de assinar e enviar? segue as configurações do componente: Self.fAcbrNFCe.Configuracoes.Arquivos.PathNFe := ApplicationPath + 'Arquivos\NFCe\Aprovadas\'; Self.fAcbrNFCe.Configuracoes.Arquivos.PathSalvar := ApplicationPath + 'Arquivos\NFCe\Log\'; Self.fAcbrNFCe.Configuracoes.Arquivos.PathSchemas := ApplicationPath + 'Arquivos\NFCe\Schemas\'; Self.fAcbrNFCe.Configuracoes.Arquivos.PathEvento := ApplicationPath + 'Arquivos\NFCe\Evento\'; Self.fAcbrNFCe.Configuracoes.Arquivos.PathInu := ApplicationPath + 'Arquivos\NFCe\Inutilizar\'; Self.fAcbrNFCe.Configuracoes.Arquivos.EmissaoPathNFe := True; Self.fAcbrNFCe.Configuracoes.Arquivos.SalvarEvento := True; Self.fAcbrNFCe.Configuracoes.Arquivos.SepararPorCNPJ := True; Self.fAcbrNFCe.Configuracoes.Arquivos.SepararPorModelo := False; Self.fAcbrNFCe.Configuracoes.Arquivos.Salvar := True; Self.fAcbrNFCe.Configuracoes.Arquivos.SepararPorMes := True; Self.fAcbrNFCe.Configuracoes.Arquivos.AdicionarLiteral := False; Self.fAcbrNFCe.Configuracoes.WebServices.Uf := fParametros.Uf; Self.fAcbrNFCe.Configuracoes.WebServices.Salvar := True; Self.fAcbrNFCe.Configuracoes.WebServices.Visualizar := False; Self.fAcbrNFCe.Configuracoes.Geral.ModeloDF := moNFCe; Self.fAcbrNFCe.Configuracoes.Geral.FormaEmissao := teNormal; Self.fAcbrNFCe.Configuracoes.Geral.FormatoAlerta := 'TAG:%TAGNIVEL% ID:%ID%/%TAG%(%DESCRICAO%) - %MSG%.'; Self.fAcbrNFCe.Configuracoes.Geral.ExibirErroSchema := True; Self.fAcbrNFCe.Configuracoes.Geral.RetirarAcentos := True; Self.fAcbrNFCe.Configuracoes.Geral.Salvar := True;

Boa tarde, na sefaz consta todas essas vendas, vi em uma pagina q o cliente tem acesso. Coloquei uma informação no xml para que fosse identificado quando o envio fosse pela minha aplicação, e todos os cupons indevidos constam essa informação, mas por mais q parece ser um problema da aplicação já garanti por logs de todos as maneiras que nao foi um envio pelo fluxo de vendas. O que me chama atenção é que muitos desses envios pelo horario da recepção deles na sefaz, o aplicação estava parada, nao estava sendo utilizada...vejo isso pelos logs dela, e o intervalo e envio desse casos indevidos é de 2 a 5 segundos, e no ultimo caso q analisamos o registro de uma venda esta la na sefaz 60 vezes em um intervalo entre eles de poucos segundos. O fato dessas vendas indevidas ser a mesma e so mudar o numero do cupom e a chave me faz pensar que nao seria alguem do suporte, pois teria q ficar editando o xml, enfim. Gerei uma versao onde nao vou salvar o arquivos de backup, pra ter certeza q não tem algum processo ou programa ou pessoa capturando esses arquivos e enviando. Ate sexta devo ter uma retorno se mudou algo.

Boa tarde, Nossa aplicação nao tem outro fluxo de envio fora o da venda, e mesmo assim coloquei logs para capturar todos os dados antes do envio pelo componente, e nao consta nada dessa numerações. Nas pasta de logs e xmls de retorno que configuramos no componente nao tem nenhum registro dessas vendas, e da mesma forma no banco esses registros nao existem. Não sei mais o que pensar porque conectei na maquina pra me certificar q nao existe um programa fazendo esse envio.

Boa noite, Esta acontecendo uma situação em um cliente que não sei mais o que verificar, e gostaria de ajuda para tenta entender e localizar o problema, que é: - Venda 1, com valor de R$1,00 aprovada as 08h - Venda 2, com valor de R$2,00 aprovada as 08:02h - venda 3, com valor de R$3,00 aprovada as 08:03h aqui começa o problema, porque aparece na sefaz esporadicamente que a venda 2 no valor de R$2,00 foi transmitida várias vezes, sendo que meu pdv enviou apenas 1 unica vez. Na sefaz consta a venda 2, porém consta venda 10, venda 15, venda 20 e etc todas com os mesmos itens, com o mesmo valor, porém com chaves diferentes, protocolos de aprovação diferentes, numero de cupons diferentes...porém meu pdv mandou apenas 1 vez essa venda. coloquei log antes de chamar o metodo enviar para poder registrar todas os xmls que são transmitidos e nao foi registrado a transmissao dessas outras vendas. Solicitei ao cliente que formatasse a maquina onde o pdv esta rodando, supondo que poderia ser alguma aplicação que estivesse pegando o xml enviado indevidamente, mas mesmo assim, continua acontecendo de forma esporádica o problema. Na pasta de backup dos xmls nao consta esses xmls indevidos. o que me intriga mais é que os dados da venda são os mesmos, porem numero, chave, protocolo e horario de envio são diferentes. Um detalhe importante que notei é que dessas vendas indevidas, o horário de autorização são bem proximos, tipo, de 2 a 5 segundos a diferença entre eles, e que a hora da autorização é anterior a hora de emissão. essa é a unica prova que algo está bem estranho nesse cliente, e somente nesse. Alguem tem uma ideia do que possa ser, ou alguma sugestão a ser verificada?

Bom dia! Eu estou com um problema em um cliente referente ao TEF, na qual as suas máquinas que estão configuradas para emitir NFCe estão com lentidão ao realizar uma transação de pagamento com cartão de crédito/débito, demorando mais de um minuto e vinte segundos para realizar todo o processo, enquanto em suas máquinas configuradas para emitir ECF não acontece a lentidão, levando em média 30 segundos para realizar todo o processo. Não há codificação especifica do TEF para cada tipo de emissão. É usado as DLL da Software Express para realizar a transação do TEF. Já entrei em contato com eles, passando a base do servidor TEF para análise e não encontraram a diferença, concluindo que a lentidão da venda na máquina NFCe acontece na automação. Alguém passou por esse problema e pode me ajudar no caso?

Bom dia @Daniel Simoes, realizamos os testes e funcionou perfeitamente. Muito obrigado pelo apoio.

Configurando libWincrypt funciona e versões anteriores da DLL OpenSSL também funciona.

De fato, o CN contém apenas o nome da empresa.

Bom dia @BigWings, realmente testando com outro certificado funcionou. Existe algo a ser feito para contornar esse problema, ou realmente é um problema no certificado? Em versões anteriores do OpenSSL não ocorre o problema. Realmente, o tópico citado é o mesmo problema. Grato