Fabrício G. Araújo

@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

@RibaSoft não estou sabendo como te ajudar, mas nunca tive problemas para ler esse atributo tBand sem estar preenchido. Fiz um exemplo bem simples que você pode testar em seu ambiente, cria um botão em um form e coloca esse código: procedure TForm1.Button1Click(Sender: TObject); var vACBrNFe: TACBrNFe; vNFe: TNFe; i: Integer; strAux: string; begin try vACBrNFe := TACBrNFe.Create(nil); vACBrNFe.NotasFiscais.Clear; vACBrNFe.NotasFiscais.LoadFromFile('C:\teste\nf.xml'); vNFe := vACBrNFe.NotasFiscais.Items[0].NFe; for i:=0 to vNFe.pag.Count-1 do begin strAux := 'Dados pagto indice ' + IntToStr(i) + '): ' + #13#10 + ' tPag: ' + FormaPagamentoToStr(vNFe.pag[i].tPag) + #13#10 + ' vPag: ' + FloatToStr(vNFe.pag[i].vPag) + #13#10 + ' tpIntegra: ' + tpIntegraToStr(vNFe.pag[i].tpIntegra) + #13#10 + ' CNPJ: ' + vNFe.pag[i].CNPJ + #13#10 + ' tBand: ' + BandeiraCartaoToStr(vNFe.pag[i].tBand) + #13#10 + ' cAut: ' + vNFe.pag[i].cAut; ShowMessage(strAux); end; finally FreeAndNil(vACBrNFe); end; end; Dá uses em ACBrNFe, pcnNFe, pcnConversao e no loadfromfile aponta para o seu arquivo xml. Neste exemplo, aqui li um xml sem o tBand também, assim: E funciona normal, sem dar acess violation. Valida aí no seu ambiente e vê no que dá.

@RibaSoft teria que entender o que está fazendo... se você já tem o componente que você chamou de "auxNF" com todos os atributos lidos da nota (provavelmente com loadfromfile), você está atribuindo em outro componente ou variável? O que seria isso (destacado em vermelho)?: if (Pag[I].TPAG = 3) or (Pag[I].TPAG = 4) then case auxNF.NotasFiscais.Items[0].NFe.pag.Items[I].tBand of bcVisa: Pag[I].TBAND := 1; Se é uma variável ou componente tem que garantir que você criou a instância dessa classe, senão vai dar o acess violation.

Não teria porque dar erro de access violation em tBand, até porque não é uma classe e sim apenas um tipo. Verifica se realmente suas variáveis estão corretas como o seu índice "I" em ...Items[I].

Sim, o fechamento do tópico anterior está correto @Juliomar Marchetti, se referia a apenas os prazos e disponibilidade dos atributos nas SEFAZ. Esse novo tópico, criei esse para indicar que tem nova versão e que os fontes sofrerão alterações para adequar a ela.

Sim, estou a par dos novos campo @MarceloDev, mas na prática até onde sei apenas MT irá exigi-los, e agora as outras SEFAZ (acredito eu) ativaram a exigência sem motivo, como disse até em MT terá que aceitar sem preenchimento para os segmentos que não são obrigado a informar sem sistema integrado. Talvez o RS obrigue, pois tem algo parecido com isso, mas até onde sei não existem outros decretos em outro estados, por isso que acho que é falha das SEFAZ ao ativarem as regras exigindo isso.

Até informei isso em outro tópico que já foi fechado: Só para destacar, que a Sefaz percebeu a bobeira deles que na versão anterior (1.61) criaram o grupo correspondente ao Crédito Presumido, mas não definiram o nome (gCred) e agora que ajustaram... e isso vai implicar em mudanças nos componentes do ACBr. Inclusive os schemas também foram ajustados, conforme links acima.

Até tenho o recurso de informar os dados do cartão para vendas de cartão mesmo @Juliomar Marchetti, mas agora é o PIX, e se for na mesma toada de MT, segundo as regras não poderia informar manualmente (somente com integração), mas espero que agora seja só manezada da SEFAZ mesmo, lembro que isso ocorreu quando alguns estados exigiram, há alguns anos atrás, as informações como o CNPJ e autorização de vendas a cartão e também a SEFAZ de GO ativou a regra em homologação e depois como em GO não exige isso, removeram da homologação e não foi para produção, mesmo assim na época tive que criar uma configuração no sistema para solicitar ou não os dados do cartão em uma venda POS (sem integração). Agora nem sei o que está exigindo do PIX, ou vou aguardar... e ver o desenrolar, ou ir na tentativa e erro de quais campos mínimos eu poderia preencher (nada parecido de toda a informação exigida por MT, que não vai aceitar POS sem integração e nem PIX sem integração - obs.: para apenas alguns segmentos).

Atualizei os componentes a uns 2 dias, e fui testar hoje cedo e realmente estava com os problemas dos caracteres estranhos nas acentuações, então fiz uma nova atualização hoje e voltou ao normal. Obrigado @BigWings

Hum... agora meio que assustei com essa parada aí... pois fiz teste com a UF de GO em homologação e também deu isso. Até onde entendi, apenas o estado de MT que vai passar a exigir preenchimentos dos dados de cartão de uma venda PIX e nem sequer deverá restringir se não preencher, pois são só para alguns segmentos, conforme o post: Agora vem a questão da dúvida... se em homologação em GO está sendo exigido o preenchimento, dando rejeição, isso vai passar para Produção? Se for exigir em produção, que campos devemos preencher, já que (diferente de MT) o pessoal pode usar o PIX sem integração em GO?