strago

Corrigindo um engano .... Na verdade o que não pode ser utilizado junto com o fetch on demand é "Auto Detect and recover broken connection", porque ele força o fetch mode para fmAll.

Para limitar o fetch de uma tabela usando fdquery, você deve ir em "options-> Fetch options -> Rowset size: 50" e trocar o 50 pelo numero de registros que você quer por fetch. Alguns detalhes que você deve levar em consideração são: O "Fetch mode" deve estar setado para "fmOnDemand" Não pode ser usado junto com Keep Connection Alive do FDConnection. Para campos lookup eu não cheguei a testar o fetch, mas ja fiz o teste com tabelas gigantes e o fetch on demand funciona direitinho.

os pacotes do DANFE RL sempre deram problemas pra serem instalados pelo instalador. Sempre precisei instala-los manualmente.

o problema Italo, é que a SEFAZ, assim como você , não se preocuparam com o fato que as regras do negócio de fato, ou seja, o que o comerciante no geral aplica em sua empresa não pode ser restringido dessa forma. Se o dono da padaria deseja assumir o risco de aceitar um cheque de 100 para uma compra de 90 e devolver 10 de troco (NÃO ESPECIFIQUEI A ESPECIE), é uma opção do dono da padaria e não da SEFAZ. Isso pode acarretar inúmeros problemas... 1 - Mudo minha regras de negócio para me adequar a emissão de um documento fiscal. Resposta : Impraticável em muitos casos, EX: Como já havia dito em um outro tópico, algumas empresas operam fornecendo aos seus clientes, recursos como recebimento de cheques de terceiros (que já vem em um valor definido e muito pouco provável que no mesmo valor da compra), carta frete (que é a somatória de dois valores, Adiantamento e Saldo, onde, o Adiantamento geralmente é uma soma elevada e o troco pode ser parte em dinheiro, parte em cheque, ou até mesmo em vale haver (alguns clientes fixos pedem essa modalidade) e o Saldo tem valor variavel pq se aplicam a ele, descontos de estadia, quebra, etc. Então, no exemplo do JOSÉ MOTORISTA chegar em um posto de estrada com um "CHEQUE de R$ 2000.00" de um posto (recebido de troco por trocar uma carta frete em outro posto) e vai pagar uma abastecida de R$ 500,00, o posto deve informar que recebeu um cheque de R$2000,00 e deu R$ 1500,00 de troco, se isso não constar na nota, o patrão do JOSÉ MOTORISTA, vai cobra-lo dos R$1500,00 de troco que não foram destacados na nota. pois nela irá constar o pagamento de uma abastecida de R$ 500,00 com um cheque de R$ 500,00 ou pior, em dinheiro. 2 - Não mudo as regras de negocio, portante faço algumas "gambiarras" para emissão da nota. Resposta : o Problema vai começar a estourar pra todo lado, os motoristas que usam a nota para comprar as despesas, vão passar por saia justa porque os dados de pagamento da nota não irão condizer com a realidade, o motorista pode e será lesado, o cliente da empresa irá cobrar a empresa explicações para essa discrepância, e o dono da empresa vai rebolar pra jogar a culpa na SEFAZ, "MAS O PROBLEMA" é que isso não vai resolver o problema de ninguem, e o dono da empresa vai perder clientes, pode até ser processado, fora possíveis problemas contabeis e fiscais. No final de tudo, não vejo nenhum motivo para haver esse tipo de restrição, não afeta o funcionamento pratico pro fisco, ele não extrai nenhuma informação relevante dos pagamentos. Pelo que vejo no final das contas, quem tiver problemas como esse, vai ter q imprimir um detalhe não fiscal contendo os valores corretos e anexa-lo a danfe e rezar.... MUITO.

Reativando o tópico, Um de meus clientes, um posto de combustíveis de estrada, opera no varejo como todo comércio varejista, porém, contém certas peculiaridades nas regras de negócios. 1 - Clientes com cadastro, podem possuir credito para compras a prazo de forma diferenciada do varejo comum, por exemplo. Fulano da Silva - Possui credito para "assinar nota" (venda em carteira) com faturamento quinzenal, ou seja, ele abastece, assina um comprovante e o financeiro do posto gera uma fatura a cada 15 dias, em muitos casos, a empresa exige uma NF-e referente a todas as abastecidas cobradas, então, o fulano da silva, abastece e é gerado um EFC, no fechamento da fatura, o financeiro do posto emitia uma NF-e com CFOP (5929/6929) de acordo com a origem da empresa (mesmo estado/outro estado) e referenciava todos os ECFs. 2 - BRF / Sadia Essa dita empresa opera com um cartão virtual, os motoristas que carregam para ela, recebem parte do frete no sistema interno e podem consumi-lo nos postos de sua preferencia, como o posto emite ECF para tudo, e NF-e referenciada, cada abastecida um ECF e no faturamento para a BRF, "ela" exige uma NF-e para a BRF, mas quem consumiu foram 138901829049012890341 de motoristas que são terceiros, muitos clientes que carregam para outras empresas .... por fim, como você referencia ECF´s emitidos para outras pessoas (fisicas ou juridicas) para uma unica ? Portanto, não há como informar meios de pagamento e prazos na NFC-e que ainda não existem. Essa estrutura não contempla todas as possíveis formas de negócio. Não ha como mudar o funcionamento de empresas como esta. A contabilidade do cliente em questão, me enviou um email solicitando o uso das mesmas aliquotas de impostos e CFOPs utilizados na NFe para emissão da NFC-e. agora o que diz a legislação a respeito eu não faço ideia, porque não encontrei nada referente ao assunto.

Envio SEM Thread : ACBrMail1.Send(False); Envio COM Thread : ACBrMail1.Send(True);

Na verdade nao ha necessidade de ser protegida... só fiz essa alteração pensando em forçar o uso da thread. Pode volta-la a public e talvez alterar o novo metodo pra algo como enviar thread pra diferenciar.

Na verdade você teria que converter o pacote criado para lpk ou criar um pacote novo e adicionar as units, compilar e instalar.

Boa noite pessoal, Estou afastado a algum tempo do projeto e parece que muita coisa mudou. Comecei a testar o componente de Email, TACBrMail, para automatizar o envio de notas e outros arquivos e verifiquei que o componente não está trabalhando com thread no método de envio, portanto fiz a alteração e estou disponibilizando para a comunidade. O método send foi protegido e um novo método "Enviar" tomou o seu lugar como método publico. Realizei o teste no Delphi 7 e XE3 e em ambos está funcionando perfeitamente. ACBrMail.pas ACBrMail.pas

Passou da hora dos estados da federação entrarem em um consenso, a NF-e é única para todos os estados da federação, com algumas pequenas diferenças em detalhes legislativos de cada estado, mas o ambiente, estrutura, enfim, tudo o que compõe a NF-e é padrão para todos. PORQUE ESSA (com o perdão da palavra) PUTARIA com a questão das notas de varejo. Sério que precisamos que a Federação "meta o dedo" pra que todos trabalhem em sintonia ? Levar a posição de que os estados tem autonimia para mandar e desmandar nessa questão deixando-os fazer cada um seu show particular é ANARQUIA, se todos os documentos fiscais (ECF, CF-e, NFC-e, etc,etc,etc) tem basicamente as mesmas exigências, contém basicamente os mesmos dados, servem para a mesma finalidade, um padrão único como o usado na NF-e seria o mais lógico, racional e econômico, tanto para os estados que não precisariam desenvolver do zero cada um sua estrutura especifica, tanto para os contribuintes que não precisariam ficar perdendo noites de sono sem saber se os 30 mil reais que gastaram em ECFs foram pro lixo assim como para os programadores que ficam correndo atrás do rabo com cada uma dessas "novidades". Se a federação obriga o varejo a possuir um ECF ou ingressar no regime da NF-e, então deveria fazer o serviço completo e estipular como a música vai tocar, porque se deixar cada estado com sua dança, vamos ter o maior arraial eclético do planeta. DOWN para toda essa "putaria", UP para a volta do antigo bloco manual =P (pelo menos assim alguém ainda pode ser feliz (o dono da gráfica))

Se você alterou alguma pasta padrão do Delphi durante a instalação pode ser que haja problema no destino dos bpls Se está usando 2 versões d o Delphi, sugiro que de uma olhada nesse tópico e se certifique que efetuou as devidas alterações nas IDEs "ANTES" de instalar o ACBr

Vlw Isaque, vou testar, o que me incomoda é o fato de uma IDE novinha, ja ter 4 updates e ainda apresentar erros grosseiros como esse, as travadinhas ao carregar alguns formularios, etc, eu tenho o Delphi 7 Enterprise com Update 1 e nunca tive problemas com ele. Me parece que a Embarcadero assumiu de vez o jeito Microsoft de ser e está correndo contra o tempo pra lançar sempre uma nova versão, mesmo que ela não esteja pronta e depois fica soltando updates sem fim. Com a Borland pelo menos a coisa parecia funcionar mais perto do que se espera, Lançamento de produtos estáveis. Mais uma vez obrigado pela atenção =]

Bom, o SAC é um produto oferecido por uma empresa que visa lucro e precisa manter uma certa estrutura para atender os contratantes. FATO. O ACBr é um projeto aberto a comunidade que não visa fins lucrativos e requer pouco investimento financeiro para se manter no ao. FATO. Porém, o SAC a meu ver é muito caro para uma boa parte dos programadores "FreeLa" e pequenas softwarehouses, mas isso não impede que o SAC, venda as versões compiladas por ele por preços módicos visto que o custo já foi amortizado pelos contratantes e ajudaria muito a comunidade, como não estamos falando de código e sim de binários pré compilados, todos sairiam ganhando, quem não pode pagar o SAC, compra os binários. É só uma idéia, minha empresa não utiliza o monitor, temos nossa própria estrutura tanto para NFe quanto pra ECF usando os componentes, então Cobrado, Free, de 3 em 3 meses, de ano em ano, os binários não me fazem falta. Os fontes sim, se o SAC mantém uma cópia do projeto em paralelo com os fontes mais atualizados e não o disponibiliza no mesmo svn publico, ai seria um problema. E dos grandes.

Esse código de rejeição se refere a discrepância entre os horários local (aplicação) e remoto (webservice), portanto, pode não ser problema do Monitor e sim uma simples questão de ajuste no horário local. Experimente fazer esses ajustes antes de tentar recompilar o ACBrMonitor. Caso o fuso horário não seja alterado, temos a mensagem : “Rejeicao (578) : A data do evento não pode ser maior que a data do processamento”. Isso quer dizer que a data/hora em que o evento foi disparado não batem com a data/hora em que o WebService iniciou o processamento da mensagem, gerando uma rejeição da solicitação. Os Estados Rio Grande do Sul, Santa Catarina, Paraná, São Paulo, Rio de Janeiro, Espírito Santo, Minas Gerais, Goiás, Mato Grosso, Mato Grosso do Sul, além do Distrito Federal e Tocantins (que participa da medida pela primeira vez), tiveram seu horário adiantado em uma hora. Ao enviar solicitações de eventos de NF-e para os estados citados, o fuso horário deve ser alterado como abaixo: UF Fuso Normal Fuso Verão RS -03:00 -02:00 SC -03:00 -02:00 PR -03:00 -02:00 SP -03:00 -02:00 RJ -03:00 -02:00 MG -03:00 -02:00 ES -03:00 -02:00 GO -03:00 -02:00 MT -04:00 -03:00 MS -04:00 -03:00 DF -03:00 -02:00 TO -03:00 -02:00

O mesmo, peguei seu projeto, contém 2 Forms, o Form 1 sem nenhum controle visual e o Form 2 com um JVDBGrid com 4 colunas, criei um novo form (Form 3) descendente do Form 2 e adicionei mais 2 colunas, compilei e rodei o projeto, voltei a IDE e tentei excluir uma das colunas que adicionei (não as que já existiam) e o erro aparece. Fiz o mesmo teste que estava fazendo do meu projeto, com um jvdbgrid limpo (sem colunas) (Form 4), criei um novo form (Form 5) herdado de Form 4 e adicionei as colunas, depois de compilar e voltar a IDE, mesmo erro. Acho que vou abrir uma thread na embarcadero a respeito desse problema. Obs : Segue em anexo o projeto Herança com os meus testes Heranca.zip