tdpsistemas

Boa tarde, Desculpe faltou uma informação.: 1) Com ANP fora dos códigos especificados consegui emitir normal como pode ver os xmls em anexo. 2) Após a alteração sugerida, consegui gerar a nota com grupo de ICMSST. Mas mesmo assim foi recusada com erro: "Grupo de Tributação informado indevidamente [nItem: 1]". Conforme poderá ver nos xmls em anexos. Não sei o que mais pode estar errado. Agradeço desde já pela ajuda. Autorizado_CST040.xml Autorizado_CST060.xml Recusada_ANP210203001_2.xml Recusada_ANP320102001_1.xml

Boa tarde a todos, Também estou passando pelos problemas documentados acima. @Wanderson Paiva pelo que entendi você fez uma adequação no fonte do componente, para forçar a geração do grupo de repasse OK. Pois aqui só consigo fazer a geração do grupo quando informo valores em alguns dos campos abaixo: vBCSTDest, vICMSSTRet, vBCSTDest e vICMSSTDes. E mesmo preenchendo não consegui fazer a emissão. E como pude ver ainda não tiveram retorno a respeito do erro "Somatorio percentuais de GLP derivado do petroleo, GLGNn e GLGNi diferente de 1 [nItem:1]" Também estou com esse erro. Agradeço desde já pela atenção.

Ok Claudemir, vou fazer conforme o Daniel orientou no Post do By by Capicom. Vou acertar o ACBr.inc, para compilar sem CAPICOM. É que em nosso projeto iriamos manter o CAPICOM para 3.10 e WinCrypt para 4.00. Tento alguma resposta eu aviso aqui. Obrigado pela atenção.!!!

Claudemir primeiramente obrigado pelo Retorno. Essa configurações do IE, também se aplica para o LibWinCrypt? (Sem CAPICOM)? Pois pelas orientações aqui do fórum quando atribuímos: "libWinCrypt", não há necessidade de configuração do IE. No seu caso deu certo você está utilizando WinCrypt ou CAPICOM? Pois no CAPICOM meu ambiente também está funcionando. Obrigado mais uma vez.

Bom dia a todos, Também estou tendo esse problema com window 7 (32 e 64) e Windows 8. Estou com a cadeia de certificado atualizada (Baixei direto do site da certificadora) e o erro persiste. Pelo que vi acima falam que precisa estar com windows atualizado, estou executando o windows update em minhas maquinas de testes, mas alem disso existe algo mais que posso fazer? A configuração do componente utilizada é: ACBrNFe1.Configuracoes.Geral.SSLLib := libWinCrypt; ACBrNFe1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; ACBrNFe1.Configuracoes.Geral.SSLHttpLib := httpWinHttp; ACBrNFe1.Configuracoes.Geral.SSLXmlSignLib := xsMsXml; Claudemir qual o link que você utilizou para baixar a cadeia de certificado? Agradeço a todos pela ajuda;

OK Obrigado!

Pessoal me desculpe acabei subindo o tópico, mas o mesmo já foi corrigido na Revisão abaixo: Revision: 14084 Author: hleorj Date: sexta-feira, 3 de novembro de 2017 10:08:47 Message: -- ACBrNFeDANFEFRDM -- [*] Ajuste para apresentar data de recebimento em Delphi 7 por: BigWings ---- Modified : /trunk2/Fontes/ACBrDFe/ACBrNFe/DANFE/NFe/Fast/ACBrNFeDANFEFR-change-log.txt Modified : /trunk2/Fontes/ACBrDFe/ACBrNFe/DANFE/NFe/Fast/ACBrNFeDANFEFRDM.pas Obrigado a todos pela atenção.

Bom dia a todos, Baixei essa manhã o fonte do projeto, e ao tentar instalar o mesmo tive um problema no seguinte pas: ACBrNFeDANFEFRDM.pas. Analisando o fonte verifiquei que o problema estava na seguinte procedure: TACBrNFeFRClass.CarregaParametros; Exatamente na seguinte linha: FieldByName('dhRecbto').AsDateTime := StringToDateTimeDef(Trim(Copy(FDANFEClassOwner.ProtocoloNFe, P + 1)), 0, 'dd/mm/yyyy hh:nn:ss'); Fiz o copy da seguinte forma: FieldByName('dhRecbto').AsDateTime := StringToDateTimeDef(Trim(Copy(FDANFEClassOwner.ProtocoloNFe, P + 1,Length(FDANFEClassOwner.ProtocoloNFe)-(P + 1))), 0, 'dd/mm/yyyy hh:nn:ss'); Após a alteração a instalação foi feita com sucesso. Segue o PAS corrigido em anexo. Qualquer coisa estou a disposição. Obrigado a todos pela atenção.

Também não consegui um detalhamento, nem da secretária da fazenda. Enviei o questionamento, mas como sempre responderam evasivamente. Obrigado pela atenção.

Boa tarde a todos os mestres, Apenas para confirmar se não entendi errado a NT 2016.002: 1.31 (e as anteriores correlacionadas). Todas os novos campos, novas regras e exclusão de algumas outras regras de validação são respectivamente relacionada ao layout 4.00. O 3.10 não terá essas validações e regras, continuando o mesmo que está em vigor atualmente. OK? Pensando nisso teremos novos WebServices específicos para novo layout; "NFeAutorizacao4 NFeRetAutorizacao4 NFeInutilizacao4 NFeConsultaProtocolo4 NFeStatusServico4 NFeRecepcaoEvento4 CadConsultaCadastro4" Compreendi errado? Agradeço a todos pela ajuda.

Olá Leonel Araujo você descobriu onde pode ser capturado esta informação? Agradeço pela atenção.

Pensei da mesma forma e questionei o suporte, a posição foi que o mesmo será ajustado para realidade do SAT e NFC-e. Nos resta aguardar os ajustes. kkkkkkk Obrigado pelo auxílio Daniel.

Bom dia Daniel, Novamente obrigado pelo retorno. Tentei utilizar o método que você passou. Mas fazendo os testes a DLL não retorna valor algum, sempre retorna zero! Mas no Relatório de Transações do SiTef a transação consta como PENDENTE. Vendo esse problema entrei em contato com a Software Express e recebi o seguinte retorno do suporte: Pensando nisso podemos desconsiderar a minha duvida e minha sugestão. Obrigado mais uma vez pelo auxilio.

No momento que aparece no Pinpad: "TRANSACAO ACEITA" e logo em seguida pede para remover o cartão, se olharmos no Relatório de Transações do SiTef, a Transação ainda está Pendente. Mas da forma que implementei acima, fazendo o processo de homologação seq 16, ao abrir novamente a aplicação, o retorno é: "Transação TEF efetuada. Favor reimprimir último Cupom. (Para Cielo utilizar os 6 últimos dígitos.)" Hoje existe algum método ACBrTEFDCliSiTef, que valida a última transação sem a existência do arquivo *.tef?

Boa tarde Daniel, Primeiramente Obrigado pelo Retorno, Sim, verifiquei a linha explanada acima. Mas o problema é que se não tirar o cartão não temos o retorno, mas no pinpad aparece transação OK, se reiniciarmos a aplicação ou a maquina antes de tirar o cartão da Leitora, no retorno da aplicação como não existe o arquivo gerado, não há verificação se existe algo pendente ou não. Apenas para teste coloquei o processo de geração do arquivo a cada mensagem processada na tela: Sequencia 3 do case que destaquei acima. Dessa forma a cada mensagem gerada para o usuário é gerado o arquivo com o retorno atualizado. Dessa forma mesmo que não tire o cartão da leitora e faça a sequencia 16 do processo de homologação, ao entrar na aplicação novamente o arquivo é validado. Mas nesse caso tem a problemática de gerar um arquivo para cada mensagem que é processada, e não sei qual seria a influência dessa mudança. Fiz alguns testes, dessa forma deu certo. (Sem colocar "Strings hardcoded"). 3 : begin MensagemOperador := ProcessaMensagemTela( Mensagem ); fArqBackUp := CopiarResposta; MensagemCliente := MensagemOperador; DoExibeMsg( opmExibirMsgOperador, MensagemOperador, (TipoCampo=5005) ) ; DoExibeMsg( opmExibirMsgCliente, MensagemCliente, (TipoCampo=5005) ) ; end ; Você acha que existe problema com essa implementação Daniel? Ou você tem outra solução para esse caso? Obrigado mais uma vez pela atenção

Boa tarde a todos, Ainda no caso acima da sequencia 16, estou refazendo a homologação para NFC-e e SAT, pelo que vi o arquivo só é gerado no diretório padrão no método: TACBrTEFDCliSiTef.ContinuarRequisicao; E só é chamado o método para geração do arquivo, quando a variavel TipoCampo, estiver atribuída a: 121, 122, 133, 952; Vendo o requisito pensei na seguinte solução: (Me desculpe se estiver equivocado!) Dentro do case ProximoComando of Na sequencia 3: Podemos implementar a criação do arquivo caso o retorno da mensagem seja "TRANSACAO ACEITA". Ex: If AnsiUpperCase(Mensagem) ='TRANSACAO ACEITA' Then fArqBackUp := CopiarResposta; Dessa forma mesmo que o cartão não seja retirado da leitora, a maquina seja finalizada (ou a aplicação) ao iniciar novamente o sistema iremos ter o retorno da transação. Se foi OK e precisa fazer a reimpressão ou reter o cupom. Estou errado no meu modo de pensar? Obrigado pela atenção.

Vou efetuar o Teste Unitário e volto a lhe falar o resultado. Obrigado desde já pela atenção.

Boa tarde Daniel, Primeiramente obrigado pelo retorno. Também não compreendo, mas nos testes feitos o TruncTo estava sempre retornando 0,01 centavos a menos do que foi passado para ele. Não sei se pode ser a versão do Delphi utilizada pois a minha versão é o Delphi 7. Testamos se era algo relacionado ao SetRoundMode, pois já tivemos problemas relacionados em formatação, mas mesmo passando para o SetRoundMode(rmNearest) o calculo fica incorreto. Você acha necessário ter a formatação desse valor, já que o mesmo já está vindo formatado corretamente da unit: ACBrECF. Mais uma vez obrigado pela atenção.

Olá a todos, Gostaria de compartilhar mais um pequeno caso que localizei na unit: ACBrECFVirtual, exatamente no método: EfetuaPagamento. O método estava programado da seguinte forma: function TACBrECFVirtualClassCupom.EfetuaPagamento(AValor: Currency; AObservacao: String; APosFPG: Integer): TACBrECFVirtualClassPagamentoCupom; begin Result := fpPagamentosCupom.New; with Result do begin PosFPG := APosFPG ; ValorPago := fpECFVirtualClasse.RoundECF(AValor); Observacao := AObservacao ; fpTotalPago := fpTotalPago + max(ValorPago, 0); end; end; Esse método fpECFVirtualClasse.RoundECF utiliza a property fpArredondaItemMFD, e a mesma está igual a False no meu caso. Ou seja, o sistema irá truncar o valor os valores. (Essa propriedade precisa ficar False, pois os produtos nesse caso precisam ser truncados na venda) Ex: Enviei um pagamento de 78,22, o método que efetua o TruncTo retornava 78,21; Pensando nisso esse Valor não deveria ser formatado, pois o mesmo já vem com seu valor respectivamente correto, pois no método: EfetuaPagamento da unit: ACBrECF (TACBrECF.EfetuaPagamento) já faz a devida formatação do campo, enviando assim corretamente para unit: ACBrECFVirtual; Meu método ficou da seguinte forma: function TACBrECFVirtualClassCupom.EfetuaPagamento(AValor: Currency; AObservacao: String; APosFPG: Integer): TACBrECFVirtualClassPagamentoCupom; begin Result := fpPagamentosCupom.New; with Result do begin PosFPG := APosFPG ; ValorPago := AValor; //fpECFVirtualClasse.RoundECF(AValor); Observacao := AObservacao ; fpTotalPago := fpTotalPago + max(ValorPago, 0); end; end; Não consegui pensar em outra solução ou encontrar algo que mudasse esse calculo. Peço por gentileza que desconsidere a sugestão caso exista outra. Agradeço a todos pela ajuda desde já. ACBrECFVirtual.pas

Boa noite Daniel, Baixamos e testamos deu certo a modificação. Agradeço muito pela prontidão no auxílio!!! Tópico pode ser colocado como resolvido

Olá Daniel, Primeiramente muito obrigado pelo retorno. Espero ter deixado tudo certo, qualquer coisa estou a disposição. Aguardo seu retorno.

Olá a todos, Gostaria de passar um caso que pegamos: Utilizamos o Compontente: ACBrECFVirtualNaoFiscal, com ACBRECF, para simular a venda na tela para o cliente, após isso finalizamos a venda SAT normalmente. Mas em clientes que trabalham 24 horas estava ocorrendo um problema na venda na mudança de dia. Após algumas validações vimos que na unit: ACBrECFVirtual, no método: function TACBrECFVirtualClass.GetEstado: TACBrECFEstado; existia o seguinte tratamento: if not (fpEstado in [estNaoInicializada,estDesconhecido]) then begin if (CompareDate( now, fpDia) > 0) and ( not (fpEstado in [estBloqueada,estRequerX])) then fpEstado := estRequerZ ; if (fpEstado = estBloqueada) and (CompareDate( now, fpDia) > 0) then fpEstado := estRequerX ; end; Ou seja no meio de uma venda o estado era modificado para RequerZ, bloqueando assim a venda e a finalização. Pensando nisso fizemos a seguinte "Melhoria" no processo, para que só seja modificado o estado para estRequerZ apenas se o estado da impressora for igual a estLivre. Ficando da seguinte forma: if not (fpEstado in [estNaoInicializada,estDesconhecido]) then begin if (CompareDate( now, fpDia) > 0) and ( (fpEstado in [estLivre])) then fpEstado := estRequerZ ; if (fpEstado = estBloqueada) and (CompareDate( now, fpDia) > 0) then fpEstado := estRequerX ; end ; Não achei outra solução, por gentileza se existir alguma outra solução me avise. Agradeço desde já pela atenção de todos. ACBrECFVirtual.pas

Bom dia, Daniel Agradeço a colaboração, após muitos telefonemas estudos, achei uma pessoa no suporte da Software Express que entendia do assunto e me ajudou a resolver o problema. Basicamente o meu sistema e o componente ACBrTEFD estão corretos, era apenas uma configuração errada do arquivo Clisitef.ini. O correto é o seguinte: [PinPadCompartilhado] Porta=01 [CliSiTefI] HabilitaTrace=1 [CliSiTef] HabilitaTrace=1 [Geral] TransacoesAdicionaisHabilitadas=3020;3289 [CartaoCombustivel] ColetaDadosProdutoSeparadamente=1 Na linha [Geral] a DLL CliSiTef32.dll lê a primeira linha do parâmetro, como estava uma linha abaixo da outra a mesma ignorava a segunda linha. Para corrigir basta colocar um ";" para as transações adicionais, dessa forma apareceu o menu possibilitando a transação correta. Agradeço a todos e fica a dica, e se tiverem algum problema com Sitef, liguem na Software Express o pessoal lá é muito competente.

Bom dia Daniel, Certo, minha aplicação não utiliza estes parâmetros adicionais, no caso como seria a forma de passar estes parâmetros ? Atualmente o meu arquivo de configuração Clisitef.ini está dessa forma: [PinPadCompartilhado] Porta=01 [CliSiTefI] HabilitaTrace=1 [Geral] TransacoesAdicionaisHabilitadas=3020 TransacoesAdicionaisHabilitadas=3289 [CartaoCombustivel] ColetaDadosProdutoSeparadamente=1 Para o componente ACBrTEFD.TEFCliSiTef.ParametrosAdicionais seria passar da mesma forma acima? Estou entrando em contato com a Software Express também. Obrigado.

Daniel, Analisando o log, as opções que estão vindo no log são as seguintes: -- 06/01 13:47:26:678 - CliSiTef DoExibeMsg: Oper: opmExibirMsgOperador Mensagem: SiTef Conectado -- 06/01 13:47:26:685 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 06/01 13:47:26:692 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 4 TipoCampo = -1 Buffer = Selecione a forma de pagamento Tam.Min = 0 Tam.Max = 0 -- 06/01 13:47:26:693 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 06/01 13:47:26:698 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 21 TipoCampo = -1 Buffer = 1:Cartao de Debito;2:Cartao de Credito;3:Cartao Private Label;4:Confirmacao de Pre-autorizacao; Tam.Min = 1 Tam.Max = 2 Segundo o manual do Valecard, deve ter uma opção "5: Combustivel". Estou enviando o log também. Obrigado. CliSiTef.log