Italo Giurizzato Junior

Boa tarde Leandro, Desfaça essa alteração, atualiza os fontes e faça novos testes. Note que fiz uma alteração no arquivo INI do provedor.

Boa tarde Celso, Muito obrigado pela colaboração, fiz uma pequena alteração, favor atualizar e testar.

Boa tarde, Em qual momento ocorre o Timeout? É no envio, na consulta a situação ou na consulta do lote?

Boa tarde Aranda, O componente só gera o XML do evento e assina no momento do seu envio.

Boa tarde, O valor do pedágio vai compor o valor da prestação, ou seja, o valor do frete? Se sim, existe no CT-e um grupo chamado: Comp que pode ocorrer "N" vezes no XML. Esse grupo possui dois campos: xNome e vComp. Em xNome você atribuir "Pedagio" e em vComp o valor do mesmo. Simples assim.

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.