Italo Giurizzato Junior

Leandro, Você esta com todos os fontes de todas as pastas atualizados? Você utilizou o ACBrInstall_Trunk2 para instalar os componentes, inclusive o ACBrGNRE? Esse tipo de erro ocorre quando o Delphi não encontra a pasta onde encontra o componente. Você já procurou por essa DCU, para saber em qual pasta ela esta? Verificou no Library Path do Delphi se o caminho dessa pasta consta da lista?

Bom dia Juliano, Você abriu o seu XML com um navegador? Se sim, notou isso: &cDest=72496207034 &dhEmi= a existência de espaço em branco entre o CPF do destinatário e o elemento dhEmi? Isso significa que você esta atribuindo ao campo CNPJCPF o numero do CPF formatado com 14 caracteres sendo que o CPF possui apenas 11. A rotina que gera o XML remove os espaços em branco, mas a rotina que gera a URL do QR-Code não faz isso.

Leandro, O que ocorre durante a compilação do programa exemplo?

Claudio, O componente ACBrNFe que é usado no ACBrMonitor Plus possui apenas uma rotina para gerar o XML. O XML é gerado com base nos valores atribuídos nos campos, que no seu caso é através da leitura do XML que você gerou. Como existem TAGs opcionais e diversas regras de negócio isso faz com que até TAGs obrigatórias não sejam geradas em função dessas regras. Para saber o que foi suprimido só comparando mesmo os 2 XML. Desculpa, mas no meu entendimento é a sua rotina que esta errada, é preciso fazer uma analise para descobrir em quais situações ela gera o que não devia ou qual a informação deva ser informada para que uma TAG ou grupo realmente seja gerado.

Claudio, Então quer dizer que você utiliza o ACBrMonitor Plus? Se sim, o comando EnviarNFe le o XML e gera novamente.

Bom dia, Na sua aplicação existe uma rotina para efetuar o cancelamento? Com certeza sim, pois bem o cancelamento é um evento e o EPEC também é. Sendo assim, você pode se basear na sua rotina de cancelamento para fazer a do EPEC.

Bom dia Claudio, Acredito que isso não seja possível. Os casos que acompanhei de TAGs sendo suprimidas do XML o motivo era que o XML esta sendo gerado por uma rotina própria do desenvolvedor e depois o XML era lido pelo ACBr para que o mesmo fosse assinado e enviado. O motivo sempre era falhas na rotina própria do desenvolvedor e não do componente. Lembre-se que o LoadFromFile possui 2 parâmetros, sendo que o segundo por padrão vale True, isso faz com que o componente gere novamente o XML e desta forma pode suprimir o que esta errado. Mas se você desejar pode passar o valor False, neste caso o componente apenas lê os dados de XML. Exemplo: LoadFromFile(sNomeXML, False)

Bom dia Hugo, Muito obrigado pela colaboração, já fiz a alteração. Baseado no Enviar síncrono e Consultar NFSe por RPS alterei os demais. Já esta disponível o novo INI para o provedor GovDigital, favor atualizar os fontes e realizar novos testes.

Tiago ao digitar a URL no navegador é solicitado a escolha do certificado? Pois aqui fiz um teste e não apareceu o erro 403.

Bom dia Elias, Esse provedor não segue o layout da ABRASF. No momento estou empenhado em fazer com que os provedores que seguem o layout funcionem 100% no componente. Mas nada impede que você estude como outros provedores que não seguem o layout foram implementados e implemente o provedor em questão.

Bom dia Leandro, Já esta disponível na pasta exemplos o programa exemplo do ACBrGNRE basta você compilar ele e fazer os testes que deseja.

Boa noite, O FCP esta dentro do grupo <ICMSUFDest> e este grupo só deve aparecer no XML se a venda for interestadual para consumidor final. Mais informações vide a Nota Técnica 2015/003 versão 1.60

Tiago, As NF-e são emitidas na mesma maquina que você esta tentando emitir a NFS-e ? Se sim não seria o problema de configuração do IE. Você esta usando o programa exemplo para realizar os testes?

Tiago, O certificado não esta vencido?

Pode ser esse, mas você configurou o componente com o numero de série do certificado?

Tiago, O erro 403 significa que você precisa de um certificado valido para poder acessar o Web Service.

Boa noite Tiago, Não é nada disso. 1. Você alimenta o componente com os dados do RPS - Recibo Provisório de Serviço; 2. Dependendo do provedor (empresa que implantou a NFS-e na cidade do contribuinte) será utilizado o método Enviar ou Gerar ou EnviarSincrono; Os métodos Enviar e EnviarSincrono permitem o envio de um lote com até 50 RPS, já o Gerar somente 1. No que diz respeito a assinatura tudo depende do provedor, alguns não se faz necessidade de assinar nada, outros o RPS tem que ser assinado, outros é o Lote que tem que ser assinado e outros tem que assinar o RPS e o Lote. Os métodos acima sitados resolvem o problema da assinatura, pois existe um arquivo INI para cada provedor que diz o que tem que ser assinado. No final de todo o processo o que temos como retorno é o XML da NFS-e, ou seja, o componente gera o XML do RPS e envia para o Web Services e este retorna o XML da NFS-e. O XML da NFS-e poderá estar assinado ou não, isso depende de cada provedor. Para que o método Enviar funcione de forma completa é preciso atribuir o valor True a propriedade que faz com que o componente realize a consulta após o envio. Se essa propriedade estiver com o valor False o Lote é enviado e o método Enviar é finalizado, não realizando mais nenhuma tarefa. Espero ter lhe dado um norte.

Boa noite Wender, Quando você diz atualizar esta querendo substituir o protocolo de autorização pelo de cancelamento? Se sim, esquece isso não é legal. Esta querendo acrescentar ao XML o protocolo de autorização a um XML que esta apenas assinado? Se sim, você carregou o componente com o XML assinado antes de executar o método Consultar?

Maravilha Hugo.

Boa tarde Luis, Sim, devemos deixar um * quando o provedor não define um SoapAction. Da forma que esta não esta conseguindo estabelecer uma conexão com o provedor e enviar o RPS?

Boa tarde Rafael, Muito obrigado pela informação. Alteração feita e disponibilizada. Favor atualizar todos os fontes e realizar novos testes.

Boa tarde Rodrigo, Isso é muito estranho mesmo. Faça um teste troque o RoundTo5 pelo o RoundTo (do Delphi) quem sabe o problema desaparece. Já corrigi o INI do provedor e vou enviar para o repositório.

Boa tarde Gabriel, Fiz algumas alterações na sua implementação. Já esta disponível, favor atualizar os fontes e realize os testes.

Boa tarde Hugo, Abra o arquivo INI do provedor e compare a estrutura do [ConsNFSeRps] e [ConsNFSe] com a do [RecSincrono]. Tente fazer algo semelhante, na esqueça de alterar as linhas Texto4 e Texto7 deixando-as de forma compatível com o método desejado.

Boa tarde Araujo, Desculpe pela falha. Fiz a correção mas ainda não enviei para o repositório. Tenho algumas pendencias para resolver, espero até o final da tarde de hoje enviar.