Fabrício G. Araújo

Bom dia @Gelson Junior Conforme informei na postagem mais acima: Basta informar o crt no que seria o pem, e para mim funcionou normalmente. No meu caso não usei as dlls, usei diretamente o componente no Delphi.

Bom dia pessoal, @IgorAcertSoft Passando só para avisar que com o empenho em nos ajudar dos parceiros do ACBr @Daniel Simoes @Franciele Rocha, finalmente fomos homologados com o Pix C6 Bank com o uso do componente ACBrPixCD em nossa aplicação. Criamos as credenciais de produção de nossa conta e tudo funcionou normalmente. Obrigado mais uma vez a todos envolvidos, um grande abraço.

Bom dia @Juliomar Marchetti Segui a sua sugestão e implementei nos fontes. Funcionando 100%. Seguem os fontes em anexo. FrPrincipal.pasFrPrincipal.dfmACBrPIXPSPInter.pas Sendo os arquivos dos diretórios: FrPrincipal: acbr\Exemplos\ACBrPIXCD\Delphi ACBrPIXPSPInter acbr\Fontes\ACBrPIXCD

Boa tarde pessoal, Vi que no programa de exemplo de uso do componente ACBrPIXCD para Delphi, existem implementações de alguns PSP de simulação de pagamento. Estou só passando para avisar, que existe API para simular isso no Pix Inter na sandbox, acabei de testar no Postman e funciona 100%. Estou passando o link da documentação: https://developers.inter.co/references/pix#tag/Cobranca-Imediata/paths/~1cob~1pagar~1{txid}/post

@IgorAcertSoft passando só para informar que já tem mais de uma semana que enviei o documento para homologação do Pix para o pessoal da C6 Bank e não deram retorno algum... que absurdo isso. Existe uma postagem fixada: Aos amigos do ACBr que interagiram na postagem acima @antonio.carlos e @Daniel Simoes, teria como interceder por nós? Ou passar algum contato direto do C6 Bank, pois seguindo os passos para homologação e enviando o e-mail com o roteiro preenchido para [email protected], simplesmente não dão retorno algum.

Bom dia @IgorAcertSoft, Espero que eles estejam homologando e ativando em produção, mas devo enviar a documentação para eles lá para semana que vem, ainda estou vendo outras coisas por aqui. Mas a princípio espero que esteja tudo ok, pois no e-mail inicial com as credenciais para teste na sandbox, falaram que assim que estiver ok, preencher o documento (que enviaram neste mesmo e-mail), e enviar para eles para a homologação do software... estou contando que tudo dará certo. Assim que obtiver retorno vou postar aqui.

Hum... nem sabia que tinha ele não, obrigado @Juliomar Marchetti Fui abrir o projeto ExemploC6 e como não instalo nenhum componente de relatório aí nem compilou, pois acredito que tenha as amarrações por conta dos boletos e como por agora estou interessado apenas no Pix, o outro projeto de exemplo (PIXCDTeste) é mais útil para mim. No PIXCDTeste, coloquei as credenciais, inclusive informei o arquivo .crt no que seria o .pem e funcionou a criação da cobrança do Pix, então só cancelei a cobrança que funcionou normalmente também. Sabe me informar como faria o teste de pagamento do Pix (lembrando que estou usando o sandbox)? Ah... sobre a dúvida inicial, sabe me informar se alguém já liberou o sistema com o componente em produção?

Estou iniciando os estudos para integrar o sistema com o uso do componente ACBrPIXCD com o Pix do C6 Bank, então me surgiram algumas dúvidas, se puderem me ajudar agradeço, seguem: Encontrei esse tópico :A última atualização deste tópico é de set/24, e o pessoal informa que ainda não está disponível o ambiente de produção para o Pix do C6 Bank. Sabem me dizer se já está disponível? Alguém já homologou e distribuiu a aplicação em produção para seus clientes? Recebi os dados do pessoal do C6 Bank para os primeiros testes com o uso do programa de exemplo (PIXCDTeste), e percebi que ao invés de receber um arquivo .pem, recebi um arquivo .crt. É a mesma coisa? Posso só informar ele na configuração no campo C6BankCertificado.pem? Ou tenho que fazer algo diferente?

Bom dia pessoal, Queria confirmar com vocês, realmente os servidores das SEFAZ não retornam mais os eventos no método ACBrNFe.Consultar (usando com o componente preenchido com ACBrNFe.NotasFiscais.LoadFromFile)? Gostaria de saber sobre isso, pois uma rotina no meu sistema parou de funcionar, sendo que verificava antes de qualquer tentativa de cancelamento de NF-e/NFC-e, fazia uma consulta para saber se já não estava cancelada, afinal podem ocorrer erros na tentativa de cancelamento e não obter resposta, como quedas de energia, oscilar a internet... enfim... então ao consultar e verificar que já tinha o evento de cancelamento, era possível identificar os protocolos e tudo mais e não enviava o cancelamento novamente, e agora infelizmente isso não é mais possível. A forma de verificar pelo componente que sempre usei era essa: laço em: ACBrNFe.WebServices.Consulta.procEventoNFe.Count verificando: ACBrNFe.WebServices.Consulta.procEventoNFe.Items[i].RetEventoNFe.InfEvento.tpEvento = teCancelamento Se realmente as SEFAZ não retornam mais essa informação no consultar, existe outra forma de consultar esses eventos para recuperá-los e armazená-los em meu sistema?

@arnaldo Santos Simplesmente não tem que preencher se usar o PIX estático (20), pois pelas regras das NT somente é permitido o preenchimento da tag card para o PIX dinâmico (17). Vale lembrar que em MT é obrigatório o uso do PIX dinâmico, com exceção para situações de entregas, que aí deve ser usado o PIX estático, sem preenchimento dos campos exigidos para o dinâmico. Dá uma googada por PORTARIA N°262/2023-SEFAZ

Hum... acho que será algo por aí mesmo @Juliomar Marchetti, o chato é só ter acesso a isso, pois os clientes não conseguirão ver essa informação, seja em um e-mail antigo quando foram instalar o GP, ou se é que o próprio GP tenha essa informação e se é possível acessá-la, configurações dele, por exemplo... enfim... mais trabalho para o suporte e transtorno para o cliente... infelizmente. Cheguei a pensar em até informar o nome da máquina da rede, pois TEF com GP fica só em uma máquina mesmo, e o campo idTermPag é alfanumérico. Não sei ao certo o que fazer ainda... Mas agradeço a dica, valeu, obrigado.

Olá pessoal, Tenho um sistema legado que utiliza TEF por Gerenciador Padrão (troca de arquivos), estou fazendo pequenos ajustes para atender a exigência de MT para a obrigatoriedade de integrações dos meios de pagamento TEF com NFC-e, mas não sei como preencher o campo idTermPag do grupo card. Sei que em um POS não integrado, no comprovante vem impresso o TERM: xxxxxxxx, ou em soluções como o Stone Connect (POS integrado) possui essa informação via api, mas no TEF com GP além de não ter essa informação, não sei de onde o usuário vai poder extrair essa informação, nem que eu deixe cadastrado fixo em meu banco de dados, mas preciso saber de onde verificar isso. Seria algo de alguma identificação do PINPAD? Como estão fazendo? Deixando sem preenchimento? Quem puder ajudar agradeço desde já.

Entendo... vou acompanhar esse post, caso os componentes sejam modificados conforme sugeriu, no meu caso que tenho DANFE próprio, deixarei de usar o método FormaPagamentoToDescricao de pncConversao, e então vou modificar meus DANFEs para usar somente uma das opões que no meu sistema se encaixa melhor a descrição "Outros Crediários".

Hum... não sei se é o mais adequado, no meu entendimento poderia ser usado uma das opções dentre: Cartão da Loja (Private Label), Crediário Digital, Outros Crediários, não sei se estaria correto colocar toda essa descrição nos DANFES. Os fontes atuais já estava com um dos permitidos, que era somente "Cartão da Loja (Private Label)".

@mfeitosa, você não está seguindo o que está especificado na nota técnica. Se for abater a desoneração no vNF, você tem que preencher a nova tag indDeduzDeson com 1, conforme está especificado. Se não gerar a tag ou preencher a tag com 0, não pode abater no vNF.

Estava estudando os fontes e as revisões e vi que logo após a minha postagem foi enviado hoje ao repositório uma modificação ajustando justamente isso: Fiz um teste básico alterando os meus fontes somente essa linha e funcionou... depois vou fazer uma atualização geral novamente dos componentes. Obrigado @Italo Giurizzato Junior

Boa tarde, Fiquei um tempo sem atualizar os componentes e agora com a versão mais atual o comportamento do componente mudou e não estou sabendo como ajustar. Tenho uma rotina que carrega um arquivo xml de evento para o componente para ler os seus dados, que basicamente faz assim: ACBr_NFe.EventoNFe.Evento.Clear; ACBr_NFe.EventoNFe.LerXML('c:\teste\XXX-procEventoNFe.xml'); // assim tinha acesso a todas a propriedades de RetInfEvento, por exemplo: ACBr_NFe.EventoNFe.Evento.Items[0].RetInfEvento.cStat ACBr_NFe.EventoNFe.Evento.Items[0].RetInfEvento.dhRegEvento ACBr_NFe.EventoNFe.Evento.Items[0].RetInfEvento.nProt Mas depois da atualização o RetInfEvento de cada evento (ex. do primeiro evento: ACBr_NFe.EventoNFe.Evento.Items[0].RetInfEvento.nProt) não está preenchido. De que forma tenho que acessar agora?

@Victor H. Gonzales - Panda Acredito que com essas configurações: ACBrNFe.Configuracoes.Arquivos.Salvar := True; ACBrNFe.Configuracoes.Arquivos.PathSalvar := PastaTmp; O componente salva as solicitações de envio e resposta da Sefaz, correto? Então, esses seriam os arquivos SOAP que se refere? Se sim, é aquilo que falei mesmo... simplesmente não está sendo retornado os eventos. 52240604429915000178550020000000661000044243-ped-sit.xml 52240604429915000178550020000000661000044243-sit.xml Para vocês está retornando normal se fizerem um teste na Sefaz de vocês?

Sim @Renato Rubinho, a nota está cancelada em homologação, tanto é que se tentar cancelar novamente recebo a rejeição: "Rejeição: Verificar se a NF-e está autorizada (não pode estar cancelada e nem denegada)". Não estou querendo acreditar que a Sefaz mudou essa regra para não retornar mais os eventos... não lembro de ver nenhuma documentação nesse sentido. Tinha um tratamento no sistema justamente para recuperar o evento de cancelamento, caso desse algum problema e não conseguisse gravar o xml do evento assim como o protocolo e tudo mais do cancelamento... agora simplesmente não será mais possível se ao consultar não retornar mais os eventos. Os meus testes estão sendo efetuados na Sefaz GO homologação, será ainda que não haverá padronização entre as Sefaz, sendo cada uma funcionar de um jeito? Aí piora mais ainda a situação... aff...

Bom dia, Estou fazendo testes gerais na aplicação após atualização e me deparei com uma situação em que sempre foi utilizado o método ACBrNFe.Consultar uma chave NF-e e antes retornava os eventos (ex: caso houvesse cancelamento), agora não retorna mais... estou sem entender se isso foi algo na Sefaz que parou de enviar essas informações? Ou tenho que ajustar algo no componente que não estou sabendo? Estou testando em homologação (Sefaz GO). Quem puder ajudar, agradeço.

Ontem fui validar o ambiente de homologação em GO e realmente estava ocorrendo a rejeição, hoje tudo indica que voltou ao normal. Testem novamente que deve ter normalizado.

Boa tarde, Passando só para informar que aqui em GO em Homologação finalmente ajustaram o ambiente e passou conforme o exemplo do @MarceloDev Isso depois de reencaminhar o e-mail ao órgão responsável daqui, no início da semana estava da mesma forma, dando rejeição e então depois do novo e-mail me responderam hoje pela manhã para testar e finalmente ajustaram o ambiente e funcionou.

Bom dia, Aqui em GO em homologação continua a mesma, solicitando preenchimento dos dados do cartão no PIX e mesmo preenchendo (o básico) dá restrição, conforme informei acima. Entrei em contato pelo site no Fale Conosco (https://goias.gov.br/economia/fale-conosco/), que me indicaram o telefone (62)3309-6950 no que seria o órgão equivalente à SEFAZ (Secretaria da Economia), que por sua vez me indicaram um e-mail ([email protected]) para enviar os questionamentos, que não souberam me responder por telefone, e que com certeza não irão me responder, pois enviei e-mail dia 03/04 e não obtive retorno. Mas como já mudaram os prazos dessas regras e já vi novas NT com alterações que virão na forma de pagamento... é esperar para ver.

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.

Que bom que deu certo @RibaSoft, mas realmente continuei sem entender o porquê do acess violation. Mas você chegou a perceber que nem sequer você precisa da longa codificação dos seus "case"? No exemplo que passei tem as funções de conversão. Todo o seu "case" para atribuir em seu array ( Pag[I].TBAND ) pode reduzir em uma linha de código, por exemplo: Pag[I].TBAND := StrToIntDef( BandeiraCartaoToStr(auxNF.NotasFiscais.Items[0].NFe.pag[I].tBand), 99 ); Pode fazer o mesmo para o outro "case" também, o que atribui o seu Pag[I].TPAG