Fabrício G. Araújo

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