Painel de líderes

Boa tarde @Lucio Bittes e @willian_delan hoje consegui registrar o boleto em produção, mais pra minha surpresa o qrcode do pix do veio no retorno do json, registrei 2 boletos e não veio retorno....é complicado....o mesmo problema que aconteci em homologação, aconteci em produção...eu informei tudo certo no json de envio. Para o qr code do pix tem marcar esse campo "cindcdCobrMisto":"S", e não deu certo...agora vou entrar em contato com suporte da API do Bradesco relatando o problema. Parte do retorno abaixo. "cindcdCobrMisto":"S","ialiasAdsaoCta":"06936134000195","iconcPgtoSpi":"20340904287093955007364400000000016","caliasAdsaoCta":"","ilinkGeracQrcd":"","wqrcdPdraoMercd":"","validadeAposVencimento":60,"qFiller6":"","sfiller6":"","sfase":1}

"[+] Adicionada propriedade AjustaAguardaConsultaRet onde quando for True, a propriedade AguardarConsultaRet será ajustada com o valor do campo tmed do retorno de consulta de status do serviço." Fonte: ACBrNFe-change-log.txt na pasta Fontes\ACBrDFe\ACBRNFe, lh. 4286.

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

Já descobri o problema, e já resolvi. Estava sendo enviado em Boleto.NossoNumero o nosso numero completo. Mudei para enviar apenas o sequencial, ai deu tudo certo. Obrigado.

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

Sim, acabei de autorizar uma NFCe em Homologação certinho <pag> <detPag> <indPag>1</indPag> <tPag>04</tPag> <vPag>1.00</vPag> <dPag>2024-04-04</dPag> <card> <tpIntegra>1</tpIntegra> <CNPJ>01027058000191</CNPJ> <tBand>02</tBand> <cAut>123456</cAut> <CNPJReceb>08764323000163</CNPJReceb> <idTermPag>3</idTermPag> </card> </detPag> </pag>

Tudo certo então ? consegui utilizar sem problemas ?

Pode ser algo relação ao ambiente de homologação.. talvez o ambiente não valida essas informações..

Boa tarde! Estado MG. A última atualização foi no dia 23/03/24, porém descobri o problema e por algum motivo a diferenciação de CPF/CNPJ da propriedade a ser consultada no componente parou de ser realizada de forma automática, porque antes usávamos a propriedade CPF sem diferenciação de CNPJ/CPF. Para correção, somente passamos a diferenciar essa propriedade, enviando agora ACBrNFeConsulta.WebServices.ConsultaCadastro.CNPJ e ACBrNFeConsulta.WebServices.ConsultaCadastro.CPF. Agradeço a atenção.

enviado

Boa tarde Acredito que sim, pois esses meios de pagamento também são meios de pagamentos eletrônicos, geram Nsu, autorização, etc...

blza, obrigado pela resposta Juliomar.

Bom dia pessoal, saberiam dizer se essa questão foi solucionada em alguma atualização do componente? Obrigado.

tem a unit do openssl que tu pode pegar e fazer que está no ACBr dá pra fazer omesmo que a linha de comando

Bom dia, cara eu não faço muita ideia de como fazer para executar comandos openssl via Delphi, talvez algum membro saiba, mas tem esse repositório no github (GitHub - lminuti/Delphi-OpenSSL: Delphi wrapper for OpenSSL), que faz uso do openssl via delphi da uma olhada nos fonte e verifica se lhe ajuda.

Bom dia a princípio deveria limpar só os titulos existentes dai configurar para o novo banco , incluir os titulos e gerar a remessa. pegar o retorno e então gerar os pdf dos boletos

Bom dia @Fabrício G. Araújo Aqui no Paraná acabamos que tivemos que voltar como estava antes... Iniciamos caíndo na regra de validação da NT 1.10 como mencionei no início do Post. Ainda na quinta feira dia 28/03/2024 já não estava mais validando o xml como eu havia orientado. Os testes em produção passou conforme imagem acima e não precisamos, até o momento, atualizar os schemas...

Bom dia! Realmente, eles trataram desse assunto lá. Aproveitei para conferir e o SVN já está atualizado. Obrigado, e pode fechar o tópico.

só complementando. não é bom colocar em system32 ou syswow64 pois pode ser substituido por outro em algum momento e ocasaionar erros

Bom dia Willian, Sim, hoje temos 3 provedores (Bauhaus, eISS e Prescon) que usam o Json, sendo assim é possível implementar o provedor Aspec. O provedor Aspec não esta implementado e você pode se basear nos 3 que já existem. Ficaremos gratos com a contribuição.

Bom dia Claudio, Para usar o OpenSSL no lugar do WinCrypt você não precisa recompilar a sua aplicação, basta você mudar a configuração do componente e usar as DLLs da pasta: ...\DLLs\OpenSSL\3.1.3\x86 ou ...\DLLs\OpenSSL\3.1.3\x64 (se a sua aplicação foi compilada para 64 bits). As DLLs devem ser copiadas para dentro da pasta do EXE da sua aplicação.

Bom dia @claudney.dbmgroup, No meu entendimento quando temos mais de uma assinatura no mesmo XML que é este caso, pois devemos assinar o RPS e o Lote de RPS, o atributo URI da assinatura tem que fazer referencia a tag de assinatura, ou seja, o conteúdo do URI tem que ser igual ao conteúdo do Id da tag assinada. O que foi proposto por eles esta errado. Faça o seguinte teste, verifica as duas assinaturas do arquivo 1433-env-lot.xml no validador da Receita Federal. Receita Federal do Brasil - Validador de Assinaturas (fazenda.gov.br) Você vai notar que somente uma assinatura ele acusa como valida a outra não. Faça o seguinte teste: Delete a unit alterada por mim e atualize novamente os fontes do ACBr, reinstale o ACBr e faça um novo teste. Não substitua a unit pela que eu anexei, vamos testar com o que esta no SVN. Se tinha funcionado e depois parou, acredito que eles consertaram o erro que tinha antes no webservice deles.

Vamos realizar os ajustes e testes necessários para versão 8, assim que tiver tudo certo, vamos disponibilizar para uso.

Boa tarde pessoal , consegui resolver o problema meu aqui , foi até simples, claro que com a ajuda de todos aqui ... Apenas peguei as dlls em : e copiei pra dentro da pasta do executável e funcionou. Claro que de acordo com a sua configuração, você vai copiar as dlls necessárias. Detalhe que não fiz teste copiando essas dlls pra dentro da pasta system32 ou syswow64 ... Mas de qualquer forma ficou resolvido aqui pra mim e espero que ajude na dúvida para os demais. Mais uma vez obrigado a todos...

Tentei fazer igual a você @MarceloDev, mas aqui em GO em Homologação a rejeição continua, sendo que para a forma de pagamento Cartão com menos informação passa de boa, mas para PIX não. Exemplo de preenchimento em GO a Cartão e funciona normal (um POS sem integração): Então, fiz o que o @Juliomar Marchetti sugeriu e mandei o questionamento para a Sefaz, agora é esperar a boa vontade deles responder. Se é falha no ambiente de homologação, ou quais campos serão exigidos, se passará para produção... enfim... esperar a resposta.

Não está habilitado no caso do sefaz em questão

https://www.cte.fazenda.gov.br/portal/consultaRecaptcha.aspx?tipoConsulta=completa&tipoConteudo=mCK/KoCqru0=&cte={chave}

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Bom dia ! Obrigado pela contribuição. Foi criado uma tarefa Tk-5296 para analise do time. Será reportado aqui qdo analisado.

Consultando no dia 28/03/2024, já não consta contingência ativada para a Sefaz.

Olá pessoal! Com a famigerada data de 01/04/2024, em que o estado do Mato Grosso passará a obrigar a vinculação dos meios de pagamento aos documentos fiscais emitidos, se aproximando cada vez mais, um movimento recente com a publicação de novas versões de Nota Técnica que está relacionada a este processo trazendo datas que não encaixam, estamos cientes de que muitos estejam com dúvidas que parecem cada vez mais urgentes. Vamos contextualizar algumas coisas. De que Nota Técnica estou falando e por que ela é importante? A Nota Técnica que me refiro é a NT2023/004 que atualmente está na versão 1.11. Ela está relacionada a este processo de vinculação porque traz alterações no layout da NFe/NFCe, adicionando, dentre outros, os campos CNPJReceb e idTermPag para serem preenchidos na integração com as informações do beneficiário do pagamento. Além disso, aumenta o tamanho do campo cAut, permitindo que ele possa receber o valor do endToEndId quando o pagamento for efetuado via QrCode PIX dinâmico. Quais são as datas? Alteração dos campos em produção: 06/05/2024 Validação das alterações no ambiente de produção: 01/07/2024 Obrigatoriedade da vinculação dos meios de pagamento ao documento fiscal: 01/04/2024 Considerando essas informações entendemos que surgem algumas dúvidas. Devido a estas diferenças nas datas, a obrigatoriedade que entra agora no dia 01/04/2024 será adiada? Até o momento desta publicação, a resposta simples e direta é NÃO. Não há nenhuma publicação específica postergando a obrigatoriedade agora do dia 01/04. Como eu vou informar o PIX se o tamanho do campo cAut ainda não foi atualizado? Como ainda não há atualmente campo específico, neste intervalo do dia 01/04/2024 até 06/05/2024, data que será atualizado os schemas, não será necessário informar a informação do PIX. Vale ressaltar, no entanto, que a partir do momento que a atualização do campo for disponibilizada, a informação deverá ser enviada. No FAQ com informações sobre esta integração, está dizendo que quando houver a emissão de NFe\NFCe e o pagamento for futuro, com carnê, deve ser usado o Evento de Conciliação Financeira(ECONF), mas ele ainda não está disponível, o que fazer? Semelhante ao caso acima, como o ECONF ainda não foi disponibilizado, não vai mudar em nada a operação da forma como é feita atualmente. Mas, quando o evento entrar em vigor, o mesmo deverá ser utilizado para vincular o pagamento ao documento fiscal, conforme orientação do FAQ. Não consegui implementar a tempo ou ainda estou no meio do processo, mas já chegou a data, e agora? No DECRETO Nº 384, DE 27 DE FEVEREIRO DE 2020 temos: Ou seja, o fisco não vai multar logo de cara, primeiro o cliente será notificado, com um prazo para adequação fornecido. Caso o prazo estipulado seja cumprido e ainda haja inadequação, ai sim, será aplicado multa e demais medidas. É importante reforçar que isso não é um "extra" no prazo mais, mas sim um "último folego", portanto, NÃO DEIXEM PARA A ÚLTIMA HORA. Veja como o ACBr pode ajudar com este processo de integração dos meios de pagamento em TEF ACBr PayGo - Seja a Solução Completa Essas considerações foram feitas com base na edição do Papo PRO realizada no dia 26/03/2024 junto a Dr. Lúcia Correia da AFRAC.

Bom dia! Poderiam incluir também a Nuvem Fiscal: https://dev.nuvemfiscal.com.br/docs/api/#tag/Cnpj Tem plano gratuito, apenas exige um cadastro com token.

Boa noite pessoal não sei se o tópico já foi resolvido, mas apanhei bastante para fazer uma requisição até achar o código que o amigo postou e funciona perfeitamente, para quem estiver com duvida de como funciona essa chamada do certificado via o arquivo .pem eu tive o mesmo problema, pois eu somente possuía o arquivo .pfx, mas felizmente encontrei uma forma de fazer, para os casos onde vocês possuírem apenas o arquivo .pfx é preciso fazer a conversão via OpenSSL com os seguintes comandos: openssl pkcs12 -in <filename.pfx> -clcerts -nokeys -out certificate.crt openssl pkcs12 -in <filename.pfx> -nocerts -nodes -out private.key comandos o parametro <filename.pfx> é o caminho do certificado, após essa conversão vai ser criados os arquivos .crt e . key e podem ser chamados assim: SSLIOHandler.SSLOptions.CertFile := 'C:\Users\Maquina1\Desktop\Serasa\Cert.crt'; SSLIOHandler.SSLOptions.KeyFile := 'C:\Users\Maquina1\Desktop\Serasa\Cert.key'; segue o código completo: var HTTPClient: TIdHTTP; SSLIOHandler: TIdSSLIOHandlerSocketOpenSSL; begin HTTPClient := TIdHTTP.Create(nil); HTTPClient.Request.Clear; HTTPClient.Request.CharSet := 'utf-8'; HTTPClient.Request.UserAgent := 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Acoo Browser; GTB5; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; Maxthon; InfoPath.1; .NET CLR 3.5.30729; .NET CLR 3.0.30618)'; HTTPClient.Request.ContentType := 'application/json'; HTTPClient.Request.CustomHeaders.Clear; HTTPClient.Request.CustomHeaders.FoldLines := false; HTTPClient.Request.CustomHeaders.Values['Content-Type'] := 'application/json; application/x-www-form-urlencoded;'; HTTPClient.HandleRedirects := True; HTTPClient.HTTPOptions := [hoKeepOrigProtocol, hoInProcessAuth]; SSLIOHandler := TIdSSLIOHandlerSocketOpenSSL.Create(nil); try // Set up SSL IO Handler with certificate SSLIOHandler.SSLOptions.Mode := sslmClient; SSLIOHandler.SSLOptions.VerifyMode := []; SSLIOHandler.SSLOptions.VerifyDepth := 0; SSLIOHandler.SSLOptions.CertFile := 'C:\Users\Maquina1\Desktop\Serasa\Cert.crt'; SSLIOHandler.SSLOptions.KeyFile := 'C:\Users\Maquina1\Desktop\Serasa\Cert.key'; SSLIOHandler.SSLOptions.SSLVersions := [sslvTLSv1_2]; // Set up HTTP client with SSL IO Handler HTTPClient.IOHandler := SSLIOHandler; // Make API call Result := HTTPClient.Get(APIEndpoint); // APIEndpoint = sua url finally HTTPClient.Free; SSLIOHandler.Free; end; end; Obs: Faça download do OpenSSL (https://sourceforge.net/projects/openssl/) e execute o arquivo OpenSSL.exe e execute os comando acima. fontes da conversão do certificado: https://support.kaspersky.com/KSC/12/pt-BR/201428.htm

Boa noite! https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=f NhsSn3/5M= Link do Anexo II - MOC - Versão 7.00 Ainda não existe a previsão do campo no leiaute do DANFE, portanto se você escrever nas informações complementares terão que aceitar o DANFE. Continua obrigatório os campos: Retirado da página 18 do Anexo II - MOC - Versão 7.00 Link: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=f NhsSn3/5M=