Diego Foliene

Olá pessoal! No dia 13/08/2024 foi publicada a versão 1.02 desta nota técnica. Alterações Os valores que definem o tipo do CTe (tag: tpCTe) foram alterados, agora os valores são 5 para CTe Simplificado e 6 para Substituição CTe Simplificado (anteriormente 4 e 5 respectivamente). A versão mais recente também corrige o texto das regras de validação G008, G057 e G063 para refletir os novos valores. Por fim, ela também separa os cStat devolvidos pelas regras G015 e G016, onde na versão anterior ambos devolviam 941 e agora devolvem 941 e 942 respectivamente. Datas Implantação Homologação: 16/09/2024 Implantação Produção: 21/10/2024 E como fica o ACBr? Temos uma TK em nosso backlog para implementação do CTe Simplificado. A alteração de TpCTe deverá ser levada em conta no momento da implementação. Leia a versão 1.02 desta nota técnica na integra AQUI.

Olá pessoal! No dia 13/08/2024 foi publicado a versão 1.63 desta nota técnica. Alterações A nova versão adequa os textos das regras de validação 5E17-10, 5E17-30, 5E17-46, 5E17-80, 6P31-30 e 6P31-46 removendo de todas elas a observação (*7) que correspondia a: Criada a regra de validação I05g-10 que pode ser ativada a critério da UF e valida se o grupo de informações sobre crédito presumido (tag: gCred) é permitido para respectiva unidade federativa. Datas Altera a data de ativação em produção das regras de validação relacionadas ao cBenef por CST no DF: Implantação Teste: 05/10/2020 (Mantida conforme versões anteriores) Implantação Produção: 02/09/2024 As alterações nas regras de validação e a nova regra criada, ambas mencionadas na seção "Alterações" acima entram em vigor com o seguinte cronograma: Implantação Teste: 02/08/2024 Implantação Produção: 02/09/2024 E o que muda no ACBr? Como a NT traz apenas alterações nas regras de validação da Sefaz, modificações nos fontes do ACBr não são necessárias. Leia a versão 1.63 desta nota técnica na íntegra AQUI.

Bom dia! Foi criada a #TK-5857 para análise do caso e parecer por parte da equipe de consultores.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-5853

Bom dia. Complementando a resposta do meu amigo @Juliomar Marchetti: \ACBr\trunk2\Projetos\ACBrLib\Demos\PHP E também:

Olá pessoal! Conferindo na página Sobre a NF-e consta um aviso informando que foi disponibilizado no ambiente de testes um autorizador síncrono para NF-e. Aviso reproduzido na íntegra: Síncrono... Assíncrono... que raios é isso?! Na transmissão de documentos fiscais, o envio para o web service pode ocorrer de duas maneiras. No envio assíncrono, o XML é enviado para o web service, que devolve um número de recibo. Em seguida, o emissor faz uma nova conexão com o mesmo web service para consultar o número de recibo e receber o resultado do processamento. No envio síncrono, o XML é enviado para o web service, que já devolve o resultado do processamento na mesma resposta, ou seja, tudo é feito em uma única conexão. E por que isso é importante? Apesar de existir as duas formas de envio, recentemente alguns documentos fiscais tem adotado exclusivamente o modo de envio síncrono e desativando o modo assíncrono. Isso aconteceu com a NFC-e: Com a versão 4.00 do CT-e: Com o MDF-e: E logo com a NF3e também: Para a NF-e especificamente, ainda existe ambos os métodos, com exceção de SP e BA que não aceitam o modo síncrono. Esse aviso indica que a Sefaz de SP está caminhando para que isso não seja mais o caso e ela passe a aceitar o envio síncrono também. O que pode ser um passo para que a NF-e também mude somente para o modo síncrono futuramente. Está edição do Papo PRO traz considerações sobre as formas de envio: Um agradecimento ao membro de nossa comunidade @Felipe Marianopor compartilhar a informação no canal #sefaz em nosso Discord.

Olá pessoal! Conferindo na página SPED MG na área específica para NF-e, consta um aviso informando que no dia 09/08/2024, à partir das 18h00 será realizada uma atualização do ambiente de infraestrutura da Sefaz de Minas Gerais. Não há previsão de indisponibilidade, no entanto, os serviços de autorizações de Documentos Fiscais Eletrônicos – NF-e, CT-e, CT-e OS e BP-e podem apresentar instabilidade e variação no tempo de resposta durante este período. O processo de manutenção tem previsão inicial de ser concluído às 08h00 do dia 12/08/2024.

Boa tarde! No componente nativo para Delphi/Lazarus existe uma propriedade ImprimeCanhoto. No entanto, pelo que pude averiguar, a mesma não é implementada no Monitor e na Lib. Criada a #TK-5840 para a adição da mesma em ambas as soluções.

Muito obrigado por todo o apoio e pelas informações @fredsmartfull. Com certeza quando disponibilizarmos o provedor e criamos um tópico para informar a comunidade, vamos lhe dar os devidos créditos.

Bom dia! Em minha postagem anterior, no "Tópico³" tem informações de como pode buscar a informação. Nesse mesmo tópico, um colega disponibiliza um print de uma tela. Veja se não consegue acesso semelhante. Pelas informações, acredito que seria o acesso do prestador.

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

Bom dia! Você utiliza componente nativo para Delphi/Lazarus, ACBrMonitor ou ACBrLib?

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-5837

Bom dia! Sim! A princípio, a assinatura parece estar correta de acordo com as informações. Conversando com os demais consultores, parece que apesar das informações que indicam ser um novo provedor, ainda é o Ginfes que atende a este município. Por isso, vamos dividir sua situação em dois frontes. Na #TK-5831 vamos focar em deixar o Giss operacional*. * Com as modificações efetuadas, já é possível comunicar com o web service, mas estamos recebendo uma rejeição que indica um problema no arquivo. Nosso objetivo, como não temos dados válidos é receber um rejeição de CNPJ do prestador não autorizado ou algo do gênero, que indique que o problema está nos dados informados e não na estrutura do arquivo. EM PARALELO, vamos voltar ao problema inicial que é você estar recebendo a rejeição "Código de Tributação Inexistente". Nos arquivos que disponibilizou a tag <CodigoTributacaoMunicipio> está com o valor "465" apenas. Esta informação está correta? Buscando mais informações a respeito deste erro aqui no fórum, em outro tópicos as respostas dos colegas deram a entender que o essa informação é maior. Neste TÓPICO¹, um colega informa que usa um valor de até 17 casas decimais considerando espaços em branco e caracteres(14.01 / 331399900 neste exemplo). Já neste outro TÓPICO², um colega disse utilizar 1.07/1.07.00/1869. Por fim, neste TÓPICO³, um colega utiliza uma informação um pouco diferente, mas ainda assim com mais caracteres do que a que está utilizando. Por favor, confira no Acesso do Prestador no Portal se o valor 465 está correto. Se ele tiver zeros a esquerda ou caracteres especiais, faça um teste passando este valor. Mesmo que o XML que conseguiu no portal esteja com o valor 465, ele é o XML de uma NFS-e. Pode ser que o web service esteja esperando uma informação e faça um conversão interna na hora de converter o XML do RPS para um NFSe.

Bom dia. Criada a #TK-5836 para análise do caso e parecer por parte da equipe de consultores.

Bom dia! Se a informação vem no XML de retorno, mas ao ler a propriedade do componente está vindo em branco, é possível que sejam as dlls de dependência. Tente adicionar as dlls da LIBXML2 (escolhendo de acordo com a arquitetura que compila sua aplicação e não a do SO) na mesma pasta do .EXE

Olá pessoal! No dia 07/08/2024, por volta das 08h35 começamos a receber em nosso Discord múltiplos relatos de membros com problemas ao tentar transmitir NF-e para a Sefaz de São Paulo. O erro que muitos relataram estar recebendo ao tentar realizar uma transmissão era: Conferindo no DownDetector, é possível observar que o volume de relatos de problema aumentou exponencialmente durante esse mesmo período: Alguns colegas relaram sucesso na emissão realizando um teste com um link de internet alternativo ou alterando o DNS. Uma dica que foi compartilhada é utilizar o comando: nslookup nfe.fazenda.sp.gov.br E ir testando qual DNS consegue comunicação.

Olá pessoal! No site da secretária do estado do Mato Grosso, consta uma NOTÍCIA informando que a Sefaz do Mato Grosso realizará no dia 10/08/2024 uma parada programada para atualização da versão do banco de dados utilizado. A manutenção está prevista para iniciar às 15h00 e ser concluída até às 22h00 do mesmo dia. Os ambientes autorizadores da NF-e, NFC-e e NF3-e já foram atualizados. A previsão é de que o ambiente autorizador do CT-e será afetado e durante este período a contingência SVC seja ativada. Para utilizar as soluções ACBr em contingência, siga as orientações deste tópico:

Olá pessoal. No dia 06/08, foi publicada uma notícia no portal do SPED orientando como deve ser feita a escrituração do PIS Cofins decorrente do Regime Especial da Industria Química (REIQ). Segue notícia na íntegra: Fonte original: http://sped.rfb.gov.br/pagina/show/7498 Lembrando que o preenchimento dos campos mencionados usando o ACBrSPEDPisCofins pode ser feito da seguinte forma: var RegF001: TRegistroF001; RegF010: TRegistroF010; RegF100: TRegistroF100; begin RegF001 := ACBrSPEDPisCofins.Bloco_F.RegistroF001New; //... RegF010 := RegF001.RegistroF010New; //... RegF100 := RegF010.RegistroF100New; RegF100.IND_OPER := RegF100.VL_OPER := RegF100.CST_PIS := RegF100.VL_BC_PIS := RegF100.ALIQ_PIS := RegF100.VL_PIS := RegF100.CST_COFINS := RegF100.VL_BC_COFINS := RegF100.ALIQ_COFINS := RegF100.VL_COFINS := RegF100.NAT_BC_CRED := end;

Obrigado! Vamos analisar e reportamos assim que descobrirmos algo.

Apenas dando um retorno. Analisando as informações disponíveis, nos parece que de fato o https://ws-jundiai.giss.com.br/service-ws/nf/nfse-ws?wsdl se refere a um web service diferente. No entanto, ao fazer os devidos ajustes e realizar alguns testes, recebemos alguns retornos um tanto estranhos, como por exemplo, ao fazer uma consulta de lote, recebemos como retorno: Mas de acordo com os próprios schemas disponibilizados, a consulta de lote, não possui assinatura. Outros retornos comuns, foram o de "Assinatura inválida" mesmo a assinatura estando em ordem de acordo com o validador da receita e também de arquivo em desacordo com os schemas, mesmo o arquivo passando pela validação que compara o XML com o .xsd. Por favor, você consegue entrar em contato com o provedor e solicitar um arquivo de envio de exemplo, para que possamos comparar com o arquivo gerado em busca de erros e fazer os ajustes necessários. Criada a #TK-5831 para tratar do caso.

Bom dia! Estou analisando as informações junto a equipe de consultores. Assim que descobrir algo, reportamos aqui.