BigWings

Sim. Pra quem usa o ACBrMonitorPLUS foi disponibilizada uma versão especial:

Faça teste com o demo do componente, veja se acontece o mesmo problema.

Verificou se está sendo informado um CPF válido? Sendo válido, verificou com o suporte da prefeitura ou do provedor o motivo do erro?

A mensagem indica que o protocolo de autorização informado está incorreto, pela expressão regular [0-9]{15} o protocolo deve ter 15 caracteres e está sendo informado 717. O XML também não contém o protocolo de autorização, você pode tentar baixar o XML autorizado no portal do MDFe. https://dfe-portal.svrs.rs.gov.br/MDFESSL/DownloadXMLDFe Ou usar o método Consultar do componente para atualizar o XML com o protocolo de autorização.

Está sendo referenciada como nota em papel modelo 01. A devolução só pode referenciar NFe, nesse caso ela deve ser referenciada na tag refNFe e não na refNF.

Para o Fortes ainda não foi ajustado 100% o layout, foi implementado apenas a impressão do QrCode.

Você só deve copiar as DLLs da pasta MinGW se estiver com a diretiva {DEFINE USE_MINGW} ativada no ACBr.inc. E não deve alterar os nomes.

A nota está sendo referenciada na tag refNFe? Anexe o XML.

Sua versão do FastReport é a Embarcadero? Se for pode ser esse o problema, você precisa da versão 5.x Standard ou acima, para compatibilidade com os fr3 do repositório.

Esse erro significa que a aplicação está tentando carregar DLLs de 32bits. De preferência copie as DLLs para a pasta do executável. Caso contrário, em Windows 64 bits as DLLs de 64 bits devem ser copiadas para a pasta Windows\system32. E veja que o problema não é na compilação e sim na execução do aplicativo.

Geralmente esse erro indica diferença entre a UF informada para a configuração ACBrCTe.Configuracoes.WebServices.UF e a UF do emitente.

Se não me engano precisa adicionar manualmente no library path do Delphi os caminhos para os fontes (*.pas) do ACBr em projetos 64 bits. O instalador não compila em 64 bits nem adiciona os caminhos no library path.

Verdade, entendi errado. Na minha opinião não devia ser impresso. Mas como o fonte atual está sendo é preciso saber o motivo que isso foi inserido. Lembro de ter feito teste recentemente e as tags ObsCont não foram impressas no DANFE. Vou fazer mais testes, mas a princípio concordo com a nova propriedade.

O MOC define que as tags que devem ser impressas no grupo de informações complementares do DANFE são as tags Z02 (infAdFisco) e Z03 (infCpl). Então creio que a sua alteração vai contra a especificação do manual.

Foram enviadas correções para os erros de compilação para o repositório. Favor atualizar os fontes e testar novamente.

Realmente parece ter um problema nos fontes do repositório. Favor usar a opção "Update to revision" do Tortoise, informando a revisão 17740. Até que o problema seja resolvido.

Se informar um código inválido para o tPag ele é redefinido para o tPag padrão (01-Dinheiro). Se não for o caso abra um novo tópico e anexe os arquivos de envio e retorno.

Todos os bancos permitem salvar o extrato em formato de arquivo OFX para integração. O ACBr não tem componente pra isso, mas neste tópico tem indicações de outros:

Já estudou o fonte do ACBr que faz essa conversão? Na unit pcnRetDistDFeInt.pas tem o código: StrAux := RetornarConteudoEntre(Leitor.Grupo, '>', '</docZip'); FdocZip.Items[i].FInfZip := StrAux; StrDecod := UnZip(DecodeBase64(StrAux)); Na terceira linha você deve ter o XML. Basta adaptar para o teu caso.

Não.

Você pode montar a chave de acesso informando os dados da nota pelo método GerarChaveAcesso da unit ACBrUtil. Com a chave basta fazer a consulta pelo ACBrNFe para obter o protocolo de autorização. Claro que você precisa informar todos os dados que compõe a chave, como o código numérico e o tipo de emissão, então se não os armazenou previamente não vai ter a chave correta. Quando a mensagem é de duplicidade com diferença na chave de acesso também é retornada a chave correta.

O cBenef informado parece válido segundo os schemas. Está usando os Schemas disponibilizados em ACBr\Exemplos\ACBrDFe\Schemas\NFe?

O troco na NFCe não está vinculado a uma forma de pagamento, o valor do troco é geral para os pagamentos informados. Na leitura do INI o valor do troco vai ser sobreposto pelo valor informado na última forma de pagamento. Nesse exemplo você deve informar o valor do troco na seção [PAG002] mesmo o troco sendo em dinheiro. Ou repetir o valor do troco em todas os pagamentos.

O webservice não retorna a situação atual da manifestação. Então você precisa controlar isso pela sua aplicação.