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.

Kkk... em produção iria parar as NFC-e do estado e Goiás inteiro... pensa... o trem ia ficar feio para o estagiário que fizesse isso hein... kkk... Que bom que deu certo @wagaonet, é cada uma que temos que passar né... Valeu.

Mas só para informação @rogeriodiasguerreiro e @wagaonet, acabei de emitir uma NFC-e em homologação e foi autorizada de boa, só tem que inverter o CSC como falei, usar o de Produção na emissão em Homologação. Já tem alguns dias que percebi isso, mas de certo logo logo devem voltar ao normal aí, já estou como o meu CSC de homologação para testar novamente caso corrijam o ambiente.

Estou criando esse tópico mais para ajudar o amigo @wagaonet, e como não consigo responder no ambiente do pró, estou enviando aqui. O meu ambiente de homologação passou a ter problemas em GO, e CSC que usava desde 2016 começou a dar que estava revogado, sendo que não estava... mas enfim... não vou me alongar... o fato é que descobri que eles (SEFAZ-GO) fizeram algum besteira lá, e na verdade eles estão validando o CSC de forma errada, e na tentativa e erro fiz funcionar... o que deve ser feito: Você estando no ambiente de HOMOLOGAÇÃO da NFC-e, tente usar o Identificador e CSC de Produção, isso mesmo, não escrevi errado... a regra deles está validando de forma errada... no mínimo o estagiário de lá fez isso e até agora não perceberam. Pra mim aqui voltou a funcionar normal. Tenta aí e vê se funciona para você também.

Boa tarde, Seria algo nesse sentido a sequencia de comandos? SAT.INICIALIZAR SAT.ENVIARCFE(... SAT.IMPRIMIREXTRATOVENDA(... SAT.DESINICIALIZAR ESCPOS.Ativar ESCPOS.Imprimir("Linha 1 de um texto qualquer") ESCPOS.Imprimir("Linha 2 de um texto qualquer") ESCPOS.Imprimir("Linha 3 de um texto qualquer") ESCPOS.Desativar Está correto dessa forma?

Só corrigindo o que falei acima, na verdade após o comando SAT.ENVIARCFE com sucesso, é disparado o SAT.IMPRIMIREXTRATOVENDA, não é automático como falei... desculpem a falha...

Bom dia pessoal, Utilizo o ACBrMonitorPLUS para integração com SAT, então tudo funciona normalmente ao enviar o comando SAT.ENVIARCFE, é gerado o CF-e SAT no aparelho e impresso o CF-e de boa automaticamente. O que preciso é após imprimir o CF-e, imprimir um texto qualquer (no meu caso um comprovante de venda PBM, coisa de farmácia e drogarias). Como eu poderia efetuar essa impressão? Me desculpem se a resposta possa ser óbvia, mas faço o uso bem básico do ACBrMonitorPLUS e estou meio perdido nisso... Quem puder ajudar agradeço.

Blz, logo logo algum moderador deve disponibilizar no repositório do ACBr e assim fica mais fácil para a comunidade.

Consegui baixar hoje. Vi que ainda não está no repositório. Não consigo anexar aqui, é limitado em 2mb e todos .csv zipado fica com pouco mais de 5mb.

Passando para avisar que tentei baixar o arquivo hoje do site ( https://deolhonoimposto.ibpt.org.br/ ) e voltou a funcionar.

Boa tarde pessoal, Vi que no site do IBPT ( https://deolhonoimposto.ibpt.org.br/ ) indicaram a liberação do novo arquivo 23.1.E, mas ao tentar baixar fica processando e não libera o link para download desde de manhã. Já mandeu mensagem no contato deles, mas é perda de tempo, eles nunca respondem. Só gostaria de saber se algum colega do fórum teve mais sorte que eu e tenha conseguido baixar os arquivos .csv. Caso alguém tenha conseguido, por favor, repasse no fórum para que algum moderador possa disponibilizar no repositório ( ...\Exemplos\ACBrTCP\ACBrIBPTax\tabela ) para todos, pois vi que ainda é o anterior (23.1.D) que está lá.