Diego.Foliene

Olá pessoal! Foi publicado no dia 28/06/2024 uma notícia confirmando a publicação de portaria conjunta que aprova o leiaute do eSocial em sua versão S-1.3. Essa nova versão finaliza os ajustes necessários para substituição da DIRF. Além do novo leiaute foi publicada uma nova versão da Nota Técnica nº04/2024 revisada que traz os ajustes necessários no eSocial para o projeto eConsignado. As datas para implementação são: Nota Técnica 04/2024 - Revisada - Itens 3.2 e 3.3: Implantação no ambiente de produção restrita: 08/07/2024. Implantação no ambiente de produção: 01/08/2024. Versão S-1.3 do eSocial: Implantação no ambiente de produção: 02/12/2024 Convivência entre a versão S-1.2 e a versão S-1.3: até 02/02/2025* *Eventos S-1210 (S-5002) e S-2501 devem ser enviados exclusivamente na versão S-1.3 a partir do período de apuração 01/2025. E como fica o ACBr? A nova versão do leiaute e nota técnica fazem com que seja necessário alterações nos fontes do ACBr para implementação das mesmas. Foi criado em nosso backlog a #TK-5666 para adequação a NT04/2024 e a #TK-5666-1 para adequação a versão S-1.3 Leia a notícia na íntegra AQUI. A versão revisa da NT04/2024, do leiaute S-1.3 e também do Manual de Orientação do eSocial podem ser encontradas AQUI.

Olá pessoal! Foi publicada a versão 4.0.4 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/7450

Olá pessoal! Na página Sobre o SAT da Sefaz de São Paulo, consta um recado informando que no dia 12/08/2024 a partir das 08h30 a Sefaz vai iniciar o processo de desligamento do protocolo SSL 3.0, com previsão inicial de o processo durar 2 horas. Durante esse período pode ocorrer instabilidade da comunicação com a Sefaz e por isso orienta que a ativação de novos SATs sejam feitos fora deste período. Também é lembrado que: Após este processo, os somente os SATs que se comunicam usando o protocolo SSL 3.0 não vão mais conseguir realizar comunicação. Esse processo já foi previamente comunicado pela Sefaz em aviso no dia 15/03/2024 (noticiado em nosso fórum no tópico Desligamento dos protocolos SSL 3.0 e TLS 1.0 para SAT nos próximos meses no dia 28/03/2024 e também no tópico ATENÇÃO!!! Desativação de Protocolos inseguros na comunicação dos SATs SSL3.0 e TLS1.0 no dia 13/06/2024). A tabela abaixo mostra os modelos de SAT afetados por este processo: Fabricante Modelo de SAT Versões de Software Básico de SAT Há atualizações de SAT para versão mais segura? ControlID S@t-Id 01.02.00 SIM Kryptus EASYS@T 01.00.02 e 01.00.04 NÃO Sweda SS-1000 02.00.01 SIM

Olá pessoal! Ao conferir no painel Situação SVC, é possível confirmar que a Sefaz de Goiás está com a contingência ativada desde às 02h10 do dia 29/06/2024, com previsão de permanecer ativada até às 08h00 do dia 01/07/2024 Para utilizar as soluções ACBr em contingência durante este período, siga as orientações do tópico abaixo:

Olá pessoal! Foi publicada a versão 1.21 desta Nota Técnica. A nova versão trás uma correção na documentação do evento "Ator Interessado" esclarecendo que o CNPJ informado no evento não receberá o evento de Comprovante de entrega na NF-e Cancelamento(foi alterado de "SIM" para "NÃO" a última coluna da última linha da tabela anexada no tópico acima). As datas permanecem as mesmas da versão 1.20. A versão 1.21 da NT pode ser encontrada na íntegra AQUI.

Olá pessoal! A Sefaz de Minas Gerais ativou novamente a contingência às 15h37 do dia 29/06/2024, com previsão de permanecer ativa até às 12h00 do dia 30/06/2024.

Foi publicada a versão 24.1.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/06/2024 até 30/07/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

Boa tarde! OpenSSL apenas com A1. Embora tenhamos relatos de membros que usam A1 com Wincrypt, ele é o recomendado para A3.

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

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

Bom dia! Tópico vinculado a #TK-5659 para análise do caso. Usando o programa exemplo em C# e a versão mais recente da Lib no Fórum: Apaguei o arquivo ACBrLib.ini. Executei a Lib para que a mesma criasse um novo. Preenchi com dados fictícios, o PathSchemas do meu ambiente e as informações do certificado que tenho. Testei e recebi uma Rejeição E138 - Informe o CNPJ autorizado a executar o serviço. Com o programa exemplo em execução, alterei as configurações do emitente colocando as mesmas do arquivo INI disponibilizado previamente no Discord e salvei as configurações. Fiz um novo teste e recebi Rejeição E138 - Informe o CNPJ autorizado a executar o serviço. Renomeei meu arquivo ACBrLib.ini para .old, colei o arquivo ACBrLib.ini disponibilizado no Discord no diretório para que a lib carregasse dele. Fiz um novo teste e recebi o erro 500 conforme reportado. Comparando os dois arquivos com o WinMerge, com exceção dos certificados, do PathSchemas e da opção SalvarWS, a única diferença apontada foi a configuração de um proxy no seu arquivo. Por favor: As informações de proxy estão corretas? O nome do servidor é mesmo "XXX"? Para salvar a senha, você usou o Config_GravarValor ao invés de adicionar manualmente no INI, correto? É possível fazer um teste em um ambiente sem proxy?

Olá pessoal! Ao conferir no painel Situação SVC-RS é possível observar que a Sefaz do Mato Grosso está com contingência agendada. Com previsão de inicio às 08h00 do dia 30/06/2024 e término às 09h40 do dia 01/07/2024. Para utilizar as soluções ACBr em contingência durante este período, siga as orientações do tópico abaixo:

Olá pessoal! Ao conferir no Portal da Nota Fiscal Eletrônica, podemos ver que a Sefaz de Minas Gerais ativou a contingência no dia 27/06/2024 às 07h58, com previsão de encerramento às 12h00 do mesmo dia. Para utilizar as soluções ACBr em contingência siga as orientações do tópico abaixo: Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a informação em nosso Discord.

Se você configurou as opções para salvar os arquivos, ela gera o XML automaticamente na pasta para você. Agora se quiser recuperar o XML e trabalhar dentro do sua rotina, sim você pode usar o ObterXML

Bom dia! Veja que no conteúdo da resposta da Lib você tem: {"...<Protocolo>a406109f-47d5-4e30-bfdc-48b103e67161<\/Protocolo>&#13;<\/EnviarLoteRpsResposta>"} Isso é um indício de que o método de envio que este provedor usa é o assíncrono. Quando o envio é assíncrono, você: Envia o XML de RPS para o web service do provedor. Recebe de volta do Web Service, um número de protocolo que atesta que o seu XML foi recebido pelo web service. Consulta a Situação do Lote usando o número de protocolo com o método NFSe_ConsultarSituacao. Recebe no retorno da consulta de situação um número que indica qual é a situação atual do lote, os número geralmente* são: Número 1 que indica que o XML não foi recebido pelo web service do provedor. Número 2 que indica que o XML foi recebido, mas que ainda não foi processado. Número 3 que indica que o XML foi recebido e foi processado com erros. Número 4 que indica que o XML foi recebido e foi processado com sucesso. *Em alguns poucos provedores específicos, os números podem representar condições diferentes, mas pelo que pude conferir, não é o caso do Pronim. Se consultar a situação e receber 3 ou 4, você consulta o Lote com o método NFSE_ ConsultarLoteRps para receber os erros caso a situação seja 3 ou o XML da NFSe* caso a situação seja 4. *Alguns provedores não devolvem o XML completo, mas sim apenas algumas informações de que a nota foi aceita. Portando, agora você precisa consultar a situação com este protocolo que recebeu.

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

Olá pessoal! Informamos que a ACBrLibSAT possui agora dois novos métodos. São eles: SAT_CarregarXML: método que permite carregar as informações de um XML de CFe na Lib. SAT_ObterINI: método utilizado para que a Lib devolva o conteúdo de um CFe no formato de um arquivo INI. Ambos métodos foram implementados visando fornecer uma maior liberdade para que possam trabalhar com as informações de um CFe com a Lib. Um extra para quem é do C# Para aqueles que utilizam a ACBrLibSAT com C# e fazem uso das classes que disponibilizamos em nosso SVN ou no Nuget, com a adição destes novos métodos, agora é possível preencher a classe de alto nível com o conteúdo do CFe com poucas linhas. Vejam um exemplo: var xmlPath = Helpers.OpenFile("Arquivo xml CFe (*.xml)|*.ini|Todo os Arquivos (*.*)|*.*"); if (string.IsNullOrEmpty(xmlPath)) return; acbrSat.CarregarXML(xmlPath); // Linha responsável por preencher a classe. CupomFiscal cFe = acbrSat.ObterCFe(); //As propriedades vão ter os valores que foram lidos do XML carregado. cFe.InfCFe.Id; cFe.Identificacao.CNPJ; cFe.Destinatario.xNome;

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

Olá pessoal! No dia 21/06/2024, foi publicado o Correio Eletrônico Circular SEF/DIAT/Nº 12 / 2024 que trás as seguintes alterações nas Tabelas Externas 5.1.1, 5.2 e 5.3 da EFD para o estado de Santa Catarina: O correio eletrônico pode ser baixado e lido na íntegra AQUI. As tabelas já atualizadas podem ser encontradas AQUI.

Olá pessoal! Foi publicada a Nota Técnica 2024/002 que traz alterações no layout da NFCom e em suas regras de validação. Alterações Adição de novo cClass Adiciona na Tabela de Códigos de Itens da NFCom (cClass) o novo item: Alterações no Schema da NFCom Adiciona os seguintes novos campos: Campos referentes a informação da Nota modelo21/22 em papel na hiótese de um Cofaturamento referenciar um documento anterior a implantação eletrônica gNF > CNPJ: CNPJ do emitente do documento fiscal. gNF > mod: Modelo do documento. gNF > serie: Série do documento fiscal. gNF > nNF: Número do documetno fiscal. gNF > CompetEmis: Ano e mês da emissão da NF gNF > hash115: Hash do registro no arquivo convêncio 115 Indicador opcional para indicar que uma nota referenciada na nota de faturamento existe somente em modelo papel indNFComAntPapelFatCentral: Informa que a NFCom Anterior de Faturamento centralizado não é eletrônica Alterações nas regras de validação Dentre as alterações nas regras de validação, vale destacar: Regra G64, Rejeição 255: Altera a regra para que passe a mesma só seja aplicada quando o tipo da NFCom for de Ajuste(finNFCom = 4). Regra G67, Rejeição 515: Altera a mensagem de rejeição para: Adição de regras: Adiciona as regras de validação G76a com a rejeição 697, G76b com a rejeição 699 e G76c com a rejeição 700 para validar os novos campos do grupo gNF Adiciona a regra de validação G91a com a rejeição 698 para validar o novo campo indNFComAntPapelFatCentral. Datas Implantação Homologação: 01/07/2024. Implantação Produção: 15/07/2024. E como fica o ACBr? Como pode ser visto, nota técnica traz a inclusão de novos campos e por isso, alterações nos fontes do ACBr serão necessárias. Foi criada #TK-5624 em nosso backlog para implementação das alterações, quaisquer novidades serão divulgadas neste tópico. Leia a Nota Técnica na íntegra AQUI.

Boa tarde! Por favor, pode fazer um teste definindo nas configurações gerais a codificação resposta para Ansi? Se o problema persistir, volte a codificação para UTF8, defina PathSalvar e SalvarWS nas configurações específicas da NFSe, faça novo teste e disponibilize os arquivos -soap.xml gerados no caminho que definiu em PathSalvar para que possamos analisar.