Jump to content

logo_acbr_paygo.png

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


Saiba mais

beneficios.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png click.png click.png

Túlio de Pádua

Membros
  • Posts

    70
  • Joined

  • Last visited

Everything posted by Túlio de Pádua

  1. O artigo aprofunda bastante, e cita num ponto algo que pode resolver parte no meu problema: "If space or speed are not as important as accuracy, use the Extended type throughout, because Delphi also uses it internally in most system functions." Usar o tipo extended realmente fornece uma precisão melhor: procedure TForm1.Button4Click(Sender: TObject); var val1: Double; val2: Extended; begin val1 := 1114313.68; val2 := 1114313.68; Memo1.Lines.Clear; Memo1.Lines.Add(FormatFloat('###,###,##0.00########', val1)); Memo1.Lines.Add(FormatFloat('###,###,##0.00########', val2)); end; O resultado da formatação acima seria: 1.114.313,6799999999 1.114.313,68 Com algum trabalho eu poderia alterar para que esse campo em tela mostrasse o valor a partir de uma variável extended, mas no ACBr como as variáveis são double, no DANFe o valor ainda sairia com a distorção. Ou seja, sem resolução total. Isso é para o valor unitário do produto em NFes, e sim, alguns usuários necessitam de toda essa quantidade de casas decimais, o que não me permite então fazer o uso de currency. E o outro problema é tentar fazer usuário leigo entender como um tipo flutuante funciona, e assim o valor que ele digita não é exibido fielmente na tela e no DANFe. De qualquer forma obrigado, eu vou manter isso assim mesmo.
  2. Bom dia Italo, eu anexei o do CTe OS e o do CTe assíncrono. CTe síncrono eu não tenho, pois consigo fazer emissão de CTe apenas para MG, que não tem webservice para síncrono ainda. 1-pro-lot ----- CTeOS.xml 311000131383853-pro-rec ----- CTe Assíncrono.xml
  3. Pessoal, fui fazer um teste com o CT-e OS, e percebi que ao transmitir a rotina de envio do ACBr está gerando uma exceção, mesmo o conhecimento sendo autorizado. Testei com o programa de exemplo e o resultado também acontece: Veja que mesmo o retorno estando correto (uso autorizado), o log trata como se houve erro de transmissão. Debugando cheguei ao trecho abaixo, na rotina TratarResposta (TCTeRecepcao.TratarResposta) // Verificar se a GTV-e foi autorizado com sucesso Result := (FCTeRetornoSincrono.cStat = 100) and (TACBrCTe(FPDFeOwner).CstatProcessado(FCTeRetornoSincrono.protCTe.cStat)); O problema é que esse result aí está ficando como falso, pois o cStat que está sendo verificado é o do lote, e o seu valor é 104. Para verificar o do CTe OS, deveria pegar o cStat do protCTe, algo assim: // Verificar se a GTV-e foi autorizado com sucesso Result := (FCTeRetornoSincrono.protCTe.cStat = 100) and (TACBrCTe(FPDFeOwner).CstatProcessado(FCTeRetornoSincrono.protCTe.cStat)); Se concordarem faço as alterações e anexo aqui, mas realmente parece um erro.
  4. Sim, aparentemente tudo certo. Obrigado.
  5. 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.
  6. No banco de dados ele está delimitado (15,10) como numérico. Isso aí é do clientdataset mesmo.
  7. 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?
  8. 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
  9. 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.
  10. 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.
  11. Resolvido, encontrei o problema, era algo na minha aplicação mesmo.
  12. Criei um exe onde eu posso gerar ambos os comprovantes, e, deu certo, Vou continuar revisando meus códigos aqui.
  13. 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.
  14. 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.
  15. Não. Eu criei um pacote meu, adicionando as minhas units. Ou seja, peguei meu pacote que estava com problemas, e o refiz.
  16. 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.
  17. Sim. O que não consigo resolver é continuar gerando essa mensagem mesmo com os pacotes do ACBr já recompilados.
  18. 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.
  19. 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
  20. 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.
  21. 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
  22. 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
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.