Italo Giurizzato Junior

Boa tarde @colmanetti, Pela mensagem de erro me leva a crer que no segundo IF ele gerando o Endereço do Tomador em vez do Endereço Exterior do Tomador. if GerarEnderecoExterior and (NFSe.Tomador.Endereco.UF = 'EX') then Result.AppendChild(GerarEnderecoExteriorTomador) else Result.AppendChild(GerarEnderecoTomador); Note que existem duas condições a primeira GerarEnderecoExterior tem que ter o valor True e a segunda condição também tem que ser True para ele gerar o Endereço Exterior. Nessa mesma unit na function GerarXml temos o seguinte: case VersaoNFSe of ve203: begin FGerarTagNifTomador := True; NrOcorrCodigoMunicInterm := 1; end; ve204: begin FGerarTagNifTomador := True; FGerarEnderecoExterior := True; NrOcorrCodigoMunicInterm := 1; end; else begin FGerarTagNifTomador := False; FGerarEnderecoExterior := False; NrOcorrCodigoMunicInterm := -1; end; end; Note que o GerarEnderecoExterior só vai ser True se a versão for 2.04 No arquivo ACBrNFSeXServicos.ini que se encontra no SVN esta desta forma: [3551702] ; Atualizado em 29/05/2024 Nome=Sertaozinho UF=SP Provedor=SmarAPD Versao=2.04 Params=SubVersao:1 ProRecepcionar=https://pmsertaozinho.smarapd.com.br/tb/services/Abrasf24 ProLinkURL=https://pmsertaozinho.smarapd.com.br/tb/loginWeb.jsp?execobj=NFENotaFiscalBuscarDireto&cnpj=%Cnpj%&numero=%NumeroNFSe%&chave=%ChaveAcesso% HomLinkURL=https://pmsertaozinho.smarapd.com.br/tb/loginWeb.jsp?execobj=NFENotaFiscalBuscarDireto&cnpj=%Cnpj%&numero=%NumeroNFSe%&chave=%ChaveAcesso% Portanto era para gerar o Endereço Exterior Tomador. Como isso não esta ocorrendo sugiro você checar se todos os fontes estão atualizados e o ACBr foi reinstalado e a aplicação foi compilada. Verifique também se não existe uma copia desatualizada do arquivo ACBrNFSeXServicos.ini dentro da pasta do EXE, caso afirmativo delete a cópia.

Boa tarde @Vitor Domingos, Pode ser que sim.

Boa tarde @brajan, O WebService do provedor EL usado pela cidade de Barra de Sao Francisco/ES possui os seguintes serviços de consulta: Consultar Situação do Lote, Consultar o Lote, Consultar NFS-e por RPS e Consultar NFSe. Os dois primeiros se utilizam do numero do protocolo retornado ao enviar o lote de RPS para o webservice. O terceiro devemos informar o numero do RPS, já o ultimo devemos informar o numero da nota. Pela mensagem de erro nessa sua ultima postagem, me leva a crer que você usou o Consultar NFS-e e informou o numero do RPS. Se foi isso, você deve Consultar a NFS-e por RPS e como dito acima informar o numero do RPS.

Boa tarde @angelosobreira, Tem provedor que exige um cadastro especifico para emissão de notas via webservice. Verifique se não é o caso.

Boa tarde @dna.automacao, Notei que o XML no componente antigo esta com uma estrutura diferente do novo. O componente antigo não esta validando o XML gerado por conta dessa divergência. Vou mudar a geração do XML e fazer um teste.

Bom dia @Fabio Fredianelli, No manual da versão 1 do layout da ABRASF não existe nada refere a quebra de linha. Já no manual da versão 2.03 da ABRASF temos a seguinte recomendação: No caso da cidade de Blumenau/SC o provedor contratado pela prefeitura é o SimplISS e este se utiliza para esta cidade a versão 2.03, logo deveria aceita a sequencia \s\n como quebra de linha e ao gerar o XML da NFS-e manter essa sequencia de caracteres no texto original que consta no RPS que foi enviado. Resumindo, esta previsto sim essa sequencia de caracteres no manual.

Boa noite Diego, Muito obrigado pela colaboração, já inclui na lista de tarefas para o pessoal que cuida do Fast Report avaliar. TK-5545

Boa noite @Vitor Domingos, O NFCom não importa a UF quem recepciona é a SEFAZ-Virtual do RS, por conta das enchentes eles devem estar priorizando os modelos de documentos fiscais que estão em uso a anos, esse por ser novo e poucos estão usando, devem ter deixado de lado.

Boa tarde @dna.automacao, O componente novo - ACBrNFSeX as URLs estão definidas no arquivo ACBrNFSeXServicos.ini, são elas: [4304408] ; Atualizado em 17/05/2022 Nome=Canela UF=RS Provedor=SystemPro Versao=2.01 Params=GerarGrupoRps: ProRecepcionar=https://www.nfse.canela.rs.gov.br:8182/NfseService/NfseService HomRecepcionar=https://www.nfse.canela.rs.gov.br:8183/NfseService_Homolog/NfseService_Homolog O componente antigo - ACBrNFSe se tratando do provedor SystemPro temos o seguinte: Arquivo SystemPro.ini [URL_P] RecepcaoLoteRPS=https://%NomeURL_P%:8182/NfseService/NfseService [URL_H] RecepcaoLoteRPS=https://%NomeURL_H%:8182/NfseService_Homolog/NfseService_Homolog A porta 8182 da URL de homologação esta errada o correto é 8183. Arquivo Cidades.ini [4304408] Nome=Canela UF=RS Provedor=SystemPro NomeURL_H=www.nfse.canela.rs.gov.br NomeURL_P=www.nfse.canela.rs.gov.br Vamos pegar a URL de Produção. O componente antigo substitui a variável %NomeURL_P% que esta no arquivo SystemPro.ini pelo valor do campo NomeURL_P que esta no arquivo Cidades.ini Ficando da seguinte forma: https://www.nfse.canela.rs.gov.br:8182/NfseService/NfseService Como você pode ver as ULRs são exatamente iguais.

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

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

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

Bom dia @Patrick Knopf, Complementando tudo o que lhe foi passado, veja este fragmento de código que se encontra na unit Prescon.Provider: Response.ArquivoEnvio := '<setInvoice soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">' + '<strJsonInvoice xsi:type="xsd:string">' + Params.Xml + '</strJsonInvoice>' + '<strToken xsi:type="xsd:string">' + Emitente.WSChaveAutoriz + '</strToken>' + '</setInvoice>'; Observe que a tag strToken ao ser gerada vai conter o valor atribuído a Emitente.WSChaveAutoriz. O Token retornado pelo método GerarToken é armazenado em: ACBrNFSeX1.WebService.GerarToken.Token e data de expiração em .DataExpiracao. A data de expiração esta zerada pois se você analisar a procedure TratarRetornoGerarToken não consta a leitura dessa data do retorno, mas segundo o manual desse provedor de outra cidade que temos o prazo de validade do token é de 15 minutos, veja:

Bom dia @tcharraw, No XML que você anexou temos o grupo Confirmacao, dentro deste temos o grupo Pedido com as informações referente ao pedido de cancelamento e a tag DataHora. Pelo XML eu entendo que a nota foi cancelada e data e hora que consta na tag DataHora é a data e hora do cancelamento. Através do site da prefeitura/provedor a nota em questão consta como cancelada ou não? Se não constar se faz necessário entrar em contato com a prefeitura/provedor para saber o porque a nota não foi cancelada sendo que o retorno do webservice consta que a nota foi cancelada. Tem provedor que após o cancelamento se você consultar a nota pelo seu numero é retornado um novo XML da nota com as informações sobre o cancelamento, mas infelizmente nem todos os provedores nos dão um retorno como deveria ser.

Bom dia @suprasys, Você trabalha com qual linguagem de programação? Se for o Object Pascal (Delphi ou Lazarus) então você vai usar os componentes, neste caso o ACBrNFSeX, temos o programa exemplo para este componente, cuidado pois existe uma versão antiga desse componente chamada ACBrNFSe, não use esse componente e consequentemente o seu programa exemplo. Se você utiliza outra linguagem de programação então você vai utilizar a DLL ACBrLibNFSe ou a aplicação chamada ACBrMonitor Plus. Caso você venha a usar a DLL, pode ser que não tenhamos o programa exemplo para a linguagem que você trabalha.

Boa tarde @jovitomg, Já esta no SVN. Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e inicio os testes.

Filipe, Já esta no SVN.

João, Já esta no SVN.

Boa tarde Michael, Já esta no SVN. A alteração só foi feita para o novo componente.

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

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

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Bom dia @Nelson Santos, Já esta no SVN.

Olá Pessoal, As dicas abaixo são validas para todos os os modelos de DF-e (Documentos Fiscais Eletrônicos). 1. A chave de um DF-e é composta por diversas informações e todas elas estão presentes no XML. A chave é composta pelo Código da UF (2 dígitos), Ano (2 dígitos) e Mês (2 dígitos) de emissão, CNPJ do emitente (14 dígitos), modelo do DF-e (2 dígitos), série (3 dígitos) e numero do documento (9 dígitos), tipo de emissão (1 dígito), código aleatório do documento (8 dígitos) e digito verificador (1 dígito). Devemos guardar no banco de dados, juntamente com os demais dados do DF-e as seguintes informações: Data/Hora de emissão e Código aleatório que deve conter somente 8 dígitos. Jamais use como código aleatório o próprio numero do documento, pois isso você deixa a chave vulnerável. O código aleatório deve ser gerado pela sua aplicação e armazenado no banco de dados conforme orientado acima, jamais deixe o componente gerar o código para você, pois desta forma você perde o controle dessa informação. A Data/Hora deve ser definida e também armazenada no banco de dados, jamais devemos usar a função Now na rotina que alimenta o componente, pois isso faz com que você também perca o controle dessa informação. Ao alimentar o componente com os dados do DF-e todas as informações devem ser lidas do banco de dados, com exceção do Digito Verificado da chave que é o próprio componente que o calcula. 2. De preferencia de guardar o XML do DF-e no banco de dados em vez de salvar em disco, pois alguns usuários desavisados resolvem excluir arquivos do HD da maquina por achar que tem muito arquivo salvo. Se isso ocorrer, ou seja, o usuário acabar deletando o XML de um DF-e, tendo todos os dados salvos no banco de dados basta fazer o seguinte: Alimente o componente com os dados do documento que estão no banco de dados, execute os métodos Assinar, Validar e Consultar. Desta forma você vai ter o XML de volta, mas lembre-se que esse processo só pode ser executado caso o DF-e tenha sido emitido dentro do prazo de 180 dias, passou de prazo não tem como recuperar. 3. Se ocorrer erro de internet (timeout por exemplo) como devo proceder? A resposta é muito simples: Não devemos enviar o documento novamente, pois o documento pode ser rejeitado por duplicidade. Não devemos gerar, assinar, validar o XML novamente, pois essa atitude pode mudar o código aleatório do documento e a data/hora de emissão caso você não seguir as orientações da primeira dica. Com isso ao enviar novamente o documento pode ser rejeitado por duplicidade com diferença chave, situação mais grave. Devemos sim carregar o XML que foi enviado através do método LoadFromFile (se esta salvo em disco) ou LoadFromString (se esta salvo no banco de dados) e em seguida executar o método Consultar. Antes de enviar o DF-e para a SEFAZ atualize o banco de dados mudando o status do documento como "Enviado", depois devemos executar o método Enviar. Se ocorrer o erro de internet a aplicação não deve permitir que o usuário envie novamente o mesmo documento uma vez que ele esta marcado como Enviado, mas a aplicação libera o documento para que o mesmo seja carregado e consultado conforme dito acima. Caso o retorno for uma rejeição acusando que o documento não se encontra na base de dados da SEFAZ, a aplicação pode tomar uma atitude automática de enviar novamente o documento, visto que ele não se encontra na base de dados da SEFAZ. Por outro lado se retornar o protocolo de autorização, como o componente esta com o documento "carregado" o XML será automaticamente atualizado e salvo em disco ou disponibilizado para que o mesmo possa ser salvo no banco de dados. A aplicação em seguida pode imprimir o documento auxiliar do DF-e. Seguindo essas dicas, muitos problemas com a emissão de DF-e são sanadas.

Bom dia Michael, Se tratando do novo componente ACBrNFSeX, leia o tópico abaixo.