Kelvin Alexandre Ferreira

Bom dia @Juliomar Marchetti, não somos da mesma empresa, ao que parece o @HelioNeto está passando exatamente pelo mesmo problema. Também cheguei a ver os fontes do ACBRNFSeX, aparentemente vai ser necessário um tratamento lá também. Estes tempos eu entrei em contato com o provedor daqui de Campo Grande MS para uma outra solicitação e eles avisaram mesmo que não estavam mais dando suporte para a prefeitura daqui. Se ficou com a SGI vai ser complicado fazermos a solicitação para a inserção da TAG, vou tentar só por desencargo de consciência. Neste caso, acredito que se não der certo a solução será criar uma nova unit considerando o layout de Campo Grande MS como próprio. Também temos planos aqui de alterar para o novo componente.

Boa tarde @Italo Giurizzato Junior! Após um build recente com o ACBRNFSe atualizado, obtive problemas para processar as notas para Campo Grande - MS, relacionado a alteração sugerida pelo @Daivid neste tópico: Queria uma sugestão de como poderia contornar este problema e contribuir também com o projeto. No meu caso provisoriamente eu comentei a linha 165 da unit pnfsNFSeW_ISSDSF. Estou em dúvidas quanto a colocar um if validando se tem alguma informação em NFSe.ConstrucaoCivil.CodigoMunicipioObra e adicionar a tag somente se tiver informação, porém não o fiz porque observei que Gerador.wCampo recebe um parâmetro informando a ocorrência 1, imprimindo a tag mesmo se ela estiver vazia. Acredito que se alterar vai impactar em outros usuários, pois pelo que vi é obrigatória. Tem algo que posso fazer neste sentido? Abaixo tem o link do manual da NFSe do site da prefeitura. Não consta a tag InscricaoMunicipalObra: https://nfse.pmcg.ms.gov.br/NotaFiscal/cgrPDF/ManualNFSeWebService.pdf

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.

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

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.

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

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

@José M. S. Junior Boa tarde! Chegou a analisar a possibilidade da implementação desta solução? Desde já agradeço.

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.

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.

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.

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

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.

Bom dia Italo, Testes realizados, está tudo ok, muito obrigado.

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

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

Deu certo.

Obrigado pelo retorno, vou fazer os testes.

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.pas ACBrCHQImpressoraComum.pas