Intelliware

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?

Boa tarde Daniel, por favor, se precisar de mais alguma informação adicional só avisar.

Boa tarde Daniel, realizamos teste com: - SICOOB - Mercantil do Brasil - Santander - Caixa - Banco do Brasil - Bradesco - Itaú - UniCred Apenas duas observações: 1) Para o Santander retornar o valor de C2 corretamente, foi preciso utilizar a correção proposta neste post: 2) Para o Itaú, eu utilizei dois cheques. O primeiro calculou corretamente. O segundo, cujos dados são: CMC7: 341067330330018805201725766099 Comp: 033 Banco: 341 Agencia: 0673 Conta: 576609 Numero: 001880 C1:1 C2:5 C3:5 O C2 retornado foi 5 no cheque aparece o dígito 3. Os outros cheques não tiveram qualquer tipo de problema, retornando os valores exatos.

Bom dia Daniel, vou começar a fazer os testes aqui. Daqui a pouco te dou um feedback.

Foi esse: 001166340188530155254001781019

O Daniel me passou neste post: Este link: https://www.bcb.gov.br/pre/normativos/busca/downloadNormativo.asp?arquivo=/Lists/Normativos/Attachments/38814/C_Circ_1049_v1_O.pdf Que descreve o funcionamento dos campos C1, C2 e C3. Observe que para C1 temos: Efetuando os cálculos temos exatamente que o resto é 10 na divisão, sendo 153 % 11 = 10. Neste caso não deveria retornar 0(zero)?