Ir para conteúdo
  • Cadastre-se

Italo Giurizzato Junior

Consultores
  • Total de ítens

    39.488
  • Registro em

  • Última visita

  • Days Won

    1.143

Tudo que Italo Giurizzato Junior postou

  1. Bom dia Dimas, Para informar uma nota fiscal de papel você tem que alimentar a lista infNF e não a infNFe, não deve se esquecer que totalizar as quantidades de notas em qNF.
  2. Bom dia Nilton, Favor atualizar os fontes, depois abra a unit ACBrCTeWebServices e procure por todos os eventos Clear. Eles estão comentados, descomente, compile e realize os testes. Fico no aguardo de um retorno. Se tudo estiver OK, vou descomentar e disponibilizar novamente.
  3. Bom dia Dércio, Tem coisa errada ai, pois o pacote synapse.dpk encontra-se na pasta: ...\Pacotes\Delphi (fontes do trunk), por outro lado o ACBr_synapse.dpk encontra-se na pasta: ...\Pacotes\Delphi\synapse (fontes do trunk2).
  4. Bom dia Elrodaocorp, Qual é o fluxo? 1. Alimentar o componente com os dados da venda; 2. Assinar; 3. Validar; 4. Enviar.
  5. Bom dia Diego, Como não utilizo o Fast, não sou a pessoa certa para avaliar o problema do DACTE.
  6. Bom dia Dércio, Se você deseja continuar usando o Quick Report faça o seguinte, instala tudo mesmos os componentes referentes aos documentos auxiliares, por exemplo: DANFE, DACTE, ... Depois execute o Delphi e abra o pacote desejado, por exemplo: DANFE - Quick Report Pasta: ...\Pacotes\Delphi\ACBrDFe\ACBrNFe\DANFE\NFe\Quick Pacote: ACBr_NFeDanfeQR Abra o pacote, compile e instale. Lembre-se que a equipe ACBr vai manter os fontes mas não existe nenhuma garantia de atualização dos mesmos. Pois o foco é Fortes e Fast Report.
  7. Bom dia Rafael, Emissão de NF-e ou NFC-e? A premissa é que não se faz necessário fazer a homologação do software para emissão, tenho uma aplicação que emite NF-e rodando a quase 4 anos no Estado de São Paulo e nunca foi necessário fazer a homologação do mesmo.
  8. Carlos, Simples, se o problema começou de um dia para outro sem você atualizar a aplicação do seu cliente, com certeza o problema é a SEFAZ.
  9. Bom dia Luciano, Estamos trabalhando para resolver o problema do protocolo de autorização. Quando ao cancelamento, o componente não vai mais alterar o XML conforme orientação contida em Manuais e Notas Técnicas publicadas pelo ENCAT. Por favor pesquise aqui mesmo no fórum sobre o cancelamento, você encontrará várias postagem explicando como proceder.
  10. Bom dia Carlos, Os fornecedores do seu cliente também utilizam a sua aplicação de emissão de NF-e? Tanto os fornecedores quanto o seu cliente são do mesmo Estado? Você concorda que o problema pode esta na SEFAZ?
  11. Bom dia Eber, Você concorda que se o problema é na SEFAZ e o mesmo não for sanado dentro do prazo, ela é obrigada a aceitar as NFC-e com emissão superior a 24 horas?
  12. Diego, Pelo que andei analisando o código novo, não foi previsto quando se tratar de SVC.
  13. Boa tarde Mazuka, Verifique se o componente não esta configurado para a versão ve300. Se sim, tai o erro. Tem que configura para a versão ve310.
  14. Boa tarde Azevedo, Qual é o motivo de gerar o TXT usando o ACBrNFe para depois ser importado pelo programa gratuito da SEFAZ e por fim ser emitido? Porque você não utiliza o ACBrNFe para tudo?
  15. Boa tarde Cleiton, Na minha aplicação eu utilizo o RoundTo( valor, -2) isso faz com que o valor seja arredondado para 2 casas decimais. Nunca tive rejeição por diferença de centavos.
  16. Boa tarde, O UltNSU do DistribuicaoDFe começou do zero portanto se você esta alterando de ConsNFeDest para DistribuicaoDFe deve começar do zero novamente e não utilizar o último NSU que você obteve ao usar pela ultima vez o ConsNFeDest.
  17. Boa tarde Dércio, Te aconselho utilizar uma outra maquina para usar os fontes do Trunk2.
  18. Boa tarde ALA, Essa história de reversão de cancelamento foi cogitada se não me falha a memória no grupo G19 entre as empresas piloto da NF-e assim que foi lançado a versão 2.00 da NF-e, isso por volta de 2010. Não houve um consenso entre as empresas, umas queriam e outras diziam que seria muito difícil gerenciar de forma eficiente essa possibilidade no sistema. Como você pode ver se passaram 5 anos e ainda nada foi resolvido. O que você tem que fazer agora é apresentar essa resposta da SEFAZ a este cliente que solicitou algo que não existe.
  19. Boa tarde Filippe, Com certeza no texto da carta de correção esta sendo informado algum carácter invalido.
  20. Boa tarde Rômulo, Desculpe pelo puxão de orelha, mas esse assunto já foi tratado no fórum e a resposta é: Não se deve alterar o XML da NF-e depois que a mesma recebe o protocolo de Autorização. Se a nota for cancelada devemos enviar ao destinatário o XML chamado *-procEventoNFe.xml este contem o pedido e o protocolo de cancelamento. Se você desejar imprimir novamente o DANFE com a tarja de cancelado basta atribuir o valor True a uma propriedade do DANFE chamada NFeCancelada.
  21. Diego, Aparentemente o seu XML esta correto. A sua rotina acima que não concordo, pois se o tipo de emissão se não for normal o ambiente é homologação esta errado isso. Uma coisa é o ambiente ser de Homologação ou de Produção, outra coisa é o tipo de emissão ser Normal ou Contingência FSDA ou SVC-RS ou SVC-SP. Posso enviar um CT-e para o ambiente de homologação cujo tipo de emissão é normal sem nenhum problema e por outro lado posso enviar um CT-e para o ambiente de produção cujo tipo de emissão é SVC-SP. Com certeza antes do envio algo esta sendo alterado e ficando incompatível. As rotinas que alimentam o componente e de envio estão na mesma Unit? Se sim, você acrescentou em uses: pcnConversao e pcteConversaoCTe ?
  22. Boa tarde Dimas, Você gera o XML salva em disco, depois carrega ele para poder assinar, validar e enviar, é isso? Se sim, porque você simplesmente alimenta o componente com os dados e manda assinar, validar, enviar ...?
  23. Boa tarde André, Com toda certeza ele deve baixar através do site da SEFAZ, pois não existe no momento outra forma.
  24. Boa tarde Diego, Post como anexo o XML que foi rejeitado.
  25. Boa tarde Daniel, Isso se pegarmos os dados do XML mais a assinatura e protocolo e gerar novamente o XML, caso contrario não. Temos também outras situações, por exemplo a inutilização de numeração, onde temos 3 XMLs, o de envio, de retorno e de compartilhamento. O de envio não temos problemas, pois é executado o "TGerador.wCampo", mas o de retorno e o de compartilhamento que é apenas uma montagem dos dois anteriores não temos essa filtragem e consequentemente vai aparecer esses caracteres "inválidos".
×
×
  • 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.