Italo Giurizzato Junior

Boa tarde, Esse erro também ocorre com o programa exemplo?

Boa tarde, Chegou a informar os dados que o webservice esta reclamando que esta faltando? Caso não tenha feito esse teste, faça. Se mesmo assim ainda surgir erros absurdos como esses, o jeito vai ser entrar em contato com o provedor e relatar o problema.

Boa tarde Guilherme, Chegou a entrar em contato com o provedor para saber o motivo que eles estão rejeitando o Rps? Quais são os valores de: SSLLib, CryptLib, HttpLib, XmlSignLib e SLLType ?

Boa tarde, Quais são os valores de: SSLLib, CryptLib, HttpLib, XmlSignLib e SLLType ?

Boa tarde Ronald, No arquivo ACBrNFSeXServicos.ini não temos as URLs de homologação de nenhuma cidade atendida pelo provedor Agili. Sendo assim essa informação me parece correta. O jeito é testar mesmo em ambiente de produção.

Bom dia Alexandre, Não vejo outra alternativa. O jeito vai ser você entrar em contato com o provedor e expor o problema, anexando o XML de envio do Rps e a imagem com a mensagem de erro.

Boa tarde Everson, O que tudo indica é que o seu Fortes Report esta desatualizado. Vai ser necessário baixar uma atualização do Fortes, reinstalar, depois atualizar os fontes do ACBr e reinstalar.

Boa tarde Moura, Complementando o que o @Juliomar Marchetti lhe passou. Da mesma forma que o lote de notas é uma lista, o retorno também é uma lista. Se você enviar um lote com 2 ou mais notas (máximo 50), teremos como resposta o numero do recibo, de posse do recibo devemos consultar. Teremos como retorno dessa consulta uma lista. Se você enviar 10 notas no lote, no retorno da consulta teremos uma lista com 10 itens. Cada um desses item é o resultado do processamento de cada nota. A principio o resultado do processamento da primeira nota do lote é o primeiro item do retorno da consulta e assim por diante. Porque a principio? Porque a SEFAZ inclui na lista primeiro as notas que foram rejeitadas e depois as que foram autorizadas. Sendo assim é importante ler os campos cStat e chave da nota que consta em cada item do retorno para saber se a nota foi autorizada ou não. Se cStat é 100 significa que foi autorizada.

Boa tarde, Manual da NF-e? Qual manual? Eu não encontrei esse texto em nenhum manual da NF-e.

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

Boa tarde Guilherme, Eu validei a assinatura que consta no XML 2668.1-env.lot.xml e realmente esta invalida. Por outro lado fiz um teste usando o programa exemplo e tentei validar o XML de envio de lote através do mesmo site abaixo e a assinatura é valida. Não sei o que pode ter ocorrido. Receita Federal do Brasil - Validador de Assinaturas (fazenda.gov.br)

Boa tarde Alexandre, Qual é o valor que você configurou para a propriedade Timeout no componente ? Recomendamos que seja configurado o valor de 30 a 40 mil.

Boa tarde, Você notou que Ribeirão Preto se utiliza de outro provedor? O provedor ISSNet é problemático, muitas coisas nele não funcionam como deveria funcionar. Segundo o Schema temos: <xsd:element name="ConsultarNfseServicoTomadoEnvio"> <xsd:complexType> <xsd:sequence> <xsd:element name="Pedido" minOccurs="1" maxOccurs="1"> <xsd:complexType> <xsd:sequence> <xsd:element name="Consulente" type="tcIdentificacaoPessoaEmpresa" minOccurs="1" maxOccurs="1" /> <xsd:choice> <xsd:element name="NumeroNfse" type="tsNumeroNfse" minOccurs="1" maxOccurs="1" /> <xsd:element name="PeriodoEmissao" minOccurs="1" maxOccurs="1"> <xsd:complexType> <xsd:sequence> <xsd:element name="DataInicial" type="xsd:date" minOccurs="1" maxOccurs="1" /> <xsd:element name="DataFinal" type="xsd:date" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="PeriodoCompetencia" minOccurs="1" maxOccurs="1"> <xsd:complexType> <xsd:sequence> <xsd:element name="DataInicial" type="xsd:date" minOccurs="1" maxOccurs="1" /> <xsd:element name="DataFinal" type="xsd:date" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:choice> <xsd:element name="Prestador" type="tcIdentificacaoPessoaEmpresa" minOccurs="0" maxOccurs="1" /> <xsd:element name="Tomador" type="tcIdentificacaoPessoaEmpresa" minOccurs="0" maxOccurs="1" /> <xsd:element name="Intermediario" type="tcIdentificacaoPessoaEmpresa" minOccurs="0" maxOccurs="1" /> <xsd:element name="Pagina" type="tsPagina" minOccurs="1" maxOccurs="1"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element ref="dsig:Signature" minOccurs="0" maxOccurs="1" /> </xsd:sequence> </xsd:complexType> </xsd:element> Como você pode ver a tag Consulente é obrigatória, as tags NumeroNfse, PeriodoEmissao e PeriodoCompetencia estão agrupadas em um choice, isso significa que uma apenas uma deve constar no XML, as tags Prestador, Tomador e Intermediario são opcionais, isso significa que elas podem não constar no XML e por fim a tag Pagina é obrigatória. O seu XML contem a tag Consulente, PeriodoEmissao e Pagina, portanto satisfaz o que foi definido no Schema. Resumindo o XML foi gerado e validado corretamente. Essas mensagens de erro, é bug no webservice que esta exigindo informações que são opcionais.

Boa tarde Everson, Já esta no SVN.

Boa tarde Willians, Essa desativação da validação da assinatura foi realizada somente em ambiente de homologação ou em produção também? Pois até onde sei o ambiente de homologação do provedor Fiorilli contem um bug que eles não admitem que é validar a tag Signature com o prefixo ns2, como podemos ver na mensagem de erro retornada pelo webservice: Invalid content was found starting with element 'ns2:Signature'.

Olá pessoal, Foi implementado um novo provedor, trata-se do SysISS que segue a versão 2.02 do layout da ABRASF. Como todos sabem, não estamos mais realizando manutenção no componente antigo, logo o provedor SysISS só esta disponível no novo componente: ACBrNFSeX. Quem nos passou todas as informações sobre esse provedor foi o nosso amigo @Everson Clei, que mais uma vez agradeço pela contribuição e colaboração. Ele também nos informou que no momento o provedor atende as seguintes cidades: Rondon/PR, Prado Ferreira/PR, Lupionópolis/PR, Rancho Alegre/PR e Cafeara/PR. Caso mais alguém saiba de outras cidades atendidas pelo mesmo provedor ou de outros provedores já implementados, é muito fácil acrescentar novas cidades, basta seguir o passo a passo da postagem abaixo. Se você tem informações de um provedor que ainda não foi implementado faça como nosso amigo Everson, crie uma postagem aqui no fórum anexando a documentação: manual, Schemas (arquivos XSD), URLs de homologação e produção das cidades atendidas por esse provedor.

Souza, Analisando o seu XML com um outro que tenho que foi baixado do Portal da NFS-e Padrão Nacional, notei as seguintes diferenças: No seu XML a série é 600 e o que foi baixado é 900 No seu XML consta o valor ZZ na tag cPaisPrestacao, no baixado não consta essa tag. Você deve estar atribuindo um valor diferente de zero e de 1058 ao campo: NFSe.Servico.CodigoPais

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

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

Já esta no SVN.

Boa tarde Everson, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3901

Boa tarde Souza, Vou ver se eu descubro o que esta ocorrendo.

Boa tarde Hugo, Leia essa postagem.

Olá Pessoal, Abaixo temos informações sobre a convivência das versão 3.00 e 4.00 do CT-e, que vai até 31/01/2024. Colaboração do nosso amigo Alexandre Parabocz.