BigWings

O assunto já está sendo tratado aqui:

Já é feito tudo automático pelo componente. Sobre os diferentes métodos de envio da NFSe, veja:

Na NFSe é gerado inicialmente o RPS (Recibo Provisório de Serviços). Esse RPS é enviado para o webservice disponibilizado pela prefeitura e é convertido em NFSe. Você deve verificar na legislação municipal qual o procedimento adotado em relação a esses dois documentos, se pode ser entregue o RPS para o tomador do serviço, qual o prazo para a conversão do RPS em NFSe, etc. O componente ACBrNFSe não faz impressão do RPS, apenas o DANFSe da NFSe.

Como disse, é algo com a instalação do FastReport, não tem a ver com o ACBr. Tente desinstalar e instalar ele novamente.

Essa unit é do FastReport. Indica fontes e binários (dcu) de versões diferentes do FastReport na máquina. Tente compilar usando a opção "Build" em vez de Compile.

Validando esse XML pelo programa exemplo do componente e usando os Schemas da pasta ACBr\Exemplos\ACBrDFe\Schemas\NFe acusou apenas falta da assinatura: 1871 - Element '{http://www.portalfiscal.inf.br/nfe}NFe': Missing child element(s). Expected is one of ( {http://www.portalfiscal.inf.br/nfe}infNFeSupl, {http://www.w3.org/2000/09/xmldsig#}Signature ). Após assinar ocorre erro na tag uTrib que não está informada: 1824 - Element '{http://www.portalfiscal.inf.br/nfe}uTrib': '' is not a valid value of the local atomic type. Preenchendo as tags uCom e uTrib nos itens a nota é validada. Sugiro então que verifique novamente a pasta de schemas. Nesse ERP usam o componente ACBrNFe?

Está usando ACBrMonitorPLUS?

Configurando SSLCryptLib como cryCapicom também deve retornar em ordem invertida.

Anexe o XML.

A pasta de schemas está atualizada?

Está recebendo essa rejeição em produção? Pela última atualização da NT 2020.001 a implementação dessa regra em produção foi postergada para 06/07/2020, em virtude da pandemia.

No caso da implementação para a geração do campo Convênio (rev. 19890) encontrei este tópico:

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

Você ainda não disse exatamente qual campo quer informar no DANFE... Apenas no CSOSN 900 é destacado ICMS. Nesse caso ele vai ser mostrado no DANFE. Nos CSOSN 101 - tributado pelo simples nacional com permissão de crédito não existe destaque de ICMS, apenas informação do ICMS que o destinatário pode se creditar. Então em vez da tag pICMS e vICMS apenas o valor é informado na tag vCredICMSSN. O manual é claro em especificar quais tags exige em que campo: A TAG N16 corresponde à aliquota do ICMS normal: O manual também não proíbe de se incluir campos desde que eles estejam no XML, e que não seja informado no local destinado a outro campo, como é o caso da alíquota do ICMS, então você pode fazer isso se desejar.

Não precisa forçar brancos, basta não preencher o "0" no convênio, que pelo que entendi é o que está fazendo. As alterações são feitas para atender a todos, e alguma cooperativa desse banco exigiu o convênio no header. Sugiro que sempre analise as alterações feitas nos fontes quando atualizar.

Geralmente Simples Nacional não destaca ICMS ou IPI. E no DANFE se pode mostrar apenas o que está no XML. Quais dados exatamente você quer mostrar no DANFE?

Está informando algo para o convênio ao alimentar o componente? Foi feito um ajuste na rev. 19890 para gerar o convênio, apenas se informado:

Pacotes runtime você apenas compila, os designtime são para instalar na IDE. Veja:

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

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

Aparentemente você adicionou um nó infUnidTransp e não preencheu o valor dos campos. Verifique a sua rotina.

Anexe os XML de envio e retorno (*-eve.xml, *-ped-eve.xml) para análise.

O campo qVol no layout é numérico, não permite decimais. Se alterar dessa forma você vai ter erro de validação por schemas. Quantidade de volumes transportados não é o mesmo que quantidade transportada.

Imprimir algo no DANFE diferente de como está no XML vai contra o manual e isso sim pode causar autuação. Aqui nos casos em que o usuário insiste em mostrar a quantidade em M3 nos volumes transportados orientamos a informar multiplicado por 1000 e truncando as casas decimais. Ex.: 10,83 M3 = 10830 2 M3 = 2000 5,8743 M3 = 5874 Dessa forma não deve ter problema com a fiscalização.