Intelliware

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.

Daniel, bom dia, Desculpa a demora. Efetuamos testes com a gaveta e foi normal, não houve perda de comunicação neste processo. Após setar as configurações acima, o problema de perda de comunicação tinha caído para 2 por dia. No entanto, no começo da semana, o cliente voltou a entrar no atendimento dizendo que estava novamente com problema toda hora, analisando os logs, era o mesmo erro de leitura da porta. Como última solução, o pessoal do suporte, adquiriu uma impressora EPSON e levou para o cliente, uma vez que os outros caixas são desta marca e não tivemos nenhuma reclamação de perda de comunicação.

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, vou fazer uns testes aqui.

Daniel, só uma pergunta. No caso de abrirmos a gaveta, a impressora entra no status stGavetaAberta, enquanto a gaveta não for fechada, ela não conseguirá efetuar uma impressão?

Bom dia Daniel, O cabo da impressora é novo, foi trocado. Foi adicionado a pasta e os arquivos de execução na exceção do anti-vírus. Olhando nos aplicativos instalados na máquina, não conseguimos identificar nenhum que fizesse algum acesso na porta. Só adicionando a parte do log aqui em que foi reportado os dois únicos problemas de ontem: CASO 01) (** LOG SISTEMA **) [28/08/2018 15:12:13] [VALIDARATIVOSAT] A impressora não está em operação. (** LOG POS **) ---------------------------------------------------------------------------------------- [28/08/2018 15:12:11] [POS_VALIDARSTATUS][VERIFICARSTATUSERRO](#01)Status detectado: stErroLeitura ---------------------------------------------------------------------------------------- [28/08/2018 15:12:12] LOG: TX -> [GS][248]1 ---------------------------------------------------------------------------------------- [28/08/2018 15:12:12] [POS_VALIDARSTATUS][VERIFICARSTATUSERRO](#01)Status detectado: stErroLeitura ---------------------------------------------------------------------------------------- CASO 02) (** LOG SISTEMA **) [28/08/2018 16:50:12] [VALIDARATIVOSAT] A impressora não está em operação. (** LOG POS **) ---------------------------------------------------------------------------------------- [28/08/2018 16:50:10] [POS_VALIDARSTATUS][VERIFICARSTATUSERRO](#01)Status detectado: stErroLeitura ---------------------------------------------------------------------------------------- [28/08/2018 16:50:11] LOG: TX -> [GS][248]1 ---------------------------------------------------------------------------------------- [28/08/2018 16:50:11] [POS_VALIDARSTATUS][VERIFICARSTATUSERRO](#01)Status detectado: stErroLeitura ---------------------------------------------------------------------------------------- Notei que no comando ativar, mostrado abaixo: -------------------------------------------------------------------------------- ATIVAR - 28/08/18 16:50:50:725 - Modelo.: EscBematech - TimeOut: 30 - Serial.: COM7 - BAUD=115200 DATA=8 PARITY=N STOP=1 HANDSHAKE= MAXBANDWIDTH=0 SENDBYTESCOUNT=1024 SENDBYTESINTERVAL=100 -------------------------------------------------------------------------------- A propriedade MAXBANDWIDTH encontra-se zerada. Ela poderia ocasionar algum tipo de problema de comunicação?

Daniel, boa tarde, Coloquei no cliente a seguinte configuração: ACBrPOSPrinter.Device.SendBytesCount=1024 ACBrPOSPrinter.Device.SendBytesInterval=100 ACBrPOSPrinter.Device.TimeOut=30 ACBrPOSPrinter.LinhasBuffer=30 Estabilizou, pois estava ocorrendo problema de porta a todo momento, mas mesmo assim houve em 1 dia, dois erros de leitura da porta. Em relação aos valores acima, acha que poderia melhorar algum valor ou até mesmo setar alguma outra propriedade? Desde já agradeço.

Vou tentar efetuar um teste no cliente utilizando este valor variável, para vermos o efeito.

Daniel, Na verdade, estou tentando resolver o erro de transmissão, que é o erro de leitura que ocorre na porta emulada. Já trocamos de porta e atualizamos o driver, revisamos procedimentos, mas o cliente ainda continua reclamando que têm dia que trabalha normalmente, de repente, apresenta erro de comunicação. Com essa informação, estamos tentando utilizar a opção serial para ver se eliminamos este erro intermitente.

Daniel, Realmente, setar a opção ControlePorta gerou uma série de erros adicionais e foi desabilitada. Foi adicionada uma interface serial na impressora com o objetivo de eliminar a dependência do driver conversor da Bematech. No entanto, começou a ocorrer o seguinte erro: ---------------------------------------------------------------------------------------- [24/08/2018 10:29:06] [POS_ImpressaoGeral]FALHA ao imprimir: Erro ocorrido durante a impressão: Communication error 9997: Timeout during operation ---------------------------------------------------------------------------------------- Em anexo, foi adicionado o arquivo de log da POS na data e hora em questão. Testamos com velocidade de 9600, 38400 e 115200, controlando fluxo via hardware e sem. Somente na velocidade de 9600, temos impressão do cupom fiscal eletrônico e do cancelamento do mesmo, no entanto, se tentarmos, utilizar o comando ACBrPosPrinter.Imprimir(texto), é gerado o erro acima em todos os casos. Nas outras velocidades a impressora nem é ativada. ACBrLog20180824.txt

Bom dia Daniel, agradeço a resposta. Vou verificar aqui.

Boa tarde Daniel, A impressora retornou em log o seguinte problema: [22/08/2018 15:46:25] LOG: TX -> [GS][248]1 ---------------------------------------------------------------------------------------- [22/08/2018 15:46:25] [POS_VALIDARSTATUS][VERIFICARSTATUSERRO](#01)Status detectado: stErroLeitura ---------------------------------------------------------------------------------------- Pedi para habilitar a opção de ControlePorta da ACBrPOSPrinter e também instalar a versão mais atual do driver da impressora. Seria este o procedimento correto ou teria alguma outra opção que poderia ser validado no cliente?

Boa tarde Daniel, Realmente, não tinha visto que existe o parâmetro 'Tentativas'. Eu fiz um loop interno para em caso de erro, efetuar uma nova tentativa. Vou efetuar uma alteração para utilizar a informação do próprio componente. Enquanto isso, adicionei uns logs para tentar validar o status que a impressora POS está retornando, enquanto também não atualizo para a versão que você subiu hoje de manhã. -- ACBrPosPrinter -- [*] Métodos LerInfoImpressora e LerStatusImpressora modificados para inserir Entrada e Resultado no Log Agradeço mais uma vez a ajuda. Qualquer informação nova, posto aqui.

Bom dia pessoal, Temos um cliente que possui a impressora POS Bematech MP4200. A mais de uma semana que está dando problema em ambos os caixas do cliente de transmissão. O cliente efetua a venda de alguns cupons e acontece erro na impressora. Olhando os logs do nosso sistema, temos: ---------------------------------------------------------------------------------------- [17/08/2018 18:16:54] [VALIDARATIVOSAT] A impressora não está em operação. ---------------------------------------------------------------------------------------- Analisando o log do componente ACBrPOSPrinter, foi verificado que em todos os momentos que recebemos este erro, é logado: -- 17/08 18:16:19:811 - TraduzirTag(</corte_total>) -> [LF] [LF] [LF] [LF] [LF] [LF] [LF][ESC]w -- 17/08 18:16:19:826 - EnviarStringDevice( [ESC]@[GS][249] [NUL][ESC]2[ESC]a[SOH][FS]p[SOH][NUL][LF][ESC]************[ESC]F[LF][ESC][15]**************[LF][ESC]a[SOH][ESC][15]RE Informatica Ltda[LF][ESC]a[SOH][ESC][15]www.iws.com.br[LF][ESC]@[GS][249] [NUL][ESC]2[LF] [LF] [LF] [LF] [LF] [LF] [LF] [LF][ESC]w[LF]) -- 17/08 18:16:24:818 - TX -> [GS][248]1 -- 17/08 18:16:25:832 - TX -> [GS][248]1 -- 17/08 18:16:26:846 - TX -> [GS][248]1 -- 17/08 18:16:27:860 - TX -> [GS][248]1 -- 17/08 18:16:28:874 - TX -> [GS][248]1 -- 17/08 18:16:29:888 - TX -> [GS][248]1 -- 17/08 18:16:30:902 - TX -> [GS][248]1 -- 17/08 18:16:31:916 - TX -> [GS][248]1 -- 17/08 18:16:32:930 - TX -> [GS][248]1 -- 17/08 18:16:33:944 - TX -> [GS][248]1 -- 17/08 18:16:34:958 - TX -> [GS][248]1 -- 17/08 18:16:35:972 - TX -> [GS][248]1 -- 17/08 18:16:36:986 - TX -> [GS][248]1 -- 17/08 18:16:38:000 - TX -> [GS][248]1 -- 17/08 18:16:39:014 - TX -> [GS][248]1 -- 17/08 18:16:40:028 - TX -> [GS][248]1 -- 17/08 18:16:41:042 - TX -> [GS][248]1 -- 17/08 18:16:42:056 - TX -> [GS][248]1 -- 17/08 18:16:43:070 - TX -> [GS][248]1 -- 17/08 18:16:44:084 - TX -> [GS][248]1 -- 17/08 18:16:45:098 - TX -> [GS][248]1 -- 17/08 18:16:46:112 - TX -> [GS][248]1 -- 17/08 18:16:47:126 - TX -> [GS][248]1 -- 17/08 18:16:48:140 - TX -> [GS][248]1 -- 17/08 18:16:49:154 - TX -> [GS][248]1 -- 17/08 18:16:50:168 - TX -> [GS][248]1 -- 17/08 18:16:51:182 - TX -> [GS][248]1 -- 17/08 18:16:52:196 - TX -> [GS][248]1 -- 17/08 18:16:53:210 - TX -> [GS][248]1 Observei que ao efetuar a ativação do equipamento são utilizados estes parâmetros: -------------------------------------------------------------------------------- ATIVAR - 17/08/18 18:24:58:995 - Modelo.: EscBematech - TimeOut: 3 - Serial.: COM7 - BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE= MAXBANDWIDTH=0 SENDBYTESCOUNT=0 SENDBYTESINTERVAL=0 -------------------------------------------------------------------------------- Gostaria da opinião de vocês sobre este assunto. Desde já agradeço.

Bom dia Italo, estou tendo esse mesmo problema, ao tentar manifestar Ciência da Operação em uma NF-e, é retornado o erro 282, "Rejeicao: Certificado Transmissor sem CNPJ". Conseguiram algum informação a respeito? Eu consigo fazer a consulta das NF-e destinadas ao CPF sem problemas, mas ao tentar a manifestação ocorre esse erro. Ao buscar se existia alguma limitação por parte do SEFAZ, encontrei a NT 2017/002 Versão 1.02b de Maio/2017 com a seguinte redação na pagina 9, item 3.4.2 "CNPJ ou CPF do Interessado no DF-2" "Informar o CPF da pessoa física ou CNPJ da empresa para recuperação de DF-e de seu interesse. Este campo possibilita que uma empresa consiga recuperar os DF-e de qualquer um de seus estabelecimentos utilizando somente um certificado digital PJ." Nada fala sobre a manifestação, mas considerando que para recuperar o documento completo é necessário realizar a manifestação, fica subentendido que seria possível se manifesta usando um e-CPF. Segue em anexo o XML de pedido e de retorno. Obrigado 1-ped-eve.xml 1-eve.xml

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.

Boa tarde Daniel, efetuamos um outro teste em um cliente que utiliza a mesma infraestrutura de TEF e este bloco em específico demorou 360 ms. Estamos monitorando o cliente para tentar detectar maiores informações. Habilitamos o log da DLL da CliSiTEF. Agradeço a resposta.

Boa tarde pessoal, Recebemos uma reclamação de um cliente nosso, que a partir do momento em que recebe na tela a mensagem de aprovado e é impresso no ECF, está lento. Estava analisando o log do componente ACBrTEFD e verifiquei o seguinte: -- 18/06 07:20:11:854 - ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = -- 18/06 07:20:45:596 - *** ContinuaFuncaoSiTefInterativo, Finalizando: STS = 0 Somente no bloco acima, que loga parte da função ContinuaFuncaoSiTefInterativo temos uma demora de 34 segundos. A princípio pelo que tenho lido, neste bloco em específico, esta função está apenas efetuando as requisições para o servidor SiTEF, conforme o fluxo do TEF, sendo que não existe uma intervenção da aplicação. Acredito que neste caso seria uma lentidão mais devido a algum problema de rede ou até mesmo de alguma demora de resposta de algum servidor relacionado ao procedimento. Seria isso mesmo a explicação? Eu anexei um trecho do log relacionado ao problema para demonstrar o caso acima com mais detalhes. Desde já agradeço a resposta. ACBrTEF_CliSITEF_20180618.txt

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.