Diego Foliene

Bom dia @douglaswf! O método ConsultarNFSeServicoTomadoPorPeriodo foi feito de forma a atender os provedores da melhor forma possível. No entanto, alguns provedores(como é o caso de SP), requerem algumas informações a mais que não previstas no método. Para atender a casos assim, foi criado o ACBrNFSeX.ConsultarNFSeGenerico, demonstrado no programa exemplo pelo botão "Consultar NFSe Genérico". Por favor, faça um teste com o mesmo.

Boa tarde! Pelo que pude averiguar, a modificação foi feita apenas nas classes de impressão da NF-e. Meu amigo @Victor H. Gonzales - Panda pode fornecer informações mais específicas, mas acredito que isso não tenha sido feito para NFC-e por não ser um comportamento esperado para a mesma. (Geralmente NFC-e é gerada em EscPos, onde não é possível gerar o PDF. E mesmo nos casos em que é usado o impresso em Fortes, no processo da NFC-e, no geral, você transmite a nota e já gera o cupom para o cliente, não sendo tão comum a reimpressão ou PDF para o mesmo). Portanto, se a classe que tiver definido em sua propriedade .DANFe for ACBrDANFCeFortesFr, ACBrDANFCeFortesFrA4 ou ACBRNFeDANFeESCPOS a modificação mencionada no tópico não é considerada.

Boa tarde! Foi criada a #TK-6251 para análise da contribuição 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

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.