Intelliware

Bom dia @zenilda. Você conseguiu mais alguma informação sobre o assunto em questão?

Usando 'TCP:' + IP_BALANCA + ':' + PORTA_TCP; Eu consigo ativá-la, mas ao ler o peso cai no timeout. Você conseguiu @rfazevedo?

Para solicitar o QRCode para ser tratado na aplicação, o manual do CARDSE pede para informar: TEFCliSiTef.Restricoes = '{DevolveStringQRCode=1}'; Antes de chamar a função 122.

Boa tarde, Notamos um pequeno errinho de ortografia no extrato gerado via ESC/POS, precisamente na linha 400 da "TACBrSATExtratoESCPOS": if (TotalDescAcresItem <> 0) then begin Sinal := IfThen(TotalDescAcresItem < 0,'-','+'); FPosPrinter.Buffer.Add(PadSpace(ACBrStr('Total de descontos/acrésimos sobre item|')+ FormatFloatBr(TotalDescAcresItem, Sinal+',0.00'), FPosPrinter.ColunasFonteCondensada, '|')); end; Obrigado.

Bom dia, os testes a que me referi acima foram feitos com os fontes atualizados da AcBr, já envolvendo as propriedades adicionadas.

Boa tarde Ala. Estamos cientes que será opcional, mas estamos atualizando nosso sistema e adequando às modificações em forma de configuração, caso algum cliente prefira utilizar o novo leiaute, uma vez que proporciona economia de papel.

Boa tarde, Fizemos alguns testes utilizando as propriedades mencionadas em alguns modelos de impressoras. Na impressora Sweda SI300S, que trabalha com apenas 42 colunas, utilizando o protocolo EscPos, o texto lateral ao QrCode ficou cortado, conforme a figura abaixo: Notamos também que a impressora Bematech não suporta este leiaute, conforme mencionado acima, mesmo forçando ela a trabalhar no protocolo EscPos no aplicativo da bematech. Haverá alguma adequação do leiaute do Fortes Report, como alternativa às impressoras que não suportam o qrCode lateral? Grato.

Boa tarde Graça, era um problema no nosso certificado. Agradeço a resposta e as configurações.

Bom dia pessoal, estávamos efetuando as alterações para NFC-e via webservice do Amazonas, no entanto, tivemos que parar por um tempo para terminar algumas implementações. Ontem, voltamos para finalizar esta parte e quando tentamos efetuar uma consulta simples, obtemos: 'WebService Consulta Status serviço:'#$D#$A'- Inativo ou Inoperante tente novamente.' No caso, passamos da versão 3.10 para a 4.0. Pelo que verifiquei nos tópicos anteriores as URL 4.0 já foram adicionadas na ACBr para homologação. Alguém têm alguma informação a respeito deste processo ou está utilizando um servidor diferente? @Gr@c@ Desde já agradeço a resposta.

Bom dia, Tiago Tarifa Munhoz, agradeço o relatório.

Se possível, se puder me enviar os relatórios para a impressora e o SAT da Control ID eu agradeceria. Também estamos com os equipamentos deles para homologação.

Entendi @Gr@c@. Agradeço a resposta. @Diego Jacaúna agradeço o retorno. Vou efetuar um teste aqui.

Só para tirar uma dúvida, você está utilizando WinCrypt, Capicom ou OpenSSL? E o SSL Type?

Boa tarde. @Gr@c@, você está conseguindo emitir NFC-e 4.0 utilizando o webservice de homologação do Amazonas? Estamos tentando e está dando o erro HTTP 500 - Internal Server Error. Agradeço.

Blz Daniel. Agradeço a resposta.

Bom dia pessoal, Só efetuando um feedback para concluir este tópico, antes de gravar no banco de dados, eu valido o número de sessão com o número da sessão da venda e o código do comando(6000) gravado no componente, com isso, caso seja detectado alguma incoerência, o componente é recarregado conforme citado acima. Este tratamento é adicionado em conjunto com a propriedade ValidarNumeroSessaoResposta, conforme também descrito acima. Um parceiro nosso enviou um e-mail para a Bematech com uma explicação nossa sobre o que ocorre mas não obtivemos retorno, logo, o tratamento ficou somente dentro da aplicação.

Daniel, desculpa a demora do retorno, mas ainda estamos acompanhando o cliente de perto, pois ainda acontece um evento realmente muito incomum no mesmo. No log do evento OnGravarLog do componente ACBrSAT temos a seguinte sequência de comandos: A princípio foi executado uma ConsultarStatusOperacional(2), no intervalo entre enviar os dados da venda e gravar no banco de dados, mas não temos esta instrução no sistema neste intervalo exato. Não utilizamos thread neste caso em nenhum momento. O que é acontece é que chamamos o comando EnviarDadosVenda, validamos se o retorno é 6000 e simplesmente adicionamos os dados no banco. Como a consulta entra no meio do fluxo, os dados do componente mudam lançando exceção. Isso ocorre uma vez ou outra mas força o cancelamento do cupom. Como condição de contorno, realizei o seguinte tratamento: - Criei um record que guarda a resposta de retorno do comando EnviarDadosVenda, o seu respectivo número de sessão logo abaixo da chamada da respectiva instrução e o caminho do arquivo da venda. Isto foi feito pois nos testes quando mandava consultar o número de sessão, o SAT reportava que a sessão não existia(estou em ambiente de homologação), embora no log, estivesse o número de sessão gravado normalmente. - Caso lance exceção eu efetuo os procedimentos: dmSAT.ACBrSAT.CFe.LoadFromFile(SATVendaContencao.CaminhoXML); dmSAT.ACBrSAT.Resposta.RetornoStr := SATVendaContencao.RespostaSessao; Nos testes, o procedimento funcionou, lançou a exceção, mas recarregou os dados e confirmou a venda. Você já viu algo parecido em relação a isso?

Excelente Daniel. Agradeço a ajuda.

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.