marciost

Bom dia. Estou com problemas para cancelar nota (testando em homologação. Diz que o código de cancelamento é inválido. Tentei mandar com 1, 2 e 3. Sempre mesma coisa. Alguém ai já conseguiu fazer o cancelamento nessa cidade?

Mas esse certificado não tem instalador, pelo menos não que eu saiba, é só colocar a leitora e o cartão que aparece na lista de certificados.

Bom dia. Homologando NFS-e de um cliente da cidade de Novo Hamburgo - Prevedor IssNet. O meu problema é com a senha do certificado, apesar de eu passar a senha para as configurações do Acbr ao solicitar pela primeira vez o certificado aparece a tela pedindo senha. Isso somente ocorre com o certificado A3, nos certificados A1 fica ok, pega a senha configurada. Isso é um comportamente padrão ou tem algo que preciso ajustar?

Estramo mesmo, é como se fosse a exclusão da nota ao invés de cancelamento. Mas esse empresa Nota Control tem mesmo algumas peculiariedades.

Resposta da empresa Nota Control: "As notas que são emitidas por integração, ao serem canceladas, o RPS utilizado volta a ficar disponível. Neste caso, a nota foi emitida utilizando o RPS 14, porem ao ser cancelada, o RPS 14 voltou a ficar disponível. Portanto, a consulta da nota pelo RPS não trará o resultado desejado (a nota cancelada)."

Quando implementei ainda não estava disponível no Acbr, então fiz tudo manual (geração das classes a partir dos Xsd, geração da classe do webservice a partir do Wsdl...). Porém quero usar ainda o Acbr para isso, a princípio está funcionando, já consegui testar algumas consultas, só falta o envio.

Datilas, o problema é com arquivo fora de estrutura ou aquela mensagem de que o município de prestacao de servico informado no XML diferente da URL do webservice? Arquivo fora de estrutura: tive problema com isso enquando não estava mandando o código do município (999 no caso de homologação), e também estava tendo erro de arquivo fora de estrutura naquela rotina de consulta a Nfse-e por Rps. Esse segundo erro acontecia porque eu não estava passando o número do Rps por estar usando direto aquele método de cancelamento que recebe todos os parametros, resolvi isso passando a carregar uma NFS-e e a chamar o cancelamento que recebe somente o código do motivo. Assim está meu código: FNFSe.NotasFiscais.Add; FNFSe.NotasFiscais.Items[0].NFSe.Numero := aEnvio.NumeroNfse; FNFSe.NotasFiscais.Items[0].NFSe.IdentificacaoRps.Numero := aEnvio.NumeroRps; FNFSe.NotasFiscais.Items[0].NFSe.IdentificacaoRps.Serie := aEnvio.Serie; FNFSe.NotasFiscais.Items[0].NFSe.IdentificacaoRps.Tipo := trRPS; FNFSe.NotasFiscais.Items[0].NFSe.PrestadorServico.IdentificacaoPrestador.Cnpj := aEnvio.Cnpj; FNFSe.NotasFiscais.Items[0].NFSe.PrestadorServico.IdentificacaoPrestador.InscricaoMunicipal := aEnvio.InscricaoMunicipal; FNFSe.NotasFiscais.Items[0].NFSe.PrestadorServico.Endereco.CodigoMunicipio := '999'; try FNFSe.WebServices.CancelaNFSe('2'); except if FNFSe.WebServices.CancNfse.Msg <> '' then raise Exception.Create(FNFSe.WebServices.CancNfse.Msg); end; Outra coisa, está informando o município 999 no cancelamento?

Um opção que testei agora foi adaptar a leitura do Xml de retorno ao Ginfes. Vou deixar o fonte aqui caso a equipe do Acbr tenha interesse em publicar isso. pnfsCancNfseResposta.pas pnfsCancNfseResposta.pas

Também estou com o mesmo problema, município de Pelotas/RS. Uma das coisas que percebi, é que a rotina de lê o retorno parece estar esperando outra estrutura. A data até que está no lugar certo, mas o Prefixo3 deveria ter 'n2':... Alguém já resolveu?

Entendi, vou verificar. Obrigado.

Na empresa onde trabalho já implementamos para dois clientes. Tem alguma dúvida? É basicamente passar os dados pro componente que ele faz o resto.

Só tenho uma dúvida: - componente executou a rotina de cancelamento, ficou ok. - após o cancelamento, a rotina faz uma consulta ao Rps, webservice retorna o seguinte: 'RPS nao encontrado ou nao processado na base de dados.'. Creio que essa mensagem ocorra porque a nota foi cancelada, ou seja já não existe mais para consulta, é isso? - como a consulta ao Rps retorna mensagens, a rotina levanta uma exception, fazendo com que o Result := True do final não seja executado. - no meu sistema uso o cancelamento da seguinte forma: if FNFSe.WebServices.CancelaNFSe('2') then... e trato o cancelamento na minha base de dados. Só que por causa dessa consulta ao Rps a function está sempre retornando False. Estou usando a rotina de cancelamento do componente de forma correta?

Testei e ficou ok o cancelamento.

Italo, boa tarde. Testei, mas ainda não rolou. Seguem arquivos de envio e retorno. -can.xml -ped-can.xml

Ainda estou com o problema. Por enquanto vamos cancelar direto pelo portal... já que são raras as necessidades de cancelar notas.

Boa tarde BluData. Báh, nem vi que o provedor ISSNet estava dentro do not in... foi incluído depois de minha alteração, dai fiz update e o svn fez merge nessa parte. Mas era ali que data esse erro pra mim.

Bom dia BluData. Sim, estou conseguindo. Mas eu estava com esse mesmo problema que você colocou. Resolvi isso comentando a parte da procedure TWebServicesBase.OnBeforePost que estava dando o erro, é essa parte: if not (FProvedor in [proGovBr, proSimplISS, proAbaco, proISSNet]) then begin if not InternetSetOption(Data, INTERNET_OPTION_CLIENT_CERT_CONTEXT, PCertContext, Sizeof(CERT_CONTEXT)*5) then begin // if Assigned(TACBrNFSe( FACBrNFSe ).OnGerarLog) // then TACBrNFSe( FACBrNFSe ).OnGerarLog('ERRO: Erro OnBeforePost: ' + IntToStr(GetLastError)); // raise Exception.Create( 'Erro OnBeforePost: ' + GetLastErrorText {IntToStr(GetLastError)} ); end; end; É uma gambiarra, mas faze o que né? Sim, estou usando certificado. Italo, questionei isso não por causa de performance da execução, é mais para saber. Estranhei ter duas configurações possíveis para a mesma validação, sendo que a que é específica do provedor e na minha opinião a que deveria ser usada não é usada.

Por dentra da unit das notas fiscais não temos acesso ao provedor, mas acho que poderia ser validado antes de chamar o método de assinar lote. Exemplo: Unit: ACBrNFSeWebServices.pas Método: TWebServicesBase.DoNFSeEnviarLoteRPS Linha: 576. Como está hoje: FDadosMsg := TNFSeEnviarLoteRPS(Self).FNotasFiscais.AssinarLoteRps(TNFSeEnviarLoteRps(Self).NumeroLote, FDadosMSg); Minha sugestão: if FProvedorClass.GetAssinarXML(acRecepcionar) then FDadosMsg := TNFSeEnviarLoteRPS(Self).FNotasFiscais.AssinarLoteRps(TNFSeEnviarLoteRps(Self).NumeroLote, FDadosMSg);

Bom dia. Percebi que ao enviar lote o componente verifica a necessidade de assinar lote em FConfiguracoes.Certificados.AssinaLote, porém no provedor, no método TProvedorISSNet..GetAssinarXML todas as ações estão marcadas para false. Alguém sabe dizer porque não está sendo verificada a necessidade de assinar o Xml através do método GetAssinarXML do provedor?

Bom dia. Falta incluir ao município de Novo Hamburgo/RS na lista de cidades e provedores.

Engano no título. O provedor é IssNet

Boa tarde. Alguém já tentou cancelar uma NFS-e desse provedor? Apesar de estar validando o xml com o xsd, ainda assim o servidor me devolve esse erro.

Pior que esses arquivos de configuração de cidades, schemas e url's nem são mais usados pelo que vi, confirmam isso?

Bom dia. Fiz update hoje para pegar as alterações no provedor IssNet. As alterações ficaram ok, porém agora fiquei com dúvida sobre como estão utilizando o componente: - na implementação da unit dos provedores, há o método GetConfigCidade. Nesse método é setado o ConfigCidade.CodigoURLs. Só que no meu caso, que uso o provedor Ginfes e o IssNet, vai dar conflito de informações, pois no Ginfes CodigoURLs para as demais cidades é 1, assim como no IssNet tem CodigoURL igual a 1 para Mogi das Cruzes. Como uso IssNet para Novo Hamburgo, ainda não é problema para mim, mas se fosse Mogi das Cruzes, como evitaria de dar o conflito? Pois no arquivo Config_URL.ini teria 2 indices 1. Entenderam? Como estão solucionando isso, usando 2 arquivos?

Bom dia. Ok, vou testar e qualquer coisa posto aqui. Obrigado.