Intelliware

Baseado na pergunta acima, a gente no caso, informa o operador para entrar em contato com o suporte para verificarmos o problema com os XML rejeitados, assim que arrumarmos os valores inconsistentes podemos enviar novamente esta venda? Faz 3 dias que estamos tentando achar algo sobre este assunto na documentação e até o momento não obtivemos nenhum sucesso.

Realmente Sérgio. Estava conversando com o pessoal da Daruma e eles me passaram que o cliente não pode sair do estabelecimento sem um comprovante válido e o único modo até o momento é efetuar o máximo possível de testes em ambiente de homologação para reduzirmos os erros em produção.

Agradeço a resposta Sérgio. Informações exatas, só que, por exemplo, para o caixa, efetuando a venda com vários clientes na fila, fica impossível efetuar qualquer alteração no momento. Sobre a contingência de ter internet tranquilo. O problema seria antes, na hora da autenticação para posterior transmissão. Pois sem termos a autenticação do XML não temos comprovante e o cliente ali no caixa iria ficar sem o mesmo?

Boa tarde pessoal, Estamos efetuando algumas melhorias no nosso sistema do SAT e estamos com a seguinte dúvida. Quando for enviar o CF-e para o SAT para autenticação, o mesmo irá validar o XML e em seguida retornar o número do CF-e. O problema seria, caso o XML contenha alguma inconsistência, qual seria a opção de contingência? Criei uma tabela onde guardo o número da sessão, o código de retorno, o código de erro de alerta, o código de referência da SEFAZ, a mensagem de retorno, a mensagem de referência da SEFAZ e a data e hora do sistema. Mas este cupom não foi autenticado e nem transferido para a SEFAZ. No caso eu criaria uma interface para ler os dados do XML e no fechamento do turno o operador poder corrigir as possíveis inconsistências e tentar retransmitir o XML novamente? O cliente ficaria neste caso sem um comprovante de compra? Gostaríamos da opiniões de vocês sobre este assunto. Desde já agradeço.

Entendi Régys. Agradeço a ajuda.

Bom dia pessoal, estamos tentando melhorar o nosso controle sobre as transações do TEF. Gostaríamos de saber, se existe um modo de no SiTEF obter o status da transação nos seguintes casos: CANC.TIM - Cancelado por Timeout NEGADA - Transação negada pela Instituição Autorizadora ESP.RESP - Aguardando resposta do Host (Instituição Autorizadora) CANC.LOC - Cancelada Localmente (através da Manutenção de Pendências). EFET.LOC - Efetivada Localmente. Os outros status: CANC.PDV - Cancelado pelo PDV EFETUADA - Transação efetuada PENDENTE - Transação pendente São os status normais tratados no nosso programa. A idéia é verificarmos, por exemplo, quando o cliente está recebendo muito CANC.TIM, referente a algum problema no TEF ou até mesmo em uma consulta de cheque, traçarmos um perfil de um determinado agente. Desde já agradeço a todos.

No caso do SiTEF, o pessoal da Software Express pode te passar essa listagem.

Show Daniel. Efetuei a implementação aqui. O pessoal já está testando para colocarmos no cliente. Desde já agradeço.

Entendi EMBarbosa. Esta é a parte que apresenta diferenças, nas outras não encontramos nada de suspeito. Vou dar uma olhada no tratamento do NumUltimoItem e no CarregaTotalizadoresNaoTributados. Agradeço a ajuda.

Daniel, boa tarde. Pesquisei no nosso source aqui e em nenhum momento chamamos a função CarregaTotalizadoresNaoTributados. Analisando novamente o log de outro cliente que utiliza a Bematech MP-4000 que funciona normalmente, entre a AbreCupom e o primeiro VendeItem raramente encontramos a função acima. 1) Caixa com problema: -- 08:13:09:528 AbreCupom( , , ) TX -> [STX][4][NUL][FS][NUL][FS][NUL] 08:13:09:528 RX <- ACK = 6 Falha: 0 08:13:09:543 VerificaFimImpressao: Pedindo o Status (19) 08:13:10:428 VerificaFimImpressao: ACK = 6, OK... Aguardando ST1 e ST2 08:13:10:871 RX <- @[NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:13:11:874 CarregaAliquotas TX -> [STX][ENQ][NUL][FS]#[GS]\[NUL] 08:13:11:920 RX <- ACK = 6 Falha: 0 08:13:12:077 RX <- [NUL][SOH]@[NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:13:12:282 TX -> [STX][4][NUL][FS][26]6[NUL] 08:13:12:282 RX <- ACK = 6 Falha: 0 08:13:12:444 RX <- [ENQ][7][NUL][18][NUL][24][NUL]%[NUL]0[NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL]@[NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:13:12:647 CarregaTotalizadoresNaoTributados TX -> [STX]p[NUL][FS]?FF0000011900001000000000000000000000000100000000000000000000UN07896524721018[NUL]LAVA LOUCAS SUPREMA NEUTRO 500[NUL]M[23] 08:13:12:763 RX <- ACK = 6 Falha: 0 08:13:12:935 RX <- @[NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:13:13:357 VendeItem( 07896524721063 , LAVA LOUCAS SUPREMA CLEAR 500M , FF , 1 , 1,19 , 0 , UN , $ , D , -1 ) TX -> [STX]p[NUL][FS]?FF0000011900001000000000000000000000000100000000000000000000UN07896524721063[NUL]LAVA LOUCAS SUPREMA CLEAR 500M[NUL]$[23] 08:13:13:481 RX <- ACK = 6 Falha: 0 08:13:13:645 RX <- @[NUL][NUL][NUL] -- Desativando a porta: COM3 2) Caixa sem problema: -- 08:16:40:171 AbreCupom( , , ) TX -> [STX][4][NUL][FS][NUL][FS][NUL] 08:16:40:191 RX <- ACK = 6 Falha: 0 08:16:40:206 VerificaFimImpressao: Pedindo o Status (19) 08:16:41:193 VerificaFimImpressao: ACK = 6, OK... Aguardando ST1 e ST2 08:16:41:834 RX <- [NUL][NUL][NUL][NUL] -- Desativando a porta: COM1 -- Ativando a porta: COM1 -- 08:16:41:990 VendeItem( 00000000000934 , PAO QJO GRANEL , T01 , 0,194 , 19,98 , 0 , KG , $ , D , -1 ) TX -> [STX]?[NUL][FS]>I0000000000093401KG0000194000199800000[NUL]0000[NUL]PAO QJO GRANEL[NUL][130][FF] 08:16:42:069 RX <- ACK = 6 Falha: 0 08:16:42:194 RX <- [NUL][NUL][NUL][NUL] -- Desativando a porta: COM1 Para chamar a função acima, seria o comando: ecf.ACBrECF.CarregaTotalizadoresNaoTributados; Correto? Verificando o log do caixa com problema, encontramos também o seguinte erro retornado pelo ECF: -- Ativando a porta: COM3 -- 08:34:59:181 NumSerie TX -> [STX][ENQ][NUL][FS]#(g[NUL] 08:34:59:181 RX <- ACK = 6 Falha: 0 08:34:59:337 RX <- BE091410100011247497[NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:34:59:540 GrandeTotal TX -> [STX][ENQ][NUL][FS]#[ETX]B[NUL] 08:34:59:540 RX <- ACK = 6 Falha: 0 08:34:59:712 RX <- [NUL][NUL][NUL][NUL][STX]2Sc6[NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:36:26:924 CarregaTotalizadoresNaoTributados TX -> [STX]g[NUL][FS]?FF0000000500001000000000000000000000000100000000000000000000UN00000000003032[NUL]BALAS SORTIDA 3/ 0,10[NUL][WAK][20] 08:36:27:031 RX <- ACK = 6 Falha: 0 08:36:27:062 RX <- [NUL][SOH]@[NUL] -- Desativando a porta: COM3 ----------------- ERRO ----------------- Erro retornado pela Impressora: Bematech Forma de pagamento aberta ---------------------------------------- -- Ativando a porta: COM3 -- 08:36:30:724 NumUltimoItem TX -> [STX][ENQ][NUL][FS]#[FF]K[NUL] 08:36:30:724 RX <- ACK = 6 Falha: 0 08:36:30:849 RX <- [NUL][STX][NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:36:31:163 NumUltimoItem TX -> [STX][ENQ][NUL][FS]#[FF]K[NUL] 08:36:31:163 RX <- ACK = 6 Falha: 0 08:36:31:295 RX <- [NUL][STX][NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:36:31:498 NumUltimoItem TX -> [STX][ENQ][NUL][FS]#[FF]K[NUL] 08:36:31:498 RX <- ACK = 6 Falha: 0 08:36:31:631 RX <- [NUL][STX][NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:36:35:334 NumUltimoItem TX -> [STX][ENQ][NUL][FS]#[FF]K[NUL] 08:36:35:334 RX <- ACK = 6 Falha: 0 08:36:35:459 RX <- [NUL][STX][NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 E também antes dele temos uma nova chamada para a função CarregaTotalizadoresNaoTributados. Desde já agradecemos a ajuda.

Entendi Daniel. Vamos trocar este cabo. Vou simular aqui o que pode estar ocorrendo com o "CarregaTotalizadoresNaoTributados". Qualquer novidade posto aqui novamente. Agradeço.

Bom dia pessoal, estamos com um problema intermitente em um cliente nosso que utiliza a Bematech MP-4000 TH FI. Segundo o cliente têm hora que o ECF funciona perfeitamente o dia inteiro, mas têm dia que ocorre vários erros ocorrem durante o dia. Analisamos várias vezes os logs do nosso sistema e do ECF, mas infelizmente não conseguimos identificar algum problema. Hoje porém encontramos algumas informações: 1) O cliente reclamou que o ECF não conseguiu fechar o cupom fiscal, no log havia: -- Ativando a porta: COM3 -- 08:36:26:924 CarregaTotalizadoresNaoTributados TX -> [STX]g[NUL][FS]?FF0000000500001000000000000000000000000100000000000000000000UN00000000003032[NUL]BALAS SORTIDA 3/ 0,10[NUL][WAK][20] 08:36:27:031 RX <- ACK = 6 Falha: 0 08:36:27:062 RX <- [NUL][SOH]@[NUL] -- Desativando a porta: COM3 ----------------- ERRO ----------------- Erro retornado pela Impressora: Bematech Forma de pagamento aberta ---------------------------------------- Observando mais acima, podemos verificar que parece que houve interrupção ao subtotalizar o cupom anterior: -- 08:30:58:859 EfetuaPagamento( 01 , 50 , , 0, 0 ) TX -> [STX][20][NUL][FS]H0100000000005000j[ETX] 08:30:58:875 RX <- ACK = 6 Falha: 0 08:30:59:015 RX <- [NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:30:59:218 Estado TX -> [STX][ENQ][NUL][FS]#[WAK]P[NUL] 08:30:59:218 RX <- ACK = 6 Falha: 0 08:30:59:343 RX <- #[NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:30:59:546 Subtotal TX -> [STX][ENQ][NUL][FS]#A[128][NUL] 08:30:59:546 RX <- ACK = 6 Falha: 0 08:30:59:672 RX <- [NUL][NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:30:59:875 TX -> [STX][4][NUL][FS][GS]9[NUL] 08:30:59:875 RX <- ACK = 6 Falha: 0 08:31:00:015 RX <- [NUL][NUL][NUL][NUL][NUL][7][136][NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:31:00:218 TotalPago TX -> [STX][ENQ][NUL][FS]#[22]U[NUL] 08:31:00:218 RX <- ACK = 6 Falha: 0 08:31:00:359 RX <- [NUL][NUL][NUL][NUL][NUL]P[NUL][NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:31:00:562 Estado TX -> [STX][ENQ][NUL][FS]#[WAK]P[NUL] 08:31:00:562 RX <- ACK = 6 Falha: 0 08:31:00:687 RX <- #[NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:31:00:906 CNPJ TX -> [STX][ENQ][NUL][FS]#*i[NUL] 08:31:00:906 RX <- ACK = 6 Falha: 0 08:31:01:062 RX <- 08.835.222/0001-36 [NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:31:01:266 DataHora TX -> [STX][ENQ][NUL][FS]#[23]V[NUL] 08:31:01:266 RX <- ACK = 6 Falha: 0 08:31:01:406 RX <- #[16][NAK][BS])[23][NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:31:01:609 Subtotal TX -> [STX][ENQ][NUL][FS]#A[128][NUL] 08:31:01:609 RX <- ACK = 6 Falha: 0 08:31:01:734 RX <- [NUL][NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:31:01:937 TX -> [STX][4][NUL][FS][GS]9[NUL] 08:31:01:937 RX <- ACK = 6 Falha: 0 08:31:02:078 RX <- [NUL][NUL][NUL][NUL][NUL][7][136][NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 08:31:02:265 Subtotal TX -> [STX][ENQ][NUL][FS]#A[128][NUL] -------------------------------------------------------------------------------- ATIVAR - 23/10/15 08:33:51:246 - Modelo: Bematech - Porta: COM3 - TimeOut: 30 Device: BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE= MAXBANDWIDTH=0 -------------------------------------------------------------------------------- 2) O cliente reportou que houve o registro do item no ECF, mas antes apareceu que houve Falta de energia, no nosso sistema foi registrado o item, mas o cliente não conseguiu fechar o cupom. Observamos no log: -- Ativando a porta: COM3 -- 09:11:15:352 CarregaTotalizadoresNaoTributados TX -> [STX]g[NUL][FS]?FF0000000500001000000000000000000000000100000000000000000000UN00000000003032[NUL]BALAS SORTIDA 3/ 0,10[NUL][WAK][20] 09:11:15:461 RX <- ACK = 6 Falha: 0 09:11:15:625 RX <- [NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 09:11:37:302 NumUltimoItem TX -> [STX][ENQ][NUL][FS]#[FF]K[NUL] 09:11:37:302 RX <- ACK = 6 Falha: 0 09:11:37:443 RX <- [NUL][STX][NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 -- Ativando a porta: COM3 -- 09:11:37:708 Subtotal TX -> [STX][ENQ][NUL][FS]#A[128][NUL] 09:11:37:708 RX <- ACK = 6 Falha: 0 09:11:37:849 RX <- [NUL][NUL][NUL][NUL][NUL] -- Desativando a porta: COM3 Neste momento o comando VendeItem que era para ser chamado a seguir, até as 09:13:03:101 não apareceu no log do ECF. Já trocamos a DLL da Bematech, já inclusive levamos um cabo serial nosso para o cliente e já tentamos várias vezes abaixar e aumentar o buffer da porta serial. Este caixa utiliza o Windows 8 e um cabo de conversão USB-SERIAL. Antes utilizava uma placa PCI Express-SERIAL, mas estava dando muito erro. Gostaríamos da opinião de vocês sobre estes dois casos, uma vez que o problema com este caixa já persiste por um tempo. Estou anexando o log completo para melhor compreensão. Desde já agradeço. LOG_20151023.ecflog

O pior Daniel, foi que no momento que acompanhei fiz o teste com somente o valor 30. Pelo que me foi passado o pessoal da implantação irá enviar o ECF para intervenção. Quando o mesmo retornar eu tento obter mais informações da intervenção de qual seria o problema, se era configuração mesmo ou hardware.

Bom dia pessoal, efetuando um feedback do problema acima. Efetuamos a alteração conforme a imagem em anexo. Não resolveu. Entramos em contato com o pessoal da intervenção e recebemos a seguinte resposta: Possivelmente, o problema é no mecanismo, teríamos que por em intervenção para podermos fazer a troca do mesmo... Pelo programa da impressora não foi resolvido, pois o que indica, é problema mecânico. O pessoal de implantação está verificando junto ao cliente este envio para intervenção. Qualquer novidade volto a reportar aqui. Agradecemos novamente a ajuda.

Valeu Daniel. O download deu certo. Estamos conectando no cliente para efetuar o teste.

Boa tarde pessoal, Estou com um problema ligeiramente diferente do tópico: Desde já peço desculpas, mas resolvi abrir um novo tópico por não ser exatamente o mesmo problema. O cliente possui uma Elgin K nova, é efetuado o corte normalmente, porém não no 'lugar correto'. Anexo a imagem 'Cupom-Tarjado.jpg'. Conforme o outro tópico, o Daniel pediu para utilizar o 'Logg2.exe'. Não consigo efetuar o download pelo link disponibilizado no tópico acima e também no site da Elgin sou redirecionado para uma área de login e não consigo efetuar o download do 'DemoLog'. Será que poderiam disponibilizar um novo link ou postar neste tópico para podermos efetuar um teste no cliente. Desde já agradeço.

Agradeço Régys.

Bom dia pessoal, estamos marcados para efetuar uma consultoria para o MG001 na semana que vêm. Ontem(25/08/2015) efetuei uma atualização do source da ACBr pois também estamos implementando SAT e aconteceu dos seguintes métodos não serem mais reconhecidos pelo componente ACBrPAF: ACBrPAF.SaveFileTXT_R(NomeArquivo); ACBrPAF.SaveFileTXT_E(NomeArquivo); ACBrPAF.SaveFileTXT_D(NomeArquivo); ACBrPAF.SaveFileTXT_P(NomeArquivo); Inclusive, tive que efetuar as alterações abaixo para os novos nomes dos métodos: ACBrPAF.SaveFileTXT_N(dm.NomeArqAutent) -> ACBrPAF.SaveToFile_N(dm.NomeArqAutent) ACBrPAF.SaveFileTXT_RegistrosPAF(nomeArquivo) -> ACBrPAF.SaveToFile_RegistrosPAF(nomeArquivo) ACBrPAF.SaveFileTXT_TITP(NomeArquivo) -> ACBrPAF.SaveToFile_TITP(NomeArquivo) Esses comandos não reconhecidos acima foram trocados por outros ou não serão mais utilizados? Gostaria de saber a opinião de vocês. Desde já agradeço.

Entendi. Habilitei o 'ProcessMessages' e verfiquei que no meu source estava setando timeout para 60 antes de enviar a redução Z. Troquei para 480 e vou efetuar um teste. Qualquer novidade posto aqui.

Realmente Daniel. Fiz uma alteração no source e vou efetuar um teste. Qualquer novidade posto aqui.

Pior Daniel, realmente.

Bom dia Daniel, efetuei o seguinte tratamento: try ecf.ACBrECF.DadosUltimaReducaoZ; ReducaoZ := ecf.ACBrECF.DadosReducaoZClass; DataDoMovimento := ReducaoZ.DataDoMovimento; except on E:Exception do begin NumCRZ_ECF := ecf.AcbrEcf.NumCRZ; if not TryStrToCurr(NumCRZ_ECF, NumCRZ_AAC) then NumCRZ_AAC := 0; if (Pos('RZ CORROMPIDOS', UpperCase(E.Message)) > 0)and(NumCRZ_AAC = 0) then begin ecf.AcbrEcf.DadosReducaoZ; ReducaoZ := ecf.AcbrEcf.DadosReducaoZClass; DataDoMovimento := ReducaoZ.DataDoMovimento; end else begin ShowErrMsg('ERRO:' + E.Message, True, dm.EmitirSomErro); end; end; end; Baseado na mensagem e no valor do CRZ, que no nosso caso, quando o ECF for novo, virá zerado. Acredito que com isso possamos resolver o problema no cliente.

Realmente Daniel, mas lendo outro post em que você comentava com outro colaborador, a gente tinha aumentado o timeout para 480. O ativar do log que te passei está desta maneira: -------------------------------------------------------------------------------- ATIVAR - 13/08/15 12:32:22:983 - Modelo: Daruma - Porta: COM1 - TimeOut: 480 Device: BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE=RTS/CTS HARDFLOW MAXBANDWIDTH=0 -------------------------------------------------------------------------------- Com as configurações acima a gente efetuou o mesmo teste na MACH 1 nossa e sem problemas, efetuamos todos os Z normalmente. Entrei em contato com a Daruma e eles me informaram que a MACH 1 pode trabalhar tanto a 9600 quanto a 115200. Algo que observei no log, não sei se possui alguma correspondência com o problema acima, seria o seguinte erro um pouco antes das 12:32:22: -- 12:29:33:623 DataHora ----------------- ERRO ----------------- Componente ACBrECF ocupado Aguardando resposta do comando anterior ---------------------------------------- -- 12:29:33:623 DataHora ----------------- ERRO ----------------- Componente ACBrECF ocupado Aguardando resposta do comando anterior E o comando 'DataHora' também é último comando a ser lido antes do Z. Estou anexando o log com esta parte que referi acima. Acha que seria interessante aumentar mais esse valor de 480 ou alterar algum parâmetro do ATIVAR da ACBr acima? log-daruma2.TXT

Entendi. Se eu omitir essa mensagem de erro neste caso em específico, a princípio estaria correto pois de fato não existe nenhum Z. Certo? Pois no caso, o sistema captura a exceção e sai do fluxo.

Segundo o cliente, aparece a mensagem, ele pressiona ESC e consegue emitir a redução Z. Só que aparece o erro pra ele, com isso o sistema não continua a emissão enquanto não sair da tela de erro. Realmente, podemos omitir o parâmetro de entrada na procedure da ReducaoZ. Vou fazer um teste no cliente para ver se resolve para ele. Agradeço Daniel.