Jump to content

click.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

click.png

click.png

Kelvin Alexandre Ferreira

Membros
  • Posts

    17
  • Joined

  • Last visited

Recent Profile Visitors

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

Kelvin Alexandre Ferreira's Achievements

Apprentice

Apprentice (3/14)

  • First Post
  • Collaborator Rare
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

13

Reputation

1

Community Answers

  1. Olá @Juliomar Marchetti. Este é o exemplo que usei em meus testes, funciona muito bem com a impressora que estou testando: Elgin I9. Porém não consigo de forma alguma passar deste teste da queda de energia da documentação. Não apresenta a mensagem, quando liga a impressora novamente termina a impressão.
  2. Bom dia! Estou tentando homologar o TEF para Cappta, e tenho tido dificuldades para reproduzir a Seq.16 do Roteiro de testes: Seq. 16 – Transação Não-Confirmada I PREPAROS - Realize uma transação com cartão de Crédito de qualquer bandeira; - Valor da transação: qualquer. PASSOS DE EXECUÇÃO 1. Realize uma venda através da Automação Comercial; 2. Selecione a forma de pagamento que acione o Gerenciador Padrão na automação; 3. Selecione a opção “Crédito” na Interface do TEF; 4. Provoque erro na impressão propositalmente desligando a impressora da energia. RESULTADOS ESPERADOS 1. A Automação deverá exibir a mensagem “Impressora Não Responde, tentar novamente?”, de maneira visível ao usuário; 2. Selecionar NÃO na Automação, que deverá enviar uma requisição de header NCN para desfazer a venda. EVIDÊNCIAS NECESSÁRIAS (RESULTADO OBTIDO) - Enviar log da transação; - Enviar print’s de todas etapas. Analisando os fontes, observei que esta mensagem existe já, porém somente para impressoras fiscais. Debugando observei que sempre termina o processo, independente de a impressora estar ligada, desligada, ou com o corte de fornecimento de energia. Alguém já passou por esta situação e conseguiu configurar de modo a aparecer a mensagem? Fiz os testes usando o programa exemplo também, sem sucesso. As Seq.17 e Seq.18 são bem parecidas, então acredito que conseguindo reproduzir a 16 já dará certo as demais. Em anexo deixei o roteiro de testes. Roteiro_de_Testes_CAPPTA_Troca_de_Arquivos_1.2.2.2.pdf
  3. Bom dia @José M. S. Junior Procurando por outros fóruns relacionados a este problema, encontrei este: Então observei que eu tinha uma cópia desta função RoundTo5 da NFSe em meus fontes. Após refatorar ela, não tem mais ocorrido o problema. Acredito que esteja solucionado este problema. Agradeço pela atenção.
  4. 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
  5. 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
  6. @José M. S. Junior Boa tarde! Chegou a analisar a possibilidade da implementação desta solução? Desde já agradeço.
  7. 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.
  8. 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.
  9. 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.
  10. 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 tenho mais deparado com este problema. Segue em anexo os arquivos para análise. ACBrBoleto.pas ACBrBancoBradesco.pas
  11. 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.
  12. 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
  13. 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
×
×
  • 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.