Valdir Dill

Justamente no instalador que não encontrei, rs... Veja o anexo. Esse componente não deveria estar ali para ser marcado? Obrigado.

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

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.

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.

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.

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.

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

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.

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.

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.

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!

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.

Certo, esses dados realmente não constam no XML. Mas se olharmos o manual de integração do MDFe veremos que eles não são obrigatórios (ocorr. 0-1). Tanto é que o usuário envia o MDFe sem esses dados e é aceito sem problemas. Lembre que o erro que está ocorrendo é de validação (antes de enviar) e não de rejeição. Se eu utilizar o xsd da SEFAZ, o Acbr vai validar e enviar o XML sem problemas. Se eu utilizar o .xsd openSSL o Acbr não passa na validação. Ocorre o erro relacionado a IE que mencionei no início. Não sei se ajuda. Não entendo muito de expressões regulares. Mas analisei os dois .xsd e encontrei uma única diferença entre eles, que está na linha 565. linha 565 do .xsd openSSL <xs:pattern value="[!-ÿ]{1}[ -ÿ]*[!-ÿ]{1}|[!-ÿ]{1}"/> linha 565 do .xsd SEFAZ <xs:pattern value="[!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1}"/> Então, por questão de lógica, se utilizando um arquivo .xsd o XML é validado e utilizando o outro .xsd, o XML não é validado, então imagino que a causa da validação/não validação esteja nessa linha, ou não?

Tanto faz. Eu só mandei dois arquivos porque um deles eu gerei com o .xsd da SEFAZ gravado no meu path Schemas. E o outro eu gerei quando estava o .xsd openSSL. No nome dos arquivos (no final) eu coloquei essa informação. Veja o print anexo. Ao que parece, gerar o xml ele gera ambos exatamente igual. Acho que para montar o XML ele não usa o .xsd, certo? Então se você pegar qualquer um dos arquivos e, tentar fazer a validação com o tiposGeralMDFe_v3.00-OPENSSL.xsd vai dar o erro.

Em anexo estão os arquivos. Se puder analisar. No final do nome do arquivo (após a extensão) informei qual arquivo é gerado com .xsd da SEFAZ e qual é com o .xsd openSSL. Também envio o arquivo do erro. Eu analisei os XMLs e parece que são iguais. Obs.: o erro ocorre na hora do ACBrMDFe1.Manifestos.Validar; Obrigado. 26181113971229000115580010000007151016422209-mdfe ComXsdOpenSSl.xml 26181113971229000115580010000007151016422209-mdfe ComXsdSEFAZ.xml

Sim Sim @Rafael DiasEstou ciente disso. Se você olhar bem no post vai ver que inclusive comento que o texto muda em função do servidor que retorna a rejeição. Meu pedido de ajuda seria mais para ver se algum colega já desenvolveu alguma função para capturar essa chave no texto de retorno ou então que tenha alguma dica para me passar sobre essa situação, entende? obrigado.

Boa tarde, Gostaria de apresentar uma mensagem mais transparente para o usuário quando ocorrer a rejeição de duplicidade de NFe com diferença na chave. Para isso eu precisaria capturar a chave retornada na rejeição para, por exemplo, verificar o mês/ano dessa chave, já que esse erro muitas vezes ocorre porque o usuário tenta enviar uma nota hoje, mas que já foi autorizada em mês anterior. Porém, não estou conseguindo fazer essa capturar da chave. Quando o retorno vem assim: "Duplicidade de NF-e, com diferenca na Chave de Acesso [chNFe:15180926228562000180650010000102311165735226]", seria até bastante simples, ou seja, bastaria aplicar um onlyNumber(textoRejeicao). Aí ficaria apenas a chave. Mas esse texto de retorno não é padrão. Além do texto da rejeição acima, às vezes vem "Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso [chNFe: 15181108905700000137550010000015931143828485][nRec:154000407154332]". Possivelmente tenha ainda outros textos de retorno dessa rejeição.Acredito que cada servidor traga o texto em seu layout diferente. Se alguém tiver uma dica... Obrigado.

Boa tarde, Há algum tempo tive problemas de tag de MDFe que gerava o erro de validação pelo schemas do campo do número da rua. Segundo informações o problema estava no tiposGeralMDFe_v3.00.xsd disponibilizado pela receita que não validava esse dado (nr da rua) de forma correta. A solução para contornar esse problema na época foi utilizar um .xsd modificado pelo ACbr, qual seja: renomear o tiposGeralMDFe_v3.00-OPENSSL.xsd para tiposGeralMDFe_v3.00.xsd. Aquele erro e respectiva solução estão detalhados nesse post: https://www.projetoacbr.com.br/forum/topic/44499-erro-no-n%C3%BAmero-da-rua-mdfe/ Muito bem, o que está ocorrendo agora é um erro parecido e que não aceita CPF para proprietário do veículo (tag rodo.veicTracao.prop.CNPJCPF). Ele até aceita CPF, mas aí exige a IE (rodo.veicTracao.prop.IE). Se deixar sem IE dá o erro "Element '{Http://www.portalfiscal.inf.br/mdfe}IE' is a not valid value...". Se colocar "ISENTO" na IE, aí passa, mas não estaria correto, pois CPF não é isento de IE. Ele simplsmente não tem IE. Fiz uma tentativa e deu certo: ao invés de renomear o arquivo tiposGeralMDFe_v3.00-OPENSSL.xsd, utilizei o arquivo tiposGeralMDFe_v3.00.xsd original da SEFAZ. Com esse procedimento o erro não mais ocorreu. Imagino que o problema inicial (aquele lá do outro post) que comentei acima, ou seja, que o .xsd da SEFAZ que estava com problema, que talvez tenha sido corrigido agora e, nesse caso, não precisaríamos mais do tiposGeralMDFe_v3.00-OPENSSL.xsd, correto? Obrigado.

Bom dia, Obriagado por retornar @BigWings. ...Validando conta os schemas do ACBr validou normalmente, já no validador da SEFAZ-RS acusou erro por o emitente ser CPF:... Como você faz essa validação? É nesse link -> https://www.sefaz.rs.gov.br/nfe/NFE-VAL.aspx, certo? É que fiz a validação nesse link e não deu esse erro de CPF que você mencionou. ..Você já havia conseguido fazer encerramento de MDFe sendo o emitente CPF?... Sim, em homologação, já conseguimos de vários usuários. Mas produção é o primeiro que estamos tentando com CPF. ..Pode ser apenas uma falha do validador, em todo caso tente contato com a SEFAZ... Tudo indica que sim. Mas..., enquanto não tivermos uma certeza para passar para o cliente, temos que tentar encontrar, hehe! Obrigado.

Boa tarde, Estou tendo o erro "Falha no Schema XML" no encerramento de um MDFe autorizado. Em anexo o XML que está sendo enviado e também o retorno com a rejeição. Pelo que andei lendo poderia ser algum erro em algum caractere, mas não localizei nada de errado. Alguma dica? Obrigado. 24-ped-eve.xml 24-eve.xml

Boa tarde, Consegui fazer um teste alterando e colocando 0 na posição 18. Mas, ao que parece, a situação piorou, rs. Veja o anexo a rejeição/erro gerado pelo banco. Também anexo o arquivo remessa enviado no teste. Obrigado. cb301001 gerado pelo GFIL.rem

Bom dia, Acredito outros estejam homologando que seja por 2 motivos: 1 - Esse segmento S foi incluído há bem pouco tempo no componente. Talvez outros desenvolvedores não tenham atualizado seus fontes; 2 - Pode não haver mais que 2 mensagens nas remessas. E, nesse caso, o componente gera certo, conforme o banco pede. Obrigado.

Boa tarde, Não fiz esse teste e, no momento não tenho como fazê-lo. Desenvolvi essa análise porque, conforme demonstrei, me parece que Acbr está gerando errado essa posição. Vou tentar contato com o usuário para fazer um teste. Obrigado.

Realmente, falta de atenção minha. Mil perdões. Estava tão acostumado a só clicar no menu inicial que não me dei conta que agora tem várias opções de filtragem após esse clique inicial. Como a categoria padrão que vem selecionada é "Blocks" e não "Fóruns"... Tudo certo. Obrigado.