[email protected]

Eu notei esse espaço, mas como sempre funcionou dessa forma eu acabei não dando a devida atenção a ele. Agora testei novamente sem o espaço e sem mascara no CNPJ e ai funcionou perfeitamente. Obrigado pela ajuda.

Tentei com outros CNPJ do mesmo estado e o retorno é o mesmo. Agora testei com a IE como vc sugeriu e tambem retorna erro: NFE.ConsultaCadastro(PR, 9087637694,1) OK: [ConsultaCadastro] CNPJ= CPF= CStat=215 CUF=41 DhRecbto= IE= Msg= UF= VerAplic=PR-v4_8_58 Versao=2.00 XMotivo=Falha no schema XML. org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 130; cvc-pattern-valid: Value ' 9087637694' is not facet-valid with respect to pattern '[0-9]{2,14}|ISENTO' for type 'TIe'. dhCons=13/08/2024 13:32:34 tpAmb=

Utilizando o ACBrMonitorPLUS Ver.1.4.0.249 Ao utilizar a função: NFE.ConsultaCadastro(PR, 40-476-573/0001-00) ou NFE.ConsultaCadastro(PR, 40476573000100) Estou tendo o seguinte retorno: -OK: [ConsultaCadastro] CNPJ= CPF= CStat=215 CUF=41 DhRecbto= IE= Msg= UF= VerAplic=PR-v4_8_58 Versao=2.00 XMotivo=Falha no schema XML. org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 138; cvc-pattern-valid: Value ' 40476573000100' is not facet-valid with respect to pattern '[0-9]{3,14}' for type 'TCnpjVar'. dhCons=13/08/2024 09:17:56 tpAmb=

Ok, vamos verificar a rotina de leitura do retorno em nosso sistema. Obrigado.

sainfe.txt Bom dia, a algum tempo utilizo o ACBRNfeMonitor 1.0.4.249 Essa semana alguns clientes começaram a reportar um problema na emissão das notas. Onde estava tendo o seguinte retorno 'Lote recebido com sucesso' ao invés de 'Autorizado o uso da NF-e'. Ao consultar as notas, elas estava devidamente autorizadas. Para corrigir esse problema, tive que fazer alterações na leitura do arquivo de retorno pois o mesmo não estava mais no formato que eu sempre utilizei. A dúvida é, o arquivo txt de retorno do Monitor foi alterado?

Realmente, consultei pelo https://pt.product-search.net/ e aqui tambem deu como inexistente. Obrigado.

Boa tarde, utilizo a função a baixo para validar o EAN: ACBrValidador.TipoDocto:=docGTIN; if ((ValidarGTIN(EdEAN.Text))<>'') then Hoje um cliente reportou que a validação esta retornando como inválido, um código que veio na embalagem do produto. (7891128919963) Segue em anexo as imagens da embalagem e tambem do debug do codigo.

Consegui gerar o xml correto. O problema era o tpEmis, o cliente avia criado essa nota em moto of line e ninguem sabia disso. Criei agora com tpEmis 9 e o xml ficou perfeito. Obrigado.

Para tentar recriar o XML eu removi a função GerarCodigoDFe, estou mantendo as mesmas informações da nota e estou passando o codigo manualmente (até coloquei a data e hora do computador igual ao momento em que a nota foi emitida). Tentei com 9958159498, 958159498, 58159498, 995815949, 99581594.... Mas todos os testes que faço geram uma chave diferente.

Utilizo o ACBrMonitorPLUS e utilizo a função GerarCodigoDFe Cada vez que crio a nota, a chave modifica: 41230603469577000135650010000201511581594984 41230603469577000135650010000201511995815942 41230603469577000135650010000201511958159492 Enquanto a chave autorizada é: 41230603469577000135650010000201519958159498

Bom dia, tivemos um problema em um cliente onde foi perdito duas xml de nfce. Tenho a venda com todos os dados, tenho a chave xml correta. Mas ao tentar recriar esse xml a chave fica diferente devido ao fato de utilizar a função (GerarCodigoDFe) do acbr. Existe alguma forma de criar esse xml exatamente como ele foi autorizado? Essa é uma das chaves autorizadas: 41230603469577000135650010000201519958159498

Bom dia, fiz o que falou e deu certo. Estranho que ao consultar o sintegra não informa esse 0 a mais. Mas o importante é que deu certo. Obrigado.

Ola, estou tendo uma rejeição de IE Invalida, porem ao consultar o cadastro do cliente a IE esta correta. Pelo que nus foi informado, não é a primeira vez que isso ocorre e isso tem ocorrido somente com IE de Minas Gerais. Em anexo segue o arquivo de criação da nota e tambem a consulta da inscrição do cliente. Utilizando o ACBr MonitorPLUS Ver.1.4.0.44 - x86. ie invalida.TXT

Se quiser pode fechar o post, todos os clientes que tiveram aquela violação de acesso na criação dos arquivos, foi solucionada configurando o LT_TLSv1_2 . Obrigado pela atenção.

Por enquanto, todos que colocamos LT_TLSv1_2 voltaram a funcionar. Mas se em algum cliente não der certo, vou testar o SSL Lib Wincrypt. Obrigado.