Intelliware

Sobre o teste do arquivo, sim, o texto está completo.

1. Não sei te dizer, pegamos este problema internamente ontem, mas acredito que não pois diversos testes semelhantes foram feitos em versões mais antigas e nunca notamos tal problema; 2. Sim, o problema ocorreu no ECF Daruma FS700; 3. A partir da linha "<e>MARIA DA SILVA</e>" ele corta o restante e já imprime o rodapé; 4. Utilizo o Delphi XE2. Obs.: nosso " MaxLinhasBuffer" está setado em 3, se aumento, não muda nada, agora se passo 0, como do ecfTeste, passando para o primeiro bloco do if, imprime normalmente.

Daniel, fizemos os testes com sua atualização, mas não resolveu. Uma informação que ficou faltando na postagem é que o problema ocorreu em um ECF Daruma. Fizemos os testes também em uma Sweda, mas nela não ocorreu a perda de informação, com o mesmo texto. O EcfTeste não passou por este bloco, ele entrou no primeiro if "if MaxLinhasBuffer < 1 then", logo não ocorreu o problema. Agora, se forço a passar para o "else", ocorre o mesmo problema. Segue o texto que fizemos os testes: </linha_dupla> <ce>ENDEREÇO DE ENTREGA</ce> <ce>REF. AO CUPOM: 013671 - VIA: 01/01</ce> <ce>VALOR TOTAL: R$ 7,39</ce> </linha_dupla> CLIENTE: <e>MARIA DA SILVA</e> DATA: 23/03/2016 HORA: 15:54:54 OPR: ADMIN </linha_simples> QUANTIDADE DE CAIXA(S): <e>001</e> END.: <e>RUA DA SAUDADE</e> <e>208,JARDIM YARA</e> <e>POUSO ALEGRE,MG,37.550-</e> <e>000</e> TEL.: <e>(35)9999-9999 (CELUL</e> <e>AR PESSOAL)</e> </linha_simples> VASSOURA: <e>1</e> <e>OVOS</e> CONGELADOS: <e>congelado</e> FARDOS: <e>2</e> CAIXAS: <e>1</e> </linha_simples> EMP.: <e>ZE</e> 'Nº das caixas/Adicional: <e>teste adicional</e> </linha_simples> Waldir, estamos com os fontes atualizados há umas 3 semanas, versão que instalamos nos nossos clientes. O interessante é que apenas trocando o "SL.Text := Buffer ;" por "SL.add(Buffer);" resolve nosso problema. Obrigado pela atenção.

Bom dia, Identificamos em nossos testes internos que, em alguns casos, o conteúdo do relatório gerencial está sendo cortado durante a impressão. Nós estamos chamando a impressão através da "ACBrECF.RelatorioGerencial(ECF_lstRG, Vias, Indice);". O estranho é que não são todos os relatórios em que ocorre a perda de informação. Em debug, notamos que o problema ocorre na procedure "TACBrECF.LinhaRelatorioGerencial", precisamente na linha "SL.Text := Buffer ;": if MaxLinhasBuffer < 1 then begin ComandoLOG := 'LinhaRelatorioGerencial( "'+Linha+'", '+IntToStr(IndiceBMP)+' )'; fsECF.LinhaRelatorioGerencial( DecodificarTagsFormatacao( Linha ), IndiceBMP ) ; 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 TentaImprimirLinhas( Texto, IndiceBMP ) ; Texto := '' ; end ; end ; if Texto <> '' then TentaImprimirLinhas( Texto, IndiceBMP ) ; finally SL.Free ; end ; end ; Conseguimos contornar o problema trocando o "SL.Text := Buffer ;" por "SL.add(Buffer);", ficando o trecho acima da seguinte forma: if MaxLinhasBuffer < 1 then begin ComandoLOG := 'LinhaRelatorioGerencial( "'+Linha+'", '+IntToStr(IndiceBMP)+' )'; fsECF.LinhaRelatorioGerencial( DecodificarTagsFormatacao( Linha ), IndiceBMP ) ; end else begin Texto := '' ; Buffer := DecodificarTagsFormatacao( Linha ); Buffer := AjustaLinhas(Buffer, Colunas) ; SL := TStringList.Create ; try //SL.Text := Buffer ; SL.add(Buffer); For Lin := 0 to SL.Count - 1 do begin Texto := Texto + SL[Lin] + sLineBreak; if (Lin mod MaxLinhasBuffer) = 0 then begin TentaImprimirLinhas( Texto, IndiceBMP ) ; Texto := '' ; end ; end ; if Texto <> '' then TentaImprimirLinhas( Texto, IndiceBMP ) ; finally SL.Free ; end ; end ; Gostaríamos da opinião de vocês. Obrigado.

Opa, desculpa a demora Régys. Vou parametrizar essa propriedade e colocar no cliente. Agradeço.

Show Daniel. Agradeço.

Realmente Régys, eu também acredito que a Daruma não seria o problema, inclusive temos uma Mach1 que a nosso ver não apresenta lentidão. Estamos logando e repassando na ponta do lápis todos os tempos de execução das funções no frente caixa para tentar achar algo que possamos melhorar também, além de estar repassando para vocês algumas partes dos logs referente ao ECF que estamos obtendo. Estou enviando para você um printscreen das propriedades do componente 'ACBrECF' que está setada no nosso sistema. Só algumas observações: 1) 'ControlePorta' no cliente está TRUE. 2) Conforme você perguntou, o comando 'IntervaloAposComando' está em '300'. Desde já agradeço, Régys.

Daniel, boa tarde, Haveria um modo de implementar um evento chamado, por exemplo, 'OnGetResposta' no componente ACBrSAT? Neste caso, poderíamos mapear o retorno de todas as respostas do SAT mais facilmente, o que poderia até ser mais fácil para verificarmos se em algum comando que efetuamos a SEFAZ retornou alguma mensagem específica e já exibirmos em primeira mão para o cliente. Apenas uma idéia, que a meu ver poderia ser interessante. O que acha?

Boa tarde Régys, eu só anexei um log referente ao tópico (1) deste mesmo tópico. Conforme abaixo: 1) Os ECFs estão lentos em relação aos outros que não foram trocados, ou seja, o fechamento do cupom com venda normal é um pouco mais devagar e que quando ocorre emissão de fechamento com CCD o desempenho chega a ser crítico. Mas qualquer coisa, se precisar abro um novo tópico. Sem problema.

Exato dorivansousa, conforme o Juliomar disse, é no nome da empresa do cliente, vi essa informação posteriormente, mas esqueci de atualizar aqui.

Pessoal, boa tarde. Eu obtive o log de um CCD em relação a lentidão reportada no tópico (1). Anexei abaixo. Observe que o CCD abre as '22:08:29:359 hrs' e fecha '22:08:46.867 hrs', uma diferença de '17,508 s' o que faz com que os caixas reclamem muito da demora. Será que é algum problema no ECF ou alguma configuração do nosso sistema que poderia estar ocasionando este delay? Log_CCD_ACBr.TXT

Boa tarde pessoal, só reportando de volta para vocês o que fizemos. Entramos em contato com o cliente e cadastramos uma forma de pagamento CREDITO e DEBITO e em seguida efetuamos as devidas correlações com as nossas formas de recebimento por modalidade. Com isso não tivemos mais problema com este cliente até o momento. Desde já agradeço. Qualquer novidade volto a repassar as informações para vocês.

Tranquilo!

Juliomar, só para confirmar uma dúvida que surgiu, sobre a assinatura do XML dos arquivos do Bloco X, vi que temos que utilizar um certificado no nome da SoftwareHouse para o processo, conforme descrito no post utilizando CAPICOM: Neste caso, vai ter que em cada caixa efetuar a instalação do nosso certificado, correto?

hehehe blz. Valeu.

Show Juliomar. Só pra complementar, no estoque quando estou obtendo os dados do mesmo no caixa, obtenho a quantidade especificada para TODO o estoque ou somente para os produtos vendidos no respectivo caixa no intervalo de data especificado?

Boa tarde pessoal, estamos adequando nosso sistema para homologação 02.03. Li vários tópicos no fórum e também a documentação disponibilizada pelo Régys e outros colaboradores. Ajudou bastante, mas ficaram algumas dúvidas. Seguem: 1) O Requisito LIX(Estoque) possui: DataReferencialInicial - Data inicial de referência do Estoque. Se o estoque se refere ao período entre 01/08/2015 e 01/09/2015, a data de referência será 01/08/2015. DataReferencialFinal - Data final de referência do Estoque. Se o estoque se refere ao período entre 01/08/2015 e 01/09/2015, a data final de referência será 01/09/2015 No meu entendimento, a idéia seria verificar os produtos em estoque, seguindo o exemplo acima do dia 01/08/2015 a 01/09/2015 e a quantidade dos mesmos no referido intervalo? Pelo que entendi, essas informações teriam que serem avaliadas apartir do sistema da retaguarda, não? Uma vez que um único caixa não teria condição de ter esta informação precisa em um supermercado de 14 caixas, por exemplo. 2) Requisito LVIII(Redução Z) possui: Nome - Identificação de cada Totalizador Parcial relativo á respectiva Redução Z. Acredito que o mesmo se refere ao campo: ecf.ACBrBlocoX.ReducoesZ.TotalizadoresParciais.Add.Identificao Neste caso, este identificador seria uma especificação minha? Se eu colocar o ID da tabela R60M que se refere a redução Z que estou arquivando seria válido? Desde já agradeço a ajuda de vocês. Desculpem se as questões acima já foram respondidas em algum outro tópico.

Sim, concordo plenamente. Hoje a tarde, no mais tardar amanhã vamos acessar o cliente e posto os logs aqui para verificarmos melhor.

Então, no nosso caso, o projeto é construído inteiramente utilizando o ACBr. Não fazemos chamada no AC diretamente na DLL da Daruma. Eu posso estar equivocado, mas acredito que no caso do espelho é executada uma chamada para a 'DarumaFramework'. Na unit 'ACBrECFDaruma.pas': 1) Linha 49: cLIB_Daruma = 'DarumaFrameWork.dll'; 2) Linha 5159: DarumaFunctionDetect('rGerarEspelhoMFD_ECF_Daruma', @xrGerarEspelhoMFD_ECF_Daruma); 3) Linha 5326: procedure TACBrECFDaruma.EspelhoMFD_DLL(COOInicial, COOFinal: Integer; NomeArquivo: AnsiString; Documentos: TACBrECFTipoDocumentoSet); procedure TACBrECFDaruma.EspelhoMFD_DLL(DataInicial, DataFinal: TDateTime; NomeArquivo: AnsiString; Documentos: TACBrECFTipoDocumentoSet); Na unit 'ACBrECF.pas': procedure TACBrECF.PafMF_MFD_Espelho(const COOInicial, COOFinal: Integer; const PathArquivo: String); procedure TACBrECF.PafMF_MFD_Espelho(const DataInicial, DataFinal: TDateTime; const PathArquivo: String); Posteriormente chamamos: ecf.AcbrEcf.PafMF_MFD_Espelho(CrzInicial, CrzFinal, Path); ecf.AcbrEcf.PafMF_MFD_Espelho(Inicio, Termino, Path);

Bom dia pessoal, Temos um cliente que a um pouco mais de 2 meses, substituiu parte dos ECFs deles adquirindo 4 Daruma MACH 2. O caixa que o cliente mais reclamou está operando a 9.600 de baudrate e o software básico é a versão 01.00.00. Depois que subtituímos os ECFs pelos novos o cliente nos reportou que: 1) Os ECFs estão lentos em relação aos outros que não foram trocados, ou seja, o fechamento do cupom com venda normal é um pouco mais devagar e que quando ocorre emissão de fechamento com CCD o desempenho chega a ser crítico. 2) Quando efetua a emissão do espelho nos ECFs a numeração dos COO não sai em sequencial, pulando alguns. Os itens acima foram constatados pelo cliente que a princípio utilizava a DarumaFramewok 9.0.21(32 bits). Enviamos para manutenção um dos ECFs que não constatou problema. Efetuamos então alguns testes no cliente e o mesmo verificou que com a DarumaFramework 8.17.8(32 bits), a venda tinha uma performance melhor e a numeração do espelho ficava sequencial, não apresentando problema. Fomos informados pelo suporte que a DarumaFramework 9.0.21(32 bits) apresentava no espelho o problema de pular os COO e que eles já haviam solicitado uma correção. Fomos então orientados a utilizar a última versão DarumaFramework 10.5.1.0(32 bits). Esta última versão o cliente reportou que apresentou uma ligeira melhora na velocidade mas constatamos que ainda pulava a numeração do COO ao emitir o espelho. Por esta razão deixamos no cliente a versão DarumaFramework 8.17.8(32 bits). O suporte nos pediu um arquivo de auditoria para poder analisar este caso, habilitando as seguintes tags no arquivo DarumaFramework.xml: <START> <LocalArquivos>.\</LocalArquivos> .... <ECF> .... <Auditoria>1</Auditoria> E no caso da lentidão pediu para verificarmos a tag: <START> .... <Produto>ECF</Produto> ... <ECF> ... <PortaSerial>COM1</PortaSerial> .... <Velocidade>9600</Velocidade> Com isso seria gerado o arquivo Auditoria_ECF.txt que iríamos passar para o suporte deles para conseguirmos identificar o que está ocorrendo no cliente. Habilitamos no cliente, mas o arquivo em questão não é gerado. Os nossos questionamentos são: 1) O arquivo acima não está sendo gerado pelo fato de utilizarmos a biblioteca da ACBR? 2) Temos algum outro modo de passarmos esta informação para o suporte? 3) Alguém já enfrentou o problema de lentidão ou o fato de pular o COO na emissão do espelho conforme descrito acima? Desde já agradeço. Gostaríamos de saber a opinião de vocês.

Entendi Daniel. Realmente estranho este erro. Vou tentar fazer mais testes aqui.

Sim, utilizamos o ACBrTEFD. Realmente, tinha debugado no source, se não me engano é na: procedure TACBrTEFD.AgruparRespostasPendentes(var Grupo : TACBrTEFDArrayGrupoRespostasPendentes); O estranho é que no emulador da 2100 eu consegui reproduzir o erro, mas agora o emulador parou também, vou tentar reinstalar. Infelizmente o nosso ECF da Bematech 2100 está com problema e está indo para assistência. Assim que tiver mais informações eu posto aqui. Só uma observação, mesmo a modalidade da forma de pagamento estar setada para CRÉDITO e a outra DÉBITO para a mesma sequência no ECF deveria agrupar tudo em um único CCD?

Boa tarde Daniel, com um único pagamento na Forma "04" o CCD funciona normalmente. Estamos entrando em contato com o cliente para separarmos as formas de crédito e débito em duas sequências no ECF diferentes.

Boa tarde Juliomar e Daniel. De fato, a forma '04' chama 'CARTAO'. E permite vinculado. MEIOS DE PAGAMENTO Nº Meio Pagamento Valor Acumulado ( R$) 01 Dinheiro 0,00 02 VISA (V) 0,00 03 MASTER CARD (V) 0,00 04 CARTAO (V) 0,00 05 BANCRED (V) 0,00 06 CHEQUE A VISTA (V) 0,00 07 PRAZO (V) 0,00 08 CARTÕES BALCÃO (V) 0,00 09 VALE COMPRAS (V) 0,00 10 CHEQUE A PRAZO (V) 0,00 11 TICKET PAPEL (V) 0,00 12 CARTÕES BALCÇO (V) 0,00 13 FUNCIONARIOS (V) 0,00 Comprovante Não Emitido: 0000 Tempo Emitindo Doc. Fiscal: 00:00:00 Tempo Operacional: 04:58:50 Qtd. Reduções Restantes: 3034 Número série MFD:392204120000075316 ------------------------------------------------ BEMATECH MP-4000 TH FI ECF-IF VERSÃO:01.00.02 ECF:018 LJ:0001 QQQQQQQQQWUTIOYUUI 31/01/2016 09:27:53 FAB:BE091510100011256895 BR E neste mesmo meio de pagamento '04' foi associada uma forma de recebimento CARTÃO DE CRÉDITO e uma forma de recebimento CARTÃO DE DÉBITO. Que foram as duas formas utilizadas para fechar o cupom acima.

Bom dia pessoal, Um cliente nosso que utiliza o ECF Bematech MP-4000 TH FI, nos reportou que em um dos caixas dele quando passa dois cartões no mesmo cupom, o mesmo é cancelado. Este post têm referência em termos de erro com o post a seguir: Só que no caso, utilizamos o CliSiTEF da Software Express. Analisando o log do nosso sistema, obtivemos: [31/01/2016 10:23:21] [INICIO]Impressão das transações pendentes! ---------------------------------------------------------------------------------------- [31/01/2016 10:23:58] [TRATAMENTOAPOSECF]Erro ocorrido durante a impressão do cupom vinculado! ---------------------------------------------------------------------------------------- [31/01/2016 10:23:58] [TRATAMENTOAPOSECF]Exceção lançada na impressão/confirmação do TEF! - ERRO: Erro ocorrido durante a impressão do cupom vinculado! ---------------------------------------------------------------------------------------- Analisando o log do ECF: -- 10:23:22:964 TX -> [STX]([NUL][FS]BCARTAO 00000000024095056934G[7] 10:23:23:011 RX <- ACK = 6 Falha: 0 10:23:23:027 VerificaFimImpressao: Pedindo o Status (19) 10:23:23:058 VerificaFimImpressao: ACK = 6, OK... Aguardando ST1 e ST2 10:23:23:058 RX <- [NUL][SOH][FS][NUL] ----------------- ERRO ----------------- Erro retornado pela Impressora: Bematech Comprovante de crédito ou débito não permitido ou já emitido ---------------------------------------- -- 10:23:23:058 TX -> [STX][20][NUL][FS]BCARTAO X[ETX] 10:23:23:089 RX <- ACK = 6 Falha: 0 10:23:23:089 VerificaFimImpressao: Pedindo o Status (19) 10:23:23:120 VerificaFimImpressao: ACK = 6, OK... Aguardando ST1 e ST2 10:23:23:120 RX <- [NUL][SOH][FS][NUL] ----------------- ERRO ----------------- Erro retornado pela Impressora: Bematech Comprovante de crédito ou débito não permitido ou já emitido ---------------------------------------- -- 10:23:27:576 Estado TX -> [STX][ENQ][NUL][FS]#[WAK]P[NUL] 10:23:27:591 RX <- ACK = 6 Falha: 0 10:23:27:716 RX <- [NUL][NUL][NUL][NUL] O cupom foi fechado nas seguintes formas: -- 10:23:13:714 EfetuaPagamento( 04 , 124,07 , , 0, 0 ) TX -> [STX][20][NUL][FS]H0400000000012407v[ETX] 10:23:13:745 RX <- ACK = 6 Falha: 0 10:23:13:870 RX <- [NUL][NUL][NUL][NUL] -- 10:23:13:870 EfetuaPagamento( 04 , 116,88 , , 0, 0 ) TX -> [STX][20][NUL][FS]H0400000000011688[128][ETX] 10:23:13:901 RX <- ACK = 6 Falha: 0 10:23:14:041 RX <- [NUL][NUL][NUL][NUL] Como não consegue imprimir o CCD, é aberto o relatório gerencial em seguida. Mas a princípio não conseguimos detectar o que pode estar ocorrendo. Anexei o log do cupom em questão, caso necessitem de mais detalhes. Anexei também um espelho do cupom em questão. Atualizamos a DLL da Bematech para a última versão para verificarmos se vai ajudar. Temos vários outros clientes com este mesmo ECF e o problema não ocorre. Gostaríamos da opinião de vocês sobre este problema. Desde já agradeço. ACBr-20160212.TXT ACBr-Espellho-20160212.TXT