EMBarbosa

Estando bom para ambas as partes, Celso Russom... droga assisti muita televisão quando era criança...

Olá, Como isso está definido no guia prático, acho que seria melhor fazer o tratamento no próprio componente. Isto é, testar se COD_PAIS for diferente de “01058” e “1058”(Brasil) e informar vazio. Você poderia implementar isso e anexar aqui o código? EDIT: haha aquele anexo não estava ali... o.o''

Tópico duplicado. Veja: viewtopic.php?f=8&t=5735

Dê mais detalhes sobre os erros por favor.

Mas não resolveu todos os problemas... http://www1.receita.fazenda.gov.br/noticias/2012/maio/noticia-08052012.htm

O CST dele é o 05

Isso. A propriedade ArqLOG é o log do ACBrTEFD e não o arquivo debug.txt que é o log do Gerenciador Padrão (GP).

Olá, realmente acho que me lembro de sua participação no fórum desde o fórumWeb. Não encaro sua sugestão como uma intromissão ao projeto. É só uma sugestão. Também dei minha sugestão como usuário do ACBr e não como moderador ou desenvolvedor. Hoje, não há uma página no projeto dizendo quais dos desenvolvedores está fazendo o quê. Também não há uma que diga quem está responsável pelo quê, e talvez isso pode passar uma impressão de desorganização ou desinteresse. Mas isso não é o que acontece. O que acontece é que os que já participam do ACBr tem muitas tarefas como o Daniel mencionou. E boa parte é funcionário de uma outra empresa, e precisa cuidar dos interesses daquela empresa também. Assim, não é má vontade, é simplesmente questão de prioridade. Por exemplo, eu tenho aqui umas 5 abas abertas no meu browser de posts mais antigos que preciso verificar com calma. Isso sem falar no Wiki, no Mantis e o ACBrBombas. Mas não tenho tido o tempo necessário pois estamos em fase de homologar nosso software novamente. Ainda assim procuro a cada dia ajudar o Isaque a atender os usuários do ACBrSPED e participar na moderação do fórum. Sendo assim, minha sugestão pessoal, é que não desistam de postar uma nova sugestão por que uma das sugestões não foi atendida no momento. Continuem contribuindo com outras. Já foi dito que é a participação constante que abre as portas para ser um desenvolvedor do projeto. Um projeto open-source só vai pra frente com a colaboração dos usuários. Então contamos mesmo com vocês. Obrigado.

Obrigado Rubens, Subi suas sugestões na revisão 3522.

Já vou verificar.

Puxa Daniel, você tem toda razão. Neste caso é o Número de Série da MFD. Eu me confundi por que os nomes das propriedades são parecidos com o nome das funções da DLL da Bematech. Como estamos tentando otimizar o tempo das funções, estamos estudando algum jeito de utilizar funções e propriedades "em cache". Mas como você mesmo mencionou, o PAF-ECF limita muito o que podemos fazer. Mas esperamos ter alguma ideia para contornar isso.

Para desabilitar é só passar o nome do arquivo de log como uma string vazia. Olhe aí no código que você mesmo postou: procedure TACBrTEFDClass.GravaLog(AString : AnsiString); begin if fArqLOG = '' then exit ;[/code]

A menos que o Eisenhein ou outro usuário tenha feito alguma modificação, o mais atual foi o que eu já deixei anexado. Você pode partir de lá. Qualquer coisa, estou a disposição.

Exatamente. Você assim como outros no mesmo post está desconsiderando o que eu mencionei por não entender seu próprio problema. O campo de alíquota DEVE poder ser deixado em branco. Isso é um requisito. No caso do CST que você mencionou, é preciso informar uma alíquota. O seu problema é que você não está informando uma alíquota válida. Confira nas tabelas de alíquotas (veja aqui) a alíquota a ser usada no seu caso. Assim acho que você vai perceber que não existe em lugar algum a informação que algo possa ter alíquota zero. Quando algum usuário conseguir comprovar que ele deve poder deixar alíquota zero no componente, então eu mesmo faço a mudança.

Por favor, leia o tópico relacionado.

Teoricamente, o Número de Série deveria ser o mesmo. Mas acho que a função NumSerie, no caso da Bematech, retorna só parte do número. Isso acontece pois antigamente o número tinha menos caracteres. Acredito que o ACBrECF deveria ter apenas a função NumSerie e durante a execução chamasse a função correta de acordo com a impressora. Mas mesmo assim, não sei o motivo de ter as duas chamadas para os Dados da Última Redução Z.

Estamos em processo de otimização de velocidade e assim procurando descartar chamadas desnecessárias ao ECF. A função GetDadosUltimaReducaoZ da classe da Bematech está fazendo chamada duas vezes para pegar o Número de Série do ECF (uma para parâmetro NumSerie e outra para NumSerieMFD). Isso acontece mesmo o ECF sendo ou não sendo MFD. No momento não estou lembrado de ser necessário fazer as duas chamadas e nem do motivo de ter os dois NumSerie. Reparei que algumas ECFs fazem o mesmo (Daruma) mas outras só preenchem o parâmetro NumSerie (SwedaSTX). O que vocês acham, isso é mesmo necessário?

Desculpe, acho que postei o link vindo do SAC. Tente o seguinte.http://www.djsystem.com.br/acbr/forum/viewtopic.php?f=5&t=5364

Postei uma possível correção para isso, baseada na correção para o outro post relacionado. Revisão 3512

Realmente o Registro C485 ficou de fora na atualização. Subi sua sugestão na revisão 3511. Por favor verificar se a correção foi suficiente.

O único inconveniente é que o nome do tipo ficou estranho; tratar tpSemPagamento como IND_PGTO OUTROS. Mas vou subir sua sugestão. Acho que é uma maneira de fazê-lo sem gerar muitas incompatibilidades. Se puder testar. Obrigado.

Favor dar mais detalhes. Como, quando, onde?

Obrigado pelo report. Corrigido na revisão 3509.

Use o ACBrInstalador veja: http://www.djsystem.com.br/acbr/forum/viewtopic.php?f=26&t=5364

A nota que substitui o cupom se não me engano é a série D (Nota de Venda a Consumidor).