Intelliware

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

No caso de SAT para supermercado, deverá ser informado estes campos apartir de 01/04/2016?

Alguém conseguiu alguma informação adicional de como efetuar a condição de contorno para CF-e rejeitado em produção?

Show. Entendi Daniel. É que tivemos que fazer uma modificação específica para um outro caso de controle interno aqui e apesar de fazer os testes e analisar o XML ainda fiquei meio preocupado. Agradeço novamente a explicação. Já atualizei aqui com a correção do SVN.

Daniel, realmente deu certo. Só uma pergunta, no caso acima, quando eu modifico a classe TEntrega, por exemplo, essa propriedade é mapeada para o XML do CF-e, aparecendo posteriormente no arquivo final do processo de venda?

Exato, se apenas temos o destinatário do CF-e não setar automaticamente os dados da entrega. Show, estamos testando aqui. Agradeço.

Então, o cabeçalho está perfeito, sem problema. O que validamos com o source atual, foi que quando utilizamos ESC/POS e identificamos o destinatário do CF-e, automaticamente é mostrado no corpo do extrato o nome do mesmo como sendo para entrega. Conforme o arquivo em anexo. Pelo que vimos, foi um tratamento incluso no tópico: No caso abaixo, não efetuamos a entrada de nenhuma informação para entrega, mas mesmo assim, no corpo do extrato temos DADOS PARA ENTREGA. No nosso caso, informações de entrega são tratadas no nosso AC em módulo separado. Por isso, fizemos a proposta de alteração no source acima.

Opa, sim. Estamos atualizando o source da ACBr praticamente todo dia, pois estamos em testes para liberação da nossa primeira versão do SAT. Sem problema Daniel, foi apenas uma sugestão. Desde já agradeço.

Para o nosso caso, efetuamos nas units as seguintes alterações: procedure TACBrSATExtratoESCPOS.GerarDadosEntrega; //ACBrSATExtratoESCPOS.pas begin if Trim(CFe.Entrega.xLgr)+ Trim(CFe.Entrega.nro)+ Trim(CFe.Entrega.xCpl)+ Trim(CFe.Entrega.xBairro)+ Trim(CFe.Entrega.xMun)+ Trim(CFe.Entrega.xNome) <> '' then begin FBuffer.Add('</fn></linha_simples>'); FBuffer.Add('DADOS PARA ENTREGA'); if Trim(CFe.Entrega.xLgr)+ Trim(CFe.Entrega.nro)+ Trim(CFe.Entrega.xCpl)+ Trim(CFe.Entrega.xBairro)+ Trim(CFe.Entrega.xMun) <> '' then begin FBuffer.Add('<c>'+Trim(CFe.Entrega.xLgr)+' '+ Trim(CFe.Entrega.nro)+' '+ Trim(CFe.Entrega.xCpl)+' '+ Trim(CFe.Entrega.xBairro)+' '+ Trim(CFe.Entrega.xMun)); end; if Trim(CFe.Entrega.xNome) <> '' then FBuffer.Add(CFe.Entrega.xNome); end; end; E na unit 'pcnCFe.pas': { TEntrega } TEntrega = class private FxNome: string; FxLgr: string; Fnro: string; fxCpl: string; FxBairro: string; FxMun: string; FUF: string; public constructor Create; procedure Clear; published property xNome: string read FxNome write FxNome; property xLgr: string read FxLgr write FxLgr; property nro: string read Fnro write Fnro; property xCpl: string read FxCpl write FxCpl; property xBairro: string read FxBairro write FxBairro; property xMun: string read FxMun write FxMun; property UF: string read FUF write FUF; end; Com isso, caso o colaborador, deseja identificar o emitente do CF-e como o destinatário de entrega, efetuaria a atribuição: CFe.Entrega.xNome := CFe.Dest.xNome; E no nosso caso, como utilizamos a tag 'Informações complementares' para efetuar a manipulação dos dados quando existe fechamento na forma de recebimento em 'CLIENTE' mantemos: CFe.Entrega.xNome := ''; Lembrando que é somente uma sugestão. Desde já agradeço.

Bom dia, Notamos que ao identificar um cliente em uma venda utilizando o EscPos, aparece o bloco "Dados para Entrega" com o nome do consumidor, mesmo sem possuir entrega vinculada. Este parâmetro não é registrado no XML, até porque não existe um "nome do destinatário" no leiaute do SAT. Vasculhando o fórum, encontramos o tópico "Nome do destinatario cupom sat", onde foi inserida a linha "Trim(CFe.Dest.xNome)'' na procedure "TACBrSATExtratoESCPOS.GerarDadosEntrega". Há possibilidade de existir um meio termo, afinal não foi identificado entrega no cupom. Obrigado.

Opa, valeu Daniel. Vou dar uma olhada na classe 'RLLayout'.

Bom dia pessoal, Quando vou efetuar a impressão do CF-e no Fortes Report, tenho a opção de mostrar um preview que me exibe em detalhes como irá ser impresso o mesmo no POS. Fiz um relatório de vendas, onde gostaria de apartir do XML da pasta CfeVendas, gerar este mesmo preview para facilitar pro usuário a visualização dos dados. Seria possível efetuar esta implementação? Não estou familiarizado com o fortes, procurei algum exemplo de uso neste sentido e não encontrei. Desde já agradeço qualquer opinião a respeito.

Entendi. Agradeço Daniel.

No caso estamos utilizando o Fortes Report para imprimir o CF-e.

Boa tarde pessoal, No campo de observações do contribuinte teria como em uma determinada linha colocarmos a mesma em negrito? No nosso caso, vamos manter um contador(COO) interno ao banco e gostaríamos de destacar(colocar em negrito) esta informação entre as outras apresentadas ao cliente. Estamos como uma certa dificuldade em rastrear no source onde esta informação é processada para ser impressa na impressora POS. Desde já agradeço.

Blz, Daniel. Vamos implementar aqui.

Blz, Daniel. Agradecemos.

Daniel, boa tarde! Hoje fuçamos um pouco mais sobre este problema e aparentemente conseguimos solucioná-lo, modificando a função "TACBrPosPrinter.TxRx". Primeiramente, limpamos o buffer da porta serial antes do envio dos comandos, resolvendo cerca de 50% dos retornos errôneos. Depois colocamos um "sleep" de 10ms (com 2ms já resolveu) entre a transmissão e a recepção dos bytes, solucionando 100% dos retornos errôneos. Segue o bloco modificado: function TACBrPosPrinter.TxRx(ACmd: AnsiString; BytesToRead: Byte; ATimeOut: Integer; WaitForTerminator: Boolean): AnsiString; begin if FDevice.IsSerialPort then FDevice.Serial.Purge; GravarLog('TX -> '+ACmd, True); FDevice.EnviaString( ACmd ); if FDevice.IsSerialPort then Sleep(10); if WaitForTerminator then Result := FDevice.LeString(ATimeOut, 0, chr(BytesToRead)) else Result := FDevice.LeString(ATimeOut, BytesToRead); GravarLog('RX <- '+Result, True); end;

Só aproveitando, quando peço para gravar a linha em arquivo, vários caracteres especiais são incluídos. A ACBr têm alguma função que possa transformar esses caracteres em representações em forma de string? Facilitaria a leitura.