Italo Giurizzato Junior

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?

Boa tarde Paulo, Já que ainda não esta pronto a impressão do Inutilizar através do Fast ou do Fortes Report e você não pode de forma alguma ficar sem essa impressão, vai ai uma sugestão, uma vez que ninguém da equipe ACBr vai realizar alguma alteração nos fontes do Rave ou Quick Report. Comente as linhas que por ventura aparecem a propriedade LocalImpCanhoto nesse fonte.

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?

Souza, Abra este link: https://iss.fortaleza.ce.gov.br/grpfor-iss/ServiceGinfesImplService?wsdl Note que os soapAction das operações é vazio. No arquivo INI colocamos um " * " para que o componente entenda que foi definido um soapAction para operação, se deixarmos em branco ele levanta uma exceção.

Boa tarde Leonardo, Muito obrigado pelas informações, já foram feitas as alterações, favor atualizar todos os fontes de todas as pastas e realize os testes.

Boa tarde Souza, Você fez alterações no arquivo INI que você anexou? Esse INI é o mesmo que esta disponível junto com o programa exemplo? Não seção [SoapAction] não tem os endereços pelo simples fato da cidade de Fortaleza se utilizar do provedor Ginfes, mas por um certo capricho da prefeitura realizou algumas alterações nos layout dos envelope e no NameSpace. Você configurou o componente para que ele realiza a consulta logo após o envio?

Boa tarde Tiago, Desculpe pela demora, estava realizando alterações e testes. Por favor atualize os fontes e realize novos testes. Fiz alterações no INI do provedor.

Tiago, Pelo que eu vi o erro esta ocorrendo na validação do lote, o RPS tem que esta sendo gerado. A mensagem de erro não mudou continua a mesma?

Tiago, Pelo que eu vi o erro esta ocorrendo na validação do lote, o RPS tem que esta sendo gerado. A mensagem de erro não mudou continua a mesma?

Bom dia Leonardo, No caso do provedor Pronim precisamos das URLs de homologação e produção da respectiva cidade.