Italo Giurizzato Junior

Boa tarde Francesco, Uma coisa é a tag <InformacoesComplementares> constar no XML do Rps que foi enviado para o provedor. Outra coisa é o XML da NFS-e gerado pelo provedor. Primeiro você precisa verificar se a tag consta no XML do Rps com o texto que foi informado. Se a tag consta e o XML foi enviado e o Rps foi processado com sucesso, o passo seguinte é verificar o XML da NFS-e se este contem a tag. Outra coisa importante é, o provedor ISSNet tem 2 webservice, um segue a versão 1 do layout da ABRASF, nesta versão não existe essa tag. O outro webservice segue a versão 2.04 do layout da ABRASF e nesta versão existe a tag no layout. Como você não informou a cidade, eu não sei qual dos 2 webservice essa cidade utiliza.

Boa tarde Massao, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3536

Boa tarde Leandro, Esse pessoal gosta de ferrar o desenvolvedor. Colocam um código no meio de uma mensagem em vez de informa-lo em uma tag. Como o componente vai extrair o código dessa mensagem? Vai pegar os 10 últimos caracteres da mensagem e depois remover tudo que não seja digito? Só se for assim e rezar para que eles não mudem a mensagem e coloquem o código em outra posição.

Boa tarde, Existem 3 maneiras do MEI emitir as suas notas: 1. via Web 2. via App (celular) 3. via API (aplicação de terceiros) Eu li uma reportagem que um MEI emitiu uma nota mesmo a cidade dele ainda não ter assinado a adesão ao padrão nacional. Mas pelo que me recordo não consta nessa reportagem qual foi a forma utilizada para emissão. Eu acredito que foi via Web.

Bom dia, O que esta ocorrendo é o seguinte: A data de emissão da nota esta no formato AAAA-MM-DD que é o que consta no manual da ABRASF. Já a data de emissão do RPS e a data de competência esta DD/MM/AAAA. A pergunta que não quer calar. É muito complicado o provedor gerar todas as datas do XML com a mesma formatação? Você consultou essa nota pelo método ConsultarNFSeporFaixa, faça um favor consulte novamente a mesma nota pelo método ConsultarLote e ConsultarNFSeporRps. Preciso saber se o XML gerado por esses 3 métodos de consultas estão gerando o XML exatamente igual. Pois tem um provedor que dependendo do método usado gera o XML com formatação das datas de forma diferente.

Bom dia Rogerio, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3534

Bom dia Rogerio, O problema é que a procedure TratarRetornoCancelaNFSe responsável por ler as informações do XML retornado ao cancelar uma nota esta incompleta. Porque ela esta incompleta? Simples, não tínhamos um XML (soap) de retorno de uma cancelamento para que fosse possível implementar essa procedure como ela tem que ser. Por favor anexe o XML (soap) retornado ao cancelar uma nota para que possamos finalizar a implementação dessa procedure. Desde já muito obrigado pela colaboração e compreensão.

Boa tarde Luis, Noto que você ainda esta usando o componente antigo. Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não está mais tendo manutenção. Faça os testes usando o programa exemplo do novo componente. Manual de Migração https://www.projetoacbr.com.br/forum/topic/63017-manual-de-migração-para-o-novo-componente-de-emissão-de-nfs-e/

Boa tarde Igor, Todas essas informações constam no XML da nota? Você chegou a alterar o componente?

Boa tarde a todos, A Consulta pelo numero do protocolo para atender a API Rest que é utilizada pela versão 2.1.1 já esta pronta. O componente ACBrReinf já esta realizando essa consulta e a API esta retornado o resultado do processamento. O próximo passo agora é adequar a leitura dos retornos, tanto do envio quanto da consulta, pois os retornos da API Rest não são envelopados e algumas tag estão com nomes diferentes do retorno gerado pelo WebService. Assim que essas adequações forem realizadas e testada, retornarei aqui para avisa-los. Atenção: As alterações que fiz ainda não foram para o SVN.

Bom dia João, Já esta no SVN.

Vagner, Você tem certeza que com essa alteração que você fez no arquivo ACBrNFSeXServicos.ini funcionou? Pois ao comentar a linha que contem o campo Versao diz ao componente que a versão é 1.00 sendo que ele é da versão 2.04 Outra coisa, segundo o SoapUI temos: Produção: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:prod="https://nfse.setelagoas.mg.gov.br/webservice/index/producao"> <soapenv:Header/> <soapenv:Body> <prod:RecepcionarLoteRps> <xml>?</xml> </prod:RecepcionarLoteRps> </soapenv:Body> </soapenv:Envelope> Homologação: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:prod="http://homolog.libresolucoes.com.br:8010/webservice/index/producao"> <soapenv:Header/> <soapenv:Body> <prod:RecepcionarLoteRps> <xml>?</xml> </prod:RecepcionarLoteRps> </soapenv:Body> </soapenv:Envelope> Observe o segundo atributo xmlns da tag Envelope, não tem nada haver com "http://www.abrasf.org.br/ABRASF/arquivos/nfse.xsd" Após alterar o arquivo INI, você recompilou ele para gerar um novo RES, depois reinstalou o ACBr e por fim compilou a aplicação com a opção Build? Se não executou essa sequencia, a alteração que você fez no arquivo INI não surtiu nenhum efeito.

Bom dia, Verifica se configurou corretamente a pasta Schemas, segundo a orientação do tópico abaixo. Como configurar corretamente a pasta de schemas - NFS-e - Projeto ACBr

Bom dia Vagner, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3529

Bom dia Danny, Muito obrigado pela colaboração, já esta no SVN.

Bom dia Gustavo, Se o XML baixado da nota após o seu cancelamento não possui o grupo <NfseCancelamento> ou a tag Status com o valor que indica cancelamento, o componente não tem como saber por esse XML que a nota esta cancelada.

Bom dia Leandro, Já esta no SVN.

Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3525

Boa tarde a todos, Realizei alterações no componente ACBrReinf visando o envio dos eventos da versão 2.01.01 para a API Rest. O envio foi realizado com sucesso e a API retornou o XML de retorno. Como essa API trabalha no modo Assíncrono após o envio não temos o resultado do processamento e sim apenas o numero do protocolo. De posse do numero do protocolo será necessário realizar uma consulta para que enfim possamos ter o resultado do processamento do(s) evento(s) enviado(s). O próximo passo agora é implementar no componente essa consulta. Assim que ela for implementada e testada, retornarei aqui para avisa-los. Atenção: As alterações que fiz ainda não foram para o SVN.

Boa tarde, O componente esta gerando com valores diferentes ou você informou desta forma?

Boa tarde Gustavo, Essa consulta retorna o XML da nota, correto? Quando a nota é cancelada via webservice o XML retornado pela consulta consta a data de cancelado, já se a nota foi cancelada via site, o XML não tem essa informação, correto? Se a resposta for sim para as 2 perguntas, você poderia anexar o XML retornado para que possamos analisar?

Boa tarde, Veja esse fragmento de código do programa exemplo: // TnfseSituacaoTributaria = ( stRetencao, stNormal, stSubstituicao ); // stRetencao = snSim // stNormal = snNao // Neste exemplo não temos ISS Retido ( stNormal = Não ) // Logo o valor do ISS Retido é igual a zero. Servico.Valores.IssRetido := stNormal; Servico.Valores.ValorIssRetido := 0.00;

Boa tarde, Quais são os valores de: SSLLib, CryptLib, HttpLib, XmlSignLib e SLLType ?

Boa tarde Talita, A cidade de Iturama/MG consta sim no arquivo ACBrNFSeX e o seu provedor é Governa. Se não esta aparecendo ela no combobox, selecione uma outra qualquer, salve a configuração, encerre a execução do programa exemplo, execute ele novamente, que vai aparecer a cidade desejada.

Boa tarde, A configuração padrão para a tag InformacoesComplementares é: FNrOcorrInformacoesComplemetares := -1; (vide a unit ACBrNFSeXGravarXml_ABRASFv2) Isso significa que a tag não deve ser gerada independente se ela foi alimentada ou não com alguma mensagem. A unit SigCorp.GravarXml temos a configuração para a versão 2.03 e 2.04 Para a versão 2.03 não existe a linha alterando o valor de NrOcorrInformacoesComplemetares, portanto para esta versão a tag não vai ser gerada. Por outro lado, para a versão 2.04 temos a linha: NrOcorrInformacoesComplemetares := 0; Isso faz com que a tag seja gerada caso ela tenha algum conteúdo, caso não tenha não vai ser gerado. Resumindo: Numero de Ocorrência = -1 a tag nunca vai ser gerada. Numero de Ocorrência = 0 a tag é opcional, só é gerada se tiver algum conteúdo. Numero de Ocorrência = 1 a tag é obrigatória, sempre vai ser gerada.