Diego Foliene

Olá pessoal! Conferindo no Portal da Nota Fiscal Eletrônica, é possível conferir que a Sefaz de São Paulo está com a contingência agendada para o dia 14/07/2024, com previsão de início às 06h00 e término às 16h00 do mesmo dia. Para utilizar as soluções ACBr em contingência durante este período, siga as orientações do tópico abaixo: Um agradecimento ao membro de nossa comunidade @Felipe Marianopor compartilhar a informação em nosso Discord.

Também recebemos relatos de que a Sefaz do Paraná devolveu está rejeição no dia 02/07/2024 pela manhã. Por volta das 12:15 e 12:25 ao tentar emitir era recebido Notas emitidas após este período foram autorizadas, dando a entender que a UF do PR também havia ativado a regra e a desativou após relatos de problemas. Um agradecimento ao membro de nossa comunidade @VagnerBegnini por compartilhar a informação conosco.

Olá pessoal! Desde a ativação no ambiente de produção das regras de validação da Nota Técnica 2023/004, alguns membros de nossa comunidade tem relatado estar recebendo a rejeição: Essa rejeição é devolvida quando é informado na nota o tipo de pagamento Cartão de Crédito (tPag=03), Cartão de Débito (tPag=04) ou Pagamento Instantâneo (PIX) - Dinâmico (tPag=17) e não é informado o grupo card. Conforme regra de validação da própria rejeição: Considerando os múltiplos relatos em diferentes Sefaz e o fato de a implementação da regra ser opcional a critério da UF. Nossos colegas da AFRAC buscaram mais informações, entrando em contato com as Sefaz de PB, PE, MG e RJ questionando sobre a ativação desta regra em específico, obtendo as seguintes respostas: Sefaz de MG: “Vamos retornar à regra anterior, ou seja, sem ativar a validação em questão, portanto, apenas para cartão. Para isso, teremos que subir uma versão da aplicação. Enquanto isso, a opção é usarem o código 20 ao invés do 17." Sefaz da PB: “Quem informava o código 17 para Pix estático deve informar o código 20. Iremos publicar no site oficial da Sefaz ainda hoje (01/07) após às 17h." Portanto, para evitar a rejeição, o Pix deverá ser informado no código 20 e, assim, evitar o preenchimento do código de autorização desse formato de pagamento. Em tempo, irão realizar pedido à SVRS para desativar temporariamente a regra de validação Y04-10 para o estado da Paraíba. A expectativa é que a SVRS faça isso até amanhã pela manhã (02/07), portanto, no momento, a solução é informar o código 20 no Pix para não obrigar a informar o grupo de cartões, onde terá que informar o E2dID Sefaz de PE: Aguardando resposta. Sefaz do RJ: "Isso ocorreu porque as empresas estavam acostumadas a informar o código 17 para o PIX. Agora elas devem informar o código 20 se for PIX estático. Se continuarem a informar o código 17 é o PIX dinâmico e a regra de validação exige informar o grupo card, pelo menos o código de autorização do PIX (endToEndId - e2eid ). A AFRAC encaminhou pedido de reavaliação para desativação dessa regra de validação nas UF´s que não disciplinaram a interligação dos pagamentos tal como realizado no RS e MT." Este tópico foi feito baseado em comunicado publicado no Radar AFRAC e que pode ser encontrado na íntegra AQUI.

Vamos continuar no tópico abaixo:

Tópico movido para área aberta conforme solicitado.

Bom dia! Criada a #TK-5672 em nosso backlog para análise do caso e parecer por parte da equipe de consultores.

Reportado no Discord que conseguiu emitir a NFSe com sucesso após remover configuração de proxy.

Olá pessoal! No dia 01/07/2024, alguns membros de nossa comunidade começaram a relatar que ao tentar emitir uma NF-e ou NFC-e estão recebendo a rejeição: Está rejeição foi introduzida na Nota Técnica 2023/001 em sua versão 1.00, no entanto, a mesma foi removida logo na versão 1.10 permanecendo assim até a sua versão 1.51 que é a mais atual. Hoje, dia 01/07/2024, está entrando em vigor no ambiente de produção a Nota Técnica 2023/004 que coincidentemente adiciona a seguinte rejeição: PORTANTO, se você está recebendo a rejeição 963 com a mensagem de Alíquota adrem, verifique se informou no tPag da respectiva nota valor diferente de 03, 04, 10, 11, 12, 13, 15, 17 e 18 e adicionou o grupo card. Se o fez, remova o grupo card, conforme Regra de Validação da própria rejeição: Aprovada a nota, também é muito importante que abram um Fale Conosco junto a respectiva Sefaz, relatando que a mensagem que está sendo devolvida está incorreta.

Olá pessoal! A equipe de consultores do ACBr está sempre buscando melhorar os componentes e as soluções com o objetivo de facilitar e auxiliar o dia a dia do desenvolvedor. Por isso, gostaríamos de anunciar que houve um refactogin na classe TACBrHTTP que fica na unit ACBrSocket! A alteração foi enviada ao SVN na Revision-34143, onde as melhorias foram incluídas junto do seguinte Log: Esmiuçando as mudanças... Na unit ACBrSocket foram adicionadas algumas constantes utilizadas em validações internas e que também podem ser aproveitadas caso a unit seja declarada na seção uses. Alguns exemplos incluem: cHTTPTimeOutDef = 90000; cHTTPMethodGET = 'GET'; cHTTPMethodPOST = 'POST'; //... cHTTPProtocols: array[0..2] of string = ('http','https', 'ftp'); //... HTTP_CONTINUE = 100; HTTP_SWITCHING_PROTOCOLS = 101; HTTP_PROCESSING = 102; HTTP_OK = 200; //... A unit ACBrSocket foi adicionada a classe TACBrHTTPQueryParams que deriva de TStringList e conta com o parâmetro AsURL. TACBrHTTPQueryParams = class(TStringList) private function GetAsURL: String; procedure SetAsURL(const aValue: String); public property AsURL: String read GetAsURL write SetAsURL; end; A classe TACBrHTTP ganhou as propriedades URLPathParams do tipo TStringList, URLQueryParams do tipo TACBrHTTPQueryParams, HTTPResponse e HTTPResultCode (essas duas últimas substituindo a propriedade RespHTTP). Também foram adicionadas propriedades para permitir capturar Log. São elas ArqLOG do tipo string, NivelLog do tipo Byte e o evento OnQuandroGravarLog. A propriedade IsUTF8 que permitia escrita e leitura foi alterada pela propriedade RespIsUTF8 de apenas leitura. TACBrHTTP = class(TACBrComponent) private //... fArqLOG: String; fHTTPResultCode: Integer; fNivelLog: Byte; fHTTPResponse: AnsiString; fURLPathParams: TStringList; fOnQuandoGravarLog: TACBrGravarLog; fURLQueryParams: TACBrHTTPQueryParams; fContenstEncodingCompress: THttpContentsEncodingCompress; protected //... procedure RegistrarLog(const aLinha: String); public //... procedure LimparHTTP; property HTTPResponse: AnsiString read fHTTPResponse; property HTTPResultCode: Integer read fHTTPResultCode; property URLPathParams: TStringList read fURLPathParams; property URLQueryParams: TACBrHTTPQueryParams read fURLQueryParams; published //... property RespIsUTF8: Boolean read GetRespIsUTF8; property ContentsEncodingCompress: THttpContentsEncodingCompress read fContenstEncodingCompress write fContenstEncodingCompress; property ArqLOG: String read fArqLOG write fArqLOG; property NivelLog: Byte read fNivelLog write fNivelLog default 1; property OnQuandoGravarLog: TACBrGravarLog read fOnQuandoGravarLog write fOnQuandoGravarLog; end; Por que saber disso é importante? A classe TACBrHTTP é utilizada como base para conexão com web services por muitos componentes. Tanto que as units ACBrPicPay, ACBrCEP, ACBrConsultaCPF, ACBrCotacao, ACBrFeriado, ACBrFrenet, ACBrIBGE, ACBrIBPTax, ACBrNCMs, ACBrNFPw, ACBrSedex, ACBrSPEDTabelas, ACBrSuframa e ACBrTaxDolar foram compatibilizadas com as alterações no mesmo commit. Esperamos que o refactoring traga impactos positivos a todos os membros da comunidade e contamos com a colaboração de todos com relatos de problemas e sugestões de melhorias.

Olá pessoal! Foi publicado Ato Diat Nº031/2024. O mesmo altera artigo 3º do Ato DIAT Nº059/2023 que define obrigatoriedade para os campos vICMSDeson e e motICMSDeson na emissão de NF-e e NFC-e para o estado de Santa Catarina. A nova redação do artigo ficou como: Na prática prorrogando a obrigatoriedade dos campos para a data estabelecida.

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: