Italo Giurizzato Junior

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

Boa tarde Willian, Esta utilizando o programa exemplo para os testes? Se sim, quais são os valores de: SSLLib, CryptLib, HttpLib, XmlSignLib e SLLType ?

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, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-2891

Boa tarde Neto, Até onde sei esse provedor não requer nenhum token. Quanto ao erro de validação, esta informando que não devemos gerar a tag CodigoPais. Experimente atribuir o valor zero ao campo CodigoPais do tomador.

Boa tarde Mario, Isso porque você esta sempre informando o mesmo Ultimo NSU. A cada execução do DistribuicaoDFePorUltNSU devemos sempre informar o valor do campo UltNSU retornado pela execução anterior. Ou tem alguém (contador) utilizando também essa funcionalidade para baixar os XML das notas. Se é o caso, o seu cliente tem que ter uma conversa muito seria com o contador dele.

Daniel, Sim, Mas, lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não esta 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 Leandro, Mesmo você adicionando os dois condutores só é impresso o primeiro?

Bom dia Guilherme, Mas no SVN já consta que essa tag é obrigatória. Faz quanto tempo que você não atualiza os seus fontes?

Willian, Abra a unit EloTech.Provider Procure por senha, você vai encontrar o seguinte: function TACBrNFSeProviderEloTech203.GerarRequerente(const CNPJ, InscMunc, Senha: string): string; var Homologacao: Boolean; begin Homologacao := (TACBrNFSeX(FAOwner).Configuracoes.WebServices.AmbienteCodigo = 2); Result := '<IdentificacaoRequerente>' + '<CpfCnpj>' + '<Cnpj>' + CNPJ + '</Cnpj>' + '</CpfCnpj>' + '<InscricaoMunicipal>' + InscMunc + '</InscricaoMunicipal>' + '<Senha>' + Senha + '</Senha>' + '<Homologa>' + LowerCase(booltostr(Homologacao, True)) + '</Homologa>' + '</IdentificacaoRequerente>'; end; Depois procure por GerarRequerente, você vai encontrar: Requerente := GerarRequerente(Emitente.CNPJ, Emitente.InscMun, Emitente.WSSenha); Resumindo, Você tem que configurar o componente no que se refere ao Emitente, informando o CNPJ a Insc. Municipal e a senha. O componente estando configurado corretamente, a tag Senha vai conter a senha e não vai ocorrer o erro de validação.

Bom dia Mauricio, Favor atualizar os fontes, reinstale o ACBr e faça novos testes com a cidade Ronda Alta.

Bom dia Daniel, Favor atualizar os fontes, reinstale o ACBr e faça novos testes para a cidade Socorro. Quanto a Sumaré se faz necessário descobrir quais são as URLs de homologação e produção. Com relação a Americana basta você abrir o arquivo ACBrNFSeXServicos.ini e procurar pela cidade. Descomentar as linhas indicadas e iniciar os testes em ambiente de homologação. Pelo fato da URL ser outra e a versão do XML também o arquivo mencionado só vai ser alterado a partir do dia 01/09/2022, pois a partir dessa data ambos os ambientes já vão estar com as novas URLs e versão do XML.

Bom dia Cristofer, Pelo seu relato o problema não é com todos os seus clientes, correto? E o componente esta configurado para TLS 1.2, correto? A conexão com a internet dos seus clientes também esta ok. Isso me faz crer que pode ter ocorrido alguma atualização do Windows. Você configura o componente com o OpenSSL ou WinCrypt?

Bom dia Willian, Pela mensagem de erro concluo que foi atribuído uma string vazia para a tag Senha sendo que esta deveria possuir no mínimo 6 caracteres. Abrindo o arquivo nfse_v2_03.xsd e procurando pela palavra senha temos: <xsd:simpleType name="tsSenha"> <xsd:restriction base="xsd:string"> <xsd:maxLength value="30"/> <xsd:minLength value="6"/> </xsd:restriction> </xsd:simpleType> O tipo simples senha é uma string com no mínimo 6 e no máximo 30 caracteres.

Bom dia a todos, Quando o provedor não quer conversa com o desenvolvedor, é muito simples de resolver. Peça a todos os seus clientes que protocole um documento na prefeitura relatando que não estão conseguindo realizar testes no ambiente de homologação e estão passando por problemas também no ambiente de produção ao tentar emitir a nota via webservice e não pelo site. Quanto mais contribuintes protocolarem reclamação na prefeitura, mais rápido o provedor vai resolver os problemas. Fica a dica.

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

Bom dia, Realmente o provedor Centi esta gerando o XML da NFS-e fora do padrão da ABRASF. Já inclui na minha lista de tarefas para analisar esse problema. TK-2888

Bom dia Mario, É normal retornar um resumo na nota. Com base nas informações desse resumo você tem condições de informar a SEFAZ através dos eventos de Manifestação do Destinatário se comprou ou não desse fornecedor e se recebeu ou não a mercadoria. Só depois de manifestar as notas, ou seja, enviado um dos eventos de Manifestação do Destinatário é que a SEFAZ vai liberar o XML completo da nota. E para obter o XML completo você vai usar o mesmo método que usou para obter o resumo. Por favor leia o tópico abaixo para entender como funciona todo o processo:

Que maravilha, mais um provedor que se diz seguir o layout da ABRASF, mas não tem capacidade de gerar o XML na NFS-e segundo o layout da ABRASF. Abra esse XML e veja se dentro do grupo <InfDeclaracaoPrestacaoServico> existe o grupo <Rps>, dentro deste o grupo <IdentificacaoRps> e dentro deste a tag <Numero> com o numero do Rps. A resposta é: NÃO. Será que algum dia alguém lá de cima vai dar um basta nessa zona? Até quando vamos ter que ficar fazendo gambiarras para ler o XML desses provedores constituídos por amadores? Esse provedor segue a versão 2.02 do layout da ABRASF, versão esta que possui os seguintes serviços documentos no manual da ABRASF: EnviarLoteRps, EnviarLoteRpsSincrono, GerarNfse, ConsultarLoteRps, ConsultarNfsePorRps, ConsultarNfsePorFaixa, ConsultarNfseServicoPrestado, ConsultarNfseServicoTomado, CancelarNfse e SubstituirNfse. Mas implementou em seu webservices os seguintes serviços: GerarNfse, ConsultarNfsePorEps e CancelarNfse. Além de implementar somente 3 dos 10 serviços documentados, implementa de forma errada. Utilize o método ConsultarNfsePorRps e anexe o XML retornado, vamos comparar para saber se o XML da NFS-e gerado pelo serviço GerarNFse e pelo ConsultarNFSePorRps são iguais.

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

Boa tarde Jhonlenon, Desculpe esta muito confuso o seu questionamento, por favor seja mais claro. Não estou entendendo se o seu problema é alimentar o componente com os dados ou a leitura dos dados que estão no XML da NFS-e retornado pelo provedor.

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

Boa tarde Elisângela, Qual é a cidade? O provedor SimplISS possui 2 webservices. Um que segue a versão 1 do layout da ABRASF que não exige o certificado digital. O outro que segue a versão 2.03 que exige o certificado digital. Essa imagem que você anexou se refere ao arquivo ini da versão 1 do webservice utilizado pelo componente antigo, portanto esse arquivo não funciona no novo componente. No novo componente na unit SimplISS.provider na procedure TACBrNFSeProviderSimplISS.Configuracao você vai encontrar a seguinte linha: UseCertificateHTTP := False; Indicando que não se faz necessário o uso do certificado. Já na procedure TACBrNFSeProviderSimplISS203.Configuracao não tem essa linha visto que se faz necessário assinar o Rps, o Lote de Rps o o Rps ao ser enviado de forma unitário. Veja: with ConfigAssinar do begin Rps := True; LoteRps := True; RpsGerarNFSe := True; end;

Boa tarde Rogério, Vamos lá a cidade de itaquaquecetuba/SP se utiliza do provedor Ginfes. Até hoje todas as cidades atendidas pelo provedor Ginfes valor do campo ItemListaServico deve ser formatado, exemplo: 14.01, pelo jeito para a cidade em questão resolveram mudar isso. Paciência. Você consegue entrar em contato com o provedor e questionar sobre essa alteração na formatação do campo ItemListaServico? Quanto ao nome do município do tomador segundo os Schemas temos o seguinte: <xsd:complexType name="tcEndereco"> <xsd:sequence> <xsd:element name="Endereco" type="tsEndereco" minOccurs="0"/> <xsd:element name="Numero" type="tsNumeroEndereco" minOccurs="0"/> <xsd:element name="Complemento" type="tsComplementoEndereco" minOccurs="0"/> <xsd:element name="Bairro" type="tsBairro" minOccurs="0"/> <xsd:element name="CodigoMunicipio" type="tsCodigoMunicipioIbge" minOccurs="0"/> <xsd:element name="Uf" type="tsUf" minOccurs="0"/> <xsd:element name="Cep" type="tsCep" minOccurs="0"/> </xsd:sequence> </xsd:complexType> Como você pode ver não existe uma tag para constar o nome do município apenas o seu código IBGE.