Fabrício G. Araújo

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?

Talvez seja algo no ACBr mesmo, até no Pro tem uma mensagem indicando que será verificado:

Divulgaram novas NT hoje adiando os prazos e inclusive já foram publicados no Portal da NF-e os novos esquemas também. Nota Técnica 2019.001 -v.1.62 - Publicada em 19/03/2024 Criação e Atualização de Regras de Validação VERSÕES OFICIAIS (em uso) Esquemas XML NF-e/NFC-e - Pacote de Liberação nº 9n (Novo leiaute da NF-e, NT 2023.004 v.1.11 e NT 2019.001 v.1.62). Publicado em 19/03/2024.

Bom dia aos colegas, Só passando para avisar que a SEFAZ/GO consertou a bagunça deles, ou seja, agora pode usar no ambiente de Homologação o CSC de Homologação mesmo, acabei de testar e tive que ajustar o CSC.