Italo Giurizzato Junior

Boa tarde Gabriel, Muito obrigado pela colaboração, já esta disponível.

Boa tarde Fábio, Favor atualizar todos os fontes de todas as pastas (atenção foi feita alteração também no arquivo INI do provedor EGoverneISS). Faça novos testes.

Bom dia Elviro, Só para deixar claro, pois muitos fazem confusão. O que você deseja emitir é o MDF-e Manifesto de Documentos Fiscais Eletrônicos ou emitir a Manifestação do Destinatário?

Bom dia a todos, O documento que temos que nos basear para desenhar o layout do DANFE NFC-e é: Especificações Técnicas do DANFE NFC-e QRCode versão 3.4 de outubro/2015. Nele não existe nada referente a troco ou valor recebido, sendo assim não pode ser impresso no DANFE uma vez que essa informação não existe no XML. Mas vamos para a página 9 item 3.1.9 do referido documento. 3.1.9 Divisão IX – Mensagem de Interesse do Contribuinte Esta divisão corresponde a parte final do DANFE NFCe e corresponde a área em que poderão ser impressas mensagens de interesse do contribuinte que façam parte do arquivo eletrônico da NFC-e no campo informações complementares do contribuinte (tag infCpl). Importante - Caso o contribuinte queira imprimir, no mesmo papel do DANFE NFC-e, mensagens institucionais ou outras informações que não estejam no arquivo XML da NFC-e, as mesmas deverão ser apresentadas logo após o final do DANFE NFCe (imediatamente após a divisão IX de mensagem de interesse do contribuinte). Trocando em miúdos, caso você deseja imprimir o Valor Recebido e o Troco pode ser na divisão IX, mas essas duas informações tem que constar no XML, mais precisamente na tag: infCpl ou após a divisão IX onde podemos imprimir mensagens institucionais ou outras informações que não estejam no XML. No meu entendimento podemos imprimir sim essas duas informações, mas não é em qualquer lugar. Como o troco é informação importante para o consumidor, acredito que ainda este ano tanto o XML quanto o DANFE NFC-e vão sofrer alterações a fim de conter essa informação.

Henrique, Configure o componente para salvar os arquivos Soap. Configuracao.WebServices.Salvar := True; Desta forma os arquivos de envio e de retorno são salvos em disco e desta forma fica mais fácil descobrir o que esta ocorrendo. Pois podemos analisar o XML de envio de forma completa, ou seja, exatamente o arquivo que é recebido pela SEFAZ.

Rogério, O seu problema não é o envio do RPS e sim a consulta. Ao enviar o pedido de consulta que ocorre o erro. O método ConsultarNFSeporRps devemos passar como parâmetro, o Numero, Série e Tipo do RPS, mas ele requer também o CNPJ e a IM do prestador de serviço, ou seja o Emitente da nota. Sendo assim te pergunto: na sua aplicação, mais precisamente na rotina que configura o componente você incluiu as linhas de configuração do Emitente? Vide o programa exemplo.

Luciano, Enviei para o repositório a inclusão da URL de produção da cidade Astorga feita por você e fiz uma correção na seção [GrupoMsgRet]. Se você abrir com o bloco de notas o arquivo 119662-sit.xml vai notar o seguinte: <NumeroLote xmlns="http://www.sistema.com.br/Nfse/arquivos/nfse_3.xsd">32</NumeroLote> <Situacao xmlns="http://www.sistema.com.br/Nfse/arquivos/nfse_3.xsd">2</Situacao> vamos simplificar para ficar mais claro: <NumeroLote>32</NumeroLote> <Situacao>2</Situacao> Esse arquivo que estou me referindo é o retorno a consulta a situação do lote, note que a resposta é 2 para situação, isso significa que o Lote esta em processamento, sendo assim devemos aguardar um tempo e realizar uma nova consulta. Deveremos repetir esse processo até que o retorno da situação seja 3 (Lote Processado com erro) ou 4 (Lote Processado com sucesso). Como você esta usando o programa exemplo do componente, favor configurar o mesmo para ConsultaLoteAposEnvio isso faz com que a Consulta a Situação do Lote seja realizada varias vezes automaticamente. Existe propriedades no componente para que você possa definir a quantidade de Consultas (Tentativas) o tempo entre uma e outra (IntervaloTentativas). Altere essas configurações no programa exemplo e faça novos testes.

Bom dia Valmir, Dentro da pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI temos dezenas de arquivos INI, temos um para cada provedor. Esses arquivos contem informações importantes que são utilizados pelo componente, algumas se refere a auto configuração e outras diz respeito a montagem dos Envelopes antes do envio de alguma solicitação de serviço. Sendo assim, quando digo que devemos atualizar todos os fontes de todas as pastas estou me referindo também aos arquivos INI dos provedores.

Bom dia Rogério, Se ao configurar o componente para ConsultaLoteAposEnvio ao tentar enviar o lote para o provedor Ginfes você tem como retorno um erro, esta claro que você tem um erro no envio e não na impressão do DANFSE. Você chegou a realizar testes com o programa exemplo? Se sim qual foi o resultado? Você disse que antes dessa última atualização (dia 26) tudo funcionava, pois bem antes do dia 26 (acredito ser 26 de abril) quando foi a última atualização?

Bom dia Danny, Desculpe não estamos mais trabalhando com os fontes do Trunk1 somente com os fontes do Trunk2.

Bom dia Fábio. Favor atualizar todos os fontes de todas as pastas. Note que fiz alteração no arquivo INI do provedor. Após a atualização dos fontes compilar a aplicação com a opção Build. E faça novos testes.

Bom dia Isledo, Muito obrigado pela colaboração, ainda hoje estarei disponibilizando.

Bom dia Henrique, Já tentou usar o método Inutilizar? ACBrNFe1.Inutilizar(ACNPJ, AJustificativa: String; AAno, ASerie, ANumInicial, ANumFinal: Integer); Lembrando que o método Inutilizar se utiliza da chamada Inutiliza do WebServices.

Bom dia Luciano, Uma pergunta boba, que disse a você que é necessário alterar as URLs de NameSpace e SoapAction para a cidade em questão? Se essa cidade se utiliza do provedor SimplISS as URLs de NameSpace e SoapAction são as mesmas usas pelas demais cidades atendidas pelo provedor.

Bom dia Luciano, No caso do provedor SimplISS cada cidade que é atendida por esse provedor possui sua URL de Produção, ou seja, a URL de produção da cidade São José do Rio Pardo é diferente da cidade de Balneário de Camboriú. Por outro lado a URL de homologação é a mesma para todas as cidades. Isso fica claro abrindo o arquivo INI do respectivo provedor. [URL_P] RecepcaoLoteRPS=******* ; Iracemapolis RecepcaoLoteRPS_3521408=http://wsiracemapolis.simplissweb.com.br/nfseservice.svc (...) [URL_H] RecepcaoLoteRPS=http://wshomologacao.simplissweb.com.br/nfseservice.svc Quanto ao erro, sem os arquivos XML de envio e de retorno gerados pelo componente não tem como analisarmos o problema. No controle que tenho esse provedor já foi considerado que esta funcionando 100% sendo assim se se trata de uma cidade nota é preciso saber se o provedor fez alguma implementação diferente, pois ele segue a versão 1 do layout da ABRASF sendo assim após o envio do lote devemos consultar a situação do mesmo. E pelo que você descobriu o erro ocorre justamente na consulta a situação do lote. Peço que você anexa os XML de envio e de retorno para analise. Certifique-se que todos os fontes de todas as pastas estão atualizados, isso inclui os arquivos INI.

Bom dia Mauro, Muito obrigado pela colaboração, já esta disponível no repositório.

Boa tarde Alexandre, Os testes que você realizou compreende o envio, consulta e cancelamento? Se sim e se todos funcionaram podemos considerar que esse provedor esta funcionando 100% ?

Luciano, Correto, é preciso incluir a URL de produção, mas a de homologação é a mesma para todos. E você tinha alterado a de homologação. O XML que você anexou é do RPS. Lembre-se que o componente gera e envia o XML do RPS e não o altera. O Provedor valida o RPS recebido, estando tudo correto o converte em NFS-e. O componente ao receber o retorno contendo o XML da NFS-e salva em disco se assim estiver configurado. Você configurou o componente para Consultar o Lote após o envio?

Boa tarde Daniel, Segundo o arquivo que você anexou notei o seguinte: <?xml version="1.0" encoding="UTF-8"?> <ns3:EnviarLoteRpsEnvio xmlns:ns3="http://www.betha.com.br/e-nota-contribuinte-ws"> <LoteRps Id="606052016"> <NumeroLote>606052016</NumeroLote> Esta faltando o prefixo ns3: na Tag LoteRps. O que precisamos saber se ao montar o lote através da unit pnfsNFSeG (linhas 503 até 508) essa TAG realmente esta sendo gerada sem o prefixo ou se o mesmo é removido indevidamente depois. Acredito que a falha esta ai, note: docElement = 'ns3:EnviarLoteRpsEnvio' infElement = 'ns3:LoteRps' O parâmetro infElement passa com o prefixo mas o Lote gerado para ser assinado a respectiva Tag não tem. Se você puder "debugar" o código nesse sentido lhe agradeço.

Boa tarde a todos, Favor atualizar os fontes e realizar novos testes.

Boa tarde Luciano, A alteração que você fez no arquivo INI do provedor esta errada. Pois a URL de homologação é igual para todas as cidades. Favor utilizar os arquivos INI que estão no repositório. Atualize todos os fontes de todas as pastas, pois acrescentei a cidade desejada.

Boa tarde Dorneles, Não necessariamente, apenas temos a certeza que a URL esta correta.

Boa tarde Lucas, Pode sim o problema de formatação, pois no componente é informado somente os dígitos e no provedor o CNPJ pode estar formatado. Volto a frisar no que diz respeito ao login, se via site ao realizar o login é solicitado o CNPJ do emitente, acredito que via Web Services ao informar o login este deve estar pegando o primeiro CNPJ da filial em vez da matriz dai o erro. É por isso que sugeri login diferente para cada uma.

Fábio, Cuidado ao usar o ADD pois este cria um item na lista de notas. Em vez de ChaveAcesso use Senha. with ACBr.NotasFiscais.Add.NFSe do begin (...) Prestador.Senha := 'c1250o70-6462-431b-b458-2oo563730087'; (...) end; ***************************** Em tempo, favor atualizar os fontes e deixar a propriedade ChaveAcesso e vez de Senha como mencionado acima.

Boa tarde, O erro ocorre ao assinar o XML do RPS ou o XML do Lote? Uma vez que o provedor Betha exige que ambos sejam assinados.