[Sugestão P/ Mudar Literal CNPJ]

18 minutos atrás, Italo Jurisato Junior disse:

Boa tarde Valdir,

Fiz a alteração no DANFE feito em Fortes Report.

Favor atualizar os fontes e refaça os testes.

Caso você utilize o Fast Report, favor aguardar mais um pouco até fazermos a alteração e disponibilizar.

Perfeito. Fontes atualizados e está funcional no Fortes.

Obrigado.

[Sugestão P/ Mudar Literal CNPJ]

Boa tarde @Italo Jurisato Junior

Estou enviando um Danfe emitido pelo site da SEFAZ-MG com CPF para vossa análise.

Obrigado.

[Sugestão P/ Mudar Literal CNPJ]

11 minutos atrás, Italo Jurisato Junior disse:

Bom dia a todos,

Realmente faz sentido Valdir, se o emitente da NF-e pode ser tanto uma pessoa Jurídica quanto uma pessoa física, o titulo do quadro em questão deveria ser CNPJ/CPF ou mudar de CNPJ para CPJ quando o emitente for uma pessoa física.

Na Nota Técnica 2018/001 que trata sobre "Emitente Pessoa Física" não faz nenhuma referencia ao DANFE, mas seria interessante ver um DANFE emitido através site da SEFAZ cujo emitente é uma pessoa física.

Bom dia,

Ok, vou tentar ver se o usuário consegue isso. Aí repasso aqui.

Abraços.

[Sugestão P/ Mudar Literal CNPJ]

2 horas atrás, Amarildo de Matos disse:

Bom dia.. a Todos.. 

Vou passar minha experiencia sobre esse assunto.

Ja a muito tempo adotamos em todos os clientes, na impressão do Danf constar CNPJ/CPF.

mas para descargo de consciencia, fiz uma nota agora, com cpf, e entrei no site, do proprio sefaz para ver como esta la.. e la, 

ja aparece cpf quando o cliente é cpf. 

Entao acho que podera adotar ou colocar Cnpj/Cpf ou mudar na hora da impressao , Cnpj, ou Cpf quando for o caso.

Isso foi uma solicitação dos proprios clientes nessa questão.

Esse do sefaz

Nosso modelo atual de impressao

Bom dia @Amarildo de Matos

Acho que você não entendeu. Se você olhar bem no print que anexei na abertura do post, a questão não é o CNPJ/CPF do destinatário da nota e sim do emitente da nota.

Mas segundo o @Rafael Diasjá comentou, esse layout só pode ser alterado após uma norma técnica do SPED. Portanto temos que aguardar.

Dou o tópico por resolvido.

Obrigado!

[Sugestão P/ Mudar Literal CNPJ]

Boa tarde,

Tendo em conta que agora um CPF também pode emitir uma NFe, sugiro alterar o literal "CNPJ" para "CNPJ/CPF" no Danfe (destaque no anexo).

Por oportuno, onde é feita gerada a descrição desses campos. Fiz um debug mas não encontrei.

Obrigado.

[MDFe - Rejeição 611]

1 hora atrás, BigWings disse:

Dá uma olhada aqui, pode ser o caso:

http://blog.oobj.com.br/encerramento-de-mdfe/

Boa tarde,

Perfeito. Matou a charada, rs..

Obrigado

[MDFe - Rejeição 611]

Bom dia,

Vou expor uma situação que nos ocorreu...se alguém puder comentar...

Na rejeição 611 para MDFe diz que não pode haver um MDFe autorizado para mesmo emitente, mesma placa e mesma UF de descarretamento sem encerramento para que se possa enviar um novo com as mesmas informações.

Por conta disso, criamos um verificação no nosso sistema para impedir que o usuário enviasse um MDFe nessa situação. Logicamente que fazemos a verificação no BD local do sistema para verificar se há um MDFe nessa situação antes de permitir que se envie um novo.
Isso para evitar que ocorra a rejeição.

Contudo, tivemos um caso de um usuário que estava com 2 MDFes com a mesma placa, mesmo emitente, mesma UF..., e ambos não encerrados, nem na SEFAZ e tampouco no BD do nosso sistema. 
Um deles foi autorizado agora esta semana e outro em out-2017.

Muito bem, em função disso, o sistema impediu um novo MDFe por causa desses outros 2 que estavam pendentes de encerramento.
Aí o usuário fez o encerramento do MDFe autorizado esta semana, mas, aquele autorizado lá em outubro não foi possível, pois não aceita a inclusão do evento. Muito provável por causa decurso do prazo que ele já foi autorizado.

O que fizemos então?
Uma tentativa de transmitir o novo MDFe, mesmo com o MDFe de out-17 sem encerrar. Para nossa surpresa, não houve rejeição. 

Então pergunto:
Será que essa rejeição 611 só leva em conta um prazo. Por exemplo, MDFes autorizados nos últimos 30 dias?
Ou será que o servidor da receita faz uma espécie de baixa dos MDFes depois de um tempo e por isso esse MDFe de out-17 não interferiu agora?
Pesquisei um monte e não encontrei nada sobre prazo. A regra é clara, rs..., pelo menos nessa rejeição 611, não há como interpretar errado e, por essa regra, esse novo MDFe não deveria passar, mesmo que o MDFe não encerrado seja de tempos atrás..

Se alguém puder comentar a situação ou até passar alguma dica...

Obrigado.
 

[Problema na impressão da Descrição do ITEM no novo Compomente ACBrNFeDanfeNfceFR]

Boa tarde,

Fontes atualizados, teste efetuado e problema resolvido.

Obrigado.

[Problema na impressão da Descrição do ITEM no novo Compomente ACBrNFeDanfeNfceFR]

5 minutos atrás, Daniel Simoes disse:

Não é o caso de usar o novo componente exclusivo para NFCe, no Fast ?

Boa tarde,

Mas é no novo componente que o problema ocorre.

[Problema na impressão da Descrição do ITEM no novo Compomente ACBrNFeDanfeNfceFR]

Boa tarde @BigWings,

Não sei bem se o que fiz é correto, rs..Não consegui analisar ainda bem em detalhes o debug, mas só para dar um caminho para sua análise...

Eu fiz o seguinte: na llinha 1006 da ACBrNFeDANFEFRDM.pas eu incluí a linha -> else FieldByName('DescricaoProduto').AsString := StringReplace( Prod.xProd, ';', #13, [rfReplaceAll]);

Acho que o problema está nesse campo DescricaoProduto que não está sendo alimentado.

Veja se isso ajuda...

Abraços.

[Problema na impressão da Descrição do ITEM no novo Compomente ACBrNFeDanfeNfceFR]

Boa tarde,

Também estou com esse problema. Tanto utilizando o DANFeNFCe3_50.fr3, como o DANFeNFCeA4.fr3.

Obrigado.

[Imprimir Itens - NFCe]

Boa noite,

Tudo certo. Instalado, testado e funcionando.

Obrigado.

[Imprimir Itens - NFCe]

19 minutos atrás, Rafael Dias disse:

Você fez a reinstalação usando o instalador, senão não vai aparecer mesmo.

Justamente no instalador que não encontrei, rs...

Veja o anexo. Esse componente não deveria estar ali para ser marcado?

Obrigado.

[Imprimir Itens - NFCe]

1 hora atrás, BigWings disse:

Faça atualização dos fontes.

Para impressão NFCe em FastReport agora deve ser usado o novo componente ACBrNFeDANFCeFR.

 

Boa noite,

Atualizei os fontes, mas não achei esse componente novo.

 

[Imprimir Itens - NFCe]

16 minutos atrás, Italo Jurisato Junior disse:

Valdir,

Pelo que entendi você esta se referindo a impressão do DANFE da NFC-e, correto?

E a impressão usando o componente EscPos do DANFE, já tentou usar?

Se sim, qual foi o resultado?

Sim, é para NFCe.

Sim, eu já uso a opção ESCPOS. 

Mas creio que não estou conseguindo me fazer entender.
Veja bem, até antes desse refatoramento eu atribuía o .ImprimirItens assim:  ACBrNFCe1.DANFE.ImprimirItens := true/false.
E também ACBrNFCe1.DANFE := ACBrNFeDANFCeFortes1 ou ACBrNFeDANFeESCPOS1 ou ACBrNFeDANFEFR1.

Com essa atualização que foi promovida pelo Acbr, isso não é mais possível. Agora temos que atribuir o .ImprimeItens diretamente ao componente de impressão, correto?

Então, como que estou fazendo:
a) ACBrNFeDANFCeFortes1.ImprimeItens := true/false;
b) ACBrNFeDANFeESCPOS1.ImprimeItens := true/false;
c) ACBrNFeDANFEFR.ImprimeItens := true/false;

Itens "a" e "b", tudo certo.
Item "c", não aceita. Esse componente não tem essa propriedade ImprimeItens,.                
Ao que parece o componente de impressão para Fast Report não tem a opção de configurar para imprimir ou não os itens.
Minha dúvida é se realmente é assim, ou se foi esquecida esse propriedade nesse componente agora quando dessa refatoração.

Entendeu?

Obrigado.

[Imprimir Itens - NFCe]

1 minuto atrás, Italo Jurisato Junior disse:

Boa tarde Valdir,

Eu não entendi, qual que você utiliza, o Fortes ou o Fast Report?

Ambos.

Dependendo do modelo/marca de impressora e também do tipo da bobina, a impressão fica melhor com Fast. Em outras, a impressão fica melhor com Fortes.

Obrigado.

[Imprimir Itens - NFCe]

31 minutos atrás, Italo Jurisato Junior disse:

Valdir,

As propriedades que chamavam ImprimirXYZ agora se chamam ImprimeXYZ, você fez essa alteração na linha que você postou?

Sim, isso eu havia entendido.

Mas no caso do TACBrNFeDANFeRL eu estava mesmo "comendo bola", rs. Não tinha configurado corretamente. Agora consegui.

Porém, no caso do TACBrNFeDANFEFR , realmente não está aceitando. Veja o print anexo.

É para ser assim mesmo, ou seja, o Fast não tem essa opção?

Obrigado.

 

[Imprimir Itens - NFCe]

5 minutos atrás, Italo Jurisato Junior disse:

Bom dia Valdir,

Nesta postagem tem uma tabela das propriedades que tiveram os seus nomes alterados.

Bom dia,

Obrigado por responder Italo. No caso do ESCPOS, tudo bem.

Mas minha dúvida é no caso do TACBrNFeDANFeRL e TACBrNFeDANFEFR não haverá mais essa opção de imprimir ou não os itens?

Nesses dois está disponível essa propriedade.

Obrigado.

 

[Imprimir Itens - NFCe]

Bom dia,

Acabei de atualizar os fontes e percebi que várias nomenclaturas foram alteradas nas propriedades. A maioria estou encontrando o novo nome, mas a ACBrNFeDANFCeFortes1.ImprimirItens não consegui localizar.

Alguma dica?

Obrigado.

[Problema SEFAZ MT]

1 minuto atrás, Amarildo de Matos disse:

é luis.. isso é um grande problema. e o que voce pensa em fazer?

E o ENCAT ainda quer punir as softwares houses por rejeições e perdas de prazo de reenvios em contingência...Pode isso? Hehe!

[Rejeição NFe - Duplicidade com Diferença na Chave]

7 minutos atrás, Italo Jurisato Junior disse:

Bom dia a todos,

Valdir, se aparece a mensagem de duplicidade ou duplicidade com diferença na chave, isso significa que a sua aplicação deixa o usuário enviar a mesma nota mais de uma vez.

E isso esta errado.

Quando o usuário clicar no botão de Envio a sua aplicação marca a nota como enviada (no banco de dados) e só remove essa marcação caso a nota venha a ser rejeitada, pois se a nota foi rejeitada ela é passível de correção e um novo envio.

Mas e se ocorreu algum erro de conexão ao enviar?

Simples, a sua aplicação precisa ter um botão de Consulta, este por sua vez vai carregar o XML assinado da nota que foi enviada e que ocorreu erro de conexão e em seguida o método Consultar é executado.

Se ocorreu erro de conexão (timeout por exemplo) não sabemos se ele ocorreu durante o envio ou retorno, concorda?

Pois bem ao realizar a consulta se o problema foi no retorno teremos o status da nota, que pode ser Autorizada, Denegada ou Rejeitada.

Se foi rejeitada devemos remover a marcação de enviado para que o usuário possa fazer as devidas correções e enviar novamente.

Agora se a nota foi Autorizada ou Denegada o XML que esta assinado será atualizado recebendo o protocolo de autorização ou  denegação.

Pode também ser retornado o status 217 que diz que a nota não consta na base de dados.

Neste caso esta claro que o erro de conexão ocorreu no envio, ai sim, devemos enviar a nota novamente.

Valdir, se você seguir essas instruções acima, vai notar que nunca mais terá problemas de Duplicidade de notas.

Espero ter ajudado.

Bom dia,

Obrigado pelas dicas Italo.

Eu concordo com tudo que você colocou, mas na prática a coisa é um pouco mais complexa do que isso. Sim, com certeza se suas dicas forem colocadas em prática, vai diminuir as rejeições por duplicidade, mas a palavra "nunca", está bem longe de ser uma realidade, hehe!

Veja bem, usuário é capaz de fazer chover quando ele está sozinho operando um sistema.

Tem usuário que reinicia um banco de dados do zero e não atualiza a última nota enviada. Tem usuário que metade das notas ele envia, metade é o contador que envia pelo emissor gratuito. Tem usuário que envia a nota em um mês e só no mês seguinte faz a conciliação. Aí a chave da nota já é outra por causa do mês e a consulta daquela nota retorna como nota não enviada. Enfim, existem várias situações como essas que acabem gerando duplicidade, por mais que façamos um controle.

Mas repito, suas dicas são importantes e, com certeza vão me ajudar a diminuir essas rejeições.

Obrigado.

 

[Rejeição NFe - Duplicidade com Diferença na Chave]

Bom dia,

Criei a função abaixo que resolve o meu problema. Pelo menos enquanto algum servidor não criar um texto de retorno novo para esse erro, hehe! Compartilho a função para que talvez possa ajudar alguém na mesma situação.

function EhErroDuplicidadeNota(VErro : String; Var VChaveDuplicComDifChave : String) : boolean;
begin
 {formas que essa rejeição retorna:
 1 - "Erro: Nota(s) não confirmadas: XXX->539-Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso
     [chNFe: 15181108905700000137550010000015931143828485][nRec:154000407154332]". XXX é o nr da nota.
 2 - "Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso [chNFe:15180926228562000180650010000102311165735226]";
 3 - "Duplicidade de NF-e, com diferenca na Chave de Acesso. [41180513971229000115650010000000791477402492] [nRec:918000000409987]".}

 result := true;

 VErro := upperCase(TFuncPubl.TiraAcentos(VErro));

 if pos('DUPLICIDADE DE NF-E', VErro) = 0 then exit(false); //se não é duplicidade

 if pos('COM DIFERENCA NA CHAVE DE ACESSO', VErro) = 0 then exit(true); //vai voltar como true pqe é duplicidade. Só não é com difereça de chave.

 VChaveDuplicComDifChave := emptyStr;
 if pos('[NREC:', VErro) > 0 then //retornos 1 ou 3
  begin
   if pos('[CHNFE: ', VErro) > 0 then VChaveDuplicComDifChave := copy(VErro, pos('[CHNFE: ', VErro) + length('[CHNFE: '), 44)
   else VChaveDuplicComDifChave := copy(VErro, pos('[', VErro) + length('['), 44);
  end
 else
  VChaveDuplicComDifChave := copy(VErro, pos('[CHNFE:', VErro) + length('[CHNFE:'), 44); //retorno 2

 if VChaveDuplicComDifChave = emptyStr then exit(true); //vai voltar como true pqe é duplicidade. Só não conseguiu capturar a chave.

 if (VChaveDuplicComDifChave <> emptyStr) and (not ValidaChaveDocEletr(VChaveDuplicComDifChave)) then VChaveDuplicComDifChave := emptyStr; //se retorno não for exatamente como nas 3 opções acima, o copy não retornaria algo, mas seria uma chave não válida.
end;

Abraços.

 

[MDFe - Rejeição se Não informar IE do proprietário]

2 horas atrás, Rafael Dias disse:

você não prestou atenção mais eu ja tinha feito esta modificação e coloquei em anexo no meu ultimo post.

Sobre este erro eu tava lendo e a LibXml2 tem problemas com expressões regulares por isso temos que alterar a linha 565 e este erro da linha 401 deve ser pelo mesmo motivo vou enviar o arquivo alterado para o repositório.

Boa tarde,

Ah certo, agora entendi.

Na verdade quando vi seu anexo tiposGeralMDFe_v3.00-OPENSSL.rar imaginei que você estaria me sugerindo para fazer o mesmo teste  com o mesmo arquivo que eu já tinha feito várias vezes e comentei nas idas e vindas das minhas respostas deste post. Como você não mencionou que esse seria um tiposGeralMDFe_v3.00-OPENSSL.xsd modificado, entendi que não teria sentido fazer o teste novamente, hehe!

Mas acho que agora está tudo esclarecido e, com seu upload, também vai ficar tudo corrigido.

Obrigado.

[MDFe - Rejeição se Não informar IE do proprietário]

Bom dia,

Por favor ignore meu comentário sobre a possibilidade da causa do erro estar no fato da diferença na linha 565 dos arquivos .xsd (SEFAZ e openSSL).
Fiz mais testes e descobri o ponto que gera o erro de validação.
Está linha 401 dos dois arquivos .xsd.

No arquivo tiposGeralMDFe_v3.00.xsd da SEFAZ, o original, a linha 401 está assim:
<xs:pattern value="[0-9]{0,14}|ISENTO|PR[0-9]{4,8}"/> 

No arquivo tiposGeralMDFe_v3.00-OPENSSL.xsd modificado pelo Acbr, a linha 401 está assim:
<xs:pattern value="ISENTO|[0-9]{0,14}|PR[0-9]{4,8}"/>

Fiz um teste e mudei a linha 401 no arquivo openSSL, deixando-a igual a linha 401 do .xsd da SEFAZ e, com isso, não ocorreu mais o erro. Então, com certeza o ponto de disparo do erro é nessa linha.
Só não sei porque, hehe! Pelo que notei, há apenas uma inversão da ordem na posição do "ISENTO", mas como comentei antes não entendo muito de ER. 

Obrigado!

[MDFe - Rejeição se Não informar IE do proprietário]

5 horas atrás, Rafael Dias disse:

So complementando os XSD não tem nada haver com a geração eles são usados apenas para validação é estranho o que você relata visto que os dois XSD são iguais nesta parte da validação, ou seja idependente de qual XSD você usa para validar não muda a forma que gera o XML, o no caso o XML gerado pelo componente esta valido.

Me responde qual método de assinatura esta usando ? xsLibXml2 ?

Teste com este XSD tiposGeralMDFe_v3.00-OPENSSL.rar

Bom dia,

Sim, como comentei no post inicial, é justamente com o arquivo tiposGeralMDFe_v3.00-OPENSSL.xsd que está ocorrendo o erro. Basta você pegar o XML que envie e testar a validação. 

Usando tiposGeralMDFe_v3.00-OPENSSL.xsd dá erro. Usando tiposGeralMDFe_v3.00.xsd, não dá erro.

Sim, uso xsLibXml2.

Obrigado.