Italo Giurizzato Junior

Boa tarde, Você deve atribuir o valor libWinCrypt a SSLLib e o valor LT_TLSv1_2 a SSLType e deixar os demais com seus valores padrões.

Boa tarde Leandro, Você tem o XML *-ped-can.xml de uma outra nota que foi cancelada com sucesso? Se sim, favor anexar.

Vou relacionar algumas que considero muito importantes. 1. Procure ter no banco de dados todas as informações do documento, pois se o seu cliente vir a perder o XML, será possível gerar e assinar ele novamente com as mesmas informações e por fim executar o método Consultar para obter o protocolo de autorização e com isso deixar o XML completo, ou seja, assinado e protocolado, tornando-o desta forma um documento com validade jurídica. 2. Jamais informe o numero do documento como sendo o código do documento, a titulo de exemplo a NF-e: muitos atribuem o valor de nNF (numero da nota fiscal) a cNF (código da nota fiscal). Essas duas informações fazem parte da chave, logo não faz nenhum sentido serem iguais. Por recomendação da SEFAZ o valor de cNF tem que ser um numero aleatório. Logo devemos gerar esse numero e armazena-lo no banco de dados junto com os demais dados da nota. Outro detalhe importante o tamanho de nNF é de 9 dígitos, já o tamanho de cNF é 8, portanto quando o numero do documento atingir a casa dos 9 dígitos, como você vai passar esse numero para o código que só aceita 8 dígitos? Todo o que foi dito acima referente a NF-e, devemos também levar em consideração aos demais Documentos Fiscais Eletrônicos. No CT-e temos nCT (numero do Conhecimento) e cCT (código do Conhecimento), sendo que este último deve ser um numero aleatório e diferente do nCT. No MDF-e temos nMDF (numero do Manifesto) e cMDF (código do Manifesto), mesma recomendação do CT-e. No BP-e temos nBP (numero do Bilhete) e cBP (código do Bilhete), mesma recomendação do CT-e. 3. Prefira armazenar os XMLs no banco de dados em vez no Disco, isso evita que algum usuário apague sem quer os XMLs. 4. Para quem utiliza o certificado A1, prefira armazenar o seu conteúdo no banco de dados, pois desta forma não se faz necessário instalar o mesmo na maquina.

Esse erro ocorre quando o XML do DF-e - Documento Fiscal Eletrônico é gerado e assinado novamente e valor da tag <DigestValue> da assinatura não é o mesmo da tag <digVal> que é retornado junto com o protocolo de autorização ao realizar uma consulta. O motivo do DigestValue estar diferente ao gerar e assinar novamente é porque alguma informação mudou em relação a primeira vez que o XML foi gerado e enviado para a SEFAZ. A informação mais comum é o valor passado para dEmi (data de emissão), devemos passar para esse campo a data/hora e podemos usar o a função Now do Delphi, mas muitos se esquecem de salvar essa informação no banco de dados e ao gerar novamente com certeza a data e ou a hora vão estar diferentes, isso já é o suficiente para gerar um DigestValue diferente na assinatura. Boa pratica: Se você prefere sempre gerar e assinar o XML novamente, então procure ter todas as informações armazenadas no banco de dados. Por outro lado lembre-se que se você já possui o XML assinado, não faz sentido gerar ele novamente, basta carrega-lo através do método LoadFromFile ou LoadFromString ou LoadFromStream (dependendo do caso) e por fim executar o método Consultar.

Vamos supor que você perdeu o XML de um DF-e Documento Fiscal Eletrônico, seja ele uma NF-e, NFC-e, CT-e, CT-e OS, MDF-e ou BP-e. O procedimento é muito simples, basta alimentar o componente com os dados do documento, executar o método Assinar e por fim o método Consultar. Abaixo um exemplo usando o componente ACBrNFe, mas pode ser aplicado para os demais modelos de DF-e. (...) AlimentarComponente; ACBrNFe1.NotasFiscais.Assinar; ACBrNFe1.Consultar; (...) E para quem usa o Monitor: NFe.CriarNFe( arqINI ); NFe.AssinarNFe( pathNomeXML ); NFe.ConsultarNFe( pathNomeXML );

Bom dia Lopes, Cara não entendi nada o que você escreveu e qual é o problema que esta ocorrendo? Outra coisa, você vai gerar o XML do CT-e ou do CT-e OS?

Bom dia Gean, Qual é o motivo de constar as duplicatas (que hoje a SEFAZ chama de Parcelas) no XML e não serem impressas no DANFE? Tanto o DANFE feito em Fast com feito em Fortes Report possuem uma propriedade de configuração chamada ExibeCampoFatura, mas não tem uma propriedade de configuração chamada ExibeCampoDuplicata. O Quadro referente a Fatura é condicionado ao valor da propriedade ExibeCampoFatura. Por outro lado o quadro referente a Duplicata(Parcelas) é condicionado a quantidade de parcelas constantes no XML, se tiver 1 ou mais o quadro será impresso. Como não vejo motivo das parcelas constarem no XML e não serem impressas no DANFE isso seja o motivo de não existe a propriedade ExibeCampoDuplicata. Mas como você possui os fontes dos componentes, use a força, veja como foi feito a implementação da propriedade ExibeCampoFatura e implemente a propriedade ExibeCampoDuplicata.

Bom dia, Se você perde o XML de uma nota que foi emitida, a solução é: 1. Alimentar o componente com os dados da nota. 2. Gerar o XML, use para isso o método assinar, pois este além de gerar o XML já assina 3. Executar o método Consultar para obter o protocolo de autorização e consequentemente atualizar o XML para que este fique completo, ou seja, assinado e protocolado. Se ao realizar esse processo no final ocorre o erro de DigestValue não confere é porque alguma informação da nota esta diferente. É muito comum os desenvolvedores ao alimentar o componente com os dados da venda atribuir o valor de Now ao campo dEmi, não que esteja errado, esta correto, mas se esquecem de armazenar no banco de dados o valor atribuído. Ao gerar novamente o campo dEmi acaba ficando com uma outra data e ou hora, consequentemente gerando um DigestValue diferente do que foi gerado da primeira vez. O componente ao obter o retorno da consulta compara o DigestValue da assinatura do XML com o DigestValue retornado pela consulta, se for diferente apresenta a mensagem relatando o fato.

Bom dia Gean, Deixa eu ver se entendi. O cliente (seu no caso) necessita da nota, o fornecedor dele pede para o contador mandar o TXT que contem os dados da nota. Que o contador tem haver com essa história? É ele que emite a nota para o fornecedor do seu cliente? Se sim, não seria mais fácil o fornecedor pedir para o contador o XML da nota em vez do TXT? Visto que o XML segue um padrão nacional e é a Nota Fiscal propriamente dita, já o arquivo TXT até o momento a SEFAZ/SEBRAE não divulgaram um documento com o layout para a versão 4.00, além de não ser a nota. Uma observação, você não leu com atenção a postagem do nosso amigo Amarildo? Você já leu sobre o Distribuição de Documentos Fiscais Eletrônicos - DistribuicaoDFe e sobre os eventos de Manifestação do Destinatário? Se não leu, lhe recomento a leitura das notas técnicas: 2014/002 versão 1.02b que trata sobre o DistribuicaoDFe e a 2012/002 versão 1.02 que trata sobre a Manifestação do Destinatário. No programa exemplo do componente existe botões que exemplificam as suas utilizações e no fórum temos diversas postagens sobre esses dois assuntos. Com essa dupla dinâmica, a sua aplicação vai ser capaz de baixar da SEFAZ os XML completos das notas de todos os fornecedores do seu cliente. Ficando livre desse arquivo TXT que só da dor de cabeça.

Bom dia Felipe, Esse erro também ocorre com o programa exemplo do componente ACBrNFe? Tente desta outra forma: ACBrNFe.NotasFiscais.Clear; ACBrNFe.NotasFiscais.LoadFromFile( NomeArquivoXML ); ACBrNFe.Cancelamento( xJust, nLote );

Bom dia Marcio, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Sandro, Essa alteração também funciona para as demais Operações Fiscais ou somente para a 5.9? Vai funcionar para todas as cidades atendidas por esse provedor ou somente para Santa Cruz do Sul?

Bom dia Eduardo, A Manifestação do Destinatário é um evento e no seu retorno não consta nenhum NSU. Logo o NSU que você esta armazenando é o NSU retornado juntamente com o resumo da nota. O seu procedimento esta errado. Sugiro então em vez de executar o DistribuicaoDFePorNSU, uma vez que você não tem o NSU do XML completo e sim do Resumo da nota, você deve executar o DistribuicaoDFePorChaveNFe, neste caso você passa a chave da nota que foi previamente manifestada pelo destinatário.

Bom dia Gean, Pelo amor de Deus, que desespero é esse? Cara, precisei ler umas 4 vezes para entender o que você deseja, por favor seja mais claro e preciso. Não seria mais simples você escrever simplesmente: As duplicatas devem constar no XML e que gostaria que as mesmas não fossem impressas no DANFE, se isso é possível como proceder?

Bom dia Gean, O programa gratuito da SEFAZ pode ser utilizado de duas formas. 1. Você digita todas as informações nele e depois manda emitir a nota. Note que usei o termo emitir e não imprimir. Emitir significa, gerar o XML, assinar, validar, enviar para SEFAZ, aguardar o seu processamento e atualizar o XML com o protocolo de autorização. Ao emitir se tudo ocorrer bem, ou seja, a nota foi autorizada, devemos então imprimir o DANFE e exportar o XML, pois o programa da SEFAZ guarda o XML assinado e protocolado no banco de dados. Por fim você deve enviar um e-mail ao destinatário da mercadoria anexado o XML exportado pelo programa da SEFAZ. A forma descrita acima é usado pelas penas empresas que não possuem nenhum outro software de controle, por exemplo: Estoque, Contas a Pagar/Receber, etc. 2. Para as empresas que já possui um software de controle, más em função da linguagem utilizada no seu desenvolvimento não permite estabelecer conexão com a internet, por exemplo o GWBasic (lembra, vinha junto no disquete do MS-DOS), neste caso é possível criar nesse software uma rotina que gere um arquivo TXT segundo o layout da SEFAZ que contem todos os dados referente a venda. Com o arquivo TXT gerado, basta executar o programa da SEFAZ e solicitar a sua importação, desta forma não se faz necessário a digitação. Arquivo importado, basta emitir a nota, imprimir o DANFE, exportar o XML e enviar por e-mail para o destinatário o XML exportado. Você notou que de uma forma ou de outra no final devemos enviar ao destinatário o XML? Esses fornecedores do seu cliente que manda o arquivo TXT em vez do XML, não estão exportando o XML para enviar por e-mail. Quer resolver esse problema com esses fornecedores? É muito simples, compra, recebe a mercadoria, se chegar o arquivo TXT em vez do XML, liga para o fornecedor e diga o seguinte: Lhe devo não nego, te pagarei quando me enviar o XML assinado e protocolado.

Luiz, Segundo o Schema se faz necessário assinar o pedido de cancelamento. Fiz mais uma alteração nos fontes do componente, favor atualizar e faça um novo teste.

Werner, Essa mensagem consta do arquivo XML de retorno da consulta? Se sim, envia esse XML para a SEFAZ. E pede para eles tomarem uma providencia, pois se a regra não esta sendo aplicada, como que o webservice esta retornando essa rejeição ao realizar a consulta?

Roberto, Esse provedor não foi implementado, peça a eles um XML exemplo de envio de RPS.

Bom dia Gumercino, Muito obrigado pela colaboração, já passei a sua alteração para o pessoal que conhece bem o Fast Report para analisa-la.

Bom dia Roberto, Afinal a cidade de Bragança Paulista usa o provedor GovDigital ou o Giap?

Bom dia, Uma coisa é você incluir a cidade no arquivo Cidades.ini para que seja possível o envio de RPS para o provedor dessa cidade. Segundo é você informar os dados corretos no componente referente ao RPS. O que esta ocorrendo é que você enviou um RPS com informações erradas.

Luiz, E quando solicita o cancelamento se incluir a assinatura, qual é o retorno? Anexa o XML de retorno.

Bom dia Werner, Essa rejeição é estranha pois não encontrei no manual e nem nas notas técnicas. Uma coisa é certa, o contador do seu cliente é muito fraco, levou 8 meses para descobrir que estavam faltando notas.

Bom dia a todos, Que eu saiba ninguém esta implementando esses 2 novos eventos. Pelo que li na Nota de Documentação Evolutiva - NDE, esses eventos vão se tornar obrigatórios a partir de janeiro de 2019. A sua implementação no componente não vejo problemas, basta tomar como base a implementação dos outros. O problema maior é quanto ao Schema (arquivo XSD) que o componente se utiliza para validar o XML após a sua geração e assinatura.

Bom dia Luiz, Mas o pedido de cancelamento tem que estar assinado, porque você alterou o arquivo INI para que não ocorra a assinatura? Qual é o erro que ocorre no programa exemplo referente a assinatura?