Diego Foliene

Bom dia @LeonardoRocha. Conferi junto aos responsáveis que estão atuando na tarefa. Foram enviadas modificações no componente nativo que consideram o retorno como ANSI e fazem a conversão para UTF8 para o provedor IPM. A nova versão da Lib que foi disponibilizada deve englobar a referida alteração. Por favor, queira atualizar para que possa realizar novo teste e reportar qualquer problema.

Olá pessoal! Foi publicado no dia 23/07/2024, no portal SPED, comunicado informando sobre a versão 10.0.10 do programa ECF utilizado para transmitir arquivo do ano-calendário 2023 e situações especiais de 2024(item 10). A nova versão trás as seguintes atualizações: Fonte: http://sped.rfb.gov.br/pagina/show/7488

Olá pessoal! Foi publicado uma notícia informando que a Secretaria do Estado da Fazenda de Santa Catarina resolveu interromper o processo de implementação do Dispositivo Autorizador Fiscal(DAF). Iniciado em 2018 e com a última movimentação do assunto em 2023, o DAF era um equipamento que viria a ser adotado pela UF nas vendas no varejo visando fornecer ao fisco um maior controle sobre os documentos emitidos principalmente em contingência. No entanto, após novo levantamento de informações por parte do fisco que indicou que o volume de documentos emitidos em contingência é pouco expressivo e que existem também outras alternativas para controle. Essas novas informações somadas ao objetivo de reduzir a burocracia na emissão de documentos fizeram com que a Diretoria de Administração Tributária (DIAT) da Fazenda concluíssem que o modelo definitivo de controle da emissão e autorização das NFC-e em Santa Catarina deve continuar usando os softwares emissores já existentes. Leia a notícia na íntegra AQUI.

Bom dia! Ainda não. Dando mais detalhes sobre o seu caso: O problema é que o Web Service do Provedor está devolvendo a resposta no formato ANSI e a leitura do retorno espera receber um arquivo codificado em UTF-8. A função que mencionei anteriormente é uma função que foi criada para tentar identificar qual é o encoding de uma string para que a Lib possa decidir se vai aplicar a conversão ou não. No entanto, depois de pesquisa e também testes com a referida função, viu se que não é possível determinar com 100% de precisão a codificação de um arquivo. Esta sendo analisado agora se será feita a conversão de ANSI para UTF-8 em todos os casos para este provedor ou se outro curso de ação deverá ser tomado. Entendo que esteja com problemas na emissão. Vou informar aos consultores que estão atuando que você pediu um status da situação.

Olá pessoal! Foi enviado ao SVN na Rev-34473 uma alteração que muda a lógica de geração dos campos quantidade tributada (qBCMono), quantidade tributada sujeita a retenção (qBCMonoReten) e quantidade tributada retida anteriormente (qBCMonoRet). O que mudou? Nas rotinas de geração do arquivo XML, o parâmetro que equivale ao número de ocorrências dos respectivos campos foi alterado de 0 para 1. Isso faz com que esses campos sempre sejam criados, independentemente de haver valor informado ou não na propriedade. Preenchendo com zeros quando valor não for atribuído. Por que mudou? Originalmente os campos foram adicionados na rotina de criação do XML com o parâmetro do número de ocorrências com o valor zero conforme o layout. Isso significa que o campo é opcional e nesse caso, quando o valor informado for zero ou não houver nenhum valor atribuído o campo não seja criado no XML. No entanto, apesar de o número de ocorrências ser zero, existem rejeições que obrigam o preenchimento desses campos mesmo quando o valor for zero. Um exemplo disso é a rejeição 767 cuja regra de validação é: E a mensagem de rejeição é: Por isso, entendemos que mesmo que o número de ocorrências indique que o campo seja opcional, logicamente falando, faz sentido que o mesmo seja sempre inserido. Para que a modificação tenha efeito, é necessário atualizar os fontes e reinstalar o ACBr. Para aqueles que utilizam ACBrMonitor ou ACBrLib, as versões compiladas após o dia 17/07/2024.

Olá pessoal! Conferindo no portal Sobre o SAT, consta um aviso informando que no dia 23/07/2024 será realizada uma manutenção na autoridade certificadora(AC) da Sefaz entre às 03h00 e às 10h00. Durante este período a orientação é de que não seja efetuada a ativação de equipamentos SAT e no caso de falhas, não seja alterado o código de ativação. Caso tenham problemas na renovação de certificados com o AC-SAT, a orientação é de que desliguem o equipamento e voltem a ligá-lo após a conclusão da atividade.

Boa tarde! Apenas confirmando, em sua primeira postagem, acredito que tenha ocultado os valores, mas você está preenchendo o Usuario e a Senha na seção [Email], correto? Você está colocando o endereço de e-mail do remetente no Usuario e a senha de app que foi gerada na Senha?

Bom dia! Seu caso segue em análise. Estamos testando uma função que acreditamos que possa resolver o problema. Assim que houver mais detalhes informamos aqui.

Bom dia! Apenas dando um retorno. A TK foi alocada no sprint dessa semana e estamos analisando o problema.

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

Bom dia. Por favor, veja:

Por favor, aguarde nova compilação da Lib para realizar os testes. A Lib costuma ser compilada todas as terças-feiras de manhã.

Boa tarde! Foi enviado ao SVN na Rev-34406 um commit adicionando as informações NumeroNota, CodigoVerificacao, NumeroRPS, SerieRPS e Data na resposta da Lib. As respectivas informações foram adicionadas na seção [ArquivoXX]. O motivo deste ter sido o local escolhido para adição das informações é porque em um lote de RPS podem ser enviados até 50 RPS e portanto podem ser devolvidas até 50 NFSes. (Pode ter até 50 ocorrências do grupo <CompNFSe> dentro do <ListaNFSe> no XML de retorno). Então, na LibNFSe compilada depois do dia 15/07/2024 a resposta será devolvida assim: { "ConsultaLoteRps": { "CodVerificacao": "PJ8F-IYAG", "Arquivo1": { "CaminhoCompleto": "C:\\ACBr\\trunk2\\Projetos\\ACBrLib\\Demos\\C#\\NFSe\\Demos\\ACBrLib.NFSe.Demo\\bin\\Debug\\Docs\\Notas\\20-nfse.xml", "CodigoVerificacao": "PJ8F-IYAT", "NomeArquivo": "20-nfse.xml", "NumeroNota": "20", "NumeroRPS": "56", "SerieRPS": "1" }, "Arquivo2": { "CaminhoCompleto": "C:\\ACBr\\trunk2\\Projetos\\ACBrLib\\Demos\\C#\\NFSe\\Demos\\ACBrLib.NFSe.Demo\\bin\\Debug\\Docs\\Notas\\21-nfse.xml", "CodigoVerificacao": "PJ8F-IYAG", "NomeArquivo": "21-nfse.xml", "NumeroNota": "21", "NumeroRPS": "57", "SerieRPS": "1" }, "Lote": "1", "Protocolo": "123465798", "Situacao": "4", "XmlEnvio": "<ConsultarLoteRpsEnvio xmlns=\"http://www.abrasf.org.br/ABRASF/arquivos/nfse.xsd\">..." "XmlRetorno": "<ConsultarLoteRpsResposta xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.abrasf.org.br/ABRASF/arquivos/nfse.xsd\"><ListaNfse><CompNfse>..." } }

Muito obrigado! O e-mail é: [email protected]

Que bom que deu certo! Muito obrigado pelo feedback! Aproveitando, vamos revisar o ACBrGtin.PRG que disponibilizou para ver se não ficou com nenhuma informação de cunho sensível. Estando tudo em ordem, podemos disponibilizar o mesmo em nosso SVN como um exemplo de consumo da Lib GTIN com Harbour? Obviamente lhe damos os devidos créditos no commit.

Olá pessoal! Informamos que foi enviado ao SVN nas revisions 34362 e 34363 as modificações que compatibilizam o ACBreSocial com os novos ajustes do e-Social relacionados ao eConsignado! Mas o que é o eConsignado afinal? O eConsignado é um projeto do governo federal que visa facilitar ao trabalhador do setor público a aquisição de empréstimos consignados de maneira simplificada reduzindo a intermediação dos bancos. O sistema será integrado ao FGTS digital permitindo que os trabalhadores façam a contratação do empréstimo direto pela plataforma. Com isso os empregadores poderão incluir na guia de recolhimento do e-Social o valor da parcela, descontado do contracheque, e o sistema fará a transferência automática para os bancos credores. E o que exatamente mudou no ACBr? O enumerado tpCodIncFGTS usado para definir o código da incidência da rubrica para o FGTS enviado no evento S-1010(Tabela de Rúbricas) ganhou o valor cdfDescontoeConsignado que converte para o valor 31 ao gerar o XML. O enumerado tpTpAcConv usado para definir o tipo de instrumento ou situação ensejadora da remuneração relativa a períodos de apuração anteriores ganhou os novos valores tacDeclaracaoBaseCalcFGTSAntAoInicFGTSDigital, tacSentencJudicial e tacParcelasComplementares que convertem para H, I e J respectivamente ao gerar o XML. Foi adicionado no evento evtBasesFGTS (S-5003) que devolve as informações do FGTS por trabalhador, uma classe para receber as informações do eConsignado que forem devolvidas. A mesma pode ser acessada conforme exemplo: procedure LerS5003(const evtS5003: TS5003); var i, j, k: Integer; LIdeEstabLot: TIdeEstabLot2CollectionItem; LInfoTrabFGTS: TInfoTrabFGTSCollectionItem; LEconsignado: TeConsignadoCollectionItem; instFinanc, nrContrato: String; vreConsignado: Double; begin for i:=0 to Pred(evtS5003.EvtBasesFGTS.infoFGTS.IdeEstabLot.Count) do begin LIdeEstabLot := evtS5003.EvtBasesFGTS.infoFGTS.IdeEstabLot.Items[i]; for j:=0 to Pred(LIdeEstabLot.InfoTrabFGTS.Count) do begin LInfoTrabFGTS := LIdeEstabLot.InfoTrabFGTS.Items[j]; for k:=0 to Pred(LInfoTrabFGTS.eConsignado.Count) do begin LEconsignado := LInfoTrabFGTS.eConsignado.Items[k]; instFinanc := LEconsignado.instFinanc; nrContrato := LEconsignado.nrContrato; vreConsignado := LEconsignado.vreConsignado; end; end; end; end; procedure LerRetornoConsultaeSocial; begin if ACBreSocial1.Consultar(NumeroProtocolo) then begin LRetornoConsultaLote := ACBreSocial1.WebServices.ConsultaLote.RetConsultaLote; if LRetornoConsultaLote.Status.cdResposta in [201, 202] then begin for i:=0 to Pred(LRetornoConsultaLote.retEventos.Count) do begin LRetornoEventos := LRetornoConsultaLote.retEventos.Items[i]; for j:=0 to Pred(LRetornoEventos.tot.Count) do begin if (LRetornoEventos.tot[j].Evento.TipoEvento = teS5503) then begin LerS5003(TS5003(LRetornoEventos.tot[J].Evento.GetEvento)); end; end; end; end; end; end; E se eu uso o ACBrMonitor ou a Lib? Utilizando Monitor ou Lib os novos valores já serão considerados nas rotinas de conversão, então, caso queira enviar, por exemplo, um evento S-1010 com a informação do codIncFGTS com o novo valor, basta informá-lo em seu arquivo INI criado seguindo o modelo S-1010: Em um exemplo simples: Mesma lógica se aplica para o tpTpAcConv. ATENÇÃO: Independente da solução que estiver utilizando os schemas também devem ser atualizados!

Estou fazendo testes com o exemplo em C# e com o exemplo que disponibilizou, mas a princípio não estou tendo problemas. Estamos analisando quaisquer diferenças para ver se encontramos alguma pista do que pode ser. Dito isso, uma das diferenças que notamos é que no GTIN.zip que disponibilizou para nós no Discord, tinha somente as Dlls do OpenSSL. Mas quando você faz o download da ACBrLibGTIN, na pasta de dependências, além das dlls do OpenSSL tem também as dlls da LibXML. Está última é utilizada para fazer a leitura de XMLs. Por favor, se elas já não estiverem na pasta do projeto no mesmo nível das dlls da OpenSSL, adicione as e faça um novo teste.

Bom dia! Por favor, qual é o valor da sua configuração TipoResposta no arquivo ACBrLib.ini?

Bom dia! Muito obrigado! Criada a #TK-5632-1 para análise do caso e parecer por parte da equipe de consultores e os arquivos disponibilizados foram anexados na mesma.

Olá pessoal! No dia 12/07/2024 foi publicada a versão 1.01 desta nota técnica. A nova versão renumera algumas regras de validação que estavam devolvendo o mesmo cStat de regras já estabelecidas por NTs anteriores. As datas de implantação permanecem as mesmas. Leia a nova versão da NT na íntegra AQUI.

Olá pessoal! Foi publicado no dia 12/07/2024, no portal SPED, comunicado informando sobre a versão 10.0.9 do programa ECF utilizado para transmitir arquivo do ano-calendário 2023 e situações especiais de 2024(item 10). A nova versão trás as seguintes atualizações: Fonte: http://sped.rfb.gov.br/pagina/show/7477

Olá pessoal! Conferindo no painel Situação SVC é possível observar que a Sefaz de Pernambuco ativou a contingência no dia 13/07/2024 às 05h30, com previsão de permanecer ativada até às 09h00 do dia 15/07/2024. Para utilizar as soluções ACBr em contingência durante este período siga as orientações do tópico abaixo:

Bom dia! Realizado teste com o exemplo disponibilizado via Discord. O Log gerado segue em anexo. Orientado no Discord que seja feito teste em outra máquina. ACBrLibGTIN-20240712.log