Túlio de Pádua
-
Total de ítens
106 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Túlio de Pádua
-
-
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.
-
1
-
-
-
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.
-
1
-
-
54 minutos atrás, BigWings disse:
É realmente necessário um arquivo fr3 separado?
Vi que teve outras alterações no fr3 além dos dados do modal aquaviário
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.-
2
-
-
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:
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
-
1
-
-
-
Uso Bematech e consigo com a configuração:
LarguraBobina = 280
MargemDireita = 0,1
MargemEsquerda = 0,1-
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.
-
3
-
-
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.
-
2
-
-
7 minutos atrás, BigWings disse:
Obrigado pelo interesse em contribuir.
Não me pareceu correto ignorar descontos e acréscimo no valor a pagar.
O mais correto seria usar a tag vNF como valor a pagar, da mesma forma como é feito no DANFE em EscPos. A soma de vProd + vServ seria o valor total.
@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.
-
2
-
-
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.
-
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:
Citarprocedure PageHeader1OnBeforePrint(Sender: TfrxComponent);
begin
ChildContingenciaCabecalho.Visible := <Identificacao."TpEmis"> = 9;
ChildContingenciaIdentificacao.Visible := ChildContingenciaCabecalho.Visible;
Memo25.Visible := not(ChildContingenciaCabecalho.Visible);
end;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.
-
1
-
-
2 minutos atrás, niloblack disse:
Fica assim, porém está faltando um campo, que seria vICMSSubstituto.
O meu gera certinho.
-
5 minutos atrás, niloblack disse:
Amigão, peguei o arquivo, substitui o outro, exclui o ACBR e Instalei novamente e a rejeição aconteceu novamente.
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.
-
1
-
-
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?
-
14 minutos atrás, Adair Filho disse:
Boa tarde PessoALL.
Estava com o mesmo problema e consegui resolver, removendo os certificados da "Autoridade Certificadora" da raiz confiavel e instalando o pacote novamente. Sem mexer o certificado do cliente.
Link que utilizei para download: http://redeicp.blob.core.windows.net/downloads/InstaladorCadeiaV2.exe
é Necessário ter o Framework 3.5 instalado no Windows 10 para instalar este pacote de Cadeia.
Até mais, espero tambem ajudar à voces!
Exato. Fazendo isso deu certo.
Testado com A1 e também com A3. Não alterei meu sistema, continua usando capicom.
Valeu pessoal.
-
1
-
1
-
-
15 minutos atrás, Gerson Crisostomo disse:
Teria como informar quais atualizações do windows fez?
Estamos com varios clientes com o mesmo erro (28/03/2019), e todos no Win10, acredito que e por causa de alguma atualização automatica feita pelo proprio Windows10.N histórico de atualizações tenho essas:
KB4483452
KB4486553
KB4489907
KB4489899Tentei removê-las mas não deu certo de voltar a funcionar não.
Invalid Barcode DAMDFe Fast
em ACBrMDFe
Postado
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.