Painel de líderes

Olá pessoal! No dia 10/07/2024 foi publicado pela Sefaz de São Paulo a Portaria SRE 40 de Julho de 2024. A nova portaria dispõe sobre a emissão da nota fiscal de consumidor eletrônico - NFC-e, seu respectivo documento auxiliar, o credenciamento dos contribuintes e outras providências. A principal novidade trazida por esta portaria é a redação do artigo 6º, cujo conteúdo segue abaixo na íntegra: Em suma, o referido texto, significa que agora é permitido realizar a emissão de NFC-e para o estado de São Paulo, fazendo uso da contingência off-line. Já conhecida e utilizada para este documento em outras UFs emissoras. Um agradecimento ao membro de nossa comunidade @marcopoloviana por compartilhar a informação em nosso Discord. Vale lembrar que os membros ACBr PRO tem acesso ao curso Implementando a Contingência Off-line, onde o modelo de contingência é explicado e demonstrado na prática.

Boa tarde! Fiz um ajuste na classe TACBrHTTP, onde inclui uma nova propriedade para indicar para o componente não disparar o raise error quando o response code for diferente de 200, 201 ou 202. Propriedade: RaiseErrorOnResponse Valor default: True Segue a unit com os ajustes para verificação. ACBrSocket.pas

@Italo Giurizzato Junior Estou enviando o arquivo ACBrOFX.pas modificado, pois não está tratando a tag <TRNTYPE> (Propriedade no ACBrOFX: MovType) adequadamente conforme Manual de Especificações do OFX (https://financialdataexchange.org/common/Uploaded%20files/OFX%20files/OFX%20Banking%20Specification%20v2.3.pdf). Assim, alterei a Function Import para fazer o tratamento corretamente conforme item 3.2.9.2 Positive and Negative Signs na página 95 e item 11.4.4.3 Transaction Types Used in <TRNTYPE> na página 235 do mesmo manual, para verificar se a tag <TRNAMT> tem valor negativo ou positivo, uma vez que a maioria dos tipos são baseados no valor, como é o caso do tipo XFER que pode ser Débito de Transferência ou Crédito de Transferência. Com isto, o ACBrOFX não retorna mais "OTHER" no MovType, mas sim "D" ou "C". Esta informação será retornada na nova propriedade que eu criei "OriginalMovType". Além de alterar o código da função, criei a propriedade "OriginalMovType" que guardará o <TRNTYPE> original do OFX, pois os códigos de tipos do OFX são também importantes, já que tem significado e podem ser tratados pelos sistemas. Obs.: Deixei os códigos anteriores comentados. ACBrOFX.pas

Olá, senhores. Estou tendo problemas com a leitura de um arquivo de retorno do banco Bradesco, modelo CNAB-400, em resposta a uma alteração de vencimento. Apenas para contextualização: Foi emitido um boleto e enviado ao banco Bradesco que confirmou seu registro normalmente, com a motivação "P1" (Registrado com QR CODE PIX) Dias depois, foi enviado em uma nova remessa, uma solicitação para alteração de vencimento, com a motivação "06" (Alteração de Vencimento) O retorno do banco trouxe dois registros para o mesmo boleto, sendo uma ocorrência "14" (Vencimento Alterado) e outro registro com ocorrência "33" (Confirmação Pedido Alteração Outros Dados), ambas com a motivação "P8" (Alteração não Permitida - QR CODE Pago ou Cancelado) Para variar, existe esse retorno do banco que parecem ser dois registros redundantes, mas no que diz respeito à nossa parte técnica, existe uma falha no procedimento ACBrBoleto.LerRetorno400(), especificamente no trecho abaixo: CodMotivo := IfThen(copy(Linha,MotivoLinha,2) = ' ','00',copy(Linha,MotivoLinha,2)); ... {Somente estas ocorrencias possuem motivos 00} if(CodOcorrencia in [02, 06, 09, 10, 12 ,13, 14, 15 ,17])then begin MotivoRejeicaoComando.Add(IfThen(copy(Linha,MotivoLinha,2) = ' ','00',copy(Linha,MotivoLinha,2))); if VarIsNumeric(CodMotivo) then DescricaoMotivoRejeicaoComando.Add(CodMotivoRejeicaoToDescricao(OcorrenciaOriginal.Tipo,Integer(CodMotivo))) else DescricaoMotivoRejeicaoComando.Add(CodMotivoRejeicaoToDescricao(OcorrenciaOriginal.Tipo,VarToStr(CodMotivo))); end else begin if(CodMotivo = 0)then ... end; Quando a ocorrência é "33", o algoritmo não atende ao if do conjunto, logo, o else é executado, fazendo com que seja levantada uma exceção, na comparação do valor de CodMotivo, que assume no momento o valor string "P8" com o valor integer "0", levantando uma exceção. Nessa situação, acredito que será necessário um ajuste nos fontes, simplesmente incluindo a ocorrência "33" na validação do conjunto: if(CodOcorrencia in [02, 06, 09, 10, 12 ,13, 14, 15, 17, 33])then Assim o variant receberá sua tratativa e evitaremos o levantamento da exceção. Obs.: O Manual de Procedimentos Operacionais para Troca de Arquivos (Bradesco) trata dessa informação na Página 46, e foi utilizado a versão mais recente, localizado no próprio svn: ..\tools\Bancos\237-Bradesco\CNAB400_Cobranca_2022_VER003.pdf

Boa tarde @Mauricio Elias, Você tem fontes do ACBr com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build. Por fim repita os testes.

Deu certo Daniel, muito obrigado pela atenção! Abraço!

Boa tarde, Fiz a consulta usando os seus dados 03997115000190 e não retornou razão social no campo de IE, isso acredito que eles trataram no lado da API deles, tudo indica ser um erro na API que já foi corrigido.

Deu certo, muito obrigado Daniel!! Abraço!

Segue em anexo, unit ACBrBoleto.pas com a sugestão de correção. ACBrBoleto.pas

Bom dia @João Antônio, Já esta no SVN.

Bom dia @Diego Reckziegel, Já esta no SVN.

Bom dia @BSSOFT, Verificando o arquivo ACBrNFSeXServicos.ini notei que a referida cidade foi atualizada no dia 14/06/2024, veja: [4310207] ; Atualizado em 14/06/2024 Nome=Ijui UF=RS Provedor=Pronim ProRecepcionar=http://ijui.govbr.cloud/nfse.portal.integracao/services.svc ProLinkURL=http://ijui.govbr.cloud/nfse/VisualizarXMLdaNota.aspx?Prestador=&Numero=%NumeroNFSe%&Codigo=%CodVerif%&page=default.aspx&origin=ConAut&pdf=true HomLinkURL=http://ijui.govbr.cloud/nfse/VisualizarXMLdaNota.aspx?Prestador=&Numero=%NumeroNFSe%&Codigo=%CodVerif%&page=default.aspx&origin=ConAut&pdf=true Provavelmente você esta com os seus fontes desatualizados.

1. Não use capicom, ela foi depreciada pela Microsoft há mais de 10 anos e em algumas situações corrompe e inutiliza o certificado do token. * Utilize as configurações recomendadas, conforme o tópico a seguir. 2. Se for certificado A1, configure para utilizar via arquivo pfx que não terá esse problema Certificados.ArquivoPFX := CaminhoDoLocalEmQueEstaSalvoOArquivoPFX; Certificados.Senha := SenhaDoPFX; 2.1. Se for certificado A3, o serviço do windows utiliza um usuário para operar. * Você deve instalar o certificado digital no mesmo usuário que o serviço está utilizando para ele ter acesso.

Obrigado @Italo Giurizzato Junior Quando vocês solucionarem, pode me dar um retorno?

Pessoal Corrigindo... Não é StrToTipoAutor o correto é TipoAutorToStr Acabei fazendo confusão na hora de escrever

Bom dia e muito obrigado pela prontidão.

Boa noite @Juliomar Marchetti Funcionou certinho... bem mais simples! Só tive que dar um FDConnection.Commit após os comandos commitupdates ou applayupdates para liberar o registro no banco de dados. Muito obrigado meu amigo!

Você parece que saiu do Loop, quando recebeu o PWRET_NOTHING 10:24:19:963 [PGWebLib.c] PW_iExecTransac <-2493> <--- PWRET_NOTHING 10:24:20:366 [PGWebLib] PP_Treatment Selecionado: [0x41] 10:24:21:782 [PGWebLib.c] Confirmacao auto (0x41131, 268612, 269, , PIX C6 BANK) IGNORADA 2 10:24:21:962 [PGWebLib.c] PW_iConfirmation(0x3221, 0000268612, 269, , 4607, PIX C6 BANK) <0> O correto seria aparecer uma nova chamada a PW_iExecTransac no Log Veja o Loop do ACBr ele permanece no Loop enquanto o Retorno for (PWRET_OK, PWRET_NOTHING, PWRET_MOREDATA) iRet := PWRET_OK; while (iRet = PWRET_OK) or (iRet = PWRET_NOTHING) or (iRet = PWRET_MOREDATA) do begin {$IfDef FPC} Initialize(ArrParams); {$EndIf} NumParams := Length(ArrParams)-1; GravarLog('PW_iExecTransac()'); iRet := xPW_iExecTransac(ArrParams, NumParams); GravarLog(' '+PWRETToString(iRet)+', NumParams: '+IntToStr(NumParams)); case iRet of PWRET_OK: Break; PWRET_NOTHING: Sleep(CSleepNothing); PWRET_MOREDATA: iRet := ObterDados(ArrParams, NumParams); end; end;

Tive este mesmo problema e não entendi, por que no manual não tem nada sobre isso ! 02RETORNO01COBRANCA 00000000000005804791ASSOCIACAO DE REDE PLUS DE BEN237BRADESCO 0107240160000000015 030724 000001 1020582903200011800000090028600114200 000000000000091427060000000000000000000000000902010724914270 00000000000009142706020724000000260400023704159 000000000019900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000 000002 1020582903200011800000090028600114200 000000000000091427060000000000000000000000000906010724914270 00000000000009142706010724000000260400000103613 000000000000000000000000000000000000000000000000000000000000000000000000000000000000260400000000000000000000000000000 030724 00000000000000 000003 1020582903200011800000090028600114200 000000000000090635980000000000000000000000000910010724906359 00000000000009063598300424000000492150023700000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 1600000000 000004 1020582903200011800000090028600114200 000000000000091427060000000000000000000000000914010724914270 00000000000009142706010724000000260400023709999 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 P800000000 000005 9201237 000000010000000260400000000015 00001000002604000000002604000000010000026040000000100000492150000000000000000000000010000026040000000000000000000000000000000000000 00000000000000000000000 000006

Boa tarde @ralty, Vou fazer um teste e depois lhe comunico.

Boa tarde @giovani deitos, O componente ao ler o XML da NFS-e, caso não conste as informações sobre o tomador ele automaticamente coloca a mensagem de Tomador Não Identificado no DANFSE. Faça o seguinte: Você tem fontes do ACBr com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build. Por fim repita os testes.

Realizei testes em ambos os métodos, NFE_LimparLista e NFE_StatusServico.. Foi realizado testes unitários nos métodos, para que tenhamos certeza, caso ocorrer algum erro de Access Violation ou não nos métodos do ACBrLib.. Estou utilizando a ultima versão disponível para download no fórum, carregando ela nos testes com base na versão que você esta utilizando.. ACBrLibNFe32.dll, CDECL na versão MultiThread.. Realizei dois testes.. O primeiro teste estou carregando apenas um arquivo .ini e limpando a lista logo em seguida.. veja trecho do log: O Segundo testes estou carregando 50 arquivos .ini após carregar o ultimo arquivo .ini, realizei a consulta do status serviço... com o método NFe_StatusServico, feito isso, foi chamado método NFE_LimparLista, veja o trecho do log: Por desencargo, realizei os mesmo teste usando método NFE_CarregarXML.. Log Testes unitários: ACBrLibNFE-20240710-TestesUnitários.log E por ultimo, realizei testes com o programa exemplo C# disponível no SVN.. utilizando a ultima versão do ACBrLib com as mesmas configurações no qual você citou.. Log testes Programa Exemplo C#: ACBrLibNFE-20240710.log

Boa tarde. Mandei o email.

Boa tarde, Criada TK-5706 para análise.

Sim, segue tópico da notícia.

Olá pessoal! Foi publicado no dia 23/04/2024 na página de notícias do eSocial, uma notícia informando que o conjunto de cifras utilizado no estabelecimento da conexão com o eSocial será revisado. A medida visa aprimorar a segurança no serviço do eSocial e acarretará na eliminação dos protocolos TLSv1.0 e TLSv1.1 de acordo com o cronograma: 24/06/2024: Eliminar o protocolo TLSv1.0 24/07/2024: Eliminar as cifras CBC 26/08/2024: Eliminar o protocolo TLSv1.1 Após a revisão das cifras, caso haja tentativa de conexão com o web service do eSocial e o resultado seja uma mensagem como a abaixo: É um forte indício de que a conexão foi feita utilizando uma versão do TLS ou cifra não suportada. Caso isso ocorra é importante buscar uma versão do sistema operacional utilizado que suporte a conexão. Lembrando que as soluções ACBr são compatíveis com o protocolo TLSv1.2, com a configuração podendo ser definida no componente nativo na propriedade: ACBreSocial.SSL.SSLType := LT_TLSv1_2; E através de parametrização no Monitor e na Lib. Leia a notícia original na íntegra AQUI.