Diego Foliene

Olá pessoal! Recentemente temos recebido relatos de membros da comunidade com problemas para realizar o envio de e-mail quando o provedor é o da Microsoft(@hotmail, @outlook e afins). Um membro de nossa comunidade compartilhou a seguinte mensagem que recebeu da Microsoft: Esses "métodos modernos de autenticação" se referem ao Oauth 2.0 (Veja mais em Os Métodos de Autenticação Modernos agora necessários para continuar a sincronizar o E-mail do Outlook em aplicações de e-mail não Microsoft). O que é o Oauth 2.0? O Oauth 2.0 é um protocolo de autorização que funciona através de tokens de acesso e foi projetado primariamente com o objetivo de conceder acesso a determinados recursos de aplicações de usuários. Neste caso em questão, seria o acesso ao e-mail. Como fica o ACBrMail? Atualmente o ACBrMail não tem suporte a Oauth 2.0, foi criada em nosso backlog a tarefa #TK-6042 para análise e implementação da mesma. É o fim do ACBrMail então? O que eu faço agora? Não é o fim do ACBrMail. Conforme mencionado anteriormente, será analisada implementação do Oauth 2.0 no mesmo. Enquanto isso não ocorre, para provedores como o g-mail, por exemplo, ainda é possível fazer a comunicação com a Senha de App. Para a Microsoft, nos testes realizados pela equipe de consultores, Microsoft365 ainda demonstra estar funcionando, o HotMail e o Outlook que pararam de funcionar. Outra opção também seria o uso de um provedor de e-mail próprio.

Olá pessoal! No dias 24/09/2024 e 01/10/2024 respectivamente foram publicados o Correio Eletrônico SEF/DIAT/Nº 16 / 2024 e o SEF/DIAT/Nº 17 / 2024 respectivamente. Ambos trazem mais informações a respeito do fim do PAF-ECF. Em resumo: As emissões de NFC-e e BP-e deverão ser feitas por programas de aplicativos fiscais (PAF) credenciados. A emissão de NFC-e e BP-e exige credenciamento prévio por meio dos Tratamentos Tributários Diferenciados (TTD) de número 707 e 709. Deverá ser gerado o CSC para emissão de NFCe, um manual de como solicitar o TTD 707 e gerar o CSC pode ser encontrado em www.sef.sc.gov.br/nfce. Uma vez iniciada a emissão de NFC-e e BP-e a empresa interventora deve cessar o uso do PAF-ECF indicando "Adesão a NFCe" como o motivo. Foram revogados os Atos DIAT nº 46/2022 e nº 55/2022, responsáveis pela implementação da exigência do Bloco X, dispensando a sua obrigatoriedade. Não é feita a distinção do CNAE principal ou secundário, por isso a obrigatoriedade se inicia na primeira data de enquadramento do anexo. Por exemplo, um estabelecimento que possua como CNAE primário 4511101 (Anexo V do Ato DIAT cujo inicio da obrigatoriedade é 01/07/2025) e CNAE secundário 4732600 (Anexo I do Ato DIAT cujo inicio da obrigatoriedade é 01/03/2025) terá o início da obrigatoriedade no dia 01/03/2025. Os estabelecimentos que realizam atividades de venda a consumidor final não citadas de forma explícita no Ato DIAT 56/2024 estão obrigados ao uso da NFC-e a partir de 01/08/2025. A obrigatoriedade de uso da NFC-e refere-se ao estabelecimento e não apenas a atividades específicas. Desta forma, iniciada a obrigatoriedade, todas as saídas internas do estabelecimento para consumidor final, não contribuinte, deverão ser acobertadas por NFC-e. Novas Inscrições Estaduais estão obrigadas ao uso da NFC-e e BP-e desde a publicação do Ato DIAT 56/2024 No momento, os contribuintes que não estão obrigados ao uso do ECF em razão de seu faturamento, continuam dispensados do uso da NFC-e e do BP-e. Todavia a previsão de que isso seja alterado ainda em 2024, por isso, é recomendado que os contribuintes se atentem ao cronograma exposto no Ato DIAT 56/2024. As alterações do regramento não afetam empresas MEI, as quais continuam dispensadas da emissão de documentos fiscais, salvo nas condições explicitadas na LC 123/06. A partir de 01/08/2025 não será mais permitido o uso de Emissor de Cupom Fiscal (ECF) em Santa Catarina.

Olá pessoal! Ao acessar o Portal da Nota Fiscal Eletrônica - SVRS foi exibido o seguinte aviso informando que como os contribuintes MEI ganharam IE, as regras de validação relacionadas a mesma passarão a ser aplicadas e que os contribuintes que não souberem sua própria inscrição poderão consultar no CCC.

Olá pessoal! No dia 01/10/2024 foi publicada a versão 2.00 do Informe Técnico 2024/001, alterando novamente a tabela de NCMs. A partir de 01/10/2024: Extinção dos NCMs: 32071010, 39069041, 39069042, 39069043, 39069044, 39069045, 39069046, 39069047, 39069048, 39069049 e 73151100. Inclusão dos NCM 32071020, 32071030, 39069051, 39069052, 39069053, 39069054, 39069059, 39069061, 39069062, 39069063, 39069064, 39069065, 39069069, 73151110 e 73151190. Para NFes que não sejam de exportação, os NCMs extintos serão aceitos até 04/11/2024. Os novos NCMs serão aceitos a partir de 02/10/2024 de acordo com a implantação da UF. Leia o Informe na integra AQUI.

Olá pessoal! Ao acessar o portal SPED MG consta um aviso com a seguinte informação: A mesma deixa claro que no ambiente de homologação, será devolvido a mensagem de consumo indevido caso uma mesma rejeição de Duplicidade de NF-e com diferença na Chave de Acesso seja devolvida mais de 200 vezes em um período de uma hora. Por isso, é importante que verifiquem se sua aplicação possui um processo em loop que possa causar uma situação como esta. Por que isso é tão importante? Porque conforme observações nas regras de consumo indevido presentes na NT2018/002, a rejeição de consumo indevido faz com que seja necessário aguardar o período de uma hora para poder voltar a consumir o web service, no entanto, a critério da UF, após 50 bloqueios o contribuinte pode receber a rejeição 656 permanentemente até entrar em contato com a UF autorizadora para regularização.

Bom dia! Em seu XML está faltando a "Identificação do tomador do serviço no CT-e", grupo obrigatório e que vem antes do grupo infCarga de acordo com o layout trazido na NT.

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

Boa tarde. Veja que não está sendo criado o grupo do PIS ou do Cofins, somente o grupo do Produto e do ICMS. Por favor, como você está alimentando na classe de alto nível as propriedades do PIS e do COFINS?

Olá pessoal! Conferindo às 15h26 no painel Situação SVC já não consta mais ativada a contingência para o estado do Mato Grosso.

Boa tarde! Foi enviado um ajuste ao SVN visando adicionar no impresso A4 a mesma lógica dos demais impressos. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema. A compilação da Lib efetuada na terça-feira de manhã (dia 01/10/2024) englobara o referido ajuste.

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

Olá pessoal! Conferindo no painel Situação SVC é possível observar que a Sefaz do Mato Grosso ativou a contingência às 09h05 do dia 30/09/2024, com previsão de encerramento às 17h00 do mesmo dia. Para utilizar as soluções ACBr em contingência durante este período, siga as orientações deste tópico: Um agradecimento ao membro de nossa comunidade @Dan Alves por compartilhar a informação no canal Sefaz em nosso Discord.

@João Victor da cruz Jorge, quando você utiliza as classes de alto nível, no final do processo, é gerado um INI para ser passado para a Lib. Você pode ver um exemplo disso se abrir o demo disponível em C# e conferir a rotina AlimentarDados(), veja o conteúdo da última linha: return notaFiscal.ToString(); Por favor, disponibilize o resultado dessa linha para análise.

Bom dia @João Victor da cruz Jorge. Por favor, o exemplo em questão é o do SAT? Se o for, por favor, veja se as orientações deste tópico lhe são úteis:

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

Hmm, pode estar ai a questão. Consegue fazer um teste debugando? Se sim, por favor, coloque um break-point no local indicado pelo print e veja se ele atende a condição para gerar a seção no INI.

Bom dia! O problema está na forma como você está montando o seu arquivo INI. O arquivo INI é tem um formato de seções, onde cada seção tem um título e seus respectivos campos. Vamos pegar a seção do produto 01 em seu arquivo: [ICMS001] CST=10 Origem=0 [impostoDevol001] pDevol=9.75 vIPIDevol=24.49 pRedBC=1.0000 vBC=251.16 pICMS=18.00 vICMS=45.21 pMVAST=42.00 pRedBCST=0.0000 vBCST=391.42 pICMSST=18.00 vICMSST=25.25 ModalidadeST=4 Neste trecho tem duas seções. A seção [ICMS001] que tem somente os campos CST e Origem e a seção [impostoDevol001] que tem os demais campos. Isso está errado. Boa parte dos campos da seção [impostoDevol001] na verdade fazer parte da seção [ICMS001]; Por favor, tente assim: [ICMS001] CST=10 Origem=0 pRedBC=1.0000 vBC=251.16 pICMS=18.00 vICMS=45.21 pMVAST=42.00 pRedBCST=0.0000 vBCST=391.42 pICMSST=18.00 vICMSST=25.25 ModalidadeST=4 [impostoDevol001] pDevol=9.75 vIPIDevol=24.49

Bom dia! Por favor, você utiliza as classes direto do SVN ou Nuget? As classes estão atualizadas e em dia com o SVN ou o Nuget está utilizando a última versão do pacote disponível? Fiz um teste com o exemplo disponível para C# e a versão mais recente da Lib. Alterei na rotina AlimentarDados() produto.PIS.CST = CSTPIS.pis49; produto.COFINS.CST = CSTCofins.cof49; E o XML gerado respeitou a informação criando o arquivo com o valor: <PIS> <PISSN> <CST>49</CST> </PISSN> </PIS> <COFINS> <COFINSSN> <CST>49</CST> </COFINSSN> </COFINS> Quando você faz uso das classes de alto nível, no momento de comunicar com a Lib, elas criam para você um arquivo .INI para ser enviado a Lib. Você pode ver isso no final da rotina AlimentarDados do exemplo. return CFe.ToString(); Em meu teste, o mesmo ficou desta forma nas seções do PIX e do CONFINS: [PIS001] CST=49 vBC=0 pPIS=0 qBCProd=0 vAliqProd=0 vPIS=0 [COFINS001] CST=49 vBC=0 pCOFINS=0 qBCProd=0 vAliqProd=0 vCOFINS=0 Por favor, veja como está ficando no seu. Se ele estiver ficando com um valor diferente de 01, por favor, se possível disponibilize o mesmo na íntegra para que possa fazer um teste em meu ambiente.

Muito obrigado. De fato, testando aqui realmente o A4 se comportou de maneira diferente, vamos analisar a questão na TK mencionada anteriormente. Qualquer novidade reportamos aqui.

Por favor, como você está configurando a impressão? Nos testes que fiz em meu ambiente utilizando o programa exemplo, apenas carregando o XML que disponibilizou e usando o método de imprimir o impresso ficou desta forma: Apenas depois que configurei desta forma antes de chamar o método de impressão: ACBrNFe1.DANFe.ImprimeTributos := trbSeparadamente; ACBrNFe1.DANFe.vTribFed := ACBrNFe1.NotasFiscais[0].NFe.Total.ICMSTot.vTotTrib; ACBrNFe1.DANFe.vTribEst := ACBrNFe1.NotasFiscais[0].NFe.Total.ICMSTot.vICMS; Que o resultado ficou assim: De qualquer forma, foi criada a #TK-6029 para análise do caso e parecer por parte da equipe de consultores.

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

Bom dia. Estou verificando junto aos demais consultores.

Por favor, seus fontes estão atualizados e em dia com o SVN? Qual é o motor de relatórios que está utilizando, Fortes ou Fast? Fiz alguns testes com seu arquivo, mas tanto no EscPos, no A4 com Fortes e no Fast foi mostrado valor 0,37, que foi lido da tag vTotTrib.

Boa tarde! Por favor, pode fornecer mais informações? Você está utilizando as classes de alto nível para preencher a classe de cupom ou está alimentando diretamente via INI? Pode disponibilizar o log gerado pela Lib para análise? Se julgar que o mesmo tenha dados sensíveis e não possa ser disponibilizado direto aqui, envie para [email protected] com o link do tópico do fórum no corpo do e-mail para posterior identificação.