BigWings

Consumo indevido pode ser por outra aplicação ou outro alguém de posse do certificado estar fazendo a consulta no intervalo de 1h entra a consulta nessa aplicação e a sua. Como disse antes, o ultNSU para continuar consultando vai retornar pra aquele de 90 dias atrás... ainda não entendi a surpresa.

Quando você informa 0 para o ultNSU vai receber os 50 primeiros NSU dos últimos 90 dias, então é normal que o ultNSU retornado nessa consulta seja menor.

Atualize o seu .FR3 com o do SVN.

Veja se a pasta dos logos está atualizada. https://svn.code.sf.net/p/acbr/code/trunk2/Fontes/ACBrBoleto/Logos

Os arquivos que anexou estão válidos, a pasta de schemas que deve estar desatualizada, basta atualizar com os xsd disponibilizados em \ACBr\Exemplos\ACBrDFe\Schemas\NFe.

Você deve estar usando o Fast Report que vem junto com o Delphi, ele não tem suporte a scripts e assim não tem atende aos .fr3 do SVN. Pra resolver você pode: - Adquirir a versão comercial do Fast Report - Standard ou acima. - Instalar o Fortes Report que é open source e usar os componentes pra esse report: https://github.com/fortesinformatica/fortesreport-ce - Usar os arquivos *-BASIC.fr3 que estão na pasta Obsoletos do SVN. Atenção que eles estão sem manutenção há um bom tempo.

Nesse tópico apenas incluímos o schema, não foi feito o tratamento do retorno no caso de GTVe.

Já viu como é feito no programa exemplo do componente?

Informe na tag própria do XML que vai ser mostrado no DANFE.

Testei com um dos arquivos dessa pasta, aqui deu certo.

Tente adicionar a unit ssl_openssl no uses.

Veja o tópico:

Página 15, observações da tag indIEDest.

De acordo com o manual, para NFCe sempre deve-se informar IE em branco e indIEDest = 9 (inNaoContribuinte).

https://acbr.sourceforge.io/ACBrLib/NFE_Enviar.html

No SVN.

Use este arquivo: https://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrDFe/ACBrNFe/Delphi/Report/DANFeNFCe5_00.fr3

O mesmo problema foi relatado no Discord. https://discord.com/channels/798697718800318484/800713511936196608/991736035572727988

No Firebird 4.0 pode usar a LAST_DAY() select last_day(of month from current_date) from RDB$DATABASE Em versões anteriores pode tentar algo como: select cast('01.' || extract(month from dateadd(month, 1, current_date)) || '.' || extract(year from dateadd(month, 1, current_date)) as DATE) - 1 from RDB$DATABASE

É possível sim, nenhum problema... CT.Imp.ICMS.SituTrib := StrToCSTICMS(ok, '60'); [...] case CT.Imp.ICMS.SituTrib of [...] cst60: begin CT.Imp.ICMS.ICMS60.CST := CT.Imp.ICMS.SituTrib; CT.Imp.ICMS.ICMS60.vBCSTRet := ; CT.Imp.ICMS.ICMS60.vICMSSTRet := ; CT.Imp.ICMS.ICMS60.pICMSSTRet := ; CT.Imp.ICMS.ICMS60.vCred := ; end;

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

A mensagem indica rejeição no CTe no. 3505280, você anexou o XML do CTe no. 3505303. Veja a descrição do cStat 799: Se você informar tomador no grupo toma4 com CPF ou CNPJ de participante do CTe (remetente, destinatário, recebedor, expedidor) vai ter essa rejeição. O correto nesse caso é informar a tag toma3.toma.

Eu ia indicar que você usasse OpenSSL, que não depende do sistema operacional. Mas pelo jeito está tendo o mesmo problema. Nos meus testes com o WS de MG está tudo ok, com WinCrypt ou OpenSSL, produção ou homologação, NFe ou NFCe. Tente trocar pra OpenSSL, e veja se está com as DLLs atualizadas: https://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/1.1.1.10/X86 Certifique-se também que está configurando SSLType = LT_TLSv1_2. A configuração do IE não interfere quando SSLHttpLib é httpWinHttp ou httpOpenSSL.