Italo Giurizzato Junior

Bom dia Hamilton, Os Schemas do provedor Ginfes são diferentes do EReceita, a aplicação esta pegando os Schemas corretos?

Bom dia Rubens, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia, Exatamente, faça o controle do numero do lote também, pois existem provedores que não aceitam lotes com o mesmo numero.

Bom dia Fernando, Muito obrigado pela colaboração, fiz algumas alterações, já enviei para o repositório, favor atualizar e refaça os testes.

Bom dia Sergio, O programa exemplo se utiliza do componente ACBrNFSe e este possui uma propriedade chamada DANFSE usada para "linkar" o componente de emissão do DANFSE que pode ser o ACBrNFSeDANFSEFR (feito em Fast Report) ou o ACBrNFSeDANFSERL (Feito em Fortes Repor) alem dessa propriedade temos a propriedade chamada MAIL usada para "linkar" o componente de envio de e-mail: ACBrMail. Estude o programa exemplo.

Bom dia Miro, Você chegou a instalar o certificado do provedor PBH? Abrindo o seu XML de envio de lote que você anexou em postagens anteriores não encontrei nenhum espaço em branco entre os caracteres.

Bom dia Rubens, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Serginho, A alteração que fiz visa o provedor SmarAPD e não o provedor Betha. No seu caso o provedor em questão não é o Bethav2? Se sim, abra o arquivo Cidades.ini e altere de Bethav2 para Betha o provedor da cidade em questão e refaça os testes.

Bom dia ALA, Até onde sei o valor da alíquota no XML tem que aparecer dividia por 100 quando o provedor for Ginfes.

Bom dia Guima, Exato, o motivo da correção tem que ter no mínimo 15 carácteres e se for a segunda carta de correção o valor de nSeqEvento tem que ser 2.

Bom dia Daniel, Ocorreu uma atualização dos Schemas para a versão 4.00, uma dessas alterações deixa a tag indEscala opcional. Fiz uma alteração que permita gerar ou não a respectiva tag. Para não gerar basta atribuir o valor ieNenhum a propriedade indEscala. Favor atualizar todos os fontes de todas as pastas e refaça os testes.

Bom dia Adriano, O campo urlChave (campo novo e obrigatório na NFC-e) tem um limite de 85 caracteres, logo as SEFAZ vão ter que encurtar para que o XML da NFC-e versão 4.00 seja validado ou vão ter que aumentar o tamanho máximo no schema.

Bom dia Jeferson, Entendo perfeitamente, também concordo que devemos fazer um software PAI - Programa a prova de imbecil. Mas esse camarada que alterou o XML de uma nota de entrada, fez isso com qual intensão? Se ele é capaz de fazer isso imagina o que mais ele é capaz de fazer se tiver acesso livre ao banco de dados. Ou ela fez isso para te ferrar ou ferrar o dono da empresa, logo não é uma pessoa confiável.

Bom dia Sandro, A SEFAZ-SP já liberou o ambiente de homologação para a versão 4.00 da NF-e. O problema é que fizeram a copia do WSDL e esqueceram de alterar as URLs dos serviços e dos SoapAction. O componente esta pronto e em conformidade com os manuais e notas técnicas, mas devido a mercadoria que fizeram no Web Services ainda não é possível fazer os testes. Veja este exemplo do Consultar Status de Serviço: Na SEFAZ-RS a URL do soapAction é: http://www.portalfiscal.inf.br/nfe/wsdl/NFeStatusServico4/nfeStatusServicoNF Já na SEFAZ-SP esta da seguinte forma: http://www.portalfiscal.inf.br/nfe/wsdl/NfeStatusServico2/nfeStatusServicoNF Notou a diferença? No componente esta da seguinte forma: if (FPConfiguracoesNFe.Geral.VersaoDF >= ve400) then begin FPServico := GetUrlWsd + 'NFeStatusServico4'; FPSoapAction := FPServico + '/nfeStatusServicoNF'; end Isso faz com que ao consultar o Status de Serviço na SEFAZ-RS temos resposta, ou seja vai funcionar, por outro lado se realizar a mesma consulta na SEFAZ-SP não vai funcionar, pois a URL montada pelo componente é diferente da que consta no Web Service de São Paulo. SEFAZ-BA : soapAction="http://www.portalfiscal.inf.br/nfe/wsdl/NFeStatusServico4/nfeStatusServicoNF" SEFAZ-MG: soapAction="http://www.portalfiscal.inf.br/nfe/wsdl/NFeStatusServico4/nfeStatusServico4" SEFAZ-MS: soapAction="http://www.portalfiscal.inf.br/nfe/wsdl/NFeStatusServico4/nfeStatusServicoNF" Como você pode ver esta difícil das SEFAZ entrarem em um acordo com as URLs.

Bom dia, Você configurou corretamente o componente, informando o valor moNFCe a propriedade ModeloDF? Você atribuiu o valor 65 ao campo Modelo ao alimentar os dados da nota?

Bom dia Whanderson, Tenha em mente o seguinte: A numeração do RPS é de responsabilidade da sua aplicação e esse numeração é sequencial. Já a numeração da NFS-e é de responsabilidade do provedor e que também é sequencial. O componente gera o XML do RPS e envia para o web services do provedor, este por sua vez gera o XML da NFS-e e nos retorna. O provedor ISSNet segue entre aspas a versão 1 do layout da ABRASF, sendo assim só é permitido apenas um item da lista de serviço que o contribuinte esteja cadastrado junto a prefeitura.

Miro, Tanto o RPS quanto o Lote estão sendo assinados, logo o problema não é assinatura e sim a conexão com o Web Services. O que devemos checar agora: Configuração do Internet Explorer no que diz respeito as opções sobre o SSL e TLS, revogação de certificados. Firewall, anti-vírus e liberação de portas.

Bom dia André, Favor atualizar novamente os fontes e refaça os testes.

Bom dia, O campo ItemListaServico aceita no máximo 5 caracteres, mas o campo CodigoTributacaoMunicipio aceita até 20. Informe 09.01 (com ponto ou sem ponto, ou com zero a esquerda ou sem o zero a esquerda) no campo ItemListaServico. E informe 09.01.01 no campo CodigoTributacaoMunicipio.

Bom dia Miro, O XML do RPS ou o XML referente ao envio do Lote esta assinado? Se sim o problema não é a assinatura e sim a conexão com o Web Service.

Bom dia a todos, Na unit ACBrNFeNotasFiscais temos: if (NFe.Ide.modelo = 65) and (Configuracoes.Geral.IncluirQRCodeXMLNFCe) then begin with TACBrNFe(TNotasFiscais(Collection).ACBrNFe) do begin NFe.infNFeSupl.qrCode := GetURLQRCode(NFe.Ide.cUF, NFe.Ide.tpAmb, onlyNumber(NFe.infNFe.ID), trim(IfThen(NFe.Dest.idEstrangeiro <> '', NFe.Dest.idEstrangeiro, NFe.Dest.CNPJCPF)), NFe.Ide.dEmi, NFe.Total.ICMSTot.vNF, NFe.Total.ICMSTot.vICMS, NFe.signature.DigestValue); if NFe.infNFe.Versao >= 4 then NFe.infNFeSupl.urlChave := GetURLConsultaNFCe(NFe.Ide.cUF, NFe.Ide.tpAmb); GerarXML; end; end; Como vocês podem ver o conteúdo da tag urlChave é gerado automaticamente caso a versão seja 4 ou superior.

Bom dia José, O XML da NFC-e é o mesmo da NF-e. Se você utiliza o componente ACBrNFe para emitir a NF-e, lembre-se que ele possui uma propriedade de configuração chamada ModeloDF que por padrão recebe o valor moNFe, se você alterar para moNFCe o componente vai emitir a NFC-e. Por se tratar do mesmo componente os comandos são exatamente os mesmos. Agora se você usa o Monitor, lembre-se que este se utiliza do componente ACBrNFe, logo ao montar o arquivo TXT, você não vai ter dificuldades, pois como dito antes é a mesma coisa e consequentemente os comandos são os mesmos, lembre-se de configurar o monitor para a emissão de NFC-e.

Bom dia Fábio, Um XML depois de gerado e principalmente assinado não se deve alterar nada, pois isso o invalida. Agora se ao gerar novamente com a informação correta, esta gerando um segundo XML isso é devido ao cNF (Código Aleatório da Nota Fiscal) que você deve esta atribuindo o valor zero, isso faz com que o componente gere automaticamente um numero aleatório, numero este que ira compor a chave da NFe. O seu sistema tem um erro de projeto. Ao salvar no banco de dados a nota (antes de gerar o XML) você deve gerar um numero aleatório com até 8 dígitos e que seja diferente de zero. Salve esse numero com os demais dados da nota. Ao alimentar o componente com os dados da nota, atribua ao campo cNF o numero que foi previamente gerado e guardado no banco de dados juntamente com os demais dados da nota. Dessa forma você vai poder gerar o XML de uma mesma nota quantas vezes desejar, pois a chave sempre será a mesma.

Boa noite Miro, O problema não esta nessa unit, pelo simples fato dela ser utilizada pelos componentes: ACBrNFe, ACBrCTe, ACBrMDFe, ACBrBPe e ACBrNFSe. Se a cidade utiliza um provedor e ao executar o método enviar acaba interpretando um outro provedor, isso significa que ou a sua aplicação esta alterando o provedor, ou seja, o componente lê do arquivo Cidade.ini o provedor (BHISS) e depois a sua aplicação altera esse provedor para outro (EL) de forma indevida, ou quem esta fazendo isso é o próprio componente. Vasculhe todos os fontes da sua aplicação por (proEL), pois o componente não esta trocando um provedor pelo outro.

Bom dia Sergio, Procure sempre realizar testes com o programa exemplo. Note que o componente ACBrNFSe possui uma propriedade chamada DANFSE onde você precisa "linkar" o componente do DANFSE, uma vez que temos um feito em Fast e o outro feito em Fortes Report. O método enviar por padrão após receber o XML da NFS-e gerado pelo provedor se encarrega de imprimir o DANFSE, mas existe o método Imprimir. Exemplos desses métodos e outros vide o programa exemplo do componente.