Jump to content

logo_acbr_paygo.png

Chegou o TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


botao_saibamais.png

beneficios.png

Curso Dominando o ACBrMonitor
Novo Módulo Soluções de Varejo
Assine o SAC ACBr em qualquer plano e tenha acesso

Saiba Mais

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba Mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

Aurino

Membros
  • Content Count

    151
  • Joined

  • Last visited

Community Reputation

25 Excellent

1 Follower

About Aurino

  • Rank
    Membro
  • Birthday 05/04/1986

Profile Information

  • Sexo
    Masculino
  • Localização
    Sao luis/Ma
  • Interesses
    Automação Comercial

Recent Profile Visitors

1,673 profile views
  1. Aurino

    Inovatechi Sistemas

    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
  2. 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.
  3. 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 );
  4. 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.
  5. 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.
  6. 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
  7. Inverti aqui ao passar pra ka. rsrs TEF: begin tpIntegra := tiPagIntegrado; end; POS: begin tpIntegra := tiPagNaoIntegrado; end;
  8. era problemas da sefaz, ref, o sincronismo entre as sefaz estaduais e nacional.
  9. 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;
  10. fiz um conversor entre as bases, ai não fico preso a programa de terceiros para migrar.
  11. Bom Dia Implementei no InfCpl do XML mas ja estou avaliando o componente para ver consigo fazer direto pelo componente.. se conseguir, mando pra analise do pessoal.
  12. Segue a tabela ANP ref. a NT 2012.003d. TabelaANP_ref._NT2012.003d_pub.sql
  13. O que pode fazer é imprimir as formas de pagamento da nfe nas observações da nota fiscal
  14. o que pode implementar é adicionar nas observações da nota fiscal capturando a tag indPag dentro da tag Pag. Outra ideia é implementar o detalhamento das formas de pagamento da NFe nas observações da nota fiscal eletrônica como exemplo abaixo:
×
×
  • Create New...