Diego Foliene

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

Bom dia! A tarefa está em nosso backlog para ser desenvolvida de acordo com a disponibilidade da equipe de consultores. Vou adicionar um observação de que pediu um status de mesma e verificar a possibilidade de adicionar a mesma no clico atual de desenvolvimento ou no próximo ciclo.

@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.

Fiz um teste forçando¹ na resposta o retorno 302 e mesmo assim não obtive o mesmo comportamento. ¹ Como não tenho os dados de um destinatário com irregularidade, eu peguei o arquivo de resposta que recebi do web service, editei o cStat e a mensagem de rejeição e forcei o carregamento dele na rotina que lê a resposta do web service. A entrada em meu arquivo de Log ficou desta forma: 18/11/2024 12:05:16 - NFe.CriarEnviarNFe("C:\Users\Diego\Documents\Arquivos_INI\NFe\NFe_Teste_Emissao.ini","1",1,0,,1,1,1) 18/11/2024 12:05:16 - OK: [Envio] CStat=103 CUF=31 DhRecbto=18/11/2024 12:05:13 Msg=Lote recebido com sucesso NProt= NRec=3100000ZZZZZZ46 TMed=1 VerAplic=W-3.2.66 Versao=4.00 XMotivo=Lote recebido com sucesso tpAmb=2 [Retorno] CStat=104 CUF=31 ChaveDFe=352411XXXXXXXXXXXXXX55004000000012YYYYYYYY07 DhRecbto= Msg=Nota(s) não confirmadas:12->0- Protocolo= VerAplic=W-3.2.64 Versao=4.00 XMotivo=Lote processado cMsg=0 nRec=3100000ZZZZZZ46 tpAmb=2 xMsg= [NFe12] Id= NomeArq= XML=<protNFe versao="4.00"><infProt><tpAmb>2</tpAmb><verAplic>W-3.2.64</verAplic><chNFe>352411XXXXXXXXXXXXXX55004000000012YYYYYYYY07</chNFe><dhRecbto>2024-11-18T10:44:36-03:00</dhRecbto><cStat>302</cStat><xMotivo>Rejeicao: Irregularidade fiscal do destinatario</xMotivo></infProt></protNFe> cStat=302 chDFe=352411XXXXXXXXXXXXXX55004000000012YYYYYYYY07 dhRecbto=18/11/2024 10:44:36 digVal= nProt= tpAmb=2 verAplic=W-3.2.64 xMotivo=Rejeicao: Irregularidade fiscal do destinatario Apenas para desencargo, por favor, pare a execução do ACBrMonitorPLUS no ambiente, faça novo download no fórum, instale novamente e faça novos testes. Se mesmo assim o problema persistir, serão necessários os arquivos solicitados anteriormente para análise.

Os testes que fiz obtive somente a rejeição de duplicidade, precisaria fazer um teste com um destinatário em irregularidade fiscal para receber o mesmo retorno que recebeu. Por favor, em seu ACBrMonitorPLUS, defina a configuração destacada no print. Feito isso, faça um novo teste. Ele vai dar o mesmo resultado, mas agora vai gerar para você arquivos com -soap no nome no local indicado na configuração. Envie os arquivos com -soap no nome e o Log gerado pelo monitor(conforme minha postagem anterior) para [email protected] com o link do tópico do fórum no corpo do e-mail para posterior identificação.

Bom dia @Lerço Tadeu. Por favor, qual é a versão do ACBrMonitorPLUS que está utilizando? Conferindo no fonte da solução, existe uma validação na rotina de impressão para que a mesma não seja executada caso o status que foi recebido no retorno seja diferente de 100 ou 150. Fazendo um teste com a versão 1.4.0.285 que é a mais recente disponível no fórum, o comportamento ocorreu como o esperado, onde ao enviar um comando CriarEnviarNFe, tanto de forma síncrona como assíncrona, para a UF de SP, com os parâmetros para gerar o PDF e a impressão, inclusive mostrando o preview. Não gerou o PDF, não mostrou o preview e nem fez a impressão pois eu recebi uma rejeição "204 - Duplicidade de NF-e". Por favor, atualize para a versão mais recente do Monitor e faça novos testes. Se o problema persistir, disponibilize o arquivo de Log gerado pelo ACBrMonitor que é configurado na tela do print.

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.

Bom dia! Por favor, verifique qual é o valor que está chegando em seu código nesta linha: //... infoRegimeTrab.infoCeletista.cnpjSindCategProf:=Sindicato.CNPJ; //... Observando na rotina que gera o XML existe está condição: if objAltContratual.Vinculo.infoRegimeTrab.InfoCeletista.cnpjSindCategProf <> '' then GerarInfoCeletista(objAltContratual.Vinculo.infoRegimeTrab.InfoCeletista) else GerarInfoEstatutario(objAltContratual.Vinculo.infoRegimeTrab.InfoEstatutario); De acordo com o seu código, deveria estar gerando a o grupo InfoCeletista, mas de acordo com a mensagem de erro que está enfrentando, está sendo gerado o grupo InfoEstatutario, o que indica que o cnpjSindCategProf está ficando vazio. Você pode colocar um break-point no local indicado pelo print para acompanhar.

Boa tarde! Se você conferir no Log, é possível observar que ele tem informações como a URL a qual é feita a requisição, o método, o body, entre outros. Por favor, configure o Log no nível mais alto para se certificar de que ele exibe todas as informações envolvidas na requisição e munido delas, faça um teste utilizando o PostMan para confirmar se é devolvido retorno diferente.

Boa tarde! A lista vai iniciar do zero, então na inclusão de 5 títulos, ficaria como o primeiro 0, 1, 2, 3, 4. Ambos o Boleto_GerarPDFBoleto e o Boleto_SalvarPDFBoleto com a diferença de que o último vai te devolver o PDF na resposta em Base64. Então você pode utilizar apenas um deles, não precisa dos dois.

Boa tarde! Sendo ambiente Windows, acho que talvez não seja o caso, mas é válido verificar. As fontes True Type da Microsoft estão instaladas no ambiente?(Já tivemos relatos onde ausência delas estava causando comportamento inesperado no impresso). Também vou lhe pedir que faça um teste alterando o valor de AlterarEscalaPadrao em seu arquivo INI na seção [BoletoBancoFCFortesConfig] para o valor 1(em seu print está com o valor zero). Essa configuração geralmente costuma ser utilizada quando há zoom aplicado no monitor e portanto, ela também pode interferir no resultado do impresso. Agora com o valor zero, ela está com o equivalente a "Não", defina o valor "Sim" para que o NovaEscala seja aplicado.

Boa tarde! SLA seria a sigla para Service Level Agreement Muito obrigado, tópico movido para o local adequado. Criada a #TK-6236 para análise do caso e parecer por parte da equipe de consultores. Qualquer novidade será divulgada neste tópico.

Boa tarde! Por favor, qual é o erro que está enfrentando preenchendo o evento desta forma que disponibilizou?