Italo Giurizzato Junior

Boa tarde Silvio, Você esta usando o componente ACBrNFSe? Lhe pergunto isso, pois até o momento o componente não atende a cidade de Guarapuava.

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

Boa tarde Marcos, Você não configurou as propriedades do Emitente. Vide o programa exemplo.

Bom dia Wilson, Faça uma cópia da sua implementação e atualize os fontes fiz uma alteração agora pouco visando resolver esse problema. Caso detecte mais algum problema favor altera-la com base no que foi enviado agora para o repositório.

Joel, Favor atualizar os fontes e testar novamente.

Felipe, Esta difícil interpretar corretamente essa mensagem de erro. Em um primeiro momento podemos concluir que esta sendo feita uma referencia a um objeto que não existe, se é isso, então qual é esse objeto? Como lhe disse não encontrei nada de errado na grafia das TAGs bem como a sua ordem. Como a mensagem de erro não é clara sugiro que entre em contato com o pessoal da Tecnos quem sabe eles dizem o que esta errado.

Bom dia, Esse problema esta ocorrendo somente com essa nota ou com todas? Se no XML os valores estão aparecendo zerados é porque eles não foram informados, ou seja, o componente não esta sendo alimentado de forma correta.

Eu tive um professor que dizia: quanto mais você escreve, mas você erra. Em uma aplicação quanto mais informações o usuário tem que digitar mais ele vai errar. É por isso que eu procuro nas minhas aplicações parametrizar o máximo possível, ou seja, colocar em tabelas de configuração no banco de dados. No caso da alíquota, se o usuário tem que digitar toda vez que for emitir uma nota, com certeza uma hora ele vai errar. Por outro lado se essa informação esta parametrizada, ela não precisa ser digitada evitando assim o erro. O que você esquece é que o seu problema é pontual, onde a sua aplicação vai usar somente esse provedor ou mais algum outro. Eu por outro lado estou escrevendo um componente que tem que satisfazer mais de 50 provedores. Como lhe disse dos 58 provedores (para ser exato até o momento) somente o Governa exige mais essas duas informações na consulta. Se eu for começar a colocar essas diferenças como parâmetros nos métodos vai chegar uma hora que vamos ter dezenas de parâmetros. O componente ainda não esta 100% para todos os provedores e com a migração para o Trunk2 estou analisando todos os fontes para tentar reduzir o máximo possível de IF Provedor. Quero um código o mais limpo possível.

Felipe, Comparando o XML enviado com o schema e mais o WSDL do web service conclui: 1. não encontrei nenhum nome de TAG ou Grupo diferente do que esta estabelecido, inclusive aparecem na ordem definida. 2. no WSDL existe o grupo <cabecalho> tanto no método do envio quando da consulta, mas eles não são gerados pelo componente e esse grupo no WSDL consta como opcional. 3. achei estranho o web service retornar após o envio o numero de protocolo contendo 23 dígitos, sendo que no schema ConsultarLoteRpsEnvio.XSD que contem a estrutura do XML para realizar a consulta ao lote consta que a TAG Protocolo é do tipo Integer. E o que esta sendo informado é exatamente o retorno do envio, ou seja, o protocolo com 23 dígitos que com certeza poderia ocorrer erro no Web Service. No seu envio, foi informado o numero de lote = 88, pelo que notei o numero do protocolo nada mais é do que o CNPJ + numero do lote formatado com 9 dígitos totalizando os 23 dígitos. Tente consultar novamente mas passando os seguintes valores: ====> sintaxe: function ConsultarLoteRps(ANumLote, AProtocolo: string): Boolean; OK := ACBrNFSe.ConsultarLoteRps('88', '88');

Bom dia Dercide, Favor atualizar novamente todos os fontes e realize novos testes.

Bom dia a todos, Graça, não, essa mensagem de erro é do componente e não um retorno do Web Services ou uma tentativa de conexão com ele. Quando comecei a migrar a minha aplicação para usar os componentes do Trunk2 passei por uma situação desse tipo. O problema era a versão errada definida na propriedade VersaoDF. Hoje tenho os componentes ACBrNFe, ACBrNFeDANFE e ACBrMail bem como a rotina de configuração deles em um Data Module, desta forma eu tenho a garantia que feita a configuração ela será valida para tudo o que preciso.

Bom dia Wilson, O provedor Ginfes foi o primeiro provedor migrado junto com componente para o Trunk2. Consegui um certificado e realizei todos os testes, todas as funcionalidades disponibilizadas pelo Ginfes estão funcionando 100% no ambiente de homologação. Não realizo nenhum teste em ambiente de produção.

Bom dia Dercide, Esse erro ocorreu ao utilizar o método EnviarSincrono? Se sim, por favor abra o INI do provedor e altere o valor do campo RecSincrono de zero para 1 na seção [Assinar], realize um novo teste. Se funcionar me avise para que eu possa fazer a alteração e enviar para o repositório.

Bom dia Wislei, Segundo a Nota Técnica 2013/004 versão 1.00a de Outubro/2013 - página 48 diz que o grupo <procEventoMDFe> poderá existir ou não ao Consultar a Situação Atual de um MDF-e. Logo o componente esta agindo conforme a NT. Como esse grupo pode ter várias ocorrências nesse retorno temos então uma lista, se a quantidade de elementos dessa lista for zero significa que não existem eventos, caso contrario existe, sendo assim: qEventos := ACBrMDFe.WebServices.Consulta.procEventoMDFe.Count; if qEventos > 0 then for x := 0 to qEventos -1 do begin TipoEvento := ACBrMDFe.WebServices.Consulta.procEventoMDFe.Items[ x ].RetEventoMDFe.InfEvento.tpEvento; (...) end;

Bom dia Felipe, Essa mensagem de erro é retornada pelo provedor? Se sim, por favor anexo os XMLs de consulta e retorno. Quando estamos realizando testes é sempre bom deixar o componente configurado para gerar os arquivos soap, esses arquivos ajudam muito na detecção de erros. Configuracoes.WebServices.Salvar := True;

Bom dia Joel, Anexe o XML de uma NFS-e cancelada para que eu possa analisar.

Bom dia Tiago, Ontem a noite tive um compromisso, não deu para realizar nenhuma analise nos fontes. Já enviei para o repositório uma possível correção. Favor atualizar os fontes e realizar novos testes.

Bom dia, Todos os provedores exige que seja informado o numero, serie e tipo do RPS para realizar a consulta, mas o provedor Governa exige mais essas duas informações. Eu não vou alterar a assinatura de um procedimento ou função acrescentando novos parâmetros só por causa de um provedor. Sendo assim a solução adotada é carregar o XML do RPS antes de realziar a consulta.

Qual é o comando que você esta executando que ocorre esse erro?

Se você utiliza o método ConsultarNFSeporRps é levantada uma exceção caso não tenha sido carregado o RPS. Agora se você utiliza as chamadas diretas do Web Service do componente não é feita essa verificação dai o erro. Note que no XML do RPS existe essas duas informações nas TAGs: ChvAcs e CodVer

Souza, Todos os fontes de todas as pastas estão atualizados? Não tem nenhum fonte da pasta ACBrDFe e ou ACBrNFSe que contem no seu ícone uma bolinha vermelha?

Boa tarde, O certificado possui um CNPJ e este consta na base de dados do provedor?

Boa tarde a todos, Marcelo, você esta alimentando as propriedades de configuração referente ao Emitente? Vide programa exemplo.

Boa tarde, Uma pergunta, a ChaveAcessoPrefeitura e CodVerificacaoRPS é opcional para esta consulta?

Boa tarde, Essa mensagem não tem nada haver com o gerar o DANFSE da NFS-e e sim gerar o XML do RPS. Qual é a cidade e o provedor?