Painel de líderes

Olá pessoal, Ficamos felizes em anunciar que foram disponibilizados os programas de exemplo em PHP, Singlethread e Multithread utilizando a ACBrLibNFSe na Rev-35661. ..\ACBr\Projetos\ACBrLib\Demos\PHP\NFSe\ACBrNFSeDemoST.php ..\ACBr\Projetos\ACBrLib\Demos\PHP\NFSe\ACBrNFSeDemoMT.php Lembrando que o programa de exemplo utiliza a ACBrComum.php, contendo métodos em comum entre os modos (ST e MT) e para todas as libs. ..\ACBr\Projetos\ACBrLib\Demos\PHP\ACBrComum\ACBrComum.php Esperamos que esse novo programa de exemplo facilite a integração da comunidade PHP com as nossas bibliotecas. Até mais!!!

@Daniel Simoes Bom dia. postando novamente Demo_NaoFiscal.rar Demo_TEFAPI.rar ACBrTEFDElgin.pas

Olá, estou recebendo um erro ao tentar efetuar a consulta detalhada de um boleto via API do Santander, nos logs é registrado que os valores enviados para consulta não estão de acordo com o formato esperado Entrei em contato com o suporte deles e me informaram que em ambiente de sandbox o parâmetro bankNumber (nossoNumero) deve ser enviado com apenas 8 dígitos para que funcione. Acionando o endpoint com a lib, o nossoNumero é completado automaticamente para que fique com 12 dígitos, que é a quantidade pedida pelo Santander em ambiente de produção. Isso impede que esse endpoint de consulta em ambiente sandbox seja utilizado e testado antes de subir pra produção. logs.txt

Olá pessoal! No dia 17/10/2024 foi publicado o Correio Eletrônico Circular SEF/DIAT/Nº 18 / 2024 divulgando cronograma para a ativação das regras de validação relacionadas as informações do cBenef e do grupo de informações do crédito presumido. Regra de Validação Descrição da Regra Data de ativação no Ambiente de Teste Data de ativação no Ambiente de Produção N12-85 (NF-e) Se informado CST e não informado código de benefício fiscal: verificar se CST exige código de benefício fiscal (tag: cBenef), conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina. 04/11/2024 03/02/2025 N12-85 (NFC-e) Se informado CST e não informado código de benefício fiscal: verificar se CST exige código de benefício fiscal (tag: cBenef), conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina. 04/11/2024 01/04/2025 N12-94 (NF-e e NFC-e) Se informado CST e informado código de benefício fiscal: verificar se código de benefício fiscal corresponde ao CST informado, conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina. 02/12/2024 28/04/2025 N12-98 (NF-e e NFC-e) Se informado código de benefício fiscal: verificar se o código de benefício fiscal existe e está vigente, conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina. 02/12/2024 28/04/2025 N14a-20 (NF-e) Se CST de ICMS = 51 (diferimento) e informado tag:ICMS51/cBenefRBC (id:N14a): verificar se código de benefício fiscal de redução de BC (cBenefRBC) existe, está vigente e corresponde a um código de benefício de redução de base de cálculo (coluna CST 20 = SIM), conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina(NT2019.001). 02/12/2024 28/04/2025 I05h-10 (NF-e e NFC-e) Se informado código de crédito presumido (tag: cCredPresumido): verificar se código de crédito presumido existe, está vigente e corresponde a um código de crédito presumido, conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina(NT2019.001). 02/12/2024 28/04/2024 N12-86 (NF-e e NFC-e) Se informado CST e informado código de benefício fiscal: verificar se CST não possui código de benefício fiscal (tag:cBenef), conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina 02/12/2024 01/09/2025 N14a-10 (NF-e) Se CST de ICMS = 51 (diferimento) e informado tag:ICMS51/pRedBC (id:N14) maior que zero, é obrigatório informar cBenefRBC (id:N14a) (NT 2019.001). 02/12/2024 01/09/2025 Vale ressaltar que as regras estão sendo ativadas conforme as datas mencionadas acima para que as empresas tenham tempo para adequação e testes no ambiente de homologação antes de partir para o ambiente de produção. O referido correio eletrônico pode ser conferido na íntegra AQUI.

Olá pessoal! Em sua atualização mais recente na Nota Técnica 2023/004 a regra de validação para este rejeição ficou desta forma: Conforme descrito, se você está recebendo está rejeição, significa que seu arquivo XML possui o tPag com o valor 03, 04 ou 17, mas não possui o grupo de cartões (grupo card no XML). Quais são os campos que compõe este grupo você se pergunta. Para isso, podemos conferir na mesma nota técnica, vejam: Como eu faço para preencher estes campos nas soluções ACBr? Se você está utilizando o componente nativo para Delphi ou Lazarus as propriedades podem ser preenchidas da seguinte forma: var NotaF: NotaFiscal; InfoPgto: TpagCollectionItem; begin NotaF := ACBrNFe.NotasFiscais.Add; //Preenche as demais informações da NFe... InfoPgto := NotaF.NFe.pag.New; InfoPgto.tPag := InfoPgto.tpIntegra := InfoPgto.CNPJ := InfoPgto.tBand := InfoPgto.cAut := InfoPgto.CNPJReceb := InfoPgto.idTermPag := end; Agora caso esteja utilizando o ACBrMonitorPLUS ou a ACBrLibNFe, para adicionar as informações, o arquivo INI deve ser preenchido assim: [pag001] tPag= tpIntegra= CNPJ= tBand= cAut= CNPJReceb= idTermPag= Vale mencionar... Embora de acordo com a NT, do grupo card, somente os campos tpIntegra e cAut sejam obrigatórios, não há problema nenhum em preencher as demais informações. Ter elas registradas no arquivo XML, pode auxiliar em um controle de informações e torna a operação mais transparente para o destinatário. Também temos indícios de que ao menos a Sefaz do Paraná, espera receber mais campos além do tpIntegra e do cAut, como pode ser visto no tópico abaixo:

Boa tarde Sandro, Muito obrigado pela colaboração, já foi criado a TK-6123 para realizar a alteração.

Boa tarde! Pelo que pude apurar, o tamanho é de fato fixo em 12 para o Santader. Criada a #TK-6122 para análise das informações e parecer por parte da equipe de consultores.

Boa tarde Felipe! Na distribuição de CTes, o XML vem sempre completo (procCTe). Sim, a manifestação disponível para o CTe seria a "recusa" (Prestação de serviço em desacordo). Acredito que não existe distribuição CTe para os seguintes schemas: "resCTe, resEventoCTe...." E diferente da distribuição NFe, vc consegue voltar o NSU para baixar documentos retroativos. Lembrando que será disponibilizado todos CTes q a empresa estiver envolvida, mesmo não sendo o Tomador do serviço... é recomendável criar uma configuração para baixar os CTes somente quando o cliente for o Tomador (gera custos/impostos), a critério de cada cliente/caso.

Olá Pessoal, Com esse refactoring mudou a forma de ler as informações de retorno ao averbar um documento. Para pegar o retorno do envio, agora fazemos da seguinte forma: ACBrANe1.WebService.Enviar.**** onde **** é os campos: Numero, Serie, Filial, etc Veja este fragmento de código do programa exemplo: memoLog.Lines.Add('Parâmetros de Retorno'); memoLog.Lines.Add('Numero : ' + Numero); memoLog.Lines.Add('Serie : ' + Serie); memoLog.Lines.Add('Filial : ' + Filial); memoLog.Lines.Add('CNPJ Cliente : ' + CNPJCliente); memoLog.Lines.Add('Tipo Documento: ' + tpDoc); memoLog.Lines.Add('Data/Hora : ' + DateTimeToStr(DataHora)); memoLog.Lines.Add('Numero do Prot: ' + Protocolo); memoLog.Lines.Add('CTe : ' + CTe); memoLog.Lines.Add('Sucesso : ' + BoolToStr(Sucesso, True)); Temos também os dados do seguro que é lido da seguinte forma: ACBrANe1.WebService.Enviar.DadosSeguro.**** if aDadosSeguro.Count > 0 then begin memoLog.Lines.Add(' '); memoLog.Lines.Add('Dados do Seguro:'); for i := 0 to aDadosSeguro.Count -1 do begin memoLog.Lines.Add('Numero Averbação: ' + aDadosSeguro[i].NumeroAverbacao); memoLog.Lines.Add('CNPJ Seguradora : ' + aDadosSeguro[i].CNPJSeguradora); memoLog.Lines.Add('Nome Seguradora : ' + aDadosSeguro[i].NomeSeguradora); memoLog.Lines.Add('Numero Apolice : ' + aDadosSeguro[i].NumApolice); memoLog.Lines.Add('Tipo Movimento : ' + aDadosSeguro[i].TpMov); memoLog.Lines.Add('Tipo de DDR : ' + aDadosSeguro[i].TpDDR); memoLog.Lines.Add('Valor Averbado : ' + FloatToStr(aDadosSeguro[i].ValorAverbado)); memoLog.Lines.Add('Ramo Averbado : ' + aDadosSeguro[i].RamoAverbado); memoLog.Lines.Add('---------'); end; end; Recomento fortemente que estudem o programa exemplo. No que se refere ao retorno vejam a procedure ChecarResposta.

Fecho, acho que talvez ja sei o que possa ser, vou dar uma revisada!

Chequei e estava tudo certo. Nada customizado. Uso valores fixos em todos os clientes. Só que agora não tenho como testar pois a máquina está em manutenção. Já estava TSL 1.2 também. Mas reporto aqui se deu certo quando a máquina voltar. Obrigado.

Bom dia @antonio.carlos. Eles não possuem uma documentação em pdf. Mas acessei aqui o "https://developercielo.github.io/manual/apipix#segurança" com meu usu e senha e te passo abaixo a parte que fala de segurança. Se realizar um cadastro no site "https://desenvolvedores.cielo.com.br/api-portal/" poderá checar a documentação com mais profundidade. Pelo postman eu utilizei os .cer e .key obtendo sucesso. Segurança Devem ser observadas para desenvolver e implementar a API seguindo boas práticas de segurança, atendendo aos requisitos obrigatórios abaixo. Requisitos de segurança obrigatórios: A conexão à API deve ser criptografada utilizando o protocolo TLS versão 1.2 ou superior, permitindo apenas cipher suites que atendam ao requisito de forward secrecy. O PSP deve implementar o framework OAuth 2.0 (RFC 6749) com TLS mútuo (mTLS – RFC 8705) para autenticação na API, conforme especificações abaixo: a. Os certificados digitais dos clientes da API poderão ser emitidos pelo próprio PSP ou por ACs externas, conforme definido por cada PSP. Não deverão ser aceitos certificados auto-assinados pelo cliente. b. Cada PSP deve possuir seu próprio Authorization Server e Resource Server associado à API Pix, e ambos devem implementar TLS mútuo. c. O Authorization Server do PSP deve implementar a técnica de vinculação do certificado do cliente aos access tokens emitidos (“Client Certificate-Bound Access Tokens”), conforme seção 3 da RFC 8705. d. O Resource Server do PSP deve confirmar que o thumbprint do certificado associado ao access token apresentado pelo cliente é o mesmo do utilizado na autenticação TLS (proof-of-possession). e. O fluxo OAuth a ser utilizado é o “Client Credentials Flow”. f. Os escopos OAuth serão definidos na especificação Open API 3.0 da API Pix e permitirão associar diferentes perfis de autorização ao software cliente. O processo de cadastro/onboarding do cliente para acesso à API deve ser realizado em ambiente logado no PSP, e deve incluir um canal seguro para envio das credenciais ao usuário, de forma a permitir a rastreabilidade das ações executadas. A API deve suportar múltiplos níveis de autorização ou papéis, segregando as funcionalidades de acordo com perfis (escopos OAuth) dos usuários clientes. O PSP deve implementar tecnologia que permita garantir a alta disponibilidade da API. A API deve garantir a confidencialidade e a integridade das informações dos usuários e de suas transações, tanto em trânsito como em repouso. O PSP deve manter logs de auditoria dos acessos à API pelo período mínimo de 1 ano. A credencial de acesso utilizada na autenticação (Client_ID) deve ser vinculada ao CNPJ ou CPF do usuário recebedor e deve permitir acesso a recursos apenas de contas transacionais de titularidade do CNPJ ou CPF associado. Para a funcionalidade de webhooks, as notificações oriundas do PSP recebedor ao usuário recebedor trafegarão utilizando um canal mTLS. a. Recomenda-se que os certificados utilizados para autenticação mútua no canal TLS do webhook sejam os mesmos da API Pix. De todo modo, não há objeção quanto à utilização de outros certificados, mediante acordo entre o PSP e o usuário recebedor. O BC entende que os PSPs poderão adotar as tecnologias e soluções de segurança para a API que mais acharem apropriados, desde que sejam atendidos os requisitos obrigatórios de segurança e, sempre que possível, as recomendações descritas acima, com atenção também aos elementos listados nos tópicos a seguir.

No svn alteração.

Boa noite @antonio.carlos. Vou ver se arrumo esta documentação e lhe passo. De qq forma e antecipadamente, afirmo que existe sim o uso do certificado. Já testei diretamente no Banco via postman. Homologação não precisa. Basta apenas clientId e clientSecret. Em produção, também funcionou, mas além destas credenciais acima descritas, precisei utilizar os certificados que o proprietário da conta me forneceu. Att

Aparentemente o problema esta no BB Repeti o processo de envio mais algumas vezes, ate que aceitou Deu certo o envio

Olá, Estou enfrentando um problema no meu sistema de busca automática de NF-es, onde a maioria das pesquisas retorna com o erro "Consumo Indevido (Deve ser utilizado o ultNSU nas solicitacoes subsequentes. Tente apos 1 hora)" Deduzi que existe alguma outra plataforma fazendo pesquisas com o mesmo Certificado, mas não tenho conhecimento de qual plataforma seria. Verificando algumas NF-es, é possível ver que elas já foram manifestadas através de outro sistema pelo meu Certificado. Minha pergunta é: Existe alguma forma de saber qual sistema está fazendo essas manifestações? Algo como a TAG <infRespTec> do XML da NF-e, mas no XML do Evento da Manifestação...

Não. pois ele está usando o certificado. revoga ele e faz um novo e manda o cliente não distribuir o mesmo para todo mundo

Boa tarde @Alisson Orsolin, Já esta no SVN.

Olá pessoal! Recentemente temos recebido relatos de membros da comunidade com problemas para realizar o envio de e-mail quando o provedor é o da Microsoft(@hotmail, @outlook e afins). Um membro de nossa comunidade compartilhou a seguinte mensagem que recebeu da Microsoft: Esses "métodos modernos de autenticação" se referem ao Oauth 2.0 (Veja mais em Os Métodos de Autenticação Modernos agora necessários para continuar a sincronizar o E-mail do Outlook em aplicações de e-mail não Microsoft). O que é o Oauth 2.0? O Oauth 2.0 é um protocolo de autorização que funciona através de tokens de acesso e foi projetado primariamente com o objetivo de conceder acesso a determinados recursos de aplicações de usuários. Neste caso em questão, seria o acesso ao e-mail. Como fica o ACBrMail? Atualmente o ACBrMail não tem suporte a Oauth 2.0, foi criada em nosso backlog a tarefa #TK-6042 para análise e implementação da mesma. É o fim do ACBrMail então? O que eu faço agora? Não é o fim do ACBrMail. Conforme mencionado anteriormente, será analisada implementação do Oauth 2.0 no mesmo. Enquanto isso não ocorre, para provedores como o g-mail, por exemplo, ainda é possível fazer a comunicação com a Senha de App. Para a Microsoft, nos testes realizados pela equipe de consultores, Microsoft365 ainda demonstra estar funcionando, o HotMail e o Outlook que pararam de funcionar. Outra opção também seria o uso de um provedor de e-mail próprio.

Eu sou autista e tenho TDAH, é dificil concentrar e voltar a concentração quando perco ela. O ruido marrom ajuda a me concentrar mais do que ouvir música por exemplo. Eu até já fiquei um tempo ouvindo podcasts enquanto programava, inclusive ouvir vários do ACBr, mas o ruido marrom ajuda mais.

Olá, pessoal. Temos o prazer de anunciar que o novo pacote ACBrBaas já está disponível no SVN! Este pacote foi criado para facilitar a integração de sistemas com serviços bancários e APIs de pagamento, atendendo à crescente demanda por soluções de automação financeira. ACBrExtratoAPI: Primeira Solução Disponível O primeiro componente disponível neste pacote é o ACBrExtratoAPI. Este componente permite a consulta de transações do extrato de uma conta corrente, ideal para quem precisa automatizar o acompanhamento e controle financeiro diretamente em seu software. Atualmente, o ACBrExtratoAPI oferece suporte para dois bancos: Banco do Brasil Banco Inter A proposta é expandir o suporte para outros bancos, conforme a demanda dos usuários. Então, caso seu banco de interesse ainda não esteja incluído, fique à vontade para sugerir a inclusão! Futuros Componentes no Pacote ACBrBaas Além do ACBrExtratoAPI, estamos trabalhando na inclusão de novos componentes ao pacote ACBrBaas, que irão ampliar ainda mais suas funcionalidades, entre eles: ACBrPagamentosAPI: Voltado para a integração com APIs de pagamento, facilitando transações financeiras diretamente pelo software. ACBrBBPay: Um componente específico para a plataforma BBPay, do Banco do Brasil, que permitirá realizar transações de forma simplificada. Estamos atentos às necessidades dos usuários e planejamos adicionar mais APIs bancárias e de pagamento, tornando o ACBrBaas uma ferramenta essencial para desenvolvedores que buscam eficiência e automação no setor financeiro. Disponível em: https://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrBaaS/ Fiquem atentos às próximas atualizações!

Cara, Sofri muito com esse erro até achar o problema. Segue a solução: Vai na Pasta onde está instalado o Acbr, e acha a pasta do Fortes Report. Dentro da pasta ache o Arquivo RLPrinters.pas. Dentro do Arquivo acha a procedure TRLPrinterWrapper.Refresh; Dentro da procedure ache a Linha que esta escrito: Printer.PrinterIndex := -1; Altera essa Linha para Printer.PrinterIndex := 1; (Perceba que troquei o -1 por 1) Pronto vai parar de dar esse erro. Se esse post foi util por favor me informe em [email protected] Sem mais, Rinaldo C Gomes Analista de Sistemas