guiprze

Obrigado pelo esclarecimento, estava meio perdido quanto a isso!

Bom dia pessoal, gostaria de saber se tem alguma forma de salvar os arquivos XML das notas sem ter que salvar também os arquivos env-lot.xml e pro-lot.xml. Antes eu conseguia fazer isso, mas no Trunk2 não consigo mais. Obrigado!

Boa tarde, Nesse link tem todas as informações necessárias para isso:

Tenho uma impressora Elgin VOX e tem o mesmo problema da margem, tanto imprimindo com Fast quanto com Fortes. Também informo a margem no componente e não altera nada. Lembrando que em outras impressoras, como a Daruma DR700, não ocorre esse problema. Mais alguém passou por isso e conseguiu resolver?

Isaque, por acaso você já subiu pro svn? Ainda não recebi a atualização. Desculpe pelo incômodo. Obrigado.

Deu certinho! Obrigado!

Consegui reproduzir o erro pelo demo. É o seguinte, altero as linhas 112, 113, 366 e 367 para gerar com data de 2014, depois altero a linha 491 (onde gera o bloco C) para o seguinte: IND_FRT := StrToIndFrt('0'); //tfSemCobrancaFrete; O certo seria gerar o txt com o campo IND_FRT = 0, mas está gerando como 2, como se convertesse para os valores antigos do SPED. Espero que consiga reproduzir aí.

Bom dia! Estou verificando aqui, quando eu passo o valor do campo IND_FRT pro componente usando a conversão StrToIndFrt, ele converte usando os valores anteriores a 2012. Dei uma olhada no código do componente, vi que ele verifica pela data na hora de criar o arquivo TXT, mas ele já fez a conversão de forma errada antes. Acredito que possa atualizar essa conversão para os valores atuais, não? Obrigado.

Mas então é pra fazer da forma que eu disse que fiz inicialmente? Colocando o frete inteiro em apenas um registro 991 do primeiro CFOP? Pois o Manual até onde vi não explica esse caso.

Então, pelo que eu li não há opção para informar o frete no registro 50, e também não achei nada que informe sobre notas com mais de um CFOP. E colocando no item 991, eu colocaria o valor de frete inteiro representado em apenas um CFOP e nos outros eu não informo o 991? Eu até fiz dessa forma inicialmente, mas os valores não bateram de acordo com os dados do contador do meu cliente, por causa dos totalizadores de cada CFOP.

Foi exatamente nessa tela que notei o erro. Ele só calcula o último 991 no valor do frete.

Então...eu estou usando o frete por item mesmo, e pra representá-lo, trago o somatório dos fretes de itens com mesmo CFOP naquela nota para gerar o 991. O arquivo aparentemente vem com os registros certos, mas quando abro o validador e abro a parte de visualização de notas, a referida nota apresenta o valor de frete de apenas um CFOP, e também apresenta erro de soma, cuja diferença é justamente o valor do frete do outro CFOP.

Pessoal...estou com uma dúvida em relação ao Sintegra, quando a nota tem mais de um CFOP diferente e tem frete, o validador acusa erro de soma, como se ele reconhecesse só o frete de um CFOP e não soma todos. Gostaria de saber se o validador tem esse erro mesmo ou estou fazendo algo errado. Obrigado!

Precisa não, já consegui resolver. Na verdade o problema era no componente ACBrLCB, que estava configurado incorretamente (no ini do cliente). Obrigado!

Pior que não, até porque isso acontece somente em um cliente, e somente dá essa mensagem nessas horas e continua funcionando.

Ae pessoal, estou tendo um problema em um cliente, ao iniciar e ao finalizar a venda mostra a seguinte mensagem: 'Valor deve estar na faixa de 50 a 4000000. Normalmente os equipamentos Seriais utilizam: 9600' O Baud está configurado certo, e mesmo dando essa mensagem o programa funciona. Como não dá pra debugar lá, queria ver se alguém já passou por isso. Valeu!

Não testei ainda, mas pelo que eu vi é aquilo mesmo. Me desculpe por não mandar o arquivo alterado, é que eu tambem estava (e ainda estou) muito enrolado aqui. Valeu!

Então, mas o meu problema não foi com o papel. Tanto que eu percebi isso na hora de efetuar o pagamento do cupom.

Elton, um exemplo está na função EfetuaPagamento: if FPG = nil then raise Exception.Create(Format(ACBrStr(cACBrECFAchaFPGIndiceException), [ CodFormaPagto ])) ; if ImprimeVinculado and (not FPG.PermiteVinculado) then raise Exception.Create(Format(ACBrStr(cACBrECFFPGPermiteVinculadoException), [ CodFormaPagto ])) ; Se pesquisar por "raise Exception" nessa unit, vai achar vários. Ou se quiser que eu liste todas, é só falar. Daniel, é uma boa ideia isso, mas ainda não é o que eu disse. O que acontece é que algumas exceptions não são geradas como EACBrECFErro, mas como Exception. Obrigado! Guilherme Przewodowski.

Boa tarde, estou usando o ACBrECF, e faço um tratamento separado para as exceptions do ACBr em relação às outras utilizando o on E:EACBrECFErro. Mas percebi que em algumas funções na unit do ACBrECF, ao invés de ter um raise EACBrECFErro.Create, tem um raise Exception.Create. Então aqui está minha dúvida/sugestão: teria como mudar todos para EACBrECFErro? Pois assim daria para diferenciar melhor os erros gerados pela impressora dos gerados pelo banco.