Diego Foliene

Olá pessoal! No dia 13/09/2024 foi publicado no portal do Sistema Público de Escrituração Digital (SPED uma orientação sobre como pessoa jurídica poderá descontar da contribuição devida para Pis/Pasep e Cofins, o crédito presumido calculado sobre a receita decorrente da prestação de serviços de transporte rodoviário regular de passageiros intermunicipal, exceto metropolitano, e de transporte rodoviário regular de passageiros interestadual, em acordo com a lei nº 14.789, de 29 de dezembro de 2023. Como no Programa Gerador de Escrituração – PGE da EFD Contribuições, o registro para se escriturar crédito presumido desse regime cumulativo é o F700 – Deduções Diversas e o mesmo ainda não está completamente de acordo com a nova determinação, orienta-se: Escriturar no Registro F700 os créditos presumidos calculados sobre a receita decorrente da prestação de serviços de transporte rodoviário regular de passageiros intermunicipal, exceto metropolitano, e de transporte rodoviário regular de passageiros interestadual (art. 2º-A da Lei nº 14.592, de 2023), conforme exemplo abaixo. Considerando que a empresa tenha direito a crédito presumido relativo à receita de transporte rodoviário regular de passageiros interestadual, no valor de R$ 1.000.000,00, a escrituração do crédito será efetuada, no registro “F700”, conforme abaixo: - Campo 02 - IND_ORI_DED: 99 (Outras Deduções) (*) - Campo 03 – IND_NAT_DED: 1 (Dedução de Natureza Cumulativa) - Campo 04 – VL_DED_PIS: - Campo 05 – VL_DED_COFINS: - Campo 06 - VL_BC_OPER: 1.000.000,00 - Campo 07 – CNPJ: xx.xxx.xxx/xxxx-xx (**) - Campo 08 – INF_COMP: Crédito Presumido art. 2º-A da Lei 14.592/2023. (*) Enquanto não for disponibilizado código específico para o crédito presumido previsto no art. 2º-A da Lei 14.592/2023, o código 99 deverá ser utilizado. A descrição do crédito deverá ser informada no campo 08 – INF_COMP. (**) Informar o estabelecimento que auferiu as receitas. Caso a receita seja auferida por mais de um estabelecimento, escriturar um registro F700 para cada estabelecimento. Caso ocorram anulações de prestação de serviços, cujas receitas estejam sujeitas ao cálculo do crédito presumido, os correspondentes valores devem ser excluídos na base de cálculo da operação e nos respectivos campos de dedução (VL_DED_PIS e VL_DED_COFINS). Escriturar no registro F100 os créditos presumidos aplicáveis unicamente ao regime não cumulativo, incidentes sobre as receitas de venda de produtos específicos. Portanto, reforçando, não devem ser informados neste registro os créditos presumidos que também se aplicam ao regime cumulativo, a relativo à prestação de serviço de transporte de passageiros (art. 2º-A da Lei nº 14.592/2023). Como regra geral, os valores escriturados nos registros F700 – Deduções Diversas - não são recuperados na geração automática de apuração, devendo sempre ser informados pela própria pessoa jurídica no arquivo importado pelo PGE ou complementado pela edição (digitação no próprio PGE) dos registros M200 (PIS) e M600 (Cofins). No caso específico deste crédito presumido do setor de transportes, os valores serão totalizados e escriturados no campo 11 - VL_OUT_DED_CUM - Outras Deduções no Período, dos registros M200 e M600, de forma a reduzir o valor da contribuição do período. Os valores de receitas e respectivas contribuições, apuradas nos registros M210 e M610, não são alterados por este procedimento. Leia a orientação original na integra AQUI. O preenchimento dos campos mencionados no exemplo podem ser preenchidos no componente ACBrSPEDPisCofins: with ACBrSPEDPisCofins1.Bloco_F do begin //... with RegistroF001New do begin //... with RegistroF010New do begin //... with RegistroF700New do begin IND_ORI_DED := indOutrasDeducoes; IND_NAT_DED := indAcumulativa; VL_DED_PIS := ??; VL_DED_COFINS := ??; VL_BC_OPER := ??; CNPJ := ??; INF_COMP := 'Crédito Presumido art. 2º-A da Lei 14.592/2023.'; end; end; end; end;

Olá pessoal! No dia 01/07/2024 entrou em vigor no ambiente de produção as regras de validação da versão mais recente da Nota Técnica 2023/004. Essa versão alterou a regra de validação que devolvia a rejeição 391, dando a ela o texto: Quando está regra entrou em vigor, muitos contribuintes começaram a receber no estado de Minas Gerais a rejeição 391, o que no início assustou muitos colegas, visto que a UF não havia publicado legislação que dessa a entender que adotaria a implementação da mesma. Na época, a AFRAC buscou mais informações junto a Sefaz e recebeu o seguinte retorno: No dia 16/09/2024, ao acessar o portal SPED MG o seguinte aviso foi exibido indicando que a regra será reativada no dia 01/10/2024:

Olá pessoal! Segue na integra aviso disponibilizado originalmente no dia 04/09/2024 no Portal da NFCom informando sobre a liberação do ambiente de homologação para São Paulo. Ativação do Ambiente de Homologação da SVRS para a SEFAZ SP Comunicamos com muita satisfação que o ambiente de autorização da SEFAZ Virtual RS para autorização de NFCom está habilitado para as operadoras de Telecom e contribuintes do estado de São Paulo. O credenciamento no ambiente de testes será realizado pela própria SEFAZ.

Olá pessoal! Conferindo no portal Sobre o SAT, consta um aviso informando que no dia 29/09/2024 entre às 08h00 e às 14h00 será realizada uma manutenção no ambiente de produção do SAT que poderá impactar a ativação de novos aparelhos SAT e também a recepção de CF-es. Devido a isso, a Sefaz de São Paulo recomenda que: Os contribuintes verifiquem se o aparelho SAT possui cupons na memória e caso afirmativo, conecte o aparelho na internet para transmissão fora deste período. Evitem realizar a ativação de novos equipamentos durante esta janela de manutenção e não troquem o código de ativação em caso de falha.

Olá pessoal! No dia 11/09/2024 foi publicada uma notícia informando que a Receita Estadual do Rio Grande do Sul enviou o quarto lote de alertas para as empresas com baixa integração das notas fiscais. Desde o dia 01/01/2024 os contribuintes do estado do RS devem emitir a NFC-e de forma integrada aos meios de pagamento. No tópico abaixo há mais detalhes a respeito: As empresas notificadas foram identificadas através de um cruzamento dos dados da Receita com as notas emitidas, onde foi identificado que uma baixa integração por parte das mesmas. Os alertas dão a oportunidade aos emissores de se regularizarem voluntariamente. Findado esta etapa de envio de alertas passará a realizar fiscalização e aplicação das sanções em casos de irregularidades. Leia a notícia original na íntegra AQUI. Informações extras e úteis: Parceria ACBr Tef x Paygo Curso T.E.F e Meios de Pagamentos ao qual os membros PRO tem acesso. Mini Curso Integração aos Meios de Pagamentos e Documentos Fiscais Eletrônicos ao qual os membros PRO tem acesso.

Bom dia. Infelizmente não... Quando você "cria um tópico" no Discord, somente a pessoa que o criou e os participantes convidados teriam podem visualizar e interagir. A melhor forma de conseguir interação da comunidade seria como com um tópico na área aberta do fórum como você fez.

Tudo indica ser alguma diferença em seu ambiente. Por favor, veja se consegue fazer o teste em um ambiente limpo. Esse passo a passo também pode ser útil.

Boa tarde! Foi enviado nova alteração ao SVN visando resolver esta questão. Assim que houver nova compilação da Lib vai englobar a modificação.

Boa tarde! O gerador de relatórios utilizado neste caso foi o Fortes Report, no entanto, como comentou, como o problema ocorria na carga do XML, acredito que o gerador utilizado não tenha relação com o problema. O .EXE foi compilado em meu ambiente hoje. Por favor: Sabendo que deu certo com ele, agora, substitua as dlls que você tem na pasta do seu .EXE pelas dlls que estão na pasta deste que deu certo. Caso ele ainda apresente o mesmo erro no momento de carregar o XML, então pode ser que você tenha modificações locais. 1º Vou lhe pedir que você faça um SVN update na pasta base do ACBr(no nível mais baixo e não dentro de uma pasta específica por exemplo). 2º Procure por .bpls ou .dcus do ACBr perdidos em seu ambiente, geralmente eles ficam em "C:\Users\Public\Documents\Embarcadero\Studio\VersaoDoSeuDelphi" se encontrar algum do ACBr neste caminho, apague. 3º Reinstale o ACBr com a opção para "Apagar Arquivos Antigos" selecionada no instalador. 4º Faça um novo teste.

Comparando seus arquivos XMLs com os meus, eles parecem estar corretos. Eles abrem corretamente a visualização no navegador, o notepad++ reconhece como XML válido e em UTF-8. Testando em meu ambiente com os arquivos que disponibilizou, o preview foi gerado corretamente. Por favor: Faça o download do exemplo anexado. Descompacte o mesmo e faça um teste com ele. Não precisa configurar nada. Não remova as dlls que vierem junto da pasta. Não adicione outras dlls fora as que já vieram com ele. Veja se também ocorre o problema testando com ele. ACBrNFeExemplo.7z

Recepção dos Cupons Fiscais Eletrônicos (CFes) emitidos com o leiaute da versão 0.07 10 de setembro de 2024 - 11:45 A Secretaria da Fazenda do Ceará (Sefaz-Ce) informa que, continuará a recepcionar os Cupons Fiscais Eletrônicos (CFes) emitidos com o leiaute da versão 0.07 até 31 de dezembro de 2025. Esclarece ainda que, no decorrer de 2025, os leiautes nas versões 0.07 , 0.08 e 0.09 do CFe poderão ser utilizados pelos aplicativos comerciais dos contribuintes. O órgão destaca que os fabricantes do equipamento Módulo Fiscal Eletrônico (MFE) já estão realizando os processos de homologação dos softwares básicos com a versão mais atual. A Sefaz alerta que é imprescindível o planejamento por parte das softwares houses para a realização de todas as adaptações técnicas exigidas pela Especificação Técnica de Requisitos SAT 2.30.03 ou posteriores, que se encontram disponíveis no PortalCFe. Para mais informações, os contribuintes podem entrar em contato pelo email [email protected]. https://cfe.sefaz.ce.gov.br/mfe#/

Arquivos recebidos, muito obrigado. Vamos analisar e reportamos assim que descobrirmos algo.

Por favor, envie os arquivos XML que está usando para o e-mail solicitado para que possa testar em meu ambiente e comparar com os que estou gerando em meus testes.

Bom dia! Outra questão que também vale conferir. Por favor, você manipula a string de alguma forma quando passando ela por uma rotina de conversão por exemplo, ou você usa a propriedade da forma como é devolvida pelo componente? Em meu teste, para salvar o arquivo manualmente eu adicionei este trecho de código no evento OnClick do botão da Carta de Correção do exemplo da NF-e. LStr := TStringList.Create; try LStr.Clear; LStr.Add(ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento[0].RetInfEvento.XML); LStr.SaveToFile(ApplicationPath + '\RetInfEvento.xml'); finally LStr.Free; end; Por favor, envie os XMLs que está utilizando para [email protected] com o link do tópico do fórum no corpo do e-mail para posterior identificação.

Por favor, adicione as dlls deste LINK, escolhendo de acordo com arquitetura que você compila a sua aplicação e não a arquitetura do SO, na mesma pasta do seu .EXE; Peço que faça também um teste com o programa exemplo do ACBrNFe. Eu fiz um teste em meu ambiente e não tive o problema. Se você também não tiver o mesmo problema testando com o exemplo, então podemos reduzir o problema a rotina que você utiliza de diferente em sua aplicação e verificar qual pode ser a causa do problema.

Boa tarde @MarcosRWeimer. Foi enviada uma alteração no SVN visando resolver a questão. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Em um chute inicial, sem me aprofundar muito nos conceitos, entendo que seria uma integração com a API dos modelos generativos já existentes no mercado. Indo para uma área mais "esotérica" talvez melhorar o ACBrFala que atualmente depende de áudios pré-gravados.

Bom dia. Obrigado pelas informações. Com elas podemos atuar em uma correção mais assertiva.

Olá pessoal! Foi detectado a necessidade de uma correção na informação do ModeloDF para a Lib do CT-e. Atualmente na documentação consta da seguinte forma: No entanto, a Lib faz uso do enumerado nativo do componente e o mesmo possui a seguinte estrutura: TModeloCTe = (moCTe, moGTVe, moCTeOS); Portanto, a correta relação de conversão é: A informação foi corrigida na documentação e será atualizada em compilação posterior. Para quem utiliza as classes de alto nível do C#, o enumerado corrigido já foi disponibilizado no SVN e o pacote Core disponível no nuget foi atualizado.

Bom dia. Vale também mencionar: O Delphi AI Developer que está sendo desenvolvido pelo Cesar Cardoso do Code4Delphi. A edição do Papo PRO: Delphi AI Developer(Copilot) +  dicas e boas práticas para uso de desenvolvimento de utilitários. A edição do Papo PRO: IA + Delphi! Aumente sua produtividade e agregue valor a seus produtos com o uso IA. Tecnologa e IA [+Fabio Akita]

Olá pessoal! Foi publicada a versão 4.0.6 do Programa Validador de Escrituração Digital EFD ICMS IPI. A nova versão traz as seguintes alterações: Fonte: http://sped.rfb.gov.br/pagina/show/7506

Olá pessoal! Houve uma alteração na forma como o ACBrMonitorPLUS devolve a informação do nome do XML gerado. Quem utiliza o ACBrMonitorPLUS a muito tempo, provavelmente está acostumado a receber na resposta do mesmo, o nome do arquivo em dois locais diferentes como no exemplo abaixo: OK: C:\ACBrMonitorPLUS\Logs\352409XXXXXXXXXXXX395700100000000112147XXXX1-cte.xml Autorizado o uso do CT-e. [Envio] CStat=100 CUF=35 DhRecbto= Msg=Autorizado o uso do CT-e. NProt=123XXX94 NRec= TMed=0 VerAplic=SP-CTe-2024-01-31-2 Versao=SP-CTe-2024-01-31-2 XMotivo=Autorizado o uso do CT-e. Xml=<CTe>...</CTe> [CTe352409XXXXXXXXXXXX395700100000000112147XXXX1] Id= XML= cStat=100 chDFe=352409XXXXXXXXXXXX395700100000000112147XXXX1 dhRecbto=05/02/2024 20:26:22 digVal=XXXXXXXXXXXXXXXXXXXXXXXX35oA= nProt=13XXXXXXXXXX994 tpAmb=1 verAplic=SP-CTe-2024-01-31-2 xMotivo=Autorizado o uso do CT-e. [CTe_Arq1] Arquivo=C:\ACBrMonitorPLUS\Logs\352409XXXXXXXXXXXX395700100000000112147XXXX1-cte.xml Vejam que mesmo havendo na resposta uma seção específica para as informações do CT-e autorizado, há um seção [CTe_Arq1] que recebe somente o local onde o arquivo foi gerado. Esta seção [DFe_ArqX] costuma ser gerada no retorno quando assíncrono. Agora, com alguns documentos adotando somente o modo de envio síncrono e visando padronização na forma como está informação é devolvida tanto na resposta do Monitor e na resposta da Lib, está seção foi removida e a informação foi movida para a já existente seção com os dados do documento fiscal com o identificador NomeArq. Então a resposta agora será desta forma: OK: C:\ACBrMonitorPLUS\Logs\352409XXXXXXXXXXXX395700100000000112147XXXX1-cte.xml Autorizado o uso do CT-e. [Envio] CStat=100 CUF=35 DhRecbto= Msg=Autorizado o uso do CT-e. NProt=123XXX94 NRec= TMed=0 VerAplic=SP-CTe-2024-01-31-2 Versao=SP-CTe-2024-01-31-2 XMotivo=Autorizado o uso do CT-e. Xml=<CTe>...</CTe> [CTe352409XXXXXXXXXXXX395700100000000112147XXXX1] Id= NomeArq=C:\ACBrMonitorPLUS\Logs\352409XXXXXXXXXXXX395700100000000112147XXXX1-cte.xml XML= cStat=100 chDFe=352409XXXXXXXXXXXX395700100000000112147XXXX1 dhRecbto=05/02/2024 20:26:22 digVal=XXXXXXXXXXXXXXXXXXXXXXXX35oA= nProt=13XXXXXXXXXX994 tpAmb=1 verAplic=SP-CTe-2024-01-31-2 xMotivo=Autorizado o uso do CT-e. Todos os meus retornos foram alterados? Foram alterados os retornos dos comandos de envio dos objetos do CTe e do MDFe, ambos documentos que adotaram somente o modo de envio síncrono.

Olá pessoal! No dia 09/09/2024, por volta das 14h41 começamos a receber em nosso Discord múltiplos relatos de problema ao consumir os web services do MDF-e. Todos os relatos tem em comum o mesmo retorno: Vejam que o erro indica ser um problema no banco de dados do servidor. Por volta das 15h06 foi relatado que a transmissão foi normalizada.

Olá pessoal! No dia 06/09/2024 foi publicado no Diário Oficial do Estado do Rio Grande do Sul o decreto Nº 57.789, de 05 de Setembro de 2024 que modifica o Regulamento do Imposto sobre Operações Relativas à Circulação de Mercadorias e sobre Prestações de Serviços de Transporte Interestadual e Intermunicipal e de Comunicação (RICMS). Dentre estas modificações, vale destacar Art. 4º, mais especificamente, as notas da Alteração Nº 6424 - No Livro I, art.1º-A, inciso I, onde são adicionadas as seguintes notas: Na prática estas notas significam que a partir de 1º de outubro de 2024, o Microempreendedor Individual (MEI) localizado no Rio Grande do Sul que possua atividades listadas como contribuinte de ICMS, na vigência da opção pelo SIMEI, terá sua inscrição gerada automaticamente no cadastro estadual. A novidade, que não trará novas obrigações acessórias para os MEI, visa incentivar a formalização e facilitar diversos tipos de transações comerciais que exigem a informação de número de inscrição estadual. Leia o Diário Completo AQUI.