Júlio Cavalcanti

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

Pode nos mandar o CNPJ e o XML que foi gerado?

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Vi que está utilizando Gmail. Ele tem algumas particularidades: Confira se está seguindo os passos corretamente.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Me manda os logs, por favor.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado Conferiu no spam? Se não estiver no spam, nos mande os logs para que a gente possa analisar.

Houve uma migração de tipos e funções para outras units mais específicas. Esse post detalha: No seu caso, a função CSTIPIToStr foi movida para a unit pcnConversaoNFe:

Um momento, vou confirmar.

Bom dia, @hspdv. Fizemos uma pequena correção no componente e na DLL. Testei em meu ambiente alterando o arquivo .ini: Dessa maneira, ao imprimir DANFE simplificada não inclui a informação adicional. A correção estará disponível na próxima compilação da DLL. danfe-exemplo.pdf

Estou utilizando a última versão da lib. Aqui no meu ambiente o retorno está com o Json correto. Veja um exemplo do retorno no log: 14/08/24 09:48:31:048 - NFE_StatusServico 14/08/24 09:48:31:049 - Travar 14/08/24 09:48:31:231 - MoverStringParaPChar. StrLen:261, BufLen:256 14/08/24 09:48:31:231 - SetRetorno(0, { "Status" : { "CStat" : 107, "CUF" : 33, "DhRecbto" : "2024-08-14T09:48:30.000Z", "DhRetorno" : "", "Msg" : "Servico em Operacao", "TMed" : 1, "VerAplic" : "SVRS202401251654", "Versao" : "4.00", "XMotivo" : "Servico em Operacao", "XObs" : "", "tpAmb" : "2" } })

Bom dia, @GO2 Sistemas. O arquivo de log fornecido não corresponde com o método NFE_StatusServico.

Certo, vou realizar os testes.

Qual método você utilizou? Outros métodos retornam dessa maneira? Com o conteúdo do JSON errado

Já que está começando, esse vídeo do @Daniel InfoCotidiano vai te ajudar bastante:

Boa tarde, @Claudiomiro. Com o SVN atualizado, alimentei o boleto com as seguintes informações: O número corresponde com o número gerado pelo banco:

Foi enviado para o SVN a inclusão da cidade Chapadão do Sul. ACBrNFSeXServicos.ini e ACBrNFSeXServicos.res Commit: 34765 CodigoMunicipio.cs Commit: 34766 NuGet Commit: 34767

Foi enviado para o SVN a inclusão da cidade Ubiratã. Commit: 34765.

Caso não tenha conseguido resolver, segue algumas orientações - Utilizar a última versão ACBrLibBoleto. - Faça um teste no programa exemplo. Caso as orientações acima não resolva, me envie os logs. Obs: -2 Indica que houve falhas na finalização da biblioteca.

Olá, pessoal. Foi disponibilizado na ACBrLibBase do pacote ACBrCommon para a linguagem Java, na Rev-34487, um novo método `convertDateToTDateTime` para tornar o objeto do tipo `Date` compatível com o `TDateTime` em Pascal. Esse método é essencial para converter o tipo `Date` do Java em um tipo `TDateTime do Pascal`, permitindo que a biblioteca interprete as datas corretamente. Exemplo de uso: Trecho da implementação: https://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Demos/Java/ACBr Common/src/com/acbr/ACBrLibBase.java /** * Função para converter um objeto do tipo Date em um double compatível com o TDateTime do Pascal * @param date * @return double */ public double convertDateToTDateTime(Date date) { // Obtém o timestamp Unix em milissegundos long unixMillis = date.getTime(); // Converte o timestamp para TDateTime double pascalDateTime = unixMillis / 86400000.0 + 25569.0; return pascalDateTime; }

Consegui resolver, com ajuda dos consultores @antonio.carlos, @EMBarbosa e @danieloliveirasouza. Criamos um conversor para tornar o Date do Java compatível com o TDateTime em Pascal. Logo iremos disponibilizar a correção no SVN.

Peço perdão pela falta de clareza na minha resposta. Eu encontrei algumas inconsistências nos fontes. Foi criado a TK-5750 para realizar as correções e disponibilizar os fontes corrigidos no SVN. No exemplo Java, estamos passando um objeto do tipo Date para representar o intervalo de datas. Ou seja, o tipo Date não é compatível com o tipo de argumento esperado pelo método da DLL, como mostra a mensagem de erro: "Unsupported argument type java.util.Date at parameter 0 of function PIXCD_ConsultarPixRecebidos" Uma solução que encontrei foi representar a data como um número do tipo double (Parece que em Lazarus/Delphi o TDateTime é representado internamente como um número do tipo double). Ainda estamos analisando outras possibilidades para realizar a correção. Sim, pode passar o argumento como uma String vazia `""`

Fiz algumas alterações e obtive sucesso no retorno do método. Foi criado a TK-5750 para realizar ajustes no programa exemplo.

Vou verificar