Ivan Orosco

Kimba, estou com o mesmo problema, você não chegou a detalhar como resolveu e o que era exatamente, poderia nos dizer ? Detalhe, eu uso o ACBRNFe e tenho a mesma aplicação sendo executada por outros clientes e funcionando normalmente, apena em um cliente está ocorrendo o erro: [nro da nota]->Rejeicao: Duplicidade de NF-e, com diferença na Chave de Acesso [chNFe:][nRec:] Independente do nro da nota que eu coloque ocorre o mesmo erro, já verifiquei o XML e a tag <nNF> esta sendo enviada corretamente, detalhe que o sistema gera a chave normalmente e quando tenta transmitir a sefaz devolve uma chave diferente, exemplo, gerou a chave 35131038874095000145550010000000091000000091 e quando ocorre o erro, a critica devolveu a chave 35110638874095000145550010000000091800007096 Alguma idéia ? []'s

Opa, consegui aqui... o cfop naturalmente no produto como ja estava fazendo e identificar o Ide.indPag como ipOutras para nao exibir o campo de faturas na danfe. Valeu pela ajuda

Desculpe a ignorância, pois creio que a resposta esteja na minha frente mas não consigo identificar, então eu pergunto... como configuro no componente ? CFOP é só na tag do produto ou tem alguma propriedade pra ele na nota? Estou utilizando a danfe pelo Rave (que está no exemplo do acbrnfe), o layout da nota de devolução é o mesmo ? não precisa retirar nada ou utilizar um outro relatório ? ou configurando o cfop correto o bloco de duplicatas fica desabilitado ?

Boa tarde, Já estou utilizando o componente ACBRNFe e gerando notas de vendas corretamente, mas agora um cliente informou da necessidade de gerar NFe para envio de mercadoria para Conserto, Troca ou Devolução. Nos exemplos do componente não tem nada do tipo, também pesquisei no Fórum mas não encontrei nada muito relevante e pesquisando na internet vi que o layout da Danfe muda um pouco (como a área de duplicatas que não é impresso), como devo tratar essa situação pelo ACBRNFe ? Tem algum exemplo ? []'s

Pessoal, temos essa classe em andamento de alguma forma ? []'s

Daniel, fiz um sync do projeto e notei que as alterações que enviei após a minha homologação do Vespague com o Premia ainda não foram comitadas (estão em anexo no meu ultimo post), gostaria de saber se não serão incluídas no projeto, pois temo que tais alterações sejam perdidas e minha aplicação pare de funcionar. []'s

re-HOMOLOGADO !!! Uffa, finalmente... Daniel, não sei como os colaboradores que utilizam Vespague conseguiram homologar anteriormente, pois tive que fazer ajustes no componente. Ficou pendente a questão do troco que não sei como poderemos resolver já que pra poder homologar eu tive que alterar a unit ABCRTEFD.pas e somar o saque, do resto, foram ajustes necessários mesmo que o componente estava fazendo operação errada. Estou anexando os arquivos que alterei e peço que faça o merge como versão de produção do ACBR. Muito obrigado pela ajuda, minha contribuição está a caminho []'s ACBrTEFDVeSPague.pas ACBrTEFD.pas

No teste de CNC, após imprimir o comprovante de cancelamento, o ACBR manda executar um CNF, tive que criar um flag para que no procedimento de CNF do Vespague nao envie novamente a CNF após imprimir o comprovande de cancelamento do CNC, pois o CNF eh enviado antes da impressao.

O Vespague funciona bem tb, ele roda através de conexao com internet simples (speedy, adsl...), os custos são bastante atrativos também.

Testes críticos e CIELO PREMIA testados... agora testes mais simples...

Estou homologando hoje minha aplicação com o Vespague, no ACBRTEFDVespague.pas, na tag transacao_valor_ajuste, deve ser enviado o valor 01 e não 00 como está originalmente no código, senão a Cielo entende que a AC não está preparada para o PREMIA. Ficou assim: //---Adicionando o parametro CIELO PREMIA-------------- ReqVS.AddParamDouble( 'transacao_valor_ajuste', 01) ; //-----------------------------------------------------

Daniel... não teve jeito... tentei de várias maneiras aqui, depurei, testei, o tratamento padrão que existe no vespague para transações pendentes ao iniciar o componente não funciona direito, o vespague da um erro la de pacote recebido com problemas e quebra o fluxo conforme relatei na mensagem anterior (tanto no meu, quanto no ambiente de teste do Vespague do Moises). A única coisa que resolveu foi utilizar um procedimento que já utilizei da outra vez que homologuei que comentei no inicio desse post, a procedure VerificarTransacoesPendentesClass, para tratar os cancelamentos de transações pendentes na inicialização, ela tem o mesmo propósito da atual CancelarTransacoesPendentesClass (do ACBrTEFDClass) onde chama o NCN, mas devido ao fluxo de tratamento da requisição NCN o Vespague gera um erro no meio do processo e cai em uma exceção, enquanto que a procedure nova trata diretamente as pendencias inclusive sem o botão de Confirmar do Vespague ativo (solicitação do Moises), acho que eh por isso que passa... De qualquer forma estou anexando a minha unit ACBrTEFDVesPague.pas para analise. Detalhe, ainda não consegui resolver a questão do troco. Por enquanto estou somando o Saque no TACBrTEFD.AgruparRespostasPendentes, e mesmo alimentando a propriedade fpDesconto (criado para isso) no momento que recebo o valor já com o desconto do Premia, o troco ainda não sai para operações de debito com saque []'s ACBrTEFDVeSPague.pas ACBrTEFD.pas

Pessoal... nosso amigo Moises achou outro bug no componente... Situação: - Venda com dois cartoes, passa-se os dois e desliga a impressão no cupom fiscal - finalizar a aplicação e o Vespague - ligar a impressora, ativar o vespague e depois que ele subir entrar na aplicação - o compomente vai identificar transações pendentes e vai pedir login e senha e ficar nesse loop ate informar login e senha corretos - apos informar login e senha corretos, confirmar uma operação - o compomente vai identificar transações pendentes e vai pedir login e senha novamente, informe uma senha invalida ou cancele - Bum ! a aplicação mostra a mensagem "Cancelado pelo usuario" e acessa a aplicação quando deveria ficar em loop pelo login e senha corretos To depurando, mas não acho o ponto onde tratar isso... Alguma idéia ?

Olha, nos meus testes aqui teve essa situação e deu certo, porque se vc subtotaliza passando o desconto e depois efetua o pagamento com saque somado, logicamente o valor total sera pago gerando o troco esperado. o Saque fica armazenado na propriedade Saque da Resposta, apenas o desconto é aplicado sobre o valor da transação. Esta é a descrição do 2o. teste do Premia, segue: 2º SITUAÇÃO DE TESTE - Cielo Premia com 1 CARTÃO [OBJETIVO]: Realizar uma venda com Cielo Premia e validar se os cupons CF e CCD estão sendo impresso corretamente. [PROCEDIMENTO]: Realizar uma venda de DÉBITO Á VISTA no valor de R$ 9.000,10 + 10,00 de SAQUE. [RESULTADO ESPERADO]: A automação deve ler o retorno de desconto e inseri-lo no CF antes de totalizar a venda e incrementar o valor do saque na forma de pagamento sem abater do valor total da venda e contabilizando o valor do saque como troco. O CCD deve ser impresso conforme o retorno da DLL. O resultado foi o cupom fiscal com um item no valor de R$ 9.000,10, subotalizado com R$ 5,00 de desconto dando um total de R$ 8.995,10 e a informação de pagamento aparece como C. DEBITO R$ 9.005,10 e TROCO R$ 10,00. Ou seja, o cupom fiscal ficou assim: CUPOM FISCAL ------------------------------------------------ 001 001 teste 1,000pc x 9.000,10 9.000,10 ------------ SubtotaL 9.000,10 Desconto 5,00 ------------------------------------------------ TOTAL 8.995,10 C. DEBITO 9.005,10 TROCO 10,00 O comprovante do TEF aparece as mesmas informações: VENDA A DEBITO VALOR: 8.995,10 SAQUE: 10,00 FINAL: 9.005,10 Creio que está correto.

Daniel, perguntei pro pessoal da VBI, o que me disseram: [17] Ivan Maldonado Orosco: tem um campo aqui do Premia chamado transacao_valor_ajuste, ele está vindo sempre zerado [17] Ivan Maldonado Orosco: e o componente espera que ele venha com o valor do desconto do cielo premia [17] Ivan Maldonado Orosco: eh assim mesmo ou tem que ajustar algo ? [17] VBI Suporte Cliente: é assim mesmo, pq ele serve apenas para sinalizar que automação está preparada para tal procedimento. O desconto vem na tag transação_valor. De fato, eu depurando o pacote, no transacao_valor_ajuste vem zerado mesmo, creio que o tratamento mais seguro então seria fazer como estou fazendo, baseado no valor que o vespague devolve no campo transacao_valor. Daniel, você acha que se este campo vier preenchido o Saque (troco) funciona na função débito ? Pois como eu disse mesmo eu informando la no evento OnComandaECFSubtotaliza o valor do desconto, o troco ainda não sai. []'s

Daniel, a propriedade Desconto fica zerada, ela não carrega com valor nenhum, mesmo depurando após o retorno do vespague, ele fica zerado, mas resolvi de outra forma, em vez de criar uma propriedade nova eu utilizei o próprio valor retornado do componente ACBrTEFD1.Resp.ValorTotal e subtraio do valor enviado. Eu programei o evento OnComandaECFSubtotaliza (novamente) e depurei a execução dele, o parâmetro DescAcre vem zerado, então, acredito que devo alimentá-lo, dai criei uma variável global aqui na minha tela pra ir somando os descontos do premia e no evento eu passo ele pro DescAcre, no entanto, continua sem somar o valor de Saque para gerar Troco. Codifiquei ele da seguinte forma: try Est := ACBrECF1.Estado; DescAcre:=(vl_desc_premia*-1); if Est = estNaoFiscal then ACBrECF1.SubtotalizaNaoFiscal( DescAcre, 'Projeto ACBr|http://acbr.sf.net' ) else ACBrECF1.SubtotalizaCupom( DescAcre, 'Projeto ACBr|http://acbr.sf.net' ); RetornoECF := 1 ; except RetornoECF := 0 ; end; Por enquanto estou resolvendo o meu problema do troco alterando o TACBrTEFD.AgruparRespostasPendentes fazendo Grupo[J].Total := Grupo[J].Total + RespostasPendentes.ValorTotal + RespostasPendentes.Saque; Sei que eh uma classe que se for alterada irá afetar todo mundo, mas devido a necessidade e urgência é a solução que estou usando no momento, estou em busca de uma alternativa mais correta.

Então Daniel, eu implementei este evento (de acordo com o Demo), mas não funcionou não, nem veio o desconto do premia no parâmetro DescAcre e nem gerou Troco quando testei a função Débito, por isso criei uma property chamada ValorPremia na classe do Vespague que dai no CRT dele eu carrego o valor retornado pelo Premia, dai no fluxo da minha aplicação (após chamar o crt) eu vou somando os descontos (valor passado ao CRT-ValorPremia) e depois subtotalizo passando a soma de desconto, dai deu certo... Agora meu problema é o Troco, estou vendo se tem algo a ser feito na classe do vespague pra somar o troco ao valor pago, mas to com dificuldade pra achar onde fazer isso pois pelo o que eu to vendo parece que ele monta a resposta do Vespague dentro ACBrTEFDClass (onde eu não quero mecher), ou então teria que mecher no ACBrTEFD no FinalizarCupom (obviamente não é aqui também) no trecho ECFPagamento( GrupoFPG.IndiceFPG_ECF, GrupoFPG.Total ) onde teria q fazer entrar o Saque somado ai com esse Total alterando a procedure AgruparRespostasPendentes fazendo: Grupo[J].Total := Grupo[J].Total + RespostasPendentes.ValorTotal + RespostasPendentes.Saque; Mas sei que não é, enfim... to perdido... []'s

Qual seria o evento ? conseguirei acessar a propriedade Saque do ACBrTEFD através desse evento ? Detalhe, trata-se de finalização de pagamentos pendentes, ou seja, devido ao premia, tenho que fazer as operações de tef e deixar para subtotalizar apenas depois que as operações de tef ja estiverem todas aprovadas, dai eu subtotalizo e imprimo todas os pagamentos tef pendentes, inclusive somados com o saque, mas não vejo nenhum evento pra isso o mais próximo seria o ComandaECFPagamento, seria nele que teria que somar o saque ? e como fazer para acessar a propriedade Saque dos pagamentos pendentes do ACBrTEFD ? []'s

Sim, anexarei os arquivos quando terminar os testes. Agora deparei com uma outra situação, Cielo Premia, criei uma propriedade na classe do Vespague chamada ValorPremia que me retorna o valor com o desconto decorrente do Premia. Blz, alterei a subtotalização do cupom no meu fluxo e consegui tratar e desconto do premia certinho. Agora, o que reparei é que o Saque não funciona (que foi o próximo teste do Premia), ou seja, faço qualquer operação com cartão de débito e informo um valor de saque e não vai, depurando vi que a field fSaque é alimentada corretamente, mas ele não imprime o "Troco" no cupom fiscal. Quando passa pela procedure FinalizarCupom do ACBrTEFD, tem o trecho: if InfoECFAsDouble(ineSubTotal) > 0 then ECFPagamento( GrupoFPG[I].IndiceFPG_ECF, GrupoFPG[I].Total ); Depurando, eu vi que ele está mandando o valor do pagamento sem a soma do troco, ou seja, em uma simulação de cartão de débito de 100,00 onde se informa um troco de 10,00, neste ponto, acredito que o campo GrupoFPG.Total deveria estar com o valor de 110,00 para que a ECF devolva os 10,00 de troco, mas ele está com o valor de 100,00. De forma que após passar por ai ele efetua o pagamento do TEF no valor de 100,00 em seguida ele manda um FechaCupom e finaliza a impressão Já atualizei meu ACBR aqui, limpei as DCU e fiz um Build e ta do mesmo jeito... será que estou esquecendo de algo ? []'s

Daniel, tenho algumas alterações que tive que fazer no componente para adequar ao roteiro, segue: na procedure TACBrTEFDVeSPague.Inicializartive que alterar o seguinte: // Cupom Ficou aberto ?? Se SIM, Cancele tudo... // if (Est in ['V','P','N','O','L']) then begin { Achando Arquivos de Backup deste GP } ArqMask := TACBrTEFD(Owner).PathBackup + PathDelim + 'ACBr_' + Self.Name + '_*.tef' ; if FilesExists( ArqMask ) then begin TACBrTEFD(Owner).DoExibeMsg( opmOK, 'Há pelo menos uma transação PENDENTE.'+sLineBreak+ 'Favor realizar o DESFAZIMENTO no menu Administrativo -> pedende.'+sLineBreak+ 'Cancelar o cupom fiscal !' ) ; CancelarTransacoesPendentesClass; end else if Est='L' then ConfirmarESolicitarImpressaoTransacoesPendentes; end else // NAO, Cupom Fechado, Pode confirmar e Mandar aviso para re-imprimir // ConfirmarESolicitarImpressaoTransacoesPendentes ; Pois tinha situação em que a impressora estava Livre mas ainda assim existiam pendencias para serem canceladas. E na procedure TACBrTEFD.CancelarTransacoesPendentes, tive que alterar o trecho: if Assigned( fOnDepoisCancelarTransacoes ) then begin BloquearMouseTeclado( false ); fOnDepoisCancelarTransacoes( RespostasPendentes ); end; Para que no evento de DepoisCancelarTransacoes do ACBRTEFD apresentasse mensagem e permitisse que o usuario intereagisse (pode ser que haja uma maneira mais correta, mas sabe como é né, a urgência pede improviso ) Enviei novamente para os testes do Moises, creio que agora está tudo certo, qualquer novidade eu posto aqui.

Rapaiz... vc ta ligeiro hein, acho que é isso mesmo, vou manda la pro moises continuar os testes. Valeu Daniel !

Grande Daniel, então, as implementações que eu utilizei quando homologuei ano passado foram essas: viewtopic.php?f=16&t=248&start=20 Quanto ao roteiro, quem está fazendo a homologação pra mim é o Moises la da Cemay (parcerão), o roteiro oficial mesmo eu não tenho, mas tenho aqui o que o Moises utiliza para validar a aplicação antes da homologação onde ele separa quais são os principais testes usados para o Vespague, a situação que coloquei é especificamente o item 1.2.1.1 (6a. linha) do arquivo Teste_PreCertificação_Cielo_Vespague.xls. Dentro desse zip também coloquei o arquivo que o Moises disse que o pessoal da homologação costuma usar, é o Teste de Desligamento_Rev06_Sitef.xls. Ele falou que é muito dinâmico que pode ter testes que executam a mais ou a menos durante a homologação. []'s Roteiros.zip

Salve Lista... (ou melhor... lista, me salve!) Pra quem trabalha com Vespague já deve saber que agora é obrigatório a re-homologação anual do mesmo, ano passado quando homologuei eu utilizei alguns métodos que vi que foram retirados do componente, obviamente porque foi encontrada soluções mais simples para a resolução do problema. No entanto, navegando aqui na lista, não consegui encontrar nada que me ajudasse a adaptar a minha aplicação as alterações sofridas no ACBrTEFDVeSPague. O meu problema é justamente com um método que eu estava usando chamado VerificarTransacoesPendentesClass que foi removido, o que acontece é que tem uma exigência no roteiro que diz o seguinte: Teste simulando queda de energia, não está apresentando a mensagem: “Há pelo menos uma transação PENDENTE. Favor realizar o DESFAZIMENTO no menu administrativo-> pedende. Cancelar o cupom fiscal ! ” - ao confirmar essa mesagem a automação deve abrir o menu ADM - transações pedentes, para DESFAZER a transação. Hoje quando o componente é instanciado ele verifica as transações pendentes e já abre a tela do admin do vespague para o usuário processar já as pendencias, ou seja, ele pula o passo de avisar o usuario das pendencias. Gostaria de saber dos colegas que desenvolvem em Delphi como estão tratando desta exigencia na homologação e se seria o caso de apenas colocar no componente a exibição da mensagem que existem pendencias e que o Administrativo será aberto em seguida. []'s

Augusto, estou na mesma situação, como você resolveu ?

Elton, muito obrigado pelas respostas, ajudou bastante, Regys, o vídeo que me indicou mostra que não sou obrigado a utilizar DAV ou Pré-venda em meu sistema (por isso que eu estava encafifado, pois meus clientes não utilizam isso). A propósito, sobre a questão de estoque no PAF é que eu queria saber se tem algum relatório específico no paf que faça listagem de posição de estoque ou algo do gênero. Valeu pela ajuda pessoal, já deu pra ter uma idéia do que tenho q fazer, detalhe, achei bastante documentação também no site de desenvolvedores da daruma (http://www.desenvolvedoresdaruma.com.br ... os/PAF.ZIP), artigos, apresentações, vídeos, bastante coisa útil pra novatos, estou lendo bastante, mas creio que não farei mais perguntas tão básicas. Valeu pessoal. []'s