Painel de líderes

Bom dia! Sim, você vai utilizar o ; para separar, mas veja no comando são parâmetros diferentes, você tem um parâmetro para o destinatário e um parâmetro para cópia oculta. Então ficaria. EnviarEmail('[email protected];[email protected]", "Assunto", "Mensagem", "[email protected];[email protected]") Neste exemplo, o fulano1 e o fulano2 são destinatários já o fulano3 e 4 são cópia oculta. Não existe. Essa visualização é feita pelo client que recebeu o e-mail. Acabei de realizar um teste utilizando o exemplo de boleto, preenchi apena o endereço de e-mail do destinatário, mas veja como ficou em minha caixa de entrada. O campo eMensagem recebe um TStrings como parâmetro. Veja código retirado do programa exemplo do ACBrBoleto: var SL: TStringList; //i: Integer; begin AplicarConfiguracoesComponenteEmail; SL := TStringList.Create; try SL.Add('Olá,'); SL.Add('Atenção, Boleto está em Anexo'); FACBrBoleto.EnviarEmail(edtEmail.Text ,'Teste de Envio de Email', SL, True); //Método para envio e-mail de forma individual para cada título {for i := 0 to FACBrBoleto.ListadeBoletos.Count -1 do begin if (FACBrBoleto.ListadeBoletos[i].Sacado.Email <> '') then FACBrBoleto.ListadeBoletos[i].EnviarEmail(FACBrBoleto.ListadeBoletos[i].Sacado.Email ,'Teste de Envio de Email', SL, True); end;} finally SL.Free; end; Você precisa ter o arquivo de jpg salvo em disco e passar o caminho completo dele no parâmetro do comando que recebe os anexos. var SL, Anexos: TStringList; //i: Integer; begin AplicarConfiguracoesComponenteEmail; SL := TStringList.Create; Anexos := TStringList.Create; try SL.Add('Olá,'); SL.Add('Atenção, Boleto está em Anexo'); Anexos.Add('C:\\Users\Fulano\MinhasImagens\MinhaAssinatura.jpg'); FACBrBoleto.EnviarEmail(edtEmail.Text ,'Teste de Envio de Email', SL, True, nil, Anexos); finally SL.Free; Anexos.Free end; end; Os fontes do componente são sem sombra de dúvidas o melhor material para estudos, você pode encontrar o programa exemplo para componente nativo disponível em ..\trunk2\Exemplos\ACBrBoleto

Bom dia @marcoprodata, Hoje a comunicação nas Libs é feita toda com arquivos no formato INI, em algumas linguagens temos as classes de alto nivel para ajudar, mas não temos a integração com o formato JSON. Porém a ideia de usar o formato é interessante, então abrimos uma TK-6875 para discutir com os consultores a viabilidade. Obrigado pela sugestão!

Olá Pessoal, O provedor PublicSoft esta migrando o seu sistema de NFS-e para uma API Rest e essa mudança vai afetar todas as cidades atendidas por esse provedor. O componente ACBrNFSeX da forma que esta hoje não atende essa mudança. Com ninguém da Equipe ACBr possui certificado digital de um prestador de serviço cuja cidade contratou o provedor PublicSoft fica mais complicado a realização de testes. Não estou pedindo para ninguém enviar o certificado digital, mas sim saber quem poderia contribuir com os testes. Os desenvolvedores que se habilitarem a realizar os testes, por favor basta responder essa postagem. Nos próximos dias vou estar disponibilizando a unit Provider do provedor com algumas alterações e como proceder com os testes. Desde já muito obrigado pela colaboração.

Olá Pessoal, Muitos de vocês estão ansiosos e apreensivos com essa mudança que vai ocorrer. Os componentes do ACBr vão ser afetados com essa reforma? Sim, mas fiquem tranquilos que já estamos trabalhando nas modificações. Como que fica a minha aplicação, também vai ser afetada? Sim, e te aconselho conversar com os contadores dos seus clientes para saber o que vai ser necessário calcular e como calcular. Como esta os trabalhos e quais são os componentes que vão ser afetados? Dividimos o trabalho em 5 etapas e os componentes afetados são: ACBrBPe (Bilhete de Passagem Eletrônico/Bilhete de Passagem Eletrônico Metropolitano); ACBrCTe (Conhecimento de Transporte Eletrônico/Conhecimento de Transporte Simplificado Eletrônico/Conhecimento de Transporte Outros Serviços); ACBrNF3e (Nota Fiscal de Energia Elétrica Eletrônica); ACBrNFCom (Nota Fiscal de Comunicação Eletrônica); ACBrNFe (Nota Fiscal Eletrônica/Nota Fiscal ao Consumidor Eletrônica) e ACBrNFSeX (Nota Fiscal de Serviço Eletrônica). Etapas definidas para a implementação da Reforma Tributária nos componentes: 1. Alteração nas classes para criar os grupos e seus respectivos campos; 2. Alteração na unit responsável pela escrita do XML; 3. Alteração na unit responsável pela leitura do XML; 4. Alteração nas funções de escrita e leitura do arquivo INI (utilizado pelo ACBrMonitor e ACBLib). 5. Alteração nos programas exemplos Delphi/Lazarus visando mostrar como alimentar o componente referente aos novos campos dos novos grupos. Observações: A primeira etapa já foi concluída para todos os componentes exceto ACBrNFe. No caso do ACBrNFSeX a implementação contempla somente a NFS-e Padrão Nacional (provedor PadraoNacional), não sabemos como vai ficar o layout do XML do RPS dos provedores que tem layout próprio ou utilizam a versão 1 ou 2 do layout da ABRASF. No que se refere a NF-e/NFC-e além das alterações necessárias para contemplar a reforma tributária, vai ser necessário também implementar 12 novos eventos que vamos discriminar em postagem futura. Prazos: Segundo a NT/2024/001 versão 1.10 - Reforma Tributária - IBS e CBS (BPe, CTe, NF3e e NFCom) e a NT/2024/002 versão 1.10 - Reforma Tributária - IBS e CBS (NFe e NFCe) traz as seguintes datas: Ambiente de Homologação: 01/09/2025 Ambiente de Produção: 31/10/2025 Já a Nota Técnica 001 - SE-CGNFSe - Novo Layout - RTC (NFSe) temos a data de janeiro/2026 como sendo o inicio do novo layout, infelizmente não informa se é ambiente de homologação ou produção. Assim que finalizarmos a primeira etapa no componente ACBrNFe, avisaremos neste tópico o inicio da segunda etapa.

Boa tarde! Obrigado! Segue arquivos com as seguintes alterações: * remover propriedade Id em EventosEspecias e em Debitos, sera utilizado o indice das listas; * adicionar ordenacao por grupo de tributos na lista de debitos; * remover formatacao do cnpj para gerar nome do arquivo; * alterar ordem de inclusao dos debitos para validar ordenacao da lista (exemplo 3); ACBrMIT.zip

Boa tarde, como o objetivivo do tópico era atualização do município e foi concluído vamos encerrar este tópico. @MarceloDevpor favor abra um novo tópico com na nova dúvida. Obrigado.

Gestão de credenciais Em alinhamento com as melhores práticas de segurança, o Banco do Brasil implementará, em 26/04/25, uma mudança na gestão das credenciais das aplicações do Portal Developers BB, com o objetivo de garantir um serviço ainda mais seguro e confiável. As credenciais ficarão acessíveis apenas no momento da sua geração, tanto no ambiente de homologação quanto no de produção. Se você não salvou suas credenciais, será necessário gerar novas. Assim, a credencial anterior será desativada. Para isso, é indispensável possuir, no mínimo, o perfil de Líder Técnico no Time da Aplicação. Essa atualização reforça a segurança em situações de acessos não autorizados à área restrita (que exige autenticação) do Portal Developers, preservando a integridade das credenciais das aplicações em cenários de possíveis acessos indevidos. Recomendamos aos usuários do Portal que guardem suas credenciais em um local seguro para garantir o acesso às credenciais de sua aplicação. Se você já é usuário do Portal e mantém suas credenciais em segurança, essa solução não causará nenhum impacto. Como gerar suas credenciais Ao acessar a área restrita do Portal Developers BB, clique no botão “CRIAR NOVA APLICAÇÃO”, em seguida clique no card de credenciais para gerar a sua credencial. Clicando em “QUERO VER DE NOVO”, você tem a possibilidade de visualizar, mais uma vez, a informação da sua APPKEY e das credenciais que foram geradas. Clicando em “JÁ ARMAZENEI”, você é redirecionado para a tela de gestão da aplicação. Após geradas as credenciais, por medida de segurança, não ficarão mais disponíveis para consulta, sendo possível apenas gerar novas credenciais. Seria isso ai acima, pelo que entendi, não ficará mais disponível a consulta no portal, mas como a gente já salva essas informações no banco, acredito que não teremos problemas.... Obrigado juliomar!

Ultima dúvida, já existe algum projeto de implementar tbm a recepção de JSON?

Bom dia não recebemos nada sobre isso. mas ao que parece é algo do tipo se quero fazer testes .terei que acessar o portal deles e pegar as credenciais na hora pois não podem mais ser fixas para testes

segue esse tópico que vou estar atualizando, estou ajustando os retornos

Achei melhor modificar dentro do componente para não precisar enviar nenhum título Arquivo -> ACBrBoletoW_Sicoob_V3.pas Classe -> TBoletoW_Sicoob_V3 Função -> DefinirURL; if Boleto.Configuracoes.WebService.Operacao in [tpConsulta] then begin LContrato := OnlyNumber(Boleto.Cedente.CodigoCedente); //atribuir abaixo na variável LContrato o codigo cedente end;

Parabéns pelo código da contribuição @Patrick Alves, ficou muito fácil de utilizar. Vou utilizar este componente. Sera que vão incorporar no instalador do ACBR @Juliomar Marchetti ? Verifiquei apenas um problema com relação ao nome do arquivo., estava pegando os 8 caracteres a direita. Outra questão é que se o numero vier com formato (pontos) fica com problema no nome. Alterei a função para utilizar o LeftStrNativeString ao invés do RightStrNativeString. function TACBrMIT.GetArquivo: string; const NomeArquivo = '%s-MIT-%d%s.json'; begin Result := Format(NomeArquivo,[LeftStrNativeString(FCnpjContribuinte, 8), PeriodoApuracao.Ano, FormatFloat('00', PeriodoApuracao.Mes)]); end;

Olá pessoal! É com grande alegria que informamos que foi disponibilizada a impressão de eventos para NFC-e com o FPDF A nova impressão possui leiaute semelhante ao print(informações de identificação foram censuradas): Vale lembrar para aqueles que usam componente nativo, que para o correto funcionamento da mesma, é necessário que o XML da NFC-e correspondente seja carregado na memória previamente. Quem utiliza ACBrMonitor ou ACBrLib já é requisitado como parâmetro do comando ImprimirEventoPDF que seja passado o XML da NFC-e. Versões da ACBrLib compiladas depois das 11h50 do dia 02/04/2025 deverão englobar o ajuste. Um agradecimento ao @Arimateia Jr pelo auxílio ao fornecer a base para a implementação.

Olá Pessoal, Boas novas, o componente ACBrNFe já esta pronto para gerar o QR-Code na versão 3.00 que é utilizado na NFC-e. Essa nova versão esta documentada na Nota Técnica 2025/001 que além da versão 3.00 do QR-Code também temos a resposta síncrona para lote com somente 1 (uma) nota. Com relação ao modo de envio síncrono já faz um bom tempo que o componente dispõe dessa funcionalidade, na verdade desde julho/2013. Lembrando que o envio em modo síncrono esta condicionado a somente uma nota por lote, ou seja, envio unitário. Vale também ressaltar que hoje podemos realizar um envio unitário em modo assíncrono, mas em breve não vai mais ser possível, somente no modo síncrono. Tanto a versão 3.00 do QR-Code quanto a obrigatoriedade do modo síncrono para o envio unitário de NF-e segue o seguinte cronograma: Ambiente de homologação 02/06/2025 e produção 01/09/2025. Mantenham os fontes do ACBr atualizados e reinstalados. Fiquem atentos aos Papos Pro que são realizados todas as terças e quintas no Discord.

Olá Pessoal, Boas novas, as etapas 2 e 3 já foram concluídas para todos os componentes e já se encontram no SVN. Partiu etapa 4 que visa adequar os métodos de leitura e escrita do arquivo INI, como dito anteriormente usados pelo ACBrMonitor e ACBrLib. Quando esta etapa for finalizada vou trabalhar nos programas exemplos. Não fiquem apavorados em querer alterar as suas aplicações, pois vocês não vão conseguir realizarem testes em ambiente de homologação da SEFAZ uma vez que este ambiente só vai ser liberado em 01/09/2025 isso se não for prorrogado. Todas as implementações estão sendo realizadas com base nas Notas Técnicas: 2024/001 e 2024/002 ambas versão 1.10 pode ser que surge uma nova versão e com isso tenhamos que alterar algumas coisas na implementação. Por fim e não menos importante, mantenham os fontes do ACBr atualizados e instalados.

Olá pessoal! Foi publicada a versão 1.10 desta nota técnica. A nova versão traz alterações em algumas regras de validação e a adição de uma nova rejeição para substituir uma denegação correspondente. Alterações Regra de Validação 1C17-50 Altera a regra de validação transformando ela de uma denegação para uma rejeição. Lembrando que quando uma nota fiscal é rejeitada, você pode realizar a correção do erro que ocasionou a rejeição e tentar emitir novamente a mesma nota, enquanto que quando for denegada, a nota fica armazenada na base de dados da sefaz e por isso o mesmo número não pode ser utilizado novamente. Regra de Validação I08-150 Adiciona na regra de validação o CFOP 5.910: Remessa bonificação, doação ou brinde permitindo o uso do mesmo na NFC-e. Datas Implantação Teste: Até 01/07/2024 Implantação Produção: 02/09/2024 Modificações no ACBr? Como a nova versão traz alterações em regras de validação da Sefaz, alterações nos fontes do ACBr não se fazem necessárias. Leia a versão 1.10 desta Nota Técnica na íntegra AQUI.