BigWings

Apenas remova essas duas linhas.

Correção no SVN, rev. 41129. Obrigado por reportar.

@Daniel Sonda Teste com a unit abaixo. ACBrXmlDocument.pas

Carteira e nosso número do seu PDF não conferem com o JSON de retorno do banco.

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.

A linha onde era pra mostrar a linha digitável correta não está mostrando os DV. E ainda está pedindo o nosso número sem o DV, o que entendi é que você quer informar o nosso número completo, certo? Eu acho que eles não tem essa validação, então a minha sugestão é que homologue com o layout 81 (deixando o ACBr calcular o DV).

Veja a propriedade "ExibeErroSchema" se está ativada, ative pra exibir o erro de validação completo. Validei o teu XML com o demo do ACBr e validou normal.

Não sei que alteração foi essa feita pelo banco, mas essa linha digitável em si está inválida, o DV do terceiro grupo não confere, nem o DV geral. Anexa a planilha alterada.

O ano e mês compõe a chave de acesso, a data e hora de emissão completos só no XML da nota. Se você é o destinatário, transportador ou terceiro autorizado na tag <autXML> pode obter o XML da nota pelo método DistribuicaoDFe. Se é o próprio emitente, não vai conseguir obter o XML a não ser manualmente pelo portal nacional da NFe. Ou entrando em contato com a SEFAZ pra que ela forneça os arquivos. Lembrando que o emitente tem por obrigação legal a guarda dos XML emitidos por ele por um prazo mínimo de 5 anos.

Veja:

Isso seria no endpoint /boletos/segunda-via. Não está implementado no ACBr.

Não, pode usar o layout 81 na API, usar o 810 com CNAB... Aqui eu passei a usar o 810 nos meus boletos, e uso API e CNAB ao mesmo tempo, na mesma carteira, os boletos antigos e os novos, tratando sem problema. A única coisa que precisei cuidar é não gerar em uma mesma remessa misturando os boletos antigos e os novos.

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

Veja a implementação do CalcularDigitoVerificador para o Sicoob: function TACBrBancoSicoob.CalcularDigitoVerificador(const ACBrTitulo: TACBrTitulo ): String; var Num, Res :String; i, base, digito : Integer; LNossoNumero : string; const indice = '319731973197319731973'; begin if fpLayoutVersaoArquivo = 810 then begin Result := ''; Exit; end; [...] Então basta você informar o LayoutVersaoArquivo = 810 antes de chamar o método de consulta.

Por favor melhore a redação da sua pergunta. Veja esse link: Como fazer perguntas inteligentes e receber respostas satisfatórias.

Com LayoutVersaoArquivo = 810 você informa o nosso número completo, 8 dígitos. Com LayoutVersaoArquivo = 81 você informa máximo e 7 dígitos e o ACBr calcula o DV. O Sicoob não valida o dígito, de qualquer forma.

Não, está correto sair <idCSRT>01</idCSRT>. Se está tendo rejeição é algo errado na autorização de uso da SEFAZ-PR. Veja se o emitente da nota fez a solicitação de uso pelo UPD e a software house fez o reconhecimento de usuário.

Identificador do CSRT é a tag idCSRT. O CSRT em si não é mostrado no XML, conforme o manual da NFe.

No modo assíncrono o número do recibo é usado pra fazer a consulta do retorno do lote, e dessa forma ter o cstat de retorno e o protocolo de autorização. No modo síncrono o cstat de retorno e protocolo de autorização vem na própria resposta do envio, então o número do recibo se torna inútil. Por isso ele vem vazio, não existe recibo no modo síncrono.

FManifesto.MDFe.Ide.tpEmis := pcnConversao.teNormal;

Use TipoAmbienteToStr da unit ACBrXmlBase.