Ir para conteúdo
  • Cadastre-se

RicardoVoigt

Membros
  • Total de ítens

    1.359
  • Registro em

  • Última visita

  • Days Won

    8

Tudo que RicardoVoigt postou

  1. 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
  2. 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
  3. É 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. me corrijam administradores do fórum, mas acho que aqui não tem uma seção de piadas...
  12. 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
  13. Ola, resumindo, vc deve enfiar a hora junto no mesmo campo q vai... Ide.dSaiEnt := Now; Att Ricardo
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...