Jump to content

TOTVS S/A

Membros
  • Posts

    33
  • Joined

  • Last visited

Everything posted by TOTVS S/A

  1. Sim, a solução do BigWings funcionou. Deu certo habilitando a opção para salvar apenas as nf processadas. Obrigado.
  2. 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.
  3. 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?
  4. 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)?
  5. 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;
  6. 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.
  7. 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.
  8. 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?
  9. 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?
  10. Bom dia @Daniel Simoes, realizamos os testes e funcionou perfeitamente. Muito obrigado pelo apoio.
  11. Configurando libWincrypt funciona e versões anteriores da DLL OpenSSL também funciona.
  12. De fato, o CN contém apenas o nome da empresa.
  13. 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
  14. Boa tarde. Realizamos a atualização dos fontes, para emissão de NFC-e utilizamos a configuração OpenSSL com certificado A1. Mas quando efetuamos qualquer teste é retornado o erro. Debugando o fonte me deparei que acontece na classe ACBrDFeOpenSSL, no método GetCertExt: Para ser mais especifico acontece no código abaixo: prop := ext^.value; propStr := PAnsiChar(prop^.data); /*Nesta linha*/ SetLength(propStr, prop^.length); P := pos(FlagExt, propStr); Mas não sei mais como proceder diante desse problema. Att.
  15. Bom dia, Minha empresa estava cadastrada na SEFAZ de São Paulo com um CNPJ "X" onde vinculamos(Associamos) vários equipamentos nesse CNPJ. Porém nosso certificado venceu, e como somos um grupo, foi nos passado outro certificado com outro CNPJ, agora o CNPJ "Y". A grande duvida é: - Quando acessamos o portal da SEFAZ de SP como Software House, somos direcionados para uma pagina para realizar o cadastro, creio que porque ainda não exista com esse novo CNPJ, onde é exigido o upload do certificado e o upload do ATO Constitutivo da empresa. Se por acaso realizarmos esse novo cadastro com CNPJ "Y" para vincularmos novos equipamentos, os clientes que estavam vinculados ao CNPJ antigo "X" não terão problemas? Eles não serão desabilitados? - Ao realizar o cadastro desse novo CNPJ "Y", eu vou ter que informar o nome do aplicativo comercial que já esta informado no CNPJ "X"...isso não irá causar nenhum problema? Ter 2 CNPJs informando o mesmo AC? A base desses cnpj "X" e "Y" são as mesmas, o que muda é apenas o final, pois como falei somo um grupo de empresas.
  16. Bom dia, Existe alguma forma de aprovar documentos NFC-e em homologação sem que o certificado esteja instalado no pdv ou sem o pfx?
  17. Bom dia, Hoje quando fui emitir vendas em ambiente de homologação em Goiás, todas as vendas estão retornando o erro 897-Valor Fatura maior que Valor Total da NF-e. Não tem nada de errado no xml, pagamento feito em dinheiro no valor de R$10,00 sem desconto e sem acréscimo. Alguém passando por essa situação? Em anexo o xml da venda. Detalhe que ontem dia 24/06/2019 estava funcionando normalmente. 148152-env-lot.xml 148152-env-lot-soap.xml 148152-pro-lot.xml 148152-pro-lot-soap.xml
  18. Bom dia, Quando efetuo o cancelamento por substituição no Estado de Rondônia, não aparece nada no site da SEFAZ informando que houve esse cancelamento. Nossos clientes consultam as notas pela chave e no site fica como se a venda não estivesse cancelada, ou seja, sem nenhuma informação desse cancelamento. Cheguei a ficar na dúvida se realmente tinha cancelado, mas ao realizar um teste consultando a chave pela minha aplicação retornou o "cStat 101 - Cancelamento Homologado", então deduzi que o problema esta na pagina da SEFAZ em não mostrar. Alguém já percebeu isso? Podem me confirmar?
  19. Obrigado pela informações @MFincotto, vou acompanhar pelo tópico mais antigo. Qualquer novidade posto lá.
  20. Bom dia, Algum relato de problemas em ambiente de produção por conta da mudança das URLs? Pergunto porque tenho clientes em todos os Estados e não estou com o ACBrNFeServicos.ini atualizado com os novos endereços em produção, e até agora nenhuma reclamação. Pelo que estou percebendo ainda está aprovando com os endereços antigos, e a pergunta é se por acaso eu realizar a atualização não correria o risco de parar por mais que tenha entrado em vigor no dia 20/05/2019? Alguém poderia relatar se houve problemas com a aprovação por causa da atualização?
  21. Sim, inclusive está funcionando em outros clientes de outras UFs.
  22. Bom dia, Estou com problema ao enviar o cancelamento por substituição nos clientes da SEFAZ do Mato Grosso. Está retornando o erro : 999 - Erro não catalogado. Seria um problema na SEFAZ? Será que ainda não está funcionando o cancelamento por substituição? Os clientes de outras UFs não estão com esse problema, apenas no Mato Grosso. Segue em anexo o xml. 1-ped-eve.xml 1-ped-eve-soap.xml
  23. Bom dia, Estou com problema ao enviar o cancelamento por substituição nos clientes da SEFAZ do Mato Grosso. Está retornando o erro : 999 - Erro não catalogado Segue em anexo o xml. 1-ped-eve.xml 1-ped-eve-soap.xml
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.