Intelliware

Bom dia Daniel, De fato, não estávamos utilizando esta propriedade. Adicionei ela como um parâmetro do sistema pois neste caso ajuda muito na validação e visualização do problema. Realmente, analisando um novo log do cliente, era erro de retorno de sessão, no print abaixo, coloquei um retorno que ocasionou um cancelamento e um retorno em que foi aprovado com sucesso: Acreditamos que ao executar um comando que resulte em erro na porta de comunicação, o driver/SAT está retornando um número de sessão do comando anterior na próxima execução. Hoje de manhã, entramos em contato com a Bematech para verificarmos este erro na leitura da porta de comunicação, pois neste cliente em questão, estava ocorrendo direto, causando lentidão, rejeição e erros. Nos foi passado que para resolver problemas de comunicação foi lançado uma versão do driver USB mais atual. Para efeito de maior esclarecimento, para hoje dia 08/03/2018 as versões que são as últimas para o SAT da Bematech RB-1000 são: - Versão do Software Básico(Firmware): 02.01.00 - Versão do driver USB: 3.4.0.0 - Versão da BemaSAT(DLL): 1.0.2.35 Atualizamos todos os caixas. Estou efetuando alguns testes e vou liberar uma versão com a propriedade da ACBrSAT parametrizada. Mais uma vez, agradeço a ajuda.

Bom dia pessoal, No dia 01/03 recebemos de um cliente(SAT Bematech RB-1000) uma reclamação que estava ocorrendo problema na emissão do CF-e. Analisando o log, encontramos um erro no processo de adicionar os dados do CF-e no banco de dados. Segue: [01/03/2018 17:29:08] [TRANSMITIRCUPOMSAT]ERRO(#07): '255,255,255,000' is not a valid floating point value - IDCUPOM: 5414226000 Só para esclarecer melhor, o nosso sistema, efetua antes de enviar a venda para o SAT, a seguinte validação: 1) SAT está em operação? 2) Status do SAT é não BLOQUEADO? 3) Qual o status da impressora? No log do SAT gerado pela ACBr, obtivemos: Ou seja, pelo visto o sistema tentou converter uma resposta da posição 09, que a princípio é resultado do comando ConsultarStatusOperacional e não do EnviarDadosVenda. No sistema eu faço: with Resposta do begin //06000 - Emitido com sucesso + conteúdo notas if (codigoDeRetorno = 6000) then begin ValorTotalCFe := StringToFloat(Resposta.RetornoLst[9]); (...) O problema relacionado a isso é que o nosso sistema cancelou o cupom pois foi executada uma exceção, mas o CF-e estava aprovado na SEFAZ. Algo que notei é que o tempo entre o número de sessão 158050 e 710051 foi de 0,936 ms. As requisições ao SAT são sequenciais, ou seja, é efetuada uma chamada, processada a resposta, efetuada outra chamada e assim por diante. Seria possível no componente uma resposta sobrescrever a outra? Este erro ocorre ocasionalmente em um cliente e não conseguimos reproduzir. Em outros clientes não recebemos este tipo de reclamação. Gostaria da opinião de vocês a respeito deste procedimento. Vocês já tiveram algum problema deste tipo? Desde já agradeço o retorno.

Daniel, boa tarde, verificamos aqui e a princípio, este problema estava relacionado a uma thread que era executada em paralelo para avisar o usuário de pouco de papel e que estava apresentando problema. Pelo que validamos, ela executava praticamente no momento da leitura do grande total na thread principal. Mais uma vez agradeço a resposta.

Boa tarde pessoal, Fizemos a liberação de uma versão recentemente com a ACBr mais atualizada e verificamos que em 2 clientes, foi reportado erro no ECF. Analisando o log, verificamos o seguinte: -- 14/02 12:54:21:506 estLivre -- 14/02 12:54:21:661 GrandeTotal -- 14/02 12:54:21:663 TX -> [FS]R[200]001[183] -- 14/02 12:54:21:814 RX <- :[200]001000000000115917095[CR] -- 14/02 12:54:21:855 GrandeTotal -- 14/02 12:54:21:855 TX -> [FS]R[200]001[183] -- 14/02 12:54:21:878 Daruma: Falha no Envio do CMD. Tentativa: 1 - Erro: 0 - Estendido: 0 -> Erro não documentado Cod.Aviso: 0 -- 14/02 12:54:21:879 RX <- -- 14/02 12:54:21:879 ----------------- ERRO ----------------- A call to an OS function failed ---------------------------------------- -- 14/02 12:57:35:155 -------------------------------------------------------------------------------- ATIVAR - 14/02/18 12:57:35:155 - Modelo: Daruma - Porta: COM4 - TimeOut: 10 Device: BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE= MAXBANDWIDTH=0 SENDBYTESCOUNT=0 SENDBYTESINTERVAL=0 -------------------------------------------------------------------------------- E também: -- 14/02 12:59:15:894 estLivre -- 14/02 12:59:16:017 GrandeTotal -- 14/02 12:59:16:018 TX -> [FS]R[200]001[183] -- 14/02 12:59:16:203 RX <- :[200]001000000000115917555[CR] -- 14/02 12:59:16:247 GrandeTotal -- 14/02 12:59:16:247 TX -> [FS]R[200]001[183] -- 14/02 12:59:16:249 Daruma: Falha no Envio do CMD. Tentativa: 1 - Erro: 0 - Estendido: 0 -> Erro não documentado Cod.Aviso: 0 -- 14/02 12:59:16:249 RX <- -- 14/02 12:59:16:249 ----------------- ERRO ----------------- A call to an OS function failed ---------------------------------------- -- 14/02 13:02:11:846 -------------------------------------------------------------------------------- ATIVAR - 14/02/18 13:02:11:846 - Modelo: Daruma - Porta: COM4 - TimeOut: 10 Device: BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE= MAXBANDWIDTH=0 SENDBYTESCOUNT=0 SENDBYTESINTERVAL=0 -------------------------------------------------------------------------------- Ou seja, aparece este erro: A call to an OS function failed Em contato com o pessoal do suporte, nos foi relatado que isso ocorre no ECF Daruma quando o mesmo fica com pouco papel, conforme podemos observar várias vezes no log em anexo: -- 14/02 12:52:14:507 PoucoPapel -- 14/02 12:52:14:507 TX -> [GS][255][CR] -- 14/02 12:52:14:649 RX <- :A1E20C000000[CR] Em teste, o pessoal da qualidade conseguiu reproduzir uma única vez, em desenvolvimento estamos tentando simular, mas ainda não conseguimos êxito. Gostaria da opinião de vocês sobre este assunto. Desde já agradeço. LOG_ECF_ACBr-20180215.txt

Bom dia, @Italo Jurisato Junior, estamos seguindo este pequeno roteiro de como entrar em contingência com a NFC-e: Você não deve consultar o status antes de enviar, isso faz com que a SEFAZ bloquei a sua conexão por consumo indevido e só libera depois de 1 hora. Você deve gerar o XML e tentar enviar se ocorrer algum erro, deve realizar uma consulta, pois não sabemos se o erro ocorreu durante o envio ou retorno. Ao consultar se a SEFAZ retornar que a nota não existe na base de dados, significa que o erro ocorreu no envio, ai devemos tentar novamente. Por outro lado se o erro foi no retorno, com a consulta teremos o protocolo de autorização, e ai com o XML completo ou seja assinado e protocolado devemos imprimir o DANFE. Se ao tentar enviar pela segunda vez novamente ocorrer o erro, fica claro que o WebService que recepciona as notas esta parado, ai sim você gera novamente o XML só que agora com o tipo de emissão Offline e imprime o DANFE. Arquive essa nota para tentar o seu envio mais tarde. Só para confirmar a nossa interpretação, quando você cita: Ao consultar se a SEFAZ retornar que a nota não existe na base de dados, significa que o erro ocorreu no envio, ai devemos tentar novamente. Você se refere ao código: WebServices.Consulta.cStat = 217 Seria isso mesmo? Desde já agradeço.

Bom dia Juliomar, Ontem, após vários testes e comparações, descobrimos o seguinte: Se na propriedade do projeto estiver marcada a opção: Delphi Compiler -> Compiling -> Runtime errors -> Range checking -> True Na unit GZIPUtils.pas, na função: function crc32(thecrc: cardinal; S: TStream; len: Cardinal): Cardinal; Na linha 395: Result := UpdateCrc32(b, Result); Começamos a receber o erro de Range check error. Pelo que verificamos em debug, o escopo do Cardinal é de 0..4294967295, enquanto que a função UpdateCrc32 retorna um tipo Integer que pode ser de -2147483648..2147483647. Logo, ao retornar um valor negativo ou um valor além do escopo do tipo da variável, vai ocasionar a exceção descrita. O demo da ACBr e o outro projeto nosso que não deu erro estava False na propriedade acima. No projeto que apresentava o problema setamos para False, efetuamos um Clean e um Build e voltou a ter o mesmo comportamento dos outros projetos. Com isto, resolvemos o problema. Estamos te passando o que concluímos para uma avaliação. Desde já agradeço.

Juliomar, boa tarde. No demo da ACBr, funciona normal. Com as mesmas configurações, no nosso projeto não está funcionando. Estamos tentando verificar o que pode estar de diferente em ambos os projetos. Já validamos os pacotes instalados e aparentemente está tudo normal. Mas no projeto nosso continua não funcionando. Bem estranho.

Delphi XE2 Update 4 A princípio, efetuando um debug aqui, parece problema do tipo de encoding que está sendo utilizado, ANSI e UTF8.

Fizemos um teste aqui, da seguinte maneira, acrescentamos na unit ACBRNFeWebServices, na function TDistribuicaoDFe.TratarResposta, comando para salvar em arquivo a variável FPRetWS antes de executar FretDistDFeInt.LerXml, foi retornado o arquivo em anexo(teste2.xml). A princípio o arquivo está completo. teste2.xml

Estranho que é uma implementação que não foi alterada. O componente ACBrNFe teria algum timeout que teríamos que setar para este caso? Nos clientes funciona normal. Estamos fazendo uma bateria de testes no sistema e fomos validar esta função e recebemos o erro acima em todos os computadores que testamos.

Boa tarde pessoal, Estou recebendo o erro de Range check error, ao executar o método: ACBrNFe1.DistribuicaoDFePorChaveNFe(0,'65212607000180', '31171110705501000470550010003151641421771140'); Retornando a seguinte mensagem: Não foi possivel importar o XML, tente novamente em alguns segundos! WebService Distribuição de DFe: - Inativo ou Inoperante tente novamente. Range check error Efetuando o debug da função, cheguei que o problema ocorre na função: function UpdateCrc32 (function crc32(thecrc: cardinal; S: TStream; len: Cardinal): Cardinal; Que está implementada na unit GZIPUtils na linha 395 que contêm o comando: Result := UpdateCrc32(b, Result); Debugando passo-a-passo para um melhor entendimento teremos: ACBrNFe -> function TACBrNFe.DistribuicaoDFePorChaveNFe(AcUFAutor: integer; ACNPJCPF, AchNFe: String): Boolean; ACBrNFe -> function TACBrNFe.Distribuicao(AcUFAutor: integer; ACNPJCPF, AultNSU, ANSU, chNFe: String): Boolean; (Linha 909) ACBrDFeWebService -> function TDFeWebService.Executar: Boolean; (Linha 187) ACBrNFeWebServices -> function TNFeEnvEvento.TratarResposta: Boolean; (Linha 2989) pcnRetDistDFeInt -> function TRetEventoNFe.LerXml: Boolean; (Linha 435) ACBrCompress -> function DeCompress(const ABinaryString: AnsiString): AnsiString; (Linha 141) ACBrCompress -> function DeCompress(AStream: TStream): AnsiString; (Linha 154) ACBrCompress -> function DeCompress(inStream, outStream: TStream): Boolean; (Linha 169) GZIPUtils -> function unzipStream(inStream, outStream: TStream): boolean; (Linha 271) GZIPUtils -> function crc32(thecrc: cardinal; S: TStream; len: Cardinal): Cardinal; (Linha 395) => Erro na função UpdateCrc32(b, Result); Retornando: Valor de "b" = 60 Valor de "Result" = 4294967295 Msg de erro: "Range check error" Efetuei o teste com outras chaves, utilizando outros CNPJ, mas o erro persiste. Atualizei o source da ACBr pelo SVN hoje, mas o problema persiste. Gostaria da opinião de vocês sobre este assunto. Houve alguma alteração de propriedade ou atualização de DLL que impactaria neste erro? Desde já agradeço a opinião de vocês.

Boa tarde @Daniel Simoes, segui o seu conselho e o tempo ficou em 1,299 s. Parametrizamos no sistema agora. Agradeço mais uma vez a resposta.

Bom dia pessoal, A algum tempo, temos notado que na impressão das vias do comprovante do TEF nos clientes existe um pequeno atraso na impressão do mesmo, ou seja, quando comparamos com alguns outros frentes de caixa, a impressão parece ser feita de maneira contínua, mais fluída, enquanto que no nosso caso, o ECF aparenta imprimir por partes. Ontem, em um cliente o processo de impressão da via do TEF estava demorando em média duas vezes mais o tempo do processo de venda dos produtos. Estamos tentando analisar, o que poderia estar ocorrendo. No nosso source efetuamos deste modo o processamento do vinculado: procedure TdmVendaECF.TEFComandaECFImprimeVia(TipoRelatorio : TACBrTEFDTipoRelatorio; Via : Integer; ImagemComprovante: TStringList; var RetornoECF : Integer); case TipoRelatorio of trGerencial: begin ... end; trVinculado: begin ecf.AcbrEcf.LinhaCupomVinculado(ImagemComprovante.Text); end; end; Analisando o método ACBrECF.LinhaCupomVinculado vimos a seguinte implementação padrão: if MaxLinhasBuffer < 1 then begin ... end else begin Texto := '' ; Buffer := DecodificarTagsFormatacao( Linha ); Buffer := AjustaLinhas(Buffer, Colunas) ; SL := TStringList.Create ; try SL.Text := Buffer ; For Lin := 0 to SL.Count - 1 do begin Texto := Texto + SL[Lin] + sLineBreak; if (Lin mod MaxLinhasBuffer) = 0 then begin ComandoLOG := 'LinhaCupomVinculado( '+Texto+' )'; fsECF.LinhaCupomVinculado( Texto ) ; Texto := '' ; end ; end ; if Texto <> '' then begin ComandoLOG := 'LinhaCupomVinculado( '+Texto+' )'; fsECF.LinhaCupomVinculado( Texto ) ; end ; finally SL.Free ; end ; end ; Ou seja, pelo que pudemos perceber, recebeu a imagem do comprovante como entrada e em seguida é realizado alguns tratamentos e adicionada para a variável Buffer, em seguida esta variável é associada para um stringlist SL que é percorrido inteiramente, imprimindo linha a linha(posições da mesma). Fizemos uma alteração para teste no seguinte sentido: if MaxLinhasBuffer < 1 then begin ... end else begin Texto := '' ; Buffer := DecodificarTagsFormatacao( Linha ); Buffer := AjustaLinhas(Buffer, Colunas) ; fsECF.LinhaCupomVinculado( Buffer ) ; end ; E obtivemos que na implementação original, foi impresso em média 2,234 s e no teste com o source acima em média 1,341 s isto para cada via, ou seja, no total, ficou 4,468 s e 2,682 s. Estamos utilizando uma Daruma FS700(MACH 1) e o Sitef Demo 6.1.0.23. Gostaríamos da opinião de vocês no seguinte sentido: Existe um modo de agilizar este procedimento de impressão sem ser a alteração acima? O modo padrão implementado acima utilizando uma stringlist, ele seria mais seguro? Haveria algum motivo específico? Desde já agradeço.

Realmente, vou enviar uma notificação para eles.

Também estamos em MG. Quando apontamos para o RS, dá rejeição informando que a IE é inválida em relação a UF informada. Acredito que não liberaram o ambiente de homologação para outros estados como ocorre com o AM. E @Gr@c@, utilizando o AM, além de estarmos somente enviando na versão 3.10, de cada 10 NFC-e gerados, 2 passam, as outras dá erro 404, 500, 0, -1, entre outros.

Bom dia @Solivan, para enviar para a SVRS, como eu setaria no componente da ACBrNFE as propriedades: with ACBrNFe.Configuracoes.Geral do begin IdCSC := ''; CSC := ''; end; with ACBrNFe.Configuracoes.WebServices do begin UF := ''; end; Desde já agradeço.

Entendi. A 4.0 realmente não funciona, toda vez que tentamos recebemos erro 500.

Bom dia @Daniel Simoes, foi setado no cliente: - Velocidade da serial emulada: 115200 - Controle de Fluxo: Via Hardware - Página de código: pc1252 (Conforme link "Homologação Daruma DR-800 D-Printer") - Tabela de comandos: Tabela 1 (Conforme sugestão do Daniel) - Número de colunas na ACBr: 44 + OBS: A impressora utiliza cabo USB, emulando porta na COM5. Funcionou perfeitamente. Agradeço mais uma vez a ajuda.

Boa tarde @Gr@c@, você está conseguindo acessar o webservice de homologação do Amazonas normalmente na versão 4.0? Estava tentando e recebia somente erro 500. Troquei o certificado e passou a autorizar a nota, utilizando o demo da ACBr setado para ve400, na resposta eu recebo versão do layout 3.10.

Bom dia @Daniel Simoes, vamos acessar o cliente e efetuar as configurações. Assim que tiver um retorno, posto um feedback. Agradeço a resposta.

Boa tarde pessoal, Hoje recebemos um cliente que possui um SAT da DIMEP e uma impressora não fiscal DR700. O SAT funcionou perfeitamente, mas ao imprimir o cupom fiscal via ESC/POS, fica conforme a imagem: No ECF está setada as seguintes configurações: No sistema temos: Para a quebra de linha, foi alterado de 48 para 42 colunas e conseguimos melhorar a mesma, mas ainda temos: - No cabeçalho faltou um caractere ficando IMEP - No cupom de cancelamento faltou caractere ficando ADOS DO CUPOM FISCAL... - O código de barras 1D não foi interpretado ficando apenas numérico - Faltou a centralização em alguns blocos do CF-e Vi em um post, que o André citou que a Daruma não segue 100% o protocolo ESC/POS, por isso a ACBr possui uma unit com tratamento em separado. Gostaria de saber se alguém utiliza esta impressora e se possui alguma configuração em que eu poderia melhorar ou setar para corrigir o layout no CF-e para o cliente. Desde já agradeço.

Bom dia Daniel, até o momento não recebemos nenhuma informação a respeito do contato com o Itaú. O que verificamos, por observação, nos testes, foi que quando no número do cheque está discriminado: UA-002175 Ou seja, quando temos o prefixo UA, o valor calculado para o C2 e C3 difere do valor impresso no cheque. Como não tivemos problema com as melhorias implementadas no ACBrCMC7 nos clientes que colocamos para teste, em relação ao cheque TEF, vamos assumir, por enquanto, que foi solucionado esta questão. Caso ocorra algum outro problema, entramos em contato. Agradeço.

Bom dia Daniel, vou verificar com o pessoal do financeiro, para verificar se temos algum contato e validarmos com eles. Qualquer retorno posto aqui um feedback. Agradeço a avaliação.

Mensagem enviada com a foto em anexo.

Posso sim. Como te envio em privado?