Italo Giurizzato Junior

Boa tarde Diogo, Em uma primeira analise não encontrei nenhum carácter que poderia estar provocando o problema. Você já tentou um contato com o provedor?

Boa tarde Joel, Muito obrigado pela colaboração, já esta disponível. Desculpa, não percebi que o arquivo em anexo estava logo na primeira linha da postagem.

Boa tarde Emerson, Muito obrigado pela informação, favor atualizar os fontes e testar novamente.

Boa tarde Wislei, Após realizar a consulta, tente ler a chave desta forma: chave := ACBrMDFe1.WebServices.ConsMDFeNaoEnc.InfMDFe.Items[x].chMDFe; coloque a linha acima dentro de um loop, onde x é o índice iniciando de zero.

Bom dia Gleidson, Em vez do DPEC já pensou em utilizar o EPEC ou SVC?

Bom dia a todos, Sérgio, se você é o destinatário da mercadoria, ao realizar uma consulta através do NFeDistribuicaoDFe não terá nenhuma informação acusando se uma nota foi manifestada ou não. A principio ao realizar a consulta é retornado um resumo da NF-e se você efetuar a manifestação dessa nota, por exemplo: Confirmação da Operação ao realizar novas consultas será retornado o XML completo da nota manifestada. Se a nota foi manifestada através do aplicativo da receita, agora você vai ter que colocar essa informação manualmente no banco de dados. Por outro lado, se quem esta realizando a consulta é o emitente da NF-e este sim, vai receber um resumo do evento de Confirmação da Operação, ou seja, a sua manifestação. Neste caso o emitente poderá se utilizar desse retorno para atualizar o seu banco de dados, desta forma, dando baixa da entrega da mercadoria. Resumindo, a Manifestação do Destinatário nada mais é do que a assinatura no canhoto de entrega da mercadoria, ou seja, temos agora o canhoto de entrega eletrônico.

Bom dia Wislei, Você chegou a estudar a unit pmdfeRetConsMDFeNaoEnc.pas ? Note que ao ler o retorno é montado uma lista chamada infMDFe. Essa lista possui duas propriedades: chMDFe e nProt que contem respectivamente a chave e o numero do protocolo do MDF-e não encerrado. Se esta lista não possuir nenhum elemento significa que todos os MDF-e emitidos estão encerrados.

Bom dia ncc, Vou analisar e assim que possível disponibilizar.

Boa tarde Diogo, Se possível post como anexo o XML de envio e que resulta na rejeição.

Boa tarde Joel, Por favor quanto postar correções em código fonte do componente, anexe a Unit alterada para que possamos realizar o merge. Não post as linhas alteradas como parte da postagem.

Caetano, Debugando você consegue descobrir qual é esse "método" que não existe?

Bom dia jGuto, Muito obrigado pela colaboração, assim que possível estarei disponibilizando.

Bom dia Diogo, No caso da NFS-e não existe uma padronização, infelizmente cada provedor faz do jeito que quer. A principio temos no caso do envio de um lote de RPS, métodos Enviar e EnviarSincrono: O lote é composto por 1 ou até 50 RPS, dependendo do provedor cada RPS deverá ser assinado ou não e o Lote também deverá ser assinado ou não. Por outro lado temos o método Gerar, esse método tem a finalidade de enviar somente 1 RPS, neste caso o RPS não é assinado somente o Lote e dependendo do provedor nem é assinado. A propriedade AssinaGerar faz com que o RPS não seja assinado quando enviado pelo método Gerar, mas o provedor requer que o mesmo seja assinado quando é enviado através dos métodos Enviar e ou EnviarSincrono. Não sei se ficou claro. Resumindo dependendo do método de envio o RPS deve ser assinado ou não.

Bom dia Caetano, O erro ocorre na compilação? Se sim, você deve estar com algum fonte desatualizado.

Bom dia, Acessando o Portal Nacional do MDF-e notei que todos os serviços tanto de homologação quanto de produção estão parados: https://mdfe-portal.sefaz.rs.gov.br/Site/Servicos Agora não sei se o site esta apresentando a real situação dos Web Services.

E checando o Portal Nacional da NF-e (Homologação) esta tudo OK com o Estado de Goiás.

Walter, Faça a seguinte alteração na unit pnfsNFSeW.pas linha 444: proGINFES: Gerador.wCampoNFSe(tcDe4, '#25', 'Aliquota', 01, 05, 0, (NFSe.Servico.Valores.Aliquota / 100), ''); para proGINFES: Gerador.wCampoNFSe(tcDe4, '#25', 'Aliquota', 01, 05, 0, (NFSe.Servico.Valores.Aliquota * 0.01), ''); Fico no aguardo de um retorno.

Boa tarde Adonias, Muito obrigado pela colaboração, assim que possível estarei disponibilizando.

Boa tarde Adriano, Não entendi a primeira alteração na uni pnfsNFSeW. Você apenas comentou a linha?

Se não tem pode ter ocorrido algum erro que o componente não foi capaz de interpretar. Verifique se o ACBrNFeMonitor possui alguma configuração para salvar arquivos SOAP. Se sim habilita e depois realiza o teste novamente.

Boa tarde Roger, O XML que você postou é o retorno do Web Services assim que você envia o Lote não tem nada haver com a alteração que você estava sugerindo que se refere a consulta a situação do lote. E a unit que faz a leitura do retorno logo após o envio consegue ler o conteúdo do XML que você postou sem nenhum problema.

Boa tarde jGuto, Muito obrigado pela colaboração, assim que possível estarei disponibilizando.

Boa tarde, E o retorno do pedido de evento ( *-eve.xml ) ?

Boa tarde a todos, Quando ocorre a rejeição: assinatura não confere, significa que o XML foi alterado após ter sido assinado. Alguns provedores resolveram colocar o identificador todo em minusculo, ou seja, "id" onde a grande maioria usa "Id" (a letra i em maiúsculo). Se deixar tudo em minusculo ocorre erro ao tentar assinar, se colocar o i em maiúsculo a assinatura ocorre mas depois o lote não é validado pois o schema não reconhece o atributo. O que fazer então? Não assinar? Se não assinar o Web Services rejeita acusando a falta da assinatura. Se assinar com o identificador alterado e depois alterar para "id" pode ocorrer rejeição: assinatura não confere. Criar uma DLL em C que seja capaz de assinar sem alterar o identificador?

Boa tarde Caetano, Favor atualizar os fontes e testar novamente.