Diego.Foliene

Não tem nada na caixa de spam ou lixeira? Se você logar no fórum não tem nenhuma mensagem ou informação relacionada? Apenas para confirmar. Seguindo a aula que há no curso, você conseguiu passar pela etapa das credências. (Deu certo de configurar as informações e de usar o botão "Solicitar Certificado"). O problema ocorre quando vai testar um fluxo de pagamento, quando vai gerar uma cobrança, é isso?

Bom dia! Se você tentar acessar abrir um chamado no portal pelo link: https://devportal.itau.com.br/baas/#/suporte-contato não recebe nenhum retorno? Caso já não o tenha feito, por favor, adicione as Dlls deste LINK dentro da mesma pasta do .EXE que foi disponibilizado e faça um novo teste.

Conferindo no último log que disponibilizou no Discord, este é o retorno que recebeu: Apesar de ele não ter uma mensagem, realizando algumas pesquisas por "Sock.LastError: 10054", encontrei alguns links relacionando este código de erros a problemas de TLS. Conferindo na unit do PSP Itau, me parece que o mesmo faz uso do Lt_all por padrão ao invés do TLS1.2. Em anexo, deixo um .EXE, com uma alteração que define o valor TLS1.2 para ser usado na conexão. Por favor, tente realizar um novo teste com o mesmo. PIXCDTeste.7z

Apenas por desencargo, por favor, consegue realizar um teste usando o anexo de minha postagem anterior? Ele é o .EXE utilizado no curso, talvez seja mais fácil acompanhar. Se der certo com ele, podemos comparar os logs gerados para ver se encontramos algum problema.

Desculpe, esta parte não ficou muito clara. O app de exemplo aqui seria o app de exemplo da Lib? Com ele você consegue comunicar tanto em homologação quanto em produção, mas quando tenta com a sua aplicação ocorre o problema? Você consegue realizar um teste com este .EXE do programa de exemplo nativo para Delphi/Lazarus?

Conferindo nas mensagens do Discord, lhe foram passadas algumas instruções para que pudesse realizar um teste com o PostMan para confirmar se o problema seria na API do PSP ou se a forma como o componente comunica com a API precisasse ser revista. Foi feito o procedimento?

Tópico vinculado a tarefa #TK-6291 criada para análise do caso e parecer por parte da equipe de consultores.

Boa tarde! Salvo engano, você mencionou no Discord que está partindo para o uso em produção com o PSP Itaú, correto? O problema relatado neste tópico ainda persiste? Se testar em produção a API do PSP ainda devolve uma informação incorreta?

Foi publicada a versão 24.2.E das tabelas fornecidas pelo IBPT, as quais já se encontram também em nosso SVN. As novas tabelas tem a vigência de 20/11/2024 até 31/01/2025. Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto", não se esqueça de realizar a atualização de seus clientes. Fonte: De Olho no Imposto

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

Foi enviado uma ajuste. Por favor, queiram atualizar, reinstalar o ACBr e realizar novos testes.

Bom dia! Obrigado por reportar. Vamos verificar.

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

Olá pessoal! Foi publicada a versão 5.0.0 do Programa Validador de Escrituração Digital EFD ICMS IPI com as alterações de leiaute válidas a partir de janeiro de 2025. A versão 4.0.7 poderá ser utilizada para transmissão dos arquivos da EFD até 31/12/2024. Fonte: http://sped.rfb.gov.br/pagina/show/7605

Olá pessoal! Na tarde do dia 18/11/2024 o Sebrae promoveu junto aos auditores fiscais da Receita, Carlos Nacif e Hermano Toscano, uma Live para detalhar duas mudanças previstas para 2026 para todos os empreendedores. Dentre as mudanças mencionadas, uma delas se refere a unificação da emissão de NFS-e em todo o país utilizando o Padrão Nacional. Está mudança está prevista para Janeiro de 2026, sem uma data específica. As informações acima foram retiradas de notícia originalmente publicada pelo Sebrae e que pode ser lida na íntegra AQUI. Relembrando. No contexto da NFS-e, não há um leiaute único. Cada administração municipal pode optar por contratar através de licitação uma empresa que fornece o web service de emissão de notas de serviço (nós do ACBr chamamos esta empresa de "provedor"). Este web service pode ser implementado seguindo um leaiute da maneira que o provedor preferir, causando assim, no cenário da NFS-e, uma falta de padrão. O Padrão Nacional, como o nome diz, é um padrão que foi criado com o objetivo de centralizar isso, acabando com os padrões próprios utilizados. No entanto, apesar do nome Padrão, sua adesão até o momento desta publicação, é obrigatória apenas para os MEIs com adoção opcional para os outros casos. Nesta adesão opcional, até o momento, 1.140 cidades estão conveniadas, sendo 22 capitais. (Você pode conferir a lista completa AQU). O que se espera é que em 2026 todos estejam emitindo pelo Padrão Nacional. Também é importante lembrar! O componente nativo para Delphi/Lazarus e consequentemente o ACBrMonitorPLUS e a ACBrLib já estão adequados ao Padrão Nacional e podem ser utilizados para emissão de nota no mesmo. O tópico abaixo traz mais informações a respeito:

Boa tarde! Foi enviado um ajuste visando corrigir esta questão. Por favor, queira atualizar seus fontes, reinstalar o ACBr com a opção "Apagar Arquivos Antigos" marcada para realizar novos testes e reportar qualquer problema.

Boa tarde! A API PIX do PSP Itaú segue o padrão proposto pelo Bacen. Se conferirmos na documentação deste padrão, podemos observar que o campo original no JSON deve ser um valor numérico que é o esperado pela Lib no momento de realizar a leitura: O que significa que o valor que lhe foi devolvido na resposta pela API do próprio PSP, NÃO É um valor válido: "valor": { "original": "{{body_valor_original}}", "modalidadeAlteracao": "0" }, A equipe de consultores ainda está analisando se é possível realizar alguma alteração do lado da solução ACBr, no entanto, também É MUITO IMPORTANTE, que você abra um chamado junto ao suporte do PSP para relatar o erro para eles.

Olá pessoal! Conferindo no Portal da Nota Fiscal Eletrônica, é possível observar que a Sefaz de São Paulo está com contingência agendada para o dia 24/11/2024, com previsão de início às 06h00 e encerramento às 11h00 do mesmo dia. Para utilizar as soluções ACBr em contingência durante este período siga as orientações do tópico abaixo: Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a informação em nosso Discord.

Bom dia! Foi criada a #TK-6258 para análise do caso e parecer por parte da equipe de consultores. Qualquer novidade será divulgada neste tópico.

Olá pessoal! No dia 19//11/2024 foi publicada notícia no portal do e-Social, informando que desde 24/10/2024 já não é mais permitido o envio dos eventos para Pagamentos de Rendimentos do Trabalho(S-1210) e para Informações Decorrentes de Processo Trabalhista(S-2510) com período de apuração(perApur) ou período de apuração pagamento(perApurPgto) com valor igual ou posterior a 01/2025 na versão S-1.2. Isso foi feito porque estas informações enviadas na versão S-1.2, não serão internalizadas no Extrator da DIRF para o ano-calendário de 2025. Somente as informações do evento S-2501, enviadas na versão S-1.3 serão internalizadas pelo Extrator. Portanto, a partir da versão S-1.3 – 02/12/2024 –, e somente nessa versão, será liberada novamente o envio de evento e S-2501 com período de apuração futuro para os eventos enviados a partir de janeiro/2025. Quem já enviou os eventos referidos na versão S-1.2 com a informação de apuração para 2025, deverão retificar o evento enviando novamente na versão S-1.3 para serem considerados. Leia a notícia original na íntegra AQUI. Lembrando que o componente ACBreSocial já foi compatibilizado com a versão S-1.3 e as referidas modificações foram englobadas na Lib e no Monitor.

Olá pessoal! No dia 13/11/2024 foi publicada a versão 1.05 da Nota Técnica 2015/002 para o CT-e. Esta nota técnica trata sobre o web service de Distribuição de DF-e para o CT-e. A nova versão adiciona o CT-e Simplificado como um documento a ser devolvido pela distribuição, para o Tomador e também para Terceiros. Com esta nova versão, o CT-e, CTe-OS, GTV-e e agora o CT-e Simplificado são devolvidos para os participantes de acordo com o quadro abaixo: Datas As datas tanto do ambiente de homologação quanto do ambiente de produção estão como 21/10/2024, dando a entender que a NT já está em vigor em ambos os ambientes. Vale lembrar: A solução ACBr já implementa o processo de Distribuição DFe para o CT-e. Leia a versão 1.05 da Nota Técnica na íntegra AQUI.

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

Olá pessoal! Foi publicado no dia 13/11/2024, no portal SPED, comunicado informando sobre a versão 10.0.14 do programa ECF utilizado para transmitir arquivo do ano-calendário 2023 e situações especiais de 2024(leiaute 10). A nova versão trás as seguintes atualizações: Fonte: http://sped.rfb.gov.br/pagina/show/7599

@Jamil Araujo, conferindo em ambos seus arquivos de Log, temos no retorno a chamada do método EnviarEmail a seguinte resposta: Conferindo no fonte do método, a lógica aplicada é: 1º A Lib verifica se o segundo parâmetro que foi passado é um arquivo ou o conteúdo do mesmo. 2º Se for um arquivo, a Lib verifica se o mesmo existe. 3º A Lib carrega o conteúdo do referido arquivo na memória da biblioteca, alimentando assim um documento na Lista. 4º A Lib verifica se a lista de documentos na memória está vazia e se estiver, devolve o retorno que recebeu. Seu processo parece estar falhando no passo 3. Por favor: Confirme se o arquivo XML existe no local indicado. (Em seu exemplo: /home/jamil/trampo/11/danfe/) Verifique se o XML que está sendo passado é válido(tente abrir ele para ver se não há nenhum erro de estrutura, por exemplo, ou se ele é o XML do documento de fato ou se tem informações a mais, como tags de envelope por exemplo). Faça um teste utilizando o comando de impressão para confirmar se a Lib carrega o XML corretamente.