EddieBR

Tivemos um SAT que acendeu a CFe, BLO e SUP em vermelho. Tivemos que trocar. Os aparelhos que precisam ser registrados pela bematech são de Homologação segundo o suporte deles. Os de produção estão OK e só precisam ser vinculados pelo contribuinte. Ricardo, todos os SATs você está tentando ativar na mesma internet? Já tentou setar IP fixo nos equipamentos? Aqui tivemos alguns problemas com DHCP. Estou conseguindo ativar os equipamentos sem problema sábado e segunda. Tenho apenas 1 aqui que nem trocando o equipamento da certo. Só pode ser algo com o CNPJ do cliente, ou no server da Sefaz para gerar a certificação. Alguem tem algo parecido nos logs do equipamento? 20150629200551|SEFAZ-SAT|info|Status do cfeCertificacao -> (255) Rejeição: CSR enviado inválido

Testado em outro SAT hoje, persiste o problema de ativação na Bematech.

O que esta no site parece mais novo. Testei com esse seu e nada aqui também. Para comparação Ricardo. Aqui fica uns 5 minutos piscando a luz OP/AC e retorna o erro de comunicação com a SEFAZ. Se puder extrair os logs do equipamento (Use 00000000 no código de ativação). O que vejo de erros: 20150626165158|AC-SAT|info|CSR não existente. Gerando novo par de chaves 20150626165158|SAT|info|Gerando novo par de chaves 20150626165539|SAT|info|Criando backup dos números de registro 20150626165543|SAT|info|Preenchendo dados do CSR 20150626165543|SAT|info|Gerando CSR 20150626165546|SAT|info|CSR criado com sucesso 20150626165546|AC-SAT|info|Enviando CSR para a SEFAZ 20150626165547|SEFAZ-SAT|info|Status do cfeCertificacao -> (255) Rejeição: CSR enviado inválido 20150626165548|SAT-AC|info|177245|04005|Erro de comunicação com a SEFAZ|| 20150626165516|SAT|info|Criando backup das chaves 20150626165517|SAT|info|Formato RSA descohecido 20150626165543|SAT|info|Chaves criadas com sucesso 20150626165546|SAT-SEFAZ|info|Enviando requisição 20150626165546|SAT-SEFAZ|info|[ Tentativa: 1] cfeCertificacao 20150626165547|SAT-SEFAZ|info|Requisição enviada com sucesso Os logs não ficam em ordem de horário. Sempre vai ter informações no final e no meio do aquivo.

Consegui ativar um da DIMEP agora (usando o software deles). Bematech nada. Poderia mandar esse software de ativação para eu testar? Tentei pelo SATTeste e também não consegui.

Retaguarda esta OK, fiz a vinculação de 2 equipamentos agora. Porém ativação nada.

Ativamos ontem por volta das 16:00. Hoje sem sucesso ainda.

Caso vocês estejam usando o Emulador da SAFAZ, acontece realmente o travamento. Com o equipamento em produção (Bematech) isso não ocorre. É retornado falha na comunicação com a porta serial e a aplicação não fica travada. Alguém do projeto pode exclarecer melhor, mas pelo que vi as funções da DLL do SAT não tem timeout.

André, para verificar se a operação foi executada ou não no equipamento, utilize Resposta.codigoDeRetorno. Caso não tenha sido executado, irá retormar 0, ou o código de erro. Acredito que não tenha como usar algum tipo de timeout de acordo com os comandos da DLL usados no ACBrSAT. Exemplo: ACBrSAT1.ConsultarSAT; if iACBrSAT1.Resposta.codigoDeRetorno = 8000 then begin //8000 é a resposta enviada pela dll quando o SAT está em operação. end ;

Recepção de cupons voltou hoje pela manhã. Ativação ainda nada.

Testei com a correção e resolveu a exception. Problema é com a bematech mesmo, pois continua retornando o erro de falha de comunicação. Passei o caso para o suporte deles, vamos aguardar agora.

Daniel, desculpe se não deu para entender. o log do ACBrSAT não estava sendo gerado, pois a gravação do log era executada depois da exception. Eu modifiquei a função FinalizaComando para logar a resposta do equipamento antes da exception, e obter a string que esta sendo enviada para Resposta.RetornoStr. Se quiser rodo novamente com as alterações que voçê fez, mas a resposta será a mesma, só não irá dar exception. Erro|Erro na leitura da porta de comunicacao com o S@T|Header Essa string explica o list index out of bounds. Para mim não é problema do ACBr, e sim da DLL da bematech que esta mandando resposta errada.

Certo Daniel, porém com a resposta que o equipamento está apresentando, o CodigoDeRetorno será 0, pois o SAT está cancelando normalmente, porém retornando erro. Estou vendo algumas informações sobre o PIS/COFINS 05 na NFe, onde o pessoal diz que no Layout não contempla, e estao usando CST 08. Porém na NFe 3.1 passou a aceitar a CST 05 no Grupo PIS não tributado. Acredito que tenha algum problema com o SAT ao usar CST 05 no cancelamento.

Daniel, tive que modificar aqui para conseguir gerar um log, pois originalmente o log seria gerado apenas após o erro acontecer. A mudança foi: function TACBrSAT.FinalizaComando( AResult : String ) : String ; var AStr : String ; begin fsRespostaComando := DecodificarPaginaDeCodigoSAT( AResult ); Result := fsRespostaComando; fsComandoLog := ''; AStr := 'NumeroSessao: '+IntToStr(numeroSessao) ; if fsRespostaComando <> '' then AStr := AStr + ' - Resposta:'+fsRespostaComando; //log temporario DoLog('LogTeste fsRespostaComando: '+fsRespostaComando); Resposta.RetornoStr := fsRespostaComando; DoLog( AStr ); Com o meu log, a resposta que tive estranhamente foi: - 10:15:30:121 - LogTeste fsRespostaComando: Erro|Erro na leitura da porta de comunicacao com o S@T|Header Me parece que o SAT da bematech esta retornando errado, pois o cancelamento está sendo feito.

Consegui debugar. O Erro ocorre no método SetRetornoStr, na linha 371 da unit ACBrSATClass.pas. fcodigoSEFAZ := StrToIntDef( fRetornoLst[index+1], 0); List index out of bounds(3). Verificando nos logs do equipamento, o cupom foi cancelado, e ao tentar novamente retorna que o cupom já foi cancelado. Primeira tentativa: 20150622194418|AC-SAT|info|Recebendo dados de cancelamento 20150622194418|AC-SAT|info|Dados de cancelamento recebidos com sucesso 20150622194418|AC-SAT|info|Mecanismo de segurança de emissão criado com sucesso 20150622194418|SAT-AC|info|Cupom cancelado com sucesso 20150622194418|SAT-AC|info|266392|07000|0000|Cupom cancelado com sucesso + conteúdo CF-eSAT cancelado.|||PENGZUNh 20150622194419|SAT-AC|info|CancelarUltimaVenda executado com sucesso Segunda tentativa: 20150622194947|AC-SAT|info|Recebendo dados de cancelamento 20150622194947|AC-SAT|info|Dados de cancelamento recebidos com sucesso 20150622194947|AC-SAT|erro|Tentativa de cancelar um CFe já cancelado 20150622194947|SAT-AC|erro|Erro ao cancelar o cupom fiscal

Vou verificar aqui. Assim que conseguir reproduzir no equipamento em produção informo. Obrigado.

Segue a modificação (trunk). Apenas para explicar melhor, a venda ocorre normalmente após a alteração (SAT Bematech em produção). O problema esta no cancelamento, que é feito no equipamento, porém retorna "list index out of bounds (3)" ao chamar o CancelarUltimaVenda, e o arquivo XML de cancelamento não é gravado. O XML de envio pelo que verifiquei esta normal, consta a chave do cfe. Pelo emulador funciona normalmente.

Olá, verifiquei, que ao vender produtos com pis/cofins na CST05, não está gerando as tags no XML Segundo o manual, no caso da CST05, deve ser informado na tag PISAliq. Nos métodos GerarDetImpostoPIS e GerarDetImpostoCOFINS na unit pcnCFeW, alterei e coloquei o seguinte else if abaixo do else if para as csts: pis01, pis02, assim como no metodo do cofins. else if CFe.Det[i].Imposto.PIS.CST = pis05 then begin Gerador.wGrupo('PISAliq', 'Q02'); Gerador.wCampo(tcStr, 'Q07', 'CST ', 02, 02, 1, CSTPISTOStr(CFe.Det[i].Imposto.PIS.CST), DSC_CST); Gerador.wCampo(tcDe2, 'Q08', 'vBC ', 03, 15, 1, 0 {forçando vBC zerado, pois é substituição tritubária}, DSC_VBC); Gerador.wCampo(tcDe4, 'Q09', 'pPIS ', 05, 05, 1, 0 {forçando pPIS zerado, pois é substituição tritubária}, DSC_PPIS); if not FApenasTagsAplicacao then Gerador.wCampo(tcDe2, 'Q10', 'vPIS ', 01, 15, 1, CFe.Det[i].Imposto.PIS.vPIS, DSC_VPIS); Gerador.wGrupo('/PISAliq'); end Até ai tudo bem, resolveu. Porém fiquei em dúvida se seria somente essa alteração, pois ao enviar um cancelamento de um item com pis05/cofins05, o cancelamento é efetuado, porém tenho o retorno List Index Out of bounds (3) apos carregar o XML original que esta em nosso banco no ACBrSAT, chamar o metodo CFe2CFeCanc, e o CancelarUltimaVenda. Itens que não tem essa CST estão cancelamento normalmente. Pessoal que tem mais experiência com os componentes... deixei passar algo alem dessa alteração? Obs: No emulador o cancelamento funciona.

Ridículo isso ter entrado em produção. O servidor NTP deles por ex, é incomunicável com conexões da Algar/CTBC. E agora quer dizer que só podemos ativar um novo SAT depois das 12:00 de terça feira?? Brasil sil sil!!!

Consegui ativar o sat depois de levar para nossa empresa e colocar ip fixo nele. Porém agora o relógio dele esta errado. Esta +- 23:30 atrasado. Nos logs mostra que atualizou com sucesso pelo NTP... mas nada de mudar no equipamento. Ta dificil esses SATs em produção da bematech. Não temos nenhuma regra de bloqueio de firewall no roteador, e o DHCP está habilitado e o equipamento pegando IP normalmente.

Felipe, foi feita a vinculação do equipamento no retaguarda SAT usando o certificado digital do cliente? Hoje pegamos um RB-1000 FI que mesmo apos a vinculação apresenta o mesmo erro. Os outros conseguimos ativar normalmente apos a vinculação.

Suporte da Bematech esquece... fica uns 2-3 dias para conseguir falar la. Eles não se prepararam para os problemas com os equipamentos. O 0800 tem q ficar ligando sem parar ate conseguir.. parece q é só uma linha de telefone. Suporte SAT é apenas com o Júlio (esse skype acima), e ele quase nunca responde. Já pegamos 2 equipamentos em produção com defeito que a solução foi a troca, pois eles não dão nenhuma posição.

Outra forma que pensei seria modificar a função que importa o XML no ACBrSAT, para setar EhCombustivel como True quando o IndRegra do item estiver Truncando. Mas eu concordo em seguir a especificação atual, e deixar truncamento = combustivel.

Daniel, me deparei com essa situação aqui também. Verifiquei que no metodo TCFeW.GerarDetProd, é lida a propriedade EhCombustivel, e entao define-se DecQtd e a indRegra do item. Verificando as especificações técnicas, deve-se usar 3 decimais e truncamento apenas em combustíveis, o restante deve ser Arredondamento e 2 decimais. Entendo que uma maneira simples seria remover a EhCombustivel, e deixar a aplicação definir a IndRegra manualmente. Caso IndRegra for Truncamento, usa-se 2 decimais, senão usa-se 3. Não seria uma opção viável?

O ACBr vai conseguir comunicação com o equipamento que estiver na USB Local. Você precisa desenvolver algum servidor de SAT, o qual receberá comandos via TCP/IP, ou via banco de dados do seu PDV. O seu servidor SAT ficaria onde o equipamento está ligado na porta USB. Dessa maneira é possivel compartilhar o equipamento para vários PDVs. Aqui fizemos dessa forma.

Também estou tentando instalar. Fui tentando mudar algumas coisas, mas ocorrem erros, em várias units. Se precisar de alguem para testar a compilação com alguma alterações, estou a disposição.