EMBarbosa

1) No log não parece estar sendo chamado o comando da Redução Z. Se estiver, o timeout pode estar muito baixo. Tente aumentar ele. Aqui no fórum tem algumas dicas para isso. 2) O comando de fechar relatório foi chamado. Muito difícil ele não estar em algum lugar do código. Tente verificar os eventos do ACBrECF. Ou talvez algum comando para corrigir o estado do ECF, já que o comando anterior parece fazer referência a isso. 3) Mesmo caso anterior. Sugiro pegar o aplicativo de exemplo (ECFTeste) e testar com ele a impressão da Redução Z. Só por desencargo de consciência.

Beleza... na verdade foi falha minha. Eu achei que os fontes estavam no anexo, mas está claro pelo que escreveu que era só o executável. A minha ideia era colocar no programa exemplo pra facilitar para os novos. Mas se não encontrar, ainda é possível de implementar olhando as mensagens do Daniel e minhas espalhadas pelo fórum. (:

Depende do problema que está tendo.

Ou você não testou a geração corretamente ou já percebeu mas não voltou pra colocar o resultado. Para que outros usuários não venham fazer a mesma pergunta novamente vou explicar o que foi implementado. O que o componente faz no método TBloco_C.WriteRegistroC100 (unit ACBrEPCBloco_C_Class.pas) é avaliar a data do registro C100. Se for antes de 01/07/2012, ele gera no formato antigo, colocando 9 no arquivo SPED. Se for após 01/07/2012, o tipo tpSemPagamento é gerado como 2. Assim mesmo quem utiliza o componente antes não precisa se preocupar. Adicionarei ainda hoje um comentário no TACBrIndPagto sobre isso.

svn://svn.code.sf.net/p/acbr/code Mais informações sobre o acesso ao SVN

E hoje quando eu fui analisar o código pra ver se enviava ao SVN é que percebir que os fontes não estavam lá no anexo... fon fon fonnnnnn

Verdade. Pelo menos dois deles estão mencionados nos links que postei acima.

Se comparara os tempos de resposta, realmente parece que o ECF está demorando muito pra responder. Veja: -- 17:12:24:711 RetornaInfoECF(U2) TX -> [STX]Z34|U2[ETX][201] TX -> [STX]Z34|U2[ETX][201] 17:12:27:821 RX <- [STX]Z34-0193AA[152][192][146][128][128][ETX], ----------------- ERRO ----------------- Erro retornado pela Impressora: SwedaSTX Erro (0193) Falha de comunicação na transmissão das informações ---------------------------------------- "17:12:24:711" e "17:12:27:821" é uma diferença de 3,1 segundos. Em média, para consultas simples o ECF demora 0,2 segundos (compare com outras partes do log). Você poderia dar mais informações sobre seu problema? Começou a acontecer agora? Chegou a testar em outros lugares?

Provavelmente... Os links dão exemplos de componentes que trabalham com a API do Google Maps. Eu particularmente não utilizei ainda o maps, mas se você for começar ou pesquisar sobre o assunto, eu sugiro partir dali. O Rodrigo (RRUZ) e o Wouter são programadores com boa experiência. E se eles já tem algo iniciado, tenho certeza que vai ser útil. Agora se preferir algo pago, parece que a TMS também tem um pacote de componentes para isso.

Links relacionados https://stackoverflow.com/questions/10843029/google-maps-non-web-access http://www.cadetill.com/gmlib_en/

Se você gerar o arquivo e passar para ele, ele pode editar o que achar necessário utilizando o PVA.

Seria melhor você citar as várias contribuições que fez e que não foi analisada ou aceita.

Qual o modelo do ECF? Você chegou a ler o manual pra saber se precisa fazer alguma coisa?

Provavelmente essa versão do Delphi que você menciona (que não deve ser oficial) não possui os códigos necessários para a instalação do RAVE. Se esse for realmente o caso, ao instalar o ACBr, não marque os pacotes que precisam do Rave Reports, como o que você mencionou. A única limitação será que você não conseguirá imprimir o DANFE no Rave.

Realmente o que vale é o que está no DOU. Muito obrigado pelo retorno.

Infelizmente, é o que está no ATO COTEPE e, até o exato momento, não houve retificação. Então a regra é clara Pode parecer brincadeira, mas é o que está escrito. Se você não conseguir reclamar ou fazê-los ligar para algum fiscal ou alguém responsável, talvez não consiga convencê-los a mudar de ideia.

Veja primeiro link no primeiro post deste tópico. Nele o Daniel menciona a legislação que faz as alterações.

Já.

Olá marcelomarini, Bem vindo ao fórum. Esperamos que possa sanar suas dúvidas e ajudar o projeto a crescer. Visto que é novo no fórum, convido a ler e também a parte que dá orientações gerais para formular perguntas. Por exemplo, temos a regra que pede para que se crie um tópico novo para uma dúvida nova. Veja neste em especial a "2.2 - Permaneça no assunto". Com respeito a sua dúvida, veja o seguinte subfórum: http://www.projetoacbr.com.br/forum/index.php?/forum/49-nfc-e-nota-fiscal-do-consumidor-eletr%C3%B4nica/

Mas nesse caso há uma possibilidade de ter um fornecedor com condição "Prazo 2x" e "Duplicata 2x" ou "Cheque 2x". Nesse caso qual será o critério de desempate?

Obrigado pelo retorno!

E onde (quais campos) está essa informação nas suas tabelas do Banco de dados?

Tome cuidado. Embora Minas não tenha mais obrigatoriedade de homologação, você ainda precisa cumprir os requisitos, seja o ER-PAF-ECF 2.01 ou o MG-001.

Dividi o tópico.

Estranho, teste o seguinte: Crie um aplicativo console, Menu File -> New -> Console application; Substitua o código por: program Project1; {$APPTYPE CONSOLE} uses SysUtils, Dialogs; var iAuxiCod : integer; begin try { TODO -oUser -cConsole Main : Insert code here } begin iAuxiCod := 15; //Funciona? // iAuxiCod := 14; //E esse? if iAuxiCod <= 15 then begin showmessage( 'voce tem ' + inttostr(iAuxiCod) + ' Dias '); end; end; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end. Veja se vai mostrar a mensagem. A propósito, qual a versão do delphi e do Windows?