RicardoVoigt

Bom dia, não sei se pode te ajudar, mas da uma lida no meu tópico abaixo.. Att Ricardo

Bom dia, implementei aqui para mim a propeidade PapelAltura no TACBrNFeDANFCeFortes. property PapelAltura: Integer read FPapelAltura write FPapelAltura default 0; Mais tarde vou enviar ao cliente um "bacalhau" para aprovação da impressão. Como eu tinha o mesmo XML que testamos outro dia, testei e acho que vai dar certo. Outro ponto no que mexi unit ACBrDANFCeFortesFr, foi na procedure rlVendaBeforePrint, onde calcula o tamanho da página em pixels e depois converte para milimetros: if (ACBrNFeDANFCeFortes.PapelAltura > 0) then begin rlVenda.PageSetup.PaperHeight := ACBrNFeDANFCeFortes.PapelAltura; end else begin // Calculando o tamanho da Página em Pixels // TotalPaginaPixel := ... Espero que esta ideia seja aprovada como uma contribuição para o projeto ACBr, qualquer outra ideia ou sugestão será bem vinda... Att Ricardo ACBrDANFCeFortesFr.pas

oi, outra dúvida que pensei, acompanhando esse tópico, este não seria um caso, de emitir uma NFe referenciando (na tag RefNFe) o NFC-e (e sem o seu cancelamento) ? Att Ricardo

Bom dia, me surgiu uma dúvida com relação à impressão da NFC-e com o componente ACBRNFeDANFCeFortes... Estou verificando a possibilidade de implantar meu sistema (juntamente com o ACBrNFeMonitor) em um cliente, e ele já tem outro sistema que imprime a NFC-e usando uma impressora laser, com papel A4 cortado ao meio, ou seja 105 mm de largura e 297 mm de altura. Por incrível que pareça, funciona... Gostaria de saber se existe essa possibilidade? Definir o tamanho do papel (não achei essas propriedades) no componente, a fim de tentar encaixar a impressão com mais perfeição ao papel, pois fiz alguns testes e o ACBrNFeMonitor imprimiu o QRCode na página 2, sendo que ainda tinha espaço na página 1... Att Ricardo

Ola, que legal... Agora quero ver o número do CHASSI... Pelo que vi, o furo é bem mais embaixo... (pt.wikipedia.org/wiki/Número_de_Identificação_do_Veículo) Acho que ao invés de tentar validar o conteúdo (pelo menos o tamnho de 17 posições), to pensando em pelo menos fazer um parse e exibir para o usuário as informações que estão codificadas no CHASSI, num TMemo por exemplo, apenas para fins de conferência. Att Ricardo

Oi, achei um tópico de 2013, num fórum de java... codifiquei a rotina aqui em Delphi, e achou que deu certo... https://ivanmeirelles.wordpress.com/tag/validar/ function ValidaRenavam1(Num: String):Boolean; const SEQUENCIA = '3298765432'; var I,SOMA,DV : INTEGER; begin Result := False; if Length(Num) = 11 then begin SOMA := 0; FOR I := 1 TO 10 DO SOMA := SOMA + (StrToInt(Num[I]) * StrToInt(SEQUENCIA[I])); DV := (SOMA * 10) MOD 11; if DV = 10 then DV := 0; IF DV = StrToInt(Num[11]) THEN Result := True; end; end; Na prática acho que é quase igual, só o "multiplicador" que não tinha na outra rotina, dos 2 dígitos a mais... Um detalhe que não validei é se os 11 caracteres da var Num: String são numéricos... Espero ter contribuído com algo útil... Att Ricardo

É essa rotina que eu já testei aqui... Eu estou testando com 2 códigos de renavam, um de 2011 passa OK na validação, e outro de 2013 NÃO PASSA. Att Ricardo

Boa tarde, antes de mais nada, já procurei no fórum e google, e não encontrei nada atualizado. Eu gostaria de validar o código RENAVAM de veículos. Pelo que achei na internet então, houve uma mudança no início de 2013, o código RENAVAM passou de 9 para 11 dígitos. Até encontrei em postagens mais antigas em outros fóruns, uma rotina em Delphi que calcula o dígito e valida, mas eu acho que só funciona para códigos Renavam gerados até 2012, pois com um código de exemplo que tenho aqui, do ano de 2013, não está funcionando. Alguém sabe como funciona a nova validação? Onde posso encontrar a regra do cálculo do dígito? Ou já tem esta validação em alguma unit do ACBr? Eu não trabalho com CT-e, mas acho que esta validação deve interessar também pra quem trabalha... Se ainda não tiver na biblioteca ACBr, eu gostaria de sugerir a implementação desta validação no componente TACBrValidador. Att Ricardo

Boa tarde, valeu mesmo pela resposta, e principalmente, pela referência... Eu já tinha visitado o site do Regys, mas não tinha pesquisado conteúdos/publicações anteriores. Att Ricardo

Bom dia, antes de mais nada, juro que pesquisei aqui no fórum e não encontrei dúvida semelhante à minha. Referente a lei 12.741/2012 (De olho no Imposto), quando é emitida uma NFe de Entrada/Compra ou uma NFe de Devolução (Saída), como devem ser preenchidos os campos vTotTrib ?? Na prática mesmo, eu gostaria de ter certeza se, nestes casos, deixo tudo ZERO mesmo... Pelo que li na lei, no primeiro parágrafo apenas menciona o "preço de venda": "deverá constar, dos documentos fiscais ou equivalentes, a informação do valor aproximado correspondente à totalidade dos tributos federais, estaduais e municipais, cuja incidência influi na formação dos respectivos preços de venda." Agradecido pela atenção, Att Ricardo

Ola, publique as linhas de código onde vc alimenta estas propriedades no componente ACBrNFe... se não me engano, as propriedades são dEmi e dEntSai Lembrando q agora (versão 3.10) vc deve informar data + hora na mesma propriedade... Att Ricardo

Eu acho que entendi a pergunta, para ver uma previa da DANFE com um XML que ainda não tenha sido assinado nem enviado para a RF, eu acho que o ACBrNFeMonitor consegue fazer isto usando o comando ImprimirNFe passando o respectivo XML... se não me engano aparece algum destaque no meio da Danfe informando que a NFe não não tem validade pois não foi assinada e não vai ter o protocolo de autorização... Acho que é isso... Att Ricardo

Ola, acho que não, pelo que entendi o ValidarNFe apenas verifica a estrutura do arquivo XML. É só no EnviarNFe que é feita a comunicação com o WEBSERVICE, que é de onde vêm as rejeições... Espero ter acertado, me corrijam se falei bobagem... Att Ricardo

Pessoal, esse tópico é de janeiro, e já que teve uma resposta hoje, gostaria de complementar com a experiência que tive nos meus testes... Em homologação, eu faço da mesma forma que o colega abriu o tópico, com CNPJ 99999999000191, informando indIEDest 9 (não contribuinte) e IE em branco. A situação que eu notei é que, ainda em homologação, quando a UF do destinatário é DIFERENTE da UF do emitente, acho que a receita valida diferente e retorna essa mesma rejeição "232 - IE do destinatário não informada", sendo necessário então, eu acho, ter a informação correta: - a IE correta e indIEDest 1 (contribuinte) - ou deixar em branco e informar indIEDest 2 (isento)... - ou (lembrando) se for "produtor rural", é pessoa física com IE e indIEDest 1 (contribuinte) Att Ricardo

me corrijam administradores do fórum, mas acho que aqui não tem uma seção de piadas...

Oi, então, sei que este post é antigo e tal, mas me ocorreu erro semelhante UMA VEZ no mês passado, fevereiro de 2015, com a versão 3.10. A minha aplicação gera o XML com o componente ACBrNFe, e o ACBrNFeMonitor faz o resto (assinar e enviar)... Tenho o XML original salvo aqui, mas não vejo necessidade de anexar, pois faltou o espaço apenas nesta tag: <protNFeversao="3.10"> Com sorte, logo achei o problema e arrumei o XML no braço e conclui o envio manualmente usando as opções da aba Testes do ACBrNFeMonitor, mas achei interessante registrar para algum possível problema futuro. Att Ricardo

Ola, resumindo, vc deve enfiar a hora junto no mesmo campo q vai... Ide.dSaiEnt := Now; Att Ricardo

Ola, não to com muito tempo para poder testar com mais calma, mas eu acho que por algum motivo o componente ACBrNFe no monitor pode não ter liberado o XML... Pensando depois sobre a situação que escrevi acima, se não me engano, pode ter havido uma rejeição ao emitir uma NFe, e ao tentar editar o XML para corrigir alguma coisa e tentar novo envio, deu esse erro de outro processo usando o XML. Acho que tive de fechar e abrir novamente o monitor para fazer o envio manualmente pela guia "Testes", como se o componente não liberasse o XML, após executar o "NotasFiscais.LoadFromFile()" e só liberasse depois de rodar um "NotasFiscais.Clear"... Att Ricardo

Oi, lendo esse tópico, lembrei de um comportamento que vi no ACBrNFeMonitor. Minha aplicação gera o XML com o ACBrNFe e o salva em uma pasta, em seguida manda o comando Enviar para o monitor. Até ai tudo certo. O estranho que gostaria de comentar aqui, que acho que pode ter relação com a mensagem citada neste tópico, é que se eu tentar copiar ou abrir o XML no bloco de notas, mesmo tendo fechado o meu aplicativo, e estando com o ACBrNFeMonitor aberto após ter retornando o resultado do comando Enviar, o Windows da um erro dizendo que o XML está sendo usado por outro processo e não deixa eu acessá-lo, só depois de fechar o monitor. Espero ter ajudado, Att Ricardo

Oi, para mim também deu problema mais cedo... Erro ao consultar Nota Fiscal eletrônica. Agora acabo de consultar a mesma NFe e deu certo! Att Ricardo

Bom dia, acho que para responder esta pergunta, vc precisa saber primeiro o tipo/finalidade da NFE que se quer emitir... Alguns exemplos que eu já vi envolvendo destinatário PF: - NFe de venda/saída para PF, (se for um produtor rural), aqui e agora não lembro se deve ou não informar a IE e isento - NFe de compra/entrada de um produtor rural, com certeza informa a IE e contribuinte - NFe de devolução/entrada de mercadoria de um cliente PF que tem IE, na nota não informa IE e isento Ontem mesmo eu postei neste tópico também relacionado a IE do destinatário: onde eu comentei sobre como resolvi a situação de uma NFe de devolução... Enfim, espero não estar repetindo a mesma reposta, mas verifiquei existem vários tópicos questionando mesmo assunto (IE do destinatário) Att Ricardo

Ola, o código acima não prevê a situação de "produtor Rural", pois é pessoa física COM inscrição estadual... Neste caso indIEDest deve ser inContribuinte... Uma das primeiras "dores de cabeça" que eu tive migrando para a 3.10, foi um caso onde meu cliente(uma loja) emitiu uma NFE de devolução/entrada para seu cliente que devolveu uma mercadoria e, como era produtor rural, ele tinha IE informada em seu cadastro de cliente... Ao validar a NFE de devolução na receita, estava acusando q a nota referenciada não era nota de produtor, pois neste caso, nf de devolução onde o destinatario é PF, não deve ser informada a IE do destinatario e indIEDest = isento. Esse é minha segunda postagem no forum, espero ter ajudado... Att Ricardo

Ola, (meu primeiro post aqui no forum, estou me aventurando na NFE com o ACBRNFEMONITOR em um cliente, e achei interessante registrar) Hoje mesmo erro 12057 ao emitir uma nfe, sendo que a última/anterior tinha sido emitida na sexta-feira 13, e de cara também achei que tinha relação com o horário de verão, pois clicando sobre o relógio -WINDOWS 7- aparecia a mensagem "O horário de verão terminou em domingo, 15 de fevereiro de 2015..." (a microsoft nunca acerta a data de inicio e fim do HV) Enfim, desmarcando esta opção na configuração do Internet Explorer: "Verificar revogação de certificados no servidor" funcionou corretamente! Att Ricardo