Diego Foliene

O que é o evento de resposta ao pedido de prorrogação gerado pelo Fisco? A nota técnica 2015/001 estabelece o evento de pedido de prorrogação. Este evento visa atender Convênio AE-15/74, de forma a permitir que o contribuinte faça um pedido de prorrogação da suspensão do ICMS na remessa para industrialização após 180 dias. No entanto, diferente dos demais eventos, quando o contribuinte faz o envio de um evento de pedido de prorrogação, ele vai receber apenas a informação de que o pedido foi registrado. A confirmação se o pedido foi deferido ou não é devolvida em um novo evento gerado pelo próprio fisco. Como obter o evento de resposta gerado pelo fisco? Os eventos de resposta gerados pelo fisco podem ser: Evento Fisco Resposta ao Pedido de Prorrogação 1º prazo (tpEvento=411500, “EFPP1”). Evento Fisco Resposta ao Pedido de Prorrogação 2º prazo (tpEvento=411501, “EFPP2”). Evento Fisco Resposta ao Cancelamento de Prorrogação 1º prazo (tpEvento=411502, “EFCPP1”). Evento Fisco Resposta ao Cancelamento de Prorrogação 2º prazo (tpEvento=411503, “EFCPP2”). Todos estes eventos são devolvidos tanto para o emitente quanto para o destinatário da nota através da Distribuição DFe. Como leio a informação do evento na resposta da Distribuição DFe? Como o web service devolve múltiplos eventos, é necessário se atentar a informação tpEvento que é devolvida na resposta. Vejam rotina adaptada a partir da rotina já existente no programa exemplo: uses pcnRetDistDFeInt; implementation //... var LretDisDFeInt: TretDistDFeInt; i: Integer; begin ACBrNFe.DistribuicaoDFePorUltNSU(CodUFAutor, CNPJInteressado, UltNSU); LretDisDFeInt := ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt; if LretDisDFeInt.cStat = 138 then //Localizou doumentos... begin for i := 0 to Pred(LretDisDFeInt.docZip.Count) do begin case LretDisDFeInt.docZip[i].schema of schresEvento: begin if LretDisDfeInt.docZip[i].resEvento.tpEvento in [teEventoFiscoPP1, teEventoFiscoPP2, teEventoFiscoCPP1, teEventoFiscoCPP2] then begin //Lê as informações do resumo do evento. LretDisDFeInt.docZip[i].resEvento.XXX end; end; schprocEventoNFe: begin if LretDisDfeInt.docZip[i].procEvento.tpEvento in [teEventoFiscoPP1, teEventoFiscoPP2, teEventoFiscoCPP1, teEventoFiscoCPP2] then begin //Lê as informações do evento. LretDisDFeInt.docZip[i].procEvento.XXX end; end; //... end; end; end; end; Para quem utiliza ACBrLib ou ACBrMonitor. A resposta devolvida possui na seção que é gerada para o evento o tipo de evento. Basta validar se o tipo de evento corresponde ao que é preciso. [ProEve001] NSU=000000000000308 chCTe=3511111111111111550010000570851000570854 cOrgao=35 CNPJCPF=99999999999999 id=ID11111111111111111111111111111111111111111 dhEvento=29/08/2017 16:17:41 nSeqEvento=1 tpAmb=1 ;Aqui vai vir 411500, 411501, 411502 ou 411503 tpEvento=411500 verEvento=1.00 desEvento=Cancelamento xJust= Dados Errados EmiCnpj= EmiIe= EmixNome= cteNProt= cteChvCte= cteDhemi=30/12/1899 cteModal=01 cteDhRebcto=30/12/1899 XML=<xml evento> [InfEve001] id=ID11111111111111111111111111111111111111111 verAplic=1.1.9 tpAmb=1 cOrgao=35 chCTe=3511111111111111550010000570851000570854 cStat= CnpjDest=99999999999999 cOrgaoAutor= ;Aqui vai vir 411500, 411501, 411502 ou 411503 tpEvento=411500 nSeqEvento=1 xEvento= xMotivo= dhRegEvento=29/08/2017 16:17:41 emailDest= nProt=1456446552542554255 XML=<xml evento> É Importante lembrar: Até o momento da criação deste tópico, somente os estados de São Paulo e Minas Gerais fazem uso do evento de pedido de prorrogação. A Distribuição DFe por Chave não devolve os eventos, somente o XML da nota. Leia mais sobre a versão mais recente da nota técnica 2015/001 publicada até o momento AQUI.

Contextualizando o problema. Olá pessoal! O erro 724 pode ser devolvido pelo web service do e-Social quando fazemos o envio do evento S-1210 que contém as informações de Pagamentos e Rendimentos do Trabalho. A mensagem do erro 724 na íntegra é: Entendendo o erro. O evento S-1210, possui em seu leiaute um grupo chamado infoPgto que é responsável por receber as informações dos pagamentos efetuados. Este grupo é composto desta forma: <infoPgto> <dtPgto>Data de pagamento</dtPgto> <tpPgto>Evento de origem do pagamento</tpPgto> <perRef>Competência declarada no evento de origem do pagamento</perRef> <ideDmDev>Identificador atribúido no evento de origem do pagamento</ideDmDev> <vrLiq>Valoir líquido recebido pelo trabalhador</vrLiq> <paisResidExt>Código do Páis quando residência fiscal no exterior</paisResidExt> <infoPgtoExt>Informações complementares relativas a pagamentos de residente fiscal do exterior</infoPgtoExt> </infoPgto> Quando você faz o envio do evento S-1210, o web service do e-Social faz uso das informações contidas neste grupo para localizar o evento que originou o pagamento. Esta mensagem é devolvida quando o web service não consegue localizar em sua base de dados evento que corresponda a essas informações. Buscando a solução. Como a mensagem é devolvida quando o web service não encontra o evento de origem que pode ser o S-1200, S-2299, S-2399, S-1202 ou S-1207, a primeira medida a se tomar é conferir se o respectivo evento de fato foi enviado ao web service do e-Social sem erros. Se o evento foi enviado corretamente e não foi devolvido erro, então o próximo passo é confirmar se as informações que foram enviadas no grupo infoPgto estão corretas. O ideDmDev deve coincidir com o que foi enviado no evento de origem, então verifique se a informação não está sendo enviada com espaçamentos em branco, pontos ou cases incorretos. Também é importante se atentar ao período de referência, seu valor deve coincidir com o valor do perApur que foi enviado no evento de origem. Outro ponto importante ainda sobre este este campo é para os casos em que se está sendo feito o envio do grupo das informações de pagamento para um evento que foi enviado com informações do 13º salário. Normalmente este campo perRef possui o formato AAAA-MM, no entanto, quando for relativo ao 13º o mesmo deve ser enviado no formato AAAA. Um agradecimento ao membro de nossa comunidade @Kleyton Lima por compartilhar conosco em nossa comunidade do Discord informações que ajudaram a montar este tópico.

Bom dia! Sua interpretação da NT está correta. De acordo com o leiaute e o arquivo de schema é somente um receituário por nota. Não me recordo de outros membros realizando questionamento semelhante. Acredito que o melhor caminho seja buscar esta orientação junto a própria Sefaz através de um Fale Conosco. Também vou mover seu tópico para a área aberta da comunidade, assim mais membros poderão interagir e compartilhar informações.

Olá pessoal! Segue na íntegra e-mail contendo perguntas e respostas relacionadas a esta mudança que foi enviado para colegas da comunidade pelo fisco.

Olá pessoal! Foi publicada a versão 2.10 do Informe Técnico 2024/001 trazendo novas alterações na tabela de NCMs: A partir de 02/01/2025 no ambiente de produção: Extinção do NCM 07129010. Inclusão do NCM 07129020. Leia o a versão 2.10 do informe técnico na íntegra AQUI.

Olá pessoal! Como muitos estão cientes, a Sefaz de São Paulo publicou recentemente portaria que determinava que novos SATs não poderiam ser ativados, exceto por aqueles que já faziam uso do mesmo e também determinando uma data final para emissão de CF-e SAT. Ou seja, em poucas palavras, a portaria decretava o fim do equipamento no estado. (Se você não sabia de nada disso, recomendamos que leia mais sobre isso AQUI). No entanto, foi publicado na edição do dia 20/12/2024 do Diário Oficial do Estado de São Paulo a portaria SRE 92, DE 19 DE DEZEMBRO DE 2024, modificando novamente a Portaria CAT147/12 (responsável pela definição do SAT). Esta publicação mais recente revoga o seguinte artigo: Isso significa, que foi liberado novamente para que mesmo aqueles que nunca haviam utilizado SAT, possam ativar o equipamento. Será então que como a famigerada fênix o SAT estaria ressurgindo das cinzas? Apesar da nova portaria, tudo indica que não! Vale lembrar que apesar da revogação do artigo 34-C, o artigo 34-D ainda permanece mantendo assim a data 31/12/2025 como sendo o último dia no qual será permitido a emissão de CF-e SAT.

Olá pessoal! No dia 16/12/2024 foi publicado o Ato Diat Nº074/2024 dando a seguinte redação para o Art.5º do Ato Diat mencionado na primeira postagem deste tópico: Efetivamente prorrogando novamente esta obrigatoriedade para o dia 01/02/2025. Um agradecimento ao membro de nossa comunidade @Felipe Marianopor compartilhar a informação no canal #fiscal em nossa comunidade do Discord.

Bom dia! Muito obrigado pela contribuição! Foi criada a #TK-6379 para análise da mesma e parecer por parte da equipe de consultores. Qualquer novidade será divulgada neste tópico.

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

No dia 12/12/2024, por volta das 16h00 recebemos primeiro relato de normalização do problema.

Olá pessoal! Para quem utiliza as soluções ACBr para transmissão de documentos fiscais eletrônicos, deve estar familiarizado com a configuração XMLSignLib. Esta configuração é um enumerado e pode receber os valores: xsNone, xsXmlSec, xsMsXml, xsMsXmlCapicom e xsLibXml2. Dentre estas, as opções as opções xsXmlSec e xsMsXmlCapicom, são desativadas nativamente no instalador, o que significa que ao tentar atribuir um deles será exibida mensagem semelhante a esta: Por que estamos falando sobre isso? A MsXML em sua versão 4.0 foi descontinuada pela Microsoft e portanto é considerada obsoleta. A MsXML em sua versão 5.0 é focada na suíte de componente do pacote Office. Versões mais recentes da MxXML fornecem um suporte mais limitado no que diz respeito a assinatura de XMLs. Temos relatos de uso da MsXML com certificado A3 onde ela inutilizou a chave privada do mesmo. Levando isso em consideração, o time do ACBr optou por também desativar por padrão está opção no instalador do ACBr. Mas eu uso essa opção! Vou ficar na mão agora? NÃO! Conforme foi mencionado, esta opção foi desativada por padrão no instalador, mas ela permanece presente. Caso precise utilizar esta configuração, basta desmarcar a opção do print no instalador. Vale ressaltar que a opção xsLibXML2 é a configuração recomendada independente do tipo de certificado conforme tópico abaixo: E se eu uso a Lib? Esta configuração também foi desativada na compilação da Lib, o que significa que o valor não é mais válido para ela. Por isso, é recomendado que alterem a configuração para um valor válido com a versão da Lib que estiver utilizando e realize a atualização posterior a isso.

Olá pessoal! Desde o dia 11/12/2024, por volta das 17h50 começamos a receber relatos em nossa comunidade do Discord e também em nosso fórum, de membros recebendo como retorno ao tentar transmitir uma NF-e para a Sefaz de São Paulo a rejeição 590. O volume relatos aumentou exponencialmente na data de 12/12/2024. Os relatos tem em comum as mesmas características: A NF-e transmitida é de um emitente do Simples Nacional. A NF-e transmitida tem um item da gás GLP cujo cProdANP informado consta na tabela de combustíveis sujeitos a tributação monofásica. A NF-e em questão faz uso do CST monofásico 61. A nota é rejeitada com o seguinte retorno: Se conferirmos na descrição da regra de validação, consta a seguinte exceção: Temos relatos de que a rejeição só é devolvida no ambiente de produção, com a mesma nota sendo autorizada normalmente no ambiente de testes e que ao validar o arquivo neste validador disponibilizado pela Sefaz RS o arquivo não acusa o erro da rejeição. Todas estas evidências indicam que o problema esteja no lado da Sefaz. Até o momento não há um parecer oficial por parte dos mesmos. Em casos assim, é muito importante que abram um Fale Conosco relatando o problema a Sefaz, pois quanto maior o volume de relatos, mais cedo eles se dão conta de que há algo errado.

Olá pessoal! Na data de 11/12/2024, por volta das 16h16 começamos a receber múltiplos relatos de membros da nossa comunidade de problemas para consumir os web services da Sefaz de São Paulo. Os relatos tem em comum estarem recebendo como retorno a mensagem: Conferindo no DownDetector, é possível observar que os relatos de problemas passaram a aumentar exponencialmente por volta do mesmo horário. Não, há contingência ativada até a publicação deste tópico.

Olá pessoal! Foi publicado o ATO DIAT Nº 067/2024 com a finalidade de trazer um modelo em formato digital da tabela mencionada no Inciso II do § 1º do art. 71 do Anexo 6 do RICMS/SC-01. Refrescando a memória, o RICMS/SC-01 se trata do Regulamento do ICMS para o estado de Santa Catarina, o artigo em questão se encontra no capítulo relativo a remessa para industrialização e o Inciso II do § 1º do art. 71 possui a seguinte redação. A tabela do ATO DIAT Nº 067/2024 possui a seguinte estrutura: O Ato em questão entra em vigor na data de sua publicação.

Olá pessoal! No dia 10/12/2024 foi publicado Correio Eletrônico Circular SEF/DIAT/Nº 22 / 2024 tratando sobre alteração na forma de credenciamento para emissão de NFC-e (modelo 65) e BP-e (modelo 63) para os contribuintes do estado de Santa Catarina. A partir de 31/01/2025, o credenciamento para emissão de ambos os documentos será feito exclusivamente por meio de autorização do Programa Aplicativo Fiscal (PAF), também não sendo mais possível a partir de 01/02/2025 o credenciamento para emissão dos referidos documentos utilizando os Tratamentos Tributários Diferenciados (TTD) 706, 707, 708 e 709. As empresas desenvolvedoras devem providenciar a vinculação de todos os estabelecimentos usuários atuais até a data limite de 31/01/2025, com o risco de suspensão do credenciamento dos mesmos para emissão de NFC-e e BP-e. (Nenhuma ação é necessária por parte dos estabelecimentos emissores) A vinculação entre a empresa desenvolvedora e o estabelecimento deve ser realizada por meio da aplicação “CEI - Manutenção de Autorização de Uso de PAF-NFC-e e de BP-e" do sistema Sistema de Administração Tributária (SAT) usando usuário e senha gerados no momento do credenciamento como desenvolvedor. O documento também informa sem entrar em muitos detalhes que em breve será instituída a obrigatoriedade da homologação do PAF-NFCe. Leia o correio eletrônico na íntegra AQUI.

Olá pessoal! No dia 04/12/2024 foi publicado o Correio Eletrônico Circular SEF/DIAT/Nº 21 / 2024 que traz seguintes alterações nas tabelas externas 5.1.1, 5.2 e 5.3 da EFD. Inclusão dos ajustes SC020106, SC090001, SC010112 e SC010113 na Tabela de Códigos de Ajustes da Apuração do ICMS que não podem ser vinculados diretamente ao documento fiscal (Tabela 5.1.1). Encerramento da vigência dos ajustes SC030011, SC010108, SC000008, SC010109 e SC030012 na Tabela de Códigos de Ajustes da Apuração do ICMS que não podem ser vinculados diretamente ao documento fiscal (Tabela 5.1.1) Inclusão dos ajustes SC810253, SC85010, SC830141, SC999999, SC830142, SC840026, SC850102, SC850103, SC850104, SC850105 e SC830143 na Tabela de Informações Adicionais da apuração - Valores Declaratórios - cBenef (Tabela 5.2). Encerramento da vigência do ajuste SC820025 na Tabela de Informações Adicionais da apuração - Valores Declaratórios - cBenef (Tabela 5.2). Inclusão dos ajustes SC10000125, SC10000126, SC10000127, SC10000128, SC10000129, SC10000130, SC50000062, SC50000063, SC20000015 e SC54000003 na Tabela de Ajustes e Informações de Valores Provenientes de Documento Fiscal (Tabela 5.3). O correio eletrônico pode ser lido na íntegra AQUI. As tabelas atualizadas podem ser encontradas AQUI.