Painel de líderes

Bom dia pessoal! Foi publicado no dia 11/12/2023 a Nota Técnica 2023/004 que implementa o evento de conciliação financeira e adiciona e altera alguns campos da NF-e. Resumo. Esta nota técnica tem o objetivo de prover aos atores envolvidos nos processos da NF-e/NFC-e a possibilidade de anotar no documento fiscal eletrônico as transações financeiras relacionadas, facilitando a vinculação entre documentos fiscais e recursos financeiros recebidos. Busca-se encontrar uma solução para pagamentos que ocorrem distantes da data do fato gerador e da emissão do documento fiscal. Portanto, para que seja possível às empresas informarem que o recebimento de recurso está relacionado a determinado documento fiscal, está sendo criado o Evento de Conciliação Financeira – ECONF. Os Ajustes SINIEF nº 3/2023 e 10/2023 prevêem este evento. A utilização do Evento de Conciliação Financeira – ECONF é facultativa e tem o objetivo de auxiliar as empresas que buscam demonstrar a existência de conformidade fiscal entre as informações financeiras e de meios de pagamentos e os documentos fiscais emitidos. Nessa NT, foram criados novos campos no grupo YA. Informações de Pagamento e nos Grupos Tributação do ICMS que possuem ICMS desonerado. Também foram alterados campos dos grupos I01. Produtos e Serviços / Declaração de Importação e Z. Informações Adicionais da NF-e Inclusão de novos campos. Grupo YA. Informações de Pagamento. Adiciona os seguintes campos: CNPJPag: CNPJ do estabelecimento onde o pagamento foi processado/transacionado/recebido quando a emissão da NF-e/NFC-e tiver ocorrido em estabelecimento distinto. UFPag: UF do CNPJ do estabelecimento onde o pagamento foi processado/transacionado/recebido. CNPJReceb: CNPJ do estabelecimento beneficiário do pagamento. IdTermPag: identificar o termnial em que foi realizado o pagamento. Os campos são opcionais, mas caso informe o CNPJPag a UFPag deve ser informada e vice-versa. Grupo de Tributação de ICMS(Somente quando regime não for Simples) Adiciona o campo: indDeduzDeson: indicador se o valor do ICMS desonerado deduz do valor do item ou não. Alteração de campos. Grupo DI (relativo a Declaração de Importação). O campo CNPJ passa a ser CNPJ/CPF permitindo que pessoa física seja adquirente ou encomendante. Adiciona novas opções para o campo tpViaTransp. Aumenta o número de ocorrências possíveis do grupo adi (Adições e/ou itens) de 100 para 999. Aumenta o tamanho de nDI para permitir informar o DUImp. Torna o nAdicao opcional, pois caso tenha sido informado o DUImp em nDI, não deverá ser informado. Altera o tipo de nDraw para caracter com tamanho 20. Grupo de Informações Adicionais da NF-e. Adiciona novas opções nos campos indProc e tpAto do grupo relativo ao Processo Referenciado (procRef). Regras de Validação. A nota técnica trás alterações nas regras de validação I23d-10 e I23d-20 para que valide além do CNPJ o também agora possível CPF. Foram criadas as regras de validação YA03b-10, YA04-20, YA09-20 e YA10-10 para validar os novos campos incluídos no grupo de informações de pagamento. Remove as regras de validação X03-10 e X03-20 deixando então de validar os dados do transportador na NFC-e. Evento "Conciliação Financeira - ECONF". Além dos campos comuns a todos os eventos temos também no grupo detEvento no layout de entrada: versão: mesmo valor da tag "verEvento". descEvento: "ECONF". CNPJ: CNPJ do beneficiário do pagamento. UF: código da UF. vPag: Valor do Pagamento. tPag: Meio de pagamento (usar Tabela de Códigos dos Meios de pagamentos publicada no Portal da NFe). dPag: Data da captura do Pagamento no formato AAAA-MM-DD. Para pagamentos agendados, usar a data de efetivação. CNPJIF: CNPJ da instituição financeira de pagamento, adquirente ou subadquirente. cAut: Identificação do numero de autorização da transação da operação. No que diz respeito ao retorno, o layout é bem semelhante ao de outros eventos, com as informações dhRegEvento e nProt sendo as que valem destaque. Evento "Cancelamento Conciliação Financeira - ECONF". Semelhante aos demais eventos do gênero, na mensagem de envio deve ser informado o tipo do evento correspondente, chave da NF-e ao qual o evento será vinculado, informações do autor do evento e o número do protocolo do evento que deseja ser cancelado. O retorno vai devolver data de registro do evento e o número do protocolo do mesmo. Datas. Implantação Teste: 05/02/2024 Implantação Produção: 01/04/2024 LEIA A NOTA TÉCNICA NA INTEGRA AQUI. E como fica o ACBr? Como é possível observar, a NT trás um novo evento e a adição de alguns campos, por isso, alterações nos fontes do ACBr serão necessárias. Já foi adicionado em nosso backlog tarefa para realizar tais alterações e as mesmas logo estarão disponíveis para que toda comunidade possa usufruir.

Olá Pessoal, Parece meio contraditório, termos nessa nova versão da NT a seguinte informação: Inclusão da Obrigatoriedade do cBenef para Santa Catarina e depois na tabela das UF que implementaram algumas regras validação e outras não. Já Santa Catarina consta que não vai implementar as regras. Não é muito estranho? Estranho é mas vamos entender isso. A tag cBenef conforme consta no Manual da NFe que contem o layout diz que a tag é opcional, portanto essa informação poderá ou não constar no XML. O Estado de Santa Cataria através de sua legislação própria, vai rejeitar notas que não contenha a tag, ou seja, para Santa Catarina a tag passa a ser obrigatória, sendo assim devemos informar o cBenef do Item. Por outro lado essa informação não vai ser validada. Isso não quer dizer que podemos informar um código de beneficio qualquer (aleatório), pois Santa Catarina poderá mudar de ideia e implementar as regras e passar a validar.

so complementando o assunto seguem 2 arquivos, as 2 notas foram "aprovadas" mas num deles tem alguns caracteres com padrao ansi (retornaram com acento no nome do tomador) o outro nao e neste q nao o retorno do acbr veio certinho 20231212151039-lista-nfse-ger-soap.xml 20231212140801-lista-nfse-ger-soap.xml

Boa tarde @Rozelo, O monitor está sendo executado como administrador? O caminho de saída está correto (o caminho existe no computador?) Obrigado

@Diego Foliene Os XML's são recebidos dos fornecedores (emitidos por outros sistemas) e fazemos a importação dos mesmos para dentro do sistema. Temos sim um sistema de manifestação mas podemos fazer essas importações manualmente também através do arquivo xml.

Boa tarde pessoal, tudo bem? Estamos com uma situação aqui onde o componente está trazendo os acentos com caracteres quebrados ao fazer a leitura do XML. A LIB da NF-e está atualizada(a de ontem), e o componente também está atualizado na última rev. A codificação é a padrão (UTF8) Posso enviar o XML via e-mail pra vocês, só me confirmam que eu anexo o link do tópico e o arquivo lá. Apenas complementando o tópico, não sei se tem relação ou não a uma alteração feita a esses tempos atrás, também referente a leitura mas em arquivo de retorno de boleto para o CRESOL, que estava retornando caracteres inválidos nos acentos, percebi que após essa alteração começou a acontecer isso

Gostaria de ver a possibilidade de desenvolvimento do boleto Cresol Via API, seque links e contato da Cresol. Suporte WhatsAPP Cobrança GOVERNAR TI exclusivo para API: +55 (47) 32095670 URLs API integrada Homologação API: https://api-dev.governarti.com.br/ Token: https://auth-dev.governarti.com.br/auth/realms/cresol/protocol/openid-connect/token Produção API: https://cresolapi.governarti.com.br/ Token: https://cresolauth.governarti.com.br/auth/realms/cresol/protocol/openid-connect/token Documentação: https://api-dev.governarti.com.br/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config Cobranca Bancaria - Detalhamento Atualizado API.pdf

Olá pessoal! No dia 09/11/2023 foi publicada no Diário Oficial da Secretaria da Fazenda do Rio de Janeiro, dentre outras a resolução Nº578 de Novembro de 2023. Essa resolução além de trazer orientações sobre como o contribuinte deve preencher o SPED, trás também os Art. 16-E e 16-F que orientam na obrigatoriedade do preenchimento dos campos de ICMS Efetivo e Retido e cujo texto transcreve: A resolução entrou em vigor na data de publicação e seus efeitos passarão a valer a partir de 01/01/2024. Como preencher estas tags no ACBr? Se você utiliza o componente ACBrNFe nativo para Delphi e Lazarus, as tags são alimentadas pelas propriedades: ACBrNFe.NotasFiscais[Indice].NFe.Det[OutroIndice].Imposto.ICMS.vBCSTRet := ACBrNFe.NotasFiscais[Indice].NFe.Det[OutroIndice].Imposto.ICMS.vICMSSubstituto := ACBrNFe.NotasFiscais[Indice].NFe.Det[OutroIndice].Imposto.ICMS.vICMSSTRet := ACBrNFe.NotasFiscais[Indice].NFe.Det[OutroIndice].Imposto.ICMS.vBCEfet := ACBrNFe.NotasFiscais[Indice].NFe.Det[OutroIndice].Imposto.ICMS.pICMSEfet := ACBrNFe.NotasFiscais[Indice].NFe.Det[Outroindice].Imposto.ICMS.vICMSEfet := Agora caso utilize o ACBrMonitor ou a Lib que recebem um arquivo INI, os campos são: [ICMSXXX] vBCSTRet= vICMSSubstituto= vICMSSTRet= vBCEfet= pICMSEfet= vICMSEfet=

Com aproximaçao do fim do prazo para a migração para a versão 4.0 vou deixar aqui dois xmls completos para exemplo que pode servir de referência para quem desenvolve Consulta status do servidor <?xml version="1.0" encoding="utf-8"?> <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Body> <cteDadosMsg xmlns="http://www.portalfiscal.inf.br/cte/wsdl/CTeStatusServicoV4"> <consStatServCTe versao="4.00" xmlns="http://www.portalfiscal.inf.br/cte"> <tpAmb>2</tpAmb> <cUF>50</cUF> <xServ>STATUS</xServ> </consStatServCTe> </cteDadosMsg> </soap12:Body> </soap12:Envelope> CTe SincV4 sem soapheader e com dados compactados na base64 <?xml version="1.0" encoding="utf-8"?> <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Body> <cteDadosMsg xmlns="http://www.portalfiscal.inf.br/cte/wsdl/CTeRecepcaoSincV4"> dadoscompactados </cteDadosMsg> </soap12:Body> </soap12:Envelope> CTe.xml descompactado (Esse é um exemplo só para mostrar como proceder a compactação na base64 , esta incompleto) <CTe xmlns="http://www.portalfiscal.inf.br/cte"> <infCte versao="4.00" Id="CTe50231200172038000167570500000000031003067083"> </infCte> <infCTeSupl> </infCTeSupl> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> </Signature> </CTe> Para obter os dados compactados utilizando a linha de comando em Linux cat CTe.xml | gzip | base64 > dadoscompactados Espero ter ajudado alguem

Vamos lá então. Lendo as informações que o @BigWings nos enviou podemos entender que o github fornece a possibilidade de você usar o SVN no github e a partir do ano que vem está encerrando essa funcionalidade. Tendo em vista que repositório do ACBr não está hospedado no github e conforme a @Juliana Tamizou confirmou não temos previsão de mudança, podemos concluir que o ajuste do github não deve nos afetar em nada. Complementando o ACBr tem alguns outros projetos no Github como o FPDF, por exemplo, porém são repositórios diferentes do componentes e já estão usando o GIT e não mais o SVN, portanto também não serão afetados!

Achei o comunicado, do início do ano: https://github.blog/2023-01-20-sunsetting-subversion-support/

Boa tarde, Renato! Depuramos a rotina e descobrimos que o problema está na falta da URL do serviço de ConsultarNFSeRps no arquivo ACBrNFSeXServicos.ini conforme abaixo: ProConsultarNFSeRps=https://www1.fgmaiss.com.br:443/issqn/wservice/wsnfeconsultaxml.php Segue em anexo o arquivo corrigido. Obrigado pelo retorno. Marcelo.ACBrNFSeXServicos.ini

Boa tarde, No topico abaixo tem algumas sugestões de atualização do windows e do .net framework... veja se ajudam..

Boa tarde! Criada a TK-4854 para avaliação! Obrigado pela contribuição!

Nilton, Você usa o DANFSE feito em Fortes ou Fast Report? Se utiliza o Fortes, os seus fontes estão desatualizados. Você tem fontes 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. Se utiliza Fast precisamos saber qual FR3 você utiliza.

enviei um e-mail a eles relatando a situação acima, tão bem nos retornem retorno aqui tb

Boa tarde @m5sistemas, Se você abrir o arquivo *-lista-nfse-ger-soap.xml através do Bloco de notas, vai descobrir que o mesmo esta no formato ANSI e não em UTF-8 apesar de constar o encoding na primeira linha. Precisamos encontrar uma forma de detectar a formatação do arquivo e fazer a conversão para UTF-8 caso necessário.

Funiconou... essa parte. Obrigado Italo. Não vou encerrar o post aqui, pois pode aparecer outras coisas na sequencia. Obrigado mesmo.

@Alexandre de Paula e @Desenvolvimento Farol Soft, vi recentemente em um tópico que estavam falando sobre a API do Cresol, espero ter ajudado com a implementação acima.

@Alexandre de Paula Ajustei aqui através dessa opção, muito obrigado, desculpe o incômodo!

Ronaldo Negreiros Danieli amigo quando se fala em credenciais do banco parece que é mais dificil do quer o código...rsrs...falo isso porque já tem um bom tempo que mexo com integração de boleto via API e PIX...no meu caso pra mim conseguir as credenciais do Bradesco em homologação tive que pressionar mesmo o gerente de meu cliente...tipo assim...ou vc consegui essas credenciais ou meu cliente vai trocar de banco. Como funciona o processo de homologação de boleto do Bradesco (Obter as credenciais em homologação e depois em produção). O gerente tem que abrir um chamado para o setor Implementação Bradesco Manangement Cash (API COBRANÇA REGISTRO ONLINE DE BOLETOS)....apartir desse chamando o setor de implantação de boleto entra em contato com você por e-mail...na abertura do chamando tem que colocar seu e-mail e do cliente para acompanhar o processo....eles pedi a chave publica do certificado do cliente e lhe envia as credenciais em homologação....ai vem a parte do código.

Boa tarde, Tem o link dessa informação para entendermos do que se trata? Obrigado.

Boa Tarde, Vou atualizar e testar. Obrigado

Perfeito, não sabia da existência dessa configuração, vou verificar aqui e dar um retorno, obrigado @Alexandre de Paula!

As Strings dentro de Aspas, não deveriam estar em "Entity Code", pois no cabeçalho do XML, já temos uma declaração informando que os textos estarão em UTF8 <?xml version="1.0" encoding="UTF-8"?>

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

Na configuração da lib é possível definir a largura do campo codigo no danfe: https://acbr.sourceforge.io/ACBrLib/ConfiguracoesdaBiblioteca16.html

Olá pessoal. Foi publicado no dia 12/12/2023 a versão 1.54 da Nota Técnica 2019/001. Vamos a um resumo das novas alterações: Atualização de informações: As regras N12-85, N12-86 e N12-94, que validam o CST e o Código do Benefício Fiscal (cBenef) tiveram a informação atualizada na NT para o Distrito Federal, alterando a data de implantação em produção para 04/09/2023. As regras N12-85, N12-86 e N12-94 que validam o CST e o cBenef e as regras N12-90 e N12-97 que validam as informações de ICMS Desonerado e diferimento tiveram a informação atualizada na NT para o estado de Goiás, alterando a data de implantação em produção para 01/07/2023. Nova regra de validação Adiciona a regra I08-171 que para validar e rejeitar NF-e (modelo 55) com os CFOPs de aquisição ou prestação de serviços 1933, 2933, 5933 e 6933. A nova regra passará a ser validade pela Sefaz seguindo o cronograma: Implantação em homologação: 12/01/2024 Implantação em produção: 01/04/2024 Inclusão da obrigatoriedade do cBenef para SC conforme legislação interna do estado. A tabela com as unidades federativas que implementam as regras de validação N12-85, N12-86, N12-90, N12-94, N112-97 e N12-98 que são opcionais a critério da UF, foi atualizada incluindo Santa Catarina.

Bom dia, Criada a TK-4853 para avaliação. Obrigado pela contribuição.

Na minha aplicação sempre foi um por vez. Se tivesse que enviar vários, faria loop e uma fila de validação para ver se algum retornou com erro. Ester teriam que ser tratados individualmente.

Bom dia! Apenas dando um parecer. A situação ainda está em análise por parte da equipe de consultores. Após alguns testes e análises, tudo indica que o problema seja algo na conversão dos caracteres escapados em Hex-Code que estão sendo usados no XML e que estão sendo convertidos erroneamente. Estamos buscando qual pode ser a causa para isso.

Bom dia pessoal, tudo bem? Estamos enfrentando o mesmo problema, e também já foi tentado com UTF8 e como ANSI e ambos obtém o mesmo retorno, por exemplo, na visualização do xml o nome do produto está como "Leitor Código...", quando tento importa-lo, aparece o ícone de interrogação e alterando o mesmo pelo notepad++ por exemplo o que eu obtenho é "Leitor C&#xF3;digo...". Se for preciso também posso enviar o xml em questão.

Efetuei os testes!!! E para minha surpresa, tb esta ocorrendo o erro, MAS, executa toda a rotina de envio, retornos!!! Estou anexando todos os arquivo xml e o log gerado. 51183724000159.7z

Bom dia @Alexandre Felippeto Henzen, Já esta no SVN.

Bom dia! Conseguimos acessar. O vídeo ficou muito didático, obrigado. A princípio, o seu processo me parece estar correto. Vou levar o vídeo a equipe de consultores para ver se alguém tem alguma sugestão do que possa ser o problema. Também vou comparar o último log que disponibilizou que é o mais completo com o que foi gerado aqui pelo exemplo do C#. Vou lhe pedir nesse meio tempo por favor que: Faça um teste usando a última versão da Lib que temos no fórum com alguma outra cidade cuja emissão esteja funcionando para você. Assim podemos tentar isolar se o problema acontece somente quando configura a cidade de Taquara/RS. No seu arquivo ACBrLib.ini, está sendo indicado o arquivo ACBrNFSeXServicos.ini, acredito que seja devido a teste anterior quando a informação havia sido alterada e ainda não tinha sido inclusa no SVN. Agora, a informação foi enviada ao SVN no componente nativo, então ela deve estar inclusa e vai ser lida internamente na Lib, por isso, não precisa mais apontar o ACBrNFSeXServicos.ini para pegar ela.

No modo síncrono só é possível enviar um CTe por vez.

Boa noite, Revise suas configurações conforme recomendações a seguir, em especial SSLType = Tls1.2

Olá... vou responder suas mensagens em ordem cronológica. Mesmo que não sejam as dúvidas atuais, podem ajudar outras pessoas no futuro ou te dar alguma ideia... Se estiver usando um conversor USB/serial, ou emulador USB/serial, geralmente esse problema é levantado por um driver defeituoso. Você pode ver isso no seguinte tópico: Também já vi ocorrer quando há problema no cabo ou conectores. Esses são os problemas mais comuns. --- Esse erro, como você pode imaginar, é porque algum programa já está acessando a porta (possivelmente o Hercules). Só um aplicativo pode ter acesso a uma porta serial por vez. Quando o segundo aplicativo "pede" o acesso à porta, o sistema operacional (nesse caso o Windows) retorna esse erro informando que o acesso foi negado. ---- Mais uma vez, geralmente isso indica problema no driver, dispositivo conversor USB/Serial como na resposta do Rubinho aqui: --- Isso é o esperado... "Monitorar a Balança" é um sistema de fazer a leitura automaticamente. É útil em alguns casos onde a aplicação quer fazer vários pesos seguidos, mas prefere delegar ao componente essas leituras. Se "Monitorar a Balança" não estiver habilitado o ACBrBal só faz a leitura de peso via o comando "LerPeso". Esse comando envia uma solicitação de peso para a Balança(caso necessário), lê e depois interpreta o retorno. ----- Esses comandos são de "limpeza" da comunicação com a porta serial. Documentação: -> IOCTL_SERIAL_PURGE -> IOCTL_SERIAL_CLR_RTS -> IOCTL_SERIAL_CLR_DTR Apesar de ser um pouco baixo nível, não deveriam causar nenhum problema na comunicação. Na verdade, para comunicação serial usamos a Synapse. A Synapse, (e por conseguinte nosso código), nem vai a tão baixo nível assim já que faz chamadas a API do Windows. Então, se esse tipo de mensagem gerasse algum problema, nós teríamos vários relatos sobre isso com todo tipo de balança que suportamos e não somente com a Urano POP S. Tente utilizar outros dispositivos conversão USB/Serial. Eles costumam ser muito baratos e talvez o problema seja justamente esse. Infelizmente, a maioria desses dispositivos no mercado não são tão confiáveis. Se houvesse detectado outras comunicações ou envio de bytes diferentes. Talvez poderíamos atribuir ao ACBr o problema. Mas não parece ser o caso.

Boa tarde pessoal! Gerei a gravação de como minha rotina é gerada, espero que tenha ficado boa a explicação. Segue o link do vídeo https://www.loom.com/share/21433cc1ca5e4ba180b5f28e041afa52?sid=4973c56b-5b56-43fd-a137-5b92f85a257d Utilizei a plataforma "loom". Qualquer duvida só me avisar.

Boa tarde, Criada a TK-4850 para avaliação. Obrigado pela contribuição

Boa tarde! Isso acontece devido ao tamanho do buffer. Que foi passado. Veja: O tamanho do buffer está menor do que o tamanho da string.

Esse tópico tem um longo debate sobre como aplicar essas regras/validações

Obrigado por reportar @BSSOFT Abraço

Olá pessoal, Foi publicado a versão 1.30 da NT 2021/003 que trata das Validações do GTIN. "A versão 1.30 da NT basicamente amplia o grupo de NCM (grupo de Mercadorias) que verificam a existência do GTIN no CCG-Cadastro Centralizado de GTIN, dando continuidade a ampliação da obrigatoriedade de uso para indústrias donas de marcas." Essa NT se refere ao Grupo III Observação: Como se trata de validação de novos NCM por parte da SEFAZ não se faz necessário nenhuma alteração no componente ou Lib ou Monitor e nem na sua aplicação. Lembrando que os NCM listados no grupo III tem que estar com os GTIN corretos no cadastro de itens de produtos nos seus clientes, caso contrario a nota vai ser rejeitada.

Mesmo colocando como ANSI no geral antes de carregar o XML, os caracteres continuam da mesma forma. ACBrNFe.Config.Principal.CodificacaoResposta = CodResposta.ANSI; ACBrNFe.LimparLista(); ACBrNFe.CarregarXML(CaminhoXml); NotaFiscal = dfeNfe.ACBrNFe.ObterNFe(0);

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

Boa tarde @mlspinelli, Não entendi a motivação de enviar novamente um novo CT-e com valor diferente e com o mesmo numero de um outro que já foi enviado e autorizado pela SEFAZ. Se a sua aplicação permite fazer isso, me desculpe, você precisa rever, pois a sua aplicação deve controlar o numero do CT-e e nunca jamais deixar o usuário aproveitar o mesmo numero para envio de um novo CT-e. Isso só deve ocorrer caso o CT-e tenha sido rejeitado, ai sim, o usuário deve fazer as devidas correções e enviar novamente. A partir do momento que o CT-e foi autorizado o numero deste CT-e deve ficar bloqueado.

Boa tarde, alguma previsão de desenvolvimento da api da cresol?

Boa tarde, Criada a TK-4538 pra avaliação. Obrigado.

Olá, Recentemente diversas empresas estão emitindo boletos com QrCode para pagamento via PIX (Boleto Híbrido), ficando a critério do pagador escolher a forma de pagamento através da ficha de compensação "Código de Barras / Linha Digitável' ou com o PIX "QRCode". Mas até então isso não estava formalizado pelo Banco em si, ou seja, o controle de Baixa do título caso seja pago por PIX ficaria a cargo da própria empresa, como ocorre no fluxo de várias API hoje disponíveis no mercado... Porém, o Banco do Brasil foi o pioneiro em disponibilizar esse tipo de integração em sua própria API, assim ao registrar um Título pode ser definido se será gerado também uma chave PIX dinâmica referente aquele título, com isso o controle da forma de pagamento fica com o Banco, independente se for pago via PIX ou Boleto. Isso facilita muito o controle por parte da empresa beneficiária e viabilizou a implementação desse tipo de integração via API também no componente ACBrBoleto. No componente ACBrBoleto já existia a possibilidade de Registro Online de Boletos para alguns Bancos, inclusive o Banco do Brasil via WebService, mas essa API se trata de um novo Serviço, portanto são configurações e funcionalidades distintas no componente ACBrBoleto. Neste tópico vamos descrever como realizar a homologação e utilizar a API do Banco do Brasil através do componente ACBrBoleto. 1- Primeiro passo é realizar o Cadastro do seu Aplicativo no ambiente Sandbox BB, com isso será fornecido as credenciais para autenticação da API em ambiente de homologação. Utilize o Serviço API Cobrança: https://developers.bb.com.br/home Documentação da API e como utilizar o ambiente Sandbox para cadastrar a aplicação: https://apoio.developers.bb.com.br/referency/post/5ffc477c3b02bd0012ecaa1a 2- Após o Cadastro poderá obter o ClientID e ClientSecret que precisará configurar no componente ACBrBoleto, cada emitente terá seu próprio ClientID e ClientSecret. No componente ACBrBoleto configure em: Banco / TipoCobranca=cobBancoBrasilAPI No componente ACBrBoleto configure em: Cedente / CedenteWS ClientID=Informe o ClientID gerado no Ambiente Sandbox BB ClientSecret=Informe o ClientSecret gerado no Ambiente Sandbox BB Scope=cobrancas.boletos-info cobrancas.boletos-requisicao KeyUser=developer_application_key IndicadorPix=True //Para utilização do PIX pela API - Banco do Brasil é necessário que o emitente tenha chave PIX cadastrada no BB, caso for utilizar somente a emissão tradicional pela API enviar False nesse parâmetro. Em Configurações / WebService - Configure da seguinte Forma: Na opção de Ambiente escolher de acordo com a operação que esteja fazendo (Homologação ou Produção) necessário coerência com as chaves contratuais junto ao BB. As operações homologadas para a API BB são de Inclusão e Consulta [tpInclui, tpConsulta, tpBaixa, tpAltera] SSLHttpLib utilizar cryOpenSSL SSLType utilizar LT_TLSv1_2 3 - Com essas configurações já é possível realizar o registro de um título no BB via API. O Título deve ser incluso normalmente como no processo tradicional do componente, mas ao invés de gerar uma remessa, utiliza-se o o método "EnviarBoleto" - (botão no Aplicativo ACBrBoleto Demo: [Registrar Boleto On-Line]) . Este botão possui exemplos de como obter o Retorno da API. Se o título foi registrado sem nenhuma rejeição, automaticamente será atualizado a chave PIX junto ao Título. Atenção usuários do Inter : Uma das informações que deve ser armazenada do retorno da inclusão é a propriedade “NossoNumeroCorrespondente” pois toda operação de alteração, baixa e consulta você vai precisar informar esta propriedade. (é um código UUID de identificação do boleto) Particularidades BB via API: obs: API possui envio Síncrono Carteira=17 EspecieDoc=DM Modalidade=35 CodigoCedente=Informar Código Cedente Convenio=Informar o Convenio 4- Para imprimir o Boleto: Obs: Quando utilizado PIX, é necessário que além das informações tradicionais, sejam informadas no título o retorno do registro "QrCode" na propriedade "EMV", esse campo corresponde a String de geração do QRCode PIX gerada pelo Banco. ex: Titulo.qrcode.emv := FRetornoConteudoEMV; Impressão em FortesReport: Utilize o Layout "PadraoPIX" Impressão em FastReport: Selecione o arquivo "BoletoPIX.fr3" no diretório "Report" junto ao ACBrBoleto Demo. Segue o Modelo de Boleto Híbrido Impresso: 5- Consulta de Títulos via API Na aplicação ACBrBoletoDemo temos o botão "Consultar Boleto" com código exemplo de como passar os parâmetros para realizar uma consulta na API, o retorno será gerado em uma lista para posterior validação de cada Título. Obs: A homologação deve ser feita também junto ao Banco, inclusive enviando os modelos das Fichas de Compensação emitidas para validação. Todos os testes foram realizados em ambiente de homologação, então é importante a validação completa antes de emitir em ambiente de produção. Atenção usuários do Inter : Uma das informações que deve ser armazenada do retorno da inclusão é a propriedade “NossoNumeroCorrespondente” pois toda operação de alteração, baixa e consulta você vai precisar informar esta propriedade. (é um código UUID de identificação do boleto)