Diego Foliene

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.

Estamos analisando o conteúdo dos arquivos de Log e também o método no fonte da Lib. Assim que houver novas informações divulgamos neste tópico.

Bom dia! A nova compilação foi gerada hoje de manhã. Por favor, as Libs CT-e e MDF-e também foram atualizadas? Se sim, o problema é o mesmo de antes ou a mensagem de erro é diferente?

Olá pessoal! No dia 18/11/2024 foi publicado o Informe Técnico 2023/001 em sua versão 1.10. Este informe atualiza a Tabela de Códigos de Produtos da ANP adicionando os 16 novos códigos: 840101003, 840101004, 620101009, 610502001, 610502002, 620501003, 620503001, 420107001, 611402001, 611302001, 610601002, 610702001, 611501001, 611401001, 611402002, 610503001. Datas Implantação Teste: Até 28/11/2024 Implantação Produção: Até 16/12/2024 conforme UF autorizadora O informe técnico pode ser lido na íntegra AQUI. A tabela atualizada pode ser encontrada AQUI. Um agradecimento ao membro de nossa comunidade @Andreas Otowicz por compartilhar a informação em nosso Discord.

Bom dia! Foram geradas novas compilações das Libs englobando os ajustes previamente mencionados. Por favor, queira atualizar para realizar novos testes e reportar qualquer problema.

Boa tarde! Foi enviado ao SVN um ajuste visando resolver está questão. Compilações da Lib geradas depois das 17h58 do dia 18/11/2024 deverão englobar o mesmo. Assim que houver nova versão, notificamos aqui para que possa atualizar a realizar novo teste.

Muito obrigado. Vamos analisar as informações disponibilizadas e damos um retorno assim que descobrirmos algo.

Foi criada a #TK-6237 para análise do caso e parecer por parte da equipe de consultores. Por favor, o arquivo de Log que disponibilizou é o Log específico para o PIXCD. Peço que disponibilize também o Log próprio da Lib. O caminho onde ele será salvo e seu nível são configurados na seção [Principal] em seu arquivo ACBrLib.ini nas propriedades LogPath e LogNivel.

Bom dia! Você havia mencionado anteriormente estar utilizando a versão 2.0.1.41 da Lib. Atualmente nós estamos na versão 2.0.1.56. Por favor, pode atualizar e realizar novo teste para confirmar se o problema ainda persiste.