BigWings

No validador da SEFAZ-RS esse XML acusa rejeição 694, pela falta do grupo ICMSUFDest no item 2. Parece mais correto que a rejeição 793... mas o problema deve ser o mesmo. No seu XML você está informando o grupo ICMSUFDest no item 2?

Em vez de usar o método mais interno, porque não usar o método ACBrGNRE1.Enviar? Ele já faz a chamada a ACBrGNRE1.Guias.GerarGNRE que gera os XML, envio, tratamento do retorno e opcionalmente a impressão da guia.

Ciência de emissão não constitui manifestação definitiva, após o envio do evento de Ciência de emissão a empresa deve enviar nova manifestação definitiva num prazo estabelecido pela SEFAZ do estado. As demais manifestações são definitivas, caso seja enviada manifestação de Confirmação, Desconhecimento ou Operação não realizada por engano, o destinatário ainda pode enviar nova manifestação para corrigir a anterior. A correção pode ser feita uma única vez. Então uma nota pode ter até 3 manifestações, valendo a última enviada.

Talvez algum antivírus ou programa de cloud (ex. Dropbox) esteja bloqueando o arquivo entre o momento que ele é criado (após a assinatura) e o momento que ele é atualizado com o protocolo de autorização (retorno do envio). Experimente habilitar a propriedade ACBrNFe.Configuracoes.Arquivos.SalvarApenasNFeProcessadas.

ESC/POS realmente não vai gerar PDF ou imprimir em impressora laser/jato de tinta, ou mesmo preview de impressão, já que ela envia comandos de impressão que devem ser interpretados pela na impressora. A única opção nesse caso seria a versão em Fortes.

Que "arquivo" Fortes Report você está precisando? Se você não tem o Fortes instalado: Se já tem o Fortes instalado precisa na instalação do ACBr marcar para instalação o componente DANFE para Fortes. Se já fez isso também basta adicionar o componente ACBrNFeDANFCeFortesA4 e vincular ao ACBrNFe.

No caso do extrato SAT não foi implementado para Fast Report. As opções são a versão em Fortes e a em ESC/POS.

A imagem é da impressão da NFCe em Fortes Report. Você pode usar o componente para Fortes. Ou modificar o fr3 a seu gosto.

Você precisou fazer alguma alteração nos fontes ou informar 0.001 para as tags? Achei estranho estar exigindo valores já que pelo arquivo de schema eles são opcionais...

No XML do CTe existe uma parte geral e uma parte por modal (rodoviário, aéreo, ferroviário, etc), cada CTe só pode ter um modal. No manual mais a frente você tem os trechos da estrutura de cada modal. Você define o modal na tag Ide.modal dessa forma o componente define qual grupo gerar.

Bem poucos provedores incluem a informação sobre o ambiente no XML, então o componente usa a configuração ACBrNFSe.Configuracoes.WebServices.Ambiente do componente ACBrNFSe para determinar a impressão da mensagem de homologação no DANFSE. Verifique então se está configurando corretamente. Atualizar os fontes, ou apenas reinstalar selecionando a opção de apagar os fontes antigos, pode resolver também.

Você está usando o DANFSE em Fortes ou Fast Report? Seus fontes estão atualizados? Um tempo atrás houve um bug numa revisão dos fontes que causou a impressão indevida dessa mensagem no DANFSE em Fortes.

Enviei um ajuste para o repositório para gerar o XML na estrutura do schema do provedor DeISS, rev. 19773. Faça um backup da sua unit, depois atualize os fontes e reverta as tuas alterações. Depois reinstale o ACBr pelo ACBrInstall_Trunk2, selecionando a opção de apagar arquivos antigos, recompile a sua aplicação e teste novamente.

A configuração SSLLib para assinatura é a SSLXmlSignLib, caso esteja em xsNone vai gerar a exceção. E o arquivo que você anexou inicialmente está assinado, então deve ter alterado algo aí na configuração. Qual erro? Nesse caso pode não ter relação com a tag OutrasRetencoes, e sim ser alguma informação que deveria ser informada antes e não consta no XML.

Acho que já é outro caso, o primeiro é erro de validação, dizendo que a tag OutrasRetencoes não deveria estar no XML. Essa exceção só vai ser gerada se você deixar de configurar as propriedades SSLLib, nem chegaria a montar o XML para validar.

Parece um erro interno do webservice. Já tentou contato com eles?

Apenas observando que RO não permite a consulta de cadastro, assim como a maioria das UF que utilizam a SVRS. Esse comando deve ter o retorno "Rejeicao: Sigla da UF da consulta difere da UF do Web Service".

Provavelmente vai ser necessário algum ajuste nos fontes, ou atualização dos arquivos de schema. Pelo que vi foi inserido recentemente a geração dessa tag, numa contribuição do @Carlos Júnior que o @Italo Jurisato Junior commitou. Talvez eles tenham mais informação sobre o assunto.

Veja a propriedade DetRastros do componente DANFE.

Em produção ainda não está disponível a manifestação por pessoa física. Está previsto para 11/05/2020, pela NT 2020.001.

O código da UF informado na consulta está inválido. <cUFAutor>55</cUFAutor> Não existe UF 55 na lista.

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

Existem várias propriedades que, dependendo da cidade/provedor, é necessário preencher ou não. O componente geralmente dispara uma exceção caso necessite.