Aurino

Boa noite, irei atualizar e testar. reportarei o resultado. obrigado.

Esta como citado.. Pagamento Instantâneo (PIX) porém ficar com erro de impressão no danfe.... como mostrado na imagem.

Bom dia NFe com PIX no FortesReport esta cortando/cobrindo o valor pago na forma de pagamento. Para corrigir temporariamente, tive que alterar na unit pcnConversao o texto Pagamento Instantâneo (PIX) para PIX conforme mostrado abaixo. Há algum ajuste no danfe FortesReport para não sair cortado ou fica a minha sugestão de refatoração do texto da descrição da forma de pagamento referente ao PIX.

Boa noite. NFe com PIX no FortesReport esta cortando/Cobrindo o valor pago na forma de pagamento. Para corrigir temporariamente, tive que alterar na unit pcnConversao o texto Pagamento Instantâneo (PIX) para PIX conforme mostrado abaixo. Há algum ajuste no danfe FortesReport para não sair cortado ou fica a minha sugestão de refatoração do texto da descrição da forma de pagamento referente ao PIX.

The company Inovatechi Sistemas has been operating in the Commercial Automation market for over 10 years. Founded on February 9, 2010, we offer solutions and services in software and equipment for commercial automation. A Empresa Inovatechi Sistemas atua no mercado de Automação Comercial há mais de 10 anos. Fundada em 09 de Fevereiro de 2010, oferecemos soluções e serviços em softwares e equipamentos para automação comercial

Pelo que entendi... a rotina cancelartransacaopendentes, mas já foi confirmada nao estando mais pendente correto? nesse caso, chamando a função que passei acima, fará o processo de cancelamento chamando a tela do GP para informar os dados da transação visto que já foi confirmada assim como pode consultar no portal de vendas. ref. o controle ser usado para cancelar pelo GP, apesar de existir o NSU mas pegando o controle (CTR) seja na impressão do comprovante apos a finalização da venda, ou durante a venda, pegando direto do processo apos aprovação do cartao, poderá implementar a leitura desse CTR direto no arquivo antes da chamada do GP ou fazer com que o operador possa informar o CTR manualmente via orientação da sua aplicação... segue a imagem que salvo no banco de dados os dados de cada transação seja durante a venda ou apos finalização da venda.

verifica a função do ACBrTEF pois não temos problemas com o TEF GetCard, que esta operacional normalmente. ACBrTEFD1.CNC(vRede, vNSU, vDataHoraTransacao, vValorTransacao );

Exato.. A partir o primeiro erro de falta de retorno da sefaz por exemplo ou falha de conexão de internet, já procede para alteração automatica para emissão em contingencia, e assim emitindo normalmente em sequencial das numerações e em contingencia offline. O manual trata apenas para caso de envio e sem retorno do status da nota, fazendo assim a necessidade de liberar a venda do cliente com uma numeração seguinte para evitar que gere a mesma numeração desta que deu falha de retorno e ao transmitir a sefaz esta mesma nota, obter o retorno de duplicidade de chave de acesso com diferenca ... assim tendo a nota normal recebida na sefaz, porem o cliente possui uma nota em contingencia que nunca será autorizada na sefaz visto que o tipo de emissão é diferente daquele registrado e recebido na sefaz. Precisa tratar automaticamente a emissão da contingencia, seja manual ou por usuário a partir do primeiro caso de falha de retorno da sefaz ou falta de internet.

no seu exemplo, emitindo 10 notas em contigencias devido ausencia de internet, logo vc nao esta enviando as notas ,e sim apenas gerando em contingencia. nao precisará gerar outras nota substitutiva para esse caso. A regra do manual da contingencia é para aquele caso que vc envia a nota no modo NORMAL, a sefaz recebe esta nota e por qualquer motivo que seja, seu sistema nao obtem o retorno. Nesse momento, vc deve seguir o manual que diz: gerar uma nova nfce com numero sequencial em contingencia .. ao enviar esta contingencia posteriormente, fará a consulta da chave de acesso da primeira nota que nao teve retorno da sefaz, e tratar o retorno e evento posterior para o caso. 1 - Quase todas notas caem em contigencia: Qual motivo para emissão? falha de internet ou retorno da sefaz? Se for este o problema, a primeira nfce que apresentou esse problema será gerada uma nfce seguinte com os mesmos dados desta nota, guardando a nota anterior para posterior consulta e tratamento de consulta para cancelar, inutilizar ou emissao de nfe de devolucao de venda. A partir desta nota que obter essa falha e gerando assim a contingencia, no fim da impressão, já providencia a alteração automatica do modo de envio para contingencia manual. E assim, as proximas notas , serão emitidas em contingencias offline , podendo reativar o modo normal a seu critério, entre tempo no time, ou manualmente pelo usuário; Mas se esta gerando contingencias por diversas falhas, precisa verificar que falhas e resolver cada falha e transmitir essas contingencias, visto que o cliente final, tem posse deste documento em contigencia para posterior consulta.

na NT da contingencia nesses casos, para tratar a numeração e não perder o controle ou liberar nota inexistente ao cliente , segue o exemplo basico que o manual da contingencia orienta: 1 - enviou a nfce 100 , sefaz recebeu mas nao teve retorno(falta de internet ou sefaz); 2- gera a nfce 101 em contingencia ref. a 100 que ficou sem confirmação; 3 - ao transmitir a 101 a sefaz autorizando a mesma, fará a consulta da chave da nfce 100 para obter o retorno da situação e tratar da seguinte forma: a - se estiver autorizada dentro do prazo, realiza o cancelamento; b - se nao estiver autorizada, inutiliza a numeração; c - se estiver autorizada fora do prazo, emissao da nfe de devolucao de venda; *isso sem fazer o controle de serie exclusiva da contingencia, por isso , a numeraçao sequencial da nota continua na sequencia. Manual_de_especificacoes_tecnicas_da_Contingencia_Off-line_versao_2.0.pdf

Inverti aqui ao passar pra ka. rsrs TEF: begin tpIntegra := tiPagIntegrado; end; POS: begin tpIntegra := tiPagNaoIntegrado; end;

era problemas da sefaz, ref, o sincronismo entre as sefaz estaduais e nacional.

Boa Tarde Pessoal e Graca, desculpe pela demora... Acabei esquecendo de repassar aqui. Verifiquei e relataram que para venda POS, deverá ser informado tiPagNaoIntegrado, e para TEF, tiPagIntegrado. Atualmente estou tratando conforme o tipo de transação e não tivemos problemas ref. as validações e emissões da notas fiscais, e tbm, sem problemas fiscais com relação aos cupons emitidos com venda POS ou TEF; Estou tratando assim, basicamente: Case TipoMeioPagamento of TEF: begin tpIntegra := tiPagNaoIntegrado; end; POS: begin tpIntegra := tiPagIntegrado; end; end; //Passandos os dados mesmo para transação POS, para controle dos comprovantes vinculados ao documento emitido; tPag := TipoTransacao; // ex: fpCartaoCredito; Tipo da Transação do cartao, se credito ou débito; vPag := ValorCredito; // ex 10.00; Valor pago na transação; tBand := BandeiraCartao; // ex: bcVisa; Bandeira selecionada pelo usuario; cAut := NSU; // ex: 102030; codigo do comprovante informado pelo usuario; CNPJ := CnpjOperadora; // ex: 11111111111111; CNPJ vinculado a tabela ref. a bandeira selecionada;

fiz um conversor entre as bases, ai não fico preso a programa de terceiros para migrar.

Gera a nfe de devolução com a tag = Outros.