Túlio de Pádua

Uso Bematech e consigo com a configuração: LarguraBobina = 280 MargemDireita = 0,1 MargemEsquerda = 0,1

Olá, percebi que o modelo de DANFCe em FortesReport bobina está com a margem direita incorreta. Isso faz com que haja uma quebra de linha onde não deveria. Anexei duas imagens, a 'DANFCe_Antes' foi impressa com o ACBr atual e mostra esse problema, se observarem no grupo dos itens, há um espaço à direita não utilizado. A imagem 'DANFCe_Depois' foi impressa após eu fazer a correção. Observem que o a linha do item é impressa até o final. Apenas alterei o arquivo dfm desse relatório (ACBrDANFCeFortesFr) colocando a RightMargin da band 'rlbDetItem' igual a zero, antes estava com valor oito. Se alguém puder validar e incorporar nos fontes. Não fiz alteração para Lazarus pois não trabalho com ele, se alguém puder implementar e testar, é uma mudança simples. Grato. ACBrDANFCeFortesFr.dfm

Tudo certo aqui.

Aqui em MG mesmo problema. Só consegui autorizar no ambiente de contingência da SVC-RS. Esse parece ser o único, ou um dos únicos que já implementou essa versão em homologação.

@BigWings, erro meu, você está certo. Eu citei que havia feito conforme o DANFCe em EscPos mas está diferente. O EscPos gera o valor a pagar com o vNF. Alterei para ficar igual. A ideia é justamente essa, deixar igual ao EscPos, que busca o valor da tag, em vez de fazer conta e correr risco de deixar a soma diferente do XML. Anexei com essa alteração. Obrigado. ACBrNFeDANFEFRDM.pas

Olá, realizei algumas alterações no layout do DANFCe bobina desenvolvido em Fast. Renomeei o arquivo para "DANFeNFCe5_00.fr3", o adaptando conforme o Manual de Padrões versão 5.0, o último liberado pelo Encat. Foram necessárias algumas alterações na unit ACBrNFeDANFEFRDM.pas também. No seguintes locais: 1) Na geração do valor a pagar, conforme: Antes: FieldByName('ValorApagar').AsFloat := VProd - VDesc - vICMSDeson + VOutro; Agora: FieldByName('ValorApagar').AsFloat := VProd + FNFe.Total.ISSQNtot.vServ; Deixei como já está no modelo EscPos, que imagino ser o mais usado e consequentemente o mais apurado. Não concordo com fazer cálculos na impressão do Danfe, os cálculos já devem ser feitos ao gerar o XML. 2) No preenchimento do nome do cliente: Antes: if EstaVazio(FieldByName('CNPJCPF').AsString) then FieldByName('Consumidor').AsString := ACBrStr('CONSUMIDOR NÃO IDENTIFICADO') else FieldByName('Consumidor').AsString := IfThen(Length(CNPJCPF) = 11, 'CPF: ', 'CNPJ: ') + Trim(FieldByName('CNPJCPF').AsString) + ' ' + trim(FieldByName('XNome').AsString); Agora: if EstaVazio(FieldByName('CNPJCPF').AsString) then FieldByName('Consumidor').AsString := ACBrStr('CONSUMIDOR NÃO IDENTIFICADO') else FieldByName('Consumidor').AsString := IfThen(Length(CNPJCPF) = 11, 'CONSUMIDOR CPF: ', 'CONSUMIDOR CNPJ: ') + Trim(FieldByName('CNPJCPF').AsString) + ' ' + trim(FieldByName('XNome').AsString); Apenas inseri o prefixo "CONSUMIDOR" antes do CPF ou do CNPJ do cliente. 3) Na geração do texto da área de mensagem fiscal: Antes: if (FNFe.Ide.Modelo = 65) then begin FieldByName('DEmi').AsString := FormatDateTimeBr(FNFe.Ide.DEmi); if FNFe.Ide.TpAmb = taHomologacao then FieldByName('MensagemFiscal').AsString := ACBrStr('EMITIDA EM AMBIENTE DE HOMOLOGAÇÃO - SEM VALOR FISCAL') else begin if (FNFe.Ide.tpEmis <> teNormal) and EstaVazio(FNFe.procNFe.nProt) then FieldByName('MensagemFiscal').AsString := ACBrStr('EMITIDA EM CONTINGÊNCIA'+LineBreak+'Pendente de autorização') else FieldByName('MensagemFiscal').AsString := ACBrStr('ÁREA DE MENSAGEM FISCAL'); end; . . . . Agora: if (FNFe.Ide.Modelo = 65) then begin FieldByName('DEmi').AsString := FormatDateTimeBr(FNFe.Ide.DEmi); if (FNFe.Ide.tpEmis <> teNormal) and EstaVazio(FNFe.procNFe.nProt) then FieldByName('MensagemFiscal').AsString := ACBrStr('EMITIDA EM CONTINGÊNCIA'+LineBreak+'Pendente de autorização'); if FNFe.Ide.TpAmb = taHomologacao then FieldByName('MensagemFiscal').AsString := FieldByName('MensagemFiscal').AsString+LineBreak+LineBreak+ACBrStr('EMITIDA EM AMBIENTE DE HOMOLOGAÇÃO - SEM VALOR FISCAL'); if EstaVazio(FieldByName('MensagemFiscal').AsString) then FieldByName('MensagemFiscal').AsString := ACBrStr('ÁREA DE MENSAGEM FISCAL'); . . . . Alterei para que a frase "EMITIDA EM CONTINGÊNCIA Pendente de autorização" seja gerada sempre que a NFCe estiver pendente, independente do ambiente utilizado (produção ou homologação) Se alguém puder validar e encaminhar ao repositório. ACBrNFeDANFEFRDM.pas DANFeNFCe5_00.fr3

Fui implementar o modelo de DANFCe em Fast DANFeNFCe4_20, e obtive o erro abaixo ao tentar visualizá-lo: "Script Error at 22:9: Undeclared identifier: 'Memo25' " Não sei se alguém está utilizando esse layout, mas o erro se deve ao trecho abaixo no fonte desse modelo: A última linha se refere a um componente que não existe, "Memo25". Remvi a linha, fiz algumas impressões e não constatei algum componente que correspondesse (talvez o componente existisse mas apenas o nome estava errado). Enfim, estou anexando o arquivo, se alguém puder dar uma olhada e subir. Grato. DANFeNFCe4_20.fr3

O meu gera certinho. 31190415641331000188550010000171861000158533-nfe.xml

Ué, estranho. As tags foram geradas no XML zeradas? Eu acabei de emitir uma aqui agora, e deu certo, foi autorizada. Em MG.

Pra quem quiser fazer seus testes, ou se alguém do ACBr quiser implementar essas alterações no repositório, anexei aqui a unit que foi alterada. Testei em MG, onde são exigidas essas tags e funcionou corretamente. Testei em MT, estado que não vai exigir essas tags, e sua informação zerada no XML não causou prejuízo nenhum também. pcnNFeW.pas

Ontem final da tarde a Sefaz/MG parece ter consertado esse problema. Se enviar o XML dentro dos requisitos (CST 060 e não consumidor final) continua dando a rejeição 938. Mas ao gerar as tags zeradas (alterei meu fonte do ACBr pra isso), a Nfe foi aceita corretamente. Ou seja, me parece que o fonte do ACBr deverá ser alterado retirando essas regras, e o programador deverá colocar no seu ERP essas validações para gerar quando necessário. Mais alguém conseguiu sucesso e concorda com essa minha suposição?

Exato. Fazendo isso deu certo. Testado com A1 e também com A3. Não alterei meu sistema, continua usando capicom. Valeu pessoal.

N histórico de atualizações tenho essas: KB4483452 KB4486553 KB4489907 KB4489899 Tentei removê-las mas não deu certo de voltar a funcionar não.

Sim, colocando isso aí dá erro 12175. OpenSSL funciona com A1 e não com A3. Tá complicado achar uma solução que atenda tudo.

Verdade, em contingência SVC aqui em MG funciona sem erro.

Aqui A1 também. Atualizei meu Windows agora, e passou a dar aqui também. Depois do almoço vou ver se tem relação.

Aqui também alguns clientes estão reportando isso. Aqui na empresa tudo normal. Fiz um teste com o demo do ACBr nesses clientes e o erro não ocorreu quando selecionei a lib openssl em vez da capicom.

@Juliomar Marchetti, entendo. Não trabalhamos com o lazarus, então vou deixar pra ir arrumando no meu fonte aqui mesmo. Obrigado.

@Italo Jurisato Junior, acha possível integrar isso ao repositório do Acbr?

Boa tarde, devido à mudança para que produtores rurais possam fazer emissão de NF-e também, passamos a ter um problema com as casas decimais do valor unitário no DANFe, pois em alguns casos o preço unitário sai com até 10 casas decimais. Nesses casos pode haver um corte na impressão desse valor. Anexei duas imagens, uma DANFe_Antes e outra DANFe_Depois, mostrando a comparação de um ajuste que fiz no modelo desse DANFe. Alterei o modelo paisagem pois ele tem maior espaço para alterações, aumentando o campo de valor unitário e diminuindo o de descrição do produto. Anexei também o arquivo dfm caso a equipe do ACBr aprove e queira mesclar minhas alterações. Grato. ACBrNFeDANFeRLPaisagem.dfm

Apenas para conhecimento, pois os fontes do Acbr já foram adequados para fazer a leitura dos retornos de forma a não gerar erro, mas após muitos e-mails a Sefaz/MG corrigiu os seus retornos, deixando-os de forma adequada. Para fins de comparação: Abaixo é o retorno que estava incorreto: <?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"> <S:Body> <ns0:nfeResultMsg xmlns:ns0="http://www.portalfiscal.inf.br/nfe/wsdl/NFeStatusServico4"> <retConsStatServ xmlns="http://www.portalfiscal.inf.br/nfe" versao="4.00"> <tpAmb>1</tpAmb> <verAplic>W-1.0.38</verAplic> <cStat>282</cStat> <xMotivo>Rejeição: Certificado Transmissor sem CNPJ</xMotivo> <cUF>31</cUF> <dhRecbto>2019-02-03T17:39:27-02:00</dhRecbto> <tMed>0</tMed> <dhRetorno>2019-02-03T17:39:27-02:00</dhRetorno> </retConsStatServ> </ns0:nfeResultMsg> </S:Body> </S:Envelope> Esse é o retorno mais recente: <?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"> <S:Body> <nfeResultMsg xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/NFeStatusServico4"> <retConsStatServ xmlns="http://www.portalfiscal.inf.br/nfe" versao="4.00"> <tpAmb>1</tpAmb> <verAplic>W-1.1.25</verAplic> <cStat>282</cStat> <xMotivo>Rejeição: Certificado Transmissor sem CNPJ</xMotivo> <cUF>31</cUF> <dhRecbto>2019-02-27T19:19:53-03:00</dhRecbto> <tMed>0</tMed> <dhRetorno>2019-02-27T19:19:53-03:00</dhRetorno> </retConsStatServ> </nfeResultMsg> </S:Body> </S:Envelope> Percebam que na terceira linha a tag "nfeResultMsg" já aparece correta, como deveria ser.

Pessoal bom dia, parece que esse problema do retorno foi resolvido, recebi a resposta da Sefaz MG hoje. Não tive tempo de testar ainda, mas pelo menos eles reconheceram o erro:

Apenas para atualização, a Sefaz MG me respondeu, mas encaminhou para outro setor pedindo mais prazo: " Ref. a mensagem: 284.822 Senhor Túlio de Pádua Batista Silva, bom dia! Conforme parecer da consultoria responsável foi aberto um chamado junto a STI para averiguação. Tão logo obtivermos retorno, faremos novo contato por esse mesmo canal de atendimento. Colocamo-nos à disposição para quaisquer outros esclarecimentos que se fizerem necessários. "

@Fernando Loiola, desculpe a demora, mas voltei a ver sobre a NFCe apenas essa semana. Com essa alteração sua, realmente consegui obter sucesso na verificação do status de serviço. Usei extra oficialmente, pois certamente trata-se de erro na Sefaz ao retornar um XML que está fora do padrão. Mas usei para testar meus envios. Com isso e também com as alterações que fiz e sugeri nesse post (Webservice NFC-e MG incorreto), consegui obter autorização das notas em homologação. Além disso, também com muita paciência, pois o ambiente está super instável.

Boa noite, percebi que no arquivo "ACBrNFeServicos.ini", os endereços da seção [NFCe_MG_P] e [NFCe_MG_H] estão incorretos em relação ao campo URL-ConsultaNFCe_2.00. Os valores corretos podem ser verificados aqui. Valores atuais: [NFCe_MG_P] URL-ConsultaNFCe_2.00=https://nfce.fazenda.mg.gov.br/portalnfce [NFCe_MG_H] URL-ConsultaNFCe_2.00=https://hnfce.fazenda.mg.gov.br/portalnfce Valores corretos: [NFCe_MG_P] URL-ConsultaNFCe_2.00=http://nfce.fazenda.mg.gov.br/portalnfce [NFCe_MG_H] URL-ConsultaNFCe_2.00=http://hnfce.fazenda.mg.gov.br/portalnfce A diferença é que não se trata de um endereço seguro (https). Da forma que está no ACBr atualmente, as NFC-es estão sendo rejeitadas pelo motivo abaixo: 878 - Endereço do site da UF da Consulta por chave de acesso diverge do previsto. Fiz essa alteração aqui nos meus fontes e a rejeição acima passou a não ocorrer mais. O arquivo corrigido está anexado, se alguém puder confirmar e implementar. ACBrNFeServicos.ini