Jump to content

logo_acbr_paygo.png

Chegou o TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


botao_saibamais.png

beneficios.png

Curso Dominando o ACBrMonitor
Novo Módulo Soluções de Varejo
Assine o SAC ACBr em qualquer plano e tenha acesso

Saiba Mais

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba Mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

Túlio de Pádua

Membros
  • Content Count

    58
  • Joined

  • Last visited

Community Reputation

36 Excellent

1 Follower

About Túlio de Pádua

  • Rank
    Membro
  • Birthday 01/28/1988

Profile Information

  • Sexo
    Masculino
  • Localização
    Monte Carmelo - MG

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Resolvido, encontrei o problema, era algo na minha aplicação mesmo.
  2. Criei um exe onde eu posso gerar ambos os comprovantes, e, deu certo, Vou continuar revisando meus códigos aqui.
  3. 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.
  4. 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.
  5. Não. Eu criei um pacote meu, adicionando as minhas units. Ou seja, peguei meu pacote que estava com problemas, e o refiz.
  6. 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.
  7. Sim. O que não consigo resolver é continuar gerando essa mensagem mesmo com os pacotes do ACBr já recompilados.
  8. 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.
  9. 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
  10. 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.
  11. 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
  12. 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
  13. Uso Bematech e consigo com a configuração: LarguraBobina = 280 MargemDireita = 0,1 MargemEsquerda = 0,1
×
×
  • Create New...