Painel de líderes

Depois de muita conversa interna e requisição de uma parte dos usuários ACBr, resolvemos estender o suporte ao Delphi 7 até Janeiro de 2017. Por que? Nossa principal motivação foi porque muita gente está pensando que quando chegasse o fim de agosto a compatibilidade com o Delphi 7 será simplesmente removida e seus aplicativos vão parar de funcionar. Infelizmente, algumas pessoas estão usando isso com um oportunismo, fazendo "terrorismo" nos usuários do projeto ACBr. Queremos que entendam que não é fácil manter a compatibilidade do projeto em tantas versões diferentes. E não estamos recebendo muita ajuda nessa área. É difícil manter compatibilidade com versões UNICODE quando nós mesmos não usamos. Mas então em janeiro meu aplicativo Delphi 7 deixará de funcionar com o ACBr? Não!!!! Seu aplicativo vai continuar funcionando. Isso é mentira, falácia, balela, uma grande prosopopéia para acalentar bovinos (conversa pra boi dormir). Então o ACBr não vai mais enviar alterações e correções de acordo com a legislação? Claro que vamos continuar enviando alterações e correções. Então não entendi... Pois é... Isso é o que a gente está tentando esclarecer... Deixa eu tentar... Como é o processo atualmente: Sempre que antes de enviar uma correção, alteração ou inclusão de nova característica, precisamos avaliar se vai funcionar no Delphi 7. Mas a maioria de nós não utiliza mais o Delphi 7. Então depois fazemos a correção, testamos na versão que utilizamos. Daí precisamos, por exemplo disparar uma máquina virtual, esperar ela carregar, copiar o novo código para a VM, fazer os testes no Delphi 7, voltar a máquina normal e só depois enviar ao SVN. Como queremos que seja o processo após janeiro de 2017: Fazemos a correção que precisamos, testamos nas versões que suportamos, e enviamos ao SVN. Mas e o Delphi 7? Os componentes até essa data vão continuar funcionando no seu Delphi 7. Mas a partir dessa data você deverá ter cautela para atualizar via SVN. Eventualmente, sem intenção, uma quebra de compatibilidade pode acontecer. Neste caso você sempre terá a opção de voltar para uma revisão que esteja funcionando. Mas se preferir poderá fazer algo: Corrigir você mesmo o problema; Encontrar algum voluntário para corrigir; Atualizar para uma IDE suportada; Quais as IDE suportadas? Lazarus ou Delphi 2009 ou posterior.

Notei falha na rotina TruncTo em alguns casos específicos... Apliquei as seguintes modificações:

Boa tarde, Juliana, Exatamente, mesmo eu alegando que o layout do canhoto não tem espaço para essas informações eles reponderam de maneira evasiva que elas precisam constar no "Recibo do Pagador". Olá, Claudiomir, Obrigado pelo retorno, também estava me preparando para fazer exatamente o que você fez. Hoje vou me reunir com o cliente para que eles dêem um ultimato ao banco, pois já estão tendo prejuízos, são 5 semanas desde o início dessa homologação sendo que esta é a terceira somente nessa indefinição do layout. Olá, Claudiomir, Obrigado pelo retorno, também estava me preparando para fazer exatamente o que você fez. Hoje vou me reunir com o cliente para Boa tarde, Juliana, O pagamento acredito que irá funcionar pelo menos via Internet banking e caixa eletrônico, e duvido muito que os funcionários dos caixas irão se atentar para esse detalhe. Por experiência, e isso é apenas minha opinião, acredito que essa falta de objetividade deles indica que podem estar escondendo uma outra motivação, que no caso acredito que seja forçar meu cliente a adotar uma modalidade de carteira com emissão pelo próprio banco, o que envolve mais taxas.

Italo, Eu já sabia, mas vamos deixar os usuários fazerem a lição de casa.

Bom dia, envie para o seu e-mail os arquivo com o erro.

Provável equívoco deste cara. Em recente reunião de algumas empresas associadas a ACATS (Associação Catarinense de Supermercados) com representantes da SEF SC - inclusive alta cúpula da área de TI - ficou claro que eles não tem a menor intenção de que isso ocorra, apesar da pressão das empresas de software e, principalmente, das grandes redes supermercadistas do estado. (Sim! Eles acham que assim diminui a chance de sonegação e que os demais estados brasileiros estão errados) De envio de informação via internet apenas foi citado que logo seremos obrigados a enviar informações de estoque na Redução Z.

@carlos_sa Pra mim esse versão caiu como uma luva, pelo jeito pra você foi igual a um sapato, e sendo assim cada um deve saber onde o sapato aperta.

Instalei a versão do Seattle sem o update ai consegui utilizar o ACBR. Obrigado pela ajuda de qualquer forma Juliomar. ar.

Não é preciso chamar a função, o próprio componente se encarrega de gerar o QRCode. Só lembre de marcar a configuração ACBrNFe1.Configuracoes.Geral.IncluirQRCodeXMLNFCe como True.

Esse XML é de NFe, modelo 55, verifique se está ajustando as configurações do componente.

O desfecho do ultimo caso ocorrido em 23/08/2016 com a Certisign foi este mesmo cenário seu, eles encaminharam um voucher para compra de um novo certificado, após nós no papel de software house solicitar um laudo onde consta que nós que apagamos o mesmo. Mas não foi uma conversa de 5 minutos, foi uma conversa longa, desgastante, e quem fica com a impressão ruim sempre é a softwarehouse, e o cliente com todo o transtorno de emissão e demais serviços paralisados no momento. Igual fiz uma reclamação na ouvidoria da empresa, onde os atendentes dela passa essa informação ao cliente, colocando a softwarehouse como a causadora do problema. Jogar a culpa no colo do próximo isso é fácil, e se for procurar mais a fundo, acho que isso até é passível de danos morais, pois estão acusando de algo sem prova do fato (evidencias);

O correto é [ICMSUFDEST001] . Informar o grupo sempre que for pra consumidor final e interestadual. Para que o bloco apareça no xml com os cálculos zerados, é necessário que informe pelo menos o campo pICMSInter e pICMSInterPart e não deve ser gerado o grupo para produtos isentos. No meu caso, meus clientes do simples devem apresentar o bloco zerado.