Italo Giurizzato Junior

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Cordeiro, Você esta perdendo tempo gerando a chave e passando para o campo ID, o componente ao gerar o XML gera a chave e atribui a chave gerada ao campo ID. Isso é uma segurança, pois muitos comentem erros ao gerar a chave. Se você quer armazenar a chave no banco de dados, é muito fácil, após alimentar o componente execute o método Assinar, este vai gerar o XML, assinar e salvar em disco se for o campo. Depois de executado o método Assinar você lê a campo ID, pronto você tem a chave para armazenar no banco de dados. Outra dica importante, vendo o seu XML notei que você esta atribuindo o numero do BP-e ao código do BP-e ( nBP é igual a cBP ). Isso esta errado e deixa a chave do seu BP-e (Documento Fiscal Eletrônico) fraca. A SEFAZ a partir de 02/09/2019, conforme consta na Nota Técnica 2019/001 não vai mais aceitar NF-e e NFC-e cujo valor de nNF seja igual a cNF. Resumindo as notas vão ser rejeitadas pela regra de validação B03-10 (que consta na NT mencionada acima). Acredito que até o final deste ano ou ano que vem os demais Documentos Fiscais Eletrônicos vão passar também a ter essa regra de validação. Sendo assim, quando for salvar no banco de dados as informações sobre o Bilhete, gere um código aleatório de no máximo 8 dígitos diferente de zero e do numero do bilhete (nBP) e salva junto com os demais dados do bilhete. nBP = é um numero sequencial cBP = é um numero aleatório (página 85 do Manual BPe versão 1.00a) - Código aleatório gerado pelo emitente, com o objetivo de evitar acessos indevidos ao documento. Espero ter ajudado.

Bom dia reij, As informações sobre produtos perigosos no CT-e versão 3.00 só devemos informar se o modal for aéreo, caso contrario não se deve informar. Por outro lado no MDF-e versão 3.00 podemos incluir as informações sobre produtos perigosos para qualquer modal. Checando o manual vigente do MDF-e bem como o novo, pois a partir de 10/2019 entra em vigor um novo layout, em ambos não esta previsto a impressão das informações sobre produtos perigosos.

Bom dia Renan, Em uma de suas postagens você anexou duas versões do Schema: tiposGeralCTe_v3.00 Qual das duas funciona sem nenhum problema com o xsLibXml2 ?

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Paulo, Maravilha, descobri que diferença é no SignatureValue. Vamos agora analisar o motivo dessa diferença.

Paulo, Como o teste foi feito com numero de NFS-e diferente fica mais complicado onde exatamente esta ocorrendo o erro pois as tags: AssinaturaCancelamento, DigestValue e SignatureValue são diferentes. Seria interessante emitir uma nota, tentar cancelar com a unit atual (vai ocorrer o erro), copiar os XMLs referente ao cancelamento, depois trocar a unit e efetuar o cancelamento da mesma nota. Ai sim comparar as 3 tags que mencionei, pois é uma delas ou mais de uma que esta sendo gerada de forma errada.

Bom dia ALA, Favor ler essa noticia: Alterações nos arquivos INIs

Paulo, Esses XMLs se referem ao pedido de cancelamento feito com a unit que funciona, correto? E os XMLs que se referem ao pedido de cancelamento feito com a unit que ocorre o erro?

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

Paulo, Anexa a unit cuja assinatura é realizada com sucesso. Mais o XML gerado com essa unit e o XML gerado pela unit que se encontra atualmente no repositório.

Bom dia Everton, Fiz uma alteração que acredito que vai resolver esse problema. Lembrando que o provedor EGoverneISS não retorna o XML da NFS-e e sim um link onde é possível baixar o XML. Se tratando de ambiente de homologação esse link não é retornado.

Bom dia Paulo, Faça uma cópia dessa unit cuja a assinatura do cancelamento funciona. Atualiza todos os fontes e faça um novo teste. Por favor leia essa noticia: Alteração nos arquivos INIs

Bom dia, O campo CodMunic é do tipo Integer, mas ao gerar a tag no XML o tipo de conversão era tcStr, isso faz com que mesmo atribuindo o valor zero ao campo a tag é gerada. Fiz uma alteração não só nesse campos mais em outros do mesmo evento que também são Integer, mas que estavam com o tipo de conversão tcStr. Mudei o tipo de tcStr para tcInt, desta forma ao atribuir o valor zero a codMunic, por ser um campo opcional ele não vai mais ser gerado. A dica é, para tpLocal = 2 devemos atribuir o valor zero a codMunic.

Boa tarde, Tente desta forma: NFe.ConsultaCadastro("SP","xxxxxxxx000160")

Flavio, Você tem certeza que não tem nenhuma cidade no arquivo Cidades.ini que esteja usando o provedor RLZ? Veja: [5107958] Nome=Tangara da Serra UF=MT Provedor=RLZ NomeURL_H=mt/tangaradaserra NomeURL_P=tangaradaserra.mt.gov.br De onde você esta baixando os fontes dos componentes?

Boa tarde, Como você fez, e qual foi o resultado, favor anexar o log.

Boa tarde Bruno, Você esta usando a versão mais recente do ACBrMonitor? Se você envia novamente a nota e a mesma é rejeitada por duplicidade, isso significa que a primeira vez que ela foi enviada em modo síncrono, ela foi recebida, processada e autorizada pela SEFAZ. Logo conclui-se que a SEFAZ-MT suporta a recepção de NFC-e em modo síncrono. Você tem um outro problema que é, Duplicidade com diferença na chave. Isso significa que a nota enviada pela segunda vez, a chave estava diferente. O que pode provocar essa diferença? O erro mais comum é não atribuir um valor para o campo cNF (Código da Nota Fiscal) que faz parte da chave. Se você não atribuir um valor para o campo cNF o Monitor se encarrega de gerar um código aleatório, isso explica que o segundo envio da mesma nota ter a chave diferente. A minha sugestão é que a sua aplicação gere um código aleatório para cNF, armazene esse código no banco de dados com os demais dados da nota e no momento de gerar o arquivo TXT com os dados da venda, atribua o código ao campo cNF. Como isso você garante que a chave sempre será gerada exatamente igual. Por fim, acredito o seu problema de não receber informações corretas logo após o primeiro envio deve ser devido ao uso de alguma versão antiga do monitor.

Boa tarde Eduardo, Qual evento você se refere? Pois quando emitidos uma NFC-e em contingência na verdade nada é enviado, pois a contingência da NFC-e é off-line. A contingência off-line resume em apenas imprimir o DANFE NFC-e em duas vias, uma para o consumidor e outra para o emitente da nota. Sugiro que leia o arquivo: Como tratar a contingência da NFC-e que se encontra na Base de Conhecimentos.

Boa tarde Flavio, Como assim, não existem implementação para o provedor RLZ? 08/02/2019 -- Diversos -- [+] Implementação de um novo Provedor - RLZ Por: Italo Jurisato Junior Faz 3 meses que esse provedor foi implementado.

Boa tarde Everton, O programa exemplo possui uma opção para ele salvar os arquivos Soap. Essa opção esta ativada? Se não esta, favor ativar essa opção e faça um novo teste e anexe os arquivos soap.

Olá pessoal, Quem se utiliza do componente ACBrNFSe fiquem atentos com as alterações realizadas em alguns arquivos INIs dos provedores. Ao atualizar os fontes do ACBr a partir de hoje (13/05/2019), por conta de melhorias realizadas nas Units responsáveis pela assinatura digital se faz necessário enviar para os seus clientes os novos arquivos INIs bem como o novo executável. Caso esse procedimento não seja feito vai ocorrer erros ao tentar realizar a assinatura no pedido de cancelamento de uma NFS-e.

Bom dia Celson, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.