Italo Giurizzato Junior

Olá Pessoal, Os Schemas foram disponibilizados e os novos campos da versão 1.10 da NT 2023/004 já foram implementados e enviados para o SVN. Resta agora a SEFAZ publicar uma nova NT com os novos eventos informando os prazos para liberação do ambiente de homologação e produção bem como os schemas. Assim que isso ocorrer a Equipe do Projeto ACBr vai fazer as alterações necessárias visando a implementação dos novos eventos.

Adhelmar, Acabei de fazer um teste em ambiente de homologação usando o programa exemplo, veja o resultado: ------------------------------ Versão OpenSSL OpenSSL 3.1.3 19 Sep 2023 03.01.00.030 C:\ACBr\trunk2\Exemplos\ACBrDFe\ACBrNFSeX\Delphi\libcrypto-3.dll C:\ACBr\trunk2\Exemplos\ACBrDFe\ACBrNFSeX\Delphi\libssl-3.dll ------------------------------ Requisição Ambiente : 2 Cidade : Campo Limpo Paulista/SP Provedor : GeisWeb Versão: 1.00 Data/Hora: 04/03/2024 09:16:18 Método Executado: Enviar Lote Síncrono Parâmetros de Envio Numero do Lote: 1 Parâmetros de Retorno Data de Envio : 30/12/1899 Numero do Prot: Numero da Nota: Link : Código Verif. : Sucesso : False Erro(s): Código : 7 Mensagem: Usuário não cadastrado. Correção:

Bom dia Danilo, Quando foi a ultima vez que você atualizou? Você tem fontes do ACBr com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build. Por fim repita os testes.

Bom dia Daniel, Você não me disse qual é o valor de TypeSSL. Quanto ao método Emitir. { O método Emitir possui os seguintes parâmetros: aNumLote (String) aModEnvio [meAutomatico, meLoteAssincrono, meLoteSincrono, meUnitario, meTeste] aImprimir (Boolean) Valor Padrão = True, portanto imprime o DANFSE } // como não foi informado o segundo parâmetro o método assume o valor // meAutomatico, isso faz com que ele se ajusta ao provedor selecionado ACBrNFSeX1.Emitir(vNumLote);

Bom dia Edson, Qual versão anterior? Pois todas as alterações realizadas de 2022 até 2024 nenhuma delas se refere a essa tag.

Adhelmar, Se o certificado for A1 de preferencia para SSLLib = libOpenSSL. Caso contrario essa configuração esta correta. Se o acesso não depende de Proxy, o mesmo não deve ser configurado no componente.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Adhelmar, Quais são os valores de: SSLLib, CryptLib, HttpLib, XmlSignLib e SSLType ?

Bom dia Lucas, Você tem fontes do ACBr com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build. Por fim repita os testes, configurando o componente corretamente para a versão 4.00.

Bom dia Roberto, O valor de SSLLib esta errado, utilize libOpenSSL se o certificado for A1 ou libWinCrypt se for A3. Não mexa nos valores de: CryptLib, HttpLib e XMLSigLib, ao setar o valor de SSLLib as 3 de baixo vão se ajustar automaticamente. O Valor de TypeSSL também esta errado, utilize o LT_TLSv1_2. Faça essas alterações, salve a configuração e tente novamente.

Bom dia Danilo, Você esta com todos os fontes de todas as pastas atualizados? Reinstalou o ACBr?

Bom dia @Sulsoftware, Segundo os Schemas do provedor Thema temos: <xsd:simpleType name="tsNaturezaOperacao"> <xsd:restriction base="xsd:byte"> <xsd:pattern value="50|51|52|53|54|55|56|57|58|59|60|61|62|63|64|65|66|67|68|69|70|71|72|78|79|81|91"/> </xsd:restriction> </xsd:simpleType> Esses são os valores que ele aceita, ocorreu erro de validação porque você informou no1 em vez de no50 ... no91.

Bom dia Anderson, Como assim no layout anterior tem o campo competência? Não entendi.

Bom dia @Sistema Auditor, Vamos aguardar.

Bom dia Edson, Esse XML não foi gerado pelo componente ACBrBPe. Pois a primeira tag dele é <bpeProc> e componente gera com a tag <BPeProc>, com essa diferença ele não consegue ler o XML.

Bom dia Lucas, Você usa o componente ACBrCTe ou o ACBrLibCTe ou o ACBrMonitor?

Bom dia Bruno, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Bom dia Weber, Pelo seu relato temos o seguinte: 1. Ao consultar a nota por rps, o XML da mesma é baixado e lido sem nenhum erro. 2. Ao consultar a nota por faixa, o XML da mesma é baixo, mas ocorre erro ao ler o mesmo. 3. O erro que ocorre é a leitura das datas de emissão e de competência. Se você comparar o XML baixado pelo consultar nota por rps com o XML baixado pelo consultar nota por faixa, vai descobrir que a formatação dessas datas estão diferentes. No primeiro esta com o formato AAAA-MM-DD, já no segundo esta DD-MM-AAAA. O que esta ocorrendo na verdade é que o webservice do provedor tem uma rotina que gera o XML para cada serviço que retorna o XML da nota. A rotina que gera o XML usada pelo serviço Consultar NFS-e Por RPS esta correta, ou seja, gerando as datas na formatação correta. Por outro lado a rotina que gera o XML usada pelo serviço Consultar NFS-e Por Faixa esta errada, ou seja, gerando as datas na formatação incorreta. É complicado fazer o componente detectar a formação, porque? Veja este exemplo: 02/03/2024 esta data esta no formado DD/MM/AAAA ou MM/DD/AAAA? Você concorda que não da para afirmar, pois pode ser 2 de março como também 3 de fevereiro. Se para uma consulta esse provedor gera a data no formato AAAA-MM-DD, para outra gera no formato DD-MM-AAAA, como será o formato das outras consultas? Para este provedor temos: Consulta Lote, Consultar NFS-e Por RPS, Consultar NFS-e Por Faixa, Consultar NFS-e Serviço Prestado e Consultar NFS-e Serviço Tomado. Como esse provedor esta usando a versão 2.03 do layout da ABRASF a rotina responsável pela leitura é a mesma para todos os provedores que usam a versão 2.xx Eu recomento que você entre em contato com o provedor e expõe o problema. No meu entendimento se o provedor lhe oferece mais de um serviço para obter o XML da nota, independente do serviço escolhido o XML tem que ser o mesmo.

Bom dia @Datacaixa, Não se é para todos os DF-e, mas para a NF-e a rejeição "Consumo Indevido" tem como código 656. No campo cStat temos 656 e no campo xMotivo temos a mensagem "Rejeição: Consumo Indevido". Após tentar emitir a nota através do método Enviar, você pode ler esses dois campos. Se cStat for 656 você faz com que a aplicação não deixe o usuário tentar novamente.

@sicnet, A unit que lhe passei já foi enviada para o SVN.

Boa tarde @sicnet, Vou lhe pedir um favor. Substitua a unit pela que esta em anexo. Ela fica na pasta: ...\Fontes\ACBrComum Reinstale o ACBr. Compile a aplicação com a opção Build e faça um novo teste. ACBrUtil.XMLHTML.pas

Boa tarde Douglas, Essas URLs estão corretas? A versão é a 2.04 mesmo? A URL de produção não esta abrindo.

Bom dia Adhelmar, Pela mensagem de erro me parece ser um problema no webservice do provedor que atende a cidade. Favor entrar em contato com eles e expõe o problema.

Boa tarde Danilo, Esse erro eu nunca vi, vai ter que entrar em contato com o provedor e questionar eles. A principio a série pode ser 1 mesmo a não ser que o provedor diga que tem que ser outra.