Ir para conteúdo
  • Cadastre-se

BigWings

Moderadores
  • Total de ítens

    10.146
  • Registro em

  • Última visita

  • Days Won

    156

Tudo que BigWings postou

  1. O destinatário da NFe deve fazer a manifestação. Se o destinatário é uma PJ em RO ele está obrigado a fazer isso pra todas as NFe. Não significa que o emitente não precise saber as manifestações que foram geradas para as NFe emitidas por ele. Se um destinatário manifestar NFe como "Desconhecimento da operação", o emitente terá que se explicar junto ao fisco. O desconhecimento da operação é o destinatário denunciando o emitente por fraude. Pelo método DistribuicaoDFePorUltNSU você recebe os eventos de manifestação geradas pelos destinatários.
  2. Experimente substituir o xsd de schema com o anexo. nfse_v2-04.xsd
  3. Sua instalação do Fortes está desatualizada.
  4. Se está usando Fortes você pode desmarcar a instalação do pacote ACBr_GNREGuiaFR.dpk já que ele é para FastReport. Ou se preferir apenas atualize os fontes novamente, apliquei um ajuste no repositório.
  5. Não pode vender sem imprimir o DANFE da NFCe, em modo normal se houve rejeição você não consegue imprimir o DANFE. Apenas em contingência off-line você tem o prazo de 24 horas.
  6. Se houve rejeição no envio em modo normal o correto é bloquear a venda, fazer a correção, gerar novo XML e enviar novamente, para permitir a impressão do DANFE. NFCe emitida em contingência off-line deve ser transmitida em até 24 horas, após esse prazo o webservice ainda acata a NFCe com o cStat 150 - Autorizado fora do prazo, e a SEFAZ pode vir a cobrar esclarecimentos da empresa pelo atraso.
  7. Pode anexar o XML com o erro?
  8. O que quer dizer com reenviar? A NFCe só é enviada uma vez.
  9. Veja se é o teu caso:
  10. Que saiba uma NFe de ajuste não serve como substituição a uma NFCe já emitida, é considerada uma nova nota fiscal. A não ser que a NFe de ajuste seja a "devolução", com CFOP de entrada, conforme o comentário do Jadielson mais acima. A NFe emitida em substituição a NFCe deve ter CFOP 5929 ou 6929. Cada UF pode permitir ou não a emissão de NFe com CFOP 5929/6929 em substituição a NFCe.
  11. A versão básica do FastReport que vem junto ao Delphi não tem suporte a scripts e causa esse problema. Se instalar a versão completa do FastReport (versão 5.2 ou acima) e FastScript não é opção, você pode tentar usar os arquivos .fr3 identificados como BASIC na pasta ACBr\Exemplos\ACBrDFe\ACBrNFe\Delphi\Report\Obsoletos. Ou usar a versão em Fortes que é OpenSource.
  12. Pode esclarecer melhor? Pra mim é o mesmo campo. E no código do componente é gerado o arquivo TXINFO.TXT com o valor informado para o campo "Receita": function TACBrCargaBal.GetNomeArquivoReceita: String; begin // Urano nao possue arquivo de Receita a parte. EXCETO URANO URF32 case FModelo of modFilizola : Result := 'REC_ASS.TXT'; modToledoMGV5, modToledoMGV6: Result := 'TXINFO.TXT'; modUranoURF32: Result := 'RECEITAS.TXT'; end; end; No momento o componente usa o mesmo código do item como código de receita (informações extras no caso da Toledo).
  13. Informe um valor para a propriedade PosPrinter.EspacoEntreLinhas, algo entre 30 e 60. Quando você deixa 0 nessa propriedade é usado o espaçamento padrão configurado na impressora, o que pode dar diferença de um equipamento pra outro.
  14. Fiz teste em homologação e confirmei que o método DistribuicaoDFePorChaveNFe não retorna o XML completo quando a manifestação é Operação não realizada, retorna apenas o resumo da NFe. Já pelos métodos DistribuicaoDFePorUltNSU ou DistribuicaoDFePorNSU a NFe completa é retornada. Em resumo, é falha no webservice.
  15. O componente apenas envia a solicitação para o webservice e recebe o retorno. Se o webservice ainda está devolvendo apenas o resumo da NFe para NFe com manifestação "Operação não realizada" é problema no ambiente deles. Há muitos relatos de demora no retorno da NFe completa mesmo após a manifestação aqui no fórum. Atenção que para o evento "Desconhecimento da Operação" o XML da NFe completa não é retornado pelo método DistribuicaoDFePorChaveNFe, conforme o manual.
  16. Boa pergunta. Qual o XML de retorno?
  17. Para CTe existe a SVC-RS e SVC-SP. Precisa saber qual ambiente de contingência MG usa.
  18. infEvento.detEvento.xJust := 'xxxx';
  19. Na verdade não está faltando, apenas não permite que você use um código de informação extra/receita já cadastrado no MGV5.
  20. Você pode passar as informações extras para a propriedade Receita do item, assim o componente gera o cadastro de informações extras com o mesmo código do item. Nesse caso não haveria necessidade da alteração.
  21. Não entendi o porque de ter duas chaves e dois arquivos. A não ser que você faça alguma alteração nos dados da NFCe como o tipo de emissão (que não deve ser alterado justamente para não alterar a chave) e faça nova geração do XML. Exatamente por esse problema o manual determina que na falha de transmissão de uma NFCe em modo normal deve ser gerada uma nova NFCe com nova numeração em contingência off-line. Essa NFCe em contingência deve ser apenas transmitida quando a conexão retornar, sem alteração da chave.
  22. Me parece que a partir do XE5. http://blog.marcocantu.com/blog/refind_and_bde_migration.html
  23. Pode usar a mesma série usada com o tipo de emissão normal.
  24. As séries 900-999 são reservadas à contingência SCAN, tipo de contingência já desativado pela SEFAZ. Para a contingência SVC não é necessário fazer alteração da série.
×
×
  • 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.