Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

clube mobile


Cursos grátis para toda base ACBr
+ Promoção Clube Mobile para o ACBr Pro

Saiba mais

adriano santos

click.png

click.png

click.png

click.png

click.png

click.png

Kelvin Alexandre Ferreira

Membros
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

10 Good

About Kelvin Alexandre Ferreira

  • Rank
    Novato

Recent Profile Visitors

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

  1. Bom dia! Sim, recebei schemas no e-mail que foi enviado para a homologação, neste e-mail também tem um link para baixar os XMLs de exemplo. Vou anexar ambos para que possa analisar, mas pelos meus testes aqui, só consegui fazer o envio depois desta alteração na tag <TomadorServiço>. XML.rar schema_xml_nfse_v2-02.zip
  2. Bom dia Pessoal, acabei de fazer a homologação para a prefeitura de Jardim/MS e o provedor usado é este mesmo da AEG. Durante meus testes eu tive que fazer algumas alterações para ficar ok, vou colocar os fontes em anexo. @Italo Giurizzato Junior caso esteja tudo ok com as alterações, solicito que sejam inseridos no repositório para compartilhar com os demais que estejam precisando, por favor. No Cidades.ini para Jardim eu alterei o provedor para AEG, estava ISSNet. pcnLeitor.pas pnfsNFSeW_ABRASFv2.pas pnfsNFSeR.pas ACBrNFSeWebServices.pas
  3. @José M. S. Junior Boa tarde! Chegou a analisar a possibilidade da implementação desta solução? Desde já agradeço.
  4. Sim, o valor passado para o componente inicialmente vai com duas casas decimais, no caso quando passa pelo Round() tem vezes que aparece uma terceira casa decimal. Inclusive observamos que no set do campo está aplicando o RoundABNT(), o qual anteriormente era Round() e foi alterado justamente porque estava apresentando problemas no arredondamento. Sendo assim, o melhor caso seria aplicar esta alteração usando o TrunkFix() nas demais classes de bancos.
  5. Boa tarde @José M. S. Junior! Realmente é bem especifico este caso, raramente consegui reproduzir em meu ambiente, acontecia sempre na máquina do cliente, neste caso, segundo os testes, ficou constatado que a dízima era criada depois de aplicado o Round(), ou seja, mesmo que o valor já chegasse formatado, ele arredondava diferente depois de aplicado o Round(). Por conta disso que estamos propondo a alteração com o uso da função TrunkFix() do ACBr, que até então não apresentou problemas nem para este cliente em específico, nem para os demais que estão usando o mesmo sistema.
  6. Bom dia! Tudo bem Juliana, eu entendo a situação, até mesmo eu tive problemas para reproduzir aqui, eu tive que ficar testando várias vezes para reproduzir uma única vez, com o mesmo boleto, ao passo que na máquina do cliente, a cada 15 boletos gerados em média saia um com a diferença de valor. Vou aguardar a análise então do @José M. S. Junior.
  7. Bom dia! Estou a alguns meses testando a alteração que fiz nos fontes, somente tive este problema com 0,01 centavos depois do refactory que teve no ACBrBoleto, mas de qualquer forma eu atualizei meus fontes e alterei novamente o ACBrBoleto.pas (Linha 4357, trocada a função Round por TruncFix ). Não tive mais problemas com o 0,01 centavos na geração do código de barras do boleto. Entretanto, observei que mesmo assim o registro do boleto estava sendo feito com esta diferença, portanto tive que alterar também a unit ACBrBancoBradesco.pas, (linha 382, mesma troca de função). Desde então não t
  8. Bom dia, José, este caso está acontecendo de forma aleatória, com valores aleatórios, discutindo com meus colegas, acabamos por acreditar que a função de arredondamento Round() pode estar pegando algum lixo na memória. Um exemplo seria um boleto no valor de 381,40, que gerou um código de barras com final "38141", mas mesmo assim quando tentei gerar outro boleto no mesmo valor os dados saíram corretos.
  9. Bom dia Italo, após a atualização de quinta-feira, o ACBrNFeDANFCeFortesA4 está apresentando a impressão das informações da Nota Premiada 2 vezes, como mostra a imagem: Os dados estão vindo da unit ACBrDANFCeFortesFrA4, linhas 408 e 731
  10. Boa tarde! Deparei com o mesmo problema que consta aqui, debugando o código (ACBrBancoBradesco.pas), observei que a função Round() usada nas linhas 117, 476 e 759 por vezes acabava gerando este 0,01 centavo de diferença. Fiz um ajuste no código, o qual estou postando em anexo. Vale lembrar que deixei um tempo aqui gerando boletos com a alteração, antes de manifestar aqui no fórum, já que este problema ocorria em boletos aleatórios. Depois que alterei meu fonte não deu mais problemas. ACBrBancoBradesco.pas
  11. Segue em anexo a implementação de uma procedure para setar a quantidade de colunas que o cheque possui para impressão usando matricial comum, atualmente este valor é tratado por uma constante no ACBrCHQImpressoraComum.pas. Observei a existência uma propriedade pública, ColCheque, na qual criei a procedure SetColcheque primeiramente em ACBrCHQ.pas, sobrescrevendo nas classes filhas. Procurei utilizar o mesmo padrão e fluxo de trabalho existente. Isso foi necessário pois precisava alterar o valor da constante cColCheque, de forma a considerar o tamanho do canhoto também. ACBrCHQClass.pa
×
×
  • Create New...