Túlio de Pádua

Criei um exe onde eu posso gerar ambos os comprovantes, e, deu certo, Vou continuar revisando meus códigos aqui.

Não Juliana. Mas não é a mesma coisa, pois são dois exes diferentes. Seria o mesmo que eu executar minha aplicação por duas vezes diferentes para testar os comprovantes, e isso me daria um teste positivo. O problema é quando dois tipos são gerados em sequência, o segundo sai estragado. Vou tentar gerar um exe com apenas a geração dos comprovantes e ver se ocorre o problema.

Olá, há algumas semanas após atualizar os fontes do ACBr, meu sistema passou a gerar Invalid Barcode onde deveria ser impresso o código de barras do DAMDFe em Fast Report, e também no DACTe em Fast. Se após a abertura do sistema, for gerado um DAMDFe, ele é gerado corretamente, e vai dar problema com os DACTes. Se após a abertura do sistema, for gerado um DACTe, ele é gerado corretamente, e vai dar problema com os DAMDFes. Ou seja, o segundo modelo de comprovante é o que vai ser gerado com problemas. O que já fiz: removi e reinstalei os fontes do ACBr; removi e instalei os fontes mais novos do ACBr; removi e reinstalei meu Fast Report. Nada deu certo. Não consigo achar uma lógica para isso ocorrer, se alguém já passou por algo assim, ou tenha alguma ideia.

Não. Eu criei um pacote meu, adicionando as minhas units. Ou seja, peguei meu pacote que estava com problemas, e o refiz.

Resolvi da seguinte maneira: peguei o meu pacote que gerava o erro, apaguei todos os seus fontes (dpk etc), e em seguida criei um pacote do zero, salvei, e adicionei as units que ele continha. Ao reabrir o projeto e recompilar, não deu mais erro.

log_Delphi_7_Win32.txt

Sim. O que não consigo resolver é continuar gerando essa mensagem mesmo com os pacotes do ACBr já recompilados.

Olá, estou com um problema após atualizar o ACBr, fazia uns meses desde a última atualização. A instalação do ACBr ocorre corretamente, seja manual pacote a pacote ou pelo instalador. Entretanto, ao tentar dar build na minha aplicação é gerado esse erro. Inicialmente gerava dizendo que o pacote 'ACBr_DFeComum' deveria ser recompilado. Cheguei a apagar no meu fonte o uso do componente ACBrNFe, deixando apenas o ACBrMail, e ao tentar recompilar é gerado dizendo que o 'ACBr_TCP' deve ser recompilado. Ou seja, o primeiro componente encontrado declarado na uses ele gera no erro. Já reinstalei o ACBr várias vezes, inclusive baixei hoje novamente. Ao reinstalar marco as opções de copiar as dlls e de apagar os arquivos antigos, mas na minha aplicação sempre dá esse erro. Voltando pra última versão que usava, tudo funciona corretamente. Já revisei o libray path do Delphi pa conferir se não tinha caminho inválido ou levando pra alguma pasta que pudesse causar isso, mas está tudo certo. Utilizo Delphi 7. Se alguém já passou por isso ou tem alguma sugestão pra dar, obrigado.

Percebi que o DANFCe em Fortes A4 não estava exibindo a chave de acesso para notas em contingência off-line. No local da chave era exibida a frase "NFC-E NÃO ENVIADA PARA SEFAZ". No fonte a verificação para a impressão desse label está incorreta: procedure TfrmACBrDANFCeFortesFrA4.RLLabel37BeforePrint(Sender: TObject; var Text: string; var PrintIt: Boolean); begin Text := FormatarChaveAcesso(OnlyNumber(self.FACBrNFeDANFCeFortesA4.FpNFe.infNFe.ID)); if FACBrNFeDANFCeFortesA4.FpNFe.procNFe.cStat = 0 then begin Text := ACBrStr('NFC-E NÃO ENVIADA PARA SEFAZ'); RLLabel37.Font.Color := clRed; end; end; Está verificando apenas o cStat. Adaptei para ficar conforme os demais modelos, onde verifica também o tipo de emissão: procedure TfrmACBrDANFCeFortesFrA4.RLLabel37BeforePrint(Sender: TObject; var Text: string; var PrintIt: Boolean); begin Text := FormatarChaveAcesso(OnlyNumber(self.FACBrNFeDANFCeFortesA4.FpNFe.infNFe.ID)); if (FACBrNFeDANFCeFortesA4.FpNFe.Ide.tpEmis = teNormal) and (FACBrNFeDANFCeFortesA4.FpNFe.procNFe.cStat = 0) then begin Text := ACBrStr('NFC-E NÃO ENVIADA PARA SEFAZ'); RLLabel37.Font.Color := clRed; end; end; Arquivo em anexo. ACBrDANFCeFortesFrA4.pas

Não precisaria não, esse tem o que os outros possuem, eu não removi nada nem acrescentei nada que o deixaria inconsistente. Foram alterações do aquaviário e algumas melhorias na exibição do seguro da carga também.

Precisei de criar um novo modelo de DAMDFe em Fast, exibindo melhor algumas informações do modal aquaviário. Em anexo o arquivo do relatório e o fonte pois precisei criar um CDS para exebição de algumas informações. O arquivo fr3 em vez de alterar os já existentes apenas adicionei o novo. ACBrMDFeDAMDFEFR.pas DAMDFe_Retrato_mod3.fr3

Olá, ao gerar alguns CTes cujo destinatário é do exterior, em alguns casos eu obtinha rejeição de validação do schema, pois o município e UF do endereço do destinatário estavam em branco. Após algumas pesquisas encontrei esse tópico aqui no fórum, e ele trata do mesmo problema que estou enfrentando: https://www.projetoacbr.com.br/forum/topic/38258-utilização-de-typed-constants-nos-componentes/?tab=comments#comment-251004 O tópico é antigo, de 2017 e não teve nenhum comentário. Apliquei a solução que foi proposta na época e funcionou corretamente. Declarar as constantes apenas com o nome e valor, sem a tipagem. Resolvi alterar os arquivos PCN dos documentos fiscais e colocar aqui, caso se ache a correção satisfatória eles podem ser mesclados no SVN. As constantes necessárias para determinação da cidade/uf do exterior eram desse modo: CMUN_EXTERIOR: Integer = 9999999; XMUN_EXTERIOR: String = 'EXTERIOR'; UF_EXTERIOR: String = 'EX'; Após a alteração ficaram desse modo: CMUN_EXTERIOR = 9999999; XMUN_EXTERIOR = 'EXTERIOR'; UF_EXTERIOR = 'EX'; pcnBPe.pas pcnNF3e.pas pcnNFe.pas pcteCTe.pas pmdfeMDFe.pas pnfsNFSe.pas

@Italo Jurisato Junior

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.