danielznt

Bom dia @Daniel Simoes Fiz o teste aqui. Dessa maneira funcionou certinho aqui pra mim. Continuarei com a integração aqui. Muito obrigado.

Boa tarde Estou implementando a integração com o TEF Scope por API. Estou tendo um problema para comunicar com o Pinpad onde ao passar pela primeira vez em ScopeConsultaPP recebo o retorno 65431 e o fluxo é interrompido. Conforme instruído por @Daniel Simões de Almeida no Discord, entrei em contato com o pessoal da Scope onde fui informado que a função em questão está obsoleta e a mesma não consta mais no manual. Fui instruído pelo pessoal da Scope a usar a função ScopePPGetCOMPort, caso queira buscar a porta ou então caso já tenha a porta, conectar diretamente com ScopePPOpenSecure. Verificando a função reparei que isso já é feito na função ConfigurarPortaPinPad que é chamada dentro de AbrirPinPad. Então fiz a remoção da validação inicial e ai funciona perfeitamente pra mim. Ou seja, quando chamar ConfigurarPortaPinPad, caso a mesma não seja passada, irá chamar o ScopePPGetCOMPort para localizar e caso já tenha sido passada ele pula e vai direto para o ScopePPOpenSecure. Vou enviar a função aqui para ver se vocês acham que é valida essa mudança para aplicar ao fonte: procedure TACBrTEFScopeAPI.AbrirPinPad; var ret: LongInt; bConfig, bExclusivo, aPorta, bPorta: Byte; Canal: Word; endereco: AnsiString; begin FecharComunicacaoScope; GravarLog('AbrirPinPad'); GravarLog('ScopeValidaInterfacePP( '+IntToStr(PP_INTERFACE_LIB_COMPARTILHADA)+' )'); ret := xScopeValidaInterfacePP( PP_INTERFACE_LIB_COMPARTILHADA ); GravarLog(' ret: '+IntToStr(ret)); if (ret <> PC_OK) then TratarErroPinPadScope(ret); try AbrirComunicacaoScope; aPorta := ConfigurarPortaPinPad(fPortaPinPad); if (aPorta = 0) then aPorta := bPorta; if (bConfig = PPCONF_MODO_ABECS) then fPinPadSeguro := True; if fPinPadSeguro then begin if (aPorta = 0) then Canal := CANAL_COMM_NONE else Canal := CANAL_COMM_SERIAL; GravarLog('ScopePPOpenSecure( '+IntToStr(Canal)+', '+IntToStr(aPorta)+' )'); endereco := IntToStr(aPorta); ret := xScopePPOpenSecure(Canal, PAnsiChar(endereco)); end else begin GravarLog('ScopePPOpen( '+IntToStr(aPorta)+' )'); ret := xScopePPOpen(bPorta); end; GravarLog(' ret: '+IntToStr(ret)); if (ret <> PC_OK) then TratarErroPinPadScope(ret); finally VerificarSeMantemConexaoScope; end; end;

Boa tarde @Agnaldo Prates Acabei fazendo dessa maneira mesmo para resolver provisóriamente a situação: qBCMonoRet:= AcbrUtil.RoundABNT(rmdProduto.FieldByName('qtde').AsFloat, 2); Porém a dúvida maior era quanto a ser correto fazer isso, visto que o campo qBCMonoRet possui precisão de até 4 casas decimais e também observado que a orientação no caso do SAT por exemplo para os valores de venda é de truncamento do valor e não arredondamento, se o correto seria arredondar ou truncar. Não achei orientação quanto a esse campo. Acabei respeitando o que o componente está fazendo nos totalizadores da nota. O componente hoje está arredondando esse campo no totalizador da nota, então optei, na falta de orientação da Nota Técnica, em arredondar no item também.

Bom dia a todos Comecei a ter esse retorno "Rejeicao: Total do ICMS monofasico retido anteriormente difere do somatorio dos itens", ao emitir a NFC-e. Reparei o seguinte. O campo de base qBCMonoRet do item, segundo a Nota Técnica 2023.001 que tenho possui precisão de 4 casas decimais, já o mesmo campo nos totalizadores da nota, só possui 2 casas decimais. Nesse cenário, a minha venda de combustível, possui quantidade 33,398, eu informei dessa maneira no item e também informei dessa maneira no total, porém o componente arredondou (acredito que pela Nota Técnica ter esse precisão de 2 casas) e gerou o XML com o total em 33,40 ficando assim divergente dos 33,398 do item e acusando a rejeição. Vi que tem um tópido desse já criado, porém o mesmo foi movido para o SAC, então não consegui responder / acrescentar informação. Acredito que a nota técnica, acaba nos forçando a informar no item a quantidade arredondada com 2 casas decimais também. Mais alguém com essa situação ? Att,

Opa @EliasCesar, Fiz o update e depois o teste aqui e funcionou certinho, Muito obrigado.

Bom dia, Utilizo o componente do ACBr para transacionar com a Shipay. Hoje ao fazer o update do componente, deu erro no método GetWallets. Fui procurar a alteração no fonte de exemplo, para ver para qual comando foi substituido ou para qual unit o mesmo poderia ter sido alterado, porém o exemplo também estava usando o metodo GetWallets e conseguentemente não compilando. Indo mais a fundo, analisando os fontes, percebi que o método em questão foi alterado de public para private. Fiz a alteração provisória aqui no fonte do ACBr para poder continuar a usar, visto que essa função é importante para que eu liste para o operador as opções disponíveis, para que ele possa selecionar a mais adequada (Chamo a função e renderizo os botões das opções na tela). Gostaria de saber se é possível manter essa função como public no fonte oficial ? Att,

Bom dia, Estou com alguns problemas de XMLs faltantes. E rastreando os logs e ocorrências chego em uma situação estranha, onde eu consulto Status do Sat, recebo 8000, na sequência faço o envio da venda e recebo o retorno de "sat em processamento", consulta a sessão na sequência e continuo recebendo "Sat em processamento". Porém se pego o log do equipamento sat dessa transação, os comandos foram todos recebidos corretamente, a consulta deu sat em operação, o envio retorno como Emitido com sucesso e a consulta de sessão também retornou Emitido com sucesso, ou seja, diferente do retorno recebido pelo componenente. Retorno Sat: Alguém já teve esse problema também. Alguma sugestão de correção ? Att,

Tentamos essa solução, porém na variável fica correto, mas hora de atribuir ao componente, o mesmo é do tipo Integer e ai o problema também foi apresentando (não sei o motivo mas em alguns casos até funcionou, porém gerando lote negativo).

Bom dia a todos, Para corrigir o problema. Adotamos a seguinte estratégia aqui na empresa. Antes usavamos a seguinte formatação: yymmddhhmm. Esse formatação gerava um número de 10 posições que começou a apresentar o problema em questão pelo estouro do inteiro. Então fizemos a substituição mmdd (mês e dia) que ocupava 4 posições, pelo número do dia real no ano, que irá variar de 001 a 365, tendo somente 3 posições. Sendo assim não irá mais atingir a casa do bilhão. Pegando como exemplo hoje 04/01/2022 às 09:44: Antes: 2201040944 Depois: 220040944 Att,

Boa tarde @Renato Rubinho, Utilizamos aqui na empresa quase o mesmo esquema seu, para gerar o número do lote fazemos yymmddhhmm. A única diferença é que não acrescentamos esse random ao final. Porém hoje 03/01/2022, começamos a ter problemas com a conversão para inteiro no ACBr em Delphi. A assinatura da função é Integer, porém ao converter de manhã após virar o ano, gerou o número 2201031127 (2.201.031.127). Porém o limite máximo do Inteiro é 2.147.483.647, sendo assim apresentou o erro: Você não chegou a ter esse problema no seu sistema ? Se sim, qual estratégia utilizou para solucionar ? Estamos verificando o manual da NF-e, etc, mas não conseguimos encontrar um lugar onde pudéssemos ter a certeza que não haveria problema nesse número repetir. Att,

Boa tarde @Daniel Simoes, Googando encontrei esse link do GitHub, aparentemente da própria FoxitSoftware https://github.com/foxitsoftware/DelphiZXingQRCode/pull/4 E na resposta do link acima, tem esse apontamenteo para a correção que apliquei que é o segundo link que estou enviando também. https://github.com/eisc0013/DelphiZXingQRCode/commit/5b84fc1dae67cf190c03f53010f8ca2996ad3649 Att,

Bom dia, Precisei usar recentemente o fonte "ACBr\Fontes\Terceiros\DelphiZXingQRCode\ACBrDelphiZXingQRCode.pas", para gerar alguns QRCodes, onde passo uma string, gero o QRCode e transformo o mesmo em imagem. Porém reparei que ao ler o QRCode gerado, ele não retorna a string original. Ele está suprimindo todos os zeros da string. Dei uma googada na internet e achei outras pessoas com o mesmo problema referente ao ZXing e passaram a seguinte correção. Alterando essa linha do trecho abaixo o problema é resolvido e o QRCode é gerado com os zeros também. Gostaria de saber se vocês enxergam algum problema nessa alteração e se caso não houver se seria possível commitar esse fonte? Fiz o teste comparando alguns QRCodes gerados com os mesmos gerados através de um site e ficaram iguais, também testei fazer a leitura reversa e a string resultou na string original gerada. Anexei o fonte com a alteração efetuada. Obrigado desde já pela atenção. ACBrDelphiZXingQRCode.pas

Boa tarde, Venho acrescentar mais algumas informações. No caso o problema tem ocorrido em impressoras HP e após a atualização do Windows para emissão da NF-e 4.0. Já foi reinstalado drivers, atualizado porém o problema persiste. A geração do PDF e impressão do mesmo via Windows funciona, inclusive outros relatórios gerados através do sistema porém sem ser utilizando o Fortes Report também funcionam. No primeiro momento ocorria o mesmo problema relatado por @j2c9m7, aparecia o preview e ao enviar para a impressora nada ocorria. Após efetuar a atualização do Fortes e do ACBr hoje, ele não lista a impressora em questão que esta em rede mais. Isso esta acontecendo em 6 clientes, ambos com impressoras HP porém de modelos diversos. Em alguns dos clientes aparece a seguinte mensagem de erro conforme imagem abaixo: Att,

Boa tarde @jGuto, Após vários testes e horas sem sucesso, acabei desistindo da solução em modo serviço do Windows, na verdade colocando na geladeira. Acabei desenvolvendo em modo gráfico e deixando rodando na bandeja do sistema. Não é exatamente como eu queria pois isso exige que o servidor esteja logado, porém até conseguir contornar a situação ficou dessa maneira. Infelizmente não consegui. Faz um tempo que não tento mais, porém se não me falha a memória o erro era esse mesmo ou inativo e inoperante por não conseguir carregar o certificado. Se eu tiver algum sucesso mais a frente eu comunico, se você conseguir e puder postar aqui também fico agradecido. Att,

Boa tarde, Após muito penar e pesquisar consegui fazer funcionar a consulta. Segue um exemplo simples, espero que ajude quem esteja precisando e no desenvolvimento do componente. Att, SAT - CONSULTA LOTES SERVIÇO.rar

Boa tarde @Daniel Simoes, @Alexandre_Bernardes e @rf.soares Como o post já é meio antigo não sei se vocês conseguiram resolver mais estou com um problema parecido: Desenvolvi um serviço do Windows para fazer toda parte de emissão e consultas de NFe, visto que meu cliente possui um certificado A3 e quer usar de mais de uma maquina. Faço toda a comunicação entre meu sistema e o serviço através de um banco especifico para troca das informações e o serviço fica encarregado de receber tais consultas/emissões, executa-las e enviar a resposta. A questão que vem é a seguinte. Com o Windows 10 funciona perfeitamente, porém quando o cliente possui um Windows 7, eu fico recebendo a mensagem de Inativo ou inoperante, e reparo que o led do leitor do cartão nem chega a piscar, dando impressão que não houve comunicação com o certificado digital. Experimentei rodar no Windows 7 com um certificado A1, e nesse caso funcionou. Não sei então se o problema é o acesso efetivo ao certificado A3 ou a leitora. Vocês saberiam de algo que eu pudesse fazer ou conseguiram rodar esses serviços com A3 no Windows 7 ? Obs:- Já esta adicionada na Unit Principal e no projeto as Uses Windows, Forms e ActiveX, e também o serviço esta configurado com o usuário administrador. Obrigado desde já pela atenção.

Boa tarde @Reinaldo Silveira e @Mark Apollo, Estou com uma situação parecida. Desenvolvi um serviço do Windows para fazer toda parte de emissão e consultas de NFe, visto que meu cliente possui um certificado A3 e quer usar de mais de uma maquina. Faço toda a comunicação entre meu sistema e o serviço através de um banco especifico para troca das informações e o serviço fica encarregado de receber tais consultas/emissões, executa-las e enviar a resposta. A questão que vem é a seguinte. Com o Windows 10 funciona perfeitamente, porém quando o cliente possui um Windows 7, eu fico recebendo a mensagem de Inativo ou inoperante, e reparo que o led do leitor do cartão nem chega a piscar, dando impressão que não houve comunicação com o certificado digital. Experimentei rodar no Windows 7 com um certificado A1, e nesse caso funcionou. Não sei então se o problema é o acesso efetivo ao certificado A3 ou a leitora. Vocês saberiam de algo que eu pudesse fazer ou conseguiram rodar esses serviços com A3 no Windows 7 ? Obs:- Já esta adicionada na Unit Principal e no projeto as Uses Windows, Forms e ActiveX, e também o serviço esta configurado com o usuário administrador. Obrigado desde já pela atenção.

Bom dia @Luís Osmar, Muito obrigado pela atenção. Mas já estou enviando essa linha no onBeforeExecute. Vou mandar o fonte que estou usando com base no exemplo do Luís, se alguém puder dar uma olhada se vê algum problema de cara eu fico agradecido. Eu utilizei o exemplo que o Luís enviou acima no forum, só fiz uma adaptação nessa parte do onBeforePost pois no Delphi XE6 esse parâmetro SOAPRequest não é do tipo WideString mas TStream, então precisei colocar da seguinte maneira, para fazer a conversão: SOAPRequest:= TStringStream.Create(cEnviaWS.Text); No mais eu fiz a importação do WSDL na unit CfeConsultarLotes1, mas não consigo de maneira alguma fazer retornar corretamente, sempre retorna XML MAL FORMADO. O que me chamou atenção, no caso não entendi foram as linhas: parametros:= CfeConsultarLotes.create; parametros.cfeDadosMsg:= ''; o cfeDadosMsg esta indo vazio, não sei se é assim mesmo ou se eu deveria informar, ou se pelo fato de já montar o xml com essas informações se isso não seria necessário. SAT - CONSULTA LOTES SERVIÇO.rar

Boa tarde, @Michel Abrão, Obrigado pela atenção. No meu sistema até funciona porém existe essa questão de ter que ficar colocando a senha, o que o cliente não quer. att,

Bom dia @Michel Abrão e a todos, Conseguiu resolver o problema com o Certificado Oberthur? Estou com o seguinte problema com esse certificado. Não consigo deixar a senha automática, pelo menos a primeira nota ele pede o Pin do Certificado. Com outros certificados A3 isso não acontece, eu informo a senha ao componente dentro do sistema ao carregar as configurações e a nota emite perfeitamente, porém com esse Oberthur abre a tela para informação da senha. Att,

Bom dia @Luís Osmar, Com esse exe que você mandou funcionou, porém na implementação aqui fica acusando XML Mal Formado. Segui seu exemplo do arquivo Teco.txt....O mais estranho é que o XML gerado pelo meu sistema é igual ao gerado por esse outro programa que vc mandou, porém no programa funciona e no meu não. Saberia me dizer algo, alguma dica?

O problema em questão é o mesmo passado pelo dionatan no inicio do tópico. "Erro interno. Pode ser que o perfil do usuário não esteja acessível ou que a chave privada que você está importando exija um provedor de serviço de criptografia que não está instalado no sistema.." Esse problema começou a acontecer após eu ter apagado o acbr utilizando o bat para apagar e refazer a instalação do mesmo com a versão atualizada. Não que isso tenha ocasionado o problema, mas estava funcionando normal a questão das notas e após isso não consigo mais comunicação com o certificado digital. Tentei remover o certificado e instalar novamente, porém ao tentar instalar o erro acima é apresentado.

No meu caso o Windows é o 10.

Bom dia @Roger_gms, Também estou com esse problema, porém ainda não consegui resolver. Windows 10 64. Você conseguiu resolver com alguma dica acima ?

Bom dia @Henrique Lima e @phgtb, na época nós tivemos esse problema com o estado do Paraná, onde o CFOP 5656 estava pedindo a informação da encerrante independente de ser combustível ou não. Para resolver isso entramos em contato com a Sefaz-PR e expliquei toda a situação, a partir disso eles começaram a validar também o NCM e o Código da ANP informado, e paramos de ter o problema. Mas no nosso caso aqui da empresa, os clientes que possuo no PR, todos tem automação pois la era PAF-ECF até recentemente então era obrigatório ter automação, não chegamos a ter esse problema com combustível propriamente dito pois estamos enviando a informação quando é combustível. Hoje não possuo clientes em Goias, portanto não conheço muito bem a legislação ai, mas se não for obrigatório e você não informar as tags Prod.comb, referente aos encerrantes da algum erro ? Aqui por exemplo quando é para o estado de São Paulo onde não é obrigatório, quando o cliente não tem automação, não informamos essa tag referente aos encerrantes e não apresenta erro.