Painel de líderes

Atualmente, a CERTIFIED, empresa que é responsável pela homologação da bandeira CIELO, está fazendo uma exigência confusa para o CliSiTEF... Eles solicitam para o Programador, que a mensagem de aprovação como por exemplo: "TRANSACAO OK" ou "APROVADO", permaneçam na tela por pelo menos 5 segundos... A solicitação faz sentido, porém é importante lembrar, que no caso de uso da CliSiTef, quem comanda as mensagens para a aplicação, é a própria CliSiTef32.dll Ou seja, ela envia os comandos 1, 2 ou 3 quando deseja enviar mensagens para a tela do Operador ou Cliente. O problema ocorre em algumas transações apenas... notei o problema na transação de débito... O mesmo ocorre, porque a CliSiTef, após exibir a mensagem "TRANSACAO OK", rapidamente envia um comando para limpar a mensagem e na sequencia envia a mensagem "Retire o Cartão" Conclusão, o problema, está na CliSiTef, e o que a CERTIFIED está nos solicitando, é que nós, modifiquemos o comportamento da CliSiTef. Veja esse tópico para uma melhor compreensão: Entrei em contato com a CERTIFIED e com a Sw.Express... e após várias trocas de e-mail, com vários envolvidos... a Sw.Express apresentou uma configuração para a CliSiTef.ini que pode resolver o problema... Habilitando a chave: [Geral] IdentificaMensagens=1 O SiTEF passa a devolver "Tipos" para as mensagens enviadas... e a mensagem de confirmação, pode ser achada com o Tipo 5005 Portanto... de posse dessa informação, apliquei as seguintes modificações no SVN

Apliquei suas modificações no SVN, obrigado pela colaboração

Pessoal, boa tarde Inseri a chamada do método no ACbrECFBematech.pas (Em anexo) , e funcionou normalmente. O método Bematech_FI_ReloadINIFile foi colocado procedure AbrePortaSerialDLL logo após LoadDLLFunctions. As alterações foram nas linhas Linhas: 339, 3330, 3353 e 3402. Espero que analisem a possibilidade de implementar na versão oficial. Obrigado. ACBrECFBematech.pas

Olá a todos, acredito que a maioria sabe de um problema que vimos a enfrentar a algum tempo ao gerar os Sped, a situação é a qual existem diversas situações na geração do arquivo, pois em casos adversos alguns dos campos de um registro gerado devemos mandar Valor, Zero ou Nulo, isso gera uma grande dor de cabeça, pois vocês desenvolvedores não tem recurso para definir como deve qual informação vai para um determinado campo. Bom como alguns já viu já tentamos até criar eventos para tentar resolver a situação quando ocorre, mas não foi o suficiente. Nesse post estou disponibilizando uma nova alternativa, e as seguintes alterações foram implementadas para tentarmos resolver o problema de uma vez por toda, mas como todas sabem, precisamos da colaboração de todos, pois não tenho ao meu alcance todas as situações existentes para afirma que tudo ocorrerá de forma a sanar 100% o problema. 1o - Você verão que existe disponível em nosso repositório, uma implementação na Unit ACBrTXT, que foi a sobrecarga da função DFill e LFill, recebendo como parâmetro uma propriedade do tipo Variant. 2o - Em anexo temos os fontes do Sped Fiscal alterado os tipo Double e Currency que existiam nas propriedades das class para atribuirmos os valores, para Variant, assim podendo agora você desenvolvedor definir através de um tratamento em seu sistema qual o conteúdo deve ir para o campo Valor (100,22), Zero (0,00) ou mesmo Nulo (Null). Sabemos que teremos um tempo de CAST, nos tipos, mas foi a unica e a menos impactante adaptação para a tentativa de sanar o problema que vem dando trabalho para alguns. Também gostaria de contar com a colaboração de todos para testar os fontes em anexo, substituindo o fonte da pasta SPED Fiscal por este em anexo, e se houver algum problema, basta excluir a pasta e baixa-la novamente do repositório, o qual não terá os novos fontes alterados até que tenhamos testes exaustivos e tenhamos total certeza que resolvemos o problema. Desde já agradeço a colaboração, e tenham um ótimo dia de trabalho. ACBrSPEDFiscal.zip

Olá, boa tarde a todos Estou testando a parte da geração dos registros do PAF-ECF, o bloco dos registros A2 estão com valores zerados. (Testado também com o demo .NET) Em uma breve olhada, no arquivo ACBrPAF.cs, linha 1016 (função PAF_Preenche_A) não está com a propriedade Valor, então a mesma é repassada zerada para a DLL. Em anexo arquivo fonte com a modificação para verificação. OBS: Arquivo anexado como TXT, pois não tenho permissão para anexar .cs; ACBrPAF.cs.txt

Perfeito convergimos para a solução. Só que da uma olhada no código da revisão 6988 verá que o meu exemplo tentou explorar que a alteração feita não surtirá efeito almejado bastando adicionar o "Epsilon" para resolver conforme seu comentário. Valeu... É bom comentarmos no fórum este tipo de assuntos enriquece os conhecimentos.

Boa tarde Favor atualizar svn e efetuar o teste novamente

Você SEMPRE precisa entrar em contato com a homologadora... afinal são eles que fazem os testes e fornecem o laudo de homologação...

Bom dia Deivide, Notei 2 coisas no seu XML. A ausência da Inscrição Estadual do Destinatário e no numero do documento consta no seu final o ponto decimal. Veja: <infOutros> <tpDoc>00</tpDoc> <nDoc>589787989898.</nDoc> <dEmi>2014-06-09</dEmi> <vDocFisc>890.00</vDocFisc> </infOutros>

Bom dia a todos, Por favor atualizem todos os fontes de todas as pastas do ACBr. Agora a pouco disponibilizei uma alteração no programa exemplo, cujo botão agora realiza o cancelamento por evento. Da pasta Schemas removi os Schemas da versão 1.04 e adicionei os da versão 2.00 Testem usando o programa exemplo.

O ACBrFramework não tem o ACBrBoleto implementado.

Atualizando o Código. Inclui um projeto de exemplo para ilustrar como iniciar um terminal e como associar um programa para o mesmo. Fiz alguns ajustes no código para facilitar iniciar um terminal novo. Aproveitem. TerMultiProtocolo.zip

Subi uma nova versão para o Link:

Muito obrigado, Realmente não havia me atentado para isso.

Decreto nº 8.264, de 5 de junho de 2014: http://www.receita.fazenda.gov.br/Legislacao/Decretos/2014/dec8264.htm "Art. 2º Nas vendas ao consumidor, a informação, nos documentos fiscais, relativa ao valor aproximado dos tributos federais, estaduais e municipais que influem na formação dos preços de mercadorias e serviços, constará de três resultados segregados para cada ente tributante, que aglutinarão as somas dos valores ou percentuais apurados em cada ente." Conforme consta no site do IBPT: https://www.ibpt.org.br/noticia/1731/Empresas-terao-ate-31-de-dezembro-de-2014-para-se-adaptar-a-Lei-de-Olho-no-Imposto "Em 90 dias, o IBPT disponibilizará todas as tabelas de carga tributária por estado e por município, de forma que as empresas poderão cumprir integralmente com as novas exigências. Para aquelas que já se adaptaram, ficará mais fácil fazer a atualização, pois bastará baixar a versão mais recente."

Boa tarde sempre que subir correções anexe somente as units alteradas! no caso só havia uma já está disponível no svn! obrigado pela colaboração

Na verdade, a princípio, você não deveria fazer esse tipo de comparação. É para isso que existem as funções como SameValue, CompareValue, IsZero na unit Math do Delphi (e Lazarus). Daniel, provavelmente o que você quer é algo mais parecido com o What Every Computer Scientist Should Know About Floating- Point Arithmetic. De forma resumida, o que acontece é que, como existem números infinitos e memória limitada, alguns números não são possíveis ser representados. Então para esses números os valores são armazenados internamente com uma aproximação. Então, dependendo do valor, temos que lidar com uma aproximação. Tem outro tópico no fórum onde teremos que lidar com um problema semelhante devido as peculiaridades dos pontos flutuantes. Inclusive com código para teste. Finalmente, essas diferenças são o motivo de muitas pessoas aconselharem a trabalhar com o tipo Currency para valores monetários ou onde não se pode perder a precisão. O tipo Currency não é armazenado como um float, mas como de ponto fixo (mais precisamente como um int64). O problema é que nesse caso, ele possui um número de dígitos significativos limitado, não sendo possível expressar nenhuma diferença entre valores fora de sua precisão (que é 4). Assim, para os valores Currency, não há diferença entre 1,12345678 ou 1,12348765.