Italo Giurizzato Junior

Bom dia simons, Em vez de criar esse novo campo, não poderia checar o conteúdo do campo logradouro? Se este campo não for vazio a tag <endereço_informando> recebe o valor "S" caso contrario recebe o valor "N".

Bom dia José, Detalhe melhor o seu cenário. É a sua aplicação que gera o XML e utiliza o componente ACBreSocial para fazer o resto? Se sim, esse erro esta ocorrendo também com o programa exemplo?

Bom dia, Primeiramente não se deve enviar novamente uma nota quando ocorre um erro de comunicação com a SEFAZ, e sim realizar uma consulta. Se o retorno da consulta acusar que a nota não existe no banco de dados da SEFAZ, fica claro que o erro ocorreu no envio, ai sim podemos enviar novamente a nota. Segundo, ao enviar ocorre o erro de duplicidade com diferença de chave a explicação é simples. 1. A nota já consta na SEFAZ; 2. No final da chave temos um campo chamado Código da Nota Fiscal (cNF) que por recomendação da SEFAZ deve ser um código aleatório para que a chave seja segura. O que esta ocorrendo é que no seu arquivo texto o campo cNF não esta sendo informado, logo o Monitor o considera como zero, desta forma faz com que ele mesmo gere um código aleatório para cNF, isso faz com que o numero da Nota Fiscal (nNF) seja o mesmo mas o cNF seja diferente da nota que foi enviada anteriormente, vamos a um exemplo. No primeiro envio tínhamos: nNF = 1000, como não foi informado o valor de cNF o monitor gerou o valor de cNF aleatoriamente( por exemplo: 125); Como ocorreu erro e a nota foi enviada novamente de forma indevida sendo que o correto seria consultar, temos no segundo envio: nNF = 1000 e cNF = 389 (gerado aleatoriamente). Repetindo, como o erro não foi no envio e sim no retorno a SEFAZ recebeu a nota de numero 1000 e ao enviar pela segunda vez a SEFAZ acusa duplicidade pelo simples fato da nota de numero 1000 já existir e a questão de diferença de chave é porque no primeiro envio o valor de cNF era 125 e no segundo é 389, e como dito o valor de cNF faz parte da chave. Sugestões: 1. Quando ocorrer erro, primeiro realize uma consulta, se a SEFAZ retornar a mensagem que a nota não consta na base de dados, ai sim você envia novamente. 2. Faz com que a sua aplicação gere o cNF aleatoriamente e armazene no banco de dados juntamente com os demais dados da nota e ao gerar o arquivo texto acrescente-o na seção [ide]. exemplo: [ide] nNF=1000 cNF=5789 (...) Observação: o código da Nota Fiscal deve ser um numero aleatório diferente de zero, diferente do próprio numero da nota e com no máximo 8 dígitos (vide exemplo acima).

Bom dia Sergio, Segundo a ABRASF a situação pode ser: 1 - Lote não recebido, 2 - Lote em processamento, 3 - Lote Processado com falhas, 4 - Lote Processado com sucesso. O problema é que o provedor de São Paulo não segue o layout da ABRASF, logo o significado da situação pode ser outro.

Bom dia Joelcio, Favor anexar a unit alterada para que possamos analisar e estando tudo OK vamos enviar para o repositório.

Bom dia Hélio, O seu arquivo esta errado. Em vez de: [NFRef001] Tipo=NF O correto é: [NFRef001] Tipo=NFE

Bom dia Paulo, O grande problema é que os provedores não seguem um padrão nacional, logo o que funciona para um cidade não existe a garantia que vai funcionar para outra. O que você deseja obter é o valor do campo Situação, correto? Pois bem no retorno obtido após o envio ou consulta da NFS-e enviada para a cidade de São Paulo tem essa informação no XML?

Bom dia a todos, Vou fechar este tópico pois ele já possui 4 paginas, por favor criem novos tópicos para assuntos novos. Obrigado pela compreensão de todos.

Bom dia, Procurou por essa cidade no arquivo Cidades.ini? Se ela não consta, não tem como emitir. Neste caso se faz necessário descobrir qual é a empresa (provedor) contratada pela prefeitura. Sabendo qual é o provedor, é preciso saber se o componente ACBrNFSe já possui ele implementado, se sim basta acrescentar a cidade em questão no arquivo Cidades.ini aos moldes das demais cidades que são atendidas pelo mesmo provedor. Talvez seja necessário também incluir as URLs de homologação e produção dessa cidade no arquivo INI do provedor. Agora se o provedor não esta implementado no componente, você vai ter que ir em busca de mais informações.

Roberto, Tente da seguinte forma: Em ACBrNFSeConfiguracoes, faça a seguinte alteração (incluir a linha em negrito): FConfigGeral.QuebradeLinha := trim(FPIniParams.ReadString('Geral', 'QuebradeLinha', '')); if FConfigGeral.QuebradeLinha = 'ENTER' then FConfigGeral.QuebradeLinha := #13#10; Em pnfsNFSeW_ABRASFv1, faça a seguinte alteração (incluir o valor False que esta em negrito): Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1, StringReplace(FNFSe.Servico.Discriminacao, ';', FQuebradeLinha, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR, False); Esse parâmetro acrescentado no final faz com que o ParseTextoXML seja false e com isso o FltrarTextoXML não seja executado, desta forma os caracteres #13#10 não serão removidos da tag <Discriminacao>. Bom, acredito que agora vai resolver o problema da quebra de linha no campo desejado. Se funcionar o XML do RPS tem que ficar com a quebra de linha como você deseja. Ai o próximo passo é encontrar uma solução no que diz respeito a assinatura, que acaba removendo a quebra de linha.

Bom dia Roberto, Assim que eu gosto, pessoas que estudam os fontes dos componentes. Então precisamos procurar a melhor solução para esse problema.

Bom dia, Será necessário fazer uma alteração no DACTE feito em Fortes Report. Não é difícil, você quer colaborar em fazer essa alteração?

Bom dia Sandro, Sim, mas precisamos de mais material, tais como os schemas de validação, XML de exemplos, ... E contamos com a colaboração de todos.

Bom dia Paulo, Muito obrigado pela colaboração, ainda hoje vou analisar e estando tudo correto vou enviar para o repositório.

André, Se ocorrer o caso de ter troco é preciso informar o valor do troco no campo vTroco, caso contrario essa informação não vai constar no XML e com certeza a nota vai ser rejeitada. exemplo: pag.vTroco := 2.00; Outra coisa, baixe do Portal Nacional da NF-e a Nota Técnica 2016/002 versão 1.60, nessa NT você encontra tudo sobre a versão 4.00, tanto da NF-e quanto da NFC-e. Com relação ao QR-Code o componente possui uma propriedade nova onde você informar a versão do mesmo, se a SEFAZ rejeitar a nota porque você informou versão 1.00 para o QR-Code, altere a versão para 2.00 e tente novamente. Só assim você vai saber qual das duas deve ser utilizada, uma vez que tem UF que já mudou para a 2.00 e outras ainda não.

Bom dia André, A questão do QR-Code se refere a NFC-e, você esta emitindo NF-e ou NFC-e? No que diz respeito ao troco, só deve ser destacado caso o cliente pague em dinheiro e um valor maior que o da nota, por exemplo, o total da nota é 48 reais e o cliente pagou em dinheiro com uma nota de 50 reais, logo devemos informar o valor pago em dinheiro e informar o troco de 2 reais.

Bom dia André, O componente ACBrNFe possui uma propriedade de configuração chamada SSLLib, basta atribuir o valor libWinCrypt. ACBrNFe1.Configuracoes.Geral.SSLLib := libWinCrypt; Não esqueça de declarar em Uses a unit ACBrDFeSSL, caso contrario não vai reconhecer o valor libWinCrypt.

Bom dia, Favor atualizar os fontes e faça novos testes. Esse erro em "branco" é porque o componente não conseguiu ler corretamente o retorno.

Bom dia Roberto, Se no arquivo RJ.ini tivermos: QuebradeLinha=#13#10 E ao alimentar o componente mais precisamente o campo Discriminação informarmos: Serviço 1;Serviço 2;;Serviço 3 (por exemplo). Ao gerar o XML teremos: Serviço 1#13#10Serviço 2#13#10#13#10Serviço 3 Mantendo a linha: Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1, StringReplace(FNFSe.Servico.Discriminacao, ';', FQuebradeLinha, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR); Pois esta realiza a troca do ";" ponto e virgula pelo conteúdo do campo QuebradeLinha definido no arquivo INI. O problema agora é com a remoção dos caracteres #13#10 realizado pela rotina que faz a assinatura.

Bom dia, O erro: Falha ao localizar o nó de Assinatura só ocorre quando executamos a aplicação através do Delphi, neste caso basta clicar no botão Continuar.

Bom dia Rene, Isso nunca ocorreu comigo. Com certeza o usuário deve ter restaurado o banco de dados e emitiu novas notas, com isso você tem chaves iguais com conteúdo diferente. Agora me diga, essa nota que possui a mesma chave foi autorizada? Compare o DigestValue da assinatura da nota com o do protocolo, tem que ser iguais.

Bom dia Paulo, Verificando as Notas Técnicas publicadas em 2017 e 2018 não tem nenhuma que vai entrar em vigor nos próximos meses, todas já estão em vigor.

Bom dia Rubens, O Capicom só funciona se o Identificador foi Id (com o i maiúsculo) no caso de Salvador é id (tudo minúsculo). Neste caso para não ocorrer esse erro, no arquivo INI temos que alterar para zero o valor de URI, mas mesmo assim vai continuar acusando que o Hash esta errado ou inválido.

Para o provedor Saatri tente o seguinte: 1. no programa exemplo aba WebServices temos 3 campos logo abaixo do quadro Proxy, são eles: Senha, Usuário e Frase Secreta. Informe a senha e o usuário criado para essa empresa emitir notas. 2. na aba certificado no campo SSL Lib coloque o valor libCapicomDelphiSoap. Refaça os testes.

Bom dia Diego, O erro: Falha ao localizar o nó de assinatura é normal uma vez que você esta executando a aplicação através do Delphi, basta clicar no botão continuar. Já o erro de falha de validação é preciso saber o que de errado no XML, tag faltando, tag com nome errado, tag fora do lugar ou valor da tag incorreto.