Ir para conteúdo
  • Cadastre-se
Seja bem-vindo
Curso Dominando a NFCe - Fim do SAT em São Paulo? Esteja preparado Curso Responsável Técnico na NFe - Atenda à nova legislação Curso Dominando o ACBrBoleto - Via API ou CNAB Seja um membro do ACBr Pro e agilize seu software Participe do Discord do ACBr Regras e orientações da nossa comunidade

Túlio de Pádua

Membros
 Perfil  Explorar Conteúdo

  • Total de ítens

    114

  • Registro em

  • Última visita

 Tipo de Conteúdo 

Tudo que Túlio de Pádua postou

  1. Túlio de Pádua
    Não, na verdade não foram informados esses decimais, o valor digitado foi "1.114.313,68", apenas com dois decimais. O problema é que ao digitar o valor no campo, ele é alterado para esse número com mias decimais aí. Eu atribuo isso ao problema de precisão que o float possui, mas queria ver se tem alguma maneira de contornar mesmo.
  2. Túlio de Pádua
    No banco de dados ele está delimitado (15,10) como numérico. Isso aí é do clientdataset mesmo.
  3. Túlio de Pádua
    Pessoal, tenho um campo para informação de preço que possui 10 casas decimais. Isso no clientdataset gera um campo do tipo float. Nesse campo eu uso a máscara "###,###,##0.00########", ou seja, para a parte dos decimais exibe sempre duas casas, e quantas mais existirem até 10. Entretanto alguns valores quando digitados acabam sendo alterados numa tentativa de arredondamento pelo cds. Por exemplo, ao se digitar "1.114.313,68" ele aparece como "1.114.313,6799999999": Isso vai se repetir também no DANFe: Eu sei que valores de ponto flutuante podem gerar distorção nos valores, mas será que não existe algum outro tipo de máscara, algum componente que consegue tratar isso melhor, sei lá, pra evitar esse tipo de situação?
  4. Túlio de Pádua
    Pessoal, o DACTE para um CTE OS estava exibindo o título DACTE (Documento Auxiliar do Conhecimento de Transporte Eletrônico). Alterei para exibir DACTE OS (Documento Auxiliar do Conhecimento de Transporte Eletrônico para Outros Serviços), caso seja esse o modelo. Um ajuste pequeno, mas um cliente exigiu isso. O modelo em Fast já está correto. ACBrCTeDACTeRLRetrato.pas
  5. Túlio de Pádua
    Configuração para o Indy: Params := TIdMultiPartFormDataStream.Create; Params.AddFile('file[]', 'C:\Desenvolvimento\Teste_Indy\31200305405941000129550010008979891610757381-nfe.xml', 'application/xml'); Params.AddFormField('query', '{"boxe/File":true}', 'UTF-8', 'application/json'); IdHTTP1.Request.CustomHeaders.Clear; IdHTTP1.Request.CustomHeaders.Values['Authorization'] := 'Bearer ' + token; IdHTTP1.Request.Accept := 'application/json'; IdHTTP1.Request.ContentType := 'multipart/form-data'; Assim deverá funcionar.
  6. Túlio de Pádua
    Cara, eu também estou tentando fazer essa parte da implementação dessa API durante essa semana, e a mesma coisa, sempre tenho o retorno 500. Já testei com Indy, RestClient, e outros componentes como o ICS. Nada funciona, apenas ao testar pelo Postman.
  7. Túlio de Pádua
    Resolvido, encontrei o problema, era algo na minha aplicação mesmo.
  8. 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.
  9. Túlio de Pádua
    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.
  10. 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.
  11. Túlio de Pádua
    Não. Eu criei um pacote meu, adicionando as minhas units. Ou seja, peguei meu pacote que estava com problemas, e o refiz.
  12. Túlio de Pádua
    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.
  13. Túlio de Pádua
    log_Delphi_7_Win32.txt
  14. Túlio de Pádua
    Sim. O que não consigo resolver é continuar gerando essa mensagem mesmo com os pacotes do ACBr já recompilados.
  15. Túlio de Pádua
    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.
  16. Túlio de Pádua
    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
  17. Túlio de Pádua
    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.
  18. Túlio de Pádua
    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
  19. Túlio de Pádua
    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
  20. Túlio de Pádua
    @Italo Jurisato Junior
  21. Túlio de Pádua
    Uso Bematech e consigo com a configuração: LarguraBobina = 280 MargemDireita = 0,1 MargemEsquerda = 0,1
  22. Túlio de Pádua
    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
  23. Túlio de Pádua
    Tudo certo aqui.
  24. Túlio de Pádua
    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.
  25. Túlio de Pádua
    @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
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.