Diego Foliene

Tópico reaberto a pedido do assinante.

Bom dia! Uma possível sugestão seria instalar as fontes Microsfot. Por favor, siga as orientações deste link e veja se o problema persiste. https://docs.groupdocs.com/viewer/java/how-to-install-windows-fonts-on-ubuntu/

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

Boa noite! Traz sim, mas somente se o web service de consulta devolver a informação. Por exemplo este é o resultado ao consultar o CNPJ do Pão de Açucar no CNPJWS:

Olá pessoal! Conferindo no Portal da Nota Fiscal Eletrônica, é possível observar que a Sefaz de Minas Gerais ativou a contingência no dia 04/07/2024 às 08h20, com previsão de permanecer ativada até às 12h00 do mesmo dia. Para utilizar o ACBr em contingência durante este período, 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.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-5692

Olá pessoal! A Sefaz do Ceará divulgou um comunicado informando que no dia 05/07/2024 das 07h00 até às 08h00 será feita uma manutenção programada nos serviços relacionados ao Conhecimento de Transporte Eletrônico. Durante este período a emissão e a autorização não serão afetadas, mas a consulta do CT-e emitido estará indisponível. Leia o comunicado na íntegra AQUI.

Olá pessoal! Foi publicado no dia 02/07/2024 a nota técnica 2024/002 para NF3e. Seguindo o que parece ser uma tendência para os documentos fiscais eletrônicos, esta NT estabelece o fim do serviço de recepção de lote de forma assíncrona para a NF3e. Dentre as justificativas apontadas para esta desativação temos: Complexidade em manter o serviço assíncrono controlando o envio e posterior busca de resultados. Estatísticas apontam que 95% das emissões já ocorrem no modelo síncrono. Após a desativação, quem tentar emitir em modo assíncrono vai receber a rejeição: DATAS Desativação no ambiente de Homologação: 02/09/2024 Desativação no ambiente de Produção: 07/09/2024 E como fica o ACBr? O componente ACBrNF3e atende a ambos os modos de envio, sendo configurado via parâmetro no comando Enviar. // Parâmetros do método Enviar: // 1o = Número do Lote // 2o = Se True imprime automaticamente o DANF3e // 3o = Se True o envio é no modo Síncrono, caso contrario Assíncrono. ACBrNF3e.Enviar(StrToInt(vNumLote), True, True); Então a partir das datas citadas, em um exemplo enviando o número de lote 1, mandando imprimir e lendo os dados do retorno será assim: //Faz o envio ACBrNF3e.Enviar('1', True, True); //Lê os dados do retorno. ACBrNF3e.WebServices.Enviar.XXXXX Leia a NT na íntegra AQUI.

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