BigWings

Tem razão, vi agora que é uma rejeição, nesse caso os schemas na SEFAZ que ainda não foram atualizados. Está enviando em homologação certo? Em produção ainda não está em vigor.

Sim, mas segundo a legislação que você citou é a única forma. Já tem uma NT adicionando novos meios de pagamento, o PIX entre eles. No XML só vai o código do meio de pagamento e o DANFE imprime a descrição segundo o manual, essa descrição não pode ser alterada.

Aparentemente o problema é na SVRS.

Se é rejeição da SEFAZ está errado lá. Precisa entrar em contato e reportar o erro. Tem o XML com o retorno da SEFAZ? Teu problema é outro, de validação local pelos schemas. Verifique a sua pasta de Schemas se está atualizada.

Se quem está consultando é o próprio destinatário ou um terceiro autorizado a baixar o XML, sim. Basta usar o método ACBrNFe.DistribuicaoDFe.

Nesse caso, a única forma, a meu ver, é incluir a informação dos meios de pagamento na tag infAdFisco da NFCe.

Não entendi... na NFCe você é limitado às formas de pagamento pré-definidas, ou informa fpOutro caso não seja nenhuma. Como assim as suas formas?

No evento QuandoEfetuarPagamento do ACBrECFVirtualNFCe você pode sobrescrever.

Se você inclusive consegue emitir CTe por esse CNPJ mas não consegue autorizá-lo pelo evento, o problema deve ser na SEFAZ.

O CNPJ que está tentando autorizar está com inscrição estadual inativa, então não está habilitado a emitir CTe. Creio ser esse o motivo da rejeição.

Sim.

Você tem os XML desse teste? Porque no que você anexou o CNPJ sendo autorizado não é transportadora. E também informou tpAutor=3 o que indica uma transportadora autorizando outra.

Sim, veja a propriedade "ImprimeValor" do componente DANFE.

Testei no demo aqui e não duplicou. Consegue fazer um passo-a-passo pra reproduzir?

Acredito que esse problema já tenha sido corrigido.

Acho que nesse caso está havendo um desvio de finalidade. O componente tem que se basear nos manuais dos bancos para os quais o arquivo é gerado e não em intermediários. Sem documentação clara fica difícil de manter. Quem precisa gerar o arquivo para a financeira pode abrir o TXT da remessa e acrescentar a chave.

Na minha máquina de desenvolvimento eu atualizo quase diariamente. Na máquina de build só quando noto alguma correção importante ou alguma funcionalidade nova que vou usar. É bom sempre ficar de olho no log de alterações do SVN.

Sim, é pra permitir o transportador a ter acesso ao XML, depois de a nota já emitida. O evento pode ser feito pelo emitente da NFe ou pelo destinatário, dependendo de quem vai contratar o frete. O transportador depois de autorizado também pode autorizar outras transportadoras a ter acesso à NFe. Transportador autônomo não precisa do XML da nota, certo?

Esta linha vai salvar o XML em disco se o componente estiver configurado pra isso. Essa linha não faz nada a não ser atribuir um objeto a uma variável. Você vai ter o XML na propriedade DocZipItem.XML e o tipo na propriedade DocZipItem.schema, conforme já postei trecho de código mais acima. Você pode usar essas propriedade pra salvar o arquivo em disco, gravar no banco, ou da forma que desejar melhor. A configuração pra salvar automaticamente também já postei mais acima.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Esse código de UF não existe.

Veja que no arquivo *-dist-dfe.xml retornou o schema procNFe_v4.00. <docZip NSU="000000000001894" schema="procNFe_v4.00.xsd"> Isso significa que é o XML completo. Extraindo o conteúdo da tag docZip confirmei que é, então não entendo porque você diz estar recebendo só o resumo...

Pelo XML de retorno houve rejeição sim, o CNPJ informado deve ser emitente de CTe. Isso porque esse evento permite apenas informar transportador e não terceiros.

Tenta o comando svn info pelo prompt. Ou no log do Tortoise ver qual revisão fica em negrito.

O Bradesco vai aceitar o arquivo com 444 posições?