Ir para conteúdo
  • Cadastre-se

Painel de líderes

Conteúdo popular

Showing content with the highest reputation on 14-07-2021 em todas as áreas

  1. Pessoal, boa noite, Fiz um teste retirando a função retorna status onde checava a todo momento se o csat =107 antes de emitir o cupom, o problema parou, não sei o que pode ser mas fiz isto deu certo. Fica a dica.
    2 pontos
  2. Sobre o que trata a NT No dia 12/07/2021 foi publicada a versão preliminar da NT 2021.003 a qual estabelece a obrigatoriedade da informação dos campo cEAN e cEANTrib para produtos que possuem códigos de barras com GTIN, tanto para NFe quanto para NFCe, conforme os ajustes SINIEF 07/05 e 19/16. As datas preliminares de implantação desta NT são: Primeira Etapa: 04/07/2022 em homologação e 12/09/2022 em produção Segunda Etapa: 06/03/2023 em homologação e 12/06/2023 em produção Como participar da Consulta Pública A Coordenação Técnica do ENCAT receberá os comentários e manifestações por meio do endereço [email protected] até as 18:00 do dia 30/07/2021. Importante Esta NT somente terá efeitos após a publicação da versão 1.0 da mesma, a qual tem previsão para 08/2021, após a avaliação dos comentários e sugestões recebidos por meio da consulta publica.
    2 pontos
  3. 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)
    1 ponto
  4. Boa tarde pessoal, Recebemos a informação dos canais de suporte a integração via API do Banco do Brasil, de que o serviço encontra-se apresentando indisponibilidade no consumo da API, a qual retorna o erro "Developer application key is not allowed to call this resource method". Os mesmos informaram que já estão atuando na correção, porém ainda não a um prazo definido para que esta indisponibilidade seja resolvida.
    1 ponto
  5. Nenhuma tecnologia supera o velho "desinstala e reinstala" ou "desliga e religa"!
    1 ponto
  6. Eu já tinha o ACBr instalado no meu computador e estava funcionando. Fiz dowloand (SVN update) instalei novamente. Passou a gerar esse erro. Estou removendo o ACBr e vou instalar do início.
    1 ponto
  7. x86 né... agora que vi na resposta acima. Desculpe a confusão. Vou dar continuidade aqui. Grata, Giovanna
    1 ponto
  8. Bom dia! Já achei onde estava o erro... não sei dizer o porque ocorreu mais ele tava pegando um arquivo com o mesmo nome de outro componente. eu isolei o arquivo e instalei o ACBr novamente e deu tudo certo. Valeu!!!!
    1 ponto
  9. Muito obrigado, assim que possível irei estudar um pouco sobre o componente e apresentar para a empresa. Atenciosamente, Júnior Lira
    1 ponto
  10. Olá, bom dia. Das duas formas o XML será validado enviado e o Cupom será gerado. Mas por experiência própria, quando a duvida for com valores de bases e cálculos de impostos, passa a bola para quem entende da área fiscal, coloca para o "Contador" do seu cliente a questão e segue o que ele indicar, lembre-se que quem é corresponsável pela escrituração é ele.
    1 ponto
  11. Olá pessoal, Para quem ainda não sabe estou promovendo um Refactoring no componente ACBrNFSe. Ele praticamente foi reescrito do zero e infelizmente teremos algumas quebras de código quando ele for liberado. Mas vamos falar de coisas boas. Hoje temos que disponibilizar para os nossos clientes além do executável, DLLs, os famosos arquivos INI, o arquivo Cidades.ini e os arquivos INI dos provedores. Pois bem, isso acabou. Os arquivos INI referente aos provedores se transformaram em Unit, ou seja, fazem parte do fonte do componente. O conteúdo do arquivo Cidades.ini migrou para o arquivo ACBrNFSeServicos.ini que é transformando no ACBrNFSeServicos.res através do BAT: Compila_RES. O arquivo ACBrNFSeServicos.res é incorporado ao executável, logo vocês só vão precisar distribuir o executável e as DLLs para os seus clientes. O que vocês acharam dessa mudança? Ainda não esta 100%, em função das diferenças dos provedores, mas criei um novo método chamado Emitir que tem por finalidade gerar o XML do RPS, assinar se necessário, gerar o Lote e assinar se necessário, enviar, aguardar o retorno do XML da NFSe. Independente do serviço que o provedor se utiliza para recepcionar o XML do RPS. Vou dar um exemplo: O provedor 4R que segue a versão 2 do layout da ABRASF implementou somente o método EnviarLoteRpsSincrono para recepcionar o RPS, sendo que no Manual da ABRASF versão 2 estão previstos os métodos: EnviarLoteRps, EnviarLoteRpsSincrono e GerarNfse. Por outro lado o provedor ISSJoinville que também segue a versão 2 do layout da ABRASF implementou somente o método EnviarLoteRps. Se vocês tem clientes cujas cidades utilizam o provedor 4R e tem clientes em Joinville, ou vocês tem duas aplicações ou a aplicação tem uma tela de configuração para definir qual método a ser utilizado. O método Emitir vem para tentar resolver esse problema da seguinte forma: se o provedor for 4R ele vai se utilizar do método EnviarLoteRpsSincrono automaticamente, agora se for ISSJoinville vai usar o EnviarLoteRps. Desta forma não precisamos de nos preocuparmos com qual o método devemos usar para enviar o RPS para o webservice. Acredito que vai ficar muito bom e pratico. O que vocês acham? Muita coisa já foi feita e muito mais precisa ser feito. Para que vocês tenham uma ideia foi criado 32 Units, ou seja, uma para cada provedor que segue a versão 1 do layout da ABRASF, mais 53 Units para os provedores que seguem a versão 2 do layout da ABRASF e mais 19 Units para os provedores que tem o seu próprio layout. Até o final deste mês de outubro estarei disponibilizando o programa exemplo compilado para que vocês possam fazer mais testes. Em breve vou explicar como vão ser os testes e como reportar os resultados. Antes que eu esqueça, esse Refactoring visa poder incluir a emissão da NFS-e no ACBrMonitor Plus e a criação do ACBrLibNFSe (DLL). Um forte abraço a todos.
    1 ponto
  12. Olá pessoal Confirme prometido estou anexando aqui nessa postagem o programa exemplo do componente ACBrNFSe refatorado para que vocês possam realizar os testes com os provedores de seus clientes. Caso tenham algum problema, em alguma funcionalidade favor anexar os XMLs de envio e de retorno que funciona atualmente e os gerados com o novo componente para que eu possa fazer as devidas correções. Foram implementados nesse novo componente 32 provedores que se utilizam da versão 1 do layout da ABRASF, 55 provedores (inclusive: SiapSistemas e DSFv2) que se utilizam da versão 2 do layout da ABRASF e 20 provedores que seguem o seu próprio layout, totalizando 107 provedores, abrangendo 1215 cidades. Como realizar os testes: Na sua maquina de desenvolvimento crie uma pasta (Por exemplo: NovoACBrNFSe) descompacte o arquivo ACBrNFSe_Exemplo.rar dentro dessa pasta. Ao executar ele pela primeira vez vai aparecer a tela de erro: O motivo de aparece essa tela é porque ainda não existe o arquivo de configuração. Clique no botão [OK] E configure da mesma forma que você configurou o programa exemplo do componente atual, ou antes de executar copie para dentro dessa pasta o arquivo de configuração (ACBrNFSe_Exemplo.ini) do programa exemplo que esta na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\Delphi Note que nesse novo programa exemplo temos um botão chamado Envio: Foi criado um novo método chamado Emitir que tem por finalidade abstrair os métodos de envio de cada provedor. Vamos a alguns exemplos: Os provedores que seguem a versão 1 do layout da ABRASF só possuem 1 método de envio que é o Enviar, logo o método Emitir vai usar esse método, por outro lado o provedor 4R que segue a versão 2 do layout da ABRASF e deveria ter disponibilizado os métodos Enviar, EnviarSincrono e Gerar, disponibilizou somente o EnvioSincrono, logo o método Emitir vai usar esse método. O provedor MegaSoft que também segue a versão 2 do layout da ABRSAF e que deveria ter disponibilizado os 3 métodos citados acima, só disponibilizou o método Gerar, logo o método Emitir vai se utilizar do método Gerar para enviar o RPS par o WebService. Assim que liberarmos os fontes do novo componente conto com todos para melhorarmos o método Emitir, pois acredito que ele vai simplificar bastante. Por fim peço a todos que postem os resultados dos testes aqui no fórum. Para quem não é membro do SAC favor postar em: Home / Fórum Aberto - ACBr / ACBrDFe / ACBrNFSe Para quem é membro do SAC favor postar em: Home / Suporte Pago - SAC / DFe - Documentos Fiscais Eletrônicos Programa exemplo do novo componente ACBrNFSe: ACBrNFSe_Exemplo.exe(compilado: 11/11/2020 as 16:14) Desde já muito obrigado pela colaboração de todos.
    1 ponto
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...
The popup will be closed in 10 segundos...