Painel de líderes

Corrigido no SVN. Atualize novamente os fontes, por favor.

Consegui resolver. Atualizei o componente, substitui os componentes que estavam no projeto por componentes com configuração original. Obrigado.

Bom dia, Procure um advogado, ai entraríamos na esfera dos juristas e interpretação de textos, que não é o escopo da ACBr. No meu ponto de vista, mas que não reflete a verdade, é apenas uma opinião. protestar "em" 6 dias, então, no meu entendimento irá ocorrer no 6 dia o evento, e não protestar "após" 6 dias. Na gramática portuguesa, "em" é uma preposição, um indicativo de relação de lugar, tempo, duração, prazo, modo, meio, preço, avaliação, fim, destinação, estado, qualidade ou matéria, causa, motivo... Ai cabe ao jurídico da sua empresa o entendimento deles, e recorrer.

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)

Boa tarde, Conforme contam nas postagens do tópico abaixo, apesar da NT 2020.005 ter entrando em vigor para o ambiente de homologação em 02/08/2021, as UF está retornado a rejeição a seguir quando as novas tags são enviadas. Segundo retorno obtido junto a SEFAZ-SP por um de nossos colegas, os mesmos já estão trabalhando para solucionar o problema.

Boa tarde amigo, Deu certo, quando troquei o .res Muito obrigado pela solução

Achei o que era, o código estava indicando o mesmo rps duas vezes, por isso estava dando assinatura invalida. Obrigado!

Ok, obrigado pelas informações.

Você vai usar o envio de evento do componente ACBrCTe. Veja:

resposta do WS (266:Falha na comunicação com a AC-SAT). Esse é o retorno, entrei em contato com a Elgin, segundo eles estão tendo mais relatos de problemas, só queria confirmar se mais alguém também não está conseguindo ativar o equipamento.

Bom dia Theiller, Não estamos dando suporte ao componente antigo. Por favor atualize todos os fontes de todas as pastas e reinstale a suíte ACBr. Não esqueça de marcar para instalar os novos componentes em especial os 2 que se refere a NFS-e. Faça os testes usando o programa exemplo do novo componente de emissão de NFS-e: ACBrNFSeX. Manual de Migração https://www.projetoacbr.com.br/forum/topic/63017-manual-de-migração-para-o-novo-componente-de-emissão-de-nfs-e/

Obrigado pelo feedback Juliomar... O Pessoal aqui me parece q adaptou mesmo... Sou novato aqui no projeto. Vou procurar entender melhor.

Boa noite Joas, Vai ser complicado você comparar o código do componente antigo com o novo, mudou muita coisa. Se com o componente antigo esta funcionando, e com o novo não, eu lhe peço que anexe o XML de envio do Rps gerado pelo antigo e pelo novo para que eu possa analisar.

Boa tarde. Referente ao problema Erro Interno: "IE id: 66 - Código do serviço está nulo / vazio", consegui resolver, era um erro meu. Eu estava preenchendo somente ACBrNFSeX.NotasFiscais.New.NFSe.Servico.ItemListaServico. No caso da Elotech, o componente usa ACBrNFSeX.NotasFiscais.New.NFSe.Servico.ItemServico[I].ItemListaServico. Preenchi e o provedor me retornou alguns outros erros, tratando de validações de preenchimento de alguns campos. Resolvi parte destas validações e o reativei a validação de XML. Desta vez ocorreu sem problemas (aparentemente, estava faltando o preenchimento do "MunicipioIncidencia"). Vou seguir resolvendo as demais validações, qualquer novidade aviso aqui. Obrigado.

Boa tarde Juliano, A cidade de Londrina, se utiliza do provedor SigISS que possui um layout próprio, sendo assim não sei como funciona esse provedor. O que eu sei é que ele possui em seu webservice apenas 3 serviços implementados: 1. Gerar - destinado a recepcionar um Rps por vez, ou seja, o envio é unitário e não em lote. 2. Consultar NFS-e - destinado a consultar uma nota informando o numero dela. 3. Cancelar NFS-e - destinado a cancelar uma nota. Favor anexar os XMLs (soap) gerados ao enviar o Rps, para que eu possa analisar.

E ai mano beleza ? Apenas para formalizar o problema estava na minha tag cNF. Eu não estava utilizando ela. Passei a utilizar e gravar o Código Numerico no banco de dados e para gerar novamente pego este mesmo código numérico e deu certo. Peguei esta dica em um outro Post que você fez.

Continuando o assunto sobre substituição de NFS-e nos provedores que seguem a versão 1 do layout da ABRASF. Um membro da equipe ACBr fez o seguinte teste, usando o programa exemplo do novo componente: ACBrNFSeX e o provedor utilizado foi Ginfes. No programa exemplo, mais precisamente a procedure AlimentarNFSe descomente as linhas abaixo: // Usado quando o RPS for substituir outro { RpsSubstituido.Numero := FormatFloat('#########0', i); RpsSubstituido.Serie := 'UNICA'; // TnfseTipoRPS = ( trRPS, trNFConjugada, trCupom ); RpsSubstituido.Tipo := trRPS; } essas linhas de código permite você informar o numero, serie e tipo do Rps a ser substituído. Exemplo, foi enviado o Rps de numero 300 que gerou a NFS-e de numero 400. Quero emitir uma nova nota visando substituir a NFS-e de numero 400. Devo alimentar o componente com os dados do novo Rps (por exemplo Rps de numero 301) nas linhas apresentadas acima informo o numero do Rps a ser substituído, ou seja 300. Como a nota de numero 400 foi gerada através do envio do Rps 300, ao enviar um novo Rps que tenha o numero do Rps a ser substituído, no caso 300, o WebService vai automaticamente substituir a nota de numero 400. Não sei se esse processo de substituição funciona em todos os provedores que seguem a versão 1 do layout da ABRASF, mas não custa nada a testar.

Bom dia. Você está testando no componente ACBrNFSeX? Se não, precisamos que teste, pois o suporte é somente a ele atualmente... Att.

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

No final das contas a mudança foi apenas no GISS. Para integração continua o GINFES, depois de muita briga com a prefeitura voltou a funcionar. Mas... No domingo houve uma queda de energia na prefeitura e o sistema está novamente intermitente. Alguns clientes ainda conseguem emitir, outros fica dando erro de timeout... vai entender...

Atualizando.... Consegui contato com a prefeitura de Itaquaquecetuba pelo número 4753-7026. De acordo com a atendente, era necessário fazer uma parametrização no sistemas deles, o que foi feito em minutos e no mesmo instante consegui fazer o envio do RPS e emissão da NFS.

GINFES Homologação normalizado 16/08/2021 - 15:38

Ok, Italo, obrigado!!! Vou verificar as atualizações de sexta (13/08) para cá, quando fizemos o nosso ultimo update.

Bom dia Italo, Perfeito, vou atualizar nosso projeto para o componente novo. Depois te reporto aqui. Obrigado.

Se não me engano o @Italo Giurizzato Junior já tem as alterações prontas, que devem enviadas para o repositório assim que for habilitado o ambiente de homologação.