_asseinfo

Bom dia Ítalo, Já posso transmitir no ambiente de produção na versão 1.04? Obrigado!

Obrigado juliomar! []s

Legal Ítalo, haviam outros ACBR.inc aqui na minha cópia de trabalho. Apaguei todas. Tudo OK. Você sabe quando a versão PL_104 passará a ser padrão no ACBRCT-e? Obrigado!

Bom dia Ítalo, Resolvi o problema adicionando as diretivas PL_103 e PL_104 em todos os arquivos ACBR.inc. Mas continuo sem entender a solução. Você sabe por que existem vários arquivos ACBR.inc? Como sei qual arquivo ACBR.inc o Delphi 7 vai usar para instalar os componentes? Teria como centralizar em somente um? Muito obrigado! Marcos

Olá Ítalo, estou com o problema que o Rogériomg citou. Realizei os passos que ele apontou para resolver mas não tive sucesso. Achei estranho esse trecho de código (diretivas comentadas): [51] unit pcteCTe; [3679] // {$IFDEF PL_103} [3680] FvalePed.Free; [3681] // {$ENDIF} E o erro acontece justamente na linha 3680. Agradeço desde já pela atenção! Marcos.

Olá pessoal, com relação a "Rejeicao: A data do evento nao pode ser maior que a data do processamento" descobri o erro. Vejam o trecho retirado do manual e integração da CC-e: "dhEvento -> Data e hora do evento no formato AAAA-MMDDThh:mm:ssTZD (UTC - Universal Coordinated Time, onde TZD pode ser -02:00 (Fernando de Noronha), -03:00 (Brasília) ou -04:00 (Manaus), no horário de verão serão -01:00, -02:00 e -03:00. Ex.: 2010-08-19T13:00:15-03:00." O problema é que estamos enviando a UTC de horário normal e não o de horário de verão, por exemplo de Brasilia (-03:00), mas por estarmos no horário de verão veríamos enviar (-02:00). Mandamos isso: 2011-10-27T13:00:15-03:00 Mas deveríamos mandar isso: 2011-10-27T13:00:15-02:00 Acredito que o ideal é ter uma função de retorne o UTC de acordo com o horário de verão (para regiões que esse horário é adotado). Se o caminho escolhido for esse, posso me comprometer a desenvolver tal função. Um abraço Ronaldo

Vocês estão usando ACBrTEFD?! Então passem mais detalhes, qual o GP, modo de operação...

Pessoal, na verdade já encontrei o problema e não tinha a ver com a DLL. Mas sim, por que haviam códigos que não estavam compilando e no caso, removi a implementação de alguns métodos e isso acabou causando o problema. Desculpem, a pressa em postar um erro que merecia um pouco mais de atenção! --- O erro que estou encontrando agora é o seguinte: Ao efetuar um pagamento com Cartão, o GP está respondendo com a mensagem de erro "VALOR INVALIDO". Ao compilar o componente para realizar a instalação tive que alterar o tipo de uma variável de PAnsiChar para PWideChar e por conta de uma chamada a DLL. Por favor, alguém que está usando ou tem a intenção de usar o TEFD, se poder me ajudar? Obrigado! --- Já descobri o problema... esse erro acontece quando estou no Delphi XE, no delphi 7 não acontece o problema!! Pode ser problema com os tipos de dados.

Olá, Usando ACBr TEF juntamente com o GP da Direção... Estou tentando realizar os testes com a implementação (Modificação) realizada pelo MarcioDC, mas estou com alguns probleminhas... Ai iniciar o DEMO, eu Ativo o ECF (Daruma FS600) e depois inicializo o "gpCliDTEF" e depois na aba de "Operações" obtenho os erros: Log de saída no DEMO: ---------------------- Ativar ECF Inicializando: gpCliDTEF ACBrTEFD.Inicializar Executado Inicio de ATV Cannot create file "". O sistema não pode encontrar o caminho especificado Inicio de ADM Access violation at address 00000000. Read of address 00000000 --- Como se pode ver no LOG, ao clicar no botão "ATV" ocorre um "Cannot create..."; Ao clicar no ADM ocorre um "Access violation..." Alguém poderia me dar uma luz? A DLL DPOSDRV foi copiada da pasta "C:\DPOS8\Bin" e colocada junto com o executável mas não resolveu. Então foi movida para Windows\System32, não resolveu, então tentei registrar a mesma com o regsvr32 e não registra retornando um erro. Obrigado!

Entendido pessoal, obrigado! Eu esbarrei nesta situação pois estou realizando testes com o GP da Direção, a qual tem uma nova parceira com a Daruma para disponibilizar um TEF Dedicado. Esse GP usa a mesma forma de comunicação que o discado. Enfim, para multiplos cartões o funcionamento está apresentando essa diferença (transação com cartão confirmada de uma em uma). Daniel que é o criador, o que você acha de uma modificação (paralela) para fazer com que essa operação seja possível? Ou seja, no momento de trabalhar com multiplos cartões, o sistema ir acumulando as transações com cartões e confirmar somente no último cartão tudo de uma vez só? Obrigado!

Olá Daniel, Considerando um testes de venda e pagamento com dois cartões, quando falta energia durante a impressão do primeiro vinculado. Por que não são realizados dois "Desfazimentos" referentes aos dois cartões, quando o software volta a funcionar? Hoje está acontecendo um desfazimento e depois um cancelamento (requer que o usuário informe alguns dados). Obrigado!

Olá layme, Se o meu problema não for o mesmo que o seu, é muito parecido! Meu problema consiste em: Ao executar o seguinte teste no TEFDemo.exe (sem alterações no código-fonte da minha parte) que acompanha o ACBr: - ECF Daruma FS600, GPDireção e Multi cartões; - Inicia-se um cupom e realiza-se o pagamento do mesmo com dois cartões de crédito; - Quando a impressão do primeiro CCD-Comprovante de Crédito ou Débito estiver sendo realizada, desligue a impressora; - O sistema de automação (TEFDemo) vai detectar a falta da impressora e vai perguntar se deseja continuar, responda NÃO; - Ocorrerá o "Desfazimento" da última operação de pagamento (último cartão); - E então acontece o PROBLEMA, aparece uma tela com o título "Transação de Cancelamento de Pagamento" solicitando alguns dados creio eu, para Cancelamento da primeira operação de pagamento (primeiro cartão). Esse cancelamento poderá ser realizado ligando-se a impressora e ai fica tudo certo, mas acho que o passo a seguir diz melhor como deveria acontecer; - Realizando esse mesmo teste juntamento com o suporte a desenvolvedores da Daruma no simulador deles, o problema não acontece. O que acontece na verdade, são dois "Desfazimentos" referentes aos dois pagamentos efetuados com os cartões. Julgo eu ser o correto; Se alguém poder esclarecer melhor a situação e nos ajudar seria muito legal. Obrigado!

Olá pessoal, Ao invocar o método "ACBrECF1.TotalAcrescimosISSQN" ou o método "ACBrECF1.TotalDescontosISSQN" para o ECF Elgin ZPM 1 Fit Logger (versão do Firmware 03.03.00) ocorre o seguinte erro: ----------------------------------- Erro retornado pela Impressora: FiscNET: ZPM - ZPM/1FIT LOGGER Erro: 11011 - ErroProtNomeRegistrador Parametro NomeDadoMonetario contem nome de registrador inexistente. ---------------------------- Alguém já enfrentou esse problema? Muito obrigado.

Olá pessoal, bom dia! Ao invocar o método ReducaoZ temos a opção de enviar a data/hora para ajuste do ECF, certo? Particularmente não gosto de enviar o ajuste de hora, mas percebi que mesmo não enviando, nas impressoras Daruma o ajuste estava sendo feito. Fui então até a classe TACBrECFDaruma e vi que quando não é informado a data/hora, o algoritmo pega a data/hora do computador (é utilizada a função now). Vejam o trecho abaixo: ... Procedure TACBrECFDaruma.ReducaoZ(DataHora: TDateTime) ; begin if DataHora = 0 then { Aparentemente a DataHora é obrigatória na Daruma } DataHora := now; ... Gostaria de propor uma alteração. O que vocês acham de nessa situação, pegar a propria data/hora do ECF? Dessa maneira não teríamos ajuste de data/hora, conforme a vontade de quem invocou o método. Segue minha sugestão: ... Procedure TACBrECFDaruma.ReducaoZ(DataHora: TDateTime) ; begin if DataHora = 0 then { Aparentemente a DataHora é obrigatória na Daruma } DataHora := GetDataHora; ... Um abraço.