Italo Giurizzato Junior

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.

Boa tarde, No meu entendimento não é bem isso que ocorre. Primeiramente o TratarRetornoConsultaNFSe verifica se existe o grupo: ListaNfse: ANode := Document.Root.Childrens.FindAnyNs('ListaNfse'); Depois verifica se existe o grupo CompNfse ou ComplNfse, como esse grupo pode ocorrer mais de uma vez a leitura do grupo é feita através do FindAllAnyNs: ANodeArray := ANode.Childrens.FindAllAnyNs('CompNfse'); if ANodeArray = nil then ANodeArray := ANode.Childrens.FindAllAnyNs('ComplNfse'); Em seguida temos um loop que vai ler todas as ocorrências do grupo CompNfse ou ComplNfse for I := Low(ANodeArray) to High(ANodeArray) do begin ANode := ANodeArray[I]; Na variável ANode temos o nó de cada ocorrência. Por fim ele verifica se existe ou não o grupo tcCompNfse para em seguida ler o grupo Nfse. AuxNode := ANode.Childrens.FindAnyNs('tcCompNfse'); if AuxNode = nil then AuxNode := ANode.Childrens.FindAnyNs('Nfse') else AuxNode := AuxNode.Childrens.FindAnyNs('Nfse'); Você consegue debugar para ver o que pode esta ocorrendo?

Boa tarde, Segundo o manual referente ao DACTE não esta previsto a impressão das parcelas. Lembre-se que o DACTE é apenas um Documento Auxiliar utilizado como documento durante o transporte da mercadoria, fora isso ele não tem validade jurídica. O que tem validade jurídica é o XML do CT-e desde que ele esteja assinado digitalmente com o certificado digital do emitente e com o protocolo de autorização gerado pela SEFAZ-Autorizadora. Eu não me preocuparia com o DACTE, pois ouvi um boato que para o ano que vem a sua impressão não vai mais ser obrigatória.

Bom dia, A unit acima se encontra no SVN.

Bom dia Sandro, Faça uma cópia da sua alteração, atualize os fontes, reinstale o ACBr e faça novos testes.

Bom dia Alan, Não devemos alterar essa unit, pois isso gera um efeito colateral nos demais provedores. Esse tipo de alteração tem que ser feita na unit GravarXml do provedor em questão na procedure Configuracao. Volto a frisar que você é o primeiro a relatar esse erro de validação ao gerar o XML para a cidade de Brasília.

Bom dia, Mude o valor de SSLType para LT_TLSv1_2 e faça novos testes.

Boa tarde Fabio, Favor atualizar os fontes, reinstalar o ACBr e faça novos testes.

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

Boa tarde Alan, Realmente esta estranho, pois outros desenvolvedores que estão utilizando o componente ACBrNFSeX e realizando testes com a cidade de Brasília, não relataram esse erro. O que tem dentro da pasta ...\Desktop\NFSex\Schemas ?

Boa tarde, Esse problema só tem uma forma de resolver. É o provedor corrigir a porcaria que fez. Se você abrir o XML *-lista-nfse-sinc.xml que é o retorno do envio do lote vai notar que, a data de emissão da nota (tag DataEmissao que esta dentro do grupo InfNfse), data de emissão do Rps (tag DataEmissao que esta dentro do grupo Rps) estão no formado AAAA-MM-DD. Agora se você abrir o XML *-comp-nfse.xml que é o retorno da consulta vai notar que, a data de emissão da nota e a data de emissão do Rps estão no formato DD/MM/AAAA. Esse provedor precisa tomar uma decisão, ou ele gera a data no formato AAAA-MM-DD (estabelecido no manual da ABRASF) ou ele segue o formato DD/MM/AAAA para todos os serviços que geram e retornam o XML da nota. Essa falta de padrão, demonstra que o XML da nota não é gerado por uma única rotina. Temos um outro provedor que fez a mesma porcaria. É bem provável que um comprou a implementação do WebService do outro.

Boa tarde Marcelo, Também fiz os testes que você fez e sempre retorna o erro 404. O manual mostra como devemos fazer, mas mesmo assim não funciona. Não vejo outra alternativa a não ser entrar em contato com o provedor e expor o problema. Você consegue conversar com o pessoal do provedor? A URL "https://www.tributosmunicipais.com.br/nfse/api/nfse.wsdl" abre em um navegador e mostra o WSDL. Já a URL recomenda pelo manual "https://www.tributosmunicipais.com.br/nfse/api/" acrescida de "?tokenAuth=17a...." ocorre o erro 404 que indica que essa URL não existe. Questione eles sobre a URL correta que devemos usar.

Boa noite Alan, Acabei de fazer um teste com o programa exemplo e não ocorreu erro de validação por conta da Alíquota.

Boa noite Edelvandro, Você trabalha com qual linguagem?

Boa noite Furquim, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Boa noite Bill, Favor atualizar os fontes, reinstalar o ACBr e faça novos testes.

Bom noite Marcelo, Já esta no SVN. Favor atualizar os fontes, reinstalar o ACBr e faça novos testes.

Olá Pessoal, Vou relacionar todos os métodos implementados no componente ACBrNFSeX no que se refere ao provedor PadraoNacional. Emitir -> Envio do DPS (Declaração Prévia de Serviços) no modo unitário, o que tudo indica vai ser a única opção, ou seja, não teremos o envio em lote. EnviarEvento -> Envio de eventos, Cancelamento, Cancelamento por Substituição, Análise para Cancelamento, Confirmação do Prestador, Confirmação do Tomador, Confirmação do Intermediário, Rejeição do Prestador, Rejeição do Tomador e Rejeição do Intermediário. ConsultarNFSePorRps -> apensar do nome do método constar Rps, mas para o Padrão Nacional ele vai realizar a consulta através da chave da DPS. ConsultarNFSe -> é o mesmo método dos demais provedores, mas para o Padrão Nacional ele vai realizar a consulta através da chave da NFS-e. ConsultarEvento -> através desse novo método vai ser possível consultar um evento informado apenas a chave da NFS-e, ou a chave mais o tipo de evento ou a chave mais o tipo mais o número sequencial. ConsultarDFe -> através desse novo método vai ser possível baixar o XML da nota ou eventos informando o último NSU - Número Sequencial Único ou a chave da nota. ObterDANFSE -> através desse novo método é possível obter o PDF da DANFSE informando a chave da NFS-e. Todos os métodos estão funcionando com exceção do ConsultarEvento que a API não está aceitando o GET da consulta. Ainda falta implementar as consultas que vão retornar os Parâmetros Municipais.

Olá Pessoal, Já se encontra no SVN a implementação do provedor Bauhaus que atende as cidades: Itapema/SC e Redenção/PA. Convido a todos a realizarem testes e reportar os problemas que encontrarem. Vamos juntos deixar mais este provedor funcional no componente ACBrNFSeX.

Boa tarde Furquim Já inclui na minha lista de tarefas para analisar o problema. TK-3186

Boa tarde, Você deve ter Unit alterada na sua máquina, favor verificar se não tem unit com uma bolinha vermelha no ícone, caso afirmativo delete a unit, atualize novamente e reinstale o ACBr.

Bom dia Fabio, Essa resposta do provedor não condiz com a realidade. Pois colocar todo o XML referente a consulta dentro do grupo <Pedido> para depois realizar a assinatura digital não se faz necessário. Apesar de não constar no Manual da ABRASF e nem nos schemas disponibilizados pela ABRASF a assinatura digital para as consultas, os provedores abaixo : SilTecnologia que segue a versão 2.03, que alterou os Schemas para que as consultas fossem também assinadas, mas não acrescentou o grupo <Pedido>. Infisc que segue a versão 2.01, fez a mesma coisa que o provedor SilTecnologia. DSF que segue a versão 2.03, também fez a mesma coisa que o provedor SilTecnologia. Vou colocar abaixo a procedure Configuração do provedor SilTecnologia para comprovar o que foi dito acima. procedure TACBrNFSeProviderSilTecnologia203.Configuracao; begin inherited Configuracao; ConfigGeral.ConsultaPorFaixaPreencherNumNfseFinal := True; with ConfigAssinar do begin LoteRps := True; ConsultarLote := True; ConsultarNFSeRps := True; ConsultarNFSePorFaixa := True; ConsultarNFSeServicoPrestado := True; ConsultarNFSeServicoTomado := True; CancelarNFSe := True; RpsGerarNFSe := True; RpsSubstituirNFSe := True; IncluirURI := False; end; with ConfigWebServices do begin VersaoDados := '2.03'; VersaoAtrib := '2.03'; end; end; Essa procedure se encontra na unit SilTecnologia.Provider Vocês podem abrir as units Provider dos outros 2 provedores para comprovarem que eles também realizam a assinatura das consultas. Caso desejam ver os schemas lista abaixo a pasta onde se encontram os schemas dos 3 provedores sitados. SilTecnologia: ...\Exemplos\ACBrDFe\Schemas\NFSe\SilTecnologia\2.03 Infisc: ...\Exemplos\ACBrDFe\Schemas\NFSe\Infisc\2.01 DSF: ...\Exemplos\ACBrDFe\Schemas\NFSe\DSF\2.03 Abaixo a alteração que o provedor SilTecnologia fez no Schema referente ao Consultar Nfse por Rps (por exemplo): <xsd:element name="ConsultarNfseRpsEnvio"> <xsd:complexType> <xsd:sequence> <xsd:element name="IdentificacaoRps" type="tcIdentificacaoRps" minOccurs="1" maxOccurs="1" /> <xsd:element name="Prestador" type="tcIdentificacaoPrestador" minOccurs="1" maxOccurs="1" /> <xsd:element ref="dsig:Signature" minOccurs="0" maxOccurs="1" /> </xsd:sequence> </xsd:complexType> </xsd:element> Como Você pode ver simplesmente foi acrescentado o elemento Signature abaixo do Prestador. Tudo muito simples sem nenhuma frescura.

Bom dia Willian, Favor entrar em contato com o provedor e expor o problema. Notei que você ainda esta usando o componente antigo. Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não está mais tendo manutenção. Faça os testes usando o programa exemplo do novo componente. Manual de Migração https://www.projetoacbr.com.br/forum/topic/63017-manual-de-migração-para-o-novo-componente-de-emissão-de-nfs-e/

Bom dia Daniel, Já inclui na minha lista de tarefas para analisar o problema. TK-3185