Italo Giurizzato Junior

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

Flavio, Se o contador dele que deveria saber não sabe, nós que somos meros programadores devemos saber? Estou vendo que precisamos fazer um bom curso de escrita fiscal e contábil e passar a cobrar a mais por ter um conhecimento além do esperado para um programador. Só tem esse contador que poderia lhe ajudar?

Boa tarde, Acredito que o problema seja na assinatura da consulta, algo deve estar errado.

O erro que você esta cometendo é o seguinte: Chave = <Código da UF(2)><Ano de Emissão(2)><Mês de Emissão(2)><CNPJ do Emitente(14)><Modelo(2)><Série da Nota(3)><Numero da Nota(9)><Tipo de Emissão(1)><Código da Nota(8)><Digito Verificador(1)> O <Numero da Nota> é o valor de nNF e o <Código da Nota> é o valor de cNF. No seu XML a chave esta da seguinte forma: 32190530624283000103650010000052361091648440 Onde 000005236 é o numero da nota e 09164844 é o código da nota. Mas nesse XML a tag cNF que é o código da nota esta com o valor 000005236. Temos ai três erros: 1. o valor do código (cNF) tem que ter no máximo 8 dígitos e você colocou com 9. 2. o valor do código (cNF) tem que ser o mesmo que foi informado na chave e no seu esta diferente. 3. o valor do código (cNF) tem que ser diferente de zero e de numero da nota (nNF) e no seu esta igual. Na verdade a chave é montada com base em alguns dados das tags da nota e não o inverso.

Olá pessoal, A pesar do titulo fazer referencia a NF-e, mas esse artigo é valido também para a NFC-e, CT-e, CT-e OS, MDF-e e BP-e. Alguns desenvolvedores preferem gerar através da sua aplicação o XML para depois ser lido pelo ACBrMonitor ou pelo componente que vão dar continuidade, ou seja, assinar, validar e enviar para SEFAZ. Vi relatos no fórum que o desenvolvedor gerou o XML com uma determinada chave e o Monitor ou o componente mudaram essa chave. Porque isso ocorre? Essa alteração é provocada porque o valor da tag cNF (se tratando da NF-e e NFC-e) esta com o valor zero ou possui um valor em cNF diferente do que foi usado para compor a chave. Se o valor for zero o componente que é usado pelo Monitor vai gerar um numero aleatório. Agora se o valor de cNF for diferente do que foi usado na chave o componente se encarrega de corrigir a chave. Como é composta a chave? Chave = <Código da UF(2)><Ano de Emissão(2)><Mês de Emissão(2)><CNPJ do Emitente(14)><Modelo(2)><Série da Nota(3)><Numero da Nota(9)><Tipo de Emissão(1)><Código da Nota(8)><Digito Verificador(1)> O <Numero da Nota> é o valor de nNF e o <Código da Nota> é o valor de cNF. Para os demais modelos de documentos fiscais eletrônicos temos: CT-e / CT-e OS <Numero do Conhecimento> = nCT <Código do Conhecimento> = cCT MDF-e <Numero do Manifesto> = nMDF <Código do Manifesto> = cMDF BP-e <Numero do Bilhete> = nBP <Código do Bilhete> = cBP

Boa tarde Gilson, Já fiz a alteração no componente e enviei para o repositório. Quanto a versão 2.00, acredito que o pessoal da SEFAZ esta patinando e não conseguem resolver o problema.

Flavio, Neste caso, acredito que a saída é ele comprar um certificado digital do tipo e-CPF para poder emitir a NF-e (modelo 55), mas ai ele vai usar esse outro certificado e vai colocar como emitente os dados dele, ou seja, pessoa física. Outra coisa é verificar junto ao contador dele como proceder a liberação para que ele possa emitir essas notas.

Boa tarde, É a sua aplicação que esta gerando o XML? Se sim, porque ela esta gerando o cNF (Código da Nota Fiscal) com 9 dígitos? Sendo que o correto é com 8. Outra coisa, por favor leia essa noticia sobre a: Nota Técnica 2019/001 Você esta usando o mesmo numero atribuído a nNF em cNF, em breve as suas notas vão ser rejeitadas pela SEFAZ.

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

Flavio, Se ele já emite NF-e como pessoa jurídica, porque ele quer emitir nota de produtor rural? Quero entender melhor essa situação.

Boa tarde Rogério, A propriedade de configuração ela existe pois esta em uma classe mãe. No caso do DANFE NFC-e feito em Fast Report essa propriedade é checada e a impressão ou não dos itens é realizada mediante o valor dela. Já no DANFE NFC-e feito em Fortes Report a impressão dos itens não esta condicionada, ou seja, a propriedade não é verificada para decidir se vai imprimir ou não. Acredito que foi isso que o Elton quis te passar. Não conheço o Fortes a fundo a ponto de dizer que a alteração é simples de ser feita. Prefiro deixar que alguém com mais conhecimento que eu em Fortes possa lhe dizer se essa alteração é fácil ou complicada de ser realizada.

Boa tarde Flavio, Então neste caso deve ser a NF-e (modelo 55), mas em vez do emitente ser uma pessoa jurídica é uma pessoa física, logo em vez de informar o CNPJ você informa o CPF.

Boa tarde a todos, Favor atualizar os fontes e façam novos testes.

Boa tarde Élviro, Não existe DACTE Resumido, o que o seu cliente te passou é um DACTE impresso 2x em uma folha A4. Como você usa o Fortes Report me parece que isso não seja possível, mas é possível imprimir o DACTE no tamanho A5. Já quem usa o Fast Report existe a opção de imprimir o mesmo DACTE 2x em uma folha A4.

Boa tarde Vinicius, Ao reinstalar os componente você marcou a opção para apagar os arquivos antigos? Favor anexar o log de instalação. Outra coisa, não existe mais a unit pcnRetConsNFeDest.

Bom dia Flavio, A Nota Fiscal ao Consumidor Eletrônica é exatamente igual a Nota Fiscal Eletrônica. O que muda é que a NF-e o modelo é 55, já a NFC-e o modelo é 65. Outro detalhe é que o seu cliente vai ter que solicitar junto a SEFAZ o idCSC e o CSC, no Monitor tem uma tela de configuração onde você informa os valores do idCSC e CSC. Outra coisa importante, se o seu cliente é do Estado de São Paulo, ele deverá adquirir o SAT e habilitar, ai ele vai poder optar por emitir a nota NFC-e ou o CF-e (SAT). No Estado de São Paulo se o varejista optar por emitir a NFC-e ele tem que ter o SAT para usar como contingência.

Pessoal, Vamos ao item 2 da NT 2018/004 que trata sobre o cancelamento por substituição: 2 Cancelamento por Substituição O Ajuste SINIEF 07/18, que alterou o ajuste 19/16, trouxe a seguinte redação: “Cláusula décima quinta-A Na hipótese prevista no inciso I da cláusula décima segunda, o emitente poderá solicitar o cancelamento da NFC-e, desde que tenha sido emitida uma outra NFC-e em contingência para acobertar a mesma operação, em prazo não superior a 168 horas, podendo ser reduzido a critério de cada unidade federada, contado do momento em que foi concedida a Autorização de Uso da NFC-e, de que trata o inciso I da cláusula oitava.”. Sendo assim, a partir dessa Nota Técnica será possível um contribuinte cancelar uma NFC-e que foi emitida em duplicidade. Esse tipo de situação pode acontecer quando um contribuinte emite uma NFC-e (NFC-e 1), porém, por algum motivo, não obtém resposta, ficando pendente de retorno, e em seguida emite outra NFC-e (NFC-2), normalmente em contingência, para acobertar a operação. Depois é verificado que a “NFC-e 1” também foi autorizada, e sendo assim temos duas NFC-e acobertando a mesma operação. Acontecendo isso, o contribuinte poderá solicitar o cancelamento, no prazo não superior a 168 horas, da NFC-e emitida em duplicidade e que não acobertou a operação (NFC-e 1), tendo que referenciar a NFC-e que substituiu (NFC-2) aquela que está sendo cancelada. Resumindo: A segunda NFC-e foi emitida em contingência. Acobertar a mesma operação, logo não posso substituir uma nota de venda de bebida por outra de venda de cigarro. O prazo para o cancelamento por substituição é de 168 horas. O prazo para o cancelamento normal é de 30 minutos. Vejas as regras a baixo:

Bom dia, Favor anexar os XMLs de envio e de retorno.

Bom dia Daniel, Desconheço o funcionamento do programa da SEFAZ. Com relação ao componente ACBrNFe, sugiro que leia esse artigo: Como obter o XML do Fornecedor No programa exemplo do componente temos um botão que exemplifica o DistribuicaoDFe e outro a Manifestação do Destinatário. Sugiro também que leia as Notas Técnicas mencionadas no artigo.

Paulo, É preciso fazer uma cópia desses fontes cujo cancelamento funciona, fazer a atualização dos fontes, realizar novos testes, constatado o problema novamente, comparar as units que mencionei da cópia com os atuais. Com certeza alguma dessas units sofreu alguma alteração que esta provocando o erro.

Bom dia Nebrio, No campo chNFe devemos informar a chave da nota ser cancelada e no campo chNFeRef a chave da nota que vai substituir a que esta sendo cancelada. Você emitiu a nota de numero 10 mas não teve resposta da SEFAZ e acabou emitindo a nota de numero 11 para a mesma venda e esta você teve resposta da SEFAZ. Depois descobriu que a nota de numero 10 tinha sido autorizada pela SEFAZ. Como o cliente foi embora com a mercadoria e levando consigo a nota de numero 11, devemos então cancelar a nota de numero 10. Resumindo: chNFe - chave da nota de numero 10 (a ser cancelada) chNFeRef - chave da nota de numero 11 (a que vai prevalecer)

Bom dia Danillo, Resumindo, ao executar o DistribuicaoDFe as notas previamente Manifestadas (evento de manifestação do destinatário) são baixadas sem o namespace na tag <NFe>, correto? Isso ocorre com todas as notas ou só com algumas?

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

Bom dia Paulo, Você tinha dito que tinha voltando os fontes de inicio de abril e o cancelamento voltou a funcionar. Desculpa, agora esta confuso.

Bom dia a todos, Os fontes estão atualizados? Se sim, qual é o erro que esta ocorrendo e qual é a versão que estão tentando usar (1.00 ou 2.00)?